Ethereumには、Externally Owned Account（EOA）とContract Account（CA）の2種類のアカウントがあります。EOAはプライベートキーによって制御されており、一方、CAはそれに含まれるスマートコントラクトコードによって制御されています。EOAは常にCAより特権があります。なぜなら、ガスを支払うことでトランザクションの実行を開始できるのはEOAだけだからです。Account Abstraction（AA）は、契約がEOAのように手数料を支払い、トランザクションの実行を開始できるようにする提案です。

AAの動機は、ユーザーが今日イーサリアムブロックチェーンとやり取りする方法において、ウォレット、ミキサー、ÐApps、DeFiなどのさまざまなシナリオにおいて、ユーザーエクスペリエンスを大幅に向上させることです。AAは、ガス代を支払うタイミングを決定するためのイーサリアムのベースレイヤー機能を提供し、これにより誰がガス代を支払い、どのように支払うかにも影響を与えます。

Status Messengerアプリには、プライバシーに配慮したメッセンジャーとEthereumウォレット、Web3 ÐAppブラウザがバンドルされています。Statusウォレットは現在、EOAウォレットであり、マルチシグセキュリティ、ソーシャルリカバリ、レート制限、アドレスの許可/拒否リスト、ガスレスメタトランザクションなど、スマートコントラクトウォレットのみが提供できる豊富なUXを提供することができません。ただし、現在のスマートコントラクトウォレットのUXは、不安定なガス価格によって深刻な制約を受けており、これはサードパーティのリレーヤーによって効率的に解決されていません。AAはこの問題に取り組むことを目指しています。

この記事では、スマートコントラクトウォレットのコンテキストにおけるアカウント抽象化の必要性について動機付けを行います。その後、プロトコルの変更やノードへの影響を説明することで、AAの主要な側面に詳しく取り組みます。最後に、提案されている拡張機能のいくつかについて議論し、Ethereumとインターフェイスを持つStatusプロジェクトの計画されたロードマップを合理化して、AAの影響を受ける可能性があるプロジェクトについて述べます。

歴史と動機

アカウント抽象化は最初に提案されましたEIP-862017年に「トランザクションの起源と署名の抽象化」を実装するためにEIPが実施されましたが、動機づけのアイデアの起源はさらに遡ることができます。2016年初頭, そこで提案されたのは次のようなものでした:「アカウントを保護するための唯一の「標準」の方法としてECDSAとデフォルトのナンススキームが確立されているプロトコル内のメカニズムの代わりに、すべてのアカウントが長期的には契約であり、契約がガス料金を支払うことができ、ユーザーは独自のセキュリティモデルを定義する自由があるモデルに向けて最初のステップを踏むことです。

初期の提案は、多くのプロトコル変更が必要であり、満たす必要があるセキュリティ保証のために実装が困難であると考えられていました。最近、Vitalikらがドラフトを提案しました。EIP-2938プロトコル/コンセンサスの変更を最小限に抑え、ノードメンプールのルールを通じて必要なセキュリティ保証を強制することにより、はるかにシンプルな実装を概説しています。ヴィタリックのイーサリアムエンジニアリンググループミートアッププレゼンテーション and ETHOnlineプレゼンテーション（関連記事と共に@SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) by Sam Wilson & Ansgar Dietrichs (two of the other EIP authors) offer great introductions to the topic. This article highlights key aspects from all these sources.

Motivation: AAの背後にある動機づけは非常にシンプルですが、基本的です。現在のEthereumトランザクションはプログラム可能な効果を持っています（スマートコントラクトへの呼び出しによって実現されています）、しかし、有効性には固定されており、トランザクションが有効であるのは、有効なECDSA署名と有効なnonce、十分な口座残高を持っている場合だけです。AAは、トランザクションを固定された有効性からプログラム可能な有効性にアップグレードすることで、新しいAAトランザクションタイプを導入することによって、プロトコルが署名、nonce、残高のチェックを必要としない特別なアドレスから常に発生するようにします。このようなAAトランザクションの有効性は、それ自体の有効性ルールを施行できるターゲットスマートコントラクトによって決定され、その後、そのようなトランザクションを支払うかどうかを決定することができます。

なぜこれが役立つのか？AAの利点を強調するために、イーサリアムウォレットの例を取り上げてみましょう。

