出典 | vitaik.ca

著者 | ヴィタリック・ブテリン

出典 | vitaik.ca

校正してくれた Dankrad Feist と Aditya Asgaonkar に特別に感謝します。

シャーディングはイーサリアムのスケーラビリティの未来であり、イーサリアム エコシステムが 1 秒あたり数千件のトランザクションを達成できるようにするための鍵であり、これによりほとんどの人がイーサリアムを使用してイーサリアムのユーザーになれるようになります。ただし、シャーディングは、イーサリアム エコシステムだけでなく、より広範なブロックチェーン エコシステムにおいても最も誤解されている概念の 1 つです。これは、独自の特異性を持つ非常に特殊な一連の概念を指しますが、脆弱で異なるセキュリティ特性を持つテクノロジと混同されることがよくあります。この投稿の目的は、シャーディングの特定の特性を紹介し、他の非シャーディング技術と区別し、これらの特性を達成するためにシャーディング システムが何を犠牲にする必要があるかを紹介することです。

画像の説明

凡例: イーサリアム シャーディング システム、元の写真は Hsiao-wei Wang からのもので、Quantstamp によってデザインされました

スケーラブルな不可能な三角形

シャーディングを導入する最良の方法は、解決策につながった問題、つまりスケーラビリティ不可能トライアングルを説明することから始めることです。

スケーラビリティの不可能な三角形によれば、ブロックチェーンは 3 つの特性を達成する必要がありますが、単純な技術的手段を使用した場合、3 つの特性のうち 2 つしか実現できません。 3 つのプロパティは次のとおりです。

➤ 分散化: ブロックチェーンの運用は、集中化された大規模な参加者の小グループから独立して行うことができます。これは、たとえ大部分のノードが誠実であっても、消費者向けのラップトップでアクセスできないノードのグループを信頼すべきではないことを意味すると一般に理解されています。

➤ セキュリティ:

ブロックチェーンは、攻撃を試みる多数のノードに抵抗できます。理想的には、ノードの 50% に抵抗する必要があります。一般に、ノードの 25% 以上に抵抗する必要がありますが、ノードの 5% のみに抵抗するだけでは、セキュリティを保証できません。

以下に 3 つの異なるタイプの「単純なソリューション」を示しますが、これらのソリューションは 3 つのプロパティのうち 2 つだけを実装します。

➤ 従来のブロックチェーンには、ビットコイン、PoS/シャーディング以前のイーサリアム、ライトコイン、およびその他の同様のブロックチェーンが含まれます。これらのブロックチェーンは、フルノードを実行しているすべての参加者に依存してすべてのトランザクションを検証するため、分散化とセキュリティは確保されますが、スケーラビリティは確保されません。

➤ 高 TPS ブロックチェーンには DPoS チェーンが含まれますが、他の多くのブロックチェーンもカバーされます。この種のブロックチェーンは、コンセンサスを維持するために少数のノード (通常は 10 ～ 100) に依存しており、ユーザーは大多数のノードを信頼する必要があります。上で定義したように、このソリューションはスケーラビリティとセキュリティを実現しますが、分散化は実現しません。

➤ マルチチェーン エコシステムは一般に、ブロックチェーンの「外側への拡張」を指します。つまり、さまざまなアプリケーションを異なるチェーンにデプロイし、クロスチェーン通信プロトコルを使用して通信できるようにします。これにより、分散化とスケーラビリティが実現しますが、安全ではありません。攻撃者は、チェーンの 1 つ (通常はエコシステム全体の 1% 未満) のコンセンサス ノードの大部分を制御するだけで損害を引き起こし、連鎖反応を引き起こす可能性があるためです。他のチェーンのアプリケーションに大きな損害を与えます。

フラグメンテーション技術は、上記3つの特徴を同時に実現します。シャード化されたブロックチェーンには次の特徴があります。

➤ スケーラビリティ: 処理するトランザクション量は、単一ノードのトランザクション量よりもはるかに多くなります。

➤ セキュリティ: 攻撃者は、いくつかのリソースを使用してシステムに対して部分的な攻撃を開始することはできず、攻撃のためにシステム全体を制御することのみを試みることができます。

