一个容易被默认掉的假设
钱包的批量调用接口（EIP-5792）允许应用把多条合约调用打包，用户一次确认、一串操作排队执行。多数人对它的预期是“要么全部成功，要么全部回滚”，就像把几件事锁进同一个信封。这个预期在严格模式下成立，但一份处于停滞状态的提案 EIP-7867 明确告诉开发者：不必总是如此。它给批量调用加了一个叫 flowControl 的能力，应用可以主动声明两种放宽——整批的原子性降级，以及单条失败后的处理策略。停滞状态意味着它短期内不会成为强制标准，但它描述的问题真实存在，值得先弄懂。
批级别的三档原子性
按原文的模式定义，批级别的 atomicity 字段有三个取值：strict、loose 和 none。严格批次在链重组面前仍保持原子，也就是说重组后要么全体仍在、要么全体不在。宽松批次没有这个保证：其中的调用可能最终落进互不相邻的不同区块，规范原文特别强调这一点。第三档 none 则连统一批处理都不承诺。换句话说，原子性不是一个物理定律，而是一个由接口协商出来的档位，应用可以根据成本和场景在其中选择。你的钱包会通过能力查询接口知道每个账户支持哪些档位，能力协商的思路与 应用先问钱包会哪些本事：ERC-7902 能力协商清单怎么核对 属于同一家族。
单条调用上的三个动作
除了整批档位，flowControl 还能挂在单条调用上，字段是失败后的行为：rollback 回滚整批，halt 停止执行后续条目，continue 无视失败继续往下。三者的差别在长批次里最直观：一笔十六步的批量操作，第七步因为滑点超限失败，回滚档让用户回到起点，停止档保住前六步、放弃后九步，继续档则可能带着失败记录把后面九步也推完。规范还规定，如果请求不符合这套模式定义，钱包必须以 INVALID_SCHEMA 拒绝。也就是说，弹窗里如果展示了带流控语义的批量请求，这些字段是接口的一部分，不是应用随口写的备注。
为什么应用想要松绑
严格原子的代价是执行与打包层面的约束：一整批塞进同一个执行环境，失败即全部作废，重签重发。对某些应用，宁可接受“各条独立上链、个别失败跳过”，换取一次提交成功率和大批次容量。规范的安全考量部分替用户写下了代价：在宽松批次里，任何两条调用之间都可能插入别人的交易；宽松批次的包含时间没有任何上限约束；即便是严格批次，在区块重组面前也可能从成功翻成失败。原文建议应用像对待普通交易一样，在合约调用里自行写入截止时间和超时逻辑，而不是指望批量接口替你兜底。
用户视角怎么读
把上面的规则翻译成你真正要防的事：第一，弹窗标题写着批量操作，不等于这批操作被同一把锁锁死，读的时候找一找有没有原子性说明；第二，宽松批次下“前一步成功了所以后一步一定安全”的直觉不成立，中间可能隔着别人的交易和不可控的时间；第三，失败后继续是一个真实存在的选项，如果你的授权场景里任何一步失败都不该继续（典型是资金链式操作），遇到无法确认档位的复杂批次，宁可换回逐笔签名的保守路径。钱包界面是否会显式展示这些档位，各产品实现不一，能查到的是它的能力清单，查不到时按最宽松的假设要求自己。
现状与纪律
EIP-7867 目前是停滞状态，跟进实现者寥寥，多数钱包对批量调用仍按严格原子处理。这篇说明的价值在于建立正确的默认预期：批量调用是效率工具，原子性是它的一个可配置属性而不是天然属性。凡是把多笔资产动作打包的请求，签字前问三件事：这批操作各自去哪个合约、有没有失败即停的保证、你能不能承受其中一部分先落地。答不上来，就要求拆成单笔逐个确认。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。