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