让EVM直接算正弦和自然对数:EIP-7543的小数运算设想 图 1
让EVM直接算正弦和自然对数:EIP-7543的小数运算设想 · 图 1

一条指令背后的数学账

今天的 EVM 只有整数运算。合约要算一个非整数幂——比如把年化波动率换算成日度,需要开十六次方根——要么查预计算的表,要么塞进大段牛顿迭代代码,每一步都烧 Gas 且必须全节点逐位复现。EIP-7543(2023 年 10 月创建,作者署名 1m1)提出直接给虚拟机加初等函数:DECADD、DECNEG、DECMUL、DECINV 管四则,DECEXP、DECLN、DECSIN 管指数、对数与正弦,理论上把幂、三角函数乃至微积分的积木全部备好。

为什么是十进制而不是二进制

提案的一个反直觉选择值得单独讲:数值用”系数乘十的幂”(c 乘 10 的 q 次方)表示,而不是像普通浮点数那样用二进制尾数。原因是像 0.1 这样的数在二进制下是无限循环的,有限位数永远存不准;而金融和科学计算里人类书写的数几乎都是十进制的。用十进制表示,0.1 就是字面意义的十分之一,配合 int256 级别的系数与指数,在允许的精度内每个值都被精确表达,不存在二进制浮点那种两位小数对不上的幽灵误差——这对要全网一致复现的智能合约尤其重要。

确定性怎么保证

虚拟机加数学函数最大的难点不是算法而是确定性:所有节点必须在每个输入上得到逐位相同的输出。提案的回答是自底向上的 Gas 精算——指数、对数、正弦用逐次逼近级数实现,算法对一切输入都收敛,迭代步数由调用方选择的精度决定,每一步的成本预先精确标进 Gas 表。跑得越准付得越多,但没有任何节点会陷入”算不完的循环”。这种把数值分析定价进燃料表的思路,是它区别于普通预编译提案的地方。

停摆的原因

截至本文核验,EIP-7543 状态为 Stagnant(搁置)。它的处境是典型的”技术可行、优先级不足”:EVM 指令空间紧张,每个新操作码都要永久占坑;数学库可以在协议外用合约和预编译试验(链上已有不少定点数与浮点库),先在生态里验证需求再下沉到虚拟机是更常见的路径;再加上精确 Gas 精算给客户端实现带来的长期维护负担。提案附带的 Black-Scholes 期权定价与神经元示例代码仍留在仓库里,作为”如果实现能做什么”的注脚。

为什么链上数学这么难做

普通程序算正弦调用系统数学库即可,智能合约不能:同一段库代码在不同机器上的浮点舍入行为可能不同,而以太坊要求一万个节点得到完全一致的结果,否则出块即分叉。所以链上数值计算的真正难点从来不是”会不会算”,而是”怎么保证所有人以相同步数、按相同顺序算出同一个数”。EIP-7543 的全部设计——十进制表示、逐次逼近、Gas 精算——都围绕这个一致性约束展开,也正因为成本集中在这,链上数学库才会长期停留在定点数近似加迭代近似的原始状态。

和预编译路线的对照

同类需求另一条实现路线是预编译合约——像 secp256r1 验签那样,把函数写进客户端原生代码。预编译快但每加一个都要全客户端实现一遍;操作码路线(本提案)把实现留给逐位收敛算法加燃料精算,客户端不需要新数学代码。两条路线在”新数学函数进协议”这条路上的竞争还会继续,读到任何一条扩容或功能提案时,先分清它走的是哪条路。

快速问答

问:链上现在完全算不了小数吗? 答:能用定点数近似(比如放大一万倍记账),但复杂函数要靠库代码,精度和 Gas 都受约束。

问:为什么不先用合约库实现就好? 答:生态里确实有定点数与浮点库,但每个项目重复实现、质量参差;本提案赌的是全网统一实现更划算,这条路线之争正是它停摆的原因之一。

风险提示

本文为技术科普,不构成投资建议。DeFi 定价与衍生品计算涉及复杂风险,请勿以科普内容作为任何交易依据。