區(qū)塊鏈的自定義解決方案PVRB的優(yōu)缺點介紹

介紹

與許多密碼概念一樣，“公開可驗證的隨機(jī)信標(biāo)”協(xié)議（簡稱PVRB）只是一種趨近理想的方案。但理想的方案并不適用于真實的網(wǎng)絡(luò)：應(yīng)該就輪中的唯一“位”、輪的數(shù)量以及必須快速且始終交付的網(wǎng)絡(luò)消息達(dá)成共識。但對于真實的網(wǎng)絡(luò)卻不是這樣?，F(xiàn)代區(qū)塊鏈的自定義PVRB解決方案開發(fā)涉及許多技術(shù)問題，因此無法控制隨機(jī)數(shù)生成和加密算法的強(qiáng)度。

區(qū)塊鏈本身是PVRB的通信媒介，其中消息=交易?，F(xiàn)在，我們可以忘記網(wǎng)絡(luò)問題、消息未交付問題以及中間軟件問題——所有這些風(fēng)險都由分散式網(wǎng)絡(luò)來處理。PVRB不能回滾或破壞已發(fā)送的交易 ，而且參與者不能拒絕參與協(xié)議，除非他們成功地攻擊了網(wǎng)絡(luò)共識。由于安全級別是可以接受的，所以PVRB必須與區(qū)塊鏈的主鏈一樣，抵抗參與者之間的共謀。有跡象表明，PVRB應(yīng)該成為共識的一部分;如果網(wǎng)絡(luò)同意主鏈，它也應(yīng)該同意正確的產(chǎn)生隨機(jī)數(shù)。否則，PVRB只是一個由智能合約支持的獨立協(xié)議。這兩種方法各有利弊，在兩者之間做出選擇是相當(dāng)困難的。

實現(xiàn)PVRB的兩種方法

我們將更詳細(xì)地描述兩個選項：基于區(qū)塊鏈獨立智能合約的獨立版本，以及嵌入?yún)f(xié)議的共識集成版本。對于每種情況，我將參考流行的區(qū)塊鏈：Ethereum、EOS，以及那些具有類似存儲和處理智能合約方法的區(qū)塊鏈。

獨立合約

這里PVRB是一個智能合約，它接受來自隨機(jī)生產(chǎn)者（以下簡稱RP）的交易，處理它們，組合結(jié)果，并最終生成任何合約用戶都可以接收的一些值。此值可能不會直接存儲在合約中，但具有數(shù)據(jù)表示形式，因此允許確定產(chǎn)生隨機(jī)性的惟一值。在該方案中，RP是區(qū)塊鏈用戶，任何人都可以參與生成過程。

獨立合約選項看起來不錯，因為：

· 可移植性（合約可以在區(qū)塊鏈之間“拖動”）

· 易于實現(xiàn)和測試（編寫和測試合約很方便）

· 方便的經(jīng)濟(jì)方案（使用特定于PVRB的邏輯很容易創(chuàng)建自己的代幣）

· 適用于區(qū)塊鏈中工作

它也有缺點：

· 對消耗的計算資源的嚴(yán)格限制：交易復(fù)雜性、容量、網(wǎng)絡(luò)速度和區(qū)塊鏈存儲（換句話說，是傳統(tǒng)的cpu/mem/io/存儲）

· 存在內(nèi)部合約機(jī)指令的限制（并非所有指令都可用，很難連接外部庫）

· 消息傳遞的速度不能超過區(qū)塊鏈中包含的交易的速度

如果我們想在現(xiàn)有的網(wǎng)絡(luò)中運行PVRB，而該網(wǎng)絡(luò)不包含復(fù)雜的加密技術(shù)，也不需要大量的交互，那么這個選項是合適的。

共識一體化選擇

這里PVRB嵌入到區(qū)塊鏈節(jié)點代碼中，或者與區(qū)塊鏈節(jié)點消息傳遞并行工作。協(xié)議結(jié)果直接寫入產(chǎn)生的塊中，而協(xié)議消息在節(jié)點之間通過p2p網(wǎng)絡(luò)發(fā)送。由于協(xié)議的數(shù)值結(jié)果需要用塊來編寫，因此網(wǎng)絡(luò)必須對它們達(dá)成一致。這意味著PVRB消息和交易必須由節(jié)點進(jìn)行驗證，并包含在塊中（以便網(wǎng)絡(luò)中的任何成員都可以驗證是否符合PVRB協(xié)議）。這自動將我們引向一個顯而易見的解決方案——如果網(wǎng)絡(luò)在一個塊及其交易上達(dá)成共識，那么PVRB應(yīng)該是共識的一部分，而不是一個獨立的協(xié)議。否則，該塊在協(xié)商共識方面是有效的，但是由于沒有遵循PVRB協(xié)議，因此不能接受該塊。因此，如果選擇“共識整合”選項，PVRB將成為共識的重要組成部分。

