在以太坊虚拟机里，一条 CALL 类指令执行前要先付一笔”基础调用费”：不论目标地址背后有没有合同、合同多大，先把账户从状态里加载进内存的费用预支掉。这笔钱的前世今生值得细说：2016 年秋天，为堵住靠反复冷调用耗磁盘的拒绝服务攻击，协议把加载合约的开销重新算了一遍，调用基础费从 40 一口气抬到 700。抬价逻辑对真合约完全成立——读代码确实贵。但对另一类地址不成立：编号最靠前的那一小段预编译地址，它们根本没有代码可加载，执行路径写死在客户端源码里。抬价之后，调用一条哈希原语和调用一个复杂合约，起步价居然一样。EIP-2046 要修的就是这笔误伤。
提案的精确形状
改动只碰静态调用这一条指令：当目标地址落在预编译地址范围内时，基础费按 40 计，其余地址维持 700 不变。为什么只改静态调用？因为它在语义上保证不写状态，而预编译本身也从不改状态，两层保险叠加，降费不引入任何新的重入或状态变更风险。为什么降到 40 而不是 0？作者的解释是保留一次虚拟机上下文切换的工本费——调用总得建栈帧、准备输入缓冲，40 就是这点劳力的价钱。提案明确反对归零，还特意对照了早先另一份主张把预编译费整体重定的提案，划清边界：那只动基础费，不动每条原语各自的运算价目。
谁受益谁吃亏
受益最明显的是依赖哈希与签名原语的高频合约：每笔交易里一次哈希省下六百多 Gas，聚合器、隐私协议、多重验证逻辑的固定开销直接削一截。吃亏方几乎不存在——降费只让已有执行更便宜，收据与状态毫无变化。唯一的冷幽默在兼容性一节：降费帮不到 Byzantium 之前部署的老合约，因为它们当年编译出的字节码用的是老式调用指令，根本走不到这条新路径。新代码才享受新价格，这在协议降费史上反复上演。
现状与边界
提案停在 Stagnant（停滞），以 EIP 官网当前标签为准。但问题本身并没有被遗忘：调用与预编译的定价此后被一系列重定价提案接力处理，“把不碰状态的操作与加载代码的开销分开计价”这条原则，最终在更系统的方案里成了共识。单看 EIP-2046 是一份没走完的工单，放回脉络里则是问题被确认的起点——它把”预编译凭什么交房租”这个问题第一次写进了协议议事录。
快速问答
问：预编译地址查代码为什么是空的？ 答：它们不是被部署出来的合同，节点执行到那个地址时直接调用内置函数，状态树里不存在对应代码。 问：700 这笔费用是转给谁的吗？ 答：不是收入。所有 Gas 费用都随执行被消耗，定价的全部意义是让每种操作的计算与存储成本在预算里如实体现。 问：普通用户能感觉到这种降费吗？ 答：单笔极小，但走这些原语的应用（聚合、隐私、批量验签）累计成本会明显下来。
一笔算术
一个每笔交易做两次哈希验证的应用，按原语运算价目不变、仅调用基础费从 700 降到 40 计，单次执行直接省下两倍六百六即一千三百二十 Gas；若该应用日理十万笔，一天就是约一亿三千二百万Gas的固定开销蒸发。数字本身不惊天动地，但它决定了一类”验证密集型”应用在当前定价下能不能活——协议重定价的价值往往不在于给谁省零头，而在于让原本不划算的构造重新划算。
风险提示：本文仅为Gas定价机制科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。