教程 | Solidity 中 revert(), assert() 和 require() 的使用方法

Ajian   |     |   2256 次阅读

-Photo by Osman Rana-

Solidity 0.4.10 版本发布了新的 assert() , require()revert() 函数,解决了以前代码中有困惑的地方。特别地,新 assert()require() 代码会“确保”提高合约代码逻辑条理清晰,但是也需要知道如何区别使用它们。

本文中,将会:

  1. 解释新函数解决的问题
  2. 讨论 Solidity 编译器如何处理新 assert()require()revert() 调用
  3. 给出使用新代码的最佳实践

为了更好理解,我生成了使用这些新功能的简单合约,用户可以在 remix 上进行测试

如果只是想看“太长不看版”,那么 ethereum stackexchange 上的回答可以解答疑问。

Solidity 的错误处理模式

传统方法:采用 throw 和 if ... throw 模式

例如合约中有一些功能,只能被授权为 拥有者 的地址才能调用。

Solidity 0.4.10之前(以及其后一段时间),这种强制授权处理方式很普遍:

contract HasAnOwner {
    address owner;

    function useSuperPowers(){ 
        if (msg.sender != owner) { throw; }
        // do something only the owner should be allowed to do
    }
}

如果 useSuperPowers() 函数被其它非拥有者调用,此函数将抛出“返回无效操作代码错误”,回滚所有状态改变,而且消耗掉剩下的gas(更多关于 gas 与费用的信息可以参考这篇 ethereum 中的文章)。

现在,“throw(抛出)”关键字已经过时了,最终将会被弃用。幸运的是,新函数 assert()require()revert() 提供了同样功能,而且上下文更加干净。

新文法

咱们看看用新代码函数如何处理传统 if ... throw 模式,

这行代码:

if(msg.sender != owner) { throw; }

完全等价于如下三种形式:

  • if(msg.sender != owner) { revert(); }

  • assert(msg.sender == owner);

  • require(msg.sender == owner);

注意在 assert()require() 例子中的条件声明,是 if 例子中条件块取反,也就是用 == 代替了 !=

assert()和require()之间的区别

首先,可以将 assert() 想象为一个过于自信的实现方式,即使有错误,也会执行并扣除gas。然而 require() 可以被想象为一个更有礼貌些的实现方式,会发现错误,并且原谅所犯错误(译注:不扣除 gas)。

基于以上理解,以上两个函数真正区别在哪里呢?在拜占庭网络更新前, require()assert() 表现完全一样,但是他们的二进制代码却有略微区别。

  1. assert() 使用 0xfe 操作码引起错误条件
  2. require() 使用 0xfd 操作码引起错误条件

如果在黄皮书中查找这些操作码,会发现找不到。也就是为什么会看到 无效操作码 错误,因为并没有客户端如何处理这些错误的明确定义。

拜占庭网络升级并实现 EIP-140:以太坊虚机回滚指南之后,会解决这个问题。0xfd 操作码的改变将在 REVERT 指南中反映出来。

以下是这一激动人心功能的描述:

在0.4.10版本之后部署了许多合约,其中包括一个暂时不用的新操作代码。现在,它被激活了,就是 REVERT

注: throwrevert() 都是用 0xfd 操作码。而 0.4.10 之前,throw 就是使用的 0xfe

REVERT 操作码实现功能

REVERT 碰到无效代码后,仍将回滚所有状态,但是会用两种不同于“无效代码”方式处理:

  1. 允许返回一个数值
  2. 将剩余gas返还调用者

1. 允许返回一个数值

许多智能合约开发者对以前那种无用的无效代码错误很熟悉。幸运的是,很快新代码可以返回一个错误信息,或者代表某种错误类型的数值。

看起来像这样:

revert(‘Something bad happened’);

或者

require(condition, ‘Something bad happened’);

注:Solidity 暂时还不支持返回变量,但是可以参见这个问题更新

2. 将剩余 gas 返还调用者