最初のレベルのタイトル

シャードのランダムなサンプリング

シャーディングの最もわかりやすいバージョンは、ランダム サンプリングによるシャーディングです。イーサリアム エコシステムに構築されたシャーディングの形式と比較すると、ランダム サンプリング シャードの信頼性は低くなりますが、イーサリアム シャーディングに適用されるテクノロジーはより単純です。

シャーディングの中心となる考え方を以下で説明します。非常に多数の検証者 (10,000 人の検証者など) と非常に多数の検証対象ブロック (100 ブロックなど) を備えた PoS ブロックチェーンがあるとします。次のブロックのセットが生成されるまで、単一のコンピューターはこれらの 100 ブロックを検証できません。

この問題を解決するには、検証作業をランダムに分散する必要があります。バリデーターのリストをランダムにシャッフルし、最初のブロックを検証するためにリストの最初の 100 個のバリデーターを選択し、2 番目のブロックを検証するために 2 番目の 100 個のバリデーターのセットを選択します。ランダムにサンプリングされたシャードは、この方法でブロックを検証したり、他のタスクを実行したりします。これらのランダムに選択されたバリデーターは委員会と呼ばれます。

検証者はブロックを検証した後、署名を発行してブロックを証明します。他のすべてのノードは、100 個の完全なブロックではなく 10,000 個の署名のみを検証する必要があるため、特に BLS 署名集約テクノロジーを適用した後は、多くの作業負荷が軽減されます。各ブロックのブロードキャストは同じ P2P ネットワークを経由する必要はなく、異なるサブネットを経由する必要があり、ノードは担当するブロックまたは検証したい他のブロックに対応するサブネットに参加するだけで済みます。

各ノードの計算能力が 2 倍に増加した場合に何が起こるかを想像してください。各ノードで安全に検証できる署名の数が 2 倍に増加したため、最低誓約金額を下げることができ、バリデーターの数を 2 倍に増やすことができるため、従来の代わりに 200 の委員会を生成できるようになりました。 100。したがって、スロットあたりのブロック検証の数は 100 ではなく 200 に達する可能性があります。また、各ブロックの容量を2倍に拡張できます。したがって、ブロックチェーン全体の容量は 4 倍に増加します。

その背後にある原理を数学的な用語で説明できます。 Big O の表記法によれば、単一ノードの計算能力を表すために「O(C)」を使用します。 O(C) は、従来のブロックチェーンが処理できるブロック サイズを表します。前述したように、シャード チェーンはサイズ O(C) のブロックを並列処理できます (各ノードは固定数の署名のみを検証する必要があるため、各ノードが各ブロックを検証するために O(1) のオーバーヘッドがあることに注意してください)。したがって、各ブロックの容量は O(C)、シャード チェーンの合計容量は O(C^2) となります。このタイプのシャーディングが二次シャーディングと呼ばれるのはこのためです。二次シャーディングの重要な役割に基づいて、長期的にはシャーディングがブロックチェーンを拡張する最良の方法であると信じています。

1. ランダム サンプリングにより、攻撃者が特定のシャードに計算能力を集中させることを防ぐことができます。 100 のブロックチェーンで構成されるマルチチェーン エコシステムでは、攻撃者は合計プレッジのわずか 0.5% で損害を与えることができます。これは、ブロックチェーンの 1 つに対して 51% の攻撃が開始される可能性があることを意味します。シャード チェーンでは、同じ目的を達成するために、攻撃者は合計ステークの 30 ～ 40% を所有する必要があります。つまり、チェーンのセキュリティはシャード間で共有されます。もちろん、攻撃者は幸運が起こるまで待って、単一シャードの計算能力の 51% を偶然に取得することもできます。プレッジ量は 50% 未満ですが、プレッジ量が 51% をはるかに下回る攻撃者にとっては、攻撃を開始する確率は指数関数的に増加します。賭け金が 30% 未満の場合、攻撃を開始することはほぼ不可能です。

これら 2 つの違いにより、シャーディングでは、マルチチェーン エコシステムでは実現できないシングルチェーン条件の主要なセキュリティ特性を保持するアプリケーション環境が確実に作成されます。

