同一条以太坊，两套序列化语言。共识层的信标区块用SSZ——一种定长布局、可生成默克尔证明的格式；执行层的区块用RLP嵌套加默克尔 Patricia 树——为字节灵活性牺牲了结构与证明友好性。草案EIP-7807要终结这种分裂：把执行区块整体搬到SSZ上，区块哈希、请求哈希、逐块的交易树、收据树、提款树全部换掉。但它也刻意划了界限——每笔交易内部的编码和全局状态树都不在这次范围内。
为什么两套编码是问题
客户端要同时维护两棵树体系。共识层验证者做证明时习惯SSZ的广义索引：知道字段位置就能算出它在默克尔树里的路径，证明是常数结构。执行层的默克尔 Patricia 树则依赖键的十六进制展开做路径分支，证明要带一串节点。两种证明逻辑在不同代码路径里运行，跨层的一致性检查——比如信标区块头里承诺的执行区块哈希——永远需要先做一次格式换算。无状态客户端与跨层证明的设想更是直接受制于此：一条证明若横穿两层，就得同时携带两种体系的材料。
EIP-7807的动机段列的收益都围绕这一句：统一两层的区块表示。迁移之后，区块哈希按SSZ结构哈希计算，执行层暴露给共识层的承诺可以直接被共识层工具理解；逐块trie被SSZ容器取代，每笔交易和收据成为可以独立寻址的元素。
不动的东西同样重要
提案特别说明两类东西不受影响。第一是交易与收据列表内部的元素：一笔交易在区块里仍按它原来的类型编码（EIP-2718那条线），钱包签名、已签交易格式不变。第二是全局状态树：世界状态那棵巨大的 Patricia 树不属于逐块结构，这次不碰。这个切分是整场迁移能控制在升级范围内的关键——动交易内部格式会波及每一把已签名交易与每一个签名工具，动状态树则是另一条更重的升级线（长期路线图里的Verkle树与之后的二叉树路线），两者都不适合塞进一次编码迁移。
于是可以把EIP-7807理解为对区块做重新装箱：箱子里的物品原样不动，箱子的规格从软塌塌的绳结换成带格子的标准托盘，托盘的每个格位都有固定编号，证明工具按编号取物。
区块哈希本身的变化值得单独说。过去执行区块哈希是RLP序列化结果的哈希，换到SSZ后，同一个区块的哈希值会改变——这正是需要硬分叉协调的原因，所有依赖执行区块哈希的合约、桥与历史校验工具都要在新的创世点之后适配新格式。
快速问答
问：EIP-7807会改变交易哈希吗？ 答：不会改变单条交易的哈希。受影响的是区块哈希；交易内部编码保持不变。
问：节点需要重新同步吗？ 答：历史区块的编码换算与存储方案由客户端实现层处理，是否需要全量重同步取决于各客户端的迁移策略，以客户端发布说明为准。
问：和无状态以太坊什么关系？ 答：SSZ的统一表示让跨层证明更小更易验证，是无状态路线多次公开讨论提到的前置条件之一，但本提案本身不实现无状态。
一把新尺子的量法
迁到SSZ之后，节点之间交换区块信息的方式也随之变化。过去想向轻客户端证明区块里第几笔交易的存在，需要带上一串 Patricia 节点；换到SSZ容器后，证明退化为按位置索引取分支的默克尔证明，尺寸稳定、工具链统一。对区块浏览器与索引服务而言，字段偏移从按长度解码变成按布局寻址，解析代码从手写解码器换成结构体映射。这些工程收益不在共识规则里，却决定了提案落地后整个生态维护成本下降多少。
一个比喻收尾
两层像两家仓库，账本一个用汉字一个用拉丁字母，每天对账都靠人工翻译。EIP-7807不改货物、不改总账，只把两家仓库的单据格式统一成一种表格——货物清点与跨仓调拨的自动化，才因此成为可能。
风险提示：本文内容为协议机制科普，不构成任何投资建议；升级细节与参数以官方规格为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。