ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

EIP-233 解读:以太坊硬分叉的正式流程与 Meta EIP 规范

2026/9/15 12:11:39 拓冰建站 浏览量
EIP-233 解读:以太坊硬分叉的正式流程与 Meta EIP 规范 EIP-233 解读以太坊硬分叉的正式流程与 Meta EIP 规范【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-233Formal process of hard forks是由 Alex Beregszaszi 于 2017 年提交的一篇Meta 类 EIP它定义了以太坊社区准备与激活硬分叉的正式流程用一篇专门的 Meta EIP 作为硬分叉的协调中枢统一记录代号、激活区块、时间线和纳入的 EIP 清单。本文以 EIPS/eip-233.md 为骨架结合本仓库中真实落地的多篇硬分叉 Meta EIPHomestead、DAO Fork、Constantinople、Petersburg、Istanbul与 EIPS/eip-1.md 的 EIP 类型定义完整讲解这套流程的规范、模板与实践要点。读完本文你将理解以太坊硬分叉从草案收集到主网激活的全生命周期如何被一篇文档形式化地管理并掌握编写硬分叉 Meta EIP 的标准写法。背景与动机为什么要形式化硬分叉流程在 EIP-233 提出之前以太坊的硬分叉讨论发生在各种论坛上有时是临时即兴的原文 Motivation 表述。这种分散的讨论方式带来两个实际问题范围不可见一次硬分叉究竟包含哪些改动、处于什么阶段缺乏一个统一、权威的查询入口追溯困难围绕某个分叉的决策过程分散在论坛、聊天记录中事后难以追踪为什么这个 EIP 被纳入、那个被拒绝。EIP-233 的解法是引入Meta EIP元 EIP机制为每一次计划中的硬分叉单独创建一篇 Meta EIP让它成为该分叉的单一事实来源。根据 EIPS/eip-1.md 的定义Meta EIP 描述的是围绕以太坊的流程或提议对流程的变更它不仅仅是建议用户通常不能随意忽略。硬分叉 Meta EIP 正是这一类型的典型应用。核心规范硬分叉 Meta EIP 应包含什么EIP-233 的 Specification 部分规定一旦计划了新的硬分叉应立即创建一篇 Meta EIP并以Draft状态合并。这篇 EIP 必须包含以下内容必需内容说明期望的硬分叉代号codename如 Istanbul、Constantinople用于简短指代该分叉激活区块号一旦确定如Block 9,069,000这类精确表达时间线timeline章节记录关键日期待纳入 EIPEIPs to include章节分叉候选 EIP 清单Requires头部必须指向上一篇硬分叉 Meta EIP形成链式依赖同时该草案应随着硬分叉相关决策的推进持续更新记录每一项决策的摘要。Requires 链硬分叉 Meta EIP 之间的依赖关系Requires头部指向上一篇硬分叉 Meta EIP是 EIP-233 最具特色的设计它把历次分叉串成一条可追溯的链。本仓库中的真实示例清晰地体现了这一点EIPS/eip-1679.mdIstanbulrequires: 152, 1108, 1344, 1716, 1884, 2028, 2200其中1716 就是上一篇分叉 Petersburg其余是被纳入的 Core EIP 编号EIPS/eip-1716.mdPetersburgrequires: 1013, 1283指向 Constantinople 与被移除的 EIP-1283EIPS/eip-1013.mdConstantinoplerequires: 145, 609, 1014, 1052, 1234, 1283EIPS/eip-606.mdHomesteadrequires: 2, 7, 8EIPS/eip-779.mdDAO Forkrequires: 606指向 Homestead。按 EIPS/eip-1.md 对requires头部的定义只有当当前 EIP 无法在没有另一 EIP 的概念或技术要素的情况下被理解或实现时才构成依赖。分叉 Meta EIP 之间的依赖是天然的——后续分叉的语境必然建立在之前分叉之上例如 Istanbul 明确基于 Petersburg。Timeline硬分叉时间线的四个关键节点EIP-233 规定一旦就关键日期达成一致时间线章节应包含四个基本要素接受本硬分叉提案的硬截止日期hard deadline to accept proposals——此后不再接受新的候选 EIP主要客户端实现软截止日期soft deadline for major client implementations——各执行客户端geth、besu、nethermind、erigon 等需在此之前完成实现测试网升级的预计日期——先在 Ropsten、Görli 等测试网验证主网升级的预计日期或该区块的预计激活区块号/日期。Istanbul 的 EIPS/eip-1679.md 在草稿期给出的时间线模板即为标准范例* 2019-05-17 (Fri) hard deadline to accept proposals for Istanbul * 2019-07-19 (Fri) soft deadline for major client implementations * 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet) * 2019-10-16 (Wed) projected date for mainnet upgrade (Istanbul)这条时间线体现了先测试网、后主网的分阶段上线策略测试网验证通过后再推进主网降低共识风险。EIP 纳入流程EIP Inclusion ProcessEIP-233 为哪些 Core EIP 能进入一次硬分叉定义了明确的申报与裁决流程。申报向 Meta EIP 发起 PR任何希望为硬分叉提议 Core EIP 的人应向代表该硬分叉的 Meta EIP 提交 PR。前提条件是该 EIP 至少已发布为Draft状态进入 Meta EIP 的Proposed EIPs拟议章节同时至少指定一位希望纳入该 EIP 的联络人point of contact。裁决通过 All Core Devs 会议移动状态EIP 的状态迁移由All Core DevsACD会议的讨论决定EIP-233 原文链接指向 ethereum/pm 仓库。规则如下决策结果状态迁移触发条件被接受→Accepted EIPs已接受在时间线截止日期前已有主要客户端实现、且无安全问题则排期纳入被拒绝→Rejected EIPs已拒绝会议明确拒绝测试网验证通过→Included EIPs已纳入Accepted 章节中的 EIP 成功在测试网 rollout 上线后这一设计把讨论ACD 会议与记录Meta EIP 文档解耦会议负责形成共识Meta EIP 负责沉淀结果任何人都能通过查看 Meta EIP 了解每个候选 EIP 的当前处境。Meta EIP 自身的状态机Meta EIP 本身也遵循 EIP 状态机流转Draft分叉计划确定后立即创建并合并Accepted当变更被冻结时——即所有被引用的 EIP 都处于Accepted状态——Meta EIP 进入AcceptedFinal硬分叉在主网成功激活后Meta EIP 进入Final。标准模板以 Istanbul 为例EIP-233 直接以 EIPS/eip-1679.md 为模板给出了一份可直接复用的硬分叉 Meta EIP 骨架下为原文模板去除了 Jekyll 的{% raw %}包裹标记--- eip: 1679 title: Hardfork Meta: Istanbul author: Alex Beregszaszi (axic), Afri Schoedon (5chdn) type: Meta status: Draft created: 2019-01-04 requires: 1716 --- ## Abstract This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul. ## Specification - Codename: Istanbul - Activation: TBD ### Included EIPs - TBD ### Accepted EIPs - TBD ### Rejected EIPs - TBD ### Proposed EIPs - TBD ## Timeline * 2019-05-17 (Fri) hard deadline to accept proposals for Istanbul * 2019-07-19 (Fri) soft deadline for major client implementations * 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet) * 2019-10-16 (Wed) projected date for mainnet upgrade (Istanbul) ## References - TBD (e.g. link to Core Dev notes or other references) ## Copyright Copyright and related rights waived via [CC0](https://link.gitcode.com/i/4b53860991d8ff22a758cd67390ce38d).注意模板中type: Meta是关键标识按 EIPS/eip-1.md 的头部规范Meta 类 EIP 不需要category字段该字段仅 Standards Track 需要。requires: 1716即指向上一分叉 Petersburg 的 Meta EIP。模板的最终形态从 Draft 到 Final 的完整样例对比同一篇 EIPS/eip-1679.md 在Final状态下的实际内容可以看到 Draft 模板中的TBD如何被真实数据填充这正是 EIP-233 所倡导的随决策推进持续更新草案的落地结果CodenameIstanbulActivation每个网络一个区块号Block 9,069,000Ethereum MainnetBlock 6,485,846RopstenBlock 14,111,141KovanBlock 5,435,345RinkebyBlock 1,561,651GörliIncluded EIPs6 项EIP-152Add Blake2 compression functionFprecompileEIP-1108Reduce alt_bn128 precompile gas costsEIP-1344Add ChainID opcodeEIP-1884Repricing for trie-size-dependent opcodesEIP-2028Calldata gas cost reductionEIP-2200Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost changeReferences记录纳入清单是在 All Core Devs Call #68 中敲定的并附测试网公告链接。硬分叉 Meta EIP 在仓库中的真实演进本仓库保留了从以太坊诞生至今的硬分叉 Meta EIP 序列是理解 EIP-233 流程演进的活教材EIPS/eip-606.mdHomestead最早期的 Meta EIP 之一采用Block 1,150,000单区块表达纳入 EIP-2Homestead 硬分叉变更、EIP-7DELEGATECALL、EIP-8devp2p 前向兼容EIPS/eip-779.mdDAO Fork特殊案例——它并非协议变更而是将一份账户列表L中的以太币转移到 WithdrawDAO 合约的非正则状态变更irregular state change文档中完整给出了账户列表、Solidity 源码、部署字节码以及[1_920_000, 1_920_009]区块必须携带dao-hard-fork标记的硬性要求。它展示了 Meta EIP 足够灵活可承载高度定制化的分叉内容EIPS/eip-1013.mdConstantinopleActivation明确区分主网与各测试网区块号纳入 EIP-145、EIP-1014、EIP-1052、EIP-1234、EIP-1283EIPS/eip-1716.mdPetersburg展示了一种罕见的反向下架场景——从 Constantinople 中移除 EIP-1283净计量 SSTORE gas并规定若 Petersburg 与 Constantinople 在同一区块激活Petersburg 优先净效果是 EIP-1283 被禁用若 Petersburg 先激活则无即时效果待 Constantinople 激活后 EIP-1283 仍应被禁用。这证明 Meta EIP 不仅可以累加功能也能表达复杂的优先级语义EIPS/eip-1679.mdIstanbul目前最完整、最接近 EIP-233 模板规范的一篇五条网络激活区块与六项 Included EIP 全部填充完毕。Rationale为什么需要 Meta EIP 机制EIP-233 的 Rationale 部分给出了这一设计的根本理由一篇用于协调硬分叉的 Meta EIP应当有助于提高变更范围的可视性与可追溯性并为该分叉提供一个简短的名称和/或编号以便引用。换言之Meta EIP 的价值在于社区成员、客户端团队、应用开发者只需记住这次分叉叫什么如 Istanbul再通过这篇文档即可看到完整的变更范围、决策状态与时间计划而不必在论坛、会议纪要等多个分散渠道中拼凑信息。这种一文档到底的模式也为此后每次以太坊网络升级沿用至今。阅读建议与仓库导航规范源头EIPS/eip-233.md当前状态为Stagnant即因长期未更新而从 Draft 冻结其流程思想已被后续实践广泛继承类型定义EIPS/eip-1.md 的 EIP Types 与 EIP Work Flow 章节理解 Meta 类 EIP 与 Draft/Accepted/Final/Stagnant 状态机标准写作模板eip-template.md其中type字段注释明确列出Meta作为可选值贡献规范CONTRIBUTING.md案例序列按requires链阅读 EIPS/eip-606.md → EIPS/eip-779.md → EIPS/eip-1013.md → EIPS/eip-1716.md → EIPS/eip-1679.md即可完整还原以太坊硬分叉治理的演进脉络。版权说明EIP-233 及本仓库所有 EIP 文档均以 CC0 公有领域授权发布版权声明原文位于 LICENSE.md。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考