區塊鏈世界裡不能信什麼?

2019-11-25     雲霧風景

「節點應該是把自己看成在黑暗叢林裡孤身求生存的獵人,必須有「獨立自主」、「自給自足」的態度,擺出「不相信其他任何節點」的姿勢保護自己。」

責編 | maozz、carol

來源 | Fisco Bcos開源社區

出品 | 區塊鏈大本營

建立Don't Trust,Just Verify的理念,才是通往區塊鏈世界的正確態度。

平時總在聊信任區塊鏈,這次來聊一聊區塊鏈世界裡,不能信的有什麼?

一、不信任其他節點

區塊鏈節點和其他節點會建立P2P通信,共同組成網絡,傳遞區塊、交易、共識信令等各種信息。其他節點可能是由不同的機構、不同的人持有,持有節點的人可能是善意,也可能是惡意。

即使在善意假設時,節點運行存活的健康度也會受運維水平和資源影響,比如處於一個不穩定的網絡里,會偶爾掛掉,會抽風亂髮消息,或者硬碟滿等原因導致數據存儲失敗,以及出現其他可能的故障。

在惡意假設時,要預設其他節點可能會騙自己或傷害自己,比如傳遞過來錯誤的協議包,或者用詭異的指令尋找漏洞進行攻擊,或者發起高頻垃圾請求,頻繁連接然後斷開,又或者海量連接占用資源等。

所以節點應該是把自己看成在黑暗叢林裡孤身求生存的獵人,必須有「獨立自主」、「自給自足」的態度,擺出「不相信其他任何節點」的姿勢保護自己。在節點准入時,需要採用證書技術來認證節點身份;在連接控制上,拒絕有異常的連接;採用頻率控制對連接次數、請求量等做限制;在協議包格式和指令正確性等方面做驗證。自己發出去的信息,不應暴露自己的私有信息,也不期望其他節點一定會給出立刻和正確的響應,必須採用異步處理和校驗容錯的設計。

二、節點和客戶端互相不信任

客戶端,指在區塊鏈網絡外,向區塊鏈發起請求的模塊,如業務使用的java sdk、錢包客戶端等。客戶端和節點通過網絡埠通信。

如果客戶端掌握在不受控的人手裡,有可能會向節點發起大量的請求,或發送一堆垃圾信息,使節點疲於應對,甚至巧妙地構建漏洞攻擊信息,試圖越權訪問,竊取信息或使節點出錯。

同時,從客戶端的角度看,節點有可能不響應或響應緩慢,或者返回錯誤的數據,包括格式錯誤、狀態錯誤、表示收妥但其實不處理等,甚至別有用心的人會設置一個「假」節點和客戶端通信,欺騙客戶端。節點做出這些與期望不符的反應,可能使客戶端運行出錯,功能受損。

為提升節點和客戶端的互信,可以為雙方分配數字證書,必須通過證書進行雙向握手,客戶端經過私鑰簽名才能對節點發起交易類請求,節點應對客戶端進行權限控制,拒絕高危的接口調用,不要輕易開放節點管理接口、系統配置接口等。雙方對每次通信的數據格式、數據有效性都進行嚴密校驗。

雙方在交互時也應該進行頻率控制,異步處理,對每一個交互進行結果校驗,不能預設對方正確處理,必須獲取交易回執和處理結果進行確認。

當認為只和一個節點通信並不能保證安全時,客戶端可以採用「f+1查詢」的思路,儘可能多地和幾個節點通信。如果當前鏈的共識安全模型是「3f+1」,那麼,如果從f+1個節點讀到的信息是一致的,結果是可以確認的。

三、不信任區塊高度

區塊高度是一個非常關鍵的信息,代表整個鏈當前的狀態。向區塊鏈發送交易、節點間進行共識、對區塊和狀態的校驗等操作都會依賴區塊高度。

某個節點在斷網或處理速度緩慢時,其區塊高度有可能落後於整個鏈,又或者某個節點惡意偽造數據時,其高度又可能超過整個鏈。在鏈出現分叉時,如某一個分叉上的區塊高度被另一個分叉超越,落後的分叉就會變得毫無意義。即使在正常的情況下,節點依舊有可能間歇性地落後於整個鏈一到幾個區塊,然後在一定時間內才可能追上最新高度。

如在PBFT共識模型里,總數2/3以上節點在同一個高度時,全鏈就有機會達成共識繼續出塊。餘下的1/3的節點有可能和參與共識的節點高度不同,這時意味著從這個節點讀取到的數據,並不是全網最新的數據,只能代表鏈在該高度時的一個快照。

業務邏輯可以把區塊高度做為一個參考值,基於高度做一些判定邏輯,在確定性共識(如PBFT)的鏈上,採用f+1查詢等方法確認鏈的最新高度,在可能分叉的鏈上,需要參考「6個區塊確認」的邏輯,審慎選取可信的區塊高度。

四、不信任交易數據

