理想ウォレットのビジョン：クロスチェーン体験からプライバシー保護への全方位アップグレード

イーサリアムのインフラストラクチャスタックにおけるウォレット層は重要ですが、しばしばコア研究者や開発者によって過小評価されています。ウォレットはユーザーがイーサリアムの世界と対話するための窓口であり、ウォレット自体が適切な属性を備えている場合にのみ、ユーザーはイーサリアムおよびそのアプリケーションが提供する分散化、検閲に対する耐性、安全性、プライバシーなどの特性を本当に享受できます。

最近、イーサリアムウォレットはユーザー体験、安全性、機能の改善において顕著な進展を遂げました。本記事は、理想的なイーサリアムウォレットが備えるべきいくつかの特性を探求することを目的としています。これは完全なリストではなく、著者の暗号パンクの傾向を反映し、安全性とプライバシーに焦点を当てています。ユーザー体験に関しては十分ではないかもしれませんが、ユーザー体験の最適化は展開とイテレーションを通じて実現するのが最適であると考えられるため、本記事では安全性とプライバシーの属性に重点を置きます。

! Vitalik新記事:理想的なウォレットのビジョン、クロスチェーンエクスペリエンスからプライバシー保護まで

クロスL2取引のユーザーエクスペリエンス

現在、短期および長期の部分を含むL2ユーザーエクスペリエンスを改善するためのますます詳細なロードマップがあります。ここでは、主に短期的に実施可能なアイデアについて議論します。

核心思路は:(1)内蔵クロスL2送信機能、(2)チェーン特定アドレスと支払いリクエスト。ウォレットはユーザーに特定のERC草案フォーマットに従ったアドレスを提供する必要があります。

ユーザーがこの形式のアドレスを受け取った場合は、それをウォレットの「受取人」欄に貼り付けて「送信」をクリックするだけで、ウォレットが自動的に送信操作を処理します:

• 目標チェーン上に必要なトークンが十分にある場合、直接送信します。
• 他のチェーンに必要なトークンがある場合、クロスチェーンDEXプロトコルを使用して送信します。
• 他のタイプのトークンがある場合は、DEXで変換してから送信します。

dappが入金を要求するシーンでは、理想的なプロセスはweb3 APIを拡張し、dappがチェーン特有の支払いリクエストを発行できるようにすることです。ウォレットはこれらのリクエストを柔軟に処理できます。良好なユーザーエクスペリエンスのためには、利用可能な残高を照会するリクエストを標準化する必要があり、ウォレットはユーザー資産をどのチェーンにデフォルトで保存するかを慎重に考慮する必要があります。

特定の支払いリクエストは、モバイルウォレットがスキャンできるQRコードに入れることもできます。対面またはオンラインの支払いシーンでは、受取人がQRコードまたはweb3 API呼び出しを発行し、「XチェーンでY単位のZトークンを受け取りたい、参照IDはW」と示すことができます。ウォレットはそのリクエストに応じる方法を自由に選択できます。

もう一つの関連するテーマはガス代の支払いです。もしユーザーがあるL2で資産を受け取ったがガス代の支払いにETHがない場合、ウォレットは自動的にプロトコルを使用して他のETHがあるチェーンからガス代を支払うべきです。ウォレットがユーザーが将来的にそのL2でさらに取引を行うことを予想する場合、DEXを通じて一定量のガス代を支払うのに十分なETHを送信することもできます。これにより、将来的にそのチェーン上で直接ガス代を支払うことができ、(、より安価になります)。

! Vitalik新記事:理想的なウォレットのビジョン、クロスチェーンエクスペリエンスからプライバシー保護まで

アカウントの安全性

アカウントセキュリティの概念化された方法は、良いウォレットが同時に2つの側面で機能するべきであるということです: (はウォレット開発者の攻撃や悪意のある行為からユーザーを保護し、)はユーザー自身のミスの影響から保護します。

長年にわたり、著者の好む解決策は、階層的アクセス制御を持つソーシャルリカバリーとマルチシグウォレットです。ユーザーアカウントには、主キーとN人の保護者(（N=5)）の2層のキーがあります。主キーは、低価値および非財務操作を実行できます。ほとんどの保護者は、(1)のような高価値操作を実行する必要があります。例えば、アカウントの全資金を送信したり、(2)主キーや任意の保護者を変更したりします。必要に応じて、主キーがタイムロックを介して高価値操作を実行することも許可できます。

