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