詳細丨Vitalik が提案した EIP-2938 は Ethereum にどのような変化をもたらすのでしょうか?

Ethereum には 2 種類のアカウントがあります。外部所有アカウント (EOA) と契約アカウント (CA)。 EOA は秘密鍵によって制御され、CA はその中に含まれるスマート コントラクト コードによって制御されます。 EOA だけがガスを支払ってトランザクションの実行を開始できるため、EOA は常に CA よりも特権を持っています。アカウント抽象化 (AA) は、契約を、手数料を支払ってトランザクションの実行を開始できる EOA のような「トップレベル」のアカウントにできるようにする提案です。

アカウント抽象化の目的は、ウォレット、DApps、DeFi などのさまざまなシナリオでユーザーが Ethereum とやり取りする際のユーザー エクスペリエンスを大幅に向上させることです。アカウントの抽象化は、ガスをいつ支払うことができるか、誰にガスを支払うことができるかを決定するための Ethereum の機能の基本レイヤーを提供します。

Status Messenger アプリは、プライバシー重視のメッセージング システムのほか、Ethereum ウォレットと Web3 DApp ブラウザーを統合しています。 Status ウォレットは現在 EOA ウォレットであるため、マルチ署名セキュリティ、ソーシャルリカバリ、金利制限、許可/拒否アドレスリスト、ガスフリーのメタトランザクションなど、スマートコントラクトウォレットだけが提供できる豊富なユーザーエクスペリエンスを提供することができません。現在、スマートコントラクトウォレットのユーザーはガス料金の変動の影響を経験しており、サードパーティのリレーラーはこの問題を効果的に解決できません。アカウントの抽象化はこの問題を解決することを目的としています。

本稿では、スマート コントラクト ウォレットのコンテキストにおけるアカウント抽象化の必要性を提案しました。次に、プロトコルの変更とノードへの影響を説明して、アカウント抽象化の重要な側面をさらに深く掘り下げます。最後に、いくつかの拡張提案について議論し、アカウント抽象化の影響を受ける可能性のある、Ethereum とインターフェースする Status プロジェクトの計画ロードマップを合理化して終了しました。

歴史と動機

アカウントの抽象化は、2017 年に EIP-86 として初めて提案されました。これは、「トランザクションの起源と署名の要約」を実現することを目的としていますが、このアイデアの起源は、それより前の 2016 年にまで遡ることができます。当時、ある人が次のように提案しました。「ECDSA とデフォルトの nonce スキームをアカウントを安全に保つ唯一の「標準」の方法にするプロトコル内メカニズムを使用するよりも、長期的にはすべてのアカウントが契約であり、契約でガス料金を支払うことができ、ユーザーが独自のセキュリティ モデルを自由に定義できるモデルを構築するための初期ステップを踏む方が良いでしょう。」

当初の提案は、多くのプロトコルを変更する必要があり、セキュリティを保証する必要があったため、困難であると考えられていました。最近、Vitalik et al. EIP-2938 のドラフトを提案しました。これは、プロトコル/コンセンサスの変更を最小限に抑え、ノード メモリ プール ルールを通じて必要な安全性の保証を強制するという、より簡単に実装できるアプローチを概説しています。 Vitalik の Ethereum Engineering Group Meetup プレゼンテーションと、Sam Wilson と Ansgar Dietrichs (他の 2 人の EIP 著者) が執筆した ETH Online プレゼンテーション (および関連記事 1 と 2) では、このトピックについてさらに詳しく紹介しています。この記事では、これらすべての情報源から得られる重要なポイントを紹介します。

動機: アカウント抽象化の背後にある動機は非常に単純ですが、根本的なものです。現在の Ethereum トランザクションにはプログラム可能な効果 (スマート コントラクトを呼び出すことによって実装) がありますが、その有効性は固定されており、つまり、トランザクションは、有効な nonce を持つ有効な ECDSA 署名があり、十分なアカウント残高がある場合にのみ有効です。アカウント抽象化は、新しいアカウント抽象化トランザクション タイプを導入することで、トランザクションを固定の有効性からプログラム可能な有効性にアップグレードします。このアカウント抽象化トランザクション タイプは常に特定のアドレスから送信され、プロトコルでは署名、ノンス、残高チェックは必要ありません。このようなアカウント抽象化トランザクションの有効性は、ターゲット スマート コントラクトによって決定され、独自の有効性ルールを適用した後、そのようなトランザクションの支払いを決定できます。

