理想のイーサリアムウォレットのビジョン: クロスチェーン体験からプライバシー保護までの全方位的なアップグレード

イーサリアム基盤のスタックにおいてウォレット層は重要でありながら、コア研究者や開発者によって過小評価されることがよくあります。ユーザーとイーサリアムの世界との窓口として、ウォレット自体は分散型、検閲耐性、安全性、プライバシーといった特性を備えている必要があります。そうすることで、ユーザーはイーサリアムおよびそのアプリケーションが提供するこれらの特性を真に享受できるのです。

最近、イーサリアムウォレットはユーザー体験、安全性、機能の面で顕著な進歩を遂げました。この記事では、理想的なイーサリアムウォレットが備えるべき特性についての私の意見を共有することを目的としています。これは完全なリストではなく、私の暗号パンクの傾向を反映したものであり、安全とプライバシーに焦点を当てているため、ユーザー体験の観点では不十分かもしれません。しかし、単にフィードバックに基づいて展開と反復を行いユーザー体験を最適化するのではなく、安全性とプライバシー属性に注目することがより価値があると考えています。

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

クロスL2取引のユーザー体験

現在、L2ユーザーエクスペリエンスの改善に向けた、短期および長期の要素を含む、ますます洗練されたロードマップがあります。ここでは、短期的に実施可能なアイデアについて議論します。

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

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

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

dappの入金リクエストのシナリオについて、理想的なアプローチはweb3 APIを拡張し、dappがチェーン特有の支払いリクエストを発行できるようにすることです。ウォレットはgetAvailableBalanceリクエストを標準化し、ユーザーの資産がデフォルトでどのチェーンに保存されるかを真剣に考慮し、安全性と送金の便利さの両方を兼ね備える必要があります。

チェーン特定の支払いリクエストはQRコードに入れることもでき、モバイルウォレットがスキャンします。対面またはオンライン支払いシーンでは、受取人が発行したQRコードまたはAPI呼び出しが「私はXチェーン上のY単位のZトークンを欲しい、参照IDはW」と示しており、ウォレットはそのリクエストを満たす方法を自由に選択できます。もう一つの選択肢は請求リンクプロトコルで、ユーザーのウォレットが承認を含むQRコードまたはURLを生成し、受取人が資金を引き出す責任を負います。

ガス支払いも関連するトピックです。ユーザーがあるL2で資産を受け取ったがETHを持っていない場合、ウォレットはユーザーがETHを持っているチェーン上で自動的にプロトコルを使用してガスを支払う必要があります。ウォレットがユーザーが将来的にそのL2でさらに多くの取引を行うことを予測する場合、DEXを使用して一定量のETHをガスの備蓄として送信することもできます。

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

アカウントセキュリティ

私は、アカウントの安全性の鍵は、ユーザーをウォレット開発者のハッキングや悪意のある行為から保護することと、ユーザー自身のエラーの影響から同時に守ることにあると考えています。

私が長い間傾向していた解決策は、階層的なアクセス制御を持つソーシャルリカバリーとマルチシグウォレットです。ユーザーアカウントには2層のキーがあります: プライマリーキーとN人のガーディアン(（N=5)）。プライマリーキーは、低価値および非財務的な操作を行うことができます。大多数のガーディアンが必要なのは、(1)高価値操作を実行することです。例えば、アカウントの全資金を送信すること、(2)プライマリーキーや任意のガーディアンを変更することです。必要に応じて、プライマリーキーがタイムロックを通じて高価値操作を実行できるようにすることができます。

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

保護者の選択肢にはいくつかのオプションがあります:

1. 経験豊富な暗号ユーザーは、友人や家族のキーを選択できます。
2. 機関の監護者: 専門的に署名サービスを提供する会社で、追加の確認情報が必要です。
3. 複数の個人デバイス(、例えばスマートフォン、コンピュータ、ハードウェアウォレット)、しかし新しいユーザーは設定と管理が難しいかもしれません。
4. パスワードマネージャーに基づくソリューションは、ローカルまたはクラウドにバックアップできますが、それだけではユーザーのすべての資産を保護するには不十分です。
5. ZKパッケージの中央集権ID: zk-email、Anon Aadhaarなどは、中央集権IDをイーサリアムアドレスに変換できます。

ZK包装された中央集権型IDは新しいユーザーにとって優しいです。ウォレットは簡略化された統合UIを提供するべきで、ユーザーが直接メールアドレスを指定して保護者として使用し、自動的に対応するzk-emailエーテルアドレスを生成できるようにします。上級ユーザーは生成されたアドレスの正確性を検証できるべきです。

新しいユーザーに対して、ウォレットはzk-email、ローカルストレージキー、およびプロバイダーによるバックアップキーに基づく2-of-3スキームなどの簡単なオプションを提供します。ユーザーの経験が増すか、資産が増加するにつれて、さらに多くの保護者を追加するように促す必要があります。

