著者: カーネルベンチャーズ ジェリー・ルオ

編集者: カーネルベンチャーズ ローズ、カーネルベンチャーズ マンディ、カーネルベンチャーズ ジョシュア

TLDR:

  1. ブロックチェーンの初期段階では、データの一貫性を維持することは、セキュリティと分散化を確保するために非常に重要と考えられていました。しかし、ブロックチェーンエコシステムの発展に伴い、ストレージの圧力も高まり、ノード操作の集中化の傾向につながっています。このような状況では、レイヤー1のTPSの増加によってもたらされるストレージコストの問題は、早急に解決する必要があります。

  2. この問題に直面した開発者は、セキュリティ、ストレージ コスト、データ読み取り速度、DA レイヤーの汎用性を十分に考慮したソリューションを提案する必要があります。

  3. この問題を解決する過程で、シャーディング、DAS、Verkle Tree、DA中間コンポーネントなど、多くの新しい技術とアイデアが登場しました。これらは、データの冗長性を減らし、データ検証の効率を向上させることで、DAレイヤーのストレージスキームを最適化しようとしています。

  4. DA ソリューションは、データの保存場所の観点から、メインチェーン DA とサードパーティ DA の 2 種類に大別されます。メインチェーン DA は、定期的なデータ クレンジングとスライスされたデータ ストレージの観点から設計されており、ノードのストレージ負荷を軽減します。一方、サードパーティ DA は、大量のデータに対して合理的なソリューションを備えたストレージ ニーズに対応するように設計されています。その結果、サードパーティ DA では主にシングル チェーン互換性とマルチ チェーン互換性の間でトレードオフが行われ、メインチェーン固有の DA、モジュール化された DA、ストレージ パブリック チェーン DA の 3 種類のソリューションが提案されています。

  5. 決済型パブリックチェーンは履歴データのセキュリティに対する要求が非常に高いため、メインチェーンをDA層として使用するのが適しています。しかし、長期間稼働し、多数のマイナーがネットワークを稼働させているパブリックチェーンの場合、コンセンサス層の変更を伴わず、比較的セキュリティの高いサードパーティのDAを採用する方が適しています。包括的なパブリックチェーンの場合、データ容量が大きく、コストが低く、セキュリティが高いメインチェーンの専用DAストレージを使用する方が適しています。ただし、クロスチェーンの需要を考慮すると、モジュラーDAも良い選択肢です。

  6. 全体的に、ブロックチェーンはデータの冗長性を削減し、マルチチェーンの分業化を進める方向に進んでいます。

1. 背景

分散型台帳であるブロックチェーンは、データストレージが安全で十分に分散化されていることを確認するために、すべてのノードに保存されている履歴データのコピーを作成する必要があります。各状態変更の正確性は以前の状態（トランザクションのソース）に関連しているため、トランザクションの正確性を保証するために、ブロックチェーンは最初のトランザクションの生成から現在のトランザクションまでのすべてのトランザクション履歴を保存する必要があります。Ethereumを例にとると、ブロックあたりの平均サイズを20kbとした場合でも、Ethereumの現在のデータの合計サイズは370GBに達しています。フルノードの場合、ブロック自体に加えて、状態とトランザクションの受信を記録する必要があります。この部分を含めると、単一ノードの総ストレージ量は1TBを超えており、ノードの操作は徐々に集中化されています。

出典: Etherscan

イーサリアムの最近のカンクンアップグレードは、イーサリアムのTPSを1000近くまで増加させることを目指しており、その時点でイーサリアムの年間ストレージ増加は現在のストレージの合計を超えることになります。高性能パブリックチェーンでは、数万TPSのトランザクション速度により、1日あたり数百GBのデータが追加される可能性があります。ネットワーク上のすべてのノードの共通のデータ冗長性は、明らかにこのようなストレージ圧力に適応できません。そのため、レイヤー1は、TPSの増加とノードのストレージコストのバランスをとる適切なソリューションを見つける必要があります。

2. DAのパフォーマンス指標

2.1 安全性

データベースやリンクリストと比較すると、ブロックチェーンの不変性は、新しく生成されたデータが履歴データによって検証できるという事実に由来しており、したがって、履歴データのセキュリティを確保することは、DA レイヤーのストレージで最初に考慮すべき問題です。ブロックチェーン システムのデータ セキュリティを判断するには、多くの場合、データの冗長量とデータ可用性の確認方法を分析します。

  • 冗長性の数: ブロックチェーン システムにおけるデータの冗長性は、主に次のような役割を果たします。まず、ネットワークの冗長性が高いほど、検証者がアカウントの状態を確認する必要があるときに参照できるサンプルが多くなり、ノードが大多数のノードによって記録されたデータをより安全に選択するのに役立ちます。従来のデータベースでは、データは特定のノードにキーと値のペアの形式でのみ保存されるため、履歴データの変更は単一のノードでのみ実行され、攻撃コストが低く、理論的には冗長性の数が多いほど、データの信頼性が高くなります。理論的には、冗長性が多いほど、データの信頼性が高くなります。さらに、ノードの数が多いほど、データが失われる可能性が低くなります。この点は、Web2 ゲームを保存する集中型サーバーと比較することもできます。バックグラウンド サーバーがすべてシャットダウンされると、サービスが完全に終了します。しかし、冗長性を高めることは必ずしも良いことではありません。冗長性によってストレージ スペースが追加され、システムに過度のストレージ負荷がかかるからです。優れた DA レイヤーでは、セキュリティとストレージ効率のバランスをとるために適切な冗長性方法を選択する必要があります。

  • データ可用性チェック: 冗長性の量により、ネットワーク内のデータの記録が十分であることを保証できますが、使用するデータの正確性と完全性をチェックする必要があります。現在のブロックチェーンでは、検証方法として暗号化コミットメント アルゴリズムが一般的に使用されており、トランザクション データの混合によって得られた小さな暗号化コミットメントをネットワーク全体に記録するだけです。履歴データの信頼性をテストするには、データを使用してコミットメントを復元する必要があります。復元コミットメントが元のコミットメントと同一であれば、検証は成功です。一般的に使用される暗号化検証アルゴリズムは、Merkle Root と Verkle Root です。セキュリティの高いデータ可用性検証アルゴリズムは、可能な限り少ないサードパーティ データの助けを借りて、履歴データを迅速に検証できます。

