アルゴランドの帯域幅利用効率はどの程度ですか?カルダノのウロボロスはどうですか？なぜ Solana と NKN はこれほど高い TPS を実現できるのでしょうか?イーサリアムはブロック間隔を 15 秒に短縮しましたが、なぜビットコインのスループットよりもそれほど高くないのでしょうか?

Zhang Ren 博士は、共有の中でこれらの質問に 1 つずつ答えます。以下はレン博士の講演の書き起こしです。

この記事を読むには、読者にブロックチェーンの基本知識が必要です。

• ビットコインコンセンサスプロトコル（すなわち、ナカモトコンセンサス）の基本概念

• イーサリアムコンセンサスプロトコルの基本概念

• オーファンブロック、アンクルブロック、利己的マイニングなどのコンセプト

ビデオリンク:

ビデオリンク:https://v.qq.com/x/page/g0837...

自己紹介をさせてください。私は、Nervos & Cryptape の研究者、Zhang Ren です。現在、ルーヴェン大学の COSIC (コンピュータ セキュリティおよび産業暗号化グループ) の博士課程の学生で、Bart Preneel の指導を受けています。 COSIC に詳しくない場合は、すべての携帯電話で使用されている暗号化標準である AES について聞いたことがあるでしょうか。

もちろん、Bart Preneel に詳しい方なら、彼が RIPEMD 160 のデザイナーであることはご存知でしょう。 RIPEMD 160 は、ビットコイン公開鍵をビットコイン アドレスに変換するときに使用されるハッシュ アルゴリズムです。

Nervos CKB は、さまざまなプログラミング言語およびさまざまなレイヤー 2 プロトコルのスマート コントラクトをサポートできるパブリック チェーンです。 Nervos CKB では、あらゆる資産を使用して取引手数料を支払うことができます。 Nervos CKB のスマート コントラクトの実行と検証は、より優れたプライバシーとパフォーマンスを実現するために分離されています。最後に、ナカモト コンセンサスのバリアントである NC-Max が、より高いスループットを備えたコンセンサス プロトコルとして Nervos CKB に採用されています。

免責事項: この共有コンテンツはレイヤー 1 コンセンサス プロトコルの分析のみに焦点を当てており、ライトニング ネットワークなどのレイヤー 2 ソリューションについては説明しません。

副題

なぜビットコインのNCが好きなのでしょうか?

まず質問に答えましょう。なぜ私たちはビットコインのナカモト・コンセンサス（NC）が好きなのでしょうか?

理由はたくさんありますが、まず第一に、NC のパフォーマンスの最適化は非常に優れており、すべての送信とすべての計算サイクルのすべてのバイトを節約できます。たとえば、Compact Block を使用してブロックの伝播を高速化し、将来的には Minisketch (分散システム内の異なるノード間で情報を同期するときに帯域幅要件を削減するために使用されるソフトウェア ライブラリ) を使用してトランザクション ブロードキャスト帯域幅リソースを節約する可能性があります。同時に、ビットコインの開発者らはグラフトルート（ビットコイン上のスマートコントラクトとプライバシーの開発に関する提案）を提案しており、ビットコイン上のスマートコントラクトのパフォーマンスを圧縮することで、より優れたプライバシーとより優れたセキュリティを獲得できると考えることができます。おそらく、署名集約がビットコインにも適用される可能性があります。

知識ポイント: Bitcoin Improvement Protocol (BIP) 152 で提案されているコンパクト ブロック リレーは、P2P ネットワーク ノードがブロックをブロードキャストするために必要な帯域幅の量を削減できます。
コンパクト ブロックは、次の 3 つの情報部分を含む完全なブロックの「概要」です。
1. 新しいブロックのブロックヘッダー
2. トランザクションID
3. 送信ノードによって予測されたが、受信ノードでは利用できない完全なトランザクション
受信側は、受信した情報とメモリプール内のトランザクションに基づいてブロック全体の再構築を試みます。一部のトランザクションがまだ不足している場合は、ブロードキャスト ノードを要求します。

NC が好まれるもう 1 つの理由は、その多用途性です。 UTXO モデルとグローバル トランザクション順序は、さまざまなシャーディング テクノロジとレイヤー 2 スキーム、および複雑なスマート コントラクトをサポートできます。

