ヴィタリック: 理想的なイーサ・ウォレットとは？

もともとはとして出版された。

著者：Vitalik、Ether創設者、コンパイラー：Deng Tong、Golden Finance

フィードバックとレビューをしてくれたLiraz Siri、Yoav Weiss、ImToken、Metamask、OKXの開発者に感謝する。

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

最近、私たちはイーサウォレットのユーザーエクスペリエンス、セキュリティ、機能性を向上させるために多くの進歩を見てきました。この投稿の目的は、理想的なイーサウォレットが持つべき属性について私自身の考えを述べることです。これは完全なリストではありません。私の暗号パンク的傾向を反映しており、セキュリティとプライバシーに焦点を当てています。しかし、ユーザー・エクスペリエンスを最適化する上で、ウィッシュリストは単に展開し、フィードバックに基づいて反復するほど効果的ではないと思うので、セキュリティとプライバシーの属性に焦点を当てることが最も価値があると思う。

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

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

中核となるアイデアは、(i)組み込みのトランスL2送信、(ii)チェーン固有のアドレスと支払い要求です。

[email protected]

以下のように、あなたのウォレットは（このドラフトERCのスタイルに従って）アドレスを提供できるはずです：

[email protected]

When誰か(または何らかのアプリケーション)がこのフォーマットでアドレスを提供してくれたら、それをウォレットのToフィールドに貼り付けてSendをクリックします。

• ターゲットチェーン上に希望のタイプのトークンがすでに十分にある場合は、それらを直接送信します。

  別のチェーン（または複数の他のチェーン）に必要なタイプのトークンがある場合は、ERC-7683（実際にはクロスチェーンDEXです）などのプロトコルを使用してトークンを送信します。

• 同じチェーンまたは他のチェーンに異なるタイプのトークンがある場合は、分散型取引所を使用して、正しいチェーンの正しいタイプのトークンに変換して送信します。トークンに変換して送信してください。これはユーザーからの明示的な許可を必要とするはずです。ユーザーは、自分がいくら支払ったか、受信者がいくら受け取ったかを見ることができます。

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

上記は、「誰かがあなたに支払いを行えるように、アドレス（またはENS、例えば[email protected]）をコピーして貼り付ける」というユースケースに当てはまります。もしダップがデポジットを要求しているのであれば（例えばPolymarketの例を参照）、理想的なフローはweb3 APIを拡張し、ダップがチェーン固有の支払い要求を行えるようにすることでしょう。あなたのウォレットは、必要な方法でその要求を満たすことができます。良いユーザーエクスペリエンスのためには、getAvailableBalanceリクエストも標準化される必要があり、ウォレットはセキュリティと転送のしやすさを最大化するために、デフォルトでどのチェーンにユーザー資産を保存するかを慎重に検討する必要があるでしょう。

チェーン固有の支払いリクエストは、モバイルウォレットがスキャンできるQRコードに入れることもできる。対面式（またはオンライン）の消費者支払いシナリオでは、受信者は「チェーンZのXユニットトークンYが欲しい、参照IDまたはコールバックWで」というQRコードまたはWeb3 APIコールを発行し、ウォレットは可能な限り自由に要求を満たすことができます。この場合、ユーザーのウォレットは、チェーン上のコントラクトから一定額の資金を請求するための権限を含むQRコードまたはURLを生成し、受信者はその資金を自分の口座に送金する方法を見つけることになります。

関連するもう1つのトピックは、ガス決済です。まだETHを持っていないL2上のアセットを受け取り、そのL2上でトランザクションを送信する必要がある場合、ウォレットは自動的にプロトコル（例えばRIP-7755）を使用して、ETHを持っているチェーン上でガスの支払いを行うことができるはずです。もしウォレットが将来その L2 上でより多くのトランザクションを行うことを望むのであれば、その送信にも DEX のみを使用すべきです。ETHは数百万ガスに値するので、将来の取引はそこで直接ガスを使うことができます（その方が安いからです）。

アカウントセキュリティ

私がアカウントセキュリティの課題を概念化する1つの方法は、優れたウォレットは同時に2つの面で機能すべきだということです。(ii)ユーザーを自身の過ちから守ることです。

左の「エラー」は意図的なものではありません。しかし、それを見たとき、文脈にぴったり合っていることに気づいたので、そのままにすることにした。

