如何在以太坊伊斯坦布爾硬分叉之後保護你的智能合約不被重入攻擊。
即將於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（提款支付法）等工具來對我們的合約進行編程，以防止重入攻擊。