一枚根哈希，如何承诺整个以太坊？Modified Merkle Patricia Trie · State · Storage · Transaction

读到 “State Trie、Storage Trie、Transaction Trie” 时，最危险的做法是把它们想成 一棵巨大目录树的三个文件夹。更准确的模型是：三类独立的键值承诺结构， 其中 State Trie 的账户值会引用某个账户自己的 Storage Trie 根。

假设服务器告诉你：“地址 A 的余额是 12 ETH。”普通数据库可以很快返回 12， 但这个答案本身不能证明服务器没有说谎。若你已经信任某区块头里的 stateRoot，服务器再提供从根到 A 的少量 MPT 节点，你就能在本地重算并验证。

四个能力，正好对应节点的四个需要

1. 查找：给定 key，能走到对应 value。
2. 更新：只重建受影响路径，其余不可变节点可复用。
3. 证明：只提供路径上的节点，就能对可信根验证存在或不存在。
4. 确定性：不同客户端处理相同键值后，必须算出同一个根。

一步不是一个字节，而是半个字节

nibble 是 4 bit，可表示 0…f 共 16 种值。 一个 byte，例如 0xa7，会拆成两个 nibble：a 与 7。 所以 32 字节哈希会形成 64 步的候选路径。

Hex-prefix：两 bit 标记两件事

两项节点的路径要被装回 bytes。首个 flag nibble 同时记录： 它是 Leaf 还是 Extension，以及剩余 nibble 数为奇数还是偶数。

为什么有时父节点存哈希，有时直接嵌入？

节点先做 RLP 编码。若 RLP(node) 长度小于 32 字节， 父节点直接嵌入它；若长度大于等于 32 字节，父节点存 Keccak256(RLP(node))。短节点直接放进去，比再放一个 32 字节哈希更省空间。

stateRoot =
  MPT_ROOT({
    Keccak256(address20)
      ↦ RLP([nonce, balance, storageRoot, codeHash])
  })

四个字段分别承诺什么？

• nonce：EOA 已发送交易数，或合约创建计数相关状态。
• balance：该账户持有的 wei 数量。
• storageRoot：该账户独立 Storage Trie 的根。
• codeHash：账户 EVM 字节码的 Keccak 哈希。

EVM 把合约持久化 storage 看成 2²⁵⁶ 个 32 字节槽位。 Storage Trie 不是一棵全网共用树：每个账户都有自己的独立 storage trie， 空账户使用统一的空 Trie 根。

storageRoot(account) =
  MPT_ROOT({
    Keccak256(slot32)
      ↦ RLP(value)
    | value ≠ 0
  })

Mapping 为什么看起来“哈希了两次”？

这是两个不同层级。Solidity 先把高级语言变量映射到 EVM 的逻辑槽位； Storage Trie 再把这个 32 字节槽位哈希成树路径。

// balances 位于声明槽 p，查询 balances[user]
logicalSlot = Keccak256(pad32(user) || pad32(p))
triePath   = nibbles(Keccak256(bytes32(logicalSlot)))

为什么写入 0 常被称为“删除槽位”？

Storage 的默认值是 0。MPT 不必为默认值保存叶子，因此把某槽写回 0，会从 trie 中移除该 key。 读取不存在的槽仍返回 0；这也是“缺省值”和“显式存一个 0”在协议状态里不作区分的结果。

transactionsRoot =
  MPT_ROOT({
    RLP(transactionIndex)
      ↦ encodedTransaction
  })

三个精确点

1. key 是零基索引的 RLP。 index 0 → 0x80，index 1 → 0x01， index 128 → 0x8180。它不会再被 Keccak 哈希。
2. value 保留交易封装。 Legacy 交易为 RLP 列表；typed transaction 为 typeByte || payload。
3. 顺序本身被承诺。 只要交换两笔不同的编码交易，它们与 index 的 key/value 绑定就会改变， transactionsRoot 也会改变；若两个 value 逐字节完全相同，互换当然不可观察。

假设合约把 slot 1 从 640 写成 900。客户端不会重写所有账户和槽位； 它创建新的相关叶子与祖先节点，未受影响的节点可以继续复用。最终得到新的 storageRoot，再把它写入该账户记录，继而得到新的 stateRoot。

存在证明不是“给我一个值”

1. 你先拥有一个可信区块头，因而信任其中的 stateRoot。
2. 提供者给出账户值，以及从 root 到该 Leaf 的 RLP 节点序列。
3. 你计算地址的 Keccak 与 nibble 路径，从 root 逐步核对节点引用。
4. Leaf 剩余路径完全匹配，且 value 等于该账户 RLP，证明成立。

不存在也能证明

如果路径落到空 child，或遇到一个剩余路径不匹配的 Extension / Leaf， 这组节点同样可以证明该 key 在此根下不存在。MPT proof 因此不只是“一串兄弟哈希”： 它包含路径上的 RLP 节点，短节点还可能直接嵌在父节点里。

协议要求所有正确执行客户端对同一状态算出相同根，但不要求它们用同一种磁盘布局。 客户端可能采用 flat state、snapshot、缓存、path-based 存储或其他索引来加速读取； 只要最终 trie 承诺与执行结果满足规范即可。

三个 32 字节常量不要混

• 空 Trie 根：0x56e81f…63b421，即 Keccak256(RLP(""))。
• 空代码哈希：0xc5d246…85a470，即 Keccak256("")。
• 零值：storage 默认 0；它通常意味着该 key 根本不进入 Storage Trie。

2026 年 Ethereum Foundation 的协议优先级更新，把长期状态扩展方向写成 “a move to binary trees and statelessness”。这说明学习 MPT 时要区分两句话：

1. 现在如何验证主网执行状态？答案仍是当前十六叉 MPT 语义。
2. 未来状态结构可能怎样改？统一二叉树是草案方向，不是已经迁移的事实。

Trie

按 key 的符号序列逐步寻址的前缀树；名称来自 retrieval，不是拼错的 tree。

Patricia

Practical Algorithm To Retrieve Information Coded in Alphanumeric；在这里主要体现为共同路径压缩。

Merkle

父节点通过哈希引用子内容，使任意底层改变传导到根，并支持局部证明。

Nibble

4 bit 半字节，取值 0–15；十六进制恰好用 0–f 表示。

RLP

Recursive Length Prefix，以太坊执行层用于嵌套字节序列的规范序列化编码。

Root

32 字节密码学承诺；它绑定整棵 trie 的键、值与结构，但不包含可逆的全部数据。

Proof

从可信根到目标 key 的路径节点；可验证 inclusion，也可验证 non-inclusion。