作者: ヴィタリック ブテリン
編集者: Yangz、Techub News
ウォレットはイーサリアム インフラストラクチャ スタックの重要なレイヤーですが、コアの L1 研究者や開発者によって過小評価されがちです。ウォレットはユーザーとイーサリアムの世界との間の窓口であり、ユーザーがその恩恵を受けることができるのは、ウォレット自体にも分散化、検閲耐性、セキュリティ、プライバシー、またはイーサリアムとそのアプリケーションによって提供されるその他の機能がある場合のみです。
近年、イーサリアムのエコロジカルウォレットがユーザーエクスペリエンス、セキュリティ、機能性の向上において大きな進歩を遂げているのを見てきました。この記事の目的は、理想的なイーサリアムウォレットが持つべき特性のいくつかについて私の個人的な意見を表明することです。このリストはすべてを網羅したものではありませんが、私のサイファーパンクの傾向を反映しています。ユーザーエクスペリエンスの点で完璧なウォレットはほとんど存在しないため、私はウォレットに関してはセキュリティとプライバシーをより重視しています。ウィッシュリストはユーザー エクスペリエンスを最適化するのに、単にフィードバックに基づいて展開して反復するほど効果的ではないと思います。私の意見では、セキュリティとプライバシーの属性に焦点を当てることが最も価値があります。
クロス L2 トランザクションのユーザー エクスペリエンス
現在、クロス L2 ユーザー エクスペリエンスを向上させるためのルートは、短期的な部分と長期的な部分を含めて、ますます詳細になってきています。ここでは短期的な部分、つまり今日でも理論的に可能なアイデアについて話したいと思います。
この部分の中心となるアイデアは、チェーン固有のアドレスと支払いリクエストだけでなく、クロス L2 トランザクションを組み込むことです。ウォレットは次のようなアドレスを提供する必要があります。
誰か (またはアプリ) がこの形式でアドレスを提供した場合、それをウォレットの「宛先」フィールドに貼り付けて「送信」をクリックすると、ウォレットが自動的にアドレスを処理します。
ターゲット チェーン上に必要なタイプのトークンが十分にある場合は、それらを直接送信します。
別のチェーン (複数のチェーン) に必要なタイプのトークンがある場合は、 ERC-7683 (実際にはクロスチェーン DEX) のようなプロトコルを使用してトークンを送信できます。
同じチェーンまたは別のチェーンに異なるタイプのトークンがある場合は、DEX を使用して、それを正しいチェーン上の正しいタイプのトークンに変換して送信できます。もちろん、これにはユーザーの明示的な許可も必要です。つまり、ユーザーは自分が支払った金額と受信者が受け取った金額を確認することになります。
上記は、「アドレス (または ENS、例: vitalik.eth@optimism.eth) をコピーして貼り付け、誰かにお金を支払ってもらう」というユースケースです。 DApp に入金が行われる場合 ( Polymarket の例を参照)、理想的なフローは Web3 API を拡張して、DApp がチェーン固有の支払いリクエストを行えるようにすることです。このようにして、ユーザーウォレットはあらゆる方法でリクエストを満たすことができます。優れたユーザーエクスペリエンスを実現するには、getAvailableBalanceリクエストも標準化する必要があり、ウォレットは、セキュリティと転送の容易さを最大化するために、ユーザーの資産がデフォルトでどのチェーンに保存されるかを考慮する必要があります。
特定のチェーンに対する支払いリクエストを QR コードに配置して、モバイル ウォレットで直接スキャンすることもできます。対面 (またはオンライン) での消費支払いシナリオでは、受取人は QR コードまたは Web3 API を通じて「参照 ID またはコールバック W を持つ Z チェーン上の X ユニットの Y トークンが欲しい」と呼び出すことができ、ウォレットはいかなる方法でも自由にこの要求に従うことができます。別の解決策は、リンクプロトコルを要求することです。つまり、ユーザーウォレットは、オンチェーンコントラクトから一定量の資金を要求する権限を含むQRコードまたはURLを生成できます。受取人の仕事は、その方法を見つけることです。これらの資金を転送するには、自分のウォレットに転送します。
もう 1 つの関連トピックは、ガソリンの支払いです。 ETH をまだ所有していない L2 で資産を受け取り、その L2 でトランザクションを送信する必要がある場合、ウォレットは自動的にプロトコル ( RIP-7755など) を使用してチェーン上のガスの支払いを行うことができる必要があります。 ETHを所有している場所。将来その L2 でさらに多くのトランザクションが行われることがウォレットで予測されている場合は、将来のトランザクションでガスを直接使用できるように (これも安価です)、DEX を使用して数百万のガス相当の ETH を送信する必要があります。
アカウントのセキュリティ
アカウントセキュリティの課題についての私の理解は、優れたウォレットはハッカーやウォレット開発者による悪意のある攻撃、そしてユーザー自身のミスの両方からユーザーを保護する必要があるということです。
縦軸の「間違い」は正直な間違いです。このエラーは文脈に適合していると感じたので、修正しませんでした。
10 年以上にわたり、私が好むソリューションは、階層型アクセス制御を備えたソーシャル リカバリとマルチシグネチャ ウォレットでした。単一のユーザー アカウントは、マスター キーと N 人の署名者 (たとえば、N = 5) を含む 2 レベルのキーで設定されます。マスターキーにより、低価値の非財務的な操作が可能になります。ただし、アカウント内のすべてのアセットを送信したり、マスターキーや署名者を変更したりするなど、価値の高い操作を実行するには、署名者の過半数が必要です。必要に応じて、マスター キーがタイム ロックを使用して高価値の操作を実行できるようにすることができます。
上記は基本的なデザインにすぎませんが、拡張することもできます。たとえば、セッション キーと許可メカニズム ( ERC-7715など) は、利便性とセキュリティのバランスが異なるさまざまなアプリケーションをサポートするのに役立ちます。異なるしきい値で複数のタイムロック期間を設定するなど、より複雑な署名者のアーキテクチャは、盗難のリスクを最小限に抑えながら、正規のアカウントを正常に回復できる可能性を最大限に高めるのに役立ちます。
マルチシグネチャウォレットの署名者として誰を選ぶべきですか?
経験豊富な暗号通貨ユーザーにとって、有効な選択肢は友人や家族です。実際、マルチシグウォレットの署名者は、お互いが誰であるかを知る必要さえありません。あなたの知らないうちに彼らが共謀する可能性はほとんどありません。ただし、ほとんどの新規ユーザーにとって、このオプションは実行できません。
2 番目の選択肢は、サービスの提供を専門とする代理店です。このような署名者は、追加の確認情報 (確認コードや富裕層ユーザーからのビデオ通話など) を受け取った後にのみトランザクションに署名します。人々は長い間このような会社を設立しようとしてきました。たとえば、私は 2013 年にCryptoCorpについて紹介しました。しかし、今のところ、この種の企業で大きな成功を収めた代表者はいない。
3 番目のオプションは、複数の個人デバイス (モバイル、デスクトップ、ハードウェア ウォレットなど) を使用することです。このアプローチは機能する可能性がありますが、経験の浅いユーザーにとっては設定と管理が難しい場合もあります。さらに、特に同じ場所にある場合、デバイスが同時に紛失または盗難されるリスクがあります。
最近、パスキーベースのウォレットがさらに登場しているのを目にするようになりました。パスキーはデバイス上でのみバックアップできるため、個人からデバイスへのソリューションになります。また、パスワード セキュリティ、権限、および信頼できるハードウェアの前提条件が複雑に組み合わされたものにセキュリティが依存するように、クラウドにバックアップすることもできます。実際には、パスキーは平均的なユーザーにとって貴重なセキュリティ上の利点ですが、それだけではユーザーの命の節約を保護するには十分ではありません。
幸いなことに、ZK-SNARK では、ZK によって処理される集中 ID という 4 番目のオプションがあります。このタイプには、 zk-email 、 Anon Aadhaar 、 Myna Walletなどが含まれます。基本的に、任意の形式の集中 ID (企業または政府) を取得してイーサリアム アドレスに変換し、その ID の所有権を証明する ZK-SNARK を生成することによってのみ、そのアドレスからトランザクションを送信できます。
この新機能ではさまざまなオプションがあり、ZK によって処理される一元的な ID は非常に初心者に優しいものです。
これを実現するには、合理化された統合ユーザー インターフェイスを使用する必要があります。ユーザーは署名者として「example@gmail.com」を指定するだけで、ウォレットは対応する zk-email Ethereum アドレスを自動的に生成します。さらに、上級ユーザーは、自分の電子メール (電子メールに保存されるプライバシー ソルトとともに) をオープン ソースのサードパーティ アプリケーションに入力し、結果のアドレスが正しいことを確認できる必要があります。他のサポートされている署名者のタイプにも同じことが当てはまります。
zk-email が現在直面している実際的な課題は、数か月ごとにローテーションされる鍵を使用するDKIM 署名に依存しており、鍵自体は他の機関によって署名されていないことです。これは、プロバイダー自体を超えて必要な信頼レベルがあることを意味します。zk-email が信頼できるハードウェア上でTLSNotary を使用して更新されたキーを検証する場合、信頼要件を軽減できますが、これは理想的ではありません。電子メールプロバイダーが DKIM キーに直接署名し始めることを願っています。また、大多数の署名者ではなく、1 人の署名者にのみ zk-email を使用することをお勧めします。これにより、zk-email がクラッシュした場合でも、資金にアクセスできなくなります。
新規ユーザーとアプリ内ウォレット
実際には、新規ユーザーは、最初にサインアップするときに、多数のマルチシグネチャ ウォレットの署名者情報を入力することを望まないでしょう。したがって、ウォレットは非常にシンプルなオプションを提供する必要があります。自然なアプローチは、3 つの署名のうち 2 つ、ユーザーのデバイスにローカルに保存されているキー (パスキーの可能性があります)、およびプロバイダーが保持するバックアップ キーに zk-email を使用することです。ユーザーが経験を積んだり資産を蓄積したりすると、署名者を追加するよう求められる場合があります。
仮想通貨以外のユーザーを引きつけようとするアプリは、ユーザーに 2 つの新しいアプリ (アプリ自体とイーサリアム ウォレット) を同時にダウンロードさせることで悪いユーザー エクスペリエンスを生み出すことを望まないため、ウォレットをアプリに統合することは避けられません。複数のウォレットを使用するユーザーは、「アクセス制御の問題」だけを心配する必要があるように、すべてのウォレットを相互に接続できる必要もあります。最も簡単なアプローチは、階層化アプローチを使用することです。ユーザーは、簡単な「リンク」プロセスを通じて、メインのウォレットをすべてのアプリ内ウォレットの署名者として設定できます。現在、Farcaster クライアント Warpcast はすでにこのメソッドをサポートしています。
デフォルトでは、Warpcast アカウントの回復は Warpcast チームによって制御されます。ただし、ユーザーは Farcaster アカウントを「引き継ぎ」、それを自分のアドレスに変更することができます。
詐欺やその他の外部の脅威からユーザーを保護する
アカウントのセキュリティに加えて、今日のウォレットは偽のアドレス、フィッシング、詐欺、その他の外部の脅威を特定し、そのような脅威からユーザーを保護するために熱心に取り組んでいます。しかし、多くの対策はまだ非常に原始的です。たとえば、100 ドルまたは 100,000 ドルを送金する場合でも、クリックするだけで ETH またはその他のトークンを新しいアドレスに送金できます。この点に関しては単一の解決策はなく、さまざまな種類の脅威に対してゆっくりと継続的に一連の修正と改善が行われます。ただし、改善の努力を続けることには大きな価値があります。
プライバシー
ZK-SNARK テクノロジーは非常に進歩しており、バックドアに依存せずに規制リスクを軽減できるプライバシープールなどのプライバシー テクノロジーも、 Wakuや ERC-4337 など、徐々に安定してきています。しかし、これまでイーサリアムでプライベート送金を行うには、ユーザーは鉄道(ステルス アドレスの場合はUmbra ) などの「プライベート ウォレット」を明示的にダウンロードして使用する必要がありました。このことは、利用者にとって多大な不便をもたらし、また、そのような利用者の数を減少させることになる。この問題の解決策は、そのような送金をウォレットに直接統合することです。
簡単な実装方法は、ウォレットがユーザーの資産の一部を「プライベート残高」としてプライバシープールに保存できることです。ユーザーが送金を行うと、まずプライバシー プールから自動的に引き落とされます。ユーザーが資金を受け取る必要がある場合、ウォレットはステルス アドレスを自動的に生成します。さらに、ウォレットは、ユーザーが参加するアプリケーション（DeFi プロトコルなど）ごとに新しいアドレスを自動的に生成できます。入金はプライバシー プールから行われ、出金はプライバシー プールに直接送られます。このようにして、1 つのアプリでのユーザーのアクティビティは、他のアプリでのアクティビティから独立しています。
このテクノロジーの利点の 1 つは、資産転送のプライバシーだけでなく、ID 認識のプライバシーも実現できることです。現在、ID 認識はチェーン上に実装されており、本人確認を使用するアプリケーション (Gitcoin Grants など)、特定のトークンを必要とするチャット、およびEthereum Follow プロトコルはオンチェーン ID 認識です。私たちは、このエコシステムがプライベートであることを望んでいます。つまり、チェーン上のユーザーのアクティビティは 1 か所に収集されるべきではなく、各プロジェクトは個別に保存されるべきであり、ユーザーのウォレットだけが「グローバル ビュー」を持つべきです。 " を使用すると、すべての証明を同時に見ることができます。 EASやZupassなどのオフチェーン認証プロトコルと同様、ユーザーごとに複数のアカウントのネイティブ エコシステムがこの目標の達成に役立ちます。
これは、中期的なイーサリアムのプライバシーに対する実用的なビジョンを表しています。現在でも実装できますが、L1 および L2 段階でいくつかの機能を導入すると、プライバシー保護トランザクションがより効率的かつ信頼性の高いものになります。プライバシー擁護者の中には、すべてが完全にプライベートであり、EVM 全体が暗号化されることだけが許容されると信じている人もいます。しかし、これはおそらく長期的に望ましい結果であり、プログラミング モデルのより根本的な再考が必要であり、イーサリアムにデプロイできるほどまだ成熟していないと思います。十分な匿名性を実現するには「デフォルトのプライバシー」が必要です。ただし、アカウント間の送金のプライバシー、およびアイデンティティとアイデンティティ関連のユースケースに焦点を当てることは、実装が容易であり、この段階でウォレット用に構築できる実用的な最初のステップです。
イーサリアムウォレットはデータウォレットでもある必要がある
支払い、識別、その他のユースケースのいずれであっても、効果的なプライバシー ソリューションでは、ユーザーはオフチェーン データを保存する必要があります。これはトルネード キャッシュで明らかであり、ユーザーは 0.1 ～ 100 ETH のデポジットを表す各「メモ」を保存する必要があります。また、より最新のプライバシー プロトコルでは、暗号化されたデータをオンチェーンに保存し、単一の秘密キーを使用して復号化する場合があります。ただし、鍵が漏洩したり、量子コンピュータが可能になったりすると、データはすべて公開されてしまうため、これは危険です。それまでに、EAS や Zupass などのオフチェーン認証用のオフチェーン データ ストレージの必要性がより明確になるでしょう。
ウォレットは、チェーン上のアクセス権を保存するだけでなく、個人データも保存するソフトウェアである必要があります。これは、暗号通貨以外の世界でもますます認識されてきています。個人データ ストレージに関するティム バーナーズ リーの最近の研究をご覧ください。私たちが解決する必要があるすべての問題は、アクセス権の制御を効果的に確保するだけでなく、データのアクセス性と漏洩の防止も効果的に保証する必要があります。おそらく、これら 2 つのソリューションを積み重ねることができます。N 人の複数署名者を設定すると仮定すると、これらの N 人の署名者の間で M-of-N の秘密共有を使用してデータを保存できます。他人によるデータの共有を取り消すことができないため、データの安全性を確保することは本質的により困難ですが、可能な限り安全な分散型ホスティング ソリューションを考案する必要があります。
安全なブロックチェーンアクセス
多くのウォレットは、RPC プロバイダーを信頼してチェーンに関する情報を伝えます。これには 2 つの点で欠陥があります。まず、RPC プロバイダーは、虚偽の情報 (市場価格など) を提供して資金を盗もうとする可能性があります。第 2 に、RPC プロバイダーは、ユーザーがどのアプリや他のアカウントとやり取りするかについての個人情報を抽出する可能性があります。
理想的には、これら 2 つの脆弱性の発生を防ぐ必要があります。最初の脆弱性を防ぐには、ブロックチェーンのコンセンサスを直接検証する標準化された L1 および L2 ライト クライアントが必要です。 Helios はこの機能を L1 に実装しており、特定の L2 をサポートするためにいくつかの初期作業が行われています。すべての L2 を適切にカバーするには、L2 を表す構成コントラクト (特定のチェーン アドレスの場合も同様) が、最大限の効果を得る機能を含む関数を (おそらくERC-3668と同様の方法で) 公開できる標準が必要です。最近の状態のルート ロジックを作成し、これらの状態のルートに対して状態の証明書と領収書を検証します。このようにして、ウォレットが L1 と L2 上のあらゆる状態やイベントを安全に検証できるユニバーサル ライト クライアントを構築できます。
2 番目の脆弱性に関しては、現時点で唯一実現可能な方法は、独自のフルノードを実行することです。ただし、L2 の普及が進むにつれて、すべてを含めた完全なノードを実行することがますます困難になってきます。この問題に対処するためのライト クライアントと同等のソリューションは、 Private Information Retrieval (PIR) です。 PIR には、すべてのデータのコピーを保持するサーバーと、暗号化されたリクエストをサーバーに送信するクライアントが含まれます。サーバーはすべてのデータに対して計算を実行し、クライアントがアクセスしたデータをサーバーに明らかにすることなく、クライアントが必要とするデータ (クライアントのキーで暗号化された) を返します。
サーバーが正直であるためには、個々のデータベース項目自体がマークル ツリー ブランチである必要があり、クライアントは独自のライト クライアントを使用してそれらを検証できます。
PIR は計算コストが高くなりますが、この問題に対処する方法はいくつかあります。
ブルート フォース:アルゴリズムや特殊なハードウェアの改善により、PIR を十分に高速に実行できる可能性があります。これらの手法は前処理に依存する場合があり、サーバーは各クライアントの暗号化およびシャッフルされたデータを保存し、クエリを実行できます。イーサリアム環境における主な課題は、これらのテクノロジーを急速に変化する (状態変化など) データセットにどのように適応させるかです。これにより、リアルタイム コンピューティングのコストは削減されますが、コンピューティングとストレージの総コストは増加する可能性があります。
プライバシー要件の緩和:たとえば、クエリごとに存在できる「ミックスイン」は 100 万個のみであるため、サーバーはクライアントがアクセスできる 100 万個の可能な値を認識しますが、より細かい粒度は認識しません。
マルチサーバー PIR:複数のサーバーが使用され、これらのサーバー間の誠実さが 1-of-N であると仮定される場合、通常、PIR アルゴリズムははるかに高速になります。
機密性ではなく匿名性:リクエストはハイブリッド ネットワーク経由で送信でき、リクエストの内容を隠すのではなく、リクエストの送信者を隠すことができます。ただし、そうすると必然的に遅延が増加し、ユーザー エクスペリエンスが低下します。
イーサリアム環境では、実用性を維持しながらプライバシー保護を最大限に高めることができるテクノロジーの組み合わせを見つけることは未解決の研究テーマであり、暗号学者はそれを試すことを歓迎します。
理想的な鍵収納ウォレット
トランスポートと状態へのアクセスに加えて、L2 環境全体でスムーズに実行する必要があるもう 1 つの重要なワークフローは、アカウントの認証構成の変更 (キーの変更であれ、アカウントのロジック全体へのより深い変更であれ) です。以下に、難易度が高くなる 3 層のソリューションを示します。
更新の再生: ユーザーが構成を変更すると、ユーザーが資産を所有していることをウォレットが検出したすべてのチェーンで認可変更メッセージが再生されます。メッセージ形式と検証ルールはチェーンに依存しないため、できるだけ多くのチェーンで自動的に再生できます。
L1 のキーストレージ: 構成情報は L1 に保存され、L2 のウォレットはL1SLOADまたはREMOTESTATICCALLを通じて構成情報を読み取ります。この方法では、L1 の構成を更新するだけで、構成が自動的に有効になります。
L2 上のキーストレージ: 構成情報は L2 に保管され、L2 上のウォレットは ZK-SNARK を通じて構成情報を読み取ります。これはケース (2) と同じですが、キー ストレージの更新の方が安く、読み取りの方が高価である点が異なります。
3 番目のソリューションは、プライバシーとうまく両立するため、特に強力です。通常の「プライバシー ソリューション」では、ユーザーが秘密 s を持っており、チェーン上に「リーフ値」 L を公開すると仮定します。ユーザーは、L = hash(s,1) および N = hash(s,2) であることを証明します。その制御の秘密 (決して公開されません)。 N は、同じリーフへの将来の支出が失敗せず、L が漏洩しないことを保証するために公開されます。アカウントの回復に適したプライバシー ソリューションでは、s はチェーン上の場所 (アドレスやストレージ スロットなど) であり、ユーザーはステータス クエリ、つまり L = hash(sload(s), 1)。
DApp のセキュリティ
ユーザーのセキュリティにおいて最も弱い部分は多くの場合 DApp です。ほとんどの場合、ユーザーは Web サイトにアクセスしてアプリケーションを操作します。Web サイトはユーザー インターフェイス コードをサーバーからリアルタイムでダウンロードし、ブラウザーで実行します。サーバーがハッキングされたり、DNS がハッキングされたりすると、ユーザーはインターフェイスの偽のコピーを取得し、ユーザーをだまして任意の操作を実行させる可能性があります。取引シミュレーションなどのウォレット機能はリスクを軽減するのに役立ちますが、それだけでは十分ではありません。
理想的には、エコシステムをオンチェーン コンテンツ バージョンに移行する必要があります。このバージョンでは、ユーザーは、インターフェイスの IPFS ハッシュを含む ENS 名を通じて DApp にアクセスします。インターフェイスを更新するには、マルチ ID または DAO からのオンチェーン トランザクションが必要です。ウォレットは、ユーザーがより安全なオンチェーン インターフェイスを使用しているか、安全性の低い Web2 インターフェイスを使用しているかを表示します。ウォレットは、ユーザーが安全なブロックチェーンと対話しているかどうかを示すこともできます (ステージ 1+、複数のセキュリティ監査など)。
プライバシーを重視するユーザーにとって、ウォレットは少し厳しくなり、ユーザーが Web3 操作だけでなく HTTP リクエストをクリックして受け入れる必要がある場合もあります。
より高度なアプローチは、HTML + Javascript を超えて、Solidity や Vyper に比較的軽量な言語をオーバーレイするなど、専用言語で DApp のビジネス ロジックを記述することです。このようにして、ブラウザは必要な機能のユーザー インターフェイスを自動的に生成できます。 OKContract はすでにこれを行っています。もう 1 つの方向は、暗号化された経済情報の防御です。つまり、DApp 開発者、セキュリティ会社、オンチェーン展開者などがデポジットを設定できます。DApp がハッキングされた場合、または非常に誤解を招く方法でユーザーに損害を与えた場合、デポジットはその後に行われます。オンチェーン裁定DAOが決定を下した場合、影響を受けるユーザーに支払いが行われます。ウォレットはマージンサイズに基づいてユーザーに評価を表示できます。
長期的な将来
上記はすべて従来のコンテキストで行われており、現在、モデルが大幅に変更されようとしています。
人工知能 (AI) は、私たちを「クリックしてタイプする」モデルから「言うとボットが理解する」モデルに変えるかもしれません。
ブレイン コンピューター インターフェイス: 視線追跡などの比較的「穏やかな」方法だけでなく、より直接的でさらに侵襲的な技術 ( 最初の Neuralink 患者など) も含まれます。
プロアクティブな防御におけるクライアント側の関与: Brave Browser は、広告、トラッカー、その他多くの不要なオブジェクトからユーザーをプロアクティブに保護します。多くのブラウザ、プラグイン、暗号通貨ウォレットでは、チーム全体がさまざまなセキュリティやプライバシーの脅威からユーザーを保護するために積極的に取り組んでいます。今後10年で、こうした「現役守護者」はさらに強力になるだろう。
これら 3 つの傾向を総合すると、ウォレットの仕組みについてのより深い再考が促されるでしょう。自然言語入力、視線追跡、または最終的にはより直接的な生体認証 (BCI) と、ユーザーの履歴の知識を組み合わせることで、「ウォレット」はユーザーが何をしたいのかを直感的に正確に知ることができます。 AI は、ユーザーの意図を達成するために、この直感を一連のオンチェーンおよびオフチェーンのインタラクションなどの特定の「アクション プラン」に変換します。これにより、サードパーティのユーザー インターフェイスの必要性が大幅に軽減されます。ユーザーがサードパーティのアプリ (または他のユーザー) と対話する場合、AI はユーザーに代わって敵対的に考え、脅威を特定し、それらを回避するための行動計画を提案する必要があります。理想的には、これらの AI は、異なるバイアスとインセンティブ構造を持つ異なるグループによって生成される、オープンなエコシステムを形成します。
もちろん、これらのより過激なアイデアは、現在非常に未熟なテクノロジーに依存しているため、私はこれらのテクノロジーに依存するウォレットに資産を置きません。ただし、この種のテクノロジーは将来のトレンドであると思われるため、この方向でより積極的に検討を開始する価値があります。
