元のタイトル：私がウォレットで見たいと思うこと
著者：Vitalik、イーサリアム創設者；編纂：邓通、金色财经
特に Liraz Siri、Yoav Weiss、そして ImToken、Metamask、OKX の開発者たちのフィードバックとレビューに感謝します。
イーサリアムインフラストラクチャスタックの重要なレイヤーはウォレットですが、しばしばコア L1 研究者や開発者に過小評価されています。ウォレットはユーザーとイーサリアムの世界との間の窓口であり、ユーザーはイーサリアム及びそのアプリケーションが提供するいかなる分散型、検閲抵抗、安全性、プライバシー、またはその他の属性から利益を得ることができますが、それはウォレット自体にもこれらの属性が必要です。
最近、私たちはイーサリアムウォレットがユーザー体験、安全性、機能の改善において大きな進展を遂げているのを見ています。この記事の目的は、理想的なイーサリアムウォレットが具備すべき特徴について私自身の見解を示すことです。これは完全なリストではなく、私の暗号パンク的な傾向を反映しており、安全性とプライバシーに焦点を当てており、ユーザー体験の観点では不完全であることはほぼ確実です。しかし、私は、欲求リストがユーザー体験を最適化するのに役立つよりも、単にフィードバックに基づいて展開と反復を行うことがより有効であると考えているため、安全性とプライバシーの属性に焦点を当てることが最も価値があると信じています。
L2間の取引のユーザー体験
現在、L2間のユーザー体験を改善するためのますます詳細なロードマップがあり、短期的な部分と長期的な部分があります。ここでは、短期的な部分について話します：今日の理論的に実施可能なアイデアです。
コアのアイデアは (i) L2 間送信を内蔵し、(ii) チェーン特有のアドレスと支払いリクエストです。あなたのウォレットは、次のようなアドレスを提供することができるはずです（この ERC 草案のスタイルに従って）：
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
誰か（または特定のアプリケーション）がこの形式のアドレスを提供した場合、あなたはそれをウォレットの「受取人」フィールドに貼り付け、「送信」をクリックすることができるはずです。ウォレットは、送信されたデータを可能な限り自動的に処理すべきです：
あなたが目的のチェーン上ですでに必要なタイプのトークンを十分に持っている場合、直接トークンを送信してください；
もしあなたが別のチェーン（または複数の他のチェーン）上に必要なタイプのトークンを持っている場合、ERC-7683（実際にはクロスチェーン DEX）などのプロトコルを使用してトークンを送信してください；
同じチェーンまたは他のチェーンに異なるタイプのトークンがある場合、分散型取引所を使用してそれらを正しいチェーン上の正しいタイプのトークンに変換して送信してください。これにはユーザーの明示的な許可が必要です：ユーザーは、彼らがいくらの手数料を支払ったか、受取人がいくらの手数料を受け取ったかを見ることができるでしょう。
クロスチェーンアドレスサポートを持つ可能なウォレットインターフェースモデル
上述の内容は、「あなたがアドレス（または ENS、たとえば、vitalik.eth@optimism.eth）をコピーして貼り付けて、誰かがあなたに支払うための」ユースケースに適用されます。もし dapp が預金をリクエストする場合（たとえば、Polymarket の例を参照）、理想的なプロセスは web3 API を拡張し、dapp がチェーン固有の支払いリクエストを発行できるようにすることです。そうすれば、あなたのウォレットは必要な任意の方法でそのリクエストを満たすことができるでしょう。ユーザー体験を良好にするためには、getAvailableBalance リクエストを標準化する必要があり、ウォレットはユーザー資産をどのチェーンにデフォルトで保存するかを真剣に考慮する必要があります。これにより、安全性と送金の便宜を最大化します。
チェーン固有の支払い要求も QR コードに埋め込むことができ、モバイルウォレットが QR コードをスキャンできます。対面（またはオンライン）での消費者の支払いシーンでは、受取人が「私はチェーン Z 上の X 単位のトークン Y が必要で、参照 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）アイデンティティおよびアイデンティティに関連するユースケース（たとえば、プライベート証明）に焦点を当てることは実用的な第一歩であり、より実現可能であり、ウォレットは今すぐ使用を開始できます。
イーサリアムウォレットもデータウォレットになる必要があります
任意の有効なプライバシー解決策の一つの結果は、支払い、アイデンティティ、または他のユースケースに使用される場合、ユーザーがチェーン外でデータを保存する必要があることです。これはトルネードキャッシュで非常に明白で、ユーザーは0.1-100 ETH の預金を代表する「領収書」を保存する必要があります。より現代的なプライバシープロトコルは時にはチェーン上に暗号データを保存し、単一の秘密鍵でそれを復号化します。これはリスクがあります。なぜなら、鍵が漏洩した場合や量子コンピュータが実用化された場合、データはすべて公開されるからです。EAS や Zupass などのオフチェーン証明は、チェーン外データストレージの必要性をさらに明確に示しています。
ウォレットは、単にチェーン上のアクセスを保管するソフトウェアであるだけでなく、あなたのプライベートデータを保管するソフトウェアにもなる必要があります。非暗号化の世界でも、たとえば、ティム・バーナーズ＝リーが最近行った個人データの保存に関する仕事のように、これに気づくようになっています。私たちがアクセス制御を確保するために解決する必要がある問題の周りに、私たちはデータのアクセス可能性と漏洩のないことを確保する問題の周りにも取り組む必要があります。もしかしたら、これらの解決策は組み合わさるかもしれません：あなたが N 人の保護者を持っているなら、あなたのデータを保存するためにその N 人の保護者の間で M-of-N 秘密共有を使用してください。データは本質的に保護が難しくなります。なぜなら、誰かのデータのシェアを取り消すことができないからですが、私たちはできるだけ安全な分散型ホスティングソリューションを提案するべきです。
セキュアチェーンアクセス
今日、ウォレットは彼らの RPC プロバイダーがチェーンに関する任意の情報を伝えると信じています。これは脆弱性であり、二つの側面があります：
RPC プロバイダーは、彼らに偽の情報を提供することによってお金を盗もうとするかもしれません。たとえば、市場の価格に関する情報です
RPC プロバイダーは、ユーザーが相互作用しているアプリケーションや他のアカウントに関するプライベート情報を抽出することができます
理想的には、私たちはこの二つの脆弱性を塞ぎたいと考えています。最初の問題を解決するためには、L1 と L2 の標準化された軽量クライアントが必要で、これによりブロックチェーンコンセンサスを直接検証できます。Helios はすでに L1 のためにこれを実現しており、特定の L2 をサポートするためのいくつかの初期作業を行っています。すべての L2 を正しくカバーするためには、L2 を代表する契約が関数を宣言できる標準が必要です。おそらく ERC-3668 に似た方法で、最新の state roots を取得し、これらの州の state roots に基づいて証明とレシートを提供することができます。これにより、ウォレットが L1 と L2 上の任意の状態やイベントを安全に検証できる一般的な軽量クライアントを持つことができます。
プライバシーのために、今日の唯一現実的な方法はあなた自身の完全ノードを運営することです。しかし、今は L2 が人々の視界に入ってきており、すべてを運営する完全ノードを運営することがますます困難になっています。ここで軽量クライアントに相当するのはプライベート情報取得（PIR）です。PIR では、すべてのデータのコピーを保存するサーバーと、サーバーに暗号化されたリクエストを送信するクライアントが関与します。サーバーはすべてのデータに計算を実行し、クライアントが必要とするデータをクライアントの鍵に暗号化して返しますが、クライアントがどのデータにアクセスしたかはサーバーに明らかにしません。
サーバーの誠実さを保つために、各データベースプロジェクトは Merkle ブランチであるため、クライアントは軽量クライアントを使用してそれらを検証できます。
PIR の計算量は非常に大きいです。この問題を解決する方法はいくつかあります：
ブルートフォース：アルゴリズムまたは専用ハードウェアの改善により、PIR を十分に速く実行できるようになるかもしれません。これらの技術は事前処理に依存する可能性があります：サーバーは各クライアントのために暗号化されたシャッフルされたデータを保存し、クライアントはそのデータをクエリできます。イーサリアム環境における主な課題は、これらの技術を急速に変化するデータセット（国家のように）に適応させることです。これにより、リアルタイム計算コストは低くなりますが、総計算およびストレージコストは高くなる可能性があります。
プライバシー要求の緩和：たとえば、各検索では最大100万の「ミキシン」を持つことができるため、サーバーはクライアントがアクセスできる100万の可能な値を知ることができますが、他のより細かい粒度については知りません。
複数サーバー PIR：複数のサーバーを使用し、これらのサーバー間の誠実性仮定が 1-of-N の場合、PIR アルゴリズムは通常より速くなります。
匿名ではなく秘匿：リクエストは mixnet を通じて送信でき、リクエストの送信者を隠すことができますが、リクエストの内容を隠すことはできません。しかし、これを効果的に行うことは避けられない遅延を引き起こし、ユーザー体験を悪化させます。
イーサリアム環境でプライバシーを最大化しつつ実用性を維持するために正しい技術の組み合わせを見つけることはオープンな研究課題であり、暗号学者がそれを試みることを歓迎します。
理想的なキー管理庫ウォレット
送信と状態アクセスに加えて、L2間の文脈でスムーズに機能する必要があるもう一つの重要なワークフローは、アカウントの検証構成を変更することです：鍵を変更する場合（たとえば、復元）、またはアカウントの全体的なロジックをより深く変更する場合です。ここには、難易度が増す順に三つの層の解決策があります：
リプレイ更新：ユーザーが構成を変更すると、ユーザーが資産を持っている各チェーンでこの変更を許可するメッセージがウォレットでリプレイされます。可能な限り、メッセージ形式と検証ルールはチェーンに独立しているため、できるだけ多くのチェーンで自動的にリプレイ可能です。
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 の安全を保証することに依存します。回復に優しいプライバシー解決策は、s がチェーン上の位置（たとえばアドレスやストレージスロット）であり、ユーザーが状態クエリを証明する必要があると言います： L = hash(sload(s), 1) 。
Dapp セキュリティ
ユーザーのセキュリティで最も脆弱なリンクは通常 dapp です。ほとんどの場合、ユーザーはウェブサイトを介してアプリケーションと対話し、ウェブサイトは暗黙的にサーバーからユーザーインターフェースコードをリアルタイムでダウンロードし、ブラウザで実行します。サーバーがハッキングされたり、DNS がハッキングされたりすると、ユーザーはインターフェースの偽のコピーを受け取り、これがユーザーに任意の操作を実行させる可能性があります。取引シミュレーションなどのウォレット機能はリスクを軽減するのに非常に役立ちますが、彼らはまだ完璧にはほど遠いです。
理想的には、私たちはエコシステムをチェーン上のコンテンツバージョン管理に移行させます：ユーザーはその ENS 名称を通じて dapp にアクセスし、その名前はインターフェースの IPFS ハッシュ値を含むことになります。インターフェースの更新には、マルチシグまたは DAO からのチェーン上の取引が必要です。ウォレットはユーザーに対して、より安全なチェーン上のインターフェースまたは安全性の低い Web2 インターフェースと相互作用しているかどうかを示すことができます。また、ウォレットはユーザーに対して安全なチェーンと相互作用しているかどうかを示すこともできます（たとえば、ステージ 1+、マルチセキュリティ監査など）。
プライバシーを重視するユーザーのために、ウォレットは偏執モードを追加し、ユーザーが web3 操作だけでなく HTTP リクエストを受け入れることをクリックするように要求することができます：
偏執モードの可能なインターフェースモデル
より高度なアプローチは、HTML + Javascript を超え、専用の言語（おそらく Solidity または Vyper の上に相対的に薄いカバー層）で dapp のビジネスロジックを書くことです。そうすれば、ブラウザは必要な機能の UI を自動生成できます。OKContract はすでにこれを行っています。
もう一つの方向は、暗号経済情報の防御です：dapp 開発者、安全企業、チェーンデプロイヤーなどは、dapp がハッキングされたり、高度に誤解を招く方法でユーザーに害を及ぼした場合、その保証金が影響を受けたユーザーに支払われるように設定することができます。いくつかのチェーン上の裁定 DAO によって。ウォレットはユーザーにボンドのサイズに基づくスコアを表示できます。
より遠い未来
以上はすべて、指し示しクリックすることやテキストフィールドに事物を入力することを含む従来のインターフェースの文脈で行われています。しかし、私たちはまた、パラダイムがより深い変化を遂げる転換点に立っています：
人工知能は、クリック式入力のパラダイムから「やりたいことを言えば、ロボットが理解する」というパラダイムに移行する可能性があります；
脳-機械インターフェース、眼球追跡などの「穏やかな」方法や、より直接的または侵襲的な技術（参照：今年の最初の Neuralink 患者）も含まれます；
クライアントの能動的防御：Brave ブラウザは、ユーザーを広告、トラッカー、その他の悪質なオブジェクトから保護します。多くのブラウザ、プラグイン、暗号ウォレットには、ユーザーをさまざまなセキュリティとプライバシーの脅威から保護するために積極的に取り組むチームがあります。これらの「能動的な守護者」は、今後10年間でより強力になるでしょう。
これら三つの傾向は、インターフェースの動作方法についてのより深い再考を促すことにつながります。自然言語入力、眼球追跡、あるいは最終的にはより直接的な脳-機械インターフェース、さらにはあなたの履歴（おそらくSMSを含む、すべてのデータがローカルで処理される限り）を加えれば、「ウォレット」はあなたがやりたいことを明確に直感的に理解できます。その後、人工知能はこの直感を具体的な「行動計画」に変換できます：あなたがやりたいことを達成するための一連のオンチェーンおよびオフチェーンの相互作用です。これにより、第三者のユーザーインターフェースに対する需要を大幅に減らすことができます。もしユーザーが実際に第三者アプリケーション（あるいは他のユーザー）と相互作用する場合、人工知能はユーザーの代わりに対抗的思考を行い、あらゆる脅威を特定し、脅威を回避するための行動計画を提案すべきです。理想的には、これらの人工知能は異なるバイアスとインセンティブ構造を持つ異なるグループによって生成されるオープンなエコシステムを持つべきです。
これらのより過激なアイデアは、今日の非常に未熟な技術に依存しているため、私は今日、これらに依存するウォレットに資産を置くつもりはありません。しかし、類似のものが未来のトレンドであることは明らかであり、したがってこの方向により積極的に探求する価値があります。
