マルチチェーンアカウントの抽象化解析：暗号化インフラストラクチャの未来を探る

最近、イーサリアムコミュニティ会議（EthCC 7）がベルギーのブリュッセルで開催され、これはヨーロッパ最大規模のイーサリアム年次イベントで、技術とコミュニティに焦点を当てています。本会議では、350人以上のブロックチェーン業界の第一線の意見リーダーが講演を行い、その中の一人の開発者が「未来を明らかにする：マルチチェーンアカウントの抽象化解析」というタイトルの講演を行いました。

講演の核心ポイント

• アカウントの抽象化（AA）は、主に署名の抽象化と支払いの抽象化の2つの重要なポイントを含みます。署名の抽象化により、ユーザーは好みの検証メカニズムを選択でき、支払いの抽象化はさまざまな取引支払いオプションの使用を許可します。この柔軟性は、より安全で優れたユーザー体験を提供します。

• ERC-4337とネイティブAAにおいて、"検証"段階のエントリポイント関数は固定されていますが、"実行"段階ではネイティブAAでのみエントリポイントが固定されています。取引の検証制限と取引の実行手順は、異なる実装においてそれぞれの特徴と制限があります。

• EVM互換チェーン上でERC-4337を実装する際には、2つの重要な違いがあります：Rollup設計におけるプロトコルの違いとアドレス計算方法の違いです。これにより、L1とL2の間でERC-4337を実装する際に注意が必要な開発の詳細が生じます。

! 暗号インフラストラクチャの未来は? マルチチェーンアカウントの抄録解析

アカウントの抽象化の紹介

アカウントの抽象化とは何ですか

アカウントの抽象化（AA）は主に二つの重要なポイントを含みます：

1. サインの抽象化：ユーザーは特定のデジタル署名アルゴリズム（ECDSAなど）に限定されず、好みの検証メカニズムを選択できます。

2. 支払いの抽象化：ユーザーは、ERC-20資産をネイティブ資産の支払いに代替したり、第三者が取引をスポンサーするなど、さまざまな取引支払いオプションを使用できます。

この柔軟性は、より安全でより優れたユーザー体験を提供します。アカウントの抽象化の目標は、これらの2つの重要なポイントをさまざまな方法で実現することです。

ERC-4337の紹介

現在、Ethereumプロトコルの外部所有アカウント（EOA）には、固定された署名方法や支払い設計などのいくつかの制限があります。ERC-4337は、より柔軟なアカウント管理と取引処理方法を導入することで、これらの問題を解決します。

• userOp 構造体: ERC-4337 では、ユーザーが userOp 構造体を Bundler に送信します。 Bundler は複数の userOps を収集し、handleOps 関数を呼び出して EntryPoint コントラクトに送信します。

• EntryPointコントラクト：このコントラクトはオペレーティングシステムのようにトランザクションを処理し、主な機能は次のとおりです：

  • アカウント契約内のvalidate関数を呼び出し、userOpがアカウント所有者の承認を得ることを確認します。
  • 手数料を受け取る。
  • アカウントの契約内のexecute関数を呼び出し、userOpの対象操作を実行します。

ネイティブAAの紹介

イーサリアムでは、アカウントはEOAとコントラクトアカウントに分かれています。しかし、ネイティブAAでは、各アカウントはコントラクトであり、取引処理メカニズムはブロックチェーンプロトコルに直接組み込まれています。

各ブロックチェーンネットワークにおけるAA設計：

• ERC-4337 アカウントの抽象化: Ethereum、Arbitrum、Optimism、Base、Linea、Scroll、Polygon PoS
• ネイティブアカウントの抽象化はERC-4337に準拠しています：StarkNetとzkSyncの時代
• プライバシーデザインを備えたネイティブアカウントの抽象化：Aztec

! 暗号インフラストラクチャの未来は? マルチチェーンアカウントの抽象解析

ERC-4337とネイティブAAの違い

オペレーティングシステムの役割

AA OSは次の問題を解決する必要があります：

• 誰がガス価格を決定するのですか？
• 誰が取引の順序を決定しますか？メモリプールはどこにありますか？
• 誰がエントリーポイント関数をトリガーしましたか？
• 取引処理のフローは何によって決まりますか？

ERC-4337 では、これらのロールは Bundler と EntryPoint コントラクトを通じて協力して行われます。

ネイティブAAでは、ユーザーはそのuserOpsを公式サーバーのオペレーター/ソーターに送信し、BundlerやEntryPoint Contractではなくなります。

StarkNetでは、Sequencerがこれらすべてのタスクを処理します。

zkSyncにおいて、Eraと他のAA実装との主な違いは、Operatorがbootloader（システムコントラクト）と連携して作業する必要があることです。Bootloaderは新しいブロックを開き、そのパラメータ（ブロックパラメータやその他のGasパラメータを含む）を定義し、Operatorからのトランザクションを受け取って検証を行います。

コントラクトインターフェース

