Vitalikが提案したEIP-2938はイーサリアムにどのような変化をもたらすのでしょうか？

編集者注: この記事は以下から引用しましたクリプトバレーライブ (ID:cryptovalley)編集者注: この記事は以下から引用しました

クリプトバレーライブ (ID:cryptovalley)"クリプトバレーライブ (ID:cryptovalley)"、著者: Rajeev Gopalakrishna、翻訳者: Olivia、許可を得て転載しています。

イーサリアムには2種類のアカウントがあります。外部所有アカウント (EOA) と契約アカウント (CA)。 EOA は秘密キーによって制御され、CA はそれに含まれるスマート コントラクト コードによって制御されます。 EOA のみがガスを支払うことでトランザクションの実行を開始できるため、EOA は常に CA よりも大きな特権を持っています。アカウント抽象化 (AA) は、契約を

最上階

アカウント抽象化の動機は、ユーザーがウォレット、DApps、DeFi などのさまざまなシナリオでイーサリアムを操作するときのユーザー エクスペリエンスを大幅に向上させることです。アカウント抽象化は、いつガスを支払うことができるか、誰にガスを支払うかを決定するためのイーサリアムのベース層機能を提供します。

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

このペーパーでは、スマート コントラクト ウォレットのコンテキストにおけるアカウント抽象化の必要性について取り上げます。次に、プロトコルの変更とノードへの影響について説明することで、アカウント抽象化の重要な側面を詳しく説明します。最後に、スケーリングに関するいくつかの提案について説明し、イーサリアムと接続する Status プロジェクトの計画されたロードマップを合理化して締めくくります。これらはすべてアカウントの抽象化によって影響を受ける可能性があります。"副題"歴史と動機"アカウント抽象化は、もともと 2017 年に EIP-86 として提案されました。"

トランザクションの発信元と署名の概要

, しかし、このアイデアの起源は2016年にまで遡ることができます。そのとき、次のことが提案されました。

アカウントを安全に保つための唯一の「標準」方法として ECDSA とデフォルトの nonce スキームを使用するプロトコル内メカニズムを用意するよりも、最初のステップを踏み、長期的にはすべてのアカウントがコントラクトであり、ガスは支払うことができ、ユーザーは独自のセキュリティ モデルを自由に定義できます。

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

動機: アカウント抽象化の背後にある動機は非常に単純ですが根本的です: 今日のイーサリアムトランザクションにはプログラム可能な効果 (スマートコントラクトを呼び出すことによって実装されます) がありますが、それらの有効性は固定されているだけです。つまり、有効な ECDSA 署名、有効なナンス、十分な口座残高が取引に有効であること。アカウント抽象化は、新しいアカウント抽象化トランザクション タイプを導入することにより、トランザクションを固定有効性からプログラム可能な有効性にアップグレードします。このアカウント抽象化トランザクション タイプは常に特別なアドレスから取得され、プロトコルでは署名、ノンス、残高チェックは必要ありません。このようなアカウント抽象化トランザクションの有効性は、ターゲットのスマート コントラクトによって決定され、独自の有効性ルールを強制することができ、その後、そのようなトランザクションに対する支払いを決定できます。

では、なぜこれが役立つのでしょうか?アカウント抽象化の利点を強調するために、例としてイーサリアム ウォレットを使用します。

スマート コントラクト ウォレット: 現在のイーサリアム ウォレットのほとんどは 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 は、チームによる資金管理に重点を置いたマルチシグネチャ スマート コントラクト ウォレットで、トランザクションの発生を承認するには最小数 (n 個中 m) のチーム メンバーが必要です。また、メタトランザクションを介したガスフリー署名も可能になります。

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

