アカウントの抽象化は安全ですか? リスクを軽減するためのガイド

初級編12/12/2023, 4:51:36 PM
本稿では、Account Abstraction(AA)の概念的特徴とユースケースを分析し、ERC-4337を例にその実践を説明し、潜在的なリスクと対策について説明します。

アカウント抽象化以前は、イーサリアムには外部所有アカウント(EOA)とスマートコントラクトの2種類のアカウントがありました。 EOAは、秘密鍵を持つ一般的なユーザーアカウントです。 これは、トランザクションを開始できる唯一のタイプのアカウントでもあります。 たとえば、ユーザーがトランザクションを送信するにはETHが必要です。 バッチ処理されたトランザクションの作成は困難であり、ユーザーが秘密キーを紛失した場合の回復オプションはありません。 アカウント抽象化 (AA) は、これらの問題を解決するために作成されました。 しかし、それはリスクのないソリューションなのでしょうか? このガイドでは、AAの基本について説明し、そのリスクとその軽減方法について詳しく説明します。

このガイドの内容:

  • 勘定科目の抽象化の主な特徴は何ですか?
  • 勘定科目の抽象化のユースケース
  • 勘定科目の抽象化の実装
  • アカウントの抽象化リスクと報酬?
  • よくある質問

勘定科目の抽象化の主な特徴は何ですか?

アカウントの抽象化は、 スマートコントラクト がそれ自体でトランザクションを初期化できるようにする技術です。 これにより、ユーザーはスマートコントラクトで表されるアカウントを作成できます。 また、このテクノロジーにより、ユーザーとチェーンとのやり取りを改善するいくつかの機能も可能になります。

  • ユーザーは トークンでガス料金 を支払うことができます
  • アプリケーションは、ユーザーのトランザクションのガスを後援できます
  • アカウントを保護するための柔軟なメカニズムがあります
  • ブリッジとクロスチェーンdexは、ネイティブ通貨がなくても機能します。

勘定科目の抽象化のユースケース

  • 無料取引: プロジェクトはユーザーの取引手数料を支払うことができます。
  • 非ネイティブのクロスチェーン取引:ERC20トークンを別のチェーンにブリッジし、取引のためにそれを支払うことができるため、ネイティブ通貨でアカウントに追加で資金を供給する必要はありません。
  • 追加の ウォレットセキュリティ機能: セキュリティ リスクが発生した場合、アカウントに対するすべての操作を一時停止し、バックアップキーを使用してアクセスを復元できます。
  • アカウントの回復: たとえば、一連のキーを使用してキーを回復できます。
  • 取引限度額:毎月特定の金額のETHを使用できるアカウントを作成できます。
  • サブスクリプション: 従来のクレジット カードと同じ方法でサブスクリプションを有効にします。

勘定科目の抽象化の実装

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 つの信頼できるブロックチェーン セキュリティ会社によって監査されるようにします。

paymastersのサードパーティコード

ユーザーまたはプロジェクトがペイマスターを使用する場合、トランザクションの支払いはサードパーティに依存しています。 ペイマスターの実装にエラーがある可能性があり、悪意のあるペイマスターがユーザーの資金を盗む可能性があります。

選択したペイマスターサービスは、ペイマスターをだまして取引の支払いをさせる方法を見つけることができる悪意のあるユーザーにも苦しむ可能性があることに注意する必要があります。

緩和策: ウォレットは信頼できるプロバイダーのペイマスターのみを使用し、ペイマスターのコードを使用する前に監査されていることを確認します。

おすすめの方法

イーサリアムブロックチェーンでのアカウントの抽象化は、比較的新しい概念です。 そのため、その利用に関するベストプラクティスと開発者のフレームワークはまだ確立の過程にあります。 開発者が学ぶべきアカウントの抽象化を使用する例はほとんどありません。

軽減策: ベストプラクティスは、標準の普及に続いて最終的に開発されます。 開発者にとって、特に導入の初期段階では、新しいテクノロジを使用した経験を共有することが重要です。

規格のドラフトモード

ERC-4337はまだドラフトモードですが、コントラクトはすでにメインネットにデプロイされています。 規格が変わる可能性はあります。 なお、この変更は細部に影響し、すでに展開されているスマートコントラクトには影響しないことに留意してください。

軽減策: 開発者は、標準がどのように開発されるかに注意を払い、標準の変更が発生した場合は、それに応じてプロジェクトのコードを更新する必要があります。

一元化

ERC-4337は、少なくとも初期段階では、誰もがバンドラーを開始できるように設計されていますが、バンドラーの本番環境に対応した実装がほとんどないため、アカウント抽象化エコシステムはかなり中央集権化されています。

軽減策: Bundler実装のエラーがアカウント抽象化ネットワークに影響を与えるリスクを回避するには、少なくとも2つのBundler実装を使用する必要があります。 現在、多くの Bundler 実装が開発中であり、間もなくその多くが本番環境に実装される予定です。

アカウントの抽象化リスクと報酬?

アカウントの抽象化は、イーサリアムの採用を促進する可能性のある優れた技術です。 同時に、これはブロックチェーンをより安全にするための開発の1つです。 それでも、初期段階のブロックチェーン技術に新しく追加されたものと同様に、ユーザーは特に警戒する必要があります。 AAのレビューと調査は、このテクノロジーを採用することをいとわないすべての人にとって最良の選択です。

免責事項:

  1. この記事は[Beincrypto]からの転載です。 すべての著作権は原作者[Gleb Zykov]に帰属します。 この転載に異議がある場合は、Gate Learnチームに連絡していただければ、迅速に対応いたします。
  2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
  3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。

