カンクンのアップグレードが決定 どのL2が適応を？

マギー（フォーサイト・ベンチャーズ）

TL;DR:

• カンクンのアップグレードは2024年3月13日に展開され、EIP 4844は間もなくオンラインになる。ダンクシャーディングはイーサのロードマップの中心であり、このアップグレードはダンクシャーディングを可能にする第一歩です。

• イーサリアム L2はEIP4844に適応し、取引手数料は劇的に下がり、L2のTPSは指数関数的に増加しました。ユーザーは、取引速度が速くなり、コストが下がり、エクスペリエンスがスムーズになり、反応が良くなったと感じるだろう。これらのL2上では、より複雑で大規模なDappアプリケーションが増えるだろう。

• 楽観的ロールアップはEIP4844への適応がよりシンプルで、ZKロールアップは適応がより複雑です。イーサネットには、BLS12-381楕円曲線をサポートするコンパイル済みのコントラクトがないため、ZKPの一部を検証することが難しく、ZKロールアップをEIP4844に適合させる進捗を妨げています。

• 楕円曲線の問題は、1.EtherCompがBLS12-381楕円曲線をプリコンパイルするのを待つ。

• 現在、Arbitrum、Optimistic、Starknet、zkSync、Scroll、Polygon zkEVM、および新しい L2MorphはすべてEIP4844に適応しています。Arbitrum、Optimistic、Starknetは、Cancunのアップグレード後にEIP4844を実装すると明言しており、Morphは、EIP4844に適応した最初のzkSNARK zkEVMとなる革新的なzkSNARK zkEVMをリリースする最初の存在です<

  ArbitrumとStarknetは、Cancunのアップグレード後にEIP4844を実装すると明言しています。

I.背景

2020年、EtherNetは「ロールアップ中心イーサネット」をリリースしました。strong>ロールアップ中心のイーサネット・ロードマップ」を発表し、翌年に発表されたVitalikの「Endgame」に記載されたイーサネットの最終的な姿は、イーサネットの一般的な方向性を定義しました。

イーサネットは、データ可用性層としてのイーサネットの可用性を向上させるために、Dankshardingのシャーディング技術を設計しました。これにより、L2トランザクション手数料が大幅に削減され、RollupのTPSが向上し、イーサネットの大幅なスケーリングが可能になります。p>

今年、イーサネットDencunアップグレードが2024年3月13日に最終的にロールアウトされ、EIP4844が間もなく本稼働するまでは、このハードフォークは間違いなく、イーサの中核であるDankshardingの実装に向けた第一歩でした。イーサネットのロードマップの中核をなすものです。

DAレイヤーとは何か、Dankshardingの技術的原則、EIP4844とは何かについての詳細は、昨年書いた技術記事を参照してください：DA (Data Availability) Summer is coming?https://foresightnews.pro/article/detail/33575

II.カンクン。アップグレードはL2にどのような恩恵をもたらすのでしょうか？

EIP4844では、ブロブ・キャリング・トランザクションと呼ばれる新しいタイプのトランザクションが導入されます。各blob-carryingトランザクションは、約125KBのデータパケットであるblobのリストを「運ぶ」ことができます。blobは非常に短い期間、わずか4096エポック、つまり18日強の間保存されます。

1. L2の取引手数料は大幅に下がりました。Blobは永続的なストレージを必要としないため、Blobはブロックスペースよりもはるかに大きく安価であり、同じガス消費量でCalldataの最大10倍のデータを保存できます。EIP4844を使用したロールアップは、トランザクションデータをBlobに格納し、トランザクションコストを1桁削減することができます。

2. L2のTPSは指数関数的に増加しています。現在、1ブロックあたり3ブロブ、最大6ブロブを目標としています。 ブロックはわずか90KBで、各ブロブは約125KBです。ブロブを導入することは、ロールアップ・データを格納するために使用できる領域の数倍ブロックを拡張することに相当するため、ロールアップのTPSは指数関数的に向上させることができます。ToniとVitalicによる "On Increasing the Block Gas Limit "では、ブロックガスの上限と非ゼロcalldataバイトの価格を増加させることで、より小さく、より可変的なブロックサイズを達成することができ、その結果、将来、より多くのblobを追加することができると述べられている。より多くのblobは、より多くのストレージスペースを意味します。

エンドユーザーにとって、Ethereum  L2 adapted to EIP4844は、より速く、より安く、よりスムーズで、より反応がよいです。これらのL2には、より複雑で大規模なDappアプリケーションが存在するでしょう。

3、L2はどのようにEIP4844に適応するのか

L2はどのようにEIP4844に適応するのか？これについては、Optimistic RollupとZK Rollupで別々に議論する必要があります。

EIP4844のための楽観的ロールアップ

楽観的ロールアップは、ロールアップ実行の正しさの不正な証明である。は、ロールアップ実行の正しさを保証する。つまり、ノードはまず、状態遷移が正しいと信じることを選択します。ただし、誰かが指定された期間内に、以前に提出された状態遷移が不正であるという不正証明を開始しない限り、状態遷移は取り消されます。

