Vitalikの新技術論文：理想のウォレットのビジョン――クロスチェーン体験からプライバシー保護までの包括的アップグレード
TechFlow厳選深潮セレクト
Vitalikの新技術論文：理想のウォレットのビジョン――クロスチェーン体験からプライバシー保護までの包括的アップグレード
ウォレットはユーザーとイーサリアム世界をつなぐ窓口であると考えており、セキュリティとプライバシーの特性に注目することが最も価値があると思います。
Web3業界の深掘り報道に専念し潮流を洞察Liraz Siri、Yoav Weiss、ImToken、Metamask および OKX の開発者の方々からのフィードバックとレビューに深く感謝します。
イーサリアムインフラスタックの重要なレイヤーの一つがウォレットですが、これはコアな L1 研究者や開発者によってしばしば軽視されています。ウォレットはユーザーとイーサリアム世界との間の窓であり、ユーザーがイーサリアムおよびそのアプリケーションから提供される分散化、検閲耐性、セキュリティ、プライバシーなどの恩恵を受けるには、ウォレット自体もこれらの属性を持っている必要があります。
最近、イーサリアムウォレットはユーザーエクスペリエンス、セキュリティ、機能の面で大きな進展を見せています。本稿では、理想的なイーサリアムウォレットが備えるべきと考えられるいくつかの特性について、私の見解を述べます。これは完全なリストではなく、私のサイファーパンク的な傾向を反映しており、セキュリティとプライバシーに重点を置いており、ユーザーエクスペリエンスの観点からは明らかに不十分です。しかし、私はUXの最適化において、願望のリストよりもフィードバックに基づくデプロイと反復がはるかに効果的だと考えているため、セキュリティとプライバシーの属性に焦点を当てることが最も価値があると考えます。
L2間トランザクションのユーザーエクスペリエンス
現在、L2間のユーザーエクスペリエンスを改善するための詳細なロードマップが存在し、短期的要素と長期的要素に分かれています。ここでは、短期的な部分、つまり今日理論上でも実装可能なアイデアについて述べます。
中心となる考え方は（i）L2間送信の内蔵サポートと（ii）チェーン固有のアドレスおよび支払いリクエストです。あなたのウォレットは、以下のような形式（このERC草案に準拠したスタイル）のアドレスを提供できるべきです：
誰か（または何らかのアプリケーション）があなたにこのような形式のアドレスを提供した場合、それをウォレットの「送信先」フィールドにペーストして、「送信」をクリックするだけで済みます。ウォレットは可能な限り自動的に以下の処理を行います：
-
目的のチェーン上で必要な種類のトークンがすでに十分にある場合、直接トークンを送信
-
他のチェーン（または複数のチェーン）に必要な種類のトークンがある場合、ERC-7683などのプロトコル（実質的にはクロスチェーンDEX）を使用してトークンを送信
-
同じチェーンまたは他のチェーンで異なる種類のトークンを持っている場合、分散型取引所を使ってそれらを正しいチェーン上の正しい種類の通貨に変換して送信。これはユーザーの明示的な承認を必要とすべきです：ユーザーは自分が支払った手数料と受取人が受け取った金額を確認できます。
L2間アドレス対応可能ウォレットインターフェースのモデル
上記は、「あなたがアドレス（またはENS、例：vitalik.eth@optimism.eth）をコピー・ペーストして、誰かがお金を支払う」というユースケースに適用されます。dAppが預け入れを要求する場合（例：このPolymarketの例を参照）、理想的なフローはweb3 APIを拡張し、dAppがチェーン固有の支払いリクエストを発行できるようにすることです。その後、あなたのウォレットはそのリクエストを満たすために必要な手段で対応できます。良好なユーザーエクスペリエンスを得るには、getAvailableBalance リクエストの標準化も必要であり、またウォレットはユーザー資産をどのチェーンにデフォルトで保存するかを真剣に考える必要があります。これにより、安全性と送金の利便性が最大化されます。
チェーン固有の支払いリクエストはQRコードにも埋め込め、モバイルウォレットがスキャンできます。対面またはオンラインでの消費者支払いシーンでは、受取人がQRコードまたはweb3 API呼び出しを発行し、「Zチェーン上でX単位のYトークンをWという参照IDまたはコールバック付きで欲しい」と表明します。ウォレットはそのリクエストを満たす自由な方法を持ちます。もう一つの選択肢はclaimリンクプロトコルで、ユーザーのウォレットが、自分のチェーン上コントラクトから一定量の資金を引き出す権限を含むQRコードまたはURLを生成し、受取人の役割はそれらの資金を自分のウォレットに移動させる方法を見つけることです。
関連するもう一つのテーマはガス代の支払いです。まだETHを持っていないL2で資産を受け取り、そのL2上でトランザクションを送信する必要がある場合、ウォレットはRIP-7755などのプロトコルを自動的に使用して、ETHがある場所のチェーンでガス代を支払えるべきです。もしウォレットが将来そのL2でより多くのトランザクションを行うことを想定しているなら、例えば数百万ガス相当のETHをDEXを通じて送ることで、将来的なトランザクションが直接そこでガスを消費できるようにすべきです（こうすることでコストが安くなるため）。
アカウントセキュリティ
アカウントセキュリティの課題を捉える私の方法の一つは、良いウォレットが二つの側面で機能すべきであるということです。（i）ウォレット開発者のハッキングや悪意行為からユーザーを守り、（ii）ユーザー自身のミスからユーザーを守る。
左の「エラー」は無意識のものです。しかし、これを目にしたとき、文脈にぴったりだと感じたので、そのまま残すことにしました。
私が好む解決策——10年以上前から提唱してきた——は、ソーシャルリカバリーと多重署名ウォレットであり、階層的アクセス制御を備えています。ユーザーのアカウントは二層の鍵を持ちます：メイン鍵とN個のガーディアン（例：N=5）。メイン鍵は低価値かつ非財務的な操作を実行できます。高価値の操作（例：アカウント内の全資産の送信）や、メイン鍵やガーディアンの変更などは、多数のガーディアンの合意が必要です。必要であれば、メイン鍵がタイムロックを通じて高価値操作を実行できるようにすることも可能です。
以上が基本設計であり、拡張可能です。セッション鍵やERC-7715などの権限管理メカニズムは、さまざまなアプリケーションにおける使いやすさとセキュリティのバランスを支援できます。異なるしきい値で複数のタイムロック期間を持つより複雑なガーディアン構造は、正当なアカウントの回復成功率を最大化しつつ、盗難リスクを最小化するのに役立ちます。
以上が基本設計であり、拡張可能です。セッション鍵や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アカウントを「引き継ぐ」ことができ、リカバリを自分のアドレスに変更できます。
ユーザーを詐欺やその他の外部脅威から保護する
アカウントセキュリティに加えて、今日のウォレットは偽アドレス、フィッシング、詐欺、その他の外部脅威を識別し、ユーザーをそれらから保護するために多くの作業を行っています。一方で、多くの対策は依然として原始的です。例えば、100ドル送る場合も10万ドル送る場合も、ETHや他のトークンを新しいアドレスに送る際にはクリックが必要になるといった具合です。ここには万能の解決策はありません。さまざまなカテゴリの脅威に対する一連のゆっくりとした持続的な修正と改善です。しかし、ここでの改善努力には大きな価値があります。
プライバシー
今こそ、イーサリアムのプライバシーをより真剣に扱い始めるべき時期です。ZK-SNARK技術はすでに非常に進歩しており、規制リスクを下げる後門に依存しないプライバシーテクノロジー（例：プライバシープール）はますます成熟しています。また、WakuやERC-4337 mempoolのような第2層インフラも徐々に安定してきています。しかし、現状ではイーサリアム上でプライベート送金を行うには、ユーザーが明示的に「プライバシーウォレット」（例：Railway、またはステルスアドレス用のUmbra）をダウンロードして使用する必要があります。これは極めて不便であり、プライベート送金を行う人の数を減らしています。解決策はプライベート送金をウォレットに直接統合することです。
簡単な実装例を以下に示します。ウォレットはユーザー資産の一部を「プライベート残高」としてプライバシープールに保存できます。ユーザーが送金を行う際は、まず自動的にプライバシープールから出金します。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的にステルスアドレスを生成できます。
さらに、ウォレットはユーザーが参加する各アプリケーションに対して自動的に新しいアドレスを生成できます（例：DeFiプロトコル）。預け入れはプライバシープールから行われ、引き出しは直接プライバシープールに行われます。これにより、ユーザーの一つのアプリケーションでの活動と他のアプリケーションでの活動を切り離すことができます。
この技術の利点は、プライバシー保護された資産移転だけでなく、プライバシー保護されたアイデンティティの自然な手段でもあることです。アイデンティティはすでにオンチェーンで発生しています。身分証明ゲート付きのアプリ（例：Gitcoin Grants）、トークンゲート付きチャット、イーサリアムフォロープロトコルなど、すべてがオンチェーンアイデンティティです。我々はこのエコシステムもプライバシーを保護することを望んでいます。つまり、ユーザーのオンチェーン活動が一箇所に集約されてはいけません。各プロジェクトは個別に保存され、ユーザーのウォレットだけがすべての証明を一度に見ることができる「全体像」を持つべきです。各ユーザーが複数のアカウントを持つネイティブなエコシステムはこの目標に貢献し、EASやZupassなどのオフチェーン証明プロトコルも同様です。
これは中期内のイーサリアムプライバシーの現実的なビジョンを表しています。L1やL2にいくつかの機能を導入することでプライバシー保護送金をより効率的かつ信頼性高くできるかもしれませんが、これはすでに実現可能です。一部のプライバシー擁護者は、すべてのものに完全なプライバシーしかないことが唯一許容されると考えます。つまり、EVM全体を暗号化することです。これは理想的な長期的結果かもしれませんが、プログラミングモデルのより根本的な再考が必要であり、現時点ではイーサリアムに展開可能な成熟度には達していません。確かに十分に大きな匿名セットを得るにはデフォルトのプライバシーが必要です。しかし、まず（i）アカウント間の送金と（ii）アイデンティティおよびそれに関連するユースケース（例：プライベート証明）に注力することは、現実的で実現しやすく、ウォレットが今すぐ始められる第一歩です。
イーサリアムウォレットはデータウォレットにもなるべき
あらゆる有効なプライバシー解決策の帰結として、支払い、アイデンティティ、その他の用途にかかわらず、ユーザーがオフチェーンデータを保存する必要が生じます。これはTornado Cashで明らかで、ユーザーは0.1〜100ETHの預け入れごとに「チケット」と呼ばれるものを保存しなければなりません。より現代的なプライバシープロトコルは、時としてチェーン上に暗号化されたデータを保存し、単一の秘密鍵で復号します。これはリスクがあります。鍵が漏洩したり、量子コンピュータが実用可能になった場合、データがすべて公開されるからです。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（TechFlow注：通常「プライベート情報検索（Private Information Retrieval）」を指し、データベースから情報を検索する際に、検索内容を漏らさずに取得できるプロトコルまたは技術）の計算負荷は非常に大きいです。この問題を解決するにはいくつかのアプローチがあります：
-
力技：アルゴリズムや専用ハードウェアの改良により、PIRを十分に高速に実行できる可能性があります。これらの技術は前処理に依存するかもしれません。サーバーは各クライアントのために暗号化されシャッフルされたデータを保存し、クライアントはそのデータを照会できます。イーサリアム環境における主な課題は、国家のように急速に変化するデータセットにこれらの技術を適応させることです。これによりリアルタイム計算コストは低くなりますが、総計算およびストレージコストは高くなる可能性があります。
-
プライバシー要件の緩和：例として、各検索につき100万の「mixin」しか許可されず、サーバーはクライアントがアクセス可能な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)であることを証明します（sは決して公開されない）。Nは無効化子として公開され、同じリーフの将来の支出が失敗することを保証しつつ、Lを漏らさず、sの安全性に依存します。リカバリに優しいプライバシー解決策はこう言います：sはオンチェーンの位置（例：アドレスとストレージスロット）であり、ユーザーはL = hash(sload(s), 1)であることを証明しなければなりません。
dAppセキュリティ
ユーザーセキュリティにおける最も脆弱な環は通常dAppです。ほとんどの場合、ユーザーはWebサイトを通してアプリケーションとやり取りし、サイトは暗黙的にサーバーからリアルタイムでユーザーインターフェースコードをダウンロードし、ブラウザで実行します。サーバーがハッキングされたり、DNSがハッキングされたりすると、ユーザーは偽のインターフェースのコピーを受け取り、任意の操作を誘導される可能性があります。トランザクションシミュレーションなどのウォレット機能はリスク低下に非常に役立ちますが、まだ完璧ではありません。
理想的には、エコシステムをオンチェーンコンテンツバージョニングに移行すべきです。ユーザーはENS名でdAppにアクセスし、それがインターフェースのIPFSハッシュを含みます。インターフェースの更新にはマルチシグまたはDAOからのオンチェーントランザクションが必要です。ウォレットはユーザーに、より安全なオンチェーンインターフェースと安全性の低いWeb2インターフェースのどちらとやり取りしているかを表示できます。ウォレットはまた、ユーザーが安全なチェーン（例：ステージ1+、複数のセキュリティ監査）とやり取りしているかどうかも表示できます。
プライバシー志向のユーザー向けに、ウォレットは**偏執モード（paranoid mode）**を追加でき、web3操作だけでなくHTTPリクエストもユーザーのクリック承認を要求します：
偏執モードの可能なインターフェースモデル
より高度なアプローチはHTML + Javascriptを超え、dAppのビジネスロジックを専用言語（おそらくSolidityやVyperの比較的薄いラッパー）で記述することです。その後、ブラウザは必要なすべての機能のUIを自動生成できます。OKContractはすでにこれを実現しています。
もう一つの方向性は暗号経済的情報防御です。dApp開発者、セキュリティ企業、チェーンデプロイヤーなどは、dAppがハッキングされたり、非常に誤解を招く形でユーザーに被害を与えた場合に、影響を受けたユーザーに支払われる（いくつかのオンチェーン裁定DAOによって確定された）保証金を設けることができます。ウォレットはユーザーに保証金の大きさに基づいたスコアを表示できます。
より遠い未来
以上はすべて、物事を指してクリックし、テキストフィールドに何かを入力するという従来のインターフェースの文脈で行われています。しかし、我々はパラダイムがより深く変化する瀬戸際に立っています：
-
人工知能。これは、クリックしてタイプするパラダイムから、「やりたいことを言うと、ロボットがそれを理解してくれる」パラダイムへと移行する可能性があります
-
ブレインマシンインターフェース。眼の動き追跡のような「穏やかな」方法から、より直接的で、場合によっては侵襲的な技術まで（例：今年初のNeuralink患者）
-
クライアント側の積極的防御。Braveブラウザは広告、トラッカー、その他の悪質な要素からユーザーを積極的に保護しています。多くのブラウザ、プラグイン、暗号ウォレットには、さまざまなセキュリティおよびプライバシー脅威からユーザーを守るために積極的に取り組んでいるチームがいます。こういった「積極的な守護者」は、今後10年間でさらに強力になっていくでしょう。
この三つのトレンドは、インターフェースの動作方法に対するより深い再考を促します。自然言語入力、眼球追跡、あるいは最終的にはより直接的なブレインマシンインターフェースに加え、ユーザーの履歴（おそらくローカル処理されるSMSを含む）を通じて、「ウォレット」はユーザーが何をしたいのかを明確かつ直感的に理解できます。その後、AIはその直感を具体的な「行動計画」に変換できます。つまり、ユーザーの望むことを達成するための一連のオンチェーンおよびオフチェーンのやり取りです。これにより、サードパーティのユーザーインターフェースへの依存が大幅に減少します。ユーザーが実際にサードパーティアプリケーション（または他のユーザー）とやり取りする場合、AIはユーザーを代表して敵対的な思考を行い、脅威を特定し、それらを回避する行動計画を提案すべきです。理想的には、こういったAIには、異なるバイアスとインセンティブ構造を持つさまざまなグループが生み出すオープンなエコシステムがあるべきです。
こうしたより急進的なアイデアは、今日の技術が非常に未熟であることに依存しているため、私は今のところ自分の資産をそれらに依存するウォレットに入れることはありません。しかし、似たようなことは明らかに将来のトレンドであるように思えるため、この方向に積極的に探求を始める価値があります。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
