導入

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

暗号化による絶対的に強力な暗号の概念と同様、実際の「Publicly Verifiable Random Beacon」(以下、PVRB) プロトコルは、理想的なスキームに可能な限り近づけようとするだけです。 実際のネットワークでは、純粋な形では適用できません。XNUMX つのビットについて厳密に一致する必要があり、多くのラウンドが必要で、すべてのメッセージが完全に高速で常に配信される必要があります。 もちろん、これは実際のネットワークには当てはまりません。 したがって、最新のブロックチェーンで特定のタスク用に PVRB を設計する場合、結果として生じるランダム性と暗号強度を制御できないことに加えて、純粋にアーキテクチャ上および技術上多くの問題が発生します。

PVRB にとって、ブロックチェーン自体は本質的にメッセージ = トランザクションである通信媒体です。 これにより、ネットワークの問題、メッセージの配信不能、ミドルウェアの問題を部分的に抽象化できます。これらすべてのリスクは分散型ネットワークによって引き受けられ、PVRB の主な価値は、送信済みのトランザクションを取り消したり破損したりできないことです。コンセンサスへの攻撃が成功しない限り、参加者がプロトコルへの参加を拒否することを許可してはなりません。 このレベルのセキュリティは許容できるため、PVRB はメインのブロックチェーン チェーンとまったく同じ程度に参加者による共謀に対して耐性を持つ必要があります。 また、これは、ネットワークがメインのブロックチェーンに同意する場合、たとえ公平な結果として得られる唯一のランダムにも同意する場合でも、PVRB がコンセンサスの一部である必要があることを示唆しています。 または、PVRB は、ブロックチェーンとブロックに関して非同期に動作するスマート コントラクトによって実装された単なるスタンドアロン プロトコルです。 どちらの方法にも長所と短所があり、どちらを選択するかは非常に簡単ではありません。

PVRB を実装する XNUMX つの方法

PVRB を実装するための XNUMX つのオプションについて詳しく説明します。ブロックチェーンから独立したスマート コントラクトを使用して機能するスタンドアロン バージョンと、プロトコルに組み込まれているコンセンサス統合バージョンです。これに従って、ネットワークはブロックチェーンと含まれるトランザクション。 すべての場合において、私は人気のあるブロックチェーン エンジンを意味します。イーサリアム、EOS、およびスマート コントラクトをホストおよび処理する方法においてそれらに類似するすべてのものです。

単独契約

このバージョンでは、PVRB は、ランダム プロデューサー (以下、RP と呼びます) のトランザクションを受け入れ、それらを処理し、結果を結合し、その結果、すべてのユーザーがこのコントラクトから受け取ることができる特定の値に到達するスマート コントラクトです。 この値はコントラクトに直接保存できず、結果として得られるランダムの値を XNUMX つだけ決定論的に取得できるデータによってのみ表されます。 このスキームでは、RP はブロックチェーンのユーザーであり、誰でも生成プロセスに参加することができます。

スタンドアロン契約のオプションは優れています:

• 移植性（コントラクトをブロックチェーンからブロックチェーンにドラッグできる）
• 実装とテストの容易さ (契約の作成とテストが簡単です)
• 経済スキームの実装の利便性 (PVRB の目的を果たすロジックを備えた独自のトークンを簡単に作成できます)
• すでに動作しているブロックチェーン上で起動する可能性

また、次のような欠点もあります。

• コンピューティング リソース、トランザクション ボリューム、ストレージ (つまり、CPU/メモリ/IO) に対する強い制限
• 契約内の操作に制限がある（すべての命令が利用できるわけではない、外部ライブラリとの接続が難しい）
• ブロックチェーンにトランザクションが含まれるよりも速くメッセージを整理できない

このオプションは、既存のネットワーク上で実行する必要があり、複雑な暗号化が含まれず、多数の対話を必要としない PVRB の実装に適しています。