より優れたセキュリティ モデルによるシャーディングの改善

より集中化された高 TPS チェーンの主な弱点は、この追加のセキュリティが欠如していることです。このブロックチェーンには、通常のユーザーがノードを実行する文化がありませんし、持つこともできないため、たとえコミュニティが強く嫌っていても、主要なノードとエコシステムのプレーヤーが結集してプロトコルの変更を強制することが容易になります。さらに悪いことに、デフォルトでは、ユーザーのノードはこの変更を受け入れます。しばらくするとユーザーは気づくでしょうが、その頃には変更は既成事実となっており、変更を拒否するという調整の主な負担はユーザーが負うことになり、ロールアウトするという苦渋の決断をしなければならないことになります。他のユーザーが完了したと考えている 1 日以上の取引記録。

最初のレベルのタイトル

スケーラブルな計算検証

51% 攻撃に耐えられるスケーラブルな検証問題は、次の 2 つのケースに分けることができます。

➤ 計算の検証: 計算を完了するためのすべての入力データがあると仮定して、特定の計算が正しく行われていることを確認します。

➤ データの可用性を検証: 計算自体へのデータ入力が何らかの形式で保存され、必要に応じてダウンロードできるようになっているかをチェックします。このチェックは、データが大きすぎて実行できない可能性があるため、すべての入力データを実際にダウンロードすることなく実行されます。両方がダウンロードされます。

ブロックチェーンのブロック検証には、計算とデータの可用性チェックの両方が含まれます。つまり、ブロック内のトランザクションが有効であり、ブロック内の新しい状態のルート ハッシュがそれらのトランザクションの正しい実行であることを確信する必要がありますが、Make も必要です。データをダウンロードしたユーザーが状態を計算してブロックの処理を続行できるように、ブロック内の十分なデータが実際に公開されていることを確認します。 2 番目の点は、非常に微妙ですが重要な概念、つまりデータの可用性の問題に関するものです。この問題については以下で説明します。

スケーラブルな計算検証は、不正証明と ZK-SNARK の 2 種類の技術を使用して実装するのが比較的簡単です。

不正行為の証明により、スケーラビリティを確保しながら計算を検証できます

以下に、2 種類のテクノロジーについて簡単に紹介します。

➤ 不正証明 (不正証明) は、計算の結果を受け入れるシステムであり、質権保証金を持っている人に次の形式のメッセージに署名するよう依頼できます。「入力 X を使用して C を計算すると、私は出力Yを取得します。あなたはデフォルトでメッセージを信頼しますが、保証金を預けている他の人は、計算結果に異議を唱える機会が与えられます。「同意しません。出力は Y ではなく Z であるべきです。」というメッセージに署名できます。異議を発行した後は、すべてのノードが計算を実行します。これら 2 つの当事者のいずれかが誤りを犯した場合、デポジットは失われ、計算ミスに基づくすべての計算がやり直しとなります。

「通常の場合」では複雑な計算を実行する必要がなく、単一の署名を検証するだけで済むため、不正証明に基づく計算はスケールが大きくなります。チャレンジ後にオンチェーンで計算を検証する必要がある特殊なケースがありますが、元のクレーマーまたはチャレンジャーのいずれかがデポジットの多額を失うため、これをトリガーするのは非常にコストがかかるため、特殊なケースはまれです。 ZK-SNARK は概念的には単純で、検証のために計算を安価な証明に置き換えるだけですが、その背後にある数学ははるかに複雑です。

最初のレベルのタイトル

データ可用性のスケーラビリティ検証はより困難

不正行為の証拠を使用してデータの可用性を確認することはできません。オペレーションの不正証明は、元のステートメントが送信されると、オペレーションの入力データがオンチェーンで公開されるという条件に基づいています。そのため、誰かがチャレンジを開始した場合、チャレンジの実行は、最初のステートメントとまったく同じになります。元の実行の「環境」。データの可用性チェックの場合、チェーン上に公開する場合、チェックする必要があるデータの量が多すぎるため、上記の操作は実装できません。したがって、データの可用性に関しては、不正防止スキームをどのように生成するかが重要な問題となっており、誰かが「データ X は利用可能である」と主張しても、それをチェーン上に公開せず、挑戦者が現れるのを待ってからデータを公開することができます。チャレンジを開始した後にネットワーク全体に送信し、ネットワーク内の他の参加者にチャレンジ者が間違っていると思わせる

