EIP-8105 通用内嵌加密交易内存池Universal Enshrined Encrypted Mempool协议全解析【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕以太坊核心层提案EIP-8105Universal Enshrined Encrypted Mempool通用内嵌加密交易内存池展开系统讲解其将加密交易内存池内嵌进协议层的设计动机、密钥提供方注册表与信任图、两种新增 EIP-2718 交易类型、密钥发布与 PTC 验证流程、区块排序与有效性规则以及执行语义与安全模型。读完本文你将能完整理解该提案如何在不依赖单一加密方案的前提下抵御抢跑front running与三明治攻击、增强弱审查阻力并掌握其与 EIP-7732ePBS、EIP-1559 的衔接方式。一、提案背景与动机1.1 要解决的三类问题EIP-8105 的目标非常聚焦在 Motivation 一节中明确列出防止恶意的交易重排序攻击用户在公开内存池提交的交易可被观察攻击者可据此实施抢跑front running与三明治sandwiching攻击。增强协议的实时弱审查阻力交易内容对包括区块构建者在内的中间方暂时不可见攻击者难以精准筛选并审查特定交易。降低区块构建者等协议参与者的监管风险通过临时蒙蔽blinding构建者使其无法看到交易内容从而减少其面临的选择性审查压力。需要特别强调该提案的目标不是提升用户隐私。所有交易最终都会在链上公开揭示它保护的是包含进区块之前这一时间窗口内的交易内容而不是交易的长期机密性。1.2 与既有工作与路线图的关系该提案建立在两个重要先例之上Shutterized Beacon ChainShutter 化的信标链将阈值加密与信标链结合的研究工作。Gnosis Chain 上已上线运行的协议外out-of-protocol加密内存池实现一个经过真实环境检验的加密内存池方案。此外提案明确指出该设计与**内嵌的提议者-构建者分离enshrined proposer-builder separationePBS**天然契合是 EIP-7732 所描述的以太坊路线图的逻辑延伸——这也解释了为什么提案要求依赖requiresEIP-7732。二、总体设计技术中立的加密内存池提案的核心思路可以概括为一句话让用户以加密形式提交交易直到交易被包含进区块之后才解密执行。为了实现这一目标设计上做出三个关键选择加密技术无关scheme agnostic协议不内置任何具体的加密算法而是通过密钥提供方key provider抽象支持任意解密密钥提供方例如阈值加密threshold encryptionMPC 委员会MPC committees可信执行环境TEEs延迟加密delay encryption全同态加密FHE schemes传统明文交易继续支持现有的明文交易不受影响用户可以自由选择加密或非加密路径。链的进展有兜底保证即使所有密钥提供方都失败例如离线、拒绝发布密钥链的推进也不会停滞——加密交易的信封envelope仍会被包含并支付费用只是其负载payload暂时无法执行。整个协议涉及执行层Execution Layer与共识层Consensus Layer两方面的改动下面按规范Specification逐层展开。三、密钥提供方注册表Key Provider Registry3.1 注册机制在执行层部署一个名为**密钥提供方注册表key provider registry**的系统合约任何账户都可以注册一个密钥提供方并获得一个唯一 IDkey_provider_id。注册时需要指定一个合约该合约必须提供两个函数解密函数decryption function密钥验证函数key validation function这两个函数都以**密钥 IDkey ID和密钥消息key message**作为字节串byte string参数。3.2 信任图Trust Graph密钥提供方可以将其他的提供方指定为直接信任directly trusted从而形成一张有向信任图定义密钥提供方 A 信任密钥提供方 B当且仅当在信任图中存在一条从 A 到 B 的有向路径。也就是说信任关系沿有向路径传递。这张信任图是后续区块排序规则见第七节和安全模型见第十节的核心依据。3.3 信标链状态复制信标链beacon chain会在其状态中复制密钥提供方注册表其机制与信标链处理存款deposits的机制类似——执行层发生注册事件后通过存款式的桥接路径将注册信息同步到共识层状态中供共识层在验证区块时使用。需要注意的是EIP 中明确说明密钥提供方注册表合约的源代码目前待定TBD。这意味着本文描述的注册表接口解密函数、验证函数、唯一 ID是协议层面的约定具体合约实现尚待后续补充。四、两种新的交易类型加密信封与解密负载EIP-8105 新增两种 EIP-2718 交易类型。EIP-2718 定义了TransactionType || TransactionPayload的交易信封格式其中TransactionType是 0 到 0x7f 的无符号 8 位整数这让未来交易类型可以互不冲突地共存。本提案使用了类型0x05和0x06。4.1 加密交易Encrypted Transaction类型 0x05加密交易即信封其 RLP 编码形式为0x05 || rlp([chain_id, envelope_nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_amount, key_provider_id, key_id, encrypted_payload, envelope_signature_y_parity, envelope_signature_r, envelope_signature_s])各字段含义如下字段含义chain_id链 ID防止跨链重放envelope_nonce信封签名者envelope signer的 noncemax_priority_fee_per_gas最大优先费小费语义与 EIP-1559 一致max_fee_per_gas最大总费用含 base fee语义与 EIP-1559 一致gas_amount本次加密交易所分配的总 gas 量见第八节执行语义key_provider_id处理本交易的密钥提供方 IDkey_id指定使用该提供方的哪一把密钥encrypted_payload加密后的交易负载即解密交易的密文envelope_signature_y_parity / r / s信封的 secp256k1 签名关键点费用字段全部位于明文的信封中因此构建者和协议可以在不解密的情况下完成计价与扣费而交易的实际内容encrypted_payload在密钥发布前不可见。4.2 解密交易Decrypted Transaction类型 0x06解密交易即负载是加密交易被解密后得到的、真正参与 EVM 执行的那部分交易其形式为0x06 || rlp([envelope_signer, nonce, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])各字段含义如下字段含义envelope_signer对应加密交易信封的签名者地址防剥离攻击的关键见第十节nonce发送方账户 noncedestination接收方地址amount转账金额data调用数据access_list访问列表与 EIP-2930 风格的 access_list 字段一致signature_y_parity / r / s负载自身的签名可以看到解密交易在结构上非常接近常规的 EIP-1559 交易区别在于多了envelope_signer引用字段并且没有费用字段——因为费用已经在对应的加密信封中支付过了见第八节。4.3 与 EIP-1559 的关系加密信封的费用字段max_priority_fee_per_gas、max_fee_per_gas完全沿用 EIP-1559 的语义发送方支付 base fee销毁与优先费归区块提议者/构建者。EIP-8105 没有发明新的计费模型而是把 EIP-1559 的计价规则复用到信封上从而保证协议和构建者的收入确定性。五、密钥提供方的职责发布密钥或扣押通知在每个 slot 中密钥提供方需要执行如下流程观察当构建者发布了执行负载execution payload时密钥提供方收集其中所有以自己key_provider_id为目标的加密交易的信封所引用的key_id。响应对每一个key_id密钥提供方必须发布以下两者之一对应的解密密钥decryption key或一份密钥扣押通知key withhold notice。防重放相应的消息必须引用 beacon block hash以防止该消息在未来的 slot 中被重放。时机密钥提供方既可以在观察到执行负载后立即发布也可以延迟到 slot 中的更晚时间点发布。这一允许延迟、允许扣押的设计是刻意的——它为密钥提供方实现用户准入策略如基于预先付款和抵御密钥 ID 抢跑攻击留出了空间详见第九、十节。六、PTC 的额外职责验证并证明密钥EIP-7732 定义了执行负载时效委员会Payload Timeliness CommitteePTC信标委员会中一个大小为PTC_SIZE 2**9 512的子集负责对构建者是否及时揭示了承诺的执行负载进行证明提交PayloadAttestationMessage。EIP-8105 在此基础上为 PTC 增加了新的职责监听密钥PTC 成员必须监听区块中所有加密交易引用的解密密钥通过key_provider_id与key_id字段识别。验证密钥使用注册表合约中指定的验证函数对密钥进行验证每个密钥使用一个硬编码的小 gas 上限hardcoded small gas limit per key——避免验证过程消耗过多资源。证明结果PTC 必须在payload attestation message中证明每个加密交易是否存在有效密钥。为此EIP-7732 定义的 payload attestation 消息会被扩展一个专用的 bitfield每一位对应一个加密交易标记其密钥存在或缺失。PTC 的证明结果是后续区块判断解密交易能否被包含的关键前提见下一节。七、区块结构与有效性规则7.1 交易排序规则在一个有效区块中交易必须按以下顺序排列解密交易decrypted transactions在最前加密交易encrypted transactions在最后其他任何交易在中间。这种解密在前、加密在后的布局与执行语义第八节配合所有信封先被执行并支付费用之后解密负载才在后续区块中执行。7.2 加密交易之间的信任约束此外如果一笔加密交易 A 的前面有另一笔加密交易 B那么必须满足以下条件之一A 和 B 指定同一个密钥提供方或B 的密钥提供方被 A 的密钥提供方信任即信任图中存在从 A 的提供方到 B 的提供方的有向路径。这条规则的动机将在第九节信任图设计权衡详细解释。7.3 解密交易与加密交易的对应关系每一笔解密交易必须对应上一区块中的一笔加密交易且对应关系必须是保序的order-preserving即第 i 笔解密交易对应上一区块中的第 i 笔加密交易。具体而言解密交易必须是对相应加密交易的encrypted_payload应用key_provider_id所指定的解密函数得到的结果使用的密钥由加密交易的key_id指定并且该密钥必须已经由 PTC 在加密交易被包含的那个 slot 中证明为存在。7.4 解密交易不得被包含的条件EIP 明确规定当且仅当满足以下任一条件时解密交易不得被包含进区块密钥被 PTC 证明为缺失key is attested as missing解密失败decryption fails解密结果不是结构上有效的解密交易not structurally valid解密交易的envelope_signer与对应加密交易的签名者不匹配包含该解密交易会导致区块无效例如 nonce 不匹配。注意第 4 条解密交易中的envelope_signer必须与信封签名者一致这是防止信封剥离攻击envelope stripping的核心防线见第十节。八、交易执行语义8.1 加密交易信封的执行加密交易在包含它的那个区块中执行递增信封签名者账户的 nonce按照 EIP-1559 的方式为gas_amount付费交易消耗gas_amount单位的 gas。8.2 解密交易负载的执行解密交易在解密完成后的区块即加密信封所在区块的下一区块中执行在包含区块inclusion block的执行上下文下作为常规交易执行例如block.slot、block.coinbase都取包含区块的值交易的gas limit为对应加密交易的gas_amount减去加密交易本身的成本以及解密成本然而消耗的 gas 不计入区块 gas limit也不支付任何费用——费用已在信封执行时付清。8.3 为什么这样设计gas 激励一致性Rationale 一节给出了两个关键理由保护协议与构建者加密负载的内容不可预知为避免无法支付 gas的加密交易被包含费用支付放在明文信封中且所有信封在任何加密负载之前执行。同时不支付 gas 退款gas refunds以保证构建者和协议在出块时能确定收到的费用金额。gas 全部在信封所在区块消耗加密交易所在区块消耗全部 gas解密交易执行区块不消耗 gas。这是激励相容的要求——某个区块的构建者不应能够出售下一个区块的区块空间。此外EIP 承认一个简化设计加密负载中包含一个签名即解密交易自带签名。一个隐私性稍差但更高效的替代方案是直接将信封签名者视为发送方省去负载签名。九、设计权衡Rationale9.1 为什么注册采用技术中立 执行层合约技术中立保证了协议的公平中立性最小化新密钥提供方的准入门槛并让用户为自己目的选择最优方案。选择执行层合约作为注册方式是因为它是表达任意执行逻辑的规范途径纯共识层CL注册也是一个合理替代方案。许多加密方案在 EVM 中难以高效表达需要专用的预编译precompiles但添加预编译超出了本 EIP 的范围。9.2 为什么需要信任图这是本提案最精巧的设计之一。逻辑链条如下使用加密交易的用户不仅信任自己的密钥提供方还必须信任区块中更早交易所使用的密钥提供方理由见第十节安全分析。如果协议要求每个用户只能信任自己的提供方那么构建者在每个区块中只能包含来自单一密钥提供方的加密交易——这会让市场份额小的提供方难以竞争有形成密钥提供方垄断的风险。反过来如果要求用户显式声明信任哪些第三方提供方会带来交易大小开销并且让区块构建变得复杂大量相互竞争的用户偏好需要同时满足。折中方案由密钥提供方来做这个信任选择用户通过使用该提供方的密钥来隐式同意其信任关系。9.3 信任图如何缓解垄断即使出现一个占主导地位的准垄断密钥提供方且该提供方不信任任何其他提供方构建者仍然可以在没有机会成本的情况下包含使用其他小型提供方的交易——只要这些小型提供方信任主导提供方以及彼此信任。这样小型提供方就能依附于大型提供方而存活避免市场彻底固化。9.4 为什么允许密钥扣押Key Withholding协议明确允许密钥提供方在自选条件下扣押解密密钥这使其能够安全地实施规则来限制哪些用户可以使用哪些密钥例如基于预先付款抵御密钥 ID 抢跑攻击key ID front running见第十节。另一方面被无理扣押的密钥可以用于自定义的罚没slashing机制和可靠性度量——协议会记录哪些密钥存在、哪些密钥曾经存在。9.5 为什么不在协议内设置密钥提供方激励EIP 明确不内置密钥提供方的费用机制也不对其不当行为设置惩罚。这允许链下实现多样化的激励模型例如密钥提供方与构建者达成协议用户按交易向提供方付费提供方作为公共产品运营提供方自愿接受罚没条件针对无理扣押密钥以提升自身服务的吸引力。9.6 未来方向执行负载加密EIP 设想未来可能出现一个 EIP允许构建者使用密钥提供方的密钥加密执行负载本身。好处是构建者可以在构造完成后立即发布执行负载而不是等到 slot 的 50% 标记目前 ePBS 下的揭示时间点提高 p2p 效率保护构建者免受因崩溃导致的漏块missed slots如果构建者附带关于区块中使用密钥的零知识证明密钥揭示时间窗口可以提前并延长。该功能不包含在本 EIP 中目的是最小化复杂度。十、安全考虑Security Considerations10.1 对密钥提供方的信任用户使用某密钥提供方加密交易必然信任该提供方做到两点不提前发布解密密钥——否则会导致抢跑和三明治攻击不延迟发布解密密钥——否则交易无法执行而信封费用仍然需要支付。提供方可以通过以下机制赢得信任密码学机制阈值加密、硬件加密、经济机制针对不当行为的罚没、治理机制投票选出社会声誉良好的实体或它们的组合。次级信任用户还在较小程度上需要信任其交易之前所有加密交易使用的密钥提供方。原因在于密钥提供方可以在观察到后续交易的解密密钥之后再选择发布或扣押自己的密钥从而获得对后续交易 pre-state 的一个比特one bit的影响权。更糟的是恶意设计的解密方案可以通过构造的密钥直接修改解密结果的特定部分甚至整体设定从而有效实现抢跑。无需信任的情形用户不需要信任其交易之后被包含的交易所用的任何提供方——因为用户交易负载的 pre-state 不受后续交易负载影响只有信封在先而信封在密钥发布之前就已确定明文交易用户不需要信任任何密钥提供方但他们仍然要信任构建者。10.2 重组Reorgs解密密钥在对应加密交易被最终确认finalized之前就已发布。因此如果发生链重组一笔交易可能在未被包含进链的情况下就变成公开的。缓解措施由于解密密钥消息包含区块哈希密钥验证函数可以使其失效。这不能阻止信封交易被包含但能阻止其执行从而防止负载被抢跑。10.3 密钥 ID 抢跑Key ID Front Running攻击场景用户用某个key_id加密交易后攻击者观察到这笔在途交易创建另一笔指定相同key_provider_id和key_id的加密交易。如果攻击者的交易先被包含进更早的区块天真的密钥提供方会提前揭示密钥从而暴露原交易尽管它尚未被包含。防御策略——密钥 ID 命名空间化namespacing提供方只发布那些以信封签名者地址为前缀的密钥 ID 的密钥其余全部扣押。由于可以合理假设攻击者无法访问信封签名者账户攻击者无法构造出命名空间正确的密钥 ID。10.4 密钥提供方与子构建者合谋Key Provider-Child Builder Collusion构建新区块需要知道上一区块的 post-state即区块中所有解密密钥及其扣押情况。这些信息在 PTC 证明后公开但恶意密钥提供方可以与构建者合谋提前通风报信让构建者更早开始建块获得竞争优势。EIP 评估该攻击的影响较低理由如下从 payload attestation 发布到 slot 结束之间仍有足够时间完成建块建块期的开始远不如结束关键只有到结束时才知道全部可包含交易集合而该攻击不影响结束阶段延迟发布密钥有不被 PTC 证明的风险反而抵消攻击者的竞争优势如果使用恶意提供方的加密交易数量很少其对状态树的影响通常也很小因此不依赖完整状态树知识的乐观建块optimistic block building策略可能可行从而化解该攻击。10.5 信封与负载剥离攻击Envelope and Payload Stripping Attacks信封剥离攻击如果某已发布加密交易的密钥被揭示但解密交易未被包含例如密钥揭示过晚攻击者可能尝试解密该交易、放入新的信封并在未来区块中抢跑它。解密交易中的envelope_signer引用对除所选信封签名者以外的所有人阻止了这种攻击——而信封签名者在实践中通常能接触到明文交易本就被信任不会抢跑。该假设可以进一步收紧例如同时包含 chain id、key provider、key id但完整引用信封是不可能的因为会产生循环依赖包含信封 nonce 原则上可取但会复杂化信封签名者与负载签名者的交互。负载剥离攻击拦截加密交易并替换其负载的攻击不可能成功因为加密交易的签名覆盖整个负载envelope signature spans the payload。十一、向后兼容性与当前状态向后兼容性该提案对执行层和共识层协议都引入了不向后兼容backwards incompatible的变更属于 EIP-2718 分类下的 Standards Track / Core 提案需要硬分叉级别的协议升级来落地。当前状态截至本仓库收录的版本该 EIP 状态为Draft草稿创建于 2025-12-17作者为 Jannik Luhnjannikluhn讨论链接见提案头部的discussions-to字段。密钥提供方注册表合约的源代码仍标注为 TBD这意味着注册表接口细节、硬编码 gas 上限的具体数值、bitfield 扩展的精确编码等实现参数将在后续版本中补充。十二、与仓库内其他相关提案的关联在本仓库中可以找到与该提案直接相关的若干姊妹提案可作为延伸阅读EIPS/eip-2718.mdTyped Transaction Envelope本提案两种新交易类型0x05、0x06的格式基础EIPS/eip-7732.mdEnshrined Proposer-Builder Separation定义了 PTC、payload attestation 与构建者体系本提案对其扩展EIPS/eip-1559.md费用市场机制信封的费用字段语义来源EIPS/eip-8184.mdLUCID 加密内存池一个并行的加密内存池提案在其备选规范中明确参考了本提案的信任图设计例如允许用户将信任选择委托给其选定的密钥发布方以降低单一主导密钥发布方带来的压力EIPS/eip-7793.mdConditional Transactions通过仅在指定 slot 与索引执行的交易格式从排序约束角度支持加密内存池的落地。综上所述EIP-8105 提供了一个加密技术无关、与 ePBS 深度集成、兼顾信任自由与市场健康的协议级加密内存池蓝图。其核心价值在于把防止抢跑/三明治、增强弱审查阻力从依赖第三方中介的链下方案提升为协议原生能力同时通过信任图与密钥扣押机制的设计在安全性、去中心化与实现复杂度之间取得了审慎的平衡。版权说明本文内容基于 LICENSE.md 声明的 CC0 协议条款整理原文版权归 EIP 作者所有。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-8105 通用内嵌加密交易内存池（Universal Enshrined Encrypted Mempool）协议全解析
EIP-8105 通用内嵌加密交易内存池Universal Enshrined Encrypted Mempool协议全解析【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕以太坊核心层提案EIP-8105Universal Enshrined Encrypted Mempool通用内嵌加密交易内存池展开系统讲解其将加密交易内存池内嵌进协议层的设计动机、密钥提供方注册表与信任图、两种新增 EIP-2718 交易类型、密钥发布与 PTC 验证流程、区块排序与有效性规则以及执行语义与安全模型。读完本文你将能完整理解该提案如何在不依赖单一加密方案的前提下抵御抢跑front running与三明治攻击、增强弱审查阻力并掌握其与 EIP-7732ePBS、EIP-1559 的衔接方式。一、提案背景与动机1.1 要解决的三类问题EIP-8105 的目标非常聚焦在 Motivation 一节中明确列出防止恶意的交易重排序攻击用户在公开内存池提交的交易可被观察攻击者可据此实施抢跑front running与三明治sandwiching攻击。增强协议的实时弱审查阻力交易内容对包括区块构建者在内的中间方暂时不可见攻击者难以精准筛选并审查特定交易。降低区块构建者等协议参与者的监管风险通过临时蒙蔽blinding构建者使其无法看到交易内容从而减少其面临的选择性审查压力。需要特别强调该提案的目标不是提升用户隐私。所有交易最终都会在链上公开揭示它保护的是包含进区块之前这一时间窗口内的交易内容而不是交易的长期机密性。1.2 与既有工作与路线图的关系该提案建立在两个重要先例之上Shutterized Beacon ChainShutter 化的信标链将阈值加密与信标链结合的研究工作。Gnosis Chain 上已上线运行的协议外out-of-protocol加密内存池实现一个经过真实环境检验的加密内存池方案。此外提案明确指出该设计与**内嵌的提议者-构建者分离enshrined proposer-builder separationePBS**天然契合是 EIP-7732 所描述的以太坊路线图的逻辑延伸——这也解释了为什么提案要求依赖requiresEIP-7732。二、总体设计技术中立的加密内存池提案的核心思路可以概括为一句话让用户以加密形式提交交易直到交易被包含进区块之后才解密执行。为了实现这一目标设计上做出三个关键选择加密技术无关scheme agnostic协议不内置任何具体的加密算法而是通过密钥提供方key provider抽象支持任意解密密钥提供方例如阈值加密threshold encryptionMPC 委员会MPC committees可信执行环境TEEs延迟加密delay encryption全同态加密FHE schemes传统明文交易继续支持现有的明文交易不受影响用户可以自由选择加密或非加密路径。链的进展有兜底保证即使所有密钥提供方都失败例如离线、拒绝发布密钥链的推进也不会停滞——加密交易的信封envelope仍会被包含并支付费用只是其负载payload暂时无法执行。整个协议涉及执行层Execution Layer与共识层Consensus Layer两方面的改动下面按规范Specification逐层展开。三、密钥提供方注册表Key Provider Registry3.1 注册机制在执行层部署一个名为**密钥提供方注册表key provider registry**的系统合约任何账户都可以注册一个密钥提供方并获得一个唯一 IDkey_provider_id。注册时需要指定一个合约该合约必须提供两个函数解密函数decryption function密钥验证函数key validation function这两个函数都以**密钥 IDkey ID和密钥消息key message**作为字节串byte string参数。3.2 信任图Trust Graph密钥提供方可以将其他的提供方指定为直接信任directly trusted从而形成一张有向信任图定义密钥提供方 A 信任密钥提供方 B当且仅当在信任图中存在一条从 A 到 B 的有向路径。也就是说信任关系沿有向路径传递。这张信任图是后续区块排序规则见第七节和安全模型见第十节的核心依据。3.3 信标链状态复制信标链beacon chain会在其状态中复制密钥提供方注册表其机制与信标链处理存款deposits的机制类似——执行层发生注册事件后通过存款式的桥接路径将注册信息同步到共识层状态中供共识层在验证区块时使用。需要注意的是EIP 中明确说明密钥提供方注册表合约的源代码目前待定TBD。这意味着本文描述的注册表接口解密函数、验证函数、唯一 ID是协议层面的约定具体合约实现尚待后续补充。四、两种新的交易类型加密信封与解密负载EIP-8105 新增两种 EIP-2718 交易类型。EIP-2718 定义了TransactionType || TransactionPayload的交易信封格式其中TransactionType是 0 到 0x7f 的无符号 8 位整数这让未来交易类型可以互不冲突地共存。本提案使用了类型0x05和0x06。4.1 加密交易Encrypted Transaction类型 0x05加密交易即信封其 RLP 编码形式为0x05 || rlp([chain_id, envelope_nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_amount, key_provider_id, key_id, encrypted_payload, envelope_signature_y_parity, envelope_signature_r, envelope_signature_s])各字段含义如下字段含义chain_id链 ID防止跨链重放envelope_nonce信封签名者envelope signer的 noncemax_priority_fee_per_gas最大优先费小费语义与 EIP-1559 一致max_fee_per_gas最大总费用含 base fee语义与 EIP-1559 一致gas_amount本次加密交易所分配的总 gas 量见第八节执行语义key_provider_id处理本交易的密钥提供方 IDkey_id指定使用该提供方的哪一把密钥encrypted_payload加密后的交易负载即解密交易的密文envelope_signature_y_parity / r / s信封的 secp256k1 签名关键点费用字段全部位于明文的信封中因此构建者和协议可以在不解密的情况下完成计价与扣费而交易的实际内容encrypted_payload在密钥发布前不可见。4.2 解密交易Decrypted Transaction类型 0x06解密交易即负载是加密交易被解密后得到的、真正参与 EVM 执行的那部分交易其形式为0x06 || rlp([envelope_signer, nonce, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])各字段含义如下字段含义envelope_signer对应加密交易信封的签名者地址防剥离攻击的关键见第十节nonce发送方账户 noncedestination接收方地址amount转账金额data调用数据access_list访问列表与 EIP-2930 风格的 access_list 字段一致signature_y_parity / r / s负载自身的签名可以看到解密交易在结构上非常接近常规的 EIP-1559 交易区别在于多了envelope_signer引用字段并且没有费用字段——因为费用已经在对应的加密信封中支付过了见第八节。4.3 与 EIP-1559 的关系加密信封的费用字段max_priority_fee_per_gas、max_fee_per_gas完全沿用 EIP-1559 的语义发送方支付 base fee销毁与优先费归区块提议者/构建者。EIP-8105 没有发明新的计费模型而是把 EIP-1559 的计价规则复用到信封上从而保证协议和构建者的收入确定性。五、密钥提供方的职责发布密钥或扣押通知在每个 slot 中密钥提供方需要执行如下流程观察当构建者发布了执行负载execution payload时密钥提供方收集其中所有以自己key_provider_id为目标的加密交易的信封所引用的key_id。响应对每一个key_id密钥提供方必须发布以下两者之一对应的解密密钥decryption key或一份密钥扣押通知key withhold notice。防重放相应的消息必须引用 beacon block hash以防止该消息在未来的 slot 中被重放。时机密钥提供方既可以在观察到执行负载后立即发布也可以延迟到 slot 中的更晚时间点发布。这一允许延迟、允许扣押的设计是刻意的——它为密钥提供方实现用户准入策略如基于预先付款和抵御密钥 ID 抢跑攻击留出了空间详见第九、十节。六、PTC 的额外职责验证并证明密钥EIP-7732 定义了执行负载时效委员会Payload Timeliness CommitteePTC信标委员会中一个大小为PTC_SIZE 2**9 512的子集负责对构建者是否及时揭示了承诺的执行负载进行证明提交PayloadAttestationMessage。EIP-8105 在此基础上为 PTC 增加了新的职责监听密钥PTC 成员必须监听区块中所有加密交易引用的解密密钥通过key_provider_id与key_id字段识别。验证密钥使用注册表合约中指定的验证函数对密钥进行验证每个密钥使用一个硬编码的小 gas 上限hardcoded small gas limit per key——避免验证过程消耗过多资源。证明结果PTC 必须在payload attestation message中证明每个加密交易是否存在有效密钥。为此EIP-7732 定义的 payload attestation 消息会被扩展一个专用的 bitfield每一位对应一个加密交易标记其密钥存在或缺失。PTC 的证明结果是后续区块判断解密交易能否被包含的关键前提见下一节。七、区块结构与有效性规则7.1 交易排序规则在一个有效区块中交易必须按以下顺序排列解密交易decrypted transactions在最前加密交易encrypted transactions在最后其他任何交易在中间。这种解密在前、加密在后的布局与执行语义第八节配合所有信封先被执行并支付费用之后解密负载才在后续区块中执行。7.2 加密交易之间的信任约束此外如果一笔加密交易 A 的前面有另一笔加密交易 B那么必须满足以下条件之一A 和 B 指定同一个密钥提供方或B 的密钥提供方被 A 的密钥提供方信任即信任图中存在从 A 的提供方到 B 的提供方的有向路径。这条规则的动机将在第九节信任图设计权衡详细解释。7.3 解密交易与加密交易的对应关系每一笔解密交易必须对应上一区块中的一笔加密交易且对应关系必须是保序的order-preserving即第 i 笔解密交易对应上一区块中的第 i 笔加密交易。具体而言解密交易必须是对相应加密交易的encrypted_payload应用key_provider_id所指定的解密函数得到的结果使用的密钥由加密交易的key_id指定并且该密钥必须已经由 PTC 在加密交易被包含的那个 slot 中证明为存在。7.4 解密交易不得被包含的条件EIP 明确规定当且仅当满足以下任一条件时解密交易不得被包含进区块密钥被 PTC 证明为缺失key is attested as missing解密失败decryption fails解密结果不是结构上有效的解密交易not structurally valid解密交易的envelope_signer与对应加密交易的签名者不匹配包含该解密交易会导致区块无效例如 nonce 不匹配。注意第 4 条解密交易中的envelope_signer必须与信封签名者一致这是防止信封剥离攻击envelope stripping的核心防线见第十节。八、交易执行语义8.1 加密交易信封的执行加密交易在包含它的那个区块中执行递增信封签名者账户的 nonce按照 EIP-1559 的方式为gas_amount付费交易消耗gas_amount单位的 gas。8.2 解密交易负载的执行解密交易在解密完成后的区块即加密信封所在区块的下一区块中执行在包含区块inclusion block的执行上下文下作为常规交易执行例如block.slot、block.coinbase都取包含区块的值交易的gas limit为对应加密交易的gas_amount减去加密交易本身的成本以及解密成本然而消耗的 gas 不计入区块 gas limit也不支付任何费用——费用已在信封执行时付清。8.3 为什么这样设计gas 激励一致性Rationale 一节给出了两个关键理由保护协议与构建者加密负载的内容不可预知为避免无法支付 gas的加密交易被包含费用支付放在明文信封中且所有信封在任何加密负载之前执行。同时不支付 gas 退款gas refunds以保证构建者和协议在出块时能确定收到的费用金额。gas 全部在信封所在区块消耗加密交易所在区块消耗全部 gas解密交易执行区块不消耗 gas。这是激励相容的要求——某个区块的构建者不应能够出售下一个区块的区块空间。此外EIP 承认一个简化设计加密负载中包含一个签名即解密交易自带签名。一个隐私性稍差但更高效的替代方案是直接将信封签名者视为发送方省去负载签名。九、设计权衡Rationale9.1 为什么注册采用技术中立 执行层合约技术中立保证了协议的公平中立性最小化新密钥提供方的准入门槛并让用户为自己目的选择最优方案。选择执行层合约作为注册方式是因为它是表达任意执行逻辑的规范途径纯共识层CL注册也是一个合理替代方案。许多加密方案在 EVM 中难以高效表达需要专用的预编译precompiles但添加预编译超出了本 EIP 的范围。9.2 为什么需要信任图这是本提案最精巧的设计之一。逻辑链条如下使用加密交易的用户不仅信任自己的密钥提供方还必须信任区块中更早交易所使用的密钥提供方理由见第十节安全分析。如果协议要求每个用户只能信任自己的提供方那么构建者在每个区块中只能包含来自单一密钥提供方的加密交易——这会让市场份额小的提供方难以竞争有形成密钥提供方垄断的风险。反过来如果要求用户显式声明信任哪些第三方提供方会带来交易大小开销并且让区块构建变得复杂大量相互竞争的用户偏好需要同时满足。折中方案由密钥提供方来做这个信任选择用户通过使用该提供方的密钥来隐式同意其信任关系。9.3 信任图如何缓解垄断即使出现一个占主导地位的准垄断密钥提供方且该提供方不信任任何其他提供方构建者仍然可以在没有机会成本的情况下包含使用其他小型提供方的交易——只要这些小型提供方信任主导提供方以及彼此信任。这样小型提供方就能依附于大型提供方而存活避免市场彻底固化。9.4 为什么允许密钥扣押Key Withholding协议明确允许密钥提供方在自选条件下扣押解密密钥这使其能够安全地实施规则来限制哪些用户可以使用哪些密钥例如基于预先付款抵御密钥 ID 抢跑攻击key ID front running见第十节。另一方面被无理扣押的密钥可以用于自定义的罚没slashing机制和可靠性度量——协议会记录哪些密钥存在、哪些密钥曾经存在。9.5 为什么不在协议内设置密钥提供方激励EIP 明确不内置密钥提供方的费用机制也不对其不当行为设置惩罚。这允许链下实现多样化的激励模型例如密钥提供方与构建者达成协议用户按交易向提供方付费提供方作为公共产品运营提供方自愿接受罚没条件针对无理扣押密钥以提升自身服务的吸引力。9.6 未来方向执行负载加密EIP 设想未来可能出现一个 EIP允许构建者使用密钥提供方的密钥加密执行负载本身。好处是构建者可以在构造完成后立即发布执行负载而不是等到 slot 的 50% 标记目前 ePBS 下的揭示时间点提高 p2p 效率保护构建者免受因崩溃导致的漏块missed slots如果构建者附带关于区块中使用密钥的零知识证明密钥揭示时间窗口可以提前并延长。该功能不包含在本 EIP 中目的是最小化复杂度。十、安全考虑Security Considerations10.1 对密钥提供方的信任用户使用某密钥提供方加密交易必然信任该提供方做到两点不提前发布解密密钥——否则会导致抢跑和三明治攻击不延迟发布解密密钥——否则交易无法执行而信封费用仍然需要支付。提供方可以通过以下机制赢得信任密码学机制阈值加密、硬件加密、经济机制针对不当行为的罚没、治理机制投票选出社会声誉良好的实体或它们的组合。次级信任用户还在较小程度上需要信任其交易之前所有加密交易使用的密钥提供方。原因在于密钥提供方可以在观察到后续交易的解密密钥之后再选择发布或扣押自己的密钥从而获得对后续交易 pre-state 的一个比特one bit的影响权。更糟的是恶意设计的解密方案可以通过构造的密钥直接修改解密结果的特定部分甚至整体设定从而有效实现抢跑。无需信任的情形用户不需要信任其交易之后被包含的交易所用的任何提供方——因为用户交易负载的 pre-state 不受后续交易负载影响只有信封在先而信封在密钥发布之前就已确定明文交易用户不需要信任任何密钥提供方但他们仍然要信任构建者。10.2 重组Reorgs解密密钥在对应加密交易被最终确认finalized之前就已发布。因此如果发生链重组一笔交易可能在未被包含进链的情况下就变成公开的。缓解措施由于解密密钥消息包含区块哈希密钥验证函数可以使其失效。这不能阻止信封交易被包含但能阻止其执行从而防止负载被抢跑。10.3 密钥 ID 抢跑Key ID Front Running攻击场景用户用某个key_id加密交易后攻击者观察到这笔在途交易创建另一笔指定相同key_provider_id和key_id的加密交易。如果攻击者的交易先被包含进更早的区块天真的密钥提供方会提前揭示密钥从而暴露原交易尽管它尚未被包含。防御策略——密钥 ID 命名空间化namespacing提供方只发布那些以信封签名者地址为前缀的密钥 ID 的密钥其余全部扣押。由于可以合理假设攻击者无法访问信封签名者账户攻击者无法构造出命名空间正确的密钥 ID。10.4 密钥提供方与子构建者合谋Key Provider-Child Builder Collusion构建新区块需要知道上一区块的 post-state即区块中所有解密密钥及其扣押情况。这些信息在 PTC 证明后公开但恶意密钥提供方可以与构建者合谋提前通风报信让构建者更早开始建块获得竞争优势。EIP 评估该攻击的影响较低理由如下从 payload attestation 发布到 slot 结束之间仍有足够时间完成建块建块期的开始远不如结束关键只有到结束时才知道全部可包含交易集合而该攻击不影响结束阶段延迟发布密钥有不被 PTC 证明的风险反而抵消攻击者的竞争优势如果使用恶意提供方的加密交易数量很少其对状态树的影响通常也很小因此不依赖完整状态树知识的乐观建块optimistic block building策略可能可行从而化解该攻击。10.5 信封与负载剥离攻击Envelope and Payload Stripping Attacks信封剥离攻击如果某已发布加密交易的密钥被揭示但解密交易未被包含例如密钥揭示过晚攻击者可能尝试解密该交易、放入新的信封并在未来区块中抢跑它。解密交易中的envelope_signer引用对除所选信封签名者以外的所有人阻止了这种攻击——而信封签名者在实践中通常能接触到明文交易本就被信任不会抢跑。该假设可以进一步收紧例如同时包含 chain id、key provider、key id但完整引用信封是不可能的因为会产生循环依赖包含信封 nonce 原则上可取但会复杂化信封签名者与负载签名者的交互。负载剥离攻击拦截加密交易并替换其负载的攻击不可能成功因为加密交易的签名覆盖整个负载envelope signature spans the payload。十一、向后兼容性与当前状态向后兼容性该提案对执行层和共识层协议都引入了不向后兼容backwards incompatible的变更属于 EIP-2718 分类下的 Standards Track / Core 提案需要硬分叉级别的协议升级来落地。当前状态截至本仓库收录的版本该 EIP 状态为Draft草稿创建于 2025-12-17作者为 Jannik Luhnjannikluhn讨论链接见提案头部的discussions-to字段。密钥提供方注册表合约的源代码仍标注为 TBD这意味着注册表接口细节、硬编码 gas 上限的具体数值、bitfield 扩展的精确编码等实现参数将在后续版本中补充。十二、与仓库内其他相关提案的关联在本仓库中可以找到与该提案直接相关的若干姊妹提案可作为延伸阅读EIPS/eip-2718.mdTyped Transaction Envelope本提案两种新交易类型0x05、0x06的格式基础EIPS/eip-7732.mdEnshrined Proposer-Builder Separation定义了 PTC、payload attestation 与构建者体系本提案对其扩展EIPS/eip-1559.md费用市场机制信封的费用字段语义来源EIPS/eip-8184.mdLUCID 加密内存池一个并行的加密内存池提案在其备选规范中明确参考了本提案的信任图设计例如允许用户将信任选择委托给其选定的密钥发布方以降低单一主导密钥发布方带来的压力EIPS/eip-7793.mdConditional Transactions通过仅在指定 slot 与索引执行的交易格式从排序约束角度支持加密内存池的落地。综上所述EIP-8105 提供了一个加密技术无关、与 ePBS 深度集成、兼顾信任自由与市场健康的协议级加密内存池蓝图。其核心价值在于把防止抢跑/三明治、增强弱审查阻力从依赖第三方中介的链下方案提升为协议原生能力同时通过信任图与密钥扣押机制的设计在安全性、去中心化与实现复杂度之间取得了审慎的平衡。版权说明本文内容基于 LICENSE.md 声明的 CC0 协议条款整理原文版权归 EIP 作者所有。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考