10年以上にわたって、私が好んで使ってきたソリューションは、ソーシャルリカバリーと、階層的なアクセス制御を備えたマルチ署名ウォレットでした。ユーザーのアカウントには、マスターキーとN個の保護者（たとえばN = 5）という2層のキーがあります。マスター・キーは価値の低い、非金融的な操作を行うことができる。ほとんどのガーディアンは、(i)口座の全額を送金するなどの高価値操作、または (ii)マスター・キーやガーディアンの変更を行う必要がある。もし必要であれば、マスターキーは時間ロックによって、 価値の高いオペレーションを実行できるようにすることができる。

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

ガーディアンは誰であるべきか、何であるべきか？

ベテランの暗号通貨ユーザーコミュニティにおける実行可能な選択肢の1つは、友人や家族の鍵です。全員に新しいアドレスを提供してもらう場合、誰も自分が誰なのかを知る必要はありません -- 実際、後見人は互いが誰なのかを知る必要すらありません。むしろ、保護者同士が互いの素性を知る必要さえない。もし保護者たちがあなたに情報を漏らしていないなら、共謀している可能性は極めて低い。しかし、このオプションはほとんどの新規ユーザーには利用できません。

2つ目の選択肢は、機関後見人です。サービスを専門に提供する会社で、あなたの要求から他の確認を得た場合にのみ、取引に署名します。確認コードとか、価値の高いユーザーにはビデオ通話とか。人々は長い間、こうしたものを作ろうとしてきた。私は2013年にCryptoCorpを紹介した。しかし、これまでのところ、この種の企業はあまり成功していない。

3つ目の選択肢は、複数の個人用デバイス（携帯電話、デスクトップ、ハードウェアウォレットなど）です。これは実現可能ですが、経験の浅いユーザーにとってはセットアップや管理が難しくなります。また、特に同じ場所にある場合、デバイスの紛失や盗難のリスクもあります。

最近では、キーベースのウォレットが目につくようになってきました。パスワードはデバイスにしかバックアップできないため、個人デバイスのソリューションとなるか、クラウドにバックアップされるため、そのセキュリティは暗号化セキュリティ、制度、信頼できるハードウェアの前提の複雑な組み合わせに依存することになります。現実には、鍵は平均的なユーザーにとっては貴重なセキュリティ上の利点ですが、ユーザーの生活貯蓄を守るにはそれだけでは十分ではありません。

幸いなことに、ZK-SNARKには第4の選択肢があります。zk-packed centralised IDsです。このタイプには、zk-email、Anon Aadhaar、Myna Walletなどがあります。基本的には、複数の形態（企業や政府）の集中型IDをイーサアドレスに変換し、集中型IDを持っていることを証明するZK-SNARKを生成することによってのみトランザクションを送信することができます。

この追加により、私たちは幅広い選択肢と、ZKパッケージの集中型IDに対する独自の「初心者に優しい」IDを手に入れることができるようになりました。

そのためには、簡略化された統合されたUIで実現する必要があります。保護者として「[email protected]」を指定するだけで、対応するzk-emailイーサアドレスが自動的に生成されるようにする必要があります。上級ユーザは、オープンソースのサードパーティアプリケーションに自分の電子メール（およびその電子メールに保存されている可能性のあるプライバシーソルト）を入力し、生成されたアドレスが正しいことを確認できるはずです。同じことが、サポートされている他の保護者タイプにも当てはまるはずです。

考えられるセキュアなインターフェイス モデル

今日のzk-emailが直面している現実的な課題の1つは、数ヶ月ごとにローテーションされるキーを使用するDKIM署名に依存していることです。DKIM署名は、数カ月ごとに入れ替わる鍵を使用し、それ自身は他のいかなる権威によっても署名されていない。zk-emailが更新された鍵を検証するために、信頼できるハードウェア内でTLSNotaryを使用すれば、これを減らすことができるが、これは理想的ではない。メールプロバイダーがDKIM鍵に直接署名するようになることを期待したい。zk-emailの破損によって資金が使えなくなるような設定にはしないことです。

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

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

アプリにウォレットを統合することは避けられません。非クリプトユーザーを引き付けようとするアプリは、ユーザーが同時に2つの新しいアプリ（アプリ自体とイーサウォレット）をダウンロードするという混乱したユーザーエクスペリエンスを望まないからです。しかし、多くのアプリのウォレットを使用しているユーザーは、1つの「アクセス制御の問題」だけを心配すればよいように、すべてのウォレットを一緒にリンクできるようにする必要があります。これを実現する最も簡単な方法は、ユーザーが自分のプライマリ・ウォレットをすべてのアプリ内ウォレットの保護者として設定できるような、迅速な「リンク」プロセスを備えたレイヤード・アプローチを採用することだ。 FarcasterクライアントのWarpcastはすでにこれをサポートしています:

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

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

