著者: ヴィタリック・ブテリン

フィードバックとレビューを提供してくれた Liraz Siri、Yoav Weiss、および ImToken、Metamask、OKX の開発者に特別に感謝します。

コアの L1 研究者や開発者によって過小評価されがちなイーサリアムインフラストラクチャスタックの重要な層はウォレットです。ウォレットはユーザーとイーサリアムの世界との間の窓口であり、ユーザーは、ウォレット自体もそれらの属性を備えている場合にのみ、イーサリアムとそのアプリケーションによって提供される分散化、検閲耐性、セキュリティ、プライバシー、またはその他の属性から恩恵を受けることができます。

最近、イーサリアムウォレットがユーザーエクスペリエンス、セキュリティ、機能性の向上において大きな進歩を遂げていることがわかりました。この記事の目的は、理想的なイーサリアムウォレットが持つべき機能のいくつかについて私自身の意見を述べることにあります。これは包括的なリストではありません。これは私のサイファーパンクの傾向を反映しており、セキュリティとプライバシーに焦点を当てており、ユーザーエクスペリエンスの点ではほぼ確実に不完全です。ただし、ウィッシュリストはユーザーエクスペリエンスを最適化する上で、フィードバックに基づいて単に展開して反復するほど効果的ではないと思います。そのため、セキュリティとプライバシーの属性に焦点を当てることが最も価値があると考えています。

クロス L2 トランザクションのユーザーエクスペリエンス

現在、L2 全体のユーザーエクスペリエンスを向上させるための、短期部分と長期部分を含むロードマップがますます詳細になっています。ここでは短期的な部分、つまり今日でも理論的には実装可能なアイデアについて説明します。

中心的なアイデアは、(i) 組み込みのクロス L2 送信、および (ii) チェーン固有のアドレスと支払いリクエストです。あなたのウォレットは、次のようなアドレスを (この ERC ドラフトのスタイルに従って) 提供できるはずです。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

誰か (または何らかのアプリケーション) がこの形式でアドレスを提供した場合、それをウォレットの「宛先」フィールドに貼り付けて「送信」をクリックできるはずです。ウォレットは、送信されたデータを可能な限りの方法で自動的に処理する必要があります。

必要なタイプの十分なトークンがターゲットチェーンにすでにある場合は、トークンを直接送信します。
別のチェーン (または他の複数のチェーン) に目的のタイプのトークンがある場合は、ERC-7683 (実際にはクロスチェーン DEX) などのプロトコルを使用してトークンを送信します。
同じチェーンまたは他のチェーンに異なる種類のトークンがある場合は、分散型取引所を使用して、それらを適切なチェーン上の適切な種類の通貨に変換して送信します。これにはユーザーからの明示的な許可が必要です。ユーザーは自分が支払った金額と受信者が受け取った金額を確認できます。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

クロスチェーンアドレスをサポートする可能なウォレットインターフェイスのモデル

上記は、「アドレス (または ENS、例: Vitaik.eth @optimism.eth ) をコピー＆ペーストすると、誰かがあなたにお金を支払う」というユースケースのものです。 dapp がデポジットをリクエストする場合 (たとえば、この Polymarket の例を参照)、理想的なフローは、web3 API を拡張し、dapp がチェーン固有の支払いリクエストを行えるようにすることです。これにより、ウォレットは必要な方法でリクエストを満たすことができるようになります。優れたユーザーエクスペリエンスを実現するには、getAvailableBalanceリクエストも標準化する必要があり、ウォレットは、セキュリティと転送の利便性を最大化するために、ユーザー資産がデフォルトでどのチェーンに保存されるかを慎重に検討する必要があります。

チェーン固有の支払いリクエストを QR コードに入力して、モバイルウォレットでスキャンすることもできます。対面 (またはオンライン) の消費者支払いシナリオでは、受信者は QR コードまたは Web3 API 呼び出しを発行して、「参照 ID またはコールバック W を使用して、チェーン上に X ユニットのトークン YZ が必要です」と伝えます。このリクエストはどのような方法でもお気軽にお応えします。もう 1 つのオプションは、請求リンクプロトコルです。このプロトコルでは、ユーザーのウォレットがオンチェーン契約から一定量の資金を取得するための請求承認を含む QR コードまたは URL を生成し、それらの資金を次のユーザーに転送する方法を理解するのが受信者の仕事です。自分自身が財布の中に。

