回顾以太坊历史发展过程中的标志性事件，从源头开始理解以太坊「从何处来，到何处去」。

演讲：沙漏时间

整理：Amber

今天的分享主题主要还是围绕着以太坊历次的升级回顾展开的，但在进入正式的讨论之前，先分享对这次活动的一些感想：围绕以太坊和上海的关系这样一个符号举办活动虽然很有意义，但可能有些小题大做，因此最初的分享内容也更多围绕技术本身，而非以太坊的「历史与文化」，毕竟对于一个新兴的行业来说，因为太多事物需向前方追寻，而使得大家并没有太多时间去追忆整个行业的往事。然而对早期从业者而言，他们仍有责任提示「我们从哪里来，到何处去」。这种向着终点的往复循环的探寻，大到社会环境，小到个人命运，都离不开行业浪潮中波浪式前进的发展历程。

诗人艾略特在荒原的开头写到，4 月是最残忍的月份。一年前的今天，上海也进入了一个很特别的时期，也是从那时开始有很多的人逐渐理解以太坊、 Crypto 这些技术背后蕴含的一些「神秘」力量。以太坊和上海在那一刻建立起了超越物理空间的连接。关于感慨的部分到此为止，以下将正式开始关于以太坊历程的回顾。

全部分享内容包含三个部分。第一部分，简单介绍以太坊「是什么」；其次，是谁「定义」了以太坊，即是谁促成以太坊的升级，以及以太坊升级后的样子；最后则是回顾以太坊历史发展过程中的标志性事件。沙漏时间在去年写了一篇文章，叫《以太坊协议层的 7 年之变》，提及了本次分享当中的大多知识性内容。

追本溯源：以太坊是什么

首先，关于以太坊是什么？一千个人心中有一千个哈姆雷特。比如以太坊基金会，在官网上就使用了这样的表述，以太坊是社区运行的加密货币 ETH，以及数以千计的去中心化应用社区的底层技术。而如果使用更技术化的语言，又应当怎样描述以太坊协议呢？又或者说，作为一个开发者，应依据什么规则来进行代码创作，从而进行以太坊客户端开发呢？其实在合并之前，并没有一套规范来描述以太坊的共识机制，它是通过黄皮书，即启动时的技术规范，再叠加增量来实现所谓「共识」的定义，增量的具体表现形式，被称为以太坊改进提案（EIP，Ethereum Improvement Proposal）。

对于开发者而言，如果希望成为以太坊的一部分，或者说成为以太坊本身，就需要运行一个「全节点」，启动全节点之后，开发者就正式成为了以太坊的一部分，要做的就是遵循共识协议，那么共识协议对全节点的不同技术实现的具体展现形式，就是不同的客户端，包括大家熟知的 Geth、Parity 等等。

而维护这些客户端的人，就是一部分以太坊核心开发者，他们的主要工作就是保障以太坊客户端的安全、稳定运行以及性能优化。除此之外还包括实现新功能，这些功能主要就是通过刚才提到的 EIP 这个形式来呈现。EIP 的全称就是以太坊改进提案，描述了以太坊的平台标准，包括核心协议的规范、客户端 API、以及合约层面的标准。EIP 的起源，受 RFC-2119 的启发，也借鉴了比特币的第一份提案 BIP-001。

到这里就有一个很有趣的问题，谁可以去编写 EIP 呢？ 大家常会听到一些名词，比如 EIP-1559，或者 EIP-2938 等等，这些编号又是从何而来呢？其实任何人都能编写 EIP，根据 EIP 所需要遵守的技术规范，直接在 GitHub 平台上发起一个提案。然而实际上，被合并到升级过程中的 EIP 总量不过只有 1% 左右，大部分的 EIP 并不会受到广泛的关注和讨论，更不会走到升级这个过程当中。

抽丝剥茧：谁定义了以太坊

经过第一部分，我们大体形成了对以太坊的一个基本认识，接下来的分享将来到以太坊是如何进行升级的？这里可能包含三个问题，第一个问题是谁有权利决定以太坊的升级？第二个问题是以太坊的升级意味着什么？第三个问题则是以太坊升级的具体流程是什么？

可能有一种广泛的误解，认为以太坊的发展和升级，是由以太坊基金会决定的，不管事实到底怎样，至少基金会并不这么认为。以太坊基金会在自己的网站上说他们就是一个注册在瑞士的非盈利组织，他们不控制以太坊，也并非资助以太坊发展的唯一机构，它只是这个巨大生态当中的一个成员。

真正进行以太坊升级决策，或者说以太坊的权力机构，是一个叫做「以太坊核心开发者会议」的组织。这个权力机构负责决议，EIP 是否被纳入升级，是否需要进行路线图变更等重要事项。

