EOS.IO 开发团队 Block.One 于 2019 年 5 月 15 日发布了 1.8.0-rc2 的 EOS.IO 版本，这是 EOS.IO 开源以来最重要的版本，将奠定 EOS.IO 今后通过硬分叉升级快速迭代的基调，也会让整个区块链行业重新审视硬分叉升级的重要性。同时，所有的用户，钱包，交易所，DAPP 都会受到影响。

原文标题：《EOS.IO 将迎来史上最复杂硬分叉升级，硬分叉的流行意味着什么？》
作者：孤矢，EOS 原力创始人

孤矢，EOS 原力创始人

2019 年年初，一些媒体开始报道 EOS.IO 代码提交次数下降的问题，我们 EOS 原力团队曾经公开回应过：EOS.IO 每天都有多个开发者在提交代码，这些开发内容在不同的分支里提交，并且需要经过测试以后再合并到主线。今天我们要提到的 1.8.0-rc2 就是此类情况，从 2019 年年初甚至更早就开始进行了开发，直到 2019 年 5 月 15 日 1.8.0-rc2 发布。

接下来我们将详细解释此次更新何以如此重要。

• 版本号：1.8.0
• Github：https://github.com/EOSIO/eos/releases/tag/v1.8.0-rc2

一、1.8.0-rc2 有哪些重要的改进

1 扩展性提升与代码重构

在这个版本中我们看到了大量的提交 , 主要集中在代码重构和线程安全化两个方面 :

首先的代码重构 , 很多人往往不关心这些既没有增加功能也没有提升性能的代码修改 , 但是从开发的角度看 , 这些其实构成后续开发的重要基础 , 我们可以看到 , 自年初以来 , Block.one 的核心开发者一直在改善 EOS.IO 的代码结构 , 并且从设计层面上逐步在建立一个抽象层 , 最明显的是 EOS.IO.cdt 的完善 , 这些构成了 EOS.IO 的框架 , 不同于很多在一开始就给出了庞大架构的团队 ，Block.one 的开发团队一贯以务实且自低向上的思路开发 EOS.IO。

在 1.8.0 版本中 , Block.one 的开发者拆分了很多之前的巨无霸类型 , 剥离了散落在各处的一些复杂逻辑 , 比如 `pending_block_state` 相关的状态管理 , 就从 `block_header_state` 中剥离出来 . 还有之前略带“坏味”的 transaction traces, 也在这次重新整理。

另一个方面是关于多线程 , 在最近一段时间有很多关于线程安全性的提交，为下一步实现多线程相关开发做准备，Block.One 团队在 2019 年的开发中对多线程非常重视，此次重构后将很更好的实现 EOS.IO 白皮书里描述的多线程，届时 TPS 会上升到一个新的台阶。

众所周知 , 中大规模 C++软件的多线程开发一直是一个“深坑”, 为了在引入并行计算的同时保证 EOS.IO 的稳定性 , Block.One 团队并没有急于进行多线程相关新特性的开发 , 而是耐心的排查代码中的线程安全问题 , 完善基础架构支持 , 同时在特定的适合并发的独立模块 , 如 chain api 以及 p2p 模块引入对应的多线程实现。

2 提升链安全性

在这个版本中 , Block.One 团队修正了之前遗留的一些资源计算问题 , EOS.IO 中资源相关的逻辑很多 , 并且极为分散 , 为了提升链性能并避免节点进行不必要的计算 , EOS.IO 中添加了很多资源相关的特化逻辑 , 这也造成了很多特定场景下用户资源计算的不明确 , 对于 EOS.IO 链来说 , 这带来了很多起潜在的安全性问题 , 前一阶段暴露的由延迟交易所触发的阻塞交易问题 , 很大程度上就是资源检查不完备的问题。

另外 , 某些场景下资源计算的问题也会导致用户权益上的损失 , 所以这方面的修改势在必行。

3 智能合约安全

智能合约安全困扰了 EOS.IO 社区很久，DAPP 开发者在过去一年的实践中发现了大量的问题，Block.One 团队吸收了这些问题并且做出了极大的改进，此次更新对智能合约开发者更友好。

举例来说 , 对于 DAPP 开发者来说 , 一个好消息就是千呼万唤的 `GET_SENDER` API 终于要引入 EOS.IO 中了 , DAPP 开发者可以通过这个 API 判定当前 Action 是否是通过 inline action 机制触发的 , 据此可以回避大量的基于合约触发 inline action 的攻击手段 . 这个更新，可以一定程度上部分解决了困扰社区已久的随机数问题，需要注意的是 , 即使通过这个 api 可以屏蔽当前的很多攻击手段 , 固然攻击者的攻击成本会大幅提高 , 但是不意味着 DAPP 开发者可以高枕无忧 , 对于开发者来说安全问题永远需要注意 , 没有什么一劳永逸的银弹。

4 硬分叉升级机制

