クロス-L2ユーザーエクスペリエンスの改善に向けた、ますます詳細なロードマップが現在存在しており、短期的な部分と長期的な部分に分かれています。ここでは、短期的な部分について話します。これらは理論的には今日でも実現可能なアイデアです。
コアアイデアは(i)組み込みのクロスL2送信、および(ii)チェーン固有のアドレスと支払いリクエストです。あなたのウォレットは、(「」のスタイルに従って)アドレスを提供できるはずです。この下書きERC) はこのように見えます。
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
この形式のアドレスが誰か(またはアプリケーション)から提供された場合、それをウォレットの「送信先」フィールドに貼り付け、[送信] をクリックすることができるはずです。ウォレットは自動的にその送信を可能な方法で処理するはずです:
可能なウォレットインターフェースのモックアップ、クロスチェーンアドレスのサポートを含む
上記は、「アドレスをコピーして貼り付ける(またはENSなど)」のためです。vitalik.eth@optimism.eth)がある場合、あなたに支払いをするための「使用例」として機能します。Dappが預金を要求している場合(例:見てください)このPolymarketの例)の場合、理想的なフローは、web3 APIを拡張し、dappがチェーン固有の支払いリクエストを行えるようにすることです。そうすれば、あなたのウォレットは、必要な方法でその要求を満たすことができます。ユーザーエクスペリエンスをうまく機能させるには、getAvailableBalanceリクエストを標準化する必要があり、ウォレットは、セキュリティと転送の容易さを最大化するために、デフォルトでユーザーの資産をどのチェーンに保存するかを大幅に検討する必要があります。
チェーン固有の支払いリクエストは、モバイルウォレットがスキャンできるQRコードにも入れることができます。対面(またはオンライン)の消費者支払いシナリオでは、受取人は「私はチェーンZのトークンYのX単位が欲しい。参照IDまたはコールバックWを添えて」というQRコードまたはweb3 APIコールを作成し、ウォレットはそのリクエストに自由に応えることができます。別のオプションは、クレームリンクプロトコルで、ユーザーのウォレットがQRコードまたはURLを生成し、それによってオンチェーン契約から一定量の資金を請求する権限が含まれており、それを受信者がどのようにしてその資金を自分のウォレットに移動させるかを考えることになります。
もう1つ関連するトピックはガスの支払いです。L2で資産を受け取る場合でまだETHがなく、そのL2でトランザクションを送信する必要がある場合、ウォレットは自動的にプロトコルを使用できるようにする必要があります(例:RIP-7755)ETHを持っているチェーン上のガスを支払うために、暗号通貨ウォレットがDEXを使用して少なくとも数百万ガス分のETHを送信するようにすることができます。これにより、将来のトランザクションで直接ガスを消費できるようになります(これはより安価です)。
アカウントのセキュリティの課題を考える上で、私が考える良いウォレットは、2つの領域で同時に優れている必要があります:(i) ウォレットの開発者がハッキングや悪意のある行為をされることからユーザーを保護すること、および (ii) ユーザーが自分自身のミスから保護されることです。
左側のタイポ「mistakles」は意図的ではありませんでした。しかし、それを見て、それが文脈に完全に適していることに気付いたので、それを保持することにしました。
私の好みの解決策は、オーバー十年、ソーシャルリカバリーおよびマルチシグウォレットが実施されました。グレード別のアクセス制御があります。ユーザーのアカウントには2つのキーレイヤーがあります。プライマリキーとN個のガーディアン(例:N = 5)。プライマリキーは、低価値および非金融操作を実行することができます。ガーディアンの過半数が、(i)アカウント内のすべての価値を送り出すなどの高価値操作、または(ii)プライマリキーまたはガーディアンのいずれかを変更するために必要です。必要に応じて、プライマリキーにはタイムロックを設定して高価値の操作を許可することもできます。
上記は基本的なデザインであり、拡張することができます。セッションキー、および許可メカニズムなどERC-7715、さまざまなアプリケーションの利便性とセキュリティのバランスをサポートすることができます。複雑な監視者アーキテクチャ(例:異なる閾値で複数のタイムロック期間を持つ)は、合法的なアカウントの回復の成功確率を最大化しながら、盗難のリスクを最小化するのに役立ちます。
経験豊富な暗号通貨ユーザーである場合、経験豊富な暗号通貨ユーザーのコミュニティ内の人々の鍵は、有効なオプションです。各人に新しいアドレスを提供するよう頼むと、誰が誰かは誰も知る必要がありません。実際、あなたの管理人たちさえもお互いが誰かを知る必要はありません。彼らがあなたに気付かれることなく共謀する可能性は非常に低いです。ただし、ほとんどの新規ユーザーにはこのオプションは利用できません。
第2のオプションは機関の管理者です:特定のサービスを実行する専門企業であり、取引を署名するためには、他の確認が得られる場合にのみ署名します。たとえば、確認コード、または高額利用者の場合はビデオ通話などの要求があることを確認します。これらは長い間作成されてきました。2013年にCryptoCorpのプロファイルを作成しましたしかし、これまでこうした企業はあまり成功していませんでした。
第三の選択肢は複数の個人用デバイス(例:電話、デスクトップ、ハードウェアウォレット)です。これは機能することができますが、未経験者にとって設定や管理が難しいです。同時に、特に同じ場所にある場合、デバイスが紛失または盗まれるリスクもあります。
最近、パスキーに基づいたウォレットが増えてきました。パスキーは個人デバイスのみでバックアップできるため、個人デバイスソリューションの一種となり、またはクラウドでバックアップできるため、そのセキュリティは依然としてクラウドに依存しています。複雑なハイブリッドパスワードのセキュリティ、機関および信頼できるハードウェアの仮定について。 現実的には、パスキーは普通のユーザーにとって貴重なセキュリティの利益ですが、それだけではユーザーの生活貯蓄を保護するには十分に強力ではありません。
幸いにも、ZK-SNARKsを使用することで、第四のオプションがあります:ZK-wrapped centralized ID。このジャンルには、zk-email, Anon Aadhaar、マイナウォレット, およびその他多くのもの。 基本的に、あなたは多くの形式の(企業または政府の)中央集権化されたIDを取り、それをイーサリアムアドレスに変換することができます。このアドレスからの取引は、中央集権化されたIDの所有を証明するZK-SNARKを生成することによってのみ行うことができます。
この追加により、私たちは今や幅広い選択肢を持っており、ZK-wrapped集中型IDはユニークに「初心者向け」です。
これが機能するためには、効率的かつ統合されたUIで実装する必要があります:指定したいというだけでexample@gmail.com”保護者として、それは自動的に対応するzk-email Ethereumアドレスを生成するはずです。上級ユーザーは、(おそらくプライバシーのための塩の値とともに)オープンソースのサードパーティーアプリケーションに自分のメールアドレスを入力し、生成されたアドレスが正しいことを確認することができるはずです。他のサポートされている保護者タイプに対しても同じことが当てはまるはずです。
可能なセーフインターフェースのモックアップ
今日の注意点は、特にzk-emailに関して、それが依存しているという実践的な課題があることです。DKIM署名数ヶ月ごとに回転するキーを使用し、これらのキー自体が他の権限によって署名されていないという特徴を持つ、これらのプロバイダによる信頼要件がある」という意味で、zk-emailは今日、プロバイダ自体を超えた信頼要件がある。これは、zk-emailが使用されることによって、信頼要件が削減される可能性がある。TLSNotary信頼されたハードウェア内で更新されたキーを検証するが、これは理想的ではない。 うまくいけば、電子メールプロバイダーはDKIMキーに直接署名することを開始するでしょう。 今日、1人の保護者にはzk-emailを使用することをお勧めしますが、保護者の大部分にはお勧めしません:zk-emailの破損があなたの資金へのアクセスを失うことを意味するセットアップには資金を保管しないでください。
新規ユーザーは最初のサインアップ体験で多数のガーディアンを入力したくないでしょう。したがって、ウォレットは非常にシンプルなオプションを提供する必要があります。自然なルートの1つは、メールアドレスのzk-emailを使用した2-of-3であり、ユーザーのデバイスにローカルに保存されたキー(パスキーである可能性があります)と、プロバイダーが保持するバックアップキーが含まれています。ユーザーがより経験を積んだり、資産を蓄積したりするにつれて、いつかより多くのガーディアンを追加するよう促されるべきです。
アプリケーションに統合されたウォレットは避けられません。なぜなら、非暗号通貨ユーザーを惹きつけるアプリケーションは、ユーザーに新しい2つのアプリケーション(アプリ自体とEthereumウォレット)を同時にダウンロードするという混乱するユーザーエクスペリエンスを望んでいないからです。ただし、多くのアプリケーションウォレットのユーザーは、すべてのウォレットをリンクしておく必要があります。これにより、ユーザーは「アクセス制御のための1つのもの」だけを心配することができます。これを行う最もシンプルな方法は、階層的なスキームです。このスキームでは、ユーザーがプライマリウォレットを設定してすべてのアプリケーションウォレットの管理者にするための迅速な「リンク」プロセスがあります。FarcasterクライアントWarpcastはこれをすでにサポートしています。
デフォルトでは、あなたのWarpcastアカウントの回復はWarpcastチームによって制御されています。しかし、あなたはあなた自身のアドレスに回復を変更することができます。
アカウントのセキュリティに加えて、ウォレットは今日、偽のアドレス、フィッシング、詐欺などの外部脅威を特定するために多くのことを行い、そのような脅威からユーザーを保護しようとします。同時に、多くの対策はまだかなり原始的です。たとえば、新しいアドレスにETHや他のトークンを送信するにはクリックスルーが必要です。送金額が$100であろうと$100,000であろうと関係なくです。ここでは、一つの魔法の銃弾の解決策はありません。異なるカテゴリの脅威に対する遅い継続的な修正と改善の連続です。ただし、ここでの改善作業を続けることには多くの価値があります。
今、Ethereumにおいてプライバシーに対してより真剣に取り組む時が来ています。ZK-SNARK技術は非常に高度になりました。バックドアに頼らずに規制リスクを軽減するプライバシー技術があります。gateなどの用語は変更しないでください。プライバシープール, 成熟度が高まっており、および二次的なインフラストラクチャーも成長していますWakuERC-4337メンプールは徐々に安定してきています。しかし、現時点では、Ethereum上でのプライベートトランザクションを行うには、ユーザーが明示的に「プライバシーウォレット」をダウンロードして使用する必要がありました。鉄道(またはウンブラ for ステルスアドレスこれにより、大きな不便が生じ、プライベートな送金を行うことに消極的な人が増えます。解決策は、プライベートな送金を直接ウォレットに統合する必要があります。
シンプルな実装方法は次のとおりです。ウォレットは、ユーザーの資産の一部をプライバシープール内の「プライベートバランス」として保存できます。ユーザーが送金を行うと、まずプライバシープールから自動的に引き出されます。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的にステルスアドレスを生成することができます。
さらに、ウォレットは、ユーザーが参加する各アプリケーション(例:defiプロトコル)に自動的に新しいアドレスを生成することができます。預金はプライバシープールから行われ、引き出しは直接プライバシープールに行われます。これにより、ユーザーの1つのアプリケーションでのアクティビティが他のアプリケーションでのアクティビティとは関連付けられなくなります。
この技術の利点の1つは、プライバシーを保護する資産の転送だけでなく、プライバシーを保護するアイデンティティへの自然な経路であることです。アイデンティティはすでにオンチェーンで発生しています:人格証明ゲーティング(例:Gitcoin Grants)を使用するアプリケーション、トークンゲートチャットを使用するアプリケーションなど、 Ethereum Follow Protocol、さらに多くのオンチェーンのアイデンティティがあります。このエコシステムもプライバシーを保護する必要があります。つまり、ユーザーのアクティビティは1つの場所に集められるべきではありません。各項目は個別に保存され、ユーザーのウォレットだけが同時にすべての証明を見ることができる「グローバルビュー」を持つものであるべきです。ユーザーごとに複数のアカウントがあるエコシステムは、これを実現するのに役立ちます。また、オフチェーンの証明プロトコルも役立ちます。EASとZupass.
これは、中長期的な将来におけるEthereumのプライバシーに対する実用的なビジョンを表しています。 これは今日実装することができますが、プライバシーを保護するためにL1およびL2で導入できる機能があります。一部のプライバシーの提唱者は、唯一許容されるものはすべてのものの完全なプライバシーであり、EVM全体を暗号化することだと主張しています。これは長期的な結果として理想的であるかもしれませんが、プログラミングモデルのより基本的な見直しが必要であり、現在の段階ではEthereum全体に展開する準備ができているとは言えません。私たちが十分に大きな匿名性の集合体を得るためには、デフォルトでプライバシーを持つ必要があります。ただし、ますます重要になっているのは、(i)口座間の送金、および(ii)アイデンティティおよびアイデンティティに関連する証明などのユースケースを最初にプライベートにすることです。これは実装しやすく、今日からウォレットが始めることができる実用的な最初のステップです。
どんな効果的なプライバシーソリューションであっても、支払いやアイデンティティ、その他のユースケースについてであっても、1つの結果は、ユーザーがオフチェーンデータを保存する必要が生じるということです。これはTornado Cashで明らかであり、それはユーザーに0.1-100 ETHの預金を表す各個々の「ノート」を保存する必要がありました。より現代的なプライバシープロトコルは、時にはデータを暗号化してオンチェーンに保存し、1つの秘密鍵を使用してそれを復号化します。これはリスクが伴います。なぜなら、鍵が漏洩した場合や、量子コンピュータが実用化された場合、すべてのデータが公開されてしまうからです。EASやZupassのようなオフチェーンの証明には、さらに明白なオフチェーンデータの保存の必要性があります。
ウォレットは、オンチェーンアクセス権限を保存するためのソフトウェアだけでなく、プライベートデータを保存するためのソフトウェアになる必要があります。これは、非暗号世界でもますます認識されていることであり、例えば、Tim Berners-Leeのことを見てください。パーソナルデータストアでの最近の作業。私たちが堅牢にアクセス許可の制御を保証する必要があるすべての問題と同様に、データのアクセス可能性と漏洩を確実に保証する必要もあります。おそらく解決策は重ね合わせることができるでしょう。N人の管理者がいる場合、同じN人の管理者間でM-of-N秘密分散を使用してデータを保存します。データはセキュリティが難しいものです。それを持っている人の共有を取り消すことはできませんが、できるだけ安全な分散管理の解決策を考えるべきです。
今日、ウォレットはRPCプロバイダーにチェーンに関する情報を教えてもらうことを信頼しています。これは2つの方法で脆弱性です:
理想的には、これらの両方の穴を塞ぎたいと思っています。最初の穴を塞ぐためには、L1とL2の標準化された軽量クライアントが必要です。これにより、ブロックチェーンのコンセンサスを直接検証します。ヘリオスすでにL1についてはこれを行っており、特定のL2をサポートするための予備的な作業も行ってきました。すべてのL2を適切にカバーするためには、L2を表す構成契約が関数を宣言できる標準が必要です(また、チェーン固有のアドレスにも使用されます)。おそらく、同様の方法で機能を宣言できるようにするための標準が必要です。ERC-3668最近の状態のルートを取得し、その状態のルートに対する状態およびレシートの証明を検証するためのロジックを含んでいます。これにより、ユニバーサルなライトクライアントを持つことができ、ウォレットはL1とL2上の任意の状態やイベントを安全に検証することができます。
プライバシーのために、今日、唯一現実的なアプローチは自分自身のフルノードを実行することです。ただし、L2が登場するようになった今、すべてのフルノードを実行することはますます困難になっています。ここでのライトクライアントに相当するものは、プライベート情報検索(PIR). PIRは、サーバーがすべてのデータのコピーを保持し、クライアントがサーバーに暗号化されたリクエストを送信することを含みます。サーバーはすべてのデータに対して計算を実行し、クライアントの希望するデータをクライアントのキーで暗号化して返しますが、クライアントがアクセスしたデータのどの部分かをサーバーには明らかにしません。
サーバーを正直に保つために、個々のデータベース項目自体がMerkleブランチであるため、クライアントは軽量クライアントを使用してそれらを確認できます。
PIRは非常に計算量が多くかかります。この問題にはいくつかの回避策があります:
Ethereumの文脈で実用性を維持しながらプライバシーを最大化するための適切な技術の組み合わせを見つけることは、未解決の研究課題です。暗号技術者が取り組むのを歓迎します。
トランスファーやステートアクセスに加えて、クロス-L2コンテキストでスムーズに動作する必要があるもう1つの重要なワークフローは、アカウントの検証構成を変更することです。つまり、キー(例:回復)を変更するか、アカウント全体のロジックに深刻な変更を加えるかどうかです。ここでは、難易度の上昇順に3つのソリューションがあります。
ソリューション(3)は、プライバシーとの組み合わせで特に強力です。通常の「プライバシーソリューション」では、ユーザーは秘密のsを持ち、チェーン上に「葉の値」Lが公開され、ユーザーはL = hash(s、1)およびN = hash(s、2)が彼らが制御する(決して明らかにされない)秘密のためであることを証明します。nullifier Nが公開され、同じ葉の将来の支出が失敗するようになり、Lが明らかにされることはありません。これには、ユーザーがsを安全に保つことが必要です。回復に優しいプライバシーソリューションでは、sはオンチェーン上の場所(例:アドレスとストレージスロット)であり、ユーザーは状態クエリを証明する必要があります:L = hash(sload(s)、1) 。
ユーザーのセキュリティにおける最も脆弱なリンクは、多くの場合、dappです。ほとんどの場合、ユーザーは Web サイトにアクセスしてアプリケーションを操作し、Web サイトは暗黙的にユーザー インターフェイス コードをサーバーからリアルタイムでダウンロードし、ブラウザー内で実行します。サーバーがハッキングされた場合、またはDNSがハッキングされた場合、ユーザーはインターフェイスの偽のコピーを取得し、ユーザーをだまして任意のことをさせる可能性があります。トランザクションシミュレーションなどのウォレット機能は、リスクを軽減するのに非常に役立ちますが、完璧にはほど遠いです。
理想的には、エコシステムをオンチェーンのコンテンツバージョニングに移行します。ユーザーは、そのENS名を介してDAppにアクセスすることができ、それにはインターフェースのIPFSハッシュが含まれています。マルチシグまたはDAOからのオンチェーントランザクションがインターフェースを更新するために必要です。ウォレットは、ユーザーがより安全なオンチェーンインターフェースか、より安全でないWeb2インターフェースかを示すことができます。ウォレットはまた、ユーザーが安全なチェーン(例:ステージ1+、複数のセキュリティ監査)とやり取りしているかどうかをユーザーに表示することができます。
プライバシーに配慮したユーザーのために、ウォレットにはパラノイドモードを追加することもでき、これによりユーザーはHTTPリクエストを受け入れるためにクリックする必要があり、Web3操作だけでなく:
パラノイドモードの可能なインターフェースのモックアップ
より高度なアプローチは、HTML + Javascriptを超えて進むことであり、dappsのビジネスロジックを専用の言語で書くことです。おそらく、SolidityまたはVyperの比較的薄いオーバーレイの上にあります。その後、ブラウザは必要な機能のために自動的にUIを生成できます。OKコントラクトは既にこれを行っています。
もう1つの方向性は、暗号経済の情報防御です。DApp開発者、セキュリティ企業、チェーン展開業者などが、あるオンチェーンの裁定DAOによって、DAppがハッキングされたり、高度に誤解を招く方法でユーザーに害を及ぼした場合、影響を受けたユーザーに支払われる保証金を提供することができます。ウォレットは、保証金の額に基づいたユーザーのスコアを表示することができます。
上記はすべて、従来のインタフェースの文脈でした。これには、物を指したりクリックしたり、テキストフィールドに入力したりすることが含まれています。しかし、私たちはさらに深くパラダイムが変わろうとしている最中でもあります。
これら 3 つのトレンドが組み合わさることで、インターフェイスの仕組みをより深く再考できるようになります。自然言語入力、アイトラッキング、最終的にはより直接的なBCIと、履歴に関する知識(すべてのデータがローカルで処理されている限り、テキストメッセージを含む)を通じて、「ウォレット」は、あなたが何をしたいのかについて、明確で直感的なアイデアを得ることができます。 AIは、その直感を具体的な「アクションプラン」、つまり、あなたが望むことを達成するための一連のオンチェーンとオフチェーンの相互作用に変換することができます。これにより、サードパーティのユーザーインターフェイスの必要性を大幅に減らすことができます。ユーザーがサードパーティのアプリケーション(または別のユーザー)と対話する場合、AIはユーザーに代わって敵対的に考え、脅威を特定し、それらを回避するためのアクションプランを提案する必要があります。理想的には、これらのAIのオープンなエコシステムが、異なるバイアスとインセンティブ構造を持つ異なるグループによって生み出されることです。
これらのより過激なアイデアは、現在非常に未熟な技術に依存しているため、今日の資産をそれに依存するウォレットに入れることはしません。ただし、このようなものは将来的には非常に明確なものになる可能性がありますので、その方向性をより積極的に探求する価値はあると思います。
クロス-L2ユーザーエクスペリエンスの改善に向けた、ますます詳細なロードマップが現在存在しており、短期的な部分と長期的な部分に分かれています。ここでは、短期的な部分について話します。これらは理論的には今日でも実現可能なアイデアです。
コアアイデアは(i)組み込みのクロスL2送信、および(ii)チェーン固有のアドレスと支払いリクエストです。あなたのウォレットは、(「」のスタイルに従って)アドレスを提供できるはずです。この下書きERC) はこのように見えます。
0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth
この形式のアドレスが誰か(またはアプリケーション)から提供された場合、それをウォレットの「送信先」フィールドに貼り付け、[送信] をクリックすることができるはずです。ウォレットは自動的にその送信を可能な方法で処理するはずです:
可能なウォレットインターフェースのモックアップ、クロスチェーンアドレスのサポートを含む
上記は、「アドレスをコピーして貼り付ける(またはENSなど)」のためです。vitalik.eth@optimism.eth)がある場合、あなたに支払いをするための「使用例」として機能します。Dappが預金を要求している場合(例:見てください)このPolymarketの例)の場合、理想的なフローは、web3 APIを拡張し、dappがチェーン固有の支払いリクエストを行えるようにすることです。そうすれば、あなたのウォレットは、必要な方法でその要求を満たすことができます。ユーザーエクスペリエンスをうまく機能させるには、getAvailableBalanceリクエストを標準化する必要があり、ウォレットは、セキュリティと転送の容易さを最大化するために、デフォルトでユーザーの資産をどのチェーンに保存するかを大幅に検討する必要があります。
チェーン固有の支払いリクエストは、モバイルウォレットがスキャンできるQRコードにも入れることができます。対面(またはオンライン)の消費者支払いシナリオでは、受取人は「私はチェーンZのトークンYのX単位が欲しい。参照IDまたはコールバックWを添えて」というQRコードまたはweb3 APIコールを作成し、ウォレットはそのリクエストに自由に応えることができます。別のオプションは、クレームリンクプロトコルで、ユーザーのウォレットがQRコードまたはURLを生成し、それによってオンチェーン契約から一定量の資金を請求する権限が含まれており、それを受信者がどのようにしてその資金を自分のウォレットに移動させるかを考えることになります。
もう1つ関連するトピックはガスの支払いです。L2で資産を受け取る場合でまだETHがなく、そのL2でトランザクションを送信する必要がある場合、ウォレットは自動的にプロトコルを使用できるようにする必要があります(例:RIP-7755)ETHを持っているチェーン上のガスを支払うために、暗号通貨ウォレットがDEXを使用して少なくとも数百万ガス分のETHを送信するようにすることができます。これにより、将来のトランザクションで直接ガスを消費できるようになります(これはより安価です)。
アカウントのセキュリティの課題を考える上で、私が考える良いウォレットは、2つの領域で同時に優れている必要があります:(i) ウォレットの開発者がハッキングや悪意のある行為をされることからユーザーを保護すること、および (ii) ユーザーが自分自身のミスから保護されることです。
左側のタイポ「mistakles」は意図的ではありませんでした。しかし、それを見て、それが文脈に完全に適していることに気付いたので、それを保持することにしました。
私の好みの解決策は、オーバー十年、ソーシャルリカバリーおよびマルチシグウォレットが実施されました。グレード別のアクセス制御があります。ユーザーのアカウントには2つのキーレイヤーがあります。プライマリキーとN個のガーディアン(例:N = 5)。プライマリキーは、低価値および非金融操作を実行することができます。ガーディアンの過半数が、(i)アカウント内のすべての価値を送り出すなどの高価値操作、または(ii)プライマリキーまたはガーディアンのいずれかを変更するために必要です。必要に応じて、プライマリキーにはタイムロックを設定して高価値の操作を許可することもできます。
上記は基本的なデザインであり、拡張することができます。セッションキー、および許可メカニズムなどERC-7715、さまざまなアプリケーションの利便性とセキュリティのバランスをサポートすることができます。複雑な監視者アーキテクチャ(例:異なる閾値で複数のタイムロック期間を持つ)は、合法的なアカウントの回復の成功確率を最大化しながら、盗難のリスクを最小化するのに役立ちます。
経験豊富な暗号通貨ユーザーである場合、経験豊富な暗号通貨ユーザーのコミュニティ内の人々の鍵は、有効なオプションです。各人に新しいアドレスを提供するよう頼むと、誰が誰かは誰も知る必要がありません。実際、あなたの管理人たちさえもお互いが誰かを知る必要はありません。彼らがあなたに気付かれることなく共謀する可能性は非常に低いです。ただし、ほとんどの新規ユーザーにはこのオプションは利用できません。
第2のオプションは機関の管理者です:特定のサービスを実行する専門企業であり、取引を署名するためには、他の確認が得られる場合にのみ署名します。たとえば、確認コード、または高額利用者の場合はビデオ通話などの要求があることを確認します。これらは長い間作成されてきました。2013年にCryptoCorpのプロファイルを作成しましたしかし、これまでこうした企業はあまり成功していませんでした。
第三の選択肢は複数の個人用デバイス(例:電話、デスクトップ、ハードウェアウォレット)です。これは機能することができますが、未経験者にとって設定や管理が難しいです。同時に、特に同じ場所にある場合、デバイスが紛失または盗まれるリスクもあります。
最近、パスキーに基づいたウォレットが増えてきました。パスキーは個人デバイスのみでバックアップできるため、個人デバイスソリューションの一種となり、またはクラウドでバックアップできるため、そのセキュリティは依然としてクラウドに依存しています。複雑なハイブリッドパスワードのセキュリティ、機関および信頼できるハードウェアの仮定について。 現実的には、パスキーは普通のユーザーにとって貴重なセキュリティの利益ですが、それだけではユーザーの生活貯蓄を保護するには十分に強力ではありません。
幸いにも、ZK-SNARKsを使用することで、第四のオプションがあります:ZK-wrapped centralized ID。このジャンルには、zk-email, Anon Aadhaar、マイナウォレット, およびその他多くのもの。 基本的に、あなたは多くの形式の(企業または政府の)中央集権化されたIDを取り、それをイーサリアムアドレスに変換することができます。このアドレスからの取引は、中央集権化されたIDの所有を証明するZK-SNARKを生成することによってのみ行うことができます。
この追加により、私たちは今や幅広い選択肢を持っており、ZK-wrapped集中型IDはユニークに「初心者向け」です。
これが機能するためには、効率的かつ統合されたUIで実装する必要があります:指定したいというだけでexample@gmail.com”保護者として、それは自動的に対応するzk-email Ethereumアドレスを生成するはずです。上級ユーザーは、(おそらくプライバシーのための塩の値とともに)オープンソースのサードパーティーアプリケーションに自分のメールアドレスを入力し、生成されたアドレスが正しいことを確認することができるはずです。他のサポートされている保護者タイプに対しても同じことが当てはまるはずです。
可能なセーフインターフェースのモックアップ
今日の注意点は、特にzk-emailに関して、それが依存しているという実践的な課題があることです。DKIM署名数ヶ月ごとに回転するキーを使用し、これらのキー自体が他の権限によって署名されていないという特徴を持つ、これらのプロバイダによる信頼要件がある」という意味で、zk-emailは今日、プロバイダ自体を超えた信頼要件がある。これは、zk-emailが使用されることによって、信頼要件が削減される可能性がある。TLSNotary信頼されたハードウェア内で更新されたキーを検証するが、これは理想的ではない。 うまくいけば、電子メールプロバイダーはDKIMキーに直接署名することを開始するでしょう。 今日、1人の保護者にはzk-emailを使用することをお勧めしますが、保護者の大部分にはお勧めしません:zk-emailの破損があなたの資金へのアクセスを失うことを意味するセットアップには資金を保管しないでください。
新規ユーザーは最初のサインアップ体験で多数のガーディアンを入力したくないでしょう。したがって、ウォレットは非常にシンプルなオプションを提供する必要があります。自然なルートの1つは、メールアドレスのzk-emailを使用した2-of-3であり、ユーザーのデバイスにローカルに保存されたキー(パスキーである可能性があります)と、プロバイダーが保持するバックアップキーが含まれています。ユーザーがより経験を積んだり、資産を蓄積したりするにつれて、いつかより多くのガーディアンを追加するよう促されるべきです。
アプリケーションに統合されたウォレットは避けられません。なぜなら、非暗号通貨ユーザーを惹きつけるアプリケーションは、ユーザーに新しい2つのアプリケーション(アプリ自体とEthereumウォレット)を同時にダウンロードするという混乱するユーザーエクスペリエンスを望んでいないからです。ただし、多くのアプリケーションウォレットのユーザーは、すべてのウォレットをリンクしておく必要があります。これにより、ユーザーは「アクセス制御のための1つのもの」だけを心配することができます。これを行う最もシンプルな方法は、階層的なスキームです。このスキームでは、ユーザーがプライマリウォレットを設定してすべてのアプリケーションウォレットの管理者にするための迅速な「リンク」プロセスがあります。FarcasterクライアントWarpcastはこれをすでにサポートしています。
デフォルトでは、あなたのWarpcastアカウントの回復はWarpcastチームによって制御されています。しかし、あなたはあなた自身のアドレスに回復を変更することができます。
アカウントのセキュリティに加えて、ウォレットは今日、偽のアドレス、フィッシング、詐欺などの外部脅威を特定するために多くのことを行い、そのような脅威からユーザーを保護しようとします。同時に、多くの対策はまだかなり原始的です。たとえば、新しいアドレスにETHや他のトークンを送信するにはクリックスルーが必要です。送金額が$100であろうと$100,000であろうと関係なくです。ここでは、一つの魔法の銃弾の解決策はありません。異なるカテゴリの脅威に対する遅い継続的な修正と改善の連続です。ただし、ここでの改善作業を続けることには多くの価値があります。
今、Ethereumにおいてプライバシーに対してより真剣に取り組む時が来ています。ZK-SNARK技術は非常に高度になりました。バックドアに頼らずに規制リスクを軽減するプライバシー技術があります。gateなどの用語は変更しないでください。プライバシープール, 成熟度が高まっており、および二次的なインフラストラクチャーも成長していますWakuERC-4337メンプールは徐々に安定してきています。しかし、現時点では、Ethereum上でのプライベートトランザクションを行うには、ユーザーが明示的に「プライバシーウォレット」をダウンロードして使用する必要がありました。鉄道(またはウンブラ for ステルスアドレスこれにより、大きな不便が生じ、プライベートな送金を行うことに消極的な人が増えます。解決策は、プライベートな送金を直接ウォレットに統合する必要があります。
シンプルな実装方法は次のとおりです。ウォレットは、ユーザーの資産の一部をプライバシープール内の「プライベートバランス」として保存できます。ユーザーが送金を行うと、まずプライバシープールから自動的に引き出されます。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的にステルスアドレスを生成することができます。
さらに、ウォレットは、ユーザーが参加する各アプリケーション(例:defiプロトコル)に自動的に新しいアドレスを生成することができます。預金はプライバシープールから行われ、引き出しは直接プライバシープールに行われます。これにより、ユーザーの1つのアプリケーションでのアクティビティが他のアプリケーションでのアクティビティとは関連付けられなくなります。
この技術の利点の1つは、プライバシーを保護する資産の転送だけでなく、プライバシーを保護するアイデンティティへの自然な経路であることです。アイデンティティはすでにオンチェーンで発生しています:人格証明ゲーティング(例:Gitcoin Grants)を使用するアプリケーション、トークンゲートチャットを使用するアプリケーションなど、 Ethereum Follow Protocol、さらに多くのオンチェーンのアイデンティティがあります。このエコシステムもプライバシーを保護する必要があります。つまり、ユーザーのアクティビティは1つの場所に集められるべきではありません。各項目は個別に保存され、ユーザーのウォレットだけが同時にすべての証明を見ることができる「グローバルビュー」を持つものであるべきです。ユーザーごとに複数のアカウントがあるエコシステムは、これを実現するのに役立ちます。また、オフチェーンの証明プロトコルも役立ちます。EASとZupass.
これは、中長期的な将来におけるEthereumのプライバシーに対する実用的なビジョンを表しています。 これは今日実装することができますが、プライバシーを保護するためにL1およびL2で導入できる機能があります。一部のプライバシーの提唱者は、唯一許容されるものはすべてのものの完全なプライバシーであり、EVM全体を暗号化することだと主張しています。これは長期的な結果として理想的であるかもしれませんが、プログラミングモデルのより基本的な見直しが必要であり、現在の段階ではEthereum全体に展開する準備ができているとは言えません。私たちが十分に大きな匿名性の集合体を得るためには、デフォルトでプライバシーを持つ必要があります。ただし、ますます重要になっているのは、(i)口座間の送金、および(ii)アイデンティティおよびアイデンティティに関連する証明などのユースケースを最初にプライベートにすることです。これは実装しやすく、今日からウォレットが始めることができる実用的な最初のステップです。
どんな効果的なプライバシーソリューションであっても、支払いやアイデンティティ、その他のユースケースについてであっても、1つの結果は、ユーザーがオフチェーンデータを保存する必要が生じるということです。これはTornado Cashで明らかであり、それはユーザーに0.1-100 ETHの預金を表す各個々の「ノート」を保存する必要がありました。より現代的なプライバシープロトコルは、時にはデータを暗号化してオンチェーンに保存し、1つの秘密鍵を使用してそれを復号化します。これはリスクが伴います。なぜなら、鍵が漏洩した場合や、量子コンピュータが実用化された場合、すべてのデータが公開されてしまうからです。EASやZupassのようなオフチェーンの証明には、さらに明白なオフチェーンデータの保存の必要性があります。
ウォレットは、オンチェーンアクセス権限を保存するためのソフトウェアだけでなく、プライベートデータを保存するためのソフトウェアになる必要があります。これは、非暗号世界でもますます認識されていることであり、例えば、Tim Berners-Leeのことを見てください。パーソナルデータストアでの最近の作業。私たちが堅牢にアクセス許可の制御を保証する必要があるすべての問題と同様に、データのアクセス可能性と漏洩を確実に保証する必要もあります。おそらく解決策は重ね合わせることができるでしょう。N人の管理者がいる場合、同じN人の管理者間でM-of-N秘密分散を使用してデータを保存します。データはセキュリティが難しいものです。それを持っている人の共有を取り消すことはできませんが、できるだけ安全な分散管理の解決策を考えるべきです。
今日、ウォレットはRPCプロバイダーにチェーンに関する情報を教えてもらうことを信頼しています。これは2つの方法で脆弱性です:
理想的には、これらの両方の穴を塞ぎたいと思っています。最初の穴を塞ぐためには、L1とL2の標準化された軽量クライアントが必要です。これにより、ブロックチェーンのコンセンサスを直接検証します。ヘリオスすでにL1についてはこれを行っており、特定のL2をサポートするための予備的な作業も行ってきました。すべてのL2を適切にカバーするためには、L2を表す構成契約が関数を宣言できる標準が必要です(また、チェーン固有のアドレスにも使用されます)。おそらく、同様の方法で機能を宣言できるようにするための標準が必要です。ERC-3668最近の状態のルートを取得し、その状態のルートに対する状態およびレシートの証明を検証するためのロジックを含んでいます。これにより、ユニバーサルなライトクライアントを持つことができ、ウォレットはL1とL2上の任意の状態やイベントを安全に検証することができます。
プライバシーのために、今日、唯一現実的なアプローチは自分自身のフルノードを実行することです。ただし、L2が登場するようになった今、すべてのフルノードを実行することはますます困難になっています。ここでのライトクライアントに相当するものは、プライベート情報検索(PIR). PIRは、サーバーがすべてのデータのコピーを保持し、クライアントがサーバーに暗号化されたリクエストを送信することを含みます。サーバーはすべてのデータに対して計算を実行し、クライアントの希望するデータをクライアントのキーで暗号化して返しますが、クライアントがアクセスしたデータのどの部分かをサーバーには明らかにしません。
サーバーを正直に保つために、個々のデータベース項目自体がMerkleブランチであるため、クライアントは軽量クライアントを使用してそれらを確認できます。
PIRは非常に計算量が多くかかります。この問題にはいくつかの回避策があります:
Ethereumの文脈で実用性を維持しながらプライバシーを最大化するための適切な技術の組み合わせを見つけることは、未解決の研究課題です。暗号技術者が取り組むのを歓迎します。
トランスファーやステートアクセスに加えて、クロス-L2コンテキストでスムーズに動作する必要があるもう1つの重要なワークフローは、アカウントの検証構成を変更することです。つまり、キー(例:回復)を変更するか、アカウント全体のロジックに深刻な変更を加えるかどうかです。ここでは、難易度の上昇順に3つのソリューションがあります。
ソリューション(3)は、プライバシーとの組み合わせで特に強力です。通常の「プライバシーソリューション」では、ユーザーは秘密のsを持ち、チェーン上に「葉の値」Lが公開され、ユーザーはL = hash(s、1)およびN = hash(s、2)が彼らが制御する(決して明らかにされない)秘密のためであることを証明します。nullifier Nが公開され、同じ葉の将来の支出が失敗するようになり、Lが明らかにされることはありません。これには、ユーザーがsを安全に保つことが必要です。回復に優しいプライバシーソリューションでは、sはオンチェーン上の場所(例:アドレスとストレージスロット)であり、ユーザーは状態クエリを証明する必要があります:L = hash(sload(s)、1) 。
ユーザーのセキュリティにおける最も脆弱なリンクは、多くの場合、dappです。ほとんどの場合、ユーザーは Web サイトにアクセスしてアプリケーションを操作し、Web サイトは暗黙的にユーザー インターフェイス コードをサーバーからリアルタイムでダウンロードし、ブラウザー内で実行します。サーバーがハッキングされた場合、またはDNSがハッキングされた場合、ユーザーはインターフェイスの偽のコピーを取得し、ユーザーをだまして任意のことをさせる可能性があります。トランザクションシミュレーションなどのウォレット機能は、リスクを軽減するのに非常に役立ちますが、完璧にはほど遠いです。
理想的には、エコシステムをオンチェーンのコンテンツバージョニングに移行します。ユーザーは、そのENS名を介してDAppにアクセスすることができ、それにはインターフェースのIPFSハッシュが含まれています。マルチシグまたはDAOからのオンチェーントランザクションがインターフェースを更新するために必要です。ウォレットは、ユーザーがより安全なオンチェーンインターフェースか、より安全でないWeb2インターフェースかを示すことができます。ウォレットはまた、ユーザーが安全なチェーン(例:ステージ1+、複数のセキュリティ監査)とやり取りしているかどうかをユーザーに表示することができます。
プライバシーに配慮したユーザーのために、ウォレットにはパラノイドモードを追加することもでき、これによりユーザーはHTTPリクエストを受け入れるためにクリックする必要があり、Web3操作だけでなく:
パラノイドモードの可能なインターフェースのモックアップ
より高度なアプローチは、HTML + Javascriptを超えて進むことであり、dappsのビジネスロジックを専用の言語で書くことです。おそらく、SolidityまたはVyperの比較的薄いオーバーレイの上にあります。その後、ブラウザは必要な機能のために自動的にUIを生成できます。OKコントラクトは既にこれを行っています。
もう1つの方向性は、暗号経済の情報防御です。DApp開発者、セキュリティ企業、チェーン展開業者などが、あるオンチェーンの裁定DAOによって、DAppがハッキングされたり、高度に誤解を招く方法でユーザーに害を及ぼした場合、影響を受けたユーザーに支払われる保証金を提供することができます。ウォレットは、保証金の額に基づいたユーザーのスコアを表示することができます。
上記はすべて、従来のインタフェースの文脈でした。これには、物を指したりクリックしたり、テキストフィールドに入力したりすることが含まれています。しかし、私たちはさらに深くパラダイムが変わろうとしている最中でもあります。
これら 3 つのトレンドが組み合わさることで、インターフェイスの仕組みをより深く再考できるようになります。自然言語入力、アイトラッキング、最終的にはより直接的なBCIと、履歴に関する知識(すべてのデータがローカルで処理されている限り、テキストメッセージを含む)を通じて、「ウォレット」は、あなたが何をしたいのかについて、明確で直感的なアイデアを得ることができます。 AIは、その直感を具体的な「アクションプラン」、つまり、あなたが望むことを達成するための一連のオンチェーンとオフチェーンの相互作用に変換することができます。これにより、サードパーティのユーザーインターフェイスの必要性を大幅に減らすことができます。ユーザーがサードパーティのアプリケーション(または別のユーザー)と対話する場合、AIはユーザーに代わって敵対的に考え、脅威を特定し、それらを回避するためのアクションプランを提案する必要があります。理想的には、これらのAIのオープンなエコシステムが、異なるバイアスとインセンティブ構造を持つ異なるグループによって生み出されることです。
これらのより過激なアイデアは、現在非常に未熟な技術に依存しているため、今日の資産をそれに依存するウォレットに入れることはしません。ただし、このようなものは将来的には非常に明確なものになる可能性がありますので、その方向性をより積極的に探求する価値はあると思います。