那么这里又产生了一个问题，到底谁是核心开发者？之前提到的客户端开发者是核心开发者，底层协议的开发者、研究者也是，那么其他人到底谁可以声称自己是核心开发者呢？根据以太坊早期核心开发者会议的早期协调人 James Hardison 文章中的观点，他强调核心开发者是目前为以太坊底层协议作出重大贡献的人，值得注意的是，他强调的是「当前状态」，这也就意味着开发者过去作出的贡献，并不能决定当下的自己是核心开发者中的一员。然而这一定义也并没有明确的判别标准，所以 Hardison 本人也说，并没有人可以决定谁更适合进入核心开发者行列， 主要判别依据还是个人的贡献与名誉。所以这里一个有意思的点是，声称自己是以太坊的核心开发者其实没有问题，理论上也不存在证伪，但是对参与者个人贡献和名誉会有一个社区层面的判断。

第二个问题是升级意味着什么？一次以太坊的升级，比如上海升级意味着什么？它意味着从某个区块开始，或者从某个时间开始，以太坊将会有一些变化，这个变化可能是新的功能，可能是一些参数的调整，或是安全补丁。它也意味着所有的全节点必须去升级客户端，否则将无法进行网络同步，这也就是所谓的硬分叉，即所有节点必须接受升级，否则将无法在这个网络下进行和他人的协同。同时在反面，它也意味着潜在的安全风险，因为代码的改变，它虽然经过完善的审计，仍然有可能在设计上或者在工程实现上产生一些问题。

毕竟影响着一个价值几千亿美元的网络安全，所以为了以太坊网络的效率以及升级的安全性，必须要有一套严谨的流程。但实际上，关于以太坊的升级，或者说硬分叉的决策，长期以来是缺少一个相关的文档的，更多的依赖于一种所谓的「社区共识」，也就是说「社会共识」。曾经有一个 EIP-233，试图去规范硬分叉的正式流程，但这个 EIP 最终并没有被接受。

虽然无法在分享过程中完整地展现整个社区对这个流程的讨论，但显然，这个流程曾经发生过一次重大的变化。这个变化的时间点就是在柏林升级（2021 年 3 月）前后。柏林升级之前，硬分叉的流程，首先是要开发者选择升级的时间，升级所要包含的 EIP，然后大家开始花大量时间讨论这些 EIP 相关的问题，比如，是否采纳 A 或者 B，A 与 B 是否有冲突，谁的优先级更高，工作量有多大，在这里就会出现很多问题。

第一个是大量的时间要用来讨论，升级需要包含哪些 EIP，这里面有大家对重要性的认识是不一致的，也有社区在应用和发展中会不断变化，导致升级的流程缺少完整的测试，缺少跨客户端的测试，正如之前所说，对协议的不同实现会产生不同的客户端。所以一旦有一个 EIP 的实现拖了后腿，整体的进度就会受到个体的影响。所以在此之前的两次升级间隔的时间长达一年多。那时 Geth 的工程师，同时也是以太坊基金会的安全专家 Martin Swende，提出了一种新的流程，也就是以 EIP 为中心的升级流程。

在这个新的流程下，首先在核心开发者会议（简称 ACD）上初步接纳一个 EIP，然后客户端团队无论该 EIP 被纳入升级与否，都对其进行测试，并在最终测试完后进行再一次回顾。核心开发者因此只需要聚焦于 EIP 本身，并在开发之前完成所有测试，从而减少正式升级过程中的工作。虽然存在 EIP 完成了所有流程，但最终没有被纳入升级的情况，但总体来讲升级流程的效率得到了极大改善。

而在柏林升级时出现了一个很严重的事故，沙漏时间也曾写过一篇名为《移除 EIP-2315：以太坊柏林升级前的紧急刹车》。关于 EIP-2315 是否要纳入柏林升级，其实在核心开发者会议上一直没有被最终确认，因而产生了一些误会。在 2 月 19 日的 ACD 第 106 次会议上，被纳入了柏林升级，但在两周后，核心开发者 lightclient 建议移除 EIP-2315，原因在此不多赘述，总之，核心开发者在仅仅两天内对达成一致，并在第 107 次会议上，决定移除 EIP-2315。但是由于整个开发和测试的流程是围绕着 EIP 展开的，所以移除某个 EIP 只是相当于关闭一个开关，并不会影响整个升级流程，测试网和主网升级计划并没有被打断。如果上述问题出现在之前的升级，那么这次升级是肯定会被推迟的。

温故知新：以太坊世纪历史

到这里，对以太坊是什么以及以太坊如何升级进行了初步的介绍，累计的知识可能有些枯燥，下面则是故纸堆中，以太坊历史上的代表性升级案例。值得注意的是，这里包含的以太坊历史上的升级，讲的都是 The merge 之前，也就是以太坊转向 PoS 之前的数据。从 2015 年 7 月 30 日以太坊上线开始，到 The merge 之前，一共进行了 14 次硬分叉，包含了 39 个 EIP，间隔最近的两次硬分叉是 26 天，间隔最远的两次则是 490 天。而关于升级名称的来源，比如柏林，伦敦，上海等等，其实都是来自于举办 Devcon 的城市。Devcon 0 在柏林，Devcon 1 在伦敦，Devcon 2 在上海。那么接下来则是墨西哥的坎昆。

