分析EOS有哪些安全隱患？

EOSForce.io作為對EOS代碼進行過深入研究并且做過大量部署測試的團隊，曾經多次提醒過主網安全問題，并且針對發現的問題進行了修復和更改。近期，隨著研究深入，我們發現了更多的安全隱患，而一些候選節點也開始關注到主網的安全問題。

我們接下來披露直到現在也還依然困擾我們的9個核心安全隱患，由于Block.one宣稱不對任何一條主網的安全負責，我們自己做了一些初步解決方案。這里試圖也幫助大家理解：

EOSForce.io對EOSIO的更改為什么是必須的。如果有更好的解決方案，也希望大家來跟我們溝通，一起為EOS的安全做出貢獻。 EOSForce.io承諾不競選超級節點，在EOS主網公測結束驗證安全之前不會貿然啟動主網。也不建議用戶在此之前隨便導入私鑰去激活主網資產。

為了解決 EOS 目前的困擾， EOSForce.io做了最新的預防，以期望最小功能安全啟動EOS主網，然后等各個限制模塊形式化驗證以及大規模測試驗證通過后慢慢放開相應的功能。

困擾1：

EOS基于資源抵押模式， 這很創新，但現在還沒有做到原來期望的程度。 目前已經在運行的公有鏈都是以收手續費的模式。

收手續費有兩個好處：

1、 防止鏈級別DDOS， 眾所周知， 以太坊的POW測試網為什么經常受攻擊， 因為幣沒有價值， 沒有防止鏈級別攻擊的門檻。 之前以太坊每個code gas價格的合理設置也是為此。 大家都知道，防止DDOS的最好辦法，是迫使攻擊成本遠大于利潤獲得成本。 

2、手續費可以作為激勵的來源，保持整條鏈的生態穩定向前發展。

" EOS基于抵押模型 "這一思維很創新，零手續費， 當時大家（包括BM）期望通過資源抵押的方式來防止DDOS， 后面又期望成立EOSRAM等相關的資源代幣來產生激勵。這樣就解決了收交易手續費的問題。 

然而交易手續費問題只是在System合約和底層間有點聯系 ，并沒有得到預期的希望。 

對于開發者， 大家只要隨便搭個測試網， 你們可以不用任何成本可以發送交易， 這樣就能驗證我說的這一問題。 這個問題是鏈級別致命的問題， 遠超過360“史詩級”的傳統內存泄露問題。因為只要任何一個人開一臺電腦，批量持續向EOS主網發送交易。 EOS網絡就會失敗。

EOSForce.io 預防1 ：

針對這一點， EOSForce.io在EOS的基礎上增加了對每個action設置價格收費。 只是現在在EOS沒有把資源模塊做好的時候加了個交易手續費的過濾器。 等后面BM大神把這塊功能做好了， EOSForce就可以把交易手續費這一層過濾器關掉，進行真正可以通過資源來防止DDOS攻擊，還可以激勵整條鏈的生態。

困擾2：

EOS代碼中有超級權限這一說， 超級權限不需要私鑰就可以通過身份驗證。 并且以字符eosio.開頭的賬戶都是準超級權限賬戶（現在就有eosio）

這點與區塊鏈哲學的基本功能私鑰保護下個人資產神圣不可侵犯相違背。

EOSForce.io 預防2 ：

針對這點， EOSForce.io 限制整個系統只有一個特權額賬戶就是eosio, 并且使該賬戶的公鑰數據段為全0， 加了檢驗后的該地址為

EOS1111111111111111111111111111111114T1Anm。 沒有任何人擁有或者知道該私鑰。

困擾3：

交易的設計結構過于復雜

大家可以看我們所摘下來完整的EOS數據塊。 EOS的一個交易可以由action數組和多個contextfreeaction數組組成。 而action 中又可以加入inline action, contextfreeaction 不需要簽名， action 中可以套大量的inline action。

EOS是以action 為單位順序執行。交易又可以是延時交易。等等這些設計，都很創新，感謝BM。但這么復雜的功能過于龐大，可攻擊組合的點很多。交易套延時交易，交易里有action, action 又可以套inline_action。這復雜的功能需要長時間，多種case組合,長有力的測試驗證。

EOSForce.io 預防3：

我們也正在組織大量的團隊進行這一塊的測試和驗證。 但為了持幣人的安全性。 我們限制交易里面的action為單action， 不需要簽名的contextfreeaction我們先限制掉。 等形式化證明結果，以及大規模各種實列測試驗證成功通過后，再把這層過濾器給放開。

困擾4：

EOS的查詢 get table 等查詢接口不能分批指定關鍵字查詢。

在這里不得不贊嘆一下BM這個技術天才， 他用到了多plugin可插拔式模塊編程， 多個模塊都是單列模式，可以互相訪問。

除此之外他還用到了消息總線微服務編程模式。 各個模塊只要對相應的消息感興趣， 只要注冊相應的消息總線， 就能接受相應的消息。 但在這些模塊中有很多查詢接口只能批量查詢。