コンセンサス統合

このバージョンでは、PVRB がブロックチェーン ノード コードに実装され、ブロックチェーン ノード間のメッセージ交換に組み込まれるか、並行して実行されます。 プロトコルの結果は生成されたブロックに直接書き込まれ、プロトコル メッセージはノード間の p2p ネットワーク経由で送信されます。 このプロトコルでは数値がブロックに書き込まれるため、ネットワークはそれらについて合意に達する必要があります。 これは、ネットワーク参加者が PVRB プロトコルへの準拠を検証できるように、PVRB メッセージはトランザクションと同様にノードによって検証され、ブロックに含められる必要があることを意味します。 これにより、自動的に明白な解決策が導き出されます。ネットワークがブロックとそのブロック内のトランザクションに関するコンセンサスに同意する場合、PVRB はスタンドアロン プロトコルではなく、コンセンサスの一部である必要があります。 それ以外の場合、コンセンサスの観点からはブロックが有効であっても、PVRB プロトコルに従っていないため、PVRB の観点からはブロックを受け入れることができない可能性があります。 したがって、「コンセンサス統合」オプションが選択された場合、PVRB はコンセンサスの重要な部分になります。

ネットワークコンセンサスレベルで PVRB の実装を説明する場合、ファイナリティの問題を決して避けることはできません。 ファイナリティは、最終的なブロック (およびそれにつながるチェーン) をロックし、並列フォークが発生した場合でも決して破棄されない、決定論的なコンセンサスで使用されるメカニズムです。 たとえば、ビットコインにはそのようなメカニズムはありません。より複雑なチェーンを公開すると、チェーンの長さに関係なく、より複雑でないチェーンが置き換えられます。 そして、たとえば EOS では、最後のブロックはいわゆる最後の不可逆ブロックであり、平均して 432 ブロック (12*21 + 12*15、投票前 + コミット前) ごとに表示されます。 このプロセスは基本的に、ブロックプロデューサー (以下、BP と呼びます) の署名の 2/3 を待ちます。 最後の LIB よりも古いフォークが出現した場合、それらは単純に破棄されます。 このメカニズムにより、攻撃者がどのようなリソースを持っているかに関係なく、トランザクションがブロックチェーンに含まれ、決してロールバックされないことを保証できます。 また、最終ブロックは、Hyperledger、Tendermint、およびその他の pBFT ベースのコンセンサスで 2/3 BP によって署名されたブロックです。 また、ファイナリティを保証するためのプロトコルをコンセンサスへのアドオンにすることは理にかなっています。これは、ブロックの生成と公開と非同期で動作できるためです。 ここに良いものがあります 記事 イーサリアムのファイナリティについて。

ファイナリティはユーザーにとって非常に重要であり、ファイナリティがないと、BP がブロックを「保持」し、ネットワークが良好なトランザクションを「確認」した後にブロックを公開する「二重支払い」攻撃の被害者になる可能性があります。 ファイナリティがない場合、公開されたフォークはブロックを「良い」トランザクションに置き換え、「悪い」フォークから別のトランザクションに置き換え、同じ資金が攻撃者のアドレスに転送されます。 PVRB の場合、ファイナリティの要件はさらに厳しくなります。これは、PVRB 用のフォークを構築するということは、攻撃者が最も収益性の高いオプションを公開するためにいくつかのランダムなオプションを準備する機会を意味し、攻撃の可能性のある時間を制限することが重要であるためです。良い解決策。

したがって、最良のオプションは、PVRB とファイナリティを XNUMX つのプロトコルに結合することです。その場合、ファイナライズされたブロック = ファイナライズされたランダムとなり、これがまさに私たちが取得する必要があったものです。 これで、プレイヤーは N 秒以内にランダムなランダムを受け取ることが保証され、ロールバックや再プレイが不可能であることを確信できます。

コンセンサス統合オプションは優れています:

