【超越白皮书2】EOS主网上线前夕的实测分析与技术建议

本报告由火币区块链研究院出品，做者：袁煜明、胡智威。原文地址

相关报告：

【超越白皮书1】EOSIO程序实测分析与技术建议

【火线视点6】复盘EOS安全事件及再议区块链安全

火币区块链应用研究院从技术角度对EOSIO保持跟踪，并对上线期间可能会遇到的问题进行研究分析，主要获得如下研究结果:

• 多链上线的状况有可能出现，但更应引发普通投资者的关注是EOS映射与钱包安全。
• EOSIO Dawn 4.x 版本在性能方面相较于Dawn 3.0有所降低。相同环境下，Dawn 4.x可达到约700 -1300 TPS，而3.0为1900
• 即便没有足够的计算资源，攻击者仍有可能恶意消耗EOSIO额外资源。但此影响不会经过网络蔓延到其余节点。
• 综合分析当前版本性能与EOSIO应用的防攻击状况，咱们建议经过VPN连接以及不直接在公网暴露超级节点等方式尽量避免因网络攻击而带来的节点宕机、分叉等状况。

1. 引言

“话说天下大势，分久必合，合久必分”。区块链的世界彷佛也符合这个规律。

从中心化的传统信息系统世界逐渐过渡到去中心化的区块链新世代，咱们正有幸经历着一场从“合”到“分”的生产关系伟大变革。在这个过程当中，区块链也在现有如PoW、PoS这些彻底去中心化的共识方式的基础上，开始了一些从“分”到“合”的有益探索，例如EOS的DPoS+BFT这种去中心化与中心化相结合的共识模式。

在分分合合的大势下，EOSIO基于目前的版本在开始上线运营过程当中可能会遇到哪些问题？对于普通投资者与技术人员应怎样应对？咱们尝试从技术角度对这些问题进行分析。

另外须要注意的是：测试获得的指标数据结果不是也不该被视为是对EOSIO平台或项目最终效果的证实或确认。特此声明。

2. 主要结论

根据咱们对近期EOS热点问题的跟踪与实测分析，咱们获得如下主要研究结果：

• 多链上线的状况有可能出现，但更应引发普通投资者的关注是EOS映射与钱包安全
• EOSIO Dawn 4.x 版本在性能方面相较于Dawn 3.0有所降低
• 即便没有足够的计算资源，攻击者仍有可能恶意消耗EOSIO额外资源，但此影响不会经过网络蔓延到其余节点
• 综合分析当前性能与EOSIO应用的防攻击状况，咱们建议经过VPN连接以及不直接在公网暴露超级节点等方式来尽量避免因网络攻击而带来的节点宕机、分叉等状况

3. 从“分”到“合”

EOS主网即将在6月初上线。不少EOS技术人员、投资者在期待的同时也有所担忧：由于Block.One公司只负责EOSIO程序的开发，而把上线及运营交给了社区来作，所以存在出现多个社区各自启动区块链的可能性。

关于这一问题，EOS原力等已进行了相关研究解答（参考 https://www.huobipool.com/#!/... ）

社区对有哪些链将启动，以及启动时所采起的技术方式均有多种思路意见，并不统一（参考 https://bihu.com/article/491000 ）。这对用户EOS的映射工做可能会形成较大的困扰。

令EOS支持者欣喜的是，愈来愈多的EOS社区开始发表声明，只认可一个主链。所以按照目前的状况估计，在投票开始前，候选节点们应该会共同选出一条链做为投票及后续运营的主链。因此对于EOS的持有者，更应关注的事情是作好本身数字资产的映射。

尽管Block.One的产品VP——Thomas Cox曾在网络上表示即便不映射EOS也不会丢（参考https://bihu.com/article/370163），但为了资产安全，咱们仍然强烈建议在北京时间6月2日前完成映射。

目前映射的主要方法包括：

• 手动映射
• 经过钱包映射
• 由交易所完成映射

因为手动映射须要的技术工做较多，且若是确实上线时存在多个链，则须要对每一个链都进行映射，所以此种方法对用户并不友好且存在私钥暴露的风险。

综上考虑，对于普通投资者，咱们推荐使用支持自动映射的交易所，由交易所来完成映射工做。

4. 从“合”到“分”？

开始稳定运行后，并非万事大吉。DPoS+BFT创新方式会对系统运行与维护带来新的挑战。尤为在近期360公布了EOS存在漏洞的消息后，为了不由于恶意攻击而带来不但愿的网络分叉或节点下线等状况，更须要在平台运行过程当中以安全为导向进行持续跟踪。这里咱们从技术概念论证角度提出在性能分析中发现的风险及其防范思路。

4.1. 性能跟踪

在开始正式讨论是否会“合久必分”前，咱们先看下EOSIO最新版本的性能状况。

相较于咱们以前对于EOSIO Dawn 3.0版本的测试，EOSIO Dawn 4.0、4.1和4.2版本在一样的测试环境下，其性能有了必定幅度的降低。

测试的场景为：

• 使用Block.One提供的txn_test_gen测试插件工具发送测试交易数据并观察实际TPS与系统CPU使用率等指标状况。

测试的软件环境为：

• 测试程序分别为EOSIO的dawn-v4.0.0版本、dawn-v4.1.0版本、dawn-v4.2.0版本
• 操做系统为Ubuntu 16.04

测试硬件环境为：

