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

介紹

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

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

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

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

獨(dú)立合約

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

獨(dú)立合約選項(xiàng)看起來不錯(cuò)，因?yàn)椋?/p>

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

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

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

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

它也有缺點(diǎn)：

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

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

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

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

共識(shí)一體化選擇

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

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

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

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

共識(shí)一致選項(xiàng)看起來不錯(cuò)：

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

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

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

它也有缺點(diǎn)：

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

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

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

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

PVRB和塊變量

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

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

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

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

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

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

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

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

在塊生成軟件中執(zhí)行這樣的攻擊并不復(fù)雜。在驗(yàn)證和包含一個(gè)塊中的交易時(shí)，會(huì)有一個(gè)快速檢查通道，以查看是否會(huì)有收益，并可能選擇一個(gè)交易參數(shù)來增加獲勝概率。與此同時(shí)，發(fā)現(xiàn)一個(gè)聰明的BP來執(zhí)行這樣的操作幾乎是不可能的，因?yàn)槊看嗡伎梢允褂眯碌牡刂?，并在不引起懷疑的情況下一點(diǎn)一點(diǎn)地獲勝。

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

PVRB和commit-reveal

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

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

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

至少我們有機(jī)會(huì)懲罰那些提交了卻而沒有顯示的人，這個(gè)方案稍后會(huì)有用。此外，它的簡單性也是一個(gè)重要的優(yōu)勢，因?yàn)楦匾膮f(xié)議需要更多的計(jì)算。

PVRB和確定性簽名

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

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

PVRB和秘密共享方案

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

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

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

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

· 每個(gè)參與者都揭示了其他參與者的秘密

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

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

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

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

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

PVRB和閾值簽名

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

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

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

在BLS閾值簽名方案中，每個(gè)參與者都使用BLS（例如前面的隨機(jī)數(shù)）簽名，并將其份額發(fā)送給區(qū)塊鏈。BLS簽名的密碼特性滿足隨機(jī)性質(zhì)量要求，因?yàn)殚撝挡糠址乐埂白詈蟮膮⑴c者”，而密鑰的獨(dú)特兼容性允許使用許多有趣的算法（例如，有效聚合協(xié)議消息的算法）。

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

實(shí)現(xiàn)PVRB

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

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

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

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

3. 協(xié)議破壞。當(dāng)控制一個(gè)或多個(gè)RP的攻擊者決定是否生成隨機(jī)數(shù)時(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. 計(jì)算的復(fù)雜性。任何PVRB階段的鏈上驗(yàn)證都應(yīng)該很容易，因?yàn)樗怯伤型暾木W(wǎng)絡(luò)客戶機(jī)執(zhí)行的。在智能合約執(zhí)行的情況下，速度要求是非常嚴(yán)格的。

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

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

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

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

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

結(jié)論

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

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

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