• ブロックの生成に関連した非同期実装の可能性 - ブロックは通常どおり生成されますが、これと並行して、ブロックごとにランダム性を生成しない PVRB プロトコルが機能します。
• スマートコントラクトに課せられる制限なしに、強力な暗号化さえも実装できる機能
• トランザクションよりも高速にメッセージの交換を組織する機能がブロックチェーンに組み込まれています。たとえば、プロトコルの一部は、ネットワーク上でメッセージを分散せずにノード間で機能できます。

また、次のような欠点もあります。

• テストと開発の難しさ - ネットワーク エラー、ノードの欠落、ネットワーク ハード フォークをエミュレートする必要があります。
• 実装エラーにはネットワーク ハードフォークが必要です

PVRB を実装するどちらの方法にも生存権がありますが、最新のブロックチェーンでのスマート コントラクトの実装は依然としてコンピューティング リソースが非常に限られており、本格的な暗号化への移行は単純に不可能であることがよくあります。 そして、以下で説明するように、本格的な暗号化が必要になります。 この問題は明らかに一時的なものですが、多くの問題を解決するには契約における本格的な暗号化が必要であり、徐々に現れてきています (たとえば、イーサリアムの zkSNARK のシステム契約)。

ブロックチェーンは透過的で信頼性の高いプロトコル メッセージング チャネルを提供しますが、それは無料ではありません。 分散型プロトコルでは、Sybil 攻撃の可能性を考慮する必要があり、あらゆるアクションは複数のアカウントの連携によって実行される可能性があるため、設計時には、攻撃者が任意の数のプロトコルを作成できることを考慮する必要があります。参加者が共謀して行動すること。

PVRB およびブロック変数。

多くのギャンブルアプリケーションでテストされた優れた PVRB をブロックチェーンに実装した人はまだ誰もいないと言ったのは嘘ではありませんでした。 では、これほど多くのギャンブル アプリケーションがイーサリアムや EOS 上でどこから来たのでしょうか? これはあなたが驚くのと同じくらい私も驚いていますが、彼らは完全に決定論的な環境でこれほど多くの「永続的な」ランダムをどこで入手したのでしょうか?

ブロックチェーンでランダム性を得る一般的な方法は、ブロックからある種の「予測不可能な」情報を取得し、それに基づいてランダムな情報を作成することです。単純に XNUMX つ以上の値をハッシュするだけです。 このようなスキームの問題についての良い記事 ここで。 ブロック内の任意の「予測不可能な」値、たとえば、ブロック ハッシュ、トランザクション数、ネットワークの複雑さ、および事前に不明なその他の値を取得できます。 次に、XNUMX つ以上のそれらをハッシュすると、理論的には、実際のランダムが得られるはずです。 ホワイトペーパーに、自分のスキームが「ポスト量子安全」であることを追加することもできます (量子耐性のあるハッシュ関数があるため :))。

しかし、悲しいことに、量子後の安全なハッシュでも十分ではありません。 その秘密は PVRB の要件にあります。前の記事の要件を思い出してください。

1. 結果は、証明された一様な分布を持っていなければなりません。つまり、証明された強力な暗号化に基づいている必要があります。
2. 結果のビットを制御することはできません。 したがって、結果を事前に予測することはできません。
3. プロトコルに参加しなかったり、攻撃メッセージでネットワークに過負荷をかけたりして、生成プロトコルを妨害することはできません。
4. 上記のすべては、許容される数の不誠実なプロトコル参加者 (たとえば、参加者の 1/3) の共謀に耐性がなければなりません。

