新闻详情

新闻详情

首页 / 资讯中心 / 详情

EIP-1013 深度解析:以太坊 Constantinople 硬分叉 Meta-EIP 及其五大核心改进(SHL/CREATE2/EXTCODEHASH/难度炸弹延迟/SSTORE 计量)

发布时间:2026/9/15 16:46:38来源:尧图网络
EIP-1013 深度解析:以太坊 Constantinople 硬分叉 Meta-EIP 及其五大核心改进(SHL/CREATE2/EXTCODEHASH/难度炸弹延迟/SSTORE 计量)
EIP-1013 深度解析以太坊 Constantinople 硬分叉 Meta-EIP 及其五大核心改进SHL/CREATE2/EXTCODEHASH/难度炸弹延迟/SSTORE 计量【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-1013 是以太坊基金会仓库EIPs中记录Constantinople 硬分叉的 Meta 类 EIP类型Meta状态Final它不引入任何具体协议规则而是将本分叉采纳的 5 个核心 EIPEIP-145、EIP-1014、EIP-1052、EIP-1234、EIP-1283聚合为一份统一的规范清单并给出各网络的激活区块号。本文以该 Meta-EIP 为主线逐项拆解每个被纳入 EIP 的动机、精确规范、Gas 计费、边界条件与测试用例帮助你完整理解 Constantinople 分叉在 EVM 指令集、账户创建、代码哈希、区块奖励与存储计量五个维度上对以太坊协议的具体改动以及这些改动对应的源码文档位置EIPS/eip-1013.md。一、Meta-EIP 定位一份硬分叉的总清单EIP-1013 由 Nick Savers 于 2018-04-20 创建requires字段声明它依赖 EIP-145、EIP-609、EIP-1014、EIP-1052、EIP-1234、EIP-1283。作为 Meta 类 EIP其唯一职责是定义分叉的代号、激活区块与纳入范围具体规则细节全部落在被引用的各个子 EIP 中。1.1 分叉代号与别名代号CodenameConstantinople别名AliasesMetropolis/Constantinople、Metropolis part 2Constantinople 是 Metropolis大都会路线图的第二阶段第一阶段是 Byzantium拜占庭即 EIP-609 所在的分叉该命名关系与仓库中的 EIP-609、EIP-649 相互印证。1.2 各网络激活区块号网络激活区块高度说明Ethereum 主网MainnetBlock 7_280_0002019-02-28 前后激活Ropsten 测试网Block 4_230_000Kovan 测试网Block 9_200_000Rinkeby 测试网Block 3_660_663这些区块号是客户端实现分叉切换的判定依据当block.number FORK_BLKNUM时启用对应规则。在 EIP-1234 的规范中这个分叉区块号被称为CNSTNTNPL_FORK_BLKNUM。1.3 纳入范围五大 EIP 一览编号标题类别核心改动EIP-145Bitwise shifting instructions in EVMCore新增 SHL/SHR/SAR 三个移位指令EIP-1014Skinny CREATE2Core新增 CREATE2 指令可预测合约地址EIP-1052EXTCODEHASH OpcodeCore新增 EXTCODEHASH 指令返回合约代码哈希EIP-1234Delay difficulty bomb, adjust block rewardCore延迟难度炸弹区块奖励降至 2 ETHEIP-1283Net gas metering for SSTORE without dirty mapsCoreSSTORE 净 Gas 计量引入退款机制需要说明的是这些 EIP 均是从 All Core Devs全核心开发者会议讨论的候选列表中筛选确定的相关讨论记录在 CONTRIBUTING.md 所述的 EIP 流程之外、由核心开发者会议纪要维护。下文将逐个深入每一份子 EIP 的技术细节。二、EIP-145EVM 原生位运算移位指令 SHL / SHR / SAR在 Constantinople 之前EVM 支持算术与逻辑运算却缺少原生移位指令。开发者只能用算术运算模拟移位左移用PUSH1 2 EXP MUL逻辑右移用PUSH1 2 EXP DIV但每条模拟指令要消耗35 gas且增加宿主机的处理负担。EIP-145 引入三个原生指令每条仅3 gasverylow层级将移位操作成本降低了一个数量级。2.1 指令语义操作数顺序与常规算术相反三个指令都从栈顶弹出两个值先弹arg1移位量再弹arg2被移位值计算结果压回栈。注意操作数顺序与大多数算术指令相反——这是特意设计的以适配栈上已有待移位值这一更自然的用法。0x1b: SHL左移结果等于(arg2 * 2^arg1) mod 2^256arg2按无符号数解释arg1按无符号数解释若arg1 256结果为 0等价于PUSH1 2 EXP MUL0x1c: SHR逻辑右移结果等于floor(arg2 / 2^arg1)高位补零arg2按无符号数解释arg1按无符号数解释若arg1 256结果为 0等价于PUSH1 2 EXP DIV0x1d: SAR算术右移结果等于floor(arg2 / 2^arg1)高位符号扩展负数补 1arg2按有符号数解释arg1按无符号数解释若arg1 256arg2非负时结果为 0arg2为负时结果为 -1不等价于PUSH1 2 EXP SDIV因为取整方向不同SDIV(-1, 2) 0而SAR(-1, 1) -12.2 代表性测试用例EIP-145 附带了完整的测试用例集状态测试填充源位于 ethereum/tests 的GeneralStateTestsFiller/stShift。下面选取能体现关键边界行为的几条SHL 边界移位量等于 256 时结果归零PUSH 0x0000000000000000000000000000000000000000000000000000000000000001 PUSH 0x0100 SHL --- 0x0000000000000000000000000000000000000000000000000000000000000000SAR 符号扩展负数右移保持全 1 符号位PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff PUSH 0x01 SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffSAR 负数边界0x8000...右移 255 位得到 -1右移 256 位仍为 -1PUSH 0x8000000000000000000000000000000000000000000000000000000000000000 PUSH 0xff SAR --- 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff2.3 实现与兼容性客户端支持cpp-ethereum 通过 PR #4054 实现。编译器支持Solidity/LLL 通过 PR #2541 支持这三个指令Solidity 的、运算在 0.5.x 之后直接映射为 SHL/SHR/SAR。向后兼容性新指令不会影响历史部署的字节码旧的算术模拟写法依然有效只是不再有 Gas 优势。三、EIP-1014Skinny CREATE2——可预测地址的合约创建EIP-1014 由 Vitalik Buterin 提出在0xf5位置新增CREATE2指令。与CREATE0xf0的区别在于合约地址的计算方式不再使用基于发送者地址 nonce 的 RLP 哈希而是使用一个固定长度的预映像。3.1 地址计算公式与栈参数CREATE2从栈上取 4 个参数endowment转入资金、memory_start内存起始、memory_length内存长度、salt盐值。合约初始化地址为keccak256( 0xff address salt keccak256(init_code) )[12:]其中0xff是单字节1 字节address恒为 20 字节创建者地址salt恒为 32 字节一个栈项因此最终哈希轮次的预映像长度恒为 85 字节1 20 32 32。该公式于 2018-08-10 的核心开发者电话会议中确定。3.2 为何用 0xff 前缀地址公式采用0xff起始字节有两个关键理由与旧公式天然隔离传统地址keccak256(rlp([sender, nonce]))的 RLP 编码不可能以0xff开头RLP 以0xff开头只可能对应长度达 PB 级的数据从而保证两种方案创建的地址不会碰撞。固定预映像长度便于实现与验证。3.3 Gas 费用模型CREATE2沿用CREATE的 Gas 框架但额外增加一项hashcosthashcost GSHA3WORD * ceil(len(init_code) / 32)即与SHA3指令相同的每 32 字节一个字的哈希计费。该hashcost与内存扩展 Gas、CreateGas在同一时刻扣除——即在结果地址求值与init_code执行之前扣除。这样设计的动机是防 DoS地址计算依赖对init_code的哈希而内存扩展只收费一次若不按字收费攻击者可以反复执行造成客户端反复哈希大段代码。示例验证假设无内存扩展init_code为空时 Gas 为 32000addresssaltinit_codegas结果地址0x0000...00000x0000...00000x00320060x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF380xdeadbeef000000000000000000000000000000000x0000...00000x00320060xB928f69Bb1D91Cd65274e3c79d8986362984fDA30xdeadbeef000000000000000000000000000000000x0000...feed...0x00320060xD04116cDd17beBE565EB2422F2497E06cC1C98330x0000...00000x0000...00000xdeadbeef320060x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e0x0000...deadbeef0x0000...cafebabe0xdeadbeef320060x60f3f640a8508fC6a86d45DF051962668E1e8AC70x0000...deadbeef0x0000...cafebabe0xdeadbeef×1144 字节320120x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C0x0000...00000x0000...0000空320000xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0注意第 6 行44 字节的init_code需要ceil(44/32) 2个字的哈希费6 gas 2×3所以 Gas 从 32000 升到 32012。3.4 碰撞行为与 EIP-161 的交互CREATE2使地址碰撞成为可能碰撞行为由 EIP-684 的规则规定若目标地址已有非零 nonce 或非空 code创建立即失败与 init code 首字节为无效指令时行为一致且自创世起追溯适用。结合 EIP-161账户创建事务与CREATE操作应在初始化代码执行前将 nonce 自增 1可以得到一个重要推论同一笔交易内由事务创建出的合约 nonce 立即非零因此即使在其自身 init_code 内用 CREATE2 撞自己的地址也必然失败。另外SELFDESTRUCT0xff不会立即影响 nonce 或 code所以无法在同一笔交易内销毁并重建一个合约。3.5 典型应用场景CREATE2的核心价值在于反事实counterfactual交互可以与链上尚不存在、但地址可预先确定且未来只可能由特定 init_code 创建的合约进行交互。这对状态通道等场景至关重要——参与方可以先在链下按公式协商好地址待需要时再真正部署合约地址不会因 nonce 波动而变化。四、EIP-1052EXTCODEHASH——零拷贝获取合约代码哈希许多合约需要校验另一合约的字节码例如判断是否属于允许的实现集合、对代码做白名单分析但并不需要字节码本身。此前只能通过EXTCODECOPY0x3c把整段代码拷出来再哈希对大合约来说代价高昂。EIP-1052 在0x3f位置引入EXTCODEHASH指令直接返回账户代码的 keccak256 哈希。4.1 指令规范从栈上取 1 个参数清零前 96 位即只取低 160 位作为账户地址将账户代码的 keccak256 哈希压栈。账户不存在或为空账户按 EIP-161 定义压入0。账户存在但无代码压入空数据的 keccak256 哈希即c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470。Gas 成本为400。4.2 设计理由Gas 定价与 BALANCE 一致400因为执行EXTCODEHASH需要与BALANCE相同的账户查找操作。参数语义与其他账户指令一致只取参数后 20 字节忽略前 12 字节与BALANCE0x31、EXTCODESIZE0x3b、EXTCODECOPY0x3c相同。区分无代码账户与不存在账户这与状态树中账户的表示方式一致且让智能合约得以直接判断某账户是否存在。4.3 关键测试语义EIP-1052 给出了 10 条测试语义涵盖各类边界无代码账户的EXTCODEHASH为空数据哈希c5d246...a470不存在账户的EXTCODEHASH为0预编译合约的EXTCODEHASH为c5d246...或0视实现而定若A的哈希为X则A 2**160的哈希也为X高位清零语义本交易内已自毁账户、6. 自毁后又回滚、7. 本交易内新创建账户、8. 创建后又回滚、9. 先不存在后为空、10. 将被状态清理规则清除的空账户——这些场景各有明确定义的行为。该指令无向后兼容性问题是后续 DeFi 合约做代码即身份如实现注册表、权限白名单的标准工具。五、EIP-1234难度炸弹延迟与区块奖励调整Constantinople 同时处理两个经济层面问题一是 Ethash 的**难度炸弹冰河期ice age**导致出块时间不断上升二是 Casper/权益证明切换一再推迟需要维持 PoW 挖矿在约 15 秒平均出块时间下再运行约 12 个月。EIP-1234 的方案是推迟难度炸弹 同步下调区块奖励二者对冲以维持系统总体状态稳定并降低接近 PoS 时矿工主导链分裂的可能性。其逻辑与 Byzantium 分叉中的 EIP-649 一脉相承实现逻辑无差异。5.1 用假区块号放松难度在calc_difficulty中用以下公式替换指数冰河期组件中使用的block.numberfake_block_number max(0, block.number - 5_000_000) if block.number CNSTNTNPL_FORK_BLKNUM else block.number即从分叉区块起难度计算假装链还停留在 500 万个区块之前从而将冰河期的到来推迟约 2900 万秒约 12 个月预计 2019 年冬季前出块时间仍可维持在 30 秒以内。5.2 区块奖励降至 2 ETH为保证 Ether 发行量恒定区块奖励调整为new_block_reward 2_000_000_000_000_000_000 if block.number CNSTNTNPL_FORK_BLKNUM else block.reward即2E18 wei2 ETH此前 Byzantium 已将奖励从 5 ETH 降至 3 ETH。5.3 叔块与侄块奖励沿用分叉前的叔块公式仅替换new_block_rewardnew_uncle_reward (8 - k) * new_block_reward / 8其中k block.number - uncle.number叔块高度差。侄块奖励为new_nephew_reward new_block_reward / 32例如高度差 1 的叔块奖励为7/8 × 2 1.75 ETH包含叔块的侄块奖励为2/32 0.0625 ETH。5.4 兼容性与实现该 EIP非前向兼容在难度计算及区块/叔块/侄块奖励结构上引入了后向不兼容必须随计划好的硬分叉在指定区块号启用。参考实现为 Parity-Ethereum 的 PR #9187逻辑与 EIP-649 相同。六、EIP-1283SSTORE 净 Gas 计量无脏映射EIP-1283 重写了SSTORE指令的 Gas 计量含退款是 EIP-1087、EIP-1153 的替代方案。其关键设计是不引入脏映射dirty map或额外存储结构只依赖三种普遍可得的信息槽位原始值original value、槽位当前值current value与退款计数器从而对不同存储缓存优化策略的客户端都友好。6.1 术语定义原始值original value当前交易发生回滚时该槽位将恢复的值。当前值current value本次SSTORE执行前槽位的值。新值new value本次SSTORE执行后槽位的值。6.2 完整计量规则替换SSTORE的 Gas 计算含退款为以下逻辑当前值 新值no-op无操作扣200 gas。当前值 ! 新值原始值 当前值该槽位在本执行上下文中未被改过即Fresh原始值为 0扣20000 gas否则扣5000 gas若新值为 0向退款计数器加15000 gas。原始值 ! 当前值槽位已脏即Dirty扣200 gas并同时应用以下两条若原始值不为 0若当前值为 0则新值必不为 0从退款计数器减去 15000 gas可证明计数器不会因此低于 0若新值为 0则当前值必不为 0向退款计数器增加 15000 gas。若原始值 新值槽位被重置回原值原始值为 0向退款计数器加19800 gas否则加4800 gas。6.3 状态机视角三种状态覆盖了 original/current/new 的全部组合No-op虚拟机组无需任何操作、Fresh未改动或已重置、Dirty已改动。所有非 no-op 的首次SSTORE都从 Fresh 开始从 Fresh 到 Dirty 按原方案收费Dirty 槽位可通过一次SSTORE重置回 Fresh 并触发退款槽位停留在 Dirty 时每次只收 200 gas。下图出自 EIPS/eip-1283.md由 Arachnid 绘制展示了 Gas 费用的可能状态转换忽略 trivial 的 No-op 态对应的状态转换表如下纵轴为所设新值横轴为原始值/当前值状态原始值为 0 时A (currentorig0)B (current!orig)~0B; 20k gasB; 200 gas0A; 200 gasA; 200 gas, 19.8k refund原始值非 0 时X (currentorig!0)Y (current!orig)Z (current0)origX; 200 gasX; 200 gas, 4.8k refundX; 200 gas, -10.2k refund~orig, ~0Y; 5k gasY; 200 gasY; 200 gas, -15k refund0Z; 5k gas, 15k refundZ; 200 gas, 15k refundZ; 200 gas6.4 退款计数器的实现注意事项退款计数器仍受不超过已消耗 Gas 一半的限制事务级别上不会低于零。但实现上有两种模式需区别对待事务级退款计数器在每次调用帧处做 checkpoint保持无符号即可执行帧级退款计数器每帧新建、帧结束时合并回父帧必须改为有符号——因为内部调用中子帧退款可能暂时为负。6.5 典型收益场景与示例受益于该方案的应用包括同一调用帧内的连续存储写入重入锁、同合约多笔转账、子帧与父帧之间交换无需持久化的信息错误码、消息传递等。EIP-1283 文档给出的三个典型算例空存储合约把 slot 0 设为 1 再设回 020000 200 - 19800 400 gas空存储合约将 slot 0 递增 5 次20000 5 × 200 21000 gas从账户 A 转账到 B 再转到 C起止余额均非零5000 × 3 200 - 4800 10400 gas。6.6 测试用例双 SSTORE 与三 SSTORE文档附带了 17 条测试用例15 条覆盖连续两次SSTORE基于 chfast 的工作2 条用三次SSTORE测试重置后再设置的场景。节选关键几行CodeUsed GasRefundOriginal1st2nd0x6000600055600060005541200000x6001600055600060005520212198000100x60006000556001600055521248001010x60026000556001600055521248001210x60016000556000600055600160005540218198000101三次0x60006000556001600055600060005510218198001010三次6.7 正确性证明附录EIP-1283 附录用归纳法证明了计量规则的性质。以原始值为 0 为例需要证明Case I若最终值仍为 0总费用为200 × N无需写盘Case II若最终值为非零总费用为20000 200 × (N-1)需要写盘一次。归纳步覆盖 A→A、A→B、B→B、B→A 四种转移原始值非 0 时扩展为 X/Y/Z 三态共九种转移证明费用与写盘次数精确对应。因为原始值定义为当前事务回滚时的值调用帧之间不会互相干扰 SSTORE 计量证明对带调用帧的情形同样成立。七、Constantinople 的整体影响与资料索引指令集维度新增 SHL/SHR/SAREIP-145、CREATE2EIP-1014、EXTCODEHASHEIP-1052共 5 个新操作码合约编程在移位、可预测部署、代码哈希校验上获得了原生化能力。经济维度区块奖励由 3 ETH 降至 2 ETH叔块/侄块奖励同步调整难度炸弹推迟约 12 个月EIP-1234。存储计量维度SSTORE 净计量大幅降低重复写入与重置写入的 Gas使重入锁、子帧通信等模式成本骤降EIP-1283。若想继续深入可在本仓库中对照阅读EIP-1013 的依赖项 EIP-609Byzantium 分叉、EIP-649上一轮难度炸弹与奖励调整的模板、EIP-161账户状态清理/非零 nonce 规则、EIP-684合约创建碰撞规则以及 eip-template.md 了解 Meta 类 EIP 的撰写规范。仓库根目录的 README.md 和 LICENSE.md 提供了整体项目与版权说明本 EIP 及全部子 EIP 均以 CC0 放弃版权。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

