单指令多数据，简称SIMD，是现代处理器的标配：一条指令喂给一整排数据车道，加法做一次、八个结果出八份。EVM的栈单元天生256位宽——三十二个字节——比很多老式向量寄存器还宽，于是有人动了念头：为什么不把这32字节切成车道，让虚拟机也并行算？这就是Greg Colvin在2017年4月写的EIP-616，标题直接叫“给EVM的SIMD运算”，状态停在Stagnant。它是一段没走完的路，但问题本身至今有效：字节码层的加密运算怎么跑快。
双字节指令：操作码后面挂一张类型说明
提案的编码方案干净得近乎讨喜：新指令用两个字节表示，第一字节是操作码，第二字节是SIMD类型说明书。这个类型字节内部再切三段：一位标量类型，零是无符号整数、一表示三十二位或六十四位的IEEE浮点车道；两位存车道字节数的对数，于是车道宽度从八位到六十四位可选；三位存车道数量的对数，从两车道到三十二车道。组合起来，一个字节就能说清“这是一条把256位数劈成八段三十二位整数”的指令，而类型值为某个特定字节的场合保留给普通256位整数——车道数为一的时候，SIMD指令自动退化回标量运算，提案特意用斜体强调这一点：单个标量也用同一套编码，不必另加指令。
提案引用的加速数字
动机部分抄了一圈文献里的加速比：SHA-512最高七倍、椭圆曲线标量乘法四倍、BLAKE2b三到四倍、OpenSSL部分场景两到三倍、椭圆曲线模乘两倍上下、SHA-256约一点七到一点九倍、RSA加密约一点三倍。这些数字来自Intel、学术论文集和各项目自己的基准页，描述的都是在原生CPU上用SIMD重写后的收益。提案的逻辑是把这些收益搬进字节码：EVM栈单元已经是一条现成的宽寄存器，指令劈成车道后，字节码里循环做模加的哈希函数，理论上能一步走完原来八步。
它为什么停在半路
提案没走完的路，后来被两条别的车道超车。第一条是预编译合约：与其教字节码并行，不如把SHA-256、配对验证这类热点运算整个搬出EVM，交给客户端用原生代码实现，Gas按公式一口价。哈希和曲线的性能之争在预编译名单上不断加长，字节码层并行化的需求空间被持续压缩。第二条是可行性本身：给主网虚拟机加一整套双字节指令，牵动Gas计量、每客户端实现、已部署字节码的兼容性审计，而受益面——在合约里手写向量友好算法的场景——始终没长出来。提案自己在浮点车道上也留了余地，明确说浮点运算不建议进首批。一个优雅的设计在“收益不确定加改动面巨大”面前止步，是协议提案最常见的死法，Stagnant状态只是给这种死法盖的章。
同一场竞赛的两条赛道
把两种提速思路摆在一起最见分晓。预编译像连锁店中央厨房：菜单上少数几道菜集中做，出品稳定、计费简单，代价是菜单由协议定，每加一道菜要走一轮提案。SIMD指令像给每家厨房配商用灶具：任何菜都能借火力，菜谱自由，代价是每家的灶都要验收、燃气表全换。以太坊把资源投给了前者，SHA-256、RIPEMD、配对运算一道道进中央厨房；字节码层则沿着另一条线演化——为字节码整体加结构化容器与函数机制的那条工程线，同样在2019年前后开始反复提案，两条线至今都没合流。
快速问答
问：EVM现在有没有任何并行运算？ 答：常规指令是逐条执行的；并行性集中在预编译的原生实现和客户端进程层面的交易并行调度里，不是字节码车道。 问：提案的浮点车道后来有机会吗？ 答：浮点语义一致性在跨实现共识环境里格外棘手，提案自己也把浮点排除在首批之外，这条支线基本没有再往前走。 问：Stagnant会被正式废掉吗？ 答：状态词表里废弃是单独选项；长期无活动的提案通常就停在Stagnant，不代表被否决，只代表无人续跑。
风险提示：本文回顾技术提案史，不构成任何投资建议，也不涉及任何资产的买卖时机判断。指令与Gas机制以EVM规范与EIP原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。