アカウントを抽象化してインフラストラクチャを強化し、何十億ものユーザーにサービスを提供するにはどうすればよいでしょうか?

著者: Albert He、BlockPI 首席科学者

オリジナル編集: MarsBit、MK

強気市場であろうと弱気市場であろうと、イーサリアムエコシステムは継続的に構築され、自己最適化されてきました。その中でも、アカウント抽象化 (AA) は近年非常に重要な進歩となっており、アプリケーション、インフラストラクチャ、ユーザー、開発者など、イーサリアム エコシステムのさまざまなコンポーネントに浸透しています。

AA の広範な採用により、ブロックチェーンのユースケースへの参入障壁が低くなり、それによって Web2 のユーザー エクスペリエンスが Web3 業界にもたらされると予測できます。

数十億規模の AA 市場を形成する可能性を受け入れるために、BlockPI は AA を自社のインフラストラクチャ サービスに統合するためにリソースを投入する予定です。 AA の統合を構築することで、AA ユーザーがブロックチェーン上の契約ウォレット アカウントとやり取りするためのより便利で効率的な方法を提供すると同時に、BlockPI を業界リーダーとして位置づけることを目指しています。

この投稿では、AA についての理解を深め、インフラストラクチャ サービス プロバイダーの観点から考えを共有します。

EOA とスマート コントラクト ウォレット

AA の概念は、EOA アカウントの制限に由来しています。 EOA アカウント (外部所有アカウント) は、公開キー (ブロックチェーン アドレス) で表され、秘密キーを介してアクセスできるイーサリアムの典型的なユーザー アカウントです。これはイーサリアム エコシステムの主要コンポーネントであり、ユーザーがスマート コントラクトと対話し、ネットワーク上でトランザクションを実行できるようにします。ただし、EOA の使用は人々にとって困難な場合があり、いくつかの不便さがユーザー エクスペリエンスに影響を与える可能性があります。

EOA の最初の不便な点は、ガスの使用に関連しています。各トランザクションでは、ユーザーにガス手数料として多額の ETH がかかります (ガス価格に対して 25 グウェイの単純な ETH 送金手数料は 0.5 米ドルで、契約のやり取りやガス価格が高い場合はさらに多くなります)。このため、特にネットワーク輻輳のピーク時に、小規模取引の取引手数料が非常に高価になります。さらに、Gas の支払いには ETH のみを使用できるため、ユーザーはウォレットに ETH を入れておく必要があり、これが多くのユーザーにとって参入の大きな障壁となっています。

EOA の 2 番目の不都合は、他のスマート コントラクトを使用して何らかのロジックが実装されない限り、条件付きトランザクションを実行できないことです。たとえば、ユーザーが時間指定の定期転送を設定したい場合、この機能を実現するには、この機能を使用して ETH をサードパーティのスマート コントラクトに転送する必要があります。

EOA の 3 番目の不都合は、署名暗号化アルゴリズムです。イーサリアム ネットワークは、secp 256 k 1 と呼ばれる特定のデジタル署名アルゴリズムを使用して、トランザクションの信頼性とセキュリティを保証します。これはシステムにハードコードされており、ユーザーは別のアルゴリズムの使用を選択できません。

したがって、人々はこれらの問題から出発して、解決策を見つけようと試み始めました。 MetaMask や Argent などのスマート コントラクト ウォレットはこれらの取り組みの成果であり、イーサリアム スマート コントラクトを使用してユーザー アカウントの機能を強化することで EOA の制限の多くに対処しています。ただし、このようなソリューションには依然としていくつかの欠点があり、主にユーザーは取引のためにガス料金を支払う必要があることと、スマートコントラクトウォレットの人気が挙げられます。

これらの課題に基づいて、イーサリアムはアカウントの抽象化という新しい概念を導入する試みを開始しました。アカウント抽象化の目標は、スマート コントラクトや他のミドルウェアに依存するのではなく、プロトコル レベルでこれらの問題を解決することです。これは現在アカウント抽象化 (AA) と呼ばれるものです。

この投稿の残りの部分では、アカウント抽象化の概念と、それを使用して BlockPI のインフラストラクチャを最適化する方法について詳しく説明します。

EOA の上記 3 つの不都合に加えて、公開鍵と秘密鍵の結合関係にも問題があります。秘密キーは EOA にアクセスする唯一の方法であり、紛失した場合、秘密キーを回復する方法はありません。これは、秘密キーを紛失した場合、それに関連付けられているすべての資産を回復できなくなることを意味します。