铁磁软体连续机器人:磁场驱动的柔性执行器技术解析 2026/9/15 17:28:44

铁磁软体连续机器人:磁场驱动的柔性执行器技术解析

1. 从项目标题拆解技术内核“Ferromagnetic soft continuum robots”这个标题,字面直译是“铁磁软体连续型机器人”。如果只是匆匆扫一眼,很多人以为这就是一般的软体机器人加了磁性材料,或者以为是用磁场去吸着一个软体结构到处跑。说实话&a…

阅读更多 →
Ultralytics HUB App 移动端实时目标检测实战指南:iOS 与 Android 上的 YOLO 模型部署 2026/9/15 17:28:44

Ultralytics HUB App 移动端实时目标检测实战指南:iOS 与 Android 上的 YOLO 模型部署

Ultralytics HUB App 移动端实时目标检测实战指南:iOS 与 Android 上的 YOLO 模型部署 【免费下载链接】yolov10 YOLOv10: Real-Time End-to-End Object Detection [NeurIPS 2024] 项目地址: https://gitcode.com/GitHub_Trending/yo/yolov10 YOLOv10 仓库&…

阅读更多 →
Git Pull操作中SSH Key原理与配置指南 2026/9/15 17:28:44

Git Pull操作中SSH Key原理与配置指南