在網(wǎng)絡(luò)共識級別上討論PVRB實現(xiàn)時，無論如何都不能避免終結(jié)性問題。終結(jié)性是確定性共識中使用的一種機(jī)制，它修復(fù)了一個“最終確定”的塊（以及指向它的鏈），即使在并行分叉的情況下，這個塊也不會被丟棄。如果你發(fā)布一條更復(fù)雜的鏈，它將取代任何其他更簡單的鏈，而不用管鏈的“年齡”和長度。例如，在EOS中，有所謂的最后不可逆塊被認(rèn)為是最終確定的。它們平均每432個塊出現(xiàn)一次（12*21（預(yù)投票）+ 12*15（預(yù)提交））。而比上一個庫更老的分支將被簡單地丟棄。該機(jī)制保證交易包含在區(qū)塊鏈中，并且永遠(yuǎn)不會回滾。開發(fā)一個協(xié)議來確保最終結(jié)果作為一個一致的外接程序是有意義的，因為它能夠與塊生產(chǎn)和發(fā)布異步工作。

當(dāng)BP持有這些區(qū)塊，并在網(wǎng)絡(luò)看到一筆不錯的交易后發(fā)布它們時，對于那些可能成為“雙倍支出”攻擊受害者的用戶來說，最終結(jié)果至關(guān)重要。PVRB有更嚴(yán)格的終結(jié)性要求，因為分叉構(gòu)造意味著攻擊者可以準(zhǔn)備幾個隨機(jī)數(shù)選項并發(fā)布最有益的一個。因此，限制可能的攻擊時間是一個很好的解決方案。

因此，最好的選擇是將PVRB和終結(jié)性結(jié)合在一個協(xié)議中—那么最終確定的塊將等于最終確定的隨機(jī)數(shù)—這正是我們的目標(biāo)。從現(xiàn)在開始，玩家將在N秒內(nèi)得到一個保證的隨機(jī)數(shù)，并確保不可能將其回滾或重放。

共識一致選項看起來不錯：

· 與塊生產(chǎn)相關(guān)的可能的異步實現(xiàn)——塊像往常一樣生成，但是PVRB協(xié)議可以并行工作，并為每個塊生成隨機(jī)數(shù)

· 能夠?qū)崿F(xiàn)即使是復(fù)雜的密碼學(xué)，沒有智能合約的限制

· 能夠比區(qū)塊鏈中包含的交易更快地組織消息傳遞，例如，協(xié)議的一部分可以在沒有網(wǎng)絡(luò)交互的節(jié)點之間工作

它也有缺點：

· 測試和開發(fā)中的困難—您將不得不模擬錯誤網(wǎng)絡(luò)、丟失的節(jié)點和網(wǎng)絡(luò)硬分叉

· 實現(xiàn)錯誤需要一個網(wǎng)絡(luò)硬分叉

這兩種實現(xiàn)PVRB的方法都是可以接受的，但是現(xiàn)代區(qū)塊鏈中的智能合約在計算資源方面仍然非常有限，這使得一般的密碼學(xué)幾乎不可能實現(xiàn)。但是這種情況一年比一年好。我們可以以以太坊中zksnark的預(yù)編譯系統(tǒng)合約為例。

提供透明可靠的協(xié)議消息傳遞通道并不是免費的。任何分散協(xié)議都必須考慮到可能發(fā)生的西比爾（ Sybil）攻擊，任何行動都可以通過多個帳戶進(jìn)行協(xié)調(diào)。在開發(fā)過程中，請記住攻擊者能夠從任意數(shù)量的協(xié)議參與者中創(chuàng)建共謀。

PVRB和塊變量

我并沒有撒謊說 （到2019年春季） 還沒有人在區(qū)塊鏈中實施一個好的、強(qiáng)大的 PVRB， 并在賭博應(yīng)用中進(jìn)行了測試。以太坊和 EOS 中的這些賭博應(yīng)用申請來自何方？我和你一樣驚訝： 在完全確定的環(huán)境中， 怎么會有這么多 “強(qiáng)” 隨機(jī)數(shù)呢？

