電子發(fā)燒友App
智能合約可以部署其他智能合約。這使工廠模式成為可能，在工廠模式中，您可以創(chuàng)建多個智能合同，每個智能合同只跟蹤一件事，而不是一個跟蹤許多事情的智能合同。使用此模式可以簡化代碼并減少某些類型的安全漏洞的影響。
在這篇文章中，我將向您介紹一個基于我們在最近的審計中發(fā)現(xiàn)的一個關(guān)鍵漏洞的示例。如果使用了工廠模式，那么漏洞就就減少了很多。
越野車智能合約
下面是一個智能合約，通過一個相當簡單的界面銷售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 }
10
11 // 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 }
17
18 // Used by a seller to get their ETH.
19 function withdraw（uint256 amount） external {
20 require（amount 《= balanceOf［msg.sender］， “Insufficient funds.”）;
21
22 // Whoops！ Forgot this：
23 // balanceOf［msg.sender］ -= amount;
24
25 （bool success， ） = msg.sender.call.value（amount）（“”）;
26 require（success， “ETH transfer failed.”）;
27 }
28}
（如果您想知道為什么代碼使用.call而不是.transfer，請閱讀“立即停止使用Solidity的傳輸（）”）。
因為賣方的余額從未減少，所以欠任何以太的賣方都可以反復調(diào)用withdraw（）來消耗每個人的合約。這是一個嚴重的漏洞。
修復這個bug，就像大多數(shù)bug一樣，一旦你發(fā)現(xiàn)了它，就變得微不足道了。但在這篇文章中，我想談談如何通過使用工廠模式來減輕這個bug，即使我們不知道這個特定的問題。
現(xiàn)在讓我們看一下更簡單的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 }
10
11 // 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.”）;
20
21 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}
盡管存在完全相同的邏輯錯誤，但此漏洞并不是那么嚴重。只允許一個帳戶調(diào)用withdraw（），并且合約中存儲的所有以太網(wǎng)都屬于該帳戶。這個錯誤的影響只是余額并不能反映合約中的真實余額。
這個bug是手工挑選來顯示其優(yōu)點的，但是這個bug代表了托管協(xié)議中的一大類bug。根據(jù)我審計智能合約的經(jīng)驗，這是發(fā)現(xiàn)關(guān)鍵漏洞最常見的地方之一。
托管背后的想法是，不同的資金必須分開存放，以確保合同始終可以涵蓋所有欠款。獲得托管權(quán)最簡單的方法之一是將資金完全分成不同的智能合約。
您可以將工廠模式看作是一種深入防御的托管方法。
簡單代碼
單賣方版本的合約不僅有更強大的代管，而且更簡單。我們?nèi)サ袅艘粋€函數(shù)參數(shù)和一個映射。在生產(chǎn)代碼中，我們可能會更進一步，完全刪除balance，而代之以address（this）.balance。
因為我寫合約是為了方便閱讀，原來的代碼已經(jīng)很簡單了。在現(xiàn)實世界的例子中，這種差異可能更為顯著。從安全的角度來看，任何降低復雜性的機會都是一種勝利。
工廠模式
每個賣家都可以部署自己的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氣體。
另一個潛在的缺點是復雜性。在大多數(shù)實際情況下，工廠模式簡化了現(xiàn)有的合同，但請記住，它還添加了一個新的合同：工廠本身。根據(jù)代碼的不同，這可能會導致復雜性的增加。
在決定工廠模式之前，請仔細考慮變更的總體影響。
總結(jié)
1. 托管方面的錯誤是導致關(guān)鍵漏洞的一個重要原因。
2. 使用單獨的智能合約可以降低這些錯誤的嚴重性。
3. 工廠模式以一種不可信任的方式實現(xiàn)了這一點。
4. 在采用工廠模式之前還要考慮潛在的缺點。
來源： 區(qū)塊鏈研究實驗室
工商網(wǎng)監(jiān)
評論