さらに、EOA は、単一トランザクションで線形タスクを実行する場合にも制約に直面します。たとえば、ユーザーが 1 回のアクションでトークンの承認、交換、承認解除を希望する場合、3 つの個別のトランザクションを実行する必要があり、非効率的で時間がかかります。

良いニュースは、上記の問題はすべてスマート コントラクト ウォレットで解決できるということです。スマート コントラクト ウォレットは、AA を実装する特別なタイプのスマート コントラクトです。これは、イーサリアム ネットワーク上でユーザーのウォレットとして機能し、より適応的でパーソナライズされた資金管理方法を提供するように設計されています。イーサリアムスマートコントラクトのロジックが実現できれば、スマートコントラクトウォレットは必要な機能を提供できます。

具体的には、スマートコントラクトウォレットのトランザクションをオンチェーントランザクションにパッケージ化してガスコストを共有することができ、第三者が喜んで支払う場合にはガスコストがかからないこともあります。操作により、スマート コントラクト ウォレット内での連続タスクの実行が容易になります。スマート コントラクト ウォレットは、あらゆる署名暗号化アルゴリズムをサポートし、リカバリ コードなどを設定できます。

スマート コントラクト ウォレットの利点についての話題が多い中、イーサリアム コミュニティは実際に最初からコントラクト ウォレットに取り組んでいます。アカウントの抽象化を検討するために多くの EIP が提案されていますが、2021 年まで統一標準は確立されていません。以下に代表的な提案をいくつか紹介します。

EIP-86

元々はヴィタリック・ブテリンによって 2017 年に作成されました。 「抽象的な」署名検証および nonce チェック サービスに一連の変更を実装し、ユーザーが必要な署名/nonce チェックを実行する「アカウント コントラクト」を作成できるようにしました。

EIP-2938

2020年に作成されました。この EIP のタイトルは「アカウントの抽象化」です。この EIP は、AA の概念を詳しく説明します。新しいタイプのトランザクションである AA トランザクションが導入されます。このトランザクションは、EntryPoint アドレスによって初期化され、AA ウォレット コントラクトを呼び出します。これにより、統一された仕様が提供され、イーサリアムのコンセンサスに AA が導入されます。より具体的には、2 つの新しいオペコード、3 つのグローバル変数、および異なるペイロード構造がイーサリアム コンセンサスに追加されます。

EIP-3074

2020年に作成されました。この EIP では、AUTH と AUTHCALL という 2 つの EVM 命令が導入されています。 AUTH は、ECDSA 署名に基づいて、authorized と呼ばれるコンテキスト変数を設定します。 AUTHCALL は、承認されたアカウントに代わって呼び出しを送信します。これにより、スマート コントラクトが EOA に代わってトランザクションを送信できるようになります。しかし、これは AA に対する完璧な解決策ではありません。 EIP-3074 は、スポンサーシップ取引中のネイティブ価値の転送に一定の制限を設けます。 EOA にアクセスできなくなると資産を回復できなくなり、盗難された場合はすべての資産を新しいアカウントに移す必要があります。

上記のアイデアはいずれも、コンセンサス層での変更が必要である、または包括的ではないなどの大きな理由により、イーサリアム プロトコルに正式に採用されませんでした。したがって、イーサリアム コミュニティは、コンセンサスを変更せずに AA をイーサリアム プロトコルに導入する方法を模索し続け、最終的に EIP 4337 を作成しました。

ERC — 4337

EIP-4337 はもともと 2021 年 9 月に提案され、2023 年 3 月に ERC-4337 として認可されました。著者には、Vitalik Buterin、Yoav Weiss、Kristof Gazso、Namra Patel、Dror Tirosh、Shahaf Nacson、Tjaden Hess が含まれます。

EIP-4337 は、コアのイーサリアム プロトコルに変更を加えずに AA を導入する、革新的な提案です。 EIP-4337 は、ビルダーが独自のスマート コントラクト ウォレットを実装するために使用できる ERC-4337 標準をガイドしており、「バンドラー」や UserOperation メモリ プールなどの追加のインフラストラクチャが含まれています。これを行うことにより、基本的にトランザクション メモリプールの機能がより高度なシステムに複製されます。ユーザーはトランザクションを送信する代わりに、UserOperation オブジェクトを送信します。このオブジェクトは単一のトランザクションにパッケージ化して Ethereum チェーンに含めることができます。