アカウントのセキュリティに加えて、今日のウォレットは偽アドレス、フィッシング、詐欺、その他の外部脅威を特定するために多くのことを行い、ユーザーをそれらから守るためにできることをしています。その一方で、多くの対策はまだかなり原始的である。例えば、100ドルであろうと100,000ドルであろうと、新しいアドレスにETHやその他のトークンを送信するにはクリックが必要である。ここには唯一の特効薬はない。さまざまな脅威のカテゴリーに対して、継続的な修正と改善をゆっくりと積み重ねていくことになる。しかし、ここで改善に取り組み続けることには多くの価値がある。

プライバシー

イーサリアムのプライバシーをもっと真剣に考え始める時期が来ています。 ZK-SNARK技術は現在非常に進んでおり、規制リスクを軽減するためにバックドアに頼らないプライバシー技術（プライバシープールなど）はより洗練されつつあり、WakuやERC-4337 mempoolsのような二次的なインフラは徐々に安定してきています。しかし、これまでイーサでの私的送金は、ユーザーが明示的にRailway（または不可視アドレス用のUmbra）のような「プライバシーウォレット」をダウンロードして使用する必要がありました。これは大きな不便をもたらし、私的送金を行う人の数を減らしています。解決策は、私的送金をウォレットに直接統合することです。

簡単な実装は以下の通りです。ウォレットはユーザーの資産の一部を「プライベート残高」としてプライバシープールに保管することができます。ユーザーが送金をすると、自動的にプライバシープールから抜ける。ユーザーが資金を受け取る必要がある場合、ウォレットは自動的に不可視アドレスを生成することができます。

さらに、ウォレットはユーザーが参加するアプリケーション（例えばdefiプロトコル）ごとに新しいアドレスを自動的に生成することができる。入金はプライバシープールから行われ、出金はプライバシープールに直接行われます。これにより、1つのアプリでのユーザーの活動は、他のアプリでの活動からリンクされなくなる。

この技術の利点の1つは、プライバシーを保護する資産移転だけでなく、プライバシーを保護するアイデンティティも自然に保護できることです。アイデンティティはすでにオンチェーンで発生しています。アイデンティティ証明ゲーティングを使用するアプリケーション（Gitcoin Grantsなど）、トークンゲーティングチャット、Ether Followプロトコルなどはすべてオンチェーンアイデンティティです。私たちはこのエコシステムがプライバシーも保護することを望んでいます。各プロジェクトは別々に保存されるべきであり、ユーザーのウォレットは同時にすべての証明の「グローバルビュー」を持つ唯一のものであるべきです。ネイティブのユーザーごとのマルチアカウントエコシステムは、EASやZupassのようなオフチェーンの使用証明プロトコルと同様に、これを達成するのに役立ちます。

これは中期的なイーサリアムのプライバシーの現実的なビジョンを表しています。プライバシーを保護する送信をより効率的で信頼性の高いものにするために、L1とL2で機能が導入される可能性はありますが、それは現在達成可能です。プライバシー擁護者の中には、唯一受け入れられるのはすべてのものに対する完全なプライバシー、つまりEVM全体を暗号化することだと主張する人もいます。これは長期的には望ましい結果かもしれませんが、より根本的なプログラミングモデルの再考が必要であり、イーサリアムにデプロイできる成熟度にはまだ達していません。十分に大きな匿名性セットを得るためには、デフォルトのプライバシーが必要です。しかし、(i)アカウント間の送金、(ii)アイデンティティとアイデンティティに関連するユースケース（プライベート証明など）にまず焦点を当てることは、現実的な最初のステップであり、実装が容易で、ウォレットは今すぐにでも利用できます。

Etherウォレットもデータウォレットである必要がある

効果的なプライバシーソリューションの結果の1つは、それが支払いやID、その他のユースケースに使われるものであれ、ユーザーがチェーン外のデータを保存する必要性を生み出すことです。これはTornado Cashで明らかで、ユーザーは0.1-100ETHのデポジットを表す各「チケット」を保存する必要がある。より近代的なプライバシー・プロトコルは、暗号化されたデータをオンチェーンに保存し、単一の秘密鍵を使って復号化することがある。鍵が漏洩した場合、あるいは量子コンピュータが実用化された場合、データはすべて公開されてしまうので、これは危険である。 EASやZupassのようなオフチェーン証明では、オフチェーンデータストレージの必要性はより明白です。

