EIP-196 深度解析以太坊 alt_bn128 椭圆曲线加法与标量乘法预编译合约【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕 EIP-196EIPS/eip-196.md 展开系统讲解以太坊拜占庭Byzantium硬分叉引入的 alt_bn128 椭圆曲线点加法ADD地址0x6与标量乘法MUL地址0x7预编译合约从曲线参数、输入编码、精确执行语义到 gas 成本与设计取舍并结合仓库中 EIP-197、EIP-1108、EIP-1109、EIP-1962 等关联提案讲清这些原语如何支撑链上 zkSNARK 验证。读完本文你将掌握这两个预编译合约的调用规范、边界行为与 gas 定价逻辑并能理解它为何是隐私与扩容类应用的基础设施。背景为什么需要在区块 gas 限制内做椭圆曲线运算以太坊智能合约的执行过程是完全公开透明的任何调用输入、状态变更都对全网可见。这种透明性使以太坊不适合承载位置、身份、历史交易等敏感信息相关的用例。zkSNARK零知识简洁非交互式知识论证正是解决这一问题的关键技术它既能保护隐私Zero-Knowledge 属性又因其证明的简洁性与高效可验证性succinctness and efficient verifiability而可能成为扩容方案。虽然 EVM 理论上可以执行 zkSNARK 验证逻辑但纯 Solidity 实现的椭圆曲线点运算与配对函数开销过大无法在区块 gas 限制内完成验证。EIP-196 的解决方案是把几个最基础的椭圆曲线原语以**预编译合约precompiled contract**的形式固化到协议层让客户端用原生代码C/Rust/Go 等高效执行从而把 gas 成本降到可接受范围。值得注意的是EIP-196 刻意只固定了加法与标量乘法这类基础原语。文档明确指出虽然固定参数看似限制了 zkSNARK 的用例但由于这些原语足够基础、组合方式足够灵活未来 zkSNARK 研究的进展甚至可以在不需要再次硬分叉的情况下被纳入。规范激活条件、合约地址与曲线参数EIP-196 的激活条件与地址定义非常简洁激活条件当block.number BYZANTIUM_FORK_BLKNUM时生效即随拜占庭硬分叉引入点加法ADD地址0x6标量乘法MUL地址0x7。两个预编译合约运行在名为alt_bn128的椭圆曲线上曲线方程与域参数为Y^2 X^3 3 over the field F_p with p 21888242871839275222246405745257275088696311157297823662689037894645226208583alt_bn128 属于 BN 曲线族是**配对联友好pairing-friendly**曲线它存在高效的配对函数实现这正是 zkSNARK 验证的核心构件。选择该曲线的另一个重要原因是与 ZCash 形成协同效应——可以直接复用 ZCash 生态中已经成熟、经过实战检验的组件与工件如 libff、bn 等密码学库大幅降低实现风险。编码规范32 字节大端与补零/截断语义EIP-196 对输入输出的编码做了严格定义理解这套规则是正确调用预编译合约的前提域元素与标量均编码为32 字节大端序big-endian数字曲线点由两个域元素(x, y)组成无穷远点point at infinity编码为(0, 0)元组拼接多个对象的元组按顺序直接拼接concatenation编码无分隔符。输入长度处理遵循与 EVMCALLDATALOAD操作码一致的语义输入过短末尾视为虚拟补零virtually padded with zeros即缺失部分按零补齐输入过长末尾多余字节被忽略返回数据长度固定返回值始终是规范规定的长度不会做去填充unpadded处理。也就是说ADD 合约的输入固定为 4 个域元素两个点(x1, y1, x2, y2)共 128 字节MUL 合约的输入固定为 3 个域元素点(x, y)加标量s共 96 字节但调用方可以传入不足或超长的 calldata由预编译合约按上述规则容错处理。精确执行语义无效输入与失败行为EIP-196 对两个合约的无效输入定义完全一致任一输入点不在曲线上不满足Y^2 X^3 3任一点坐标域元素大于等于域模数 p。满足以上任一条件即视为无效输入合约调用失败并消耗调用所提供的全部 gas。作为对照标量本身没有上限约束可以是0到2**256 - 1之间的任意整数——这是 EIP-196 一个容易被忽视的设计点它允许标量超出群阶甚至域阶详见后文测试用例。ADD地址 0x6椭圆曲线点加法输入两个曲线点(x, y)输出曲线点x y其中是上文 alt_bn128 曲线上的标准点加法失败条件无效输入时失败并消耗全部 gas。MUL地址 0x7椭圆曲线标量乘法输入曲线点与标量(x, s)输出曲线点s * x其中*是上文 alt_bn128 曲线上的标量乘法即x自加s次失败条件无效输入时失败并消耗全部 gas。两个合约对失败行为都是all-or-nothing要么成功返回正确结果要么耗尽调用提供的 gas从而保证调用方可以安全地依赖失败状态。Gas 成本与后续调整EIP-196 规定的初始 gas 成本为操作地址Gas 成本ECADD0x6500ECMUL0x740000这一成本在后续提案中被显著下调。EIP-1108EIPS/eip-1108.md 基于 2018 年客户端密码学库的性能飞跃Go 参考实现 go-ethereum 迁移到 Cloudflare 的 bn256 库、Parity 客户端优化 bn 库的域运算与配对算法重新定价合约地址EIP-196 原成本EIP-1108 新成本ECADD0x06500150ECMUL0x0740 0006 000Pairing check0x0880 000 * k 100 00034 000 * k 45 000EIP-1108 的定价方法是以ecrecover预编译116 微秒、3000 gas为基准折算约 25.86 gas/微秒再按 Parity 客户端性能较弱者的实测耗时给出公式。另外EIP-1109EIPS/eip-1109.md 指出每次CALL操作码本身会额外消耗 700 gas这使得有效成本低于 700 的预编译合约无法发挥价值因此提出独立的PRECOMPILEDCALL操作码0xfb以剥离 CALL 开销——该提案以 ECADD 500 gas 为示例论据目前状态为 Stagnant。设计取舍Rationale分析EIP-196 的 Rationale 部分记录了几个关键设计决策及其理由为什么选 alt_bn128该曲线特别适合 zkSNARK尤其是其验证核心构件——配对函数且可与 ZCash 复用组件与工件形成协同效应。为什么拒绝把曲线/域参数放入输入设计时曾考虑允许调用方在输入中指定曲线与域参数但最终被否决。理由有二其一gas 成本将极难确定不同曲线运算耗时差异巨大其二调用方可能传入并非真正的椭圆曲线的参数破坏安全性。固定参数换来了可预测的 gas 与更简单的规范。为什么采用非紧凑non-compact点编码(x, y)全坐标编码虽然在带宽上不如压缩编码但有两个实际好处合约自身仍可直接对坐标执行一些运算保留了完整的 y 坐标两个编码后的点可以直接比较相等性不需要第三个射影坐标。向后兼容性考量与任何预编译合约的引入一样已经使用地址0x6、0x7的既有合约将改变其语义——此前这两个地址上的调用行为通常是空调用或未知地址调用会被替换为预编译合约逻辑。为降低风险EIP-196 特意选取了256 以下的保留区间reserved range内的地址避免与常规合约部署地址冲突。官方测试用例清单EIP-196 给出了六类必须覆盖的测试输入用于验证实现与规范的严格一致性模 p 后才有效的曲线点坐标在模 p 意义下成立、但原始数值大于等于 p 的点——必须失败对应域元素 p 即无效规则空输入两个合约在空输入上必须成功补零语义下空输入等价于无穷远点等合法输入截断输入截断后恰好构成合法曲线点的输入——必须成功不在曲线上的点数值合法但方程不成立的点——必须失败标量位于群阶与域阶之间乘以这样的标量——必须成功标量无上限约束的直接验证标量大于域阶乘以更大的标量——同样必须成功。这些用例精确刻画了编码合法性与标量自由性的分界线是实现者回归测试的最低要求。与 EIP-197 组合链上 zkSNARK 验证EIP-196 的价值必须通过与 EIP-197EIPS/eip-197.md 的组合才能完整显现。EIP-197 在地址0x8增加alt_bn128 最优 ate 配对检查pairing check预编译合约其定义为输入(a1, b1, ..., ak, bk)来自(G1 × G2)^k当且仅当离散对数方程log_P1(a1) * log_P2(b1) ... log_P1(ak) * log_P2(bk) 0 (in F_q)成立时返回 1否则返回 0其中G1的生成元为P1 (1, 2)群阶q 21888242871839275222246405745257275088548364400416034343698204186575808495617与 EIP-196 使用同一个域 p。EIP-197 的 gas 成本为80 000 * k 100 000k 为输入长度除以 192即配对组数。从实现原理看该检查可借助配对函数e的双线性性质高效完成验证e(a1,b1) * ... * e(ak,bk) 1是否成立。将 EIP-196 的 ADD/MUL 与 EIP-197 的配对检查配合即可在以太坊合约中完成 zkSNARK 证明的完整链上验证——这构成了隐私交易、Rollup 类 L2 扩容方案等大量应用的共同底座。实现参考与仓库脉络EIP-196 的原文提供了三种参考实现libffCZCash 生态、zcash 的 bn 库Rust以及 ethereum 的 py_pairingPython文档评价其最自包含、可读性最佳。三套代码都使用 alt_bn128 曲线上名为G1的具体群。由于这些基础运算已固化进主流客户端如 go-ethereum 的 bn256 实现合约开发者通常无需自行实现直接按本文规范调用0x6/0x7即可。在本仓库中与 EIP-196 直接相关的提案形成了清晰的演进脉络EIP-197配对检查与之互补、EIP-1108降低 gas 成本、EIP-1109预编译调用开销优化Stagnant、EIP-1962提出可完整替代0x06/0x07/0x08的统一椭圆曲线运算预编译。阅读这些提案可以完整追溯 alt_bn128 预编译从拜占庭引入到成本优化的全过程。小结EIP-196 以两个高度聚焦的预编译合约0x6ADD、0x7MUL为以太坊注入了高效的 alt_bn128 椭圆曲线点运算能力并以严格的编码规范、明确的无效输入语义和可预测的 gas 定价ECADD 500、ECMUL 40000后由 EIP-1108 下调至 150/6000保障了可用性与安全性。它与 EIP-197 的配对检查共同构成链上 zkSNARK 验证的基础设施是理解以太坊隐私与扩容技术栈时不可绕过的协议级知识点。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-196 深度解析：以太坊 alt_bn128 椭圆曲线加法与标量乘法预编译合约
EIP-196 深度解析以太坊 alt_bn128 椭圆曲线加法与标量乘法预编译合约【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕 EIP-196EIPS/eip-196.md 展开系统讲解以太坊拜占庭Byzantium硬分叉引入的 alt_bn128 椭圆曲线点加法ADD地址0x6与标量乘法MUL地址0x7预编译合约从曲线参数、输入编码、精确执行语义到 gas 成本与设计取舍并结合仓库中 EIP-197、EIP-1108、EIP-1109、EIP-1962 等关联提案讲清这些原语如何支撑链上 zkSNARK 验证。读完本文你将掌握这两个预编译合约的调用规范、边界行为与 gas 定价逻辑并能理解它为何是隐私与扩容类应用的基础设施。背景为什么需要在区块 gas 限制内做椭圆曲线运算以太坊智能合约的执行过程是完全公开透明的任何调用输入、状态变更都对全网可见。这种透明性使以太坊不适合承载位置、身份、历史交易等敏感信息相关的用例。zkSNARK零知识简洁非交互式知识论证正是解决这一问题的关键技术它既能保护隐私Zero-Knowledge 属性又因其证明的简洁性与高效可验证性succinctness and efficient verifiability而可能成为扩容方案。虽然 EVM 理论上可以执行 zkSNARK 验证逻辑但纯 Solidity 实现的椭圆曲线点运算与配对函数开销过大无法在区块 gas 限制内完成验证。EIP-196 的解决方案是把几个最基础的椭圆曲线原语以**预编译合约precompiled contract**的形式固化到协议层让客户端用原生代码C/Rust/Go 等高效执行从而把 gas 成本降到可接受范围。值得注意的是EIP-196 刻意只固定了加法与标量乘法这类基础原语。文档明确指出虽然固定参数看似限制了 zkSNARK 的用例但由于这些原语足够基础、组合方式足够灵活未来 zkSNARK 研究的进展甚至可以在不需要再次硬分叉的情况下被纳入。规范激活条件、合约地址与曲线参数EIP-196 的激活条件与地址定义非常简洁激活条件当block.number BYZANTIUM_FORK_BLKNUM时生效即随拜占庭硬分叉引入点加法ADD地址0x6标量乘法MUL地址0x7。两个预编译合约运行在名为alt_bn128的椭圆曲线上曲线方程与域参数为Y^2 X^3 3 over the field F_p with p 21888242871839275222246405745257275088696311157297823662689037894645226208583alt_bn128 属于 BN 曲线族是**配对联友好pairing-friendly**曲线它存在高效的配对函数实现这正是 zkSNARK 验证的核心构件。选择该曲线的另一个重要原因是与 ZCash 形成协同效应——可以直接复用 ZCash 生态中已经成熟、经过实战检验的组件与工件如 libff、bn 等密码学库大幅降低实现风险。编码规范32 字节大端与补零/截断语义EIP-196 对输入输出的编码做了严格定义理解这套规则是正确调用预编译合约的前提域元素与标量均编码为32 字节大端序big-endian数字曲线点由两个域元素(x, y)组成无穷远点point at infinity编码为(0, 0)元组拼接多个对象的元组按顺序直接拼接concatenation编码无分隔符。输入长度处理遵循与 EVMCALLDATALOAD操作码一致的语义输入过短末尾视为虚拟补零virtually padded with zeros即缺失部分按零补齐输入过长末尾多余字节被忽略返回数据长度固定返回值始终是规范规定的长度不会做去填充unpadded处理。也就是说ADD 合约的输入固定为 4 个域元素两个点(x1, y1, x2, y2)共 128 字节MUL 合约的输入固定为 3 个域元素点(x, y)加标量s共 96 字节但调用方可以传入不足或超长的 calldata由预编译合约按上述规则容错处理。精确执行语义无效输入与失败行为EIP-196 对两个合约的无效输入定义完全一致任一输入点不在曲线上不满足Y^2 X^3 3任一点坐标域元素大于等于域模数 p。满足以上任一条件即视为无效输入合约调用失败并消耗调用所提供的全部 gas。作为对照标量本身没有上限约束可以是0到2**256 - 1之间的任意整数——这是 EIP-196 一个容易被忽视的设计点它允许标量超出群阶甚至域阶详见后文测试用例。ADD地址 0x6椭圆曲线点加法输入两个曲线点(x, y)输出曲线点x y其中是上文 alt_bn128 曲线上的标准点加法失败条件无效输入时失败并消耗全部 gas。MUL地址 0x7椭圆曲线标量乘法输入曲线点与标量(x, s)输出曲线点s * x其中*是上文 alt_bn128 曲线上的标量乘法即x自加s次失败条件无效输入时失败并消耗全部 gas。两个合约对失败行为都是all-or-nothing要么成功返回正确结果要么耗尽调用提供的 gas从而保证调用方可以安全地依赖失败状态。Gas 成本与后续调整EIP-196 规定的初始 gas 成本为操作地址Gas 成本ECADD0x6500ECMUL0x740000这一成本在后续提案中被显著下调。EIP-1108EIPS/eip-1108.md 基于 2018 年客户端密码学库的性能飞跃Go 参考实现 go-ethereum 迁移到 Cloudflare 的 bn256 库、Parity 客户端优化 bn 库的域运算与配对算法重新定价合约地址EIP-196 原成本EIP-1108 新成本ECADD0x06500150ECMUL0x0740 0006 000Pairing check0x0880 000 * k 100 00034 000 * k 45 000EIP-1108 的定价方法是以ecrecover预编译116 微秒、3000 gas为基准折算约 25.86 gas/微秒再按 Parity 客户端性能较弱者的实测耗时给出公式。另外EIP-1109EIPS/eip-1109.md 指出每次CALL操作码本身会额外消耗 700 gas这使得有效成本低于 700 的预编译合约无法发挥价值因此提出独立的PRECOMPILEDCALL操作码0xfb以剥离 CALL 开销——该提案以 ECADD 500 gas 为示例论据目前状态为 Stagnant。设计取舍Rationale分析EIP-196 的 Rationale 部分记录了几个关键设计决策及其理由为什么选 alt_bn128该曲线特别适合 zkSNARK尤其是其验证核心构件——配对函数且可与 ZCash 复用组件与工件形成协同效应。为什么拒绝把曲线/域参数放入输入设计时曾考虑允许调用方在输入中指定曲线与域参数但最终被否决。理由有二其一gas 成本将极难确定不同曲线运算耗时差异巨大其二调用方可能传入并非真正的椭圆曲线的参数破坏安全性。固定参数换来了可预测的 gas 与更简单的规范。为什么采用非紧凑non-compact点编码(x, y)全坐标编码虽然在带宽上不如压缩编码但有两个实际好处合约自身仍可直接对坐标执行一些运算保留了完整的 y 坐标两个编码后的点可以直接比较相等性不需要第三个射影坐标。向后兼容性考量与任何预编译合约的引入一样已经使用地址0x6、0x7的既有合约将改变其语义——此前这两个地址上的调用行为通常是空调用或未知地址调用会被替换为预编译合约逻辑。为降低风险EIP-196 特意选取了256 以下的保留区间reserved range内的地址避免与常规合约部署地址冲突。官方测试用例清单EIP-196 给出了六类必须覆盖的测试输入用于验证实现与规范的严格一致性模 p 后才有效的曲线点坐标在模 p 意义下成立、但原始数值大于等于 p 的点——必须失败对应域元素 p 即无效规则空输入两个合约在空输入上必须成功补零语义下空输入等价于无穷远点等合法输入截断输入截断后恰好构成合法曲线点的输入——必须成功不在曲线上的点数值合法但方程不成立的点——必须失败标量位于群阶与域阶之间乘以这样的标量——必须成功标量无上限约束的直接验证标量大于域阶乘以更大的标量——同样必须成功。这些用例精确刻画了编码合法性与标量自由性的分界线是实现者回归测试的最低要求。与 EIP-197 组合链上 zkSNARK 验证EIP-196 的价值必须通过与 EIP-197EIPS/eip-197.md 的组合才能完整显现。EIP-197 在地址0x8增加alt_bn128 最优 ate 配对检查pairing check预编译合约其定义为输入(a1, b1, ..., ak, bk)来自(G1 × G2)^k当且仅当离散对数方程log_P1(a1) * log_P2(b1) ... log_P1(ak) * log_P2(bk) 0 (in F_q)成立时返回 1否则返回 0其中G1的生成元为P1 (1, 2)群阶q 21888242871839275222246405745257275088548364400416034343698204186575808495617与 EIP-196 使用同一个域 p。EIP-197 的 gas 成本为80 000 * k 100 000k 为输入长度除以 192即配对组数。从实现原理看该检查可借助配对函数e的双线性性质高效完成验证e(a1,b1) * ... * e(ak,bk) 1是否成立。将 EIP-196 的 ADD/MUL 与 EIP-197 的配对检查配合即可在以太坊合约中完成 zkSNARK 证明的完整链上验证——这构成了隐私交易、Rollup 类 L2 扩容方案等大量应用的共同底座。实现参考与仓库脉络EIP-196 的原文提供了三种参考实现libffCZCash 生态、zcash 的 bn 库Rust以及 ethereum 的 py_pairingPython文档评价其最自包含、可读性最佳。三套代码都使用 alt_bn128 曲线上名为G1的具体群。由于这些基础运算已固化进主流客户端如 go-ethereum 的 bn256 实现合约开发者通常无需自行实现直接按本文规范调用0x6/0x7即可。在本仓库中与 EIP-196 直接相关的提案形成了清晰的演进脉络EIP-197配对检查与之互补、EIP-1108降低 gas 成本、EIP-1109预编译调用开销优化Stagnant、EIP-1962提出可完整替代0x06/0x07/0x08的统一椭圆曲线运算预编译。阅读这些提案可以完整追溯 alt_bn128 预编译从拜占庭引入到成本优化的全过程。小结EIP-196 以两个高度聚焦的预编译合约0x6ADD、0x7MUL为以太坊注入了高效的 alt_bn128 椭圆曲线点运算能力并以严格的编码规范、明确的无效输入语义和可预测的 gas 定价ECADD 500、ECMUL 40000后由 EIP-1108 下调至 150/6000保障了可用性与安全性。它与 EIP-197 的配对检查共同构成链上 zkSNARK 验证的基础设施是理解以太坊隐私与扩容技术栈时不可绕过的协议级知识点。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
