アカウントの抽象化とネイティブのアカウントの抽象化

簡単に言うと、ERC-4337のアカウント抽象化は、ブロックチェーン上のオプションのインフラストラクチャです。 採用するかどうかを選択できます。 採用されると、マルチシグ、ERC-20トークンによるガス料金の支払い、ソーシャルリカバリーなど、コントラクトアカウント(CA)と同様の機能を提供します。 stackupのような多くのサービスプロバイダーが、このインフラストラクチャに取り組んでいます。 ただし、このインフラストラクチャは、次の理由により広く採用されていません。

• バンドラーの問題: バンドラーのみが検証に参加するため、バンドラーに過度に依存することになります。
• バンドラーの利益不足:これは主に規模が小さいため、ガス代を節約するためにアカウント抽象化インフラストラクチャを選択するためにより多くのDAppsが必要です。
• バンドラーの集中:バンドラーは少数のサプライヤー(Alchemy、Pimlico、Stackup)に集中しており、集中化のリスクがあります。
• リテンション率:エアドロップを除けば、アカウント抽象化サービスのユーザー リテンション率は 非常に低いです。

多くのレイヤー2ソリューションは、ガス料金を削減するために、アカウント抽象化をネイティブチェーンに直接展開します。 これは、ネイティブ アカウントの抽象化と呼ばれます。 しかし、このアプローチには、この機能を望まないユーザーがオプトアウトできない、クロスチェーン機能が制限されている、全体的な柔軟性に欠けるなど、他の問題もあります。

この記事では、EOA とCA の違い(簡単に言えば、MetamaskはEOA、コントラクトはCA)や バンドラー (Account Abstractionのエコシステムでは、ユーザーはUserOperationsをノードバリデーター/Mempoolに送信するのではなく、パッケージングとオンチェーン処理のためにバンドラーに送信します)などの用語について説明します。 詳細な説明については、上記の2つの記事へのリンクをクリックし、Gate Learnで以前に公開された記事を参照してください。

RIP-7560とは?

RIP-7560 は、アカウント抽象化の改善提案 (EIP-2938/ERC-4337) です。 新しいトランザクションタイプ「AA_TX_TYPE」の導入により、トランザクションの検証と実行の段階にバンドルマーチャント(ブロックビルダー/ノードバリデーター)以外の役割が組み込まれます。 パッケージングやオンチェーンの提出をバンドル加盟店だけに頼ることはなくなり、前述の集中化の問題に対処します。 さらに、RIP-7560は標準化された設計を提供し、将来の採用者のためにより高い適合性を確保します。 この記事では、RIP-7560 の提案によって改善された標準についてさらに詳しく説明し、提起された懸念に対処します。

最も根本的な変化

これはコンセンサス層プロトコルの変更です。
アカウント抽象化に関する最も初期の提案は、実際には2020年9月の EIP-2938で行われました。 最終的にコミュニティに受け入れられ、イーサリアムにデプロイされました。 最終的に2938ではなくERC-4337が採用された理由は、4337はコンセンサスレイヤーでの変更を必要としないため、コミュニティが比較的受け入れやすいためです。

ERC-4337とは異なり、RIP-7560の提案は、特にコンセンサス層プロトコルレベルでのより大きな変更を伴います(接頭辞RIPは、これがロールアップ技術を改善するための低レベルの提案であることを示しています)。 それに対応する利点は、L2ネイティブチェーンのインフラストラクチャに直接依存することを回避できることです。

新しいトランザクションタイプの導入 \
新しいトランザクションタイプが導入されました: 4 番目のトランザクションタイプは「AA_TX_TYPE」とも呼ばれます (実際には古い EIP-2938 で提案されていました)。 一般的なCAのすべての機能( Visaの記事で言及されているガス料金の支払いや定期的な自動支払い機能など)をサポートするだけでなく、ERC-4337とは異なり、既存のEOAがトランザクションを送信することもできます。 これは、この提案がより広範な採用を促進することを目的としていることを意味します。

トランザクション実行ロジック

この提案はERC-4337規格と互換性があり、より多くのGasを必要とする実行と検証を分離するトランザクションロジックを採用しています。 さらに、ドキュメントによると、トランザクションの実行はERC-4337と同じで、検証フェーズのすべてのステップを元に戻さずに完了する必要があります。 確認後、通話データがアカウントに送信され、実行されます。 実行後、Paymasterはトランザクション後のロジックを実行できます。 完全な実行プロセスを次の図に示します。

実行フローチャート(出典:RIP-7560のGitHubドキュメント)

本提案に関する主な懸念事項

著者は、Ethereum Magiciansフォーラムでの議論の中で、以下の懸念を提起しました。 RIP-7560: ネイティブアカウントの抽象化

インテントベースのアカウント抽象化サービスの開発は制限されますか?

インテントベースサービスの主なプレーヤーはUniswap V4とUniswapXと予想され、UniswapXはアカウント抽象化サービスの開発を計画しています。 さらに、ERC-7521でも同様の方向性が提案されています。 コミュニティの議論に応えて、この提案の著者の1人であるYoav Weissは、RIP-7560に加えて、ERC-7562と呼ばれるアカウント抽象化検証ルールもあると述べました。 インテント システム設計は、RIP-7560 とのみ互換性があり、検証ルールとは互換性がありません。 次に、別のインテントソルバーネットワークを使用して、インテント設計と競合することなくRIP-7560の利点を享受できます。

不可逆性のリスク

コミュニティの中には、この提案が「オペレーティングシステムをベアメタルに埋め込もうとしている」ようなもので、重大なリスクをもたらすのではないかと疑問を呈する人もいます。 これに対して、Yoav Weiss氏は次のように答えた。 この提案は、オペレーティングシステム(ERC-4337など)をベアメタルに埋め込むことを選択したチェーン、つまりネイティブアカウントの抽象化を展開することを選択したL2チェーンのためのものです。 イーサリアムのエコシステムには十分な選択肢があり、ユーザーはネイティブアカウントの抽象化を導入していない他のL2チェーンを選ぶことができます。

複雑さとコストに関する考慮事項

提案の複雑さとそれに伴う高コストに関する懸念について、執筆者の一人であるDror Tiroshは、これはアカウントの抽象化自体に内在するものだと答えた。 アカウントの抽象化は、汎用EVMコードを使用して外部データを検証するという事実に起因します。 この複雑さを排除すると、ブロックプロデューサーがDoS攻撃にさらされたり、一般的なEVMコードの使用を削除する必要が生じたりして、アカウント抽象化技術を開発する目的が損なわれます。

結論

現在、少なくともStackupの創設者など、アカウント抽象化インフラストラクチャのプロバイダーは、コンセンサスレイヤーでのこのような変更を歓迎しており、現在のアカウント抽象化サービスの中核的な問題がまだ蔓延していることを示しています。 ガス代を削減し、ユーザーフレンドリーなCAのような機能を導入するためにこのソリューションを採用する十分なdAppsがなければ、バンドルプロバイダーは利益を得られず、ユーザー維持率は決して上昇しません。 しかし、この提案に基づいて開発されたサービスが、既存のEOAをオンチェーンでシームレスにサポートし、アカウントの抽象化をネイティブにサポートすることができれば、最終的な目標(大量採用、Metamaskによるアカウント抽象化のサポートなど)に近づき、DAppsと対話する際のユーザーエクスペリエンスは徐々に向上するでしょう。