著者: Vitalik、イーサリアム創設者、翻訳: Jinse Finance cryptonaitive
イーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバル、パーミッションレスなエクスペリエンスを提供できる成熟したテクノロジースタックに進化するにつれて、次の 3 つの主要な技術的移行が同時に起こる必要があります。
*イーサリアムエコシステム変革トライアングル。 3 つすべてを選択することしかできません。 *
最初の項目がなければ、イーサリアムは失敗します。なぜなら、各取引には 3.75 ドル (別の強気相場を経験した場合は 82.48 ドル) かかるためです。また、あらゆるマスマーケット製品は必然的にオンチェーン取引を廃止し、集中型ソリューションを採用することになります。
2番目の項目がなければ、ユーザーは資金（および非金融資産）を保管することに消極的となり、誰もが集中型取引所に頼るようになるため、イーサリアムは失敗するでしょう。
3 番目の項目がなければ、多くのユーザーにとってすべてのトランザクション (および POAP など) が公開され、プライバシーの犠牲が大きすぎ、誰もが少なくともあるレベルの隠蔽データに目を向けることになるため、イーサリアムは失敗します。
上で概説した理由により、これら 3 つの移行は重要です。しかし、調整が複雑であるため、それらは困難でもあります。改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとの対話方法を根本的かつ大幅に変更する必要があり、アプリケーションやウォレットの大幅な変更が必要になります。
L2 スケーリングの世界では、ユーザーは複数の L2 ネットワーク上に存在することになります。あなたは ExampleDAO のメンバーですか? ExampleDAO は Optimism にあります。これで、Optimism のアカウントを取得できました。 ZkSync でステーブルコイン システムの CDP を保有していますか?これで、ZkSync のアカウントを取得できました。カカロットにあるアプリをいくつか試したことがありますか?これでカカロットのアカウントができました！ユーザーが 1 つのアドレスしか持てなかった時代は終わりました。
※私のBraveウォレットビュー、イーサリアムを4か所に保有しています。はい、Arbitrum と Arbitrum Nova は異なります。心配しないでください。時間の経過とともに状況はさらに複雑になっていきます。 *
**スマート コントラクト ウォレットは、L1 およびさまざまな L2 ネットワーク上で同じアドレスを持つことがより困難になるため、より複雑になります。 **今日のほとんどのユーザーは外部所有のアカウントを使用しており、そのアドレスは実際には署名の検証に使用される公開キーのハッシュであるため、L1 と L2 の間では何も変わりません。ただし、スマート コントラクト ウォレットを使用すると、アドレスを維持することがさらに難しくなります。アドレスを異なるネットワーク間で同等のコードのハッシュにするために多くの作業が行われてきましたが、最も重要なのは CREATE2 と ERC-2470 シングルトン ファクトリですが、これを完全に達成することは困難です。一部の L2 ネットワーク (例: 「第 4 タイプの ZK-EVM」) は EVM と厳密には同等ではなく、多くの場合、同等のハッシュではなく Solidity または中間アセンブリ言語を使用します。たとえハッシュの同等性が達成できたとしても、キーの変更によってウォレットの所有権が変更される可能性があり、他の予測不可能な結果につながります。
**プライバシーを確保するには、ユーザーごとにさらに多くのアドレスが必要であり、処理するアドレスの種類が変更される場合もあります。 **ステルス アドレスの提案が広く使用されている場合、ユーザーは、ユーザーあたり数個のアドレスや L2 ネットワークあたり 1 つのアドレスだけではなく、トランザクションごとに 1 つのアドレスを持つ可能性があります。他のプライバシー スキームは、Tornado Cash のような既存のものであっても、資産の保存方法をさまざまな方法で変更します。つまり、多くのユーザーの資金が同じスマート コントラクト (したがって同じアドレス) に保存されます。特定のユーザーに資金を送金するには、ユーザーはプライバシー スキーム独自の内部アドレス システムに依存する必要があります。
これまで見てきたように、これら 3 つの変換は、さまざまな方法で「1 ユーザー ≈ 1 アドレス」メンタル モデル を弱めます。その結果、これらの変換の実行の複雑さが増すものもあります。特に複雑な問題は次の 2 つです。
**1. 誰かに支払いたい場合、支払い情報はどうやって入手しますか? **
**2. ユーザーが異なるチェーンの異なる場所に資産を保存している場合、重要な変更とソーシャル リカバリをどのように実行しますか? **
私は Scroll でトークンを保持しており、それを使ってコーヒーを購入したいと考えています (文字通りの「私」がこの記事の著者である Vitalik を指す場合、「コーヒー」はもちろん「緑茶」を意味します)。 Taiko ではコーヒーを販売していますが、Taiko ではトークンのみを受け入れます。何をすべきか？
基本的に、解決策は 2 つあります。
受け取り側のウォレット (販売者または一般の個人) は、各 L2 をサポートするよう努め、いくつかの非同期資金結合機能を備えています。
受取人はアドレスの隣に L2 情報を提供し、送信者のウォレットは、ある種のクロス L2 ブリッジ システムを通じて資金をターゲット L2 に自動的にルーティングします。
もちろん、これらのソリューションは組み合わせて使用できます。受取人は受け入れたい L2 リストを提供し、送信者のウォレットが支払い方法を決定します。支払い方法は、（運が良ければ）直接送信することも、クロス L2 ブリッジ経由で支払うこともできます。道。
しかし、これは 3 つの変換によってもたらされる重要な課題の一例にすぎません。単純な支払い動作では、20 バイトのアドレスだけではなく、より多くの情報が必要になり始めています。
幸いなことに、スマート コントラクト ウォレットへの移行はアドレス システムにとって大きな負担ではありませんが、アプリケーション スタックの他の部分で解決する必要がある技術的問題がまだいくつかあります。ウォレットは、トランザクション送信時に 21000 ガスを送信するだけでなく、ウォレットの受信側が EOA からの ETH 送金だけでなく、EOA からの ETH 送金も追跡するように更新する必要があります。スマートコントラクトコード。アドレスの不変の所有権に依存するアプリケーション (ロイヤルティを強制するスマートコントラクトを禁止する NFT など) は、目標を達成するために別の方法を見つける必要があります。スマート コントラクト ウォレットにより、いくつかの作業が簡単になります。特に、ETH 以外の ERC20 トークンのみを受け入れる場合、ERC-4337 ペイマスターを使用して、そのトークンを使用してガス料金を支払うことができるようになります。
一方で、プライバシーの問題もまた大きな課題であり、まだ実際には解決されていません。オリジナルの Tornado Cash では、内部送金がサポートされていなかったため、これらの問題は発生しませんでした。ユーザーはシステムへの入金と引き出しのみが可能でした。ただし、内部転送が可能になると、ユーザーはプライバシー システムの内部アドレス指定スキームを使用する必要があります。実際には、ユーザーの「支払いメッセージ」には、(i) 受信者が支払いに使用できる秘密のコミットメントであるある種の「支払い公開キー」、および (ii) 送信者は受信者のみが送信できる暗号化されたメッセージを送信できる必要があります。暗号化を解除できる ヘルプ受信者は支払い方法を発見します。
ステルス アドレス プロトコルはメタアドレスの概念に依存しており、メタアドレスの一部は送信者の騙された支出キーであり、他の部分は送信者の暗号化キーです (ただし、最小限の実装では両方のキーを設定できます)。同じであること）。
暗号化と ZK-SNARK に基づく抽象ステルス アドレス スキームの概要
ここでの重要な教訓は、**プライバシーに配慮したエコシステムでは、ユーザーは支出用の公開鍵と暗号化用の公開鍵を持つことになり、ユーザーの「支払い情報」には両方の鍵が含まれる必要があるということです。 **支払い以外にも、この方向性を拡大する正当な理由は他にもあります。たとえば、イーサリアムに基づいて暗号化された電子メールが必要な場合、ユーザーはある種の暗号化キーを公的に提供する必要があります。 「EOA の世界」ではアカウント キーを再利用できますが、安全なスマート コントラクト ウォレットの世界では、おそらくこれのためのより明示的な機能を提供する必要があります。これは、イーサリアムベースのアイデンティティと、非イーサリアム分散型プライバシー エコシステム、特に PGP キーとの互換性を高めるのにも役立ちます。
各ユーザーが複数のアドレスを持っている世界では、主要な変更とソーシャル リカバリを実装するデフォルトの方法は、ユーザーが各アドレスに対して個別にリカバリ プロセスを実行することです。これはワンクリックで実行できます。ウォレットは、ユーザーのすべてのアドレスに対して回復プロセスを同時に実行するソフトウェア機能を提供できます。ただし、このようにユーザー エクスペリエンスが簡素化されたとしても、複数アドレスの回復には次の 3 つの問題があります。
1. ガス代は非現実的です: これは自明のことです。
2. 虚偽のアドレス: スマート コントラクトをまだ発行していないアドレス (実際には、これはまだ資金を送金していないアカウントを意味します)。ユーザーは、無限の数の仮想アドレスを持つことができます。つまり、まだ存在しない L2 を含む各 L2 に 1 つ以上の仮想アドレスと、ステルス アドレス スキームから生じる仮想アドレスの無限のセット全体です。
3. プライバシー: ユーザーが複数のアドレスを相互に関連付けることを避けるために意図的に使用している場合、それらを同時にまたはほぼ同時に復元して、すべてのアドレスを公に関連付けることは望ましくありません。
これらの問題を解決するのは困難です。幸いなことに、非常にうまく機能するエレガントなソリューションがあります。このアーキテクチャは、検証ロジックを資産保持から分離します。
すべてのユーザーは、1 つの場所 (メインネットまたは特定の L2 の可能性があります) に存在する キーストア コントラクト を持っています。その場合、ユーザーは異なる L2 上にアドレスを持ち、各アドレスの検証ロジックはキーストア コントラクトへのポインターになります。これらのアドレスから資金を支出するには、資金の現在 (またはより現実的にはごく最近) の支出公開鍵の証明を提供する必要があります。
この証明はいくつかの方法で達成できます。
すべてのトランザクションに証明が必要になることを避けたい場合は、L2 証明全体での回復のみを必要とする、より軽量なスキームを実装できます。アカウントからの支出は、アカウント内に保存されている対応する公開キーを持つ支出キーに依存しますが、回復には現在の支出公開キーをキーストアにコピーするトランザクションが必要になります。古いキーが安全でない場合でも、仮想アドレス内の資金は安全です。仮想アドレスを「アクティブ化」して使用可能な契約に変えるには、現在の使用済み公開キーを複製するためのクロス L2 証明が必要です。 Safe フォーラムには、同様のアーキテクチャがどのように動作するかを説明するスレッドがあります。
このようなスキームにプライバシーを追加するには、ポインタを暗号化し、ZK-SNARK 内ですべての証明を行うだけです:
さらに作業を進めると (この作業を開始点として)、ストリップすることもできます。 ZK - SNARK の複雑さのほとんどは、より単純化された KZG ベースのスキームを構築することです。
これらのシナリオは複雑になる可能性があります。利点は、それらの間に多くの潜在的な相乗効果があることです。たとえば、「キーストア コントラクト」の概念は、前のセクションで説明した「アドレス」に対する解決策にもなり得ます。ユーザーがキーを更新するたびに変更されない永続的なアドレスを持たせたい場合は、次のようにすることができます。ステルス メタ アドレス、暗号化キー、その他の情報がキーストア コントラクトに組み込まれ、キーストア コントラクトのアドレスがユーザーの「アドレス」として使用されます。
ENS の使用には費用がかかります。 2023 年 6 月の時点では以前ほど高価ではありませんが、ドメイン名を登録するための取引手数料は依然として比較的高く、ENS ドメイン名のコストに匹敵します。たとえば、zuzalu.eth への登録には約 27 ドルかかり、そのうち 11 ドルは取引手数料です。しかし、市場が再び強気に転じれば、手数料は高騰するだろう。 ETH価格が上昇しなくても、ガス料金が200グウェイに戻れば、ドメイン名登録の取引手数料は104ドルに達します。したがって、人々に実際に ENS を使ってもらいたい場合、特にユーザーがほぼ無料の登録を求める分散型ソーシャル メディアのようなユースケースでは (これらのプラットフォームはユーザーにサブドメインを提供できるため、ENS ドメイン料金は問題になりません)、ENS を次の場所で使用する必要があります。レイヤー2。
幸いなことに、ENS チームはすでに強化されており、ENS はレイヤー 2 に実装されています。 ERC-3668 (「CCIP 標準」としても知られています) および ENSIP-10 は、レイヤー 2 上の ENS サブドメインを自動的に検証する方法を提供します。 CCIP 標準では、レイヤー 2 上のデータの証明を検証する方法を記述するスマート コントラクトを設定する必要があり、ドメイン名 (Optinames の ecc.eth など) をそのようなコントラクトの制御下に置くことができます。 CCIP 契約が L1 上の ecc.eth を制御すると、特定の subdomain.ecc.eth にアクセスすると、その特定のサブドメイン (マークル ブランチなど) のレイヤー 2 状態を保存するプルーフが自動的に検索され、検証されます。
これらの証拠を実際に取得するには、コントラクトに保存されている URL のリストにアクセスする必要があります。どういうわけか、集中管理のように見えるかもしれませんが、実際はそうではないと思います。これは 1 対 N の信頼モデルです (無効な証明は、A URL の 1 つである限り、CCIP コントラクト コールバック関数の検証ロジックによって捕捉されます)有効な証拠を返すものであれば問題ありません)。 URL リストには数十の URL が含まれる場合があります。
**ENS の CCIP の取り組みは成功例であり、私たちが必要とする根本的な改革が実際に可能であることの表れと見なされるべきです。 ** しかし、アプリケーションレベルで行う必要のある改革はまだたくさんあります。ここではいくつかの例を示します。
現在、ウォレットの使命は資産を保護することです。すべてがオンチェーンに保存され、ウォレットが保護する必要があるのは、現在これらの資産を保護している秘密鍵だけです。キーを変更した場合、翌日には以前の秘密キーをインターネット上に安全に公開できます。しかし、ゼロ知識の世界では、これは当てはまりません。ウォレットは認証資格情報を保護するだけでなく、データも保持します。
そのような世界の最初の兆候は、ZK-SNARK ベースの ID システムである Zupass を備えた Zuzalu で見られます。ユーザーはシステムへの認証に使用される秘密キーを持っており、これを使用して「私がどの居住者であるかを明らかにせずに、私がズザルの居住者であることを証明する」などの基本的な証明を生成できます。 Zupass システムは、その上に他のアプリケーション、最も重要なのはスタンプ (Zupass バージョンの POAP) の構築も開始しました。
*私がチームキャットのメンバーであることを証明するたくさんのズーパススタンプのうちの1つ。 *
POAP に関連したスタンプの主な特徴は、スタンプがプライベートであることです。データはローカルに保存され、その情報を誰かに提供したい場合にのみスタンプを ZK に証明する (またはスタンプに対して何らかの計算を実行する) ことができます。ただし、これには追加のリスクも伴います。その情報を紛失すると、スタンプも失われることになります。
もちろん、データ保持の問題は、単一の暗号化キーの保持の問題に還元できます。つまり、サードパーティ (オンチェーンであっても) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを保持するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてのデータが失われます。 そして、 誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。 **
Zupass の実際的な解決策は、同時にすべてのデバイスにアクセスできなくなる可能性が低いため、複数のデバイス (ラップトップや電話など) にキーを保存することを人々に奨励することです。キー共有を使用して複数のプロテクター間でキー ストレージを分割することで、さらに一歩進めることができます。
MPC を介したソーシャル リカバリは、現在の保護者だけでなく、以前の保護者も共謀して資産を盗む可能性があり、容認できないほど高いリスクを意味するため、ウォレットにとって適切な解決策ではありません。通常、プライバシー侵害は資産の完全な損失よりもリスクが低いですが、プライバシーのニーズが高いユースケースでは、プライバシーのニーズに関連するキーをバックアップしないことで損失のより高いリスクを受け入れることができます。
複数の回復パスからなる複雑なシステムでユーザーが行き詰まることを避けるために、ソーシャル回復をサポートするウォレットは、資産回復と暗号鍵回復の両方の側面を管理する必要がある場合があります。
これらの変化に共通するテーマは、ブロックチェーン上のアイデンティティの表現としての「アドレス」の概念を根本的に変える必要があるということです。 ** 「私と対話する方法に関する指示」は単なる ETH アドレスではなくなります。 **
これらの方法の 1 つは、ENS をアイデンティティとして使用することです。ENS レコードには、支払い方法とあなたとのやり取りに関するすべての情報が含まれており、誰かに bob.eth (または bob.ecc.eth など) を送信すると、相手は問い合わせることができます。さらに、ドメイン間やプライバシー保護など、より複雑な方法でやり取りするすべてのことについて学びます。
ただし、この ENS 中心のアプローチには 2 つの弱点があります。
考えられる解決策の 1 つは、この記事のアーキテクチャで前述したキーストア コントラクトにさらに多くのコンテンツを組み込むことです。キーストア コントラクトには、ユーザーとユーザーとのやり取りに関するさまざまな情報を含めることができます (CCIP では、この情報の一部をオフチェーンにできます)。ユーザーはキーストア コントラクトを主要な識別子として使用します。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に依存せず、仮想名にも適しています。特定の固定初期パラメータを使用したキーストア コントラクトによってのみ初期化できるアドレスを生成できます。
別のクラスのソリューションには、ビットコインの支払いプロトコルと同様に、ユーザー向けアドレスの概念を完全に放棄することが含まれます。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者はリクエスト リンクを (明示的な URL または QR コードとして) 送信し、受信者はそれを使用して、受け入れたいリクエストを送信できます。支払い。
最初に行動するのが送信者であっても受信者であっても、ウォレットにさらに依存して最新の支払い情報をリアルタイムで生成することで、摩擦が軽減されます。ただし、永続的な識別子は便利ですが (特に ENS の場合)、実際には送信者と受信者の間の直接通信に依存するのは非常に難しい問題であるため、さまざまな手法を組み合わせることが考えられます。
これらの設計のすべてにおいて、分散化を維持し、ユーザーにとって理解しやすいことが重要です。ユーザーが現在のアセットとそのユーザーを対象としたメッセージの最新ビューに簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。より複雑化した決済インフラが、理解しにくく新しい環境に適応するのが難しい不透明な「抽象の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。
55.3K 人気度
101.3K 人気度
12.6K 人気度
165K 人気度
442 人気度
Vitalik: イーサリアムのエコシステムには 3 つの技術変革が必要です
著者: Vitalik、イーサリアム創設者、翻訳: Jinse Finance cryptonaitive
イーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバル、パーミッションレスなエクスペリエンスを提供できる成熟したテクノロジースタックに進化するにつれて、次の 3 つの主要な技術的移行が同時に起こる必要があります。
*イーサリアムエコシステム変革トライアングル。 3 つすべてを選択することしかできません。 *
最初の項目がなければ、イーサリアムは失敗します。なぜなら、各取引には 3.75 ドル (別の強気相場を経験した場合は 82.48 ドル) かかるためです。また、あらゆるマスマーケット製品は必然的にオンチェーン取引を廃止し、集中型ソリューションを採用することになります。
2番目の項目がなければ、ユーザーは資金（および非金融資産）を保管することに消極的となり、誰もが集中型取引所に頼るようになるため、イーサリアムは失敗するでしょう。
3 番目の項目がなければ、多くのユーザーにとってすべてのトランザクション (および POAP など) が公開され、プライバシーの犠牲が大きすぎ、誰もが少なくともあるレベルの隠蔽データに目を向けることになるため、イーサリアムは失敗します。
上で概説した理由により、これら 3 つの移行は重要です。しかし、調整が複雑であるため、それらは困難でもあります。改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとの対話方法を根本的かつ大幅に変更する必要があり、アプリケーションやウォレットの大幅な変更が必要になります。
これら 3 つの変換は、ユーザーとアドレスの関係を根本的に再構築します。
L2 スケーリングの世界では、ユーザーは複数の L2 ネットワーク上に存在することになります。あなたは ExampleDAO のメンバーですか? ExampleDAO は Optimism にあります。これで、Optimism のアカウントを取得できました。 ZkSync でステーブルコイン システムの CDP を保有していますか?これで、ZkSync のアカウントを取得できました。カカロットにあるアプリをいくつか試したことがありますか?これでカカロットのアカウントができました！ユーザーが 1 つのアドレスしか持てなかった時代は終わりました。
**スマート コントラクト ウォレットは、L1 およびさまざまな L2 ネットワーク上で同じアドレスを持つことがより困難になるため、より複雑になります。 **今日のほとんどのユーザーは外部所有のアカウントを使用しており、そのアドレスは実際には署名の検証に使用される公開キーのハッシュであるため、L1 と L2 の間では何も変わりません。ただし、スマート コントラクト ウォレットを使用すると、アドレスを維持することがさらに難しくなります。アドレスを異なるネットワーク間で同等のコードのハッシュにするために多くの作業が行われてきましたが、最も重要なのは CREATE2 と ERC-2470 シングルトン ファクトリですが、これを完全に達成することは困難です。一部の L2 ネットワーク (例: 「第 4 タイプの ZK-EVM」) は EVM と厳密には同等ではなく、多くの場合、同等のハッシュではなく Solidity または中間アセンブリ言語を使用します。たとえハッシュの同等性が達成できたとしても、キーの変更によってウォレットの所有権が変更される可能性があり、他の予測不可能な結果につながります。
**プライバシーを確保するには、ユーザーごとにさらに多くのアドレスが必要であり、処理するアドレスの種類が変更される場合もあります。 **ステルス アドレスの提案が広く使用されている場合、ユーザーは、ユーザーあたり数個のアドレスや L2 ネットワークあたり 1 つのアドレスだけではなく、トランザクションごとに 1 つのアドレスを持つ可能性があります。他のプライバシー スキームは、Tornado Cash のような既存のものであっても、資産の保存方法をさまざまな方法で変更します。つまり、多くのユーザーの資金が同じスマート コントラクト (したがって同じアドレス) に保存されます。特定のユーザーに資金を送金するには、ユーザーはプライバシー スキーム独自の内部アドレス システムに依存する必要があります。
これまで見てきたように、これら 3 つの変換は、さまざまな方法で「1 ユーザー ≈ 1 アドレス」メンタル モデル を弱めます。その結果、これらの変換の実行の複雑さが増すものもあります。特に複雑な問題は次の 2 つです。
**1. 誰かに支払いたい場合、支払い情報はどうやって入手しますか? **
**2. ユーザーが異なるチェーンの異なる場所に資産を保存している場合、重要な変更とソーシャル リカバリをどのように実行しますか? **
これら 3 つの移行とオンチェーン支払い (および ID)
私は Scroll でトークンを保持しており、それを使ってコーヒーを購入したいと考えています (文字通りの「私」がこの記事の著者である Vitalik を指す場合、「コーヒー」はもちろん「緑茶」を意味します)。 Taiko ではコーヒーを販売していますが、Taiko ではトークンのみを受け入れます。何をすべきか？
基本的に、解決策は 2 つあります。
受け取り側のウォレット (販売者または一般の個人) は、各 L2 をサポートするよう努め、いくつかの非同期資金結合機能を備えています。
受取人はアドレスの隣に L2 情報を提供し、送信者のウォレットは、ある種のクロス L2 ブリッジ システムを通じて資金をターゲット L2 に自動的にルーティングします。
もちろん、これらのソリューションは組み合わせて使用できます。受取人は受け入れたい L2 リストを提供し、送信者のウォレットが支払い方法を決定します。支払い方法は、（運が良ければ）直接送信することも、クロス L2 ブリッジ経由で支払うこともできます。道。
しかし、これは 3 つの変換によってもたらされる重要な課題の一例にすぎません。単純な支払い動作では、20 バイトのアドレスだけではなく、より多くの情報が必要になり始めています。
幸いなことに、スマート コントラクト ウォレットへの移行はアドレス システムにとって大きな負担ではありませんが、アプリケーション スタックの他の部分で解決する必要がある技術的問題がまだいくつかあります。ウォレットは、トランザクション送信時に 21000 ガスを送信するだけでなく、ウォレットの受信側が EOA からの ETH 送金だけでなく、EOA からの ETH 送金も追跡するように更新する必要があります。スマートコントラクトコード。アドレスの不変の所有権に依存するアプリケーション (ロイヤルティを強制するスマートコントラクトを禁止する NFT など) は、目標を達成するために別の方法を見つける必要があります。スマート コントラクト ウォレットにより、いくつかの作業が簡単になります。特に、ETH 以外の ERC20 トークンのみを受け入れる場合、ERC-4337 ペイマスターを使用して、そのトークンを使用してガス料金を支払うことができるようになります。
一方で、プライバシーの問題もまた大きな課題であり、まだ実際には解決されていません。オリジナルの Tornado Cash では、内部送金がサポートされていなかったため、これらの問題は発生しませんでした。ユーザーはシステムへの入金と引き出しのみが可能でした。ただし、内部転送が可能になると、ユーザーはプライバシー システムの内部アドレス指定スキームを使用する必要があります。実際には、ユーザーの「支払いメッセージ」には、(i) 受信者が支払いに使用できる秘密のコミットメントであるある種の「支払い公開キー」、および (ii) 送信者は受信者のみが送信できる暗号化されたメッセージを送信できる必要があります。暗号化を解除できる ヘルプ受信者は支払い方法を発見します。
ステルス アドレス プロトコルはメタアドレスの概念に依存しており、メタアドレスの一部は送信者の騙された支出キーであり、他の部分は送信者の暗号化キーです (ただし、最小限の実装では両方のキーを設定できます)。同じであること）。
暗号化と ZK-SNARK に基づく抽象ステルス アドレス スキームの概要
ここでの重要な教訓は、**プライバシーに配慮したエコシステムでは、ユーザーは支出用の公開鍵と暗号化用の公開鍵を持つことになり、ユーザーの「支払い情報」には両方の鍵が含まれる必要があるということです。 **支払い以外にも、この方向性を拡大する正当な理由は他にもあります。たとえば、イーサリアムに基づいて暗号化された電子メールが必要な場合、ユーザーはある種の暗号化キーを公的に提供する必要があります。 「EOA の世界」ではアカウント キーを再利用できますが、安全なスマート コントラクト ウォレットの世界では、おそらくこれのためのより明示的な機能を提供する必要があります。これは、イーサリアムベースのアイデンティティと、非イーサリアム分散型プライバシー エコシステム、特に PGP キーとの互換性を高めるのにも役立ちます。
これら 3 つの遷移とキーの回復
各ユーザーが複数のアドレスを持っている世界では、主要な変更とソーシャル リカバリを実装するデフォルトの方法は、ユーザーが各アドレスに対して個別にリカバリ プロセスを実行することです。これはワンクリックで実行できます。ウォレットは、ユーザーのすべてのアドレスに対して回復プロセスを同時に実行するソフトウェア機能を提供できます。ただし、このようにユーザー エクスペリエンスが簡素化されたとしても、複数アドレスの回復には次の 3 つの問題があります。
1. ガス代は非現実的です: これは自明のことです。
2. 虚偽のアドレス: スマート コントラクトをまだ発行していないアドレス (実際には、これはまだ資金を送金していないアカウントを意味します)。ユーザーは、無限の数の仮想アドレスを持つことができます。つまり、まだ存在しない L2 を含む各 L2 に 1 つ以上の仮想アドレスと、ステルス アドレス スキームから生じる仮想アドレスの無限のセット全体です。
3. プライバシー: ユーザーが複数のアドレスを相互に関連付けることを避けるために意図的に使用している場合、それらを同時にまたはほぼ同時に復元して、すべてのアドレスを公に関連付けることは望ましくありません。
これらの問題を解決するのは困難です。幸いなことに、非常にうまく機能するエレガントなソリューションがあります。このアーキテクチャは、検証ロジックを資産保持から分離します。
すべてのユーザーは、1 つの場所 (メインネットまたは特定の L2 の可能性があります) に存在する キーストア コントラクト を持っています。その場合、ユーザーは異なる L2 上にアドレスを持ち、各アドレスの検証ロジックはキーストア コントラクトへのポインターになります。これらのアドレスから資金を支出するには、資金の現在 (またはより現実的にはごく最近) の支出公開鍵の証明を提供する必要があります。
この証明はいくつかの方法で達成できます。
すべてのトランザクションに証明が必要になることを避けたい場合は、L2 証明全体での回復のみを必要とする、より軽量なスキームを実装できます。アカウントからの支出は、アカウント内に保存されている対応する公開キーを持つ支出キーに依存しますが、回復には現在の支出公開キーをキーストアにコピーするトランザクションが必要になります。古いキーが安全でない場合でも、仮想アドレス内の資金は安全です。仮想アドレスを「アクティブ化」して使用可能な契約に変えるには、現在の使用済み公開キーを複製するためのクロス L2 証明が必要です。 Safe フォーラムには、同様のアーキテクチャがどのように動作するかを説明するスレッドがあります。
このようなスキームにプライバシーを追加するには、ポインタを暗号化し、ZK-SNARK 内ですべての証明を行うだけです:
これらのシナリオは複雑になる可能性があります。利点は、それらの間に多くの潜在的な相乗効果があることです。たとえば、「キーストア コントラクト」の概念は、前のセクションで説明した「アドレス」に対する解決策にもなり得ます。ユーザーがキーを更新するたびに変更されない永続的なアドレスを持たせたい場合は、次のようにすることができます。ステルス メタ アドレス、暗号化キー、その他の情報がキーストア コントラクトに組み込まれ、キーストア コントラクトのアドレスがユーザーの「アドレス」として使用されます。
多くの二次インフラストラクチャを更新する必要がある
ENS の使用には費用がかかります。 2023 年 6 月の時点では以前ほど高価ではありませんが、ドメイン名を登録するための取引手数料は依然として比較的高く、ENS ドメイン名のコストに匹敵します。たとえば、zuzalu.eth への登録には約 27 ドルかかり、そのうち 11 ドルは取引手数料です。しかし、市場が再び強気に転じれば、手数料は高騰するだろう。 ETH価格が上昇しなくても、ガス料金が200グウェイに戻れば、ドメイン名登録の取引手数料は104ドルに達します。したがって、人々に実際に ENS を使ってもらいたい場合、特にユーザーがほぼ無料の登録を求める分散型ソーシャル メディアのようなユースケースでは (これらのプラットフォームはユーザーにサブドメインを提供できるため、ENS ドメイン料金は問題になりません)、ENS を次の場所で使用する必要があります。レイヤー2。
幸いなことに、ENS チームはすでに強化されており、ENS はレイヤー 2 に実装されています。 ERC-3668 (「CCIP 標準」としても知られています) および ENSIP-10 は、レイヤー 2 上の ENS サブドメインを自動的に検証する方法を提供します。 CCIP 標準では、レイヤー 2 上のデータの証明を検証する方法を記述するスマート コントラクトを設定する必要があり、ドメイン名 (Optinames の ecc.eth など) をそのようなコントラクトの制御下に置くことができます。 CCIP 契約が L1 上の ecc.eth を制御すると、特定の subdomain.ecc.eth にアクセスすると、その特定のサブドメイン (マークル ブランチなど) のレイヤー 2 状態を保存するプルーフが自動的に検索され、検証されます。
**ENS の CCIP の取り組みは成功例であり、私たちが必要とする根本的な改革が実際に可能であることの表れと見なされるべきです。 ** しかし、アプリケーションレベルで行う必要のある改革はまだたくさんあります。ここではいくつかの例を示します。
ウォレットは資産とデータを保護する必要がある
現在、ウォレットの使命は資産を保護することです。すべてがオンチェーンに保存され、ウォレットが保護する必要があるのは、現在これらの資産を保護している秘密鍵だけです。キーを変更した場合、翌日には以前の秘密キーをインターネット上に安全に公開できます。しかし、ゼロ知識の世界では、これは当てはまりません。ウォレットは認証資格情報を保護するだけでなく、データも保持します。
そのような世界の最初の兆候は、ZK-SNARK ベースの ID システムである Zupass を備えた Zuzalu で見られます。ユーザーはシステムへの認証に使用される秘密キーを持っており、これを使用して「私がどの居住者であるかを明らかにせずに、私がズザルの居住者であることを証明する」などの基本的な証明を生成できます。 Zupass システムは、その上に他のアプリケーション、最も重要なのはスタンプ (Zupass バージョンの POAP) の構築も開始しました。
*私がチームキャットのメンバーであることを証明するたくさんのズーパススタンプのうちの1つ。 *
POAP に関連したスタンプの主な特徴は、スタンプがプライベートであることです。データはローカルに保存され、その情報を誰かに提供したい場合にのみスタンプを ZK に証明する (またはスタンプに対して何らかの計算を実行する) ことができます。ただし、これには追加のリスクも伴います。その情報を紛失すると、スタンプも失われることになります。
もちろん、データ保持の問題は、単一の暗号化キーの保持の問題に還元できます。つまり、サードパーティ (オンチェーンであっても) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを保持するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてのデータが失われます。 そして、 誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。 **
Zupass の実際的な解決策は、同時にすべてのデバイスにアクセスできなくなる可能性が低いため、複数のデバイス (ラップトップや電話など) にキーを保存することを人々に奨励することです。キー共有を使用して複数のプロテクター間でキー ストレージを分割することで、さらに一歩進めることができます。
MPC を介したソーシャル リカバリは、現在の保護者だけでなく、以前の保護者も共謀して資産を盗む可能性があり、容認できないほど高いリスクを意味するため、ウォレットにとって適切な解決策ではありません。通常、プライバシー侵害は資産の完全な損失よりもリスクが低いですが、プライバシーのニーズが高いユースケースでは、プライバシーのニーズに関連するキーをバックアップしないことで損失のより高いリスクを受け入れることができます。
複数の回復パスからなる複雑なシステムでユーザーが行き詰まることを避けるために、ソーシャル回復をサポートするウォレットは、資産回復と暗号鍵回復の両方の側面を管理する必要がある場合があります。
アイデンティティに戻る
これらの変化に共通するテーマは、ブロックチェーン上のアイデンティティの表現としての「アドレス」の概念を根本的に変える必要があるということです。 ** 「私と対話する方法に関する指示」は単なる ETH アドレスではなくなります。 **
これらの方法の 1 つは、ENS をアイデンティティとして使用することです。ENS レコードには、支払い方法とあなたとのやり取りに関するすべての情報が含まれており、誰かに bob.eth (または bob.ecc.eth など) を送信すると、相手は問い合わせることができます。さらに、ドメイン間やプライバシー保護など、より複雑な方法でやり取りするすべてのことについて学びます。
ただし、この ENS 中心のアプローチには 2 つの弱点があります。
考えられる解決策の 1 つは、この記事のアーキテクチャで前述したキーストア コントラクトにさらに多くのコンテンツを組み込むことです。キーストア コントラクトには、ユーザーとユーザーとのやり取りに関するさまざまな情報を含めることができます (CCIP では、この情報の一部をオフチェーンにできます)。ユーザーはキーストア コントラクトを主要な識別子として使用します。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に依存せず、仮想名にも適しています。特定の固定初期パラメータを使用したキーストア コントラクトによってのみ初期化できるアドレスを生成できます。
別のクラスのソリューションには、ビットコインの支払いプロトコルと同様に、ユーザー向けアドレスの概念を完全に放棄することが含まれます。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者はリクエスト リンクを (明示的な URL または QR コードとして) 送信し、受信者はそれを使用して、受け入れたいリクエストを送信できます。支払い。
最初に行動するのが送信者であっても受信者であっても、ウォレットにさらに依存して最新の支払い情報をリアルタイムで生成することで、摩擦が軽減されます。ただし、永続的な識別子は便利ですが (特に ENS の場合)、実際には送信者と受信者の間の直接通信に依存するのは非常に難しい問題であるため、さまざまな手法を組み合わせることが考えられます。
これらの設計のすべてにおいて、分散化を維持し、ユーザーにとって理解しやすいことが重要です。ユーザーが現在のアセットとそのユーザーを対象としたメッセージの最新ビューに簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。より複雑化した決済インフラが、理解しにくく新しい環境に適応するのが難しい不透明な「抽象の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。