未来我们可以在conflux上也部署一套随机数预言机系统的讨论

#1

未来我们可以在conflux上也部署一套随机数预言机

#3

这个可以。写一篇你们的随机数，普及一下

#4

现在先在EOS生态论证可靠性，然后移植到conflux上

#5

大家纯讨论技术

#7

如果某个seed提供者 有人用了噪音芯片，那产生的随机数 质量可以保证。

#8

随机数生成是一个很有用的东西，但是这个收费方式容易被attack吧，比如，我支付一个token获得了随机数，然后转卖出去，而且用合约保证我转卖的随机数和正品完全一样。

#9

被人提前知道的随机数 就没有什么价值了吧。

#10

比如说，某个合约一小时请求一下 randomoracle，然后结果作为他人的seed. 然后，某个想节省成本的开奖合约，可以把逻辑写成，这个 转发合约 明天晚上20点的结果。不过，这种“盗”来的随机数，和直接使用oracle在安全性上还是有一些差距的。latency上也有差距。

#11

他的seed被提前知道了，没发用了啊

#12

噪音芯片的主要问题是没法验证吧？hash出来的伪随机数应该大部分场合够用了，不够的话可以再上extractor

#13

想象这样一个合约，卖奖券然后抽奖，奖券 8 点半停止售卖，抽奖基于 9 点开出的 seed，所以seed 并没有早于 8点半被知道。

#14

有一篇paper讲怎么从比特币的block header里提取随机数的

#15

当然，这样的场景对延时不敏感。对游戏开宝箱这样对延时敏感的随机数，这样是行不通的。

#16

延时几个块就行，反正我们本来也是延迟执行的，而且pow挖矿可以提供足够的随机性

#17

另外，我觉得大家应该区别一下“伪随机数”和“有偏的随机数”之间的区别。伪随机数指基于无偏的随机数种子，用安全性足够高的算法生成的随机数。这种随机数被广泛用于各种密码协议的设计。有偏的随机数，是指随机数的生成过程有设计缺陷，可能被攻击者改变概率分布的“所谓随机数”虽然我们经常用 伪xxx 来代指这个圈子里各种不靠谱的 buzzword，但是“伪随机性”真的是有专门的定义的

#18

Pseudo vs fake

#19

很多商用方案的随机数都是用的随机数产生芯片，基本原理就是噪音

#20

想象这样一个合约，卖奖券然后抽奖，奖券 8 点半停止售卖，抽奖基于 9 点开出的 seed，所以seed 并没有早于 8点半被知道。