當數據小時，還可以接受。但當真到了百萬tps后， 這樣的查詢，就基本沒有機器能滿足了。 雖然--key在EOS就是有的字段，但在EOS代碼中一直像transfer接口中的memo參數一樣， 只有其名，確沒有他的實現。

EOSForce.io 預防4：

加入--key 按關鍵字定點小額查詢。

困擾5：

EOS的水龍頭模塊已經有很長一段時間，該模塊是不通的了。

水龍頭模塊，是一個讓用戶可以通過第三方注冊用戶名的插件。

EOSForce.io 預防5：

增加水龍頭插件。

困擾6：

chainbase 數據庫的不穩定性。

大家可以調用chainbase 的接口，對相同的數據進行兩次存儲， 程序就會core dump。 EOS合約中的multiIndex table表也是用的chainbase, 當你對一個table的同一行數據的不通列同時進行修改時， 他只會更新最后一次的操作。

EOSForce.io 預防6：

認真的review相關這塊的代碼， 對所有有出現問題的地方進行了review。

困擾7：

EOS 的wasm-jit 是直接fork Andrew Scheidecker近兩年的代碼,以及fork了官方的webassembly。這里面有多少bug，需要大規模測試。

EOSForce.io 預防7 ：

EOSForce.io在創始塊內置系統合約，使系統合約從創始塊起，就是內置合約。 EOSForce.io限制了setcode, setabi接口

困擾8：

EOS沒有世界狀態， 只能通過塊級別驗證檢驗發生分叉。

比如：A，B節點的交易序列表都是一樣的，也就是塊都是一樣的。 但對各個賬戶執行了不同的數據庫落盤，鏈是不知道的。

攻擊可能性： 雖然BM在apply_context.cpp中做了只能合約table 擁有者才能修改table。但不排除不能通過外面構造相應的key value 直接對不同合約賬戶的table做相關 的狀態落盤攻擊。

這時，鏈上的塊大家都是一致的，但各個節點里面的狀態存儲就會相應的不同，甚至可以跨賬戶覆蓋相應的table。對不同合約賬戶的狀態進行更改。

EOSForce.io 預防8：

先限制自由提交代碼的功能，等所有的這些經過了形式化證明后， 再放開。

困擾9：

mongodb, sql插件的不穩定性。

EOS的數據庫的落盤插件模塊，mongodb 之前是好的，中間他們就想廢棄了，換sql模塊。但這種朝令昔改，對于生態的開發用戶是致命的。

EOSForce.io 預防9 ：

EOSForce.io正在大規模招募區塊鏈開發者， 對filter模塊， 數據庫模塊會有更好，更持續的更新。

區塊鏈開發不比傳統軟件開發，如果一個模塊的漏洞導致大規模的丟幣事件，就算性能真達到百萬tps也沒有任何意義，安全穩定怎么強調都不為過。在保證安全穩定的基礎上，再去擴展性能，擴展特色。 

我們相信BM，也尊重BM給我們帶來充滿希望的EOSIO。 然而程序沒有BUG是不可能的。區塊鏈和中心化系統有本質區別，中心化系統的代碼更新和數據修改權限完全由中心化機構負責，可以隨意上線、發現BUG、修復BUG、回滾數據、沖賬、高速迭代等操作。

但區塊鏈沒法做到貌似沒BUG、或者沒有特別明顯的BUG就上線，鏈上數據全是最高價值的用戶資產相關的，即使99%沒問題了，也還是一定有問題，只要有任何一個可被攻擊的點或維度，區塊鏈網絡就一定會失敗，不要抱任何僥幸心理。

EOSIO代碼一年來經過了持續迭代，尤其是4月和5月，對以前更復雜的設計進行了裁減，一路修改到6月1號發布1.0版本，并沒有多少團隊對EOSIO進行過完整的測試。而傳統安全攻防級別的運維測試并不能算真正的測試。真正需要測試的是鏈上投票流程、資源相關、自定義合約等，這種測試用例真要寫起來也要寫幾個月，大家都知道，以太坊的測試數據和測試腳本是代碼本身的好幾倍。

今天，EOS的市值一度到達1000億人民幣，細枝末節多如牛毛，遠超過比特幣和以太坊上線時的規模。如果鏈本身的安全不能得到基本保證的話，用戶的資產會大量縮水或者歸零。

而Block.one官方一直強調不會對主網的安全負責。 EOSForce.io對EOSIO本身存在的重大風險做了大量的測試和修復，也不敢說目前一定是安全的。接下來，我們誠摯邀請各位EOS社區的用戶，節點候選人，第三方安全團隊一起來驗證一條安全的EOS主網。在確認無重大安全隱患后再行上線。 歡迎登陸EOSForce.io參與EOS主網公測。

向Oracle chain，EOS Shenzhen 等投票No go的團隊致敬，在安全問題上，沒有任何妥協的余地。