3つのステップが存在するため、アカウント契約インターフェースは異なる実装で類似しています。これらのエントリポイント関数はAA OSによってのみ呼び出すことができます：

• ERC-4337:ユーザー アクションの認証
• zkSync：トランザクションの検証、トランザクションの支払い、トランザクションの実行
• StarkNet:実行、検証、validate_declare、validate_deploy

ERC-4337とネイティブAAでは、"検証"段階のエントリーポイント関数は固定されていますが、"実行"段階では、ネイティブAAのエントリーポイントのみが固定されています。

検証ステップの制限

取引の検証にはコスト制限がないため（本質的に、取引の検証はビュー関数の呼び出しです）、攻撃者はメモリプールにDoS攻撃を仕掛け、バンドル器（EIP-4337）またはオペレーター/ソーター（ネイティブAA）を破壊することができます。

EIP-4337は、禁止されているオペコードとストレージアクセスの制限方法を定義しています。zkSync Eraは、一部のオペコードの使用を緩和しました。

• コントラクトロジックは自分のストレージスロットにのみアクセスできます。アカウントコントラクトのアドレスがアドレスAである場合、アクセスできるのは：

  • アドレスAに属するストレージスロット
  • アドレスAに属するストレージスロット
  • 他のアドレスに属するストレージスロットkeccak256(A || X)：これは、マッピング内でアドレスをキーとして直接使用することを意味します（たとえば、マッピング(address => value)）、これはスロットkeccak256(A || X)にアクセスすることに相当します。例えば、ERC-20コントラクト内の資産残高。

• コントラクトのロジックは、ブロック番号などのグローバル変数にアクセスできません。StarkNetは外部コントラクトの呼び出しも許可していません。

実行ステップの制限

zkSyncでは、システムコールを実行するにはシステムフラグの存在を確認する必要があります。例えば、nonceを増加させる唯一の方法はNonceHolderと対話することであり、契約をデプロイするにはContractDeployerと対話する必要があります。システムフラグは、アカウント開発者が意識的にシステム契約と対話していることを保証します。

ERC-4337とStarkNetでは、実行フェーズに特別な制限はありません。

ランダム数

• ERC-4337では、エントリーポイントのランダム数の設計が192ビットのキー値と64ビットのランダム値を区別します。
• zkSyncにおいて、NonceHolderシステムコントラクトはnonceを管理し、厳密に増加することを保証します。つまり、ランダム数を1増やします。
• StarkNetでは、nonceも厳密に増加しますが、特定のコントラクトによって管理される抽象のnonceはありません。

を使用して最初のトランザクションをデプロイします

• ERC-4337はuserOp構造体にinitcodeフィールドを含み、最初のuserOpで送信者（アカウント契約）をデプロイします。
• StarkNetとzkSyncでは、ユーザーはアカウント契約をデプロイするために最初の取引をオペレーター/ソートナーに送信する必要があります。

zkSyncの特別なデザイン###

もしあなたがETHをEthereumのEOAからzkSyncに直接移動させると、カスタムアカウントコントラクトをデプロイする必要はなく、同じアドレスを持つデフォルトアカウントが受け取られます。このアカウントはEthereumのEOAのように機能し、対応するEthereumのEOAの秘密鍵によっても制御されます。

このアカウントタイプはバージョンNoneであり、version1ではありません。DefaultAccountの関数を呼び出すことはできません。なぜなら、それはカーネル空間にコードをデプロイしていないからです。

! 暗号インフラストラクチャの未来は? マルチチェーンアカウントの抄録解析

L1の4337とL2の4337の違い

EVM互換チェーン上でERC-4337を実施するには、2つの重要な違いがあります：プロトコルの違いとアドレスの違い。

プロトコルの違い

Rollup設計において、L2はセキュリティと決済のためにデータをL1にアップロードする必要があります。ERC-4337の文脈では、このアップロードプロセスに関連する費用、例えばL1のセキュリティ費用とblob費用は、事前検証Gasに含めるべきです。事前検証Gasに適切なアップロード費用を決定することは重大な課題です。

アドレスの違い

zkSync ERAのcreate関数におけるアドレスエンコーディング方式は、イーサリアムやOPのサマリーとは異なります。さらに、StarkNetは独自のハッシュ関数を使用してアドレス計算を行います。EVM互換チェーン上のERC-4337の背景において、通常、各チェーン上でのアドレス計算が一貫していると仮定します。しかし、イーサリアムとL2におけるERC-4337実装間でアカウントコントラクトアドレスが異なる可能性がある注意すべき詳細があります。

重要な問題は、ハードフォークで新しいオペコードを追加することです。例えば、L2チェーンが上海ハードフォークをサポートしておらず、コンパイル時にEVMバージョンが指定されていない場合、push0の導入はバイトコードを変更させることになります。同じSolidityコードであっても。

! 暗号インフラストラクチャの未来は? マルチチェーンアカウントの抄録解析