これは基本設計であり、さらに拡張可能です。セッションキーと権限メカニズムは、異なるアプリケーション間で利便性と安全性のバランスを取るのに役立ちます。異なる閾値で複数のタイムロック期間を設定するような、より複雑な保護者アーキテクチャは、合法的にアカウントを復元する機会を最大化しつつ、盗難リスクを最小化することができます。

ガーディアンの選択

経験豊富な暗号ユーザーにとって、実行可能な選択肢は友人や家族のキーを保護者として使用することです。もし皆が新しいアドレスを提供すれば、互いの身元を知る必要もなく、共謀の可能性が低くなります。しかし、ほとんどの新しいユーザーにとって、このオプションはあまり実行可能ではありません。

第二の選択肢は機関監護人です: 追加確認情報(、確認コードやビデオ通話)を受け取ったときのみ取引に署名するサービスを専門に提供します。この試みは長い間行われてきましたが、現在のところあまり成功していません。

第三の選択肢は、スマートフォン、コンピュータ、ハードウェアウォレット(などの複数の個人デバイス)です。これは可能ですが、新しいユーザーにとっては設定と管理が難しく、デバイスが同時に紛失または盗まれるリスクがあります。

最近、万能キーに基づくプランが増えてきました。キーはデバイス上にのみバックアップすることも、クラウドにバックアップすることもでき、安全性は複雑なハイブリッド暗号、機構、信頼できるハードウェアの仮定に依存します。一般ユーザーにとっては貴重なセキュリティ向上ですが、これだけではユーザーの全資産を保護するには不十分です。

幸運なことに、ZK-SNARK技術は私たちに第四の選択肢を提供します: ZK包装の中央集権ID。これにはzk-email、Anon Aadhaar、Myna ウォレットなどが含まれます。基本的な考え方は、さまざまな形式の(企業または政府)の中央集権IDをイーサリアムアドレスに変換し、ユーザーはその中央集権IDを持っていることを証明するZK-SNARKを生成することでのみ取引を送信できるというものです。

この方案は、簡素化された統合UIを通じて実現する必要があります: ユーザーは、使用したいメールアドレスをガーディアンとして指定するだけで、システムはバックグラウンドで対応するzk-emailイーサリアムアドレスを自動生成します。上級ユーザーは、メールアドレス(と、保存される可能性のあるプライバシーソルト)をオープンソースのサードパーティアプリに入力し、生成されたアドレスが正しいかどうかを確認できるべきです。他のサポートされているガーディアンタイプも同様です。

注意すべきことは、現在zk-emailが直面している実際の課題は、数ヶ月ごとにローテーションされるDKIM署名キーに依存していることであり、これらのキー自体は他の機関によって署名されていないということです。これは、現在のzk-emailがある程度プロバイダー自体を信頼する必要があることを意味します。もし信頼できるハードウェア内でTLSNotaryを使用して更新されたキーを検証すれば、この依存関係を減らすことができますが、まだ理想的ではありません。メールプロバイダーが自らのDKIMキーを直接署名し始めることを期待しています。現時点では、zk-emailをガーディアンの一つとして使用することが推奨されていますが、ほとんどのガーディアンが使用することは推奨されていません: zk-emailに問題が発生した場合、資金が利用できなくなる設定で資金を保管しないでください。

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

新規ユーザーは、初回登録時に大量の保護者情報を入力することを実際には望んでいません。したがって、ウォレットは彼らに非常にシンプルな選択肢を提供する必要があります。一つの自然な方法は、メールアドレスのzk-email、ユーザーのデバイスにローカルに保存されたキー(が万能キー)として機能し、プロバイダーが保有するバックアップキーを使用して2-of-3の選択を行うことです。ユーザーがより多くの経験や資産を蓄積するにつれて、適切なタイミングで彼らに追加の保護者を追加するよう促すべきです。

