智能合约可以部署其他智能合约。这使工厂模式成为可能，在工厂模式中，您可以创建多个智能合同，每个智能合同只跟踪一件事，而不是一个跟踪许多事情的智能合同。使用此模式可以简化代码并减少某些类型的安全漏洞的影响。
在这篇文章中，我将向您介绍一个基于我们在最近的审计中发现的一个关键漏洞的示例。如果使用了工厂模式，那么漏洞就就减少了很多。
越野车智能合约
下面是一个智能合约，通过一个相当简单的界面销售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的传输（）”）。
因为卖方的余额从未减少，所以欠任何以太的卖方都可以反复调用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 }
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}
尽管存在完全相同的逻辑错误，但此漏洞并不是那么严重。只允许一个帐户调用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. 在采用工厂模式之前还要考虑潜在的缺点。
Skip to content
区块世界 驱动一切