在 EIP-8361 标准下，交易有效性证明的工作机制是怎样的？

EIP-8361 允许 EIP-8141 框架交易在点对点负载之外携带简洁的 STARK 证明，使节点能够确认验证前缀已在声明状态假设下批准该交易。节点只需检查一份证明、其依赖项及相关状态条件，无需反复执行同一机制，这有助于降低复杂账户逻辑的验证成本。本文详细梳理了有效交易如何获得证明、节点如何检测过期或欺诈性交易、为何证明引用前一有效状态而不是成为 Merkle 根，以及区块包含后证明为何被丢弃。

文中还将 EIP-8361 与主流 rollup 安全机制区分，包括 ZK 证明（在接受前确立正确性）和欺诈证明（通过挑战流程证明无效转移）。同时，文章澄清了 ECDSA 签名、量子安全、潜在量子计算机风险及该提案与扩容方案相比更狭窄的适用范围。技术解读面向钱包团队、客户端开发者、证明者运营者及评估承载证明交易如何支持更复杂以太坊验证的用户。需要注意，EIP-8361 目前仍为草案网络提案，尚未成为正式共识规则。

重点摘要

• EIP-8361 允许 EIP-8141 框架交易以链下传输元数据形式携带准入证明。
• 链下证明者根据声明假设执行验证前缀，生成与交易、付款人、依赖项及有效性条件绑定的 STARK 证明。
• 接收节点进行无状态检查，验证证明及依赖项，并将假设与当前以太坊状态比对。
• 有效证明允许交易进入内存池，无需重复完整验证前缀模拟。
• 证明不决定区块有效性、不影响执行结果，也不会成为以太坊永久状态的一部分。交易被包含或从内存池移除后，证明即被丢弃。

什么是 EIP-8361 交易有效性证明？

EIP-8361 定义了针对 EIP-8141 生成的交易的准入方法，目标是让某些计算量大的交易在节点转发至公共内存池前的评估变得足够便宜。

EIP-8141 框架交易可包含可编程逻辑，用于判断发送方是否授权、由谁支付执行费用及特定条件是否满足。这些逻辑体现在交易普通执行帧前运行的验证前缀中。

在常规模拟准入下，每个接收节点都需执行该前缀判断交易能否进入内存池。EIP-8361 提供了另一选择：证明者在链下执行一次前缀，生成密码学证明，表明以 APPROVE 结果及指定付款人终止。

交易与证明一同传递。节点验证证明，无需重建完整验证过程。

更广泛的 EIP-8361 框架 关注承载证明的内存池准入，EIP-8361 内存池验证流程 则决定接收节点是否接受、保留、搁置或移除这些交易。

截至 2026 年 8 月 6 日，EIP-8361 以草案拉取请求 #12075 的形式发布，作为标准跟踪网络提案。该提案本身不会引入新交易类型或更改以太坊共识。

EIP-8361 密码学证明如何工作？

该证明针对特定断言，而非声称已知所有未来执行结果。

简化形式下，证明者需证明：

交易 T 的验证前缀，在声明的假设及依赖项下，遵循 EIP-8141 跟踪规则，并以 APPROVE 及付款人 P 结果终止，受声明条件约束。

提议的公共输入将证明绑定至五个要素：

这种绑定确保一个交易的有效证明无法简单地附加到另一个包含不同数据、依赖项、条件或付款人的交易上。

私有见证包含评估前缀所需的信息，包括声明依赖列表内容。最终证明展示了计算的正确性，无需每个接收节点都重复执行。

EIP-8361 建议复用与 EIP-8288 相关的证明格式及入口验证机制。STARK 能以简洁证明表示大规模计算，无需每个验证者重现原始计算负载。

假设向量在交易验证中的作用

密码学证明可证明某一计算对特定输入是正确的，但内存池节点需判断这些输入是否与当前以太坊状态匹配。

EIP-8361 用假设向量（A）解决此问题，列出验证前缀读取的每个状态值。条目包括地址、存储键或余额引用、比较类型及数值。

定义了两种比较类型：

• EQ 假设：当前状态值等于证明声明值；
• GEQ 假设：当前状态值大于或等于声明阈值。

EQ 适用于代码哈希、nonce 或存储分支等，GEQ 适用于单调递增需求，如检查付款人余额至少覆盖预付款。

例如，智能账户验证前缀仅在 paymaster 余额不少于 0.2 ETH 时批准交易。证明者可记录 GEQ 假设，阈值为 0.2 ETH。只要余额大于等于 0.2 ETH，节点可继续视证明有效，无需因余额增加或超过阈值反复生成新证明。

该设计避免了将证明锚定于完整状态根，或为整个以太坊状态生成大规模 Merkle 证明。电路针对声明值评估验证前缀，节点则与当前状态比对。

EIP-8361 下的交易有效性证明机制

交易验证流程遵循有序检查：

