原作者: イーサリアム創設者ヴィタリック・ブテリンDan Finlay、Karl Floersch、David Hoffman、および Scroll チームと SoulWallet チームのフィードバック、レビュー、提案に心より感謝いたします。イーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバル、パーミッションレスなエクスペリエンスを真に提供できる成熟したテクノロジースタックに移行するにつれて、スタックは 3 つの主要な技術的移行をほぼ同時に通過する必要があります。* L2 拡張移行 - 全員がロールアップに移行* ウォレットのセキュリティ移行 - 誰もがスマート コントラクト ウォレットに移行* プライバシーの移行 - プライバシーを保護した資金移動が利用可能であることを確認し、開発中の他のすべてのガジェット (社会的回復、アイデンティティ、評判) がプライバシーを保護していることを確認します。 生態系遷移トライアングル。最初のものがなければ、各取引に 3.75 ドル (再度強気相場があれば 82.48 ドル) のコストがかかるため、イーサリアムは失敗し、大衆市場を対象としたすべての製品は必然的にチェーンのことを忘れ、すべてに対して集中的な回避策を採用することになります。2番目がなければ、ユーザーが資金（および非金融資産）を保管することに消極的となり、誰もが集中型取引所に目を向けたため、イーサリアムは失敗していただろう。3 番目がなければ、すべてのトランザクション (および POAP など) がデータを最大限に隠す集中型ソリューションであるため、イーサリアムは失敗します。これら 3 つの移行は、上で概説した理由により重要です。しかし、適切に対処するには緊密な連携が必要なため、課題でもあります。改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとの対話方法を根本的に変更する必要があり、アプリケーションやウォレットに大幅な変更が必要になります。## **これら 3 つの移行により、ユーザーとアドレスの関係が根本的に再構築されます**L2 が拡張された世界では、ユーザーは多くの L2 上に存在します。あなたは Optimism に依存する ExampleDAO のメンバーですか?これで、Optimism アカウントを取得できました。 ZkSync のステーブルコイン システムで CDP を保持していますか?これで、ZkSync のアカウントを取得できました。カカロットのアプリはもう試しましたか？これでカカロットのアカウントができました！ユーザーが 1 つのアドレスしか持たなかった時代は終わりました。 ※私のBrave Walletの見方によれば、ETHは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 つです。誰かにお金を払いたい場合、その支払い方法に関する情報をどうやって入手しますか?ユーザーがさまざまな場所に保存されたチェーンにわたる多くの資産を持っている場合、主要な変更とソーシャルリカバリをどのように実行するのでしょうか?## 3 つの移行とオンチェーン支払い (および ID)私は Scroll にコインを持っているので、コーヒーの代金を支払いたいと思っています (「私」が文字通りこの記事の著者として私を指している場合、「コーヒー」はもちろん「緑茶」の換喩です)。コーヒーを売ってくれますが、コインは太閤でしか受け取れません。何をすべきか基本的に、解決策は 2 つあります。1. 受け取り側のウォレット (販売者または一般の個人) は、資金を非同期に統合するための自動化を行い、各 L2 をサポートするために非常に熱心に働きます。2. 受取人は自分の L2 とそのアドレスを提供し、送信者のウォレットは L2 間ブリッジ システムを介して資金を宛先の L2 に自動的にルーティングします。もちろん、これらのソリューションは組み合わせることができます。受信者は受け入れてもよい L2 のリストを提供し、送信者のウォレットは支払いを計算します。これには直接送信が含まれる場合もあれば、運が良ければ L2 を介したブリッジ パスが含まれる場合もあります。しかし、これは、これら 3 つの移行が引き起こす重要な課題の一例にすぎません。誰かにお金を支払うような単純な操作では、20 バイトのアドレスだけではなく、より多くの情報が必要になるのです。幸いなことに、スマート コントラクト ウォレットへの移行によってアドレス指定システムに過剰な負荷がかかることはありませんが、アプリケーション スタックの他の部分には解決すべき技術的問題がまだいくつかあります。トランザクションで 21000 ガスを送信するだけではないことを確認するためにウォレットを更新する必要があります。また、ウォレットの支払い受け取り側が EOA からの ETH 送金を追跡するだけでなく、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 に証明することも、この 2 つを組み合わせて、ある L2 の部分的な状態を別の L2 に証明することもできます。 Merkle 証明の主な弱点は、証明の長さに起因する高いガスコストです。証明には 5 KB が必要になる場合がありますが、Verkle ツリーのおかげで、これは将来 1 KB 未満に削減される予定です。* ZK-SNARK。フォーク自体の代わりに Merkle フォークの ZK-SNARK を使用することで、データ コストを削減できます。オフチェーン集約技術を (たとえば、EIP-4337 の上に) 構築して、ZK-SNARK にブロック内のすべてのクロスチェーン状態証明を検証させることができます。※KZGのお約束。 L2、またはその上に構築されたスキームは、シーケンシャル アドレッシング システムを導入することができ、そのシステム内の状態証明の長さをわずか 48 バイトにすることができます。 ZK-SNARK と同様に、複数の証明スキームは、これらすべての証明をブロックごとに 1 つの証明に結合できます。 すべてのトランザクションに対してプルーフを作成することを避けたい場合は、回復するために 1 つのクロス L2 プルーフのみを必要とする、より軽量なスキームを実装できます。アカウントからの支出は、対応する公開キーがアカウントに保存されている支出キーに依存しますが、回復には、キーストア内の現在の支出公開キーをコピーするトランザクションが必要です。古いキーがそうでない場合でも、反事実アドレス内の資金は安全です。反事実アドレスを「アクティブ化」して有効な契約に変えるには、現在の支出\_pubkey を複製するためのクロス L2 証明が必要です。 Safe フォーラムのこのスレッドでは、同様のアーキテクチャがどのように機能するかについて説明しています。このようなスキームにプライバシーを追加するには、このポインターを単純に暗号化し、ZK-SNARK ですべての証明を行います。 さらに作業を進めると (たとえば、この作業を出発点として使用するなど)、ZK-SNARK の複雑さのほとんどを除去し、より単純な KZG ベースのスキームを作成することもできます。これらのシナリオは複雑になる可能性があります。プラスの面としては、それらの間には多くの潜在的な相乗効果があります。たとえば、「キーストア コントラクト」の概念は、前のセクションで説明した「アドレス」の課題も解決できます。ユーザーがキーを再生成するたびに変更されない永続的なアドレスをユーザーに持たせたい場合は、非表示のメタ アドレスを置くことができます。 、暗号化キーおよびその他の情報はキーストア コントラクトに組み込まれ、キーストア コントラクトのアドレスがユーザーの「アドレス」として使用されます。## 多くの二次インフラストラクチャをアップグレードする必要があるENS の使用には費用がかかります。 2023 年 6 月の現在、状況はそれほど悪くありません。取引手数料は高いものの、依然として ENS ドメイン料金に匹敵します。 zuzalu.eth への登録には約 27 ドルかかり、そのうち 11 ドルは取引手数料でした。しかし、再び強気相場があれば、手数料は高騰するでしょう。 ETH 価格の値上げがなくても、ガス料金を 200 グウェイに戻すと、ドメイン登録の送信料金は 104 ドルに上昇します。したがって、人々に実際に ENS を使ってもらいたい場合、特にユーザーがほぼ無料の登録を要求する分散型ソーシャル メディアのようなユースケースでは (これらのプラットフォームはユーザーにサブドメインを提供するため、ENS ドメイン料金は問題になりません)、L2 で ENS が機能する必要があります。 。幸いなことに、ENS チームが強化し、L2 で ENS が開催されています。 ERC-3668 (別名「CCIP 標準」) は、ENSIP-10 と連携して、L2 上の ENS サブドメインを自動的に検証可能にする方法を提供します。 CCIP 標準では、L2 データの証明を検証する方法を記述するスマート コントラクトの作成と、ドメイン (例: Optinames が ecc.eth を使用する) をそのようなコントラクトの制御下に置くことができることが要求されます。 CCIP コントラクトが L1 上の ecc.eth の制御を取得すると、一部の subdomain.ecc.eth にアクセスすると、その特定のサブドメインが実際に保存されている L2 内の状態証明 (マークル ブランチなど) を自動的に見つけて検証することになります。 実際にプルーフを取得するには、コントラクトに保存されている URL のリストが必要で、確かに一元管理されているように感じますが、実際はそうではないと思います。これは 1-of-N 信頼モデルです (無効なプルーフは、CCIP コントラクト コールバック関数の検証ロジックによってキャッチされます)。 URL の 1 つが有効な証明を返す限り、問題ありません)。 URL のリストには数十が含まれる場合があります。ENS CCIP の取り組みは成功例であり、私たちが必要としているような抜本的な改革が実際に可能であることの表れと見るべきです。しかし、アプリケーション層の改革にはやるべきことがまだたくさんあります。いくつかの例:* 多くの dapp は、ユーザーがオフチェーン署名を提供することに依存しています。外部所有アカウント (EOA) を使用すると、それは簡単です。 ERC-1271 は、スマート コントラクト ウォレットがこれを行うための標準化された方法を提供します。ただし、多くの dapps はまだ ERC-1271 をサポートしていないため、今後はサポートする必要があります。* ユーザーと契約を区別するために「これは EOA ですか?」を使用する Dapps (転送の禁止やロイヤルティ料金の強制など) は機能しません。一般に、ここで純粋に技術的な解決策を探そうとしないことをお勧めします。暗号制御の特定の移転が受益所有権の移転であるかどうかを判断することは、オフチェーンのコミュニティ主導のメカニズムに対処しない限り解決できない可能性がある難しい問題です。おそらく、アプリは転用防止よりもハーバーガー税のような技術に依存することになるでしょう。* ウォレットが支出キーと暗号化キーを操作する方法を改善する必要があります。現在、ウォレットは通常、決定論的な署名を使用してアプリケーション固有のキーを生成します。EOA の秘密鍵を使用して標準のノンス (アプリケーション名のハッシュなど) に署名すると、秘密鍵なしでは生成できない決定論的な値が生成されるため、安全です。純粋に技術的な意味で。ただし、これらの手法はウォレットに対して「不透明」であるため、ウォレットがユーザーインターフェイスレベルのセキュリティチェックを実装することができません。より成熟したエコシステムでは、署名、暗号化、および関連機能はウォレットによってより明示的に処理される必要があります。* ライト クライアント (Helios など) は、L1 だけでなく L2 も認証する必要があります。現在、ライト クライアントは、(ライト クライアント同期プロトコルを使用して) L1 ヘッダーの有効性をチェックし、L1 状態のマークル フォークと L1 ヘッダーに基づくトランザクションを検証することに重点を置いています。明日は、L1 に保存されている状態ルートに基づく L2 状態の証明も検証する必要があります (より高度なバージョンでは実際に L2 事前確認を調べます)。## ウォレットは資産とデータを保護する必要がある今日、ウォレットは資産を保護する役割を果たしています。すべてがオンチェーン上にあり、ウォレットが保護する必要があるのは、現在これらの資産を保護している秘密鍵だけです。キーを変更すると、翌日には以前の秘密キーをインターネット上で安全に公開できます。しかし、ZK の世界では、これはもはや真実ではありません。ウォレットは認証資格情報を保護するだけでなく、データも保持します。私たちは、Zuzalu が使用する ZK-SNARK ベースの ID システムである Zupass で、そのような世界の最初の兆候を確認しました。ユーザーはシステム認証用の秘密鍵を持っており、これを使用して「自分がズザルの居住者であることを、誰であるかを明かさずに証明する」などの基本的な証明を行うことができます。しかし、Zupass システムは、その上に他のアプリケーション、特にスタンプ (POAP の Zupass バージョン) の構築も開始しました。 私がチームキャットの誇り高きメンバーであることを証明する、私の多くのズパススタンプのうちの 1 つ。POAP と比較してスタンプが提供する主な機能は、スタンプがプライベートであることです。データはローカルに保存され、誰かに自分に関する情報を知ってもらいたい場合は、スタンプ (またはスタンプに関する何らかの計算) を誰かに証明するだけで済みます。しかし、それはリスクを増大させます。その情報を失うと、スタンプも失われることになります。もちろん、データの保持の問題は、単一の暗号化キーの保持の問題に還元できます。つまり、サードパーティ (またはチェーン) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを安全に保管するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてが失われます。一方、誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。Zupass の実際的な解決策は、同時にすべてのデバイスにアクセスできなくなる可能性が低いため、複数のデバイス (ラップトップや電話など) にキーを保存することを人々に奨励することです。さらに一歩進んで、秘密共有を使用してキーを保存し、複数のガーディアンに分散させることができます。MPC を介したこの社会的回復は、現在の後見人だけでなく、以前の後見人も共謀して資産を盗む可能性があり、容認できないほど高いリスクを意味するため、ウォレットにとって適切な解決策ではありません。しかし、プライバシー侵害のリスクは通常、資産全体の損失リスクよりも低く、プライバシーを重視するユースケースを持つ人々は、プライバシーを要求する操作に関連するキーをバックアップしないことで、より高い損失リスクを常に受け入れることができます。ユーザーが複数の回復パスを備えたビザンチン システムに圧倒されないようにするために、ソーシャル リカバリをサポートするウォレットは、資産の回復と暗号化キーの回復の両方を管理する必要がある場合があります。## アイデンティティに戻るこれらの変更に共通することの 1 つは、チェーン上で「あなた」を表すために使用する暗号化識別子である「アドレス」の概念を根本的に変更する必要があるということです。 「私と対話する方法に関する指示」は単なる ETH アドレスではなくなり、複数の L2 上の複数のアドレス、ステルス メタ アドレス、暗号化キー、およびその他のデータを何らかの形式で組み合わせたものでなければなりません。1 つの方法は、ENS を自分の ID にすることです。ENS レコードにはこれらすべての情報を含めることができ、誰かに bob.eth (または bob.ecc.eth、または...) を送信すると、相手は検索して、その方法についてすべてを確認できます。より複雑なクロスドメインやプライバシー保護の方法を含めて、支払いを行い、ユーザーと対話します。しかし、この ENS 中心のアプローチには 2 つの弱点があります。* ドメイン名に関連付けられているものが多すぎます。あなたのドメイン名はあなた自身ではありません。あなたのドメイン名はあなたの多くの属性の 1 つです。 ID プロファイル全体を移動したり、多くのアプリケーションで大量のレコードを更新したりすることなく、ドメイン名を変更できるはずです。* 信頼できない事実に反するトウモロコシを入手することはできません。ブロックチェーンの重要な UX 機能は、まだチェーンと対話したことのない人々にコインを送信できる機能です。このような機能がないと、問題 22 があります。チェーンとの対話には取引手数料の支払いが必要であり、そのためには... すでにコインを持っている必要があります。 CREATE2 を使用したスマート コントラクト アドレスを含む ETH アドレスには、この機能があります。 ENS 名はそうではありません。2 人の Bob が両方とも bob.ecc.eth オフチェーンであると判断した場合、どちらに名前を付けるかを選択する方法がないからです。考えられる解決策の 1 つは、この記事の前半のアーキテクチャで説明したキーストア コントラクトにさらに多くのコンテンツを組み込むことです。キーストア コントラクトには、ユーザーに関するあらゆる種類の情報と、キーストア コントラクトとのやり取り方法 (CCIP の場合、この情報の一部はオフチェーンである可能性があります) を含めることができ、ユーザーはキーストア コントラクトを主要な識別子として使用します。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に依存せず、反事実に優しいため、いくつかの固定初期パラメーターを使用したキーストア コントラクトによってのみ初期化されることが証明できるアドレスを生成できます。別のタイプのソリューションは、ビットコイン支払いプロトコルに似ており、ユーザー指向のアドレスの概念を完全に放棄しています。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者は、受信者が支払いを受け入れる意思を追跡するために使用できる請求リンクを (明示的な URL または QR コードとして) 送信することができます。 送信者と受信者のどちらが先に移動するかに関係なく、ウォレットにさらに依存して最新の支払い情報をリアルタイムで直接生成することで、摩擦が軽減されます。そうは言っても、永続的な識別子は便利ですが (特に ENS の場合)、送信者と受信者の間の直接通信の前提は実際には非常に扱いにくいため、最終的にはさまざまなテクノロジーの組み合わせが登場する可能性があります。これらすべての設計において、物事を個別に作成し、ユーザーにとって理解しやすくすることが最も重要です。ユーザーが自分の現在の資産や公開されているニュースの最新ビューに簡単にアクセスできるようにする必要があります。これらの観点は、独自のソリューションではなく、オープン ツールに依存する必要があります。より複雑な決済インフラが、開発者が何が起こっているのかを理解し、新しい環境に適応させることが難しい不透明な「抽象化の塔」にならないようにするには、大変な努力が必要です。課題はあるものの、スケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することは、イーサリアムの将来にとって極めて重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に立ち向かう必要があります。
ヴィタリック・ブテリン: イーサリアムの 3 つの技術的移行
原作者: イーサリアム創設者ヴィタリック・ブテリン
Dan Finlay、Karl Floersch、David Hoffman、および Scroll チームと SoulWallet チームのフィードバック、レビュー、提案に心より感謝いたします。
イーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバル、パーミッションレスなエクスペリエンスを真に提供できる成熟したテクノロジースタックに移行するにつれて、スタックは 3 つの主要な技術的移行をほぼ同時に通過する必要があります。
最初のものがなければ、各取引に 3.75 ドル (再度強気相場があれば 82.48 ドル) のコストがかかるため、イーサリアムは失敗し、大衆市場を対象としたすべての製品は必然的にチェーンのことを忘れ、すべてに対して集中的な回避策を採用することになります。
2番目がなければ、ユーザーが資金（および非金融資産）を保管することに消極的となり、誰もが集中型取引所に目を向けたため、イーサリアムは失敗していただろう。
3 番目がなければ、すべてのトランザクション (および POAP など) がデータを最大限に隠す集中型ソリューションであるため、イーサリアムは失敗します。
これら 3 つの移行は、上で概説した理由により重要です。しかし、適切に対処するには緊密な連携が必要なため、課題でもあります。改善する必要があるのはプロトコルの機能だけではありません。場合によっては、イーサリアムとの対話方法を根本的に変更する必要があり、アプリケーションやウォレットに大幅な変更が必要になります。
これら 3 つの移行により、ユーザーとアドレスの関係が根本的に再構築されます
L2 が拡張された世界では、ユーザーは多くの L2 上に存在します。あなたは Optimism に依存する ExampleDAO のメンバーですか?これで、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 つです。
誰かにお金を払いたい場合、その支払い方法に関する情報をどうやって入手しますか?
ユーザーがさまざまな場所に保存されたチェーンにわたる多くの資産を持っている場合、主要な変更とソーシャルリカバリをどのように実行するのでしょうか?
3 つの移行とオンチェーン支払い (および ID)
私は Scroll にコインを持っているので、コーヒーの代金を支払いたいと思っています (「私」が文字通りこの記事の著者として私を指している場合、「コーヒー」はもちろん「緑茶」の換喩です)。コーヒーを売ってくれますが、コインは太閤でしか受け取れません。何をすべきか
基本的に、解決策は 2 つあります。
もちろん、これらのソリューションは組み合わせることができます。受信者は受け入れてもよい L2 のリストを提供し、送信者のウォレットは支払いを計算します。これには直接送信が含まれる場合もあれば、運が良ければ L2 を介したブリッジ パスが含まれる場合もあります。
しかし、これは、これら 3 つの移行が引き起こす重要な課題の一例にすぎません。誰かにお金を支払うような単純な操作では、20 バイトのアドレスだけではなく、より多くの情報が必要になるのです。
幸いなことに、スマート コントラクト ウォレットへの移行によってアドレス指定システムに過剰な負荷がかかることはありませんが、アプリケーション スタックの他の部分には解決すべき技術的問題がまだいくつかあります。トランザクションで 21000 ガスを送信するだけではないことを確認するためにウォレットを更新する必要があります。また、ウォレットの支払い受け取り側が EOA からの ETH 送金を追跡するだけでなく、ETH も追跡していることを確認することがより重要です。スマートコントラクトコードによって送信されます。アドレスの不変の所有権の前提に依存するアプリケーション (ロイヤルティ料金を強制するスマートコントラクトを禁止する NFT など) は、目標を達成するために別の方法を見つける必要があります。スマート コントラクト ウォレットも物事を簡単にします。特に、誰かが非 ETH ERC20 トークンのみを受け取った場合、ERC-4337 ペイマスターを使用してそのトークンを使用してガス代を支払うことができるようになります。
一方、プライバシーは、私たちがまだ実際に取り組んでいない大きな課題を再び提起します。オリジナルの Tornado Cash では、内部送金がサポートされていなかったため、これらの問題は発生しませんでした。ユーザーはシステムへの入金とシステムからの引き出しのみが可能でした。ただし、内部転送が可能になると、ユーザーはプライバシー システムの内部アドレス指定スキームを使用する必要があります。実際には、ユーザーの「支払いメッセージ」には、(i) 受信者が使用できる秘密の約束であるある種の「使用公開鍵」、および (ii) 送信者が暗号通貨を送信するための何らかの方法が含まれている必要があります。受取人が支払いを発見するために役立つ、受取人が解読できる情報のみ。
ステルス アドレス プロトコルはメタ アドレスの概念に依存しており、このように機能します。メタ アドレスの一部は送信者の支出キーのブラインド バージョンであり、他の部分は送信者の暗号化キーです (ただし、最小限の実装では両方を設定できます)。キーは同じです）。
ここでの重要な教訓は、プライバシーに配慮したエコシステムでは、ユーザーは消費用公開鍵と暗号化用公開鍵の両方を持つことになり、ユーザーの「支払い情報」には両方の鍵が含まれている必要があるということです。支払い以外にも、この方向に拡大する十分な理由があります。たとえば、イーサリアムに基づいて暗号化された電子メールが必要な場合、ユーザーはある種の暗号化キーを公的に提供する必要があります。 「EOA の世界」では、このためにアカウント キーを再利用できますが、安全なスマート コントラクト ウォレットの世界では、おそらくこれのためのより明示的な機能を提供する必要があります。これは、イーサリアムベースのアイデンティティと、非イーサリアム分散型プライバシー エコシステム、特に PGP キーとの互換性を高めるのにも役立ちます。
3 つの遷移とキーの回復
各ユーザーが複数のアドレスを持っている世界で重要な変更とソーシャル リカバリを実装するデフォルトの方法は、単にユーザーに各アドレスに対して個別にリカバリ プロセスを実行させることです。これはワンクリックで実行できます。ウォレットには、すべてのユーザーのアドレスに対して回復手順を同時に実行できるソフトウェアを含めることができます。ただし、このようにユーザー エクスペリエンスが簡素化されたとしても、単純な複数アドレスの回復には次の 3 つの問題があります。
これらの問題を解決するのは困難です。幸いなことに、妥当なパフォーマンスを発揮するエレガントなソリューションがあります。それは、検証ロジックを資産保持から分離するアーキテクチャです。
証明はいくつかの方法で行うことができます。
このようなスキームにプライバシーを追加するには、このポインターを単純に暗号化し、ZK-SNARK ですべての証明を行います。
これらのシナリオは複雑になる可能性があります。プラスの面としては、それらの間には多くの潜在的な相乗効果があります。たとえば、「キーストア コントラクト」の概念は、前のセクションで説明した「アドレス」の課題も解決できます。ユーザーがキーを再生成するたびに変更されない永続的なアドレスをユーザーに持たせたい場合は、非表示のメタ アドレスを置くことができます。 、暗号化キーおよびその他の情報はキーストア コントラクトに組み込まれ、キーストア コントラクトのアドレスがユーザーの「アドレス」として使用されます。
多くの二次インフラストラクチャをアップグレードする必要がある
ENS の使用には費用がかかります。 2023 年 6 月の現在、状況はそれほど悪くありません。取引手数料は高いものの、依然として ENS ドメイン料金に匹敵します。 zuzalu.eth への登録には約 27 ドルかかり、そのうち 11 ドルは取引手数料でした。しかし、再び強気相場があれば、手数料は高騰するでしょう。 ETH 価格の値上げがなくても、ガス料金を 200 グウェイに戻すと、ドメイン登録の送信料金は 104 ドルに上昇します。したがって、人々に実際に ENS を使ってもらいたい場合、特にユーザーがほぼ無料の登録を要求する分散型ソーシャル メディアのようなユースケースでは (これらのプラットフォームはユーザーにサブドメインを提供するため、ENS ドメイン料金は問題になりません)、L2 で ENS が機能する必要があります。 。
幸いなことに、ENS チームが強化し、L2 で ENS が開催されています。 ERC-3668 (別名「CCIP 標準」) は、ENSIP-10 と連携して、L2 上の ENS サブドメインを自動的に検証可能にする方法を提供します。 CCIP 標準では、L2 データの証明を検証する方法を記述するスマート コントラクトの作成と、ドメイン (例: Optinames が ecc.eth を使用する) をそのようなコントラクトの制御下に置くことができることが要求されます。 CCIP コントラクトが L1 上の ecc.eth の制御を取得すると、一部の subdomain.ecc.eth にアクセスすると、その特定のサブドメインが実際に保存されている L2 内の状態証明 (マークル ブランチなど) を自動的に見つけて検証することになります。
ENS CCIP の取り組みは成功例であり、私たちが必要としているような抜本的な改革が実際に可能であることの表れと見るべきです。しかし、アプリケーション層の改革にはやるべきことがまだたくさんあります。いくつかの例:
ウォレットは資産とデータを保護する必要がある
今日、ウォレットは資産を保護する役割を果たしています。すべてがオンチェーン上にあり、ウォレットが保護する必要があるのは、現在これらの資産を保護している秘密鍵だけです。キーを変更すると、翌日には以前の秘密キーをインターネット上で安全に公開できます。しかし、ZK の世界では、これはもはや真実ではありません。ウォレットは認証資格情報を保護するだけでなく、データも保持します。
私たちは、Zuzalu が使用する ZK-SNARK ベースの ID システムである Zupass で、そのような世界の最初の兆候を確認しました。ユーザーはシステム認証用の秘密鍵を持っており、これを使用して「自分がズザルの居住者であることを、誰であるかを明かさずに証明する」などの基本的な証明を行うことができます。しかし、Zupass システムは、その上に他のアプリケーション、特にスタンプ (POAP の Zupass バージョン) の構築も開始しました。
POAP と比較してスタンプが提供する主な機能は、スタンプがプライベートであることです。データはローカルに保存され、誰かに自分に関する情報を知ってもらいたい場合は、スタンプ (またはスタンプに関する何らかの計算) を誰かに証明するだけで済みます。しかし、それはリスクを増大させます。その情報を失うと、スタンプも失われることになります。
もちろん、データの保持の問題は、単一の暗号化キーの保持の問題に還元できます。つまり、サードパーティ (またはチェーン) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを安全に保管するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてが失われます。一方、誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。
Zupass の実際的な解決策は、同時にすべてのデバイスにアクセスできなくなる可能性が低いため、複数のデバイス (ラップトップや電話など) にキーを保存することを人々に奨励することです。さらに一歩進んで、秘密共有を使用してキーを保存し、複数のガーディアンに分散させることができます。
MPC を介したこの社会的回復は、現在の後見人だけでなく、以前の後見人も共謀して資産を盗む可能性があり、容認できないほど高いリスクを意味するため、ウォレットにとって適切な解決策ではありません。しかし、プライバシー侵害のリスクは通常、資産全体の損失リスクよりも低く、プライバシーを重視するユースケースを持つ人々は、プライバシーを要求する操作に関連するキーをバックアップしないことで、より高い損失リスクを常に受け入れることができます。
ユーザーが複数の回復パスを備えたビザンチン システムに圧倒されないようにするために、ソーシャル リカバリをサポートするウォレットは、資産の回復と暗号化キーの回復の両方を管理する必要がある場合があります。
アイデンティティに戻る
これらの変更に共通することの 1 つは、チェーン上で「あなた」を表すために使用する暗号化識別子である「アドレス」の概念を根本的に変更する必要があるということです。 「私と対話する方法に関する指示」は単なる ETH アドレスではなくなり、複数の L2 上の複数のアドレス、ステルス メタ アドレス、暗号化キー、およびその他のデータを何らかの形式で組み合わせたものでなければなりません。
1 つの方法は、ENS を自分の ID にすることです。ENS レコードにはこれらすべての情報を含めることができ、誰かに bob.eth (または bob.ecc.eth、または...) を送信すると、相手は検索して、その方法についてすべてを確認できます。より複雑なクロスドメインやプライバシー保護の方法を含めて、支払いを行い、ユーザーと対話します。
しかし、この ENS 中心のアプローチには 2 つの弱点があります。
考えられる解決策の 1 つは、この記事の前半のアーキテクチャで説明したキーストア コントラクトにさらに多くのコンテンツを組み込むことです。キーストア コントラクトには、ユーザーに関するあらゆる種類の情報と、キーストア コントラクトとのやり取り方法 (CCIP の場合、この情報の一部はオフチェーンである可能性があります) を含めることができ、ユーザーはキーストア コントラクトを主要な識別子として使用します。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に依存せず、反事実に優しいため、いくつかの固定初期パラメーターを使用したキーストア コントラクトによってのみ初期化されることが証明できるアドレスを生成できます。
別のタイプのソリューションは、ビットコイン支払いプロトコルに似ており、ユーザー指向のアドレスの概念を完全に放棄しています。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者は、受信者が支払いを受け入れる意思を追跡するために使用できる請求リンクを (明示的な URL または QR コードとして) 送信することができます。
これらすべての設計において、物事を個別に作成し、ユーザーにとって理解しやすくすることが最も重要です。ユーザーが自分の現在の資産や公開されているニュースの最新ビューに簡単にアクセスできるようにする必要があります。これらの観点は、独自のソリューションではなく、オープン ツールに依存する必要があります。より複雑な決済インフラが、開発者が何が起こっているのかを理解し、新しい環境に適応させることが難しい不透明な「抽象化の塔」にならないようにするには、大変な努力が必要です。課題はあるものの、スケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することは、イーサリアムの将来にとって極めて重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に立ち向かう必要があります。