即將于12月初推出的伊斯坦布爾硬分叉包括EIP1884：“限制trie大小有關(guān)的操作碼”。關(guān)鍵字是“限制”，這意味著某些指令現(xiàn)在將花費更多的氣體來執(zhí)行。最近對此進(jìn)行了很多討論的原因是現(xiàn)有的可以少量氣體運行代碼，硬分叉后可能超過該限制，并導(dǎo)致會出現(xiàn)“out of gas”錯誤。

“以少量氣體運行代碼”的一個特例是任何Solidity智能合約中的fallback函數(shù)，因為它是由Solidity的transfer函數(shù)或Solidity和Vyper的send函數(shù)觸發(fā)的以太坊傳遞過程中運行的代碼。transfer和send都只允許以太坊的接收者以2300的氣體（實際上是零）。伊斯坦布爾到分叉后，接近此限制的fallback函數(shù)可能會停止工作，而任何調(diào)用這些函數(shù)的智能合約都將在有限的氣體中停止工作。

出于安全原因，到目前為止，推薦使用transfer和send來傳輸Ether。它們所允許的氣體不足以進(jìn)行重入攻擊，因此有論據(jù)認(rèn)為，它將保護(hù)智能合約免受它們的侵害。確實有……但是以太坊開發(fā)者社區(qū)現(xiàn)在正面臨這樣一個現(xiàn)實，即操作碼定價不能被認(rèn)為是穩(wěn)定的，并且如果我們希望構(gòu)建面向未來的系統(tǒng)，我們應(yīng)該尋求其他確保安全的方法。即我們應(yīng)該停止使用transfer，而轉(zhuǎn)而使用其他發(fā)送以太網(wǎng)的方法，而應(yīng)依賴其他安全技術(shù)來防止重入攻擊。

本文介紹了可重入性，目前可用于根據(jù)它獲得智能合約的技術(shù)，以及如何使用OpenZeppelin合約輕松在項目中實現(xiàn)它們。特別值得一提的是我們還沒有提到的一種技術(shù)：提款支付法（pull payments）。

什么是可重入攻擊？

智能合約在正常執(zhí)行期間可以通過執(zhí)行函數(shù)調(diào)用或簡單地轉(zhuǎn)移以太坊來執(zhí)行對其他智能合約的調(diào)用。這些智能合約本身可以稱為其他智能合約。特別是它們可以回調(diào)到調(diào)用他們的智能合約或回調(diào)棧中的任何其他智能合約。在這種情況下，我們說智能合約被重新輸入，這種情況被稱為可重入性。

重入本身不是問題。當(dāng)智能合約以“不一致”狀態(tài)重新輸入時，就會出現(xiàn)問題。當(dāng)智能合約特定的不變量成立時，狀態(tài)被認(rèn)為是一致的。例如對于ERC20主要不變性是所有智能合約余額的總和不超過已知的總供應(yīng)量。

通常函數(shù)假定它們開始運行時便以一致的狀態(tài)觀察智能合約，并且它們還承諾一旦完成運行就使智能合約保持一致。在執(zhí)行過程中，可能會違反不變量，這很好，只要沒有人能觀察到不一致的狀態(tài)。問題在于通過重入，這成為可能。函數(shù)完成時，不僅要保持不變量，還必須在每個潛在的重入點保持不變。

當(dāng)我們調(diào)用不受信任的智能合約或?qū)①Y金轉(zhuǎn)入不受信任的帳戶時，我們的代碼容易受到重入攻擊的攻擊?？梢詫@些帳戶進(jìn)行特殊編程，以在重入調(diào)用期間濫用不變違規(guī)。

這里的不變之處在于，智能合約中的資金額等于余額映射中所有條目的總和。在第三行執(zhí)行調(diào)用期間，由于_amount資金已轉(zhuǎn)出，但余額尚未更新，因此不變量被破壞了。 由于msg.sender可以是智能合約，因此同一調(diào)用允許重入。 如果攻擊者此時觸發(fā)了重入，他們將能夠從破碎的不變量中獲利。

function withdraw（uint _amount） public {

if （amount 《= balances［msg.sender］） {

msg.sender.call.value（_amount）（）;

balances［msg.sender］ -= _amount;

}

}

現(xiàn)在，我們將看到幾種抵御這些攻擊的方法。

Checks-Effects-InteracTIons（檢查-效果-交互）

我們應(yīng)該提到的第一種技術(shù)稱為Checks-Effects-InteracTIons模式。 它描述了一種在函數(shù)中組織語句的方法，以使智能合約的狀態(tài)在調(diào)出其他智能合約之前處于一致的狀態(tài)。通過將每個語句分類為檢查，效果（狀態(tài)更改）或交互作用，并確保嚴(yán)格按照此順序進(jìn)行操作來完成此操作。通過在交互之前放置效果，我們可以確保所有狀態(tài)更改都在任何潛在的重入點之前完成，從而使?fàn)顟B(tài)保持一致。

