【超越白皮書 2】EOS 主網上線前夕的實測分析與技術建議

  摘 要

火幣區(qū)塊鏈應用研究院從技術角度對EOSIO保持跟蹤，并對上線期間可能會遇到的問題進行研究分析，主要得到以下研究結果:

多鏈上線的情況有可能出現(xiàn)，但更應引起普通投資者的關注是EOS映射與錢包安全。

EOSIO Dawn 4.x 版本在性能方面相較于Dawn 3.0有所下降。相同環(huán)境下，Dawn 4.x可達到約700 -1300 TPS，而3.0為1900。

即使沒有足夠的計算資源，攻擊者仍有可能惡意消耗EOSIO額外資源。但此影響不會通過網絡蔓延到其他節(jié)點。

綜合分析當前版本性能與EOSIO應用的防攻擊情況，我們建議通過VPN鏈接以及不直接在公網暴露超級節(jié)點等方式盡可能避免因網絡攻擊而帶來的節(jié)點宕機、分叉等情況。

1. 引言

“話說天下大勢，分久必合，合久必分”。區(qū)塊鏈的世界似乎也符合這個規(guī)律。

從中心化的傳統(tǒng)信息系統(tǒng)世界逐漸過渡到去中心化的區(qū)塊鏈新世代，我們正有幸經歷著一場從“合”到“分”的生產關系偉大變革。在這個過程中，區(qū)塊鏈也在現(xiàn)有如PoW、PoS這些完全去中心化的共識方式的基礎上，開始了一些從“分”到“合”的有益探索，例如EOS的DPoS+BFT這種去中心化與中心化相結合的共識模式。

在分分合合的大勢下，EOSIO基于目前的版本在開始上線運營過程中可能會遇到哪些問題？對于普通投資者與技術人員應怎樣應對？我們嘗試從技術角度對這些問題進行分析。

另外需要注意的是：測試得到的指標數據結果不是也不應被視為是對EOSIO平臺或項目最終效果的證明或確認。特此聲明。

2. 主要結論

根據我們對近期EOS熱點問題的跟蹤與實測分析，我們得到以下主要研究結果：

● 多鏈上線的情況有可能出現(xiàn)，但更應引起普通投資者的關注是EOS映射與錢包安全

● EOSIO Dawn 4.x 版本在性能方面相較于Dawn 3.0有所下降

● 即使沒有足夠的計算資源，攻擊者仍有可能惡意消耗EOSIO額外資源，但此影響不會通過網絡蔓延到其他節(jié)點

● 綜合分析當前性能與EOSIO應用的防攻擊情況，我們建議通過VPN鏈接以及不直接在公網暴露超級節(jié)點等方式來盡可能避免因網絡攻擊而帶來的節(jié)點宕機、分叉等情況

3. 從“分”到“合”

EOS主網即將在6月初上線。很多EOS技術人員、投資者在期待的同時也有所擔心：因為Block.One公司只負責EOSIO程序的開發(fā)，而把上線及運營交給了社區(qū)來做，因此存在出現(xiàn)多個社區(qū)各自啟動區(qū)塊鏈的可能性。

關于這一問題，EOS原力等已進行了相關研究解答。

社區(qū)對有哪些鏈將啟動，以及啟動時所采取的技術方式均有多種思路意見，并不統(tǒng)一。這對用戶EOS的映射工作可能會造成較大的困擾。

令EOS支持者欣喜的是，越來越多的EOS社區(qū)開始發(fā)表聲明，只承認一個主鏈。因此按照目前的情況估計，在投票開始前，候選節(jié)點們應該會共同選出一條鏈作為投票及后續(xù)運營的主鏈。所以對于EOS的持有者，更應關注的事情是做好自己數字資產的映射。

盡管Block.One的產品VP——Thomas Cox曾在網絡上表示即使不映射EOS也不會丟，但為了資產安全，我們仍然強烈建議在北京時間6月2日前完成映射。

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

● 手動映射

● 通過錢包映射

● 由交易所完成映射

由于手動映射需要的技術工作較多，且如果確實上線時存在多個鏈，則需要對每個鏈都進行映射，因此此種方法對用戶并不友好且存在私鑰暴露的風險。

綜上考慮，對于普通投資者，我們推薦使用支持自動映射的交易所，由交易所來完成映射工作。

4. 從“合”到“分”

開始穩(wěn)定運行后，并不是萬事大吉。DPoS+BFT創(chuàng)新方式會對系統(tǒng)運行與維護帶來新的挑戰(zhàn)。尤其在近期360公布了EOS存在漏洞的消息后，為了避免因為惡意攻擊而帶來不希望的網絡分叉或節(jié)點下線等情況，更需要在平臺運行過程中以安全為導向進行持續(xù)跟蹤。這里我們從技術概念論證角度提出在性能分析中發(fā)現(xiàn)的風險及其防范思路。

4.1 性能跟蹤

在開始正式討論是否會“合久必分”前，我們先看下EOSIO最新版本的性能情況。

相較于我們之前對于EOSIO Dawn 3.0版本的測試，EOSIO Dawn 4.0、4.1和4.2版本在同樣的測試環(huán)境下，其性能有了一定幅度的下降。

測試的場景為：

● 使用Block.One提供的txn_test_gen測試插件工具發(fā)送測試交易數據并觀察實際TPS與系統(tǒng)CPU使用率等指標情況。