もう 1 つの関連トピックは、ガソリンの支払いです。 ETH をまだ持たない L2 で資産を受け取り、その L2 でトランザクションを送信する必要がある場合、ウォレットは自動的にプロトコル (RIP-7755 など) を使用してオンチェーンガスの支払いを行うことができる必要があります。 ETHを持っている場所。ウォレットが今後 L2 でさらに多くのトランザクションを実行することを望んでいる場合は、たとえば、DEX を使用してのみ送信する必要もあります。数百万のGas相当のETH。将来のトランザクションでGasを直接そこに費やすことができます（その方が安いため）。

アカウントのセキュリティ

私がアカウントセキュリティの課題を概念化する方法の 1 つは、優れたウォレットは 2 つのことを同時に実行する必要があるということです。 (i) ウォレット開発者によるハッキングや悪意のある攻撃からユーザーを保護すること、および (ii) 自分の間違いによる影響からユーザーを保護することです。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

左側の「エラー」は意図的ではありません。しかし、実際に見てみると、文脈にぴったりだと気づいたので、そのままにすることにしました。

この問題に対する私が 10 年以上にわたって推奨してきたソリューションは、階層型アクセス制御を備えたソーシャルリカバリとマルチシグネチャウォレットでした。ユーザーのアカウントには、マスターキーと N 個のガーディアン (たとえば、N = 5) という 2 つのレベルのキーがあります。主キーは、価値の低い非財務的な操作を実行できます。ほとんどのガーディアンは、(i) アカウント内の値全体の送信などの高価値の操作、または (ii) マスターキーまたはガーディアンの変更を実行する必要があります。必要に応じて、主キーがタイムロックを介して高価値の操作を実行できるようにすることができます。

上記は基本的な設計であり、拡張することができます。セッションキーや ERC-7715 などの許可メカニズムは、アプリケーションごとに利便性とセキュリティのさまざまなバランスをサポートするのに役立ちます。異なるしきい値で複数のタイムロック期間を設定するなど、より複雑なガーディアンアーキテクチャは、盗難のリスクを最小限に抑えながら、正規のアカウントを正常に回復できる可能性を最大限に高めるのに役立ちます。

保護者は誰、または何になるべきですか?

経験豊富な仮想通貨ユーザーのコミュニティにおける、経験豊富な仮想通貨ユーザーにとって実行可能な選択肢は、友人や家族のキーです。全員に新しい住所を教えてもらうと、誰もその人が誰であるかを知る必要はありません。実際、あなたの保護者はお互いが誰であるかを知る必要さえありません。彼らがあなたに密告しなかったとしても、彼らが共謀する可能性は低いでしょう。ただし、ほとんどの新規ユーザーは、このオプションを利用できません。

2 番目のオプションは機関後見人です。お客様のリクエストの追加確認を受け取った場合にのみトランザクションに署名するサービスの提供を専門とする会社です。確認コード、または価値の高いユーザー向けのビデオ通話。たとえば、人々は長い間これを作ろうと試みてきました。私は 2013 年に CryptoCorp についてプロファイリングしました。しかし、これらの企業はこれまでのところあまり成功していません。

3 番目のオプションは、複数の個人デバイス (電話、デスクトップ、ハードウェアウォレットなど) です。これは機能しますが、経験の浅いユーザーにとっては設定と管理が困難でもあります。特に同じ場所にある場合には、デバイスが同時に紛失または盗難されるリスクもあります。

最近では、マスターキーベースのものが増えてきました。キーはデバイス上でのみバックアップできるため、個人用デバイスソリューションとなるか、クラウド上にバックアップされ、そのセキュリティは暗号化セキュリティ、権限、信頼できるハードウェアの前提条件の複雑な組み合わせに依存します。実際、キーは平均的なユーザーにとって貴重なセキュリティ上の利点ですが、それだけではユーザーの命の節約を保護するには十分ではありません。

幸いなことに、ZK-SNARK には 4 番目のオプション、ZK パッケージの集中 ID があります。このタイプには、zk-email、Anon Aadhaar、Myna Wallet などが含まれます。基本的に、任意の形式 (企業または政府) で集中 ID を取得し、それをイーサリアムアドレスに変換します。トランザクションを送信するには、集中 ID を持っていることを証明する ZK-SNARK を生成する必要があります。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