スマートコントラクトウォレット：ほとんどのEthereumウォレットは、シードフレーズから生成されたプライベートキーによって保護されているEOAウォレットです。(A BIP-39シードフレーズまたはニーモニックとは、2048語のリストから無作為に選択された12〜24語の順序付きリストです。これにより、PBKDF2関数を使用して生成されたバイナリシードを取得するために必要なエントロピーが提供されます。バイナリシードは、その後、非対称キーペアを生成するために使用されます。BIP-32ウォレット。）ユーザーは、別のウォレットでキーを復元する際に後で必要となる可能性があるため、シードフレーズを安全な場所に書き留めることが期待されています。ただし、このようなウォレットはプライベートキーの盗難やシードフレーズの紛失に対して脆弱であり、ユーザーの資金の損失につながる可能性があります。

スマートコントラクトウォレットは、名前が示すように、スマートコントラクトを介してオンチェーンで実装されています。このようなウォレットは、マルチシグネチャセキュリティ、ソーシャルまたは時間ベースのリカバリ、トランザクションや金額のレート制限、アドレスの許可/拒否リスト、ガスレスメタトランザクション、バッチトランザクションなどの機能を実装することで、プログラマブルなリスク緩和とユーザーフレンドリーな体験を提供します。

スマートコントラクトウォレットは脆弱なスマートコントラクトからのセキュリティリスクにさらされていますが、ウォレットプロバイダーによるセキュリティテストとレビューによってこのリスクを軽減することができます。 EOAウォレットのリスクは、スマートコントラクトで可能なプログラマブルなセーフガードのいずれも持たないシードフレーズのセキュリティを任されているウォレットユーザーに完全にあります。

スマートコントラクトウォレットの例は、アルジェント, Authereum, Dapper, ダルマ, Gnosis Safe, モノリスそしてMYKEY. このようなウォレットの採用は、以下に示すように増加しているようです グラフ.

Argentは、Guardiansと呼ばれるユーザーの信頼できる人物やデバイスを通じて、ウォレットの回復を支援できる概念を活用した、シードレス・ソーシャルリカバリーを実装しています。Argentはまた、日常の取引限度額、口座ロック、信頼できる連絡先などの機能を通じて銀行のようなセキュリティを実現し、ENSネームの使用やメタ取引のサポートを通じてVenmoのような使いやすさを追求しています。

Gnosis Safeは、最小数（m-of-n）のチームメンバーがトランザクションを承認する必要がある資金のチーム管理に焦点を当てたマルチシグスマートコントラクトウォレットです。また、メタトランザクションを介したガスレス署名も可能です。

そのような高度なウォレット機能は、非自明なスマートコントラクトの使用を必要とします。ウォレットのユーザーは、それらとやり取りするためのガスを持ったEOAが必要です。それとも、ウォレットプロバイダがプロバイダのリレーやサードパーティのリレーネットワークをサポートしてメタトランザクションを行うことに依存する必要があります。Gas Station Network前者は通常、KYC後に中央集権取引所で購入されたETHに依存していますが、後者はユーザーの負担をリレーザに移し、ウォレットプロバイダーによってオン/オフチェーンで補償されるコストによって、このオンボーディングUX摩擦を軽減することを目指しています。ユーザーによってオフチェーンで補償されます。

ただし、リレーヤーをベースとしたアーキテクチャには、3つの主な欠点があります：(1) センサリングトランザクションを行う可能性がある中央集権的な中間業者と見なされる可能性があります。(2) リレーやビジネスがガス料金の上に利益を得る必要があるため、技術的/経済的に効率が悪い。 (3) リレーやベースレイヤーではないイーサリアムインフラに依存することを強制するリレーや特定のプロトコルの使用は、ユーザベースが小さく利用可能性が不確実です。

Account Abstractionは、スマートコントラクトウォレットがユーザーのガスレスメタトランザクションを受け入れ、リレーネットワークに依存せずにガス料金を支払うことを可能にします。この基本レイヤーの機能により、そのようなウォレットのオンボーディングUXが大幅に向上し、Ethereumの分散化保証を犠牲にすることなく、そのユーザビリティが向上します。

Tornado Cash: 関連する動機付けのアプリケーションは、ミキサーのようなものです tornado.cashどこ@tornadoTornadoは、ETHのデポジットを受け入れ、後で異なるアドレスから引き出すことができるスマートコントラクトを使用して、アドレス間のオンチェーンリンクを破壊することにより、取引のプライバシーを向上させます。ユーザーはデポジット時に秘密のハッシュを提供し、後で引き出し時にzkSnarkの証明を提供して、秘密や先行するデポジット自体を明らかにせずに秘密の知識を示すことが期待されます。これにより、引き出しとデポジットが切り離されます。

しかし、出金には鶏と卵の問題があります。新しく生成されたアドレスから出金トランザクションを実行するには、利用者はガス料金を支払うためにその中にあるいくらかのETHを持っている必要があります。このETHの出所（通常は取引所）は、トルネードのプライバシーを壊す可能性があります。好ましい代替手段は、以前に概説した欠点を持つリレーネットワークを再度使用することです。

アカウントの抽象化により、トルネード契約がユーザーの引き出しAAトランザクションを受け入れ、zkSnarkを検証し、いくつかのガス手数料（前回の預金額から）を差し引いた後、残りの預金額を引き出しアドレスに送金することで、この問題を解決します。

アカウント抽象化

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

AAの応用は、1)ユーザーごとに新しい契約を作成するスマートコントラクトウォレットなどの単一テナントアプリケーションと、2)複数のユーザーが同じ一連のスマートコントラクトとやり取りするtornado.cashやUniswapなどのマルチテナントアプリケーションを含めて、2つのカテゴリーを横断して考えられています。