ウォレットは、オンチェーンアクセスだけでなく、プライベートデータも保存するソフトウェアである必要があります。例えば、非暗号化世界もこのことを認識しつつあります。ティム・バーナーズ＝リー個人データストレージに関する最近の仕事をご覧ください。アクセス権制御を強固に保証するために解決しなければならない問題はすべて、データへのアクセシビリティと非漏洩を強固に保証するために解決する必要もあります。N人の保護者がいる場合、それらのN人の保護者間でM-of-Nの秘密共有を使用してデータを保存します。誰かのデータ共有を取り消すことはできないので、データを保護するのは本質的に難しいが、可能な限り安全な分散型の保管ソリューションを考え出すべきだ。

Secure Chain Access

今日、ウォレットはRPCプロバイダーがチェーンについて何でも教えてくれると信じています。

• RPCプロバイダーは、例えば市場価格についてなど、偽の情報を与えてお金を盗もうとするかもしれません

• RPCプロバイダーは、ユーザーがやりとりしているアプリケーションや他のアカウントに関するプライベートな情報を引き出すことができます

理想的には、これらの脆弱性の両方を閉じたいと考えています。1つ目の脆弱性に対処するには、ブロックチェーンのコンセンサスを直接検証できる、L1とL2用の標準化されたライトクライアントが必要です。 すべてのL2を正しくカバーするためには、L2（チェーン固有のアドレスにも使用される）を表すコンフィギュレーション・コントラクトが、おそらくERC-3668に類似した方法で、最も近いステートROOTSをフェッチする機能を宣言できる標準が必要です。この関数は、最も近いステートROOTSをフェッチし、そのステートROOTSに基づいて証明とレシートを行う。こうすることで、ウォレットがL1とL2上のあらゆる状態やイベントを安全に検証することを可能にする、一般的なライトクライアントを持つことができます。

プライバシーのための今日唯一の現実的なアプローチは、自分自身のフルノードを実行することです。しかし、L2が見えてきた今、すべてのフルノードを実行することはますます難しくなってきています。ここでライトクライアントに相当するのが、プライベート情報検索（PIR）である。 PIRでは、すべてのデータのコピーを保持するサーバーと、暗号化されたリクエストをサーバーに送信するクライアントが関与する。サーバーはすべてのデータに対して計算を実行し、クライアントが必要とするデータを返し、クライアントがどのデータにアクセスしたかをサーバーに明かすことなく、クライアントの鍵に暗号化する。

サーバーを正直に保つために、個々のデータベースエントリーはそれ自体がMerkleブランチであるため、クライアントはライトクライアントを使用してそれらを認証することができます。

PIRは非常に計算量が多い。

• Brute force:アルゴリズムや特殊なハードウェアの改良により、PIRを十分に高速に実行できるかもしれません。これらの技術は前処理に依存する可能性があります。サーバーは各クライアントの暗号化されスクランブルされたデータを保存することができ、クライアントはそのデータを照会することができます。イーサネット環境における主な課題は、急速に変化するデータセット（国のような）にこれらの技術を適応させることである。これにより、リアルタイムの計算は安くなるが、計算とストレージの総コストは高くなる可能性が高い。

• プライバシー要件の弱体化：たとえば、ルックアップごとに100万の「ミックスイン」しか存在できないため、サーバーはクライアントがアクセスできる100万の可能性のある値を知ることになりますが、これ以上細かい粒度ではアクセスできません。

• 複数サーバーPIR: PIRアルゴリズムは、複数のサーバーを使用し、それらのサーバー間で1-of-Nの正直さを仮定すると、通常より速くなります。

• 秘密性よりも匿名性: リクエストはmixnet上で送ることができ、リクエストの内容よりも、 リクエストの送信者を隠すことができます。しかしながら、効果的にそうすることは必然的に待ち時間を増やし、結果としてユーザーエクスペリエンスを悪化させます。

イーサリアム環境で実用性を維持しながらプライバシーを最大化する技術の適切な組み合わせを見つけ出すことは、未解決の研究課題であり、暗号技術者がそれを試みることを歓迎します。

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

トランスポートとステートアクセスに加えて、L2コンテキストでスムーズに動作する必要があるもう1つの重要なワークフローは、アカウントの認証設定を変更することです。ロジックをより深いレベルで変更することである。

• 更新の再生: ユーザーが設定を変更すると、ユーザーがキーを所有していることを検出したときに、変更を承認するメッセージがウォレットに送信されます。メッセージは、ウォレットがユーザがアセットを所有していることを検知するすべてのチェーンで再生されます。メッセージのフォーマットと検証ルールはチェーンに依存しないので、可能な限り多くのチェーンで自動的に再生される可能性があります。