この追加により、幅広いオプションと、ZK でラップされた集中型 ID の独特の「初心者向けの優しさ」が得られました。

これを行うには、簡素化され統合された UI を通じて実装する必要があります。「example@gmail.com」をガーディアンとして指定することのみを指定でき、対応する zk-email Ethereum アドレスが自動的に生成される必要があります。フード。上級ユーザーは、自分の電子メール (および場合によってはその電子メール内に保存されたプライバシーソルト) をオープンソースのサードパーティアプリケーションに入力し、結果のアドレスが正しいことを確認できる必要があります。他のサポートされているガーディアンタイプにも同じことが当てはまります。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

現在、zk-email が直面している実際的な課題は、DKIM 署名に依存していることです。DKIM 署名は、数か月ごとにローテーションされる鍵を使用し、それ自体が他の機関によって署名されていないことです。これは、今日の zk-email にはプロバイダー自体を超えたある程度の信頼要件があることを意味します。zk-email が信頼できるハードウェア内で TLSNotary を使用して更新されたキーを検証すれば、これを軽減できますが、これは理想的ではありません。電子メールプロバイダーが DKIM キーに直接署名し始めることを願っています。今日、私は 1 人の保護者に zk-email をお勧めしますが、ほとんどの保護者には推奨しません。zk-email が壊れると資金が使用できないことを意味する設定で資金を保管しないでください。

新規ユーザーとアプリ内ウォレット

実際、新規ユーザーは、最初にサインアップするときに多数の保護者を入力したくありません。したがって、ウォレットは非常にシンプルなオプションを提供する必要があります。自然な方法は、電子メールアドレスで zk-email、ユーザーのデバイスにローカルに保存されているキー (おそらくマスターキー)、およびプロバイダーが選択したバックアップキーを使用して 2-of-3 を実行することです。ユーザーの経験が増えたり、より多くの資産を蓄積したりすると、ある時点でさらにガーディアンを追加するように求められるはずです。

非暗号通貨ユーザーにアピールしようとするアプリは、ユーザーが 2 つの新しいアプリ (アプリ自体とイーサリアムウォレット) を同時にダウンロードするという混乱を招くユーザーエクスペリエンスを望んでいないため、アプリへのウォレットの統合は避けられません。ただし、多くのアプリウォレットのユーザーは、心配する「アクセス制御の問題」が 1 つだけになるように、すべてのウォレットをリンクできる必要があります。最も簡単なアプローチは、階層化スキームを採用することです。このスキームでは、ユーザーがメインのウォレットをすべてのアプリ内ウォレットの保護者として設定できるようにする簡単な「リンク」プロセスがあります。 Farcaster クライアント Warpcast はすでにこれをサポートしています。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

デフォルトでは、Warpcast アカウントの回復は Warpcast チームによって管理されます。ただし、Farcaster アカウントを「引き継いで」、リカバリを自分のアドレスに変更することはできます。

詐欺やその他の外部の脅威からユーザーを保護する

アカウントのセキュリティに加えて、今日のウォレットは偽のアドレス、フィッシング、詐欺、その他の外部の脅威を特定し、そのような脅威からユーザーを保護しようとします。同時に、多くの対策は依然として非常に原始的です。たとえば、100 ドルまたは 100,000 ドルを送金する場合、新しいアドレスに ETH またはその他のトークンを送信するにはクリックが必要です。ここには、唯一の特効薬はありません。これは、さまざまなクラスの脅威に対する、ゆっくりとした継続的な一連の修正と改善です。ただし、ここで改善に取り組み続けることには多くの価値があります。

プライバシー

イーサリアムのプライバシーをもっと真剣に受け止め始める時期が来ています。 ZK-SNARK テクノロジーは現在非常に進歩しており、規制リスクを軽減するためにバックドアに依存しないプライバシーテクノロジー (プライバシープールなど) はますます成熟しており、Waku や ERC-4337 メンプールなどの二次インフラストラクチャは徐々に安定してきています。しかしこれまで、イーサリアムでプライベート送金を行うには、ユーザーはRailway（またはステルスアドレスの場合はUmbra）などの「プライバシーウォレット」を明示的にダウンロードして使用する必要がありました。これにより、大幅な不便が生じ、プライベート送金を希望する人の数が減少します。解決策は、プライベート送金をウォレットに直接統合する必要があることです。

