イーサネット、ソラナ、コスモスのアカウント抽象化ソリューションの類似点と相違点の研究

Author: Zeqing Guo & Jinming Neo, HashKey Capital; Translated by Golden Finance.xiaozou

1, なぜアカウントの抽象化（AA）が必要なのでしょうか？

今日のブロックチェーン分野には、未解決の問題がたくさんあります。その中でも、ブロックチェーンを利用することの難しさ、あるいはブロックチェーンと対話する際のユーザーエクスペリエンス（UX）は、最も公的な不満が多い分野であることは間違いありません。

例えば、多くの人は、鍵を使うことが電子メールを使ってアカウントを管理するよりも複雑であること、鍵の管理が難しく安全でないこと、ネイティブトークン（イーサやソルなど）が各送金（USDCなど）にまだ必要であることを逆に直感的に感じている。

このような状況の中、オンチェーンでのやりとりのユーザーエクスペリエンスを向上させ、大量採用を促進するために、アカウントの抽象化という分野にますます注目が集まっています。

調査プロセスにおいて、イーサネットはERC-4337、EIP-3074、EIP-7702などのアカウント抽象化ソリューションを提案しました。他のL1（例：Solana）はプロトコルレベルのアカウント抽象化をサポートする機能（例：Program Derived Address PDA）を持っており、 Cosmosも同様の設計（例：x/authzやFee Abstraction Module）を持っている。この論文では、上記のソリューションを紹介し、比較し、異なるソリューション設計の微妙な点を理解し、異なるソリューションのトレードオフと注意点を示します。

2, 背景

(1)EOAと契約。アカウント

外部アカウント（EOS）と契約アカウントは、イーサのホワイトペーパーで定義されている2種類のアカウントです。EOAアカウントは秘密鍵によって管理され、ユーザーは様々な取引に署名し、アカウント内の資産を管理することができます。コントラクト・アカウントはコントラクト・アカウント自体のコードによって制御され、他のアカウントはコントラクト・アカウントのコードを呼び出して、コントラクト・アカウントが特定のロジックを実行できるようにすることができる。

(2)アカウントの抽象化

抽象アカウントの概念は2016年にさかのぼります。アカウントの抽象化は、イーサの現在の2種類のアカウント、EOAアカウントとコントラクトアカウントに基づいて構築されています。

- Schnorr, BLS, post-quantum signaturesなどの複数のシグネチャを使用できるようにする。

- ERC を使用してガス料金を支払うことができるようにする。

- ERC20 トークンまたはカスタム支払いロジックを使用して、ユーザーがガス料金を支払うことができるようにします。

- Allow multiple on-chain operations to be performed in a single atomic transaction.

- 複数のオンチェーン操作を単一のアトミックトランザクションで実行できるようにします。

(3)イーサロードマップ

イーサロードマップは、イーサの将来のアップグレードパスを強調しています。現在、イーサリアムコミュニティにおける研究のほとんどは、イーサリアムのロードマップを中心に展開されています。

イーサネットコミュニティは、ERC-4337に基づき、EIP-3074やEIP-7702などの提案を通じて、プロトコル内にアカウント抽象化ソリューションを実装し、最終的にはEndgameのアカウント抽象化を実現したいと考えています。

ユーザーエクスペリエンスの向上にもかかわらず、EOAアカウントに使用されている現在のECDSAアルゴリズムは量子コンピューティングの時代には安全ではないため、アカウントの抽象化エンドゲームはイーサの反量子コンピューティングにとっても重要です。ポスト量子署名をサポートするためにアカウント抽象化を採用することは、量子コンピューティングによってもたらされる進化する脅威からユーザーアカウントを保護します。

3、EIP-3074、ERC-4337

アカウント抽象化アカウントを理解するには、EOAの仕組みを理解する必要があります。

次の図は、チェーン上で最も一般的なトークン売買のプロセスを示しています。: left;">一般的に、ユーザーはトークンを売買する際に2つのトランザクションを送信する必要があります。まず、Uniswapが交換のためにUSDCを送金することを承認し、次にUniswapに操作の実行を要求する別のトランザクションを送信します。 UniswapはユーザーのアカウントからUSDCを送金し、現在の価格に基づいて適切な量のETHをユーザーに送ります。="text-align: left;">ERC-4337は、上記の2つのトランザクションを1つに統合します：

