EIP-4844：proto-dankshardingの仕組みの紹介（2024年イーサリアムDencunアップグレード）

こんにちは。次世代システム研究室のL.C.A.です。（海外の出身です。）
ChatGPT4にこの記事の日本語訂正を手伝っていただき、感謝します

はじめに

2024年、イーサリアムは新たなアップグレードを迎えることになります。このアップグレードは、既存のL2 Rollupにとって大きな利点と見なされています。また、イーサリアムの未来の大規模アップグレード「Sharding」への大きな一歩でもあります。

このブログでは、2024年のDencunアップグレードにおける最も注目される技術の一つ、EIP-4844 proto-dankshardingについて紹介します。Ethereum L1がどのようにしてL2 Rollupの拡張性を高め、L1にトランザクションをデプロイするコストを削減するのかを説明します。

結論ファースト

EIP-4844 proto-dankshardingは既存のEthereumのトランザクションの仕組みを改良により、L1の拡張性を高める
トランザクションの構造にShard Blob Transactions（Blob）というデータ形式を追加することで、L1でのトランザクションデータの保存コストを削減する
Blobに保存される取引には保持期限がある
CalldataがEVMのメモリ内に保存するのに対し、BlobはEVMの以外のノードのディスク上に保存することができる
EIP-4844はBlobのGas feeの計算システムを提供している
スマートコントラクトはBlobの内容に直接アクセスすることはできず、commitment（Merkle Treeのrootに似ている）を通じてアクセスする
Shard Blob Transactionsの提案は、L2がL1に提出する取引データの可用性問題を解決しつつ、L1のストレージコストを効果的に削減する（Optimistic Rollupが一つのバッチで数十万のGas feeを節約できると予想される）。

L2 Rollupの課題
解決法：EIP-4844 – Shard Blob Transaction
Proto-dankshardingとロールアップの実際の応用：Precompileコントラクト
まとめ
参考

L2 Rollupの課題

L2データ可用性の確保が必要のために、コスト高いcalldata仕組みを使用

以前のzkRollupを紹介するブログで、L2 Rollupはトランザクションデータの可用性と復元可能性を確保するため、ほとんどのトランザクションデータをL1にアップロードするの必要があります。（L2が使用できない場合や誰かが異議を唱えた場合、L1のデータを使用してトランザクションの正確性を確認できます）。

実装上では、現在のRollupは主にトランザクションのcalldataの仕組みのを用いてこれらのトランザクションデータをL1にアップロードし、イーサリアムの全ノードがこれらのL2トランザクションデータを永久に保存する必要があります。これにより、L2での取引手数料を大幅に削減することができず、トランザクション処理速度（TPS）も効果的に向上させることができません。

注：「ロールアップでは、トランザクションをcalldataとしてイーサリアムに書き込みます。 calldata とは、スマートコントラクトの関数を外部から呼び出す際に含まれるデータが格納される場所を指します。 calldata に含まれる情報はブロックチェーン上で公開されるため、すべてのユーザーが独自にロールアップの状態を再構築することができます」- ゼロ知識ロールアップ

現状L1上のL2 Rollupのコスト

L1で1つの非ゼロバイトをアップロードするためには16ガスが必要です。以下の記事では、optimism rollupのArbitrumでトランザクションのcalldataをアップロードするコストが約4000ガス、zkRollupのzksyncでは約500ガスであることが示されています。そして、一つのバッチでのトランザクション処理には数十万のガス費用がさらに必要です。

現在のArbitrumでは、calldataアップロードのコストだけを計算すると、一つのブロックには750件のトランザクション（30m/4k）しか含まれない可能性があります。これらのcalldataのアップロードコストを削減できれば、L2のトランザクション手数料と速度（TPS）は大幅に向上するでしょう。

出典：https://twitter.com/sanjaypshah/status/1552679513338925056/photo/1

解決法：EIP-4844 – Shard Blob Transaction

上述のように、L2トランザクションデータのアップロードの大きな目的は、データの可用性を保存し、誰もがそれを閲覧できるようにすることです。しかし、データの保存以外に、L1コントラクトはこれらのデータを呼び出す必要はありません。

そのため、「Shard Blob Transaction」と呼ばれる新しいトランザクションフォーマットが、この問題を解決するために設計されました。その目標は、「すべてのノードがダウンロード可能であるが、EVMで実行できないデータ」の仕組みを提供することです。

Blob

Shard Blob Transactionのトランザクションフォーマットは、一般的なものとほぼ同じですが、blobというフィールドが追加されています。

各Blobは長さ4096の配列で、配列の各要素は32バイトです。また、各ブロックには最大16個のblobを収容できるため、各ブロックは最大で2MBのBlobデータ（40963216）を含むことができます。 – Proto-Danksharding

注：calldataとblobの保存の違いについてですが、calldataはノードがトランザクションを実行する際にEVMメモリに書き込む必要がありますが、コントラクトによってアクセスされないBlobは、直接ハードディスクに書き込んで放置できます。これら二つのデータタイプはノードのリソース消費が異なります。

Blobの特徴1：EVMで実行・アクセス不可

