一個NEO鏈上安全隨機數的解決方案是什么

本篇文章為大家展示了一個NEO鏈上安全隨機數的解決方案是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

0x00 困境

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

• （1）已有的鏈上數據。

• （2）通過調用別的合約獲取返回值。

• （3）交易傳遞的參數。

對于第一種數據來源，已有的鏈上數據都是公開的，隨機數獲取算法也是公開的，無論怎么搞，通過鏈上數據獲取的隨機數結果怎么看都不怎么靠譜， 用戶在交易發布之前，稍微分析甚至不需要分析就能猜到自己可能獲取到的隨機數值范圍。

如果通過調用別的合約來獲取返回值，這就進入了死循環————別的合約的隨機數哪里來的？

最后一種，交易傳參，這就更不能用于隨機數生成了，本來隨機數是要讓用戶交易執行之前完全不可預測的，現在直接跟用戶輸入相關的話倒不如直接讓用戶自己設置自己的隨機數來的直接。

0x01 共識前的共識

研究過NEO共識的同學應該都知道，NEO共識協議采用的是dBFT，這種共識協議不需要靠計算量證明，也不需要大家提供股權證明，簡直是綠色環保節能減排居家旅行必備的良心共識協議。 仔細看看，這個共識協議有一個很奇怪的特性，就是在真正的對區塊進行打包共識之前，有一個產生議長的共識過程， 只有在議長確定之后，才會由議長發起一輪共識。這就意味著，在所有的節點中， 議長節點是第一個對新一個區塊中所有的交易進行驗證執行的節點。議長之前沒有節點執行交易，議長之后大家數據必須跟議長一致，否則就會重新選舉議長。放在我們隨機數場景里。議長節點執行之前沒有隨機數，議長節點執行后，所有的節點的隨機數必須和議長使用的 隨機數一致。那這就很明確了，在新的區塊生成之前，隨機數不能存在，而新區塊生成的開天辟地第一步就是議長節點發起共識。同時，我們也知道，其實議長也確實在新區快生成的時候，本地生成了一個新的隨機數---nonce。

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

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

0x03 議長的可信問題

在現有的dBFT協議中，議長其實是不需要可信的，因為一個不可信的議長并不會對系統造成任何的干擾，整個系統除了依賴系統發起共識之外，議長并沒有什么剩余價值，即便是那個隨機數nonce雖然依賴議長生成，但是也并不會對系統安全造成影響。但是如果依賴那個nonce來 最為種子生成隨機數，那么就相當于給了議長一定的權力，至少議長就可以干擾隨機數的生成了。所以這個系統還是有問題的，那就是議長的可信度。

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

擺脫議長可信問題的解決方案是，在選舉議長的時候增加議員節點間通信，每個議員都廣播自己本地生成的隨機數，然后把所有議員的隨機數進行哈希來產生分布式的隨機數，這樣就可以不依賴某個幾點來產生隨機數了。

上述內容就是一個NEO鏈上安全隨機數的解決方案是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。