この場合、要件 1 のみが満たされ、要件 2 は満たされていませんが、ブロックから予測不可能な値をハッシュすることで、均一な分布と良好なランダムが得られます。 しかしBPには​​少なくとも「ブロックを公開するか否か」という選択肢がある。 したがって、BP は少なくとも 42 つのランダムなオプションから選択できます。「独自の」オプションと、他の誰かがブロックした場合に判明するオプションです。 BP は、ブロックを公開すると何が起こるかを事前に「覗き見」し、それを実行するかどうかを決定するだけです。 したがって、たとえばルーレットで「偶数-奇数」または「赤/黒」をプレイする場合、勝利が確認された場合にのみブロックを公開できます。 これにより、たとえば「将来からの」ブロック ハッシュを使用する戦略も実行できなくなります。 この場合、「ランダムが使用されます。これは、現在のデータと、たとえば N + XNUMX の高さの将来のブロックのハッシュをハッシュすることによって取得されます。ここで、N は現在のブロックの高さです。」 これによりこのスキームは少し強化されますが、BP は将来的にはブロックを保持するか公開するかを選択できるようになります。

この場合の BP ソフトウェアはより複雑になりますが、それほど複雑ではありません。 簡単に言うと、トランザクションを検証してブロックに含めるときに、勝ちがあるかどうかを簡単に確認し、場合によっては勝ちの確率を高めるために XNUMX つのトランザクション パラメーターを選択します。 同時に、そのような操作で賢い BP を捕まえることはほとんど不可能です; そのたびに、新しいアドレスを使用して、疑いを抱かずに少しずつ勝つことができます。

したがって、ブロックからの情報を使用するメソッドは、PVRB の汎用実装としては適していません。 ベットサイズの制限、プレーヤーの数および/またはKYC登録の制限（XNUMX人のプレーヤーが複数のアドレスを使用することを防ぐため）を備えた限定バージョンでは、これらのスキームは小規模なゲームでは機能しますが、それ以上は機能しません。

PVRB とコミット公開。

そうですね、ハッシュ化と、少なくともブロック ハッシュやその他の変数の相対的な予測不可能性のおかげで。 フロントランニングマイナーの問題を解決すれば、より適切なものが得られるはずです。 このスキームにユーザーを追加しましょう - ユーザーにランダム性にも影響を与えましょう。テクニカル サポートの従業員なら誰でも、IT システムで最もランダムなものはユーザーのアクションだと言うでしょう :)

ユーザーが単純に乱数を送信し、その結果がたとえばその合計のハッシュとして計算されるような単純なスキームは適切ではありません。 この場合、最後のプレイヤーは自分のランダムを選択することで、結果がどうなるかを制御できます。 これが、非常に広く使用されている commit-reveal パターンが使用される理由です。 参加者はまずランダムからハッシュを送信し (コミット)、次にランダムを自分で開きます (公開)。 「公開」フェーズは必要なコミットが収集された後にのみ開始されるため、参加者は以前に送信したランダム ハッシュを正確に送信できます。 では、これらすべてをブロックのパラメーターと組み合わせてみましょう。未来から取得したものよりも優れています (ランダム性は将来のブロックの XNUMX つにのみ見つかります)。これで、ランダム性の準備が整いました。 これで、どのプレイヤーも結果として生じるランダム性に影響を与え、悪意のある BP を自分自身の事前に不明なランダム性でオーバーライドすることで、悪意のある BP を「倒す」ことができます。また、公開段階でプロトコルを開かないようにすることで、プロトコルの妨害に対する保護を追加することもできます。これは、コミット時に取引に一定の金額、つまり保証金を添付することを要求することによって行われます。保証金は公開手続き中にのみ返還されます。 この場合、コミットしても明らかにしないことは利益を生みません。

これは良い試みであり、そのようなスキームはゲーム DApp にも存在しますが、残念ながら、これでも十分ではありません。 マイナーだけでなく、プロトコルの参加者も結果に影響を与えることができるようになりました。 変動が少なくコストがかかりますが、値自体を制御することは依然として可能ですが、マイナーの場合のように、抽選の結果が PVRB プロトコルへの参加料よりも価値がある場合、ランダムな-プロデューサー(RP)は公開するかどうかを決定でき、少なくとも XNUMX つのランダムなオプションから選択することができます。
しかし、犯罪を犯したのに暴露しない者を罰することが可能になり、この制度は役に立つだろう。 その単純さは大きな利点です。より本格的なプロトコルでは、より強力な計算が必要になります。