ただし、リレーラーベースのアーキテクチャには 3 つの大きな欠点があります。(1) 中央集権的な仲介者とみなされる可能性があり、トランザクションを検閲する可能性があります。(2) リレーラーによるトランザクションには追加の 21,000 の基本ガス料金が必要で、そのビジネスはガス料金以外で利益を上げる必要があります。 、そのため、技術的/経済的に非効率的です (3) リレーラー専用プロトコルを使用すると、アプリケーションはユーザーベースが小さい非ベースレイヤーのイーサリアムインフラストラクチャに依存することになります。可用性の保証は保証されません。

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

しかし、出金には問題があり、新しく生成されたアドレスから出金トランザクションを実行するには、ユーザーはガス代を支払うためにある程度の ETH を持っている必要があります。この ETH のソース (通常は取引所) は、Tornado のプライバシーを侵害することになります。推奨される代替方法は、やはり中継器のネットワークを使用することですが、これには前に概説した欠点があります。

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

副題

EIP-2938 によって提案されたアカウント抽象化により、コントラクトは、料金を支払い、トランザクションの実行を開始する最上位のアカウントになることができます。これは、プロトコルの変更、2 つの新しいオペコード (NONCE と PAYGAS) を必要とする新しいアカウント抽象化トランザクション タイプ、mempool のルールの変更、および高度な使用法をサポートする拡張機能の導入によって実現されました。アカウント タイプには依然として 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 は、特定の契約によるデータの検証チェックによって置き換えられます。 to アドレスは、ターゲットのコントラクト アドレスに置き換えられます。この値が省略される理由は、すべてのアカウント抽象トランザクションの開始アドレスが特別な ENTRY_POINT アドレス (0xFFFF...FFF) であり、それに関連付けられた EOA 値ではないためです。

チェックが失敗した場合、トランザクションは無効とみなされます。失敗した場合は、tx.target.nonce がインクリメントされ、トランザクションが続行されます。

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

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

PAYGAS オペコード: PAYGAS オペコード (0x49) は、スタックから 2 つのパラメータをフェッチします: (先頭) version_number、(先頭 2 番目)memory_start. version_number により、将来の実装でオペコードのセマンティクスを変更できます。現在、このオペコードのセマンティクスは次のとおりです。

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

抽出ガス_価格 = bytes_to_int(vm.memory[memory_start:memory_start + 32])

extract 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 -= ガス価格 * ガス制限(制限) を設定します。

globals.transaction_fee_paid = True を設定します

globals.gas_price = ガス価格および globals.gas_limit = ガス_制限を設定します。

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

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

"Mempool "新しいトランザクション タイプと 2 つの新しいオペコードはプロトコル/コンセンサス レベルの変更を構成し、それらのセマンティクスは比較的簡単に理解できます。"副題"メンプールのルール"マイニング前に候補トランザクションを保存する、イーサリアム ノード内の一連のメモリ内データ構造を指します。ゲスはそれを呼んでいます"トランザクションプール"; パリティはそれを呼びます"トランザクションキュー"

。名前に関係なく、メモリ内でブロックに組み込まれるのを待っているトランザクションのプールです。それを次のように考えてください

待合所

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

Opcode Restriction

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

副題

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

ノードは、メモリプール内のアカウント抽象化コントラクトを対象としたアカウント抽象化トランザクションを放棄し、このオペコード制限ルールを破る必要があります。これにより、アカウント抽象化コントラクトの状態が変わらない限り、mempool 内の有効なアカウント抽象化トランザクションが有効であり続けることが保証されます。

副題

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

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

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

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

副題

拡大する

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

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

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

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

副題

仕事の次のステップ

アカウントの抽象化 EIP-2938 は現在ドラフトモードにあり、イーサリアム研究フォーラムで議論されています。 EIP の次のステップは、今後のハード フォークの 1 つに含めることが検討されることです。 EIP 作成者の目標は明らかにベルリン後のハードフォークであり (ベルリンは暫定的に 2021 年初頭に予定されています)、そのスケジュールは現時点では不明です。したがって、EIP-2938 には時期尚早です。

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

要約する

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

副題

要約する

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