なぜ勘定科目の抽象化が必要なのか?

現在のブロックチェーン分野には、まだ多くの未解決の問題があります。その中でも、ブロックチェーンを利用することの難しさ、つまりチェーンと対話するユーザーエクスペリエンス(UX)は、一般の人々から最も批判されている分野に違いありません。

たとえば、多くの人は、鍵の使用は電子メールを使用してアカウントを管理するよりも複雑であり、鍵の管理は困難で安全ではないと考えています。 そして、各転送(USDCなど)はネイティブトークン(エーテルやソルなど)の消費を必要とし、これは直感に反します。

これに関連して、ますます多くの人々がアカウントの抽象化の分野に注意を向けて、オンチェーンインタラクションのユーザーエクスペリエンスを向上させ、大量採用を促進しています。

探索の過程で、イーサリアムはERC-4337、EIP-3074、EIP-7702などのアカウントの抽象化ソリューションを提案しました。ソラナなどの他のL1には、プログラム派生アドレス(PDA)などのプロトコルレベルのアカウントの抽象化を可能にする機能があり、Cosmosにもx / authzや料金抽象化モジュールなどの同様の設計があります。この記事では、上記のソリューションを紹介して比較し、さまざまなソリューションの設計の微妙な点を整理し、さまざまなソリューションのトレードオフと考慮事項を示します。

Background

外部所有アカウント (EOA) と契約アカウントは、イーサリアム ホワイトペーパーで定義されている 2 つのアカウントタイプです。EOAアカウントは秘密鍵によって制御され、ユーザーは秘密鍵を介してさまざまなトランザクションに署名し、アカウント内の資産を制御できます。コントラクトアカウントはアカウント自体のコードによって制御され、他のアカウントはコントラクトアカウントのコードを呼び出すことで、コントラクトアカウント特定のロジックを実行させることができます。

アカウントの抽象化

