EIP-4844の深層解読：Layer2の費用を100倍削減する方法は？
EIP-4844はどのような考え方と方案でGAS問題を解決していますか？原文作者：Chuan Lin
原文来源：A\&T Capital
01、引子
Vitalikは2022年11月5日に更新されたEthereumのロードマップを発表しました。これは2021年12月2日に発表された以前のロードマップと比較して、間もなく来るThe Surge段階の更新が間違いなく最も注目すべき点です。
以下の図に示すように、この段階の更新は明らかにより多くの詳細を追加しています ------ 私たちは明確に見ることができます。 "基本的なRollupスケーリング"を実現するために、EthereumコミュニティはEIP-4844：Proto-Dankshardingを提案しました。この提案は2023年5月から6月初旬に実施される予定で、その時点でRollupの費用は100倍に削減され、Ethereum L2のユーザー体験が大幅に改善されるでしょう。このような大きな最適化は、Web3コミュニティの議論と関心の焦点となることは間違いありません。
Ethereumに関連する問題はどこにあるのか？EIP-4844はどのような考え方と計画でこの問題を解決するのか？この記事は、EIP-4844を簡潔に理解する手助けをします。
Ethereumの基盤となるアーキテクチャの更新に追いつき、コミュニティの議論をリアルタイムで把握したい場合は、この記事をお見逃しなく！
02、正文
一、EIP-4844の起源：データの可用性によるL2費用のボトルネック
1.1 現在のL2とL1のデータ相互作用の基本状況
現在、Ethereum L2はほとんどがRollupを基本技術路線としており、VitalikはEthereumの更新を"A Rollup-Centric Roadmap"と表現しています。これはRollupがL2の世界をほぼ支配していることを示しています。
Rollupの基本的な原理は、一束の取引をEthereumメインチェーンの外で実行し、実行後に実行結果と取引データ自体を圧縮してL1に戻すことで、他の人が取引結果の正確性を検証できるようにすることです。明らかに、他の人がデータを読み取れない場合、検証を完了することはできません。したがって、他の人が取引の原始データを取得できることは非常に重要であり、これは「データの可用性」（Data Availability）とも呼ばれます。
しかし、Ethereumの現在のアーキテクチャに制約されて、L2からL1に送信されるデータは、取引のCalldataに保存されています。しかし、CalldataはEthereumの最初の設計時には単なるスマートコントラクト関数呼び出しのパラメータであり、すべてのノードが同期してダウンロードする必要があるデータです。Calldataが膨張すると、Ethereumネットワークノードに高負荷をもたらすため、Calldataの費用は比較的高価です。これが現在のL2費用の主な要因でもあります。
1.2 問題の改善思路
読者は考えてみてください。この問題に対して最適化の提案を設計するなら、どの方向に改善を進めますか？
実際、私たちはL2の取引圧縮データのアップロードは、他の人がダウンロードして検証できるようにするためだけであり、L1で実行される必要はないことを観察できます。そして、Calldataの費用が高い理由は、それが関数呼び出しのパラメータとして、デフォルトでL1で実行される可能性があるため、全ネットワークのノードが同期する必要があるからです。
これが不一致を引き起こします：たとえば、私はデータをネットワークドライブにアップロードして、必要な他の人が一定期間内にダウンロードできるようにしたいだけなのに、あなたは私のデータを全ネットワークにブロードキャストして、すべての人が制限時間内にダウンロードを完了する必要があると強制し、そのサービスのために私に高額な料金を請求することになります。これは明らかに不適切であり、改善が必要です。
では、どう改善するのでしょうか？私たちはL2から送られたデータを別のデータタイプとして設計し、L1のCalldataとは分けることができます。このデータタイプは、一定期間内に必要な他の人がアクセスしてダウンロードできることを満たすだけで、全ネットワークの同期を必要としません。実際、これも多くのEthereum技術コミュニティのメンバーによって考えられています。
EIP-4844の改善は、実際にこの流れに沿って行われています。
二、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のデータサイズは非常に大きく、最大125KBに達することができます。
Blobはコンセンサス層のノードによって保存され、Calldataのように直接メインチェーンに上がることはありません。これにより、Blobには2つの核心的な特徴があります：
CalldataのようにEVMによって読み取ることはできない
ライフサイクルがあり、30日後に削除される
さらに詳細に言うと、Blob自体は4096個の要素から構成されるベクトル（Vector）です。このベクトルの各次元は非常に大きな数字であり、0から52435875175126190479447740508185965837690552500527637822603658699938581184513の範囲にあります ------ この非常に大きな数字は素数であり、楕円曲線暗号アルゴリズムに関連しています。
このベクトルの各次元の数字は、4096階以下の有限体多項式の各係数と見なすことができ、たとえば第i次元の数字はw^iの前の係数であり、ここでwは定数でw^4096 = 1を満たします。この構造設計は、KZG多項式コミットメントの生成を容易にするためのものです。
2.2 Blobに関連するアーキテクチャ設計：Sidecar
Blobアーキテクチャを理解する前に、1つの概念を説明する必要があります：Execution Payload（実行ペイロード）。Ethereumのマージ後、Consensys LayerとExecution Layerに分かれ、それぞれが2つの主要な機能を担当しています：前者はPoSコンセンサスを担当し、後者はEVMを実行します。Execution Payloadは、EL層内の通常のL1取引と簡単に考えることができます。
Blobと現在のEthereumアーキテクチャの統合は、バイク本体とサイドカー（Sidecar）との関係に例えることができます。このように：（左側がバイクのサイドカーです）
サイドカーは公式の比喩です。その意味は、Blobの運用はメインチェーンに依存していますが、ある程度はメインチェーンと並行しており、相当な独立性を持つということです。
以下の図に示すように、次にBlobに関連する実行プロセスを見て、より良くこの比喩を理解しましょう：
まず、L2 Sequencerが取引を決定し、取引の結果と関連証明（黄色部分）およびデータパッケージ（Blob、青色部分）をL1の取引プールに送信します。
L1のノード（Beacon Proposer）は取引を見て、新しいブロック提案（Beacon Block）内で関連取引を実行し、ブロードキャストします。しかし、ブロードキャストの際に、Blobを分離してコンセンサス層CLに留め、新しいブロックの実行層には置きません。
他のL1ノード（Beacon Peer）は新しいブロック提案と取引結果を受け取ります。L2の検証者になりたい場合は、Blobのサイドカーから関連データをダウンロードできます。
以下の図は、別の視点からBlobのライフサイクルを説明しています。私たちはBlobデータがL1メインチェーンに上がらず、コンセンサス層のノードの中にのみ存在し、異なるライフサイクルを持つことを明確に見ることができます。
したがって、BlobがEVM、つまりL1のスマートコントラクトによって直接読み取れない理由も理解しやすいです：読み取れるものはすべて実行層に送られたものであり、Blobはコンセンサス層にのみ留まるため、その機能はありません。実際、この分離こそがRollup費用が削減される理由でもあります。
2.3 Blobの保存：新しい料金市場
前述のように、Blobデータはコンセンサス層のノードに存在し、ライフサイクルを持っています。しかし、このサービスは無料ではないため、L1のガス料金とは独立した新しい料金市場が生まれます。これがVitalikが提唱するMulti-dimensional Fee Marketです。この料金市場の関連詳細はまだ進化中であり、GitHubの関連議論と更新を参照してください：https://github.com/ethereum/EIPs/pull/5707
さらに、ノードレベルでこれらのデータを短期間しか保存できない場合、長期的な保存をどのように実現するのでしょうか？これに対して、Vitalikは実際には多くの解決策があると述べています。ここでの安全仮定は高くなく、「1 of N信頼モデル」であり、誰かが実際のデータの保存を完了できれば良いのです。現在、大きなストレージハードウェアは1TBあたり20ドルであり、年間2.5TBのデータ保存は関心のある人にとっては小さな問題です。また、他のさまざまな分散型ストレージソリューションも選択肢となりますが、Vitalikは具体的なプロジェクトについては言及していません。
三、EIP-4844の影響
アーキテクチャの観点から、EIP-4844は新しい取引タイプBlob-carrying Transactionを導入しました。これはEthereumがL2のためにデータ層を単独で構築するのは初めてであり、今後のFull Dankshardingの実現への第一歩です。
経済モデルの観点から、EIP-4844はBlobに新しい料金市場を導入し、これもEthereumがMulti-dimensional Marketに向かう第一歩となります。
ユーザー体験の観点から、ユーザーが最も直感的に感じるのはL2の費用が大幅に削減されることであり、この基盤となる重要な改善はL2およびそのアプリケーション層の爆発的な成長に重要な基盤を提供します。
四、EIP-4844後の展望：Fully Danksharding
現在、EIP-4844はEthereumの上海アップグレードシリーズに明確に含まれており、現在のコミュニティメンバーが示したタイムラインに従って、来年の5月から6月初旬に完了する予定です。
EIP-4844は「Proto-Danksharding」であり、Dankshardingのプロトタイプを意味します。完全版のDankshardingの構想は以下の図に示されており、各ノードはデータ可用性サンプリング（Data Availability Sampling）を通じてL2データの正確性をリアルタイムで検証することができます。これにより、L2の安全性と性能がさらに向上します。
