データの可用性は、ブロックチェーンの拡張における主なボトルネックの 1 つです。
**作成者: **zer0kn0wledge.era
編集者: ケイト、マースビット
注: この記事は @ChaosDAO の研究者である @expctchaos Twitter からのものであり、元のツイートの内容は MarsBit によって次のように整理されています。
0/ データ可用性 (DA) がスケーリングの主なボトルネックです
幸いなことに、@CelestiaOrg、@AvailProject、@eigenlayer が DA ゲームを変え、新たなレベルのスケーラビリティを可能にするでしょう。
しかし、それはどのように機能するのでしょうか?また、#EigenDA は #Celestia や #Avail などの DA 15 とどう違うのでしょうか?
1/ データの可用性の問題について詳しくない場合は、データの可用性の状況について詳しく説明した以下の投稿をご覧ください 👇
2/ 一般に、データ処理ソリューションには主に 2 つのタイプがあります
3/ そして、「純粋な有効性検証」とは、オフチェーン データ サービス プロバイダがいつでもオフラインになる可能性があるため、データ処理が保証なしでオフチェーンで行われることを意味します...
4/ …#StarkEx、#zkPorter、#Arbitrum Nova は、データの可用性を保証する有名なサードパーティのグループである DAC に依存する検証シナリオの例です。
5/ 一方、#EigenDA、@CelestiaOrg、@AvailProject は、ユニバーサル DA ソリューションと呼べるものです。
ただし、EigenDA と他の 2 つのソリューションの間にはいくつかの違いがあります。
6/ @CelestiaOrg がどのように機能するかを知りたい場合は、以下のリンクをチェックしてください。
7/ 過去に @AvailProject についても取り上げたことがあります。詳しくは、こちらをご覧ください。
8/ @eigenlayer について復習が必要な場合は、以下のスレッドをチェックしてください 👇
9/ したがって、今日の投稿では、@eigenlayer の #EigenDA と、@CelestiaOrg や @AvailProject などの DA L1 チェーンの比較に焦点を当てたいと思います。
10/ イーサリアムをベースにし、DA に Celestia (別名 Celestium) を使用したロールアップを想定してみましょう。
したがって、イーサリアム上の L2 コントラクトは通常どおり有効性の証明または詐欺の証明を検証し、DA は Celestia によって提供されます。
11/ @CelestiaOrg と @AvailProject では、スマート コントラクトや計算はなく、データのみが利用可能であることが保証されています
12/ でも、よく見てみましょう
@CelestiaOrg では、TX データが L2 ソーターによって Celestia に公開され、Celestia 検証者が DA 証明のマークル ルートに署名し、検証と保存のためにイーサリアム上の DA ブリッジ コントラクトに送信されます。
13/ DA をオンチェーンに保存する場合と比較して、これにより強力な DA 保証のコストが大幅に削減され、同時に (集中型 DAC ではなく) Celestia からのセキュリティ保証も提供されます。
14/ コスト削減により、ロールアップ フィールド全体のルールが変わります。イーサリアム L1 にデータを公開することで生成されるコールデータのコストがロールアップ コストの 80 ～ 90% を占めるためです。
通話データ料金の詳細については、以下の投稿をご覧ください 👇
15/ しかし #Celestia で一体何が起こったのでしょうか?
@CelestiaOrg に投稿されたデータ BLOB (基本的に生データとして) は P2P ネットワークを通じて伝播され、Tendermint コンセンサスを使用してデータ BLOB に関するコンセンサスが得られます。
16/ すべての #Celestia フル ノードは、データ BLOB 全体をダウンロードする必要があります。これは、データ可用性サンプリング (DAS) を使用してデータの可用性を確保できるライト ノードの場合とは異なります。
17/ DAS とライトノードの詳細については、以下の投稿を確認してください。
18/ このスレッドの後半で DAS にも戻りますが、今のところは完全なノードに焦点を当てています。
@CelestiaOrg の話に戻ります。@CelestiaOrg はブロードキャストとデータ BLOB のコンセンサスに依存して、L1 方式で動作し続けます。
19/ したがって、ネットワークのノード全体に高い要求が課せられます (ダウンロード 128 MB/秒、アップロード 12.5 MB/秒)。
それでも、@CelestiaOrg は開始時に中程度のスループット (1.4 MB/秒) を目指していましたが、ノード全体の要件を考慮すると低いように思えます。
20/ ただし、ネットワークはライト ノードを追加することでスループットを拡張できます。データサンプリングするライトノードが多いほど、セキュリティと分散化を確保する条件下でブロックサイズを大きくすることができます。
21/ 一方、@eigenlayer には異なるアーキテクチャがあり、独自のコンセンサスがなく、ピアツーピア ネットワークもありません。
では、これはどのように機能するのでしょうか?
まず、EigenDA ノードは @eigenlayer コントラクトで $ETH を再割り当てする必要があります。したがって、#EigenDA ノードは Ethereum バリデーターのサブセットです
22/ データ BLOB を受信した後、DA 購入者 (分散者とも呼ばれるロールアップなど) はそれを消去コードでエンコードし、KZG コミットメントを生成します。
23/…プルーフサイズは消去コードの冗長率に依存し、#EigenDA スマートコントラクトに対する KZG のコミットメントを公開します
24/ エンコードされた KZG コミットメントがディスパーサーによって #EigenDA ノードに配布される
KZGコミットメントを受信した後、これらのノードはそれをEigenDAスマートコントラクトのKZGコミットメントと比較し、確認後に証明に署名します。
25/ その後、分散者はこれらの署名を 1 つずつ収集し、集約された署名を生成して #EigenDA スマート コントラクトに公開し、スマート コントラクトは署名を検証します
26/ しかし、#EigenDA ノードが単にこのワークフローでエンコードされたデータ BLOB を保存したと主張する証明に署名し、EigenDA スマート コントラクトが集約された署名の正確性のみを検証する場合、EigenDA ノードが実際にデータを保存したことをどうやって確認できるでしょうか?
27/ #EigenDA はこれを達成するためにエスクロープルーフ方式を使用しています
しかし、一歩下がって、それが重要になるこのシーンを見てみましょう
28/ 一部の遅延バリデーターが、割り当てられたタスク (データが利用可能であることの確認など) を実行していないとしましょう。
代わりに、作業を完了したふりをして、最終結果を承認します (データが利用できない場合に、データの利用可能性を偽って報告します)。
29/ 概念的には、保護の証拠は詐欺の証拠に似ています。
誰でも証明 (検証者遅延) を #EigenDA スマート コントラクトに送信でき、スマート コントラクトによって検証されます。
29/ 検証が成功した場合、遅延バリデーターはスラッシュされます (客観的に原因が考えられるエラーであるため)
30/ コンセンサスについてはどうですか?
@CelestiaOrg は、単一スロットのファイナリティを持つコンセンサス プロトコルとして Tendermint を使用します。つまり、ブロックが #Celestia コンセンサスを通過すると、完了です。これは、ファイナリティが基本的にブロック時間 (15 秒) と同じくらい速いことを意味します。
31/ @AvailProject はプロトコル構成を使用してファイナリティを達成します。 BABEは確率的ファイナリティを持ったブロック生成機構、GRANDPAはファイナルガジェットです。 GRANDPA は 1 つのスロットでブロックを完了できますが、ラウンドで複数のブロックを完了することもできます。
32/ @eigenlayer はイーサリアム上の一連のスマート コントラクトであるため、データの可用性を証明するためにロールアップ コントラクトに転送する必要があるデータについては、イーサリアムと同じファイナライゼーション時間 (12 ～ 15 分) も継承します。
33/ ただし、ロールアップで @eigenlayer を使用する場合は、使用するコンセンサス メカニズムなどに応じて、より高速に実行できる可能性があります。
さらに、@eigenlayer の再ステーキングバリデーターによって保護されたミドルウェア (EigenSettle など) は、迅速な決済の提供に重点を置いており、ファイナリティの事前確認を可能にする強力な経済的セキュリティ保証を提供できます。ただし、ハードファイナリティ保証は依然としてイーサリアム L1 から提供されます。
34/ データ可用性サンプリングの概念を再検討する時期
ほとんどのブロックチェーンでは、ノードはすべてのトランザクション データをダウンロードして、データの可用性を確認する必要があります。これにより生じる問題は、ブロック サイズが増加すると、検証する必要があるデータ ノードの数も増加することです。
35/ データ可用性サンプリング (DAS) は、ブロック データのごく一部のみをダウンロードすることで、ライト ノードがデータの可用性を検証できるようにする技術です。
36/ これにより、ライトノードにセキュリティが提供され、無効なブロック (DA とコンセンサスのみ) を検証できるようになり、ノード要件を増やすことなくブロックチェーンがデータの可用性を拡張できるようになります。
37/ DAS には、少なくとも 1 つの正直なフル ノードと十分な数のライト クライアントが必要です
38/ しかし、ライトノードのセキュリティを確保するにはどうすればよいでしょうか?
従来のライト クライアントはブロック ヘッダーのみを検証するため、フル ノードに比べてセキュリティの前提が弱くなります。
したがって、ライト クライアントは、無効なブロックが不誠実な大多数のブロック プロデューサーによって作成されたかどうかを検出できません。
39/ データ可用性サンプリングを備えたライトノードは、DA 層がコンセンサスとデータ可用性のみを実行する場合、無効なブロックが生成されているかどうかを検証できるため、セキュリティがアップグレードされます。
40/ @CelestiaOrg と @AvailProject は両方ともデータ可用性サンプリングを行うため、ライト ノードは信頼を最小限に抑えたセキュリティを備えます。
41/ これはイーサリアムや @eigenlayer とは異なります
#EIP4844 のイーサリアムにはデータ可用性サンプリングがないため、ライトクライアントには信頼を最小限に抑えたセキュリティがありません
42/ イーサリアムにもスマート コントラクト環境があるため、ライト クライアントは、誠実さのほとんどの前提に依存するのではなく、実行を検証する必要もあります (詐欺または有効性の証明によって)。
43/ @eigenlayer (DAS がない限り) ライト クライアントがサポートされている場合、再ステーキング ノードの正直な大多数に依存します。
したがって、#EigenDA のセキュリティは主にイーサリアムバリデータセットに基づいており、イーサリアムスラッシュプリミティブを継承し、DA の経済的安全性を確保します。
44/ したがって、#EigenDA への関係者の参加が増えるということは、セキュリティが強化されることを意味します。ノード要件の削減は、分散化の向上にも貢献します
45/ イレイジャーコーディングは、データの可用性サンプリングを可能にする重要なメカニズムです。イレイジャーコーディングは、データの追加コピーを作成することによってブロックを拡張します。データを追加すると冗長性が生まれ、サンプリング プロセスのセキュリティが強化されます。
46/ ただし、ノードはネットワークを中断するためにデータを誤ってエンコードしようとする場合があります。この攻撃を防ぐには、ノードはエンコードが正しいことを検証する方法が必要です。ここで証明が必要になります。
47/ Ethereum、@eigenlayer、@AvailProject はすべて、ブロックが正しくエンコードされていることを保証するために、有効性証明スキームを使用しています。この考え方は、zk ロールアップで使用される有効性証明に似ています。 @eigenlayer がこのスレッドの前半でこれについて議論しました
48/ ブロックが生成されるたびに、検証者は、ブロックが正しくエンコードされていることを証明するために、KZG 証明を使用してノードによって検証されたデータにコミットする必要があります。
49/ KZG 証明のコミットメントの生成には、ブロックプロデューサーにとってより多くの計算オーバーヘッドが必要ですが、ブロックが小さい場合、コミットメントの生成は大きなオーバーヘッドをもたらしません。しかし、これは変わりました...
50/… ブロックが大きくなるにつれて、KZG 証明のコミットメントの負担がはるかに大きくなります
したがって、これらのコミットメントの生成を担当するノードのタイプには、より高いハードウェア要件が必要になる可能性があります。
51/ 一方、@CelestiaOrg はイレイジャーコーディングの不正証明を実装しています。したがって、#Celestia ノードはブロックが正しくエンコードされていることを確認する必要はありません。彼らはデフォルトでそれが正しいと設定します
52/ 利点は、ブロックプロデューサーが消去符号化されたコミットメントを生成するという高価な作業を行う必要がないことです。
ただし、ライトノードは、ブロックが正しくエンコードされているとみなしてビュー内で完了するまで、少し待つ必要があるため、トレードオフがあります。
53/ 不正防止エンコーディング スキームと正当性プルーフ エンコーディング スキームの主な違いは、コミットメントを生成するためのノードのオーバーヘッドとライト ノードのレイテンシーとの間のトレードオフです。
54/ この表は比較をうまくまとめています
231k 投稿
199k 投稿
147k 投稿
80k 投稿
66k 投稿
64k 投稿
61k 投稿
58k 投稿
52k 投稿
51k 投稿
データ可用性ソリューションはどのように機能し、どのように異なるのでしょうか?
**作成者: **zer0kn0wledge.era
編集者: ケイト、マースビット
注: この記事は @ChaosDAO の研究者である @expctchaos Twitter からのものであり、元のツイートの内容は MarsBit によって次のように整理されています。
0/ データ可用性 (DA) がスケーリングの主なボトルネックです
幸いなことに、@CelestiaOrg、@AvailProject、@eigenlayer が DA ゲームを変え、新たなレベルのスケーラビリティを可能にするでしょう。
しかし、それはどのように機能するのでしょうか?また、#EigenDA は #Celestia や #Avail などの DA 15 とどう違うのでしょうか?
1/ データの可用性の問題について詳しくない場合は、データの可用性の状況について詳しく説明した以下の投稿をご覧ください 👇
2/ 一般に、データ処理ソリューションには主に 2 つのタイプがあります
3/ そして、「純粋な有効性検証」とは、オフチェーン データ サービス プロバイダがいつでもオフラインになる可能性があるため、データ処理が保証なしでオフチェーンで行われることを意味します...
4/ …#StarkEx、#zkPorter、#Arbitrum Nova は、データの可用性を保証する有名なサードパーティのグループである DAC に依存する検証シナリオの例です。
5/ 一方、#EigenDA、@CelestiaOrg、@AvailProject は、ユニバーサル DA ソリューションと呼べるものです。
ただし、EigenDA と他の 2 つのソリューションの間にはいくつかの違いがあります。
6/ @CelestiaOrg がどのように機能するかを知りたい場合は、以下のリンクをチェックしてください。
7/ 過去に @AvailProject についても取り上げたことがあります。詳しくは、こちらをご覧ください。
8/ @eigenlayer について復習が必要な場合は、以下のスレッドをチェックしてください 👇
9/ したがって、今日の投稿では、@eigenlayer の #EigenDA と、@CelestiaOrg や @AvailProject などの DA L1 チェーンの比較に焦点を当てたいと思います。
10/ イーサリアムをベースにし、DA に Celestia (別名 Celestium) を使用したロールアップを想定してみましょう。
したがって、イーサリアム上の L2 コントラクトは通常どおり有効性の証明または詐欺の証明を検証し、DA は Celestia によって提供されます。
11/ @CelestiaOrg と @AvailProject では、スマート コントラクトや計算はなく、データのみが利用可能であることが保証されています
12/ でも、よく見てみましょう
@CelestiaOrg では、TX データが L2 ソーターによって Celestia に公開され、Celestia 検証者が DA 証明のマークル ルートに署名し、検証と保存のためにイーサリアム上の DA ブリッジ コントラクトに送信されます。
13/ DA をオンチェーンに保存する場合と比較して、これにより強力な DA 保証のコストが大幅に削減され、同時に (集中型 DAC ではなく) Celestia からのセキュリティ保証も提供されます。
14/ コスト削減により、ロールアップ フィールド全体のルールが変わります。イーサリアム L1 にデータを公開することで生成されるコールデータのコストがロールアップ コストの 80 ～ 90% を占めるためです。
通話データ料金の詳細については、以下の投稿をご覧ください 👇
15/ しかし #Celestia で一体何が起こったのでしょうか?
@CelestiaOrg に投稿されたデータ BLOB (基本的に生データとして) は P2P ネットワークを通じて伝播され、Tendermint コンセンサスを使用してデータ BLOB に関するコンセンサスが得られます。
16/ すべての #Celestia フル ノードは、データ BLOB 全体をダウンロードする必要があります。これは、データ可用性サンプリング (DAS) を使用してデータの可用性を確保できるライト ノードの場合とは異なります。
17/ DAS とライトノードの詳細については、以下の投稿を確認してください。
18/ このスレッドの後半で DAS にも戻りますが、今のところは完全なノードに焦点を当てています。
@CelestiaOrg の話に戻ります。@CelestiaOrg はブロードキャストとデータ BLOB のコンセンサスに依存して、L1 方式で動作し続けます。
19/ したがって、ネットワークのノード全体に高い要求が課せられます (ダウンロード 128 MB/秒、アップロード 12.5 MB/秒)。
それでも、@CelestiaOrg は開始時に中程度のスループット (1.4 MB/秒) を目指していましたが、ノード全体の要件を考慮すると低いように思えます。
20/ ただし、ネットワークはライト ノードを追加することでスループットを拡張できます。データサンプリングするライトノードが多いほど、セキュリティと分散化を確保する条件下でブロックサイズを大きくすることができます。
21/ 一方、@eigenlayer には異なるアーキテクチャがあり、独自のコンセンサスがなく、ピアツーピア ネットワークもありません。
では、これはどのように機能するのでしょうか?
まず、EigenDA ノードは @eigenlayer コントラクトで $ETH を再割り当てする必要があります。したがって、#EigenDA ノードは Ethereum バリデーターのサブセットです
22/ データ BLOB を受信した後、DA 購入者 (分散者とも呼ばれるロールアップなど) はそれを消去コードでエンコードし、KZG コミットメントを生成します。
23/…プルーフサイズは消去コードの冗長率に依存し、#EigenDA スマートコントラクトに対する KZG のコミットメントを公開します
24/ エンコードされた KZG コミットメントがディスパーサーによって #EigenDA ノードに配布される
KZGコミットメントを受信した後、これらのノードはそれをEigenDAスマートコントラクトのKZGコミットメントと比較し、確認後に証明に署名します。
25/ その後、分散者はこれらの署名を 1 つずつ収集し、集約された署名を生成して #EigenDA スマート コントラクトに公開し、スマート コントラクトは署名を検証します
26/ しかし、#EigenDA ノードが単にこのワークフローでエンコードされたデータ BLOB を保存したと主張する証明に署名し、EigenDA スマート コントラクトが集約された署名の正確性のみを検証する場合、EigenDA ノードが実際にデータを保存したことをどうやって確認できるでしょうか?
27/ #EigenDA はこれを達成するためにエスクロープルーフ方式を使用しています
しかし、一歩下がって、それが重要になるこのシーンを見てみましょう
28/ 一部の遅延バリデーターが、割り当てられたタスク (データが利用可能であることの確認など) を実行していないとしましょう。
代わりに、作業を完了したふりをして、最終結果を承認します (データが利用できない場合に、データの利用可能性を偽って報告します)。
29/ 概念的には、保護の証拠は詐欺の証拠に似ています。
誰でも証明 (検証者遅延) を #EigenDA スマート コントラクトに送信でき、スマート コントラクトによって検証されます。
29/ 検証が成功した場合、遅延バリデーターはスラッシュされます (客観的に原因が考えられるエラーであるため)
30/ コンセンサスについてはどうですか?
@CelestiaOrg は、単一スロットのファイナリティを持つコンセンサス プロトコルとして Tendermint を使用します。つまり、ブロックが #Celestia コンセンサスを通過すると、完了です。これは、ファイナリティが基本的にブロック時間 (15 秒) と同じくらい速いことを意味します。
31/ @AvailProject はプロトコル構成を使用してファイナリティを達成します。 BABEは確率的ファイナリティを持ったブロック生成機構、GRANDPAはファイナルガジェットです。 GRANDPA は 1 つのスロットでブロックを完了できますが、ラウンドで複数のブロックを完了することもできます。
32/ @eigenlayer はイーサリアム上の一連のスマート コントラクトであるため、データの可用性を証明するためにロールアップ コントラクトに転送する必要があるデータについては、イーサリアムと同じファイナライゼーション時間 (12 ～ 15 分) も継承します。
33/ ただし、ロールアップで @eigenlayer を使用する場合は、使用するコンセンサス メカニズムなどに応じて、より高速に実行できる可能性があります。
さらに、@eigenlayer の再ステーキングバリデーターによって保護されたミドルウェア (EigenSettle など) は、迅速な決済の提供に重点を置いており、ファイナリティの事前確認を可能にする強力な経済的セキュリティ保証を提供できます。ただし、ハードファイナリティ保証は依然としてイーサリアム L1 から提供されます。
34/ データ可用性サンプリングの概念を再検討する時期
ほとんどのブロックチェーンでは、ノードはすべてのトランザクション データをダウンロードして、データの可用性を確認する必要があります。これにより生じる問題は、ブロック サイズが増加すると、検証する必要があるデータ ノードの数も増加することです。
35/ データ可用性サンプリング (DAS) は、ブロック データのごく一部のみをダウンロードすることで、ライト ノードがデータの可用性を検証できるようにする技術です。
36/ これにより、ライトノードにセキュリティが提供され、無効なブロック (DA とコンセンサスのみ) を検証できるようになり、ノード要件を増やすことなくブロックチェーンがデータの可用性を拡張できるようになります。
37/ DAS には、少なくとも 1 つの正直なフル ノードと十分な数のライト クライアントが必要です
38/ しかし、ライトノードのセキュリティを確保するにはどうすればよいでしょうか?
従来のライト クライアントはブロック ヘッダーのみを検証するため、フル ノードに比べてセキュリティの前提が弱くなります。
したがって、ライト クライアントは、無効なブロックが不誠実な大多数のブロック プロデューサーによって作成されたかどうかを検出できません。
39/ データ可用性サンプリングを備えたライトノードは、DA 層がコンセンサスとデータ可用性のみを実行する場合、無効なブロックが生成されているかどうかを検証できるため、セキュリティがアップグレードされます。
40/ @CelestiaOrg と @AvailProject は両方ともデータ可用性サンプリングを行うため、ライト ノードは信頼を最小限に抑えたセキュリティを備えます。
41/ これはイーサリアムや @eigenlayer とは異なります
#EIP4844 のイーサリアムにはデータ可用性サンプリングがないため、ライトクライアントには信頼を最小限に抑えたセキュリティがありません
42/ イーサリアムにもスマート コントラクト環境があるため、ライト クライアントは、誠実さのほとんどの前提に依存するのではなく、実行を検証する必要もあります (詐欺または有効性の証明によって)。
43/ @eigenlayer (DAS がない限り) ライト クライアントがサポートされている場合、再ステーキング ノードの正直な大多数に依存します。
したがって、#EigenDA のセキュリティは主にイーサリアムバリデータセットに基づいており、イーサリアムスラッシュプリミティブを継承し、DA の経済的安全性を確保します。
44/ したがって、#EigenDA への関係者の参加が増えるということは、セキュリティが強化されることを意味します。ノード要件の削減は、分散化の向上にも貢献します
45/ イレイジャーコーディングは、データの可用性サンプリングを可能にする重要なメカニズムです。イレイジャーコーディングは、データの追加コピーを作成することによってブロックを拡張します。データを追加すると冗長性が生まれ、サンプリング プロセスのセキュリティが強化されます。
46/ ただし、ノードはネットワークを中断するためにデータを誤ってエンコードしようとする場合があります。この攻撃を防ぐには、ノードはエンコードが正しいことを検証する方法が必要です。ここで証明が必要になります。
47/ Ethereum、@eigenlayer、@AvailProject はすべて、ブロックが正しくエンコードされていることを保証するために、有効性証明スキームを使用しています。この考え方は、zk ロールアップで使用される有効性証明に似ています。 @eigenlayer がこのスレッドの前半でこれについて議論しました
48/ ブロックが生成されるたびに、検証者は、ブロックが正しくエンコードされていることを証明するために、KZG 証明を使用してノードによって検証されたデータにコミットする必要があります。
49/ KZG 証明のコミットメントの生成には、ブロックプロデューサーにとってより多くの計算オーバーヘッドが必要ですが、ブロックが小さい場合、コミットメントの生成は大きなオーバーヘッドをもたらしません。しかし、これは変わりました...
50/… ブロックが大きくなるにつれて、KZG 証明のコミットメントの負担がはるかに大きくなります
したがって、これらのコミットメントの生成を担当するノードのタイプには、より高いハードウェア要件が必要になる可能性があります。
51/ 一方、@CelestiaOrg はイレイジャーコーディングの不正証明を実装しています。したがって、#Celestia ノードはブロックが正しくエンコードされていることを確認する必要はありません。彼らはデフォルトでそれが正しいと設定します
52/ 利点は、ブロックプロデューサーが消去符号化されたコミットメントを生成するという高価な作業を行う必要がないことです。
ただし、ライトノードは、ブロックが正しくエンコードされているとみなしてビュー内で完了するまで、少し待つ必要があるため、トレードオフがあります。
53/ 不正防止エンコーディング スキームと正当性プルーフ エンコーディング スキームの主な違いは、コミットメントを生成するためのノードのオーバーヘッドとライト ノードのレイテンシーとの間のトレードオフです。
54/ この表は比較をうまくまとめています