我最喜歡的在區(qū)塊鏈中獲取隨機(jī)數(shù)的方法是從塊中獲取一些“不可預(yù)測”的信息，并在其基礎(chǔ)上生成一個隨機(jī)數(shù)。您還可以選擇塊中的任何其他“不可預(yù)測”值，例如，塊哈希值、大量交易、網(wǎng)絡(luò)復(fù)雜性和其他未知值。您甚至可以在白皮書中寫道，您的方案是“后量子安全的”（因為存在防量子哈希值函數(shù)：）。

唉，即使是后量子安全的哈希值也不夠。秘訣在于PVRB的要求，我將引用上一篇文章：

1. 結(jié)果應(yīng)該具有可證明的均勻分布，即基于強(qiáng)密碼學(xué)。

2. 控制任何一點結(jié)果都是不可能的。

3. 不參與協(xié)議或用攻擊消息重載網(wǎng)絡(luò)來破壞生成協(xié)議是不可能的。

4. 上面所述的一切都應(yīng)抵制一定數(shù)量的不誠實的協(xié)議參與者（例如1/3的參與者）串通一氣。

在這種情況下，只需滿足第一個需求。通過哈希不可預(yù)測的塊值，我們將得到一個均勻分布和正確的隨機(jī)數(shù)。BP至少能夠決定是否“驗證一個塊”，并從兩個隨機(jī)變量中進(jìn)行選擇的問題。BP可以作弊，保留一個塊來看看接下來會發(fā)生什么，然后決定是否發(fā)布它。因此，以“偶數(shù)-奇數(shù)”或“紅/黑”輪盤賭為例，他只能在獲利的情況下發(fā)布一個區(qū)塊。使用未來塊的參數(shù)也沒有什么意義。在這種情況下，他們說“通過哈希當(dāng)前數(shù)據(jù)和一個高度為N+42的未來塊獲得隨機(jī)性，其中N是當(dāng)前塊高度”。這稍微加強(qiáng)了該方案，但是BP仍然可以選擇是否持有或發(fā)布區(qū)塊。

在塊生成軟件中執(zhí)行這樣的攻擊并不復(fù)雜。在驗證和包含一個塊中的交易時，會有一個快速檢查通道，以查看是否會有收益，并可能選擇一個交易參數(shù)來增加獲勝概率。與此同時，發(fā)現(xiàn)一個聰明的BP來執(zhí)行這樣的操作幾乎是不可能的，因為每次他都可以使用新的地址，并在不引起懷疑的情況下一點一點地獲勝。

因此，基于塊數(shù)據(jù)的方法不適用于通用PVRB實現(xiàn)。在一個簡短的版本中，限制了賭注大小、玩家數(shù)量或KYC注冊（為了禁止玩家使用多個地址），這些方案只適用于小型游戲。

PVRB和commit-reveal

好吧， 至少我們有哈希值， 一個 “幾乎不可預(yù)測” 的塊哈希值。如果我們設(shè)法解決領(lǐng)先礦工的問題， 我們可能會得到更有價值的東西。讓我們將用戶添加到此方案中， 并允許他們影響隨機(jī)性結(jié)果： 任何技術(shù)支持員工都會告訴您， IT 系統(tǒng)中最隨機(jī)的問題是用戶操作：）

在這種方案中，用戶只需發(fā)送隨機(jī)數(shù)，然后通過哈希他們的共同產(chǎn)品計算結(jié)果。在這種情況下，最后一個玩家可以選擇自己的隨機(jī)數(shù)來控制結(jié)果。這就是為什么最好使用眾所周知的commit-reveal模式。首先，參與者發(fā)送他們的隨機(jī)數(shù)的哈希值，然后提交原始隨機(jī)數(shù)。一旦收集了所有必要的提交，“reveal”階段就開始了，也就是說，參與者只能發(fā)送之前提交的哈希值隨機(jī)數(shù)。現(xiàn)在我們將添加塊參數(shù)—最好使用將來的塊參數(shù)，因為隨機(jī)數(shù)只出現(xiàn)在下一個塊中?，F(xiàn)在任何玩家都可以影響結(jié)果的隨機(jī)性，并能夠“擊敗”一個惡意的BP，用它自己不可預(yù)測的隨機(jī)性來阻止它……您還可以通過為“提交”請求一些交易費用來提高協(xié)議安全性。

