合并前夜 回顾以太坊协议层的七年之变
回溯历史，通往“世界计算机”的每一步都印在那密密麻麻的code里。
作者：freeyao
什么是以太坊
什么是以太坊？一千个人有一千个答案，而本文想探讨的是最为一致的答案，即以太坊的协议是什么？或用更技术地描述——如果要开发以太坊的客户端(PoW链/ETH1)，我需要依照什么规则？
你没法找到一份规范描述以太坊当前的共识规则，因为以太坊的协议是通过增量更新来描述的。以太坊黄皮书描述了创世时的完整协议，而每一次协议变更都称为一次硬分叉(当然，也有人尝试用「网络升级」这个表述)，需要所有的客户端更新代码。简而言之，以太坊通过硬分叉来实现协议层的变化，变化的最小单元被称为以太坊改进提案(EIP, Ethereum Improvement Proposal)，一次硬分叉包含一组以太坊改进提案。 本文将回顾以太坊的历次硬分叉及其中包含的改进提案，试图展现过去的七年中以太坊究竟做了什么。
历次硬分叉介绍
概况
以太坊的历次硬分叉可以通过此页面查看。自 2015 年 7 月30日上线起，共进行了 14 次硬分叉，包含 39 个 EIP（「君士坦丁堡」和「彼得堡」视为同一次）。间隔最近的两次硬分叉是 26 天，间隔最远的两次则是 490 天。
硬分叉分为「主动升级」和「被动升级」。主动升级指的是开发团队主动对以太坊协议的修正，而被动升级则是「不得不」采取的行动，以应对潜在的安全性风险。被动升级至少包括「DAO Fork」、「Tangerine Whistle」、「Spurious Dragon」、「Muir Glacier」、「Arrow Glacier」、「Gray Glacier」，它们或处置黑客盗窃(DAO Fork)，或应对 DDOS 攻击(Tangerine Whistle, Spurious Dragon)，或仅仅处置难度炸弹(Muir Glacier, Arrow Glacier, Gray Glacier)。而「主动升级」大致符合白皮书的规划（至少在命名上），Frontier(Frontier, Frontier Thawing)、Homestead、Metropolis(Byzantium, Constantinople/Petersburg, Istanbul)，而 Berlin 和 London 则是以太坊路线图变更后的过渡性升级。此外，多次主动升级也包含了推迟难度炸弹的选项。
硬分叉是如何达成共识的呢？尽管关于硬分叉的协商并无成文规定，而是依照某种社区惯例进行，但其流程发生过一次变更，标志性事件是 Martin Holst Swende 提出了「以 EIP 为中心的升级」。这种新的硬分叉协商机制首次在 Berlin 升级使用，并避免了一次大型失误，细节将在后文中介绍。
代表性硬分叉解读
历次硬分叉背后蕴含着一些代表性事件，颇具戏剧性，包括 DAO 分叉、上海 DOS、双堡奇缘和拆弹危机。
DAO 分叉
DAO 分叉事件是以太坊发展过程中最为深远的一次事件。由于 the DAO 的智能合约被黑客攻击，约 360 万 ether 被黑客盗走，但有 28 天的冻结时间。在这期间，借助 Carbonvote ，持币者表达意愿，以太坊基金会决定将这部分资金转移到新的智能合约，允许投资者提款。此次分叉产生了 Ethereum Classic，也引发了大量的社会争论。
上海 DOS
在 Devcon 2 期间，以太坊核心开发者们齐聚上海，但以太坊网络却遭遇了大量的网络流量攻击，造成了拒绝服务(DOS)。由于 EXTCODESIZE 操作码所消耗的实际系统资源远高于攻击者所需支付的手续费，攻击者反复调用该操作码，造成全网大多数节点无法追上最新区块。开发者们一面协调矿池和全节点启用受影响较小的 Parity 客户端，一面协商降低区块 gas(从 5 M 降低至 1.5 M)。最终，借助 Tangerine Whistle 和 Spurious Dragon 两次硬分叉调整了相关操作码的价格，并做了状态清理，才缓解了 DOS 攻击的影响。这次硬分叉还带来了后续影响，由于对 EIP-161(纳入在 Spurious Dragon 中)的实现不当(Go-ethereum 和 Parity 各自错误地做了实现)，造成了共识分叉。
双堡奇兵
你也许会好奇为什么在 7280000 高度会有「君士坦丁堡」和「彼得堡」两个分叉，仔细观察会发现两者的差别就在于「彼得堡」移除了 EIP-1283。
根据ChainSecurity 的报告，EIP-1283 会为部分合约引入重入攻击的风险。TrailOfBits 给出了更详尽的分析并提供了可能受影响的合约列表。在硬分叉激活前 32 小时，以太坊基金会发文提醒节点升级或降级以推迟君士坦丁堡升级，随后发布新版本引入彼得堡硬分叉，客户端需要将「双堡」配置在同一块高或禁用君士坦丁堡硬分叉。
拆弹危机
为什么 Muir Glacier 和 Istanbul 两次硬分叉之间只有 26 天，这是因为核心开发者们错误计算了难度炸弹的爆炸时间，导致在 Istanbul 中未纳入推迟难度炸弹的提案。等到发现难度炸弹即将要对网络产生影响时，第 76 次核心开发者会议迅速接受了 EIP-2384，并纳入到 Muir Glacier 硬分叉中。
硬分叉决策流程变更
硬分叉是如何决定的？实际上以太坊长期缺少成文文档，更多依赖「社会共识」（如果我错了请改正）。EIP-233 试图规范分叉的正式流程，但并未被接受。
尽管本文无法展现以太坊社区对硬分叉决策流程的讨论，但以太坊的硬分叉决定流程显然发生过变化。在 Berlin 硬分叉之前，开发者首先确定硬分叉的时间，再决定要纳入哪些 EIP，确定之后再进行实现和测试。Berlin 前的每次硬分叉都是一个 Meta EIP，例如 Istanbul 硬分叉通过EIP-1679定义(简称 HFM-1679)。
Martin Holst Swende 提出了EIP 为中心的硬分叉流程，其核心观点是将 EIP 的接受与硬分叉剥离，核心开发者聚焦于单个 EIP 的认可、实现和测试，当单个 EIP 被接受后，后续的硬分叉可选择纳入该 EIP。尽管在写作过程中尚未找到该流程是如何被以太坊核心开发者接受的，但是 Berlin 硬分叉弃用了HFM-2070，而是采纳了 Martin 提出的流程。
决策流程的变更很快就发挥了作用，在 Berlin 硬分叉测试网激活前两周，围绕 EIP-2315 的废留，开发者们展开了激烈的争论并最终移除了 EIP-2315 。由于新流程的采纳，最后时刻的变更并未对硬分叉造成太大影响，并最终按期进行。更多细节可参考本人撰写的《移除EIP-2315:以太坊柏林升级前的紧急刹车》
不是改变的改变
值得一提的是，以太坊的区块空间上限(Block gas limit)并非共识的一部分。矿工有权更改区块空间上限，每个区块的上限变化最多为 0.1%。不去硬编码这个数值主要是为了避免潜在的攻击风险。该数值变化的历史可参见 MyCrypto 撰写的研究报告。