それで、なぜこれが便利なのでしょうか?アカウント抽象化の利点を強調するために、Ethereum ウォレットを例として使用します。

スマート コントラクト ウォレット: 今日のほとんどの Ethereum ウォレットは EOA ウォレットであり、シード フレーズから生成された秘密鍵によって保護されています。 (BIP-39 シード フレーズは、2048 語のセットからランダムに選択された 12 ～ 24 語の順序付きリストです。これにより、PBKDF2 関数を使用して生成されるバイナリ シードを導出するために必要なエントロピーが提供されます。バイナリ シードは、BIP-32 ウォレットの非対称キー ペアを生成するために使用されます。) ユーザーは、後で別のウォレットでキーを回復するために必要になる可能性があるため、シード フレーズを安全な場所に書き留めておく必要があります。しかし、このようなウォレットは秘密鍵の盗難やシードフレーズの紛失に対して脆弱であり、その結果、ユーザーの資金が失われることになります。

スマート コントラクト ウォレットは、スマート コントラクトを通じてチェーン上に実装されます。このウォレットは、マルチ署名セキュリティ、ソーシャルまたは時間ベースのリカバリ、トランザクションまたは金額のレート制限、許可/拒否アドレスリスト、ガスフリートランザクション、トランザクションのバッチ処理などの機能を実装することで、リスクを軽減するプログラム可能な機能とユーザーフレンドリーなエクスペリエンスを提供します。

スマート コントラクト ウォレットは脆弱なスマート コントラクトのセキュリティ リスクにさらされていますが、ウォレット プロバイダーが実行するセキュリティ テストと監査によってこのリスクを軽減できます。 EOA ウォレットのリスクは、スマート コントラクトでセキュリティを確保するための手順を一切踏まずに、シード フレーズのセキュリティを委ねられているウォレット ユーザーに完全にあります。

スマート コントラクト ウォレットの例としては、Argent、Authereum、Dapper、Dharma、Gnosis Safe、Monolith、MYKEY などがあります。下のグラフに示すように、これらのウォレットの採用は増加しているようです。

Argent は、ガーディアンの概念を通じてキーレス ソーシャル リカバリを実現します。ガーディアンとは、ユーザーがウォレットの回復を手伝うために信頼する人物またはデバイスのことです。 Argent はまた、銀行のようなセキュリティ (1 日の取引限度額、アカウントのロック、信頼できる連絡先などの機能を通じて) と Venmo のような使いやすさ (住所の代わりに ENS 名を使用し、メタ取引をサポートすることを通じて) を組み合わせることを目指しています。

Gnosis Safe は、チーム管理の資金に重点を置いたマルチ署名スマート コントラクト ウォレットであり、トランザクションが発生する前に、最小数のチーム メンバー (m-of-n) による承認が必要です。また、メタトランザクションを介してガスフリー署名も可能になります。

これらの高度なウォレット機能はすべて、洗練されたスマート コントラクトの使用を必要とします。ウォレット ユーザーは、EOA とやり取りするか、ウォレット プロバイダーに依存して、プロバイダーのリレーまたはガソリン スタンド ネットワークなどのサードパーティのリレー ネットワークを介してメタ トランザクションをサポートする必要があります。前者は、KYC 後に中央集権型取引所で ETH を購入することに依存していますが、後者は、ユーザーへの負担をリレーヤーに移すことでこのオンチェーン UX 摩擦を軽減することを目指しており、そのコストはオンチェーン/オフチェーンのウォレットプロバイダーと/またはオフチェーンのユーザーによって補償されます。

しかし、リレーヤーベースのアーキテクチャには3つの大きな欠点があります。(1) 取引を検閲する可能性のある中央集権的な仲介者とみなされる可能性があります。 （２）リレー取引には21,000の基本ガス料金が追加で必要であり、その運営にはガス料金に加えて利益を上げる必要があるため、技術的・経済的に非効率的である。 （3）リレー専用プロトコルを使用すると、アプリケーションは非ベースレイヤーのEthereumインフラストラクチャに依存せざるを得なくなりますが、その場合、ユーザーベースは小さく、可用性の保証も不確実です。