アカウントの抽象化は安全ですか? リスクを軽減するためのガイド

初級編12/12/2023, 4:51:36 PM
本稿では、Account Abstraction(AA)の概念的特徴とユースケースを分析し、ERC-4337を例にその実践を説明し、潜在的なリスクと対策について説明します。

アカウント抽象化以前は、イーサリアムには外部所有アカウント(EOA)とスマートコントラクトの2種類のアカウントがありました。 EOAは、秘密鍵を持つ一般的なユーザーアカウントです。 これは、トランザクションを開始できる唯一のタイプのアカウントでもあります。 たとえば、ユーザーがトランザクションを送信するにはETHが必要です。 バッチ処理されたトランザクションの作成は困難であり、ユーザーが秘密キーを紛失した場合の回復オプションはありません。 アカウント抽象化 (AA) は、これらの問題を解決するために作成されました。 しかし、それはリスクのないソリューションなのでしょうか? このガイドでは、AAの基本について説明し、そのリスクとその軽減方法について詳しく説明します。

このガイドの内容:

  • 勘定科目の抽象化の主な特徴は何ですか?
  • 勘定科目の抽象化のユースケース
  • 勘定科目の抽象化の実装
  • アカウントの抽象化リスクと報酬?
  • よくある質問

勘定科目の抽象化の主な特徴は何ですか?

アカウントの抽象化は、 スマートコントラクト がそれ自体でトランザクションを初期化できるようにする技術です。 これにより、ユーザーはスマートコントラクトで表されるアカウントを作成できます。 また、このテクノロジーにより、ユーザーとチェーンとのやり取りを改善するいくつかの機能も可能になります。

  • ユーザーは トークンでガス料金 を支払うことができます
  • アプリケーションは、ユーザーのトランザクションのガスを後援できます
  • アカウントを保護するための柔軟なメカニズムがあります
  • ブリッジとクロスチェーンdexは、ネイティブ通貨がなくても機能します。

勘定科目の抽象化のユースケース

  • 無料取引: プロジェクトはユーザーの取引手数料を支払うことができます。
  • 非ネイティブのクロスチェーン取引:ERC20トークンを別のチェーンにブリッジし、取引のためにそれを支払うことができるため、ネイティブ通貨でアカウントに追加で資金を供給する必要はありません。
  • 追加の ウォレットセキュリティ機能: セキュリティ リスクが発生した場合、アカウントに対するすべての操作を一時停止し、バックアップキーを使用してアクセスを復元できます。
  • アカウントの回復: たとえば、一連のキーを使用してキーを回復できます。
  • 取引限度額:毎月特定の金額のETHを使用できるアカウントを作成できます。
  • サブスクリプション: 従来のクレジット カードと同じ方法でサブスクリプションを有効にします。

勘定科目の抽象化の実装

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 つの信頼できるブロックチェーン セキュリティ会社によって監査されるようにします。

paymastersのサードパーティコード

ユーザーまたはプロジェクトがペイマスターを使用する場合、トランザクションの支払いはサードパーティに依存しています。 ペイマスターの実装にエラーがある可能性があり、悪意のあるペイマスターがユーザーの資金を盗む可能性があります。

選択したペイマスターサービスは、ペイマスターをだまして取引の支払いをさせる方法を見つけることができる悪意のあるユーザーにも苦しむ可能性があることに注意する必要があります。

緩和策: ウォレットは信頼できるプロバイダーのペイマスターのみを使用し、ペイマスターのコードを使用する前に監査されていることを確認します。

おすすめの方法

イーサリアムブロックチェーンでのアカウントの抽象化は、比較的新しい概念です。 そのため、その利用に関するベストプラクティスと開発者のフレームワークはまだ確立の過程にあります。 開発者が学ぶべきアカウントの抽象化を使用する例はほとんどありません。

軽減策: ベストプラクティスは、標準の普及に続いて最終的に開発されます。 開発者にとって、特に導入の初期段階では、新しいテクノロジを使用した経験を共有することが重要です。

規格のドラフトモード

ERC-4337はまだドラフトモードですが、コントラクトはすでにメインネットにデプロイされています。 規格が変わる可能性はあります。 なお、この変更は細部に影響し、すでに展開されているスマートコントラクトには影響しないことに留意してください。

軽減策: 開発者は、標準がどのように開発されるかに注意を払い、標準の変更が発生した場合は、それに応じてプロジェクトのコードを更新する必要があります。

一元化

ERC-4337は、少なくとも初期段階では、誰もがバンドラーを開始できるように設計されていますが、バンドラーの本番環境に対応した実装がほとんどないため、アカウント抽象化エコシステムはかなり中央集権化されています。

軽減策: Bundler実装のエラーがアカウント抽象化ネットワークに影響を与えるリスクを回避するには、少なくとも2つのBundler実装を使用する必要があります。 現在、多くの Bundler 実装が開発中であり、間もなくその多くが本番環境に実装される予定です。

アカウントの抽象化リスクと報酬?

アカウントの抽象化は、イーサリアムの採用を促進する可能性のある優れた技術です。 同時に、これはブロックチェーンをより安全にするための開発の1つです。 それでも、初期段階のブロックチェーン技術に新しく追加されたものと同様に、ユーザーは特に警戒する必要があります。 AAのレビューと調査は、このテクノロジーを採用することをいとわないすべての人にとって最良の選択です。

免責事項:

  1. この記事は[Beincrypto]からの転載です。 すべての著作権は原作者[Gleb Zykov]に帰属します。 この転載に異議がある場合は、Gate Learnチームに連絡していただければ、迅速に対応いたします。
  2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
  3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。
Comece agora
Registe-se e ganhe um cupão de
100 USD
!