著者: Vitalik、イーサリアム創設者、翻訳: Jinse Finance cryptonaitiveイーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバル、パーミッションレスなエクスペリエンスを提供できる成熟したテクノロジースタックに進化するにつれて、次の 3 つの主要な技術的移行が同時に起こる必要があります。* **1 つ目は、L2 容量拡張の変革** - 誰もがロールアップ テクノロジーに注目します。* **2 番目はウォレットのセキュリティの変革** - 誰もがスマート コントラクト ウォレットを使い始めます。* **3 番目はプライバシーの変革です** - プライバシーを保護する資金移動機能が利用可能であることを保証し、開発中の他のすべてのツール (ソーシャル リカバリ、本人確認、評判など) がプライバシーを保護する機能を備えていることを保証します。*イーサリアムエコシステム変革トライアングル。 3 つすべてを選択することしかできません。 *最初の項目がなければ、イーサリアムは失敗します。なぜなら、各取引には 3.75 ドル (別の強気相場を経験した場合は 82.48 ドル) かかるためです。また、あらゆるマスマーケット製品は必然的にオンチェーン取引を廃止し、集中型ソリューションを採用することになります。2番目の項目がなければ、ユーザーは資金（および非金融資産）を保管することに消極的となり、誰もが集中型取引所に頼るようになるため、イーサリアムは失敗するでしょう。3 番目の項目がなければ、多くのユーザーにとってすべてのトランザクション (および POAP など) が公開され、プライバシーの犠牲が大きすぎ、誰もが少なくともあるレベルの隠蔽データに目を向けることになるため、イーサリアムは失敗します。上で概説した理由により、これら 3 つの移行は重要です。しかし、調整が複雑であるため、それらは困難でもあります。改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとの対話方法を根本的かつ大幅に変更する必要があり、アプリケーションやウォレットの大幅な変更が必要になります。## これら 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. ユーザーが異なるチェーンの異なる場所に資産を保存している場合、重要な変更とソーシャル リカバリをどのように実行しますか? **## これら 3 つの移行とオンチェーン支払い (および ID)私は Scroll でトークンを保持しており、それを使ってコーヒーを購入したいと考えています (文字通りの「私」がこの記事の著者である Vitalik を指す場合、「コーヒー」はもちろん「緑茶」を意味します)。 Taiko ではコーヒーを販売していますが、Taiko ではトークンのみを受け入れます。何をすべきか？基本的に、解決策は 2 つあります。1. 受け取り側のウォレット (販売者または一般の個人) は、各 L2 をサポートするよう努め、いくつかの非同期資金結合機能を備えています。2. 受取人はアドレスの隣に 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 内の直接 L1 への読み取り専用アクセス。 ** L2 は、L1 の状態を直接読み取ることができるように変更できます。キーストア コントラクトが L1 にある場合、L2 のコントラクトがキーストアに「無料」でアクセスできることを意味します。* **マークルの枝。 **マークル分岐は、L1 状態を L2 に証明することも、L2 状態を L1 に証明することも、両方の組み合わせにより、ある L2 の部分的な状態を別の L2 に証明することもできます。 Merkle 証明の主な弱点は、証明長によるガスコストの高さであり、5kB の証明長が必要となる場合がありますが、Verkle ツリーの使用により、将来的には 1kB 未満に削減される予定です。* **ZK-SNARK。 **ブランチ自体を使用する代わりに、Merkle ブランチの ZK-SNARK を使用することで、データ コストを削減できます。オフチェーン集約技術 (例: EIP-4337 上) を構築すると、単一の ZK-SNARK でブロック内のすべてのクロスチェーン状態証明を検証できるようになります。* **KZG の約束。 **L2 であっても、その上に構築されたスキームであっても、シーケンシャル アドレッシング システムを導入することができ、システム内の状態証明をわずか 48 バイトにすることができます。 ZK-SNARK と同様、マルチプルーフ スキームでは、これらすべてのプルーフをブロックごとに 1 つのプルーフに結合できます。すべてのトランザクションに証明が必要になることを避けたい場合は、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 の取り組みは成功例であり、私たちが必要とする根本的な改革が実際に可能であることの表れと見なされるべきです。 ** しかし、アプリケーションレベルで行う必要のある改革はまだたくさんあります。ここではいくつかの例を示します。* **多くの DApp は、ユーザーがオフチェーン署名を提供することに依存しています。 **外部アカウント (EOA) の場合は簡単です。 ERC-1271 は、スマート コントラクト ウォレットに対してこれを行うための標準化された方法を提供します。ただし、多くの DApps は依然として ERC-1271 をサポートしていないため、適応する必要があります。* ** ユーザーと契約を区別するために「これは EOA ですか?」を使用する DApps (転送の防止やロイヤルティの強制など) には問題が発生します。 ** 一般に、ここで純粋に技術的な解決策を見つけようとしないことをお勧めします。暗号制御の特定の移転が受益所有権の移転であるかどうかを判断することは、オフチェーンのコミュニティ主導の何らかの手段に頼らなければ解決できない可能性がある難しい問題です。メカニズムが解決します。おそらく、アプリケーションは転送をブロックする技術的手段よりも、ハーバーガー税のような技術に依存することになるでしょう。* **支払いと暗号化キーとのウォレットの相互作用には改善が必要です。 **現在、ウォレットは通常、アプリケーション固有のキーを生成するために決定論的な署名を使用します。EOA の秘密鍵を使用して標準のノンス (アプリケーション名のハッシュなど) に署名すると、秘密鍵が所有されていない限り決定論的な値が生成され、そうでない場合は値が生成されます。生成できないため、純粋に技術的に安全です。ただし、これらの手法はウォレットに対して「不透明」であるため、ウォレットがユーザー インターフェイス レベルのセキュリティ チェックを実装することができません。より成熟したエコシステムでは、署名、暗号化、および関連機能はウォレットによってより明示的に処理される必要があります。* **ライト クライアント (Helios など) は、レイヤー 1 だけではなくレイヤー 2 を認証する必要があります****。 **現在、ライト クライアントは、L1 ブロック ヘッダー情報の有効性のチェック (ライト クライアント同期プロトコルを使用)、および L1 ブロック ヘッダー情報に基づく L1 状態のマークル ブランチとトランザクションの検証に重点を置いています。将来的には、L1 に保存されている状態ルートに基づく L2 状態の証明も検証する必要があります (より高度なバージョンでは実際に L2 事前確認を確認します)。## ウォレットは資産とデータを保護する必要がある現在、ウォレットの使命は資産を保護することです。すべてがオンチェーンに保存され、ウォレットが保護する必要があるのは、現在これらの資産を保護している秘密鍵だけです。キーを変更した場合、翌日には以前の秘密キーをインターネット上に安全に公開できます。しかし、ゼロ知識の世界では、これは当てはまりません。ウォレットは認証資格情報を保護するだけでなく、データも保持します。そのような世界の最初の兆候は、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 つにすぎません。 ID プロファイル全体を移行したり、多くのアプリケーションのレコードを更新したりせずに、名前を変更できる必要があります。* **信頼を必要としない、事実に反する名前を付けることはできません。 **あらゆるブロックチェーンの重要なユーザー エクスペリエンス機能は、まだチェーンと対話したことのないユーザーにトークンを送信できる機能です。このような機能がないと、ジレンマが生じます。チェーンと対話するには取引手数料を支払う必要があり、取引手数料を支払うには既にトークンを所有している必要があります。 CREATE2 を使用したスマート コントラクト アドレスを含む ETH アドレスには、この機能があります。 ENS 名はそうではありません。両方のボブがオフチェーンで bob.ecc.eth であると決定した場合、どちらのボブに名前を付けるかを選択する方法がないからです。考えられる解決策の 1 つは、この記事のアーキテクチャで前述したキーストア コントラクトにさらに多くのコンテンツを組み込むことです。キーストア コントラクトには、ユーザーとユーザーとのやり取りに関するさまざまな情報を含めることができます (CCIP では、この情報の一部をオフチェーンにできます)。ユーザーはキーストア コントラクトを主要な識別子として使用します。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に依存せず、仮想名にも適しています。特定の固定初期パラメータを使用したキーストア コントラクトによってのみ初期化できるアドレスを生成できます。別のクラスのソリューションには、ビットコインの支払いプロトコルと同様に、ユーザー向けアドレスの概念を完全に放棄することが含まれます。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者はリクエスト リンクを (明示的な URL または QR コードとして) 送信し、受信者はそれを使用して、受け入れたいリクエストを送信できます。支払い。最初に行動するのが送信者であっても受信者であっても、ウォレットにさらに依存して最新の支払い情報をリアルタイムで生成することで、摩擦が軽減されます。ただし、永続的な識別子は便利ですが (特に ENS の場合)、実際には送信者と受信者の間の直接通信に依存するのは非常に難しい問題であるため、さまざまな手法を組み合わせることが考えられます。これらの設計のすべてにおいて、分散化を維持し、ユーザーにとって理解しやすいことが重要です。ユーザーが現在のアセットとそのユーザーを対象としたメッセージの最新ビューに簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。より複雑化した決済インフラが、理解しにくく新しい環境に適応するのが難しい不透明な「抽象の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。
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 の場合)、実際には送信者と受信者の間の直接通信に依存するのは非常に難しい問題であるため、さまざまな手法を組み合わせることが考えられます。
これらの設計のすべてにおいて、分散化を維持し、ユーザーにとって理解しやすいことが重要です。ユーザーが現在のアセットとそのユーザーを対象としたメッセージの最新ビューに簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。より複雑化した決済インフラが、理解しにくく新しい環境に適応するのが難しい不透明な「抽象の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。