
プライマー
現在主流のイーサリアムウォレット(EOAウォレットを指す)はユーザーエクスペリエンスが非常に限られており、以下の便利な機能はスマートコントラクトウォレットを通じてのみ完了できます(一部のオフチェーン補助ソリューションは利便性を提供しますが、不必要な外部リスクを導入することになるため、はこの記事の範囲外です)。
秘密キーとニーモニックの経験なし、ソーシャル検索 (Argent、Unipass など)
バッチトランザクション (Gnosis Safe など)
純粋なオンチェーン ゲームでは、複数の署名 (セッション キー) は必要ありません。
幸いなことに、私たちはすでに一般的なスマート コントラクト標準に非常に近づいており、ユーザーはまもなく 100 倍優れたイーサリアム ウォレット エクスペリエンスを得ることができることになります。
解釈: スマート コントラクト ウォレット、アカウントの抽象化、および ERC-4337
スマート コントラクト ウォレットは、現在イーサリアムでサポートされている 2 つのウォレット形式のうちの 1 つで、もう 1 つは一般に一般的に使用されている EOA ウォレット (メタマスクなど) です。
名前が示すように、前述のすべての優れた価値はスマート コントラクトから恩恵を受けます。
スマート コントラクト アカウントはコードによって制御されます。コードを記述することで、あらゆるロジックを実現できます。
対照的に、EOA ウォレットは、ユーザーがトランザクションを発行できる秘密キーによって制御されるブロックチェーン上のアドレスです。
ただし、「秘密キーはアカウント」機能の制限も明らかです。ユーザーは、特定のアドレスに対して別のキーに署名することを承認できず、そのアドレスにカスタム ロジックを作成することもできません。
重要な追加事項: スマート コントラクト ウォレットは、EOA とまったく同じエクスペリエンス (署名キーが 1 つだけ、アップグレード不可など) を持つようにコンパイルできますが、その逆はできません。
アカウントの抽象化それは、イーサリアムアカウントシステムの不必要な詳細を省略することで複雑さを軽減し、効率を向上させることであり(EOAとスマートコントラクトウォレットの特別な処理の必要性を排除します)、最終的に前述の貴重な機能の基盤を提供します。 (コンピュータサイエンスにおける抽象化の説明[1]を参照)
ERC-4337 これは、アカウントの抽象的な有用性を実現するための設計の 1 つです。
これは、ブロックチェーンの基礎となるコアプロトコルを変更することなく実現されます。 (ERC-4337、近い将来に実行される予定です)
これは、ブロックチェーンの基礎となるコア プロトコルを変更することによって実装されます。 (EIP-3074、EVMでは中長期計画/Starkware/zksyncはほぼ完了)
フレームワークレベルの比較: EOA ウォレット、現在主流のスマート コントラクト ウォレット、ERC-4337 ウォレット
(技術的な詳細に興味がない場合は、「現在の主流のスマート コントラクト ウォレットと比較した ERC-4337 の利点」に直接スキップできます)
補助的な読書のヒント:
上の図では、分割線は各フレームをユーザー署名フェーズ、中継フェーズ (トランザクションがブロックにパッケージ化される前)、および最終実行フェーズ (トランザクションがブロックにパッケージ化された後) の 3 つの部分に分割しています。この分割により、より良い理解が得られることを願っています。
EOA
標準 ECDSA を使用してユーザーが秘密鍵で署名したトランザクションは、イーサリアム メンプールに送信され、そこでマイナーがトランザクションを次のブロックに詰め込みます。
現在のスマートコントラクトウォレット
EOA との最大の違い: ネットワークのセキュリティと UX の向上のため、現在主流のスマート コントラクト ウォレットは、最終的なスマート コントラクト ウォレットにユーザー情報を送信するためのリプレイヤを構築および運用する必要があります。
イーサリアムの現在主流のスマートコントラクトウォレット(Safe、Argent、Loopringなど)には共通の開発標準がないことを考慮すると、各プロジェクトは独自のリレーラーと関連料金モジュールを開発および維持し、導入されたスマートコントラクト機能を独立して監査する必要があります。
ERC-4337
現在主流のスマートコントラクトウォレットとの最大の違いは次のとおりです。
各プロジェクトが独自に開発したリレーラー モジュールを置き換える共通モジュール Useroperation Mempool & Bundler を構築します。
新しいウォレットを作成するユーザーエクスペリエンスを最適化するためにエントリーポイントスマートコントラクトを導入し、ユーザー操作やその他のプロセスの実現可能性を検証するためにスマートコントラクトウォレットを導入します。
具体的なプロセスは以下の通りで、トランザクションとは異なり、ユーザーが発行したUser OperationはUser Operation Mempoolに集められ、Bundlerは複数のUser Operationをパッケージ化して(ガス手数料を付加して)イーサリアムのトランザクションMempoolに送信します。ブロック。
上記のパッケージ化されたユーザー操作は、スマート コントラクト アカウントの初期展開やユーザーのユーザー操作オブジェクトの検証を含め、エントリー ポイント スマート コントラクトによって処理されます。
最終的に、ユーザーのユーザー操作は、ユーザーが選択したスマート コントラクト ウォレットによって処理されます。
現在主流のスマートコントラクトウォレットと比較したERC-4337の利点
各スマート コントラクト ウォレットは個別のリレーラーを動作させる必要はありません。
利便性の高いスマートコントラクト機能モジュールは汎用性があり、車輪の再発明のコストを大幅に節約します。
Bundler によってパッケージ化された後、トランザクションの固定コストが償却され、最終的にユーザーのトランザクション コストが削減されます。
スマートコントラクトウォレットの普及はどのくらい先でしょうか?
100% EVM チェーン
(https://hackmd.io/@erc4337 [2]) の素晴らしい助けに感謝します)
答えはすぐ上。コア契約は基本的に準備ができており、いくつかの優れたチームが本番レベルの ERC-4337 ネイティブ クライアント ウォレットをリリースしようとしています。
EVM エコシステム全体の共通標準である ERC-4337 を導入するには、いくつかの主要モジュールを開発する必要があります (上の赤い点で示されています)。
① 製品グレードの ERC-4337 ネイティブ クライアント ウォレット
ERC-4337 では署名スキームが指定されていませんが、MetaMask に依存して ERC-191 または ERC-712 で署名された dapps を UserOperation に使用することは、最適なユーザー エクスペリエンスではありません。市場では、クライアントのウォレットが、専用の標準署名スキームを通じてプロキシ ウォレット アドレスとその UserOperation トランザクションをネイティブにサポートする必要があります。
開発の進捗状況:
② UserOperation Block Builder Bundler
ERC-4337 ネットワークの主な動作モードでは、パブリック P2P メモリプールで UserOps をネイティブにサポートし、これらの UserOps を使用してバンドルとエントリ ポイント トランザクションを含むトランザクションはブロック内にあります。
開発の進捗状況:
③エントリーポイントスマートコントラクト
ERC-4337のコア部分。
開発の進捗状況:
④本番レベルERC-4337 ECDSAプロキシウォレットスマートコントラクト
ERC-4337 の主な動作モードは、各ユーザーがプロキシ ウォレットによって表される ID を取得することを前提としています。これは、そのようなウォレットに安全な実装を提供することが重要であることを意味します。これは、EOA と同様に、ユーザーのプロキシ ウォレット アドレスが決定的であり、ネットワーク全体で一貫していることを確認する必要があることも意味します。
開発の進捗状況:
⑤ERC-4337クライアントSDK
この部分は、ERC-4337 の機能を体験しながら MetaMask を使い続けるなど、ERC-4337 をさまざまなウォレットや dapps にできるだけ簡単に統合できるようにすることを目的としています。
開発状況:
⑥⑦⑧⑨…ソーシャル検索、ペイマスター、欲しい便利機能
開発の進捗状況:
開発の進捗状況:
100% EVM L2 ではない (Starknet など)
答えはEVM環境よりも前にあります。現在、開発者はすでにこれを使用してテストネットでコードを作成でき、多くの強力な機能が実稼働レベルに入っています。
画像の説明
StarkNet でのアカウント抽象化の基本プロセス
現在、アカウント抽象化の進歩はほぼ運用準備が整ったレベルに達しており、Starkware はアカウント抽象化の改善を含む StarkNet Alpha 0.10.0 (ERC-4337 に触発された) をリリースしました。
[DevConnect StarkNet Hackathon] 中にいくつかの興味深いことが明らかになりました。
セッション キー: ブラウザーに保存されるワンタイム署名キーを作成すると、ユーザーは一定期間内にゲームに 1 回サインインするだけで済みます。これにより、プレイヤーが重複した取引に署名する必要がなくなります。 (ブリック&レルムズ[3])
Dead Man's Switch: アカウントが一定期間使用されなかった場合、この設計により、信頼できるアカウントがウォレット内の資産にアクセスし、アカウントの所有権を指定された人に譲渡できるようになり、元のアカウントが使用されていない場合の問題を解決できます。所有者の失踪、アカウント資産の譲渡。 (デッドマン[4])
ゲームユニオンマルチ署名システム:トークン所有者が所有権を保持しながらユニオン内でNFTの使用許可を開くことができます。 (ギルドリー[5])
製品の形と価値の捉え方
製品形態:結局のところ、これまで見てきたものと同じではないかもしれない
前の内容を思い出してください。アカウント抽象化の主要なコントラクトとウォレット クライアント SDK さえもオープンソースになります。これは、アカウント抽象化フレームワークに基づいて基本的なウォレット (さまざまな派手な機能なし) を非常に簡単に起動できることを意味します。そして、オープンソース コミュニティにはすでに多くの優れた便利な機能があり、さらに多くの機能が期待されます。何よりも、これらの基本的なウォレットと便利な機能はすべて同じ基準に基づいています。
そうすると、誰でも標準化されたフロントエンドを構築でき、便利な機能を備えたプラグインマーケットを搭載し、ユーザーが使いたいプラグインを利用して表示することができるプロダクト形態になるでしょう。現在使用中 (私は PM やアーティストではありません。下の写真が醜い場合はご容赦ください :)
価値の獲得: 公共財の収益モデルにもう一度向き合う必要がある
前述の理論を参照すると、基本的なインターフェイスが基盤となるインフラストラクチャに組み込まれ、便利な機能のほとんどもオープンソースになる場合、価値の獲得はどのように行うのでしょうか?
もちろん、ウォレットは引き続きスワップ機能を使用してトラフィックの収益化を実現できます。
しかし、これらの貴重な利便機能に対して、現在の市場にはそのような公共財に対する適切なインセンティブメカニズムが欠如しているため、より多くの利便機能を充実させる責任は誰にあるのでしょうか。結局のところ、これはスマート コントラクト ウォレットの最も重要な価値です。
終わり
終わり
Vitalik がアカウントの抽象化について公に繰り返し説明したのと同じように、アカウントの抽象化はブロックチェーン ネットワークが主流のユーザーに到達する唯一の方法です。この記事がそれをより深く理解していただければ幸いです。
ただし、実際的な制限はまだ多くあり (たとえば、EIP-1271 をサポートしていない多くの dapps >>> スマート コントラクト ウォレットはこれらの dapps と対話できません)、マルチチェーン シナリオには適していません。しかし、L2 がイーサリアムの未来であるのと同じように、アカウントの抽象化がイーサリアム ウォレットの未来であると私は信じています。
もちろん、マルチチェーンのユースケースで MPC ウォレットを試してみることもお勧めします。近い将来、MPC ウォレットが最良のウォレット ソリューションとなるはずです。マルチチェーンシステムにおけるアカウント抽象化ウォレットについてのアイデアがありましたら、ぜひご連絡ください。
元のリンク