簡単な実装は次のとおりです。ウォレットは、ユーザーの資産の一部を「プライベート残高」としてプライバシープールに保存できます。ユーザーが転送を行う場合、最初にプライバシープールから自動的に終了します。ユーザーが資金を受け取る必要がある場合、ウォレットはステルスアドレスを自動的に生成できます。

さらに、ウォレットは、ユーザーが参加するアプリケーションごとに新しいアドレスを自動的に生成できます (例: defi プロトコル)。入金はプライバシープールから行われ、出金はプライバシープールに直接送られます。これにより、任意のアプリでのユーザーのアクティビティを他のアプリでのアクティビティからリンク解除できます。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

このテクノロジーの利点の 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 には、すべてのデータのコピーを保持するサーバーと、暗号化されたリクエストをサーバーに送信するクライアントが含まれます。サーバーはすべてのデータに対して計算を実行し、クライアントがどのデータにアクセスしたかをサーバーに明らかにすることなく、クライアントが必要とするデータをクライアントのキーに暗号化して返します。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

サーバーを正直に保つために、個々のデータベースプロジェクト自体が Merkle フォークであるため、クライアントはライトクライアントを使用してそれらを検証できます。

PIR（ディープチャオ注：通常は「Private Information Retrieval」（個人情報検索）、取得した情報を公開せずにデータベースから情報を取得できるプロトコルまたは技術を指します。）計算量が非常に多くなります。この問題を解決するには、いくつかの方法があります。

ブルートフォースの場合: アルゴリズムまたは特殊なハードウェアの改善により、PIR が十分に高速に実行される可能性があります。これらの手法は前処理に依存する場合があります。サーバーは各クライアントの暗号化およびスクランブルされたデータを保存でき、クライアントはそのデータをクエリできます。イーサリアム環境における主な課題は、これらのテクノロジーを（国と同様に）急速に変化するデータセットに適応させることです。これにより、リアルタイムの計算が安価になりますが、計算とストレージの合計コストが高くなる可能性があります。
プライバシー要件の緩和: たとえば、ルックアップごとに存在できる「ミックスイン」は 100 万個のみであるため、サーバーはクライアントがアクセスできる 100 万個の可能な値については認識しますが、より細かい粒度は認識しません。
マルチサーバー PIR: 複数のサーバーを使用し、これらのサーバー間の正直さが 1-of-N であると想定される場合、通常は PIR アルゴリズムの方が高速です。
機密性の代わりに匿名性: リクエストはハイブリッドネットワーク経由で送信でき、リクエストの内容を隠すのではなく、リクエストの送信者を隠すことができます。ただし、これを効果的に行うと必然的に遅延が増加し、ユーザーエクスペリエンスが低下します。

イーサリアム環境での実用性を維持しながらプライバシーを最大限に高めるためのテクノロジーの適切な組み合わせを見つけ出すことは未解決の研究課題であり、暗号学者がそれに挑戦することを私は歓迎します。

理想的なキーストアウォレット

トランスポートと状態へのアクセスに加えて、L2 コンテキスト全体でスムーズに動作する必要があるもう 1 つの重要なワークフローは、アカウントの認証構成の変更です。キーの変更 (回復など) や、ロジック全体にさらに深い変更を加えることです。アカウントを変更します。ここには、難易度の高い順に 3 つの段階のソリューションがあります。

更新の再生: ユーザーが設定を変更すると、この変更を許可するメッセージが、ユーザーが資産を所有していることをウォレットが検出したすべてのチェーンで再生されます。潜在的に、メッセージ形式と検証ルールはチェーンに依存しないため、できるだけ多くのチェーンで自動的に再生されます。
L1 のキーストア: 構成情報は L1 にあり、L2 のウォレットは L1SLOAD またはリモート静的呼び出しを使用してそれを読み取ります。この方法では、L1 の構成を更新するだけで、構成が自動的に有効になります。
L2 のキーストア: 構成情報は L2 に存在し、L2 のウォレットは ZK-SNARK を使用してそれを読み取ります。これは (2) と同じですが、キーストアの更新は安くなる可能性がありますが、一方で読み取りの方が高価である点が異なります。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

