DAOrayaki DAOリサーチボーナスプール:

DAOrayaki DAOリサーチボーナスプール:

投票経過: DAO委員会3/7可決

ファンディングアドレス: DAOrayaki.eth

投票経過: DAO委員会3/7可決

合計賞金: 80USDC

調査の種類: DAO、ERC4337、アカウント抽象化、スマートウォレット

原作者: ヴィタリック・ブテリン

投稿者: Dewei、DAOctor @DAOrayaki

原文: ERC 4337: イーサリアムプロトコルの変更を伴わないアカウントの抽象化

アカウントの抽象化は、イーサリアム開発者コミュニティにとって長年の夢でした。 EVM コードは、アプリケーションのロジックを実装するためだけでなく、個々のユーザー ウォレット (ナンス、署名など) の論理検証を実装するためにも使用されます。これにより、ウォレット設計の革新に多くのアイデアが提供され、ウォレットは次のような重要な機能を提供できます。

1. マルチシグとソーシャルリカバリ

2. より効率的でシンプルな署名アルゴリズム (Schnorr、BLS など)

3. ポスト量子安全署名アルゴリズム (Lamport、Winternitz など)

これらすべては現在、スマート コントラクト ウォレットで実行できますが、イーサリアム プロトコル自体では、ECDSA の安全な外部アカウント (EOA) から発信されるトランザクションにすべてをパッケージ化する必要があり、スマート コントラクト ウォレットでこれを実現するのは困難です。すべてのユーザー操作を EOA からのトランザクションでラップする必要があり、21000 ガスのオーバーヘッドが追加されます。ユーザーは、ガス料金を支払い、両方のアカウントの残高を管理するために、別の EOA で ETH を所有するか、多くの場合集中化されている中継システムに依存する必要があります。

EIP 2938 は、一部のイーサリアム プロトコルを変更して、トップレベルのイーサリアム トランザクションが EOA ではなくコントラクトから開始できるようにすることで、この問題を解決する方法です。契約自体には検証と料金支払いのロジックがあり、マイナーがそれをチェックします。ただし、プロトコル開発者がマージとスケーラビリティに細心の注意を払う場合、プロトコルに大幅な変更を加える必要があります。私たちの新しい提案 (ERC 4337) では、コンセンサス層プロトコルを変更せずに同じ利点を達成する方法を提供します。

副題

この提案はどのように機能しますか?

変更するのはコンセンサス層のロジックそのものではなく、トランザクションメモリプールを上位システムに複製する機能です。ユーザーは、ユーザーの意図を検証用の署名およびその他のデータとともにパッケージ化して、UserOperation オブジェクトを送信します。 Flashbot などのサービスを使用するマイナーとバンドラーはどちらも、UserOperation オブジェクトのセットを「バンドル トランザクション」にバンドルでき、これがイーサリアム ブロックに組み込まれます。

バンドラーはETHでのバンドル取引に対して支払いを受け、実行されるすべての個々のユーザーアクションの一部として支払われる手数料によって補償されます。バンドラーは、マイナーが既存のトランザクション メモリプールで動作する方法と同様の料金優先順位付けロジックに基づいて、どの UserOperation オブジェクトを含めるかを選択します。 UserOperation はトランザクションに似ており、次のフィールドを含む ABI エンコードされた構造です。

1.送信者：操作用ウォレット

2. ノンスと署名: ウォレットが動作を検証できるようにウォレット検証関数に渡されるパラメータ

4. callData: 実際の実行ステップでウォレットを呼び出すために使用されるデータ

残りのフィールドはガスと料金の管理に関連しており、フィールドの完全なリストは ERC 4337 仕様にあります。

副題

ウォレットはスマート コントラクトであり、次の 2 つの機能が必要です。

2. op は関数を実行し、ウォレットがアクションを実行するための命令として calldata を解釈します。この関数が calldata とその結果をどのように解釈するかは完全に不明ですが、最も一般的な動作は、calldata を解析してウォレットが 1 つ以上の呼び出しを行うための命令にすることであると予想されます。

ウォレットのロジックを簡素化するために、セキュリティを確保するために必要な複雑なスマート コントラクトのトリックのほとんどは、ウォレット自体ではなく、エントリ ポイントと呼ばれるグローバル コントラクトで行われます。 validateUserOp 関数と実行関数は require(msg.sender == ENTRY_POINT) でゲートされることが期待されているため、信頼できるエントリ ポイントのみがウォレットに操作を実行させたり、手数料を支払わせたりすることができます。エントリ ポイントは、validateUserOp の後にウォレットに対して任意の呼び出しを行うだけであり、その呼び出しのデータを運ぶ UserOperation は成功しているため、ウォレットを攻撃から保護するにはこれで十分です。ウォレットが存在しない場合、エントリ ポイントは、提供された initCode を使用してウォレットを作成する責任もあります。

副題

ランタイムエントリポイント制御フロー

UserOperation の検証が正常にモックされた場合、送信者アカウントで他の内部状態変化が発生するまで (別の UserOperation に同じ送信者があるか、送信者を呼び出す別のコントラクトがあるため)、UserOperation は収容可能であることが保証されます。 、アカウントでこの条件をトリガーするには、チェーンに 7500+ガスを費やす必要があります)。