アプリにウォレットを統合することは避けられません。なぜなら、暗号に関心のないユーザー向けのアプリは、ユーザーが2つの新しいアプリ、(アプリ自体とイーサリアムウォレット)を同時にダウンロードすることによる混乱したユーザー体験を望んでいないからです。しかし、多くのアプリ内ウォレットのユーザーは、すべてのウォレットをリンクさせることができるべきで、それによって「アクセス制御の問題」にのみ注目すればよいのです。最も簡単な方法は、階層的なアプローチを採用し、迅速な「リンク」プロセスを通じて、ユーザーが主ウォレットをすべてのアプリ内ウォレットの保護者として設定できるようにすることです。

! ヴィタリックの新しい記事:クロスチェーン体験からプライバシー保護まで、理想的なウォレットのビジョン

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

アカウントの安全性に加えて、現在のウォレットは偽のアドレス、フィッシング、詐欺などの外部の脅威を識別するために多くの作業を行っており、ユーザーをこれらの脅威から保護するために努力しています。同時に、多くの対策はまだかなり原始的であり、100ドル送信する場合でも10万ドル送信する場合でも確認をクリックすることが求められます。この点において、完璧な単一の解決策は存在せず、さまざまなカテゴリの脅威に対して一連の継続的な改善が必要です。この分野での努力を続けることは非常に価値があります。

プライバシー

今こそ、イーサリアムのプライバシーをより真剣に考える時です。ZK-SNARK技術は非常に進んでおり、バックドアに依存しない規制リスクを低減するプライバシー技術(やプライバシープール)がますます成熟しています。WakuやERC-4337メンプールのようなレイヤー2インフラも徐々に安定しています。しかし、現在イーサリアムでプライベート送金を行うには、ユーザーが明示的に"ウォレット"をダウンロードして使用する必要があり、これが不便さを増し、プライベート送金を行う意欲のある人の数を減らしています。解決策は、プライベート送金を直接ウォレットに統合することです。

簡単な実装は、ウォレットがユーザーの一部資産を「プライベートバランス」としてプライバシープールに保存できるというものです。ユーザーが振込を行う際には、自動的にプライバシープールから退出します。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的に隠しアドレスを生成できます。

さらに、ウォレットはユーザーが参加する各アプリケーションのために自動的に新しいアドレスを生成できます。入金はプライバシープールから行われ、出金は直接プライバシープールに入ります。これにより、ユーザーはあるアプリでの活動を他のアプリでの活動から切り離すことができます。

この技術は、プライバシー資産の移転を保護する自然な方法であるだけでなく、プライバシーアイデンティティを保護する自然な方法でもあります。アイデンティティはすでにチェーン上に存在しています: 身分証明ゲートを使用したアプリケーション、トークンゲートチャット、イーサリアム準拠のプロトコルなどはすべてチェーン上のアイデンティティです。このエコシステムもプライバシーを保護できることを望んでいます。これは、ユーザーのチェーン上の活動が一箇所に集中すべきではないことを意味します: 各プロジェクトは個別に保存されるべきであり、ユーザーのウォレットは唯一の「グローバルビュー」を持つ場所であり、すべての証明を同時に見ることができるべきです。各ユーザーが複数のアカウントを持つネイティブエコシステムは、この目標を達成するのに役立ちます。EASやZupassなどのオフチェーン証明プロトコルも同様です。

これは、中期的なイーサリアムのプライバシーに対する実用的なビジョンを示しています。L1およびL2でいくつかの機能を導入してプライバシー保護のトランザクションをより効率的かつ信頼性の高いものにすることは可能ですが、今すぐに実現できます。一部のプライバシー擁護者は、唯一受け入れ可能な解決策はすべての内容の完全なプライバシーであり、EVM全体を暗号化することだと考えています。これは理想的な長期的な結果かもしれませんが、プログラミングモデルを根本的に再考する必要があり、現在はイーサリアム上に展開できる成熟したレベルには達していません。私たちは確かに十分な匿名集を得るためにデフォルトのプライバシーが必要です。しかし、まず(1)アカウント間の送金に焦点を当て、(2)アイデンティティおよびアイデンティティ関連のユースケース(、たとえばプライベート証明)は実用的な第一歩であり、より実現しやすく、ウォレットは今すぐに使用を開始できます。

イーサリアムウォレットもデータウォレットになる必要があります

有効なプライバシーソリューションは、ユーザーがストレージチェーンを生成します。