PVRB と決定論的署名。

「プリイメージ」が提供されている場合には影響を及ぼさない疑似乱数を RP に強制的に提供させる別の方法があります。これは決定論的な署名です。 このような署名は、たとえば RSA であり、ECS ではありません。 RP が鍵のペア (RSA と ECC) を持っており、秘密鍵で特定の値に署名した場合、RSA の場合は XNUMX つだけの署名を取得し、ECS の場合は任意の数の署名を生成できます。有効な署名が異なります。 これは、ECS 署名を作成するときに、署名者が選択した乱数が使用され、任意の方法で選択できるため、署名者には複数の署名から XNUMX つを選択する機会が与えられます。 RSA の場合: 「XNUMX つの入力値」 + 「XNUMX つの鍵ペア」 = 「XNUMX つの署名」。 別の RP がどのような署名を取得するかを予測することは不可能であるため、同じ値に署名した複数の参加者の RSA 署名を組み合わせることによって、決定的な署名を持つ PVRB を編成できます。 たとえば、前のランダム。 このスキームは多くのリソースを節約します。 署名は、プロトコルに従った正しい動作の確認であると同時に、ランダム性の原因でもあります。

ただし、決定論的な署名があっても、このスキームは依然として「最後のアクター」問題に対して脆弱です。 最後の参加者は署名を公開するかどうかを決定できるため、結果を制御できます。 スキームを変更したり、それにブロック ハッシュを追加したり、結果が事前に予測できないようにラウンドを作成したりすることはできますが、これらすべての手法は、多くの変更を考慮したとしても、1024 人の参加者が集合体に与える影響という問題が未解決のまま残ります。その結果、信頼できない環境が生じ、経済的および時間的制約の下でしか機能できません。 さらに、RSA キーのサイズ (2048 ビットおよび XNUMX ビット) は非常に大きく、ブロックチェーン トランザクションのサイズは非常に重要なパラメーターです。 どうやら問題を解決する簡単な方法はないようです。先に進みましょう。

PVRB と秘密共有スキーム

暗号化では、ネットワークが XNUMX つだけの PVRB 値に同意できるようにするスキームが存在しますが、そのようなスキームは一部の参加者の悪意のある行為に対して耐性があります。 知っておく価値のある便利なプロトコルの XNUMX つは、Shamir の秘密共有スキームです。 これは、秘密 (秘密キーなど) をいくつかの部分に分割し、これらの部分を N 人の参加者に配布するのに役立ちます。 シークレットは、N 個のうち M 個の部分で十分に回復できるように配布されます。これらは任意の M 個の部分にすることができます。 指に未知の関数のグラフがある場合、参加者はグラフ上のポイントを交換し、M ポイントを受け取った後、関数全体を復元できます。
良い説明が与えられています ウィキ しかし、頭の中でプロトコルを再生するために実際に遊んでみると、次のような場合に役立ちます。 デモ ページ。

FSSS (Fiat-Shamir Secret Sharing) スキームが純粋な形で適用できる場合、それは破壊不可能な PVRB となるでしょう。 最も単純な形式では、プロトコルは次のようになります。

• 各参加者は独自のランダムを生成し、そこから他の参加者にシェアを分配します
• 各参加者は他の参加者の秘密の自分の部分を明らかにします
• 参加者が M 個を超えるシェアを持っている場合、この参加者の数は計算でき、公開された参加者のセットに関係なく一意になります。
• 明らかにされたランダムの組み合わせが目的の PVRB です