目前的合约处理 throws 后会消耗剩余的 gas。尽管可以视为对矿工的慷慨捐助,但是往往会消耗用户大量金钱。

一旦 REVERT 在 EVM 中实现,将会抛弃旧方式转而将剩余 gas 返还用户。

在revert(), assert()和require()中作出选择

那么,如果 revert()require() 都会返还剩余 gas,而且允许返回一个数值,那么为什么还使用 assert() 这种会消耗 gas 的调用呢?

不同点在于输出的二进制代码,引用如下文档以便更清楚解释(我做的着重强调)

require函数用于:
- 确认有效条件,例如输入,
- 确认合约声明变量是一致的
- 从调用到外部合约返回有效值

如果正确使用,分析工具会评估合约并分辨出引起 assert 调用错误的条件和函数。正确函数代码将会避免引起调用错误的 assert 声明;如果发生就意味着合约中存在需要修复的bug。

为了更清楚地解释:require() 声明失败应该被认为是正常和健壮的情况(跟 revert() 一样);而当 assert() 声明失败时,则意味着有些东西失控了,需要修复代码中的问题。

如果遵循以上实践指南,静态分析正式验证工具可以用于检查合约,发现并证实合约中的隐患,或者确保合约安全无漏洞地运行。

特别地,我会使用如下准则来帮助判断正确使用场景。

以下场景使用 require()

  • 验证用户输入,即: require(input<20);
  • 验证外部合约响应,即: require(external.send(amount));
  • 执行合约前,验证状态条件,即: require(block.number > SOME_BLOCK_NUMBER) 或者 require(balance[msg.sender]>=amount)
  • 一般地,尽量使用 require 函数
  • 一般地,require 应该在函数最开始的地方使用

在我们的智能合约最佳实践中有很多使用 require() 的例子供参考。

以下场景使用 revert() :

  • 处理与 require() 同样的类型,但是需要更复杂处理逻辑的场景

如果有复杂的 if/else 逻辑流,那么应该考虑使用 revert() 函数而不是require()。记住,复杂逻辑意味着更多的代码

以下场景使用 assert()

  • 检查 overflow/underflow,即:c = a+b; assert(c > b)
  • 检查非变量(invariants),即:assert(this.balance >= totalSupply);
  • 验证改变后的状态
  • 预防不应该发生的条件
  • 一般地,尽量少使用 assert 调用
  • 一般地,assert 应该在函数结尾处使用

基本上,require() 应该被用于函数中检查条件,assert() 用于预防不应该发生的情况,但不应该使条件错误。

另外,“除非认为之前的检查(用 ifrequire )会导致无法验证 overflow,否则不应该盲目使用 assert 来检查 overflow”——来自于@chriseth

结论

这些函数是安全性检查工具库中很强大的工具。知道如何以及何时使用这些函数不仅能帮助你的代码免受攻击,而且会使代码更加对用户友好,更加面向未来变化。


喜欢这种类型文章吗?

我来自ConsenSys Diligence团队。如果你有 Solidity 和 EVM 方面深入技能,而且对提高智能合约安全性很感兴趣,我们希望你能加入智能合约审查部门(从这里申请)。

如果你看到了这里但还达不到工作描述中的要求,也没关系。只需要在消息中引用此文,并说出你的技能和对以太坊的兴趣即可。

免责声明:以上作者观点并不代表 Consensys AG 的观点。ConsenSys 是一个去中心化社区,采用 ConsenSys Media 作为社区成员自由交流的平台。如果关注 CensenSys 和以太坊,请访问我们的网站


作者注:文中的 Remix 代码可以在这个地址中找到。
或者,你可以在这个 GitHub 地址中找到文中的代码。


原文链接: https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57
作者: Maurelian
翻译&校对: 小野于林 & Elisa

本文由作者授权 EthFans 翻译及再出版。


你可能还会喜欢:

干货 | 智能合约安全指南
干货 | 智能合约开发简介
教程 | 以太坊开发演练, Part-3

 
0 人喜欢