Vitalikの新しい技術文：理想的なウォレットのビジョン - クロスチェーン体験からプライバシー保護への全方位のアップグレード
財布はユーザーとイーサリアムの世界との窓口であり、安全性とプライバシーの属性に注目することが最も価値があると考えています。著者：Vitalik Buterin
特に Liraz Siri、Yoav Weiss、ImToken、Metamask、OKX の開発者のフィードバックとレビューに感謝します。
イーサリアムのインフラストラクチャスタックの重要な層の一つはウォレットですが、しばしばコア L1 の研究者や開発者によって過小評価されています。ウォレットはユーザーとイーサリアムの世界との窓口であり、ユーザーはウォレット自体がこれらの属性を持っている限り、イーサリアムとそのアプリケーションが提供する分散化、検閲耐性、安全性、プライバシー、その他の属性から利益を得ることができます。
最近、私たちはイーサリアムウォレットがユーザーエクスペリエンス、安全性、機能の改善において大きな進展を遂げているのを目にしています。この記事の目的は、理想的なイーサリアムウォレットが持つべきいくつかの特性について私自身の見解を示すことです。これは完全なリストではなく、私の暗号パンクの傾向を反映しており、安全性とプライバシーに焦点を当てており、ユーザーエクスペリエンスの面では不完全であることはほぼ確実です。しかし、私は、ユーザーエクスペリエンスを最適化するための願望リストは、フィードバックに基づいて展開と反復を行うことほど効果的ではないと考えているため、安全性とプライバシーの属性に焦点を当てることが最も価値があると考えています。
クロスL2取引のユーザーエクスペリエンス
現在、クロスL2ユーザーエクスペリエンスを改善するための詳細なロードマップがあり、短期的な部分と長期的な部分があります。ここでは短期的な部分について話します：今日の理論上実装可能なアイデアです。
核心的なアイデアは（i）組み込みのクロスL2送信、および（ii）チェーン特有のアドレスと支払いリクエストです。あなたのウォレットは、次のようにアドレスを提供できる必要があります（このERC草案のスタイルに従って）：
誰か（または特定のアプリケーション）がこの形式のアドレスを提供した場合、あなたはそれをウォレットの「受取人」フィールドに貼り付け、「送信」をクリックできる必要があります。ウォレットは、送信データを可能な限り自動的に処理する必要があります：
目的のチェーン上に必要なタイプのトークンが十分にある場合、トークンを直接送信
他のチェーンに必要なタイプのトークンがある場合、ERC-7683 などのプロトコル（実際にはクロスチェーンDEX）を使用してトークンを送信
同じチェーンまたは他のチェーンに異なるタイプのトークンがある場合、分散型取引所を使用してそれらを変換し、正しいチェーン上の正しいタイプの通貨に送信します。これにはユーザーの明示的な許可が必要です：ユーザーは支払った手数料と受取人が受け取った手数料を確認できます。
クロスチェーンアドレスサポートを持つ可能なウォレットインターフェースのモデル
上記の内容は「あなたがアドレスをコピー＆ペーストする（またはENS、例えば、vitalik.eth @ optimism.eth）誰かがあなたに支払う」ユースケースに適用されます。dappがデポジットを要求する場合（例えば、このPolymarketの例を参照）、理想的なフローはweb3 APIを拡張し、dappがチェーン特有の支払いリクエストを発行できるようにすることです。次に、あなたのウォレットはそのリクエストを満たすために必要な方法で応じることができるようになります。ユーザーエクスペリエンスを良好に保つためには、getAvailableBalanceリクエストを標準化する必要があり、ウォレットはユーザーの資産をどのチェーンにデフォルトで保存するかを真剣に考慮する必要があります。これにより、安全性と送金の便利さが最大化されます。
チェーン特有の支払いリクエストはQRコードに埋め込むこともでき、モバイルウォレットはQRコードをスキャンできます。対面（またはオンライン）での消費者支払いシナリオでは、受取人は「私はチェーン上でX単位のトークンY Zを、参照IDまたはコールバックWを持って欲しい」と示すQRコードまたはweb3 API呼び出しを発行し、ウォレットはそのリクエストを自由に満たすことができます。別の選択肢はクレームリンクプロトコルであり、ユーザーのウォレットは、彼らのチェーン上の契約から一定量の資金を取得するためのクレーム権限を含むQRコードまたはURLを生成し、受取人はその資金を自分のウォレットに移動する方法を理解する必要があります。
もう一つの関連するテーマはガス支払いです。もしあなたがまだETHを持っていないL2で資産を受け取り、そのL2で取引を送信する必要がある場合、ウォレットは自動的にプロトコル（例えば、RIP-7755）を使用して、あなたがETHを持っている場所でチェーン上のガスを支払うことができる必要があります。もしウォレットが将来的にあなたがL2でさらに多くの取引を行うことを望むなら、DEXを使用して、例えば数百万ガスの価値のETHを送信し、将来の取引が直接そこでガスを消費できるようにするべきです（その方が安価だからです）。
アカウントの安全性
私がアカウントの安全性の課題を概念化する一つの方法は、良いウォレットが二つの側面で機能するべきだということです：（i）ユーザーをウォレット開発者のハッキングや悪意のある攻撃から保護し、（ii）ユーザー自身の誤りから保護する。
左側の「誤り」は意図しないものです。しかし、私がそれを見たとき、それが文脈に非常に適していることに気づいたので、保持することにしました。
私のこの件に関する好ましい解決策は、過去十年にわたって、ソーシャルリカバリーとマルチシグウォレットであり、階層的なアクセス制御を持っています。ユーザーのアカウントには二層のキーがあります：主キーとN人の保護者（例えばN=5）。主キーは低価値および非財務的な操作を行うことができます。大多数の保護者は、(i) アカウント内の全価値を送信するなどの高価値操作を行うか、(ii) 主キーまたは任意の保護者を変更する必要があります。必要に応じて、主キーはタイムロックを介して高価値操作を実行することが許可される場合があります。
上記は基本設計であり、拡張可能です。セッションキーやERC-7715などの権限メカニズムは、異なるアプリケーションの利便性と安全性の間の異なるバランスをサポートするのに役立ちます。異なる閾値で複数のタイムロック持続時間を持つより複雑な保護者アーキテクチャは、正当なアカウントの成功した回復の機会を最大化しつつ、盗難リスクを最小化するのに役立ちます。
保護者は誰または何であるべきか？
経験豊富な暗号通貨ユーザーコミュニティの中で、実行可能な選択肢は友人や家族のキーです。もしあなたが皆に新しいアドレスを提供するように頼むなら、誰も彼らが誰であるかを知る必要はありません - 実際、あなたの保護者はお互いが誰であるかを知る必要すらありません。彼らがあなたに通報しない限り、彼らが共謀する可能性は非常に低いです。しかし、ほとんどの新しいユーザーにとって、この選択肢は利用できません。
第二の選択肢は機関保護者です：あなたのリクエストの他の確認情報を受け取ったときのみ取引に署名するサービスを提供する会社です：例えば、確認コードや高価値ユーザー向けのビデオ通話などです。人々は長い間これを作ろうとしてきました、例えば。私は2013年にCryptoCorpを紹介しました。しかし、これまでのところ、これらの会社はあまり成功していません。
第三の選択肢は複数の個人デバイス（例えば電話、デスクトップ、ハードウェアウォレット）です。これは機能しますが、経験のないユーザーにとっては設定と管理が難しいです。また、特に同じ場所にある場合、デバイスが同時に失われたり盗まれたりするリスクもあります。
最近、私たちはマスタキーに基づくものをより多く見るようになりました。キーはあなたのデバイスにのみバックアップされ、個人デバイスソリューションとなり、クラウドにバックアップされることもでき、セキュリティは複雑なハイブリッドパスワードセキュリティ、機関、信頼できるハードウェア仮定に依存します。実際、キーは一般ユーザーにとって貴重なセキュリティの向上ですが、それだけではユーザーの生涯の貯蓄を保護するには不十分です。
幸いなことに、ZK-SNARKがあるおかげで、私たちは第四の選択肢を持っています：ZKラップされた中央集権ID。このタイプにはzk-email、Anon Aadhaar、Myna Walletなどが含まれます。基本的に、あなたはさまざまな形式（企業または政府）の中央集権IDを取得し、それをイーサリアムアドレスに変換し、中央集権IDを所有していることを証明するZK-SNARKを生成することで取引を送信できます。
この補足により、私たちは広範な選択肢を持ち、ZKラップされた中央集権IDは独自の「初心者に優しい」特性を持っています。
これを実現するためには、簡素化された統合UIが必要です：あなたは単に「example@gmail.com」を保護者として指定でき、ウォレットは自動的に対応するzk-emailイーサリアムアドレスを生成する必要があります。上級ユーザーは、彼らの電子メール（およびその電子メールに保存されている可能性のあるプライバシーソルト）をオープンソースのサードパーティアプリケーションに入力し、生成されたアドレスが正しいことを確認できる必要があります。他のすべてのサポートされている保護者タイプについても同様です。
今日、zk-emailが直面している実際の課題の一つは、それがDKIM署名に依存していることであり、この署名は数ヶ月ごとにローテーションされるキーを使用し、これらのキー自体は他の機関によって署名されていません。これは、今日のzk-emailが提供者自体を超えたある程度の信頼要求を持つことを意味します；もしzk-emailが信頼できるハードウェア内でTLSNotaryを使用して更新されたキーを検証するなら、この状況を軽減できますが、理想的ではありません。電子メール提供者が自らのDKIMキーを直接署名し始めることを期待しています。今日、私は保護者としてzk-emailを使用することを推奨しますが、ほとんどの保護者には推奨しません：zk-emailが損なわれると、資金を使用できない設定になります。
新しいユーザーとアプリ内ウォレット
新しいユーザーは実際には初回登録時に多くの保護者を入力したくありません。したがって、ウォレットは彼らに非常にシンプルな選択肢を提供する必要があります。一つの自然な方法は、彼らの電子メールアドレスでzk-emailを使用し、ユーザーのデバイスにローカルに保存されたキー（おそらくマスタキー）と、プロバイダーが保持するバックアップキーを使用して、2-of-3の選択肢を行うことです。ユーザーがより経験を積むか、より多くの資産を蓄積するにつれて、ある時点で彼らにさらに多くの保護者を追加するよう促すべきです。
アプリケーションへのウォレット統合は避けられないものであり、暗号ユーザー以外を引き付けようとするアプリケーションは、ユーザーが同時に二つの新しいアプリケーション（アプリケーション自体とイーサリアムウォレット）をダウンロードすることによる混乱したユーザーエクスペリエンスを望んでいません。しかし、多くのアプリケーションウォレットのユーザーは、すべてのウォレットをリンクさせることができるべきであり、そうすれば彼らは一つの「アクセス制御問題」だけを心配すればよいのです。最も簡単な方法は階層的なスキームを採用し、ユーザーが主ウォレットをすべてのアプリ内ウォレットの保護者として設定できる迅速な「リンク」プロセスを許可することです。FarcasterクライアントWarpcastはすでにこれをサポートしています：
デフォルトでは、あなたのWarpcastアカウントの回復はWarpcastチームによって制御されています。しかし、あなたは「あなたのFarcasterアカウントを引き継ぎ」、回復を自分のアドレスに変更することができます。
ユーザーを詐欺やその他の外部脅威から保護する
アカウントの安全性に加えて、今日のウォレットは偽のアドレス、フィッシング、詐欺、その他の外部脅威を特定し、ユーザーをそのような脅威から保護するために多くの作業を行っています。同時に、多くの対策は依然としてかなり原始的です：例えば、ETHや他のトークンを新しいアドレスに送信するためにクリックを要求することは、あなたが100ドルを送信するか100,000ドルを送信するかに関係なく行われます。ここには単一の万能薬は存在しません。これは異なるカテゴリの脅威に対する一連の緩やかな継続的な修正と改善です。しかし、ここでの改善に向けた努力を続けることには多くの価値があります。
プライバシー
今こそ、イーサリアムのプライバシーをより真剣に考える時です。ZK-SNARK技術は現在非常に進んでおり、バックドアに依存せずに規制リスクを低減するプライバシー技術（例えばプライバシープール）はますます成熟しており、WakuやERC-4337メモリプールのような二次インフラも徐々に安定してきています。しかし、これまでのところ、イーサリアム上でプライベートな送金を行うには、ユーザーが明示的に「プライバシーウォレット」をダウンロードして使用する必要があります。例えばRailway（または隠れたアドレスのためのUmbra）。これは非常に大きな不便をもたらし、プライベートな送金を行うことに対する意欲を減少させます。解決策は、プライベートな送金をウォレットに直接統合することです。
簡単な実装は次のようになります。ウォレットはユーザー資産の一部を「プライベートバランス」としてプライバシープールに保存できます。ユーザーが送金を行うと、まず自動的にプライバシープールから退出します。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的に隠れたアドレスを生成できます。
さらに、ウォレットはユーザーが参加している各アプリケーションのために自動的に新しいアドレスを生成できます（例えば、DeFiプロトコル）。入金はプライバシープールから行われ、出金は直接プライバシープールに入ります。これにより、ユーザーがあるアプリケーションでの活動が他のアプリケーションでの活動とリンクされないようになります。
この技術の一つの利点は、プライバシーを保護する資産移転の自然な方法であるだけでなく、プライバシーを保護するアイデンティティの自然な方法でもあることです。アイデンティティはチェーン上で発生しています：ID証明が必要なアプリケーション（例えばGitcoin Grants）、トークンが必要なチャット、イーサリアム遵守プロトコルなどはすべてチェーン上のアイデンティティです。私たちはこのエコシステムがプライバシーを保護することを望んでいます。これは、ユーザーのチェーン上の活動が一つの場所に収集されるべきではないことを意味します：各プロジェクトは個別に保存され、ユーザーのウォレットだけが「グローバルビュー」を持ち、すべての証明を同時に見ることができるべきです。各ユーザーが複数のアカウントを持つネイティブエコシステムはこれを実現するのに役立ちますし、EASやZupassなどのオフチェーン証明プロトコルも同様です。
これは中期的なイーサリアムプライバシーの実用的なビジョンを示しています。L1とL2にいくつかの機能を導入してプライバシー保護の送信をより効率的かつ信頼性の高いものにすることができますが、今すぐに実現可能です。いくつかのプライバシー擁護者は、唯一受け入れ可能なものはすべてのものの完全なプライバシーであると考えています：EVM全体の暗号化。私はこれは理想的な長期的結果かもしれないと考えていますが、それにはプログラミングモデルの根本的な再考が必要であり、現在はイーサリアム上で展開する準備が整っている成熟度には達していません。私たちは十分な匿名集団を得るためにデフォルトのプライバシーが必要です。しかし、まず（i）アカウント間の送金、（ii）アイデンティティおよびアイデンティティ関連のユースケース（例えばプライベート証明）に焦点を当てることは実用的な第一歩であり、より実現しやすく、ウォレットは今すぐにでも開始できます。
イーサリアムウォレットもデータウォレットになる必要がある
有効なプライバシーソリューションの一つの結果は、支払い、アイデンティティ、またはその他のユースケースのために、ユーザーがオフチェーンデータを保存する必要があることです。これはTornado Cashで明らかであり、ユーザーは0.1-100 ETHの預金を表す「レシート」を保存する必要があります。より現代的なプライバシープロトコルは、時にはチェーン上に暗号化されたデータを保存し、単一の秘密鍵でそれを解読します。これはリスクがあります。なぜなら、もし鍵が漏洩したり、量子コンピュータが実用化されたりすると、データがすべて公開されてしまうからです。EASやZupassなどのオフチェーン証明は、オフチェーンデータストレージの必要性をさらに明確に示しています。
ウォレットは、チェーン上のアクセス権を保存するソフトウェアだけでなく、あなたのプライベートデータを保存するソフトウェアにもなる必要があります。非暗号世界もこれをますます認識しています。例えば、Tim Berners-Leeの最近の個人データストレージに関する取り組みを参照してください。私たちは、堅牢なアクセス制御を保証するために解決すべき問題だけでなく、堅牢なデータの可用性と漏洩を保証するために解決すべき問題も必要です。これらの解決策は重ね合わせることができるかもしれません：もしあなたがN人の保護者を持っているなら、これらのN人の保護者の間でM-of-N秘密共有を使用してデータを保存します。データは本質的に保護が難しいです。なぜなら、誰かのデータシェアを取り消すことができないからです。しかし、私たちはできるだけ安全な分散型ホスティングソリューションを提案するべきです。
安全なチェーンアクセス
今日、ウォレットはRPCプロバイダーがチェーンに関するあらゆる情報を提供してくれると信じています。これは二つの側面での脆弱性です：
RPCプロバイダーは、偽の情報を提供することによってお金を盗もうとする可能性があります。例えば、市場価格に関して。
RPCプロバイダーは、ユーザーが相互作用しているアプリケーションや他のアカウントに関するプライベート情報を抽出することができます。
理想的には、私たちはこれら二つの脆弱性を塞ぎたいと考えています。最初の問題を解決するためには、L1とL2の標準化された軽量クライアントが必要であり、これによりブロックチェーンのコンセンサスを直接検証できます。HeliosはL1でこれを行っており、いくつかの具体的なL2をサポートするための前進的な作業を行っています。すべてのL2を正しくカバーするためには、L2を代表する構成契約（チェーン特有のアドレスにも使用される）を通じて、関数を宣言できる標準が必要です。これは、ERC-3668のような方法で、最近の状態ルートを取得し、これらの州の根に対する証明を検証するロジックを含むことができます。これにより、ウォレットはL1とL2上のあらゆる状態やイベントを安全に検証できる一般的な軽量クライアントを持つことができます。
プライバシーのために、今日の唯一現実的な方法は、自分のフルノードを運営することです。しかし、今L2が人々の視野に入ってきており、すべてを運営するフルノードを運営することがますます困難になっています。ここで軽量クライアントに相当するのはプライベート情報取得（PIR）です。PIRは、すべてのデータのコピーを保持するサーバーと、サーバーに暗号化されたリクエストを送信するクライアントを含みます。サーバーはすべてのデータに対して計算を実行し、クライアントが必要とするデータを返し、クライアントの鍵に暗号化され、どのデータにアクセスしたかをサーバーに明かさないようにします。
サーバーの誠実さを保つために、各データベースプロジェクト自体がMerkleブランチであるため、クライアントは軽量クライアントを使用してそれらを検証できます。
PIRの計算量は非常に大きいです。この問題を解決する方法はいくつかあります：
力任せに：アルゴリズムや専用ハードウェアの改善により、PIRを十分に速く実行できる可能性があります。これらの技術は前処理に依存する可能性があります：サーバーは各クライアントのために暗号化されシャッフルされたデータを保存し、クライアントはそのデータをクエリできます。イーサリアム環境における主な課題は、これらの技術を急速に変化するデータセットに適応させることです（国家のように）。これにより、リアルタイム計算コストが低くなりますが、総計算およびストレージコストが高くなる可能性があります。
プライバシー要件を緩和する：例えば、各検索には100万の「ミキシン」しか持てないため、サーバーはクライアントがアクセスできる100万の可能な値を知ることになりますが、より細かい粒度は知りません。
マルチサーバーPIR：複数のサーバーを使用し、これらのサーバー間の誠実性の仮定が1-of-Nである場合、PIRアルゴリズムは通常より速くなります。
匿名性ではなく機密性：リクエストを送信するためにミキシングネットワークを使用することで、リクエストの送信者を隠すことができますが、リクエストの内容を隠すことはできません。しかし、効果的にこれを行うことは避けられない遅延を増加させ、ユーザーエクスペリエンスを悪化させます。
イーサリアム環境でプライバシーを最大化しつつ実用性を維持するための正しい技術の組み合わせを見つけることはオープンな研究問題であり、私は暗号学者がこれを試みることを歓迎します。
理想的なキーストレージウォレット
転送と状態アクセスに加えて、クロスL2コンテキストでスムーズに機能するもう一つの重要なワークフローは、アカウントの検証構成を変更することです：そのキーを変更する（例えば、リカバリー）か、アカウントの全体的なロジックをより深く変更することです。ここには三層の解決策があり、難易度が増す順に並べられています：
リプレイ更新：ユーザーが構成を変更すると、その変更を承認するメッセージが、ユーザーが資産を持っている各チェーンでリプレイされます。メッセージの形式と検証ルールはチェーンに依存せず、できるだけ多くのチェーンで自動的にリプレイできる可能性があります。
L1上のキーストレージ：構成情報はL1にあり、L2上のウォレットはL1SLOADを使用してそれを読み取ります。またはリモート静的呼び出し。これにより、L1で構成を更新するだけで、構成が自動的に有効になります。
L2上のキーストレージ：構成情報はL2に存在し、L2上のウォレットはZK-SNARKを使用してそれを読み取ります。これは（2）と同じですが、キーストレージの更新が安価である可能性がありますが、他方で読み取りは高価です。
解決策（3）は特に強力です。なぜなら、プライバシーと非常にうまく連携できるからです。通常の「プライバシーソリューション」では、ユーザーは秘密sを持ち、「葉の値」Lをチェーン上に公開し、ユーザーはL = hash(s, 1)かつN = hash(s, 2)を証明しなければなりません。無効な符号Nが公開され、同じ葉の将来の支出が失敗することを保証しますが、Lはユーザーのsの安全性に依存します。リカバリーに優しいプライバシーソリューションは、sがオンチェーンの位置（例えばアドレスとストレージスロット）であり、ユーザーは状態クエリを証明しなければならないと言います：L = hash(sload(s), 1)。
Dappの安全性
ユーザーの安全性の最も弱い環は通常dappです。ほとんどの場合、ユーザーはウェブサイトを通じてアプリケーションと相互作用し、ウェブサイトはユーザーインターフェースコードをリアルタイムでサーバーからダウンロードし、ブラウザ内で実行します。サーバーがハッキングされたり、DNSがハッキングされたりすると、ユーザーは虚偽のインターフェースを受け取り、任意の操作を実行するように誘惑される可能性があります。取引シミュレーションなどのウォレット機能はリスクを低減するのに役立ちますが、まだ完璧ではありません。
理想的には、私たちはエコシステムをチェーン上のコンテンツバージョン管理に移行させます：ユーザーはENS名を通じてdappにアクセスし、その名前にはインターフェースのIPFSハッシュが含まれます。インターフェースを更新するには、マルチシグまたはDAOからのチェーン上の取引が必要です。ウォレットはユーザーに、より安全なチェーン上のインターフェースまたは安全性の低いWeb2インターフェースと相互作用しているかどうかを示すことができます。ウォレットはまた、ユーザーが安全なチェーンと相互作用しているかどうかを示すことができます（例えば、ステージ1+、マルチセキュリティ監査など）。
プライバシーを重視するユーザーのために、ウォレットは偏執モードを追加し、ユーザーにHTTPリクエストを受け入れるためにクリックを要求することができます。単にweb3操作だけではなく：
偏執モードの可能なインターフェースモデル
より高度なアプローチは、HTML + Javascriptを超えて、専用言語（おそらくSolidityまたはVyperの上に比較的薄いカバー層）でdappのビジネスロジックを書くことです。次に、ブラウザは必要な機能のUIを自動的に生成できます。OKContractはすでにこれを行っています。
もう一つの方向性は暗号経済情報防御です：dapp開発者、安全会社、チェーンデプロイヤーなどは、dappがハッキングされたり、ユーザーに対して高度に誤解を招く方法で害を及ぼした場合、その債券が影響を受けたユーザーに支払われるようにする債券を構築できます（確認された）いくつかのチェーン上の裁定DAOによって。ウォレットはユーザーに、債券のサイズに基づいたスコアを表示できます。
より長期的な未来
上記はすべて、指し示し、クリックすること、そしてテキストフィールドに何かを入力することを含む伝統的なインターフェースの背景で行われています。しかし、私たちはまた、より深いパラダイムの変化の瀬戸際にいます：
人工知能、これは私たちがクリック式のタイピングパラダイムから「やりたいことを言えば、ロボットが理解する」パラダイムに移行する可能性があります
脳-コンピュータインターフェース、眼球追跡などの「穏やかな」方法から、より直接的で侵襲的な技術（参照：今年の最初のNeuralink患者）
クライアントの積極的防御：Braveブラウザは広告、トラッカー、その他の悪質なオブジェクトからユーザーを積極的に保護します。多くのブラウザ、プラグイン、暗号ウォレットには、ユーザーをさまざまなセキュリティとプライバシーの脅威から保護するために積極的に取り組むチームがあります。これらの「積極的な守護者」は、今後10年間でさらに強力になるでしょう。
これら三つのトレンドは、インターフェースの動作方法に対するより深い再考をもたらすでしょう。自然言語入力、眼球追跡、または最終的にはより直接的な脳-コンピュータインターフェースと、あなたの履歴（おそらくSMSを含む、すべてのデータがローカルで処理される限り）、ウォレットはあなたが何をしたいのかを明確に直感的に理解できるようになります。次に、人工知能がこの直感を具体的な「行動計画」に変換します：あなたがやりたいことを達成するための一連のオンチェーンおよびオフチェーンの相互作用です。これにより、第三者のユーザーインターフェースへの依存が大幅に減少する可能性があります。もしユーザーが実際に第三者アプリケーション（または他のユーザー）と相互作用する場合、人工知能はユーザーのために対抗的思考を行い、あらゆる脅威を特定し、脅威を回避するための行動計画を提案するべきです。理想的には、これらの人工知能は異なるバイアスとインセンティブ構造を持つ異なるグループによって生成されるオープンなエコシステムを持つべきです。
これらのより過激なアイデアは、技術が今日非常に未熟であることに依存しているため、私は今日それらに依存するウォレットに私の資産を置くつもりはありません。しかし、類似のことは明らかに未来のトレンドであるように思われるため、この方向により積極的に探求を始める価値があります。
