カンクンアップグレードの到来：どのL2が対応済みか？
TechFlow厳選深潮セレクト
カンクンアップグレードの到来：どのL2が対応済みか？
Optimistic RollupsはEIP-4844への対応が簡単であり、ZK Rollupsは対応がより複雑である。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Maggie@Foresight Ventures
TL;DR
-
クエンタウンアップグレードは2024年3月13日にリリースされ、EIP4844がまもなく実装される。Dankshardingはイーサリアムロードマップの中核であり、今回のアップグレードはDankshardingの実現に向けた第一歩である。
-
イーサリアムL2がEIP4844に対応した後、トランザクション手数料が大幅に低下し、L2のTPSが倍増する。ユーザーは取引速度の向上、コスト削減、スムーズで迅速な体験を感じるようになる。これらのL2上ではより複雑で大規模なDappアプリケーションが登場するだろう。
-
Optimistic rollupはEIP4844への対応が比較的簡単だが、ZK rollupはより複雑である。イーサリアムにはBLS12-381楕円曲線をサポートするプリコンパイル契約がなく、一部のZKP検証が困難となり、ZK rollupのEIP4844対応が遅れている。
-
楕円曲線の問題は二つの方法で解決できる：1. イーサリアムがBLS12-381楕円曲線に対してプリコンパイルを導入するのを待つ；2. 同等の目的を達成するために別の証明方式を用い、イーサリアムがプリコンパイルでサポートしているBN254を使用する。
-
現在、Arbitrum、Optimism、Starknet、zkSync、Scroll、Polygon zkEVM、そして新規L2のMorphもEIP4844への対応を進めている。うち、Arbitrum、Optimism、Starknetはクエンタウンアップグレード後にEIP4844対応を実施すると表明している。一方、Morphは革新的なzkSNARK zkEVM対応案をいち早く発表し、初のEIP4844対応zkSNARK zkEVMとなる。
一、背景
2020年、イーサリアムが発表した「Rollupを中心としたイーサリアムロードマップ」、および翌年にVitalikが提唱した「Endgame」における最終ビジョンにより、イーサリアムの大方向性が定められた。すなわち、イーサリアムレイヤー1の基盤整備を最適化し、Rollupを支えるプラットフォームとなることである。
イーサリアムはDankshardingというシャーディング技術を設計し、データ可用性層としての能力を高めることを目指している。これによりL2のトランザクション手数料が大きく低下し、RollupのTPSが向上し、イーサリアム全体のスケーラビリティが飛躍的に拡大する。
そして今年、イーサリアムのクエンタウン（Dencun）アップグレードがついに2024年3月13日に実施され、EIP4844が間もなく導入される。このハードフォークはDanksharding実現への第一歩であり、イーサリアムロードマップの中核中の核心と言える。
二、クエンタウンアップグレードがL2にもたらす恩恵
EIP4844は「blob-carrying transaction」と呼ばれる新しいトランザクションタイプを導入する。各blob-carryingトランザクションは、Blobのリストを「運ぶ」ことができる。Blobとは約125KBのデータパケットであり、その保存期間は短く、4096エポック（約18日以上）のみである。
-
L2のトランザクション手数料が大幅に低下。Blobは永続的なストレージを必要としないため、ブロックスペースよりも大きくかつ安価である。同じガス消費量で、Calldataよりも10倍多いデータを格納できる。EIP4844に対応したRollupは取引データをBlobに保存することで、手数料を桁違いに下げることができる。
-
L2のTPSが倍増。現在、各ブロックは目標として3つのBlobを持ち、最大6つまで許可されている。ブロック自体は90KB程度だが、Blob一つあたり約125KBである。Blobの導入は、ブロックにRollupデータを格納するための追加スペースを数倍拡張することに相当し、結果としてRollupのTPSも倍増する。また、ToniとVitalikが「On Increasing the Block Gas Limit」で述べているように、将来的にはブロックガスリミットの増加や非ゼロCalldataバイトの価格調整を通じて、より小さく変動の少ないブロックサイズを実現し、さらに多くのBlobを追加できるようにする予定である。Blobが増えれば、利用可能なストレージ容量も大きくなる。
エンドユーザーにとって、イーサリアムL2がEIP4844に対応すれば、取引速度が速くなり、コストが下がり、体験がスムーズで反応性が高まる。これらのL2上では、より複雑で大規模なDappアプリケーションが可能になる。
三、L2はどのようにEIP4844に対応するのか？
L2がEIP4844に対応するにはどうすればよいのか？ここではOptimistic RollupとZK Rollupに分けて考察する必要がある。
Optimistic RollupsのEIP4844対応
Optimistic rollupは不正検出証明（fraud proof）によって、rollupの実行が正しいことを保証する。つまりノードはまず状態遷移が正しいものと仮定し、所定の期間内に誰かが不正を証明するfraud proofを提出しない限り、その状態遷移を受け入れる。もしfraud proofが提出された場合、以前に提出された状態遷移は取り消される。
Optimistic rollupのEIP4844対応は、ZK rollupに比べて比較的簡単である。L2の取引をBlob-carryingトランザクションとしてL1に送信するだけで対応が完了する。それに加えて、fraud proofの部分をEIP4844に合わせて調整する必要があるが、これはゆっくり進めていけばよい。そもそも多くのoptimistic rollupは未だにfraud proofを実装していないし、すでに実装しているものでも、2年以上経っても一度もfraud proofが提出されていないのが現状である。
L2取引の提出：Rollupが提出する際、Blob-carryingトランザクションを使い、RollupデータをBlobに格納する。Blob-carryingトランザクションのペイロードはrlp([tx_payload_body, blobs, commitments, proofs])であり、それぞれ：
-
tx_payload_body - 標準EIP-2718 blobトランザクションのTransactionPayloadBody。
-
blobs - Blobのリスト。一つのトランザクションに含まれるBlobは最大2つ。
-
commitments - Blobに対するKZGコミットメントのリスト。
-
proofs - Blobと対応するKZGコミットメントの証明リスト。この証明はETHノードによって検証される。
fraud proofの調整：
-
まず、証明者と挑戦者が複数回のやり取りなどを通じて論点を特定する。
-
その後、その論点をL1に提出して判定を仰ぐ。EIP4844対応の場合、その論点のデータが特定のBlobに格納されていたことも証明する必要があるかもしれない。
-
Blobのデータは約18日後に削除されるため、挑戦期間はそれ以前に終了していなければならない。現在のoptimistic rollupの多くはこれを満たしており、通常挑戦期間は7日以内である。
ZK RollupsのEIP4844対応
ZK rollupはZKPを使ってL2の状態遷移が正しいことを証明する。ZK rollupのEIP4844対応は、optimistic rollupに比べてより複雑である。
-
L2取引の提出：このステップはOptimistic Rollupと同様である。
-
ZK証明の提出：従来のZK Rollupに比べ、状態遷移のZKP証明に加えて、もう一つのプロセスを証明する必要がある。すなわち、blob commitmentとtransaction batchが対応していることを証明し、状態遷移証明の入力が正しいことを保証する。
-
例えるなら、状態遷移のZK回路は a + a = b の計算過程の証明を生成できる。ここで(a=1,b=2) と (a=2,b=4) の両方で有効なZKPが生成される。そのため、実際に使用した入力が(a=1,b=2)であって、(a=2,b=4)ではないことを証明する別の証明が必要になる。
-
これはEIP4844対応前には不要だった。なぜならデータはCalldataに直接保存され、読み取り可能で、入力がすり替えられないことが保証されていたからである。しかしEIP4844採用後は、Blobデータは直接読み取れず、新たな回路を構築してこの対応を証明する必要がある。
-
STARKを使用するZK rollup（例：Starknet）はこのような証明メカニズムを実装しやすい。一方、SNARKを使用するZK rollupにとっては課題がある。理由はEIP4844のblob commitmentに使われる楕円曲線がBLS12-381であるのに対し、ETHのプリコンパイル契約はBN254のみをサポートしており、曲線が異なるため、blob commitmentの検証をスマートコントラクト内で直接行うことが難しくなる。
-
SNARK型zkEVM/zkVMは、第2点で述べた曲線の不一致によりZK証明を生成できない問題を解決する必要がある。
-
イーサリアムがBLS12-381のプリコンパイルをサポートするのを待つ。しかしこれは長期的な見通しである。
-
別の証明方式を採用する。新たな回路を設計する必要があり、プリコンパイルがサポートするBN254楕円曲線を使用しなければならない。現在、Morphがこの手法を採用している。これにより、Morphは初のEIP4844対応zkEVMとなった。
MorphのEIP-4844 zkEVM統合ソリューションについてはこちら：記事リンク
四、どのL2がEIP4844に対応したのか？
Optimistic rollupでは、OptimismとArbitrumがEIP-4844の採用に取り組んでおり、コミュニティと密接に連携して必要な更新のテストと展開を行っている。ArbitrumはStage 1のRollupに該当し、セキュリティ面で比較的優れている。EIP4844に合わせたfraud proofの調整が必要となる。一方、OptimismはStage 0のRollupに属し、まだfraud proofを実装していないため、対応が容易だが、セキュリティレベルはやや低い。
ZK rollupでは、STARKとSNARKを使用するもので対応の難易度が異なる。STARKを使用するrollupはEIP4844対応が容易で、代表例がStarknetである。Starknetはクエンタウンアップグレード後にEIP4844対応を実施すると発表している。SNARKを使用するrollupでは、zkSyncがblob付きトランザクションの活用によるコスト削減と性能向上を模索している。Scrollも昨年、EIP4844対応のアプローチについての記事を発表している。
最も注目すべきはMorphである。これはOptimistic ZK Rollupであり、zkEVMのEIP4844対応案をいち早く発表した。事実上、初のEIP4844対応zkEVM Rollupと言える。
Optimistic ZK Rollupは二種類のRollupの利点を併せ持つ。Sequencerが提出した実行結果を楽観的に信用し、疑義を持つ者が挑戦を申し立てられる。挑戦が発生した場合にのみ、証明者がZKPを生成して実行結果の正当性を証明する。Optimistic rollupの効率性と、ZK rollupのZK証明による信頼性の両方を兼ね備えている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Foresight Ventures
