2021 年柏林升级起，以太坊交易家族多了一个成员：带访问列表的类型一交易（EIP-2930，Final），签名者可以在发送前声明“我这笔操作会碰哪些地址和存储槽”。当时还出现过一个更大胆的孪生想法 EIP-3584：既然单笔交易能声明访问列表，为什么不让整个区块汇总出一份“区块访问列表”，把指纹放进区块头？3584 停留在 Stagnant 状态，从未生效。但要读懂它，得先把已经生效的那一半机制讲明白——这一半直接影响你今天交易的 Gas 账单。
冷热访问：访问列表的经济学基础
EIP-2929 给存储访问定了两档价：第一次碰某个地址或存储槽按“冷访问”计高价，同一交易内再次访问按“暖访问”计低价。逻辑很朴素——节点第一次加载某个状态时要付出真实的读取成本，重复使用则近乎免费。访问列表交易在此基础上做了一步前移：发送方提前把预计要碰的地址与存储槽清单写进交易，节点得以在并行执行前先批量预载这些状态，把冷启动的等待挪到执行之前。清单里声明项的首次访问享受折扣价，没声明而实际碰到的位置照旧付冷价，于是诚实声明有甜头、漏声明只回到基准线，不惩罚失误到不可用。想看清这类字段在交易信封里的位置，可以对照 一串交易十六进制怎么读：类型字节、字段顺序与签名尾巴的位置 对类型字节与字段顺序的拆解。
3584 想把这件事做成区块级
EIP-3584 的观察是：执行过程中的首次访问本来就会被客户端记录，交易自带的访问列表只是其中一部分来源。那就把整个区块里所有交易的首次访问汇总成一份区块级访问列表，生成一个名为 AccessListRoot 的指纹放进区块头作为防作恶承诺。按提案的编码，这个指纹形如 urn:sha256:json: 前缀加访问列表 JSON 序列化后的 SHA-256 十六进制值，固定表现为 32 字节的根，验证节点可以据此校验自己重建的列表是否与他人一致。设想中的收益：验证者拿到列表后可提前预载整个区块的状态，把跨交易的冷访问等待从关键路径上搬走；同时区块头里的承诺让“少报列表”变得可检测。它没有走远的同样值得记：状态预载是执行优化问题，塞进共识层会增加每个节点的一致性与实现负担，收益却主要归性能敏感的角色，这种“共识买单、执行受益”的分配失衡是此类提案的常见死因；后续相关研究选择了不动区块头的路线。
用户能观察到的三处痕迹
第一，Gas 用量：同一合约逻辑，构造得当的访问列表交易与不带列表的类型二交易在不同客户端、不同并行度下会出现可测差异，做批量或高频交互时值得实测比较，而不是想当然。第二，收据与浏览器：访问列表本身不改变事件日志，收据里的 topics 与 data 仍是你在浏览器反查交互的主线索；列表只影响执行期 Gas 与效率。第三，构造入口：普通钱包默认发不带列表的交易，访问列表主要出现在需要精细调Gas的批量场景；如果你用的工具声称“自动优化访问列表”，可以导出原始交易十六进制检查它到底填了什么——类型字节 0x01 的信封里 access_list 字段是否非空，肉眼即可核对。
常见误判与操作提醒
误判一：把访问列表当授权——它只是性能元数据，声明了某地址不等于你授予任何人权限，也不改变调用语义。误判二：以为列表越全越省——每个声明项本身占交易数据字节、要付数据费，为没碰到的位置付声明费反而亏；诚实且精准才是最优解。误判三：把 3584 的“区块头指纹”当作已存在字段去查区块浏览器——它从未生效，查不到是正常的，遇到声称支持“区块访问列表”的产品要按前述方法核实现。风险提示同所有 Gas 优化话题：省费手段的净收益要拿同口径账单实测，两笔金额差在噪声范围内时不值得增加签名复杂度。
小结
访问列表是“提前交作业换折扣”的机制：2930 让单笔交易受益，3584 想让整块受益却被停在半途。对普通用户，机制的存在感很低，但在核对 Gas 异常、审阅批量工具构造的交易时，它会以“信封里多了一个列表字段”的形式现身——认得它，比记住它的十六进制位置更重要。本文内容为机制科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。