本期作者：Tiny熊，深入淺出區塊鏈社羣發起人、登鏈科技創始人、登鏈學院首席講師。"
不要因為一次攻擊，就拒絕使用新技術。
可重入攻擊不是 ERC777 的錯
週末兩天 Uniswap 和 Lendf.me 都發生了駭客攻擊事件，都是 DeFi 應用與 ERC777 組合應用導致可重入漏洞，其中導致 Lendf.me 損失抵押資產千萬美元。
發生這樣的事情，相信是所有從業者不願意看到的，本文也無意針對 Lendf.me，你們也是受害者，只是看到有人甩鍋給 ERC777 ，不忍從技術角度說幾句公道話。要把鍋全甩給 ERC777 ，是特朗普壞（甩鍋給你，只因你太優秀）。
ERC777 是一個好的 Token 標準， 可以極大的提高 DeFi 應用的使用者體驗，透過使用的 Hook 回撥機制，在 ERC20 中需要二筆或多筆完成的交易（當然還有其他的特性），而使用 ERC777 單筆交易就可以完成。
對行業的發展我一直是樂觀派， 如果因為本次攻擊，拒絕使用 ERC777，那一定在開歷史倒車。這次事件挫敗了大家對 DeFi 的信心， 從長遠看，我相信會讓行業更健康。
可重入攻擊是怎麼發生的？
下面我用一段簡潔的程式碼說明可重入攻擊是如何發生的（警告，以下是程式碼請勿使用），下面是 DeFi 應用最常見的邏輯，deposit 函式用來存款，存款時會記錄下使用者的存款金額，withdraw 函式用來取款，取款在餘額的基礎上加上一個利率。
在互動過程中，存在 3 個角色，使用者、DeFi 合約、Token 合約， 使用者存款和取款的時序圖是這樣的：
此時一切執行正常，（經過測試後）使用者在一段時間之後可以贖回 110 個 Token，開開心心釋出上線了。
後來上線了一個 ERC777 代幣， ERC777 定義了以下兩個 hook 介面：
用來同時傳送者和接收者進行相應的響應，當然傳送者和接收者也可以選擇不響應（不實現介面）。
ERC777 的轉賬實現一般類似下面這樣：（transfer 和 transferFrom 實現差不多，下面用 transfer 舉例)
簡單來說，就是在更改傳送者和接收者餘額的前後檢視是否需要通知傳送者和接收者，大部分情況下，普通賬號對普通賬號的轉賬（因為普通一般不會實現介面）和 ERC20 效果上一樣的。
如果傳送者和接收者實現了 ERC777 的轉賬介面， 上面的存款呼叫時序圖就是這樣的：
在 DeFi 合約呼叫 Token 的 transferFrom 時，Token 合約會呼叫 tokensToSend 和 tokenReceived 以便傳送者和接收者進行相應的響應。注意這裡 tokensToSend 由使用者實現，tokenReceived 由 DeFi 合約實現。
這個回撥能做很多有趣的事情，比如：可以把授權和存款合併為一筆交易，使用者直接呼叫 Token 合約的轉賬，DeFi 合約收到轉賬後，在 tokenReceived 中完成使用者的存款操作。
ERC777 協議沒有對使用者如何實現 tokensToSend 及 tokenReceived 做出規定，DeFi 合約開發者也不應該對參與方的實現進行任何的假定。在 Lendf.me 的攻擊案例中，駭客使用者就是在 tokensToSend 的實現中，呼叫了 DeFi 合約的 withdraw ，駭客使用者合約的程式碼大概是這樣的：
駭客攻擊的時序圖如下：
注意 tokensToSend() 、 withdraw() 和 tokensReceived() 函式都是在 transferFrom() 中執行的，根據 deposit 的程式碼：
只要前面 3 個函式沒有出錯，transferFrom 執行成功之後，就重置使用者餘額（駭客合約）為 100（存款金額）。而實際上駭客已經把所有存款全部取出，從而實現了一次對 DeFi 合約的攻擊。
大家都沒方法控制合約的實現，但是甩鍋到 ERC777 對嗎？那麼對於 DeFi 開發者，如何避免攻擊呢？
避免 ERC777 重入攻擊
其實可重入攻擊一直都存在，OpenZeppelin 也給過解決方案，給 DeFi 合約加上重入限制即可。
給 deposit 和 withdraw 函式加入重入限制後，此時如果在 tokensToSend 中呼叫 withdraw 就會失敗而回退交易。很明顯在 DeFi 合約中可以避免重入攻擊。
最後希望 Lendf.me 度過難關。