1. Git Pull操作中的SSH Key核心原理在团队协作开发中,Git的pull操作是最常用的命令之一。当使用SSH协议进行仓库访问时,密钥配置的正确性直接决定了操作能否成功。SSH Key本质上是一对非对称加密的密钥文件,包含公钥(id_rsa.pub&…

阅读更多 →
Hyper-V与KVM虚拟机监控程序对比:从架构到选型全解析 2026/9/15 17:28:44

Hyper-V与KVM虚拟机监控程序对比:从架构到选型全解析

每次有朋友问我服务器虚拟化该选什么,我基本不会第一时间报产品名,而是先反问一句:你的核心业务跑在Windows上,还是Linux上?这个问题之所以关键,是因为Hyper-V和KVM虽然都是虚拟机监控程序(Hype…

阅读更多 →
机器视觉相机选型指南:从CCD成像原理到参数详解与实战 2026/9/15 17:28:44

机器视觉相机选型指南:从CCD成像原理到参数详解与实战

1. CCD成像到底是怎么一回事:从光子到灰度值的完整链路很多刚接触机器视觉的朋友,一上来就问我:"CCD和CMOS到底差在哪?是不是CCD一定更好?"这个问题看似简单,但要真正回答清楚,得从CC…

阅读更多 →
使用 Rube MCP 与 Composio Twitch 工具包实现 Codex 直播平台自动化 2026/9/15 17:25:43

使用 Rube MCP 与 Composio Twitch 工具包实现 Codex 直播平台自动化

使用 Rube MCP 与 Composio Twitch 工具包实现 Codex 直播平台自动化 【免费下载链接】awesome-codex-skills A curated list of practical Codex skills for automating workflows across the Codex CLI and API. 项目地址: https://gitcode.com/GitHub_Trending/aw/awesome…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