ブロックチェーンコンセンサス分析のためのシンプルなフレームワーク

特邀专栏作者

2019-06-26 04:26

この記事は約3615文字で、全文を読むには約6分かかります

この記事では、さまざまなブロックチェーンコンセンサスを簡単に比較するために、ブロックチェーンコンセンサスを分析するためのシンプルなフレームワークを提案します。

最初のレベルのタイトル

ブロックチェーンコンセンサスの比較
[1] 遅延とは、トランザクションがコンセンサスによって確認されるまでに必要な時間です。低: <10 秒、中: 10 秒～600 秒、高: >=600 秒
[2] コンセンサスパフォーマンスを維持しながら許可されるコンセンサスノードの数。低: <100、中: >=100、高: 制限なし
[4] EOS のプロモーションは BFT を指しますが、何人かの友人と通信した結果、NC がまだ使用されていることがわかりました。これは、EOS の DPoS と BitShares の DPoS が同じである必要があることを意味します。

最初のレベルのタイトル

フレームワークのアイデア

最初のレベルのタイトル

基本的な要件

コンセンサスの基本的な指標には、正確性とパフォーマンスという 2 つの側面が含まれます。正しさには次のものが含まれます。
ライブネス - リクエスト/トランザクションは常に有限時間内に処理されます

文章非同期ネットワーク真ん中真ん中一貫性と稼働性を常に確保することは非常に困難な作業です

, そのため、コンセンサス設計は通常、ある特定のケースで 1 つのポイントを保証し、別のポイントを放棄することを選択します。たとえば、ビットコインで使用されているナカモトコンセンサスは、ライブ性の確保を優先することを選択しますが、BFT コンセンサスは一貫性の確保を優先します。

特徴は次のとおりです。スループット
- システムが単位時間あたりに処理できるリクエストの数レイテンシ- 開始から完了までのリクエスト/トランザクション/確かに

所要時間

スループットとレイテンシに影響を与える要因は数多くあります。たとえば、コンセンサスノードの数、コンセンサスメッセージの複雑さ、メッセージ検証に必要な時間、コンセンサスに利用可能な帯域幅、コンセンサス設計の傾向などです。一般に、コンセンサスメッセージの複雑さには下限があるため、スループットとレイテンシの両方を実現することは困難です。コンセンサスの各ラウンドで、コンセンサスに参加しているノードは少なくとも 1 回メッセージを受信する必要があります (そうでない場合、コンセンサスは何ですか)。 ?全く分かりません）。待ち時間を短くしたい場合は、各リクエスト/トランザクションにできるだけ早く同意する必要があります。つまり、単一のリクエスト/トランザクションにはより高度なメッセージの複雑さが必要になります。高いスループットが必要な場合は、リクエスト/トランザクションを可能な限りバッチ処理する必要があります。これにより、単一のリクエスト/トランザクションのメッセージの複雑さは軽減されますが、待ち時間が長くなります。コンセンサスのパフォーマンスについては、Nervos 研究チームの Zhang Ren が提案した、より有益な指標が次のとおりです。: 同じ帯域幅の場合、コンセンサスが占有する帯域幅が低いほど、コンセンサスのスループットは高くなります。

最初のレベルのタイトル

ブロックチェーンコンセンサスの特徴

動的参加者のセットパーミッションレスかどうか（「許可は必要ありません」と訳すと複雑すぎますが、「パブリックチェーン」の使用はあまり正確ではありません

、ここではまだ言葉を使用しています）または許可型ブロックチェーンの最も重要な特徴は、それが長期にわたって実行されているオープンシステムであることです。長期的な運用とオープンな重ね合わせの結果、コンセンサスへの参加者は常に変化します。時々、常に古いコンセンサスノードが離脱し、新しいコンセンサスノードが参加します。コンセンサス参加者は動的なセットです。コンセンサス参加者の動的な変化にどう対処するかは、ブロックチェーンコンセンサスの中核的な問題です。

ブロックチェーンのコンセンサスとは異なり、従来のコンセンサス研究では、まず固定の参加者を想定し、次にその集合内で合意に達する方法を研究し、場合によっては参加者の集合の変化にどう対処するかを議論することが多く、基本的には何についても気にしません。コンセンサス参加資格が必要です。研究の焦点は、コンセンサスの正しさ（一貫性や有効性など）をどのように保証するかであり、コンセンサスセットを形成する方法は補助的なトピックにすぎません。従来のコンセンサスの適用シナリオは集中管理ネットワークであることが多く、増減するサーバーはすべて独自のものであるため、このような焦点が形成されるのは自然なことです。

多数の参加者

分散化は、パーミッションレスブロックチェーンコンセンサスプロトコルの独自の目標です。私たちは通常、コンセンサスへの参加の閾値によって分散化の度合いを測定します (なぜこれが良い尺度なのでしょうか?)。参加の閾値が低いほど、分散化の度合いは高くなります。参加閾値が低いと当然の結果として、コンセンサス参加者のセットが非常に大きくなる可能性があるため、コンセンサスプロトコルの設計ではこれを考慮して、参加者の増加によってコンセンサス効率が低下しないようにする必要があります。

最小限の信頼モデル

