EIP-3074 は、次の Ethereum ハードフォーク (Pectra/Petra) への組み込みが承認されたため、一夜にして最もホットな話題となりました。しかし、この騒ぎは何のためで、Ethereum と EVM エコシステムにどのような影響を与えるのでしょうか。この記事では、この提案について検討し、よくある質問に回答し、いくつかの神話や誤解を払拭します。さっそく見ていきましょう。
アカウント抽象化 EIP/ERC の概要
アカウントの抽象化についての理解を深めるには、「アカウントの抽象化」という言葉は、ほとんどの場合、「スマート（コントラクト）アカウント」を意味していることを知っておく必要があります。これは、アカウントが単一の秘密鍵ではなくコントラクト コードに基づいている場合です。ほとんどの場合と同様に、単一の秘密鍵で認証できますが（これは後で重要になります）、Safe の場合のように、マルチ署名ウォレットになることもあります。
「アカウント抽象化」の本来の意味は「スマート コントラクトがトランザクションを開始できるようにする」でしたが、その後「スマート コントラクト アカウントが有効にするすべての機能」に変わりました。
スマートコントラクトアカウントでは、これらの機能やその他の機能が有効になります。
ガスの抽象化: dApp がガスをスポンサーし、ユーザーがさまざまな ERC20 トークンでガスを支払い、さらにはガスの前払いも可能で、クロスチェーン オンボーディングに最適です。
これは、チェーン/ロールアップのネイティブ通貨が何であれ、友人に ETH MATIC でアカウントに資金を提供するよう依頼したり、さらに悪いことに取引所から引き出したりすることで、個人情報をさらすことがなくなるため、プライバシーと OpSec にとって優れています。
トランザクションのバッチ処理: 複数のアクションを 1 つのトランザクションにまとめること。これは、セキュリティとガス効率の両方にとって素晴らしいことです。
セキュリティ: ERC-20 承認の解決。バッチ処理の副作用として、承認を必要とする各アクションと一緒に正確な量の承認を行うことができるため、承認の問題が解消されます。なぜでしょうか? 承認が無限に必要になったり、余ったりする必要がなく、承認に 2 番目の署名が必要なくなるためです。
カスタム暗号化: 新しい暗号化曲線、WebAuthn、iOS セキュア エンクレーブ、量子安全性などを有効にします。
キーローテーションとアカウント回復: 既存のアカウントの秘密鍵を変更するか、Argent のソーシャル回復などのスキームを使用してアカウントを回復します。
何かお気づきでしょうか? これらはすべて、何らかの形でセキュリティに役立ちます。
ERCに戻ります。
一般的に、アカウント抽象化に関連するすべての ERC は、それらの機能をその動機として主張していますが、必ずしもそれらを提供するわけではなく、それらの機能を主流にするための道を開くのに役立つだけです。
詳しく見てみましょう。大規模な ERC は、次のような異なる問題を解決します。
トランザクションの開始: 契約がトランザクションを開始する機能。
ネイティブ: スマート コントラクトから発生するプロトコル内の特別なトランザクション タイプ。ERC-2938 が含まれますが、後に RIP-7560 に置き換えられました。
エミュレート: ERC-4337 は、トランザクションが実際には EOA によって開始されるという意味で「エミュレート」されています。これは、ユーザーがこの EOA を認識している必要があるという意味ではありません。この EOA はバンドラーによって制御および操作されます。
既存ユーザーの変換: ここでEIP-3074 (およびそのより小さな相棒であるERC-5003)が登場します
EIP-3074 では、既存の EOA の制御をスマート コントラクトに委任できます。スマート コントラクトはこの EOA を制御し、そのアドレスから呼び出しを行うことができますが、トランザクションを開始することはできません。トランザクション開始の問題を解決する必要があるため、これは重要です。
ERC-5003 では、この EOA のマスター キーのように機能する元の秘密キーを取り消すことで、EOA をスマート コントラクト アカウントに「完全に」変換できます。
署名: 通常、契約では署名に署名することはできません。しかし、契約ではその契約の有効な署名を定義するロジックを定義できます。たとえば、Bob と Alice の間のマルチシグであるスマート コントラクト ウォレットでは、有効な署名を isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature) として定義します。これは、契約コードで定義する必要があります。
ERC-1271 はこれを実現するためのインターフェースを定義します。
ERC-6492 はこれを拡張して、まだデプロイされていないスマート コントラクト アカウントをサポートします。これにより、すべてのチェーンで同じアドレスをシームレスに使用できるようになり、ユーザーは引き続きメッセージに署名できます。
動作させるには、両方を dApps で実装する必要があります。
真の AA エクスペリエンスを実現するには、上記のすべてを同時に解決する必要があります。これが、EIP-3074 が ERC-4337、RIP-7560、またはその他のアカウント抽象化 ERC と競合しない理由です。
これらすべてを視覚的に確認したい場合は、AA ERC の謎を解く講演のこのスライドをお勧めします。
よくある EIP-3074 FUD の神話打破
まず、重要な問題から始めましょう。EIP-3074 に関連する FUD が 3 つあります。
悪意のある dApp が 1 回のトランザクションで既存のウォレットを空にすることを可能にします。このような署名を作成できることは事実ですが、ウォレット プロバイダーが dApp にこのようなリクエストに署名させることを許可する理由や使用例はありません。ウォレット側からこれを保護することは、秘密鍵自体を保護するよりもはるかに簡単であり、秘密鍵を漏洩しても同じ効果があります。
アカウントは単一のマスターキー（元のEOAキー）を保持します。これを解決する追加のERC、EIP-5003（別名AUTHUSURP）があり、これにより元の秘密キーを失効させることができます。
EIP-3074 は、ネイティブ AA の利点をもたらさない応急処置です。EIP-3074 は、RIP-7560 などの実際の AA 提案と競合することを意図したものではありません。これは AA に対する応急処置ではなく、移行パスです。前述のように、ネイティブ AA ではトランザクション開始の問題が解決されないため、ネイティブ AA は依然として必要です。
EIP-3074 の長所と短所
利点: MetaMask、Trezor、Ledger などの既存ユーザーが既存のアカウントでアカウント抽象化の機能を体験できる、非常に簡単な移行パスが作成されます。
短所: キーのローテーションが犠牲になります。上記のすべての AA 機能を有効にすることはできますが、元の秘密キーは、EIP-5003 であっても、使用されたことのないすべてのネットワーク上のアカウントを制御し続けるため、キーのローテーションはやや困難になります。
精神的な訓練
動いている部分を理解するのに役立つ精神的なエクササイズを次に示します。
Ethereum メインネットには EOA である alice.eth (0x696969..69) が存在します。この EOA は定義上クロスチェーンであるため、すべてのロールアップと EVM チェーンにも存在します。
この EOA は、アリスが所有する秘密鍵 A によってのみ制御されます。
EIP-3074 が稼働開始。
悪意のある dApp は Alice を騙して、悪意のある契約を承認する EIP-3074 AUTH 署名に署名するように要求します。ウォレットはこの要求を無視し、dApp を切断します。これは、この要求が適切に実装されており、dApp からこれを許可するユースケースがまったくないためです。
Alice はウォレット プロバイダー (たとえば、Snap または Ambire 経由の MetaMask) で [アカウント抽象化を有効にする] ボタンをクリックします。ウォレットは EIP-3074 AUTH 署名に署名し、ウォレット プロバイダーが作成した、バッチ処理、ガス スポンサーシップなどを実行するための契約を承認します。
この契約は秘密鍵 A によってのみ制御されます。
alice.eth は、現在、秘密鍵 A (EOA モード) と新しいコントラクト (それ自体も秘密鍵 A によってのみ制御されます) の 2 つのエンティティによって個別に制御されています。
アリスはバッチ処理を実行できるようになりましたが、ガス スポンサーシップを実行するには、アリスのウォレット プロバイダーが ERC-4337 または RIP-7560 (ネットワークがサポートしている場合) を実装するか、アリスが ETH を使用する必要がないように独自のリレーヤーを実装する必要があります (トランザクションを開始する場合、これはネットワークの厳しい要件です)。
Alice は alice.eth をマルチシグに変換することを決定し、ウォレットプロバイダーはコントラクトに秘密鍵 A を取り消して秘密鍵 BMobilePhone と BLaptop の 2/2 マルチシグを承認するように指示します。
ただし、秘密鍵 A が依然として Alice.eth を制御しているため、これは機能しません。EIP-3074 によれば、元の秘密鍵は契約に委任されているにもかかわらず制御を保持します。
EIP-5003 が Ethereum で稼働し、alice.eth がウォレット プロバイダー経由でネットワークに特別な指示を送信し、秘密鍵 A の制御を取り消すことができるようになります。
alice.eth はマルチシグに変換されましたが、これは Ethereum 上のみです。他のすべてのネットワーク上の alice.eth に対する制御は、引き続き (Alice が所有する) 秘密鍵 A によって保持されます。
最終的に、私たちはいくつかのことを学びました:
EIP-3074 がなければ、Alice はおそらく Account 抽象化を採用しなかったでしょうから、私たちは素晴らしいことを成し遂げました。
EIP-3074 ですべてが解決されるわけではありません。昨日と同じくらい、ERC-4337 と RIP-7560 も必要です。
EIP-3074 は、たとえ EIP-5003 があっても、キーのローテーションとうまく連携しません。このため、マルチシグやキーのローテーションなどのユースケースを容易にするには、実際のスマート アカウントが依然として必要です。
余談ですが、キーローテーションはほとんどの人にとってはあまりにも新しいものであり、すべてのロールアップとチェーン間で同じ状態を持たないクロスチェーンの世界では少し複雑であると考えています。ほとんどのユーザーは、特にほとんどのユースケースで十分に安全なハードウェアウォレットの場合、1 つのキー = 1 つのアカウントというパラダイムに固執しているようです。
よくある質問
この記事の残りの部分は FAQ 形式になっており、よくある質問のいくつかに適切に対応することができます。
それはMetaMaskの前進に役立つでしょうか?
私たちは、アカウント抽象化企業は、既存企業が既存のオーディエンスに AA 機能を提供できることから得られる価値よりも、より簡単なオンボーディング UX からより大きな価値を得られると考えています。
言い換えれば、資金を新しいアドレスに移動することを望む早期導入者だけでなく、アドレス可能な市場全体に AA ウォレットの力を「解き放つ」のです。
MetaMask Snaps のおかげで、多くの AA 企業が MetaMask 上に AA を構築する方向に転換するでしょう。これは、最も鋭敏な観察者以外は誰も予想できなかった銀河脳の位置付けです。
バッチ処理自体は安全ではないのでしょうか?
絶対にそうではありません。署名内容は依然として表示されます。トランザクション シミュレーションと組み合わせると、複数のアクションに署名することは単一のアクションに署名するのと同じくらい安全であり、ほとんどの場合、より安全です。
トランザクションのバッチ処理は、アカウント抽象化の最も高く評価されている機能の1つです。
これは dApps が AA を採用するのに役立ちますか? 互換性の問題は解決されますか?
dApps は、いくつかの例外を除いて、あらゆる形式のアカウント抽象化で動作します。
一部のdAppはスマート（契約）アカウントを差別する
一部のdAppはERC-1271をサポートしていません
EIP-3074 は、両方の問題を魔法のように解決します。アカウントは EOA として表示される (コードがない) ため、区別できません。署名に関しては、AA 対応 (3074 経由) EOA は引き続き EOA として署名されるため、問題はありません。キーのローテーションが失われるという代償を払って、すべての dApp で魔法のように機能します。
しかし、ほとんどの人が純粋なスマート アカウントよりも AA 対応の EOA を選択した場合、dApp が ERC-1271 と ERC-6492 をサポートするインセンティブが失われますが、ERC-4337 はすでに署名提案に対する認識を高めるのに役立っています。
元のキーを取り消すとどうなりますか?
EIP-5003 (ハードフォークではまだ計画されていません) を介してキーを取り消すことができます。
この点の微妙な点は、これがクロスチェーンの世界では完璧なソリューションではないということです。EOA は、使用を開始するすべての新しいチェーンで常に EOA として開始されるため、元のキーを完全に取り消すことはできません。ただし、これはすべての形式の AA に当てはまります。アカウントを作成した元の権限/特権は、常に新しいネットワークでアカウントが開始されるときに付与される権限/特権だからです。
EIP-3074 は、キー ローテーションを除くすべての AA 機能を既存の EOA に導入する上でより効果的です。つまり、EOA に対して AA を有効にすることを選択した場合、この EOA の背後にある元の秘密キーは永久に保持されます。
ネイティブ AA (RIP-7560) は削除されますか?
いいえ、少なくともネイティブトークンとは異なるトークンでガスを支払う場合（またはガススポンサーシップが必要な場合）は、トランザクションを開始するためのソリューションがまだ必要だからです。
ERC-4337 は、プロトコルのアップグレードを必要としない (ネイティブではない) ソリューションの 1 つですが、ネイティブのプロトコルに準拠した AA は、ERC-4337 のガス オーバーヘッドと複雑さを解決するため、非常に価値があります。
しかし、EIP-7377はどうでしょうか
EIP-7377 を使用すると、EOA をスマート アカウントに変換できます。この EIP では、スマート コントラクトが元の PK と一緒に EOA を制御できるようにするのではなく、コントラクトが 1 つのトランザクションで EOA を引き継ぐことができます。
EIP-3074 + EIP-5003 の代替品として考えられますが、それほどの勢いは得られませんでした。
最後に
EIP-3074 は応急処置ではありません。ユーザーに既存のアカウントを突然放棄し、すべての資金、ステーキング ポジションなどを新しいアカウント (スマート コントラクト アカウント) に移行するよう求めることで、参入障壁が大幅に高まるため、Ethereum と EVM エコシステムの将来にとって非常に明るい兆しとなります。
EIP-3074 は、UX を劇的に改善するために必要な、新たな中間点と段階的なオンボーディングを提供します。
Ambireに興味がありますか？フォローしてください:
Discord | X (Twitter) | Reddit | GitHub | Telegram | Facebook