2.2 ストレージコスト

基本的なセキュリティを確保した後、DA レイヤーの次の目標は、コストを削減し、効率を高めることです。最初のステップは、ハードウェアのパフォーマンスの違いに関係なく、単位サイズあたりのデータを格納することによって発生するメモリ消費によってもたらされるストレージ コストを削減することです。現在、ブロックチェーンでストレージ コストを削減する主な方法は、シャーディング テクノロジを採用し、リワード ストレージを使用してデータのバックアップ数を減らしながらセキュリティを維持することです。ただし、上記の改善方法から、ストレージ コストとデータ セキュリティの間にはゲーム関係があり、ストレージの占有率を下げるとセキュリティが低下することが多いことは容易にわかります。したがって、優れた DA レイヤーは、ストレージ コストとデータ セキュリティのバランスを実現する必要があります。さらに、DA レイヤーが独立したパブリック チェーンである場合は、データ交換の中間プロセスを最小限に抑えてコストを削減する必要もあります。このプロセスでは、すべてのトランジット プロセスで後続の検索のためにインデックス データを残す必要があります。そのため、呼び出しプロセスが長くなるほど、残されるインデックス データが多くなり、ストレージ コストが増加します。最後に、データを保存するコストは、データの永続性と直接関係しています。一般的に、データ保存のコストが高くなるほど、パブリックチェーンがデータを永続的に保存することが難しくなります。

2.3 データ読み取り速度

コスト削減を達成したら、次のステップは効率化です。つまり、必要なときに DA レイヤーからデータをすばやく呼び出す機能です。このプロセスには 2 つのステップがあり、最初はデータを保存するノードを検索します。主にネットワーク全体でデータの一貫性を実現していないパブリック チェーンの場合、パブリック チェーンがネットワーク全体でノードのデータ同期を実現している場合は、このプロセスの時間消費は無視できます。次に、Bitcoin、Ethereum、Filecoin など、この段階で主流となっているブロックチェーン システムでは、ノードの保存方法はすべて Leveldb データベースです。Leveldb では、データは 3 つの方法で保存されます。まず、オンザフライで書き込まれたデータは、Memtable がいっぱいになるまで Memtable タイプのファイルに保存され、その後、ファイル タイプが Memtable から Immutable Memtable に変更されます。2 つのタイプはどちらもメモリに保存されますが、Immutable Memtable ファイルは読み取り専用です。 IPFS ネットワークで使用されるホット ストレージは、ネットワークのこの部分にデータを保存するため、呼び出されたときにメモリからすばやく読み取ることができますが、平均的なノードには GB 単位の取り外し可能なメモリしかないため、速度が低下しやすく、ノードがダウンするとメモリ内のデータは永久に失われます。永続的なデータ ストレージが必要な場合は、ソリッド ステート ディスク (SSD) に SST ファイルの形式でデータを保存する必要がありますが、データを読み取るときは、最初にデータをメモリに読み取る必要があるため、データのインデックス作成の速度が大幅に低下します。最後に、ストレージ シャーディングを備えたシステムの場合、データの復元には複数のノードにデータ要求を送信して復元する必要があり、このプロセスによってもデータの読み取り速度が低下します。

出典: Leveldb ハンドブック

2.4 DA層の一般化

DeFiの発展とCEXのさまざまな問題により、分散型資産のクロスチェーン取引に対するユーザーの要件が高まっています。ハッシュロック、公証人、リレーチェーンのいずれのクロスチェーンメカ​​ニズムを採用しても、2つのチェーン上の履歴データの同時判定は避けられません。この問題の鍵は、異なる分散型システムで直接通信できない2つのチェーン上のデータの分離にあります。そのため、DAレイヤーの保存方法を変更することで解決策が提案されています。DAレイヤーは、複数のパブリックチェーンの履歴データを同じ信頼できるパブリックチェーンに保存し、検証時にこのパブリックチェーン上のデータを呼び出すだけで済みます。これには、DAレイヤーがさまざまな種類のパブリックチェーンと安全な通信を確立できることが必要であり、DAレイヤーは優れた汎用性を備えています。

3. DAに関する技術

3.1 シャーディング

従来の分散システムでは、ファイルはノードに完全な形で保存されるのではなく、元のデータを複数のブロックに分割して各ノードに保存します。また、ブロックは1つのノードに保存されるだけでなく、他のノードに適切なバックアップを残すことがよくあります。既存の主流の分散システムでは、バックアップの数は通常2に設定されています。このシャーディングメカニズムにより、個々のノードのストレージ圧力が軽減され、システムの総容量が各ノードのストレージ容量の合計まで拡張され、同時に適切なデータ冗長性を通じてストレージのセキュリティが確保されます。ブロックチェーンで採用されているシャーディングスキームは、一般的に従来の分散システムと似ていますが、細部ではいくつかの違いがあります。まず、ブロックチェーンのデフォルトノードは信頼できないため、シャーディングを実現するプロセスでは、その後のデータの真正性の判断のために十分な量のデータバックアップが必要になるため、このノードのバックアップ数は 2 よりはるかに多くする必要があります。理想的には、このストレージスキームを採用するブロックチェーンシステムでは、認証ノードの総数が T でシャード数が N の場合、バックアップ数は T/N である必要があります。次に、ブロックのストレージプロセスに関して、ノード数が少ない従来の分散システムでは、ノードが複数のデータブロックに適応するモードがよくあります。まず、データはコンシステントハッシュアルゴリズムによってハッシュリングにマッピングされ、次に各ノードはハッシュリングの割り当てを使用して、特定の範囲の番号付きブロックを格納します。システムでは、1 つのノードが特定のストレージにストレージタスクを持たないことが許容されます。ブロックチェーン上では、ストレージブロックはもはやランダムではなく、ノードにとって避けられないイベントです。各ノードは、ブロックチェーンに保存するブロックをランダムに選択し、ノードの情報と混合したデータのハッシュ結果をスライス番号で割った結果でプロセスが完了します。各データが N 個のブロックに分割されていると仮定すると、各ノードの実際のストレージ サイズは 1/N のみです。N を適切に設定することで、TPS の増加とノード ストレージへの負荷のバランスを実現できます。

