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

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

1. #L2 取引手数料が大幅に下がりました。 BLOB は永続的なストレージを必要としないため、BLOB はブロック スペースよりも大きく、安価です。 BLOB は、同じガス消費量で Calldata の 10 倍のデータを保存できます。 EIP4844 に適合したロールアップでは、トランザクション データを BLOB に保存できるため、トランザクション手数料が桁違いに削減されます。
2. #L2 の TPS が 2 倍になります。
   現在、ブロックあたりのターゲットは 3 BLOB で、最大 6 BLOB が許可されます。ブロックはわずか 90 KB で、各 BLOB は約 125 KB です。 Blob の導入は、Rollup データを格納するブロックの領域を数倍に拡張することに相当するため、Rollup の TPS も 2 倍にすることができます。また、Toni と Vitalic によって書かれた「ブロック ガス制限の増加について」では、ブロック ガス制限とゼロ以外の Calldata バイトの価格を増やすことで、より少ない変数でより小さなブロック サイズが実現され、より多くの変数を追加できるようになると述べています。未来。ブロブ。 BLOB が多いほど、記憶域が大きくなります。
エンドユーザー向け:

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

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

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

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 に適応します

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

2. 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 コミットメントの完了証明をスマート コントラクトで直接検証します。

3. #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のロールアップに適応させるのは比較的複雑です