比較すると、イーサリアムのアカウント モデルはシャーディングが難しく、多くの DAG タイプのプロトコルなど、グローバルなトランザクション順序がない場合、複雑なスマート コントラクトをサポートすることが困難です。後で DAG について話すときに。

また、ビットコイン NC のセキュリティも気に入っています。ビットコインネットワークは多くの攻撃を受けてきましたが、10年間安定して稼働しています。そして厳密に言えば、現時点では NC 全体を超える既知のproof-of-workコンセンサスメカニズムは存在しません。このトピックに興味がある場合は、こちらをご覧くださいここ。

副題

NC ではどこを変更する必要がありますか?

上記の調査で述べたように、ネットワークに接続されているビットコイン IPv4 ノードの帯域幅の中央値は、2016 年には 33Mbit/s、2017 年 2 月には 56Mbit/s でした。

簡単に考えられる改善方法は、プロトコル自体が帯域幅レベルの変化に適応してスループットを動的に調整できるかどうかです。

Bitcoin Unlimited は、Bitcoin のスループットを動的に調整するという不適切な試みを行いましたが、失敗し、プロトコルを安全でないものにするために複数の新しい攻撃ベクトルを導入しました。上記は Coindesk で公開された Bitcoin Unlimited の安全性に関する調査です (リンク:https://www.coindesk.com/etf-...）、私もこの研究の参加者の一人でした。

私たちが NC で変えたいもう 1 つのことは、そのインセンティブの問題、つまり利己的なマイニング攻撃の問題です。利己的なマイニング攻撃者は、ネットワーク内でより大きなリードを獲得することを期待して、発見されたブロックを保留します。他の誠実なマイナーがブロックを発見すると、攻撃者は保留されたブロックをネットワークにブロードキャストし、ブロードキャストされた保留されたブロックが正直なブロックよりも先に最も誠実なマイナーに受信されることを期待します。攻撃者が幸運にも、攻撃者のブロックの上で次のブロックがマイニングされた場合、正直なブロックは孤立します。攻撃者が幸運にも連続して複数のブロックをマイニングできた場合、攻撃者はより長いチェーンを持つため、正直なマイナーのブロックを無効にすることが非常に安全になります。

なぜ利己的なマイニングが儲かるのか?利己的なマイニング攻撃者がネットワーク全体の計算能力の 30% を所有し、誠実なマイナーが残りの 70% を制御していると仮定して、具体的な例を見てみましょう。利己的なマイニング攻撃がない場合、攻撃者は 10 ブロックのうち 3 つを見つけることができ、誠実なマイナーは 7 つを見つけることができ、全員が当然の報酬を得ることができます。攻撃者が利己的なマイニング攻撃を開始した場合、攻撃者は 3 つのブロックを見つけることができますが、正直なマイナーは 4 つのブロックしか見つけることができません。これは、他の 3 人の正直なマイナーが見つけたブロックが前述の攻撃方法によって孤立ブロックになっているためです。生成できたブロックはわずか 7 ブロックになり、メイン チェーンの成長速度が鈍化しました。

副題

その他の代替コンセンサスプロトコル

では、なぜ他の代替コンセンサスプロトコルを選択しないのでしょうか?

現在、NC を置き換える方法は 3 つあり、PoS (Proof of Stake、権利と利益の証明)、DAG、および 2 種類のブロックのコンセンサス プロトコルです。これら 3 つの方法は相互に排他的ではなく、そのうち 2 ～ 3 つを同時に適用できることに注意してください。以下では、これらのプロトコルのセキュリティ、機能、およびスループットをさらに分析します。

1 つ目は PoS であり、事実上すべての PoS プロトコルには新しいセキュリティ前提が導入されています。アルゴランドを例に挙げると、最も誠実なユーザーが送信したメッセージは、既知の時間範囲内で他のほとんどの誠実なユーザーが受信できることが必要です。これは、プロトコルの元の設計によれば、アルゴランド トークンを保持している場合、メッセージを受信するには常にオンラインに留まる必要があることを意味します。オンラインでない場合は、資格のあるトークン所有者ではありません。

Cardano のコンセンサス プロトコルである Ouroboros は、すべてのユーザーが弱く同期された時計を持っており、すべてのメッセージが特定の時間間隔内に配信できることを前提としています。これは実際には非常に強力な仮定を立てています。マイニング装置、パブリック ノード、または携帯電話の時計を狂わせる可能性のある攻撃が数多くあります。そして、このソリューションを実際の環境に実装するのは非常に困難です。

さらに、Sleepy Protocol では、ユーザーが時計をほぼ同期していることも要求されます。

これらのセキュリティの前提条件が違反されると、PoS プロトコルに悲惨な結果が生じる可能性があります。また、PoS プロトコルでは、Nothing-at-stake Attack、Grinding Attack、Long-range Attack などのいくつかの新しい攻撃方法が導入されていますが、これらの攻撃方法は PoW プロトコルには存在しないため、ここではこれらの攻撃方法について詳しく説明しません。

では、DAG プロトコルはどうなのでしょうか?

すべての DAG プロトコルにはトランザクションの順序付けの問題があります。DAG プロトコルのようにブロックが同期的に生成される場合、異なるマイナーまたは異なるパブリック ノードがトランザクションの順序に関して一貫性のない判断を行うことになります: 一部のトランザクションは確認されたと思いますが、その他のトランザクションは人間が別のものを考慮する可能性があります確認する一連のトランザクション。このとき、問題を解決するには 2 つの考え方があります。

1つは、ブロックチェーンのトポロジカルなソートが完了した後にトランザクションをソートすることです。これは、トランザクションの確認に長時間待つ必要があることを意味します。

もう一つは、取引の順序を確認しないことです。コントラクトの入力にはグローバルなトランザクション シーケンスが必要です。異なるマイナーによって判断されたトランザクション シーケンスが異なる場合、特に複雑なコントラクトの場合、各マイナーはコントラクト ロジックの実行シーケンスについて異なる理解を持つことになります。これにより、コントラクトの機能が制限され、複雑なコントラクトを実行できなくなり、コントラクトに含まれるトークンがコントラクトに固定されます。

2 つのブロック タイプを持つプロトコルについてはどうすればよいでしょうか?ツーブロック型プロトコルは、その名のとおり、トランザクション確認の安全性を確保するためにNCのブロックと同じキーブロック(Key Block)を使用し、2つのキーブロック(Micro Block)間でマイクロブロックをブロードキャストします。スループットを向上させるため。

これらのプロトコルは通常、DAG プロトコルと同様に長い確認遅延を伴います。ビットコインNGは上記の仕組みを採用しています。ビットコイン NG の論文には、ユーザーがトランザクションの確認を確実に行う必要がある場合、ビットコイン NG ではいくつかのキーブロックの確認を待ち、トランザクションの長い遅延に耐える必要があると明確に述べられています。

(共有の過程で、Zhang Ren は Byzcoin にも同様の問題があると述べました。しかし、さらなる分析の後、問題は同様ではありません。Byzcoin に興味がある場合は、フォーラムにアクセスしてください。https://talk.nervos.org/t/ner...副題

TPS を主張しますか?

これらの代替コンセンサス プロトコルを採用しているプロジェクトはすべて、スループットが高いと主張しています。では、これらのプロジェクトのスループットはどのくらいなのでしょうか? (次のセクションはビデオを見ることをお勧めします。約 15:30 のシーンは非常にエキサイティングです)

Solana は、1 秒あたり 710,000 件のトランザクションを処理できると主張しています。これほど大きな進歩を遂げることができれば、チューリング賞を受賞するに値します。彼らの受賞について聞くのが待ちきれません。

NKN と呼ばれるこのプロトコルもあります。彼らは、ネットワーク全体に 10,000 のノードを持ちながら、1 秒あたり 100 万のトランザクションを処理できると主張しています。彼らがどうやってそれを実現しているのかはまだわかりませんが、私は彼らがそれを達成する方法に非常に感銘を受けています。好奇心旺盛。

また、Stellar と Ripple がプロトコルを NC に分類している理由にも興味があり、10,000 のノードが 1 秒あたり 100 万のトランザクションをどのように処理できるのかにも非常に興味があります。

そして、夢を持つなら、今回の取引のような大きな夢を持ったほうが良いでしょう。最終確認時間は 1 秒未満で、10000000000000TPS を実現できると主張しています。

まあ、地球は彼らにとって十分な大きさではないと本当に思います。彼らはプロトコルを展開するために別のより大きなOdailyを見つける必要があります。

自称TPSとは比較にならないことに注意してください。これらは異なるネットワーク環境でシミュレーションされるため、一部のシミュレーションでは 1Gbit/s の帯域幅が使用されることもありますが、これは明らかに実際のネットワーク状況からかけ離れています。

そして、これらの合意は現実の状況を無視しています。いずれもトランザクションの同期を可能にしません。彼らにとって、すべてのトランザクションはブロック内ですでに同期されており、コンセンサス プロトコルはトランザクションを並べ替えるためにのみ使用されているようです。また、一部のシミュレーションでは、委員会メンバー (ノード) 間に直接接続があると仮定していますが、実際には、パブリック チェーン ネットワーク内のすべてのメッセージはブロードキャストによって実行され、ブロードキャスト メッセージはパブリック ノードの帯域幅を占有します。

副題

スループットを比較するための単純なモデル

ここに TPS を評価するためのモデルがあります。図に示すように、まず、すべてのパブリック ノードの帯域幅には上限があり、最大でも 100% の帯域幅を使用でき、100% を超える帯域幅を使用することはできないと考えられます。ここでの帯域幅使用量には 3 つの要素があります。

上の図に示すように、最初の部分は同期最終確認に使用されるトランザクションによって占有される帯域幅の割合であり、この部分が実際の TPS です (これが実際の TPS です)。トランザクションを確認するには、まずトランザクションを同期する必要があります。 2 番目の部分は、コンセンサス プロトコルによって「無駄にされる」帯域幅の部分です。 3 番目の部分は未使用の帯域幅です。

したがって、TPS を向上させたい場合、できることは 2 つだけです。

1. コンセンサスプロトコルが占める帯域幅の割合を減らす
2. 未使用の帯域幅の割合を減らす

実行できることはこの 2 つだけです。はい、他に方法はありません。レイヤー 1 のプロトコル帯域幅占有率は 100% を超えることはできません。

次に、他の代替コンセンサス プロトコルの帯域幅使用量を見てみましょう。

実際、多くのプロトコルは委員会メンバー間の通信で貴重な帯域幅リソースを無駄にしています。

アルゴランドは、ブロックがコミットされたことを新しいユーザーに証明するためにブロック証明書を保管します。各ブロック証明書のサイズは、ブロック サイズ制限に関係なく 300 KB です。 1MB のブロック サイズで計算すると、帯域幅の約 25% がこれらの証明書の同期に常に使用されることになります。したがって、なぜ彼らが NC よりもスループットが優れていると主張するのか非常に興味がありますが、これはまったく意味がありません。

コンセンサス プロトコルで帯域幅を無駄にするもう 1 つの方法は、ブロック DAG および孤立ブロックでの冗長トランザクションです。上記の論文で述べたように、すべてのノードがブロックに同じサブトランザクションのセットを含めることを選択した場合、並行して作成された 2 つのブロックが競合する可能性があり、スループットはあまり高くありません。

副題

サトシ・ナカモトのコンセンサスがもたらすジレンマをどう打破するか?

上記の分析から、現在のスループットでは満足できないことは明らかであるため、Nervos CKB のコンセンサス プロトコル NC-Max は NC にいくつかの改良を加えました。

NC-Max には 3 つの主要な革新があります

2 段階のトランザクション確認を使用して孤立ブロック率を削減する
ブロック間隔とブロック報酬を動的に調整して、帯域幅の使用率を向上させます。
利己的なマイニング攻撃に抵抗するために難易度を調整するときは、サイクル内のすべてのブロックを考慮してください。

次に詳しく説明していきます。

NC のスループットを向上させるためにできることは次の 2 つだけであるため、NC には自然なスループット制限があります。

まず重要なのは、Bitcoin Unlimited や Bitcoin Cash などのより大きなブロックであり、他の多くのプロジェクトも同様です。

2 つ目は、ブロック間隔を短くすることです。

ただし、ブロックブロードキャストには時間がかかるため、ブロードキャスト中に他のノードがブロックを発見してブロードキャストすると、ブロードキャスト中のブロックと競合し、そのうちの1つが孤立ブロックになってしまいます。ブロックが大きいほどブロードキャストに時間がかかり、ブロック間隔を短縮すると実際にブロック生成の難易度が低下し、ノードがブロックを発見しやすくなります。これら 2 つの方式の結果、孤立ブロック率が高くなります。これらの孤立ブロックはより多くの帯域幅を消費しますが、トランザクションの確認には寄与しません。オーファンブロック率が増加すると、システムのセキュリティが低下し、スループットが低下します。したがって、これら 2 つの方式は最終的にはバランスが取れ、ブロック サイズやブロック間隔をある程度調整すると、オーファン ブロック率がある程度高くなります。 、スループットも改善されません。

孤立ブロックが多すぎると、ネットワークのセキュリティとパフォーマンスに悪影響を及ぼすのはなぜですか?上の図では、孤立ブロック率が非常に高い場合、攻撃者はプライベートでより長いチェーンを簡単に構築できることがわかります。攻撃者がブロックチェーンを上書きするには、ネットワーク全体のコンピューティング能力の 51% よりはるかに低いコンピューティング能力だけが必要です。また、孤立ブロックはパブリック ノードの帯域幅を大量に消費するため、システム全体のスループットに大きな悪影響を及ぼします。

では、どのようにして NC スループットの制限を打破するのでしょうか?上記の分析の後、この制限を破りたい場合は、孤立ブロック率を下げる必要があります。孤立ブロック率が低下すると、ネットワークのセキュリティとスループットの両方が向上します。

孤立ブロック率を減らすにはどうすればよいですか?孤立ブロックの出現は、ブロック ブロードキャストの遅延によって発生し、ブロックのブロードキャスト中に別のブロックが発見された場合、いずれかのブロックは孤立ブロックになることになります。ブロックブロードキャストが瞬時に完了できれば、当然孤立ブロックは発生しません。では、ブロックが十分な速度でブロードキャストされることを保証するにはどうすればよいでしょうか?

ビットコイン開発者は、ブロックのブロードキャスト速度を高速化するために多大なリソースとエネルギーを投資してきましたが、どのブロックがブロードキャストに遅いか、または問題があるかをさらに調査する必要があります。

これがどのように起こるかを詳しく見てみましょう。下の画像を参照してください。

現在のビットコイン ネットワークでは、すべてがうまくいけば、ブロックはコンパクト ブロック リレー プロトコルを通じてブロードキャストされます。

コンパクト ブロックでは、トランザクション全体 (ビットコインのトランザクションあたり約 250 バイト) はブロードキャストされませんが、コンパクト ブロック内のトランザクション ID はブロードキャストされます。これらのトランザクション ID は、実際のブロックよりもはるかに小さいコンパクト ブロックを形成するため、速度が大幅に速くなります。

ノード A がコンパクト ブロックをノード B にブロードキャストすると、ノード B はこれらのトランザクション ID をチェックします。これらのトランザクションがノード B のフレッシュ トランザクションでない場合 (つまり、ノード B のトランザクション プールにこれらのトランザクションが含まれている場合)、ノード B はこれらのトランザクションをすぐに転送できます。コンパクト ブロック: 隣接するノードへのブロック、この状況は非常に良好で、プロセスは非常にスムーズです。

ただし、コンパクト ブロックにフレッシュ トランザクションがある場合、ノード B はまずノード A からのフレッシュ トランザクションを同期し、次にこれらのトランザクションの署名を検証する必要があり、これらの手順は非常に時間がかかります。ノード B は、ブロック全体が正しいことが検証された後にのみ、ブロックのブロードキャストを続行できます。このプロセスにより、受信したブロックが不正であることが防止されるため、マイナーはこのブロックの後にマイニングおよびブロードキャストを行うようになります。検証されずに不正なブロックであることが判明した場合、この不正なブロック以降のブロックは無効になります。フレッシュ トランザクションの同期プロセスが、ビットコイン ブロック ブロードキャストの遅延の主な理由です。

したがって、イーサリアムは失敗した試みでしたが、どのようにしてそれができたのかを分析してみましょう。イーサリアムは単純にブロック間隔を短くするだけですが、ブロックを受け取る前にトランザクションの正当性を検証できないという問題があります。イーサリアムのトランザクションの有効性はブロック内のトランザクションの順序に依存するため、トランザクションの有効性を検証したい場合は、ブロック全体が受信されるまで待つ必要があるため、各ブロックは実際にはすべて新鮮です取引。

そして、イーサリアムのネットワークプロトコルはメンテナンスが非常に不十分であり、2015年以来更新されていません。

また、トランザクション ブロードキャスト プロセスにも多くの冗長性があります。 Ethereum クライアントは、同じトランザクションを異なるノードに 7 回ブロードキャストします。これは、各ノードが同じトランザクションを 7 回受信することを意味します。 (イーサリアムには、パリティ イーサリアム、ゲスなど、さまざまなクライアントがあります。) また、さまざまな種類のクライアント間には不一致があり、2 つの主要なイーサリアム クライアントは基本的に独立しています。

したがって、2 つの異なるネットワークをリンクできるノードは非常に少ないため、イーサリアムの孤立ブロック率は 30% にも達することがあり、トランザクションのスループットは非常に低くなります。

そして、大手マイナーにはブロックブロードキャストを高速化するインセンティブがありません。私のブロックをよりゆっくりとブロードキャストできれば、それは実際に「利己的マイニング」を達成できることを意味するからです（ここでは、大手マイナーはブロックを保留しませんが、ブロックブロードキャストは遅くなり、他のマイナーがプロセスに現れます。競合するブロック、そして私は大規模なマイナーであるため、他の競合ブロックと競合する過程で勝つ可能性が高くなります。）これは私にとっては良いことですが、なぜブロック ブロードキャストを高速化する必要があるのでしょうか?

イーサリアムのアンクルブロック報酬も役に立ちません。マイナーは依然として孤立したブロックに対して報酬を得るからです。したがって、小規模マイナーは、ブロック ヘッダーをブロードキャストする速度がはるかに高速になるため、ブロック ヘッダーと空のブロックを最初にブロードキャストする方法を採用します。また、次のブロックにどのトランザクションが含まれるかわからないため、マイナーは通常、空のブロックをマイニングして、前のブロック トランザクションと競合するトランザクションがブロックに含まれていないことを確認します。空のブロックはトランザクションの確認に寄与しないため、これは非常に悪いことです。

以下は、上記の問題のいくつかを軽減するための設計です。

この図はブロック構造です。ビットコインのブロック構造に基づいていくつかのフィールドを追加しました。

上の図は、完全なブロックのブロック構造です。まず、取引提案エリア (ティールエリア) があります。トランザクション提案領域のみがフレッシュ トランザクションを含めることができますが、従来のトランザクション確認領域 (オレンジ色の領域) には、前の数ブロックのトランザクション提案領域内のトランザクションのみを含めることができます。現在のブロックの高さが h の場合、それは hm です。 hn は、トランザクション提案領域内のトランザクションをブロックします。トランザクション確認エリアではこれらのトランザクションのみ確認可能であり、フレッシュトランザクションは確認できません。トランザクション提案領域には完全なトランザクションは含まれず、トランザクション ID (Truncated Transaction ID) のみが含まれるため、トランザクション提案領域は非常に小さくなります。

アンクル ブロック (紫色の領域) はいくつでもアンクル ブロック ヘッダー領域に含めることができ、アンクル ブロックにはブロック ヘッダーとトランザクション提案領域を含める必要があります。アンクルブロックのヘッダー領域はブロックサイズにカウントされないため、ブロックサイズによる制限を受けず、マイナーがアンクルブロックの追加を制限されることはありません。

取引提案領域についてさらに説明させていただきます。この領域にはトランザクション ID のみが含まれるため、非常に小さいです。これは並列プロセスであるため、完全なトランザクションはブロックと同期してブロードキャストされ、トランザクションのブロードキャストはブロックのブロードキャストには影響しません。また、ノードはブロードキャストされたトランザクションを受信した後にハッシュを検証するだけで済み、ブロックの検証プロセスには影響しません。

これは、トランザクション提案領域に無効なトランザクション、二重支払いトランザクション、マイナーが受け入れられないトランザクションが存在する可能性があることを意味しますが、それは問題ではありません。

上で説明したビットコイン ブロックのブロードキャスト プロセスと同様に、私たちのプロトコルでは、ブロックを発見したノードが最初にコンパクト ブロック (つまり、ブロック ヘッダーとトランザクションの ID) をブロードキャストします。コンパクト ブロックはビットコインよりわずかに大きく、複数のアンクルブロックのトランザクション提案領域とブロックヘッダー、およびアンクルブロックのトランザクション提案領域を含みます。ただし、コンパクト ブロック自体は十分に小さいため、通常はすぐに隣接ノードにブロードキャストされます。

新しく提案されたトランザクションの一部がノードのトランザクション プールにない場合、それらはコンパクト ブロックの発行後にブロードキャストされます。これらは並列プロセスであり、相互に影響しません。ノードはトランザクションを受信し、ハッシュ検証後に隣接ノードにブロードキャストします。

これには当然、いくつかの疑問が生じます。

マイナーが提案されたトランザクションの完全版の提供を拒否した場合はどうなるでしょうか?
私はこの取引を取引提案セクションに記載しましたが、取引の全文を尋ねられたとき、私は知らないふりをしました。

実際、トランザクション提案領域にフレッシュ トランザクションがあるかどうかに関係なくブロックはブロードキャストできるため、これはブロック ブロードキャストには影響しません。

そして、確認すべき十分な提案されたトランザクションが常に存在するため、他のマイナーはマイニングを続けるでしょう。前のブロックのトランザクション提案領域にはパッケージ化されるトランザクション ID が含まれており、発見されたブロックはパッケージ化されたトランザクション確認領域にトランザクション ID をブロードキャストするため、マイナーがブロックを掘り出す必要はありません。コンパクトブロック. マイナーはどのトランザクションがパッケージ化され、どのトランザクションがパッケージ化されていないのかを知っており、発見されたブロックのトランザクション確認領域と競合するトランザクションを選択しません. したがって、マイナーはブロックを生成して手数料を得るためにトランザクションのパッケージ化を続行することを選択します取引の確認に貢献するため。

それでは、マイナーが、ある種の利己的なマイニング上の利点を得るために、これらの提案されているがブロードキャストされていないトランザクションを最新のブロックに含めたらどうなるでしょうか?

ビットコインの NC では、マイナーはブロック ブロードキャストを遅くすることでマイニングの優位性を獲得します。マイナーは通常、ブロックをマイニングするときにブロック ヘッダーのみをブロードキャストでき、ブロック全体をブロードキャストするときは速度が低下します。このプロセスでは、マイナーのみがマイニングできます (次のブロックの情報を知っているのはマイナーだけであり、この新しいブロックに基づいてマイニングできるため、このプロセスはブロックを保留するのと似ています)。

しかし、私たちのプロトコルでは、この方法を採用しても、n ブロック後のブロック ブロードキャスト速度が遅くなるだけです。なぜなら、提案されたもののブロードキャストされていないトランザクションは利己的なマイナーだけが知っており、利己的なマイナーだけがそれを有利に利用できるからです。ただし、これを次のブロックで使用することはできません。これは、私たちのプロトコルでは、プロポーザルエリアにトランザクションが含まれる前にマイニングできるのは n ブロックのみであり、間に間隔が必要であるためです。

マイナーは hm から hn ブロック内のプロポーザル トランザクションのみをマイニングできますが、このブロックも攻撃者によってマイニングされない限り、前のブロック内のプロポーザル トランザクションをマイニングすることはできません。

示されているように、これはコンセンサス プロトコルとビットコイン NC の比較です。ビットコイン NC では、利己的なマイナーがブロック h を見つけると、すぐにブロック h+1 のマイニングを開始できますが、他のマイナーはブロックに含まれる完全なトランザクションを知る必要があるため、正直なマイナーは完全なブロック h を受け取った後にのみマイニングを開始できます。ブロックが合法であるかどうかを検証するために検証され、利己的なマイナーはブロック h の送信速度を遅くして、後で他のマイナーがブロックを受信できるようにすることができます。ブロックブロードキャスト期間中は利己的なマイナーにとって有利な期間です。

ただし、私たちのプロトコルでは、利己的なマイナーがブロック h を見つけて、ブロック ヘッダーとトランザクション ID を含むコンパクト ブロックをブロードキャストすると、正直なマイナーはすぐに h+1 のマイニングを開始できます。利己的なマイナーがこれらの提案されたがブロードキャストされていないトランザクションを利用したい場合、これを利用できるように、これらの提案されたがブロードキャストされていないトランザクションを含むブロックを n ブロック後に見つけなければなりません。ただし、これは起こりにくく、n ブロック後のブロックが自分によってマイニングされたかどうかはわかりません。これを予測するのは非常に困難です。

帯域幅をより有効に活用するために、私たちのプロトコルは別の難易度調整メカニズムを使用し、固定のオーファン ブロック レート (前回の難易度調整期間のアンクル ブロックの数に基づいて計算) を設定します。

孤立ブロック率が前回の難易度調整サイクルで設定された孤立ブロック率よりも低い場合、マイニングの難易度が低下し、ブロック間隔が短縮され、スループットが向上します。とはいえ、孤立ブロックが少ないということは、ネットワークの現在の状態が実際にトランザクションをより高速に同期する機能を備えていることを意味し、ネットワークの分散化を損なうことなくスループットを向上させることができます。

逆に、難易度が高くなるとブロック間隔が長くなり、スループットが低下します。孤立ブロック率が高い場合、現在のネットワークではこの難易度調整期間中にそれほど多くのトランザクションを処理できず、プロトコルのスループットが低下することを意味します。

同時に、ブロック報酬は 1/(予想ブロック間隔) に比例するため、各難易度調整サイクルでの予想合計ブロック報酬は固定されます。

これは、10 分ごとにブロックを生成すると仮定すると、各ブロックに 12.5 ビットコインが存在し、難易度調整が 5 分ごとにブロックに変更される場合、各ブロックには 6.125 ビットコインが存在することを意味します。したがって、通貨発行率も一定に保たれます。

最後に、利己的なマイニング攻撃に抵抗してください。先ほど、私たちのプロトコルと NC の違いは、難易度調整メカニズムが難易度調整間隔に出現するすべてのブロックに基づいて計算され、総計算能力を見積もるときにアンクル ブロックも含まれることであると述べました。

NC-Max では、攻撃者が総計算能力の 30%、誠実なマイナーが 70% を占めると仮定しており、利己的なマイニング攻撃がない場合、攻撃者は 10 ブロック中 3 ブロックを見つけることができ、誠実なマイナーは7つのブロックを見つけることができます。利己的なマイニングが実行されると、攻撃者は 7 つのブロックのうち 3 つのブロックを見つけることができ、正直なマイナーは 4 つのブロックを見つけ、3 つの正直なブロックは孤立ブロックとなり、メインチェーンはゆっくりと成長します。

前述したように、最初の難易度調整サイクルでは利己的なマイニングにメリットはありませんが、2回目の難易度調整サイクルではどうなるでしょうか？

次の難易度調整サイクルでは、難易度は変更されず (孤立したブロックを含むすべてのブロックに基づいて難易度が計算されるため)、攻撃者は同じ計算能力を使用してより多くのブロックを見つけることができないため、利己的なマイニングはもはや利益を生みません。写真。

つまり、通貨価格が短期間で安定していると仮定し、利己的なマイニング攻撃者は近視眼的であるため、その報酬は単位時間当たりに得られる報酬に応じて定義され、これは同じ電力に相当する可能性があります。消費や賞品ビットコインでは、利己的なマイニング攻撃者は、チェーンの成長率を低下させることでブロック生成の難易度を下げるようプロトコルを「強制」し、難易度調整後に単位時間当たりにより多くの報酬を得ることができます。 NC-Max プロトコルの設計では、ブロック生成の難易度は、孤立ブロックを含むすべてのブロックに基づいて計算されます。攻撃者は、正直なマイナーのブロックを孤立ブロックにしますが、プロトコルに「強制」してブロックを減らすことはできません。ブロック生成の難易度が高く、単位時間当たりの報酬が高くなります。

最後に要約すると、私たちのプロトコルは孤立ブロックを有効に活用します。

2 段階のトランザクション検証を通じて孤立したブロックの数を削減したいと考えており、孤立したブロックの数が減少した後は、孤立したブロックの割合を帯域幅使用率の指標として使用し、スループットを動的に調整します。

そして、オーファンブロックの情報はブロックチェーンに書き込まれており、この情報をマイニング難易度調整アルゴリズムに使用して、利己的なマイニングを不採算にします。

NC-Max は、Nervos CKB の PoW コンセンサス プロトコルです。 NCとは、ビットコインのコンセンサスプロトコルであるnakamoto Consensusの略称です。この記事を読んだ後、このコンセンサスプロトコルにはもっと良い名前を付ける必要があると思われる場合は、お知らせください。

推奨読書: Zhang Ren 博士のコンセンサス安全性分析記事「共通基準の開発: PoW コンセンサスプロトコルのセキュリティの評価」