マルチテナントアプリケーションのAAサポートにはさらなる調査が必要であり、将来の作業として提案されています。そのため、この記事ではシングルテナントのAAサポートに焦点を当てます。

プロトコルの変更

新しい取引タイプが導入され、NONCEとPAYGASの2つのサポートオペコードがあります。これらが唯一のプロトコル変更です。

AAトランザクション：新しいAAトランザクションのタイプAA_TX_TYPEが導入されました。そのペイロードは、既存のトランザクションタイプとは異なり、RLP（[nonce、target、data]）として解釈されます。既存のトランザクションタイプのペイロードはRLP（[nonce、gas_price、gas_limit、to、value、data、v、r、s]）です。

AAトランザクションで省略されたgas_priceとgas_limitは、実行中にターゲットAA契約によって指定されます。AAトランザクションで省略されたECDSA署名v、r、sは、データに対する契約固有の検証チェックで置き換えられます。toアドレスはターゲット契約アドレスに置き換えられます。値は、全てのAAトランザクションの発信元アドレスが特別なENTRY_POINTアドレス（0xFFFF…FFFF）であり、値が関連付けられているEOAではないため、省略されています。

ノンスは、tx.nonce == tx.target.nonce として既存のトランザクションに類推的に処理されます。このチェックに失敗した場合、トランザクションは無効と見なされますが、それ以外の場合は、tx.target.nonce が増分され、トランザクションが続行されます。

AAトランザクションの基本ガスコストは、現在の21000ではなく、15000に設定されることが提案されています（独自のECDSA署名がないためのコスト削減を反映するため）。さらに、AAトランザクションには固有のガス制限がありません。実行を開始する際、ガス制限は単純にブロック内の残りガスに設定されます。

NONCEオペコード：NONCEオペコード（0x48）は、EVMスタックに呼び出し先であるAAターゲットコントラクトのナンスをプッシュします。したがって、ナンスはEVMに公開され、AAコントラクトの検証の一環としてトランザクションのすべてのフィールド（ナンスを含む）上で署名検証を行うことを可能にします。

PAYGASオペコード：PAYGASオペコード（0x49）はスタックから2つの引数を取ります：（一番上）version_number、（一番上から2番目）memory_start。 version_number は将来の実装でオペコードの意味を変更できます。現在、このオペコードの意味は以下のとおりです：

1. version_number == 0をチェックします（それ以外の場合は例外をスローします）
2. gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])を読み取ります
3. gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])を読み取ります
4. Check contract.balance >= gas_price * gas_limit (else throw exception)
5. globals.transaction_fee_paid == Falseのチェック（それ以外の場合は例外をスロー）
6. AA実行フレーム==トップレベルフレームをチェックします。つまり、現在のEVM実行が終了またはリバートする場合、トランザクション全体のEVM実行が終了します（それ以外は例外をスローします）。
7. contract.balance -= gas_price * gas_limitを設定します
8. globals.transaction_fee_paid = True に設定
9. globals.gas_price = gas_priceとglobals.gas_limit = gas_limitを設定します
10. 現在の実行コンテキストの残りのガス = ガスリミット - すでに消費されたガス

AAトランザクションの実行終了時には、(globals.gas_limit - remaining_gas)globals.gas_price はマイナーに転送され、AA契約は残りのgasが返金されますglobals.gas_price.