这方面的更新可以使得未来的硬分叉升级更加高效的同时使得硬分叉升级过程中不影响用户使用体验。

近一段时间 , Block.One 其实开发了非常多的新功能，包括上面提到的几个功能 , 但都没有在过往的更新中出现，一个很大的原因就是开发者必须保证 EOS.IO 的兼容性 , 节点可以选择不升级节点版本 , 显然这会极大的阻挠 EOS.IO 的发展 , 这次 1.8.0 的版本与以往的一个最大区别是这个版本不兼容前面的版本 , 也就是所谓的“硬分叉”, 在这个版本之前 EOS.IO 并没有应对硬分叉的机制 , 硬分叉的过程会对用户的使用带来很大影响 , 为了使以后的更新不会像这一次一样造成很大影响 , 这次更新中添加了一系列硬分叉升级机制 , 为的是以后的硬分叉更新可以更加平滑和安全。

在 EOS 原力过往的更新中 , 原力团队也遇到了同样的问题 , 所以引入了链配置功能 , 通过这个机制向链添加特性的开启区块高度和链维护状态 , 以此解决硬分叉中的过渡问题 , Block.One 的对策与此类似 , 通过引入 protocol feature 来解决这个问题 , 与原力强调简单通用的解决方案不同 , Block.One 的 feature 设计希望更加完备的解决特性的兼容问题 , 具体的设计可以参见 #6831。

这里可以判断 Block.One 以后的开发过程中会有比之以往更多的硬分叉 , 未来 EOS.IO 的进展会明显快于以往 .

二 EOS.IO 硬分叉影响

EOS.IO 第一次使用硬分叉方式来升级，因此带来的影响也是非常巨大的。

1 节点

大部分节点应该没有经历过硬分叉升级 , 如果严格按照硬分叉的要求来，所有节点需要重放一遍区块，按现在的节点配置，大多数节点最少需要数天才能完成区块重放，当然，还有一种比较偷懒的方法，就是直接使用其他机构提供的快照，但是这样的坏处是如果太多核心节点尤其是 BP 如果这样更新 , 则会影响整个链的安全性。

2 用户

交易所，钱包，区块浏览器，DAPP 等所有的 P2P 节点都会暂停一段时间，其他所有的外部访问数据都会中断，用户感知非常明显。
当然，区块链本身并没有停止，只是为了安全着想，暂停外部和链的交互。

3 DAPP 开发者

理论上链的硬分叉不会影响合约的运行 , 但是考虑到很多 DAPP 采取了半中心化的架构 , 有大量的逻辑在链外运行并与链交互 , 这样一次硬分叉势必带来一定的风险。

三 硬分叉好处和风险

1 好处

在互联网时代，产品迭代是家常便饭，几乎每周开发者都会发布新的版本，用户也习惯第一时间更新升级享受更多的功能和服务。
而此前硬分叉升级在区块链行业几乎非常少见，原因是大部分区块链由去中心化的自由开发者组成，因此开发进度缓慢，节点极其分散，导致硬分叉升级更加麻烦，以比特币为例，2010 年的溢出漏洞导致了导致了 1840 亿的 BTC 凭空创建出来，中本聪第一时间发布了新的版本硬分叉升级，避免了比特币的危机，后来中本聪离开社区后，比特币由社区接管，硬分叉升级很难达成共识，因此很少使用硬分叉升级的方式。

而 Block.One 团队是一个专业开发组织，开发进度比以往的区块链项目得到了指数级的提升，因此快速迭代适应用户需求成为了主流。以目前大多数公有链的技术架构来看，如果要实现大规模的功能升级，硬分叉升级的方式不可避免。

2 风险

如果分叉的过程中超级节点作恶，分叉过程会变得十分危险，如果一部分节点联合起来拒绝升级，那么大概率会出现两个 EOS。

Blockone 做了一定的防范措施：尽管 Block.One 在 2019 年上半年进行了大量的开发，有很多的新功能，但是此次更新只包括一些必要的功能和安全性问题修复 , 等到 feature 上线后硬分叉会变得更加顺利。

四、本次硬分叉注意事项

这是 EOS.IO 面临的第一次硬分叉更新，而且是没有在一个有效的升级机制下进行的硬分叉更新，需要节点和社区付出更多的努力。EOS 原力团队从主网启动开始进行过多次大规模的硬分叉升级以迭代新的功能，这里我们分享一下硬分叉升级中的一些经验：

首先 , 准备越多则更新越顺利 , 在更新之前 , 节点必须做好备份工作 , 当前 EOS.IO 节点数据很大 , 节点备份时也一定要考虑恢复备份数据时的效率 , 备份数据与节点一定要在同一内网中 , 不要依赖于他人的备份 , 否则出现问题时传输备份数据的时间会很漫长 , 最好的方式是直接建立节点的备份节点。