1. 无状态检查：节点检查交易有效性，确认依赖或签名列表格式正确。格式错误交易在高成本证明验证前被拒绝。
2. 验证准入证明：节点用指定验证密钥验证 STARK。失败则说明声明的验证计算未成立。
3. 验证外部依赖：证明可假定签名或其他依赖项有效。节点需分别验证这些依赖，并确认其列表与承诺的依赖哈希匹配。
4. 检查有效性条件：节点评估声明条件，可能包括截止时间、插槽或 epoch 窗口、到期范围或 nonce 要求。
5. 假设与实时状态比对：对每个 EQ 条目检查相等，对每个 GEQ 条目比较阈值。
6. 准入交易：所有检查通过后，节点可接受并传播交易，无需模拟完整验证前缀。

该流程防止证明绕过常规结构、签名、状态或时序检查，仅改变了做出准入决策的计算方法，不改变交易本身的有效性要求。

以太坊状态变化时

内存池准入并非永久保证，以太坊状态会在交易进入池后继续变化。

EIP-8361 下，节点在新区块改变链头时会重新检查有效性条件及假设向量。无需重新生成证明、重跑验证前缀或再次验证同一证明。先前已验证的证明作为声明输入下的验证函数缓存结果保留。

EQ 检查失败通常令证明失效，因为精确输入已变。除非发送方生成新证明或交易符合常规模拟准入，否则节点必须移除该交易。

GEQ 条件失败时，节点可暂存交易而非彻底移除。若付款人或 paymaster 后续获得足够资金，节点可再次检查阈值并激活交易。

这一机制使假设向量不仅是对某一历史状态的 Merkle 承诺，更明确了哪些状态变动会实际令批准失效，哪些变动仍兼容。

区块包含后证明为何被丢弃

EIP-8361 证明仅用于公共内存池的准入与传播，不是权威性地证明所包含交易产生了正确状态转移。

一旦验证者将交易写入区块，以太坊通过常规协议执行。EVM 按规范区块状态执行验证前缀及剩余帧。共识客户端按以太坊规则判断区块是否有效。

因此，准入证明：

• 不写入区块；
• 不添加到交易 calldata；
• 不出现在回执中；
• 不成为 Merkle 树或状态根的一部分；
• 不产生永久链上状态变更；
• 交易被包含或移除后无需保留。

丢弃证明可避免为已完成网络用途的信息永久承担 calldata 成本和状态膨胀。交易本身留在链上，临时证明封套不会。

EIP-8361 证明与 ZK-Rollup 有效性证明对比

EIP-8361 采用密码学证明技术，但其准入证明不等同于 ZK rollup 的有效性证明。

ZK rollup 通常用 ZK-SNARK 或 ZK-STARK 证明交易批次正确性。Layer 1 合约接受证明后，rollup 可直接最终状态转移，无需乐观 rollup 的欺诈证明挑战期。

EIP-8361 不用于证明 L2 批次、授权即时 rollup 提现或保证 L2 链状态永不失效。其证明仅为区块包含前的临时网络载体。

零知识证明可在不泄露全部私有见证数据的情况下验证断言，但 EIP-8361 并非隐私提案。“简洁证明”与“零知识”相关但不等同。

Layer 2 到 Layer 1 的提现因有效性证明可加速，因为 ZK rollup 无需乐观 rollup 的欺诈挑战期。最终提现时间仍取决于证明生成、L1 验证、跨链桥规则及以太坊终局性。EIP-8361 不提供此提现机制，其证明仅用于单笔 EIP-8141 框架交易的内存池准入。

乐观 Rollup 的欺诈证明机制

欺诈证明采用不同安全机制。乐观 rollup 初始接受拟议状态转移，允许挑战者在争议期内证明欺诈。争议解决可能需多轮或精简执行证明。

EIP-8361 试图在交易被相关内存池类别接受前确立准入断言。准入后无挑战期，参与者无法证明前缀结果欺诈。

核心区别在于时机和范围：

• 有效性证明在接受前证明指定主张；
• 欺诈证明允许乐观主张，除非被成功挑战；
• EIP-8361 准入证明关注内存池策略；
• Rollup 欺诈证明关注 L2 状态转移正确性。

重复 EVM 执行与简洁验证的权衡详见 EIP-8361 与交易模拟对比。

EIP-8361、复杂账户验证与后量子安全

可编程账户可能采用多重签名、密钥轮换、恢复规则、非标准签名方案、后量子签名候选、支出策略或高消耗零知识校验。部分逻辑虽有效，但模拟成本过高。

EIP-8361 通过让验证对证明者成本高、对验证者成本低，力图为此类账户保留交易公开传播权，并减少将复杂授权逻辑移至执行阶段的压力。

该机制不保证所有智能合约安全或建立完整后量子安全。STARK 可避免部分椭圆曲线证明系统相关假设，但交易仍可能依赖公钥、签名方案、客户端实现、钱包代码或独立安全属性的验证密钥。

交易创建者、钱包、证明者及客户端责任差异详见 EIP-8361 对钱包、节点及开发者影响。

例如，交易员评估以太坊账户抽象进展是否影响市场情绪时，可将提案里程碑与 ETH/USDT 行情图 对比，尽管价格走势无法确认草案 EIP 已被实施或采纳。

