近期，各類DeFi專案屢屢遭受駭客攻擊，損失慘重。駭客們有的利用DeFi產品設計和程式碼實現方面的漏洞實施入侵，有的利用了以太坊始終沒有徹底解決的重入攻擊問題竊取DeFi平臺資產。早在去年9月，Qtum的聯合創始人Jordan Earls就在部落格上對以太坊解決重入攻擊問題的解決方案進行了解讀，並提出了自己的建議。我們也翻譯了這篇乾貨滿滿的技術評論，並在今天再次分享出來。在半年後的今天來看，其中觀點與建議仍然具有建設性的意義，有助於開發者和使用者加深對區塊鏈安全的理解。以下為部落格內容：當我在寫另一篇不相關的文章的時候，接觸了以太坊生態裡建立的假設。本篇文章我將會講述為什麼以太坊假設是有缺陷的以及給出相應的解決方案。首先，我們需要知道以太坊假設是什麼。假設的內容是為了向以太坊智慧合約傳送ETH，同時為了避免重入攻擊，呼叫智慧合約的 gas limit 應該不多於2300。魔力數和STATICALL每一個使用transfer函式傳送款項的現代智慧合約中（如果我沒記錯的話，在Solidity3.0之後），都有一個硬編碼的常數——2300。例如在這個簡單的例子中：contract Tester{     function() external{

         address payable paymentAddress = 0x5A0b54D5dc17e0AadC383d2db43B0a0D3E029c4c ;         paymentAddress.transfer(5);     } }Transfer位於轉譯成EVM位元組碼後如下：CALL 2300, address, ....這個數字為何如此重要？這樣決定是有原因的。