出典: カーネルベンチャーズ

3.2 DAS（データ可用性サンプリング）

DAS 技術は、シャーディングに基づくストレージ方法をさらに最適化したものです。シャーディングのプロセスでは、ノードの単純なランダム ストレージが原因で、ブロック損失が発生する可能性があります。次に、シャーディング後のデータについては、復元プロセス中にデータの信頼性と整合性をどのように確認するかも非常に重要です。DAS では、これら 2 つの問題は、Eraser コードと KZG 多項式コミットメントによって解決されます。

  • 消去コード: Ethereum には検証済みのノードが多数あるため、確率イベントではあるものの、ブロックがどのノードにも保存されていない可能性があります。ストレージが失われる脅威を軽減するために、生データをブロックにスライスして細分化する代わりに、このスキームでは生データを n 次多項式の係数にマッピングし、多項式上の 2n 個のポイントを取得して、ノードがランダムに 1 つを選択して保存できるようにします。この n 次多項式では、削減に必要なポイントは n+1 個だけなので、元のデータの削減を実現するためにノードが選択する必要があるブロックは半分だけです。消去コードにより、データ ストレージのセキュリティとネットワークのデータ回復能力が向上します。

  • KZG多項式コミットメント：データストレージの非常に重要な側面は、データの真正性の検証です。Eraserコードを使用しないネットワークでは、検証にさまざまな方法を使用できますが、上記のEraserコードを導入してデータセキュリティを向上させる場合は、KZG多項式コミットメントを使用する方が適切です。KZG多項式コミットメントは、単一ブロックの内容を多項式の形式で直接検証できるため、多項式をバイナリデータに縮小する必要がありません。KZG多項式コミットメントは、単一ブロックの内容を多項式の形式で直接検証できるため、多項式をバイナリデータに縮小する必要がありません。全体的な検証形式はMerkle Treeに似ていますが、特定のパスノードデータを必要とせず、ブロックの真正性を検証するためにKZGルートとブロックデータのみが必要です。

3.3 DAにおけるデータ検証方法

データ検証は、ノードから呼び出されたデータが正確かつ完全であることを保証します。検証プロセスに必要なデータ量と計算コストを最小限に抑えるために、DA 層では現在、ツリー構造を主流の検証方法として使用しています。最も単純な形式は、完全なバイナリ ツリー レコードの形式を使用する Merkle Tree を使用して検証することです。Merkle ルートと、ノードのパスの反対側にあるサブツリーのハッシュ値を保持するだけで検証でき、検証の時間計算量は O(logN) レベルです (logN はデフォルトで log2(N))。検証プロセスは大幅に簡素化されましたが、検証プロセスのデータ量は一般に、データの増加とともに増加します。検証量の増加という問題を解決するために、この段階では別の検証方法である Verkle Tree が提案されています。この方法では、Verkle Tree の各ノードが値を保存するだけでなく、Vector Commitment も添付します。これにより、元のノードの値とコミットメント証明を使用して、他の姉妹ノードの値を呼び出す必要がなく、データの真正性を迅速に検証できるため、各検証の計算が簡単かつ高速になります。これにより、各検証の計算回数は Verkle Tree の深さ (固定定数) にのみ関連するため、検証速度が大幅に加速されます。ただし、Vector Commitment の計算には、同じレイヤーのすべての姉妹ノードの参加が必要であり、データの書き込みと変更のコストが大幅に増加します。ただし、履歴データなど、永続的に保存され、改ざんできず、読み取りのみ可能で書き込みはできないデータの場合、Verkle Tree は非常に適しています。さらに、Merkle Tree と Verkle Tree 自体には K 進形式のバリエーションがあり、メカニズムの具体的な実装は類似しており、各ノードの下のサブツリーの数を変更するだけです。具体的なパフォーマンスの比較は次の表で確認できます。

出典: バークルの木

3.4 汎用DAミドルウェア

ブロックチェーンエコシステムの継続的な拡大により、パブリックチェーンの数が増加しています。各パブリックチェーンはそれぞれの分野で優位性と代替不可能性を持っているため、Layer1パブリックチェーンが短期間で統一されることは不可能です。しかし、DeFiの発展とCEXの問題により、分散型クロスチェーン取引資産に対するユーザーの需要が高まっています。そのため、クロスチェーンデータインタラクションのセキュリティ問題を解消できるDAレイヤーマルチチェーンデータストレージがますます注目を集めています。ただし、異なるパブリックチェーンからの履歴データを受け入れるには、DAレイヤーが標準化されたストレージとデータフローの検証のための分散プロトコルを提供する必要があります。たとえば、Arweaveベースのストレージミドルウェアであるkvyeは、メインチェーンからデータをアクティブにクロールする方法を採用しており、すべてのチェーンのデータを標準化された形式でArweaveに保存して、データ転送プロセスの違いを最小限に抑えることができます。比較すると、特定のパブリックチェーンにDA層のデータストレージを提供することに特化したLayer2は、内部共有ノードを介してデータのやり取りを行います。やり取りのコストが削減され、セキュリティが向上しますが、制限が大きく、特定のパブリックチェーンにしかサービスを提供できません。