楽観的ロールアップはERPシステムに適応します。EIP4844を適応させるOptimistic Rollupは、ZK Rollupに比べて単純である。適応は、すべてのL2トランザクションをBlob-carryingトランザクション経由でL1にサブミットすることで行うことができる。さらに、不正プルーフをEIP4844に適合させるだけであり、これはゆっくりと行うことができる。結局のところ、これまでのところ、楽観的なロールアップの多くはオンライン詐欺証明を行っていない。不正証明で本番を迎えた人たちは、2年以上にわたって1件も不正証明が提出されていないことに気づいています。

1. L2トランザクションの送信：ロールアップが送信されるとき、Blob-carryingトランザクションは、ロールアップデータをBlobに格納するために使用されます。Blob-carryingトランザクションのペイロードはrlp([tx_payload_body, blobs, commitments, proofs]) 、ここで

• tx_payload_body - は標準的なEIP-2718 blobトランザクションのTransactionPayloadBodyです。

• blobs - blobのリスト。

• commitments - Blobに対するKZGコミットメントのリスト。

• proofs - Blobと対応するKZGコミットメントの証明リスト。この証明はETHノードによって検証される。

• 不正証明の調整：

• まず、証明者と挑戦者は、複数ラウンドのやり取りなどで争点を見つける必要があります。

• その後、争点はL1に提出され、決定される。EIP4844を適応させるには、この論争点のデータがBlobに保存されていることを証明する必要もあるかもしれません。

• Blobデータは約18日後に削除されるため、チャレンジ期間は削除される前でなければなりません。通常、チャレンジ期間は7日以内です。

ZK Rollups Adapt to EIP4844

ZKロールアップは、ZKPによってL2状態遷移が正しいことを証明するために使用されます。ZKロールアップは、楽観的ロールアップよりもEIP4844に適応させるのが複雑です。



1.strong>1.L2トランザクションの提出：この楽観的ロールアップステップも同様です。

2.ZK証明の提出：適応前のZKロールアップと比較して、状態遷移のZKP証明を行うことに加えて、もう1つのプロセスを証明する必要がある。すなわち、状態遷移証明の入力が正しいことを保証するために、ブロブコミットメントとトランザクションバッチが対応していることを証明することである。

類推：状態遷移の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（Starknetなど）によるZKロールアップで実装する方が簡単です。その理由は、EIP4844のblobコミットメントは楕円曲線BLS12-381を使用しているのに対し、ETHのコンパイル済みコントラクトはBN254のみをサポートしているため、スマートコントラクトでblobを直接検証することが、曲線の違いにより困難になっているからです。カーブの違いにより、スマートコントラクトでブロブの完了証明を直接検証することが難しくなっています。

1. SNARKを搭載したzkEVM/zkVMは、ポイント2で述べた曲線の不一致によりZK証明を生成できないという問題を解決する必要があります。
   

• イーサリアムがBLS12-381用のコンパイル済みコントラクトをサポートするのを待っています。長くなりそうだ。

• 証明に異なるアプローチを取る。新しい回路を設計するには、コンパイル済みコントラクトでサポートされているBN254楕円曲線を使用する必要があります。現在、Morphはこの方法を使っています。

MorphのEIP-4844 zkEVM統合ソリューションは、https://medium.com/@morphlayer2/morphs-solution-to-eip-4844-zkevm-integration-7f469910478f

Four, what L2s have adapted to EIP4844?

Optimistic rollup, OptimismとArbitrumは、EIP-4844を採用することを表明し、必要なアップデートをテストして展開するために、それぞれのコミュニティと緊密に協力しています。Arbitrumはステージ1のロールアップで、セキュリティは比較的良好です。Optimistic rollupsはStage 0のロールアップで、まだ不正の証明を持っていません。

ZKロールアップにおけるSTRAKとSNARKを用いたロールアップの適応の難しさは異なります。STARKのロールアップでEIP4844を適応させるのは、CancunのアップグレードでEIP4844の適応が実装されるという記事を掲載したStarknetに代表されるように、より簡単です（記事へのリンク）。SNARKのロールアップでは、zkSyncはさらにコストを削減し、パフォーマンスを向上させるために、ブロブを運ぶトランザクションを活用する方法も模索しており、Scrollは昨年、EIP4844に適応するためのアイデアを記述した記事を発表しています（記事へのリンク）

ロールアップの中で最も印象的なのは、Morphです。EIP4844に適応するzkEVMソリューションを最初にリリースしたOptimistic ZK Rollupは、EIP4844を完成させた最初のzkEVM  Rollupと言えます。

Optimistic ZK Rollupは、両方のタイプのRollupの長所を兼ね備えています。両方のロールアップの長所を兼ね備えています。シーケンサーから提出された実行結果を楽観的に信頼し、結果に懐疑的な人がチャレンジを開始できるようにします。チャレンジが開始されたときだけ、証明者は実行結果の正しさを証明するZKPを生成する。これは、ZKロールアップのZK証明の信頼性と楽観的ロールアップの効率性を併せ持つ。