以太坊给交易数据定价的思路近年在补漏：已随 Pectra 定稿的 EIP-7623 为 calldata 设立了「地板费」——按数据字节折算 token 数、每 token 至少贡献 10 gas，防止有人靠复杂执行套利把海量数据塞进一个块。但数据的入口不止 calldata 一扇门。EIP-2930 引入的访问列表（type-1 交易里的地址与存储键清单）同样占交易的字节数，却只按「存储访问」计价：一个地址 2400 gas、一个存储键 1900 gas，账面是执行侧的定价，不进数据地板的账。EIP-7981 要补的就是这块：让访问列表按自身的数据足迹也付一份地板级的钱。提案 2024 年 12 月 27 日创建，现处于 Review 状态，并被列进 EIP-7773 里 Glamsterdam 升级的排期名单。
绕开地板的那道算术
现行 7623 的规则是：交易无论执行多简单，calldata 每个零字节至少贡献 10 gas、每个非零字节至少贡献 40 gas 的地板（即每 token 10 gas）。而 2930 的列表项计价名义上是「预热」费用——一个键 1900 gas，看起来比地板贵得多，但关键在于计价对象：列表项贡献的 gas 记在「执行 gas」一侧，列表占用的字节却几乎不进「blob 等价的数据字节账」。于是把 calldata 和访问列表按某个比例混搭，就能用更少的数据字节撑起同样多的 gas——极端构造者由此把最坏情况下的区块体积推回天花板之上。7981 的堵法很直接：先按列表的字节数收一笔地板等价费——每字节 64 gas（20 字节的地址折 1280、32 字节的键折 2048，正好等于 64 乘字节数的规则化表达），再照旧叠加 2930 的执行侧定价。这样列表项永远至少付到地板价，混搭套利失去意义。
一笔直觉账
提案动机段给了体量：按这一规则，最坏情况区块体积可减少约两成。换算到日常可见的层面，它不改变你转 ERC-20 代币的费用——普通转账根本不带访问列表；它改变的是索引器、批量读取工具一类重度用列表省钱的操作：列表越写越长，新增的那份数据费就从「几乎白占字节」变成按字节收钱。对普通用户，这更像一次围栏加固：堵门的成本由构造巨型块的人付，网络最坏体积被压小，全节点同步与验证的账本更稳。
和 7976 是一对连体提案
7981 的 requires 字段列着 2930、7623 与 7976。7976 把 calldata 的地板单价从 16 提到 64 gas/字节，7981 则把列表数据对齐到同一个 64 的系数——两者都进了 Glamsterdam 的排期名单，且配套生效才有意义：只提 calldata 不给列表补账，套利比例只是变小而非消失。顺带澄清一个易混点：这里的 64 gas 是「每个列表字节的最低贡献」，而 2930 的 2400/1900 仍然作为预热执行费保留，两条并不互斥——列表项从「按地址/键数收费」变成「按字节收费加上执行费」，总账变贵，但语义不变。
状态与边界
截至本文写作，7981 是 Review 状态的 Core 提案，在 EIP-7773 的名单里挂着 Scheduled for Inclusion——排期，不等于已激活：Glamsterdam 的主网激活时间在 meta 文件里仍是空白行。判断相关交易费用的说法时守住这条线：现行主网的访问列表定价仍是 2930 的 2400/1900（叠加 7623 的地板规则），「列表按字节收 64」属于待生效方案。参数（如每字节单价）在提案期间仍可能随审查调整，以提案仓库文本为准。
一条观察线
价格类提案有个共同的验证套路：先看它对哪类地址生效。7981 的答案是「构造交易数据的程序」——批量节点、索引服务、自动化脚本，它们是访问列表的最大用户；而散户钱包发出的九成交易列表为空，一个字节都不会多付。用这条线还能读出提案的排序逻辑：先抬 calldata 地板（7976），再堵列表旁门（7981），最后才轮到状态创建费等更贵的刀（8037）。顺序本身说明了优先级：协议宁可让数据搬运变贵，也不愿让验证成本继续社会化。读者每次看到「以太坊又涨价了」的标题，都可以先查它改的是哪一格价目表，再决定这与自己有几毛钱的真实关系。
快速问答
问：普通用户的手续费会因此上涨吗？ 答：不带访问列表的交易不受影响；重度使用列表的工具交易成本上升，但这是它堵漏设计的目的。
问：它和 blob 的定价有什么关系？ 答：同一套「数据按最窄口径记账」的哲学。calldata 与列表是执行层的两类数据入口，blob 是二层数据的入口，三条账各自有各自的地板。
问：现在能用 7981 的算法预估 gas 吗？ 答：不能用于现行主网。它未激活，预估只适用于理解方向；实际费用仍以当前节点价目为准。
风险提示
本文为机制解读，不构成投资建议或交易定价承诺。协议参数以官方提案与客户端文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。