アカウントの抽象化により、スマート コントラクト ウォレットは、リレー ネットワークに依存せずに、ユーザーからのガスなしトランザクションを受け入れ、ガス料金を支払うことができるようになります。したがって、この基本レベルの機能により、Ethereum の分散化保証を犠牲にすることなく、このようなウォレットのオンボーディング ユーザー エクスペリエンスが大幅に向上します。

Tornado Cash: 関連する動機付けのアプリケーションとして、tornado.cash などのミキサーがあります。Tornado は、後で別のアドレスから引き出すことができる ETH の入金を受け入れるスマート コントラクトを使用して、アドレス間のオンチェーン接続を切断することで、トランザクションのプライバシーを向上させます。ユーザーは入金時に秘密のハッシュを提供し、出金時に秘密や前回の入金自体を明かすことなく秘密を知っていることを示すために zkSnark 証明を提供する必要があります。これにより、引き出しと預金が切り離されます。

しかし、引き出しには問題があります。新しく生成されたアドレスから引き出しトランザクションを実行するには、ユーザーはガス代を支払うために ETH を保有している必要があります。この ETH のソース (通常は取引所) は、Tornado のプライバシーを侵害します。推奨される代替案は、やはりリピーター ネットワークを使用することですが、これには前述の欠点があります。

アカウント抽象化によりこの問題は解決され、Tornado コントラクトはユーザーの引き出しアカウント抽象化トランザクションを受け入れ、zkSnark を検証して一部のガス料金 (前回の入金額から差し引かれたもの) を差し引いた後、残りの入金額を引き落としアドレスに転送できるようになります。

アカウントの抽象化

EIP-2938 で提案されたアカウント抽象化により、契約は手数料を支払い、トランザクションの実行を開始する最上位のアカウントになることができます。これは、プロトコルの変更、2 つの新しいオペコード (NONCE と PAYGAS) を必要とする新しいアカウント抽象化トランザクション タイプ、メモリプール ルールの変更、および高度な使用法をサポートするための拡張機能を導入することによって実現されました。アカウント タイプは引き続き 2 種類 (EOA と契約アカウント) 存在し、提案された変更はすべて現在のトランザクション、スマート コントラクト、プロトコルと下位互換性があります。

アカウント抽象化を適用する際には、次の 2 つの側面を考慮する必要があります。1) ユーザーごとに新しいコントラクトが作成されるスマート コントラクト ウォレットなどのシングルテナント アプリケーション。2) 複数のユーザーが同じスマート コントラクト セットと対話する tornado.cash や Uniswap などのマルチテナント アプリケーション。

マルチテナント アプリケーションのアカウント抽象化サポートにはさらなる研究が必要であり、今後の作業として提案されています。したがって、この記事では、シングルテナント アカウント抽象化のサポートに焦点を当てます。

プロトコルの変更

NONCE と PAYGAS をサポートする 2 つのオペコードとともに、新しいトランザクション タイプが導入されました。プロトコルの変更はこれだけです。

アカウント抽象化トランザクション: 新しいアカウント抽象化トランザクション タイプ AA_TX_TYPE が導入されました。有効なタイプは、既存のトランザクション タイプではなく、RLP([nonce、target、data]) として解釈されます。後者の有効なタイプは RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]) です。

アカウント抽象化トランザクションで省略された gas_price と gas_limit は、実行時にターゲット アカウント抽象化コントラクトによって指定されます。アカウント抽象化トランザクションで省略された ECDSA 署名 v、r、s は、特定の契約によるデータの検証チェックに置き換えられます。宛先アドレスはターゲット契約アドレスに置き換えられます。すべてのアカウント抽象化トランザクションの発信元アドレスは、関連付けられた EOA 値ではなく、特別な ENTRY_POINT アドレス (0xFFFF...FFF) であるため、この値は省略されます。

チェックに失敗した場合、トランザクションは無効とみなされます。それ以外の場合は、tx.target.nonce が増分され、トランザクションが続行されます。

アカウント抽象化トランザクションの基本ガスコストは、現在の 21000 ではなく 15000 にすることが提案されています (固有の ECDSA 署名がないことによるコスト削減を反映するため)。さらに、アカウント抽象化トランザクションには固有のガス制限はありません。実行の開始時に、ガス制限はグループの残りのガスに設定されます。