上の図からわかるように、ユーザーは、ユーザーのEOAアカウントとは異なる4337アカウントにあるユーザーの資産を操作する権限をバンドラーに与えるために、2つの署名が必要です。バンドル担当者は権限を取得した後、その権限をトランザクションパッケージにマージし、そのパッケージをポストしてトランザクションを完了する。また、ユーザーがガス料金の支払いに使用するイーサトークンを持っていない場合、ペイマスターの役割を導入することで、ペイマスターがガス料金を支払い、ユーザーから同等のERC20トークンを受け取ることができます。

EIP-3074とERC-4337にはいくつかの類似点がありますが、EIP-3074の実装はEtherプロトコル内にあります：

ERC-4337では、署名によって、バンドル者がオンチェーンのスマートコントラクトウォレットで資産を扱うことを承認します。EIP-3074では、バンドル者は署名を通じてEOAウォレット内の資産を直接扱う権限を与えられます。

AUTHは、バンドラーによるユーザーのEOAアカウント内の資産の取り扱いが認可されていることを検証するために使用されます。AUTHCALLは、ユーザーと相互作用するスマートコントラクト（この例ではUSDCとUniswap）が、トランザクションがユーザーのEOAアカウントから来たと考えるように「なりすます」ために使用される。これには、UniswapとUSDCのメンテナがデプロイされたスマートコントラクトをアップグレードする必要がない一方で、EOAアカウントはアカウント抽象化の機能を維持できるという利点があります。

(1)EIP-3074とERC-4337の比較

イーサネット コミュニティでは通常、EIP はサポートするためにイーサネットのアップグレードを必要とする提案を指し、ERC はサポートするためにイーサネットのアップグレードを必要としない仕様を指します。

つまり、2つのアカウント抽象化スキームの命名からわかるように、ERC-4337はイーサネットネットワークのハードフォークを必要としないため、EIP-3074よりも実装が簡単です。これがERC-4337がリリースされ、polygonやbaseでますます使用されている理由の1つですが、EIP-3074は第183回イーサネット全コア開発者幹部会議（ACDE）で承認されたばかりです。

さらに、ERC-3074では、ユーザーがERC-3074に移行する必要があります。4337では、ユーザーは現在のアカウントを新しい契約アカウントに移行する必要があり、DAppはEIP-1271の機能をサポートする必要があります。これがERC-4337の採用率が低い主な理由です。また、ERC-4337は、中間的なマルチインボケーション契約を導入することなく、複数のオンチェーン操作を承認するための単一の署名をサポートすることができませんが、EIP-3074は可能であるという事実も、ERC-4337の限界の一因となっています。

しかし、EIP-3074には独自の問題があります。最も重要な問題は、オペコードAUTHがあまりにも特権的で、攻撃者がユーザーのEOAアカウントを完全にコントロールできるようになる可能性があることです。結局のところ、ハッカーがあなたを騙してAUTH署名を実行させさえすれば、そのハッカーはあなたのEOAウォレット内の資産を処分することができる。最近フィッシング攻撃が横行しており、そのほとんどがユーザーの署名を詐称することで行われていることを考えると、EIP-3074が実装されれば、これはさらに深刻な問題になるでしょう。

これに対して、EIP-3074の作者の一人であるlightclientは、ウォレットレベルで悪意のある署名をインターセプトする緩和方法を提案しました。はユーザーのアカウントにあるすべてのアセットを処分する許可を得るのが難しいからである。

(2)ACDEの開発者は、Pectra Devnet 0からEIP-3704を削除し、次のPectra Devnet 1にEIP-7702を含めることに合意しました。strong>EIP-7702で何が変わったのか?

EIP-7702は、EIP-3074とERC-4337の利点を統合し、中間の道を取ろうとしています。ユーザーは署名されたオペレーションをバンドルに送ります。バンドルがトランザクションをチェーンに送ると、ユーザーのEOAアカウントは一時的に4337アカウントのようなスマートコントラクトアカウントになります。次に、EIP-3074のAUTHプロセスと同様に、スマートコントラクトアカウントは、ユーザーによって認可されたバンドラー操作を検証する。その後、AUTHCALLと同様に、ユーザーによって認可された操作が実行される。トランザクションの実行後、ユーザーアカウントは通常のEOAアカウントにロールバックされる。

EIP-7702の利点は以下の通りです：