解決策 (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 リクエストを受け入れることをユーザーに要求するパラノイドモードを追加することもできます。

Vitalik の新しい記事: 理想的なウォレットのビジョン、クロスチェーン体験からプライバシー保護までの包括的なアップグレード

パラノイドモードの可能なインターフェースモデル

より高度なアプローチは、HTML + Javascript を超えて、dapp のビジネスロジックを専用言語 (おそらく Solidity または Vyper 上の比較的薄いオーバーレイ) で記述することです。ブラウザーは、必要な機能の UI を自動的に生成できます。 OKContract はすでにこれを実行しています。

もう 1 つの方向は、暗号経済情報の防御です。DAPP 開発者、セキュリティ会社、チェーン展開者などが、DAPP がハッキングされたり、非常に誤解を招く方法でユーザーに損害を与えた場合に、受信者に支払われる保証金を確立できます。影響を受ける (特定された) ユーザーは次のとおりです。一部のオンチェーン DAO によって裁定されます。ウォレットは、債券のサイズに基づいてユーザーにスコアを表示できます。

長期的な将来

上記はすべて、何かをポイントしてクリックしたり、テキストフィールドに入力したりする従来のインターフェイスのコンテキストに基づいています。しかし、私たちはまた、より深刻なパラダイムシフトの真っ只中にいます。

人工知能は、クリックして入力するというパラダイムから、「やりたいことを言うとロボットがそれを理解する」というパラダイムに私たちを導く可能性があります。
ブレインコンピューターインターフェイスは、視線追跡などの「穏やかな」方法から、より直接的でさらには侵襲的な技術まで多岐にわたります (参照: 今年の最初の Neuralink 患者)
クライアント側のプロアクティブな防御: Brave Browser は、広告、トラッカー、その他多くの不要なオブジェクトからユーザーをプロアクティブに保護します。多くのブラウザ、プラグイン、暗号ウォレットでは、チーム全体がさまざまなセキュリティやプライバシーの脅威からユーザーを保護するために積極的に取り組んでいます。これらの「積極的な保護者」は、今後 10 年間でさらに強力になるでしょう。

これら 3 つのトレンドを総合すると、インターフェイスがどのように機能するかについてのより深い再考につながるでしょう。自然言語入力、視線追跡、または最終的にはより直接的な脳とコンピューターのインターフェイスを介して、履歴 (すべてのデータがローカルで処理されている限り、おそらくテキストメッセージを含む) と組み合わせることで、「ウォレット」は、ユーザーがどこにアクセスしたいのかを明確かつ直感的に理解できます。行ってください。 AI は、この直感を具体的な「行動計画」、つまり、ユーザーが望むことを達成するための一連のオンチェーンおよびオフチェーンのインタラクションに変換します。これにより、サードパーティのユーザーインターフェイスの必要性が大幅に軽減されます。ユーザーがサードパーティのアプリケーション (または他のユーザー) と対話する場合、AI はユーザーに代わって敵対的に考え、脅威を特定し、それらを回避するための行動計画を提案する必要があります。理想的には、これらの AI は、異なるバイアスとインセンティブ構造を持つ多様なグループによって生成される、オープンなエコシステムを持つ必要があります。

これらのより過激なアイデアは、今日では非常に未熟なテクノロジーに依存しているため、私は今日それらに依存するウォレットに自分の資産を入れたくありません。ただし、このようなことが将来の道であることは明らかであるため、この方向に向けてより積極的に検討を開始する価値があります。

クロス L2 トランザクションのユーザー エクスペリエンス

アカウントのセキュリティ

保護者は誰、または何になるべきですか?

新規ユーザーとアプリ内ウォレット

詐欺やその他の外部の脅威からユーザーを保護する

プライバシー

イーサリアムウォレットはデータウォレットでもある必要がある

安全なチェーンアクセス

理想的なキーストアウォレット

Dappのセキュリティ

長期的な将来

クロス L2 トランザクションのユーザーエクスペリエンス

Ledger的加密钱包应用Ledger Live已集成ENS

人気記事