Foresight Ventures: カンクンのアップグレードが近づいていますが、どの L2 が適応されましたか?-ウェブ3.0-php.cn

#著者: Maggie@Foresight Ventures

#TL;DR：

Danksharding はイーサリアムロードマップの中核であり、このアップグレードは Danksharding を実現するための最初のステップです。
イーサリアム L2 が EIP4844 に適応した後、トランザクション手数料は大幅に下がり、L2 の TPS は 2 倍になりました。
オプティミスティックロールアップは EIP4844 に適応するのが簡単ですが、ZK ロールアップは適応するのがより複雑です。イーサリアムには BLS12-381 楕円曲線をサポートするためのプリコンパイルされたコントラクトがないため、一部の ZKP 検証が困難になり、EIP4844 に適応する ZK ロールアップの進行が妨げられます。
楕円曲線の問題は 2 つの方法で解決できます:
1. イーサリアムが BLS12-381 楕円曲線をプリコンパイルするのを待ちます; 2. 別の証明方法を使用して、同じ目的を達成するには、Ethereum プリコンパイルでサポートされている BN254 を使用してください。
現在、
Arbitrum、Optimistic、Starknet、zkSync、Scroll、Polygon zkEVM、および新しい L2 Morph が適応中です。 EIP4844まで。その中で、Arbitrum、Optimistic、Starknet は、カンクンのアップグレード後に EIP4844 適応を実装すると述べています。 Morph は、革新的な zkSNARK zkEVM アダプテーションソリューションのリリースを主導しました。これは、EIP4844 に適応する最初の zkSNARK zkEVM になります。
1. 背景

2020年、イーサリアムは「ロールアップ中心のイーサリアムロードマップ」をリリースしました。翌年、Vitalik によって出版された「Endgame」で説明されたイーサリアムの最終図と同様に、

はイーサリアムの一般的な方向性、つまりロールアップに対応するためのイーサリアムの基本層の構築の最適化を決定しました。

イーサリアムは、データ可用性レイヤーとしてのパフォーマンスを向上させるために、Danksharding のシャーディングテクノロジーを導入しました。この技術により、L2トランザクション手数料が大幅に削減され、RollupのTPSが向上し、イーサリアムの大規模な拡張が実現すると期待されています。

今年まで、

DA 層とは何か、Danksharding の技術原則、EIP4844 の内容については、昨年書いた技術記事「DA (Data Availability) Summer is coming?」を参照してください。 https://foresightnews.pro/article/detail/33575

2. カンクンのアップグレードは L2 にどのようなメリットをもたらしますか?

EIP4844 では、BLOB 搬送トランザクション と呼ばれる新しいトランザクションタイプが導入されています。 BLOB を運ぶ各トランザクションは、BLOB リストを「運ぶ」ことができます。 BLOB は、約 125 KB のデータパケットです。 BLOB は短期間、つまり 4096 エポック (18 日強) のみ保存されます。

#L2 取引手数料が大幅に下がりました。 BLOB は永続的なストレージを必要としないため、BLOB はブロックスペースよりも大きく、安価です。 BLOB は、同じガス消費量で Calldata の 10 倍のデータを保存できます。 EIP4844 に適合したロールアップでは、トランザクションデータを BLOB に保存できるため、トランザクション手数料が桁違いに削減されます。

#L2 の TPS が 2 倍になります。
現在、ブロックあたりのターゲットは 3 BLOB で、最大 6 BLOB が許可されます。ブロックはわずか 90 KB で、各 BLOB は約 125 KB です。 Blob の導入は、Rollup データを格納するブロックの領域を数倍に拡張することに相当するため、Rollup の TPS も 2 倍にすることができます。また、Toni と Vitalic によって書かれた「ブロックガス制限の増加について」では、ブロックガス制限とゼロ以外の Calldata バイトの価格を増やすことで、より少ない変数でより小さなブロックサイズが実現され、より多くの変数を追加できるようになると述べています。未来。ブロブ。 BLOB が多いほど、記憶域が大きくなります。

エンドユーザー向け:
イーサリアム L2 が EIP4844 に適応されると、トランザクション速度が向上し、コストが削減され、エクスペリエンスがよりスムーズになり、応答がよりスムーズになります。もっと敏感に反応してください。これらの L2 には、より複雑で大規模な Dapp アプリケーションが存在することになります。
3. L2 はどのようにして EIP4844 に適応しますか?
L2 はどのようにして EIP4844 に適応しますか?オプティミスティックロールアップと ZK ロールアップについては個別に説明する必要があります。

オプティミスティックロールアップは EIP4844 に適応します
オプティミスティックロールアップは不正証明を使用して、ロールアップの実行の正確さを保証します。ノードは、誰かが指定された時間内に、以前に送信された状態遷移が違法であることを示す不正証明書を提供しない限り、状態遷移が正しいと想定します。その場合、状態遷移はキャンセルされます。

ZK ロールアップと比較して、オプティミスティックロールアップは EIP4844 への適応が容易です。適応を完了するには、Blob を運ぶトランザクションを通じてレイヤー 2 トランザクションをレイヤー 1 に送信するだけで済みます。さらに、EIP4844 の要件に準拠するように不正行為の証明を調整することも必要ですが、この部分は段階的に行うことができます。実際、多くのオプティミスティックロールアッププロジェクトはまだ不正防止機能を開始していません。不正行為の証明が開始されたにもかかわらず、2 年以上不正行為の証拠は 1 件も提出されていません。
L2 トランザクション送信: ロールアップが送信されるとき、Blob 保持トランザクションを使用して、ロールアップデータを BLOB に保存します。 BLOB を運ぶトランザクションのペイロードは rlp([tx_payload_body, blob, commits,proof]) です。ここで

