EVM要开64位模式？EIP-7937的多字节指令设计

256位引擎上的小算术

EVM 的每个栈元素都是 256 位宽，加法、比较、位运算都按 256 位执行。但环顾真实合约：计数器是 uint64，代币余额常用不到 128 位，时间戳和区块号只有 64 位。让虚拟机为一次 64 位加法搬动四个 64 位字的机器宽度，就像开卡车递一封信——不是不能做，而是每天都做就太浪费。EIP-7937（2025 年 4 月创建，作者 Wei Tang）的设问是：既然虚拟机是虚拟的，为什么不直接加一条”64 位模式”？

多字节前缀：不挤占指令空间

EVM 单字节指令空间只剩零星空位，塞不进几十个新运算。提案的方案是给所有新指令共享一个前缀字节 C0，后面的第二字节决定具体操作：C001 到 C00B 是 64 位算术（加减乘除取模等），C010 到 C015 是比较，C016 到 C019 是位运算，C056 和 C057 是跳转类流控。前缀设计让 256 位模式的一切保持原样，旧字节码一字不改照常执行；只有编译器主动发射 C0 序列时才进入新通道。这与 1980 年代处理器给新指令加前缀的做法一脉相承——虚拟机的优势正在于，这样的实验没有硬件成本。

姊妹提案：字节序的另一半

主提案定义了 64 位运算但沿用大端约定，EIP-7958（2025 年 5 月）补上另一半：定义字节序相关的 64 位指令——BYTE64、MLOAD64、MSTORE64 与 PUSH2_64 到 PUSH8_64——按小端读写。小端是主流 CPU 与多数序列化格式的自然顺序，让 EVM64 模式与外部世界交换字节时不再需要逐字翻转。两份提案配套，另有一份 EIP-7957 处理 64 位模式与 EOF 容器格式的衔接，可见这是一整套小型 ISA 扩展，而非孤立实验。

收益与代价

收益端：客户端可以把 64 位模式映射到机器原生字运算，同样的合约逻辑用更少燃料或更快执行；Solidity 与 Vyper 等编译器能自动识别窄类型发射短指令。代价端：两套语义并存会加倍形式化验证与差分测试的面积；gas 表要为每条 C0 指令重新标定；调试器、反编译器、安全工具链全要认新序列。更根本的质疑是——这类微优化是不是应该留在客户端实现层，由各家引擎自行 JIT，而不必写进共识规则。

编译器会怎么用这套指令

设想 Solidity 编译一行把两个 64 位整数相加的代码：今天它发射 256 位的加法指令，引擎按四个机器字做带进位加法；有了 64 位模式，编译器可以直接发射一条 C0 前缀的窄加法，客户端映射到单条机器指令。真正吃红利的是循环密集的库代码——位图、打包的小整数数组、Merkle 索引计算，这些场景的操作数大多远窄于 256 位，却一直在为宽度付燃料。编译器团队的现实顾虑是正确性证明：两套指令意味着形式化语义要维护两份映射，任何一条窄指令的进位、溢出、符号规则出偏差，都是共识级事故。