- EIP-3074 の利点をすべて継承しています：ユーザーがEOAアカウントから新しいアドレスを持つスマートコントラクトアカウントに切り替える必要がなく、1つのアトミックトランザクションで複数の操作を実行できます。

- ERC-4337 のスマートコントラクトアカウントのコードとインフラストラクチャを再利用できる。

- ERC-4337 で表されるスマートコントラクトアカウントの抽象化と ERC-4337 で表されるスマートコントラクトアカウントの抽象化は、再度使用できる。

- ERC-4337 で表されるスマートコントラクトアカウントの抽象化と ERC-4337 で表されるスマートコントラクトアカウントの抽象化は、再度使用できる。ERC-4337に代表されるスマートコントラクトのアカウント抽象化と、EIP-3074に代表されるEOAのアカウント抽象化ソリューションは統合することができ、イーサネットが2つの異なるアカウント抽象化システムに分裂するのを防ぎ、イーサネットのロードマップにおける抽象的なアカウントの最終段階への道を開きます。AUTHCALLオペコードはイーサネットのEVMには追加されません。イーサネットのロードマップを考慮すると、EOAアカウントは将来的にアカウント抽象化アカウントに変換され、その時点でこれら2つのオペコードは冗長になります。

その上、EIP-7702はEIP-3074のすべてのセキュリティリスクを継承しています。

コミュニティは、2025年のペクトラのアップグレードにEIP-7702を含めることを決定しました。これが実現すれば、イーサリアムのエコシステムが劇的に変化し、現在のERC-4337バージョンのアカウント抽象化インフラが段階的に改善されることになります。

4, ソラナの手続き派生アドレス（PDA）

(1)Solana's Account Abstractions

SolanaのAccount Abstractionsは、EtherのERC-4337に似ています。EOAアカウント）、4337契約アカウントに似ています。Solanaのアカウント抽象化を理解する前に、Solanaが使用するアカウントモデルを理解する必要があります。

大まかに言えば、アカウントはコードを実行できる実行可能アカウントと、コードを実行できない非実行可能アカウントに分類できます。さらに詳しく見ると、ソラナには「ネイティブプログラム」「プログラムアカウント」「データアカウント」の3種類のアカウントがあります。

ネイティブプログラムはValidator実装の一部であり、新しいデータアカウントやカスタムプログラムの作成など、Solanaネットワークのコア機能を提供します。プログラムアカウントは実行可能コードを含むカスタムプログラムである。データアカウントは、所有者のプログラムアカウントによって定義されるように、データを保存し、プログラムの状態を管理することができます。

このアカウントモデルでは、プログラムアカウントが特定のアカウントを作成および管理できるため、開発者はアカウントを管理するためのカスタムルールとロジックを定義することができます。このアカウントモデルのサポートにより、Program Derived Addresses (PDA) (データアカウントの一種) は、多署名ウォレットや二要素認証によるユーザーセキュリティの強化からソーシャルリカバリーメカニズムの実現まで、Solana におけるアカウント抽象化の可能性を広げます。

(2) Procedure Derived Address

文脈上、すべてのアカウントはEd25519カーブ上にあり、公開鍵と秘密鍵のペアを持ちます。PDAはEd25519カーブの外側にあり、公開鍵のように見えますが、対応する秘密鍵を持たない、決定論的に導き出された32バイト文字列です。PDAはEd25519曲線の外側に位置し、公開鍵のように見えますが、対応する秘密鍵はありません。PDAは、開発者がカスタムルールとトランザクション署名メカニズムを作成することを可能にし、PDAのプログラムアカウント所有者がPDAに代わって自律的にトランザクションを実行できるようにします。

(3)PDAと口座の抽象化

PDAがどのように導き出されるかを理解したところで、これらの概念が口座の抽象化とどのように関係するのかも気になるでしょう。アカウントの抽象化は、Cross Procedure Invocation (CPI)と呼ばれる関数の実行により、下部で実装されます。

CPIは、あるプログラムが別のプログラムから命令を呼び出すことを可能にすることで、Solanaプログラムのコンポーザビリティを実現する機能です。プログラムが invoke_signed を介して CPI を開始すると、派生した PDA に代わって署名することができます。

