EIP-6110 深度解读将验证者存款作为执行层请求上链取代 Eth1Data 投票机制【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-6110Supply validator deposits on chain是一项已进入Final状态、类别为Core的以太坊核心协议提案其核心思想是把验证者存款validator deposits以结构化数据的形式直接追加到执行层Execution Layer区块中从根本上取代共识层Consensus Layer原有的Eth1Data提议人投票机制。本文将围绕该提案的动机、执行层与共识层规范、安全分析与配套资产逐层展开并结合本仓库中与其直接相关的 EIP-7685通用执行层请求、EIP-4881存款合约快照以及 assets/eip-6110 下的分析文档帮助读者完整掌握该机制的原理、实现要点与安全边界。一、提案概览存款如何上链EIP-6110 的抽象Abstract非常简洁将验证者存款追加到执行层区块结构中。区块中携带的存款列表由解析该区块内每笔存款交易deposit transaction所产生的存款合约日志事件deposit contract log events得到。这一改动把存款包含与验证的责任从共识层转移到了执行层从而消除了共识层对Eth1Data即eth1data投票机制的需求。也就是说信标链Beacon Chain不再需要通过验证者投票来决定下一个存款来自哪条执行链区块而是直接消费执行层区块中已经固化下来的存款操作列表。二、动机为什么必须改变存款处理机制验证者存款是权益证明proof-of-stake共识机制的核心组成部分。EIP-6110 提出了一种协议内的in-protocol存款处理机制其相对现有机制的收益包括显著提升存款安全性以协议内机制取代提议人投票后即使超过 2/3 质押份额stake是恶意的一个诚实的在线节点也不可能被说服去处理虚假存款。大幅缩短存款确认延迟在协议内处理机制下从执行层提交存款交易到共识层处理完成约13 分钟而现有机制需要约12 小时。消除信标区块提议对 JSON-RPC API 数据轮询的依赖该轮询机制容易因各客户端 JSON-RPC API 实现不一致以及 API 调用处理依赖客户端内部状态如同步中 syncing而失败。消除维护与分发存款合约快照的需求即不再依赖 EIP-4881 所定义的存款 Merkle 树快照接口。降低共识层客户端软件在易碎组件上的设计与工程复杂度。一句话概括存款流程从执行层出数据 共识层投票表决演变为执行层出数据 共识层直接消费简化了协议并提高了安全性。三、执行层规范Execution Layer3.1 常量与配置EIP-6110 在执行层定义了如下常量与配置参数常量| 名称 | 值 | 注释 | | - | - | - | |DEPOSIT_REQUEST_TYPE|b0| EIP-7685 中存款操作的请求类型字节 |配置| 名称 | 值 | 注释 | | - | - | - | |DEPOSIT_CONTRACT_ADDRESS|0x00000000219ab540356cbb839cbe05303d7705fa| 主网Mainnet | |DEPOSIT_EVENT_SIGNATURE_HASH|0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5| |规范明确要求DEPOSIT_CONTRACT_ADDRESS与DEPOSIT_EVENT_SIGNATURE_HASH两个参数**必须MUST**被包含进客户端软件的二进制发行版binary distribution中。3.2 关键定义FORK_BLOCK—— 本 EIP 激活后区块链中的第一个区块。3.3 存款请求结构Deposit request表示新存款请求的结构由以下字段组成pubkey: Bytes48—— 验证者公钥48 字节withdrawal_credentials: Bytes32—— 提款凭证32 字节amount: uint64—— 存款金额8 字节signature: Bytes96—— 存款签名96 字节index: uint64—— 存款索引8 字节存款是 EIP-7685 请求的一种类型编码方式为request_type DEPOSIT_REQUEST_TYPE request_data get_deposit_request_data(block.receipts)即请求类型字节固定为b0请求数据由区块收据receipts解析得到。3.4 区块有效性规则从FORK_BLOCK开始区块中累积的每个存款**必须MUST**以它们在日志logs中出现的顺序出现在 EIP-7685 请求列表中。为便于实现规范给出了如下 Python 参考伪代码def parse_deposit_data(deposit_event_data) - bytes[]: Parses deposit data from DepositContract.DepositEvent data pass def is_valid_deposit_event_data(deposit_event_data: bytes) - bool: Verifies the layout of the DepositEvent. Returns False if the layout is unsupported, True if the layout is of the expected format. if len(deposit_event_data) ! 576: return False pubkey_offset int.from_bytes(deposit_event_data[0:32], byteorderbig, signedFalse) withdrawal_credentials_offset int.from_bytes(deposit_event_data[32:64], byteorderbig, signedFalse) amount_offset int.from_bytes(deposit_event_data[64:96], byteorderbig, signedFalse) signature_offset int.from_bytes(deposit_event_data[96:128], byteorderbig, signedFalse) index_offset int.from_bytes(deposit_event_data[128:160], byteorderbig, signedFalse) if ( pubkey_offset ! 160 or withdrawal_credentials_offset ! 256 or amount_offset ! 320 or signature_offset ! 384 or index_offset ! 512 ): return False # These sizes are the sizes of the relevant data pubkey_size int.from_bytes(deposit_event_data[pubkey_offset:pubkey_offset32], byteorderbig, signedFalse) withdrawal_credentials_size int.from_bytes(deposit_event_data[withdrawal_credentials_offset:withdrawal_credentials_offset32], byteorderbig, signedFalse) amount_size int.from_bytes(deposit_event_data[amount_offset:amount_offset32], byteorderbig, signedFalse) signature_size int.from_bytes(deposit_event_data[signature_offset:signature_offset32], byteorderbig, signedFalse) index_size int.from_bytes(deposit_event_data[index_offset:index_offset32], byteorderbig, signedFalse) return ( pubkey_size 48 and withdrawal_credentials_size 32 and amount_size 8 and signature_size 96 and index_size 8 ) def event_data_to_deposit_request(deposit_event_data) - bytes: deposit_data parse_deposit_data(deposit_event_data) pubkey Bytes48(deposit_data[0]) withdrawal_credentials Bytes32(deposit_data[1]) amount deposit_data[2] # 8 bytes uint64 LE signature Bytes96(deposit_data[3]) index deposit_data[4] # 8 bytes uint64 LE return pubkey withdrawal_credentials amount signature index def get_deposit_request_data(receipts) # Retrieve all deposits made in the block deposit_requests [] for receipt in receipts: for log in receipt.logs: if log.address DEPOSIT_CONTRACT_ADDRESS: if len(log.topics) 0 and log.topics[0] DEPOSIT_EVENT_SIGNATURE_HASH: assert is_valid_deposit_event_data(log.data), invalid deposit log: unsupported data layout deposit_request event_data_to_deposit_request(log.data) deposit_requests.append(deposit_request) # Concatenate list of deposit request data return b.join(deposit_requests)对上述代码做几点实现层面的解读数据布局校验DepositEvent的事件数据长度必须为 576 字节前 160 字节为五个字段的 ABI 偏移量分别为 160/256/320/384/512随后按偏移量读取各字段的长度前缀并要求pubkey_size 48、withdrawal_credentials_size 32、amount_size 8、signature_size 96、index_size 8。任何不符合该布局的事件数据都会导致区块无效断言失败。过滤规则只有log.address DEPOSIT_CONTRACT_ADDRESS且log.topics[0] DEPOSIT_EVENT_SIGNATURE_HASH的日志才会被收集为存款。这避免了把合约发出的其他事件如 Sepolia 存款合约额外发出的Transfer事件误当成存款。序列化格式每个存款请求按pubkey (48B) withdrawal_credentials (32B) amount (8B LE) signature (96B) index (8B LE)共 192 字节拼接所有存款再按日志顺序拼接成最终的request_data。四、承载机制EIP-7685 通用执行层请求EIP-6110 的requires字段指向 EIP-7685General purpose execution layer requests存款是第一个通过该请求总线上行的请求类型。EIP-7685 定义了一个requests对象由一个request_type字节加上不透明的字节数组request_data组成requests request_type request_data。区块头新增 32 字节承诺值requests_hash计算方式为对所有非空请求元素先做 sha256再按request_type升序排列后整体做 sha256def compute_requests_hash(block_requests: Sequence[bytes]): m sha256() for r in block_requests: if len(r) 1: m.update(sha256(r).digest()) return m.digest() block.header.requests_hash compute_requests_hash(requests)request_data从第二个字节起保持不透明opaque这使得未来可以自由选择 SSZ、LEB128 或定宽等编码格式而不改变区块结构。EIP-7685 也强调请求往往无法在执行层被完全验证因此被称为请求requests而非指令其完整验证在共识层完成——这正是 EIP-6110 中存款签名等验证逻辑所在的位置。五、共识层变更Consensus LayerEIP-6110 对共识层的改动可以归纳为以下五点ExecutionRequests新增deposit_requests字段用于容纳存款请求列表。BeaconState追加deposit_requests_start_index字段用于从旧存款机制切换到新机制。作为过渡逻辑的一部分新增信标区块有效性条件约束Eth1Data轮询的使用。区块处理流程中新增process_deposit_request函数负责处理deposit_requests。验证者指南validator guide提供在过渡完成后关闭Eth1Data轮询的逻辑。详细共识层规范位于 consensus-specs 仓库的electra目录下beacon-chain.md状态转换、validator.md验证者指南、fork.mdEIP 激活本文不展开其逐条实现但有两个设计要点值得深入理解。5.1 验证者索引不变式Validator index invariant被打破由于Eth1Data轮询存在较大的跟随距离follow distance旧机制下新验证者在存款处理过程中获得的索引在不同区块树分支上保持一致——即共识层客户端依赖的(pubkey, index)缓存具有重组re-org弹性。新的存款机制打破了这一不变式同一个pubkey在不同区块树分支上可能拥有不同的验证者索引fork dependent。本仓库附带的 pubkey_to_index_cache_analysis.md 分析指出process_deposit函数是共识规范中唯一需要依赖未最终化unfinalized(pubkey, index)信息的位置index2Pubkey的使用场景远多于pubkey2Index且其使用场景都不需要未最终化信息因此unfinalizedIndex2Pubkey缓存并非必需而unfinalizedPubkey2Index缓存对于process_depositapply_deposit是必需的。实现共识层客户端时需要针对这一分叉相关性重新设计缓存策略。5.2Eth1Data轮询的弃用过渡期结束后共识层客户端可以**非协调地uncoordinated**移除Eth1Data轮询机制。过渡期完成的判据是网络达到state.eth1_deposit_index state.deposit_requests_start_index的状态。六、设计动机Rationale解读index字段存款index用于确定性地初始化BeaconState中的deposit_requests_start_index从而在Eth1Data轮询弃用过程中防止同一笔存款被重复应用。不限制存款操作列表大小由于数据复杂度可忽略且不存在潜在的 DoS 向量详见安全考量列表是无界的。按DEPOSIT_CONTRACT_ADDRESS与DEPOSIT_EVENT_SIGNATURE_HASH过滤事件存款智能合约在处理存款时可能发出不同类型的事件例如 Sepolia 上的存款合约除DepositEvent外还会发出Transfer因此必须过滤掉无关事件。七、向后兼容性本 EIP 对区块结构和区块验证规则集引入了向后不兼容的更改但这些更改都不会破坏任何与用户活动和体验相关的内容。八、安全考量Security Considerations8.1 数据复杂度截至文档最近更新时已提交的存款总数约为1,899,120笔对应约348MB存款数据。假设存款交易频率保持不变本 EIP 引入的历史链数据复杂度可估算为每年约 84MB相对于其他历史数据可以忽略。自 2020 年 12 月信标链上线以来观测到的最大存款提交峰值出现在2023 年 6 月 1 日24 小时内提交了超过 12,000 笔存款交易平均每个区块不足 2 笔存款即 384 字节数据。结论本提案引入的数据复杂度可以忽略不计。8.2 DoS 向量存款合约中的代码在最便宜的情况下所有存储槽均为热槽且只需修改一个叶子节点运行成本为15,650 gas批量存款batch deposit中部分存款更贵但摊薄到大量存款上后每笔约1,000 gas。在当前的 gas 定价规则下执行一次转账 ETH 的CALL需额外支付6,900 gas属于 gas 定价低效的情况未来可能降低。为增强未来健壮性信标链需要能够承受 30M gas 区块中1,916 笔存款按每笔 15,650 gas 计而按现行规则30M gas 区块中的上限不足1,271 笔。执行层维度以 1 ETH 为最低存款金额1 字节存款数据的最低成本为1 ETH / 192 ≈ 5,208,333 Gwei比 1 字节交易 calldata 的成本高出数个数量级。因此向区块添加存款操作不会扩大执行层的 DoS 攻击面。共识层维度存款处理中最耗计算的是签名验证其复杂度受限于每个区块的最大存款数当前约 1,271 笔对应 30M gas 区块即约 1,271 次签名验证处理时间约1.2 秒未采用批量签名验证等优化手段。攻击者需要花费1,000 ETH才能将区块处理拖慢 1 秒这种攻击从长期看不具备可持续性与可行性。乐观同步optimistic sync场景乐观同步中的节点无法验证 payload 中提供的存款列表攻击者最多可以塞入限制允许的存款数量——目前为8,192 笔存款1.5MB 数据粗略处理时间约8 秒。考虑到攻击者需要用加密经济上可行的签名签署该区块需要构建替代链并喂给同步中的节点该攻击向量不被认为可行因为它无法导致同步过程显著变慢。8.3 乐观同步与信任模型乐观同步节点必须依赖诚实多数假设如果对手强大到足以最终确定一个存款序列同步节点将不得不应用这些存款而无法依据给定区块的执行情况来判断存款请求的有效性。因此能够最终确定无效链的对手同样可以说服诚实节点接受虚假存款。这与执行层世界状态有效性现状一致——新的存款处理设计并未突破现有的安全模型边界。在线节点不会陷入这种情况因为其执行层会依据区块执行结果验证所提供的存款。8.4 弱主观性周期Weak subjectivity period本 EIP 移除了每个 epoch 存款数的硬上限使区块 gas 上限成为唯一的限制因素。即每 epoch 的存款数上限从MAX_DEPOSITS * SLOTS_PER_EPOCH 512变为max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ≈ 32,768按 30M gas 区块与max_deposits_per_30m_gas_block 1,024简化估算。这一变化会影响每个 epoch 的补缴top ups数量而补缴数量是弱主观性周期计算的输入之一验证者可以通过补缴自己的验证者来即时增加相对那些正在流失leaking验证者的质押份额占比。仓库附带的 ws_period_analysis.md 使用修改后的 eth2_ws_calc.py 脚本基于 eth2.0-specs 的弱主观性周期定义进行了计算结果并未显示弱主观性周期规模有显著缩减Safety DecayAvg. Val. Balance (ETH)Val. CountWS (Epochs)16deposits per slotWS (Epochs)1024deposits per slot102032768272256102065536288256102013107232025710202621443842581020524288512260102010485767682641024327683103101024655363653651024131072474474102426214469269210245242886926921024104857610415041028327685045041028655367527521028131072124812481028262144224122411028524288224122411028104857622412241103232768665665103265536107510751032131072189418941032262144353235321032524288353235321032104857635323532注意表中每 slot 1024 笔存款列的数值即模拟本 EIP 放开存款数上限后的情形其中与基准值不同的条目已用加粗标出。分析结论是弱主观性周期规模没有显著缩减且此类攻击不被视为可行因为其前提之一是需要燃烧相当比例的质押份额。九、配套资产与生态关联pubkey_to_index_cache_analysis.md对pubkey2Index/index2Pubkey缓存使用场景的完整分析论证process_deposit是唯一需要分叉相关缓存的位置。ws_period_analysis.md 与 eth2_ws_calc.py弱主观性周期计算脚本及其结果表脚本可独立运行复现上表数据。EIP-4881Deposit Contract Snapshot Interface定义存款 Merkle 树快照的压缩传输格式EIP-6110 上线后该机制将不再必需。EIP-7685本 EIP 的承载框架定义了requests_hash承诺与请求编码规则。EIP-7684后续基于 EIP-6110 的存款流程扩展提案其讨论中引用了 EIP-6110 的吞吐数字如 30M gas 区块下 1,271 笔存款上限及未来可能的 1,916 笔。十、结语EIP-6110 是存款处理流程从共识层投票走向执行层直接供给的分水岭。它利用 EIP-7685 请求总线把存款变成区块的固有组成部分既消除了Eth1Data投票及其伴随的 JSON-RPC 轮询、存款快照分发等复杂组件又显著缩短了存款确认延迟、提升了存款安全性。对于客户端实现者而言重点是理解 576 字节事件布局校验、(pubkey, index)缓存的分叉相关性变化以及deposit_requests_start_index驱动的过渡逻辑对于协议研究者而言弱主观性周期与乐观同步的安全边界分析则是评估该设计的关键材料。本仓库中的 EIPS/eip-6110.md 原文及 assets/eip-6110 下的分析文件提供了继续深入研究的完整一手资料。版权说明本文所述 EIP-6110 及相关内容版权依据 LICENSE.md 中的 CC0 条款放弃。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-6110 深度解读：将验证者存款作为执行层请求上链，取代 Eth1Data 投票机制
EIP-6110 深度解读将验证者存款作为执行层请求上链取代 Eth1Data 投票机制【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-6110Supply validator deposits on chain是一项已进入Final状态、类别为Core的以太坊核心协议提案其核心思想是把验证者存款validator deposits以结构化数据的形式直接追加到执行层Execution Layer区块中从根本上取代共识层Consensus Layer原有的Eth1Data提议人投票机制。本文将围绕该提案的动机、执行层与共识层规范、安全分析与配套资产逐层展开并结合本仓库中与其直接相关的 EIP-7685通用执行层请求、EIP-4881存款合约快照以及 assets/eip-6110 下的分析文档帮助读者完整掌握该机制的原理、实现要点与安全边界。一、提案概览存款如何上链EIP-6110 的抽象Abstract非常简洁将验证者存款追加到执行层区块结构中。区块中携带的存款列表由解析该区块内每笔存款交易deposit transaction所产生的存款合约日志事件deposit contract log events得到。这一改动把存款包含与验证的责任从共识层转移到了执行层从而消除了共识层对Eth1Data即eth1data投票机制的需求。也就是说信标链Beacon Chain不再需要通过验证者投票来决定下一个存款来自哪条执行链区块而是直接消费执行层区块中已经固化下来的存款操作列表。二、动机为什么必须改变存款处理机制验证者存款是权益证明proof-of-stake共识机制的核心组成部分。EIP-6110 提出了一种协议内的in-protocol存款处理机制其相对现有机制的收益包括显著提升存款安全性以协议内机制取代提议人投票后即使超过 2/3 质押份额stake是恶意的一个诚实的在线节点也不可能被说服去处理虚假存款。大幅缩短存款确认延迟在协议内处理机制下从执行层提交存款交易到共识层处理完成约13 分钟而现有机制需要约12 小时。消除信标区块提议对 JSON-RPC API 数据轮询的依赖该轮询机制容易因各客户端 JSON-RPC API 实现不一致以及 API 调用处理依赖客户端内部状态如同步中 syncing而失败。消除维护与分发存款合约快照的需求即不再依赖 EIP-4881 所定义的存款 Merkle 树快照接口。降低共识层客户端软件在易碎组件上的设计与工程复杂度。一句话概括存款流程从执行层出数据 共识层投票表决演变为执行层出数据 共识层直接消费简化了协议并提高了安全性。三、执行层规范Execution Layer3.1 常量与配置EIP-6110 在执行层定义了如下常量与配置参数常量| 名称 | 值 | 注释 | | - | - | - | |DEPOSIT_REQUEST_TYPE|b0| EIP-7685 中存款操作的请求类型字节 |配置| 名称 | 值 | 注释 | | - | - | - | |DEPOSIT_CONTRACT_ADDRESS|0x00000000219ab540356cbb839cbe05303d7705fa| 主网Mainnet | |DEPOSIT_EVENT_SIGNATURE_HASH|0x649bbc62d0e31342afea4e5cd82d4049e7e1ee912fc0889aa790803be39038c5| |规范明确要求DEPOSIT_CONTRACT_ADDRESS与DEPOSIT_EVENT_SIGNATURE_HASH两个参数**必须MUST**被包含进客户端软件的二进制发行版binary distribution中。3.2 关键定义FORK_BLOCK—— 本 EIP 激活后区块链中的第一个区块。3.3 存款请求结构Deposit request表示新存款请求的结构由以下字段组成pubkey: Bytes48—— 验证者公钥48 字节withdrawal_credentials: Bytes32—— 提款凭证32 字节amount: uint64—— 存款金额8 字节signature: Bytes96—— 存款签名96 字节index: uint64—— 存款索引8 字节存款是 EIP-7685 请求的一种类型编码方式为request_type DEPOSIT_REQUEST_TYPE request_data get_deposit_request_data(block.receipts)即请求类型字节固定为b0请求数据由区块收据receipts解析得到。3.4 区块有效性规则从FORK_BLOCK开始区块中累积的每个存款**必须MUST**以它们在日志logs中出现的顺序出现在 EIP-7685 请求列表中。为便于实现规范给出了如下 Python 参考伪代码def parse_deposit_data(deposit_event_data) - bytes[]: Parses deposit data from DepositContract.DepositEvent data pass def is_valid_deposit_event_data(deposit_event_data: bytes) - bool: Verifies the layout of the DepositEvent. Returns False if the layout is unsupported, True if the layout is of the expected format. if len(deposit_event_data) ! 576: return False pubkey_offset int.from_bytes(deposit_event_data[0:32], byteorderbig, signedFalse) withdrawal_credentials_offset int.from_bytes(deposit_event_data[32:64], byteorderbig, signedFalse) amount_offset int.from_bytes(deposit_event_data[64:96], byteorderbig, signedFalse) signature_offset int.from_bytes(deposit_event_data[96:128], byteorderbig, signedFalse) index_offset int.from_bytes(deposit_event_data[128:160], byteorderbig, signedFalse) if ( pubkey_offset ! 160 or withdrawal_credentials_offset ! 256 or amount_offset ! 320 or signature_offset ! 384 or index_offset ! 512 ): return False # These sizes are the sizes of the relevant data pubkey_size int.from_bytes(deposit_event_data[pubkey_offset:pubkey_offset32], byteorderbig, signedFalse) withdrawal_credentials_size int.from_bytes(deposit_event_data[withdrawal_credentials_offset:withdrawal_credentials_offset32], byteorderbig, signedFalse) amount_size int.from_bytes(deposit_event_data[amount_offset:amount_offset32], byteorderbig, signedFalse) signature_size int.from_bytes(deposit_event_data[signature_offset:signature_offset32], byteorderbig, signedFalse) index_size int.from_bytes(deposit_event_data[index_offset:index_offset32], byteorderbig, signedFalse) return ( pubkey_size 48 and withdrawal_credentials_size 32 and amount_size 8 and signature_size 96 and index_size 8 ) def event_data_to_deposit_request(deposit_event_data) - bytes: deposit_data parse_deposit_data(deposit_event_data) pubkey Bytes48(deposit_data[0]) withdrawal_credentials Bytes32(deposit_data[1]) amount deposit_data[2] # 8 bytes uint64 LE signature Bytes96(deposit_data[3]) index deposit_data[4] # 8 bytes uint64 LE return pubkey withdrawal_credentials amount signature index def get_deposit_request_data(receipts) # Retrieve all deposits made in the block deposit_requests [] for receipt in receipts: for log in receipt.logs: if log.address DEPOSIT_CONTRACT_ADDRESS: if len(log.topics) 0 and log.topics[0] DEPOSIT_EVENT_SIGNATURE_HASH: assert is_valid_deposit_event_data(log.data), invalid deposit log: unsupported data layout deposit_request event_data_to_deposit_request(log.data) deposit_requests.append(deposit_request) # Concatenate list of deposit request data return b.join(deposit_requests)对上述代码做几点实现层面的解读数据布局校验DepositEvent的事件数据长度必须为 576 字节前 160 字节为五个字段的 ABI 偏移量分别为 160/256/320/384/512随后按偏移量读取各字段的长度前缀并要求pubkey_size 48、withdrawal_credentials_size 32、amount_size 8、signature_size 96、index_size 8。任何不符合该布局的事件数据都会导致区块无效断言失败。过滤规则只有log.address DEPOSIT_CONTRACT_ADDRESS且log.topics[0] DEPOSIT_EVENT_SIGNATURE_HASH的日志才会被收集为存款。这避免了把合约发出的其他事件如 Sepolia 存款合约额外发出的Transfer事件误当成存款。序列化格式每个存款请求按pubkey (48B) withdrawal_credentials (32B) amount (8B LE) signature (96B) index (8B LE)共 192 字节拼接所有存款再按日志顺序拼接成最终的request_data。四、承载机制EIP-7685 通用执行层请求EIP-6110 的requires字段指向 EIP-7685General purpose execution layer requests存款是第一个通过该请求总线上行的请求类型。EIP-7685 定义了一个requests对象由一个request_type字节加上不透明的字节数组request_data组成requests request_type request_data。区块头新增 32 字节承诺值requests_hash计算方式为对所有非空请求元素先做 sha256再按request_type升序排列后整体做 sha256def compute_requests_hash(block_requests: Sequence[bytes]): m sha256() for r in block_requests: if len(r) 1: m.update(sha256(r).digest()) return m.digest() block.header.requests_hash compute_requests_hash(requests)request_data从第二个字节起保持不透明opaque这使得未来可以自由选择 SSZ、LEB128 或定宽等编码格式而不改变区块结构。EIP-7685 也强调请求往往无法在执行层被完全验证因此被称为请求requests而非指令其完整验证在共识层完成——这正是 EIP-6110 中存款签名等验证逻辑所在的位置。五、共识层变更Consensus LayerEIP-6110 对共识层的改动可以归纳为以下五点ExecutionRequests新增deposit_requests字段用于容纳存款请求列表。BeaconState追加deposit_requests_start_index字段用于从旧存款机制切换到新机制。作为过渡逻辑的一部分新增信标区块有效性条件约束Eth1Data轮询的使用。区块处理流程中新增process_deposit_request函数负责处理deposit_requests。验证者指南validator guide提供在过渡完成后关闭Eth1Data轮询的逻辑。详细共识层规范位于 consensus-specs 仓库的electra目录下beacon-chain.md状态转换、validator.md验证者指南、fork.mdEIP 激活本文不展开其逐条实现但有两个设计要点值得深入理解。5.1 验证者索引不变式Validator index invariant被打破由于Eth1Data轮询存在较大的跟随距离follow distance旧机制下新验证者在存款处理过程中获得的索引在不同区块树分支上保持一致——即共识层客户端依赖的(pubkey, index)缓存具有重组re-org弹性。新的存款机制打破了这一不变式同一个pubkey在不同区块树分支上可能拥有不同的验证者索引fork dependent。本仓库附带的 pubkey_to_index_cache_analysis.md 分析指出process_deposit函数是共识规范中唯一需要依赖未最终化unfinalized(pubkey, index)信息的位置index2Pubkey的使用场景远多于pubkey2Index且其使用场景都不需要未最终化信息因此unfinalizedIndex2Pubkey缓存并非必需而unfinalizedPubkey2Index缓存对于process_depositapply_deposit是必需的。实现共识层客户端时需要针对这一分叉相关性重新设计缓存策略。5.2Eth1Data轮询的弃用过渡期结束后共识层客户端可以**非协调地uncoordinated**移除Eth1Data轮询机制。过渡期完成的判据是网络达到state.eth1_deposit_index state.deposit_requests_start_index的状态。六、设计动机Rationale解读index字段存款index用于确定性地初始化BeaconState中的deposit_requests_start_index从而在Eth1Data轮询弃用过程中防止同一笔存款被重复应用。不限制存款操作列表大小由于数据复杂度可忽略且不存在潜在的 DoS 向量详见安全考量列表是无界的。按DEPOSIT_CONTRACT_ADDRESS与DEPOSIT_EVENT_SIGNATURE_HASH过滤事件存款智能合约在处理存款时可能发出不同类型的事件例如 Sepolia 上的存款合约除DepositEvent外还会发出Transfer因此必须过滤掉无关事件。七、向后兼容性本 EIP 对区块结构和区块验证规则集引入了向后不兼容的更改但这些更改都不会破坏任何与用户活动和体验相关的内容。八、安全考量Security Considerations8.1 数据复杂度截至文档最近更新时已提交的存款总数约为1,899,120笔对应约348MB存款数据。假设存款交易频率保持不变本 EIP 引入的历史链数据复杂度可估算为每年约 84MB相对于其他历史数据可以忽略。自 2020 年 12 月信标链上线以来观测到的最大存款提交峰值出现在2023 年 6 月 1 日24 小时内提交了超过 12,000 笔存款交易平均每个区块不足 2 笔存款即 384 字节数据。结论本提案引入的数据复杂度可以忽略不计。8.2 DoS 向量存款合约中的代码在最便宜的情况下所有存储槽均为热槽且只需修改一个叶子节点运行成本为15,650 gas批量存款batch deposit中部分存款更贵但摊薄到大量存款上后每笔约1,000 gas。在当前的 gas 定价规则下执行一次转账 ETH 的CALL需额外支付6,900 gas属于 gas 定价低效的情况未来可能降低。为增强未来健壮性信标链需要能够承受 30M gas 区块中1,916 笔存款按每笔 15,650 gas 计而按现行规则30M gas 区块中的上限不足1,271 笔。执行层维度以 1 ETH 为最低存款金额1 字节存款数据的最低成本为1 ETH / 192 ≈ 5,208,333 Gwei比 1 字节交易 calldata 的成本高出数个数量级。因此向区块添加存款操作不会扩大执行层的 DoS 攻击面。共识层维度存款处理中最耗计算的是签名验证其复杂度受限于每个区块的最大存款数当前约 1,271 笔对应 30M gas 区块即约 1,271 次签名验证处理时间约1.2 秒未采用批量签名验证等优化手段。攻击者需要花费1,000 ETH才能将区块处理拖慢 1 秒这种攻击从长期看不具备可持续性与可行性。乐观同步optimistic sync场景乐观同步中的节点无法验证 payload 中提供的存款列表攻击者最多可以塞入限制允许的存款数量——目前为8,192 笔存款1.5MB 数据粗略处理时间约8 秒。考虑到攻击者需要用加密经济上可行的签名签署该区块需要构建替代链并喂给同步中的节点该攻击向量不被认为可行因为它无法导致同步过程显著变慢。8.3 乐观同步与信任模型乐观同步节点必须依赖诚实多数假设如果对手强大到足以最终确定一个存款序列同步节点将不得不应用这些存款而无法依据给定区块的执行情况来判断存款请求的有效性。因此能够最终确定无效链的对手同样可以说服诚实节点接受虚假存款。这与执行层世界状态有效性现状一致——新的存款处理设计并未突破现有的安全模型边界。在线节点不会陷入这种情况因为其执行层会依据区块执行结果验证所提供的存款。8.4 弱主观性周期Weak subjectivity period本 EIP 移除了每个 epoch 存款数的硬上限使区块 gas 上限成为唯一的限制因素。即每 epoch 的存款数上限从MAX_DEPOSITS * SLOTS_PER_EPOCH 512变为max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ≈ 32,768按 30M gas 区块与max_deposits_per_30m_gas_block 1,024简化估算。这一变化会影响每个 epoch 的补缴top ups数量而补缴数量是弱主观性周期计算的输入之一验证者可以通过补缴自己的验证者来即时增加相对那些正在流失leaking验证者的质押份额占比。仓库附带的 ws_period_analysis.md 使用修改后的 eth2_ws_calc.py 脚本基于 eth2.0-specs 的弱主观性周期定义进行了计算结果并未显示弱主观性周期规模有显著缩减Safety DecayAvg. Val. Balance (ETH)Val. CountWS (Epochs)16deposits per slotWS (Epochs)1024deposits per slot102032768272256102065536288256102013107232025710202621443842581020524288512260102010485767682641024327683103101024655363653651024131072474474102426214469269210245242886926921024104857610415041028327685045041028655367527521028131072124812481028262144224122411028524288224122411028104857622412241103232768665665103265536107510751032131072189418941032262144353235321032524288353235321032104857635323532注意表中每 slot 1024 笔存款列的数值即模拟本 EIP 放开存款数上限后的情形其中与基准值不同的条目已用加粗标出。分析结论是弱主观性周期规模没有显著缩减且此类攻击不被视为可行因为其前提之一是需要燃烧相当比例的质押份额。九、配套资产与生态关联pubkey_to_index_cache_analysis.md对pubkey2Index/index2Pubkey缓存使用场景的完整分析论证process_deposit是唯一需要分叉相关缓存的位置。ws_period_analysis.md 与 eth2_ws_calc.py弱主观性周期计算脚本及其结果表脚本可独立运行复现上表数据。EIP-4881Deposit Contract Snapshot Interface定义存款 Merkle 树快照的压缩传输格式EIP-6110 上线后该机制将不再必需。EIP-7685本 EIP 的承载框架定义了requests_hash承诺与请求编码规则。EIP-7684后续基于 EIP-6110 的存款流程扩展提案其讨论中引用了 EIP-6110 的吞吐数字如 30M gas 区块下 1,271 笔存款上限及未来可能的 1,916 笔。十、结语EIP-6110 是存款处理流程从共识层投票走向执行层直接供给的分水岭。它利用 EIP-7685 请求总线把存款变成区块的固有组成部分既消除了Eth1Data投票及其伴随的 JSON-RPC 轮询、存款快照分发等复杂组件又显著缩短了存款确认延迟、提升了存款安全性。对于客户端实现者而言重点是理解 576 字节事件布局校验、(pubkey, index)缓存的分叉相关性变化以及deposit_requests_start_index驱动的过渡逻辑对于协议研究者而言弱主观性周期与乐观同步的安全边界分析则是评估该设计的关键材料。本仓库中的 EIPS/eip-6110.md 原文及 assets/eip-6110 下的分析文件提供了继续深入研究的完整一手资料。版权说明本文所述 EIP-6110 及相关内容版权依据 LICENSE.md 中的 CC0 条款放弃。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考