4. DAの保存方法

4.1 メインチ​​ェーン DA

4.1.1 DankShardingのような

このタイプのストレージ方式に明確な名前はありませんが、最も有名なのは Ethereum 上の Dank Sharding であるため、この論文では、このタイプの方式を指すために Dank Sharding のような用語を使用します。このタイプの方式は、主に前述の 2 つの DA ストレージ技術、シャーディングと DAS を使用し、まずシャーディングによってデータを適切な数のシェアに分割し、次に各ノードが DAS の形式でデータ ブロックを抽出して保存します。ネットワーク全体に十分なノードがある場合、スライス数 N を大きくして、各ノードのストレージ圧力を元の 1/N に抑え、全体のストレージ スペースを N 倍に拡張できます。同時に、ブロックがどのブロックにも保存されないという極端なケースを防ぐために、Dank Sharding は Eraser Code を使用してデータをエンコードします。これにより、データの半分だけで完全に復元できます。最後に、高速チェックサムのための多項式コミットメントを備えた Verkle ツリー構造を使用してデータが検証されます。

4.1.2 一時保存

メインチェーンのDAにとって、データを処理する最も簡単な方法の1つは、履歴データを短期間保存することです。本質的に、ブロックチェーンはパブリック台帳として機能し、台帳の内容はネットワーク全体の前で変更され、永続的なストレージは必要ありません。たとえば、Solanaの場合、履歴データはArweaveに同期されていますが、メインネットワークノードは過去2日間のトランザクションデータのみを保持しています。アカウントレコードに基づくパブリックチェーンでは、履歴データの各瞬間にブロックチェーン上のアカウントの最終状態が保持され、次の瞬間の変更の検証の基礎を提供するのに十分です。この時間の前にデータを特別に必要とする人は、他の分散型パブリックチェーンにデータを保存したり、信頼できる第三者に引き渡したりすることができます。言い換えれば、データの追加ニーズがある人は、履歴データのストレージに料金を支払う必要があります。

4.2 サードパーティDA

4.2.1 メインチ​​ェーンのDA: EthStorage

  • メインチェーンのDA：DA層にとって最も重要なのはデータ転送のセキュリティであり、最もセキュリティの高いDAはメインチェーンのDAですが、メインチェーンのストレージはストレージスペースとリソースの競合によって制限されるため、ネットワークのデータ量が急速に増加した場合、データの長期保存を実現するにはサードパーティのDAの方が適しています。サードパーティのDAがメインネットワークとの互換性が高い場合、ノードの共有を実現でき、データ相互作用プロセスのセキュリティが高くなります。したがって、セキュリティを考慮するという前提の下では、メインチェーン専用のDAには大きな利点があります。Ethereumを例にとると、メインチェーン専用のDAの基本要件の1つは、EVMと互換性があり、Ethereumデータと契約との相互運用性を確保できることであり、代表的なプロジェクトにはTopia、EthStorageなどがあります。その中でも、互換性の面ではEthStorageが最も互換性のあるDAです。代表的なプロジェクトとしては、Topia、EthStorageなどがあります。その中でも、EthStorageは互換性の面で最も発達しており、EVM互換性に加えて、Remix、Hardhat、その他のEthereum開発ツールとのインターフェースも設定し、Ethereum開発ツールとの互換性を実現しています。

  • EthStorage: EthStorage は Ethereum から独立したパブリック チェーンですが、その上で実行されているノードは Ethereum ノードのスーパーグループです。つまり、EthStorage を実行しているノードは同時に Ethereum も実行できます。さらに、Ethereum 上の opcode を介して EthStorage を直接操作することもできます。EthStorage のストレージ モデルは、メインの Ethereum ネットワーク上のインデックス作成用のメタデータを少量のみ保持し、基本的に Ethereum の分散型データベースを作成します。現在のソリューションでは、EthStorage はメインの Ethereum に EthStorage Contract を展開して、メインの Ethereum と EthStorage 間の相互作用を実現します。 Ethereum がデータを預ける場合、コントラクト内の put() 関数を呼び出す必要があり、入力パラメータは 2 バイト変数の key、data です。ここで、data は預けるデータを表し、key は Ethereum ネットワーク内でのその ID であり、IPFS における CID の存在に似ていると見なすことができます。(key、data) データ ペアが EthStorage ネットワークに正常に保存されると、EthStorage は Ethereum ホスト ネットワークに返される kvldx を生成します。これは Ethereum ネットワーク上のキーに対応し、この値は EthStorage 上のデータの保存アドレスに対応するため、大量のデータを保存するという元の問題は、単一の (key、kvldx) を保存することに変更できるようになりました。(key、kvldx) ペアにより、メインの Ethereum ネットワークのストレージ コストが大幅に削減されます。以前に保存したデータを呼び出す必要がある場合は、EthStorage の get() 関数を使用してキー パラメータを入力する必要があります。その後、Ethereum に保存されている kvldx を使用して、EthStorage 上のデータをすばやく検索できます。