測試的軟件環(huán)境為：

● 測試程序分別為EOSIO的dawn-v4.0.0版本、dawn-v4.1.0版本、dawn-v4.2.0版本

● 操作系統(tǒng)為Ubuntu 16.04

測試硬件環(huán)境為：

● 2臺 AWS EC2 C5.4xlarge 服務器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB內存

● 服務器間為10Gbps局域網網絡，通訊延遲（ping）小于1ms

測試結果：

根據《【超越白皮書1】EOSIO程序實測分析與技術建議》，我們選擇單機方式組建私有測試環(huán)境以最大限度的提高TPS。基于上述測試環(huán)境條件，目前各版本的TPS為：

這一情況在目前的測試網上也有所體現(xiàn)。Daniel Larimer在EOS Developers的Telegram群里曾表示，Dawn 4.0 的測試網Jungle已可穩(wěn)定運行，其TPS曾達到600多。

究其原因，EOSIO Dawn 4.x版本引入的諸多功能包括投票、對原有合約的改寫等是可能的原因之一。

根據《【超越白皮書1】EOSIO程序實測分析與技術建議》，為了提供良好的交易服務，新版本對服務器提出了更高的要求。所幸，EOSIO在設計時，已考慮到了無礦工手續(xù)費所可能引發(fā)的DDoS攻擊等問題，并設計了包括CPU、內存及帶寬在內的計算資源購買和使用模式，即必須持有足夠的EOS并得到計算資源后才允許進行符合當前資源下的交易。

但這樣就可以從應用層面上避免大量惡意交易占用網絡資源甚至DDoS現(xiàn)象么？答案并沒有那么簡單。在新版本EOSIO交易處理性能有所下降的情況下，我們尤其需要對這一問題進行更深入的探討。

4.2 惡意交易攻擊示例及防范思路

由于EOS的超級節(jié)點為有限的21個，因此很有可能存在針對這些超級節(jié)點的網絡攻擊，出現(xiàn)包括超級節(jié)點無法正常提供服務甚至下線、網絡出現(xiàn)惡意分叉等這些并不健康的“合久必分”現(xiàn)象。

在網絡層面上防范方案，可參考，包括增加防火墻、選擇合適的云計算資源服務商、改變網絡拓撲等。這里，我們從EOSIO的應用層面來進行實測分析論證。

盡管已經對可使用資源做了限制，我們通過構建模擬攻擊場景，分析是否存在攻擊者可花費低成本代價（擁有少量EOS）就能進行一些惡意攻擊的風險。

測試的場景為：

● 構建2個交易賬戶，其擁有極少量的EOS及不足以完成正常交易的計算資源的交易賬戶（創(chuàng)建時的參數可設置為：“--stake-net '0.0001 EOS' --stake-cpu '0.0001 EOS' ”）

● 通過這2個交易賬戶，編寫調用轉賬接口的簡單腳本，不間斷的向EOSIO節(jié)點發(fā)送大量交易。由于賬戶所擁有的計算資源限制，這些交易均不能完成。（發(fā)送時會提示錯誤，例如：“billed CPU time (360 us) is greater than the maximum billable CPU time for the transaction (21 us)”）

● 重復調用該腳本多次，觀察情況

測試的軟件環(huán)境為：

● 測試程序為EOSIO的dawn-v4.0.0版本、dawn-v4.1.0版本、dawn-v4.2.0版本

● 操作系統(tǒng)為Ubuntu 16.04

測試硬件環(huán)境為：

● 2臺 AWS EC2 C5.4xlarge 服務器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB內存

● 服務器間為10Gbps局域網網絡，通訊延遲（ping）小于1ms

在一個包含超級節(jié)點（Block Producer，以下簡稱“BP”）與普通節(jié)點（Full Node，以下簡稱“FN”）的網絡中，如果通過FN接收腳本發(fā)送的交易，nodeos進程CPU利用率關系如下：

EOSIO的節(jié)點進程nodeos會被這些無法完成的交易信息所影響。隨著惡意交易的不斷增加，其CPU占用率也會不斷提高。

同時，我們觀察到，這些對資源的額外占用并沒有對另外的節(jié)點（BP）產生影響，即這些交易并沒有通過網絡對外共識，說明FN確實處理了這些無效交易，但代價是自身CPU使用率的提高。

值得注意的是，當這些惡意交易的負載到達一定程度后，會對錢包進程keosd產生影響，首先是錢包進程的CPU利用率升高，進而產生一些服務異常情況。而EOSIO當前版本的機制是會在鏈接不到錢包服務的情況下新啟動一個keosd進程（“"/usr/local/bin/keosd" launched”），因此會不斷涌現(xiàn)大量僵尸進程。而nodeos進程CPU利用率下降的原因可能在于此情況下無法讀取基本的賬戶信息。

如果通過BP接收交易，nodeos進程CPU利用率關系如下：

可以看到與通過FN接收交易的測試結果差別不大。

根據《【超越白皮書1】EOSIO程序實測分析與技術建議》，由于處在高利用率CPU下的節(jié)點容易使其區(qū)塊進度落后于其他節(jié)點；并且當攻擊進一步發(fā)展時，甚至可能會導致BP的下線。

因此，建議BP不要直接暴露在公網上，而是采用VPN方式，例如WireGuard等與其他節(jié)點進行連接，并通過FN接收交易，從而防范此類風險。