从大的方面来说，硬分叉包含了两种类型，一种是主动的升级，另一种是被动的升级。主动升级就是开发团队主动引入一些以太坊的新功能，或者说对现有性能进行提升。而被动升级则是不得不采取的行动，主要是要去应对潜在的安全风险。之前所提到的 14 次升级中，被动的至少包括 DAO Fork、Tangerine Whistle、Spurious Dragon，以及三次 Glacier 也就是推迟难度炸弹。它们或处置黑客盗窃，或应对 DDOS 攻击，或仅仅处理以太坊难度炸弹。主动升级则是大致符合白皮书的规划的四个阶段：Frontier、Homestead、Metropolis 和 Serenity，而柏林和伦敦两次升级有一些特别，更多的是在以太坊调整路线图之后过渡性的升级。

下面的部分将主要介绍 4 个在以太坊升级过程中极具戏剧性的代表事件。

DAO 分叉（DAO Fork）

DAO 分叉事件是以太坊发展过程中最为深远的一次事件，引发了社区讨论甚至分裂。The DAO 智能合约被黑客攻击，黑客大概到盗走了 360 万个 ETH，但这些 ETH 并不能被直接转走，期间有约 28 天的冻结时间。

这 360 万个 ETH 因为金额很大，对整个社区来说，是一个非常大的事件。参与者当时可以通过一个叫做 Carbonvote 的网站，通过手中的 ETH 投票表达意愿，最终基金会决定这部分钱转移到新的智能合约中，相当于修改了交易历史，将这部分 ETH 从黑客手中夺回。这次分叉也产生了大家熟知的 ETC（Ethereum Classic），引发了大量的社会争论。

上海 DOS

第二次则是和上海有很紧密的联系，是在 Devcon2 期间，以太坊核心开发者齐聚上海，当时的以太坊网络遭遇了严重的拒绝服务攻击。简单来说就是黑客可以使用很少的成本让整个以太坊网络中的节点付出和成本不相符的计算资源，所以最后每个节点都无法同步这个网络的最新状态。

那么开发者采取的措施是使用受影响较小的 Parity 客户端进行调整，降低了区块 gas 上限，从而缓解了这次事件的影响。最后通过两次硬分叉来从根本上消除这次 DOS 的影响。

君士坦丁堡和彼得堡

第三次事件则是，当回顾这些硬分叉相关的历史，会发现 7280000 高度有「君士坦丁堡」和「彼得堡」两个分叉，仔细对比发现后者相较于前者移除了 EIP-1283。在升级之前，根据一些安全机构的分析，EIP-1283 可能为一些智能合约引入名为「重入攻击」的风险。所以在这一次升级前的 32 小时，以太坊基金会就提醒节点升级或降级以推迟君士坦丁堡升级，最终通过引入新版本，并将两次升级放在同一高度，以消除 EIP-1238 的影响。

拆弹危机

最后一次比较有代表性的事件是关于一次难度炸弹的处置，由于开发者错误地计算了难度炸弹的爆炸时间，导致了 Muir Glacier 与伊斯坦布尔两次硬分叉之间的间隔只有 26 天。由于伊斯坦布尔升级已经确定，节点已然更新到这个版本，所以只能再引入一次升级进行难度炸弹拆除。难度炸弹在以太坊发展过程中曾经扮演过非常重要的作用，但也带来了很大的困扰。

说完这些戏剧性事件，对过去 7 年的以太坊（主要是 The Merge）之前进行一个总结。

首先是数据层面，共有 39 个 EIP 纳入了 14 次升级中，共 43 人，77 人次参与了 EIP 的撰写，其中参与 2 个以上 EIP 撰写的开发者共 11 人。Vitalik Buterin 参与撰写的最多，共 17 个，Martin Swende 和 Christian Reitwiessner 各参与 5 个。Martin Swende 是基金会的安全负责人，也是上文提到的 EIP 为中心的升级流程的作者。Christian 是 Solidity 的发明者之一。

另外一个比较有意思的事情是，在这个新的流程实施之后，这些被纳入升级的 EIP 的作者的数量发生了一个比较大的变化，这或许说明这个新的流程提高了 EIP 的参与度。在柏林之前，平均每个 EIP 的作者数量只有 1.54，在柏林之后，这个数量增长了一倍。

在数据之外，还有一些比较有意义的点。共有 6 个 EIP 在推迟难度炸弹，超过 40% 的核心开发者会议（ACD）包含拆除难度炸弹讨论，50% 的升级包含了难度炸弹提案。有两次硬分叉伴随经济模型的调整，降低新区块的奖励。有 3 次名字里带有 Glacier 的硬分叉升级仅仅是为了推迟难度炸弹。有关难度炸弹的历史，可以参考原语里弄的报告。

还有最后的两点：第一，这些 EIP 的作者都是实名的；第二则是以太坊 2.0（The Merge）的路线图变更，并不是在 ACD 上提出的，而是在共识层会议上得出的，因此并没有以 EIP 的形式表述。

以上就是对以太坊历史的总结，最后还想化用艾略特的诗作个结尾。风吹的很轻快，吹送我回家去。以太坊的小孩，你在哪里逗留。

谢谢大家！很高兴有机会和大家分享。那接下来时间交给主持人，然后一会儿的圆桌还可以和大家再进行沟通，谢谢大家。