这个推理听起来是对的:一个钱包只有一次机会,那五个钱包就有五次。
★它们得到的是对同样那几个被争抢的 slot 的五次尝试,各付各的手续费 —— 而且常常写同一批账户,于是互相串行化。★
为什么它不能让你的胜算翻倍
调度是按交易的,不是按钱包的。 五个钱包发出的五次提交,是同一个窗口里的五笔交易:
1 个钱包: 1 笔交易,1 份手续费,★队列里 1 个位置★
5 个钱包: 5 笔交易,5 份手续费,★5 个位置 —— 在同一条队列里★
由此推出两件事:
★不管落块一个还是一个都没有,你都付五份手续费。★ 在一个大部分尝试都会 revert 的新盘上,那是五次 revert 而不是一次。
它们会互相争用。 买同一个代币意味着写同一个池子账户,而写同一个账户的交易会串行化。★你的钱包现在排在彼此后面。★
老实的表述是: 五次平庸的提交加不出一次好的提交。★如果一个钱包的提交路径在输,五份拷贝就输五次。★
如果你的钱包策略没问题、交易还是会错过,免费领个 BoltTx key 改一行就能测测提交路径。
拆分真正有用的场景
★行得通的那些场景有一个共同属性:这些钱包不在抢同一个东西。★
按策略隔离。 套利钱包和打新钱包有不同的风险画像、不同的余额、不同的失败方式。分开意味着一个炸了不会让另一个停摆。
限定爆炸半径。 热钱包只装运营资金。★它的余额就是一个被攻破的进程能损失的上限★ —— 这是"按信任等级拆"而不是"按数量拆"的理由。
按用户记账。 Telegram 机器人或任何多租户服务,需要一人一钱包才能把余额和历史归属清楚。
不同市场。 交易互不相关交易对的钱包不会争用,因为它们写的是不同账户。
★这些的共同点是"关注点分离",不是"尝试次数翻倍"。★
限流不是按钱包算的
多钱包方案背后一个常见假设是"网络会限制一个钱包"。★它不会 —— 你真正面对的限制在别处。★
| 限制 | 作用于 |
|---|---|
| RPC 限流 | ★你的 API key,不是你的钱包★ |
| 账户写入争用 | ★那个账户,不是钱包★ |
| 区块空间 | 整个网络 |
| 单笔计算 | 那笔交易 |
加钱包一个都抬不高。 如果你正在被限流,更多钱包走同一个端点只会更糟,不会更好。
★按钱包拆分确实抬高的只有一样:nonce 独立性 —— 不同钱包不会排在彼此"同一手续费支付方"的交易后面。★ 那是一个真实但很窄的收益,而且只在"你从一个钱包同时发很多笔交易"时才有意义。
密钥管理才是真正的成本
每一个钱包都是一把必须存在某处的密钥:
// ★从一个种子派生,而不是存 N 把密钥。★
const path = `m/44'/501'/${index}'/0'`;
const keypair = deriveKeypair(masterSeed, path);
★派生钱包意味着只有一个秘密要保护,而不是很多个★,而索引变成了一个普通的配置值,不再是敏感材料。
代价是: 主种子是每一个派生钱包的单点失守。当这些钱包共享同一个信任等级时这可以接受,而当它们不共享时就是错的 —— ★金库密钥不该和热交易钱包从同一个种子派生。★
实操规则:
密钥绝不出现在日志、错误消息或异常栈里。
静态加密,加密密钥存放在应用数据库之外。
★假设进程会被攻破,并据此决定热钱包放多少。★
出资与归集
每个钱包都需要 SOL 付手续费和租金,这产生了一个运维循环:
// ★原子认领,免得两个 worker 都去打款。★
const claimed = await db.query(
`INSERT INTO funding (wallet, hour_bucket) VALUES ($1, $2)
ON CONFLICT DO NOTHING RETURNING id`,
[wallet.toBase58(), currentHourBucket],
);
if (!claimed.rowCount) return;
if (await hasPendingFunding(wallet)) return; // ★在途的读出来仍然是低余额★
★那个"在途检查"是最容易漏掉的部分。★ 一笔在途的转账还没落块,所以余额看起来仍然低 —— 一个天真的循环会每个周期都给同一个钱包打款,直到第一笔确认。
归集回来也有它自己的成本。 从很多钱包里把灰尘归集起来,花的手续费可能超过那些灰尘的价值。★设一个阈值,低于它的余额就不管。★
别让你的钱包互相打架
如果你确实要在相关市场上跑多个钱包,就把它们协调起来:
// ★一个被争抢的机会,只让一个钱包上。★
const claimed = await claimOpportunity(opportunityId, walletId);
if (!claimed) return; // 另一个钱包已经拿走了
★没有协调,你自己的钱包会互相抬价★ —— 抬高你付给自己的手续费,并且在同一个池子账户上串行化。
行得通的模式是:一次决策,一次提交。 如果你想要提交层面的冗余,就把同一份已签名字节发给多个端点,而不是从不同钱包构建不同的交易。相同字节产出一个签名,不可能重复执行。
上链应该是什么水平
我们投递节点上的真实交易:中位确认 336 毫秒 —— 不到一个 slot。
★改善那个数字,一次性帮到你所有的钱包。而加钱包对其中任何一个都没有改善。★ 这就是在扩大钱包数量之前值得做的那个对比。
BoltTx 在这里的位置
我们负责提交。钱包结构、密钥管理和出资完全留在你的代码里。
提交走我们自建的四区域投递节点,带 SWQoS 路由,不暴露公共 mempool —— 交易在落块之前、传输途中观察不到。★API key 不绑定钱包 —— 你可以用一个 key 从任意多个钱包发送。★
你在本地签名。我们不托管资金、不代签、不修改交易内容。tip 带在交易里、从签名的那个钱包链上支付,交易失败时跟着一起 revert —— 这是 Solana 原子交易的机制决定的。只有到达链上的交易才计费。
免费领 API key,没有月费:
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
常见问题
钱包更多能提高我抢新盘的成功率吗? 不能。调度是按交易的,不是按钱包的,所以五个钱包是同一个争抢窗口里的五笔交易,各付各的手续费。
我的钱包为什么会互相竞争? 因为买同一个代币意味着写同一个池子账户,而写同一个账户的交易会串行化。你自己的钱包最后排在了彼此后面。
Solana 的限流是按钱包算的吗? 不是。RPC 限流作用于你的 API key,写入争用作用于那个账户。 加钱包两个都抬不高,而且可能让限流更严重。
什么时候多钱包才真正有用? 隔离策略、限定被攻破进程的损失上限、多租户服务的按用户记账,以及交易互不争用的不相关市场。
很多钱包的密钥该怎么存? 用派生路径从一个种子派生,这样只有一个秘密要保护。不同信任等级的钱包要用不同的种子。
所有钱包从一个种子派生有什么风险? 那个种子是每一个派生钱包的单点失守。 当它们信任等级相同时没问题;当金库和热钱包共用一个种子时就是错的。
每个钱包需要多少 SOL? 够在抬高费率下付手续费,加上它将创建账户的租金,再加租金豁免下限。估算金库规模时要乘以钱包数量。
我的出资循环为什么反复给同一个钱包打款? 因为在途的转账还没落块,余额读出来仍然低。要显式追踪在途出资,否则每个周期都会再触发一次。
从很多钱包归集灰尘值得吗? 往往不值。归集小额余额的手续费可能超过它们本身的价值,所以设一个阈值,低于它就不动那个钱包。
怎么阻止我自己的钱包互相抬价? 原子地认领机会,让每个机会只有一个钱包去做。 没有协调,你会抬高付给自己的手续费,并在同一个账户上串行化。
提交冗余的正确做法是什么? 把同一份已签名字节发给多个端点。 相同字节产出一个签名、不可能重复执行 —— 不像"从不同钱包构建的不同交易"。
一个 API key 能用于多个钱包吗? 能。提交端点不绑定钱包,所以一个 key 可以发送任意多个钱包签名的交易。
每个策略该有自己的钱包吗? 一般该。不同策略有不同的风险画像和失败方式,而隔离意味着一个用光 SOL 不会让其它的停摆。
多少个钱包算太多? 当出资、归集和密钥管理花掉的注意力超过这份隔离的价值时。 钱包数量应该由一个理由推出来,而不是由"希望成交更多"推出来。
按钱包拆分能避开 nonce 冲突吗? 它能避免"同一手续费支付方的交易排在彼此后面",这是一个真实但很窄的收益,只在单个钱包高并发发送时才有意义。
提高成交率最快的办法是什么? 改善提交路径,它同时帮到每一个钱包。 加钱包对其中任何一个落块行为都没有改善。
延伸阅读
- 交易机器人该在钱包里放多少 SOL
- Solana 交易机器人该部署在哪
- 防止 Solana 交易重复执行
- Solana 交易机器人的安全
- Solana 交易上链完全指南