這是一個很好的嘗試（類似的方案也在不同的DApps中使用）。唉，這還不夠?，F(xiàn)在，不僅礦工可以影響結(jié)果，協(xié)議的任何參與者也可以。

至少我們有機(jī)會懲罰那些提交了卻而沒有顯示的人，這個方案稍后會有用。此外，它的簡單性也是一個重要的優(yōu)勢，因為更重要的協(xié)議需要更多的計算。

PVRB和確定性簽名

確定性簽名是使RP生成偽隨機(jī)數(shù)的另一種好方法，它不會影響偽隨機(jī)數(shù)。例如，RSA簽名就是其中之一，而ECS（橢圓曲線簽名）則不是。如果RP有一對密鑰（RSA和ECS），并且他使用自己的私鑰對一些值進(jìn)行簽名，RSA允許生成一個惟一的簽名，而ECS允許生成任意數(shù)量的有效簽名。在創(chuàng)建ECS簽名時，簽名者可以隨意選擇一個隨機(jī)數(shù)，從而有機(jī)會從多個簽名中選擇一個。RSA是 “一個輸入值”+“一個密鑰對”=“一個簽名”。要預(yù)測另一個RP的簽名是不可能的，因此具有確定性簽名的PVRB可以通過組合多個已簽名相同值的參與者的RSA簽名來構(gòu)建，例如前面的隨機(jī)數(shù)。這種方案節(jié)省了大量資源，因為簽名既是正確協(xié)議行為的確認(rèn)，也是隨機(jī)性的來源。

然而，確定性簽名并不是萬能的，而且該方案仍然容易受到“最后一個參與者”問題的影響。最后一個參與者仍然可以決定是否發(fā)布簽名，從而控制結(jié)果。此外，RSA密鑰可以很長（1024和2048位），這對于區(qū)塊鏈交易來說是一個非常重要的參數(shù)。顯然，沒有簡單的方法來解決這個問題。

PVRB和秘密共享方案

有一些加密方案允許網(wǎng)絡(luò)協(xié)商一個惟一的PVRB值，同時保持對某些參與者的任何惡意行為的抵抗。其中一個有用的協(xié)議是Shamir的秘密共享。它將一些秘密（例如，一個秘密密鑰）劃分為幾個部分，并將這些部分分發(fā)給N個參與者。這個秘密的分布方式是，從N到M個部分足夠恢復(fù)它，這些可以是任意M個部分。簡單地說，有一個未知函數(shù)的圖，參與者在圖上交換點，得到M個點后，整個函數(shù)就可以恢復(fù)（線性函數(shù)需要2個點，二次函數(shù)需要3個點，等等）。

wiki提供了一個很好的解釋;您還可以在這個演示頁面上以實時模式試用該協(xié)議。

如果FSSS （Fiat-Shamir秘密共享）方案能夠以其單純的形式應(yīng)用，PVRB將是無懈可擊的。在其最簡單的形式中，協(xié)議可能是這樣的：

· 每個參與者生成一個隨機(jī)數(shù)，并將其份額分配給其他人

· 每個參與者都揭示了其他參與者的秘密

· 如果一個參與者收集了更多的m點，他的數(shù)字可以計算出來。無論“顯示”的參與者集是什么，這個數(shù)字都是惟一的

· 所需的PVRB是顯示的隨機(jī)數(shù)的組合

因此，考慮到有必要數(shù)量的可靠RP遵循規(guī)則，該協(xié)議按照嚴(yán)格的密碼學(xué)要求工作，并保持對“最后一個參與者”問題的抵抗力。

這可能是一個理想的選擇。例如，本文描述了基于Fiat-Shamir秘密共享的PVRB方案。正如我前面提到的，如果您試圖將其應(yīng)用到區(qū)塊鏈的單純形式中，技術(shù)限制將不可避免地出現(xiàn)。下面是EOS 智能合約中協(xié)議測試實現(xiàn)的一個示例，其中最重要的部分是檢查參與者已發(fā)布的共享：代碼。很明顯，證明驗證需要多次標(biāo)量乘法，而且數(shù)字非常大。同時，我們應(yīng)該記住，在區(qū)塊鏈中，當(dāng)區(qū)塊生產(chǎn)者處理事交易時，會調(diào)用verify函數(shù)。一般來說，任何參與者都應(yīng)該很容易地驗證協(xié)議的正確性，這就是為什么對“verify（）”函數(shù)的速度要求非常嚴(yán)格的原因。我們的方案沒有成功，因為驗證沒有滿足交易時間限制（0.5秒）。

