 著者: 0xhhh, Ethstorage(Twitter:@hhh69251498 )編集:レッドワン3月27日、Polygon zkEVMメインネットのベータ版が正式にローンチされ、Vitalikは最初の取引を完了しました。本稿は、Polygon zkEVMの全体的なアーキテクチャとトランザクション実行プロセスについて簡単に説明し、Polygon zkEVMがイーサリアムのセキュリティを継承しながらどのように計算スケーリングを実現しているかを分析する、Polygon zkEVMに関する一連の記事の第1弾です。次の2つの記事では、Polygon zkEVMのzkEVM BridgeとzkEVMの設計の詳細、およびPolygon zkEVMの次の分散型シーケンサーのロードマップについても詳しく説明します。### まず、ロールアップはイーサリアムの計算スケーリングを実現するためのものですまず、ロールアップのしくみを明確にする必要があります。 Rollupの登場は、イーサリアムの計算をスケーリングすることであり、具体的な実装方法は、トランザクションの実行をRollupにアウトソーシングし、トランザクションとトランザクション実行後の状態(State)をイーサリアムのコントラクトに格納することです。**オプティミスティック ロールアップ**楽観的に考えれば、ロールアップトランザクションとそれに対応するロールアップステートがイーサリアムに送信され、不正防止を提供することで、誰でもチャレンジ期間内のロールアップステートに異議を唱えることができます。**ゼロ知識ロールアップ**ZKは、イーサリアムに送信されたロールアップトランザクションの有効性証明と、対応するロールアップ状態(対応するトランザクションの実行後にロールアップが正しい状態にあることを証明するために、イーサリアム上のコントラクトによって検証される)を提供します。**イーサリアムの公式定義を参照してください:**ゼロ知識ロールアップとオプティミスティックロールアップの最大の違いは、状態の有効性を検証する方法が異なるため、最終段階に到達するまでの時間が異なることです。オプティミスティックロールアップは、イーサリアムに提出されたトランザクションとステータスが正しいことを楽観視しているため、7日間のチャレンジ期間(最終到達までの時間は7日間)があり、その間にイーサリアム上のトランザクションの対応する状態が正しくないことがわかった人は誰でも、正しいステータスを送信することでチャレンジすることができます。ゼロ知識ロールアップ(zk-Rollup)がファイナリティに達するまでにかかる時間は、トランザクションの有効性証明がイーサリアムに提出され、検証されるまでの時間によって異なります。 現時点では、最終決定までに約1時間かかる場合があります(ガス代を考慮する必要があるため)。### 2番目、Polygon zkEVM実行プロセスここでは、Polygon zkEVMがシンプルなトランザクション確認プロセスでどのように機能し、プロトコル全体を具体的に理解するか、そのプロセス全体を3つの主要なステップに分けることができるかを見てみましょう。1. シーケンサーは、複数のユーザー トランザクションをバッチにパッケージ化し、L1 コントラクトに送信します。2. Proverは、取引ごとに有効証明を生成し、複数の取引の有効性証明を1つの有効性証明に集約します。3. アグリゲーターは、アグリゲーターが複数のトランザクションをL1コントラクトに集約した有効性証明を提出します。 **1 Sequencer は、ユーザー トランザクションをバッチにパッケージ化し、L1 コントラクトに送信します。1)ユーザーがトランザクションをシーケンサーに送信し、シーケンサーはトランザクションを受信順序(FRFS)でローカルに処理し、シーケンサーがトランザクションをローカルで実行すると、ユーザーがシーケンサーが誠実であると信じた場合、トランザクションがファイナリティに達したと見なすことができます。 ここで注意したいのは、現在Sequencer内のMempoolのほとんどがプライベートであるため、当面入手できるMEVは比較的少ないということです。2) Sequencer は、複数のトランザクションをバッチにパックし (現在はバッチ内の 1 つのトランザクションのみ)、L1 の PolygonZKEvm.sol の SequenceBatch() 関数を介して、複数のバッチを L1 のトランザクション Calldata にまとめて送信します。 (L1のガス消費量を可能な限り削減するために、一度に複数のバッチが送信されることに注意してください。3) PolygonZkEvm.sol は、Sequencer から提供された Batches を受信すると、コントラクト内の各バッチのハッシュを順番に計算し、前のバッチのハッシュを次のバッチに記録するため、次の図の Batch 構造が得られます。 4)各バッチのトランザクションの順番も決まっているので、バッチの順番が決まったら、L1 Polygon zkEVMコントラクトに提出するバッチに含まれる全てのトランザクションの順番が決まったとみなします。 上記の実際のプロセスは、L1 がロールアップ DA レイヤーとして完了する必要がある作業でもあります (この時点では、状態検証や昇格作業は完了していません)。**2. アグリゲーターは、トランザクションの複数のバッチに対して有効性証明を生成します1) アグリゲーターは、L1 の PolyonZKEVM.sol コントラクトで新しいバッチが正常に送信されたことをリッスンすると、これらのバッチをノードに同期し、これらのトランザクションを zkProber に送信します。2) これらのトランザクションを受け取った後、zkProverはトランザクションごとにValidity Proofを生成し、複数のバッチに含まれるトランザクションのValidity ProofをValidity Proofに集約します。 3) zkProverは、複数のトランザクションを集約したValidity Proof をアグリゲーターに送信します。**3. アグリゲーターは、集計証明の契約を L1** に提出します。アグリゲーターは、次のメソッドを呼び出すことで、この Validity Proof を L1 の Polygon zkEvm.sol コントラクトに、対応するバッチ実行の状態と共に送信します。 次に、コントラクト内で次のアクションが実行され、状態遷移が正しいことが確認されます。  このステップがL1コントラクトで正常に実行されると、バッチのこの部分に含まれるすべてのトランザクションが本当にファイナリティに到達します(OPの7日間のチャレンジ期間の終了に対応)。### 3. Polygon-zkEVMにおけるイーサリアムの役割Polygon zkEVMの全体的なプロセスを見てきたので、イーサリアムがRollupに対して何をしたかを確認しましょう。最初のステップでは、Sequencer はロールアップ トランザクションを収集してバッチにパッケージ化し、L1 コントラクトに送信します。 L1はDAレイヤーの機能を提供するだけでなく、実際にトランザクションの順序付け機能の一部を完了し、Sequencerにトランザクションを送信すると、Sequencerはトランザクションの順序を自由に変更する権限を持っているため、トランザクションは実際には順序付けられませんが、トランザクションがバッチに含まれてL1コントラクトに送信されると、トランザクションの順序を変更する権利は誰にもありません。2 番目のステップでは、アグリゲーターは L1 コントラクトに有効証明をもたらして新しい状態に到達し、アグリゲーターは提案者のようなロールであり、コントラクトはバリデーターの役割に似ており、アグリゲーターは新しい状態が正しいことを証明するために有効証明を提供し、私が提供する有効性をバリデーターに伝えます 証明にはどのトランザクションバッチが関係し、L1のどこにあるか。次に、バリデーターはコントラクトから対応するバッチを抽出し、それをValidity Proofと組み合わせて状態遷移の正当性を検証し、検証が成功すると、コントラクトは実際に対応するValidity Proofの新しい状態に更新されます。 ### 第四に、スマートコントラクトのロールアップをモジュール性の観点から構築するモジュール性の観点から、Polygon zkEVMがスマートコントラクトロールアップタイプに属している場合、そのモジュールを分解してみることができ、Delphiが示した図から、Polygon ZkEVMは実際にはSmart Contrat Rollupのコンセンサスレイヤー、DAレイヤー、および決済であることがわかります レイヤーは実際には PolygonZkEVM.sol コントラクトに結合されていますが、これはよく区別されていません。 しかし、モジュールを分解してみましょう。データ可用性レイヤー: ロールアップ トランザクションが格納される場所であり、Polygon-zkEVM の場合、Sequencer が SequenceBatch() メソッドを呼び出すと、実際には DA レイヤーへのトランザクション データの送信が含まれます。決済レイヤー:具体的には、RollupとL1の間の資金の流れのメカニズム、特にPolygon-zkEVMの公式ブリッジを指します(これについては次の記事で詳しく説明します)。コンセンサスレイヤー:トランザクションの順序付けと、次の有効な状態(フォーク選択)を決定する方法が含まれており、SequencerはL1コントラクトでSequenceBatch()を呼び出すとトランザクションの順序付けを完了し、アグリゲーターがL1コントラクトでTustedVerifyBatches()を呼び出すと次の法的状態を確認します。実行レイヤー: ユーザーが Sequencer にトランザクションを送信し、Sequencer の実行後に新しい状態が取得されるときに、トランザクションが実行され、新しいワールド状態が取得されるプロセス ( そのため、L1 はトランザクションを実行して新しい状態を取得するプロセスをロールアップにアウトソーシングし、シーケンサーは zkProver をデリゲートしてアグリゲーターを介して有効証明を生成するため、ロールアップは計算スケーリングであると言いがちです。 ### 5. Polygon-zkEVMがL1のセキュリティを継承する理由上記の全体的なプロセスから判断すると、Sequencerは実際にはEthereum Proposerと似たようなことをしており、トランザクションのバッチが有効なトランザクションであることを提案し、実行後にこのトランザクションのバッチの新しい状態を与え、L1コントラクトの検証ロジックは、すべてのL1バリデーターが独自のイーサリアムクライアントで実行されるのと同等であり、実際には、すべてのイーサリアムバリデーターがRollupのバリデーターとして機能するため、PolygonはzkEVMであると考えています イーサリアムのセキュリティを継承。一方、Rollupsのすべてのトランザクションと状態はEthereumに保存されているため、Polygon zkEVMチームが逃げたとしても、誰でもEthereumに保存されているデータに基づいてRollupネットワーク全体を回復することができます。### 6. Polygon zkEVMのインセンティブメカニズムロールアップ インセンティブは、主にシーケンサーとアグリゲーターを収益性の高いものにし、作業を継続する方法に関するものです。 まず、ユーザーはRollupでETH建てでブリッジETHで支払われる取引手数料を自分で支払う必要があります。シーケンサーは、ロールアップトランザクションを含むバッチをL1トランザクションのコールデータにアップロードするコスト(SequenceBatch(batches())を呼び出すコスト)を支払う必要があり、Maticはバッチがアップロードされると同時にL1コントラクトに一定量のMaticを支払う必要があり、後でこれらのバッチの有効性証明を提供するアグリゲータのコストを支払うことになります。アグリゲーターは信頼できる VerifyBatches を呼び出して、まだファイナリティに達していない L1 コントラクト内のバッチの有効性証明を提供しますが、Sequencer は、有効性証明を提供したことに対する報酬として、契約で Sequencer によって事前に支払われた MATIC トークンを取得することもできます。シーケンサーの収益 = ロールアップ内のすべてのトランザクションのガス料金 - L1 へのバッチのアップロードに費やされた L1 ネットワークのガス料金 - アグリゲーターに支払われた構成証明料金 (MATIC 単位)。アグリゲーターの収益 = シーケンサーが支払ったMATIC報酬 - L1の有効性証明に提出されたガス料金 - 有効性証明の生成に費やされたハードウェア料金。アグリゲーターに支払うアテステーション料金を調整し、シーケンサーがストライクに不採算にならないように、シーケンサーがアグリゲーターに支払うアテステーション料金を調整するために、以下の仕組みが提供されています。コントラクトには、バッチの配達確認を提供するコストを調整するメソッドがあります。関数\_updateBatchFee(uint64 newLastVerifiedBatch)内部これは、BatchFeeと呼ばれるコントラクトの変数を変更し、Sequencerが各バッチに対して支払うMATICトークンの量を決定します。変更のメカニズムは次のとおりです。コントラクトは、Sequencer によって L1 にコミットされた後、その時間内に検証される各バッチの予想される状態を表す変数 VeryBatchTimeTarget を保持します。コントラクトは、VeryBatchTimeTarget を超えた後に検証されなかったすべてのバッチを記録し、これらのバッチの合計数が DiffBatches として記録されます。したがって、バッチが遅れると、BatchFeeは次の式で調整されます。MultiplierBatchFee は 1000 ~ 1024 の範囲に制限された数値で、契約管理者が関数 setMultiplierBatchFee() を使用して変更できます。FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdminここで MultiplierBatchFee と 10^3 を使用しているのは、小数点以下 3 桁以降の調整精度を実現するためであることに注意してください。  同様に、バッチが事前にある場合は、対応するbatchFee調整メカニズムがトリガーされます。 DiffBatchesは、早期検証状態のバッチの数を示します。  ### まとめ本記事では、Polygon zkEVMのコアメカニズムを整理し、イーサリアムの計算スケーリングを実現するための実現可能性を分析します。 以下の記事では、プロトコルの内部について掘り下げ、zkEVMブリッジの設計の詳細、シーケンサーの分散化ルート、zkProverの実装、zkEVMの設計原則を分析します。——つづく——
