【本期分享主題】Libra與區塊鏈安全問題剖析
【本期特邀嘉賓】墨子安全實驗室創始人苗知秋
分享嘉賓：苗知秋
資訊安全專業博士，畢業于中國科學院資訊安全國家重點實驗室，長期從事資訊安全研究作業，在P2P網路安全、物聯網安全和區塊鏈安全等方面有較深的研究積累。目前為墨子安全實驗室創始人、墨客區塊鏈公司首席安全官，并擔任多家區塊鏈公司的資訊安全顧問。
Q1：資訊安全對于區塊鏈行業意味著什么？目前的安全態勢如何？
區塊鏈行業是一個比較特殊的行業，最突出的特點就是涉及大量數字資產的管理，動輒千萬上億的資產全部存在鏈上，通過一個256位元的私鑰來確權，誰掌握了這個私鑰，誰就是資產的主人。
這使得資訊安全在區塊鏈行業的重要性空前提升。可以說對于區塊鏈行業來說，沒有安全就沒有一切。這不是危言聳聽，隨著各類安全事件的不斷披露，區塊鏈行業對資訊安全的重視度也持續升溫。
可以說，目前資訊安全已經成為區塊鏈產業發展的關鍵環節。
那么，如何評價目前的安全態勢呢？我們同意派盾公司的判斷，如果把目前的區塊鏈安全劃分為非常安全、安全、令人堪憂、極度危險四個等級的話，現階段區塊鏈安全是令人堪憂的。
黑客對于攻擊區塊鏈興致持續高漲，主要原因如下：
(1)區塊鏈技術帶來的資產數字化，使得大量數字資產存盤在鏈上，不光人人都看得見，讓黑客還有了摸得著的機會，在巨額資產的傭訓下，黑客的攻擊動力幾乎是無限的；
(2)數字資產變現非常容易，與傳統的資料盜竊然后非常費勁的變現不同，數字資產可以直接通過7*24的交易所變現；
(3)數字資產的匿名特性使得黑客非常容易逃避追查，安全性更高。
(4)區塊鏈技術雖然是去中心化的，但是這個行業存在大量的基礎設施是中心化的，并且區塊鏈的實作也依賴于很多傳統的IT基礎設施，如手機、云主機、web service等，這使得黑客可以借助原先的技術手段和工具，攻擊門檻并不高。
高額收益、容易變現、極易逃避追查、攻擊門檻低，這四者的疊加，使得區塊鏈安全事件將持續處于高危期。
Q2：區塊鏈安全主要涉及哪些方面？有哪些熱點問題？核心問題是什么？談一下墨子安全實驗室對區塊鏈安全的理解，以及主要的安全服務內容？
區塊鏈安全防護是一個系統性作業，涉及的環節很多，不但有很多傳統安全方面的作業，如云主機防護、通信安全、手機安全、APP防護等，還有大量的特色安全內容，如智能合約安全、礦池風控、交易所安防等。
從墨子安全實驗室的角度，我們一般把區塊鏈安全分成兩類五方面。
第一類，區塊鏈自身安全，這一類包括兩個方面：區塊鏈底層安全和上層智能合約安全。
第二類，區塊鏈配套設施安全，這一類包括三個方面：錢包、交易所和礦池。
這五個方面都屬于區塊鏈安全范疇，我們認為其中三個方面是需要特別關注的熱點問題，即智能合約、交易所和錢包。這也是安全問題比較多、安全事件比較頻發的地方。
如果要說區塊鏈安全的核心是什么？我們認為就目前的區塊鏈發展現狀，安全問題雖然很多，但核心只有一個，那就是數字資產安全。區塊鏈安全領域的攻守兩方基本上都是圍繞著這一點來的。
這也影響到了區塊鏈安全行業對安全漏洞的評級標準的制定。與其他行業不同的是，區塊鏈行業中，凡是威脅到數字資產安全的，一律評定為高危漏洞，否則評定為中危或低危漏洞。
墨子安全實驗室的安全服務也主要是圍繞我們所認為的區塊鏈安全熱點問題開展的。鑒于我們實驗室規模有限，所以也一直不斷凝練和聚焦我們的作業方向。
目前主要是三方面的作業：
（1）區塊鏈安全測評方向：包括區塊鏈底層測評、智能合約安全審計和測評、錢包安全測評、交易所安全測評和礦池安全測評。
（2）數字資產安全防護方向：包括事前的風險教育、錢包選擇、環境檢測，事中的私鑰管控、轉賬管控，事后的私鑰缺失找回和丟幣追蹤、應急回應等。
（3）安全資料可視化方向：包括區塊鏈運行態勢監測、DAPP運行態勢檢測與例外行為預警、資金流轉檢測與例外告警等。
此外，我們也提供安全培訓、安全技術咨詢、安全開發支撐、真亂數等服務。
Q3：智能合約安全問題的本質是什么？智能合約最常見的安全問題有哪些？為什么智能合約安全問題如此頻發？2016年年中，以太坊上最大的眾籌專案the DAO撰寫的智能合約出現漏洞，被轉走300多萬枚以太幣，市值近6000萬美元，迫使以太坊開發人員執行“硬分叉”將資產找回。請分析這件事的影響和啟示。
在我們看來，智能合約安全的本質是合約意圖和實際實作之間的差異。換句話說，就是開發人員以為要做的事跟合約實際執行中所做的事出現了不一致。這一定義幾乎可以囊括所有的智能合約安全事件，我們認為是比較符合安全本質的。
智能合約常見的安全問題包括：重入攻擊、計算溢位、越權訪問、交易順序操縱、拒絕服務等。
合約安全問題的頻發，有三個方面的原因：
第一，因為智能合約往往涉及數字資產的發放和管理，對于黑客來說，攻擊合約的產出投入比是非常可觀的，有足夠的動機；
第二，智能合約是一個非常新的事物，從以太坊提出到現在不過四五年的時間，還存在一些缺陷需要彌補，問題迭出也是成熟程序中不可避免的，這也是促使合約技術成熟必不可少的，合約技術的真正成熟還需要時間；
第三，因為現有的一些合約開發人員，對智能合約的本質理解不到位，對智能合約的開發不熟悉，對合約的運行環境理解不清，還是一味地照搬之前的老思路，導致問題頻發。
關于DAO事件，先大概介紹一下事件本身。
The DAO安全事件是以太坊發展史上的一次重大安全事件，大概程序是這樣的：就是有攻擊者利用DAO智能合約可重入攻擊的安全漏洞，盜竊了大量DAO募集的資金。具體來說就是攻擊者讓自己的提現程序反復重入，按照系統限制，同樣的取款操作攻擊者可以反復執行1024次，這樣計算下來，使得存款100的用戶可以取現102400。
我們認為The DAO事件是以太坊發展程序中的一個重要里程碑，不能單純地看作一次安全事件，需要從多個角度來看。從不利的方面來說，一度幾乎讓以太坊陷入滅頂之災，實際上也確實導致了以太坊社區的大分裂，以太坊社區元氣大傷；從有利的角度來說，通過這次事件，以及對這個事件如何處理的大討論，讓整個社區迅速從幼稚走向成熟，讓以太坊后續發展越來越穩健，最終成為無可厚非的區塊鏈2.0代言人。
DAO事件帶來的啟示，我認為主要有兩點：
發生安全事件并不可怕，也是難以避免的，重要的是能否采取正確的應對措施，并吸取教訓，教育社區，讓安全事件成為生態健康發展的養料。對于ETH來說，通過DAO事件的考驗并成熟起來了，因此我們成為是以太坊發展史上的里程碑，如果以太坊因為DAO事件折戟沉沙，那只能稱為以太坊發展史上的墓碑。
處理問題的正確態度應當是原則性和靈活性兼備，極端的原教旨主義并不可取。ETH社區對于DAO事件的處理就有兩種截然不同的分歧，一方認為對于這種證據確鑿的攻擊行為，為避免重大損失，應當回滾賬本，另一方認為區塊鏈和智能合約的根本在于可信和不可篡改，因此應當愿賭服輸，不應該回滾賬本。后者我們稱之為區塊鏈的原教旨主義者。最終雙方誰也說服不了誰，于是分道揚鑣，由此以太坊分裂為ETC和ETH兩個幣種，相應地，以太坊社區分裂為兩個社區。從這幾年的后續發展來看，ETH社區的發展明顯優于ETC社區，后續處于不斷萎縮的狀態。實踐是檢驗真理的唯一標準，因此，我們認為，前者處理問題的態度更值得我們借鑒，后者的極端化思路需要警惕。
Q4：美圖BEC溢位清零事件的影響和啟示是什么？
先簡單介紹一下計算溢位是怎么回事。所謂計算溢位就是計算結果超出了系統能夠正確表示的數值范圍的最大上限或者下限。前者稱為上溢位，后者稱為下溢位。例如以太坊的數值上限是2^256，超過這個數字系統就無法正確表示，也就是說在這個數值范圍之外的計算結果是錯誤的，但合約意識不到，繼續使用錯誤的結果進行后續流程，這樣就會導致嚴重的后果。
計算溢位攻擊是區塊鏈安全中最常見的攻擊手段，其中美圖BEC溢位清零事件是此類攻擊的巔峰之作，直接導致一個最高市值一度630億美元的數字幣直接歸零。
事件的起因是BEC合約中的轉賬函式缺乏溢位檢測機制，攻擊者利用這一點直接賦值實作結果溢位，結果超發天量的BEC幣。BEC幣的總量是10億枚，最終超發的結果是總量變成57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000個，直接導致幣值崩盤，數億美元資產灰飛煙滅。
這一事件的發生，讓業界對計算溢位問題有了充分的重視，并大量使用safemath庫，避免溢位問題的發生。但是在實際作業中，類似的錯誤依然屢見不鮮，因為計算溢位是一個常見的現象，在其他行業中也很常見，但后果相對較輕。在區塊鏈時代，涉及到數字資產的計算和轉賬，那么計算溢位的后果就嚴重多了，BEC就是一個典型的例子。
目前，這個問題雖然可以通過引入safemath庫來得到很大程度的緩解，但并沒有得到本質的解決。我們認為，溢位問題是底層錯誤，因此應該從底層解決才是徹底的解決方案，從上層加強檢查固然在一定程度上可以緩解，但是只能治標不能治本。同時還帶來很多副作用，比如給開發人員帶來很多額外的負擔，導致開發效率的低下，同時隱患沒有徹底排除，隨時會有爆發的可能。
因此，我們希望在將來的區塊鏈技術中，可以從底層使這一安全隱患得到徹底解決，從此遠離計算溢位的安全陰影。
Q5：請分析EOS彩虹攻擊事件的原因、影響，以及對從業者的啟示。
EOS彩虹攻擊事件的本質是亂數問題。問題的根源在于部分私鑰生成工具允許用戶采用強度較弱的助記詞組合，而通過這種方式生成的私鑰很容易被“彩虹”攻擊，進而導致賬戶數字資產被盜。
錢包的安全基礎是亂數種子，凡是隨機性不夠的，如使用“12345678”、“123456”等弱口令當助記詞，或是使用之前各大網站已泄露的密碼庫中的密碼當助記詞的，統統存在賬戶被盜的風險。
亂數的核心要義是不可預測性，這也是對亂數最基本的底線要求。一旦亂數被人預測到，則基于隨機性的安全體系將立刻崩塌。用通俗點的語言來說，隨機性的本質是猜不到，如果你使用的亂數可以被人猜到或者推測出來，那么就不是亂數，或者隨機性不夠。亂數雖然看起來不起眼，但它卻是資訊安全的基礎之一，由于亂數問題導致的安全事件層出不窮。
特別是在區塊鏈世界里，我們的資產安全其實就是依賴于一個亂數來保護。如果這個數字被人猜到了，那么資產也就變成別人的了，如果別人怎么也猜不到，那么資產就是安全的。
亂數在區塊鏈世界中的作用如此重要，承載了數千億美元的資產，因此對于亂數問題萬萬不可輕忽。亂數生成器有真隨機和偽隨機之分，偽亂數生成方便，成本低，但是隨機性有限，真亂數生成條件苛刻，要求高，但是可以實作真正的隨機性。
普通場景使用偽隨機也足以滿足使用，但對于區塊鏈這樣涉及大額甚至巨額數字資產保護的行業，為了你的資產安全，我們強烈建議使用真亂數。
Q6：軟體錢包和硬體錢包的主要區別是什么？使用上有什么建議？
軟體錢包和硬體錢包最主要的區別在于私鑰的保存和使用方式。
軟體錢包成本非常低，使用起來非常便利，但是用戶的私鑰一般是通過加密等方式保存在本地，然后在使用的時候解密。這樣就導致一個比較嚴重的安全問題：至少在某一段時間內，私鑰會以明文的方式出現在本地，從理論來說，是可以被攻擊者獲取或者泄露的，這樣就對數字資產的安全造成了直接的不可忽視的威脅。這也是軟體錢包在安全上最大軟肋。
而硬體錢包則不然，硬體錢包成本較高，使用上相對不便，將私鑰保存在加密芯片中，通過特殊設計的控制電路，使得私鑰無法給讀取出去，只能在芯片內部使用。這樣，用戶在轉賬的時候，看不到私鑰，只能得到私鑰簽名之后的密文，這使得私鑰的泄漏和被竊取的風險降到最低，這是硬體錢包最大的優點。
結合兩者的優缺點，軟體錢包和硬體錢包分別有不同的應用場景和使用方式。軟體錢包適合數字資產數量有限，使用頻度較高，對于便利性要求更高的用戶。
硬體錢包適合數字資產額度較大，需要更高安全保護等級的用戶。通常的建議是使用軟體錢包保存自己的小額資產，供日常使用，硬體錢包保存大額資產，輕易不動，這樣可以實作便利性和安全性兼備。
目前已經出現軟硬體結合的數字錢包方案，在很大程度上結合了兩者的優點，對于用戶來說是一個更佳的選擇。
Q7：私鑰保存在常見的錯誤有哪些？怎樣保存私鑰才安全？助記詞和私鑰是什么關系？
私鑰保存的常見錯誤是將私鑰保存在云盤、云筆記、郵箱中，或者用手機拍照保存，這都是非常危險的容易泄露私鑰的方式。
對于私鑰保存，我們建議如下：
1. 用紙筆保存，不要依賴電子設備，因為電子設備容易出安全事件，也存在出現安全故障的可能；
2. 紙筆記錄后要反復確認，主要有以下幾點：
（1）私鑰位數是否正確，是否有遺漏或者重復記錄（這種情況我們見到過很多次）
（2）對于私鑰中容易混淆的字母、數字要特別加以標記，如w與W，P與p，q與9等。
3. 建議分多份保存，避免因為物理損壞、丟失等造成不可預料的后果。
前面我們說過很多私鑰記錄的不便之處，因為私鑰本身是給計算機使用的，對人來說可讀性非常差，上面說得諸多問題很多時候都是由此而起，因此對于紙筆記錄，我們更推薦使用助記詞的方式。
助記詞實際上是二進制的另外一種表現形式，重點突出對于人的可讀性。在實踐中，助記詞一般用來記錄密鑰種子，從這個種子可以產生出用戶使用的私鑰。實際上，也完全可以將原始私鑰映射為助記詞來使用，盡量避免直接記錄原始助記詞。
Q8：區塊鏈應用開發者，特別是智能合約開發者，以及普通用戶，在安全方面應當注意哪些問題？
對于基于區塊鏈的應用開發者，特別是智能合約開發者來說，我們提供如下建議：
1. 對于開發人員提供必要的安全培訓，提升安全意識，引入SDLC安全開發生命周期管理流程；
2. 開發中建議使用推薦安全框架，多參考成熟的安全范例和安全模板
3. 要盡快轉化并習慣“去中心化”思維，時刻提醒自己：你面對的是良莠不齊的純分布式環境，不是傳統的中心化開發環境。
4. 不要輕信，要驗證，不要使用自己發明的密碼演算法，謹慎對待亂數、哈希函式等貌似不起眼的演算法，仔細審查使用的每一個第三方庫，避免被釣魚
5. 補齊密碼學和資訊安全的基礎知識，了解基本的安全攻擊手法；
6. 不要有依賴心，專案的安全性取決于開發者自身，而不是采用某種平臺或某種語言
7. 不要存僥幸心理，發現問題馬上糾正，不要嫌麻煩，安全來自長期警惕，事故源于瞬間麻痹。
8. 建立完善的安全審計機制，建議聘請第三方安全顧問，不要因為省小錢損失大錢。核心模塊必須經過嚴格審計
9. 上線前充分的測驗和安全審查，因為智能合約一旦部署糾正成本很高
對于普通用戶而言，我們的建議只有一件事：保護好自己的私鑰。
Q9：最近FACEBOOK公司的Libra專案，引起業界高度關注。可否從安全的角度對Libra專案做一個簡單點評？
libra的出現對區塊鏈行業來說是一件大好事，所以我覺得在談Libra的安全問題之前，首先要肯定Libra在安全方面付出的努力，對于后來者具有很好的參考和借鑒價值。就我們目前針對libra的技術調研來看，Libra吸取前期教訓，充分意識到安全的重要性，在安全方面付出了很多努力，包括我們看得見和看不見的。
時間有限，我們簡單說一下Libra在安全方面所做的一些作業。
首先，架構設計上，采用了可信計算方面的概念。Libra把可信計算基（Trusted Computing Base）的思想用在了核心代碼的架構設計和撰寫中。可信計算基是計算機系統安全領域的一個概念，指計算機系統中對系統安全性最重要的一部分，和其他的部分隔離，以保障這部分核心安全組件的正常運行。
Libra Core中也試圖將軟體中的重要部分打造成可信計算基，對依賴庫和其他代碼的依賴性做到最小，節點功能由幾個相對獨立的組件實作，將重要的部分和其他不太重要的組件實作隔離。
另外，作為區塊鏈系統的底層基礎，Libra的P2P網路使用了Noise協議，這個協議也用在國外的Whatsapp中，這是一個社交通信應用，安全性更好。
要加入驗證節點池，節點必須通過當前驗證節點池里的某個網路公鑰進行認證。驗證節點池啟動階段需要一些種子節點，種子節點認證新的驗證節點。這樣可以抵御Ethereum 類的區塊鏈中常見的地址池污染，提高惡意節點加入的門檻。
其次，合約方面。Move 是從迄今為止發生的與智能合約相關的安全事件中吸取經驗而創造的一種編程語言，能從本質上令人更加輕松地撰寫符合作者意圖的代碼，從而降低了出現意外漏洞或安全事件的風險。
特別值得指出的是四個方面的作業：
一方面，節點的資料和代碼隔離，代碼叫做Module，資料被視作資源單獨存盤在另一個模塊Resource中。在計算機架構設計中是比較安全的做法。
另一方面，Move的設計更有利于靜態驗證。因為代碼審計領域，靜態驗證是發展最成熟的領域，如果語言對于靜態驗證比較友好，那么就很容易發現其中存在的安全問題，有利于安全檢測。
為此，Move不支持動態派遣（dynamicdispatch），就是說每個被呼叫的物件都是可靜態確定的，不會產生復雜的控制流圖（CFG），也避免產生Ethereum合約中經常出現的重入攻擊漏洞。Move中的變數的型別是相對靜態固定的，避免型別轉換中經常發生的錯誤。模塊化程度高，便于應用靜態分析工具。
第三，Move把數字資產不是看作普通的資料，而是視為一等資源（First-Class Resource），設計中考慮到滿足一等資源的稀缺性、訪問控制，一等資源可以創建、銷毀，但是進入Libra后，不能被復制，只能被移動（moved），這也是Move 語言名字的來源。這樣讓move語言具備了明確的資產程式語言的特性，有效避免了使用普通程式語言處理金融資產所可能帶來的各類安全隱患。
最后，代碼每次被運行前，都要經過鏈上的安全驗證，類似JVM中的加載時位元組碼的驗證，這在一定程度上保障了被執行代碼的安全性。
再次，共識機制安全。
共識機制安全是區塊鏈安全的生命線。Libra 區塊鏈采用了基于LibraBFT共識協議的BFT機制來實作所有驗證者節點就將要執行的交易及其執行順序達成一致。而LibraBFT基于2018年新提出的HotStuff協議，一種基于leader的拜占庭容錯復制協議，包括關于安全的投票/提交承諾規則和保活機制，允許惡意節點（即拜占庭容錯引數）不超過總數的1/3.
這種協議的特點是幾乎不會分叉，實時確定性好，特別有利于Libra未來很可能會重點關注的支付、匯兌和資產交易場景。
第四，實作語言安全。rust語言的特點是注重安全性，在編譯環境強調規范的使用和檢查，通俗地說，只要編譯通過，安全方面就具有了較高的水準。因此rust安全性較高，是一種在安全方面比較有特色的語言。
下面我簡單介紹一下Libra在設計和實作上存在的一些不足。
Libra肯定會存在漏洞，它們自己也公布了賞金獵人計劃，征集漏洞。但是目前尚無確定性的漏洞被指出。但是，根據我們對區塊鏈安全的測評經驗，認為Libra在下面幾個方面會存在安全問題有待解決。從目前對Libra的初步研究成果，Libra雖然已經盡力解決前期發現的安全問題，但是距離徹底解決還有不小的距離。
1. 共識機制安全：
Libra的共識機制最近鬧得沸沸揚揚，起因是一篇文章指出Libra的共識機制存在嚴重安全問題，并宣稱攻破了核心的LibraBFT共識協議。目前Libra 尚未對該文發表回應，而該文發布6天后被作者自行撤回。我們找到作者發表的相關文章進行了研究，就這一問題大概給大家解讀一下。
“AnotherLook at Byzantine Fault Tolerance”指出BFT解決方案里的一些問題，并以HotStuff為例，例如PBFT和HotStuff 需要可靠的廣播信道，一旦廣播信道不可靠，就不會達成共識，即使這些協議的前提條件“部分同步網路”滿足，也不能達到共識。
作者之前發布過對Algorand的分析，指出Algorand在BFT不超過1/3的情況下，可能發生分叉，并且指出BFT解決方案中的一個普遍假設“大多數節點是誠實的”并不合理，因為在利益驅動下，任何節點都可能不遵守事先約定的行為規則，反倒是位元幣的假設比較合理，位元幣假設任何節點都可能是惡意的，但是假設這些惡意節點被統一到同一個攻擊者麾下，協調組織起來聯合作惡的概率是很小的。Algorand至今也未對該分析做出回應。
我們認為，共識協議是區塊鏈的核心，共識協議的安全域定了區塊鏈的安全。BFT類的共識協議適合聯盟鏈或私有鏈，一旦要用于公鏈，需要非常慎重。Libra也聲稱自己要從聯盟鏈出發，等成熟后再推出公鏈。基于Libra的遠景目標，Libra的交易會影響各國法幣的流通狀況，如果在共識協議的安全性不太確定的情況下成為公鏈，會吸引各國的黑客，甚至有可能導致國家力量介入，那時后果不堪設想。
2. 虛擬機計算溢位處理機制：沒有看到libra在這方面有什么建樹，如果依然依賴合約的自我約束和代碼檢查，那么距離理想的解決方案，還有一段距離。
3. 亂數：Libra 使用Rust的rand::rngs::EntropyRng 作為種子生成私鑰、密鑰。而EntropyRng首選采集作業系統的亂數生成介面OsRng。如果失敗，采用JitterRng生成器，基于CPU執行時間、記憶體訪問時間等系統操作的抖動，隨機性比OsRng要好，但是性能上比較慢，因為需要等待足夠長的時間。
在Secret Service 代碼庫中使用了Rust的基于流密碼演算法ChaCha的亂數生成器ChaChaRng, 密鑰的匯出未來將支持前向安全性（ forward security）, 即當前密鑰的泄露不會危及以前使用的密鑰的安全性， 后向安全性或泄露后安全性，即當前密鑰的泄露不會影響未來可能生成的密鑰的安全性、以及增強的熵。
亂數種子的安全性方面和現有的區塊鏈持平或更好，但是并未采用真亂數，可能是專案方認為目前的亂數產生機制已經足以滿足要求，或者在未來的升級中再進一步采用真亂數。
4. 第三方庫依賴：無較大創新，與之前的區塊鏈專案持平。
5. 實作語言：
選擇了一個非常小眾但宣稱安全性突出的語言RUST。但語言的安全無法確保實作的安全，因為我們知道，安全的關鍵是人，是設計者、開發者，如果開發者安全意識和水平夠高，不安全的語言可以可以開發出安全的產品，反之，程式員不靠譜，再安全的工具和平臺也無法阻止他犯錯誤，甚至很低級的錯誤。
漏洞常常來自代碼實作程序。比如Rust代碼，RUST本身的庫函式，使用的其他第三方庫的安全性。Libra生成亂數的函式就是用的RUST本身的函式，RUST社區也在討論亂數生成函式的安全升級。所以RUST語言雖然具有安全的特色，但是并不完美。
6. 單一性依賴問題：Libra如果完全依賴RUST語言實作，那么會存在單一依賴問題，如果RUST語言出現安全問題，則會波及整個Libra系統，這一點可能需要時間來解決。
7. 一些想法只提出沒實作：
Libra含混的提到當私鑰泄露時，可更換公私鑰對，而賬戶地址保持不變，用戶也可輪換一個賬戶里的密鑰。這是一個非常好的想法，可以提升用戶的便利性。由于傳統區塊鏈地址是由公鑰變換得到的，而私鑰和公鑰是一一對應的，不知道Libra采用什么方式實作公鑰和地址的脫離。但是我們看目前代碼中的賬戶地址還是公鑰的keccak哈希值，不具備更換的能力。我們也很期待看到Libra專案在這里有所突破。
uj5u.com熱心網友回復：
精彩互動Q：智能合約交易順序操縱是如何做到的？如何防范？
這是因為礦工在打包交易的時候，有一定的自主權限，他可以確定那個交易放在前面，那個交易放在后面。這個順序按照慣例，是誰gas費給的高，誰就優先打包。這樣，攻擊者可以通過設定非常高或者非常低的gas，誘導礦工按照他的意圖打包交易，達到操縱交易順序的目的。
防范措施，建議不要認為同一個區塊內交易的先后順序就是交易實際發生的順序，不要基于這個假定來設定條件。因為區塊中的內容和順序作為礦工打包的產物，實際產出是可以被操縱或者誘導的，不宜作為可信的資訊。
Q：安全資料可視化中的資金流轉檢測是怎么做到的？可以追蹤洗錢的路徑嗎？
這得益于區塊鏈賬本資料的公開透明，通過對原始資料的匯總、清洗和挖掘，是可以追蹤每筆資金的轉移路徑的。我們主要是從安全的角度對資金流轉程序進行分析。
區塊鏈中的原始資料無法直接分析，必須要進行整理之后，利用大資料挖掘技術，發現有用的資訊。但是對于賬本不公開的匿名數字幣，目前沒有太好的辦法追蹤。
區塊鏈鏈行業中的洗錢行為，如果是傳統的混幣洗錢，相對而言還可以抽絲剝繭，慢慢梳理。但是天生匿名的數字幣，如門羅等，就沒法監控了。
Q：Libra為什么選擇RUST這么小眾的語言呢？有沒有更優的選擇？
我不是Libra官方，按照我們的推測，Libra選擇RUST語言的初衷，應該是看中了RUST的安全性。因為對于Libra宣稱的跨境匯兌來說，安全性是第一位的，這個選擇在某種意義上也是給未來的潛在客戶看的，讓客戶放心地選擇Libra。
至于有沒有更優選擇，這個選擇需要放在Libra的整體場景和發展目標下看，是多方權衡妥協的結果，從來就不是一個單純的技術問題。我相信，Libra選擇RUST語言也是這樣一種妥協的結果，因為Libra最了解自己要做什么，自己的目標是什么，自己的客戶是什么，所以我們無法幫助Libra作出更佳選擇，不在其位不謀其政。
但是為了避免單一依賴問題，Libra未來必將會選擇多種語言實作，以分散風險，確保系統整體的魯棒性。
備選語言，我想應該會有Java/C++等老牌勁旅，也會有Go等新銳，Libra的路剛剛開始，未來的路還很長，現在很多地方還存在爭議，所以現在很多選擇都存在變數。
Q：安全漏洞比例最大的是記憶體安全問題，（見微軟安全回應中心的文章，70%的安全漏洞是記憶體問題引起的）。而Rust語言的安全性恰恰就是解決記憶體安全（常見的記憶體安全問題，當然不完美，也不可能完美）。記憶體漏洞是跨語言漏洞，多用一種語言就多一份風險，其實并不能改善安全性。
這是一種經典的安全防護思路，安全問題必須從整體上考慮，不能只看區域。區塊鏈作為去中心化的P2P架構，不怕部分節點出問題，擔心的是全部節點出問題。因此如果單一使用rust語言實作，誰敢打包票說rust萬壽無疆、刀槍不入？萬一某天rust爆出系統性漏洞，Libra就全軍覆沒了。因此為了實作系統級的安全，必須要把風險分散。如果所有的rust部署節點出問題，在解決rust問題期間Go語言節點還可以支撐系統運行，Go語言出問題，在解決Go語言問題期間Java節點也可以讓系統正常運行。那么如果rust，go，java同時出問題呢？概率比rust一個出問題的概率小多了啊，這就叫千斤重擔萬人挑，人人頭上有指標。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/31831.html
標籤：區塊鏈技術