风险与限制

EIP-8361 仍为早期草案，其证明格式、限制、依赖项、术语及实现细节在标准化前可能变化。

主要技术风险包括：

证明生成集中化：生成 STARK 需专用软件与大量计算。若仅少数服务可高效生成证明，钱包可能依赖中心化证明者基础设施。

拒绝服务压力：验证证明虽比重复原计算便宜，但并非无成本。客户端需一致的证明大小限制、节点速率限制及失败归因，防止无效或超大证明淹没节点。

假设完整性：仅当假设向量包含验证前缀用到的全部状态读取时，证明才有意义。电路或客户端遗漏依赖项可能导致准入决策错误。

状态陈旧：证明在声明条件与当前状态不符时，仍可能在密码学上正确。节点需在交易留存池中时持续重查 A 和 C。

无执行保证：内存池准入不保证区块包含或最终执行成功。其他交易可能在包含前更改发送方 nonce、余额、代码、存储或其他相关状态。

实现复杂性：客户端、钱包及证明系统需就证明编码、验证密钥、依赖处理、节点行为及重验证规则达成一致。不一致实现可能导致交易传播碎片化。

EIP-8361 是否为 Tapered Issuance Burn 提案？

早期讨论中，EIP-8361 编号曾与以太坊货币政策提案 Tapered Issuance Burn 相关。该提案后被定为 EIP-8363，EIP-8361 指网络类别下的交易有效性证明。两者无关：EIP-8361 关注基于证明的内存池准入，Tapered Issuance Burn 则根据活跃质押余额调整共识层奖励经济。

结论

EIP-8361 交易有效性证明将可编程交易验证的高成本环节从每个接收节点转移至链下证明者。生成的 STARK 将 EIP-8141 交易与批准结果、付款人、依赖项、条件及状态假设绑定，使节点能在内存池准入前验证简明断言。

该机制最适用于智能账户存在合法但超出现实模拟极限的验证逻辑。其核心约束同样重要：证明仅适用于网络层准入。以太坊在包含时仍按常规执行交易，临时证明因无共识或链上角色而被丢弃。

常见问题

ZK rollup 如何利用有效性证明？

ZK rollup 在链下处理交易，将其分批，并为每批生成有效性证明。该证明通常采用 ZK-SNARK、ZK-STARK 或多项式承诺方案构建，使以太坊合约能在不重放每笔交易的情况下验证状态转移正确性。

有效性证明能否保证 L2 链永不失效？

有效性证明可在电路、验证合约、密码学及实现均正确时，阻止 L1 验证者接受无效状态转移。但无法消除代码错误、数据可用性、跨链桥、排序者、治理或升级控制等相关风险。

为什么 ZK-rollup 通常提现更快？

ZK rollup 在提交并验证有效性证明后可直接最终提现，无需等待乐观 rollup 的欺诈证明挑战期。提现仍取决于证明生成、批次提交、跨链桥规则及以太坊终局性，“立即”并不总等于瞬时。

有效性证明与欺诈证明有何不同？

有效性证明在状态转移被接受前确立交易正确性。欺诈证明则采用乐观模式，状态转移可暂时被接受，后续可被挑战。许多乐观 rollup 挑战期约为七天，具体时长视实现而定。

零知识证明是否总能隐藏交易数据？

不一定。零知识证明可在不暴露私有见证的情况下验证断言，但隐私取决于哪些输入被隐藏。许多 ZK rollup 主要用 ZK 证明实现可扩展交易验证，而非完全隐私交易。

ZK-SNARK 与 ZK-STARK 有何区别？

ZK-SNARK 通常生成小型证明且验证成本低，但许多设计需可信设置。ZK-STARK 无需可信设置，普遍被认为更具抗未来量子计算攻击能力，但证明体积通常更大。

Merkle 证明验证什么？

Merkle 证明可确认特定数据属于由 Merkle 根代表的数据集，无需暴露或下载完整数据集。它证明包含性或排除性，而不是一整个交易批次或状态转移的正确性。

有效性证明能否降低链上资源消耗？

可以。它可将大规模链下计算压缩为单一证明，链上验证成本远低于重放每笔交易。实际节省取决于证明验证成本、批次规模、calldata 或 blob 使用及 rollup 实现。

有效性证明能否降低 51% 攻击风险？

不能直接降低。有效性证明保护已验证 Layer 2 状态转移的正确性，而 51% 攻击关乎以太坊共识与分叉选择，两者应对的安全风险不同。

EIP-8361 证明与 ZK-rollup 证明相同吗？

不同。ZK-rollup 证明用于验证 Layer 2 交易批次，并支持状态终局性及提现。EIP-8361 证明用于单笔 EIP-8141 框架交易的内存池准入，不写入区块，且被包含或移除后即丢弃。

免责声明

本内容仅供教育用途，描述一项以太坊草案提案，其规范及实现状态可能发生变化。内容不构成金融、安全或软件部署建议。开发者在构建生产系统前应核查最新 EIP 文本及客户端要求。