ETH的困境】为什么商用API在君士坦丁堡硬分叉中挂了？CEO发
image
BlockCypher是知名的区块链API开发商，基于BlockCypher的API，开发者和大型企业，能更容易的开发及采用区块链技术。BlockCypher在2018年曾获得300万天使轮融资。
3月12日，BlockCypher的CEO Catheryne发表文章：讲述了BlockCypher在ETH君士坦丁堡硬分叉中的遭遇、经验及教训。
原文链接：https://blog.blockcypher.com/ethereum-woes-d9b2af62da67
翻译如下：
由于君士坦丁堡硬分叉，BlockCypher的以太坊API，挂了（不能运行）将近一个月。这份验尸报告（夸张的语言，表达了CEO的愤怒）解释了所发生的事情、经验教训，以及我们正在采取哪些措施来防止将来再发生类似的事故。
提前规划君士坦丁堡硬分叉，居然有错？
以太坊在2018年12月中旬，宣布他们的君士坦丁堡硬分叉（Hard Fork——HF）将于2019年1月15日发布。
以太坊开发商表示“即将到来的硬分叉将是以太坊历史上最不重要的一个。”我们不同意这个看法：因为，受硬分叉影响的有数百个源文件。遵循以太坊协议概述，我们开始主动遵循他们的指示，这也涉及修改我们的备份存储。
我们在圣诞假期工作，并在2019年1月的第一周完成了这些工作。
我们以为我们准备好了。
1月8日：有些事情严重错误
1月8日晚，我们意识到我们的以太坊状态（ Ethereum state ）出了问题，但不知道是什么：唯一知道的是我们得到的错误是：缺少一些小数据块。以太坊状态是不可思议的 - 所有数据都存在一个哈希树中 - 这使我们无法弄清楚到底出了什么问题。
尝试了多个恢复程序但都没成功。我们不断收到丢失数据的错误（一个Trie节点）。
多次发现错误并尝试恢复丢失的数据都失败后，我们开始了“快速”同步：完成“快速”同步需要2天时间。不幸的是，它并没有帮助我们恢复丢失的数据，也没有恢复我们的状态。
对于如下这些问题，我们回答如下：
1.为什么快速同步不起作用？
因为它只包含整个区块链数据的一小部分。为了可靠地提供和运行我们的API，我们需要所有这些数据。
2. 为什么我们在做君士坦丁堡硬分叉更新之前，没有对我们状态（state）进行备份？
我们做了，但它被恢复部分破坏了。此外，以太坊状态不是可以简单地备份和修补的数据库。而且，当以太坊节点在线时无法完成备份，状态备份不能以递增方式完成（并且状态数据远远超过1兆兆字节）。
（经验教训№1：以太坊状态与其他区块链非常不同。使用任何传统备份方法都无法恢复。）
漫长的全同步行军开始了
作为最后一招，我们在1月12日开始了2+TB 的Ethereum状态的“完全”同步（2 TB = 2048 GB，数据量巨大）。因为明了必须应对的数据量大小，我们升级到最大可用机器，试图让同步更快。但这几乎没带来改变，反而使我们的问题更加复杂——因为整个流程不具备透明度——这是因为我们不知道在升级中的状态，并且没有信息来更新客户的数据。
我们无助地等待和检查。
1月14日 - 君士坦丁堡硬分叉计划生效的前一天——它却被取消了。安全审计发现了一个漏洞，可能允许潜在的攻击者从智能合约中窃取加密货币。最后一刻的取消令我们非常沮丧。如果我们在君士坦丁堡硬分叉生效之后再采取行动，就会为自己节省大量的工作、焦虑、费用…….而且我们的ETH API一直都在工作。
（经验教训№2：不要提前计划以太坊升级。等它们生效后再采取行动。）
两周后，我们了解到“完全”同步并不是真正的全状态恢复。
2周以后，我们的以太坊状态得以恢复，但这并没有结束我们的困境。
事实证明，完全同步默认为不包括完整的Trie状态。如果正在进行完全同步，为什么默认设置不包含所有内容？这违背了逻辑。我们的下一个挑战是弄清楚如何将Trie状态添加到我们的“完整”状态。
Vitalik，帮帮忙！
在检查了能想到的将Trie状态添加到以太坊状态的每一种方式之后，我们向Vitalik寻求帮助。
他对我们的第一个评论是“哦，你是少数几个运行巨大而可怕的节点之一。（oh you’re one of the few running one of those big, scary nodes.）”
我们问他是否知道还有人在运行一个“大而可怕的节点”，看看我们是否可能同步他们。他知道没有人，甚至以太坊基金会都没有完整的以太坊链档案。
**我们回到原点：再次启动完全同步，这次包括Trie状态。 **
（经验教训№3：如果链重组，我们可能是唯一知道以太坊交易历史的人）
如何防止这种情况再次发生？
只有ETH API挂了。我们的其他区块链API都继续按预期正常工作。
我们清楚地知道，以太坊状态与任何其他区块链非常不同：没有可靠的回滚块，没有直接的状态恢复，也没有备用状态的方法。
一旦我们恢复，问题就变成了：我们如何防止客户中断？
A. 简短的方案是：从现在开始，我们将等到以太网升级生效后，再升级备份，并提前计划停机。
B.复杂一些的方案是：我们已经放置了多个冗余来连续复制交错状态，这样我们就不会（knock on wood把霉运敲掉）再次进行完全同步。
正如多次看到的那样，区块链经历了成长的痛苦。有些人比其他人更痛苦，我们在君士坦丁堡硬分叉中获得了非常痛苦的教训。硬分叉实际发生在2月28日，生效后一切变得很容易！
总结：以太坊每次硬分叉，对技术供应商，风险都比较大，需要小心应对！！
谢谢您的阅读！谢谢！_
币乎主页：爱莉莎
微信公众号：竹三七
【币圈金马奖】和你一起走币圈这条光明大道
image
「力场 lichang.io 」公链挖矿第一社区！