出典: カーネルベンチャーズ

  • ノードがデータを保存する方法については、EthStorage は Arweave モデルから学習します。まず、ETH からの大量の (k,v) ペアがシャーディングされ、各シャーディングには固定数の (k, v) ペアが含まれます。各 (k, v) ペアのサイズには制限があり、マイナーの報酬を保存するプロセスでワークロードの公平性を確保します。報酬を発行するには、ノードがデータを保存しているかどうかを確認する必要があります。このプロセスでは、EthStorage はシャーディング (TB サイズ) を多数のチャンクに分割し、検証用に Ethereum メインネット上に Merkle ルートを保持します。次に、マイナーは、EthStorage 上の前のブロックのハッシュを使用してランダム アルゴリズムでいくつかのチャンクを生成するための nonce を提供する必要があります。マイナーは、シャーディング全体を保存したことを証明するためにこれらのチャンクのデータを提供する必要がありますが、この nonce は任意に選択することはできません。そうしないと、ノードは保存したチャンクに対応する適切な nonce を選択し、検証に合格します。ただし、この nonce はランダムに選択することはできません。そうしないと、ノードは保存したチャンクにのみ対応する適切な nonce を選択し、検証に合格します。そのため、この nonce は、生成されたチャンクを混合およびハッシュ化した後に作成する必要があり、難易度の値がネットワークの要件を満たし、nonce とランダム アクセス プルーフを送信した最初のノードだけが報酬を得ることができます。

4.2.2 モジュール化 DA: セルセティア

  • ブロックチェーンモジュール：レイヤー1パブリックチェーン上で実行されるトランザクションは、次の4つの部分に分かれています。（1）ネットワークの基礎ロジックの設計、特定の方法での検証ノードの選択、ブロックの書き込み、ネットワーク管理者への報酬の割り当て。（2）トランザクションのパッケージ化と処理、および関連トランザクションの公開。（3）ブロックチェーンにアップロードされるトランザクションの検証と最終ステータスの決定。（4）ブロックチェーン上の履歴データの保存と維持。実行されるさまざまな機能に応じて、ブロックチェーンはコンセンサス層、実行層、決済層、データ可用性層（DA層）の4つのモジュールに分けることができます。

  • モジュラーブロックチェーン設計：長い間、これらの4つのモジュールは単一のパブリックチェーンに統合されており、このようなブロックチェーンはモノリシックブロックチェーンと呼ばれています。この形式はより安定しており、メンテナンスが容易ですが、単一のパブリックチェーンに多大な負担をかけます。実際には、4つのモジュールは互いに制約し、パブリックチェーンの限られた計算リソースとストレージリソースをめぐって競争します。たとえば、処理層の処理速度を上げると、データ可用性層にさらにストレージ圧力がかかります。実行層のセキュリティを確保するには、より複雑な検証メカニズムが必要ですが、トランザクション処理の速度が低下します。そのため、パブリックチェーンの開発では、これらの4つのモジュール間のトレードオフに直面することがよくあります。パブリックチェーンのパフォーマンス向上のこのボトルネックを打破するために、開発者はモジュラーブロックチェーンソリューションを提案しました。モジュラーブロックチェーンの核となるアイデアは、上記の4つのモジュールのうち1つまたはいくつかを取り除き、別のパブリックチェーンに実装することです。このようにして、パブリックチェーンはトランザクション速度またはストレージ容量の向上に集中でき、ショートボード効果によるブロックチェーンの全体的なパフォーマンスに対する以前の制限を打破できます。

  • モジュラーDA：DAレイヤーをブロックチェーンビジネスから分離し、別のパブリックチェーンに配置するという複雑なアプローチは、レイヤー1の増加する履歴データに対する実行可能なソリューションと見なされています。現時点では、この分野の調査はまだ初期段階にあり、最も代表的なプロジェクトはCelestiaです。これは、データを複数のブロックに分割し、各ノードがその一部を抽出して保存し、KZG多項式コミットメントを使用してデータの整合性を検証するShardingのストレージ方法を使用しています。同時に、Celestiaは高度な2次元RS修正コードを使用して、元のデータをk * kマトリックスの形式で書き換えます。これにより、最終的に元のデータの25％のみを回復する必要があります。ただし、スライスされたデータストレージは、基本的にネットワーク全体のノードのストレージ圧力を総データ量の係数で乗算するだけであり、ノードのストレージ圧力は依然としてデータ量に比例して増加します。レイヤー1のトランザクション速度が向上し続けると、ノードのストレージ圧力はいつか許容できないしきい値に達する可能性があります。この問題を解決するために、Celestia に IPLD コンポーネントが導入されました。k*k マトリックスのデータを Celestia に直接保存するのではなく、データは LL-IPFS ネットワークに保存され、データの CID コードのみがノードに保持されます。ユーザーが履歴データを要求すると、ノードは対応する CID を IPLD コンポーネントに送信し、IPFS 上の元のデータを呼び出すために使用されます。データが IPFS に存在する場合、IPLD コンポーネントとノードを介して返されます。存在しない場合は、データを返すことはできません。

出典: セレスティア コア

  • Celestia: Celestia を例にとると、モジュラー ブロックチェーンが Ethereum のストレージ問題を解決するのにどのように応用されているかがわかります。Rollup ノードはパッケージ化され検証されたトランザクション データを Celestia に送信し、そのデータを Celestia に保存します。その過程で、Celestia はデータをあまり感知せずに保存するだけです。この過程で、Celestia はデータを感知せずに保存するだけで、最終的にストレージ スペースのサイズに応じて、Rollup ノードは対応する tia トークンをストレージ料金として Celestia に支払います。Celestia のストレージは、EIP4844 と同様の DAS とデバッグ コードを使用していますが、EIP4844 の多項式デバッグ コードは 2 次元 RS デバッグ コードを使用するようにアップグレードされており、ストレージのセキュリティがさらに向上し、トランザクション データ全体を復元するために必要な分数は 25% のみになっています。これは本質的にはストレージコストが低いPOSパブリックチェーンであり、Ethereumの履歴データストレージ問題の解決策として実現する場合、Celestiaと連携するための他の多くの特定のモジュールが必要です。たとえば、ロールアップに関して、Celestiaの公式サイトで強く推奨されているロールアップモデルの1つはSovereign Rollupです。これは、トランザクションの計算と検証のみが可能で、実行レイヤーを完了するだけで、実行と決済プロセス全体を含むLayer2の一般的なロールアップとは異なり、Celestiaでの実行と決済プロセスの必要性を最小限に抑えます。これにより、Celestiaでのトランザクションの処理が最小限に抑えられ、Celestiaの全体的なセキュリティがEthereumのセキュリティよりも弱い場合に、トランザクションプロセスの全体的なセキュリティが最大化されます。EthereumのメインネットワークでCelestiaが呼び出すデータのセキュリティに関しては、最も主流のソリューションはQuantum Gravity Bridgeスマートコントラクトです。 Celestia に保存されたデータについては、Merkle Root (データ可用性証明書) を生成し、EtherCenter のメイン ネットワーク上の Quantum Gravity Bridge コントラクトに保存します。EtherCenter が Celestia 上の履歴データを毎回呼び出すときは、ハッシュ結果を Merkle Root と比較し、一致した場合は、それが実際の履歴データであることを意味します。