驗證效率是區(qū)塊鏈中任何高級密碼方案最重要的要求之一。證明和消息創(chuàng)建可以脫離鏈，由高性能計算機(jī)完成，但是不能忽略驗證——這是PVRB的另一個重要要求。

PVRB和閾值簽名

秘密共享方案打開了在“閾值”保護(hù)傘下統(tǒng)一的一類協(xié)議。他們允許處理“最后的參與者”的問題：如果攻擊者不透露秘密的一部分，另一個誠實的參與者會相反。反過來，這使我們能夠就唯一的意義達(dá)成一致，即使一些參與者正在破壞協(xié)議。

結(jié)合確定性簽名和閾值方案，我們得到了一個非常方便和有前途的PVRB方案-確定性閾值簽名。

上一篇文章討論了BLS的公共簽名和私有簽名以及密鑰，現(xiàn)在可以使用簡單的數(shù)學(xué)操作組合它們——這對開發(fā)人員來說非常方便。組合仍然是有效的密匙和簽名，這使得將多個簽名聚合為一個密匙和多個公鑰聚合為一個密匙變得很容易。它們的決定論允許獲得具有相同輸入數(shù)據(jù)的相同結(jié)果。由于這種特性，BLS簽名組合成為有效的密鑰，這使得M個誠實的參與者（從N個總數(shù)到M個總數(shù)）有可能生成唯一的確定性、公共可驗證性和不可預(yù)測的簽名，直到M個參與者披露為止。

在BLS閾值簽名方案中，每個參與者都使用BLS（例如前面的隨機(jī)數(shù)）簽名，并將其份額發(fā)送給區(qū)塊鏈。BLS簽名的密碼特性滿足隨機(jī)性質(zhì)量要求，因為閾值部分防止“最后的參與者”，而密鑰的獨特兼容性允許使用許多有趣的算法（例如，有效聚合協(xié)議消息的算法）。

因此，如果您正在為您的區(qū)塊鏈在2019年春夏構(gòu)建PVRB，您很可能會遇到BLS閾值簽名方案;一些項目已經(jīng)在使用它。例如，DFinity是一個實現(xiàn)該方案的基準(zhǔn)測試工具， Keep.network是一個為協(xié)議提供服務(wù)的智能合約示例。

實現(xiàn)PVRB

遺憾的是，目前還沒有真正的強(qiáng)密碼PVRB區(qū)塊鏈協(xié)議，這證明了它在真實的DApps中的安全性和穩(wěn)定性。盡管現(xiàn)有協(xié)議是現(xiàn)成的，但是將它們應(yīng)用于現(xiàn)有解決方案并不容易。PVRB對于集中式系統(tǒng)毫無用處，而分散式系統(tǒng)的計算資源非常有限：CPU、內(nèi)存、存儲、I/O。開發(fā)PVRB涉及到不同協(xié)議的組合，以便它能夠匹配至少一個真正可行的區(qū)塊鏈。

我將列出您在選擇高品質(zhì)PVRB時必須考慮的因素：

1. 它應(yīng)該是強(qiáng)加密的，即嚴(yán)格不可偏置的，不能給任何人控制。對于某些方案，情況并非如此，因此最好向密碼編寫者尋址。

2. “最后一個參與者”問題。當(dāng)控制一個或多個RP的攻擊者可以在兩種可能的結(jié)果中進(jìn)行選擇時，PVRB必須能夠抵抗攻擊。

3. 協(xié)議破壞。當(dāng)控制一個或多個RP的攻擊者決定是否生成隨機(jī)數(shù)時，您的PVRB必須能夠抵抗攻擊，并且能夠影響隨機(jī)信標(biāo)的生成。

4. 消息數(shù)量。您的RP應(yīng)該向區(qū)塊鏈發(fā)送最少數(shù)量的消息，并盡可能避免同步操作，比如“發(fā)送信息，等待特定參與者的響應(yīng)”。您不應(yīng)該期望p2p網(wǎng)絡(luò)中的快速響應(yīng)，尤其是來自地理分布的網(wǎng)絡(luò)。

5. 計算的復(fù)雜性。任何PVRB階段的鏈上驗證都應(yīng)該很容易，因為它是由所有完整的網(wǎng)絡(luò)客戶機(jī)執(zhí)行的。在智能合約執(zhí)行的情況下，速度要求是非常嚴(yán)格的。

