区块链随机数的安全性阐述

yingujun 2019-03-01 733

区块链

581人已加入

描述

本文将从EOS DApp 攻击事件出发，以科普角度阐述安全随机数的标准及现行公链上随机数的生成机制。

自去年6月EOS主网上线之后，陆续发生DApp的智能合约被黑客入侵的事件，其中泛隨機數攻擊事件占了大多数，以下是攻击事件列表：

区块链智能合约

以上19起EOS DApp攻击事件，总共造成了超过100万美元的损失，其中14起为随机数攻击，另外5起为回滚攻击，这些攻击都直接或间接地与随机数有关，可称为泛随机数攻击。随着这些攻击事件的发生，区块链上随机数的安全性也越来越被广泛关注。

什么是「安全」的随机数？

先想想我们对随机数的要求是什么，生活中很多地方会用到随机数，当它至关重要时，我们才会要求它「公正」、「安全」。例如乐透彩开奖时，乐透公司让大家的检验方式是租一个频道，预先让第三方背书数组公正的彩球，公开在频道上取一组彩球，将彩球放到抽奖箱中打乱，再一颗一颗吸出彩球得到号码，用意就是为了让大家相信抽签的过程是公正的。

然而，这也未必能真正达到公正，比如说，这第三方和乐透公司共谋时，可以在彩球装上磁铁，最后只有有磁铁的彩球会被吸出来，让这看似随机的过程其实并不随机。

至此，我们先做一个小结论，一个好的随机数应该要满足以下三个特质：

· 无法被操纵或预测（不能用磁铁改变抽中的彩球）

· 可以被公众验证其随机性（大家可以相信开球过程是真的随机）

· 无需信任第三方（不需要找律师确认彩球没问题）

除了现实生活中的乐透开奖之外，开发程式时也常会需要随机数，譬如竞猜、***、随机分配任务等，我们先有了随机数的概念后，再来看目前区块链上的随机数有什么问题。

区块链上的随机数是怎么来的？

目前EOS 跟Ethereum 都没有提供官方的随机数生成服务，如果开发者需要在智能合约上使用随机数的话，他们有两个选择 — — 自己产生随机数或是仰赖第三方oracle。

Ethereum 官方推荐使用Oraclize （一个第三方的oracle 服务）来产生随机数，但去中心化的区块链要仰赖中心化的第三方提供随机数，完全就是本末倒置。而且对于一个热门的DApp 来说，频繁的调用第三方的oracle 是很昂贵的，可能还会增加完成步骤所需的transaction 数，而造成DApp 的latency 增加，所以大多数开发者都倾向自己产生随机数。

问题来了，在官方不提供随机数生成服务的状况下，公链上的开发者只能自行根据公链上能取到的各种变量来作为随机数种子，而这些变量往往来自于区块的讯息，这么做很容易让有心人士可以去预测随机数。

举例来说，前阵子被攻击的EOSDice 就是采用了tapos_block_prefix（）跟tapos_block_num（）这两个变量作为随机数种子，而它们正是下注transaction的「前一个区块」的资讯。

聪明的读者可能已经发现哪里不对劲了，随机数的种子居然在下注前就已经形成了！骇客正是看出了这个规则，才能预测出「必定中注」的随机数，在不公平的状况下赢走庄家的钱。

EOSDice在第一次黑客事件后，旋即修正了随机数生成的方式，开发者改用双重的deferred action延迟了开奖的时间，使得reference block变成下注时还未生成的区块，如此一来就无法事先取得区块资讯。但道高一尺魔高一丈，骇客直接写了一个合约去模拟EOSDice合约的行为，只要两种合约运行在同一个区块，就会refer相同的block，进而得到相同的区块资讯，于是乎EOSDice又被骇了第二次…

由于公链上的区块资讯是公开的，现行在智能合约中采用「区块资讯」生成随机数的做法，其安全性不管再怎么设计都会有其极限。一个好的随机数生成方式不应该仰赖第三方oracle ，且必须满足「不可被预测」的特质，就这点看来， EOS 跟Ethereum 都还还做得不够好。

当EOS的技术长Daniel Larimer被开发者问到随机数安全性的问题时，他提出了一个「信任区块生产者」的方案— —区块生产者在打包交易时，在某个特定时机获取特定讯息，以此作为随机数种子来生成伪随机数。虽说这是一个链上的解决方案，但这种做法其实跟仰赖oracle的本质并无不同，一样都是由一个中心化的第三方来提供随机数，EOS的DPoS制度已经赋予少数区块生产者极大的权力，若他们还能直接参与随机数生成的过程，那中心化的风险就更高了。

如果公链随机数的安全性问题一直存在，那么任何需要「公平随机数」的程式逻辑就无法安心地运行在公链上，这对整个区块链生态系的发展都有不利的影响。

打开APP阅读更多精彩内容