本次大礼包由一块链习运营喵Juice倾情放送，请不要太喜欢我。
让我们先开门见山：今天，我们想送你第一份有价值、有分量的礼物。如果你还有点时间，不妨往下看。实在心急，直接拉到文末也可。
《一块链习·区块链技术100讲》第4讲—智能合约中的随机数上周进行的如火如荼。说句题外话，和 Jonny 老师对接工作后，了解他其实是一位特幽默、风趣的人~有图有真相↓↓↓
你们怎么看~
好啦，老规矩，先送干货↓↓↓
《智能合约中的随机数》
大纲
1. 智能合约/Dapp场景下对安全伪随机数的要求
2. 常见问题和实际案例解析
● 纯链上信息做种子生成 伪随机数，例子 - Fomo3D
● 庄家用自己的私钥对用户发送的消息签名作为随机数，例子 - BetDice
● 多方(庄家、玩家、矿工)贡献种子生成伪随机数，例子 - Dice2Win
3. 正确的姿势
● 完整的Commit Reveal
● 门限组签名
● 通过预言机导入
● DOS Network随机数生成方式介 绍和链上API使用
智能合约/Dapp场景下对安全伪随机数的要求
● 评测标准:
○ 随机、不可预测:要求产生独立、均匀分布的 杂乱数据，并且参与生成随机数的任何一
方都无法单独预测结果
○ 不可选择:要求生成的随机数 对给定种子是唯一的，生 产者不能生成一系列的随机数
并选择对自己有利的 发布出去
○ 不可隐瞒:要求生成的随机数无法被 隐瞒或撤回
○ 成本/响应速度的要求
● 产生伪随机数=算法+种子
○ 典型算法:密码学安全的哈希函数 - sha256, sha3, keccak256, etc.
常见问题1: 纯链上信息做种子
● block.coinbase: 挖出当前块的矿工地址
● block.diffuculty: ...
● block.number: ...
● block.timestamp: ...
● blockhash(uint blockNumber):
○ blockhash(block.number) => 0x0
○ blockhash(最近的256个块) => 除去当前块的最近256个区块哈希
❗由于在同一个块内所有交易获得的区块信息相同，可以通过部署链上合约的方式来“预测”随机数。
例子:Fomo3D
简单攻击:部署合约，在合约中按照相同的随机数逻辑来预测能否中奖，不能就回滚 (约1/1000成功率)
进一步:新创建的合约的地址也能预先计算出来
newlyDeployedContractAddr = address(sha3(RLPEncode([from_addr, from_nonce])))
- https://github.com/ethereum/go-ethereum/blob/89a32451aeb418db3fd5d9c427a0c29fddb1e85b/ crypto/crypto.go#L74
那么可以通过控制的合约再部署合约来攻击，以近乎100%的成功率获取空投奖励：
常见问题2: 庄家用私钥对用户发送的消息签名作为随机数
例子1:BetDice - 玩家贡献种子，庄家用私钥签名来生成随机数
1. 玩家发送一笔下注交易到合约，下注交易包含玩家猜测的骰子数(rollUnder)、下注金额和玩家种子。
2. 庄家监测合约状态，在确认合约收到下注之后，庄家用私钥对消息 sha256(”下注id : 用户名 : 玩家种子”) 来签名，发送开奖交易到合约，用生成的签名作为合约开奖的随机数依据。
BetDice声称这种方式产生的随机数“可验证公平” - 玩家可以用庄家公布的公钥、自己的种子和下注id来验证签名;随机数用到了链外私密信息(庄家私钥)，不会被链上攻击合约预测。
❗EOS/ETH普遍使用ECDSA签名算法 (on secp256k1 curve)，而ECDSA不是确定性签名算法:即对同一个消息msg用同一个私钥去签名，每次能得到不同的签名，同时都能被匹配的公钥验证。
例子 :
https://github.com/pertsev/web3_utilz/tree/master/ECDSA%20signature%20generating%20(cheating)
生成的随机数的特性:
❗不满足“不可选择”的特性 - 对某些赌注/赔率特别高的下注，庄家可以作弊:在server端持续对消息签名 直到得到满足自己要求的签名结果作为随机数，用户还完全没法验证这一点。
❗不满足“不可隐藏”的特性 - 见下一个例子
目前市面上通过用庄家私钥对玩家种子签名得到“可验证公平”随机数的博彩类游戏普遍具有这个问题。
常见问题3: 多方贡献种子生成随机数
例子2:Dice2Win - 玩家、庄家和矿工联合生成随机数
1. 在每轮游戏的开头，庄家会先生成一个种子reveal, 并把reveal的sha3()哈希值commit和使用该 commit的最后有效区块号commitLastBlock (目的是防止重放攻击 Replay Attack) 以及它们的签名 sig传给玩家。
2. 玩家选择猜测的大小r、下注金额， 连同收到的庄家的commit, commitLastBlock, sig发送下注交易 placeBet()。
3. placeBet()被打包后庄家立马发送settleBet(reveal, blockhash of placeBetBlockNumber)去开奖，首 先验证sha3(reveal) == commit, 其次验证current block number <= commitLastBlock; 开奖时使用 的随机数依据由sha3(reveal, blockhash(placeBetBlockNumber))来决定。
Dice2win声称这种方式产生的随机数“可验证公平”，其随机数由玩家、庄家和矿工共同决定:庄家控制种子 reveal, 但是没法知道玩家何时下注;矿工在打包placeBet()下注交易时不知道种子reveal是什么，也没法影 响最后结果。(其实这是一种弱化版的commit - reveal协议)
生成的随机数的特性:
❗ 不满足 “不可隐瞒”的特性 - 庄家有一定的后手优势，可以选择不开奖，而是取消或者退款并归咎于技术 原因或链的拥堵/资源紧张。而且由于生成的随机数没有被公布，玩家永远无法知道下注没成功的原因(此时 也不满足可验证性)
正确的姿势1:完整的Commit-Reveal
1. 收集所有参与方(庄家、玩家)种子的commits: 所有参与方在指定的时间窗口(比如6个块)内向合约C发送足够的押金O_i和自己的种子s_i的密码学 安全的承诺commit(s_i);
2. 收集所有参与方的Reveal:
在新的时间窗口内让所有贡献者都向合约发送种子明文s_i, 合约验证是否和上一步的commit一致， 一致则接受，不一致则没收该贡献者的押金并中止。如果在这阶段时间窗口内有参与方没有reveal, 则没收它的押金并分发给reveal了并通过验证的其他参与方。
3. 合约C产生公平的随机数:
一旦收集并验证通过所有的参与方贡献的种子时，产生新随机数R = H(s_1 || s_2 || ... || s_i), 并给所 有参与方退回押金。
commit-reveal还需要考虑防止重放攻击 - 通常会把一个commit最后有效的revea时间和commit一起签名， 在第一步里发送给合约，在第二步里收到reveal时合约验证是否已过期。(Dice2win的做法)
● 优点:
○ 生成的随机数安全、单方无法预知 - 在生成随机数之前确保所有参与方都已reveal (不然就不生成并没收押金)，庄家没有后手优势
○ 难以共谋、可证公平 - 只要至少有一个参与方是诚实的，那么生成的随机数就是安全不可预测的
● 缺点:
○ 成本高，响应速度慢，用户体验较差
○ 对每笔随机数请求庄家需要缴纳足够的押金 (不然仍然会有庄家拒绝reveal导致没法开奖的问题)，庄家资金利用率不高，资金压力大
正确的姿势2:门限组签名(Threshold Group Signature)
回顾一下对安全伪随机数的要求:
● 随机性、不可预测:对随机数的基本要求
● 不可选择:使用确定性签名算法可以满足这点
● 不可隐瞒:要满足这点，需要保证随机数的生成不能是单方控制的
(t,n) 门限组签名基本思想:
● 整个系统里有许多个组存在，一个组有n个成员。
● 初始化:每个组有一个逻辑上的私钥SK，而每个成员 i 只拥有这个逻辑私钥的一部分SK_i，完整的私钥SK不存在于任何人手中，也没有公开出来，谁也不知道。每个组员的私钥碎片SK_i在形成组的时候通过分布式秘密分享算法(Distributed Secret Share)方式得到。
● 对某个消息Msg用逻辑私钥签名得到逻辑组签名记为Sig;每个组的组公钥PK是公开的。
● 签名时:每个成员用自己的私钥碎片SK_i 对消息Msg签名得到签名碎片Sig_i并把签名碎片广播给其他组员;而任意一个组员收集到了任意>= t个(包含自己)签名碎片就能够计算出完整的组签名Sig。
● 验证时:存在合约里的组公钥PK可以验证某成员上传的签名Sig’是不是对Msg的有效组签名 - 只要逻辑私钥SK没有泄漏，如果验证通过表明至少有(t / n x 100%)的组员参与签名过程并同意。
门限组签名示例图
签名的特性:
● 不可选择:RSA或BLS门限签名算法是确定性签名算法，可以满足。
● 不可隐瞒:任意组员收到其他任意 t-1个组员的签名碎片都能计算出完整的组签名并发布。
● 难以串谋:攻击者需要同时控制 >= t个组员才能伪能通过验证的组签名，在每次选组都随机以及选 组时间间隔小的情况下串谋及预测的概率很小。
● 成本低(链外产生，一次交易提交)，响应时间快(同组成员非交互，每个组员只需要签名 - 广播 - 组合 三步)，对eos也可以做到下一个块返回组签名。
门限 t 的选取和安全性:
假设 k 是攻击者控制的组员个数，当k >= t时可以伪组签名，当n - k < t时可以阻止组签名的产生，所以 t设为(组大小的一半 + 1) 最合适。
假设全网有2000个节点，其中600个恶意节点 (30%恶意节点概率)，选取组的大小 n 为151, 则 t 为76。一 次随机选组组里有一半以上恶意节点的概率 < 4.05 x 10-8 , 而且这个概率会随着组的大小 n 的增加急剧减 小。
其他姿势:外部预言机
例子:
● 通过Oraclize(一个中心化预言机) 导入”https://random.org”的结果，问题i) 要相信random.org的结果确实是随机的; ii) 要确保Oraclize没有篡改结果, Oraclize提供的证明难以在链上被调用者实时验证; iii) Oraclize有downtime，期间依赖它的Dapp不可用;iv) Oraclize收费贵等
● DOS (Decentralized Oracle Service) Network 是一个支持多链的去中心化预言机网络，支持链上合 约获取互联网上的所有数据。 同时驱动网络节点和组的随机源完全实现了前面所说的门限组签名和 链上签名验证，并且提供了链上接口给其他合约调用链外API和请求安全的随机数。目前已经在以太 的Rinkeby测试网发布alpha版本和参考文档，欢迎试用和建议: https://dosnetwork.github.io/docs/#/contents/blockchains/ethereum。
● 目前alpha的所有节点都跑在白名单模式，未来会发布beta版本，进一步优化p2p网络层、支持更多的 公链 (比如EOS, Thunder等)、开源客户端、开放节点运行权限让大众都能做预言机节点、支持跨链 的合约调用等等。
以上这些分享干是不是货彰显着 Jonny 老师一丝不苟、认真负责的工作作风和态度呢～
因而，它一定是颇有价值的，很可能也值得很多人反复阅读和参考。
所以，现在可以正经说说另外一份礼物的事儿了——
为了在11月25日我们送出礼物，身为一块链习运营喵的我，为此特意百度了一下历史上的11月25都有哪些大事发生：
值此特殊之日，我们特意邀请了资深软件工程师、架构师，区块链技术布道者杨镇老师，这次，他将“区块链的Layer2扩展”带入《区块链技术公开课100讲》。
本分享将为对 Layer2 扩展定义、 Layer2 扩展价值、目前有哪些可行思路或技术方案等感兴趣的朋友做一个扫盲性的介绍，也会包含一些具体的技术细节，比如状态通道的实现、Plasma MVP 和 Plasma Cash 的实现、TrueBit 的原理，以及几个有潜力的 Layer2 扩展项目简介，帮助童鞋们从概念上了解区块链 Layer2 扩展的思路和目前相对成熟的几种技术方案。
分享大纲：
1.区块链的 Layer2 扩展的定义，产生 Layer2 扩展思路的原因；
2.典型的 Layer2 扩展方案：状态通道和广义状态通道、Plasma和侧链、TrueBit；
3.Layer2 扩展的发展现状和展望：典型项目简介。
我们希望，把这两份礼物，送给你。
现在添加一块链习Jessie小姐姐的微信号：yikuailianxi，即可马上领取这份属于你的特殊大礼包！
「一块链习」技术社区链接全世界最极客的区块链开发者，共同学习区块链技术知识与开发实战，为每一位开发者提供有深度的、持续的价值与帮助。
关注一块链习，
一块链习更多好课等你来看哦
网友评论