以下の図の「漁師のジレンマ」は、その理由をよく説明しています。

どちらが正しいのかを見分けることは不可能であるため、データの可用性に関して効果的な不正防止ソリューションを生成することも不可能です。

「一部のデータが利用できない場合はどうなりますか? ZK-SNARK はすべての有効性を保証できますが、それだけでは十分ではありませんか?」とよく尋ねられます。

この問題は根本的なものであり、適切な解決策 (暗号アキュムレータの使用など) がないという強力な情報理論上の議論がいくつかあります。詳細については、この記事を参照してください。

では、ダウンロードせずに 1 MB のデータが利用可能かどうかを確認するにはどうすればよいでしょうか?それは不可能に思えます!

1. Erasure Code ツールを使用すると、N セグメントのデータが 2N セグメントのデータに分割されるため、任意の N データ セグメントだけでデータ全体を復元できます。

2. ユーザーが可用性を確認したい場合、すべてのデータをダウンロードするのではなく、ブロック内の位置 (30 などの定数) をランダムに選択し、選択した位置内のすべてのデータが見つかった場合にのみブロックを受け入れます。ブロック内。

ZK-SNARK 証明を通じて、データ消去コードの正確性も検証でき、マークル ツリーの分岐を使用して各データ ブロックが検証されます。検証するもう 1 つの方法は、Kate コミットメント (KZG コミットメント) などの多項式コミットメントを使用することであり、基本的に、コミットメントは各要素を証明する単純なコンポーネントと、映画で使用されているイーサリアム技術の正当性検証を通じて消去符号化されます。

要約: すべてのデータの正確性を確認するにはどうすればよいですか?

100 個のブロックがあり、すべてのブロックの正確性を効率的に検証するために委員会に依存したくないとします。この目標を達成するには、次の措置を実行する必要があります。

• ➤ 各クライアントは，各ブロックでデータ可用性サンプリングを実行して，各ブロック内のデータが利用可能かどうかを確認しますが，同時に，ブロック全体のサイズが MB 以上である場合でも，ブロックごとに数 KB のデータをダウンロードする必要があります。ブロックは、すべてのデータ可用性チャレンジが正しく回答された後にのみ、クライアント ピアによって受け入れられます。

• ➤ データの可用性が検証されると、その正確性を検証することが容易になります。正確さは次の 2 つの手法によって検証されます。

不正証拠を使用すると、デポジットを賭けた一部の参加者が各ブロックの正当性を証明する署名を提供できます。他のチャレンジャーまたはフィッシャーマン ノードはランダム チェックを実行し、ブロック全体を完全に処理しようとします。データの可用性はすでにチェックされているため、他のノードはいつでもデータをダウンロードし、特定のブロックを完全に処理できます。無効なブロックが見つかった場合、ノードは誰もが検証できるチャレンジを発行します。ブロックが不良ブロックであることが判明した場合、このブロックに基づくすべてのブロックを再計算する必要があります。

ZK-SNARKテクノロジーを使用できます。このように、本技術により各ブロックの正当性を検証することができます。

以上が全文要約です！ Ethereum シャーディングの場合、短期的な計画は、シャード内のブロックにデータのみを含めることです。つまり、これらのシャードの役割は純粋に「データ可用性エンジン」であり、レイヤー 2 ロールアップの仕事は、安全なデータ空間を使用し、不正防止または ZK-SNARK テクノロジーも利用して、セキュリティ セックスを維持しながら高いトランザクション スループットを達成することです。ただし、「インプレース」で高スループットの実行を実現する内部システムを作成することも可能です。

シャーディング システムの主な特性は何ですか?トレードオフは何ですか?

シャーディングの主な目的は、従来の非シャーディング ブロックチェーンの最も重要なセキュリティ特性を可能な限り継承しながら、すべてのノードがすべてのトランザクションを検証する必要性を排除することです。

