智能合約審計的條件競爭

前言

與大多數區塊鏈一樣，以太坊節點聚合交易並將其形成區塊，一旦礦工解決了共識機制（目前是以太坊的 ETHASH PoW），這些交易就被認為是有效的，解決區塊的礦工也會從這個礦池中選擇哪些交易將被包含在區塊中，這通常由 gasPrice 交易決定，這裡存在潛在的攻擊向量，攻擊者可以觀察交易礦池中可能包含問題解決方案的交易， 智能合約審計服務 修改或撤銷攻擊者的許可權或更改對攻擊者不利的合約中的狀態，攻擊者可以從該交易中獲取數據並創建更高級別的交易gas Price並將其交易包含在塊中。

有條件的競爭

該合約包含 1000 個以太幣，找到並提交正確答案的用戶將獲得此獎勵。 當用戶找到答案並以答案為參數調用求解函數時，不幸的是，攻擊者可以觀察到交易礦池中的任何交易礦池。 看到這個解決方案的人提交的答案，檢查它的有效性，然後提交一個gasPrice遠高於原始交易的新交易，解決問題的礦工可能會先打包攻擊，因為攻擊者的gasPrice更高，攻擊者會獲得 1000 以太幣，最初解決問題的用戶將不會獲得任何獎勵（合約中沒有剩餘以太幣），出現條件競爭問題

防禦措施

有兩種類型的用戶可以進行這種類型的早期交易攻擊：

用戶（修改交易的gasPrice）

礦工自己（他們可以根據需要重新排序交易）

總體而言，易受類型 1（用戶）攻擊的合約比易受類型 2（礦工）攻擊的合約要差得多，因為礦工只能在解決區塊時執行攻擊，這對任何目標都非常重要。特定區塊的單個礦工，以下是一些緩解措施：

氣體限制

可以採取的一種方法是在合約中創建一個約束，即 gasPrice 上限，以防止用戶增加 gasPrice 並獲得超出上限的交易優先順序，這種預防措施只能緩解第一類攻擊者（任意用戶）的攻擊， 智能合約審計 在這種情況下，礦工仍然可以攻擊合約，因為無論gasPrice如何，他們都可以隨意訂購交易。

披露計劃

更可靠的方法是儘可能使用提交-顯示方案，該方案規定用戶使用隱藏信息（通常是哈希）發送交易，在交易被包含在區塊中後，用戶發送交易以解密已發送的數據（披露階段），該方法防止礦工和用戶前瞻性交易，因為他們無法確定交易的內容，但該方法無法隱藏交易價值（在某些情況下，需要隱藏有價值的信息），ENS 智能合約允許用戶發送交易，其承諾數據包括他們願意花費的以太幣數量，然後用戶可以發送任何價值的交易，並且在披露階段用戶退還交易中發送的金額他們願意花費的金額之間的差額。

相關討論

關於 Approve 函數的「條件競爭」問題已經有過廣泛的討論：

首先是以太坊官方給出了一個建議：

上面的主要意思是限制approve函數把quota從N變成M，只從N變成0，再從0變成M，可以通過下面的語句來限制：

後來有人提出，上面的安全建議可以解決「交易訂單依賴」，但如果加上require，合約將不符合ERC20標準規範。

這裡reduce Approve的意思是在原有「quota」的基礎上減少「quota」

筆者認為，如果將approve、增加approve、減少approve這三個函數放入一個合約中，並且這三個函數都是public的，並且approve函數中沒有安全判斷，那麼如果用戶仍然可以調用approve對於「配額」劃分，此時的增減審批與不存在基本相同，此時合約仍存在「交易訂單依賴問題」。

在對智能合約進行審計的過程中，筆者發現很多合約採用以下三種方式來處理「批准交易訂單依賴」的問題：

1. 增加安全判斷需要審批，

2、使用增減審批功能代替審批功能。 Approve 功能維護 ERC20 標準，不增加安全防範要求，

3. 使用增減審批功能代替審批功能。 Approve 功能使用 require 進行安全保護。

上面的解決方案可以在很多地方看到 bsc 智能合約審計 其中第一、二居多，第三居少。 「交易訂單依賴」問題的解決可以從以下兩個角度來看：

從安全形度看：第一種和第三種可以成功解決「交易順序依賴」問題，而第二種仍然不能有效解決「交易順序依賴」問題。

從ERC20標準來看：第一種和第三種違反ERC20標準規範，第二種符合ERC20標準規範。

小思考：加上「require」判斷是為了安全，不是為了標準，你會怎麼選擇？ （雖然這種類型的漏洞更難利用）

文末總結

合約開發者應建立一套開發標準，同時儘可能收集網路上公開的現有合約的漏洞類型、利用方式和安全修復方式，然後不斷完善自己的開發體系，推出合約. 之前建議找專門的公司對合約進行安全審計，對合約進行評估。