交易(Transaction)代表一方向另一方發起了一個事務請求,交易可能導致資產的轉移、改變帳戶狀態或系統配置,區塊鏈系統通過共識後確認交易,使相關的事務生效。

交易必須帶上發送者的數字簽名,交易里所有數據欄位都必須包含在簽名里,未經簽名的欄位存在被偽造的可能,不予採信。

交易數據在網絡上廣播時,可以被其他人讀取,如交易數據里包含隱私數據,發送者則必須對數據進行脫敏或加密保護。

交易可能因為網絡原因被重發,或者被其他人保存下來刻意再次發送,造成交易的「重放」,所以區塊鏈系統必須對交易進行防重,避免出現「雙花」。

五、不信任狀態數據

區塊鏈的狀態(State)數據是由智能合約運行後生成的,理想情況下,每個節點的合約引擎一致、輸入一致、規則一致,那麼輸出的狀態就應該一致。但不同的節點可能安裝了不同的軟體版本,或者合約引擎的沙盒機制不夠嚴密引入了不確定性因素,甚至被侵入、篡改,或者存在其他莫名其妙的bug,都可能導致合約運行輸出結果不一致,那麼一致性和事務性就無法得到保障。

狀態的校驗是成本很高的事情,典型的校驗方法是使用MPT(Merkle Patricia Tree)樹,把所有狀態都塞到樹里管理起來。MPT樹可以把所有的狀態歸結為一個Merkleroot Hash,節點之間在共識過程中確認交易運行後生成的狀態樹Merkleroot,確保狀態一致。

這棵樹結構複雜,數據量大,消耗不少的計算和存儲資源,很容易就成為了性能瓶頸。所以對狀態的校驗需要有更快、更簡單,且又穩妥的方案,如結合版本驗證、增量Hash驗證等算法,輔以數據緩存,可減少重複計算和優化IO次數,能在保證一致性、正確性的同時,有效地提升驗證效率。

六、不信任私鑰持有者

採用私鑰對交易以及其他關鍵操作進行簽名,再使用公鑰驗簽,是區塊鏈上最基礎的驗證邏輯。只要私鑰被正確使用,這個邏輯是安全的。

但私鑰僅僅是一段數據,只依賴私鑰則用戶是匿名的。在聯盟鏈面對的場景里,需要使用許可型的身份,首先通過KYC、盡調、權威認證等現實世界的驗證方式確認身份,然後將身份和公鑰綁定並公示,或者結合PKI體系的數字證書發放公私鑰,這樣私鑰對應的身份是可知、可信、可控的。

私鑰可能會因丟失、泄漏而被他人盜用,或者因被遺忘導致資產損失。所以在私鑰的保存上,需要考慮採用周全的保護方案,如加密存儲、TEE環境、密碼卡、USBkey、軟硬加密機等方案。在私鑰的管理上,則需要考慮密鑰丟失後如何安全的重置、找回。

加強版的私鑰使用思路有幾個,比如使用多簽、門限簽名等方式,每次交易時必須用多個私鑰進行簽名,私鑰可以保管在不同的地方,安全性高,但技術方案和使用體驗複雜。

還有一種是交易私鑰和管理私鑰分離。交易私鑰用於管理資產,管理私鑰用於管理個人資料,交易私鑰可以被管理私鑰重置,管理私鑰本身則通過門限、分片等算法,分開存儲保管,以備重置或找回。

七、不信任其他鏈

在跨鏈的場景里,每條鏈有自己的資產、共識,鏈之間的安全模型變得非常複雜,比如一條鏈上的記帳者串通造假,或者鏈出現了分叉、區塊高度回滾,這時如果鏈外的其他模塊和鏈有不夠嚴謹的交互,都會造成數據不一致或資產損失。

如果不同的鏈採用的還是不一樣的平台架構,那麼在工程上會更加複雜。

跨鏈、側鏈目前依舊是業界在研究和逐步實現的課題,主要目的是解決鏈和鏈之間的通信,進行資產鎖定和資產交換,保證整個過程的全局一致性、交易事務性,以及抗欺詐。從A鏈往B鏈轉移一個資產,必須要確保A鏈上的資產被鎖定或銷毀,且B鏈上一定能增加對應的一筆資產,在雙方可能分別出現分叉、回滾的時間窗里,要有機制確保雙向的資產安全。

在現有跨鏈的方案里,存在中繼、鏈間HUB等方式,這些系統的設計本身也要達到高度可信可靠的標準,安全等級應不低於甚至高於所對接的鏈,同樣也應採用多中心、群體共識的體系設計,整體複雜度可算是鏈的N次方了。

八、不信任網絡層

區塊鏈節點需要和其他節點發生通信,所以必須在網絡上暴露自己的通信埠,如果通過公網通信,那麼相當於在公網上暴露了自己,很容易遭到類似滲透、DDOS這樣的網絡攻擊。節點必須在網絡層保護自己,包括在網關上設置IP黑白名單、設置埠策略、進行DDOS流量防護,且對網絡流量、網絡狀態進行監測,如果突髮網絡流量或連接數暴增,說不定,就是被人當肉雞或者正在脫庫進行時了。