コンセンサスアルゴリズムを実行する目的は、計算リクエストに対して一貫した計算結果を生成することであり、このプロセスでは、リクエストを開始するノードとリクエストを処理するノードが存在する必要があります。従来のコンセンサスモデルでは、一部のコンセンサスアルゴリズムはリクエスト処理ノードのセット内で完全に実行され、一部のコンセンサスアルゴリズムはリクエスト開始ノードと処理ノードによって一緒に実行されます。いずれの場合も、信頼境界は一般にリクエスト開始ノードの間にあります。開始ノードは計算リクエストを実行ノードに送り、実行ノードはその結果を計算して開始ノードに返し、開始ノードは実行ノードの計算結果を信頼します（逆に、実行ノードは必ずしもプロセスを信頼するとは限りません)。

ブロックチェーンのコンセンサスの信頼モデルはまったく異なり、信頼の要件ははるかに小さいことがよくあります。パーミッションレスブロックチェーンネットワークでは、同じノードがトランザクションを開始し、コンセンサスに参加します。ノードは、他のノードのコンセンサス結果を単に信頼するのではなく、コンセンサス結果を検証する必要があります。ビットコインを例にとると、フルノードがマイニングに参加する場合、それは同時にリクエスト (トランザクション) を開始するノードであると同時に、リクエスト (トランザクション) を処理するノードでもあります。静かなフルノードになりたいだけでマイニングに参加しない場合でも、受信したリクエストの処理結果（ブロック）を自身で検証し、他のコンセンサスノードが提供する結果を信頼しません。このようなフルノードは、多数の計算能力によって選択されたトランザクションの順序に従うことを選択するだけであり、多数の計算能力によって与えられるトランザクションの結果を信じません。これは最小限の信頼モデルです。

SPV/ライトノードは、フルノードよりも強力な信頼モデルを使用し (強力であるということは、信頼についての仮定がより多くなることを意味します)、トランザクションの実行は検証せず、ブロックヘッダーの有効性のみを検証します。ブロックヘッダーの有効性を検証する方法は、ブロックチェーンのコンセンサス設計におけるもう 1 つの中心的な問題です。ブロックヘッダーに付加された非対称署名によってのみ有効性が検証される場合、従来のコンセンサスのリクエスト処理ノードは結果に署名を追加することもできるため、この信頼モデルは基本的に従来のコンセンサスの信頼モデルと同等になります。モデルは次のとおりです。よく知られている長距離攻撃など、一連の動的なアクターを組み合わせると、一連の問題が発生します。 PoWによってブロックヘッダの正当性が検証されれば、このようなトラブルは起こらず、ブロックヘッダの検証効率をさらに向上させるにはどうすればよいかという研究方向が主流となっている。

シンプルな分析フレームワーク

上記の分析に基づいて、さまざまなブロックチェーンコンセンサスを比較するための単純なブロックチェーンコンセンサス分析フレームワークを整理できます。
参加方法* - コンピューティングパワー / 住宅ローントークンの購入 / …
ブロック生成方法* - ブロックの順番生成/PoW ランダム選択/オンチェーン疑似ランダム/VRF ランダム選択/…
コンセンサス方法* - ナカモトコンセンサス / BFT /…
終了方法* - マイニングの停止 / アンステーク / ...
一貫性 - どれだけの悪意のあるノード/計算能力/ステーク/…を許容できるか
ライブネス - どれだけの悪意のあるノード/コンピューティング能力/ステーク/…を許容できるか
レイテンシー - トランザクションが完全に確認されるまでにかかる時間 (覆される確率は x 未満)
帯域幅効率 - コンセンサスによる帯域幅の利用率。高いほど優れています。

ノード数 - コンセンサスノード数の上限が多いか少ないか

[1] 例えば：
99% の確実性[2]検討する
[3] 利己的な採掘通常の計算能力がどれほど小さくても、ブロックを生成する可能性はあります。
[4] https://github.com/tendermint...
[5] https://medium.com/nervosnetw...

ブロックチェーンコンセンサスプロトコルの場合、最初の 4 つのポイント (* 付き) によって基本的に次の特性が決まります。また、このフレームワークを通して、私たちが通常「PoW コンセンサス」または「PoS コンセンサス」と呼んでいるものは非常に曖昧な説明であることも簡単にわかります。PoW/PoS はブロックプロデューサーを選択するための単なる方法であり、特定のコンセンサスプロセスがどのようなものであるかを表現することはできませんのように。トークンをステーキングすることで参加し、PoW を通じてブロックノードを選択し、ナカモトコンセンサスを通じて最長の (重い) チェーンを形成する必要があるプロトコルの設計など、いくつかの非常に混合されたコンセンサスプロトコルを設計することもできます (SakingPoW と完全に組み合わせて名前を付けることもできます)ステーキングホットスポット）、またはPoWを通じて参加する必要があるプロトコルを設計し（コンセンサスに参加するには、ある程度の難易度を満たすPoWを提供する必要があります）、VRFを通じてブロックノードを選択し、BFTを通じてコンセンサスに達します（これをPoWと呼ぶことができます） +VRF/BFT、一目見ただけで心の底からプロフェッショナルだと感じます）。