ここでは、ランダム性開示閾値の達成がその人だけに依存する場合を除いて、個々の参加者はプロトコルの結果に影響を与えなくなります。 したがって、このプロトコルは、プロトコル上で動作し、利用可能な必要な割合の RP があれば機能し、暗号強度の要件を実装し、「最後のアクター」問題に耐性があります。

これは理想的なオプションである可能性があります。Fiat-Shamir 秘密共有に基づいたこの PVRB スキームは、たとえば次のように説明されています。 この 記事。 しかし、前述したように、それをブロックチェーンに真正面から適用しようとすると、技術的な限界が現れます。 以下は、EOS スマート コントラクトでのプロトコルのテスト実装とその最も重要な部分、つまり公開された共有参加者のチェックの例です。 コー​​ド。 コードから、証明の検証には複数のスカラー乗算が必要であり、使用される数値が非常に大きいことがわかります。 ブロックチェーンでは、ブロックプロデューサーがトランザクションを処理する瞬間に検証が行われ、一般に参加者はプロトコルの正しさを簡単に検証する必要があるため、検証機能の速度要件が非常に重要であることを理解する必要があります。 。 このオプションでは、検証がトランザクション制限 (0.5 秒) 内に収まらなかったため、このオプションは無効であることが判明しました。

検証効率は、一般に、ブロックチェーンで高度な暗号化スキームを使用する場合の最も重要な要件の XNUMX つです。 証明の作成、メッセージの準備 - これらの手順はオフチェーンで実行でき、高性能コンピューターで実行できますが、検証を回避することはできません。これは PVRB のもう XNUMX つの重要な要件です。

PVRB としきい値の署名

秘密分散スキームを理解した後、私たちは「しきい値」というキーワードで統一されたプロトコルのクラス全体を発見しました。 ある情報の開示に N 人中 M 人の正直な参加者の参加が必要で、正直な参加者のセットが N 人の任意のサブセットになり得る場合、私たちは「しきい値」スキームについて話します。 私たちが「最後の攻撃者」問題に対処できるようにしてくれるのは彼らです。攻撃者が秘密の一部を明らかにしなければ、別の誠実な参加者が彼のためにそれを行うことになります。 これらのスキームにより、参加者の一部によってプロトコルが妨害されたとしても、唯一の意味についての合意が可能になります。

決定論的署名と閾値スキームの組み合わせにより、PVRB を実装するための非常に便利で有望なスキームを開発することが可能になりました。これらは決定論的閾値署名です。 ここ 記事 しきい値署名のさまざまな使用法について、もう XNUMX つの優れた使用法を紹介します。 ロングリード ダッシュから。

最後の記事では BLS 署名について説明します (BLS は Boneh-Lynn-Shacham の略です) ここで これは、プログラマーにとって非常に重要かつ非常に便利な性質を持っています。公開鍵、秘密鍵、公開鍵、および BLS 署名は、単純な数学的演算を使用して相互に組み合わせることができ、その組み合わせは有効な鍵と署名のままであり、多数の署名を簡単に集約できます。署名を XNUMX つにまとめ、多数の公開鍵を XNUMX つにまとめます。 また、これらは決定論的であり、同じ入力データに対して同じ結果を生成します。 この性質のおかげで、BLS 署名の組み合わせ自体が有効な鍵となるため、N 人の参加者のうち M 人が、決定的で公的に検証可能で、M 人目までに公開されるまで予測不可能な XNUMX つだけの署名を生成するオプションの実装が可能になります。参加者。

しきい値 BLS 署名を使用するスキームでは、各参加者は BLS を使用して何か (たとえば、前のランダム) に署名し、共通のしきい値署名が目的のランダムになります。 BLS 署名の暗号特性はランダム品質の要件を満たし、しきい値部分は「最後のアクター」から保護します。また、キーの独自の組み合わせにより、プロトコル メッセージの効率的な集約などを可能にする、より多くの興味深いアルゴリズムの実装が可能になります。 。