PDA関連のトランザクションの正当性を検証するために、Solanaは、PDAが正当なトランザクションであることを確認します。トランザクションが正当であることを確認するために、Solanaランタイムは内部的に、呼び出し元のsigners_seedsとprogram_idを使用してcreate_program_addressを呼び出す。有効なPDAが見つかった場合、ランタイムはPDAと呼び出し元のプログラムを関連付け、そのプログラムを認可された署名者として識別する。として識別する。

現在、SquadsはSolanaアカウント抽象化のためのPDAベースのソリューションを開発しています。

現在、SquadsはSolanaのアカウントを抽象化するためのPDAベースのソリューションを開発しています。

(4)PDAの利点

-スマートコントラクトの自動実行：PDAは、より複雑なスマートコントラクト設計をサポートします。スマート・コントラクトの自動実行：PDAは、クロス・プログラム・コールによってユーザーに代わって複数の操作を自律的に実行できる、より複雑なスマート・コントラクト設計をサポートします。

- Enhanced user experience: ユーザーは複数のトランザクションを管理したり、技術的な複雑さに対処したりする必要がありません。

- Enhanced security and flexibility:秘密鍵がないため、鍵の漏洩リスクを軽減できます。PDAはマルチシグネチャ・ウォレットや、単一リスクポイントを軽減するその他の柔軟なガバナンス・モデルに使用することができ、大規模な共有リソースを管理する組織にとって特に効果的です。

(5)PDAの限界

PDAは、アカウント抽象化機能の基礎固めには役立ちますが、キーよりも実装が難しいかもしれません。ペアアカウントはキーアカウントに比べて実装が複雑になる可能性があります。

ERC-4337と同様、ユーザーは新しいアカウントへの移行を行う必要があり、Solanaアカウント抽象化の採用を阻害する可能性があります。

5, Cosmos上のアカウント抽象化（AuthzとFee Grant）

5, Cosmos上のアカウント抽象化（AuthzとFee Grant）

(1)Cosmos x/authz

アカウントの抽象化がますます開発者の関心を集めています。authz（CosmosのコアSDKの一部）は、EIP-3074およびEIP-7702と同様に、あるアカウントが認証によって別のアカウントの代わりに特定のアクションを実行できるようにするために導入されました。

Authzには、誓約などの特定の操作の実行を承認者に委任することで、ユーザーエクスペリエンスを向上させるいくつかの事前定義された承認タイプがあります。

authzでは、以下の3種類の認可を与えることができます。

- GenericAuthorization：この認可は認可者に認可者に代わってメッセージを実行する無制限の許可を与えます。

- SendAuthorization: ERC20の承認と同様に、この認可は認可された人物に、認可された人物に代わって使用できる最大金額を定義する、正の支出制限を与えることを目的としています。

- StakeAuthorization: この権限により、ライセンシーは、承認者に代わって質権を委任したり、委任を取り消したり、再委任したりといった質権操作を管理することができます。

認可は、認可者のアドレスバイト、被認可者のアドレスバイト、および認可のタイプで構成されます。また、特定の期間の認可を制限するために、期間を定義することも可能である。各ブロックの終わりに、ネットワークはプルーニングと呼ばれるプロセスを通して、期限切れの認可を削除します。

オペレーションのフレームワークを理解する

Authzは様々なオペレーションにオーソライゼーションを提供するために使用することができますが、ここでは簡単にするために、Authzが汎用的な一般ポーリングトランザクションを可能にするためにどのように動作するかを見ていきます。

- 認可を実行する前に、認可インターフェースを実装します。この段階はメッセージタイプも定義します。この場合、MsgVoteです。ここでは、ガバナンス投票操作のためにアリスによって行われた付与を見てみましょう。

- Bob は署名なしの投票トランザクションを生成する。

- Bob は付与者から署名され実行された投票トランザクションを生成する。トランザクションは完了し、期限切れのトランザクションは削除される。

。authzの利点は何ですか？

- Operational security:検証者やその他のユーザーは、ガバナンス提案に対する投票や特定のアクションを実行するために、別のアカウントを承認することができます。

- Simplified operations: 取引は検証者の鍵にアクセスすることなく実行でき、複数署名のウォレット取引は、認証されたアカウントのAuthz認証を実行する単一のトランザクションを使用することで簡素化できます。

- No Migration Required: EIP-3074およびEIP-7702と同様に、認証操作はユーザーの元のアカウントで行われます。ユーザーは、アカウント抽象化を有効にするために、元のアカウントから新しいアカウントに資産を移行する必要はありません。

