原作者: チュアン・リン
最初のレベルのタイトル
01. はじめに
Vitalik は、2022 年 11 月 5 日に更新されたイーサリアム ロードマップをリリースしました。2021 年 12 月 2 日にリリースされた以前のロードマップと比較して、サージ フェーズの次のアップデートは間違いなく最も注目すべきものです。
以下の図に示すように、この段階のアップデートでは明らかに詳細が追加されています。「基本的なロールアップ拡張」を達成するために、イーサリアム コミュニティが EIP-4844: Proto-Danksharding を提案したことが明確にわかります。この提案は 2023 年 5 月から 6 月初旬まで実施され、その時点でロールアップのコストは 100 分の 1 に削減され、イーサリアム L2 のユーザー エクスペリエンスが大幅に最適化されます。このような大規模な最適化は、Web3 コミュニティでの議論と注目の焦点になることは間違いありません。
イーサリアムに関連する問題はどこにありますか? EIP-4844 はこの問題を解決するためにどのようなアイデアとソリューションを使用しますか?この記事は、EIP-4844 を簡潔に理解するのに役立ちます。
最初のレベルのタイトル
02. テキスト
1. EIP-4844 の原因: データの可用性によって引き起こされる L2 料金のボトルネック
1.1 L2 と L1 間のデータ通信の現在の基本状況
現在、ほとんどのイーサリアム L2 は基本的な技術ルートとしてロールアップを使用しており、Vitalik 氏はイーサリアムのアップデートについて「ロールアップ中心のロードマップ」とさえ述べており、ロールアップが基本的に L2 の分野を支配していることを示しています。
Rollup オペレーションの基本原理は、トランザクションの束をイーサリアムのメインチェーンの外側で実行し、実行後は実行結果とトランザクションデータそのものを圧縮して L1 に送り返し、他の人がトランザクション結果の正しさを検証できるようにすることです。当然のことながら、他にデータを読み取る方法がない場合は、検証を行うことができません。したがって、生のトランザクション データを他の人が利用できるようにすることは非常に重要であり、「データの可用性」とも呼ばれます。
ただし、イーサリアムの現在のアーキテクチャによる制限により、L2 から L1 に送信されるデータはトランザクションの Calldata に格納されます。ただし、Calldata は、イーサリアムが最初に設計されたときはスマート コントラクト関数呼び出しのパラメーターにすぎず、すべてのノードが同期的にダウンロードする必要があるデータです。 Calldata が拡張すると、イーサリアム ネットワーク ノードに高負荷がかかるため、Calldata のコストは比較的高価になります。これは、現在の L2 料金に寄与する主な要因でもあります。
1.2 問題に対する改善案
読者の皆さんは考えてみてはいかがでしょうか。この問題の最適化計画を立てるように頼まれた場合、どの方向に改善しますか?
実際、L2 のトランザクション圧縮データのアップロードは、他のユーザーがダウンロードして検証できるようにするためだけであり、L1 によって実行される必要はないことがわかります。 Calldata のコストが高い理由は、関数呼び出しのパラメーターとしてデフォルトで L1 で実行される可能性があるため、ネットワーク全体のノードで同期する必要があるためです。
これにより不一致が生じます。たとえば、データを必要とする他の人が一定期間ダウンロードできるように、データをネットワーク ディスクに転送したいだけです。最終的には、私のデータを作成したのはあなたです。ネットワーク全体のブロードキャスト同期です。私には必要のないもので、限られた時間内に全員にダウンロードを完了させることを強制し、その結果、このサービスに対して高額な料金を請求することになります。これは明らかに不適切であり、改善が必要です。
では、どうすれば改善できるのでしょうか？L2 から渡されるデータに対して別のデータ型を設計し、L1 の Calldata から分離することができます。このタイプのデータは、一定期間内にそれを必要とする他の人がアクセスしてダウンロードできるようにするだけでよく、ネットワーク全体を同期する必要はありません。実際、この点はイーサリアム技術コミュニティの多くのメンバーも考えてきました。
EIP-4844 の改良は実際にこの文脈を中心に行われています。
2. EIP-4844 の核心: BLOB を使用したトランザクション
EIP-4844 の機能を一文で要約すると、次のようになります。「BLOB を使用したトランザクション」この新しいトランザクション タイプ。 Blob は、前述の L2 データ送信用に特別に設計されたデータ型です。
したがって、blob の詳細を明確に理解できれば、EIP-4844 を基本的に理解していると言えます。
2.1 BLOB オントロジー: L2 圧縮データを配置するために使用され、コンセンサス層のノードに保存される「ビッグ データ ブロック」
Blob という名前は実際には Binary Large Object の略語で、直訳すると「バイナリの大きなデータ ブロック」となります。これは、L2 の元のトランザクションの圧縮データを運ぶように設計されており、これは、L2 のデータを以前は Calldata に置き、今回は Blob に入れるのと同じです。 Calldata と比較すると、Blob のデータ サイズは最大 125 KB と非常に大きくなる可能性があります。
BLOB は、Calldata のようなメイン チェーンに直接アップロードされるのではなく、コンセンサス レイヤーのノードによって保存されます。これにより、BLOB の 2 つのコア機能も提供されます。
Calldata のような EVM では読み取れません
有効期間があり、30 日後に削除されます
より詳細に説明すると、Blob 自体は 4096 個の要素から構成されるベクトル (Vector) です。このベクトルの各次元は、0 ～ 52435875175126190477474050818596525252527637826036999938584513 の範囲を持つ非常に大きな数です。この非常に大きな数は品質の数であり、楕円形と楕円形です。曲線 - アルゴリズム アルゴリズムに関連します。
そして、このベクトルの各次元の番号は、4096 次以下の有限体多項式の各係数とみなすことができます。たとえば、i 番目の次元の番号は w^i の前の係数です。ここで、w は定数であり、w^4096 = 1 を満たします。この構造は、KZG 多項式コミットメントの生成を容易にするように設計されています。
2.2 Blob: Sidecar に関連するアーキテクチャ設計
BLOB アーキテクチャを理解する前に、実行ペイロードという概念を説明する必要があります。イーサリアムの合併後、コンセンサス層と実行層が分離されました。これらは 2 つの主要な機能を担当します。前者は PoS コンセンサスを担当し、後者は EVM を実行します。実行ペイロードは、単純に EL 層の通常の L1 トランザクションと考えることができます。
Blob と現在のイーサリアム アーキテクチャの統合は、次のようにオートバイの車体とオートバイのサイドカー (サイドカー) の関係に例えることができます: (左側のものはオートバイのサイドカーです)
サイドカー（オートバイのサイドカー）は公式の比喩です。その意味は、実際には、Blob の動作はメインチェーンに依存しますが、ある程度メインチェーンと並行しており、かなりの独立性を持っているということです。
以下の図に示すように、このメタファーをよりよく理解するために、Blob に関連する実行プロセスを見てみましょう。
まず、L2 シーケンサーがトランザクションを決定し、トランザクションの結果と関連するプルーフ (黄色の部分) およびデータ パケット (Blob、青色の部分) を L1 のトランザクション プールに送信します。
L1 ノード (ビーコン プロポーザー) はトランザクションを認識し、新しいブロック提案 (ビーコン ブロック) で関連するトランザクションを実行し、それをブロードキャストします。ただし、ブロードキャストの際、Blob を分離してコンセンサス層 CL に残します。それを実行層の新しいブロックに置きます
他の L1 ノード (ビーコン ピア) は、新しいブロック提案とトランザクション結果を受け取ります。 L2 バリデーターになる必要がある場合は、Blobs Sidecar に移動して関連データをダウンロードできます。
以下の図は、別の観点から見た BLOB ライフ サイクルを示しています。BLOB データは L1 メイン チェーンにはアップロードされず、コンセンサス レイヤー ノードにのみ存在し、異なるライフ サイクルを持つことが明確にわかります。 。
したがって、Blob が EVM、つまり L1 スマート コントラクトによって直接読み取れない理由を理解するのは難しくありません。読み取れるのは、実行層に渡されるものです。Blob はコンセンサス層にのみ存在するため、今はそのような機能はないはずです。実際、この分離によりロールアップ コストを削減できるのです。
2.3 Blob Storage: 新しい料金市場
前述したように、BLOB データはコンセンサス レイヤー ノードに保存され、ライフサイクルがあります。しかし、明らかにこのサービスは無料ではないため、L1 ガス料金とは独立した新しい料金市場をもたらすことになります。これは、Vitalik が提唱する多次元料金市場でもあります。この手数料マーケットの関連詳細は、現在も繰り返し改善されています。詳細については、Github の関連するディスカッションと更新を参照してください: https://github.com/ethereum/EIPs/pull/5707
さらに、ノード レベルでこれらのデータを短期間しか保存できない場合、長期保存を実現するにはどうすればよいでしょうか?この点に関して、ヴィタリック氏は、実際には多くの解決策があると述べました。ここでのセキュリティの前提条件はそれほど厳しいものではないため、誰かが実際のデータの保存を完了できる限り、これは「1/N 信頼モデル」となります。大規模ストレージ ハードウェアのコストが TB あたりわずか 20 ドルである現在、年間 2.5 TB のデータ ストレージは、希望する人にとっては小さな問題です。さらに、他のさまざまな分散ストレージソリューションもオプションになりますが、Vitalik氏はここで特定のプロジェクトについては言及しませんでした。
3. EIP-4844の影響
アーキテクチャ レベルでは、EIP-4844 は新しいトランザクション タイプである Blob-carrying Transaction を導入します。これは、イーサリアムが L2 用に別個のデータ層を構築したのは初めてであり、フル ダンクシャーディングの実現の最初のステップでもあります。
経済モデル レベルでは、EIP-4844 は BLOB の新しい手数料市場を導入します。これは、イーサリアムが多次元市場に向けて移行する最初のステップでもあります。
ユーザー エクスペリエンス レベルで、ユーザーが最も直感的に認識するのは、L2 料金の大幅な削減であり、最下層でのこの重要な改善は、L2 とそのアプリケーション層の爆発的な増加に重要な基盤を提供することになります。
4. EIP-4844 後の見通し: 完全なダンクシャルディング
現在のところ、EIP-4844 は明らかにイーサリアム上海アップグレード シリーズに含まれており、現在のコミュニティ メンバーから提供されたスケジュールによると、来年 5 月から 6 月初旬に完了する予定です。
そして、EIP-4844はまさに「Proto-Danksharding」、つまりダンクシャーディングの原型を意味します。 Danksharing のフルバージョンの概念は下図に示されており、各ノードは Data Availability Sampling を通じて L2 データの正確性を直接検証できます。これにより、L2 のセキュリティとパフォーマンスがさらに向上します。