アプリ内ウォレットの統合は避けられませんが、ユーザーはすべてのウォレットをリンクさせ、アクセスコントロールを一元管理できる必要があります。簡単な方法は、ユーザーが主ウォレットをすべてのアプリ内ウォレットの保護者として設定できるような階層的な仕組みを採用することです。

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

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

アカウントの安全性を除いて、現在のウォレットは偽のアドレス、フィッシング、詐欺などを認識するために多くの作業を行っています。しかし、多くの対策は依然として原始的であり、新しいアドレスにトークンを送信する際に金額に関係なく確認をクリックすることを統一して要求するなどがあります。これは、異なる種類の脅威に対して継続的に改善する必要があり、一度きりの解決策はありません。

プライバシー

イーサリアムのプライバシーを真剣に考える時が来ました。ZK-SNARK技術はかなり進歩しており、バックドアに依存しないプライバシー技術(やプライバシープール)は成熟してきています。二次インフラストラクチャーとしてWakuやERC-4337メンプールも徐々に安定しています。しかし、現在プライベート送金を行うにはユーザーが明示的に「ウォレット」をダウンロードして使用する必要があり、これが不便さを増し、利用者を減少させています。解決策は、プライベート送金をウォレットに直接統合することです。

簡単な実装は、ウォレットがユーザーの一部の資産を「プライベートバランス」としてプライバシープールに保存することです。送金時に自動的にプライバシープールから退出し、資金を受け取る際に自動的に見えないアドレスを生成します。

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

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

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

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

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

有効なプライバシーソリューションは、支払い、身分証明、その他のユースケースに使用されるかどうかにかかわらず、ユーザーがオフチェーンデータを保存する必要性を生み出します。現代のプライバシープロトコルは、時にはチェーン上に暗号化データを保存し、単一の秘密鍵で復号化します。これはリスクがあり、鍵が漏洩したり、量子コンピュータが実用化された場合、すべてのデータが公開される可能性があります。オフチェーン証明は、オフチェーンデータストレージの必要性をより顕著にします。

ウォレットは、チェーン上のアクセス権を保存するだけでなく、ユーザーのプライベートデータを保存する必要があります。非暗号世界でもこの点がますます認識されています。私たちは、データの可アクセス性と漏洩防止に関する堅牢な保証を構築する必要があります。これらのソリューションを重ね合わせることができるかもしれません: N人の保護者がいる場合、M-of-N秘密共有を使用してそのN人の保護者の間でデータを保存します。データは本質的に保護が難しくなります、なぜなら誰かのデータシェアを取り消すことができないからですが、私たちはできるだけ安全な分散型ホスティングソリューションを提案すべきです。

安全なチェーンアクセス

現在、ウォレットはRPCプロバイダーに依存してチェーン情報を取得していますが、これには2つの脆弱性があります:

1. RPCプロバイダーは、虚偽の情報(、例えば市場価格)を提供することによって資金を盗む可能性があります。
2. RPCプロバイダーは、ユーザーとアプリケーションがやり取りするプライベート情報を取得できます。

理想的には、これらの2つの脆弱性を解決したいと考えています。最初の問題を解決するには、L1とL2の標準化されたライトクライアントが必要で、ブロックチェーンのコンセンサスを直接検証します。HeliosはL1に実装され、いくつかのL2のサポートを開始しました。すべてのL2をカバーするためには、L2を表す設定契約を介して最新の状態ルートを取得し、状態とレシート証明の論理を検証する標準が必要です。これにより、ウォレットはL1とL2の任意の状態またはイベントを安全に検証できる汎用ライトクライアントを持つことができます。

プライバシーについて、現在唯一現実的な方法は自分のフルノードを運営することです。しかし、L2の普及に伴い、すべてのコンテンツを運営するフルノードがますます難しくなっています。ここでのライトクライアントの同等物はプライベート情報検索(PIR)です。PIRは、すべてのデータのコピーを保存するサーバーと、そのサーバーに暗号化リクエストを送信するクライアントを含みます。サーバーはすべてのデータに対して計算を実行し、クライアントが必要とする暗号化データを返しますが、クライアントがどのデータにアクセスしたかはわかりません。

サーバーの誠実性を保証するために、各データベース項目自体がマークルブランチであり、クライアントはライトクライアントを使用して検証できます。

PIRの計算量は非常に大きいです。解決策には以下が含まれます:

• ブルートフォース: アルゴリズムまたは専用ハードウェアの改善により、PIRが十分に速く動作する可能性があります。
• プライバシー要件の緩和: 各検索で100万の"mixins"のみ。
• 多サーバーPIR:複数のサーバーを使用し、1-of-Nが誠実であると仮定すると、PIRアルゴリズムは通常より速くなります。
• 匿名性ではなく機密性: 混合ネットワークを介してリクエストを送信し、送信者を隠すが、内容は隠さない。しかし、これにより遅延が増加します。

イーサリアム環境でプライバシーを最大化しつつ実用性を維持するための正しい技術の組み合わせを見つけることは、オープンな研究問題です。

理想的なウォレット

クロスL2の文脈では、別のスムーズに機能する重要なプロセスはアカウント認証の変更です。