感恩節來臨之際，一塊鏈習送你兩份能讓你兩眼冒光的禮物！

時間 2019-11-30

標籤感恩節來臨之際一塊兩份讓你兩眼禮物简体版

原文原文鏈接

本次大禮包由一塊鏈習運營喵Juice傾情放送，請不要太喜歡我。git

讓咱們先開門見山：今天，咱們想送你第一份有價值、有份量的禮物。若是你還有點時間，不妨往下看。實在心急，直接拉到文末也可。github

《一塊鏈習·區塊鏈技術100講》第4講—智能合約中的隨機數上週進行的如火如荼。說句題外話，和 Jonny 老師對接工做後，瞭解他實際上是一位特幽默、風趣的人~有圖有真相↓↓↓web

大家怎麼看~算法

好啦，老規矩，先送乾貨↓↓↓安全

《智能合約中的隨機數》

大綱

1. 智能合約/Dapp場景下對安全僞隨機數的要求微信

2. 常見問題和實際案例解析網絡

● 純鏈上信息作種子生成僞隨機數，例子 - Fomo3D架構

● 莊家用本身的私鑰對用戶發送的消息簽名做爲隨機數，例子 - BetDice併發

● 多方(莊家、玩家、礦工)貢獻種子生成僞隨機數，例子 - Dice2Winapp

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 擴展的發展示狀和展望：典型項目簡介。