• <option id="cacee"><noscript id="cacee"></noscript></option>
  • <table id="cacee"><noscript id="cacee"></noscript></table>
  • <td id="cacee"></td>
  • <option id="cacee"></option>
  • <table id="cacee"></table>
  • <option id="cacee"><option id="cacee"></option></option>
  • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
    <option id="cacee"><option id="cacee"></option></option>
     找回密碼
     立即注冊

    掃一掃,登錄網站

    首頁 自媒體 查看內容
    • 2636
    • 0
    • 分享到

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

    2018-6-2 14:49

    來源: blockfin

    摘  要


    火幣區塊鏈應用研究院從技術角度對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/#!/comment-detail/t367s8)。


    社區對有哪些鏈將啟動,以及啟動時所采取的技術方式均有多種思路意見,并不統一(參考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為:



    這一情況在目前的測試網上也有所體現。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-mitigation/ 及https://medium.com/eostribe/addressing-ddos-risks-at-eos-launch-fa33f16a54af等,包括增加防火墻、選擇合適的云計算資源服務商、改變網絡拓撲等。這里,我們從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利用率關系如下:



    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利用率關系如下:



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


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


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

    版權申明:本內容來自于互聯網,屬第三方匯集推薦平臺。本文的版權歸原作者所有,文章言論不代表鏈門戶的觀點,鏈門戶不承擔任何法律責任。如有侵權請聯系QQ:3341927519進行反饋。
    相關新聞
    發表評論

    請先 注冊/登錄 后參與評論

      回頂部
    • <option id="cacee"><noscript id="cacee"></noscript></option>
    • <table id="cacee"><noscript id="cacee"></noscript></table>
    • <td id="cacee"></td>
    • <option id="cacee"></option>
    • <table id="cacee"></table>
    • <option id="cacee"><option id="cacee"></option></option>
    • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
      <option id="cacee"><option id="cacee"></option></option>
      妖精视频