随着イーサリアム生態系の繁栄、長年にわたり生態系に関連する大きな問題は、取引の速度と費用です。これはイーサリアムが抱える問題でもあり、拡張性も最も広く議論されている問題です。ここでは、簡単に歴史を紹介します。
拡張の道#
Pos：ブロックの提案者とブロックの検証者を分離し、pos のワークフローは次のようになります：
- シャードにトランザクションを提出する
- 検証者はトランザクションをシャードブロックに追加する
- ビーコンチェーンは新しいブロックを提案するためにバリデータを選択する
- 残りの検証者はシャード上の提案を検証するためにランダムな委員会を形成する
ブロックの提案と証明の提案は、1 つのスロット内で行う必要があります。通常、12 秒です。32 つのスロットが 1 つのエポックを形成し、各エポックでバリデータの順序がシャッフルされ、新しい委員会が選出されます。
マージ後、イーサリアムはコンセンサスレイヤーでの提案者とビルダーの分離を実現します。Vitalik は、すべてのブロックチェーンの最終目標は、中央集権的なブロックの生成と分散型のブロックの検証を持つことだと考えています。シャード後のイーサリアムのブロックデータは非常に密集しているため、データの可用性の高い要件から、ブロックの生成は中央集権的である必要があります。同時に、ブロックを検証し、データの可用性サンプリングを実行するための分散型のバリデータセットを維持する方法が必要です。
シャードとは何ですか？負荷を分散させるためのデータベースの水平分割プロセスです。#
シャードは、P2P ネットワーク内で計算タスクとストレージワークロードを分散する方法です。この処理方法により、各ノードはネットワーク全体のトランザクション負荷を処理する必要はなく、関連するパーティション（またはシャード）に関連する情報のみを維持すればよくなります。各シャードには独自のバリデータネットワークまたはノードネットワークがあります。シャードのセキュリティの問題：
例えば、ネットワーク全体に 10 つのシャードチェーンがある場合、ネットワーク全体を破壊するには 51％の計算能力が必要ですが、個々のシャードを破壊するには 5.1％の計算能力が必要です。
ビーコンチェーンは、ランダムな数値を生成し、ノードをシャードに割り当て、単一のシャードのスナップショットをキャプチャし、ハンドシェイクの権益やその他のさまざまな機能を処理し、シャード間の通信を担当し、ネットワークの同期を調整します。
シャードの大きな問題の 1 つは、シャード間のトランザクションの処理です。シャード内では、各ノードグループはそのシャード内のトランザクションのみを処理します。トランザクションはシャード間で比較的独立しているため、異なるシャードにいる A と B のユーザーが互いに送金する場合、どのように処理されるのでしょうか？
ブロックが破棄される可能性があるため、A、B が処理される場合、#2 で W、X トランザクションが受け入れられる場合、トランザクション全体が続行できなくなります。フォークの確率は非常に低いですが、発生する可能性があります。
過去の方法は、データの可用性レイヤーのシャーディングで、各シャードには独自の提案者と委員会がありました。バリデータセット内の各バリデータは、シャードのデータを順番に検証し、データをすべてダウンロードして検証します。
欠点は次のとおりです：
- バリデータ間での同期を確保するために厳密な同期技術が必要です。
- バリデータはすべての委員会の投票を収集する必要があり、ここでも遅延が発生する可能性があります。
- また、バリデータがデータを完全にダウンロードして検証するため、負荷がかかります。
2 番目の方法は、完全なデータの検証を放棄し、データの可用性サンプリングの方法を採用することです。ここでは、2 つのランダムサンプリング方法があります。
- ブロックのランダムサンプリング：一部のシャードに対してサンプリングし、検証が合格した場合、バリデータが署名します。ただし、ここでの問題は、トランザクションの欠落が発生する可能性があることです。
- データを多項式に再解釈し、特定の条件下で多項式がデータを復元できる特性を利用して、データの完全な可用性を確保します。
多項式の特性：4 つのポイントからデータを復元できます。
したがって、エンコードされたデータの 50％以上が利用可能であれば、データ全体が利用可能です。
複数のサンプリングを行う場合、データが利用できない確率は 2^-n のみです。
ロジックは、データを多項式に変換し、拡張し、拡張でデータを復元できるようにすることです。
問題は、多項式の拡張プロセスで正しく拡張されるかどうかです。
データ自体に問題がある場合、拡張後にデータを再構築することも誤って行われます。データが正しく拡張されることを確認する方法はありますか？
- celestia はフラウドプルーフを使用し、同期の問題があります。
- イーサリアムとポリゴンの avail は kzg コミットメントを使用し、正直な少数と同期の問題はありません。ただし、kzg コミットメントは量子計算攻撃に対して耐性がないため、将来的にはイーサリアムは zkstarks の技術に移行し、量子計算攻撃に対する耐性を持つ可能性があります。
この競技場で最も注目されているのは、ゼロ知識証明を使用した zksync と starkware です。後で詳しく説明します。
量子攻撃とは何ですか：アルゴリズムが多くの数学的なセキュリティ仮定に依存しないことを意味します。#
Kzg コミットメント：特定の位置の多項式の値が指定された値と一致することを証明します。
KZG コミットメントは、具体的なメッセージを指定せずにメッセージを検証することができる多項式コミットメントの一種です。具体的な手順は以下の図に示す通りです。
メルケルツリーとの比較：#
全体のプロセスは、データをエンコードして多項式に変換し、それを拡張することです。KZG コミットメントを使用して拡張が有効であり、元のデータが有効であることを確認します。その後、拡張を使用してデータを再構築し、最後にデータの可用性サンプリングを行います。
Celestia は、バリデータが全体のブロックをダウンロードすることを要求し、現在の danksharding はデータの可用性サンプリング技術を利用しています。
ブロックが部分的に利用できる場合、いつでもブロックを再構築する必要があります。ブロックが実際に一部利用できる場合、ノード間の通信によってブロックが組み立てられます。
KZG コミットメントとフラウドプルーフの比較：#
KZG コミットメントは、拡張とデータが正しいことを保証できますが、フラウドプルーフは第三者の監視を導入します。最も明らかな違いは、フラウドプルーフが観察者が反応するための時間間隔を必要とし、その後フラウドを報告するためにノード間の同期を満たす必要があることです。KZG は、数学的な方法を使用してデータの正確性を保証するため、待ち時間は必要ありません。
Celestia 自体の欠点は、大きなブロックを使用し、バリデータがすべてのデータをダウンロードすることを要求することです。これはイーサリアムの danksahrding の proto ソリューションでもあります。したがって、将来的にはデータの可用性サンプリングの方法を選択する必要があり、そのためには kzg コミットメントが必要です。
kzg もフラウドプルーフも同期が必要です。ブロックが利用できない可能性があるためです。