以太坊正在尝试一类新的节点：它不保存完整状态，只扛一小片状态分区，靠区块随附的访问清单补齐缺的那部分。这类节点的前提是访问清单必须自证清白。EIP-7928给清单设计了每槽位的改动前后值，看似完备，却被一个沉默的缺口卡住：清单里没有被改账户自己的存储树根。草案EIP-8268的补丁因此很小——给每个记录改动的条目挂上区块后的存储默克尔根——补的却正是部分状态节点最后一段信任链。
清单已经有什么
EIP-7928设想每个区块随区块头发布一份访问清单：哪些账户被读写、哪些存储槽被改写、改动后的值是什么。部分状态节点拿到清单，只需比对本地那部分与清单中的改动，就能确认自己持有的片段与全局一致。问题出现在它不持有的账户上。要证明一个区块算出的状态根是对的，节点需要重建这棵树最顶层的哈希；而顶层哈希依赖每个被改账户的存储子树根。清单给了每个槽位的新值，却没给子树的根，一个没存过某账户存储槽的节点就只能二选一：要么去别处补整棵存储树，要么选择信任别人算出的状态根。两种选择都把部分状态节点的自给自足打破了。
多带一个字段换什么
EIP-8268的做法直白：扩展EIP-7928，在每个条目里附带对应账户的区块后存储根。节点核对三步走：用清单里该账户的槽位改动，在本地构造或验证子树根；比对条目附带的存储根；再沿账户树往上拼出状态根。每一步都在自己手里完成，无需向任何第三方要证明。
代价是清单变胖，尤其对改动存储槽多的区块——每个被触及账户多一笔三十二字节的根。提案用改动条目粒度控制膨胀，只给确实记录了状态修改的账户挂根，单纯读取不额外增加字段。理由段强调，这换来的是部分状态节点不必为了验证而偷偷扩张存储边界，否则分区只是纸面上的。
这份草案还在早期评审。它背后是一整条无状态路线，从状态分片到访问清单到本提案，每一步都把节点负担与清单体积放在天平两端反复掂量。
快速问答
问：现在的节点会被这条提案影响吗？ 答：全节点逻辑不变，清单只是附加数据；受益方是打算只保存部分状态的实验节点。
问：为什么不直接改用状态树快照同步？ 答：同步只是搬运状态的另一种方式，并不能减少节点需要保管的数据量。让节点少存数据的路线，靠的是区块自带可验证的改动记录。
问：访问清单由谁产生？ 答：由执行区块的构建者随区块产出，验证者在收到区块时按规则校验其完整性；具体流程以协议当前方案为准。
一条依赖链的位置
把它放回全景里看层次更清楚：第一层是状态如何分区存放，让节点合法地只存一部分；第二层是区块携带访问清单，让不存的那部分可以随区块补齐；第三层才是本提案——补齐了值却没补齐结构承诺时的最后一块拼图。三层各自都有人在推进，任何一层延期都会让其他两层的效果打折，所以这类小提案的进度往往是整条路线健康度的温度计。清单每字节的体积、网络每区块多广播的那点根数据，都会在其他提案的讨论里被反复清算，属于典型的集体工程而非个人英雄叙事。
一笔直觉账
部分状态节点像只看自家账页的会计。清单给了所有改动的流水条目，却没给每页末尾的小计；对账时缺了小计的那页，仍要回去翻原账。补上小计那栏，账页才真正可独立复核。
风险提示：本文内容为协议机制科普，不构成任何投资建议；提案参数与状态以官方规格为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。