EIP-7568 硬分叉元 EIP 回填全指南从 Berlin 到 Shapella 的以太坊网络升级规范总览【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-7568Hardfork Meta Backfill - Berlin to Shapella是 Ethereum 改进提案仓库中的一份 Meta 类 EIP它回填了 Muir Glacier 硬分叉之后所有未使用 Hardfork Meta EIP 记录的网络升级规范覆盖范围从 Beacon Chain 启动Serenity Phase 0一直延伸到 Shapella。阅读本文你将系统掌握 Berlin、London、Altair、Arrow Glacier、Gray Glacier、The MergeParis Bellatrix与 ShapellaShanghai Capella这七个网络升级的规范来源、激活机制演变区块号 → epoch → TTD → 时间戳以及它们与 EIP-6953、EIP-6122、EIP-2982 等提案之间的关联。一、背景Meta EIP 的沉寂与复兴在以太坊的历史上社区长期使用Meta EIP元 EIP来记录网络升级Hardfork所包含的具体变更清单。这类 EIP 扮演着升级总目录的角色让开发者与用户能够一目了然地知道某次升级会引入哪些协议变更。在Muir Glacier硬分叉之后这一做法被暂时放弃——网络升级改为通过其他方式如各客户端仓库中的network-upgrades目录追踪所包含的变更。而最近社区又重新形成了使用 Meta EIP 的共识。本 EIP 正是这一共识的产物它聚合了没有独立 Meta EIP的那些网络升级并逐一链接到它们的权威规范出处。作为参考仓库中仍保留着 Muir Glacier 之前最后一波 Meta EIP 的样例例如EIP-1679 Hardfork Meta: Istanbul列出了伊斯坦布尔升级包含的 EIP-152、EIP-1108、EIP-1344、EIP-1884、EIP-2028、EIP-2200并给出主网与各测试网的激活区块号EIP-2387 Hardfork Meta: Muir Glacier说明该升级在主网Block 9,200,000激活仅包含 EIP-2384难度炸弹延迟。EIP-7568 的定位正是延续这条线索把柏林到 Shapella 之间的升级规范回填进 EIP 体系。二、理解升级的关键激活机制的四次演变要读懂 EIP-7568 中罗列的各个升级首先需要理解以太坊网络升级激活机制的演变EIP-6953 Network Upgrade Activation Triggers 对此给出了权威的完整清单。1. PoW 时代按区块号触发在权益证明PoS之前以太坊网络升级以特定区块号作为激活触发器。EIP-7568 覆盖范围内的相关升级如下升级名称激活区块号Berlin12244000London12965000Arrow Glacier13773000Gray Glacier15050000这一机制贯穿 Frontier区块1到 Gray Glacier 的整个 PoW 时代其他著名升级如 Homestead1150000、DAO Fork1920000、Byzantium4370000、Istanbul9069000等也遵循同一模式。2. Beacon Chain按 epoch 触发Beacon Chain 的升级以特定 epoch激活。与后续升级直接相关的有升级名称激活 EpochAltair74240Bellatrix1448963. The Merge按 Terminal Total DifficultyTTD触发Paris 升级The Merge 的执行层部分由 PoW 总难度值58750000000000000000000触发具体规范见 EIP-3675。值得注意的是Beacon Chain 上 Bellatrix 升级的激活是 Paris 升级成功激活的前置条件。4. 合并后共识层 epoch 执行层时间戳The Merge 之后网络升级在共识层以 epoch 触发执行层则以时间戳而非区块号触发。这是因为 Beacon Chain 存在错过 slot 的可能执行层无法仅依赖区块号与共识层保持同步激活。相关参数升级名称激活 Epoch激活时间戳CapellaCL194048—ShanghaiEL—1681338455关键洞察在于epoch194048恰好发生在时间戳1681338455因此 Shapella 虽然执行层与共识层各用一个不同的常量却实现了两层同时激活。此外EIP-6953 还指出时间戳作为触发器导致节点FORK_HASH与FORK_NEXT的计算方式发生变化这部分由 EIP-6122 详细描述。三、逐项解读EIP-7568 覆盖的七个网络升级EIP-7568 的规范正文按激活顺序列出各升级并约定执行层Execution Layer升级标注为[EL]共识层Consensus Layer升级标注为[CL]。1. Beacon Chain Launch — Serenity Phase 0 [CL]Beacon Chain 启动时的完整规范位于ethereum/consensus-specs仓库的v1.0.0版本。同时EIP-2982 Serenity Phase 0 提供了 Beacon Chain 的设计背景与主网参数化理由属于理解 Phase 0 的必读材料。EIP-2982 记录的 Phase 0 关键参数包括参数值SPEC_RELEASE_VERSIONv1.0.0DEPOSIT_CONTRACT_ADDRESS0x00000000219ab540356cBB839Cbe05303d7705FaMIN_GENESIS_TIME1606824000BASE_REWARD_FACTOR2**664INACTIVITY_PENALTY_QUOTIENT2**2667,108,864PROPORTIONAL_SLASHING_MULTIPLIER1MIN_SLASHING_PENALTY_QUOTIENT2**7128启动条件方面EIP-6953 给出了 Beacon Chain 启动需同时满足的三个条件Beacon Chain 存款合约收到至少524288ETH来自16384个验证者超过MIN_GENESIS_TIME时间戳1606824000即 2020 年 12 月 1 日自最低验证者数量达标后已过去GENESIS_DELAY的604800秒。Phase 0 的设计核心是 Casper FFG最终性小工具与 LMD-GHOST 分叉选择算法验证者通过向主网存款合约质押 ETH 加入验证者集并履行区块提议、见证attestation等职责获取奖励该阶段不包含转账、分片或智能合约执行能力。2. Berlin [EL]Berlin 升级最初由 EIP-2070 Hardfork Meta: Berlin 作为 Meta EIP 起草但随后规范被迁移至ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/berlin.md文件EIP-2070 也随之转为 Withdrawn 状态。Berlin 于主网区块12244000激活。3. London [EL]London 升级所包含的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/london.md文件于主网区块12965000激活。这是引入 EIP-1559 手续费机制、EIP-3554 难度炸弹延迟等变更的重要升级。4. Altair [CL]Altair 是 Beacon Chain 的第一次升级完整规范位于ethereum/consensus-specs仓库的v1.1.0版本于 epoch74240激活。它引入了同步委员会sync committees、更轻量的轻客户端支持并对参与者的奖惩机制进行了调整。5. Arrow Glacier [EL]Arrow Glacier 升级的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/arrow-glacier.md文件于主网区块13773000激活主要内容是再次延迟难度炸弹。6. Gray Glacier [EL]Gray Glacier 升级的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/gray-glacier.md文件于主网区块15050000激活同样以延迟难度炸弹为主。7. The MergeParis BellatrixThe Merge 是第一个要求执行层与共识层协调的升级共识层先激活 Bellatrix随后执行层激活 Paris。Bellatrix [CL]完整规范位于ethereum/consensus-specs仓库的v1.2.0版本于 epoch144896激活。Paris [EL]EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/paris.md文件由 TTD58750000000000000000000触发见 EIP-3675且以 Bellatrix 激活为前置条件。The Merge 将执行层从 PoW 切换到由共识层驱动的 PoS 机制区块生产由验证者承担原有矿工奖励机制终结。8. ShapellaShanghai CapellaShapella 是第一个在执行层与共识层同时激活的升级。为实现这一点执行层的升级激活机制从按区块号改为按时间戳这一机制分别在 EIP-6953 与 EIP-6122 中描述。Shanghai [EL]EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/shanghai.md文件于时间戳1681338455激活最核心的变更是引入 EIP-4895 的验证者提款。Capella [CL]完整规范位于ethereum/consensus-specs仓库的v1.3.0版本于 epoch194048激活负责配合执行层实现提款功能如 BLS 提款凭证转换。四、源码级佐证EIP-6122 与基于时间戳的 forkid 校验Shapella 从按区块号切换到按时间戳激活直接影响了 P2P 网络中节点的身份识别机制。 EIP-6122 Forkid checks based on timestamps 在 EIP-2124 的基础上将 forkid 计算扩展为同时支持区块号与时间戳使节点能快速识别并断开配置不兼容的 peer。每个节点维护两个值FORK_HASH创世哈希与已通过的 fork 区块号/时间戳的 IEEE CRC32 校验和[4]byte。fork 值按升序喂入校验和若多个 fork 在同一区块/时间激活该校验和只计算一次区块号与时间戳均按uint64大端编码参与计算。FORK_NEXT下一个即将到来的 fork 的区块号或时间戳uint64若无已知的下一个 fork 则为0不需要区分是时间戳还是区块号。EIP-6122 还给出了一个典型计算示例在 Homestead 之上引入一个时间戳1668000000的 fork其FORK_HASH为0xcb37b2ee即CRC32(genesis-hash || uint64(1150000) || uint64(1668000000))。两条补充规则值得注意按时间戳的 fork必须排在按区块号的 fork 之后主网与私有网络均适用对远端 peer 的 forkid 校验实现上需要先按区块号过滤再按时间戳过滤——因为所有基于区块号的 fork 都早于基于时间戳的 fork。该 EIP 还附带了完整的 Go 测试套件以主网配置、提款在时间1668000000启用、合并分叉区块在18000000为例逐区块验证FORK_HASH/FORK_NEXT的取值序列——从 Frontier 区块0一直到首个 Shanghai 区块{20000000, 1668000000, ID{Hash: checksumToBytes(0xc1fdf181), Next: 0}}以及主网节点在不同同步状态下对远端 forkid 的接受/拒绝判定如ErrRemoteStale、ErrLocalIncompatibleOrStale两类拒绝场景。这些测试是理解 forkid 语义与网络隔离行为的直接参考。五、设计动机为什么要回填 Hardfork Meta EIPEIP-7568 的 Rationale 部分阐明了回填的动机EIP 仓库在以太坊社区中广为人知Meta EIP 历史上在清晰列出某次网络升级包含哪些 EIP这件事上非常有效尽管执行层与共识层的规范流程各不相同但将每个升级在两层的 EIP 清单统一收录进同一个仓库能提供单一、协调的权威列表重新引入 Hardfork Meta EIP 还允许去重——当一个 EIP 同时影响执行层与共识层时无需在两个地方重复维护。本 EIP 覆盖的正是那些未使用Hardfork Meta EIP 的升级对 Muir Glacier 之前已经拥有 Meta EIP 的升级如 Istanbul、Muir Glacier 本身则无需回填。六、向后兼容与安全考虑EIP-7568 明确声明未发现向后兼容性问题No backward compatibility issues found安全考虑为空None。这符合 Meta EIP 的性质——它本身不修改任何协议规则只作为规范聚合与索引存在因此不会引入新的共识风险。其版权按惯例通过 CC0 放弃与仓库中其他 EIP 保持一致。结语一份可追溯的升级档案EIP-7568 的价值不在于引入新的协议逻辑而在于为以太坊从 PoW 过渡到 PoS 的关键历史阶段建立了一份可追溯、可引用的规范档案。无论你是客户端开发者、节点运维者还是协议研究者都可以通过它快速定位每个升级的权威规范出处并结合 EIP-6953 的激活机制表与 EIP-6122 的 forkid 规则完整还原何时、以何种方式、激活了哪些变更的全貌。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-7568 硬分叉元 EIP 回填全指南：从 Berlin 到 Shapella 的以太坊网络升级规范总览
EIP-7568 硬分叉元 EIP 回填全指南从 Berlin 到 Shapella 的以太坊网络升级规范总览【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-7568Hardfork Meta Backfill - Berlin to Shapella是 Ethereum 改进提案仓库中的一份 Meta 类 EIP它回填了 Muir Glacier 硬分叉之后所有未使用 Hardfork Meta EIP 记录的网络升级规范覆盖范围从 Beacon Chain 启动Serenity Phase 0一直延伸到 Shapella。阅读本文你将系统掌握 Berlin、London、Altair、Arrow Glacier、Gray Glacier、The MergeParis Bellatrix与 ShapellaShanghai Capella这七个网络升级的规范来源、激活机制演变区块号 → epoch → TTD → 时间戳以及它们与 EIP-6953、EIP-6122、EIP-2982 等提案之间的关联。一、背景Meta EIP 的沉寂与复兴在以太坊的历史上社区长期使用Meta EIP元 EIP来记录网络升级Hardfork所包含的具体变更清单。这类 EIP 扮演着升级总目录的角色让开发者与用户能够一目了然地知道某次升级会引入哪些协议变更。在Muir Glacier硬分叉之后这一做法被暂时放弃——网络升级改为通过其他方式如各客户端仓库中的network-upgrades目录追踪所包含的变更。而最近社区又重新形成了使用 Meta EIP 的共识。本 EIP 正是这一共识的产物它聚合了没有独立 Meta EIP的那些网络升级并逐一链接到它们的权威规范出处。作为参考仓库中仍保留着 Muir Glacier 之前最后一波 Meta EIP 的样例例如EIP-1679 Hardfork Meta: Istanbul列出了伊斯坦布尔升级包含的 EIP-152、EIP-1108、EIP-1344、EIP-1884、EIP-2028、EIP-2200并给出主网与各测试网的激活区块号EIP-2387 Hardfork Meta: Muir Glacier说明该升级在主网Block 9,200,000激活仅包含 EIP-2384难度炸弹延迟。EIP-7568 的定位正是延续这条线索把柏林到 Shapella 之间的升级规范回填进 EIP 体系。二、理解升级的关键激活机制的四次演变要读懂 EIP-7568 中罗列的各个升级首先需要理解以太坊网络升级激活机制的演变EIP-6953 Network Upgrade Activation Triggers 对此给出了权威的完整清单。1. PoW 时代按区块号触发在权益证明PoS之前以太坊网络升级以特定区块号作为激活触发器。EIP-7568 覆盖范围内的相关升级如下升级名称激活区块号Berlin12244000London12965000Arrow Glacier13773000Gray Glacier15050000这一机制贯穿 Frontier区块1到 Gray Glacier 的整个 PoW 时代其他著名升级如 Homestead1150000、DAO Fork1920000、Byzantium4370000、Istanbul9069000等也遵循同一模式。2. Beacon Chain按 epoch 触发Beacon Chain 的升级以特定 epoch激活。与后续升级直接相关的有升级名称激活 EpochAltair74240Bellatrix1448963. The Merge按 Terminal Total DifficultyTTD触发Paris 升级The Merge 的执行层部分由 PoW 总难度值58750000000000000000000触发具体规范见 EIP-3675。值得注意的是Beacon Chain 上 Bellatrix 升级的激活是 Paris 升级成功激活的前置条件。4. 合并后共识层 epoch 执行层时间戳The Merge 之后网络升级在共识层以 epoch 触发执行层则以时间戳而非区块号触发。这是因为 Beacon Chain 存在错过 slot 的可能执行层无法仅依赖区块号与共识层保持同步激活。相关参数升级名称激活 Epoch激活时间戳CapellaCL194048—ShanghaiEL—1681338455关键洞察在于epoch194048恰好发生在时间戳1681338455因此 Shapella 虽然执行层与共识层各用一个不同的常量却实现了两层同时激活。此外EIP-6953 还指出时间戳作为触发器导致节点FORK_HASH与FORK_NEXT的计算方式发生变化这部分由 EIP-6122 详细描述。三、逐项解读EIP-7568 覆盖的七个网络升级EIP-7568 的规范正文按激活顺序列出各升级并约定执行层Execution Layer升级标注为[EL]共识层Consensus Layer升级标注为[CL]。1. Beacon Chain Launch — Serenity Phase 0 [CL]Beacon Chain 启动时的完整规范位于ethereum/consensus-specs仓库的v1.0.0版本。同时EIP-2982 Serenity Phase 0 提供了 Beacon Chain 的设计背景与主网参数化理由属于理解 Phase 0 的必读材料。EIP-2982 记录的 Phase 0 关键参数包括参数值SPEC_RELEASE_VERSIONv1.0.0DEPOSIT_CONTRACT_ADDRESS0x00000000219ab540356cBB839Cbe05303d7705FaMIN_GENESIS_TIME1606824000BASE_REWARD_FACTOR2**664INACTIVITY_PENALTY_QUOTIENT2**2667,108,864PROPORTIONAL_SLASHING_MULTIPLIER1MIN_SLASHING_PENALTY_QUOTIENT2**7128启动条件方面EIP-6953 给出了 Beacon Chain 启动需同时满足的三个条件Beacon Chain 存款合约收到至少524288ETH来自16384个验证者超过MIN_GENESIS_TIME时间戳1606824000即 2020 年 12 月 1 日自最低验证者数量达标后已过去GENESIS_DELAY的604800秒。Phase 0 的设计核心是 Casper FFG最终性小工具与 LMD-GHOST 分叉选择算法验证者通过向主网存款合约质押 ETH 加入验证者集并履行区块提议、见证attestation等职责获取奖励该阶段不包含转账、分片或智能合约执行能力。2. Berlin [EL]Berlin 升级最初由 EIP-2070 Hardfork Meta: Berlin 作为 Meta EIP 起草但随后规范被迁移至ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/berlin.md文件EIP-2070 也随之转为 Withdrawn 状态。Berlin 于主网区块12244000激活。3. London [EL]London 升级所包含的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/london.md文件于主网区块12965000激活。这是引入 EIP-1559 手续费机制、EIP-3554 难度炸弹延迟等变更的重要升级。4. Altair [CL]Altair 是 Beacon Chain 的第一次升级完整规范位于ethereum/consensus-specs仓库的v1.1.0版本于 epoch74240激活。它引入了同步委员会sync committees、更轻量的轻客户端支持并对参与者的奖惩机制进行了调整。5. Arrow Glacier [EL]Arrow Glacier 升级的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/arrow-glacier.md文件于主网区块13773000激活主要内容是再次延迟难度炸弹。6. Gray Glacier [EL]Gray Glacier 升级的 EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/gray-glacier.md文件于主网区块15050000激活同样以延迟难度炸弹为主。7. The MergeParis BellatrixThe Merge 是第一个要求执行层与共识层协调的升级共识层先激活 Bellatrix随后执行层激活 Paris。Bellatrix [CL]完整规范位于ethereum/consensus-specs仓库的v1.2.0版本于 epoch144896激活。Paris [EL]EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/paris.md文件由 TTD58750000000000000000000触发见 EIP-3675且以 Bellatrix 激活为前置条件。The Merge 将执行层从 PoW 切换到由共识层驱动的 PoS 机制区块生产由验证者承担原有矿工奖励机制终结。8. ShapellaShanghai CapellaShapella 是第一个在执行层与共识层同时激活的升级。为实现这一点执行层的升级激活机制从按区块号改为按时间戳这一机制分别在 EIP-6953 与 EIP-6122 中描述。Shanghai [EL]EIP 集合规范于ethereum/execution-specs仓库的network-upgrades/mainnet-upgrades/shanghai.md文件于时间戳1681338455激活最核心的变更是引入 EIP-4895 的验证者提款。Capella [CL]完整规范位于ethereum/consensus-specs仓库的v1.3.0版本于 epoch194048激活负责配合执行层实现提款功能如 BLS 提款凭证转换。四、源码级佐证EIP-6122 与基于时间戳的 forkid 校验Shapella 从按区块号切换到按时间戳激活直接影响了 P2P 网络中节点的身份识别机制。 EIP-6122 Forkid checks based on timestamps 在 EIP-2124 的基础上将 forkid 计算扩展为同时支持区块号与时间戳使节点能快速识别并断开配置不兼容的 peer。每个节点维护两个值FORK_HASH创世哈希与已通过的 fork 区块号/时间戳的 IEEE CRC32 校验和[4]byte。fork 值按升序喂入校验和若多个 fork 在同一区块/时间激活该校验和只计算一次区块号与时间戳均按uint64大端编码参与计算。FORK_NEXT下一个即将到来的 fork 的区块号或时间戳uint64若无已知的下一个 fork 则为0不需要区分是时间戳还是区块号。EIP-6122 还给出了一个典型计算示例在 Homestead 之上引入一个时间戳1668000000的 fork其FORK_HASH为0xcb37b2ee即CRC32(genesis-hash || uint64(1150000) || uint64(1668000000))。两条补充规则值得注意按时间戳的 fork必须排在按区块号的 fork 之后主网与私有网络均适用对远端 peer 的 forkid 校验实现上需要先按区块号过滤再按时间戳过滤——因为所有基于区块号的 fork 都早于基于时间戳的 fork。该 EIP 还附带了完整的 Go 测试套件以主网配置、提款在时间1668000000启用、合并分叉区块在18000000为例逐区块验证FORK_HASH/FORK_NEXT的取值序列——从 Frontier 区块0一直到首个 Shanghai 区块{20000000, 1668000000, ID{Hash: checksumToBytes(0xc1fdf181), Next: 0}}以及主网节点在不同同步状态下对远端 forkid 的接受/拒绝判定如ErrRemoteStale、ErrLocalIncompatibleOrStale两类拒绝场景。这些测试是理解 forkid 语义与网络隔离行为的直接参考。五、设计动机为什么要回填 Hardfork Meta EIPEIP-7568 的 Rationale 部分阐明了回填的动机EIP 仓库在以太坊社区中广为人知Meta EIP 历史上在清晰列出某次网络升级包含哪些 EIP这件事上非常有效尽管执行层与共识层的规范流程各不相同但将每个升级在两层的 EIP 清单统一收录进同一个仓库能提供单一、协调的权威列表重新引入 Hardfork Meta EIP 还允许去重——当一个 EIP 同时影响执行层与共识层时无需在两个地方重复维护。本 EIP 覆盖的正是那些未使用Hardfork Meta EIP 的升级对 Muir Glacier 之前已经拥有 Meta EIP 的升级如 Istanbul、Muir Glacier 本身则无需回填。六、向后兼容与安全考虑EIP-7568 明确声明未发现向后兼容性问题No backward compatibility issues found安全考虑为空None。这符合 Meta EIP 的性质——它本身不修改任何协议规则只作为规范聚合与索引存在因此不会引入新的共识风险。其版权按惯例通过 CC0 放弃与仓库中其他 EIP 保持一致。结语一份可追溯的升级档案EIP-7568 的价值不在于引入新的协议逻辑而在于为以太坊从 PoW 过渡到 PoS 的关键历史阶段建立了一份可追溯、可引用的规范档案。无论你是客户端开发者、节点运维者还是协议研究者都可以通过它快速定位每个升级的权威规范出处并结合 EIP-6953 的激活机制表与 EIP-6122 的 forkid 规则完整还原何时、以何种方式、激活了哪些变更的全貌。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
