在合并之后的相当长时间里，以太坊验证者的入场券要走一条双轨管道：存款交易发生在执行层的旧存款合约里，信标链却靠另一套机制「认领」这些存款——提案者往信标链区块里塞一个 eth1_data 投票（指向执行层某批区块的哈希与存款计数），凑够多数后把那一窗口的存款记录整体导入。EIP-6110 把这件事改成了协议内直销：存款作为请求对象随执行层区块直接送达信标链，确认从大约九小时的投票窗口缩到分钟级。但旧字段没有被立刻删——EIP-8015 就是负责在迁移彻底结束后给它们办退休的：2025 年 8 月 22 日创建的 Draft 草案，requires 字段挂着 EIP-6110、请求框架 EIP-7688 与升级元提案 EIP-7773。
双轨过渡期里字段在忙什么
6110 的设计刻意保守：新管道上线时，deposits 列表和 eth1_data 投票原样留在 BeaconBlockBody 里，两条通道并存，直到所有历史待处理存款清账、且新机制被确认稳定。过渡期里，区块里同时能看到旧投票结构与新请求队列的痕迹——这是纯保险：万一协议内通道出问题，旧管道仍是逃生门。8015 的激活条件因此写得非常保守，两个条件必须同时满足：其一是 state.eth1_deposit_index == state.deposit_requests_start_index，即旧账簿的每一笔都已入账、两套序号首尾对齐；其二是 Glamsterdam 升级生效。在那之前，任何节点都不得移除这两个字段。
删字段删的是什么
实现方式很 SSZ：不硬改容器定义，而是把 ProgressiveContainer 里对应字段的 active_fields 位清零——eth1_data 与被 ProgressiveList 包裹的 deposits 从区块体中整体消失。收益不在「少传几字节」那么表面：历史过期（history expiry）类提案希望节点不必为追块回放远古历史，而旧存款管道恰恰要求节点能访问遥远的历史区块哈希；字段一撤，信标链状态机对执行层历史的最后一根长程依赖被剪断，验证一条信标链所需的历史证据显著缩短。对运维，这意味着协议里少了一类会过期的兼容性包袱。
为什么值得写一篇「删除」
协议设计里，加东西容易撤东西难。双轨制结束多年后仍留着旧字段的链并不罕见，代价藏在每个新提案必须处理的向后兼容分支里。8015 给出的是一个干净的范本：先立迁移提案（6110），再为收尾单独立项，且收尾的激活条件用状态等式而非时间点表述——「账对齐了」比「时候到了」更难出错。对读信标链数据的分析者，可见的变化是：未来的某次升级之后，区块体里再也解析不出 eth1_data；解析历史区块时则需要按升级前结构读取，两套解析器并存的窗口会长期存在。
一次字段的旅行
把一笔存款的一生走完就能看清双轨的分野。旧时代：用户在执行层存款合约存入 32 个 ETH，这笔记录先躺在执行层某批区块里；提案者计算那批区块的存款根与计数，填进信标链区块的 eth1_data；全体验证者投票多数认可后，这条存款才在信标链「生效」——最快也要跨约九小时窗口，期间它还不在信标链状态里。新时代：6110 让同一次存款变成执行层区块里的一条请求，下一轮就出现在信标链的请求队列里，几分钟入账。8015 删掉的正是前半段剧本里才需要的道具：投票结构和认领用的存款计数。道具离场，剧本不再上演，这就是「字段退役」四个字的完整含义。
快速问答
问：删除之后存款还会经过执行层吗？ 答：会。6110 的方向恰恰是存款全程在执行层产生、经请求通道进入信标链；退役的是旧时代的投票认领字段，不是执行层入口。
问：这会影响已质押的 ETH 吗？ 答：机制层面无影响。存款字段只关乎「新验证者入场记录如何被认领」，不触碰既有验证者的余额与密钥。
问：Glamsterdam 是什么时态？ 答：尚未激活的升级代号——激活时间在 meta 文件里仍是待定，8015 对它的引用只是把「升级生效」写成条件之一。
风险提示
本文为协议提案解读，不构成投资建议，也不构成对质押收益的任何承诺。存款与质押操作请以当前官方启动面板与客户端文档为准；提案内容可能随社区讨论修改或作废。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。