EIP-3074: AUTH and AUTHCALL opcodes紹介（2024イーサリアムPectraアップグレード）

こんにちは。次世代システム研究室のL.C.A.です。（海外の出身です。）

ChatGPT-4oにこの記事の日本語訂正を手伝っていただき、感謝します。

24年に予定されているイーサリアムのPectraアップグレードでは、EIP-3074が大きな注目を集めています。この提案は、 AUTH と AUTHCALL という二つの新しいEVM OpCodesを導入し、スマートコントラクトが直接EOA（Externally Owned Account）の名義でトランザクションを代行できる機能を提供します。これにより、EOAの利便性が大幅に向上することが期待されています。

EIP-3074の実装により、バッチトランザクション、ソーシャルリカバリー、第三者によるGas feeの支払いといった新たな機能が実現し、ユーザー体験は大きく革新されるでしょう。

本記事では、EIP-3074の詳細な機能や、その実装による利点とデメリットについて詳しく解説します。

目次

TLDR

EoAにスマートコントラクトの機能を付与

• EoAのできることが増える
  • バッチトランザクション
  • 支払い代行
  • Social recovery
•  実現の方法：スマートコントラクトがEoAの代理人（EoAの名義として）としてトランザクションを実行できるようにする
  • 具体的にはEVMにAUTHとAUTHCALL のOpCodesを新たに追加する
  • EVMに直接opcode追加するので、hard forkが必要
  • Abstract Account(AA, ERC-4337)のようなアカウント機能がEIP-3074で実現できる

• 最近 VitalikがEIP-3074の他に、EIP-7702の提案がある

  • 簡単に言えば、 EIP-3074 の最適化された進化版であり、ERC-4337 イーサリアムアカウント抽象化の戦略とより互換性が高い。

EoAとは

• 外部所有アカウント（metamaskにあるアカウント）

• EoAは、秘密鍵によって制御されています。ユーザーがその秘密鍵を持っている限り、そのアカウントにアクセスし、アカウントでイーサリアムを使用することが可能です。

現在EoAが直面しているUXの問題

• transactionは一つずつ送信する必要がある（バッチトランザクションできない）
• 他人がガス料金を代わりに支払うことが難しい
• 秘密鍵を失うと資金の救出が不可能
• ETHがないとどんな取引もできない

EIP-3074以前トランザクション実行の流れ

• msg.senderは必ずコントラクトの呼び出し元となる
• コントラクトはEoAの名義としてトランザクションの実行できない

既存のAA（EIP-4337）で解決できない？

EIP-4337（アブストラクトアカウント）を通じて上記の問題を解決することは可能ですが、現在のユーザーは主にEoAを使用しており（Metamaskなどのサービスが普及しているため）、さらに EIP-4337は設計や開発が複雑 なため、全てのDAppがAAを利用するのは難しい状況です。

また、AAを使用するためには、EoAからAAへの資金移動が必要 です。

そのため、EIP-3074を通じて、 EVMの基盤構造を直接改善し、EoAユーザーの体験を向上させることを目指します 。

出典：https://safe.global/blog/eip-3074-risks-opportunities-for-smart-account-adoption

EIP-3074の導入

msg.sender を使用する理由は、トランザクションの呼び出し元の身元を認証するためです。つまり、呼び出し元が正当なEoAの許可を持っていることを確認すれば、msg.senderが必ずしも「送信元アドレス」である必要はありません。

EIP-3074を理解するための一つの方法は、新しいOPコード（AuthとAuthcall）と新しいウォレットプラグイン（invokerコントラクト）を通じて、既存の msg.sender が必ず呼び出し元のコントラクトのアドレスであるという制限を排除することです。

この制限を排除することで、カスタマイズされた「代理ロジック」を invoker コントラクト（AAのような）に実装でき、EoAがコントラクトのようにトランザクションを実行できるようになります。

技術の紹介

EIP-3074は、二つの新しいOPコード、 AUTH と AUTHCALL を使用して上記の機能を実現します。AUTH は認証プロセスを意味し、EOAの所有者が署名し、invokerに代理呼び出しを許可したことを認証します。AUTHCALL は、コントラクトがCALLの代わりに使用すると、外部コントラクトへの呼び出し時にmsg.senderをEOAの署名者として上書きすることができます。

署名(Auth message)の中身

出典：https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3074.md

認可の撤回方法

• EoAが署名する際、常に署名（Authメッセージ）にはnonceが含まれます。
•  Authcallが実行される際、EoAのnonceと署名内のnonceが一致するかどうかを検証します。
  • もし一致しない場合、その署名は無効です。
• 要するに、EoAの所有者が再度トランザクションを送信するだけで、以前に署名した署名を無効にすることができます。

例えば、あるEOAの現在のnonceが10であるとします。

その所有者が簡単なイーサリアムトランザクション、例えば自分自身に送金を行うとしましょう。

すると、イーサリアムの記録上でEOAのnonceは1増加して11になります。その後、AUTHCALLの検証ではnonce=11を使用して署名を検証するため、以前に署名された署名は無効となります。

応用例

1. 第三者によるGas feeの支払い
   例：User AがETHを購入する必要がなく、AppがUser Aの代わりにGas feeを支払うことで、User AのEoA名義でERC-20などの資産（例：GYEN）を移動することができます。
2. バッチトランザクション（Batch Transaction）
   例：一度のトランザクションで複数の操作を実行する能力。現在、Uniswapでトークンを交換するためには、まずトランザクションでUniswapにトークンの使用を許可し、その後に実際の交換トランザクションを行う必要があります。
3. ソーシャルリカバリー（Social Recovery）
   特殊なInvokerコントラクトを設定することで、失った秘密鍵をソーシャルリカバリーを利用して資産を回復することが可能になります。

デメリット

• フィッシング
  • 悪意のあるinvokerへ署名を求めるリスクがあります。
• Invokerコントラクトのハッキング
  • Invokerコントラクト自体がハッキングされるリスクがあります。-
• アップグレード不可
  • 一度デプロイされた後、Invokerコントラクトはその機能やロジックをアップグレードすることができないため、将来の変更やセキュリティ強化が難しいです。

まとめ

EIP-3074は、 AUTH と AUTHCALL の2つの新しいEVM OpCodesを追加します。これにより、スマートコントラクトが直接EoA（Externally Owned Account）の名義でトランザクションを代行することが可能になり、EoAの利便性が大幅に向上します。このEIPにより実現できる機能は以下の通りです：

• バッチトランザクション
• EoAのソーシャルリカバリー
• 第三者によるGas feeの支払い

しかし、この機能はEIP-4337（アカウント抽象化、AA）と重複する部分があり、EIP-4337への注目度が低下する可能性があります。EIP-3074は2024年4Qか2025年1Qに予定されているPectraアップグレードで適用される予定です。

最近では、VitalikがEIP-3074の他にEIP-7702も提案しており、これはEIP-3074よりもERC-4337（イーサリアムアカウント抽象化）の戦略とより高い親和性を持っています。

参考資料

• • Rollup 的大補帖：Proto-Danksharding（一）
  • EIP3074 簡介
  • Account Abstraction 抽象帳戶：EIP-3074 與 EIP-4337 簡介
  • Haotian | CryptoInsight on Twitter / X
  • Komy | Kyuzan on Twitter / X
  • [EIP3074] 2つの新しい命令を追加しコントラクトにEOAの制御を委任する仕組みを理解しよう！

最後に

グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧からご応募をお待ちしています。