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

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

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

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

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

1. 引言

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

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

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

另外需要注意的是：測試得到的指標(biāo)數(shù)據(jù)結(jié)果不是也不應(yīng)被視為是對EOSIO平臺或項目最終效果的證明或確認。特此聲明。

2. 主要結(jié)論

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

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

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

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

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

3. 從“分”到“合”

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

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

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

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

盡管Block.One的產(chǎn)品VP——Thomas Cox曾在網(wǎng)絡(luò)上表示即使不映射EOS也不會丟，但為了資產(chǎn)安全，我們?nèi)匀粡娏医ㄗh在北京時間6月2日前完成映射。

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

● 手動映射

● 通過錢包映射

● 由交易所完成映射

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

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

4. 從“合”到“分”

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

4.1 性能跟蹤

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

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

測試的場景為：

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

測試的軟件環(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 服務(wù)器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB內(nèi)存

● 服務(wù)器間為10Gbps局域網(wǎng)網(wǎng)絡(luò)，通訊延遲（ping）小于1ms

測試結(jié)果：

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

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

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

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

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

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

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

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

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

測試的場景為：

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

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

● 重復(fù)調(diào)用該腳本多次，觀察情況

測試的軟件環(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 服務(wù)器: 16 核 3GHz, Intel Xeon Platinum 8124M CPU，32GB內(nèi)存

● 服務(wù)器間為10Gbps局域網(wǎng)網(wǎng)絡(luò)，通訊延遲（ping）小于1ms

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

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

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

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

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

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

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

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