スマートコントラクトは、Blob内のデータを呼び出すことはできません。Blobをcommitment（実際はversioned hash）に作成する必要があり、その後でスマートコントラクトによって呼び出されます。

commitmentは、Blob内の要素をまとめて一つのMerkle Treeを形成し、その Merkle Rootのみがコントラクトにアクセス可能と考えることができます。

（EIP-4844では実際に使用される方法はMerkle Treeではなく、KZG Proofです。その検証ステップはMerkle Treeよりも簡単ですが、事前にzkSNARKsのようなtrusted setupを設計する必要があり、量子耐性も懸念があります。）

Versioned Hash

互換性を保つために、commitmentはKZG commitmentをkeccak256のハッシュ化し、blob_versioned_hashesとしてトランザクション内に存在します。将来的にKZG方式をやめる場合でも、別の方法を使用できます。

ちなみにEIP-4844のブロックトランザクション内容は以下の感じです。

[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]

下の図のように、EVMのスマートコントラクトはopcodeを使用して、トランザクションに対応する各Blobのblob_versioned_hashesにアクセスできます

出典：https://hackmd.io/@protolambda/blobs_l2_tx_usage

Blobの特徴2：ライフサイクルがある

Blobは一定期間（例えば1ヶ月）経過後にノードによって削除可能と設定されています。

Blobの有効期限を設定する理由

Blobに有効期限を設定する理由ですが、Optimistic Rollupを例にとると、トランザクションデータ（raw transaction data）は誰かが疑わしいトランザクションを告発し、挑戦（fraud proof）を行う際（おおよそ7日以内）にのみ使用されます。一方、zkRollupでは、ゼロ知識証明が状態の更新が正しいことを既に証明しており、トランザクションデータのアップロードは、ユーザーが完全なブロック状態を復元できるようにするためだけです。

現在のほとんどのRollupでは、トランザクションデータはcalldataを通じてL1に永久保存されますが、実際にはほとんどのデータは検証期間が終了した後には不要になります。

したがって、トランザクションデータをBlobに置くことで、誰かが挑戦を開始した場合、Blob内のトランザクションデータがコントラクトがアクセス可能なcommitmentに対応することを証明するだけで済みます。挑戦期間が終了すると、これらのトランザクションデータをL1に保存し続ける必要はありません。

Blobの有効期限を設定するメリット

定期的にBlobのデータを削除可能な特性により、ノードのストレージ負担も軽減できます。（Blobのデータは年間約2.5TBのディスク容量が必要になるとされています EIP-4844: Shard Blob Transactions ）。

削除まで残りの時間は、これらのトランザクションデータを保存する必要があるノード（例えば、L2ノードやL2ブロックエクスプローラサービス）が、これらのBlobデータをダウンロードできるようにすることが主な目的です。

Proto-dankshardingとロールアップの実際の応用：Precompileコントラクト

EIP-4844では主に2つのコントラクトが追加されています。以下でそれぞれを紹介します。

Blob Verification Precompile

このコントラクトは主にOptimistic Rollupsで使用され、Blobとcommitment間の関係を検証するために用いられます。Optimistic Rollupsのコントラクトは、ユーザーが提供したBlobの内容とcommitmentをPrecompileコントラクトに送り、Precompileコントラクトは、commitmentがBlobの有効なcommitmentであるかどうかを返します。

Point evaluation precompile

このコントラクトは主にzkRollupsで使用されます。zkRollupsがL1に送信する際、Validity Proofに対応するトランザクションとBlobに保存されたトランザクションが同じであることを確認する必要があります。

この時、Point Evaluation Precompileコントラクトを使用して、KZG CommitmentとValidity Proofの関連性を証明できます。Point Evaluation Precompileは、Proof of Equivalenceの方法を通じて、Validity ProofとBlobのトランザクションが関連していることを確認します。

具体的な詳細なロジックについては、EIP-4844のドキュメントを参照してください。

まとめ

2024年は、Rollup技術の発展にとって非常に重要な年です。イーサリアムのDencunアップグレードは、Rollup技術に多くの期待をもたらしました。現在、Rollupのコストが高いため、多くの設計では安全性やデータの可用性を犠牲にし、コストを節約するためにトランザクションをオフチェーンのノードに保存します（例：zkRollupのValidium）。

proto-dankshardingの登場により、L1ストレージの手数料が下がり、Rollupがオフチェーンストレージで直面する信頼の問題の解決も期待できます。また、イーサリアムの大規模アップグレードであるShardingに向けて大きな一歩を踏み出し、L2 Rollupの開発チームがShardingに向ける仕様をRollupの設計に早期に適用できるようになりました。

最後、本ブログで触れた技術的な面だけでなく、proto-dankshardingにおける手数料も重要な議題です。EIP-4844は、既存のGas計算方式とは異なり、Blobに対してのGas Fee計算システムを提供しています。詳細は本文では述べませんが、EIP-4844で述べられているGas feeの計算に関する部分を参照できます。

参考資料

最後に

グループ研究開発本部次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧からご応募をお待ちしています。