很多人說交易所被黑、錢包被盜，區塊鏈是不是不安全。其實很多問題是來自在區塊鏈上搭建DApp、系統或相關應用程式的開發者，因為不熟悉區塊鏈、沒有做安全審計，導致程式上出現漏洞，而非區塊鏈本身的問題。
如果從智慧合約的漏洞來講的話，之前有一個十大漏洞的整理，裡面最著名的是溢位漏洞(overflow)。一般出現在加法減法或是對數值做運算的時候，如果沒有上下限，或者任何檢查的話，有可能數值會加超過儲存空間，就會溢位使數值歸零。這在很多的合約上都遭到攻擊，現在大家都用一個叫safe math的模組庫來做修正。
另外還有編譯器版本造成的問題，像是solidity 0.4.13這個版本，它會直接忽略空字串，如果在呼叫一個函式時，第一個函式若是空字串，第二個字串會直接遞補上去。那這樣的遞補就可能造成原本打算轉錢給自己或其他人，但產生其他結果。
還有比較酷的東西就是，有人開始會在網路上搜尋大量的智慧合約看看有什麼漏洞，藉此獲得錢財。而介於白帽與黑帽駭客之間的「灰帽」，就發明了蜜罐合約(honey pot)。蜜罐合約有趣的地方就是，它是用來反駭客的，合約內容會故意顯現一些明顯的漏洞，吸引比較弱或經驗少的駭客攻擊，蜜罐合約則會透過抵押的方式把駭客的錢鎖進這個合約裡面。
最近大家可能比較關心的是，以太坊計劃更新時所發現的re-entrancy漏洞。從技術上來講，你要讓一個合約將錢轉給其他人的時候，有三種路徑：call/transfer/send。早期來說只有用call這個指令，但它沒有gas上限，假設當一個合約出現漏洞時，它可能會持續被執行。所以出現了transfer/send兩種路徑，將gas上限設定在2300個gas，基本上做完一次傳送之後，就不會再次執行。
也就是說，如果你的合約有re-entrancy漏洞，但用的指令是transfer/send兩種路徑的話，發生這種錯誤的可能性就幾乎是零。
如果君士坦丁堡讓部分邏輯最佳化，讓資料儲存與更新時所需要的gas下降，也就是說讓轉送錢財過程之後，你仍然可以執行一些錯誤邏輯，這就會使得re-entrancy漏洞又再度被允許。
其實如果是按照正常的智慧合約開發程式，是不會發生這樣的重複訪問漏洞(re-entrancy)。
現在在市場上最建議的合約開發順序，在一個函式內應該是先檢查放入的變數是否符合期望，再去執行內部邏輯，直到最後一兩行，再去呼叫外部邏輯。
重複訪問漏洞(re-entrancy)做錯的就是，我先呼叫外部邏輯，再做內部邏輯。那如果外部邏輯是有問題的話，那你的函式有可能就不會結束，內部邏輯就不會被呼叫到，而是一直執行錯誤，或者是惡意的外部邏輯。其他還有許多安全議題可以說，不僅是以太坊，EOS也有自己的問題。
大家看待區塊鏈安全問題時不用太驚慌，技術人員應借漏洞累積經驗，而一般使用者則瞭解不同開發環境的狀況去做一些策略上的調整。
文章來源：BB財經（www.bbcaijing.cn），轉載請註明出處！