PAYGASはEVMの実行チェックポイントとして機能します。このポイント以降にリバートが発生した場合、ここまでしかリバートされず、その後契約は払い戻しを受けず、globals.gas_limit * globals.gas_priceがマイナーに送られます。

新しいトランザクションタイプと2つの新しいオペコードは、プロトコル/コンセンサスレベルの変更を構成し、その意味論は比較的直感的に理解できます。

Mempoolのルール

"The メモリプールEthereumノード内のインメモリデータ構造のセットを指し、採掘される前の候補トランザクションを格納しています。 Gethはこれを「トランザクションプール」と呼び、Parityはこれを「トランザクションキュー」と呼びます。名前に関係なく、それはブロックに含まれるのを待っているメモリ内のトランザクションのプールです。トランザクションがブロックに受け入れられるのを待つ「待合室」と考えてください。

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

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

したがって、マイナーやノードは、メンプール内の他の保留中のトランザクションに依存しないように、予測可能なメカニズムが必要です。そうでないと、1つのトランザクションの実行がメンプール内の多数の/すべてのAAトランザクションの無効化につながり、DoS攻撃を引き起こす可能性があります。このシナリオを回避するために、メンプール内のAAトランザクションに強制される2つの提案されたルールがあります（マイナーやノードによって、ただしプロトコル自体ではない）。

オペコード制限

AAトランザクションの有効性がAA契約自体に依存しないようにするために、次のオペコードは検証フェーズ（つまりPAYGASの前）で無効と見なされます：環境オペコード（BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT）、BALANCE（ターゲット自体を含む任意のアカウントの残高）、ターゲット以外の何かに対する外部呼び出し/作成（CALL、CALLCODE、STATICCALL、CREATE、CREATE2）およびコードを読み取る外部状態アクセス（EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL）（アドレスがターゲットでない限り）。

ノードは、このオペコード制限ルールを破るAAコントラクトを対象とするAAトランザクションをメモリプールから削除することが予想されます。これにより、メモリプール内の有効なAAトランザクションは、AAコントラクトの状態が変わらない限り有効のままになります。

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

非AAトランザクションがAA契約の状態に影響を与える可能性がある場合、それはメンプール内のAAトランザクションの有効性に影響を与えるでしょう。 これを防ぐためには、AAトランザクションは、バイトコードの先頭にAA_PREFIXがある契約のみを対象とするように許可されるべきです。AA_PREFIXは、msg.senderがAAトランザクションの特別なENTRY_POINTアドレスであることを確認するチェックを実装しており、これにより、非AAトランザクションがAA契約とやり取りすることが効果的に防止されます。

ノードは、バイトコードのエントリポイントにこのAA_PREFIXを持たないAA契約へのAAトランザクションをドロップすることが予想されています。

これらのAA契約に対して強制される2つの制限は、(1) AAトランザクションの有効性ロジックからアクセス可能な唯一の状態がAA契約内部の状態であり、(2) この状態は、この特定のAA契約を対象とする他のAAトランザクションによってのみ変更できることを確認します。

AA契約への保留中のAA取引は、したがって、同じAA契約を対象とする別のAA取引を含むブロックによってのみ無効にすることができます。ただし、これらがプロトコル/コンセンサスの変更ではないため、マイナーはこれらのルールを破る取引をブロックに含めることができます。

拡張機能

上記のプロトコル変更とメンプール規則により、基本的なAA契約を安全に実装し、スマートコントラクトウォレットなどの単一テナントアプリケーションを十分に実装することができます。上記のルールの緩和またはマルチテナントアプリケーションの実装が必要な他の高度な使用法については、AAからのより多くのサポートが必要とされます。

1. 自己破壊を無効にし、AAコントラクトがDELEGATECALLを使用してライブラリを安全に呼び出すことを可能にするSET_INDESTRUCTIBLEオペコードを、検証フェーズで使用します。
2. IS_STATICオペコードは、現在のコンテキストが静的であり、非AAトランザクション呼び出し元が以前のバイトコードプレフィックス制限を上書きし、AAコントラクトから値を安全に読み取ることを許可する場合にtrueを返します。
3. 非AAトランザクションから呼び出された場合にAAコントラクトによって消費されるガスの下限を確立するRESERVE_GASオペコード。これにより、攻撃者がAAトランザクションを無効にしようとする試みを減らすために、最小限のガス量を消費することが強制されます。

