把交易搬上默克尔树：EIP-6404 的 SSZ 交易迁移

一套链，两种打包纸

以太坊的序列化长期分成两个世界：执行层的数据结构用 RLP 编码——只编码长度和嵌套、不描述字段的极简格式；共识层的数据结构用 SSZ——定长字段、可默克尔化的结构化编码。更古老的 RLP 管着交易与状态的字节形态，为信标链设计的 SSZ 管着共识消息。EIP-6404 提议把交易本身也搬进 SSZ。关键词是迁移存放格式，不是重写历史——历史交易在链上仍以原字节存在，这条提案改变的是交易数据在证明体系与网络传输里的结构化程度。

树证明：交易为什么需要变成一棵树

RLP 的交易哈希是对整段字节做一次性线性哈希——要证明交易里某个字段，你得把整笔交易全亮出来。SSZ 把交易组织成一棵默克尔树：每个字段占一个可定位的叶子，证明”第 3 笔交易的接收方是谁”可以只出示若干个兄弟节点哈希。价值在几个具体场景里立即兑现：轻客户端不重放整块就能验证单个字段；索引服务可以按字段建证明而不是整笔存档；在无状态路线里，交易侧字段证明与状态侧见证能打包成同一套树语言，验证器不必在两套证明格式间来回翻译。提案同时把树形态交易的标识符定义为对结构根的哈希，与旧线性标识符建立映射。

兼容设计里最要紧的一条：字节级可逆

这份提案工程上最讲究的段落是可逆性设计：迁移后的规范表示保留足够的类型与字段信息，保证任何一笔从旧格式转换来的交易都能逐字节恢复出原始 RLP 编码，规范形式与原形式之间可以双向转换。为什么较真到这个程度？因为以太坊的交易签名直接对原始编码字节做哈希——签名校验、交易哈希索引、区块浏览器缓存全都锚定”那串字节”。只要恢复不出原文，历史账本的引用完整性就会碎。提案因此把”转换无损、原签名与交易哈希可恢复”写成硬要求，后续所有字段类型讨论都以”能不能从树还原字节”为准绳。

为什么它仍是草案

交易格式动的是共识层地基：每台节点、每个二级索引、每条依赖交易哈希的第三方管道都要跟着改。EIP-6404 的规范还依赖执行载荷与区块头的配套改造（区块头换结构本身另有人推进），任何一环没就位，它就只能停在草案状态。格式搬家类提案的共同命运是：技术收益清晰，协调成本巨大，推进节奏取决于无状态与轻客户端对字段证明的需求有多迫切。

一笔树高度的算术

把抽象换算成一次具体验证。设想一笔规范化交易有 9 个字段，SSZ 布局下字段叶子向上取整到 16 个，树高四层。要为”接收地址等于某值”构造证明，出示的兄弟节点哈希数约等于树高——四个哈希量级，验完即止。同一件事放在线性格式里：整个交易体（含签名字段，常见规模数百字节）全部交给验证方重算解析——数据量差出一个数量级，验证方还得懂那套编码的逐字段解析。再推一层：区块里几百笔交易若每笔都要被抽查一个字段，树化前的抽查成本近似整块交易载荷重传一遍，树化后近似抽查次数乘以树高。无状态路线盯着这笔账，因为见证数据每省一字节都直接折算进带宽与费用。

快速问答

问：我的交易哈希会因为这类提案变掉吗？ 答：历史交易不变；格式迁移类提案解决的是未来的存放与证明方式，旧引用通过可逆映射保持可查。

问：RLP 会被淘汰吗？ 答：执行层短期内仍以 RLP 为主；这条提案推进与否都不影响今天的钱包与浏览器。

风险提示：本文是数据格式机制科普，不构成任何投资建议；格式细节以各提案原文与客户端实现文档为准。