以下は、公式ドキュメントからの ERC-4337 のより具体的な技術的な説明と、理解を深めるためのいくつかのコメントです。

ERC-4337 の定義と主要な役割

UserOperation — ユーザーに代わって送信されるトランザクションを記述する構造体。混乱を避けるため、「トランザクション」という名前は付けません。これはバンドラーに送信され、他の UserOperations とともにパッケージ化されます。その後、パッケージは単一のトランザクションとしてブロック作成者に送信されます。

送信者 — 新しい UserOperation を送信する契約アカウント。スマート コントラクト ウォレットは、ERC-4337 の IAccount インターフェイスを実装する必要があります。

EntryPoint — UserOperations パッケージを実装するシングルトン コントラクト。バンドラー/クライアントは、サポートされている EntryPoint をホワイトリストに登録します。この契約は Infinitim チームによって承認およびレビューされ、すべての UserOperations の処理と、Wallet Factory、Aggregator、Paymaster を含む他の契約の接続を担当します。ほとんどの EVM 互換チェーンで同じアドレスになります。

Bundler — メモリプールから複数の UserOperations をバンドルし、EntryPoint.handleOps() トランザクションを作成するノード (ブロック ビルダー)。プロトコル層のすべてのバリデーターがバンドラーである必要はありません。 Bundler サービスはブロック ビルダーとは独立して実行でき、RPC を使用してバンドルされた UserOperations を送信します。

アグリゲーター — 集約された署名を検証するためにアカウントによって信頼されるヘルパー コントラクト。バンドラー/クライアントのホワイトリストでサポートされているアグリゲーター。アグリゲータは、ERC-4337 IAggregator インターフェイスを実装する必要があります。

Paymaster — EntryPoint コントラクトに十分な ETH がデポジットされている場合に、UserOperation のガス料金を送信者に支払うことができるコントラクト。 Paymaster は効率的な Gas 抽象化を実装します。 Paymaster は、ERC-4337 の Paymaster インターフェイスを実装する必要があります。 Paymaster は、Sender と取引を行うための独自のロジックを持つことができます。たとえば、Sender は Paymaster に USDC を支払い、Paymaster は ETH で UserOperations をスポンサーします。実際、Paymaster が同意し、技術的に実現可能である限り、ERC 20 トークンや他のチェーン上のトークンもサポートできます。

Wallet Factory — ERC-4337 ユーザー向けのスマート コントラクト ウォレットを作成するために呼び出すことができるコントラクト。ウォレット ファクトリのデプロイは許可が必要ありません。オンチェーンコンポーネントとして、公的監査と透明性のある調査にさらされています。広く使用されているウォレット ファクトリーは、専門家によって完全に監査される必要があります。

以下の図は、EntryPoint コントラクトが他のアクターとどのように対話するかを説明しています。

バンドラーは、UserOperation を入力として受け取る EntryPoint コントラクトの handleOps 関数を呼び出します。

handleOps はチェーン上の UserOperation を検証し、指定されたスマート コントラクト ウォレット アドレスによって署名されているかどうか、および Bundler を補うのに十分な Gas がウォレットにあるかどうかを確認します。

検証が成功すると、handleOps は関数の署名と UserOperation の calldata で定義された入力パラメーターに従ってスマート コントラクト ウォレット関数を実行します。

一方、Bundler が EOA を使用して handleOps 関数をトリガーすると、Gas 料金が発生します。スマート コントラクト ウォレットは、自身のアカウント残高からバンドラーにガス料金を支払うことも、Paymaster コントラクトに代わって支払うよう要求することもできます。十分な Gas がない UserOperations は、ターゲットのスマート コントラクト ウォレットの検証プロセスに合格できないため、実行前に失敗します。十分なガスがある場合でも、実行時エラーなどにより、UserOperations が実行中に失敗する可能性があります。実行が成功したかどうかに関係なく、EntryPoint コントラクトは、handleOps 関数をトリガーするバンドラーにガス料金を支払います。

