メインコンテンツへスキップする

zkEVMのプロトコルに関する質問

このドキュメントでは、Astar zkEVM のプロトコルに関するよくある質問を解説します。 詳細については、Polygon zkEVM documentationをご覧ください。

How are transactions collected and ordered?​

  • Astar zkEVMネットワーク上のトランザクションはユーザーのウォレットで作成され、そこで管理されている秘密鍵で署名されます。
  • 生成され署名されると、トランザクションは信頼されているシーケンサーのノードに送信されます。その際、JSON-RPCインターフェイスを介してやり取りがなされます。
  • それからトランザクションは、保留中のトランザクションプールに保存され、シーケンサーに選択されるのを待ちます。
  • シーケンサーはプールからトランザクションを読み取り、それを棄却するか、注文し、実行するかを決めます。
  • 最後に、シーケンサーはトランザクションをバッチにまとめ、次にバッチの順序づけを行います。

Rollupバッチを作る前にシーケンサーが待つ時間やトランザクションのインターバルはありますか?​

シーケンサーには常にオープンバッチがあります。 トランザクションは、このバッチがいっぱいになるか、長いタイムアウトが発生するまで、このバッチに追加されます。 これらのバッチは128K個のバッチ(または大きなタイムアウト)に達するまで蓄積され、蓄積したらL1へのシーケンシングトランザクションが送信されます。

L2ユーザーの観点からは、新しいL2ブロック(L2バッチとは異なる)がクローズされ、ユーザーに送信されるように見えます。 ユーザーには、L2 バッチがクローズされていない場合でも、トランザクションが確定したように見えます。 1つの L2 トランザクションで1つの L2 ブロックだからです。

L1でファイナライズされるためにトランザクションはどのような過程を通過しますか?​

バッチ内の特定のトランザクションを検証するプロセスには、通常、3つのステップが必要です。

  1. Trusted State: トランザクションは信頼のあるシーケンサーによってほとんど瞬時にこの状態になります。 L1でのトランザクションは必要ありません。

  2. Virtual State: トランザクションはL1にあります。 状態が確定的で、計算が容易なため、この状態のトランザクションとその順番は変更できません。

  3. Verified State: virtual stateがスマートコントラクトによって検証されると、資金を引き出すことが可能になります。

シーケンサーは証明を生成するためにどのようにトランザクションを検証しますか?​

シーケンサーはトランザクションプールからトランザクションを取得し、それが正しくフォーマットされ、必要なすべての情報を含んでいることを確認します。 シーケンサーは以下の点をチェックします：

  • 送金者がトランザクションのガス代とスマートコントラクトにより必要とされる十分な資金を持っていることを確認することで、取引が有効であることを確認します。 もし十分な資金を持っていれば、有効で、正しいバイトコードを生成します。

  • 送信者のトランザクションナンスをチェックし、最後に使用されたナンスより1だけ大きいものであることを確認することで、トランザクションが複製されていないことを確認します。

  • 送信者の口座残高が別のトランザクションで既に使われていないことを確認して、トランザクションが二重支払いでないことを確認します。

トランザクションが有効と見なされると、シーケンサーは必要に応じてスマートコントラクトと口座残高の状態を更新し、Astar zkEVMの現在の状態にトランザクションを適用します。 所要時間とコストは、ネットワークの混雑具合や一般的なガス価格によって異なります。

トランザクションがAstar zkEVMでファイナリティを達成するのはいつですか?​

ユーザーがシーケンサーを信頼している場合、トランザクションはシーケンサーにより順序づけられた時点 (すなわちTrusted State) で確定したとみなされます。

ユーザーがL1の状態のみを信頼する場合、トランザクションはVirtual Stateに到達した瞬間に確定します。 つまり、データが利用可能で、トランザクションが既にL1にある状態になった瞬間です。

ユーザーが資金を引き出す必要がある場合、プルーバー (証明発行者) が、変更不可能だが未検証の状態を検証済の状態へと変換するのを待つ必要があります。 この最後の状態をConsolidatedもしくはVerified Stateと呼びます。

シーケンサーとプルーバーはエコシステム内部の人物ですか？それとも外部の人物ですか？ シーケンサーとプルーバーの分散性はどのようにして保証されますか？​

Astar zkEVMのシーケンサーは、初期段階においては中央集権的にならざるを得ません。 今後のリリースでシーケンサーを分散化するロードマップがあります。

同様に、プルーバーも最初は集中していますが、ビジョンとしてはプルーバーの市場を成立させることを目指しています。 プルーバーは証明を生成すること以外はほとんど役割を持ちません。 分散したプルーバーのシステムを構築することは、シーケンサーで同じことをするよりもはるかに重要 (そして難しい) です。

zkNode はシーケンサーとアグリゲーターの両方として機能できますか? そうでない場合、ノードが果たす役割をどのようにして決定するのですか?​

zkNode は、ゼロ知識証明プロトコルの具体的な実装に応じて、シーケンサーとアグレガターの両方として機能することが可能です。

また実装によっては、ノードは一方の機能のみしか実行できないかもしれません。 ノードが果たしうる役割は、プロトコルの特定の実装とネットワークの要件によって決定されます。 例えば、 プロトコルによっては、ネットワークのセキュリティと効率性を確保するために、シーケンサーの役割とアグリゲータの役割を実行するためにそれぞれ特定の数のノードを必要とする場合があります。

状態同期コンポーネントは、トランザクションバッチとその有効性証明がL1上でミントされた後、どのようにしてL2で同期されますか?​

簡単にまとめると、バッチごとに、globalExitRootという名前のハッシュがL1 → L2へと転送され、localExitRootという名前の別のハッシュがL2 → L1へと転送されます。

globalExitRoot は主に、全ての入金内容を含んでおり、localExitRoot は全ての出金内容を含んでいます。

Forced Batchとは何ですか?​

Forced BatchはL1トランザクションに含まれるL2バッチです。 信頼されたシーケンサーはこれらのバッチをトランザクションに含まなければなりません。 これは、シーケンサーの検閲を受けてもユーザーが資金を引き出せることを保証する仕組みです。

この性質に、よりシステムの検閲耐性を模倣します。

Emergency Stateとは何ですか、そしてどのような時、それは発動しますか？​

Emergency Stateはバッチの順序づけ、バッチの検証、forced batchなどの機能を停止させます。

これは、スマートコントラクトの所有者、またはAstar zkEVMの場合、Security Councilマルチシグによって引き起こされます。 つまり、保留中の状態がタイムアウトに達した場合や脅威となる脆弱性が発生した場合、Security Councilが緊急状態を呼び出せるということです。