カンクンのアップグレードが近づいていますが、主流の L2 はどのような適応を行っていますか?

TL;DR:

• カンクンのアップグレードは 2024 年 3 月 13 日に開始され、EIP4844 は間もなくオンラインになります。 Danksharding はイーサリアムのロードマップの中核であり、このアップグレードは Danksharding の実現に向けた第一歩です。
• イーサリアム L2 が EIP4844 に適応した後、トランザクション手数料は大幅に下がり、L2 の TPS は 2 倍になりました。ユーザーは、トランザクションがより速く、より安く、よりスムーズで、より応答性が高いと感じるでしょう。これらの L2 には、より複雑で大規模な Dapp アプリケーションが存在することになります。
• オプティミスティック ロールアップは EIP4844 に適応するのが簡単ですが、ZK ロールアップは適応するのがより複雑です。イーサリアムには BLS12-381 楕円曲線をサポートするためのプリコンパイルされたコントラクトがないため、一部の ZKP 検証が困難になり、EIP4844 に適応する ZK ロールアップの進行が妨げられます。
• 楕円曲線の問題は 2 つの方法で解決できます: 1. Ethereum が BLS12-381 楕円曲線をプリコンパイルするのを待ちます; 2. 同じ目的を達成するために別の証明方法を使用し、Ethereum プリコンパイルを使用します。サポートされている BN254.
• 現在、Arbitrum、Optimistic、Starknet、zkSync、Scroll、Polygon zkEVM、および新しい L2 Morph はすべて EIP4844 に適応しています。その中で、Arbitrum、Optimistic、Starknet は、カンクンのアップグレード後に EIP4844 適応を実装すると述べています。 Morph は、EIP4844

1 に適応された最初の zkSNARK zkEVM となる革新的な zkSNARK zkEVM アダプテーション ソリューションのリリースを主導しました。核となるロードマップでは、この取り組みは将来の開発の方向性を示しています。その後、ヴィタリック氏は2年目の「エンドゲーム」でイーサリアムの最終ビジョンを説明し、ベースレイヤー構築の最適化とロールアップのサポートの提供を強調した。これらの措置は、イーサリアムの将来の発展の主な方向性を明確にし、ブロックチェーンエコシステムの継続的な成長の基礎を築きました。

イーサリアムは、データ可用性レイヤーとしての安定性を向上させるために、Danksharding シャーディング テクノロジーを導入しました。この技術により、L2トランザクション手数料が削減され、1秒あたりのロールアップトランザクション数が増加し、イーサリアムネットワークの規模がさらに拡大することが期待されています。

今年の時点で、イーサリアムのカンクン-デンクンのアップグレードはついに 2024 年 3 月 13 日にリリースされ、EIP4844 が開始されようとしています。このハードフォークは、イーサリアムが Danksharding を実装するための最初のステップとみなされており、イーサリアムのロードマップにおける重要なリンクです。

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 が多いほど、記憶域が大きくなります。

EIP4844 に適応した後、EthereumL2 はエンド ユーザーに、より高速なトランザクション、より低いコスト、よりスムーズなエクスペリエンス、より応答性の高い応答を提供します。これにより、より複雑で大規模な Dapp アプリケーションが L2 プラットフォームに導入されることになります。

3.L2 はどのようにして EIP4844 に適応しますか?

L2 はどのようにして EIP4844 に適応しますか?オプティミスティック ロールアップと ZK ロールアップについては個別に説明する必要があります。

オプティミスティック ロールアップは EIP4844 に適応します

オプティミスティック ロールアップは、不正防止を使用してロールアップの実行の正確さを保証するテクノロジーです。このメカニズムでは、状態遷移が違法であることを証明するために誰かが指定された時間内に不正証明を提案しない限り、ノードは状態遷移が正しいと想定します。不正行為の証拠が発生すると、以前に送信された状態遷移は取り消されます。

Optimistic Rollup は、ZK ロールアップよりも EIP4844 に適応するのが簡単です。 Blob を運ぶトランザクションを通じてすべての L2 トランザクションを L1 に送信して、適応を完了します。さらに、EIP4844 に適合するように不正行為の証明を調整する必要がありますが、この部分はゆっくりと行うことができます。結局のところ、多くの楽観的なロールアップはまだ不正証明を開始していません。詐欺証明書をオンラインに掲載しましたが、2 年以上詐欺証明書が提出されていないことがわかりました。

L2 トランザクションの送信: ロールアップが送信されるとき、Blob を運ぶトランザクションを使用して、ロールアップ データを BLOB に保存します。 BLOB を運ぶトランザクションのペイロードは rlp([tx_payload_body, blob, commits,proof]) です。ここで、

tx_payload_body- は、標準 EIP-2718 BLOB トランザクションの TransactionPayloadBody です。
• blobs - blob のリスト。トランザクションには最大 2 つの BLOB を含めることができます。
• コミットメント - Blob の KZG コミットメント リスト。
• proofs - KZG コミットメントに対応する BLOB およびプルーフ リスト。この証明は ETH ノードによって検証されます。

不正証明の調整:

まず第一に、証明者と挑戦者は、争点を見つけるために複数回の対話を必要とします。
• その後、争点を判断のために L1 に提出します。 EIP4844 に適応するには、問題のデータが特定の BLOB に保存されていることを証明する必要がある場合があります。
• BLOB データは約 18 日後に削除されるため、チャレンジ期間は削除前である必要があり、現在の楽観的ロールアップで満たされます。通常、チャレンジ期間は 7 日を超えません。

ZK ロールアップは EIP4844 に適応します

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

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

Optimism のロールアップで、Optimism と Arbitrum は EIP-4844 を採用するというコミットメントを表明し、コミュニティと緊密に連携して必要な更新プログラムのテストと展開を行っています。 Arbitrum はステージ 1 のロールアップであり、比較的優れたセキュリティを備えています。これには、不正行為の証拠を EIP4844 に適合させる必要があります。オプティミスティック ロールアップはステージ 0 のロールアップです。現時点では不正行為の証拠はありません。適応は容易ですが、セキュリティは十分ではありません。

ZK ロールアップでは、STRAK と SNARK を使用したロールアップ適応の難易度が異なります。 STARK のロールアップを使用すると EIP4844 を適用するのが容易であり、Starknet は代表的なものの 1 つです。 Starknet は、カンクンがアップグレード後に EIP4844 適応を実装するという記事を公開しました (記事リンク)。 zkSync は、SNARK ロールアップを使用して、BLOB を運ぶトランザクションを活用してコストをさらに削減し、パフォーマンスを向上させる方法も模索しています。 Scroll は昨年、EIP4844 に適応するアイデアを紹介する記事を公開しました (記事リンク)

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

Optimistic ZK ロールアップは、両方のタイプのロールアップの利点を組み合わせたものです。 Sequencer によって送信された実行結果を楽観的に信じ、結果を疑う人がチャレンジを開始できるようにします。チャレンジが発行された場合にのみ、証明者は実行結果の正しさを証明するための ZKP を生成します。 Optimistic ロールアップの効率性と、ZK で実証された ZK ロールアップの信頼性を備えています。

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