マルチチェーンアカウントの抽象化解析：暗号化基盤の未来を探る

2024年7月8日至11日、ヨーロッパ最大規模のイーサリアム年次イベント——イーサリアムコミュニティカンファレンス（EthCC）がベルギーのブリュッセルで開催され、技術とコミュニティの発展に焦点を当てます。

本年度のイーサリアムコミュニティカンファレンス（EthCC 7）では、350人以上のブロックチェーン業界の第一線の意見リーダーが講演を行う招待を受けました。imToken Labsの開発者であるAlfredが招待され、"未来を明らかにする：マルチチェーンアカウントの抽象化解析"というタイトルの講演を行いました。

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

発表のポイントの概要

• アカウントの抽象化（AA）の二つのコア：署名の抽象化と支払いの抽象化。署名の抽象化はユーザーが任意の検証メカニズムを選択できるようにし、支払いの抽象化は様々な取引支払いオプションを提供し、安全性とユーザー体験を向上させます。

• ERC-4337とネイティブAAの「検証」段階のエントリーポイント関数はどちらも固定されていますが、「実行」段階ではネイティブAAのみが固定エントリーポイントを保持しています。異なる実装方式は、取引の検証制限と取引の実行ステップにおいてそれぞれの特徴があります。

• EVM互換チェーン上でERC-4337を実装する際には、主に2つの重要な違いがあります：ロールアップ設計におけるプロトコルの違いとアドレス計算方法の違いです。これらの違いは、L1とL2の間でERC-4337を実現する際に見落とされがちな開発の詳細を引き起こします。

アカウントの抽象化の概要

1. アカウントの抽象化の定義

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

• サインの抽象化：ユーザーは特定のデジタル署名アルゴリズム（例：ECDSA）に制限されることなく、検証メカニズムを自由に選択できます。
• 支払いの抽象化：ユーザーはERC-20資産をネイティブ資産の支払いの代わりに使用する、または第三者が取引をスポンサーするなど、さまざまな取引支払いオプションを利用できます。

この柔軟性は、安全性とユーザーエクスペリエンスを大幅に向上させます。アカウントの抽象化は、これらの2つのコア目標をさまざまな方法で達成することを目指しています。

2. ERC-4337 解析

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

• userOp 構造体: ERC-4337 では、ユーザーが userOp 構造体を Bundler に送信します。 Bundler は複数の userOps を収集し、handleOps 関数を呼び出して EntryPoint コントラクトに送信します。
• EntryPointコントラクト：このコントラクトはオペレーティングシステムに似ており、取引の主要な機能には以下が含まれます：
  • アカウント契約におけるvalidate関数を呼び出し、userOpがアカウント所有者の承認を得ていることを確認します。
  • 手数料を徴収する。
  • アカウント契約のexecute関数を呼び出し、userOpの目的の操作を実行します。

3. ネイティブAAの紹介

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

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

• ERC-4337 アカウントの抽象化: Ethereum、Arbitrum、Optimism、Base、Linea、Scroll、Polygon PoS
• ERC-4337のネイティブアカウントの抽象化に従う：StarkNetとzkSync Era
• プライバシーデザインを備えたネイティブアカウントの抽象化：Aztec

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

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

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

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

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

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

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

StarkNetでは、シーケンサーがこれらすべてのタスクを処理します。

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

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

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

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

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

3. 検証ステップの制限

取引の検証にコスト制限がないため、攻撃者はメモリプールに対してDoS攻撃を行い、バンドラー（EIP-4337）やオペレーター/ソーティング（ネイティブAA）に影響を及ぼす可能性があります。

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

• コントラクトロジックは自分のストレージスロットにのみアクセスできます。アカウントコントラクトのアドレスがアドレスAである場合、アクセスできるのは：
  • アドレスAに属するストレージスロット
  • 他のアドレスAに属するストレージスロット
  • どの他のアドレスにも属さないストレージスロットkeccak256(A || X)：これは、アドレスをマッピングのキーとして直接使用することを意味し、スロットkeccak256(A || X)にアクセスするのと同等です。たとえば、ERC-20コントラクトの資産残高。
• コントラクトのロジックは、ブロック番号などのグローバル変数にアクセスできません。StarkNetは外部コントラクトの呼び出しも許可していません。

4. 実行ステップの制限

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

ERC-4337およびStarkNetでは、実行段階に特別な制限はありません。

5. ランダム数

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

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

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

7. zkSyncの特別なデザイン

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

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

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

L1の4337とL2の4337の違い

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

1. プロトコルの違い

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

2. アドレスの差異

zkSync ERAのcreate関数におけるアドレスエンコーディング方式は、EthereumとOPのアグリゲーションとは異なります。また、StarkNetはアドレス計算に独自のハッシュ関数を使用しています。EVM互換チェーン上のERC-4337の文脈において、私たちは通常、各チェーンでのアドレス計算が一貫していると仮定します。しかし、EthereumとL2におけるERC-4337の実装間でアカウントコントラクトアドレスが異なる可能性がある気づきにくい詳細があります。

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

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