其次 , 需要注意控制节点的交互 , 在更新的过程中 , 整个 EOS.IO 网络会处于一个节点半兼容状态 , 此时如果有人提交触发不兼容逻辑的交易到已经更新过的 BP, 则会导致未更新的 BP 立即分叉 , 虽然这次硬分叉的功能本身就是基于 feature 来管理是否生效的 , 同时执行逻辑出错的交易一般不会在 p2p 网络中传递 , 但是很难排出完全不会出现整个网络分裂的可能性 , 所以在更新过程中节点尤其是超级节点要注意控制交互 , 首先是要控制 http api 的开放 , 可以适当的开启几个 rpc 节点 , 但 rpc 节点与出块几点间不能有直接的 p2p 链接 , 同时重要的节点与其他外部节点间也不要有直接的 p2p 链接 , 这样可以在出现硬分叉时保证关键节点运行。

最后 , 需要控制好更新次序 , 如果基于一个有序的更新次序 , 即使有硬分叉可能 , 多数节点也不会受到影响 , EOS.IO 中的节点往往分为数据节点、出块节点、RPC 节点和同步节点 , 通过控制节点的交互可以很容易的为出块节点门建立一个“绿区”, 屏蔽外部对核心的出块节点的影响 , 此时出块节点可以进行升级 , 在此之后 , 逐步更新出块节点与外部的同步节点 , 同时应该为社区中的数据节点和其他只读节点预留一个更新窗口期 , 社区和开发者的节点可以一次类推 , 先通过建立屏蔽的同步节点建立一个安全区 , 再更新内部节点 , 最后更新同步节点 , 最终当大部分节点以及全部的核心节点更新完毕之后 , 再更新 RPC 节点 , 进而完成整个网络的更新。

其实以上谈到的手段和部署规范早已是老生常谈 , 只不过很多节点的维护者并没有严格的按照规范规划节点的部署 , 可以预见 , 如果节点的维护者还不完善节点部署 , 那么在这次更新中将会是很多问题的一个集中爆发点。

总之 , 越多准备则越加顺利 , 很多问题无法预测 , 所以节点在正式更新之前应当进行一次或者多次演练 , 这样会让 EOS.IO 的这次升级更加稳定。

五、硬分叉的意义是什么

硬分叉本应该是一个再普通不过的技术词汇，然而不同目的的硬分叉会产生不同的结果，因此社区对于硬分叉概念有着非常不同的理解。

从技术角度来讲：硬分叉会导致新的规则不兼容以前的规则，如果获得社区所有人的支持，那么大概率不会有什么影响。

从社区角度来讲：硬分叉时如果出现不同的共识和技术路线，那么大概率社区会分叉成两个公有链，各自支持不同的路线。

2016 年，以太坊（ETH）出现了 DAO 危机，创始人 Vitalik 决定回滚交易，社区有一部分人不同意回滚交易，认为区块链账本不可篡改，拒绝回滚，因此诞生 ETC （以太坊经典）。

2017 年，比特币（BTC）的拥堵使得大区块的支持者迫不及待要改进比特币，但是社区里有不同意见，因此诞生了比特币现金（BCH）。

2018 年，EOS 主网启动时，EOS 原力团队提出了不同的治理路线，随后诞生了 EOS 原力（EOSC）。我们可以看到，Block.one 团队做了大量的准备。

六、本次硬分叉的重要性

本次硬分叉是 EOS.IO 诞生以来最重要的版本，所有基于 EOS.IO 开发的公有链如 EOS，EOSC，ENU，Telos， BOS，Worbli 等均需要采用硬分叉升级。

Block.One 作为业内水平最高的开发组织之一，开发思路都非常大胆，此次添加了硬分叉机制，意味着后半年还会至少有两三次硬分叉。

以往的区块链都非常害怕硬分叉，只有 BCH 社区维持着半年一次的硬分叉升级， EOS 原力也进行过多次硬分叉升级，随着节点和社区认知的发展，硬分叉将不再是一个令人恐慌的词汇，反而会成为区块链进步的方式，即使出现新的分支也是有意义的探索。

此次硬分叉升级将会给 EOS.IO 带来更多的功能和易用性，可以预计，如果想要使得公有链适应时代的发展，未来硬分叉的升级方式将会成为主流。

七、关于近期社区关于 BM 跑路的传言。

近期又有传言称 BM 开发了新的项目，引发了 EOS.IO 社区的恐慌。

从 EOS.IO 的角度来讲，主网启动后 Block.One 在 EOS.IO 上付出了极大的努力，持续高效的开发将 EOS.IO 打造成了最强大的去中心化应用软件平台。同时，社区也有 EOS 原力，EOS Canada BOS Core 这样一直在公链开发一线深耕的团队，即使 BM 离开社区也不会影响 EOS.IO 的发展。

EOS 原力团队追踪着世界上大部分主流公有链的实际开发进展，无论是开发速度还是代码质量，BlockOne 在 EOS.IO 开发上的表现远超其他主流公有链开发团队，和 1.8.0-rc2 一样重要的分支还有多个都在开发中，让我们拭目以待。