【超越白皮书 2】 EOS 主网上线 前夕 的实测分析与 技术建议 2018 年 6 月 1 日 摘要 火币区块链应用研究院 从技术角度对 EOSIO 保持跟踪，并对上线期间可能会遇到的 问题进行 研究 分析 ，主要得到以下研究结果 多链上线的情况有可能出现，但更应引起普通投资者的关注是 EOS 映射与钱包安全 。 EOSIO Dawn 4.x 版本在性能方面相较于 Dawn 3.0 有所下降 。 相同环境 下 ， Dawn 4.x 可 达到约 700 -1300 TPS，而 3.0 为1900 即使没有足够的计算资源，攻击者仍有可能恶意消耗 EOSIO 额外资源 。 但 此影响 不会通过网络蔓延 到其他节点 。 综合分析当前 版本 性能与 EOSIO 应用的防攻击情况，我们建议通过 VPN 链接 以及 不直接在公网暴露超级节点等方式 尽可能避免因网络攻击而带来的节点宕机、分叉等情况 。 相关报告 【超越白皮书 1】 EOSIO 程序实测分析与技术建议 2018-5-7 作者 袁煜明 胡智威 行业技术 分析 报告 2 目录 1. 引言 ........................................................................................................ 3 2. 主要结论 ................................................................................................. 3 3. 从 “ 分 ” 到 “ 合 ” ................................................................................... 3 4. 从 “ 合 ” 到 “ 分 ” ............................................................................... 4 4.1. 性能跟踪 ............................................................................................................................... 5 4.2. 恶意交易攻击示例及防范思路 ............................................................................................... 6 火币区块链研究院 3 报告正文 1. 引言 “话说天下大势，分久必合，合久必分”。区块链的世界似乎也符合 这个规律。 从中心化的传统信息系统世界逐渐过渡到去中心化的区块链新世代，我们正有幸经历着一场从“合”到“分”的生产关系伟大变革。在这个过程中，区块链也 在现有如 PoW、 PoS 这些完全去中心化的共识方式 的基础上 ，开始了 一些从“分”到“合”的有益探索，例如 EOS 的DPoSBFT 这种去中心化与中心化相结合的共识模式。 在 分分合合的大势 下， EOSIO 基于目前的版本在开始上线运营过程中可能会遇到哪些问题 对于普通投资者与技术人员应怎样应对 我们尝试从技术角度对这些问题 进行 分析 。 另外需要注意的是 测试得到的指标数据结果不是也不应被视为是对EOSIO 平台或项目最终效果的证明或确认。 特此声明。 2. 主要结论 根据我们对 近期 EOS 热点问题的跟踪与实测分析，我们 得到 以下主要研究结果  多 链上线的情况有可能出现 ， 但更应引起普通投资者的关注是 EOS 映射与钱包安全  EOSIO Dawn 4.x 版本在性能方面相较于 Dawn 3.0 有所下降  即使没有足够的计算资源，攻击者仍有可能恶意消耗 EOSIO 额外资源 ，但此影响不会通过网络蔓延到其他节点  综合分析当前性能与 EOSIO 应用的防攻击情况，我们 建议通过 VPN 链接以及 不直接在公网暴露超级节点等方式来 尽可能 避免 因网络攻击而带来的节点宕机、分叉等情况 3. 从“分”到“合” EOS 主网即将在 6 月初上线。很多 EOS 技术人员、投资者在期待的同 行业技术 分析 报告 4 时也有所担心 因为 Block.One 公司只负责 EOSIO 程序的开发，而把上线及运营交给了社区来做，因此存在 出现多 个社区 各自启动区块链 的可能性。 关于这一问题， EOS 原力 等已进 行了相关研究解答（参考 https// 社区对有哪些链将启动，以及 启动 时所采取 的技术方式均有多种思路意见，并不统一（参考 https// 这对用户 EOS 的映射工作可能会造成较大的困扰。 令 EOS 支持者欣喜的是， 越来越多的 EOS 社区开始 发表声明，只承认一个主链 。因此 按照目前的情况估计， 在投票开始前，候选节点们应该会共同选出一条链作为投票及后续运营的主链。所以 对于 EOS 的持有者，更应关注的 事情 是 做好自己数字资产的 映射。 尽管 Block.One 的 产品 VP Thomas Cox 曾在网络上表示 即使 不映射 EOS 也不会丢（参考 https// ，但为了资产安全， 我们 仍然强烈建议 在 北京时间 6 月 2 日前完成映射。 目前 映射的 主要方法包括  手动映射  通过钱包映射  由交易所完成映射 由于手动映射需要的技术工作较多，且如果确实上线时 存在 多个链，则需要对每个链都进行映射，因此此种方法对用户并不友好 且存在私钥暴露的风险 。 综上考虑，对于普通投资者，我们推荐 使用 支持自动映射的交易所，由交易所来完成映射工作。 4. 从“合”到“分 ” 开始稳定 运行后，并不是万事大吉。 DPoSBFT 创新方式 会对 系统 运行与维护 带来新的挑战 。 尤其在近期 360 公布了 EOS 存在漏洞的消息后， 为了避免 因为恶意攻击而带来不希望的 网络 分叉或节点下线等情况，更 需要 在平台运行过程中以安全为导向 进行 持续跟踪。 这里我们从技术概念论证角度提出在性能分析中发现的风险及其防范思路。 火币区块链研究院 5 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 行业技术 分析 报告 6 这一情况在目前的测试网上也有 所体现 。 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. 恶意交易攻击 示例 及防范思路 火币区块链研究院 7 由于 EOS 的超级节点为有限的 21 个，因此很有可能存在针对这些超级节点的 网络 攻击，出现包括超级节点无法正常提供服务甚至下线、网络出现恶意分叉等这些并不健康的“合久必分”现象。 在网络层面上防范 方案， 可 参考 https//blog.eos42.io/ddos-mitigation/ 及 https// 等 ，包括增加防火墙、选择合适的云计算资源服务商、改变网络拓扑等 。 这里，我们从 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 内存 行业技术 分析 报告 8  服务器间为 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//localhost8900/; 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 接收 交易，从而 防范此类风险 。