NONCE オペコード: NONCE オペコード (0x48) は、呼び出し先の NONCE (つまり、アカウント抽象化ターゲット コントラクト) を EVM スタックにプッシュします。したがって、アカウント抽象化契約の検証の一環として、すべてのトランザクション フィールド (nonce を含む) の署名検証を可能にするために、nonce は EVM に公開されます。

PAYGAS オペコード: PAYGAS オペコード (0x49) は、スタックから 2 つのパラメータ ((一番上) version_number、(上から 2 番目) memory_start) を受け取ります。 version_number により、将来の実装でオペコードのセマンティクスを変更できるようになります。現在、このオペコードのセマンティクスは次のとおりです。

version_number == 0 かどうかを確認します (そうでない場合は例外をスローします)

抽出 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

抽出 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])

contract.balance >= gas_price * gas_limit をチェックします (そうでない場合は例外をスローします)

globals.transaction_fee_paid == False を確認します (そうでない場合は例外をスローします)

AA 実行フレーム == トップレベル フレームであることを確認します。つまり、現在の EVM 実行が終了またはロールバックされた場合、トランザクション全体の EVM 実行が終了します (それ以外の場合は例外がスローされます)。

contract.balance -= gas_price * gas_limit(limit) を設定します。

globals.transaction_fee_paid = True を設定します

globals.gas_price = gas_price および globals.gas_limit = gas_limit を設定します。

現在の実行コンテキストの残りのガスを、gas_limit - 消費されたガスに設定します。

アカウント抽象化トランザクション実行の終了時に、(globals.gas_limit - residual_gas) * globals.gas_price がマイナーに転送され、アカウント抽象化コントラクトは residual_gas * globals.gas_price を返します。

PAYGAS は EVM 実行チェックポイントとして機能します。この時点以降の元に戻す操作はここでのみ実行され、その後、契約は払い戻しを受け入れず、globals.gas_limit * globals.gas_price がマイナーに転送されます。

新しいトランザクション タイプと 2 つの新しいオペコードは、プロトコル/コンセンサス レベルでの変更を構成し、そのセマンティクスは比較的理解しやすいものです。

メモリプールのルール

「Mempool」とは、候補となるトランザクションをマイニング前に保存する、Ethereum ノード内のメモリ データ構造のセットを指します。 Geth はこれを「トランザクション プール」と呼んでいます。 Parity ではこれを「トランザクション キュー」と呼びます。名前に関係なく、これはメモリ内に存在し、ブロックに含まれるのを待機しているトランザクションのプールです。トランザクションがブロックに受け入れられるのを待っている「待機エリア」と考えてください。 「

現在、トランザクションの有効性ルールが固定されているため、マイナーやその他のノードはメモリプール内のトランザクションを検証するのに最小限の労力しか必要とせず、DoS 攻撃を回避できます。たとえば、マイナーが有効な ECDSA 署名、有効な nonce、および十分なアカウント残高を持っている場合、トランザクションが実際に手数料を支払うことが確実になります。マイナーのメモリプール内の他のトランザクションは、同じアドレスから送信され、ナンス値を増やすか、アカウント残高を十分に減らした場合にのみ、この保留中のトランザクションを無効にすることができます。これらの条件は計算上最小限であり、マイナーとノードに、それぞれブロックの待機または再生を続行するための十分なメモリプールの信頼を与えます。

アカウント抽象化トランザクションは、プログラム可能な有効性により、さらなる複雑さをもたらします。アカウント抽象化トランザクションでは、前払いのガスは支払われず、ターゲット アカウント抽象化契約に依存してガス料金を支払います (PAYGAS 経由)。概念的には、アカウント抽象化トランザクション処理は、短い検証フェーズ (PAYGAS の前) と長い実行フェーズ (PAYGAS の後) の 2 つのフェーズに分かれています。検証フェーズが失敗した場合 (または例外がスローされた場合)、トランザクションは無効となり (現在の無効に署名された非アカウント抽象化トランザクションと同様に)、ブロックに含まれず、マイナーは手数料を受け取りません。

したがって、マイナーとノードには、保留中のアカウント抽象化トランザクションの有効性がメモリプール内の他の保留中のトランザクションに依存しないようにするための予測可能なメカニズムが必要です。そうしないと、1 つのトランザクションの実行によって、メモリプール内の多数またはすべてのアカウント抽象化トランザクションが無効になり、DoS 攻撃が発生する可能性があります。これを回避するために、メモリプール内のアカウント抽象化トランザクションに適用される 2 つのルールが提案されています (マイナーとノードによって適用されますが、プロトコル自体では適用されません)。