したがって、ブロックチェーン上に PVRB を構築している場合は、BLS しきい値署名スキームを使用することになる可能性が高く、いくつかのプロジェクトがすでにそれを使用しています。 たとえば、DFinity (ここで 回路を実装するベンチマーク、および ここで 検証可能な秘密共有の実装例)、または Keep.network (これはランダム ビーコンです) 黄紙、しかし、 例 プロトコルを提供するスマート コントラクト)。

PVRBの実装

残念ながら、PVRB ブロックチェーンに実装され、そのセキュリティと安定性が証明された既製のプロトコルはまだ見つかっていません。 プロトコル自体は準備ができていても、それを既存のソリューションに技術的に適用するのは簡単ではありません。 集中型システムの場合、PVRB は意味がありません。分散型システムでは、すべてのコンピューティング リソース (CPU、メモリ、ストレージ、I/O) が厳しく制限されます。 PVRB の設計は、少なくともいくつかの実行可能なブロックチェーンのすべての要件を満たすものを作成するために、さまざまなプロトコルを組み合わせることです。 XNUMX つのプロトコルはより効率的に計算しますが、RP 間でより多くのメッセージを必要とします。もう XNUMX つのプロトコルは、必要なメッセージはほとんどありませんが、プルーフの作成に数十分、場合によっては数時間かかるタスクになる可能性があります。

高品質の PVRB を選択する際に考慮する必要がある要素をリストします。

• 暗号強度。 PVRB は厳密に不バイアスでなければならず、単一ビットを制御する機能はありません。 一部のスキームではこれは当てはまらないため、暗号学者に連絡してください
• 「最後の俳優」問題。 PVRB は、XNUMX つ以上の RP を制御する攻撃者が XNUMX つの結果のうち XNUMX つを選択できる攻撃に耐性を持つ必要があります。
• プロトコル妨害問題。 PVRB は、XNUMX つまたは複数の RP を制御する攻撃者がランダムであるかどうかを決定し、これに影響を与えることが保証されるか、または一定の確率で影響を受ける攻撃に耐性を持つ必要があります。
• メッセージ数の問題。 RP はブロックチェーンに最小限のメッセージを送信し、「情報を送信しました。特定の参加者からの応答を待っています」などの同期アクションを可能な限り回避する必要があります。 P2P ネットワーク、特に地理的に分散したネットワークでは、迅速な応答を期待すべきではありません
• 計算の複雑さの問題。 PVRB オンチェーンのどの段階でも検証は、ネットワークのすべての完全なクライアントによって実行されるため、非常に簡単です。 スマートコントラクトを使用して実装が行われる場合、速度要件は非常に厳しくなります
• アクセシビリティと活気の問題。 PVRB は、ネットワークの一部が一定期間利用できなくなったり、RP の一部が動作を停止したりする状況に耐えられるように努める必要があります。
• 信頼できるセットアップと初期キー配布の問題。 PVRB がプロトコルのプライマリ設定を使用している場合、これは別の大きくて深刻な話になります。 ここ 例。 プロトコルを開始する前に参加者がお互いに自分のキーを伝えなければならない場合、これは参加者の構成が変わった場合にも問題になります。
• 開発上の問題。 必要な言語でのライブラリの可用性、そのセキュリティとパフォーマンス、宣伝、複雑なテストなど。

