【超越白皮书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接收交易，从而防范此类风险。