已經(jīng)對這種模式進(jìn)行了很多討論，您應(yīng)該在Solidity文檔中和ConsenSys的最佳實踐中對其進(jìn)行閱讀。

但是我們應(yīng)該對這種方法不滿意，因為它容易受到人為錯誤的影響：程序員必須正確地應(yīng)用它，而審閱者必須發(fā)現(xiàn)任何錯誤。是否可以減輕窮人的這種責(zé)任？

ReentrancyGuard（重入保護(hù)）

如果在執(zhí)行的任何時候不確定智能合約的不變量是否成立，則應(yīng)避免調(diào)用其他（不可信）智能合約，因為它們可能會被重入。 如果我們別無選擇，可以嘗試使用ReentrancyGuard來防止可重入。

ReentrancyGuard（重入保護(hù)）是一段代碼，當(dāng)檢測到重入時，該執(zhí)行會導(dǎo)致執(zhí)行失敗。OpenZeppelin合約中有一個稱為ReentrancyGuard（重入保護(hù)）的模式實現(xiàn)，該模式提供了nonReentrant修飾符。將此修飾符應(yīng)用于函數(shù)將使其變?yōu)椤安豢芍厝搿?，并且通過重新調(diào)用將拒絕重新輸入該函數(shù)的嘗試。

當(dāng)我們的智能合約具有多個函數(shù)時會發(fā)生什么？ 由于修飾符是針對每個函數(shù)的應(yīng)用，因此如果要完全防止重入攻擊，則必須將其應(yīng)用于所有函數(shù)。否則如果它對不可變的變量很敏感，仍然有可能重新進(jìn)入另一個函數(shù)并將其用于重入攻擊。

但是如果我們決定使每個函數(shù)都nonReentrant，則應(yīng)牢記Solidity的public變量。標(biāo)記為public的合約變量將生成一個getter函數(shù)以讀取其值，并且無法對該函數(shù)應(yīng)用修飾符。在大多數(shù)情況下，這不會引起重入問題，但仍然值得擔(dān)心，因為它可能會導(dǎo)致其他合約由于不可變而導(dǎo)致狀態(tài)不一致的情況（假設(shè)它們會保留）。

盡管有所有注意事項，但在某些情況下，重入防護(hù)（reentrancy guards）可能會很有價值。但是要完全消除可重入性也有其弊端：在某些情況下，可重入性是安全的，并且隨著以太坊智能合約變得更加復(fù)雜，可組合和相互聯(lián)系，我們可能會在外看到它的合法用途。

Pull Payments（提款支付法）

如果我們將Ether轉(zhuǎn)移到合約中但未執(zhí)行其代碼，則根本無法重入。通過使用selfdestruct，可以在EVM中繞過接收器的代碼。但是接收以太幣的合約需要以某種方式進(jìn)行處理，并且大多數(shù)沒有編程為處理通過自毀而收到的資金，這可能導(dǎo)致資金損失。

另一種選擇是提款支付模式（pull payment ）。這個想法是與其將資金“推”到接收者，不如將它們“拉”出合約。 OpenZeppelin合約在PullPayment合約中實現(xiàn)了這種模式。繼承此協(xié)定將提供類似于傳遞的內(nèi)部函數(shù)_asyncTransfer。但是它不會將資金發(fā)送給接收方，而是將其轉(zhuǎn)移到托管合約中。此外PullPayment還為接收者提供Public函數(shù)以提取其付款：withdrawPayments和withdrawPaymentsWithGas。

OpenZeppelin Contracts 2.4中添加了第二個命令withdrawPaymentsWithGas，以修復(fù)伊斯坦布爾的操作碼重新定價，并在實際的以太坊轉(zhuǎn)移過程中將所有可用的氣體轉(zhuǎn)發(fā)給接收器。請注意此時可以重新輸入，但這是安全的，因為PullPayment（提款支付法）不會使您的合約的任何不變式無效。

值得一提的是，提款功能可以由任何人調(diào)用，而不僅僅是接收方。這意味著收款人無需知道這是預(yù)付款的目標(biāo)，這在現(xiàn)有的智能合約無法自行付款時尤其重要。

總 結(jié)

由于操作碼定價不穩(wěn)定，我們不能再依賴轉(zhuǎn)移了，因此在后伊斯坦布爾世界中，重入變得不可避免。攻擊者可以將其用于破壞狀態(tài)不變性時調(diào)用不信任帳戶的合約。有必要通過根據(jù)checks-effects-interacTIons模式組織代碼，或使用諸如ReentrancyGuard（重入保護(hù)）措施或Pull Payments（提款支付法）等工具來對我們的合約進(jìn)行編程，以防止重入攻擊。