オペコード制限

アカウント抽象化トランザクションの有効性がアカウント抽象化コントラクト自体以外のものに依存しないようにするため、検証フェーズ中 (つまり、PAYGAS の前) に次のオペコードは無効と見なされます: 環境オペコード (BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT)、BALANCE (ターゲット自体を含むすべてのアカウント)、ターゲット以外の外部呼び出し/作成またはプリコンパイル (CALL、CALLCODE、STATICCALL、CREATE、CREATE2)、およびコードを読み取る外部状態アクセス (EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL) (アドレスがターゲットでない場合)。

ノードは、アカウント抽象化コントラクトをターゲットとするメモリプール内のアカウント抽象化トランザクションを破棄し、このオペコード制限ルールに違反する必要があります。これにより、アカウント抽象化コントラクトの状態が変更されない限り、メモリプール内の有効なアカウント抽象化トランザクションが有効なままになります。

バイトコードプレフィックスの制限

非アカウント抽象化トランザクションがアカウント抽象化コントラクトの状態に影響を与える可能性がある場合、メモリプール内のアカウント抽象化トランザクションの有効性に影響します。これを防ぐには、アカウント抽象化トランザクションは、バイトコードの先頭に AA_PREFIX を持つコントラクトに対してのみ許可する必要があります。AA_PREFIX は、msg.sender がアカウント抽象化トランザクションの特別な ENTRY_POINT アドレスであるかどうかのチェックを実装します。これにより、非アカウント抽象化トランザクションがアカウント抽象化コントラクトとやり取りすることが効果的に防止されます。

ノードは、バイトコード エントリ ポイントにこの AA_PREFIX を持たないアカウント抽象化コントラクトにアカウント抽象化トランザクションを渡す必要があります。

アカウント抽象化契約に対するこれら 2 つの制限を組み合わせることで、(1) アカウント抽象化トランザクションの有効性ロジックにアクセスできる唯一の状態は、アカウント抽象化契約の内部状態であり、(2) この状態は、この特定のアカウント抽象化契約を対象とする他のアカウント抽象化トランザクションによってのみ変更できることが保証されます。

したがって、未処理のアカウント抽象化トランザクションは、同じアカウント抽象化コントラクトを対象とする別の保留中のトランザクションがある場合にのみ無効になります。ただし、これらはプロトコル/コンセンサスの変更ではないため、マイナーはこれらのルールに違反するトランザクションをブロックに自由に含めることができます。

拡張機能

上記のプロトコルの変更とメモリプールのルールにより、基本的なアカウント抽象化契約で、スマート コントラクト ウォレットなどのシングルテナント アプリケーションを完全に安全に実装できるようになります。上記のルールを緩和したり、マルチテナントアプリケーションを実装する必要があるその他の高度な使用法では、アカウント抽象化により、次のような拡張機能の形でより多くのサポートを提供する必要があります。

SET_INDESTRUCTIBLE オペコードは SELFESTRUCT を無効にし、アカウント抽象化コントラクトが検証フェーズ中に DELEGATECALL を安全に呼び出すことを可能にします。

IS_STATIC オペコードは、現在のコンテキストが静的である場合に true を返し、非アカウント抽象化トランザクションの呼び出し元が以前のバイトコード プレフィックスの制限をオーバーライドし、アカウント抽象化コントラクトから値を安全に読み取ることができるようにします。

RESERVE_GAS オペコードは、非アカウント抽象化トランザクションから呼び出されると、契約状態を書き込もうとするアカウント抽象化契約によって消費されるガスの下限を設定します。これには、攻撃者が最低限のガス量を消費しないように強制し、メモリプール内の任意のアカウントの抽象トランザクションを無効にしようとする試みを阻止する効果があります。

他にも、複数の保留中のトランザクション、検証のキャッシュされた結果、検証の動的なガス制限、スポンサー付きトランザクションなどがあり、これらはすべてマルチテナント アプリケーションや Tornado Cash などの zk 証明をサポートするために必要です。それらの詳細はこの記事の範囲を超えています。

次のステップ