4.2.3 ストレージチェーン DA

メインチェーンDAの技術原理から見ると、シャーディングに似た多くの技術がストレージパブリックチェーンから借用されています。サードパーティDAの中には、ストレージパブリックチェーンの助けを借りてストレージタスクの一部を直接実行するものもあります。たとえば、Celestiaの特定のトランザクションデータはLL-IPFSネットワークに配置されます。サードパーティDAのソリューションでは、別のパブリックチェーンを構築してレイヤー1のストレージ問題を解決する以外に、ストレージパブリックチェーンをレイヤー1に直接接続して、レイヤー1に膨大な履歴データを保存するというより直接的な方法があります。高性能ブロックチェーンの場合、履歴データの量はさらに大きく、フルスピードで動作している場合、高性能パブリックチェーンSolanaのデータ量は4PGに近く、これは通常のノードのストレージ範囲を完全に超えています。Solanaは、分散ストレージネットワークArweaveに履歴データを保存するソリューションを選択し、検証のためにメインネットワークのノードに2日分のデータのみを保持します。ストレージ プロセスのセキュリティを確保するために、Solana と Arweave チェーンはストレージ ブリッジ プロトコルである Solar Bridge を設計しました。このプロトコルは、検証済みのデータを Solana ノードから Arweave に同期し、対応するタグを返します。これにより、Solana ノードは Solana ブロックチェーンの履歴データを任意の時点で表示できます。Solana ノードは、Solana ブロックチェーン上の任意の時点の履歴データを表示できます。Arweave では、ネットワーク全体のノードが参加の必須条件としてデータの一貫性を維持することを要求するのではなく、ネットワークは報酬ストレージ アプローチを採用しています。まず、Arweave はブロックを構築するために従来のチェーン構造を使用せず、グラフ構造に似た構造を使用します。Arweave では、新しいブロックは前のブロックを指すだけでなく、生成されたブロックであるリコール ブロックをランダムに指します。リコール ブロックの正確な位置は、前のブロックのハッシュ結果とそのブロックの高さによって決定され、リコール ブロックの位置は前のブロックがマイニングされるまで不明です。ただし、新しいブロックを生成するプロセスでは、指定された難易度のハッシュを計算するために POW メカニズムを使用するために、ノードはリコール ブロックのデータを持っている必要があり、難易度を満たすハッシュを最初に計算したマイナーのみが報酬を受け取ることができるため、マイナーはできるだけ多くの履歴データを保存するように促されます。同時に、特定の履歴ブロックを保存する人が少なければ少ないほど、難易度に準拠した nonce を生成するときにノードが持つ競争相手が少なくなり、マイナーはネットワーク内にバックアップが少ないブロックを保存するように促されます。最後に、ノードがデータを永続的に保存することを保証するために、WildFire のノード スコアリング メカニズムが Arweave に導入されています。ノードは、履歴データをより多く、より速く提供できるノードと通信することを優先しますが、評価の低いノードは最新のブロックとトランザクション データを最初に取得できないため、POW 競争で有利なスタートを切ることができません。

出典: Arweave Yellow-Paper

5. 総合比較

