Move轻松避免Solidity无限增发的漏洞,让DeFi更安全
Move轻松避免Solidity无限增发的漏洞,让DeFi更安全
* 本文由Starcoin社区原创

近日,跨链协议Wormhole遭到黑客攻击,损失价值3.2亿美元的12万枚wETH。安全问题再次敲响了警钟,如何才能安全地DeFi是行业内所有人都应该重点关注的问题。

由于DeFi场景是建立在去信任的情况下的,所以代码开源是一种常态。金融场景下将代码开源,等于把很多的钱放在所有人的面前,那么,安全就更加重要了。一旦出现漏洞,很可能是毁灭性的,例如比较常见的无限增发漏洞。

基于安全的考虑,Starcoin选择使用专门针对金融场景而设计的Move作为智能合约语言。Move提倡面向资源编程,让DeFi更安全可靠。本文将深入分析无限增发的真实案例,讲述为什么面向资源编程更加安全。

无限增发案例分析

无限增发漏洞的真实原因可能是多种多样的,例如权限被盗、溢出等等,都可能引起无限增发的漏洞。无限增发的结果是导致Token被黑客任意增发,价格归零,用户损失惨重。

这里分析一个加减法导致无限增发的真实案例,感受一下安全的难度,如图所示:

transfer_mint

这是使用Solidity实现的一个ERC20的转账逻辑,from用户给to用户转value数量的Token,主要的过程:

  1. 从map中取出from的balance,赋值给oldFromVal变量;
  2. 从map中取出to的balance,赋值给oldToVal变量;
  3. 判断oldFromVal大于value;
  4. oldToVal + value并且赋值给newToVal;
  5. oldFromVal - value并且赋值给newFromVal;
  6. 将newFromVal设置成from的新balance;
  7. 将newToVal设置成to的新balance;

上面整个修改balance的过程,在中心化的金融场景下是很常见的扣款逻辑,但是有个前提,不能给自己转账。就是这么一个简单的加减逻辑,如果from和to是同一个账户就有问题了,newToVal的值覆盖了newFromVal的值,等于没从from账户减掉value,反而加了value,最终导致了无限增发。

了解了上面这种形式的无限增发漏洞的原理,解决办法当然有很多,例如增加一个from不能等于to的判断。但是这种解决办法,本质上是完全依赖合约开发者来保证安全,一方面提高了对合约开发者的要求,另一方面增加了安全门槛。

面向资源编程的Move

Move是专门为金融场景设计的智能合约语言,提供了另一种思路,能够轻松解决类似上面这种安全问题。Move语言在不增加开发者的安全负担的情况下,避免很多常见的安全风险。

在Move中,设计了一种资源类型。如果一个数据结构被声明为Resource类型,那意味着这个数据结构的instance都将受到严格保护,全局唯一,并且不能随便拷贝和修改。

以上面无限增发的例子为例,from和to用户的balance都同时存在oldVal和newVal,本质上是对数字的拷贝,这是导致漏洞的根源,任何小的失误都可能导致这几个拷贝之后的数字变量错误。在Move中将Balance和Token都声明为Resource类型,即便from和to是同一个账户:

  • 同一时间,Balance只能有一个instance或者mutable的reference,那意味着如果from和to是同一个账户将会报错
  • Token是受保护的类型,不能随便加减,必须先从from账户取出来,然后move到to账户下,即便from和to是同一个账户,Token是从自己账户取出又转回自己账户去了,总量是不变的

move_resource

Move的Ability

Move的资源类型是专门为金融场景设计的,是对现实中价值的一个更贴切的抽象。Move通过Ability的特性来表达不同的类型,例如资源类型。

Move设计了4种类型的Ability,分别是Copy、Drop、Key和Store,如图所示:

move_ability
  • Copy:指定Struct的instance可以被拷贝,如果Struct没有Copy的ability,则不能拷贝;
  • Drop:指定Struct的instance可以被丢弃,如果Struct没有Drop的ability,则只能明确的通过函数销毁;
  • Key:指定Struct的instance是否有检索的ability
  • Store:指定Struct的instance能否保存到账户下

所以,资源类型的struct定义如下,不能Copy和Drop,能够检索和存储:

move_resource_struct

在Move中,能够通过4种Ability轻松设计出自己想要的数据结构,并且会从VM层面保障Ability。

Move的转账例子

介绍了Move的面向资源及实现方式,接下来看一下Move如何通过Ability来实现安全的ERC20转账:

move_transfer

这里需要注意的是:

  1. Token是资源类型,不能Copy和Drop,避免了凭空消失进入黑洞的异常情况,也避免了通过Copy实现增发的异常情况;
  2. Token作为资源,只能将所有权从一个账户move到另一个账户,如图第7步和第9步,总量不变;

Solidity与Move对比

在DeFi场景中,Token是在基本的数据。从上面的例子中,能够看到Solidity和Move的不同,如图所示:

  • Solidity中把Token当成一个普通数字进行加减乘除,在传输的过程中很容易出现安全问题
  • Move中,把Token当成一种资源类型处理,从VM层面保障Token不可复制、不能丢弃、传输过程中不能修改,保障了Token的安全可靠,让DeFi更加放心
solidity_vs_move

交易的本质是所有权的转移。在Move中,保证资源类型本身安全可靠,同时,保障资源类型的所有权明确、完整,不仅仅能避免类似于无限增发的漏洞,还能避免其他常见的安全隐患。既减低了开发者的安全门槛,也降低了资源的安全风险。