たとえば、しきい値 BLS 署名には重大な問題があります。作業を開始する前に、参加者は相互にキーを配布し、しきい値が機能するグループを組織する必要があります。 これは、分散型ネットワークで少なくとも 1024 ラウンドの交換を待たなければならないことを意味し、たとえばゲームではほぼリアルタイムで生成されたランドが必要であることを考えると、この段階でプロトコルの妨害行為が可能であることを意味します。となり、しきい値方式の利点が失われます。 この問題はすでに以前の問題よりも単純になっていますが、それでもしきい値グループを形成するための別の手順の開発が必要です。しきい値グループは、ルールに従わない参加者からの資金の入金と引き出し（スラッシュ）を通じて経済的に保護する必要があります。プロトコル。 また、許容可能なレベルのセキュリティを備えた BLS 検証は、たとえば標準の EOS やイーサリアムのトランザクションには適合しません。検証に十分な時間がありません。 コントラクト コードは WebAssembly または EVM で、仮想マシンによって実行されます。 暗号化関数は (まだ) ネイティブに実装されておらず、従来の暗号化ライブラリよりも動作が数十倍遅くなります。 多くのプロトコルは、キーの量だけでは要件を満たしていません。たとえば、RSA の 2048 ビットと 4 ビットは、ビットコインやイーサリアムの標準トランザクション署名の 8 ～ XNUMX 倍です。

さまざまなプログラミング言語での実装の存在も重要な役割を果たしますが、特に新しいプロトコルの場合、その実装はほとんどありません。 コンセンサスに統合するオプションでは、プラットフォーム言語でプロトコルを記述する必要があるため、geth の場合は Go、Parity の場合は Rust、EOS の場合は C++ でコードを探す必要があります。 誰もが JavaScript コードを探す必要がありますが、JavaScript と暗号化は特に密接な関係にあるわけではないため、次の重要なインターネット標準であると今や間違いなく主張している WebAssembly が役に立ちます。

まとめ

前作で期待してるよ статье 私は、ブロックチェーン上で乱数を生成することが、分散型ネットワークの生活の多くの側面にとって重要であることをなんとか説得することができました。この記事では、このタスクが非常に野心的で困難であることを示しましたが、優れたソリューションはすでに存在します。 一般に、プロトコルの最終設計は、セットアップから障害エミュレーションまでのあらゆる側面を考慮した大規模なテストを実施した後にのみ可能となるため、チームのホワイトペーパーや記事で既成のレシピを見つけることはほとんどありませんし、私たちも決して見つけることはありません。来年か XNUMX 年以内に「この方法で、正確に行う」と書くことを決定します。

さようなら、開発中のブロックチェーンの PVRB です ハヤ、閾値BLS署名の使用に落ち着きましたが、許容可能なレベルのセキュリティを備えたスマートコントラクトでの検証はまだ不可能であるため、コンセンサスレベルでPVRBを実装する予定です。 一度に XNUMX つのスキームを使用する可能性があります。XNUMX つ目は、長期的なrandom_seedを作成するための高価な秘密共有であり、次にそれを決定論的しきい値BLS署名を使用した高周波ランダム生成の基礎として使用します。おそらく、これのみに制限します。計画の一つ。 残念ながら、プロトコルがどのようになるかを事前に言うことは不可能です。唯一良いことは、科学や工学の問題と同じように、否定的な結果も結果であり、問​​題を解決するための新しい試みはそれぞれ次のステップであるということです。問題に関係する全員の調査。 ビジネス要件を満たすために、ゲーム アプリケーションに信頼できるエントロピー ソースを提供するという特定の実際的な問題を解決する必要があるため、ブロックチェーン自体、特にチェーンのファイナリティとネットワーク ガバナンスの問題にも注意を払う必要があります。

そして、ブロックチェーンには耐性が証明された PVRB がまだ確認されていませんが、実際のアプリケーション、複数の監査、負荷、そしてもちろん実際の攻撃によってテストされるのに十分な期間使用されていたはずですが、考えられるパスの数はそれを裏付けています。解決策は存在し、これらのアルゴリズムのどれが最終的に問題を解決するのか。 私たちは喜んで結果を共有し、エンジニアが同じ熊手を二度踏まないようにする記事やコードについてこの問題に取り組んでいる他のチームに感謝します。

したがって、分散ランダムを設計しているプログラマーに出会ったら、注意深く思いやりを持って、必要に応じて心理的な助けを提供してください:)

出所： habr.com