原文：「三つの変遷」作者: ヴィタリック ブテリンコンパイル: MarsBit、MKイーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバルなパーミッションレスのエクスペリエンスを真に提供できる成熟したテクノロジースタックに変革するとき、スタックは 3 つの主要な技術変革をほぼ同時に通過する必要があります。1. L2 スケーリングの移行 - 全員がロールアップに移行2. ウォレットのセキュリティシフト - 誰もがスマートコントラクトウォレットに移行3. プライバシーシフト - プライバシーを保護した送金を保証し、開発中の他のすべてのツール (社会的回復、アイデンティティ、評判) がプライバシーを保護することを保証します。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)これが生態系変革のトライアングルです。 3 つのうち 3 つしか選択できません。最初のものがなければ、各トランザクションに 3.75 ドル (再度強気相場があれば 82.48 ドル) のコストがかかるため、イーサリアムは失敗し、すべてのマスマーケット製品は最終的にチェーンを忘れ、すべてに対して集中ソリューションを採用することになります。2番目がなければ、ユーザーは資金（および非金融資産）を保管することに消極的となり、すべてが集中型取引所に移行するため、イーサリアムは失敗するでしょう。3 番目がなければ、イーサリアムは失敗します。すべてのトランザクション (および POAP など) が誰でも見ることができるように公開されるため、多くのユーザーにとってプライバシーが法外に犠牲になり、誰もが少なくとも一部の隠しデータを一元管理しようとするでしょう。解決。前述の理由により、これら 3 つの移行は重要です。しかし、解決するには多大な調整が必要となるため、課題でもあります。プロトコルの機能を改善する必要があるだけでなく、イーサリアムとの対話方法にかなり根本的な変更を加える必要があり、アプリケーションやウォレットに大幅な変更が必要になる場合があります。### これら 3 つの変化は、ユーザーとアドレスの関係に革命をもたらしますL2 が拡張された世界では、ユーザーは多くの L2 に存在します。あなたは Optimism に掲載されている ExampleDAO のメンバーですか?これで、Optimism のアカウントを取得できました。 ZkSync のステーブルコイン システムで CDP を保有していますか?これで、ZkSync のアカウントを取得できました。カカロットにあるアプリをいくつか試してみましたか？これでカカロットのアカウントができました！ユーザーが 1 つのアドレスしか持てなかった時代は終わりました。Brave Wallet の見解によると、私は 4 か所に ETH を保有しています。はい、Arbitrum と Arbitrum Nova は異なります。心配しないでください。これは時間の経過とともにさらに複雑になります。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)スマート コントラクト ウォレットではさらに複雑さが増し、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 つの移行はオンチェーン決済 (およびアイデンティティ) に関連しています私は Scroll にコインを持っているので、コーヒーの代金を支払いたいと思っています (「私」が文字通りこの記事の著者として私を指している場合、「コーヒー」はもちろん「緑茶」の換喩です)。コーヒーを売ってくれますが、Taiko でコインを受け取るだけです。私は何をしますか？基本的に、解決策は 2 つあります。1. 受け取り側のウォレット (販売者または単なる個人の可能性があります) は、資金を非同期に統合するための自動機能を備え、各 L2 をサポートするよう努めます。2. 受信者は自分の L2 とそのアドレスを提供し、送信者のウォレットはある種の L2 間ブリッジ システムを通じて自動的に資金をターゲット L2 にルーティングします。もちろん、これらのソリューションは組み合わせることができます。受信者は受け入れたい L2 リストを提供し、送信者のウォレットは支払いを計算します。これには、直接送信するか (運が良ければ)、L2 を介したブリッジ パス経由で送信することも含まれます。しかし、これは 3 つのシフトによってもたらされる重要な課題の一例にすぎません。誰かにお金を支払うという単純なことでも、単なる 20 バイトのアドレス以上の情報が必要になり始めます。幸いなことに、スマート コントラクト ウォレットへの切り替えにより、アドレス システムにはそれほど負担がかかりませんでしたが、アプリケーション スタックの他の部分で対処する必要がある技術的問題がまだいくつかあります。ウォレットは、トランザクションで 21000 ガスを送信するだけでなく、より重要なことに、ウォレットの支払い受信側が EOA からの ETH 送金だけでなく、スマート コントラクト コードによって送信された ETH も追跡するように更新する必要があります。アドレスの不変の所有権の前提に依存するアプリケーション (ロイヤルティを強制するスマートコントラクトを禁止する NFT など) は、目標を達成するために別の方法を見つける必要があります。スマート コントラクト ウォレットにより、いくつかの作業が簡単になります。特に、非 ETH ERC20 トークンのみを受け入れる場合、ERC-4337 支払者を使用してそのトークンでガス代を支払うことができるようになります。一方で、プライバシーは、私たちがまだ実際には解決していない大きな課題を再び提示しています。オリジナルの Tornado Cash では内部送金がサポートされていなかったため、これらの問題は発生しませんでした。ユーザーはシステムへの入金と引き出しのみが可能でした。内部転送が可能になったら、ユーザーはプライバシー システムの内部アドレス スキームを使用する必要があります。実際には、ユーザーの「支払いメッセージ」には、(i) 受信者が支払いに使用できる秘密の約束である、ある種の「支払い公開キー」、および (ii) 送信者は、ユーザーのみが使用できる暗号化されたメッセージを送信する必要があります。受信者は、受信者が支払いを発見できるように復号化することができます。プライバシー アドレス プロトコルは、次のように機能するメタアドレスの概念に依存しています。メタアドレスの一部は送信者の支出キーのブラインド バージョンであり、他の部分は送信者の暗号化キーです (ただし、実装は最小限です)。これを設定できます（両方のキーは同じです）。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)ここでの重要な教訓は、プライバシーを重視したエコシステムでは、ユーザーは支出用の公開キーと暗号化用の公開キーを持ち、ユーザーの「支払い情報」には両方のキーが含まれている必要があるということです。支払い以外にも、この方向に拡大する正当な理由は他にもあります。たとえば、イーサリアムで暗号化された電子メールが必要な場合、ユーザーは何らかの形式の暗号化キーを公的に提供する必要があります。 「EOA の世界」では、これを達成するためにアカウント キーを再利用できますが、安全なスマート コントラクト ウォレットの世界では、おそらくこれを達成するためのより明示的な機能が必要です。これは、イーサリアムベースのアイデンティティと非イーサリアム分散型プライバシーエコシステム（最も顕著な例は PGP キー）との互換性を高めるのにも役立ちます。### 3 つの変換とキーの回復ユーザーが複数のアドレスを持つ可能性がある世界では、主要な変更とソーシャル リカバリを実装するデフォルトの方法は、ユーザーが各アドレスに対して個別にリカバリ手順を実行することです。これはワンクリックで実行できます。ウォレットには、すべてのユーザーのアドレスに対して回復手順を同時に実行するソフトウェアを含めることができます。ただし、このような UX の簡素化を行ったとしても、単純なマルチアドレス回復には 3 つの問題があります。1. 非現実的なガス料金: これがすべてを物語っています。2. 反事実アドレス: スマート コントラクトが公開されていないアドレス (実際には、まだ資金を送金していないアカウントを意味します)。ユーザーは、潜在的に無限の反事実アドレスを所有していることになります。つまり、まだ存在しない L2 を含むすべての L2 に 1 つ以上の反事実アドレスと、ステガノグラフィー アドレス スキームから派生した、まったく異なる無限の反事実アドレスのセットです。3. プライバシー: ユーザーが複数のアドレスをリンクしないように意図的に多数のアドレスを持っている場合、それらを同時にまたはほぼ同時に復元して、すべてのアドレスを公開リンクすることは望ましくありません。これらの問題を解決するのは困難です。幸いなことに、非常にうまく機能するエレガントなソリューションがあります。それは、検証ロジックを資産保持から分離するアーキテクチャです。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)各ユーザーは、1 つの場所 (メインネットまたは特定の L2 の可能性があります) に存在するキーストア コントラクトを持っています。ユーザーは異なる L2 上にアドレスを持ち、各アドレスの検証ロジックはキーストア コントラクトへのポインターになります。これらのアドレスからの支出には、現在 (またはより現実的には最新の) 支出公開キーを示す証明をキーストア契約に含める必要があります。証明はいくつかの方法で行うことができます。1. L2 で直接読み取り専用 L1 アクセス。 L2 を変更して、L1 の状態を直接読み取る方法を提供できます。キーストア コントラクトが L1 にある場合、L2 のコントラクトがキーストアに「無料」でアクセスできることを意味します。2. メルケル首相の支部。マークル分岐では、L1 状態を L2 に証明したり、L2 状態を L1 に証明したり、その 2 つを組み合わせて、ある L2 状態の一部を別の L2 に証明したりできます。 Merkle 証明の主な弱点は、証明の長さに起因する高いガスコストです。証明には 5 KB が必要になる場合がありますが、Verkle ツリーのおかげで、将来的には 1 KB 未満に削減される予定です。3. ZK-SNARK。ブランチ自体の代わりに Merkle ブランチの ZK-SNARK を使用することで、データ コストを削減できます。オフチェーン集約技術 (たとえば、EIP-4337 に基づく) を構築すると、単一の ZK-SNARK が 1 つのブロック内のすべてのクロスチェーン状態証明を検証できるようになります。4. KZG の取り組み。 L2、またはその上に構築されたスキームは、このシステム内の状態証明の長さをわずか 48 バイトにすることを可能にするシーケンシャル アドレッシング システムを導入できます。 ZK-SNARK と同様に、マルチプルーフ スキームでは、これらすべてのプルーフをブロックごとに 1 つのプルーフに結合できます。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)トランザクションごとに証明を行うことを避けたい場合は、より軽量なソリューションを実装できます。回復時にクロス L2 証明を実行するだけで済みます。アカウントからの支出は、対応する公開キーがアカウントに保存されている支出キーに依存しますが、回復にはキーストア内の現在の支出公開キーをコピーするトランザクションが必要になります。古い鍵がそうでない場合でも、反事実アドレス内の資金は安全です。反事実アドレスを「アクティブ化」して有効な契約に変えるには、現在使用している公開鍵を複製するクロス L2 証明を実行する必要があります。 Safe フォーラムのこのスレッドでは、同様のアーキテクチャがどのように機能するかを説明しています。このようなスキームにプライバシーを追加するには、ポインターを暗号化してから、ZK-SNARK ですべての証明を行うだけです。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)さらに作業を進めると (たとえば、この作業を開始点として使用するなど)、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 状態の検索と検証が自動的に行われます。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)実際にプルーフを取得するには、コントラクトに保存されている一連の URL にアクセスする必要があり、確かに集中管理のように感じられますが、実際にはそうではないと私は主張します。これは 1-of-N 信頼モデルです (無効なプルーフは CCIP によってブロックされます)。コントラクトのコールバック関数のロジックは、有効な証拠を返す URL が存在する限り問題がないことをキャプチャします）。この URL リストには、数十の URL が含まれる場合があります。ENS CCIP の取り組みは成功例であり、私たちが必要としているような抜本的な改革が可能であるという兆候と見なされるべきです。しかし、アプリケーションレベルのさらなる改革が必要です。例としては次のようなものがあります。多くの dapp は、オフチェーン署名の提供をユーザーに依存しています。外部所有アカウント (EOA) の場合は簡単です。 ERC-1271 は、スマート コントラクト ウォレットがこれを行うための標準化された方法を提供します。ただし、多くの dapps はまだ ERC-1271 をサポートしていないため、サポートする必要があります。「これは EOA ですか?」を使用してユーザーと契約を区別する (例: 移転の防止やロイヤルティの強制など) Dapps は機能しなくなります。一般に、純粋に技術的な解決策を見つけようとしないことをお勧めします。暗号化管理の特定の移転が受益権移転であるかどうかを判断するという問題は、オフチェーン コミュニティに頼らなければ解決できない可能性がある難しい問題です。駆動機構。次に解決します。おそらく、アプリケーションは転送のブロックよりもむしろハーバーガー税のような技術に依存する必要があるでしょう。ウォレットが支出や暗号化キーとどのように相互作用するかを改善する必要があります。現在、ウォレットは通常、決定論的な署名を使用してアプリケーション固有のキーを生成します: 標準のノンス (アプリケーション名のハッシュなど) が EOA の秘密鍵で署名され、秘密鍵なしでは生成できないノンスが生成されます。のなので、技術的には安全です。ただし、これらの手法はウォレットに対して「不透明」であるため、ウォレットがユーザー インターフェイス レベルのセキュリティ チェックを実装することができません。より成熟したエコシステムでは、署名、暗号化、および関連機能はウォレットによってより明示的に処理される必要があります。ライトクライアント (Helios など) は、L1 だけでなく L2 を検証する必要があります。現在、ライト クライアントは、(ライト クライアント同期プロトコルを使用して) L1 ヘッダーの有効性をチェックし、L1 ヘッダーから発生するトランザクションの L1 状態とマークル フォークを検証することに重点を置いています。明日は、L1 に保存されている状態ルートに由来する L2 状態の証明も検証する必要があります (このより高度なバージョンでは、実際には L2 の事前確認を検討します)。### ウォレットは資産とデータを保護する必要がありますさて、ウォレットの役割は資産を保護することです。すべてがオンチェーン上にあり、ウォレットが保護する必要があるのは、現在それらの資産を保護している秘密鍵だけです。キーを変更すると、翌日には以前の秘密キーをインターネット上で安全に公開できます。しかし、ゼロ知識証明の世界では、これは当てはまりません。ウォレットは認証資格情報を保護するだけでなく、データも保護します。私たちは、Zuzalu で使用されている ZK-SNARK ベースの ID システムである Zupass で、そのような世界の最初の兆候を確認しました。ユーザーはシステムの認証に使用する秘密キーを持っており、「私がズザルの居住者であることを証明するが、どの居住者であるかは明らかにしない」などの基本的な証明を行うために使用できます。ただし、Zupass システムは、その上に他のアプリケーション、特にスタンプ (POAP の Zupass バージョン) も構築され始めました。私が Team Cat の誇り高きメンバーであることを証明する、たくさんある Zupass スタンプの 1 つ。POAP 上でスタンプが提供する主な機能は、スタンプがプライベートであることです。データはローカルに保持され、スタンプ (またはその計算) を証明するのは、自分に関する情報を相手に知らせたい場合のみです。ただし、これによりリスクが増大します。この情報を紛失すると、スタンプが失われることになります。もちろん、データの保持の問題は、結局は暗号キーの保持の問題に帰結します。つまり、サードパーティ (またはチェーン) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを安全に保管するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてが失われます。逆に、誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。Zupass の事実上の解決策は、すべてのキーを同時に紛失する可能性は低いため、複数のデバイス (ラップトップや携帯電話など) にキーを保存することを人々に奨励することです。さらに一歩進んで、秘密共有を使用してキーを保存し、キーを複数のガーディアンに分割することができます。MPC を介したこの社会的回復は、現在の後見人だけでなく、以前の後見人も共謀してあなたの資産を盗む可能性があり、これは容認できない高いリスクであるため、ウォレットにとって適切な解決策ではありません。ただし、プライバシーの侵害は、通常、資産の完全な損失よりもリスクが低く、高度にプライバシーを保護するユースケースが必要な場合は、プライバシーを必要とする関連キーをバックアップしないことで、損失のより高いリスクを受け入れることができます。アクションを保存すること。複数の回復パスの複雑なシステムでユーザーが圧倒されるのを避けるために、ソーシャル回復をサポートするウォレットは、資産回復と暗号鍵回復の両方を管理する必要がある場合があります。### アイデンティティの質問に戻るこれらの変更の共通テーマは、「あなた」を表す暗号化識別子としてオンチェーンで使用する「アドレス」の概念を根本的に変える必要があるということです。 「私と対話する方法に関する指示」はもはや単なる ETH アドレスではなく、複数の L2 上の複数のアドレスの組み合わせ、秘密のメタ アドレス、暗号化キー、その他のデータが何らかの形式で含まれている必要があります。これを行う 1 つの方法は、ENS を自分のアイデンティティにすることです。ENS レコードにはこれらすべての情報を含めることができ、誰かに bob.eth (または bob.ecc.eth など) を送信すると、相手は次の情報を調べて知ることができます。より複雑な分野横断的な方法やプライバシー保護の方法など、支払いやユーザーとのやり取りに関わるすべてのこと。ただし、この ENS 中心のアプローチには 2 つの弱点があります。* それはあなたの名前にあまりにも多くのことを結びつけます。あなたの名前はあなたではありません、あなたの名前はあなたの多くの属性の 1 つにすぎません。 ID プロファイル全体を移動したり、多くのアプリで大量のレコードを更新したりすることなく、名前を変更できるはずです。* 信頼できない、事実に反する名前を付けることはできません。ブロックチェーンの重要な UX 機能は、まだチェーンと対話したことのない人々にコインを送信できる機能です。このような機能がないと、卵が先か鶏が先かという問題が発生します。チェーンとの対話には取引手数料を支払う必要があり、手数料を支払うには既にコインを所有している必要があります。 CREATE2 を使用したスマート コントラクト アドレスを含む ETH アドレスには、この機能があります。 ENS 名はそうではありません。2 人のボブが両方とも bob.ecc.eth オフチェーンであると判断した場合、どちらに名前を付けるかを選択する方法がないからです。考えられる解決策の 1 つは、この記事の前半のアーキテクチャで述べたキーストア コントラクトにさらに多くのものを組み込むことです。キーストア コントラクトには、ユーザーに関するさまざまな情報と、キーストア コントラクトとの対話方法 (CCIP を介して、一部はオフチェーンである可能性があります) を含めることができ、ユーザーはキーストア コントラクトを主要な識別子として使用できます。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に束縛されず、反事実に優しいものです。いくつかの固定初期パラメーターを使用したキーストア コントラクトによってのみ初期化できるアドレスを生成できます。別のカテゴリのソリューションは、ユーザー指向のアドレスの概念を放棄することに関係しており、これはビットコイン支払いプロトコルと精神的に似ています。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者は請求リンクを (明示的な URL または QR コードとして) 送信し、受信者はそれを使用して支払いを希望どおりに受け入れることができます。![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)最初に行動するのが送信者であっても受信者であっても、ウォレットにさらに依存して最新の支払い情報をリアルタイムで直接生成することで、摩擦が軽減されます。そうは言っても、永続的な識別子は便利です (特に ENS の場合)。実際には、送信者と受信者間の直接通信を想定するのは非常に難しい問題であるため、さまざまなテクノロジの組み合わせを検討するかもしれません。これらすべての設計において、物事を分散化し、ユーザーにとって理解しやすいものにすることが重要です。ユーザーが現在の資産の最新ビューや、ユーザー向けに公開された情報に簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。開発者が何が起こっているのかを理解し、新しい環境に適応させるために、より複雑な決済インフラが不透明な「抽象化の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。Dan Finlay、Karl Floersch、David Hoffman、および Scroll チームと SoulWallet チームのフィードバック、レビュー、提案に心より感謝いたします。
Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります。
原文：「三つの変遷」
作者: ヴィタリック ブテリン
コンパイル: MarsBit、MK
イーサリアムが若い実験的なテクノロジーから、一般のユーザーにオープンでグローバルなパーミッションレスのエクスペリエンスを真に提供できる成熟したテクノロジースタックに変革するとき、スタックは 3 つの主要な技術変革をほぼ同時に通過する必要があります。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
これが生態系変革のトライアングルです。 3 つのうち 3 つしか選択できません。
最初のものがなければ、各トランザクションに 3.75 ドル (再度強気相場があれば 82.48 ドル) のコストがかかるため、イーサリアムは失敗し、すべてのマスマーケット製品は最終的にチェーンを忘れ、すべてに対して集中ソリューションを採用することになります。
2番目がなければ、ユーザーは資金（および非金融資産）を保管することに消極的となり、すべてが集中型取引所に移行するため、イーサリアムは失敗するでしょう。
3 番目がなければ、イーサリアムは失敗します。すべてのトランザクション (および POAP など) が誰でも見ることができるように公開されるため、多くのユーザーにとってプライバシーが法外に犠牲になり、誰もが少なくとも一部の隠しデータを一元管理しようとするでしょう。解決。
前述の理由により、これら 3 つの移行は重要です。しかし、解決するには多大な調整が必要となるため、課題でもあります。プロトコルの機能を改善する必要があるだけでなく、イーサリアムとの対話方法にかなり根本的な変更を加える必要があり、アプリケーションやウォレットに大幅な変更が必要になる場合があります。
これら 3 つの変化は、ユーザーとアドレスの関係に革命をもたらします
L2 が拡張された世界では、ユーザーは多くの L2 に存在します。あなたは Optimism に掲載されている ExampleDAO のメンバーですか?これで、Optimism のアカウントを取得できました。 ZkSync のステーブルコイン システムで CDP を保有していますか?これで、ZkSync のアカウントを取得できました。カカロットにあるアプリをいくつか試してみましたか？これでカカロットのアカウントができました！ユーザーが 1 つのアドレスしか持てなかった時代は終わりました。
Brave Wallet の見解によると、私は 4 か所に ETH を保有しています。はい、Arbitrum と Arbitrum Nova は異なります。心配しないでください。これは時間の経過とともにさらに複雑になります。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
スマート コントラクト ウォレットではさらに複雑さが増し、L1 とさまざまな L2 で同じアドレスを持つことがより困難になります。現在、ほとんどのユーザーは外部所有のアカウントを使用しており、そのアドレスは実際には署名の検証に使用される公開キーのハッシュであるため、L1 と L2 の間では何も変わりません。ただし、スマート コントラクト ウォレットでは、アドレスを維持することがより困難になります。ネットワーク全体でアドレスをコードのハッシュと同等にするために多くの作業が行われてきましたが、特に CREATE2 や ERC-2470 シングルトン ファクトリでは、これを完全に行うことは非常に困難でした。一部の L2 (「タイプ 4 ZK-EVM」など) は EVM と完全に同等ではなく、通常は代わりに Solidity または中間アセンブリを使用し、ハッシュの同等性を妨げます。たとえハッシュの等価性が得られたとしても、キーの変更によってウォレットの所有権が変更される可能性は、他の非直観的な結果をもたらします。
プライバシーを確保するには、ユーザーごとにさらに多くのアドレスが必要であり、処理するアドレスの種類が変更される場合もあります。プライベート アドレスの提案が広く使用されている場合は、ユーザーごとにいくつかのアドレス、または L2 ごとに 1 つのアドレスを持つ代わりに、トランザクションごとに 1 つのアドレスが存在する可能性があります。他のプライバシー スキームは、Tornado Cash のような既存のものであっても、資産の保存方法を異なる方法で変更します。つまり、多くのユーザーの資金が同じスマート コントラクト (したがって同じアドレス) に保存されます。特定のユーザーに資金を送金するには、ユーザーはプライバシー スキーム独自の内部アドレス システムに依存する必要があります。
これまで見てきたように、3 つのシフトは「1 ユーザー ~= 1 アドレス」というメンタル モデルをさまざまな方法で弱体化させ、これらの影響の一部はシフトの実装の複雑さにフィードバックされました。 2 つの特別な合併症は次のとおりです。
誰かにお金を払いたい場合、支払うための情報をどうやって入手しますか?
ユーザーがさまざまなチェーンのさまざまな場所に多くの資産を保存している場合、キーの交換とソーシャル リカバリをどのように実行しますか?
3 つの移行はオンチェーン決済 (およびアイデンティティ) に関連しています
私は Scroll にコインを持っているので、コーヒーの代金を支払いたいと思っています (「私」が文字通りこの記事の著者として私を指している場合、「コーヒー」はもちろん「緑茶」の換喩です)。コーヒーを売ってくれますが、Taiko でコインを受け取るだけです。私は何をしますか？
基本的に、解決策は 2 つあります。
受け取り側のウォレット (販売者または単なる個人の可能性があります) は、資金を非同期に統合するための自動機能を備え、各 L2 をサポートするよう努めます。
受信者は自分の L2 とそのアドレスを提供し、送信者のウォレットはある種の L2 間ブリッジ システムを通じて自動的に資金をターゲット L2 にルーティングします。
もちろん、これらのソリューションは組み合わせることができます。受信者は受け入れたい L2 リストを提供し、送信者のウォレットは支払いを計算します。これには、直接送信するか (運が良ければ)、L2 を介したブリッジ パス経由で送信することも含まれます。
しかし、これは 3 つのシフトによってもたらされる重要な課題の一例にすぎません。誰かにお金を支払うという単純なことでも、単なる 20 バイトのアドレス以上の情報が必要になり始めます。
幸いなことに、スマート コントラクト ウォレットへの切り替えにより、アドレス システムにはそれほど負担がかかりませんでしたが、アプリケーション スタックの他の部分で対処する必要がある技術的問題がまだいくつかあります。ウォレットは、トランザクションで 21000 ガスを送信するだけでなく、より重要なことに、ウォレットの支払い受信側が EOA からの ETH 送金だけでなく、スマート コントラクト コードによって送信された ETH も追跡するように更新する必要があります。アドレスの不変の所有権の前提に依存するアプリケーション (ロイヤルティを強制するスマートコントラクトを禁止する NFT など) は、目標を達成するために別の方法を見つける必要があります。スマート コントラクト ウォレットにより、いくつかの作業が簡単になります。特に、非 ETH ERC20 トークンのみを受け入れる場合、ERC-4337 支払者を使用してそのトークンでガス代を支払うことができるようになります。
一方で、プライバシーは、私たちがまだ実際には解決していない大きな課題を再び提示しています。オリジナルの Tornado Cash では内部送金がサポートされていなかったため、これらの問題は発生しませんでした。ユーザーはシステムへの入金と引き出しのみが可能でした。内部転送が可能になったら、ユーザーはプライバシー システムの内部アドレス スキームを使用する必要があります。実際には、ユーザーの「支払いメッセージ」には、(i) 受信者が支払いに使用できる秘密の約束である、ある種の「支払い公開キー」、および (ii) 送信者は、ユーザーのみが使用できる暗号化されたメッセージを送信する必要があります。受信者は、受信者が支払いを発見できるように復号化することができます。
プライバシー アドレス プロトコルは、次のように機能するメタアドレスの概念に依存しています。メタアドレスの一部は送信者の支出キーのブラインド バージョンであり、他の部分は送信者の暗号化キーです (ただし、実装は最小限です)。これを設定できます（両方のキーは同じです）。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
ここでの重要な教訓は、プライバシーを重視したエコシステムでは、ユーザーは支出用の公開キーと暗号化用の公開キーを持ち、ユーザーの「支払い情報」には両方のキーが含まれている必要があるということです。支払い以外にも、この方向に拡大する正当な理由は他にもあります。たとえば、イーサリアムで暗号化された電子メールが必要な場合、ユーザーは何らかの形式の暗号化キーを公的に提供する必要があります。 「EOA の世界」では、これを達成するためにアカウント キーを再利用できますが、安全なスマート コントラクト ウォレットの世界では、おそらくこれを達成するためのより明示的な機能が必要です。これは、イーサリアムベースのアイデンティティと非イーサリアム分散型プライバシーエコシステム（最も顕著な例は PGP キー）との互換性を高めるのにも役立ちます。
3 つの変換とキーの回復
ユーザーが複数のアドレスを持つ可能性がある世界では、主要な変更とソーシャル リカバリを実装するデフォルトの方法は、ユーザーが各アドレスに対して個別にリカバリ手順を実行することです。これはワンクリックで実行できます。ウォレットには、すべてのユーザーのアドレスに対して回復手順を同時に実行するソフトウェアを含めることができます。ただし、このような UX の簡素化を行ったとしても、単純なマルチアドレス回復には 3 つの問題があります。
これらの問題を解決するのは困難です。幸いなことに、非常にうまく機能するエレガントなソリューションがあります。それは、検証ロジックを資産保持から分離するアーキテクチャです。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
各ユーザーは、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 が 1 つのブロック内のすべてのクロスチェーン状態証明を検証できるようになります。
KZG の取り組み。 L2、またはその上に構築されたスキームは、このシステム内の状態証明の長さをわずか 48 バイトにすることを可能にするシーケンシャル アドレッシング システムを導入できます。 ZK-SNARK と同様に、マルチプルーフ スキームでは、これらすべてのプルーフをブロックごとに 1 つのプルーフに結合できます。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
トランザクションごとに証明を行うことを避けたい場合は、より軽量なソリューションを実装できます。回復時にクロス L2 証明を実行するだけで済みます。アカウントからの支出は、対応する公開キーがアカウントに保存されている支出キーに依存しますが、回復にはキーストア内の現在の支出公開キーをコピーするトランザクションが必要になります。古い鍵がそうでない場合でも、反事実アドレス内の資金は安全です。反事実アドレスを「アクティブ化」して有効な契約に変えるには、現在使用している公開鍵を複製するクロス L2 証明を実行する必要があります。 Safe フォーラムのこのスレッドでは、同様のアーキテクチャがどのように機能するかを説明しています。
このようなスキームにプライバシーを追加するには、ポインターを暗号化してから、ZK-SNARK ですべての証明を行うだけです。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
さらに作業を進めると (たとえば、この作業を開始点として使用するなど)、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 状態の検索と検証が自動的に行われます。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
実際にプルーフを取得するには、コントラクトに保存されている一連の URL にアクセスする必要があり、確かに集中管理のように感じられますが、実際にはそうではないと私は主張します。これは 1-of-N 信頼モデルです (無効なプルーフは CCIP によってブロックされます)。コントラクトのコールバック関数のロジックは、有効な証拠を返す URL が存在する限り問題がないことをキャプチャします）。この URL リストには、数十の URL が含まれる場合があります。
ENS CCIP の取り組みは成功例であり、私たちが必要としているような抜本的な改革が可能であるという兆候と見なされるべきです。しかし、アプリケーションレベルのさらなる改革が必要です。例としては次のようなものがあります。
多くの dapp は、オフチェーン署名の提供をユーザーに依存しています。外部所有アカウント (EOA) の場合は簡単です。 ERC-1271 は、スマート コントラクト ウォレットがこれを行うための標準化された方法を提供します。ただし、多くの dapps はまだ ERC-1271 をサポートしていないため、サポートする必要があります。
「これは EOA ですか?」を使用してユーザーと契約を区別する (例: 移転の防止やロイヤルティの強制など) Dapps は機能しなくなります。一般に、純粋に技術的な解決策を見つけようとしないことをお勧めします。暗号化管理の特定の移転が受益権移転であるかどうかを判断するという問題は、オフチェーン コミュニティに頼らなければ解決できない可能性がある難しい問題です。駆動機構。次に解決します。おそらく、アプリケーションは転送のブロックよりもむしろハーバーガー税のような技術に依存する必要があるでしょう。
ウォレットが支出や暗号化キーとどのように相互作用するかを改善する必要があります。現在、ウォレットは通常、決定論的な署名を使用してアプリケーション固有のキーを生成します: 標準のノンス (アプリケーション名のハッシュなど) が EOA の秘密鍵で署名され、秘密鍵なしでは生成できないノンスが生成されます。のなので、技術的には安全です。ただし、これらの手法はウォレットに対して「不透明」であるため、ウォレットがユーザー インターフェイス レベルのセキュリティ チェックを実装することができません。より成熟したエコシステムでは、署名、暗号化、および関連機能はウォレットによってより明示的に処理される必要があります。
ライトクライアント (Helios など) は、L1 だけでなく L2 を検証する必要があります。現在、ライト クライアントは、(ライト クライアント同期プロトコルを使用して) L1 ヘッダーの有効性をチェックし、L1 ヘッダーから発生するトランザクションの L1 状態とマークル フォークを検証することに重点を置いています。明日は、L1 に保存されている状態ルートに由来する L2 状態の証明も検証する必要があります (このより高度なバージョンでは、実際には L2 の事前確認を検討します)。
ウォレットは資産とデータを保護する必要があります
さて、ウォレットの役割は資産を保護することです。すべてがオンチェーン上にあり、ウォレットが保護する必要があるのは、現在それらの資産を保護している秘密鍵だけです。キーを変更すると、翌日には以前の秘密キーをインターネット上で安全に公開できます。しかし、ゼロ知識証明の世界では、これは当てはまりません。ウォレットは認証資格情報を保護するだけでなく、データも保護します。
私たちは、Zuzalu で使用されている ZK-SNARK ベースの ID システムである Zupass で、そのような世界の最初の兆候を確認しました。ユーザーはシステムの認証に使用する秘密キーを持っており、「私がズザルの居住者であることを証明するが、どの居住者であるかは明らかにしない」などの基本的な証明を行うために使用できます。ただし、Zupass システムは、その上に他のアプリケーション、特にスタンプ (POAP の Zupass バージョン) も構築され始めました。
私が Team Cat の誇り高きメンバーであることを証明する、たくさんある Zupass スタンプの 1 つ。
POAP 上でスタンプが提供する主な機能は、スタンプがプライベートであることです。データはローカルに保持され、スタンプ (またはその計算) を証明するのは、自分に関する情報を相手に知らせたい場合のみです。ただし、これによりリスクが増大します。この情報を紛失すると、スタンプが失われることになります。
もちろん、データの保持の問題は、結局は暗号キーの保持の問題に帰結します。つまり、サードパーティ (またはチェーン) がデータの暗号化されたコピーを保持する可能性があります。これには、実行するアクションによって暗号化キーが変更されないため、暗号化キーを安全に保管するシステムとの対話が必要ないという便利な利点があります。しかし、それでも、暗号化キーを紛失すると、すべてが失われます。逆に、誰かがあなたの暗号化キーを見た場合、そのキーで暗号化されたすべてのものを見ることができます。
Zupass の事実上の解決策は、すべてのキーを同時に紛失する可能性は低いため、複数のデバイス (ラップトップや携帯電話など) にキーを保存することを人々に奨励することです。さらに一歩進んで、秘密共有を使用してキーを保存し、キーを複数のガーディアンに分割することができます。
MPC を介したこの社会的回復は、現在の後見人だけでなく、以前の後見人も共謀してあなたの資産を盗む可能性があり、これは容認できない高いリスクであるため、ウォレットにとって適切な解決策ではありません。ただし、プライバシーの侵害は、通常、資産の完全な損失よりもリスクが低く、高度にプライバシーを保護するユースケースが必要な場合は、プライバシーを必要とする関連キーをバックアップしないことで、損失のより高いリスクを受け入れることができます。アクションを保存すること。
複数の回復パスの複雑なシステムでユーザーが圧倒されるのを避けるために、ソーシャル回復をサポートするウォレットは、資産回復と暗号鍵回復の両方を管理する必要がある場合があります。
アイデンティティの質問に戻る
これらの変更の共通テーマは、「あなた」を表す暗号化識別子としてオンチェーンで使用する「アドレス」の概念を根本的に変える必要があるということです。 「私と対話する方法に関する指示」はもはや単なる ETH アドレスではなく、複数の L2 上の複数のアドレスの組み合わせ、秘密のメタ アドレス、暗号化キー、その他のデータが何らかの形式で含まれている必要があります。
これを行う 1 つの方法は、ENS を自分のアイデンティティにすることです。ENS レコードにはこれらすべての情報を含めることができ、誰かに bob.eth (または bob.ecc.eth など) を送信すると、相手は次の情報を調べて知ることができます。より複雑な分野横断的な方法やプライバシー保護の方法など、支払いやユーザーとのやり取りに関わるすべてのこと。
ただし、この ENS 中心のアプローチには 2 つの弱点があります。
考えられる解決策の 1 つは、この記事の前半のアーキテクチャで述べたキーストア コントラクトにさらに多くのものを組み込むことです。キーストア コントラクトには、ユーザーに関するさまざまな情報と、キーストア コントラクトとの対話方法 (CCIP を介して、一部はオフチェーンである可能性があります) を含めることができ、ユーザーはキーストア コントラクトを主要な識別子として使用できます。ただし、実際に受け取った資産はさまざまな場所に保管されます。キーストア コントラクトは名前に束縛されず、反事実に優しいものです。いくつかの固定初期パラメーターを使用したキーストア コントラクトによってのみ初期化できるアドレスを生成できます。
別のカテゴリのソリューションは、ユーザー指向のアドレスの概念を放棄することに関係しており、これはビットコイン支払いプロトコルと精神的に似ています。 1 つのアイデアは、送信者と受信者の間の直接通信チャネルにもっと依存することです。たとえば、送信者は請求リンクを (明示的な URL または QR コードとして) 送信し、受信者はそれを使用して支払いを希望どおりに受け入れることができます。
![Vitalik: 大規模な実装を実現するには、イーサリアムは L2、ウォレット、プライバシーという 3 つの変革を経る必要があります] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
最初に行動するのが送信者であっても受信者であっても、ウォレットにさらに依存して最新の支払い情報をリアルタイムで直接生成することで、摩擦が軽減されます。そうは言っても、永続的な識別子は便利です (特に ENS の場合)。実際には、送信者と受信者間の直接通信を想定するのは非常に難しい問題であるため、さまざまなテクノロジの組み合わせを検討するかもしれません。
これらすべての設計において、物事を分散化し、ユーザーにとって理解しやすいものにすることが重要です。ユーザーが現在の資産の最新ビューや、ユーザー向けに公開された情報に簡単にアクセスできるようにする必要があります。これらのビューは、独自のソリューションではなくオープン ツールに依存する必要があります。開発者が何が起こっているのかを理解し、新しい環境に適応させるために、より複雑な決済インフラが不透明な「抽象化の塔」にならないようにするには、大変な努力が必要です。課題にもかかわらず、イーサリアムのスケーラビリティ、ウォレットのセキュリティ、一般ユーザーのプライバシーを実現することが最も重要です。それは技術的な実現可能性だけではなく、平均的なユーザーにとっての実際のアクセシビリティも重要です。私たちはこの課題に対処する必要があります。
Dan Finlay、Karl Floersch、David Hoffman、および Scroll チームと SoulWallet チームのフィードバック、レビュー、提案に心より感謝いたします。