📜 [專欄新文章] Ethereum RNG (RANDAO & VDF)
✍️ Kimi Wu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Ethereum RNG solution(RANDAO & VDF)
RNG是Random Number Generator,也就是亂數產生器
在現實世界中要產生真正的隨機數,其實不容易,各個語言的library所提供的隨機數,都是偽隨機數,是可以預測的,不過在大部分的應用場域,都是可以應付的。區塊鏈的世界,面對的是全世界的人,怎麼產生不可預測的隨機數,就很重要,不然就可以被有心人所操作。例如Ethereum Beacon chain(POS chain)中的validator/attester(產塊跟驗證的角色),若是可以被預測,那大概就沒有人會相信這條鏈了。而這也是Ethereum Serenity(Eth-2.0),所遇到的問題之一。目前隨機數的產生,就由RANDOA + VDF所產生,以下就分別介紹
RANDAO
RANDAO是利用經濟模式(獎勵跟處罰)的方式,促使在公共場域中能產生隨機變數
原理很簡單,想參加的人把拿錢來抵押,需要產生隨機數的人要付錢。所以參加者就可以從中分潤,當然不守規矩抵押的錢也就會被沒收,利用獎勵跟處罰的方式迫使大家都守規矩。詳細步驟如下:
首先,會有個收集seed的時間,例如6個block的時間。接著,想參與的人,投入某個數量的ETH到RANDAO這個smart contract(作質押),然後附上secret(某個只有你知道的值s,然後作sha3)。
等收集時間結束,就是驗證時間。此階段所有參與著需要把s傳入smart contract做驗證,smart contract會把s作sha3,去驗證是不是跟第一階段傳進來的一致。最終會把驗證過的s當作seed去產生隨機數。
最後,就是產生隨機數,然後把隨機數傳給之前有請求過的contract。然後歸還質押的ETH跟利潤分給參與者。
此外有幾個附加條件
第一階段若收集到數筆一樣的secret,只接受第一筆
第一階段會規定基本人數,若結束後未到達人數門檻,則此次的產生就失敗
若第二階段需提供s3.1 若未提供,則質押的ETH會被沒收3.2 若此階段有一個以上參與著未提供s,則此次產生失敗,並且把沒收的 ETH分給有提供s的參與者。且退還請求者所支付的ETH。
VDF
VDF 全名為Verifiable delay functions,從字面上有點難懂在幹嘛,從運作方面做解釋,就是輸入一個值,然後運算一段時間(delay),得出一個結果,最後這個結果是可以被輕易驗證的。如下列算式,
f(x) = g(g(g(g(….g(x)….)))) where g(x) = xor(x^((p+1)/4), 1) mod p 其反函數為h(x) = xor(x, 1)² mod p
上面提到「運算一段時間」的運算,其實是重複做同一種運算,從數學式看就很清楚,把x帶入g(x),然後把算出的結果再帶入g(x)。所以同一段時間,如果能迭代的次數比其他人多,那其他人就猜不到結果,也就沒辦法預測亂數結果。
最後,介紹一下這兩個方法怎麼運用在Ethereum Serenity中
首先,RANDAO會在內建在Beacon chain的邏輯中,而不是一個獨立的smart contract,但RANDAO有個缺點,就是最後一位可以預測/操縱結果。如下圖,因為最後一位可以知道前面的值,所以在最後可以決定要出值或是不出,因此可以操縱結果。(目前epoch是64個slot,而每個slot是6秒,所以epoch約是6.4 minutes)
source : Justin Drake slides on DevCon4
所以設計上除了RANDAO,還多一層VDF。 VDF把RANDAO產生出來的亂數當種子去產生亂數,而且計算時間要夠長(至少要一個epoch,目前規劃是10個epoch,不過相信還會有變動),如下圖
source : Justin Drake slides on DevCon4
實際的lifecycle會像這樣,在VDF計算完後,會有一個epoch的緩衝讓這個亂數可以上鏈,然後接著下一個RANDAO mixing。
source : Justin Drake slides on DevCon4
但問題來了,怎麼確保沒有人算得比你快??
所以Ethereum Foundation計畫做硬體,設計新的ASIC晶片來計算VDF,以確保沒人可以預測最終的亂數。實際設計當然不是Foundation的researcher們,他們找了學界跟產業的IC design專家做設計,因為硬體研發費用龐大,Filecoin也一起支援這項計畫。更多細節的部分,可以參考Minimal VDF randomness beacon
other references :RANDAO中文白皮書Justin Drake explains “Ethereum 2.0 randomness” on Devcon4
Originally published at kimiwublog.blogspot.com.
Ethereum RNG (RANDAO & VDF) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
xor應用 在 OSSLab Geek Lab Facebook 的精選貼文
某位大大 提及硬體Raid 跟ZFS 的比較
"ZFS效能會比RAID HBA card好, 很多測試報告可以參考, 尤其是在rebuild時, 主要是ZFS看得到檔案分佈, 可以只復原有資料的部份, RAID HBA card看不到, 只能乖乖整顆復原, 在單顆硬碟越來越大的時候花費時間差異越明顯.
正常時候則因為可以對多顆硬碟同時送指令而加大存取頻寬, 若透過RAID HBA card則要等其轉譯處理, 常常瓶頸發生於此.
另外, ZFS屬於軟體RAID, 彈性較大, 例如raid-z3(可看成容許壞3顆的RAID5), 在RAID HBA card應該還沒出現..."
就OSSLab 理論跟實務維護跟救援
先要理解軟體跟硬體Raid 架構
http://www.osslab.org.tw/…/RAID_HBA%E8%88%87%E6%9E%B6%E6%A7…
RAID HBA card 轉譯就當代的 Raid ROC 在整合 Xor ,Dram cache, SAS PHY匯流排整合 (之後應該就進話到nvme) 已經不太存在bottleneck了 . 整體而言 還是會比Soft raid 快.
已知Filesystem 位置 是可以加快 Rebuild速度....但身為Date recovery從業人員,我是寧可 確定每一個block狀況, 不要只rebuild 已知FS ..畢竟也許那天有機會Data recovery 就要用...
最後一個就是硬體卡監控硬碟狀況跟設定 操作我覺得比software raid方便. 現在硬體Rebuild 時間4TB 約是3x~8x 小時..
還算合理
就Data recovery 的考量 盡量少用ZFS 的Storage Block結構
我們ZFS 應用偏向於虛擬化主機 , Disk Raid 用硬體卡 .上再建ZFS Pool,再分給cifs ,iscsi lun 再掛到本機 vsphere datastore...
http://www.napp-it.org/napp-it/all-in-one/index_en.html