DA パフォーマンス メトリックの 4 つの側面に基づいて、5 つのストレージ ソリューションのそれぞれについて、長所と短所を比較します。

  • 安全性：データセキュリティ問題の最大の原因は、データ転送プロセスによるデータ損失と不正なノードによる悪意のある改ざんであり、2つのパブリックチェーンが独立しており、状態が共有されていないため、クロスチェーンプロセスはデータ転送セキュリティの最も打撃を受ける領域です。また、この段階では専門的なDAレイヤーが必要なLayer1には、強力なコンセンサスグループが存在することが多く、そのセキュリティは通常のストレージパブリックチェーンよりもはるかに高くなります。そのため、メインチェーンDAソリューションのセキュリティは高くなります。データ転送のセキュリティを確保した後、次のステップは呼び出しデータのセキュリティを確保することです。トランザクションの検証に使用される短期履歴データのみを考慮すると、同じデータが一時ストレージネットワークにネットワーク全体でバックアップされますが、DankShardingのようなスキームでのデータバックアップの平均数は、ネットワーク全体のノード数の1/Nにすぎません。つまり、データの冗長性を高めると、データが失われにくくなり、同時に検証用の参照サンプルをより多く提供できます。したがって、一時ストレージはデータのセキュリティが高くなります。サードパーティの DA スキームでは、メインチェーンで使用されるパブリックノードにより、クロスチェーンのプロセスでこれらのリレーノードを介してデータを直接送信できるため、他の DA スキームよりもセキュリティが比較的高くなります。

  • ストレージコスト：ストレージコストに最も大きな影響を与える要因は、データの冗長性の量です。ネットワーク全体のノードデータ同期の形式を使用してストレージするメインチェーンDAの短期ストレージ方式では、新しく保存されたデータはネットワーク全体のノードにバックアップする必要があり、ストレージコストが最も高くなります。ストレージコストが高いため、TPSの高いネットワークでは、このアプローチは一時的なストレージにしか適していません。次は、メインチェーンでのシャーディングとサードパーティDAでのシャーディングを含むシャーディングストレージ方式です。メインチェーンには多くのノードがあることが多く、対応するブロックにはより多くのバックアップがあるため、メインチェーンのシャーディング方式のコストが高くなります。ストレージコストが最も低いのは、報酬ストレージ方式を採用したスト​​レージパブリックチェーンDAであり、この方式のデータ冗長性の量は一定の定数を中心に変動する傾向があります。同時に、ストレージパブリックチェーン DA は動的調整メカニズムも導入し、データのセキュリティを確保するために報酬を増やすことで、ノードがバックアップデータを保存する量を減らすように誘導します。

  • データ読み取り速度: データ保存速度は、主に、データがストレージスペース内のどこに保存されているか、データインデックスパス、およびノー​​ド間のデータの分布によって影響を受けます。その中でも、データがノード内のどこに保存されているかは、速度に大きな影響を与えます。データをメモリまたは SSD に保存すると、読み取り速度が数十倍も異なる可能性があるためです。ストレージパブリックチェーン DA は主に SSD ストレージを採用しています。これは、そのチェーンの負荷には DA レイヤーのデータだけでなく、ユーザーがアップロードしたビデオや画像など、メモリを大量に消費する個人データも含まれるためです。ネットワークがストレージスペースとして SSD を使用していないと、膨大なストレージ圧力に耐え、長期ストレージの需要を満たすことが困難です。第 2 に、メモリ状態を使用してデータを保存するサードパーティ DA およびメインチェーン DA の場合、サードパーティ DA は最初にメインチェーンで対応するインデックス付きデータを検索し、次にインデックス付きデータをチェーン全体でサードパーティ DA に転送し、ストレージブリッジを介してデータを返す必要があります。対照的に、メインチェーン DA はノードから直接データを照会できるため、データ取得速度が速くなります。最後に、メインチェーン DA 内では、シャーディング アプローチでは複数のノードからブロックを呼び出し、元のデータを復元する必要があります。そのため、シャーディングなしの短期ストレージ方式よりも遅くなります。

  • DA レイヤーの普遍性: メインチ​​ェーン DA の普遍性は、ストレージ容量が不足しているパブリック チェーンから、ストレージ容量が不足している別のパブリック チェーンにデータを転送できないため、ほぼゼロです。サードパーティの DA では、ソリューションの汎用性と特定のメインチェーンとの互換性は矛盾する指標です。たとえば、特定のメインチェーン用に設計されたメインチェーン固有の DA ソリューションの場合、その特定のパブリック チェーンに適応するためにノード タイプとネットワーク コンセンサスのレベルで多くの改善が行われているため、これらの改善は他のパブリック チェーンと通信するときに大きな障害となる可能性があります。サードパーティの DA では、ストレージ パブリック チェーン DA は、モジュラー DA よりも汎用性の点で優れています。ストレージ パブリック チェーン DA には、より大きな開発者コミュニティと、さまざまなパブリック チェーンに適応するための拡張機能があります。同時に、ストレージ パブリック チェーン DA は、他のパブリック チェーンから送信された情報を受動的に受信するのではなく、パケット キャプチャを通じてより積極的にデータを取得できます。したがって、独自の方法でデータをエンコードし、データフローの標準化されたストレージを実現し、異なるメインチェーンからのデータ情報の管理を容易にし、ストレージ効率を向上させることができます。

出典: カーネルベンチャーズ

6. 結論

ブロックチェーンは、CryptoからWeb3への変換プロセスを経ており、ブロックチェーン上のプロジェクトが豊富になる一方で、データストレージの問題も生じています。Layer1で非常に多くのプロジェクトを同時に実行できるようにし、GamefiおよびSocialfiプロジェクトのエクスペリエンスを保証するために、Ethereumに代表されるLayer1は、TPSを向上させるためにRollupとBlobsを採用しました。さらに、新生ブロックチェーンの高性能ブロックチェーンの数も増えています。しかし、TPSが高いということは、パフォーマンスが高いことを意味するだけでなく、ネットワークのストレージ圧力が高まることを意味します。膨大な量の履歴データについては、チェーンのストレージ圧力の増加に適応するために、この段階でメインチェーンとサードパーティベースの両方の複数のDAアプローチが提案されています。改善には長所と短所があり、さまざまなコンテキストで異なる適用性があります。履歴データのセキュリティに対する要求が非常に高く、特に高いTPSを追求しない、まだ準備段階にある決済ベースのブロックチェーンの場合、DankShardingのようなストレージ方式を採用することで、セキュリティを確保しながらストレージ容量を大幅に増やすことを実現できます。しかし、すでに形成され、多数のノードを持つビットコインのようなパブリックチェーンの場合、コンセンサス層を性急に改善すると大きなリスクがあるため、オフチェーンストレージでより高いセキュリティを備えたメインチェーン専用のDAを採用することで、セキュリティとストレージの問題のバランスをとることができます。ただし、ブロックチェーンの機能は時間の経過とともに変化していることに留意する必要があります。たとえば、初期のEthereumの機能は、支払いとスマートコントラクトを使用した資産と取引の単純な自動処理に限定されていましたが、ブロックチェーンの環境が拡大するにつれて、さまざまなSocialfiとDefiプロジェクトがEthereumに追加され、より包括的な方向へと押し進められました。ビットコインの登録エコシステムが最近爆発的に成長したことで、ビットコインネットワークの取引手数料は8月以来20倍近く急騰しており、これはネットワークの取引速度が現段階では取引の需要を満たすことができないという事実を反映しています。トレーダーは、取引をできるだけ早く処理するために手数料を引き上げなければなりません。現在、ビットコイン コミュニティは、高い手数料と遅い取引速度を受け入れるか、ネットワーク セキュリティを低下させて取引速度を上げるかというトレードオフを行う必要がありますが、その場合、決済システムの本来の目的が損なわれます。ビットコイン コミュニティが後者を選択した場合、データ プレッシャーの増大に応じてストレージ ソリューションを調整する必要があります。

