アカウント抽象化以前は、イーサリアムには外部所有アカウント(EOA)とスマートコントラクトの2種類のアカウントがありました。 EOAは、秘密鍵を持つ一般的なユーザーアカウントです。 これは、トランザクションを開始できる唯一のタイプのアカウントでもあります。 たとえば、ユーザーがトランザクションを送信するにはETHが必要です。 バッチ処理されたトランザクションの作成は困難であり、ユーザーが秘密キーを紛失した場合の回復オプションはありません。 アカウント抽象化 (AA) は、これらの問題を解決するために作成されました。 しかし、それはリスクのないソリューションなのでしょうか? このガイドでは、AAの基本について説明し、そのリスクとその軽減方法について詳しく説明します。
アカウントの抽象化は、 スマートコントラクト がそれ自体でトランザクションを初期化できるようにする技術です。 これにより、ユーザーはスマートコントラクトで表されるアカウントを作成できます。 また、このテクノロジーにより、ユーザーとチェーンとのやり取りを改善するいくつかの機能も可能になります。
AAをイーサリアムネットワークに実装する方法については、さまざまな提案がありました。 その中には、イーサリアムのプロトコルに大幅な変更が加えられ、実装が複雑になるものもあります。 最も顕著な実装はERC-4337で、コンセンサスレイヤーの変更を伴いません。 この標準では、トランザクション mempool をより高いレベルのスケールで複製します。 ERC-4337のスマートコントラクトは、2023年3月にイーサリアムネットワークにデプロイされました。
ERC-4337は、EOAの代わりにウォレットという名前のスマートコントラクトを使用します。 このスマートコントラクトウォレットは、秘密鍵だけでなく、コントラクトにエンコードされた任意の複雑なメカニズムによって制御することができます。
トランザクションの代わりに、ユーザーはUserOperationsを送信します。 UserOperation には、実行命令、署名検証、およびその他のデータが含まれます。 トランザクションと同様に、ユーザーは Bundler のプレミアムを指定して、操作に優先順位を付けます。
マイナーまたはバンドラーは、操作をバンドルトランザクションにパッケージ化し、イーサリアムネットワークに含めます。
AA 実装: HashEx
他のデータの中でも、UserOperationにはスマートコントラクトウォレットを作成するためのコードが含まれています。 ユーザーがウォレットを持っていない場合は、ウォレットが作成されます。
ユーザーがERC20トークンでトランザクションの支払いをしたい場合、またはトランザクションの支払いをまったく望まない場合は、UserOperationでpaymasterコントラクトアドレスを指定します。 ペイマスターは、ERC20トークンと引き換えに取引の代金を支払うサードパーティのサービスです。
アカウントの抽象化はユーザーのセキュリティを向上させるために作成されますが、特に導入の初期段階では、いくつかのリスクがあります。 イーサリアムのエコシステムは、スマートコントラクトのバグで悪名高く、悪意のあるユーザーによって数十億ドルが盗まれています。 ここでは、AAのリスクと、その回避/軽減方法を紹介します。
他の新しいテクノロジーと同様に、アカウントの抽象化には、最初の実装にバグが含まれるリスクがあります。 ERC-4337のスマートコントラクトは、大手ブロックチェーンセキュリティ企業OpenZeppelinによって監査されました。
緩和策:解決策は、スマートコントラクトの正しさを証明するために数学的手法を使用するプロセスである形式検証を使用することです。 ERC4337契約の正式な検証プロセスは進行中ですが、まだ完了していません。
すべてのスマートコントラクトがアカウント抽象化ウォレットと互換性があるわけではありません。 例えば、tx.originフィールドを使用してトランザクションを送信したウォレットをチェックするスマートコントラクトは、予期しない値を取得します。 EOA署名を使用するスマートコントラクトには、AAウォレットでサポートされていないという非互換性もあります。
このような契約では、特定の重要な機能が正しく機能しない場合があります。 最悪の場合、ユーザーの資金がブロックされる可能性があります。
緩和策: リスクを軽減するために、アカウント抽象化ウォレットを使用するユーザーは、対話するプロトコルがテクノロジーをサポートしているかどうかを確認する必要があります。
この標準は、スマートコントラクトファクトリを介して最初のUserOperation内でスマートコントラクトウォレットを作成できるように設計されています。 ただし、ウォレットの実装スマートコントラクトにバグが含まれるリスクがあります。 主要なブロックチェーンセキュリティ企業によって徹底的に監査およびテストされたウォレットファクトリーのみを使用することが非常に重要です。
軽減策: 信頼できるサービスのみを使用してウォレットを作成し、ウォレットのコードが少なくとも 1 つの信頼できるブロックチェーン セキュリティ会社によって監査されるようにします。
ユーザーまたはプロジェクトがペイマスターを使用する場合、トランザクションの支払いはサードパーティに依存しています。 ペイマスターの実装にエラーがある可能性があり、悪意のあるペイマスターがユーザーの資金を盗む可能性があります。
選択したペイマスターサービスは、ペイマスターをだまして取引の支払いをさせる方法を見つけることができる悪意のあるユーザーにも苦しむ可能性があることに注意する必要があります。
緩和策: ウォレットは信頼できるプロバイダーのペイマスターのみを使用し、ペイマスターのコードを使用する前に監査されていることを確認します。
イーサリアムブロックチェーンでのアカウントの抽象化は、比較的新しい概念です。 そのため、その利用に関するベストプラクティスと開発者のフレームワークはまだ確立の過程にあります。 開発者が学ぶべきアカウントの抽象化を使用する例はほとんどありません。
軽減策: ベストプラクティスは、標準の普及に続いて最終的に開発されます。 開発者にとって、特に導入の初期段階では、新しいテクノロジを使用した経験を共有することが重要です。
ERC-4337はまだドラフトモードですが、コントラクトはすでにメインネットにデプロイされています。 規格が変わる可能性はあります。 なお、この変更は細部に影響し、すでに展開されているスマートコントラクトには影響しないことに留意してください。
軽減策: 開発者は、標準がどのように開発されるかに注意を払い、標準の変更が発生した場合は、それに応じてプロジェクトのコードを更新する必要があります。
ERC-4337は、少なくとも初期段階では、誰もがバンドラーを開始できるように設計されていますが、バンドラーの本番環境に対応した実装がほとんどないため、アカウント抽象化エコシステムはかなり中央集権化されています。
軽減策: Bundler実装のエラーがアカウント抽象化ネットワークに影響を与えるリスクを回避するには、少なくとも2つのBundler実装を使用する必要があります。 現在、多くの Bundler 実装が開発中であり、間もなくその多くが本番環境に実装される予定です。
アカウントの抽象化は、イーサリアムの採用を促進する可能性のある優れた技術です。 同時に、これはブロックチェーンをより安全にするための開発の1つです。 それでも、初期段階のブロックチェーン技術に新しく追加されたものと同様に、ユーザーは特に警戒する必要があります。 AAのレビューと調査は、このテクノロジーを採用することをいとわないすべての人にとって最良の選択です。
アカウント抽象化以前は、イーサリアムには外部所有アカウント(EOA)とスマートコントラクトの2種類のアカウントがありました。 EOAは、秘密鍵を持つ一般的なユーザーアカウントです。 これは、トランザクションを開始できる唯一のタイプのアカウントでもあります。 たとえば、ユーザーがトランザクションを送信するにはETHが必要です。 バッチ処理されたトランザクションの作成は困難であり、ユーザーが秘密キーを紛失した場合の回復オプションはありません。 アカウント抽象化 (AA) は、これらの問題を解決するために作成されました。 しかし、それはリスクのないソリューションなのでしょうか? このガイドでは、AAの基本について説明し、そのリスクとその軽減方法について詳しく説明します。
アカウントの抽象化は、 スマートコントラクト がそれ自体でトランザクションを初期化できるようにする技術です。 これにより、ユーザーはスマートコントラクトで表されるアカウントを作成できます。 また、このテクノロジーにより、ユーザーとチェーンとのやり取りを改善するいくつかの機能も可能になります。
AAをイーサリアムネットワークに実装する方法については、さまざまな提案がありました。 その中には、イーサリアムのプロトコルに大幅な変更が加えられ、実装が複雑になるものもあります。 最も顕著な実装はERC-4337で、コンセンサスレイヤーの変更を伴いません。 この標準では、トランザクション mempool をより高いレベルのスケールで複製します。 ERC-4337のスマートコントラクトは、2023年3月にイーサリアムネットワークにデプロイされました。
ERC-4337は、EOAの代わりにウォレットという名前のスマートコントラクトを使用します。 このスマートコントラクトウォレットは、秘密鍵だけでなく、コントラクトにエンコードされた任意の複雑なメカニズムによって制御することができます。
トランザクションの代わりに、ユーザーはUserOperationsを送信します。 UserOperation には、実行命令、署名検証、およびその他のデータが含まれます。 トランザクションと同様に、ユーザーは Bundler のプレミアムを指定して、操作に優先順位を付けます。
マイナーまたはバンドラーは、操作をバンドルトランザクションにパッケージ化し、イーサリアムネットワークに含めます。
AA 実装: HashEx
他のデータの中でも、UserOperationにはスマートコントラクトウォレットを作成するためのコードが含まれています。 ユーザーがウォレットを持っていない場合は、ウォレットが作成されます。
ユーザーがERC20トークンでトランザクションの支払いをしたい場合、またはトランザクションの支払いをまったく望まない場合は、UserOperationでpaymasterコントラクトアドレスを指定します。 ペイマスターは、ERC20トークンと引き換えに取引の代金を支払うサードパーティのサービスです。
アカウントの抽象化はユーザーのセキュリティを向上させるために作成されますが、特に導入の初期段階では、いくつかのリスクがあります。 イーサリアムのエコシステムは、スマートコントラクトのバグで悪名高く、悪意のあるユーザーによって数十億ドルが盗まれています。 ここでは、AAのリスクと、その回避/軽減方法を紹介します。
他の新しいテクノロジーと同様に、アカウントの抽象化には、最初の実装にバグが含まれるリスクがあります。 ERC-4337のスマートコントラクトは、大手ブロックチェーンセキュリティ企業OpenZeppelinによって監査されました。
緩和策:解決策は、スマートコントラクトの正しさを証明するために数学的手法を使用するプロセスである形式検証を使用することです。 ERC4337契約の正式な検証プロセスは進行中ですが、まだ完了していません。
すべてのスマートコントラクトがアカウント抽象化ウォレットと互換性があるわけではありません。 例えば、tx.originフィールドを使用してトランザクションを送信したウォレットをチェックするスマートコントラクトは、予期しない値を取得します。 EOA署名を使用するスマートコントラクトには、AAウォレットでサポートされていないという非互換性もあります。
このような契約では、特定の重要な機能が正しく機能しない場合があります。 最悪の場合、ユーザーの資金がブロックされる可能性があります。
緩和策: リスクを軽減するために、アカウント抽象化ウォレットを使用するユーザーは、対話するプロトコルがテクノロジーをサポートしているかどうかを確認する必要があります。
この標準は、スマートコントラクトファクトリを介して最初のUserOperation内でスマートコントラクトウォレットを作成できるように設計されています。 ただし、ウォレットの実装スマートコントラクトにバグが含まれるリスクがあります。 主要なブロックチェーンセキュリティ企業によって徹底的に監査およびテストされたウォレットファクトリーのみを使用することが非常に重要です。
軽減策: 信頼できるサービスのみを使用してウォレットを作成し、ウォレットのコードが少なくとも 1 つの信頼できるブロックチェーン セキュリティ会社によって監査されるようにします。
ユーザーまたはプロジェクトがペイマスターを使用する場合、トランザクションの支払いはサードパーティに依存しています。 ペイマスターの実装にエラーがある可能性があり、悪意のあるペイマスターがユーザーの資金を盗む可能性があります。
選択したペイマスターサービスは、ペイマスターをだまして取引の支払いをさせる方法を見つけることができる悪意のあるユーザーにも苦しむ可能性があることに注意する必要があります。
緩和策: ウォレットは信頼できるプロバイダーのペイマスターのみを使用し、ペイマスターのコードを使用する前に監査されていることを確認します。
イーサリアムブロックチェーンでのアカウントの抽象化は、比較的新しい概念です。 そのため、その利用に関するベストプラクティスと開発者のフレームワークはまだ確立の過程にあります。 開発者が学ぶべきアカウントの抽象化を使用する例はほとんどありません。
軽減策: ベストプラクティスは、標準の普及に続いて最終的に開発されます。 開発者にとって、特に導入の初期段階では、新しいテクノロジを使用した経験を共有することが重要です。
ERC-4337はまだドラフトモードですが、コントラクトはすでにメインネットにデプロイされています。 規格が変わる可能性はあります。 なお、この変更は細部に影響し、すでに展開されているスマートコントラクトには影響しないことに留意してください。
軽減策: 開発者は、標準がどのように開発されるかに注意を払い、標準の変更が発生した場合は、それに応じてプロジェクトのコードを更新する必要があります。
ERC-4337は、少なくとも初期段階では、誰もがバンドラーを開始できるように設計されていますが、バンドラーの本番環境に対応した実装がほとんどないため、アカウント抽象化エコシステムはかなり中央集権化されています。
軽減策: Bundler実装のエラーがアカウント抽象化ネットワークに影響を与えるリスクを回避するには、少なくとも2つのBundler実装を使用する必要があります。 現在、多くの Bundler 実装が開発中であり、間もなくその多くが本番環境に実装される予定です。
アカウントの抽象化は、イーサリアムの採用を促進する可能性のある優れた技術です。 同時に、これはブロックチェーンをより安全にするための開発の1つです。 それでも、初期段階のブロックチェーン技術に新しく追加されたものと同様に、ユーザーは特に警戒する必要があります。 AAのレビューと調査は、このテクノロジーを採用することをいとわないすべての人にとって最良の選択です。