无状态执行的核心难题是凭证体积：一笔交易要附带着证明”执行碰到的数据确实如此”，谁带的东西多谁就是瓶颈。在以太坊的状态结构里，账户代码长期以来是一整块打包进凭证的——合约执行哪怕只读了三行指令，整段代码也得完整随车。EIP-2926 给这件事开出的处方是切片：把代码按固定长度的块切开、逐块哈希建树，执行时只取被触碰的块。
切分的规则
方案给出的常量很具体：页大小取三十一字节，每页头部再放一个”第一指令偏移”字节。这个偏移解决的是一个狡猾的边界问题——变长指令可以横跨页界，比如一条压栈指令的操作数尾巴被切到了下一页，只看本页的验证者可能把数据字节误读成指令。偏移字段告诉分析器：本页从第几个字节起才是下一条指令的合法起点，跨页的多字节指令因此能被安全处理。页键用四字节的序号编码，空页之外每页还带一个版本键；账户结构上给代码大小与代码根两个新字段，同时保留老的代码哈希字段去喂需要它的操作码，杂账地址则省略这些字段、控制开销。
三十一字节为什么不是更大或更小
rationale 一节把权衡摆得很直白：页越小，代码利用率越高但哈希证明越多（树更深）；页越大反之。三十一是当时推荐的折中，并明说后续要靠实验比较各种尺寸定稿。作者还评审过一整套替代切法——按基本块切、按子程序切、每页加长度前缀并保证指令不跨页——逐一给了否决理由：不跨页方案要三十三字节才装得下一条满格压栈指令，还会制造大量只装半条指令的浪费页，数页数都变得不易。
迁移是另一场硬仗
存量合约怎么换结构？方案设想类似历史树迁移的做法：分叉后由客户端在后台逐步把所有代码切块建树，用一个待定的迭代步幅推进。原因很现实——全网代码体量以十吉字节计，任何”分叉瞬间全部重排”的写法都过不了工程关。代码字节价则计划从每字节二百涨到五百，补上切块与建树的开销，这个数字继承自无状态Gas提案以保持向前兼容。
现状与边界
提案处于 Draft（草案）状态，2020 年 8 月起挂在那里，以 EIP 官网当前标签为准。它依赖无状态Gas定价等前置工作，路线图上始终排在状态树本体改造之后——先换树、再动代码存储，顺序在文中反复被引用。
一次读取的完整旅程
顺着一次冷合约调用走一遍就能看到切块前的浪费：虚拟机要执行某函数，取指令时把整段代码连同默克尔证明一起装进凭证；同块里若另一个交易也碰它，凭证还得再来一份。切块之后，被触碰的页随凭证同行，没碰的页连哈希都省了；同一块内重复触碰还能共享已加载的页。对以小额调用为主的应用——读取一个配置常量、调用一个代理转发——凭证体积的下降幅度最直观。
快速问答
问：这会让普通交易变贵吗？ 答：凭证变小让网络受益，代价主要落在合约部署与冷代码读取环节，读写价目会重新平衡。 问：为什么代码和无状态的先后绑在一起？ 答：哈希部分先靠树形改造降三倍，代码才会变成第一大负担，届时切块收益才最大——顺序错就是白忙。 问：页内的数据区会被误执行吗？ 答：偏移字节加只取被触页的规则，使分析器在没有全量代码时也能拒绝跳到数据区。
一条判断线
所有”把大对象切小块”的方案都在同一条轴上找点：切得越细，按需取用越省、元数据越多。判断好坏别看口号，看它有没有给出可实验的参数和迁移路径，二者齐备才配叫工程方案。
风险提示：本文仅为协议数据结构科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。