アカウント抽象化 EIP-2938 は現在ドラフト モードであり、Ethereum Research フォーラムで議論されています。 EIP の次のステップは、今後のハードフォークの 1 つに含めるかどうか検討することです。 EIP の作者たちは明らかにベルリン後のハードフォーク (暫定的に 2021 年初頭に予定) を目指していますが、そのタイムラインはまだ明らかではありません。したがって、EIP-2938 はまだ時期尚早です。

さらに、EIP-2938 を Ethereum のベースレイヤー 1 (L1) に追加する必要があるかどうかは不明です。レイヤー 2 (L2) ソリューションの相対的な柔軟性 (前回の記事で説明したとおり) を考慮すると、L1 全体をアップグレードすることなく、特定の L2 にアカウント抽象化を実装できます。ただし、一部の L2 が独自のアカウント抽象化バージョンを実装している場合でも、L1 でのアカウント抽象化の統一されたサポートには利点があります。したがって、アカウントの抽象化がどこでどのように実装されるかはまだ不明です。

「アカウントの抽象化は、L1 がサポートしているかどうかに関係なく、L2 に実装できるため、それほど重要ではありません。」 — Vitalik による Ethereum のロールアップ中心のロードマップに関する投稿 (ベース レイヤーで引き続き機能するもの)。

Status: Status ウォレットは現在 EOA ウォレットであり、プライバシー重視のメッセージング システムをバンドルし、チャットでの支払いや Keycard の強化されたセキュリティなどの統合を可能にすることで差別化されています。マルチシグやソーシャルリカバリなどのスマートコントラクトウォレット機能が検討されており、アカウント抽象化 EIP-2938 のサポートにより、前述のように集中型で非効率的なリレーベースのアーキテクチャへの依存を排除​​するのに役立ちます。

Status では、以前の投稿で説明したように、ウォレット内の複数のチェーンをサポートし、さまざまなユースケースに必要なスケーリングを提供する L2 ソリューションも評価しています。たとえば、Keycard は、クレジットカード レベルのスケーラビリティとほぼ即時の確定性という設計要件が現在 Ethereum ネットワークで満たされていない支払いネットワークを検討しています。さらに、紹介プログラム、Tribute-to-Talk、ENS Names などの数多くの取り組みがあり、これらはすべて L2 のスケーラビリティの恩恵を受け、実行可能な展開と適切なユーザー エクスペリエンスを実現します。実行可能な L2 ソリューションがアカウント抽象化を実装すると、その L2 上に構築されたプロジェクトは、L1 に依存することなくアカウント抽象化を活用できるようになります。

要約する

Ethereum プロトコルの基本的な側面は、外部所有アカウント (EOA) のみがガス料金を支払い、トランザクションの実行を開始できることです。契約アカウント (CA) ではこれができません。アカウント抽象化 (AA) は、この区別を変更することを目的とした提案であり、特別に構築された CA が新しいタイプのアカウント抽象化トランザクションの有効性をプログラムでチェックし、代わりにガス料金を支払うことを決定し、EOA を必要とせずにその実行を効果的に開始できるようにします。

アカウントの抽象化は、集中型で非効率的なリレーヤーベースのアーキテクチャに依存せずに、ウォレット、ミキサー、DApps、DeFi などのさまざまなシナリオでユーザー エクスペリエンスを大幅に向上させるのに役立ちます。スマート コントラクト ウォレットなどの基本的なシングルテナント シナリオは、新しいトランザクション タイプ、2 つの新しいオペコード、および 2 つのメモリプール ルールを導入することで、アカウント抽象化によって安全にサポートできます。 Tornado Cash などの高度なマルチテナント アプリケーションでは、これらのプロトコルの変更とノード ルールに合わせて拡張する必要があります。

この記事では、スマート コントラクト ウォレットのコンテキストにおけるアカウント抽象化の必要性について説明しました。プロトコルの変更とノードへの影響について説明することで、アカウント抽象化の重要な側面に焦点を当てます。高度な用途向けに提案されているいくつかの拡張機能について触れ、最後に、アカウントの抽象化を Ethereum の現在のロードマップと Status の優先事項の中に位置付けました。

Web3 での摩擦を減らし、ユーザー エクスペリエンスを向上させることは、このエコシステム内のすべてのプロジェクトにとって最優先事項です。アカウントの抽象化は、何らかの形で、将来の取り組みにおいて重要な役割を果たすことは間違いないでしょう。