• 2台 AWS EC2 C5.4xlarge 服务器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB内存
• 服务器间为10Gbps局域网网络，通信延迟（ping）小于1ms

测试结果：
根据《【超越白皮书1】EOSIO程序实测分析与技术建议》，咱们选择单机方式组建私有测试环境以最大限度的提升TPS。基于上述测试环境条件，目前各版本的TPS为：
版本 最大TPS（基于上述测试环境）

• Dawn 4.0: 约700
• Dawn 4.1: 约700
• Dawn 4.2: 约1300

这一状况在目前的测试网上也有所体现。Daniel Larimer在EOS Developers的Telegram群里曾表示，Dawn 4.0 的测试网Jungle已可稳定运行，其TPS曾达到600多。

究其缘由，EOSIO Dawn 4.x版本引入的诸多功能包括投票、对原有合约的改写等是可能的缘由之一。

根据《【超越白皮书1】EOSIO程序实测分析与技术建议》，为了提供良好的交易服务，新版本对服务器提出了更高的要求。所幸，EOSIO在设计时，已考虑到了无矿工手续费所可能引起的DDoS攻击等问题，并设计了包括CPU、内存及带宽在内的计算资源购买和使用模式，即必须持有足够的EOS并获得计算资源后才容许进行符合当前资源下的交易。

但这样就能够从应用层面上避免大量恶意交易占用网络资源甚至DDoS现象么？答案并无那么简单。在新版本EOSIO交易处理性能有所降低的状况下，咱们尤为须要对这一问题进行更深刻的探讨。

4.2. 恶意交易攻击示例及防范思路

因为EOS的超级节点为有限的21个，所以颇有可能存在针对这些超级节点的网络攻击，出现包括超级节点没法正常提供服务甚至下线、网络出现恶意分叉等这些并不健康的“合久必分”现象。

在网络层面上防范方案，可参考https://blog.eos42.io/ddos-mi... 及https://medium.com/eostribe/a...，包括增长防火墙、选择合适的云计算资源服务商、改变网络拓扑等。这里，咱们从EOSIO的应用层面来进行实测分析论证。

尽管已经对可以使用资源作了限制，咱们经过构建模拟攻击场景，分析是否存在攻击者可花费低成本代价（拥有少许EOS）就能进行一些恶意攻击的风险。

测试的场景为：

• 构建2个交易帐户，其拥有极少许的EOS及不足以完成正常交易的计算资源的交易帐户（建立时的参数可设置为：“--stake-net '0.0001 EOS' --stake-cpu '0.0001 EOS' ”）
• 经过这2个交易帐户，编写调用转帐接口的简单脚本，不间断的向EOSIO节点发送大量交易。因为帐户所拥有的计算资源限制，这些交易均不能完成。（发送时会提示错误，例如：“billed CPU time (360 us) is greater than the maximum billable CPU time for the transaction (21 us)”）
• 重复调用该脚本屡次，观察状况

测试的软件环境为：

• 测试程序为EOSIO的dawn-v4.0.0版本、dawn-v4.1.0版本、dawn-v4.2.0版本
• 操做系统为Ubuntu 16.04

测试硬件环境为：

• 2台 AWS EC2 C5.4xlarge 服务器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB内存
• 服务器间为10Gbps局域网网络，通信延迟（ping）小于1ms

在一个包含超级节点（Block Producer，如下简称“BP”）与普通节点（Full Node，如下简称“FN”）的网络中，若是经过FN接收脚本发送的交易，nodeos进程CPU利用率关系以下

• BP上nodeos进程的CPU使用率：始终维持在0%-1%
• FN上nodeos进程的CPU使用率：从11%-14%开始，随着发送负载的增长会上升到60%-66%。维持这一负载一段时间后会降低到19%-33%

EOSIO的节点进程nodeos会被这些没法完成的交易信息所影响。随着恶意交易的不断增长，其CPU占用率也会不断提升。

同时，咱们观察到，这些对资源的额外占用并无对另外的节点（BP）产生影响，即这些交易并无经过网络对外共识，说明FN确实处理了这些无效交易，但代价是自身CPU使用率的提升。

值得注意的是，当这些恶意交易的负载到达必定程度后，会对钱包进程keosd产生影响，首先是钱包进程的CPU利用率升高，进而产生一些服务异常状况（“Failed to connect to keosd at http://localhost:8900/; is keosd running?”）。而EOSIO当前版本的机制是会在连接不到钱包服务的状况下新启动一个keosd进程（“"/usr/local/bin/keosd" launched”），所以会不断涌现大量僵尸进程。而nodeos进程CPU利用率降低的缘由可能在于此状况下没法读取基本的帐户信息。

若是经过BP接收交易，nodeos进程CPU利用率关系以下：

• BP（CPU使用率）：从11%-14%开始，随着发送负载的增长会上升到58%-66%。维持这一负载一段时间后会降低到20%-30%左右
• FN（CPU使用率）：始终维持在0%-1%

能够看到与经过FN接收交易的测试结果差异不大。

根据《【超越白皮书1】EOSIO程序实测分析与技术建议》，因为处在高利用率CPU下的节点容易使其区块进度落后于其余节点；而且当攻击进一步发展时，甚至可能会致使BP的下线。

所以，建议BP不要直接暴露在公网上，而是采用VPN方式，例如WireGuard等与其余节点进行链接，并经过FN接收交易，从而防范此类风险。