智慧合約可以部署其他智慧合約。這使工廠模式成為可能,在工廠模式中,您可以建立多個智慧合同,每個智慧合同只跟蹤一件事,而不是一個跟蹤許多事情的智慧合同。使用此模式可以簡化程式碼並減少某些型別的安全漏洞的影響。在這篇文章中,我將向您介紹一個基於我們在最近的審計中發現的一個關鍵漏洞的示例。如果使用了工廠模式,那麼漏洞就就減少了很多。越野車智慧合約下面是一個智慧合約,透過一個相當簡單的介面銷售WETH。如果您有WETH,你只需要批准這個智慧合約出售你的代幣,它將確保你得到正確的金額支付。只要批准充足的代幣,任何人都可以任意購買WETH。 合約使用提款模式將付款交付給賣方,但合約的作者犯了一個嚴重的錯誤:1// Technically this could sell any token, but we're selling WETH in this 2// example because then I don't have to think about prices. 1 WETH costs 1 ETH. 3contract WETHMarket { 4 IERC20 public weth; 5 mapping(address => uint256) public balanceOf; 6 7 constructor(IERC20 _weth) public { 8 weth = _weth; 9 }1011 // Buy WETH from a specified seller. Seller must first approve WETH.12 function buyFrom(address seller) external payable {13 balanceOf[seller] += msg.value;14 require(weth.transferFrom(seller, msg.sender, msg.value),15 "WETH transfer failed.");16 }1718 // Used by a seller to get their ETH. 19 function withdraw(uint256 amount) external {20 require(amount <= balanceOf[msg.sender], "Insufficient funds.");2122 // Whoops! Forgot this:23 // balanceOf[msg.sender] -= amount;2425 (bool success, ) = msg.sender.call.value(amount)("");26 require(success, "ETH transfer failed.");27 }28}(如果您想知道為什麼程式碼使用.call而不是.transfer,請閱讀“立即停止使用Solidity的傳輸()”)。因為賣方的餘額從未減少,所以欠任何以太的賣方都可以反覆呼叫withdraw()來消耗每個人的合約。這是一個嚴重的漏洞。修復這個bug,就像大多數bug一樣,一旦你發現了它,就變得微不足道了。但在這篇文章中,我想談談如何透過使用工廠模式來減輕這個bug,即使我們不知道這個特定的問題。現在讓我們看一下更簡單的WETHMarket合約版本。在這個版本中,合約只負責銷售一個賣家的WETH。此合約與先前版本具有相同的bug: 1contract WETHSale { 2 IERC20 public weth; 3 address seller; // only a single seller 4 uint256 public balance; // no need for a mapping anymore 5 6 constructor(IERC20 _weth, address _seller) public { 7 weth = _weth; 8 seller = _seller; 9 }1011 // No need to specify the seller.12 function buy() external payable {13 balance += msg.value;14 require(weth.transferFrom(seller, msg.sender, msg.value));15 }16 17 function withdraw(uint256 amount) external {18 require(msg.sender == seller, "Only the seller can withdraw.");19 require(amount <= balance, "Insufficient funds.");2021 uint256 amount = balance;22 23 // Whoops! Forgot this:24 // balance -= amount;25 26 (bool success, ) = msg.sender.call.value(amount)("");27 require(success, "ETH transfer failed.");28 }29}儘管存在完全相同的邏輯錯誤,但此漏洞並不是那麼嚴重。只允許一個帳戶呼叫withdraw(),並且合約中儲存的所有乙太網都屬於該帳戶。這個錯誤的影響只是餘額並不能反映合約中的真實餘額。這個bug是手工挑選來顯示其優點的,但是這個bug代表了託管協議中的一大類bug。根據我審計智慧合約的經驗,這是發現關鍵漏洞最常見的地方之一。託管背後的想法是,不同的資金必須分開存放,以確保合同始終可以涵蓋所有欠款。獲得託管權最簡單的方法之一是將資金完全分成不同的智慧合約。您可以將工廠模式看作是一種深入防禦的託管方法。簡單程式碼單賣方版本的合約不僅有更強大的代管,而且更簡單。我們去掉了一個函式引數和一個對映。在生產程式碼中,我們可能會更進一步,完全刪除balance,而代之以address(this).balance。因為我寫合約是為了方便閱讀,原來的程式碼已經很簡單了。在現實世界的例子中,這種差異可能更為顯著。從安全的角度來看,任何降低複雜性的機會都是一種勝利。工廠模式每個賣家都可以部署自己的Wethsale合約並從簡單的合約中獲益,但是這種方法有一個主要的缺點,惡意賣家可能會部署稍微修改過的程式碼版本,但實際上並沒有傳輸weth。即使像ConsenSys Diligence這樣有信譽的公司稽覈了WETHSale程式碼,每個買家也必須驗證他們購買的具體合約是否使用了那些確切的程式碼。使用工廠可以解決這個問題。工廠確保每個部署的合約都使用相同的程式碼,並且它提供了一個簡單的查詢機制來查詢給定賣方的單一合約:contract WETHSaleFactory { IERC20 public weth; mapping(address => WETHSale) public sales; constructor(IERC20 _weth) public { weth = _weth; } function deploy() external { require(sales[msg.sender] == WETHSale(0), "Only one sale per seller."); sales[msg.sender] = new WETHSale(weth, msg.sender); }}潛在缺陷使用工廠模式的一個主要缺點是價格昂貴。CREATE操作碼目前的燃氣成本為32,000。我們的特殊合約還需要另外兩個SSTORE來跟蹤WETH和賣方地址,每個地址需要20,000燃氣。這比程式碼的原始多賣家版本至少多72,000氣體。另一個潛在的缺點是複雜性。在大多數實際情況下,工廠模式簡化了現有的合同,但請記住,它還新增了一個新的合同:工廠本身。根據程式碼的不同,這可能會導致複雜性的增加。在決定工廠模式之前,請仔細考慮變更的總體影響。總結1. 託管方面的錯誤是導致關鍵漏洞的一個重要原因。2. 使用單獨的智慧合約可以降低這些錯誤的嚴重性。3. 工廠模式以一種不可信任的方式實現了這一點。4. 在採用工廠模式之前還要考慮潛在的缺點。