フラグメンテーションは基本的にこれらの要件を満たすことができます。従来のブロックチェーンの特徴は次のとおりです。

➤ 検証ノードはブロックが無効であることを検出して無視するため，無効なブロックをブロックチェーンに追加することはできません。

➤ データが利用できないブロックは、バリデーターがデータをダウンロードできず無視することを選択できるため、ブロックチェーンに追加できません。

• 強力なセキュリティを備えたシャード ブロックチェーンの特徴は次のとおりです。

• ➤ 次の理由により、無効なブロックをブロックチェーンに追加できません。

不正行為の証拠があれば、ブロックはすぐに検出され、それが間違ったブロックであることがネットワーク全体に通知され、作成者に厳しいペナルティが課せられます。

• または、無効なブロックに対しては有効な ZK-SNARK プルーフを生成できないため、ZK-SNARK を通じてその正しさを検証します。

• ➤ 使用できないデータを含むブロックは、次の理由によりブロックチェーンに追加できません。

ブロックの利用可能なデータの 50% 未満が利用可能な場合、各クライアントのデータ利用可能性の少なくとも 1 つのサンプル チェックがほぼ確実に失敗し、クライアントがブロックを拒否することになります。

ブロック データの少なくとも 50% が利用可能な場合、残りを回復するには 1 つの正直なノードだけが必要となるため、実質的にブロック データ全体が利用可能になります。

従来の高 TPS チェーンでは断片化がないため、上記の特性を達成できません。マルチチェーン システムが直面する問題は、攻撃者が攻撃するチェーンを選択すると、簡単に制御を取得でき、システム内のチェーンでセキュリティを共有することもできますが、セキュリティが低い場合は、攻撃と何ら変わりません。従来の高 TPS チェーンは、従来のブロックチェーンの欠点もすべて継承します。セキュリティが高ければ、共有セキュリティは上記のシャーディング テクノロジをより複雑に実装したものにすぎません。

サイドチェーンは実装に大きく依存しており、マイナーやベリファイアを共有する場合、通常は従来の高 TPS チェーンの弱点にさらされる傾向にあり、マイナーやベリファイアを共有しない場合は、マルチチェーン エコシステムの弱点にも直面することになります。シャード チェーンはこれらの問題を回避します。

ただし、シャーディング システムには隠れた危険性もいくつかあります。特に次のような側面において：

➤ 適応的な敵対者による攻撃が発生した場合、委員会のみに依存するシャード チェーンでは対処が難しく、責任を追及することが困難です。つまり、攻撃者が任意のノードのセットをリアルタイムで侵害したりシャットダウンしたりできる場合、委員会を混乱させるために攻撃する必要があるのは少数のノードだけです。さらに、攻撃者が強い回復力を持っているか、総プレッジの 50% を所有しているかに関係なく、委員会が破壊された場合、ネットワーク全体では攻撃に参加している少数のノード、つまり委員会内のノードしか確認できません。 、そして結果として生じる違約金の額は少額の誓約額にすぎません。これは、データ可用性サンプリングを不正証明または ZK-SNARK と組み合わせることが、ランダム サンプリング手法を補完する重要な理由となるもう 1 つの重要な理由です。

➤ オンライン・クライアントの数が十分なデータ可用性サンプリング・リクエストを生成するのに十分な場合に限り，これらの重複応答は常にブロック・データの少なくとも 50% を構成します。実際には、これは数百のクライアントがオンラインでなければならないことを意味し、この数が大きくなるほど、個々のノードの容量に対するシステム容量の比率が高くなります。これは、少数の N 信頼モデルです。一般に非常に信頼できますが、もちろん、非シャード チェーン ノードのデータ可用性の点では、0 の N 信頼モデルほど堅牢ではありません。

➤ シャード・チェーンが不正証明に依存する場合、ネットワークが遅すぎる場合、データが不正であることが不正証明によって示される前にノードがブロックを終了する可能性があるというタイミングの仮定に基づいています。幸いなことに、ルールに厳密に従えば、無効なブロックが見つかると、無効なブロックはすべてロールバックされます。期間パラメータはユーザーによって設定されます。待機しすぎるとコストがかかる可能性がありますが、より慎重なユーザーの方が安全です。それでも、このメカニズムはユーザー エクスペリエンスを弱める可能性があります。 ZK-SNARK を使用して妥当性を検証すると、この問題を解決できます。

