智能账户钱包宣传”一次签名完成多步操作”时，背后有两种截然不同的实现路线：一种靠 ERC-4337 的 UserOperation 管线，另一种就是 ERC-7638 提出的批量调用编码。这条提案很薄，但正好是理解”批量确认到底确认了什么”的最小切面。
规范本体：把多笔调用压成一串字节
ERC-7638 规定的内容非常具体。一笔调用被编码为四段固定结构：to 占 20 字节（目标合约地址）、value 占 32 字节（以 wei 计的 ETH 金额）、data length 占 32 字节（数据段长度）、随后是可变长度的 data。多笔调用首尾相接拼成一个字节串，由钱包把这个字节串发给用户的智能合约账户执行。提案特意指出：不用 Solidity struct 而用裸拼接，是因为 to/value/data 类型固定，struct 会为每个元素重复打包类型信息、多花 gas；而合约端用 slice 从 bytes calldata 里切片读取是省 gas 的读法。换句话说，这套编码的”标准”就是格式本身，账户合约的具体实现与函数命名留给项目自由发挥。
原子性：批量最常见的安全理由
批量的第一动机不是省 gas，是失败即全失败。经典例子是 approve 加 transferFrom 连着做：分开签两笔，如果第一笔成功第二笔失败，你就把一个 ERC-20 授权永久留在了链上，等着被人划走——这正是钱包连接过的网站清单怎么清：断开连接和撤销授权是两件事反复强调的”遗留授权”事故。把两步装进同一个批量调用里，任何一步失败则整体回滚，授权随交易一起消失。这个特性与 EIP-7867 给批量调用加原子性开关的思路同源批量调用一定同生共死吗？EIP-7867 给原子性松绑的两档开关，区别是 ERC-7638 只定义数据怎么装、由账户合约决定要不要逐笔容错。也有非原子需求：一串”最好都成、坏一笔也无所谓”的领取类操作，硬做原子反而全单失败，用户要在签名前确认自己账户合约的实现是哪种语义。
代付 gas：与 ERC-4337 并行的另一条路
提案还描述了一种代付玩法：用户把”我要执行的若干调用 + 给代收人转 10 USDT 手续费”编进同一个批量字节串并签名交给代收人；代收人觉得费用够就自己垫 ETH 提交上链，执行完拿到那 10 USDT。这与 ERC-4337 的 gas 代付目的一样，但提案明确两者不互斥、可在同一账户里并存。用户侧的安全账很清楚：你签的不是”授权某代收人能动我的账户”，而是一份内容完整、当场可见的交易——所以核对纪律与直接发交易完全一致，收款地址、金额、目标合约逐字段看硬件钱包的小屏幕怎么读：地址回显与盲签的信任边界的设备屏核对法，批量场景下每个 to 都要看。
签名前怎么把一串调用看完
批量签名弹窗是钓鱼的高发位：列表里前几项是人畜无害的授权，最后一项藏一笔转账。固定做法是问三个问题、走两步核验。三个问题：这一串一共几笔？有没有哪一笔的 to 是你没主动接触过的合约？除了”我要做的事”之外还有没有多余的 approve？两步核验：先要求钱包展示每笔调用的解码视图（解码原理见交易的 Input Data 怎么读？方法选择器与参数解码），再抽查金额单位是否按代币小数位还原正确（Wei和Gwei是什么？手续费单位怎么换算）。设备端签名时重复同一流程；钱包显示与设备显示不一致时，一切以设备为准，这条纪律在硬件钱包的固件由谁签名：设备认证与真伪核对的边界的固件签名讨论里论证过。
什么时候不该用批量
三件事别塞进一次批量：时间敏感的抢跑型交易（拆单反而降低整单失败率）、含链下条件的操作（预言机喂价失败会连坐整串）、以及”给自己设永久授权+别的事”的组合（万一前面失败后面没执行，你反而漏做了该撤销的一步）。把它当成收银台的”打包袋”理解：袋子里每样东西仍要单独扫码核对，批量改变的是确认次数，从不改变每笔操作的真实后果。
风险提示：批量调用中任何一笔都可能造成不可逆资产变动，失败回滚也不等于零成本（gas 仍消耗）；本文不构成投资建议，具体实现语义以你所用账户合约的文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。