Ethereumアカウントの内部動作の仕組み

イーサリアムは、外部所有アカウント（EOA）と契約アカウントの2種類のアカウントを使用します。EOAはプライベートキーによって制御され、個人やアプリケーションが取引に署名するために使用されます。これらのアカウントは構造がシンプルです。ノンス、残高、関連する公開鍵が含まれますが、内部コードはありません。ユーザーがEOAから取引に署名すると、イーサリアム仮想マシン（EVM）は署名を検証し、取引を実行する前にガス料金を差し引きます。一方、契約アカウントはコードによって制御され、自ら行動を起こすことはありません。EOAによって引き起こされた取引にのみ応答します。EVMは契約ロジックを処理し、状態を保存しますが、契約は独自に取引に署名したり、外部からの入力なしに取引を開始したりすることはできません。

このアーキテクチャは、Ethereum上のアカウントの機能を制限します。すべてのアクティビティはEOAから始まる必要があり、すべてのトランザクションには有効な暗号署名が必要なため、多要素認証、ソーシャルリカバリー、バッチ処理などの高度な機能は複雑な回避策を必要とします。これらの制約は、すべてのアカウントをプログラム可能にし、ユーザー制御のアクティビティと契約制御のアクティビティの区別を統一するためのアカウント抽象化の概念を促しました。

アカウント抽象化がトランザクションの検証、ガス、およびアクセスにどのように影響するか

アカウント抽象化は、アカウント自体がアクションの承認と実行方法を定義できるようにすることで、トランザクションの検証経路を変更します。特定の秘密鍵からの署名を強制する代わりに、スマートコントラクトウォレットは認証のための独自のロジックを定義できます。このロジックには、閾値署名、ハードウェアデバイスチェック、支出制限やタイムロックのルールが含まれる場合があります。

アカウント抽象化によって導入された最も影響力のある変更の一つは、ガス料金の支払いを送信者から切り離すことです。従来、取引の発起人はETHでガス料金を支払う必要があります。アカウント抽象化の下では、検証ロジックにより、第三者（ペイマスターと呼ばれる）がユーザーの代わりにガス料金を負担することができます。これにより、初めてのユーザーのために取引を後援したり、ガスなしでdAppの相互作用を可能にしたり、安定コインやネイティブプロジェクトトークンで料金を支払ったりするなど、新しい可能性が開かれます。

さらに、アカウントアブストラクションは、複数の操作を1つのトランザクションにまとめる能力を導入します。たとえば、ユーザーはトークンを承認し、スワップを行い、資金を転送することを1回のアクションで行うことができ、必要な確認の数を減らし、ユーザー体験を向上させます。これらの改善は、dAppのインタラクションにおける摩擦を大幅に減少させる一方で、セキュリティとコンポーザビリティを維持します。

ERC-4337および「代替メモリープール」の紹介

ERC-4337は2023年に最終決定され、Ethereumのアカウント抽象化に向けた旅の重要なマイルストーンを表しています。EIP-2938などの以前の提案とは異なり、ERC-4337はEthereumのコンセンサスレイヤーの変更を必要としません。代わりに、既存のスマートコントラクト環境内で完全に機能し、代替メモリプールと特定のコントラクトアーキテクチャを使用して並行トランザクションフローを導入します。

ERC-4337の下では、トランザクションはUserOperationsに置き換えられます。これは、望ましいアクションを説明するデータオブジェクトですが、従来のメモリプールには提出されません。これらのUserOperationsは、バンドラーと呼ばれる専門のオフチェーンアクターによって取得されます。バンドラーは複数のUserOperationsを標準のEthereumトランザクションに集約し、それをブロックチェーンに提出します。

オンチェーンでは、EntryPointと呼ばれるシングルトン契約がこれらのバンドルされた操作を検証し、処理します。EntryPointはユーザーのスマートアカウントと相互作用し、これらのアカウントは独自の検証ロジックを定義し、検証が完了した後にトランザクションの実行を委任します。ガス料金を支払うために、アカウントはオプションでペイマスターと相互作用することができ、これによりコードで指定された条件の下で実行コストをスポンサーします。

この構造は、Ethereumの基本プロトコルを変更することなく、アカウント抽象をサポートするための分散型で許可不要な方法を実現します。その結果、開発者はユーザーの視点からEOAのように振る舞うスマートコントラクトウォレットを展開できるが、はるかに豊富な機能を提供します。

ソラナのアプローチ：ネイティブアカウント抽象化

ソラナは、プロトコルレベルでアカウント抽象化をサポートすることにより、根本的に異なるアプローチを取っています。ソラナのアカウントは、EOA（Externally Owned Accounts）とコントラクトアカウントに分かれていません。代わりに、ソラナのすべてのアカウントは、データを保持し、所有権を割り当て、プログラムと相互作用できる汎用ストレージコンテナです。

ソラナのモデルでは、アクションの検証はプログラム（スマートコントラクト）自体に組み込まれています。プログラム派生アドレス（PDA）は、このシステムの重要な要素です。これらはシードとプログラムから生成された決定論的なアドレスで、関連する秘密鍵はありません。代わりに、プログラムのロジックによって制御され、適切な条件が満たされるとアクションを実行できます。

このネイティブの柔軟性のおかげで、Solana はマルチシグネチャー認証、アカウント委任、第三者手数料支払いなどの機能を提供しており、外部標準やシミュレーションされた取引フローを必要としません。Phantom や Solflare のようなウォレットは、これらの機能を早期に統合しており、シームレスな UX と資金のプログラム可能な制御を実現しています。これは、同様の機能が ERC-4337 やバンドラーネットワークのようなオーバーレイに依存する Ethereum とは対照的です。