一個可能的NEO鏈上安全隨機數解決方案

0x00 困境

鏈上安全隨機數生成應該算是一個比較蛋疼的問題，哪怕你的系統再牛逼，合約程序困在小小的虛擬機裏，哪怕天大的本事也施展不開。 更悲催的是，交易執行的時候，是在每個節點都執行一遍，那就意味着，要想保證同一個交易在全部節點執行結果都一致， 那麼交易獲取的隨機數也就必須一致。目前來看，當交易執行的時候，合約所能獲取到的數據無非是

• （1）已有的鏈上數據。
• （2）經過調用別的合約獲取返回值。
• （3）交易傳遞的參數。

對於第一種數據來源，已有的鏈上數據都是公開的，隨機數獲取算法也是公開的，不管怎麼搞，經過鏈上數據獲取的隨機數結果怎麼看都不怎麼靠譜， 用戶在交易發佈以前，稍微分析甚至不須要分析就能猜到本身可能獲取到的隨機數值範圍。

若是經過調用別的合約來獲取返回值，這就進入了死循環————別的合約的隨機數哪裏來的？

最後一種，交易傳參，這就更不能用於隨機數生成了，原本隨機數是要讓用戶交易執行以前徹底不可預測的，如今直接跟用戶輸入相關的話倒不如直接讓用戶本身設置本身的隨機數來的直接。

0x01 共識前的共識

研究過NEO共識的同窗應該都知道，NEO共識協議採用的是dBFT（沒研究過的能夠看http://www.javashuo.com/article/p-kdcfdtqu-kg.html ），這種共識協議不須要靠計算量證實，也不須要你們提供股權證實，簡直是綠色環保節能減排居家旅行必備的良心共識協議。 仔細看看，這個共識協議有一個很奇怪的特性，就是在真正的對區塊進行打包共識以前，有一個產生議長的共識過程， 只有在議長肯定以後，纔會由議長髮起一輪共識。這就意味着，在全部的節點中， 議長節點是第一個對新一個區塊中全部的交易進行驗證執行的節點。議長以前沒有節點執行交易，議長以後你們數據必須跟議長一致，不然就會從新選舉議長。放在咱們隨機數場景裏。議長節點執行以前沒有隨機數，議長節點執行後，全部的節點的隨機數必須和議長使用的 隨機數一致。那這就很明確了，在新的區塊生成以前，隨機數不能存在，而新區塊生成的開天闢地第一步就是議長節點發起共識。同時，咱們也知道，其實議長也確實在新區快生成的時候，本地生成了一個新的隨機數---nonce。

0x02 沒法使用的最可靠的隨機數

然而，現實是，因爲交易在虛擬機裏執行，像是被困在了一個盒子裏，能調用的只有system和runtime幾個庫提供的少的可憐的接口，而這個nonce隨機數更是不在可用資源列表裏，因此以上分析基本又成了廢話。

0x03 議長的可信問題

在現有的dBFT協議中，議長實際上是不須要可信的，由於一個不可信的議長並不會對系統形成任何的干擾，整個系統除了依賴系統發起共識以外，議長並無什麼剩餘價值，即使是那個隨機數nonce雖然依賴議長生成，可是也並不會對系統安全形成影響。可是若是依賴那個nonce來 最爲種子生成隨機數，那麼就至關於給了議長必定的權力，至少議長就能夠干擾隨機數的生成了。因此這個系統仍是有問題的，那就是議長的可信度。

0x04 共識前的共識前的共識

擺脫議長可信問題的解決方案是，在選舉議長的時候增長議員節點間通訊，每一個議員都廣播本身本地生成的隨機數，而後把全部議員的隨機數進行哈希來產生分佈式的隨機數，這樣就能夠不依賴某個幾點來產生隨機數了。