這曾經是防止一類被歸為“重入”的智慧合約漏洞最有效率的方式。重入的概念是，一個智慧合約呼叫另一個智慧合約，最終（在同一次執行過程中）再一次呼叫了原來的智慧合約。重入是在臭名昭著的the DAO駭客事件中被利用的主要漏洞。當時提出的解決方案不是透過改變以太坊協議來允許合約阻止這種行為，而是最終透過改變Solidity讓向智慧合約傳送ETH的預設行為使用非常少量的gas，這樣重入問題就無法再被利用。當然，也有一個副作用，這個改變讓收錢的智慧合約只能在日誌裡記錄一個事件，而不能改變狀態或者做任何別的事。但最近以太坊引入了STATICCALL，作為防止重入問題的靈丹妙藥。它真的是靈丹妙藥麼？回答是——不全是。首先，我們試著強制Solidity在我們的測試合約的fallback函式中使用STATICCALL：pragma solidity ^0.5.9;contract Tester{     function() external view{

     }     function foo() external view{     } }然後編譯器用以下報錯獎勵了我們的冒險精神：browser/test.sol:4:5: TypeError: Fallback function must be payable or non-payable, but is "view".

    function() external view{    ^ (Relevant source part starts here and spans across multiple lines).而且，有趣的是，並沒有明確的“non-payable“關鍵字來明確地標識一個函式為non-payable。讓我們從fallback函式里去除view關鍵字，檢查這個ABI：[    {        "constant": true,

        "inputs": [],        "name": "foo",        "outputs": [],        "payable": false,        "stateMutability": "view",        "type": "function"

    },    {        "payable": false,        "stateMutability": "nonpayable",        "type": "fallback"    }

]所以，Solidity決定一個fallback函式的stateMutability只能是non-payable或者payable，不允許是“view”。但我們假裝Solidity不那麼糟糕，而是允許這麼做。然後你就可以讓Solidity使用STATICCALL向一個合約的fallback轉錢，一切正常了嗎？還是不行。STATICCALL的設計很有些特殊。當然，你可以在邏輯中使用fallback函式，但是STATICCALL的設計用意是允許外部合約呼叫而沒有副作用，只返回計算結果的資料。Fallback函式實際上沒有返回資料的概念，雖然如果你下降到呼叫者和被呼叫者的彙編層面來看這可以實現。所以，STATICCALL在這個場景下沒什麼用，除非你在做什麼很少見的操作。但是如果你要做些不常見的事情，為什麼不寫一個常規的函式呼叫而要用fallback函式呢？好吧，我有些跑題。STATICCALL強調的是沒有副作用。這意味著你沒法做以下操作：· 更改狀態· 呼叫另一個會更改狀態的合約

· 建立合約· 自我銷燬一個合約· 在日誌裡記錄事件· 給別的合約傳送ETH，或者更改一個合約的餘額· 因為一個合約被STATICCALL而收到ETH你能預計到不能更改狀態，因為正是從這個角度直接阻止了重入錯誤的發生。雖然，我沒預料到在日誌裡記錄事件也被禁止了。在日誌裡記錄事件對智慧合約來說沒有可見的實際副作用。一旦一個事件被記錄在日誌裡，一個外部（或內部）的智慧合約就無法看到這個狀態被記錄了。這完全是個空輸出。你向虛空中傳送了資料，但是再也不能收到那些資料，甚至不能觀察到那些資料被髮送過。這個副作用只有在區塊鏈外的世界裡才可見。事件通常被用來通知外部介面進入區塊鏈，就像說“這兒發生了你可能會感興趣的事情”。

所以，假設以技術純粹性的名義，STATICCALL非常嚴格地執行了“無副作用”這條規則。無副作用裡的副作用包括了只有外部可見的副作用。另外的效果當然是ETH不能在STATICCALL裡進行轉移。這有效地打破了它作為解決重入問題競爭者的局面。通常來說，當呼叫fallback函式時，你或者犯了錯，或者想要給一個合約傳送ETH。當一個合約收到ETH時，它通常會在日誌裡記錄一個事件來告訴外部程式”嘿，我收到了一筆錢，你可能想要對此做點什麼，給那個使用者發個資訊之類的”。在有神奇的2300 gas limit時，沒法給另一個合約傳送部分ETH，也不能更改合約內的狀態，比如更新一下”預計餘額“變數之類的。STATICCALL的唯一用處是從你不想送出ETH的合約的廣義函式那裡阻止重入攻擊。這意味著，唯一有效阻止重入攻擊，又能傳送ETH、允許創造事件的方式仍然是以前的方法，使用神奇的gas limit常數——2300。這為什麼會是個大問題？這並不是在說硬編碼數字在電腦科學裡被認為是不好的（提示：這確實很不好），而是說硬編碼數字實際上使一些合約會在需要以太坊周圍的生態環境做一些改變時變得無法執行。動態區塊鏈裡的常量這個reddit帖子［1］提供了一些有用的細節，指出了以太坊之前在一次升級中增加了CALL指令和一些其他指令的最小花費（如果我沒記錯的話當時最小花費是100，現在是500）。這類顧慮在未來所有gas price調整的時候大都依然適用。Nick Johnson指出“有明確gas limit的呼叫非常少有“。在這句話提出的時候，Solidity會在做與transfer相等的操作時把所有能用的gas都轉移到一個合約裡，於是就留下了利用重入類操作進行攻擊的可能性。Solidity在the DAO攻擊發生後引入了2300的gas limit，為了阻止發生類似事件。現在，公平地說，在預設情況下呼叫外部合約函式（不用transfer）時，Solidity仍然會預設把所有gas都傳送過去。而且文件裡關於這個操作的隱患有無數警告。神奇的2300 gas limit常數僅僅強化了那個reddit帖子裡指出的問題。比如說，想象一個合約有一個payable的fallback函式，這個函式使用了一些在部署的時候便宜到能在2300 gas limit內執行的opcode。但是，為了應對一次攻擊或者什麼之前沒發現的問題，後來這些opcode的價格大幅提高了。這個合約就會變得沒法使用，沒法從那些沒明確地將gas limit提高到高於2300（Solidity警告的行為）的合約那裡接受ETH。更糟糕的是，明確地提高gas limit會讓那些發起呼叫的合約暴露在被重入攻擊的危險中。所以，這個合約很可能就必須被棄用了。根據它接收ETH的實際邏輯（比如依賴一個特定合約給它傳送ETH），它很可能像被擋在了牆裡一樣，裡面的錢也沒法提取出來。這個2300 gas limit假設不僅僅對向後相容性有害。它也傷害了以太坊協議內的潛在的未來創新。例如，EIP-1293［2］，SSTORE的淨gas計量，是一個創新的協議改進，將會降低包括儲存在內的許多智慧合約行為的成本。它能使儲存的gas花費能反映出區塊鏈上的實際花費，這意味著當在一次執行中第二次寫入一個儲存鍵值的時候，將會花費更少gas。這符合常理，因為從區塊鏈的角度來看，第二次狀態修改幾乎沒有代價，而第一次狀態修改就幾乎給區塊鏈支付了足夠的費用。這個提案曾經被包括進了君士坦丁堡分叉，但在最後時刻被移除了［3］，因為發現這會給大量現存的智慧合約帶來危險隱患［4］。這個判斷是對的，這個改進會減少狀態儲存成本，進而帶來重入類的攻擊隱患，即使只有非常保守的2300點gas limit。這件事件中諷刺的一點是，提案的設計實際上會減少智慧合約重入保護的gas成本，而且這也是它的主要應用場景。

現在，為了EIP-1283的重入問題而提出的解決方案是EIP-1706［5］。這個提案中的改變可以總結為：淨gas值測量帶來的費用減少將不會在當前執行的gas limit低於2300時執行。所以，現在這個神奇常量在以太坊共識協議裡變得更加根深蒂固。這將會有效地迫使任何未來的EVM語言在合約呼叫時也使用硬編碼的2300 gas limit來防止重入攻擊的危險。這個神奇的假設基本上斷絕了儲存變得更便宜的可能性，更不用提以太坊將來要修復擴充套件性問題以及任何別的問題。即使有一天發明一種神奇方法能將所有儲存移到鏈下，使儲存基本免費，儲存的實際gas花費仍然不能低於2300，否則就會暴露在重入攻擊的危險中。可能的解決方案我說了很多，但這確實是個很難的問題是吧？我們正在討論區塊鏈，有關區塊鏈的所有技術都很難。這也是個事實，但同時，我也更傾向不認同以太坊團隊在改進共識協議時刻意強調的技術純粹性。實際上，我覺得EIP-1706因為硬編碼問題不會被以太坊主網接受，它不夠純粹。我個人預測EIP-1283會被無限期延期，可能最終會加入到以太坊2.0裡面。我會怎麼解決重入問題？有兩個可能的方案。第一個比較簡單：再加個opcode，但是加一個有用的。我的提議是加入這個opcode:

MAGICCALLWITHOUTREENTRANCYEXPLOITS 這確實是個需要讀很久的簡明的名字。但是嚴肅的說，這個opcode的作用與CALL基本一樣，除了以下改變：· 允許SSTORE（狀態更改），就像STATICCALL那樣· 其他任何事情都被允許老實說我不怎麼喜歡這個解決方案。我更喜歡解決本質問題，允許重入任何智慧合約。理想情況下，可以存在一個非常簡單的opcode，就像這個：KILLMEIFREENTRANT

這會在當前合約已經在呼叫棧裡時停止執行。這個功能只需要一個老道的開發者工作一晚上就能完成，然後再需要一個白天做安全性測試。這會允許在防止重入攻擊時不會涉及到儲存，並且能用如下的簡單程式碼非常低費地實現if callstack.exists(currentAddress) then throw但是說回來，我覺得這樣一個不夠“純粹”的opcode永遠不會被考慮採納進以太坊。還有更純粹的替代性方案，比如把所有的呼叫棧暴露給智慧合約。如果知道了呼叫棧裡都有什麼，就能簡單地寫一個Solidity函式來在棧裡迭代，檢查是否它自己的地址被包含在它裡面，來證明現有的執行時在重入。而且當然，如果不在預料之中，合約就會丟擲異常來阻止任何不想要的或者預料之外的行為。這也會允許在智慧合約里加入其他特性。例如，想象你舉辦了一場智慧合約能夠參與的眾籌。但是，你用黑名單拉黑了一些跟恐怖分子有關的智慧合約。恐怖分子能簡單地部署一個“過路“智慧合約，然後讓被黑名單阻擋的智慧合約呼叫”過路“合約，最後就能呼叫你的眾籌合約。如果有呼叫棧的資訊，這種行為就能被發現。現在在以太坊裡，完全無法在鏈上用智慧合約邏輯檢測這一點。現在以太坊上阻止重入攻擊的設計幾乎都本身存在安全風險。通常在合約執行的時候，一個變數會被設定成1，表明正在執行。當執行完成後，這個變數會重置成0。這樣，如果你在過程中執行一個合約呼叫，如果外部合約想要重新進入現有合約，這個合約會看到變數被設定成了1，然後中止執行。然而，如果有些邏輯問題導致執行結束了變數沒被重置回0會怎樣？基本來說，這個智慧合約就被隔離了，沒法再被操作，因為它一直認為它正在被攻擊。重入是以太坊生態內的頭號，也是被討論得最多的問題，同時也被一些網站列為在建立智慧合約時應該小心的第一號安全問題。這是導致了the DAO攻擊和一些其他的攻擊與異常的元兇。這也是智慧合約開發者最難正確處理的最難問題之一，所有大多數智慧合約就簡單地從根源上杜絕了這個可能。對我來說，以太坊還沒有實施什麼直接的方法來阻止重入十分不可思議。相反，依靠限制很多的STATICCALL機制或者神奇的2300 gas limit常數似乎優先順序更高。在我心中，這值得有一個一流的解決方案，而非一個建立在假設之上的醜陋修改。相關閱讀

1.Reddit帖子：https://www.reddit.com/r/ethereum/comments/57n2ql/why_i_believe_the_eip150_hardfork_may_break/2.EIP 1283：https://eips.ethereum.org/EIPS/eip-12833.《What is going on with the Ethereum hard fork update Constantinople?》：https://hackernoon.com/what-is-going-on-with-the-ethereum-hard-fork-update-constantinople-f453af698c0c4.《Constantinople enables new Reentrancy Attack》：https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9

5.EIP-1706：https://github.com/ethereum/EIPs/pull/1706