我們不時會遇到麻煩和災難，但我們不能期望逃離生命中的灰暗時期——因為以輝煌和金色為落日的生命不是常有的。
—— 西奧多·羅斯福
DeFi 變身“黑客提款機”
2020 年，整個世界都彷彿開啟了 Hard 模式 ，不管身處何種行業，我們每個人都或多或少的受到了影響。本就樹欲靜而風不止的區塊鏈行業更是可以用一波未平，一波又起來形容：
· 2 月 15 日，貸款協議 bZx 被黑客通過操縱預言機價格導致約 35 萬美元的損失；
· 3 月 12 日，惡意的“零出價拍賣”導致 MakerDao 500 多萬美元的不良債務;
· 4 月 18 日，Uniswap 遭受重入攻擊導致 1278 枚 ETH 的損失；
· 4 月 19 日，中國最大的 DeFi 平臺 Lendf.me 被黑客盜取價值超過 2500 萬美元的資產……
此起彼伏的攻擊事件，讓很多人蒙受財產損失，以至於對 DeFi 甚至區塊鏈都失去了信心。有人笑稱現在的 DeFi 平臺壓根就是“黑客提款機”……
回顧 2020 年的“每月一殤”，初露鋒芒的 DeFi 就像不停推巨石上山的西西弗斯，週而復始的無用功彷彿是去中心化和中心化博弈的輪迴。每當巨石滾落，都會迎來陣陣哂笑。打著“Code is law” 旗號的去中心化，卻始終無法保證“Code is safe”。一連串的事件中，我們既看到了雪中送炭，也看到了落井下石。面對嘈雜的聲音依然“在路上”我們想對同路人說：“路漫漫其修遠兮，同志們仍需努力。”
重入攻擊是怎麼回事兒？
4 月 18、19 日接連兩天的黑客攻擊都使用了同一種攻擊方式——重入攻擊。這個近期頻頻刷屏我們朋友圈的攻擊到底是什麼呢？
眾所周知，以太坊上的智能合約之間是可以相互調用的，這種調用使得多個合約可以配合實現複雜的邏輯和豐富的功能。但在錯誤或惡意的操作下，在合約對其它合約調用的執行過程中回調原合約，則很可能會突破原本設計的業務邏輯，讓合約執行一些“不正常”的操作。「合約回調原合約」，聽上去很是拗口，但這正是重入攻擊的核心——
通過回調原合約上的某一個函數，在原合約沒有預期的情況下，重新進入原合約代碼並再次執行合約。因為設計時往往不會考慮這種騷操作，所以第二次進入原合約後修改的數據可能會逃過第一層合約邏輯的檢查。對於支持交易和記賬功能的合約來說，逃過檢查的數據就可能繞過交易邏輯影響最終的結算。具體到兩次攻擊事件，都是利用回調函數進行重入攻擊，僅在具體實施方式上有所區別。在 Uniswap 事件中，攻擊者通過改變餘額變更順序進而操縱交易匯率牟利。而在 Lendf.me 事件中，攻擊者在合約緩存了第一次交易變更結果後又進行多次轉賬，致使合約後續的更改都被第一次交易緩存結果覆蓋，實現了一次付款多次提現。
這個鍋，ERC-777 不背
伴隨著 Lendf.me 事件的持續發酵，“ERC-777”、“重入攻擊”、“中國DeFi” 等關鍵詞被推上風口浪尖。尤其是 4 月 18、19 日接連的兩次黑客攻擊，都是以使用 ERC-777 代幣標準的 imBTC 為切入點，通過重入攻擊實現的。那麼這個鍋是不是應該由 ERC-777 來背呢？重入攻擊又是否可以避免呢？
眾所周知，在 ERC-20 標準下，智能合約收到 ERC-20 代幣時不會在鏈上得到任何通知，因此也無法即時響應。所以，如果用戶需要和智能合約進行 ERC-20 代幣轉賬等交互時（如使用 DeFi 產品借貸），通常要進行兩筆交易：先授權（approve），調用代幣合約的 approve 方法賦予目標合約轉移用戶部分資產的能力；再轉幣（transferFrom），由目標合約調用代幣合約的 transferFrom 方法完成轉賬。
每次交互都進行「兩步」操作的方式對用戶很不友好，所以大部分 DeFi 都會為了用戶體驗而在用戶授權時一次設置較大的資產額度（就像我們使用 DeFi 平臺時只需授權一次，後續可直接進行借貸交易）。如果 DeFi 合約出現漏洞或合約管理員作惡的話，之前授權的資產額度越大則用戶的損失也會越大。所以說，ERC-20 標準催生的“過度授權”的使用習慣增加了用戶資產的安全風險。
ERC-777 是於 2017 年發佈的以太坊鏈上代幣標準協議，並且向後兼容 ERC-20 標準。ERC-777 對智能合約的轉賬交互邏輯做了大幅優化：通過 callback 回調函數，可使智能合約收到 ERC-777 代幣轉賬時在鏈上立刻獲得通知，並即時做出反應。這樣，用戶直接通過代幣合約轉賬即可，無需提前授權給目標合約，降低了過度授權帶來的隱患。同時 ERC-777 標準也減少了用戶的操作步驟，把 ERC-20 標準下必須兩步甚至多步才能完成的操作直接變成了一步，讓用戶體驗變得更好。
與 ERC-20 相比，ERC-777 明顯對用戶更加友好。但是近期的攻擊事件使很多人對 ERC-777 標準的安全性產生了質疑，甚至把鍋全都甩給 ERC-777，覺得如果沒有 ERC-777，就不會有類似的攻擊事件。
但是，這個鍋不該 ERC-777 背。
首先，以太坊上的重入攻擊是沒法完全避免的，而進行重入攻擊的手段有很多種，ERC-777 並不是導致重入攻擊的唯一原因。例如在 2016 年以太坊上 the DAO 事件中，黑客利用 payable fallback 回退函數進行重入攻擊，導致了價值約 6 千萬美元的以太幣被盜。此事件促使以太坊硬分叉為以太坊 ETH 和以太經典 ETC 兩條鏈。
其次，合約開發者應該有意識地做好重入攻擊的保護。近期發生的攻擊事件中，都是由於 DeFi 合約本身在支持 ERC-777 代幣的同時，忽視了在使用 callback 回調函數的情況下添加“重入鎖”的重要性。黑客是利用合約安全管理的漏洞而非 ERC-777 的漏洞實行攻擊。而 callback 回調函數的設計有利於提升用戶體驗，對整個區塊鏈的發展和進步利大於弊，不應成為 DeFi 合約出現漏洞並遭到攻擊的藉口。
如何把提款機變成保險箱？
關於智能合約調用的重入機制帶來攻擊風險的問題，Conflux 有自己的權衡：現階段重入機制帶來的安全風險要遠遠多於它帶來的便利，可謂是弊大於利，因此 Conflux 將在虛擬機層面禁止“重入”行為。Conflux 上的合約將對重入攻擊免疫，但也無法實現有關於“重入”的功能。此外，考慮到未來仍有可能重新開放重入機制，Conflux 建議所有開發者在重要業務的合約代碼中都加入“重入鎖”，確保在執行過程中禁止重入調用，從根本上避免重入攻擊的可能性。
除了重入攻擊，黑客攻擊的方式還有很多種。Conflux 提倡 DeFi 產品的生態服務方在合約代碼層加強風險管理的同時，都能加強在鏈下進行實時動態監督。通過完善監控程序，保證在惡意攻擊行為發生時第一時間捕捉、通知並關停相關服務，做到儘可能減小用戶的資產安全風險。
DeFi 產品的開發者無疑是保障 DeFi 合約安全的第一責任人。但是，依靠各自為戰的開發者來維護 DeFi 生態的安全是不現實的。傳統計算機軟件領域已經有無數案例告訴我們絕對安全沒有漏洞的程序有多罕見，而軟件升級增加新功能的時候往往也是最容易引入新的漏洞的時候。DeFi 生態要發展就不可避免地會引入新的功能和新的標準，正如 ERC-20 到 ERC-777 一樣。此時如果開發者不熟悉這些新功能和新特性，就很可能在代碼中留下容易遭到黑客攻擊的漏洞。
Conflux 將以 CIP 的方式徵集提案
我們認為，建設和維護一個健康的 DeFi 生態除了需要吸引開發者和用戶以外，還需要建立一個讓大家討論新功能和新標準的平臺。這樣才能讓更多的人參與到生態發展的討論中來，從不同的視角查漏補缺，達到“眾人拾柴火焰高”的效果。例如在 2017 年制訂 ERC-777 合約標準的時候，如果當時就有人發現 ERC-777 合約的 callback 回調可能導致重入攻擊的風險並廣而告之，想必後來的 Uniswap 和 Lendf.me 等 DeFi 產品也不會留下這個漏洞。
為了匯聚社區成員的智慧和技術力量，Conflux 將以 CIP（Conflux Improvement Proposal）的方式徵集改進 Conflux 區塊鏈系統的提案。改進提案可以是對於系統設計或者代碼實現等方面的，也可以是新的 API/RPC 接口或者新的合約和錢包標準等。比如一個改進提案中可以提出一種比 ERC-777 更方便更安全的代幣標準協議，或者討論對於重入機制的現實需求和重新開放重入機制的意義等。我們希望通過這種方式讓社區成員一起參與討論，從各個角度全方位地評估將來 Conflux 上的每一項升級和改動，並幫助社區的開發者更深入地理解新功能的特性和使用不當時可能存在的風險，從源頭上堵住產品的漏洞。
寫在最後
最終，在 dForce 團隊的努力和溝通下，攻擊 Lendf.me 的黑客已經歸還了所盜資產，整個事態也趨於平靜。其實不管是旁觀者，還是從業者，我們既不應該盲目樂觀，但也大可不必過分悲觀，更不應該去嘲笑失敗者。十年前，電子商務剛剛興起的時候，京東曾受到大規模攻擊導致數據外洩，淘寶同期也因受到攻擊導致近 2400 萬用戶資料洩露，但是它們不僅沒有被擊倒，反而成長得更加強大。
機遇永遠與風險並存。沉溺於安全區固然不會有風險，但同時也會失去未來的可能性。就像吳曉波在《大敗局》中提到的，在今天的商業世界中，企業失敗率最高的地方是美國硅谷，而那裡也正是全球商業創新的心臟。
誕生短短兩年的 DeFi 仍脆弱如襁褓中的嬰兒，需要精心呵護的同時也擁有著無限可能的未來。我們堅信，只要整個行業攜手前行，即便 DeFi 成長的道路上荊棘遍佈，我們亦可毫無懼色甘之如飴。道阻且長，行則將至；行而不輟，未來可期！
——————————
Vessenes, Peter (18 June 2016). “Deconstructing theDAO Attack: A Brief Code Tour”
https://vessenes.com/deconstructing-thedao-attack-a-brief-code-tour/