zkEVMシリーズ第1弾:Polygon zkEVMのアーキテクチャとトランザクション実行プロセス全体
著者: 0xhhh, Ethstorage(Twitter:@hhh69251498 )
編集:レッドワン
3月27日、Polygon zkEVMメインネットのベータ版が正式にローンチされ、Vitalikは最初の取引を完了しました。
本稿は、Polygon zkEVMの全体的なアーキテクチャとトランザクション実行プロセスについて簡単に説明し、Polygon zkEVMがイーサリアムのセキュリティを継承しながらどのように計算スケーリングを実現しているかを分析する、Polygon zkEVMに関する一連の記事の第1弾です。
次の2つの記事では、Polygon zkEVMのzkEVM BridgeとzkEVMの設計の詳細、およびPolygon zkEVMの次の分散型シーケンサーのロードマップについても詳しく説明します。
まず、ロールアップはイーサリアムの計算スケーリングを実現するためのものです
まず、ロールアップのしくみを明確にする必要があります。 Rollupの登場は、イーサリアムの計算をスケーリングすることであり、具体的な実装方法は、トランザクションの実行をRollupにアウトソーシングし、トランザクションとトランザクション実行後の状態(State)をイーサリアムのコントラクトに格納することです。
オプティミスティック ロールアップ
楽観的に考えれば、ロールアップトランザクションとそれに対応するロールアップステートがイーサリアムに送信され、不正防止を提供することで、誰でもチャレンジ期間内のロールアップステートに異議を唱えることができます。
ゼロ知識ロールアップ
ZKは、イーサリアムに送信されたロールアップトランザクションの有効性証明と、対応するロールアップ状態(対応するトランザクションの実行後にロールアップが正しい状態にあることを証明するために、イーサリアム上のコントラクトによって検証される)を提供します。
イーサリアムの公式定義を参照してください:
ゼロ知識ロールアップとオプティミスティックロールアップの最大の違いは、状態の有効性を検証する方法が異なるため、最終段階に到達するまでの時間が異なることです。
オプティミスティックロールアップは、イーサリアムに提出されたトランザクションとステータスが正しいことを楽観視しているため、7日間のチャレンジ期間(最終到達までの時間は7日間)があり、その間にイーサリアム上のトランザクションの対応する状態が正しくないことがわかった人は誰でも、正しいステータスを送信することでチャレンジすることができます。
ゼロ知識ロールアップ(zk-Rollup)がファイナリティに達するまでにかかる時間は、トランザクションの有効性証明がイーサリアムに提出され、検証されるまでの時間によって異なります。 現時点では、最終決定までに約1時間かかる場合があります(ガス代を考慮する必要があるため)。
2番目、Polygon zkEVM実行プロセス
ここでは、Polygon zkEVMがシンプルなトランザクション確認プロセスでどのように機能し、プロトコル全体を具体的に理解するか、そのプロセス全体を3つの主要なステップに分けることができるかを見てみましょう。
シーケンサーは、複数のユーザー トランザクションをバッチにパッケージ化し、L1 コントラクトに送信します。
Proverは、取引ごとに有効証明を生成し、複数の取引の有効性証明を1つの有効性証明に集約します。
アグリゲーターは、アグリゲーターが複数のトランザクションをL1コントラクトに集約した有効性証明を提出します。
**1 Sequencer は、ユーザー トランザクションをバッチにパッケージ化し、L1 コントラクトに送信します。
1)ユーザーがトランザクションをシーケンサーに送信し、シーケンサーはトランザクションを受信順序(FRFS)でローカルに処理し、シーケンサーがトランザクションをローカルで実行すると、ユーザーがシーケンサーが誠実であると信じた場合、トランザクションがファイナリティに達したと見なすことができます。 ここで注意したいのは、現在Sequencer内のMempoolのほとんどがプライベートであるため、当面入手できるMEVは比較的少ないということです。
(L1のガス消費量を可能な限り削減するために、一度に複数のバッチが送信されることに注意してください。
上記の実際のプロセスは、L1 がロールアップ DA レイヤーとして完了する必要がある作業でもあります (この時点では、状態検証や昇格作業は完了していません)。
**2. アグリゲーターは、トランザクションの複数のバッチに対して有効性証明を生成します
アグリゲーターは、L1 の PolyonZKEVM.sol コントラクトで新しいバッチが正常に送信されたことをリッスンすると、これらのバッチをノードに同期し、これらのトランザクションを zkProber に送信します。
これらのトランザクションを受け取った後、zkProverはトランザクションごとにValidity Proofを生成し、複数のバッチに含まれるトランザクションのValidity ProofをValidity Proofに集約します。
3. アグリゲーターは、集計証明の契約を L1 に提出します。
アグリゲーターは、次のメソッドを呼び出すことで、この Validity Proof を L1 の Polygon zkEvm.sol コントラクトに、対応するバッチ実行の状態と共に送信します。
次に、コントラクト内で次のアクションが実行され、状態遷移が正しいことが確認されます。
このステップがL1コントラクトで正常に実行されると、バッチのこの部分に含まれるすべてのトランザクションが本当にファイナリティに到達します(OPの7日間のチャレンジ期間の終了に対応)。
3. Polygon-zkEVMにおけるイーサリアムの役割
Polygon zkEVMの全体的なプロセスを見てきたので、イーサリアムがRollupに対して何をしたかを確認しましょう。
最初のステップでは、Sequencer はロールアップ トランザクションを収集してバッチにパッケージ化し、L1 コントラクトに送信します。 L1はDAレイヤーの機能を提供するだけでなく、実際にトランザクションの順序付け機能の一部を完了し、Sequencerにトランザクションを送信すると、Sequencerはトランザクションの順序を自由に変更する権限を持っているため、トランザクションは実際には順序付けられませんが、トランザクションがバッチに含まれてL1コントラクトに送信されると、トランザクションの順序を変更する権利は誰にもありません。
2 番目のステップでは、アグリゲーターは L1 コントラクトに有効証明をもたらして新しい状態に到達し、アグリゲーターは提案者のようなロールであり、コントラクトはバリデーターの役割に似ており、アグリゲーターは新しい状態が正しいことを証明するために有効証明を提供し、私が提供する有効性をバリデーターに伝えます 証明にはどのトランザクションバッチが関係し、L1のどこにあるか。
次に、バリデーターはコントラクトから対応するバッチを抽出し、それをValidity Proofと組み合わせて状態遷移の正当性を検証し、検証が成功すると、コントラクトは実際に対応するValidity Proofの新しい状態に更新されます。
第四に、スマートコントラクトのロールアップをモジュール性の観点から構築する
モジュール性の観点から、Polygon zkEVMがスマートコントラクトロールアップタイプに属している場合、そのモジュールを分解してみることができ、Delphiが示した図から、Polygon ZkEVMは実際にはSmart Contrat Rollupのコンセンサスレイヤー、DAレイヤー、および決済であることがわかります レイヤーは実際には PolygonZkEVM.sol コントラクトに結合されていますが、これはよく区別されていません。 しかし、モジュールを分解してみましょう。
データ可用性レイヤー: ロールアップ トランザクションが格納される場所であり、Polygon-zkEVM の場合、Sequencer が SequenceBatch() メソッドを呼び出すと、実際には DA レイヤーへのトランザクション データの送信が含まれます。
決済レイヤー:具体的には、RollupとL1の間の資金の流れのメカニズム、特にPolygon-zkEVMの公式ブリッジを指します(これについては次の記事で詳しく説明します)。
コンセンサスレイヤー:トランザクションの順序付けと、次の有効な状態(フォーク選択)を決定する方法が含まれており、SequencerはL1コントラクトでSequenceBatch()を呼び出すとトランザクションの順序付けを完了し、アグリゲーターがL1コントラクトでTustedVerifyBatches()を呼び出すと次の法的状態を確認します。
実行レイヤー: ユーザーが Sequencer にトランザクションを送信し、Sequencer の実行後に新しい状態が取得されるときに、トランザクションが実行され、新しいワールド状態が取得されるプロセス ( そのため、L1 はトランザクションを実行して新しい状態を取得するプロセスをロールアップにアウトソーシングし、シーケンサーは zkProver をデリゲートしてアグリゲーターを介して有効証明を生成するため、ロールアップは計算スケーリングであると言いがちです。
5. Polygon-zkEVMがL1のセキュリティを継承する理由
上記の全体的なプロセスから判断すると、Sequencerは実際にはEthereum Proposerと似たようなことをしており、トランザクションのバッチが有効なトランザクションであることを提案し、実行後にこのトランザクションのバッチの新しい状態を与え、L1コントラクトの検証ロジックは、すべてのL1バリデーターが独自のイーサリアムクライアントで実行されるのと同等であり、実際には、すべてのイーサリアムバリデーターがRollupのバリデーターとして機能するため、PolygonはzkEVMであると考えています イーサリアムのセキュリティを継承。
一方、Rollupsのすべてのトランザクションと状態はEthereumに保存されているため、Polygon zkEVMチームが逃げたとしても、誰でもEthereumに保存されているデータに基づいてRollupネットワーク全体を回復することができます。
6. Polygon zkEVMのインセンティブメカニズム
ロールアップ インセンティブは、主にシーケンサーとアグリゲーターを収益性の高いものにし、作業を継続する方法に関するものです。
まず、ユーザーはRollupでETH建てでブリッジETHで支払われる取引手数料を自分で支払う必要があります。
シーケンサーは、ロールアップトランザクションを含むバッチをL1トランザクションのコールデータにアップロードするコスト(SequenceBatch(batches())を呼び出すコスト)を支払う必要があり、Maticはバッチがアップロードされると同時にL1コントラクトに一定量のMaticを支払う必要があり、後でこれらのバッチの有効性証明を提供するアグリゲータのコストを支払うことになります。
アグリゲーターは信頼できる VerifyBatches を呼び出して、まだファイナリティに達していない L1 コントラクト内のバッチの有効性証明を提供しますが、Sequencer は、有効性証明を提供したことに対する報酬として、契約で Sequencer によって事前に支払われた MATIC トークンを取得することもできます。
シーケンサーの収益 = ロールアップ内のすべてのトランザクションのガス料金 - L1 へのバッチのアップロードに費やされた L1 ネットワークのガス料金 - アグリゲーターに支払われた構成証明料金 (MATIC 単位)。
アグリゲーターの収益 = シーケンサーが支払ったMATIC報酬 - L1の有効性証明に提出されたガス料金 - 有効性証明の生成に費やされたハードウェア料金。
アグリゲーターに支払うアテステーション料金を調整し、シーケンサーがストライクに不採算にならないように、シーケンサーがアグリゲーターに支払うアテステーション料金を調整するために、以下の仕組みが提供されています。
コントラクトには、バッチの配達確認を提供するコストを調整するメソッドがあります。
関数_updateBatchFee(uint64 newLastVerifiedBatch)内部
これは、BatchFeeと呼ばれるコントラクトの変数を変更し、Sequencerが各バッチに対して支払うMATICトークンの量を決定します。
変更のメカニズムは次のとおりです。
コントラクトは、Sequencer によって L1 にコミットされた後、その時間内に検証される各バッチの予想される状態を表す変数 VeryBatchTimeTarget を保持します。
コントラクトは、VeryBatchTimeTarget を超えた後に検証されなかったすべてのバッチを記録し、これらのバッチの合計数が DiffBatches として記録されます。
したがって、バッチが遅れると、BatchFeeは次の式で調整されます。
MultiplierBatchFee は 1000 ~ 1024 の範囲に制限された数値で、契約管理者が関数 setMultiplierBatchFee() を使用して変更できます。
FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin
ここで MultiplierBatchFee と 10^3 を使用しているのは、小数点以下 3 桁以降の調整精度を実現するためであることに注意してください。
同様に、バッチが事前にある場合は、対応するbatchFee調整メカニズムがトリガーされます。 DiffBatchesは、早期検証状態のバッチの数を示します。
まとめ
本記事では、Polygon zkEVMのコアメカニズムを整理し、イーサリアムの計算スケーリングを実現するための実現可能性を分析します。 以下の記事では、プロトコルの内部について掘り下げ、zkEVMブリッジの設計の詳細、シーケンサーの分散化ルート、zkProverの実装、zkEVMの設計原則を分析します。
——つづく——