以太坊开发者 Marchhill 提交 EIP-8437 草案，提议通过 eth/73 协议传播证明包装数据，并增加一种可选模式：交易可以先将原始签名交给聚合器，无需提前生成 STARK 证明。该提案仍处于 Draft 阶段，尚未合并，其意义主要在于调整签名见证数据的传递与检查流程，实际可用性仍需验证。
可选提交模式调整证明生成的先后顺序
这项安排涉及交易提交者与聚合器之间的工作分配。在拟议的可选模式下，提交交易时可以先提供原始签名，把生成 STARK 证明的环节后移。这里的变化是提交时点与处理顺序，不能据此认定验证要求已经减少，也不能将原始签名的提交等同于证明已经生成。
从机制看，这为尚未预先生成证明的交易提供了一条拟议处理路径。但流程能否顺利推进，取决于聚合器如何检查收到的数据、组织待处理任务，并衔接后续证明生成。提案涉及的队列限制、过期清理与失败重试，正是这条路径需要共同解决的问题。
程序包随交易传播，改变验证规则的接入方式
EIP-8437 还提出，让经过认证的程序包随交易传播，并在资源受限的沙箱中执行指定程序的独立检查，以验证见证数据。沙箱的作用是约束程序运行可使用的资源，使接收到的检查任务在受控环境内执行。
按照草案设计，新程序无需为每一种签名方案分别开发原生适配器。这意味着，接入不同签名方案的部分工作可由随交易提供的程序承载。其潜在影响在于验证功能的扩展方式：若方案得到验证，新增程序与既有验证流程之间可以形成更明确的接口关系。
不过，程序包经过认证与程序检查本身正确，是两个需要分别成立的条件。认证安排不能替代密码学验证，也不能单凭存在沙箱就认定运行成本可控。草案中的资源限制提供了设计方向，具体边界仍要依靠测试确定。
队列治理决定延后生成证明是否可操作
提案计划限制批处理队列规模、清理过期交易，并在正式生成证明前重新检查记录，以支持失败重试。这些安排说明，原始签名进入聚合器后，仍有一段需要持续管理的待处理过程。
限制队列规模是在约束积压任务，清理过期交易则避免失效记录继续占据处理位置。生成证明前再次检查记录，有助于减少基于过时状态继续处理的情况。但失败重试也意味着同一任务可能经历多轮处理，队列容量、记录有效性和重试机制需要配合，才能判断这条流程是否具备稳定的执行条件。
从这些安排看，EIP-8437 值得关注的重点是证明生成前的验证与任务管理如何衔接。将部分工作后移，可能改变参与者的处理负担；是否降低整体成本或改善处理效率，目前尚无基准测试支撑。
关键验证未完成，当前仍是协议设计提案
草案尚未完成 VM 与密钥绑定一致性验证、密码学验证及性能测试，也尚未进行基准测试。因此，现阶段既无法据此量化性能收益，也不能认定其安全边界已经得到充分检验。
我们的判断是，这项提案首先需要证明两件事：随交易传播的程序能够正确检查对应见证数据，以及原始签名提交、排队、重检和证明生成这一整条流程能在资源约束下运行。前者关系到验证结果是否可信，后者关系到可选模式能否实际承载任务。后续应观察这些验证与测试结果，以及草案是否进入合并阶段；在此之前，eth/73 的相关安排仍应视为拟议设计。