➤ 転送する必要がある生データの量ははるかに多く、極端なネットワーク条件下では障害のリスクが増加します。少量のデータは大量のデータよりも送信が簡単で、強力な政府がブロックチェーンを検閲しようとした場合でも安全に隠すのが簡単です。ブロックチェーン ブラウザがチェーン全体の情報を維持したい場合は、より多くのデータを保存する必要があります。

これらはデータ検証が焦点を当てる必要がある問題ですが、私たちの見解では、集中化されたレイヤー 2 サービスを通じてではなく、より多くのアプリケーションをオンチェーンで実行することでユーザー層の集中化を軽減することの方が、上記の側面よりも注目に値します。とはいえ、実際には、これらの問題、特に最後の 2 つの問題により、シャード チェーンのスループットを一定のサイズを超えて増加させるのに実質的な制限が課せられます。二次シャーディングでは、限られた二次性しか実現できません。

最初のレベルのタイトル

ブロックの生成は一元化されていますが、検証の断片化は可能ですか?

このソリューションは、既存の集中型高 TPS ブロックチェーンを改善できますが、それでもシャーディング システムよりもはるかに強力ではありません。これらの理由のいくつかは次のとおりです。

1. TPS が高いチェーンでは、ブロックプロデューサーのレビュー動作を検出することがより困難になります。

検閲を監視するには、(i) すべてのトランザクションを確認し、何らかの理由で入力されなかった正当なトランザクションがないことを検証するか、(ii) ブロック作成者間で 1-of-N 信頼モデルを使用し、ブロックがアップロードできないことを検証するかのいずれかが必要です。チェーンに。集中型の高 TPS チェーンでは、最初の点を達成することは不可能であり、2 番目の点を達成するのはより困難です。これは、ノードの数が少なく、1-of-N の信頼モデルでさえも破壊されやすいためです。チェーンのブロック時間が DAS (データ可用性サンプリング) にとって速すぎる場合 (集中型の高 TPS チェーンのほとんどがそうであるように)、ノードのブロックの公開が遅すぎるという理由だけでノードのブロックが拒否されないことを証明するのは困難です。

2. ブロックプロデューサーとエコシステムメンバーの大多数がプロトコルの変更を強制しようとした場合、その変更は不人気ですが、ユーザーのクライアントは間違いなく変更を検出しますが、コミュニティにとっては変更を拒否し、フォークがはるかに困難になります。新しい高スループットのノードを実行する必要があるため、古いルールに基づいてブロックチェーンを維持するにはコストがかかります。

3. 集中化​​されたインフラストラクチャでは、外部の攻撃者による検閲の実施が容易になります。ブロック本番ノードはトランザクション スループットが高く、検出が非常に簡単で、これらのノードを簡単にシャットダウンできます。専用 HPC のレビューは、単一ユーザーのラップトップで行うよりも政治的およびロジスティック的にはるかに簡単です。編集: 専用 HPC を監査することは、個々のユーザーのラップトップを追跡するよりも論理的にも実践的にも簡単です。

4. ハイパフォーマンス コンピューティングの集中型クラウド サービスへの移行は、チェーン全体が 1 ～ 3 社のクラウド サービスで実行されるため、より大きなプレッシャーに直面し、リスクが増大します。大規模なブロックチェーンクラッシュのリスク。すべてのバリデーターが個別のハードウェア上で実行されるシャード化されたチェーンは、この攻撃に対する脆弱性が低くなります。

システムが適切に断片化されると、ベース層としてより適したものになります。シャードされたベースレイヤーに基づいて、ロールアップ（DeFi 向けの同期コンポーザビリティを備えた高スループットフィールドなど）を構築することで、いつでも集中型運用システムを作成できます。ただし、ベースレイヤーが集中ブロック生成に依存している場合、その上により分散化されたレイヤー 2 を構築することはできません。