以太坊主网也曾迟到，回顾历史上的升级延期事件

在区块链领域，以太坊无疑是最具影响力的平台之一，它以其智能合约功能和不断演进的路线图，吸引了开发者和用户的广泛关注，近年来，随着以太坊向“以太坊2.0”（现称“合并”后的发展阶段）的转型，社区对于主网升级的期待与讨论日益增多，一个常见的疑问也随之浮现：以太坊的主网升级是否也曾像其他项目一样,有过推迟的历史？

答案是肯定的，以太坊主网的升级并非总是一帆风顺，历史上曾多次出现推迟的情况，这些延期并非技术失败的标志，反而恰恰体现了以太坊社区去中心化、审慎和追求安全至上的核心文化。

为何以太坊升级会推迟？

在探讨具体案例之前，我们首先要理解以太坊升级的特殊性，与许多中心化项目的“硬切换”不同，以太坊的升级（如“伦敦升级”、“柏林升级”等）是通过“硬分叉”（Hard Fork）实现的，这意味着所有节点（包括矿工、验证者、交易所、钱包服务商等）都必须在特定的时间点前，同步升级到新的客户端软件，如果某个环节出现问题,就可能引发网络分裂或安全漏洞。

以太坊核心开发者社区在推动升级时，始终将网络的安全性、稳定性和社区的共识放在首位，任何可能导致不确定性的因素，都足以成为推迟升级的理由,主要原因通常包括：

客户端软件的Bug：不同的以太坊客户端（如Geth、Nethermind、Prysm、Lodestar等）由不同团队开发,在测试过程中可能发现未预期的兼容性问题或安全漏洞。
测试网验证不充分：升级在正式上线前，会先在测试网（如Goerli）上进行多轮模拟，如果测试网未能完全复现主网环境或出现问题,升级就会被推迟。
社区共识未达成：尽管不常见，但如果某个关键提案存在巨大争议，核心开发者可能会选择推迟,以争取更广泛的社区支持。
外部依赖风险：升级可能依赖特定的外部服务或工具，如果这些工具出现问题,也会影响升级进程。

历史上的著名延期案例

以太坊历史上最著名的一次延期，莫过于“君士坦丁堡”（Constantinople）升级。

“君士坦丁堡”升级的两次延期

“君士坦丁堡”升级原计划于2018年10月进行，它包含多个重要的以太坊改进提案（EIPs），旨在优化网络性能、降低交易费用,并为后续的PoS转型铺路。

第一次延期：在升级前的测试中，开发者发现其中一个关键EIP（EIP 1234）在实现上存在可能导致“区块重组”的潜在风险，区块重组会破坏区块链的不可篡改性，是绝对不能容忍的，为了彻底解决这个安全隐患,核心开发者决定将升级推迟至2019年1月。
第二次延期：在2019年1月的测试中，问题再次出现，开发者在另一个客户端软件中发现了类似的漏洞，尽管该漏洞影响范围较小，但本着对安全极致负责的态度，社区再次做出了推迟升级的决定。“君士坦丁堡”升级在2019年2月安全上线。

这次延期事件生动地展示了以太坊社区的行事风格：宁可慢，不可错，它向世界表明,以太坊的发展不会为了追赶时间表而牺牲其最核心的安全基石。

“伦敦”升级的惊险一刻

2021年7月的“伦敦”升级是另一个值得关注的案例，这次升级成功引入了备受期待的EIP-1559，彻底改变了以太坊的Gas费机制，在升级前夜,社区也曾一度面临紧张时刻。

在最后的测试网验证中，开发团队发现了一个潜在的同步问题，可能会影响部分节点的正常切换，虽然经过紧急讨论，团队认为风险可控，并最终按时完成了升级，但这一插曲再次凸显了在升级窗口关闭前,任何一丝疑虑都会被置于聚光灯下进行严格审视。