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

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

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

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

什么是可重入攻擊？

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

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

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

當我們調用不受信任的智能合約或將資金轉入不受信任的帳戶時，我們的代碼容易受到重入攻擊的攻擊。可以對這些帳戶進行特殊編程，以在重入調用期間濫用不變違規。

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

function withdraw（uint _amount） public {

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

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

balances［msg.sender］ -= _amount;

}

}

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

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

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

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

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

ReentrancyGuard（重入保護）

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

ReentrancyGuard（重入保護）是一段代碼，當檢測到重入時，該執行會導致執行失敗。OpenZeppelin合約中有一個稱為ReentrancyGuard（重入保護）的模式實現，該模式提供了nonReentrant修飾符。將此修飾符應用于函數將使其變為“不可重入”，并且通過重新調用將拒絕重新輸入該函數的嘗試。

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

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

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

Pull Payments（提款支付法）

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

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

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

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

總 結

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