EOS上如何安全生成随机数

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/TurkeyCock/article/details/84730045

EOS上的各种菠菜游戏频频被黑客攻陷,多数原因都是随机数算法被破解。实际上,由于区块链上没有稳定的熵源,很难产生真正意义上的随机数,但是可以最大限度地提高破解的难度。在不引入于预言机(oracle)等外部熵源的情况下,目前有两种可用的安全随机数生成算法,本文将逐一进行分析。

1.FarmEOS算法

FarmOS是目前比较火的游戏平台,已经上线了骰子、轮盘、扫雷和21点这四个游戏,后续还将推出更多游戏。根据白皮书上的描述,FarmOS的随机数生成算法采用了未来的区块信息,再结合多项未来不可控变量因素,从而保证安全性和公平性:
在这里插入图片描述
今年10月16日,FarmOS公开了它的随机数算法(实际上也是该项目开源的唯一代码):https://github.com/farmeos/farmeos。需要注意的是,实际上该算法还是有漏洞的,需要去除掉红框框出来的因子(EOSBet项目采用了相同的算法,黑客正是利用这个漏洞成功获利)。
在这里插入图片描述
我们先来分析一下随机数种子中的几个因子:

(1) tapos_block_prefix() :该交易refer的区块高度的低32位

(2) tapos_block_num():该交易refer它之前的哪个区块,是一个0~2^16之间的数字

(3) name:用户账户名

(4) game_id:一个每次自增1的值

(5) current_time():开奖区块的时间戳

(6) pool_eos.amount:当前合约中的EOS余额

从表面上看,这些因子都是用户不可控的,但实际上黑客利用对(1)/(2)和(6)的操控对EOSBet合约成功发起了两次攻击,我们分别分析一下。

1.1操纵交易refer的区块信息

首先科普一下什么叫TAPOS:TAPOS即Transaction As Proof Of Stake,是EOS的特点之一,每个交易的头部都必须指定一个refer的区块,我们看一下transaction_header的定义:
在这里插入图片描述
这样做的目的主要是为了阻止矿工(validator)把同一笔交易打包到不同的分叉链上,从而减小系统的分叉风险。tapos_block_num()就是获取其中的ref_block_num值,范围是0~2^16之间。tapos_block_prefix()则是根据这个偏移量,获取对应区块高度的低32位,参见代码:
在这里插入图片描述
从这里看,似乎是没问题的,因为黑客无法提前知道开奖的那笔交易会refer哪个区块。但是,由于合约开奖时采用的是deferred action,这种交易会refer当前区块的前一个区块,这是在代码里写死的:
在这里插入图片描述
或者画个图可能更清楚一些:
在这里插入图片描述
可以看到,开奖交易refer的是下注交易的前一个区块!也就是说,下注的人是可以提前知道这两个因子的,只需要调整好下注的金额,就有很大的概率能够中奖了。

有人会问:为什么不是用inline action直接开奖,而要用deferred action呢?这也是跟EOS的特性相关的:如果适用inline aciton,在执行的过程中不管出现任何错误,都会导致整个交易的回滚。而deferred action则是一个单独的交易,即使执行失败也不会影响之前的交易,因此开发者一般都会采用deferred action,这样即使开奖失败,也不会导致之前的下注交易被回滚。

那么怎么解决这个问题呢?其实也很简单,再向后延迟一个区块不就行了?参见下图:
在这里插入图片描述
这就是所谓的“二次延时开奖”,这样开奖交易refer的就是下注交易所在的区块了,下注者无法提前知晓当前区块的信息。你以为这样就完全解决问题了?Naive!我们来看看下面一种攻击方式。

1.2操纵当前合约中的EOS余额

首先介绍一下eosio.token的一个特性:在发生转账时,合约会先给发送方发通知,然后再给接收方发通知:
在这里插入图片描述
这样,下注账户就可以先于游戏合约获取通知,然后模拟出和游戏合约相同的deferred action。因此,下注人的二次延时交易将会和游戏合约的“二次延时开奖”交易位于同一区块,并且先于开奖交易执行。至此,下注人就获得了开奖交易refer的区块信息,可以计算出中奖需要的pool_eos.amount,然后往游戏合约中存入相应数量的EOS即可中奖。具体流程参见下图:
在这里插入图片描述
防御办法也很简单:从随机数种子中去除“合约当前余额”因子,也就是最前面我们提到的红框框出来的部分。

1.3总结

前面分析了那么多,总结一下:目前阶段必须采用“二次延迟开奖 + 用户不可控因子”的方式,才能保证安全生成随机数。当然,这一方法是否绝对安全,还需要经历更多时间的考验。

2.BM算法

这一算法源于BM在StackExchange上的一条回复,我们暂且就把它称为“BM算法”吧。原文如下:
在这里插入图片描述
这条回复写得太简略了,我们以一个骰子游戏为例,大致可以分解为以下几个步骤:

(1) 玩家(Player)开始新游戏

(2) 游戏后台(Casino)生成一个随机数种子casino_seed

(3) 游戏后台将hash(casino_seed)上传到合约中,这样庄家就无法篡改开奖点数了

(4) 玩家生成自己的随机数种子player_seed,也就是下注的点数

(5) 玩家将hash(player_seed)上传到合约中,这样玩家也无法篡改下注点数了

(6) 玩家将player_seed上传到合约中

(7) 合约验证该player_seed是否和之前上传的哈希值匹配

(8) 游戏后台将casino_seed上传到合约中

(9) 合约验证该casino_seed是否和之前上传的哈希值匹配

(10) 如果所有验证都通过,为中奖者开奖
在这里插入图片描述
可以看出,在这种流程设计下,项目方和游戏玩家双方都无法作弊,开奖流程完全由智能合约控制,符合区块链公开透明的去中心化精神。

参考:

https://github.com/farmeos/farmeos/blob/master/random.cpp

https://www.farmeos.io/assets/pdf/FarmEOS_PoB%26DoP白皮书1.0.5.pdf

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#transaction-as-proof-of-stake-tapos

https://blockgeeks.com/guides/eos-blockchain/#What_is_TAPOS

https://eosio.stackexchange.com/questions/41/how-can-i-generate-random-numbers-inside-a-smart-contract

https://www.weibo.com/ttarticle/p/show?id=2309404298445014841517

https://medium.com/dapppub/fairdicedesign-315a4e253ad6

更多文章欢迎关注“鑫鑫点灯”专栏:https://blog.csdn.net/turkeycock
或关注飞久微信公众号:
在这里插入图片描述

没有更多推荐了,返回首页