また、ユーザーアクションは validateUser ステップのガス制限を指定します。このガス制限が非常に小さい (たとえば、200000 未満) 場合を除き、mempool ノードとバンドラーはそれを拒否します。これらの制限により、既存のイーサリアム トランザクションの主要なプロパティが複製され、メモリプールが DoS 攻撃に対して免疫になります。バンドラーとメモリプール ノードは、今日のイーサリアム トランザクションと同様のロジックを使用して、UserOperation を含めるか転送するかを決定できます。

副題

通常の Ethereum トランザクション メモリプールと比較して、この設計ではどのようなプロパティが追加、維持、犠牲になりますか?

プロパティを維持します。

1. 集中管理された参加者は存在せず、すべてがピアツーピアのメモリプールを通じて行われます。

2. DoS セーフ (偽装チェックに合格したユーザーのアクションは、送信者が別の状態変化を起こすまで阻止可能であることが保証されます。その場合、攻撃者は送信者ごとに 7500+ ガスを支払う必要があります)

3. クライアント側のウォレット設定は複雑ではありません: ユーザーは、ウォレットコントラクトが「公開」されているかどうかを気にする必要はありません。ウォレットは決定的な CREATE2 アドレスに存在し、ウォレットがまだ存在しない場合は、最初の UserOperation が実行されます。自動的に作成します

4. 料金設定を含む完全な EIP 1559 サポート (ユーザーは固定料金プレミアムと最高合計料金を設定でき、迅速な包含と公正な料金が期待できます)

5. アクションを置き換えるために、古いアクションよりも高いプレミアムで新しいユーザー アクションを送信したり、有償置換により迅速にアクションを含めたりする機能

新しいメリット:

1. 検証ロジックの柔軟性: validateUserOp 関数は、任意の署名とナンス検証ロジック (新しい署名スキーム、マルチ署名など) を追加できます。

3. ウォレットのアップグレード可能性: ウォレットの検証ロジックはステートフルにできるため、ウォレットは公開鍵を変更したり、(DELEGATECALL を使用して発行された場合は) コードを完全にアップグレードしたりできます。

欠点がある

4. 実行ロジックの柔軟性: ウォレットは実行ステップにカスタム ロジックを追加できます。アトミックなマルチオペレーションを実行する (EIP 3074 の重要な目標)

欠点がある

1. プロトコルの最善の努力にも関わらず、許可される検証ロジックが単一の ECDSA 検証による現状よりも複雑であるという理由だけで、DoS 脆弱性がわずかに増加しています。

2. ガス オーバーヘッド: 通常のトランザクションよりもガス オーバーヘッドがわずかに増加します (ただし、ユースケースによっては、これはマルチオペレーションのサポートによって相殺されます)。

3. 一度に 1 つのトランザクション: アカウントはキューに入れて複数のトランザクションをメモリプールに送信することはできません。ただし、アトミックな複数操作を実行できるため、この機能の必要性は大幅に低くなります。

支払者とのスポンサーシップ:

スポンサーシップ取引には重要な使用例が多数あります。最も一般的に挙げられる望ましいユースケースは次のとおりです。

2. ユーザーが ERC20 トークンで料金を支払うことを許可し、契約は ERC20 への請求と ETH での支払いの仲介として機能します。

この提案では、組み込みの支払い管理メカニズムを通じてこの機能をサポートする可能性があります。 UserOperation は、別のアドレスを支払者として設定できます。支払い管理者が設定されている (つまり、ゼロ以外) 場合、検証ステップ中に、エントリ ポイントも支払い管理者を呼び出して、支払い管理者が UserOperation に対して支払う意思があるかどうかを確認します。その場合、手数料はウォレットではなく、エントリーポイント内にステークされているペイメントディレクターのETHから差し引かれます（安全のため出金は遅れます）。実行ステップでは、ウォレットは通常どおり UserOperation で calldata を呼び出しますが、その後 postOp で paymaster を呼び出します。

副題

上記 2 つの使用例のワークフローの例は次のとおりです。

2. 支払い管理者は、送信者のウォレットに UserOperation を支払うのに十分な ERC20 残高があるかどうかを確認します。その場合、ペイマスターは ETH 料金を受け入れて支払い、その後、補償として postOp で ERC20 トークンを請求します (UserOperation によって ERC20 残高が枯渇したために postOp が失敗した場合、実行が再開され、postOp が再度呼び出されるため、ペイマスターは常に支払われます）。現在、これは ERC20 が支払い管理者自体によって管理されるラップされたトークンである場合にのみ実行できることに注意してください。

特に、2 番目のケースでは、支払い監督者が完全に反応的である可能性があり、場合によってはパラメータのリバランスやリセットを行う可能性があることに注意してください。これは、個々の取引を積極的に処理するために支払者が常にオンラインである必要がある既存のスポンサーシップの試みに比べて、大幅な改善です。

副題

この提案はどうなるのでしょうか？