非必要埠,切忌對公網開放,如用於做管理監控的RPC埠,只能對機構內部開放,在進行網絡策略設定之前,一定要慎之又慎。

九、不信任代碼

「Code is law」確實是一句響亮的口號,但是在程式設計師頭髮掉光之前,他寫的代碼都可能有bug,只是看寫bug快還是修bug快而已。

無論是底層的代碼還是智能合約代碼,都可能存在技術性或邏輯性的坑,但凡代碼產生的數據和指令行為,都需要另一段代碼對其進行嚴格地校驗,代碼本身也需要進行靜態和動態掃描,包括採用形式化證明等技術進行全面地審核驗證,以檢測可能的邏輯錯誤、安全漏洞或是否有信息泄露。前段時間有一份公布到github上的某酒店系統的代碼,居然包括了mysql的連接用戶名密碼,且資料庫埠居然是向公網開放的,這種坑簡直不可想像。

開放出去的開原始碼,固然可以被人審查、反饋以提升安全性,也可能被人翻找漏洞、隨意修改,甚至惡意埋雷。但總的來說,開源還是利大於弊。在開源社區中,開發者會向項目提交PR(Pull Request)。審核PR是很關鍵也很繁重的工作,值得安排專家並分配大量時間去做審核。有開源項目的老司機透露,其項目核心模塊的PR的審核時間長達經年,否則「加了個功能引入兩個bug」那真是得不償失,更別說如果被植入漏洞埋雷了。

十、不信任記帳者

共識的流程大致可以抽象為,選出記帳者,記帳者發布區塊,其他節點校驗和確認。公鏈里記帳可以用「挖礦」的方式進行(如比特幣),礦工用大量的算力代價為它自己的誠信背書,又或者是用大量的資產權益抵押獲得記帳權(Pos和DPos等共識)。在聯盟鏈常用的PBFT/Raft等算法裡,記帳者列表可以是隨機或輪換產生,記帳者給出提案,其他投票人多步提交,收集投票。按少數服從多數的原則,一般是2/3以上共識節點同意,共識才能達成。

從系統可用性角度看,記帳者有可能出錯、崩潰,或者運行緩慢,影響整個鏈的出塊。又或者記帳者可以只收錄手續費高的交易,拋棄一些交易,導致有些交易總是不能達成。有的記帳者還可以憑藉算力或暗箱運作,進行「預挖」或者「扣塊攻擊」,破壞博弈關係……

記帳者故障或作惡,超越了共識的安全閾值的話,將直接傷害整條鏈的價值基礎。根據不同的記帳模式,記帳者需要設計不同的容錯、校驗、抗欺詐算法,執行激勵和懲罰機制,在運行過程中定期檢查記帳者的健康度,對於無力記帳或者作惡的記帳節點,全網不接受他們的記帳結果,並對其進行懲戒,甚至是踢出網絡。

……

羅列起來還有很多,包括合約、證書、同步等等,每一個模塊都有自己的功用和風險點,簡直罄竹難書。總之,區塊鏈做為分布式的多方協作的體系,接入了形形色色參與者,整個體系絕不是單個開發者或運營者所能單點把控,「善意推測」在這個領域已經不盡適用,整個世界步步驚心,處處冷箭,只能通過周密的算法和繁雜的流程維繫共識和安全,簡而言之,沒有經過驗證的信息,一個位元組都不能相信。

比起單一環境里的軟體設計,區塊鏈領域的設計思路確實存在顛覆性,開發者要從「做功能,只容錯,不防騙」的思維模式里跳出來,帶著「懷疑一切」的態度進行設計。

開發者在面向區塊鏈領域時,不能只是思考怎麼實現一個功能,而更要去思考整個流程會不會有出錯,會不會被人篡改數據、發掘漏洞、攻擊系統、欺詐其他參與者。要換位思考自己所實現的功能,會被別人用什麼方式使用,在不同的環境會有什麼表現,可能造成什麼後果。任何收到的信息,任何流程輸入、輸出,都必須經過嚴格地校驗才能採信,開發者能做到這一點,才算是打開了區塊鏈新世界的大門,才能在連續劇里至少活到第二集。

分布式算法、對稱非對稱加密、HASH、證書、安全和隱私等技術在區塊鏈領域大行其道,都是為了在保護信息的同時,給信息加上一層又一層的證明和可驗證因子,這使得整個系統變得複雜、繁瑣,但這是值得的,因為這樣才能共同驗證,構建「安全」和「信任」。

以上,寫給準備跳坑,或已經在坑裡的程式設計師。共勉。

文章來源: https://twgreatdaily.com/yv1hoW4BMH2_cNUgseFT.html