この問題の最適な解決策は、10年以上にわたり、階層的アクセス制御を備えたソーシャルリカバリーとマルチシグウォレットです。ユーザーのアカウントには、マスターキーと N 人のガーディアン(の2層のキーがあります。ここで N = 5)です。マスターキーは、低価値の非財務操作を実行できるキーです。ほとんどのガーディアンは、高価値の操作を実行するために(i)が必要です。たとえば、アカウント内のすべての価値を送信することや、(ii)マスターキーまたは任意のガーディアンを変更することです。必要に応じて、マスターキーが時間ロックを介して高価値の操作を実行することを許可することができます。
理想イーサリアムウォレット:クロスチェーン体験、安全性とプライバシーの全面的なアップグレード
理想のイーサリアムウォレットのビジョン: クロスチェーン体験からプライバシー保護への全方位的なアップグレード
イーサリアム基盤のインフラストラクチャスタックの重要なレイヤーの一つはウォレットですが、しばしばコアL1研究者や開発者によって過小評価されています。ウォレットはユーザーとイーサリアムの世界との窓口であり、ユーザーはウォレット自体もこれらの特性を持つ前提で、イーサリアムおよびそのアプリケーションが提供するあらゆる分散型、検閲耐性、安全性、プライバシーなどの特性から利益を得ることができます。
最近、イーサリアムウォレットはユーザー体験、安全性、機能の改善において大きな進展を遂げました。この文章の目的は、理想的なイーサリアムウォレットが持つべきいくつかの特性についての見解を示すことです。これは完全なリストではなく、暗号パンクの傾向を反映し、安全性とプライバシーに焦点を当てており、ユーザー体験に関してはほぼ不完全であることは確かです。しかし、願望リストはユーザー体験を最適化する点では、フィードバックに基づいて展開および反復することほど効果的ではないため、安全性とプライバシーの属性に焦点を当てることが最も価値があります。
! Vitalik新記事:理想的なウォレットのビジョン、クロスチェーンエクスペリエンスからプライバシー保護まで
クロスL2取引のユーザー体験
現在、L2ユーザー体験を改善するためのますます詳細なクロスチェーンのロードマップがあり、このロードマップには短期的な部分と長期的な部分があります。ここでは短期的な部分について話します: 今日理論的にはまだ実施可能なアイデアです。
核心思想は(i)内蔵クロスL2送信、および(ii)チェーン特定アドレスと支払いリクエストです。ウォレットはユーザーに関連ERC草案のスタイルに従ったアドレスを提供できるべきです。
! Vitalik新記事:理想的なウォレットのビジョン、クロスチェーンエクスペリエンスからプライバシー保護まで
誰かが(または特定のアプリケーション)がユーザーにこの形式のアドレスを提供する場合、ユーザーはそれをウォレットの「受取人」フィールドに貼り付けて、「送信」をクリックできる必要があります。ウォレットは、送信されたデータを可能な限り自動的に処理する必要があります:
上記の内容は「ユーザーがアドレス(またはENSをコピー＆ペーストする、例えば、vitalik.eth @ optimism.eth)に誰かがユーザーに支払う」というユースケースに適用されます。もしdappが入金を要求する場合、理想的なプロセスはweb3 APIを拡張し、dappがチェーン特有の支払いリクエストを発行できるようにすることです。その後、ウォレットは必要に応じてそのリクエストに応じることができるようになります。ユーザー体験を良好にするためには、getAvailableBalanceリクエストを標準化し、ウォレットはユーザーの資産をどのチェーンにデフォルトで保存するかを真剣に考慮し、安全性と送金の便利さを最大限に高める必要があります。
特定のチェーンに特化した支払いリクエストは、QRコードに埋め込むこともでき、モバイルウォレットがQRコードをスキャンできます。対面(またはオンライン)の消費者支払いシーンでは、受取人は「私はチェーン上でX単位のトークンYZを、参照IDまたはコールバックWを持って要求したい」と示すQRコードまたはweb3 API呼び出しを発行します。ウォレットは、このリクエストを自由に満たすことができます。もう一つの選択肢は、クレームリンクプロトコルで、ユーザーのウォレットがクレーム権限を含むQRコードまたはURLを生成し、彼らのチェーン上の契約から一定の資金を取得します。受取人の仕事は、これらの資金を自分のウォレットにどのように移転するかを考えることです。
もう一つの関連するテーマはガスの支払いです。ユーザーがETHを持っていないL2で資産を受け取った場合、そのL2で取引を送信する必要があるとき、ウォレットはプロトコルを自動的に使用してチェーン上のガスを支払うことができるべきです。ウォレットがユーザーに将来的にL2でより多くの取引を行わせたい場合、例えば数百万ガスの価値のETHを送信するためにDEXのみを使用するべきです。そうすれば将来の取引は直接そこでガスを使うことができ、(それがより安価だからです)。
アカウントセキュリティ
アカウントセキュリティの課題を概念化する一つの方法は、良いウォレットが同時に二つの側面で機能すべきであるということです: (i)ユーザーをウォレット開発者によるハッキングや悪意のある攻撃から保護し、(ii)ユーザー自身のミスの影響から保護することです。
この問題の最適な解決策は、10年以上にわたり、階層的アクセス制御を備えたソーシャルリカバリーとマルチシグウォレットです。ユーザーのアカウントには、マスターキーと N 人のガーディアン(の2層のキーがあります。ここで N = 5)です。マスターキーは、低価値の非財務操作を実行できるキーです。ほとんどのガーディアンは、高価値の操作を実行するために(i)が必要です。たとえば、アカウント内のすべての価値を送信することや、(ii)マスターキーまたは任意のガーディアンを変更することです。必要に応じて、マスターキーが時間ロックを介して高価値の操作を実行することを許可することができます。
以上は基本設計であり、拡張が可能です。セッションキーと関連する権限メカニズムは、異なるアプリケーションの利便性と安全性の間の異なるバランスをサポートするのに役立ちます。異なるしきい値で複数のタイムロック持続時間を持つようなより複雑なガーディアンアーキテクチャは、正当なアカウントを成功裏に復元する機会を最大限に高める一方で、盗難リスクを最小限に抑えるのに役立ちます。
保護者は誰または何であるべきか?
経験豊富な暗号通貨ユーザーコミュニティの経験豊富な暗号ユーザーにとって、実行可能な選択肢は、ユーザーの友人や家族の鍵です。ユーザーが全員に新しいアドレスを提供するように頼む場合、誰も彼らが誰であるかを知る必要はありません - 実際、ユーザーの監護者はお互いが誰であるかを知る必要さえありません。彼らがユーザーに情報を漏らさなければ、彼らが共謀する可能性は非常に低いです。しかし、ほとんどの新しいユーザーにとって、このオプションは利用できません。
第二の選択肢は機関の保護者です: ユーザーの要求に応じて、他の確認情報を受け取ったときにのみ取引を署名するサービスを専門に提供する会社です: 例えば確認コードや高価値ユーザー向けのビデオ通話などです。人々は長い間これを作ろうとしてきましたが、例えば2013年にCryptoCorpが紹介されました。しかし、今のところ、これらの会社はあまり成功していません。
第三の選択肢は複数の個人デバイス(、例えば電話、デスクトップ、ハードウェアウォレット)です。これは機能しますが、経験のないユーザーにとっては設定や管理が難しいこともあります。また、同時にデバイスを失ったり盗まれたりするリスクも存在し、特にそれらが同じ場所にある場合はなおさらです。
最近、私たちは万能鍵に基づくものをより多く見るようになりました。鍵はユーザーのデバイスにのみバックアップでき、個人デバイスソリューションとなります。また、クラウドにバックアップすることもでき、その安全性は複雑なハイブリッド暗号セキュリティ、機関、および信頼できるハードウェアの仮定に依存します。実際、鍵は一般ユーザーにとって貴重なセキュリティの向上ですが、それだけではユーザーの生涯の貯蓄を保護するには不十分です。
幸運なことに、ZK-SNARKのおかげで、私たちは4番目の選択肢を持っています: ZKパッケージの中央集権ID。このタイプにはzk-email、Anon Aadhaar、Myna Walletなどが含まれます。基本的に、ユーザーは(企業または政府)の中央集権IDを様々な形で採用し、それをイーサリアムアドレスに変換することができます。ユーザーは中央集権IDを持っていることを証明するZK-SNARKを生成することでのみ取引を送信できます。
この補足があれば、私たちは幅広い選択肢を持っており、ZKパッケージの中央集権IDは独特の「初心者に優しい」特性を持っています。
これを実現するには、簡素化された統合UIを通じて行う必要があります: ユーザーは「example@gmail.com」を保護者として指定するだけで済み、その下で対応するzk-emailエーテルアドレスを自動生成する必要があります。上級ユーザーは、彼らのメール(と、そのメールに保存されている可能性のあるプライバシーソルト)をオープンソースのサードパーティアプリケーションに入力し、生成されたアドレスが正しいことを確認できる必要があります。他のサポートされている保護者タイプについても同様であるべきです。
ご注意ください、現在 zk-email が直面している実際の課題の1つは、DKIM署名に依存していることであり、この署名は数ヶ月ごとにローテーションされる鍵を使用しており、これらの鍵自体は他の機関によって署名されていません。これは、現在の zk-email がプロバイダー自体を超えた一定の信頼要求を持っていることを意味します。もし zk-email が信頼できるハードウェア内でTLSNotaryを使用して更新された鍵を検証する場合、この状況は軽減されるかもしれませんが、理想的ではありません。電子メールプロバイダーが直接そのDKIM鍵に署名を始めることを期待しています。今日は、zk-emailを使用することを推奨するガーディアンがいますが、ほとんどのガーディアンには推奨されていません: zk-emailに資金を保管することは、ユーザーが資金を使用できない状況を意味します。
新規ユーザーとアプリ内ウォレット
新しいユーザーは、実際に最初の登録時に多くの保護者を入力したくありません。したがって、ウォレットは彼らに非常にシンプルな選択肢を提供する必要があります。自然な方法の一つは、彼らの電子メールアドレスで zk-email を使用し、ユーザーのデバイスにローカルに保存された鍵(、万能鍵)、そしてプロバイダーが保持するバックアップ鍵を用いて2-of-3の選択を行うことです。ユーザーがより経験豊富になるか、より多くの資産を蓄積するにつれて、ある時点で彼らに追加の保護者を追加するように促すべきです。
ウォレットをアプリケーションに統合することは避けられません。なぜなら、非暗号ユーザーを引き付けようとするアプリケーションは、ユーザーが同時に2つの新しいアプリ(アプリケーション自体、さらにエーテルウォレット)をダウンロードすることを望んでいないからです。それによって混乱したユーザー体験をもたらします。しかし、多くのアプリケーションウォレットのユーザーは、自分のすべてのウォレットをリンクさせることができるべきであり、そうすれば「アクセス制御問題」だけを心配すればよいのです。最も簡単な方法は、階層型のスキームを採用することです。そこでは、ユーザーが主ウォレットをすべてのアプリ内ウォレットの監護者として設定できる迅速な「リンク」プロセスが許可されます。特定のクライアントはすでにこれをサポートしています。
デフォルトでは、ユーザーの特定のアプリ内アカウントの復元はアプリ開発チームによって制御される場合があります。しかし、ユーザーは「引き継ぐ」ことができ、自分のアドレスに復元を変更することができます。
ユーザーを詐欺やその他の外部の脅威から保護する
アカウントのセキュリティに加えて、今日のウォレットは偽のアドレス、フィッシング、詐欺、およびその他の外部の脅威を特定するために多くの作業を行っており、ユーザーをそのような脅威から保護するために全力を尽くしています。一方で、多くの対策は依然としてかなり原始的です。たとえば、ユーザーが100ドルを送信する場合でも、ETHや他のトークンを新しいアドレスに送信するにはクリックを要求するなどです。