出典: OKLINK

包括的な機能を備えたパブリックチェーンの場合、TPSの追求度は高く、履歴データの膨大な増加に伴い、DankShardingのようなソリューションを採用することでは、長期的にはTPSの急速な増加に適応することが困難です。そのため、より適切な方法は、データをサードパーティのDAに移行して保存することです。その中でも、メインチェーン固有のDAは互換性が最も高く、単一のパブリックチェーンの保存のみを考えれば、より有利になる可能性があります。しかし、レイヤー1パブリックチェーンが開花している今日では、チェーン間の資産転送とデータ相互作用もブロックチェーンコミュニティの共通の追求となっています。ブロックチェーンエコシステム全体の長期的な発展を考えると、異なるパブリックチェーンの履歴データを同じパブリックチェーンに保存すると、データ交換と検証のプロセスにおける多くのセキュリティ問題を排除できるため、モジュール化されたDAとパブリックチェーンDAの保存方法がより良い選択となる可能性があります。モジュラーDAは、密接な一般性を前提として、ブロックチェーンDAレイヤーサービスの提供に重点を置き、履歴データを管理するためにより洗練されたインデックスデータを導入し、さまざまなパブリックチェーンデータを合理的に分類できるため、ストレージパブリックチェーンと比較して多くの利点があります。ただし、上記の提案では、既存のパブリックチェーン上のコンセンサスレイヤー調整のコストが考慮されておらず、非常にリスクがあります。小さな体系的な抜け穴により、パブリックチェーンがコミュニティのコンセンサスを失う可能性があります。したがって、ブロックチェーン変革のプロセスにおける過渡的なソリューションである場合、メインチェーンでの一時的なストレージの方が適切である可能性があります。最後に、上記のすべての議論は実際の運用中のパフォーマンスに基づいていますが、特定のパブリックチェーンの目標がエコロジーを発展させ、より多くのプロジェクト関係者や参加者を引き付けることである場合は、その財団によってサポートおよび資金提供されているプロジェクトを好む傾向もあります。たとえば、全体的なパフォーマンスがストレージのパブリック チェーン ストレージ ソリューションと同等か、それよりわずかに低い場合、Ethereum コミュニティは、Ethereum エコシステムの継続的な開発のために、Ethereum Foundation がサポートするレイヤー 2 プロジェクトである EthStorage も支持するでしょう。

全体的に見ると、今日のブロックチェーンの複雑さが増すにつれて、ストレージスペースの必要性も高まっています。十分なレイヤー1検証ノードがあれば、履歴データはネットワーク全体のすべてのノードでバックアップする必要はなく、一定のしきい値を超えるとセキュリティを確保できます。同時に、パブリックチェーンの分業はますます細かくなり、レイヤー1はコンセンサスと実行を担当し、ロールアップは計算と検証を担当し、その後、別のブロックチェーンがデータストレージに使用されます。各部分は、他の部分のパフォーマンスに制限されることなく、特定の機能に集中できます。ただし、セキュリティと効率のバランスを実現するために、履歴データを保存できるストレージの具体的な数やノードの割合、および異なるブロックチェーン間の安全な相互運用性をどのように確保するかは、ブロックチェーン開発者が検討する必要がある問題です。投資家は、イーサリアムのメインチェーン固有のDAプロジェクトに注目することができます。イーサリアムは、この段階ですでに十分な支持者を抱えており、他のコミュニティの力を借りて影響力を拡大する必要がないためです。より多くのプロジェクトをイーサリアムエコシステムに引き付けるには、コミュニティの改善と発展がより重要です。しかし、SolanaやAptosなど、追い上げているパブリックチェーンの場合、単一のチェーン自体には完璧なエコシステムがないため、他のコミュニティと力を合わせて大規模なクロスチェーンエコシステムを構築し、影響力を拡大することを好む可能性があります。したがって、台頭しているLayer1では、汎用のサードパーティDAがより注目されるに値します。

Kernel Ventures は、研究および開発コミュニティ主導の暗号通貨 VC ファンドであり、70 を超える初期段階の投資を行っており、インフラストラクチャ、ミドルウェア、dApp、特に ZK、Rollup、DEX、モジュラー ブロックチェーン、およびアカウント抽象化、データ可用性、スケーラビリティなど、暗号通貨の次の 10 億人のユーザーを獲得する垂直分野に重点を置いています。過去 7 年間、私たちは世界中のコア開発コミュニティと大学ブロックチェーン協会の成長をサポートすることに尽力してきました。

参照

  1. Celestia: モジュラーブロックチェーンの星空: https://foresightnews.pro/article/detail/15497

  2. DHT の使用法と今後の作業: https://github.com/celestiaorg/celestia-node/issues/11

  3. セレスティア コア: https://github.com/celestiaorg/celestia-core

  4. Solana ラボ: https://github.com/solana-labs/solana?source=post_page-----cf47a61a9274----------------------- - -------

  5. SOLAR Bridge の発表: https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2

  6. leveldb ハンドブック: https://leveldb-handbook.readthedocs.io/zh/latest/sstable.html

  7. Kuszmaul J. Verkle の木[J]。 Verkle Trees、2019、1:1.: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

  8. Arweave ネットワーク: https://www.arweave.org/

  9. Arweave イエローブック: https://www.arweave.org/yellow-paper.pdf