• L1上のキーストア：設定メッセージはL1にあり、L2上のウォレットはL1SLOADまたはREMOTESTATICCALLを使用してそれを読み取ります。この方法では、L1上で設定を更新するだけでよく、設定は自動的に有効になります。

• L2上のキーストア： L2上に設定情報が存在し、L2上のウォレットがZK-SNARKを使ってそれを読み取ります。これは(2)と同じですが、キーストアの更新は安くなるかもしれませんが、一方で読み込みは高くなります。

解決策(3)が特に強力なのは、プライバシーとうまく連動するからです。通常の「プライバシーソリューション」では、ユーザは秘密sと、チェーン上に投稿された「リーフ値」Lを持ち、ユーザは自分が管理する（決して公開されない）秘密について、L = hash(s, 1)とN = hash(s, 2)であることを証明する。無効化子Nは、Lを明らかにすることなく、同じリーフに対する将来の支出が失敗することを保証するために投稿される。これは、ユーザがsを確保することに依存する。回復に適したプライバシーの解決策は次のようになる：sはチェーン内の場所（例えばアドレスやストレージスロット）であり、ユーザーは状態クエリを証明しなければならない：L = hash(sload(s), 1)。

アプリのセキュリティ

ユーザーセキュリティの最も弱いリンクは、通常、アプリです。サーバーがハッキングされたり、DNS がハッキングされたりすると、ユーザーはインターフェースの偽のコピーを入手することになり、ユーザーを騙して任意のアクションを実行させる可能性があります。取引シミュレーションのようなウォレット機能は、リスクを軽減するのに非常に役立ちますが、完璧にはほど遠いものです。

理想的には、私たちはエコシステムをオンチェーンコンテンツのバージョン管理に移行させます。インターフェイスを更新するには、マルチシグネチャやDAOからのオンチェーン取引が必要になる。ウォレットはユーザーがより安全なオンチェーンインターフェースと、より安全でないWeb2インターフェースのどちらとやりとりしているかを表示する。ウォレットはまた、ユーザーが安全なチェーン（ステージ1+、複数のセキュリティ監査など）とやりとりしているかどうかを表示することもできます。

プライバシーを重視するユーザーのために、ウォレットはユーザーがWeb3アクションだけでなくHTTPリクエストを受け入れるためにクリックすることを要求するパラノイアモードを追加することもできます:

可能なパラノイアモード

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

より高度なアプローチは、HTML + Javascriptを越えて、特別な言語(おそらくSolidityまたはVyper上の比較的薄いオーバーレイ)でダップのビジネスロジックを記述することです。OKContractはすでにこれを実行しています。

もう1つの方向性は、暗号経済的な情報防衛です。ダップ開発者、セキュリティ企業、チェーンデプロイ業者などは、ダップがハッキングされたり、非常に誤解を招くような方法で損害を受けたりした場合に、影響を受けたユーザーに支払われる保証金を設定することができます。DAOs.ウォレットは、いくつかのオンチェーン裁定によって、ボンドサイズに基づいたスコアをユーザーに表示することができる。

The longer term future

上記はすべて伝統的なインターフェースの文脈での話であり、物事をポイントしてクリックしたり、テキストフィールドに物事を入力したりすることが含まれます。

• 人工知能は、クリックから入力へというパラダイムから、「やりたいことを言えば、そのことを教えてくれる。

• 脳とコンピュータのインターフェースは、視線追跡のような「より優しい」アプローチから、より直接的で侵襲的な技術（今年最初のNeuralink患者を参照）まで多岐にわたります。

人工知能は、私たちをクリック入力のパラダイムから「やりたいことを言えばロボットが解決してくれる」パラダイムへと導く可能性があります。p>

• クライアント側のアクティブな防御：Brave Browserは、広告、トラッカー、その他多くの望ましくないオブジェクトからユーザーを積極的に保護します。多くのブラウザ、プラグイン、クリプトウォレットは、さまざまなセキュリティやプライバシーの脅威からユーザーを守るために、チーム全体が積極的に取り組んでいます。このような「アクティブな保護者」は、今後10年でさらに強くなっていくでしょう。

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

このようなより急進的なアイデアは、今日の極めて未熟な技術に依存しているため、私は今日の技術に依存した財布に資産を預けることはないだろう。しかし、似たようなものが未来にあるのは明らかなようなので、その方向でより積極的に探求を始める価値はあるでしょう。