- DAO 運用効率と柔軟性：実行権の一部を各DAOメンバーに与え、特定の操作を実行させることができます。

- Pledge Reward Synthesis(誓約報酬の合成): Authzは、誓約報酬を自動的に合成するために、リプレッジと同等のサービスの使用を容易にします。

Authzの制限とリスク:

Authzを通じて承認される取引の種類に注意してください。悪意のある認証は、ユーザーにとって有害なさまざまなタイプの認証を実行する可能性があります。

- GenericAuthorization: 認証者に代わって、すべての複数署名を実行する無制限の許可を与えます。署名される内容を完全に理解していない限り、このタイプの認証への署名は避けることを強く推奨します。また、ウォレットによってはAuthzトランザクションに署名する際に警告を表示しない場合もあります。

- SendAuthorization: 認証された人が特定の金額を指定していない場合、認証された人が使用できる最大数のトークンを送信できるようにします。AllowListを確認することも重要です。AllowListは、承認者が送信したトークンを受信できる特定のアドレスを指定します。

(2)手数料付与モジュール

ユーザーエクスペリエンスに対するもう一つの障害は、ブロックチェーンユーザーがトークンにお金を払わなければならないという事実を認識しなければならないことです。障害のひとつは、ブロックチェーンユーザーがさまざまなエコシステムとやりとりするために、さまざまなネイティブトークンを保有する必要があることだ。これは、特にCosmosのエコシステムに存在する無数のチェーンに慣れていない非クリプトネイティブユーザーにとっては、全体的なユーザーエクスペリエンスを損なうことになる。

しかし、手数料付与モジュールの統合により、この問題に突破口が開かれました。イーサのアカウント抽象化を実装するペイマスターコントラクトと同様に、Cosmosの手数料付与モジュールは、オーソライザーがトランザクション手数料の一部または全部を支払うために、オーソライザーに手数料の許容範囲を付与することを可能にします。資金はオーソライザーの管理下に置かれたままであり、オーソライザーの許可はいつでも取り消すことができます。

費用認可の分類

費用手当は、基本手当（BasicAllowance）と定期手当（PeriodicAllowance）の2つに分類されます。定期手当に分類される。

BasicAllowanceでは、承認者は利用限度額または有効期限に達するまで、承認者のアカウントにある費用を使用することができ、その後承認はステータスで終了します。BasicAllowanceは1回限りの経費認可を実装していることに注意してください。もしSpend LimitとTimeがNULLに設定されている場合、その支出許可には有効期限や支出上限はありません。

PeriodicAllowanceでは、指定された期間ごとに定期的に支出許容量を更新することができます。period_spend_limitでは、指定された期間に使用できるトークンの最大数を指定します。period_can_spendは新しい期間の開始までに残っているトークンの数を追跡します。

オペレーション・フレームワークを理解する

AllowedMsgAllowanceを使用して、指定されたメッセージ・タイプの許容値を作成します。アローアンスは、BasicAllowance 基本アローアンスまたは PeriodicAllowance 定期アローアンスにすることができます。有効期限が設定されている場合、FeeAllowance は有効期限の接頭辞が付いた状態でキューに入れられ、Endblocker は FeeAllowanceQueue の状態をチェックして有効期限切れのアローアンスをチェックし、見つかった有効期限切れのアローアンスを削除します。MsgGrantAllowance に加えて、MsgRevokeAllowance を使用して支出許容を取り消すことができます。

要するに、AuthzモジュールとFee Grantモジュールは、最終的にCosmosエコシステム上でより良いユーザーエクスペリエンスを構築する、さまざまな革新的なユースケースのロックを解除します。

6、結論

2024年5月27日時点のアカウント抽象化予測は以下の通りです。align:center">

スポットBTC ETFとETH ETFが承認されたことで、機関投資家とリテールの需要は大幅に増加しました。">BTCのETFとETHのETFがスポットで承認されたことで、機関投資家やリテールからの需要が大幅に増加し、暗号業界へのエクスポージャーを得ようとするユーザーの新たな波が到来すると予想されています。プロトコルとdAppsがコミュニティを拡大するためにシームレスなエクスペリエンスを作成しようとする中、アカウントの抽象化は今年の重要な物語となるでしょう。