他にも、複数の保留中取引や検証結果のキャッシュ、検証のための動的ガス制限、およびマルチテナントアプリケーションやzkプルーフ（例：Tornado Cash）をサポートするために必要なスポンサード取引などがあります。これらの議論は、この記事の対象外です。

次の手順

アカウント抽象化EIP-2938は現在ドラフトモードであり、イーサリアム研究フォーラムで議論されています。EIPの次のステップは、今後のハードフォークの1つに含まれることが検討されることです。EIPの著者は、明らかにベルリンの後のハードフォークを目指しています（ベルリンは暫定的に予定されています）。2021年初) そのタイムラインが現時点であまり明確ではないプロセスの早い段階です。そのため、EIP-2938に関してはまだ早い段階です。

さらに、イーサリアムの基本レイヤー1（L1）にEIP-2938を含める必要があるかどうかも明確ではありません。Layer 2（L2）ソリューションの相対的な柔軟性を考慮すると（以前の記述に記載されているように）、記事)、特定のL2でのAccount Abstractionの実装は、L1全体のアップグレードを必要としない場合があります。ただし、一部のL2が独自のAAバージョンを実装している場合でも、L1での一貫したAAサポートには利点があります。したがって、AAがどこでどのように実装されるかはまだ見極める必要があります。

「アカウント抽象化はある程度重要ではありますが、L1がそれをサポートしているかどうかにかかわらず、L2に実装できるため、それほど重要ではありません。」- ヴィタリック、ベースレイヤーで重要な点について (彼の言葉)ポストロールアップ中心のイーサリアムのロードマップ)。

ステータス：ステータスウォレットは現在、プライバシー中心のメッセンジャーのバンドルやチャットでの支払い、強化されたセキュリティなどの統合を可能にするEOAウォレットです。キーカード. スマートコントラクトウォレットの機能であるマルチシグやソーシャルリカバリなどは、AA EIP-2938のサポートによって、中央集権化および非効率なリレーベースのアーキテクチャへの依存がなくなることが考慮されています。前述のように。

Statusは、ウォレットで複数のチェーンをサポートし、以前に説明したさまざまなユースケースに必要なスケーリングを提供するために、L2ソリューションも評価しています。記事たとえば、Keycardは探索しています。支払いネットワーク現在のイーサリアムネットワークでは、クレジットカードレベルのスケーラビリティとほぼ即時の最終性の設計要件が満たされていません。さらに、他にも多くのイニシアチブが存在します。紹介プログラム, SNTリアクション, トリビュート・トゥ・トークそしてENSネーム, すべてのこれらのプロジェクトは、実現可能な展開と合理的なユーザーエクスペリエンスのためにL2スケーラビリティから恩恵を受けることになるでしょう。実行可能なL2ソリューションがAAを実装する場合、そのL2上に構築されたプロジェクトは、L1に頼らずにAAの利点を活用することができるでしょう。

概要

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

AAは、中央集権的で非効率なリレーベースのアーキテクチャに頼らずに、ウォレット、ミキサー、ÐApps、DeFiなどのさまざまなシナリオでユーザーエクスペリエンスを大幅に向上させる可能性があります。スマートコントラクトウォレットなどの基本的な単一テナントシナリオは、新しいトランザクションタイプ、2つの新しいオペコード、2つのメモリプールルールを導入することで、AAによって安全にサポートされることができます。Tornado Cashなどの高度なマルチテナントアプリケーションには、これらのプロトコル変更およびノードルールの拡張が必要です。

この記事では、スマートコントラクトウォレットのコンテキストでAAの必要性を説明しました。プロトコルの変更とノードへの影響を説明することで、AAの主要な側面を強調しました。提案されている高度な使用法のいくつかに触れ、最終的にはEthereumの現在のロードマップとStatusの優先事項の文脈でAAを位置付けました。

Web3での摩擦の軽減とユーザーエクスペリエンスの向上は、このエコシステムのすべてのプロジェクトにとって最優先事項です。アカウントの抽象化は、今後この取り組みで重要な役割を果たす可能性があります。

免責事項：

1. この記事は[から転載されましたステータス元のタイトル「アカウント抽象化（EIP-2938）：なぜ＆何」を転送します。すべての著作権は元の著者に帰属しますラジーヴ・ゴパラクリシュナ]. この転載に異議がある場合は、お問い合わせください。ゲートラーンチームが promptly に対処します。

2. 責任の免除：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。

3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、もしくは盗用は禁止されています。