EIP-8254 深度解读为执行层区块设置存款请求硬上限MAX_DEPOSIT_REQUESTS_PER_BLOCK 8192【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文全面解读以太坊改进提案 EIP-8254Cap Deposit Requests Per Block仓库文档位于 EIPS/eip-8254.md它以 EIP-6110 的链上存款机制为背景为每个执行层区块的存款请求数量引入8192的硬性上限作为新的共识层规则在出块与验块两个阶段强制执行。读完本文你将理解为什么 EIP-6110 在 gas 上限升高后会演变成活性liveness隐患、8192这个数值的来龙去脉、执行层各客户端在构造与验证区块时必须遵守的约束以及该上限对弱主观性、乐观同步与出块者打包问题带来的安全影响。背景EIP-6110 之后存款请求如何进入区块要理解 EIP-8254 解决的问题必须先回到它的前置依赖 EIP-6110Supply validator deposits on chain状态为 Final。在 EIP-6110 之前共识层通过eth1data投票机制获取存款信息延迟可达约 12 小时EIP-6110 将存款的包含与验证责任转移到执行层使存款从提交到上链的延迟缩短到约 13 分钟并彻底移除了共识层对 JSON-RPC 数据轮询以及存款合约快照EIP-4881的依赖。具体机制是执行层区块中的存款请求列表来自该区块内所有交易收据receipts中由存款合约发出的DepositEvent日志。执行层客户端在收据构造阶段解析日志将每个存款事件编码为固定长度的 192 字节请求数据字段依次为pubkey: Bytes48、withdrawal_credentials: Bytes32、amount: uint64、signature: Bytes96、index: uint64合计48 32 8 96 8 192字节再通过 EIP-7685 定义的通用请求总线request_type字节 request_data暴露给共识层。EIP-6110 规范中给出了两个客户端必须内置的关键配置参数| 参数 | 值 | | - | - | |DEPOSIT_CONTRACT_ADDRESS|0x00000000219ab540356cbb839cbe05303d7705fa主网 | |DEPOSIT_EVENT_SIGNATURE_HASH|0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5|这两个参数必须包含在客户端软件的二进制发行版中。收据解析逻辑对应 EIP-6110 中的get_deposit_request_data会遍历每个收据的日志仅当log.address DEPOSIT_CONTRACT_ADDRESS且日志首条 topic 等于DEPOSIT_EVENT_SIGNATURE_HASH时才收集该日志例如 Sepolia 存款合约会额外发出Transfer事件必须依靠这一双重过滤将其排除。问题为什么需要一个执行层上限EIP-6110 在设计时明确选择不限制存款操作列表的大小Rationale 章节理由是数据复杂度可忽略且缺乏可行的 DoS 向量。但 EIP-8254 指出这只在当时的 gas 上限下成立它是一个随着 gas 上限上升而潜伏的活性故障在约 193–200M 的 gas 上限下使用批量存款合约每笔 10M-gas 交易约可容纳 410 笔存款约 200M gas 的区块即可塞入约 8200 笔存款。此时执行层乐意产出包含超过 8192 笔存款请求的 payload——因为执行层一侧没有任何规则禁止它这样做。但共识层无法解码这样的 payload。文档记录了一个在 Lighthouse 上观察到的代表性故障Failed to convert json to execution requests: DecodeError(Failed to decode DepositRequest from EL: BytesInvalid(\VariableList of 12300 items exceeds maximum of 8192\))验证者在向 beacon 节点请求区块时收到400 Bad Request提案proposal失败。由于该 SSZ 上限对所有共识层客户端一致生效这个故障并非某个客户端特有在同一执行层头head上的后续区块提案会持续失败直到存款积压排空从而打破网络活性。文档还论证了依赖区块构建者不要填满区块是不可靠的攻击者只要愿意花费 gas就能通过公共 mempool 洪泛存款交易同时触发构建者的熔断机制circuit-breaker迫使网络回退到本地出块——而本地出块路径目前完全不了解任何上限的存在。因此上限必须是执行层强制执行的共识规则——执行层是唯一能在存款被序列化进 engine API 响应之前观察到存款的层级。规范细节上限如何定义与执行EIP-8254 的关键词遵循 RFC 2119 与 RFC 8174 的规范语义MUST / MUST NOT / SHOULD / MAY 等。其核心规范可分为五部分。常量| 名称 | 值 | 说明 | | - | - | - | |MAX_DEPOSIT_REQUESTS_PER_BLOCK|8192| 单个执行层区块允许包含的存款请求最大数量 |定义FORK_BLOCK本 EIP 激活后区块链上的第一个区块。区块的 deposit-request 数量deposit-request count区块内所有收据中由DEPOSIT_CONTRACT_ADDRESS发出且匹配DEPOSIT_EVENT_SIGNATURE_HASH的DepositEvent日志条目总数等价于按 EIP-6110 编码len(get_deposit_request_data(block.receipts)) // 192每个条目 192 字节。区块有效性自FORK_BLOCK起在 EIP-6110 原有规则之外区块的存款请求数量超过MAX_DEPOSIT_REQUESTS_PER_BLOCK即视为无效assert deposit_request_count(block) MAX_DEPOSIT_REQUESTS_PER_BLOCK该检查必须在执行层区块验证时应用。超限区块必须与其他共识规则违规同等严重程度地被拒绝基于它构建的后代区块同样无效。区块构造执行层客户端在构造 payload 时无论是用于engine_getPayload、本地驱动的挖矿/验证还是任何其他路径必须跟踪正在组装区块的累计存款请求数量不得包含任何其执行会导致该数量超过MAX_DEPOSIT_REQUESTS_PER_BLOCK的交易。会把数量推过上限的交易必须从区块中省略不影响存款请求数量的后续交易仍可按常规出块规则包含。被排除的含存款交易仍然有资格进入后续区块。这一要求适用于所有出块代码路径包括外部构建者不可用时的回退路径。客户端不得将上限的强制执行委托给构建者。Engine APIengine_getPayloadV*与engine_newPayloadV*继承上述有效性规则执行层客户端不得从engine_getPayload返回违反上限的 payload若engine_newPayload收到的 payload 违反上限则必须将其报告为INVALID。共识层共识层无需任何改动。SSZ 界限MAX_DEPOSIT_REQUESTS_PER_PAYLOAD 8192体现在 beacon block body 的execution_requests.deposits字段继续生效本 EIP 引入的执行层上限与其完全一致从而保证执行层永远不会产出共识层无法解码的存款列表。设计权衡为什么这样定为什么在执行层修复而不是提高 SSZ 界限提高共识层MAX_DEPOSIT_REQUESTS_PER_PAYLOAD曾被考虑作为备选方案但未被采纳理由有三共识层的处理成本主要由存款签名验证主导每笔存款约一次 BLS 验证我们要限制的是每区块的最坏处理时间。提高 SSZ 上限只是把边界往上移并没有封顶——未来每次 gas 上限提升都会重新引发同一问题。共识层的 SSZ 界限本质是序列化层面的关切而存款列表的大小从根本上讲是执行层执行结果的属性。把上限放在产生列表的那一层才是自然的归属。执行层侧的上限还顺带关闭了执行层静默产出不可解码 payload的缺陷——即使共识层界限被提高这个执行层意识不到限制存在的底层 bug 依然存在。为什么是 81928192 2^13恰好等于现有共识层 SSZ 列表界限MAX_DEPOSIT_REQUESTS_PER_PAYLOAD。将执行层上限设为与共识层界限相同直接关闭动机一节描述的故障模式最多 8192 笔存款请求的区块总是可被 SSZ 解码而 8193 及以上才是第一个破坏共识层解码的数量两层只需维护同一个数值而不是引入第二个需要同步的常量保留了 EIP-6110 中已有的最坏情况分析其将 8192 笔存款视为乐观同步的上界因此无需重新做安全分析。8192远高于当前主网 gas 上限下任何实际可达的单区块存款量200M-gas 区块用批量合约可装约 8200 笔30M-gas 区块则要少大约两个数量级。更低的数值如8191曾被考虑但被否决它会在 SSZ 界限之下留出无任何功能意义的一个元素空隙同时引入第二个需要开发者保持同步的常量。为什么用固定存款数量而不是预留 gas以存款数量计量的上限与未来存款合约 gas 成本的变化无关跨分叉推理更简单并且与共识层处理成本扩展的单位一致每笔存款一次签名验证。为什么构造阶段必须强制执行活性是这一要求的根本动机。如果只有区块验证执行上限攻击者可以提交足够多的含存款交易把数量推过 8192任何不了解上限的诚实构建者都会产出无效 payload导致提案者错过自己的 slot。在构造阶段强制执行可以保证任何诚实的提案者都能在任意 mempool 状态下产出合法区块。参考实现EIP-8254 给出了 Python 参考实现分为验证与构造两个入口MAX_DEPOSIT_REQUESTS_PER_BLOCK 8192 # Validation: applied alongside other EIP-6110 deposit-request checks. def validate_deposit_requests_count(block) - None: deposit_requests get_deposit_request_data(block.receipts) # from EIP-6110 count len(deposit_requests) // 192 # each entry is 48328968 192 bytes assert count MAX_DEPOSIT_REQUESTS_PER_BLOCK, too many deposit requests # Construction: invoked when deciding whether to include a candidate transaction. def can_include_transaction(running_count: int, tx_deposit_request_count: int) - bool: return running_count tx_deposit_request_count MAX_DEPOSIT_REQUESTS_PER_BLOCK其中tx_deposit_request_count是候选交易在针对当前区块状态执行后会发出的DepositEvent日志数量客户端在区块组装期间已经在跟踪收据可以在常规收据构造的同时推导出该数量。值得对照的是EIP-6110 的安全分析指出存款合约代码在最便宜情况下运行需要 15,650 gas所有存储槽均为热槽且只需修改单个叶子批量存款中部分存款更贵但摊薄到大量存款后每笔约 1,000 gas当前 gas 定价规则下转账 ETH 的CALL还要额外收取 6,900 gas。为保持未来健壮性beacon 链需要能承受 30M-gas 区块中 1,916 笔存款而现行规则下 30M-gas 区块的上限不足 1,271 笔——这正是当前 gas 上限下达不到 8192这一结论的量化来源。测试用例EIP 激活后以下测试描述了预期的有效性结果收据恰好产生8192笔存款请求的区块有效在满足其他所有规则的前提下。收据产生8193笔存款请求的区块无效这是共识层 SSZ 解码首次失败的数量。收据产生12300笔存款请求的区块无效该值即动机一节所述实际观察到的故障值。在 gas 上限较高、mempool 中存在超过 8192 笔等优先级费用的含存款交易时构造出的区块最多包含8192笔存款请求。含0笔存款请求的区块有效。收据产生的存款请求数量在闭区间[0, 8192]内的区块有效在满足其他所有规则的前提下。针对用例 2–4 的一个参考对抗场景是 spamoor 的deposit-contract-batch配置在约 193M gas 下它能通过批量合约稳定地在单区块内产生超过 8192 笔存款。向后兼容性本 EIP 引入了一条新的区块有效性规则因此属于硬分叉激活需要各客户端协调升级。在当前 gas 上限下该上限不可达按 EIP-6110 的分析30M-gas 区块约可容纳 1,271 笔存款即使是 200M-gas 区块也只有对抗性构造的批量交易才能触达上限。因此本 EIP 不会改变任何历史区块只在攻击场景或显著高于主网当前水平的 gas 上限下才具有约束力。对存款数据的应用层消费方没有影响上限低于或等于它们本就预期的现有 SSZ 列表界限。安全考量活性——首要动机没有本 EIP 时攻击者可以在 gas 上限允许单区块超过 8192 笔存款的网络约 193M gas 时已实测可达上通过洪泛含存款交易来破坏活性。共识层无法解码这类 payloadVariableList of N items exceeds maximum of 8192使用受影响区块的提案者会错过 slot。在执行层强制执行上限——包括构造阶段——关闭了这一攻击使活性不再依赖未来 gas 上限的变化。乐观同步EIP-6110 将乐观同步视为存款相关最严重的 DoS 面同步中的节点可能需要在不对派生过程做验证的情况下对每个区块应用多达MAX_DEPOSIT_REQUESTS_PER_PAYLOAD笔存款。本 EIP 不改变这一最坏情况界限上限与 EIP-6110 已考虑的 SSZ 天花板一致但将其从由 SSZ 派生变为由执行层强制执行的规则使该界限对未来的 gas 上限变化不敏感并在产生存款列表的那一层强制执行。EIP-6110 的估算数据可作为量级参考8192 笔存款约 1.5MB 数据、约 8 秒处理时间而攻击者还需要对该区块做出加密经济上可行的签名。对构建者的依赖依赖外部区块构建者不要填满区块是不安全的攻击者可以同时洪泛存款交易并触发熔断机制迫使回退到本地出块。在构造阶段强制执行层侧强制确保任何诚实验证者在构建者可用性不定的情况下都能产出合法区块。合法存款尖峰下的活性上限远高于任何历史观察到的存款量EIP-6110 引用的最大单日存款量是 24 小时内约 12,000 笔平均每区块约 2 笔。单区块 8192 的上限为合法活动保留了多个数量级的余量。超出的含存款交易只需进入后续区块已被存款合约接受的存款不会丢失。出块打包复杂度背包问题没有上限时区块构造是一维打包问题在sum(gas) ≤ gas_limit约束下最大化费用收入按每 gas 费用做简单贪心即接近最优。加上上限后构造变为二维打包问题在sum(gas) ≤ gas_limit与sum(deposit_request_count) ≤ MAX_DEPOSIT_REQUESTS_PER_BLOCK双重约束下最大化费用收入。这是二维背包问题一般情况下是 NP-hard 的。预期构建者会采用启发式策略例如预留存款槽预算、预算耗尽后丢弃含存款交易这些策略并非最优且可被利用。文档给出一个具体的 griefing骚扰性攻击场景攻击者提交按每 gas 费用看很有吸引力、但每笔都会产生大量存款的交易。天真的贪心构建者会在这些交易上过早耗尽存款槽预算从而无法在同一区块中包含之后更有利可图的含存款交易。攻击成本的下界由存款合约的每笔存款成本决定——以最低 1 ETH 存款计算完全饱和上限至少需要8192 × 1 ETH ≈ 8192 ETH这正是威慑所在。这一复杂度被视为换取活性保证的既定权衡避免第二重约束的替代方案提高或移除共识层 SSZ 界限、对存款定价使其永不触顶等都已在 Rationale 中讨论并被否决。数据大小达到上限的区块包含 8192 笔各 192 字节的存款请求即约 1.5MB 的存款列表数据。这落在 EIP-6110 已有分析范围内——该分析已将 8192 笔存款视为乐观同步的上界。弱主观性上限通过将每纪元最大 top-up 数量限制为MAX_DEPOSIT_REQUESTS_PER_BLOCK * SLOTS_PER_EPOCH与 EIP-6110 中的弱主观性周期分析交互。由于该值与先前分析的 SSZ 派生界限一致相关结论无需改变即可继续适用。仓库中的 弱主观性分析 与 计算脚本 展示了 deposit-per-slot 数量从 16 提升到 1024 时弱主观性周期的变化情况——EIP-6110 已将每纪元存款上限从MAX_DEPOSITS * SLOTS_PER_EPOCH 512提升到约 32,768而本 EIP 正是通过把单区块数量封顶将这一分析锚定在可预期的边界内。如何在仓库中继续深入阅读依赖链上游EIP-6110 定义了存款请求的来源与 192 字节编码、DEPOSIT_CONTRACT_ADDRESS与DEPOSIT_EVENT_SIGNATURE_HASH配置以及乐观同步与弱主观性分析EIP-7685 定义了request_typerequest_data的通用请求总线与requests_hash头部承诺。查看 EIP-6110 附带的 弱主观性分析文档 与 eth2_ws_calc.py 计算脚本理解每纪元 top-up 数量这一输入如何影响弱主观性周期。查看 pubkey 索引缓存分析理解 EIP-6110 引入的验证者索引依赖分叉特性及其对共识层客户端缓存设计的影响。若关注存款树的弱主观性同步与修剪可继续阅读 EIP-4881 及 LICENSE本 EIP 同样以 CC0 放弃版权。需要注意的是EIP-8254 当前状态为Draft创建于 2026-05-06类型为 Standards Track / Core要求实现 EIP-6110其规范在正式采纳前仍可能调整。作为共识层规则的硬分叉提案其实施细节应以各执行层客户端最终合并的代码与规范演进为准。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考