6. 可訪問性和靈活性。您的PVRB應(yīng)該對可能的網(wǎng)絡(luò)故障具有彈性（例如，當(dāng)它在一段時間內(nèi)不可用，并且部分RPs停止工作時）。

7. 可信設(shè)置和初始密鑰分發(fā)。如果PVRB涉及主協(xié)議設(shè)置，則可能會導(dǎo)致某些問題。這里舉一個例子：如果參與者必須在開始協(xié)議之前告訴對方他們的密鑰，這也是一個問題，因為參與者的列表可能會改變。

8. 發(fā)展問題。所需語言的庫的可用性、它們的安全性和性能、公共可訪問性、復(fù)雜的測試等等。

例如，閾值BLS簽名有一個顯著的瓶頸——在開始之前，參與者必須共享密鑰并組織閾值組。這意味著我們將不得不在一個分散式網(wǎng)絡(luò)中跳過至少一輪，并且，由于隨機(jī)數(shù)對于實時模式下的游戲來說是必不可少的，因此存在著很高的協(xié)議破壞風(fēng)險，而閾值方案的優(yōu)點將變得毫無用處。這個問題比之前的問題要簡單，但是我們?nèi)匀恍枰_發(fā)一個單獨的閾值組程序，它必須通過對不遵守協(xié)議的參與者的存款和資金提?。ㄏ鳒p）來得到經(jīng)濟(jì)上的保護(hù)。合約代碼由虛擬機(jī)WebAssembly或EVM執(zhí)行。密碼函數(shù)尚未在本地實現(xiàn)，并且比普通密碼庫慢很多倍。許多協(xié)議根本不滿足密鑰長度要求：例如，RSA的1024位和2048位。這是標(biāo)準(zhǔn)比特幣和以太坊交易簽名大小的4-8倍。

還應(yīng)該使用不同的編程語言實現(xiàn)，這種語言并不多，尤其是對于新協(xié)議而言。為了將PVRB集成到共識中，我們應(yīng)該用平臺語言編寫代碼，即查找用于geth的Go代碼、Parity的Rust代碼和用于EOS的c++代碼。JavaScript代碼更難找到，而且由于JavaScript和密碼學(xué)關(guān)系并不密切，所以選擇WebAssembly。它看起來將成為下一個重要的互聯(lián)網(wǎng)標(biāo)準(zhǔn)。

結(jié)論

我希望在上一篇文章中，我成功地說服了您，區(qū)塊鏈中的隨機(jī)數(shù)生成對于分散式網(wǎng)絡(luò)的許多方面都是至關(guān)重要的。今天我已經(jīng)表明，這項任務(wù)是極其艱巨的，但也有一些很好的解決辦法。說實話，協(xié)議體系結(jié)構(gòu)只有在進(jìn)行了涉及從設(shè)置到故障模擬各個方面的大規(guī)模測試之后才會被認(rèn)為是最終的。你不太可能在白皮書或文章中找到現(xiàn)成的解決方案。我們也不能建議該做什么。至少在最近的幾年是這種情況。

到目前為止，在Haya區(qū)塊鏈中開發(fā)我們的PVRB時，我們已經(jīng)選擇了閾值BLS簽名，并計劃在共識級別上實現(xiàn)PVRB，因為智能合約不允許體面的安全驗證。我們可以同時使用兩種方案：首先，一個昂貴的秘密共享來創(chuàng)建一個長期的種子值，它將作為具有確定性閾值BLS簽名的高頻隨機(jī)數(shù)生成的基礎(chǔ)。我們還可以把自己限制在其中一個計劃之內(nèi)。不可能預(yù)先說協(xié)議是什么樣子的，然而，一個負(fù)面的結(jié)果也是一個結(jié)果，每一次解決問題的新嘗試對參與研究的每個人來說都是另一個步驟。為了滿足業(yè)務(wù)需求，我們正在處理一個特定的實際問題——為游戲應(yīng)用程序提供一個可靠的熵源，因此我們還必須關(guān)注區(qū)塊鏈，特別是終結(jié)性問題和網(wǎng)絡(luò)治理問題。

目前，還沒有經(jīng)過驗證的PVRB可以被長期使用;然而，許多可能的解決方案證明了還是有出路的，最終會有算法來解決這個問題。我們將樂于分享結(jié)果，并感謝其他團(tuán)隊提供的文章和代碼，使開發(fā)人員不會犯同樣的錯誤。