以太坊在 Pectra 升级里给执行层和共识层之间修了几条正式的「请求通道」：存款、提款、验证者合并，各自有专门的请求类型、专门的系统处理和专门的校验逻辑。EIP-8012 盯上了其中看似最不起眼的合并通道，提出一个便宜的改造：这条管道不必只传合并，它可以被重新解释成一条通用的执行层到共识层传话管，而且执行层一个字都不用改。提案由共识层客户端开发者 Potuz 起草，2025 年 8 月提交，官方状态是停滞（Stagnant），设计完全落在共识层一侧。
四十八字节的身份歧义
合并请求的负载里有一个 target pubkey 字段，按规范装着目标验证者的四十八字节 BLS 公钥。提案的观察是：四十八字节就是一串四十八字节，协议并不能强制它「必须长得像公钥」。于是新读法可以这样定：共识层收到一条合并请求，先拿这串字节去对照信标链上现有活跃验证者的公钥——对上了，一切照旧，按合并处理；对不上，就把这串字节按新格式拆开读。拆法是定死的三段式：开头三个字节必须是一个写死的前缀魔数 0xEF0A11，表明「这不是一把公钥，是一条编码消息」；接下来四个字节按小端序解释成函数类型编号，再一个字节数出参数个数；剩下的位置按每个八字节小端无符号整数排开，最多装五个参数。每新增一种用途，共识层就在处理合并请求的入口里挂一个新处理函数，执行层始终蒙在鼓里。
省掉的是跨层协调
这套戏法真正值钱的地方在提案的动机段写得直白：为共识层的未来硬分叉免掉跨层协调。以太坊升级的执行层侧与共识层侧历来需要同排期、同测试、同激活，任何一个方向的改动忘了通知另一个方向都是事故素材。如果执行层已经有一条「把不透明字节塞进请求、共识层爱怎么读怎么读」的通道，那么纯共识层的实验就可以搭现有管道发布：执行层照常收集请求、照常转发字节，只有共识层的新版本才理解新含义。提案举的应用例子是让现有验证者通过同一条通道申请成为出块构建者，配合的是仍在推进的内置构建者分离设想。
便宜方案的账单
把专用通道改成万能通道，代价藏在语义里。同一串字节到底是合并指令还是通用消息，判定依赖「链上有没有一把撞名的公钥」——一个边缘的运气事件可能让一条通用消息被误读成合并，或者反过来；魔数前缀就是为了压缩这种碰撞面而存在的第一道闸。第二道闸是全链一致的解码规则：参数数量、字节序、每个字段的宽度都必须在所有客户端里逐位一致，否则「合并请求的账本」这一本来语义单一的队列会分裂出方言。这也解释了为什么它停在停滞：与其为一个假想的便利现在就吃掉字段语义的复杂度，不如等各真需求成熟再决定要不要共用这条管道。在 EIP 的世界里，好想法排队的地方不是墓地，而是状态徽章里那个不起眼的 Stagnant。
快速问答
问：这条通道会改变普通用户的操作吗？ 答：不会。执行层零改动意味着钱包、节点、发请求的方式全都不变，变化只发生在信标链怎么理解收到的字节。
问：这和预注册请求合约是什么关系？ 答：它复用正是 Pectra 引入的那套请求框架——同一类「执行层收下、共识层结算」的管道，只是把其中一条管道负载的读法再加了一层。
风险提示：本文讨论处于停滞状态的协议提案，不构成投资建议；质押相关操作请以当期客户端文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。