抽象化されたアカウントの概念は、2016年にさかのぼることができます(https://github.com/ethereum/EIPs/issues/86)。アカウントの抽象化は、イーサリアムの現在の2つのアカウントタイプ(EOAとコントラクトアカウント)に基づいて構築されています。これにより、次の方法でイーサリアムユーザーのインタラクティブなエクスペリエンスが向上します。

1. ユーザーは、Schnorr、BLS、ポスト量子署名などの複数の署名を使用できます。
2. ユーザーがERC20トークンまたはカスタム支払いロジックを使用してガス料金を支払うことを可能にします。
3. ユーザーが電子メールやソーシャルメディアなどを使用してアカウントを取得できるようにします。
4. ユーザーは、毎日の引き出し限度額を設定するなど、きめ細かな権限でアカウントの資金を管理できます。
5. 1つのアトミックトランザクションで複数のオンチェーン操作を実行できます。たとえば、ユーザーは 1 つの署名で DEX トランザクションの承認操作とスワップ操作を完了できます。

イーサリアムロードマップ

イーサリアムロードマップ(https://ethereum.org/en/roadmap/)は、イーサリアムの将来のアップグレードルートを強調しています。現在、イーサリアムコミュニティのほとんどの研究は、イーサリアムのロードマップを中心に展開しています。アカウントの抽象化は、このために不可欠な部分です。

出典: https://x.com/VitalikButerin/status/1741190491578810445

イーサリアムコミュニティは、ERC-4337に基づいて構築し、EIP-3074やEIP-7702などの提案を通じてプロトコル内にアカウントの抽象化ソリューションを実装し、最終的にエンドゲームのアカウントの抽象化に到達することを望んでいます。

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

EIP-3074 vs ERC-4337

化されたアカウントアカウントを理解するには、EOAがどのように機能するかを理解する必要があります。下の図は、チェーン上で最も一般的なトークンの売買プロセスです。

一般的に言えば、ユーザーは売買時に2つのトランザクションを発行する必要があります:最初にUniswapがスワップのためにUSDCを送金することを承認し、次にUniswapがアクションを実行するために別のトランザクションリクエストを送信します。 Uniswapは、ユーザーアカウントのUSDCを転送し、現在の価格に応じて対応する金額のETHをユーザーに送信します。

ERC-4337 は、上記の 2 つのトランザクションを 1 つのトランザクションにマージします。

上の図からわかるように、ユーザーは、ユーザーのEOAアカウントとは異なる4337アカウントでユーザーのアセットを操作することをバンドラーに承認するために2回署名する必要があります。バンドラーは、承認を取得した後、許可されたコンテンツをバンドルにマージし、発行してトランザクションを完了します。同時に、ユーザーがガス料金用のイーサリアムトークンを持っていない場合、ペイマスターの役割も導入でき、ペイマスターはガス料金を支払い、ユーザーから同額のERC20トークンを取得できます。

EIP-3074とERC-4337にはいくつかの類似点がありますが、EIP-3074の実装方法はイーサリアムのプロトコルにあります。

ERC-4337では、Bundlerが署名を通じてオンチェーンスマートコントラクトウォレット内の資産を処理することを許可します。EIP-3074では、バンドラーは署名を介してEOAウォレット内の資産を直接処理することが許可されています。これを行うには注文、イーサリアムコミュニティは AUTH と AUTHCALL という 2 つの新しいオペコードをイーサリアム プロトコルに追加する必要があります。

AUTHは、ユーザーのEOAアカウント資産を処理するバンドラーの動作が承認されているかどうかを確認するために使用され、AUTHCALLは、ユーザーインタラクションのスマートコントラクト(この例では、USDCとUniswap)を「だます」ために使用され、スマートコントラクトにトランザクションがユーザーのEOAアカウントからのものであると思わせます。これの利点は、UniswapとUSDCのメンテナーがデプロイされたスマートコントラクトをアップグレードする必要がなく、同時にEOAアカウントがアカウントの抽象化機能を享受できることです。

EIP-3074とERC-4337の比較

イーサリアムコミュニティでは、EIPは一般的にイーサリアムアップグレードをサポートする必要がある提案を指し、ERCはイーサリアムアップグレードなしでサポートできる仕様を指します。

したがって、2つのアカウントの抽象化スキームの命名から、ERC-4337はイーサリアムネットワークのハードフォークを必要としないため、ERC-4337はEIP-3074よりも実装が容易であることがわかります。これは、ERC-4337が発売され、ポリゴンとベースで使用されることが増えている理由の1つでもありますが、EIP-3074は、第183回イーサリアムオールコア開発者実行呼び出し(ACDE)で受け入れられたばかりです。

出典: https://dune.com/niftytable/account-abstraction

さらに、ERC-4337では、ユーザーが現在のアカウントを新しい契約アカウントに移行する必要があり、EIP-1271が機能するにはDApps サポートが必要です。EIP-3074 では、これらの追加サポートは必要ありません。これがERC-4337の採用率が低い主な理由です。同時に、ERC-4337 は、中間マルチコール コントラクトを導入しない限り、複数のオンチェーン操作を承認するための 1 つの署名サポートことはできませんが、EIP-3074 は可能であり、これも ERC-4337 の制限を引き起こします。

ただし、EIP-3074にも独自の問題があります。最も重要なのは、操作コード AUTH のアクセス許可が高すぎるため、攻撃者がユーザーの EOA アカウントを完全に制御できる可能性があることです。結局のところ、ハッカーがあなたのAUTH署名をだますのと同じくらいロング、彼はあなたのEOAウォレット内の資産を処分することができます。フィッシング攻撃が現在蔓延しており、そのほとんどがユーザーの署名を欺くことを考えると、EIP-3074が実装されると、これはより深刻な問題になります。

この点に関して、EIP-3074の作成者の1人であるlightclientは、ウォレットレベルで悪意のある署名を傍受する緩和方法を提案しています。詳細については、https://x.com/lightclients/status/1778823652584120497 を参照してください。ERC-4337 にはこの問題はありませんが、ハッカーはユーザーを騙して悪意のある UserOps に署名させることはできます。これは、UserOpがユーザーアカウント内のすべての資産に対する処分権限を取得するのが難しいためです。執筆時点では、ACDEの開発者は、Pectra Devent 0からEIP-3704を削除し、次のPectra Devnet 1にEIP-7702を含めることに同意しました。

EIP-7702 の変更点

EIP-7702は、EIP-3074とERC-4337の利点を統合して中間パスを形成しようとします。ユーザーは、署名された操作をバンドラーに送信します。バンドラーがトランザクションをチェーンに送信すると、ユーザーのEOAアカウントは一時的に4337アカウントのようなスマートコントラクトアカウントになります。次に、EIP-3074のAUTHの進行状況と同様に、スマートコントラクトアカウントはユーザーの承認されたバンドラー操作を検証します。次に、AUTHCALLと同様に、ユーザーが許可した操作を実行します。トランザクションの実行後、ユーザーアカウントは通常のEOAアカウントにロールバックされます。

EIP-7702 の利点は次のとおりです。

1. EIP-3074のすべての利点を継承します:ユーザーがEOAアカウントから新しいアドレスを持つスマートコントラクトアカウントに切り替える必要はありません。 1つのアトミックトランザクションで複数の操作を実行できます。
2. ERC-4337のスマートコントラクトアカウントコードとインフラストラクチャは再利用できます。
3. ERC-4337に代表されるスマートコントラクトアカウントの抽象化とEIP-3074に代表されるEOAアカウントの抽象化ソリューションをマージすることで、イーサリアムが2つの異なるアカウントの抽象化システムに分割されるのを防ぎ、イーサリアムロードマップでエンドゲーム抽象化アカウントへの道を開くことができます。
4. EVMイーサリアムイーサリアムロードマップアカウント、EOAアカウントは将来アカウントの抽象化に変換され、これら2つのオペコードは冗長になります。

それを超えて、EIP-7702はEIP-3074からすべてのセキュリティリスクを継承します。

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

ソラナのプログラム派生 アドレス

ソラナ ソラナアカウントの抽象化のアカウント抽象化

は、イーサリアムのERC-4337と似ています。これらは、元のアカウント(EOAアカウントと同様)から派生したアカウントであり、4337契約アカウントに似ています。ソラナのアカウントの抽象化を理解する前に、ソラナで使用されるアカウントモデルを理解する必要があります。

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

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

このアカウントモデルでは、プログラムアカウントが特定のアカウントを作成および管理できるネイティブなため、開発者はそれらを管理するためのカスタムルールとロジックを定義できます。このアカウントモデルによって可能になったデータアカウントの一種であるプログラム派生アドレス(PDA)は、マルチシグウォレットや2要素認証によるユーザーセキュリティの強化から、ソーシャルリカバリメカニズムの実現など、ソラナ上のアカウントの抽象化機能の可能性を拡張します。

プログラム派生アドレス

コンテキストとして、すべてのアカウントはEd25519曲線上にあり、公開鍵と秘密鍵のペアを持っています。PDAは、Ed25519曲線の外側にあり、決定論的に導出された32バイトの文字列で、公開鍵のように見え、対応する秘密鍵は付属していません。PDAを使用すると、開発者はカスタムルールとトランザクション署名メカニズムを作成して、PDAのプログラムアカウント所有者がPDAに代わって自律的にトランザクションを実行できるようにし、ソラナネットワークによって完全に認識およびサポートされます。

PDAとアカウントの抽象化

さて、PDAがどのように派生するかを理解したところで、これらの概念がアカウントの抽象化とどのように結びついているのか疑問に思われるかもしれません。アカウントの抽象化は、プログラム間呼び出し (消費者物価指数) と呼ばれる関数の実行を通じて内部で行われます。

CPI は、プログラムが別のプログラムの命令を呼び出せるようにする関数であり、ソラナ プログラムの構成可能性を可能にします。プログラムが invoke_signed を介して消費者物価指数を開始すると、プログラムは派生した PDA の代わりに署名できます。

出典:ソラナ

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

現在、SquadsはPDAに基づくアカウントの抽象化ソリューションをソラナ上で開発しています。ただし、Squadsが提供する製品は現在、Gnosis Safeのスマートコントラクトアカウントソリューションに似ており、アカウントの抽象化機能はまだ完全には開発されていません。

PDA

の利点
1. スマートコントラクトの自動実行:PDAは、プログラム間の呼び出しを通じて、ユーザーに代わって複数の操作を自律的に実行できる、より複雑なスマートコントラクトの設計を可能にします。
2. ユーザーエクスペリエンスの向上:ユーザーは複数のトランザクションを管理する必要がなく、技術的な複雑さにさらされる必要もありません。
3. セキュリティと柔軟性の強化:秘密鍵を使用しないため、鍵が侵害されるリスクが軽減されます。PDAは、マルチシグウォレットに使用したり、単一のリスクポイントを軽減する他の柔軟なガバナンスモデルに対応したりすることができ、大規模な共有リソースを管理する組織に特に役立ちます。

PDAの制限

事項
1. PDAは、アカウントの抽象化機能の基礎を築く上で有益ですが、キーペアアカウントと比較して実装が複雑になる可能性があります。
2. また、ERC-4337と同様に、ユーザーは新しいアカウントへのアカウント移行を行う必要があるため、ソラナ アカウントの抽象化の採用率が抑制される可能性があります。

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

アカウントの抽象化が開発者のマインドシェアをますます占めるようになる中、EIP-3074 や EIP-7702 と同様の承認グラントを使用して、アカウントが別のアカウントに代わって特定のアクションを実行できるようにするために、コア Cosmos SDK の一部である authz がリリースされました。

Authzには、ステーキングなどの特定のアクションの実行を被付与者に委任するいくつかの事前定義された承認タイプが付属しており、その結果、ユーザーエクスペリエンスが向上します。

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

1. GenericAuthorizationです。この承認グラントは、権限受領者が付与者に代わってメッセージを実行する無制限のアクセス許可を付与します。
2. SendAuthorization です。この承認は、ERC20の承認と同様に、付与者に代わって使用できる最大金額を定義するプラスの支出制限へのアクセスを被付与者に付与することを目的としています。
3. StakeAuthorization です。このグラントにより、被付与者は、デリゲート、デリゲート解除、再デリゲートなどのステーキングアクションを付与者に代わって管理できます。

許可は、付与者のアドレス・バイト、被付与者のアドレス・バイト、および認可タイプで構成されます。期間を定義して、特定の期間内のアクセス許可を制限することもできます。各ブロックの最後に、ネットワークはプルーニングと呼ばれるプロセスを通じて期限切れの許可を削除します。

運用フレームワークの理解

Authz は、さまざまなアクションの承認を与えるために使用できますが、簡単にするために、authz が一般的な投票トランザクションを有効にするためにどのように機能するかを調べます。

1. 承認が実行される前に、承認インターフェイスを実装します。このフェーズでは、メッセージの種類 (この場合は MsgVote) も定義されます。ここでは、ガバナンス投票アクションに対する Alice からの付与承認が表示されます。
2. Bob は未署名の投票トランザクションを生成します。
3. Bob は、被付与者からの投票の署名および実行トランザクションを生成します。トランザクションは完了し、有効期限が切れている場合は承認が削除されます。

authzがもたらす利点は?

1. 運用上のセキュリティ: バリデーターと他のユーザーは、ガバナンスの提案に投票したり、特定のアクションを実行したりするためのアクセス許可を別のアカウントに付与できるため、アカウントのセキュリティが強化され、セキュリティの負担が軽減されます。
2. 合理化された操作:トランザクションはバリデーターキーへのアクセスを必要として実行でき、マルチシグウォレットトランザクションは、単一のトランザクションを使用してAuthzを被付与者アカウントに付与することで合理化することもできます。
3. 移行の必要がない: EIP-3074 および EIP-7702 と同様に、承認操作はユーザーの元のアカウントで行われます。ユーザーは、アカウントの抽象化を有効にするために、元のアカウントから新しいアカウントにアセットを転送する必要はありません。
4. DAOの運用効率と柔軟性:特定のアクションに対して、実行権限のサブセットを個々のDAOメンバーに与えることができます。
5. ステーキング報酬複利:Authzは、ステーキング報酬の自動複利計算のためのリテーキングおよび同等のサービスの使用を容易にします。

Authzの制限とリスク:

Authzを介して承認するトランザクションの種類に注意してください。悪意のある承認は、ユーザーに害を及ぼす可能性のあるさまざまなタイプの承認を実行する可能性があります。

1. GenericAuthorization: 付与者に代わって、指定された Msg を実行するための無制限のアクセス許可を付与します。署名する内容を完全に認識していない限り、このような承認タイプに署名しないことを強くお勧めします。一部のウォレットでは、Authzトランザクションに署名するときに警告が表示されない場合もあります。
2. SendAuthorization: 被付与者が指定しない場合、被付与者が使用できるトークンの最大量を被付与者が送信できるようにします。また、被付与者がトークンを送信できる特定のアドレスを指定する AllowList を確認することも重要です。

Fee Grant Module

苛立たせているユーザーエクスペリエンスのもう一つのハードルは、ブロックチェーンユーザーがこれらの異なるエコシステムと対話する注文、さまざまなネイティブトークンを保持する必要があることです。これは、特にCosmosエコシステムに存在する無数のチェーンに最初にさらされた非暗号ネイティブの人々にとって、全体的なユーザーエクスペリエンスを損ないました。

しかし、このハードルは、Fee Grant Moduleの統合によって突破口を開きました。イーサリアムでアカウントの抽象化を可能にするペイマスターコントラクトと同様に、Cosmosの手数料付与モジュールを使用すると、付与者は被付与者に手数料の手当を付与し、取引手数料の一部または全部を支払うことができます。資金は助成金者の管理下にあり、助成金はいつでも取り消すことができます。

手数料助成金の種類

Fee Allowance は、BasicAllowance と PeriodicAllowance の 2 つのタイプに分類できます。

BasicAllowance を使用すると、被付与者は、使用制限または有効期限に達するまで、付与者アカウントからの料金を使用できます。その後、助成金は州から終了します。BasicAllowance は 1 回限りの料金の付与を実装していることに注意することが重要です。使用制限と時間が空の場合、手数料許容量に有効期限と支出の上限はありません。

PeriodicAllowance を使用すると、指定した期間ごとに料金付与を定期的に更新できます。Period_spend_limitは、期間内に使用できるコインの最大数を指定します。Period_reset次の期間がいつ発生するかを追跡し、period_can_spend新しい期間が始まる前に残っているコインの量を追跡します。

運用フレームワークの理解

AllowedMsgAllowance を使用すると、指定したメッセージの種類に対して許容量が作成されます。Allowance は、BasicAllowance または PeriodicAllowance のいずれかです。有効期限が設定されている場合、FeeAllowance は期限切れのプレフィックスが付与に付加された状態でキューに入れられ、Endblocker は FeeAllowanceQueue 状態で期限切れの付与をチェックし、見つかった場合はプルーニングします。MsgGrantAllowance とは別に、MsgRevokeAllowance を使用して手数料の許容量を取り消すこともできます。

まとめると、AuthzとFee Grantのモジュールは、革新的で多様なユースケースを解き放ち、最終的にCosmosエコシステムでより良いユーザーエクスペリエンスを構築します。

結論

勘定の抽象化 2024年5月27日時点の数値は推定値です。

スポットBTC ETFとETH ETFの承認により、機関投資家や個人投資家の需要が大幅に増加し、業界へのエクスポージャーを得ようとするユーザーの新しい波の到来を告げることが期待されています。今年は、プロトコルやDAppsがコミュニティを拡大するためのシームレスな体験を模索する中で、アカウントの抽象化が重要な物語となるでしょう。

免責事項

この資料は一般的な情報提供のみを目的としており、いかなる形式の研究成果、専門家のアドバイス、勧誘、オファー、推奨、または取引戦略を構成するものではなく、そのように解釈されるべきではありません。明示または黙示を問わず、このレポートで提供される一般的な金融および市場情報、分析、および/または意見の公平性、正確性、適時性、完全性、または正確性に関して、いかなる保証、表明、保証、または約束も行われず、そのような情報の使用または信頼に関してHashKey Capitalはいかなる責任も負いません。このレポートに関する情報は、予告なしに変更される場合があります。このレポートは、香港証券先物委員会、シンガポール金融管理局、または香港またはシンガポールの規制当局によってレビューされていません。

暗号通貨を含むデジタル資産はボラティリティが高く、市場リスクにさらされることに注意してください。デジタル資産の価値は大きく変動する可能性があり、利益や元本の保全を保証するものではありません。決定を下す前に、自分のリスク許容度と財務状況を慎重に検討する必要があります。

このレポートの配布は、特定の管轄区域で制限される場合があります。この資料は、そのような行為が許可されていない法域、またはそのようなレポートを配布することが違法である人物による情報の配布、または申し出または勧誘を行うことを構成するものではありません。

HashKey Capitalの最新ニュースをお届けします。

ウェブサイト — https://hashkey.capital/

ツイッター — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

免責事項:

1. この記事は [Medium] からの転載です。すべての著作権は原著作者に帰属します[HashKey Capital]。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。

2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。

3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。