##tx_payload_body - 標準 EIP-2718 BLOB トランザクションの TransactionPayloadBody です。

blobs - BLOB のリスト。トランザクションには最大 2 つの BLOB を含めることができます。

commitments - BLOB の KZG コミットメントのリスト。

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

不正証明を調整します:

まず、証明者には複数のラウンドが必要です。と挑戦者対話などを通じて争点を見つける。

その後、紛争点を判断のために L1 に提出します。 EIP4844 に適応するには、問題のデータが特定の BLOB に保存されていることを証明する必要がある場合があります。

BLOB データは約 18 日後に削除されるため、チャレンジ期間は削除される前である必要があり、現在の楽観的なロールアップで満たされています。通常、チャレンジ期間は 7 日を超えません。

ZK ロールアップは EIP4844 に適応します
ZK ロールアップは ZKP を使用して、L2 状態遷移が正しいことを証明します。 EIP4844 への ZK ロールアップの適応は、オプティミスティックロールアップよりも複雑です。

L2 トランザクション送信: オプティミスティックロールアップのこのステップも同様です。

ZK 証明の提出: 適応前の ZK ロールアップと比較すると、状態遷移の ZKP 証明に加えて、もう 1 つのプロセスを証明する必要があります。 . .つまり、BLOB コミットメントとトランザクションバッチが対応していることが証明され、状態遷移証明の入力が正しいことが保証されます。
例: 状態遷移の ZK 回路は、計算プロセス a a = b の証明を生成できます。 (a=1,b=2) および (a=2,b=4) の場合に生成される ZKP は正当です。したがって、そのときに提供した入力が (a=2,b=4) ではなく (a=1,b=2) であったという証明も提供する必要があります。
これは、EIP4844 に適応する前に行う必要はありません。データは Calldata に直接保存され、直接読み取ることができ、入力が調整されないことが保証されるためです。 EIP4844 を使用した後は、Blob データを直接読み取ることができなくなり、これは新しい回路を介してのみ証明できます。
STARK の ZK ロールアップ (Starknet など) を使用すると、この証明メカニズムを実装する方が簡単です。これは、SNARK を使用した ZK ロールアップの課題です。その理由は、
EIP4844 の BLOB コミットメントで使用される楕円曲線は BLS12-381 であるのに対し、ETH のプリコンパイルされたコントラクトは BN254 のみをサポートしているためです。曲線が異なるため、私たちにとっては困難です。 BLOB コミットメントの完了証明をスマートコントラクトで直接検証します。

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

イーサリアムが BLS12-381 プリコンパイルされたコントラクトをサポートするのを待っています。これは長くなります。

別の方法で証明してください。新しい回路を設計するには、プリコンパイルされたコントラクトでサポートされている BN254 楕円曲線を使用する必要があります。現在、Morph はこのアプローチを採用しているようです。これにより、Morph は EIP4844 への適応を完了した最初の zkEVM になります。

Morph の EIP-4844 zkEVM 統合ソリューションについては、https://medium.com/@morphlayer2/morphs-solution-to-eip-4844 を参照してください。 -zkevm-integration-7f469910478f

4.どの L2 が EIP4844 に適合しますか?

オプティミスティックロールアップは、EIP4844 に比較的簡単に適応できます。

Arbitrum は、カンクンアップグレード (記事リンク) の EIP 変更を実装するために、3 月 14 日に Arb OS20 アップグレードを開始します。 Arbitrum はステージ 1 のロールアップに属します。トランザクションの送信と不正行為の証明の両方が EIP4844 に適応する必要があり、そのセキュリティは比較的良好です。

Optimism は、適応を完了するために 3 月 14 日に Ecotone アップグレードを開始しました (記事リンク)。オプティミスティックロールアップはステージ 0 のロールアップです。現在、不正行為の証拠はありません。適応は容易ですが、セキュリティは十分に高くありません。適応が完了すると、Op エコシステム内のすべてのスーパーチェーンネットワークも EIP-4844 の恩恵を受けることになります。

ZK ロールアップでは、STRAK と SNARK を使用したロールアップ適応の難易度が異なります。

EIP4844 は STARK ロールアップを使用すると簡単に適用でき、Starknet は代表的なものの 1 つです。

Starknet は、カンクンがアップグレード後に EIP4844 適応を実装するという記事を公開しました (記事リンク)。

zkSync は Boojum を通じてアップグレードされ、zkSync が SNARK から STARK プルーフへの移行を完了できるようになりました。これは、EIP4844 アップグレードの準備でもあります。 Boojun は STARK に基づいた証明システムです。 (記事リンク)

SNARKのロールアップに適応させるのは比較的複雑です

Polygon zkEVMが予想されますFeijoa へのアップグレード は 5 月に開始され、EIP-4844 に適応しました。 (記事リンク)
Scroll は昨年、EIP4844 を適応させるアイデアを紹介する記事を公開しました (記事リンク)。
最も印象的なのは Morph です。彼は Optimistic ZK Rollup であり、EIP4844 の zkSNARK zkEVM 適応計画を最初にリリースしました 、 は最初に完了したと言えます。 EIP4844 zkSNARK zkEVM ロールアップ (記事リンク)。 Optimistic ZK ロールアップは、両方のタイプのロールアップの利点を組み合わせたものです。 Sequencer によって送信された実行結果を楽観的に信じ、結果を疑う人がチャレンジを開始できるようにします。チャレンジが発行された場合にのみ、証明者は実行結果の正しさを証明するための ZKP を生成します。 Optimistic ロールアップの効率性と ZK ロールアップの ZK 証明の信頼性を備えています。

以上がForesight Ventures: カンクンのアップグレードが近づいていますが、どの L2 が適応されましたか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。