(出典: 公式ドキュメント:

ERC-4337 の発効後、ユーザーは 2 つの方法でブロックチェーン トランザクションを開始できるようになりました。 1 つは、EOA がトランザクションを開始するオリジナルの方法です。もう 1 つは、ERC-4337 標準を使用して Bundler を通じて UserOperation を開始し、その後 Bundler がそれを他の UserOperation とパッケージ化し、チェーン上で開始することです。次のフローチャートは、通常の EOA 送信トランザクションと ERC-4337 コントラクト ウォレット送信 UserOperation の違いを示しています。

道路は舗装されていますが、乗客は多くありません

ERC-4337 は、ユーザーと開発者が Ethereum プラットフォーム上で AA を使用および構築するための強力なフレームワークを提供します。この枠組みは重要な前進ですが、いくつかの課題と不確実性はまだ対処し、解決する必要があります。

AA の導入はまだ初期段階にあります。 Dune ERC-4337 分析パネル (@niftytable からの ERC-4337 アカウント抽象化) によると、チェーン上で実行されるのは 65,000 以上の UserOperations のみで、その 90% は Polygon からのものです。したがって、現時点で実行される UserOperations の数はまだ非常に少なく、そのほとんどは開発者テストであり、ユーザーに起因するものはほんの一部です。 AA を統合した製品はまだ初期段階にあることに注意してください。同時に、Bundler の利益がマイナス (MATIC 換算で -700) であることがわかります。これは、Polygon の一部のバンドラーが事前検証ガスを正しく計算しないためです。この検証アルゴリズムにはまだ最適化が必要です。

それ以外にも、対処する必要のある問題がいくつかあります。そのような問題の 1 つは、バンドラーがトランザクションの失敗をどのように処理するかです。 Bundler が複数の UserOperations をまとめた後、Bundler は最初にトランザクションをシミュレートしてロールバックされるかどうかを確認し、次に送信者または支払マスターから返されたガス料金がトランザクションによって支払われたガス料金より大きいかどうかを計算します。収益性がある場合、Bundler はこの UserOperations のバッチをトランザクションとしてまとめてブロック ビルダーに送信します。ただし、トランザクションは依然として失敗する可能性があり、その結果、バンドラーはガス料金を支払いますが、EntryPoint からガスの返還を受け取らないことになります。たとえば、ユーザーはアクションを別のバンドラーに送信する場合があります。バンドラーは、利益があり、シミュレーションが成功した場合、あらゆるオペレーションをオンチェーンに送信することに前向きです。これは、UserOperation が異なるバンドラーによって同時に送信された場合を意味します。成功するトランザクションは 1 つだけで、1 つのバンドラーだけが EntryPoint からガス料金を受け取り、他のすべてのバンドラーはオンチェーンの障害によりガスを失います。ユーザーはこれを行うべきではなく、そのような行為は悪意のある攻撃とみなされ、バンドラーが送信者アドレスを禁止し、このアドレスからの将来のリクエストを拒否する可能性があると主張する人もいますが、これは合理的なアプローチではありません。うっかり提出されてしまった。このような問題は、おそらく未完成のパブリック メモリ プール ネットワークを開発することによって、コード内で適切に対処する必要があります。さらに、トランザクションが正常に送信され、利益が得られるようにシミュレートされた場合でも、突然のガス変動により、バンドラーは損失に直面する可能性があります。

もう 1 つは、AA から抽出できる最大抽出可能値 (MEV) です。イーサリアムのコンテキストでは、MEV は一般に、マイナーまたは他のトランザクション処理者がブロック内のトランザクションの順序を操作するか、ブロック内に自身のトランザクションを含めることによって抽出できる値を指します。バンドラーは UserOperations を自由に注文できるため、MEV のロジックが AA にも適用できることに気づいた人はいますか?ただし、これは条件付きであり、バンドラーが MEV を抽出するには十分な UserOperations をバンドルする必要があります。現在、AA 市場全体がまだ初期段階にあるため、Bundler MEV も初期段階にあると考えられます。一般に、AA 業界は 2 つの方向に発展する可能性があります。1 つは、Flashbots、Ultra Sound、BloXroute などの参加者が参加するイーサリアムのメインネットに似ており、もう 1 つは公正な注文を強制するためにバンドラーのコンセンサスを形成することです。後者のアプローチは、AA における MEV の可能性を完全に排除します。

＃＃ 将来の開発

パブリックメモリプール

AA エコシステムはすでに機能していますが、やるべき開発作業はまだたくさんあります。 AA エコシステム全体を見ると、現時点で最大のギャップはパブリック メンプールです。 Skandha Bundler クライアントの開発者である Etherspot チームは現在、パブリック メモリプールを備えた p2p ネットワークを開発中です。パブリック mempool の p2p ネットワークは、今年 8 月に利用可能になる予定です。

パッキングアルゴリズム

その過程で、イーサリアム財団は、献身的で勤勉な開発者からなるいくつかの AA 開発チームに資金を提供してきました。現在までに、Bundler クライアントのいくつかのバージョンが開発され、現在利用可能です。それらの中には、製品の成熟度の点で高度に開発されたものもあります。それらは、Candide (Python で書かれた Voltaire Bundler)、Pimlico (Type で書かれた Alto Bundler)、Etherspot (Type で書かれた Skandha Bundler)、Stackup (Go で書かれた Stackup-Bundler) などです。

ここで、パッキング アルゴリズムをさらに詳しく見てみましょう。現在、UserOperations の数が少ないため、バンドラーは、固定の時間間隔や各バンドルの UserOperations の数など、シンプルで単純なパッケージ化ロジックを採用できます。ただし、UserOperation の数が増加するにつれて、特にパブリック メモリプールの導入後は、UserOperations の選択とパッケージ化の戦略がより複雑になります。理由は簡単です。ブロックチェーンのようなコンセンサスプロトコルがなければ、バンドラーは暗い森を形成し、それぞれが自分の利益に従って作業の優先順位を付け、互いに競争します。パブリック mempool に対応するプライベート mempool が最初に来る可能性が高くなります。 UserOperations をパブリック メモリプールからパッケージ化することが利益にならない場合、UserOperations をプライベート メモリプールにパッケージ化すると利益が得られる可能性があるためです。このように、Bundler はパッケージングに関して競争上の優位性を持っています。

さらに、パブリックメモリプールが徐々に受け入れられるにつれて、その中のUserOperationsは、異なるGas利益期待やオンチェーン実行の複雑さなど、異なる特性を持つようになります。バンドラーはオフチェーン シミュレーションを実行して、UserOperations のさまざまな組み合わせの収益性を評価し、独自のバンドル戦略を確立します。より多くの UserOperations をパックすると、より大きな利益が得られる可能性がありますが、検証失敗のリスクも増加します。たとえ検証に合格したとしても、チェーン上で実行が失敗するリスクは依然として存在します。あまりパッケージ化されていない UserOperations はその逆を行います。バンドラーは独自のトランザクション ガス パラメーターを設定する必要があります。これは、ブロック ビルダーがトランザクションを実行する優先順位に影響します。市場のガス価格やガスの変動状況が異なると、バンドラーは異なるパッケージング戦略を採用する可能性があります。同時に、これらの検証とポリシーの計算では、ローカルのハードウェア コンピューティング リソースとブロックチェーン ノード リソースを消費する必要があります。バンドラーはまた、ユーザーに良好なエクスペリエンスを提供し、UserOperation の送信後に過度の遅延に直面しないようにする必要もあります。

これらの課題に対する解決策は依然として不確実ですが、AA 業界の進化と開発者の努力の結集により、最終的には解決策が見つかると確信しています。 BlockPI は、インフラストラクチャ ビルダーとして、開発者として、または他の開発者にフレンドリーな AA インフラストラクチャを提供することで、AA 業界の発展における問題を解決したいと考えています。

インフラストラクチャは適応する必要がある

AA は、送信者、バンドラー、ガス支払者、契約ウォレット、署名者など、チェーン上のトランザクション動作におけるさまざまな役割を抽象化し、ユーザーがブロックチェーンを使用する際に高い自由度を得ることができます。また、AA 内のサービスは個別に展開できます。

AA の大規模な導入に適応するために、インフラストラクチャ プロバイダーはまず少なくとも 2 つの基本サービス、つまり Bundler サービスと Paymaster サービスを提供する必要があります。

Bundler サービスでは、優れたユーザー エクスペリエンスを確保するために、インフラストラクチャ プロバイダーが Bundler を使用してプライベート メモリプールを開発する必要がある場合があります。具体的には、インフラストラクチャ プロバイダーは、バンドラー サービスの堅牢性を確保するために、さまざまなバンドラー クライアントを統合する必要があります。これらの Bundler クライアントはさまざまなプログラミング言語で開発されていますが、いずれも ERC-4337 コア チームによって指定された JSON RPC メソッドの標準セットを提供します。現時点では利用できるメソッドはそれほど多くありませんが、将来的にはさらに多くのメソッドが追加される予定です。インフラストラクチャ サービス プロバイダーは、これらの API に対して継続的かつ完全なサポートを提供する必要があります。

また、バンドラー API とオリジン ノード クライアント RPC の間の関係を最適化して適応させることも重要です。現在のノード クライアントは、AA の応答性と適応性に関して十分に最適化されていないことがわかっています。特定の Bundler API メソッドが機能するには、AA のデータ インデックスが必要です。たとえば、ハッシュによって UserOperation を検索するには、すべての UserOperation のインデックスを作成する必要があります。そうしないと、この 1 つのリクエストによるハードウェアの消費量が非常に多くなり、リクエストが返されるまでに長い時間がかかります。

さらに、インフラストラクチャ プロバイダーは、顧客にガスを使わないユーザー エクスペリエンスを提供し、さまざまなサービス オプションを提供するために、さまざまな Paymaster サービスを統合する必要もあります。これには、サードパーティの Paymaster サービス プロバイダーとの良好なコミュニケーションと統合が必要ですが、同時に、市場の需要に応じて、既存の Paymaster サービスに基づいた、より便利な統合ソリューションを設計することもできます。集約署名、ウォレットファクトリーなどの他のサービスも、将来の開発と統合の方向性として考えられます。

現在、BlockPI は実際に上記の目標をすべて達成しようとしています。それだけでなく、私たちはコミュニティ内のほぼすべての Bundler クライアントおよび Paymaster サービス プロバイダーと通信しており、AA サービスを BlockPI Network に統合することを最優先事項にしています。また、ユーザーのニーズを理解するために、AA ウォレット開発者と綿密な議論を行っています。したがって、私たちは前進するにあたり、すべてのバンドラー、ペイマスター、ウォレットとの協力と交流を心から歓迎します。私たちの全体的な目標は、他の企業と協力して AA エコシステムを構築および発展させ、その成長と発展を私たちの能力の限り推進することです。私たちは協力することで、AA 業界全体に有意義な貢献をし、その継続的な発展をサポートしたいと考えています。結局のところ、私たちの究極の使命は、業界のパイオニアとなり、Web2 ユーザーが障壁なくブロックチェーン体験を楽しめるように AA エコシステムの開発を促進することだからです。

要約する

AAの観点から見ると、私たちは新たな歴史的瞬間にいます。大通りは舗装されていますが、まだライダーは多くありません。現時点では、AA の適用はまだ初期段階にあります。ERC-4337 は、ユーザーと開発者がイーサリアム プラットフォーム上で AA を使用および構築するための強力なフレームワークを提供します。しかし、解決すべき課題や不確実性はまだ多くあります。

AA のインフラストラクチャ プロバイダーは、ユーザーに Bundler サービスと Paymaster サービスを提供する必要があり、サービスの堅牢性を確保するためにさまざまな Bundler クライアントと Paymaster サービス プロバイダーを統合する必要があります。 API クライアントとノード クライアント間の応答性を最適化するには、AA データにインデックスを付けて、単一リクエストのハードウェア消費量を削減する必要がある場合があります。より良いユーザー エクスペリエンスを提供するために、インフラストラクチャ プロバイダーはユーザーにさらに多くのサービス オプションを提供する必要もあります。

将来、AA エコシステムが成長し続け、パブリック メンプールが出現するにつれて、UserOperations の選択とパッケージ化の戦略はより複雑になるでしょう。各バンドラーは、自身の利益に従って仕事に優先順位を付け、他のバンドラーと競争します。バンドラーは独自のトランザクション ガス パラメーターを設定する必要があります。これは、ブロック ビルダーがトランザクションを実行する優先順位に影響します。市場のガス価格やガスの変動状況が異なると、バンドラーは異なるパッケージング戦略を採用する可能性があります。

これらの課題に対する解決策は不確実ですが、AA 業界の進化と開発者の努力の結集により、最終的には解決策が見つかると確信しています。 BlockPI は、インフラストラクチャ構築者として、開発者として、または他の開発者にフレンドリーな AA インフラストラクチャを提供することによって、AA 業界の発展における問題解決者となることを望んでいます。私たちの使命は、Web2 ユーザーが障壁なくブロックチェーン体験を楽しめるように、AA エコシステムの開発を促進することです。