著者: Vitalik Buterin 編集: Vernacular Blockchain

3 つのシフトに関する前回の記事で、エコシステム スタックの必要な基本機能として、L1 + クロス L2 サポート、ウォレット セキュリティ、プライバシーについて明確に考え始めることが重要である主な理由のいくつかを概説しました 物事はプラグインとして構築されます1 つの財布で個別にデザインできます。

この投稿では、L2 から L1、L1 から L2、または別の L2 から L2 をより簡単に読み取る方法など、特定のサブ問題の技術的側面に直接焦点を当てます。この問題に対処することは、アセット/キーストア分離アーキテクチャを有効にするために重要ですが、他の分野でも貴重なユースケースがあり、最も顕著なのは、 L1 と L2 の間でアセットを移動するようなユースケースを含む、信頼性の高いクロス L2 コール チェーンの最適化です。 この記事のカタログ 目標は何ですか? クロスチェーンの証明はどのようなものですか? どのような証明スキームを使用できるでしょうか? マークル証明 ZKスナーク 専用のKZG証明書 バークルツリープルーフ 重合 ステータスを直接読み取る L2 はどのようにして最新のイーサリアム状態ルートを学習しますか? 非 L2S チェーン上のウォレット プライバシー保護 要約する

＃＃１．目標は何でしょうか？

L2 が主流になると、ユーザーは複数の L2、場合によっては L1 にわたって資産を所有するようになります。スマート コントラクト ウォレット (マルチシグ、ソーシャル リカバリなど) が主流になると、特定のアカウントにアクセスするために必要なキーは時間の経過とともに変化し、古いキーは有効である必要がなくなります。これら 2 つのことが起こると、ユーザーは非常に多くのトランザクションを行わずに、さまざまな場所にある多数のアカウントにアクセスできるキーを変更する方法が必要になります。 特に、事実に反するアドレス、つまりオンチェーン上にいかなる形でも「登録」されていないものの、資金を安全に受け取って保持する必要があるアドレスに対処する方法が必要です。私たちは皆、事実に反するアドレスに依存しています。初めてイーサリアムを使用するとき、オンチェーンにアドレスを「登録」しなくても、誰かがあなたへの支払いに使用できる ETH アドレスを生成できます (これには送信手数料を支払う必要があるため、すでにいくらかの ETH を保持しています)。 EOA の場合、すべてのアドレスは事実に反するアドレスで始まります。スマート コントラクト ウォレットでは、特定のハッシュに一致するコードを持つスマート コントラクトによってのみ埋められる ETH アドレスを持つことができる CREATE2 のおかげで、依然として事実に反するアドレスが可能です。

EIP-1014 (CREATE2) アドレス計算アルゴリズム

ただし、スマート コントラクト ウォレットには、アクセス キーが変更される可能性があるという新たな課題が生じます。このアドレスは initcode のハッシュであり、ウォレットの初期検証キーのみを含めることができます。現在の検証キーはウォレットのストレージに保存されますが、そのストレージの記録が魔法のように他の L2 に伝播されることはありません。 ユーザーが多くの L2 上に多数のアドレスを持っており、その中にはユーザーがいる L2 に知られていないアドレス (事実に反しているため) も含まれる場合、ユーザーがキーを変更できるようにする方法は 1 つだけであるように見えます。それは、アセット/キーストア分離アーキテクチャです。各ユーザーは、(i) すべてのウォレットの検証キーとキー変更のルールを保存する「キーストア コントラクト」 (L1 または 1 つの特定の L2 のいずれか)、および (ii) チェーン全体で検証キーを読み取る「ウォレット コントラクト」を持っています。

これを実現するには 2 つの方法があります。

軽量バージョン (更新されたキーのみをチェックする): 各ウォレットは検証キーをローカルに保存し、キーストアの現在の状態のクロスチェーン証明をチェックし、ローカルに保存されている検証キーを一致するように更新するために呼び出すことができる関数を含みます。ウォレットが特定の L2 で最初に使用されるとき、この関数を呼び出してキーストアから現在の認証キーを取得する必要があります。 -長所: クロスチェーンプルーフは控えめに使用されるため、クロスチェーンプルーフが高価であっても問題ありません。すべての資金は現在のキーでのみ使用できるため、安全に保たれます。

• 欠点: 検証キーを変更するには、キーストアと初期化されたすべてのウォレット (ただし、反事実的なウォレットではありません) でオンチェーンキーの変更を行う必要があります。これには多額のガソリン代がかかる可能性があります。 ヘビー バージョン (すべての送信をチェック): すべてのトランザクションには、キーストア内の現在のキーを示すクロスチェーン証明が必要です。
• 長所: システムの複雑さが軽減され、キーストアの更新が安価になります。
• 短所: 単一の送信は高価であるため、クロスチェーン証明をより安価にするには、より多くのエンジニアリングが必要です。また、ERC-4337 との互換性も容易ではありません。ERC-4337 は現在、検証中にコントラクト間で可変オブジェクトを読み取ることをサポートしていません。

2. クロスチェーン証明とはどのようなものですか?

完全な複雑さを示すために、最も困難なケースである、ある L2 にキーストア、別の L2 にウォレットを検討します。ウォレットのキーストアが L1 にある場合、この設計の半分だけが必要です。

キーストアが Linea にあり、ウォレットが Kakarot にあると仮定します。ウォレット キーの完全な証明には次のものが含まれます。

• カカロットに知られている現在のイーサリアム状態ルートを考慮した、現在のリネア状態ルートの証明
• 現在の Linea 状態のルートを考慮した、キーストア内の現在のキーの証明 ここには 2 つの主要な実装上の問題があります。
• どのような証拠を使用しますか? （それはメルケルの証拠ですか？何か別のものですか？）
• L2 は最初にどのようにして最も近い L1 (イーサリアム) 状態のルート (または、後で説明するように、おそらく完全な L1 状態) を学習しますか?あるいは、L1 はどのようにして L2 状態のルートを学習するのでしょうか? どちらの場合も、一方の側で起こったことと、もう一方の側で実証可能なことの間にはどれくらいの時間がかかりますか?

3. どのような種類の証明スキームを使用できますか?

主なオプションは 5 つあります。 -マークル証明 -ZK-SNARK全般

• 専用の証明 (例: KZG を使用) -Verkle は、インフラストラクチャのワークロードとコストの点で KZG と ZK-SNARKs の間にあることを示しています。
• 証明は必要ありません。状態の直接読み取りに依存します。 必要なインフラストラクチャ作業とユーザー コストの観点から、大まかに次のようにランク付けします。

「集約」とは、各ブロック内でユーザーが提供したすべてのプルーフを、すべてのプルーフを組み合わせた 1 つの大きなメタプルーフに集約することを指します。これは SNARK と KZG では可能ですが、Merkle フォークでは不可能です (Merkle フォークを少し組み合わせることもできますが、節約できるのはログ (ブロックあたりの TXS)/ログ (キーストアの総数) だけです。実際には、おそらく 15 ～ 30% です。真ん中なので、おそらく価格の価値はありません）。 集計はシナリオに多数のユーザーが含まれる場合にのみ価値があるため、実際にはバージョン 1 の実装で集計を省略し、バージョン 2 で実装できます。

4. マークル証明はどのように機能しますか?

これは簡単です。前のセクションの図に従うだけです。より正確には、各「証明」（ある L2 の最大難易度を別の L2 に証明する場合を想定）には次のものが含まれます。 L2 に知られているイーサリアムの最新のステート ルートを考慮した、キーストアを保持する L2 のステート ルートを証明するマークル ブランチ。キーストアは、既知のアドレスの既知のストレージ スロットに格納されている L2 の状態ルートを保持するため (L1 上のコントラクトは L2 を表します)、ツリーを通るパスをハードコーディングできます。 キーストアを保持する L2 の状態ルートを考慮した、現在の検証キーを証明するマークル ブランチ。ここでも、認証キーは既知のアドレスの既知のストレージ スロットに格納されるため、パスをハードコーディングできます。 残念ながら、イーサリアムの国家証明は複雑ですが、それを検証するためのライブラリが存在し、それらのライブラリを使用すれば、このメカニズムの実装はそれほど複雑ではありません。 **さらに大きな問題はコストです。 **マークル証明は非常に長く、残念ながらパトリシア ツリーは必要な長さよりも約 3.9 倍長くなります (正確に言うと、N 個のオブジェクトを保持するツリーの理想的なマークル証明は 32 * log2(N) バイトの長さです。イーサリアムのパトリシア ツリーは子ごとに 16 枚の葉があり、これらの木の証明は 32 * 15 * log16(N) ~= 125 * log2(N) バイト長です)。約 2 億 5,000 万 (~2²⁸) のアカウントがある州では、各証明は 125 * 28 = 3500 バイト、つまり約 56,000 ガスになり、さらにハッシュのデコードと検証の追加コストがかかります。 2 つの証明を合わせると、最終的に約 100,000 ガスから 150,000 ガスの費用がかかります (署名検証を除く、トランザクションごとに使用した場合)。これは、トランザクションごとの現在の基本価格 21,000 ガスよりもはるかに高くなります。ただし、証明が L2 で検証されると、不一致はさらに悪化します。 L2 内の計算はオフチェーンで、L1 よりもノード数がはるかに少ないエコシステムで実行されるため、低コストです。一方、データは L1 に公開する必要があります。つまり、比較は 21,000 ガス対 15,000 ガスではなく、21,000 L2 ガス対 100,000 L1 ガスです。 L1 ガスのコストと L2 ガスのコストを比較することで、これが何を意味するかを計算できます。

現在、L1 は単純な送信では L2 より 15 ～ 25 倍、トークン スワップでは 20 ～ 50 倍のコストがかかります。単純な送信は比較的データ量が大きくなりますが、やり取りの計算量はさらに多くなります。したがって、スワップは、L1 計算と L2 計算のおおよそのコストのより良いベンチマークとなります。これらすべてを考慮すると、L1 の計算コストと L2 の計算コストのコスト比が 30 倍であると仮定すると、L2 にマークル証明を配置するコストが通常のトランザクション 50 回に相当する可能性があることを意味しているようです。 もちろん、バイナリ マークル ツリーを使用すると、コストは最大 4 分の 1 に削減されますが、それでもほとんどの場合、コストは高すぎます。イーサリアムの現在の六角形ステート ツリーとの互換性を犠牲にするつもりがあるのであれば、より良い選択肢を。

5. ZK-SNARK証明はどのように機能しますか?

ZK-SNARK の使用も概念的に理解しやすいです。上の図のマークル証明を、それらのマークル証明の存在を証明する ZK-SNARK に置き換えるだけです。 ZK-SNARK は計算に約 400,000 GAS を必要とし、これには約 400 バイトが必要です (比較: 基本トランザクションには 21,000 ガスと 100 バイトが必要ですが、将来の Festival では圧縮後に約 25 ワードに削減される可能性があります)。したがって、計算の観点から見ると、ZK-SNARK のコストは今日の基本トランザクションのコストの 19 倍であり、データの観点から見ると、ZK-SNARK のコストは今日の基本トランザクションの 4 倍、16 倍になります。将来の基本トランザクション時間のコスト。 これらの数字はメルケルの証明よりも大幅に改善されていますが、それでもかなり高価です。これを改善するには 2 つの方法があります。(i) 特別な目的の KZG 証明、または (ii) ERC-4337 集計に似ていますが、より高度な数学を使用する集計です。私たちは両方を同時に勉強することができます。

6. 特殊用途の KZG 証明はどのように機能しますか?

警告、このセクションは他のセクションよりも数学的です。これは、私たちが汎用ツールを超えて、より安価な専用ツールを構築しているため、より「内部」に取り組む必要があるためです。複雑な数学が苦手な場合は、そのまま次のセクションに進んでください。 まず、KZG コミットメントがどのように機能するかを要約します。 データから導出された多項式の KZG 証明を使用して、データのセット [D_1...D_n] を表すことができます。具体的には、多項式 P、ここで P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w ここで「一様根」、評価領域サイズ N の場合の wN = 1 の値です (これはすべて有限体で行われます)。 P に「コミット」するには、楕円曲線点 com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk を作成します。ここ： -G は曲線の生成点です。 -Pi は多項式 P の i 番目の係数です。 -Si は信頼できるセットアップの i 番目のポイントです P(z) = a を証明するには、商多項式 Q = (P - a) / (X - z) を作成し、コミットメント com(Q) を作成します。このような多項式を作成できるのは、P(z) が実際に a に等しい場合のみです。 証明を検証するには、証明 com(Q) と多項式コミットメント com(P) に対して楕円曲線チェックを実行して、方程式 Q * (X - z) = P - a をチェックします。 e(com(Q) をチェックします。 )、com( X - z)) ? = e(com(P) - com(a), com(1)) 知っておくべき重要なプロパティには次のようなものがあります。

• 証明は com(Q) 値 (48 バイト) だけです -com（P₁） + com（P₂） = com（P₁ + P₂） これは、値を既存のコントラクトに「編集」できることも意味します。 D_i が現在 a であることが分かっているので、これを b に設定したいとします。また、D に対する既存のコミットメントが com(P) であるとします。 「P、ただし P(wⁱ) = b、その他の評価は変更しない」と約束し、com(new_P) = com(P) + (ba)*com(Li) と設定します。ここで、Li は「ラグ ランゲリアン」です多項式」、wⁱ で 1、他の wj 点で 0 に等しくなります。 これらの更新を効率的に実行するために、各クライアントはラグランジュ多項式 (com(Li)) に対する N 個のコミットメントをすべて事前計算して保存できます。オンチェーン コントラクトでは、N 個のコミットメントをすべて保存するには多すぎる可能性があるため、値の com(L_i) (または hash(com(L_i)) セットに対して KZG コミットメントを作成できます。誰かがオンチェーン ツリーを更新するときに、適切な com(L_i) にその正しさの証明を提供するだけで済みます。 したがって、ある程度のサイズ制限はありますが (実際には数億個も可能かもしれません)、増大するリストの末尾に値を追加し続けることができる構造になっています。次に、これをデータ構造として使用して、(i) L2 に保存され L1 にミラーリングされた各 L2 のキーのリストへのコミットメント、および (ii) イーサリアム L1 に保存され、L1 にミラーリングされた L2 キーコミットメント リストへのコミットメントを管理します。すべての L2 にミラーリングされます。 コミットメントを更新し続けることは、コア L2 ロジックの一部とすることも、L2 コア プロトコルを変更せずに入金および引き出しブリッジを介して実装することもできます。

したがって、完全な証明には次のことが必要です。

• キーストアは、L2 (48 バイト) 上の最新の com (キー リスト) を保持します。 -KZG は、com(キー リスト) が com(ミラー_リストの値) であることを証明し、すべてのキー リスト送信リスト (48 バイト) へのコミットメントを示します。 -KZG は、キーが com (キー リスト) にあることを証明します (48 バイトとインデックス用の 4 バイト) 実際には、2 つの KZG プルーフを 1 つに結合することができるため、合計サイズはわずか 100 バイトになります。 微妙な点に注意してください。キーリストはリストであり、状態のようなキーと値のマップではないため、キーリストには順番に位置を割り当てる必要があります。キー コミットメント コントラクトには、各キーストアを ID にマッピングする独自の内部レジストリが含まれます。また、キーごとに、キーストアがどの L2 と明示的に通信するために、キーだけではなくハッシュ (キーストアのアドレス) が保存されます。特定のエントリが話題になっています。 この手法の利点は、L2 で非常に優れたパフォーマンスを発揮することです。データは 100 バイトで、ZK-SNARK よりも約 4 倍短く、マークル証明よりも短いです。計算コストは主に 1 ペアの小切手、または約 119,000 ガスです。 L1 では、データは計算ほど重要ではないため、残念ながら KZG はマークル証明よりも少し高価です。

＃＃７．バークルツリーはどのように機能しますか？

Verkle ツリーには基本的に、KZG コミットメント (または、より効率的でより単純な暗号化を使用できる IPA コミットメント) の積み重ねが含まれます。2⁴⁸ 値を保存するには、2²⁴ 値のリストに対する KZG コミットメントを作成します。それぞれの値自体が、次に対する KZG コミットメントになります。 2²⁴ 値。 Verkle ツリーは、リストだけでなくキーと値のマッピングを保持するために使用できるため、Ethereum の状態ツリーとして強く考慮されています (基本的に、サイズ 2²⁵⁶ のツリーを作成できますが、空から始めることができます。実際にそれらを埋める必要がある場合は、ツリーを作成します)。

ビッカーツリーはどのように見えるか。実際、各ノードに IPA ベースのツリーの場合は 256 == 2⁸ の幅を、KZG ベースのツリーの場合は 2²⁴ の幅を与えることができます。 Verkle ツリーの証明は KZG よりも若干長く、長さは数百バイトになる場合があります。また、特に多くの証明を 1 つに集約しようとする場合、検証することも困難です。 実際、Verkle ツリーは Merkle ツリーと同様に考慮されるべきですが、SNARK なしの方が (データ コストが低いため) 実現可能であり、SNARK の方が安価です (証明コストが低いため)。 Verkle ツリーの最大の利点は、データ構造を調整できることです。Verkle 証明は L1 または L2 状態に直接使用でき、重ね合わせ構造がなく、L1 と L2 にまったく同じメカニズムを使用します。量子コンピューターが問題になるか、マークル分岐が十分に効率的であることが証明されたら、バークル ツリーを SNARK に適した適切なハッシュ関数を備えたバイナリ ハッシュ ツリーに置き換えることができます。

8. 集合体

N 人のトランザクションを実行する N 人のユーザー (より現実的には、N 個の ERC-4337 UserOperations) が N 個のクロスチェーン クレームを証明する必要がある場合、これらの証明を集約して、これらのトランザクションをブロックまたはバンドルのビルダーに結合することで、多額の費用を節約できます。ブロックに入力すると、これらすべての主張を同時に証明する証拠を作成できます。 これは次のことを意味します:

• N Merkle 分岐の ZK-SNARK 証明
• KZGマルチプルーフ
• Verkle マルチプルーフ (またはマルチプルーフ ZK-SNARK) 3 つのケースすべてにおいて、各証明に必要なガスは数十万ガスのみです。ビルダーは、各 L2 でその L2 内のユーザーに対してこれらのいずれかを作成する必要があります。したがって、構築を容易にするために、通常、複数の主要な L2 取引の同じブロックに少なくともいくつかのトランザクションが存在するようにスキーム全体を十分に使用する必要があります。 。 ZK-SNARK を使用する場合、主な限界費用は契約間で番号を渡す「ビジネス ロジック」にすぎないため、各ユーザーには数千の L2 ガスが必要になる可能性があります。 KZG マルチプルーフを使用する場合、証明者はブロック内で使用される L2 を保持するキーストアごとに 48 ガスを追加する必要があるため、ユーザーあたりのスキームの限界コストは (ユーザーごとではなく) L2 あたりになり、その後、最大 800 の L1 ガスが追加されます。 。ただし、これらのコストは、ユーザーごとに必然的に 10,000 以上の L1 ガスと数十万の L2 ガスが必要となる集約を行わない場合よりもはるかに低くなります。 Verkle ツリーの場合、Verkle マルチプルーフを直接使用してユーザーごとに約 100 ～ 200 バイトを追加することも、Verkle マルチプルーフの ZK-SNARK を作成することもできます。コストは Merkle からフォークされた ZK-SNARK と同様ですが、証明コストがかかります。はるかに低いです。 実装の観点から見ると、バンドラーにとっては、ERC-4337 アカウント抽象化標準を通じてクロスチェーン証明を集約する方が良いでしょう。 ERC-4337 には、ビルダーがユーザー アクションの一部をカスタム方法で集約するメカニズムがすでに組み込まれています。 BLS シグネチャ集約の実装もあり、含まれる他の形式の圧縮に応じて、L2 のガスコストを 1.5 ～ 3 分の 1 に削減できます。

BLS ウォレット実装投稿の図。ERC-4337 の初期バージョンにおける BLS 集約署名のワークフローを示しています。クロスチェーンプルーフを集約するワークフローは非常に似ているかもしれません。

9. ステータスの直接読み取り

最後の可能性は、これも L1 を読み取る L2 (L2 を読み取る L1 ではない) でのみ利用可能ですが、L1 上のコントラクトへの静的呼び出しを直接行うように L2 を変更することです。 これは、オペコードまたはプリコンパイルを使用して実行できます。これにより、L1 への呼び出しが可能になり、ターゲット アドレス、ガス、呼び出しデータを指定すると、出力が返されます。ただし、これらの呼び出しは静的であるため、実際には L1 の状態を変更することはできません。 L2 は、L1 がすでにデポジットを処理していることを認識する必要があるため、そのような実装を妨げるものはまったくありません。これは主に技術的な実装の課題です (L1 への静的呼び出しをサポートするための楽観的な RFP からのこれを参照)。 キーストアが L1 上にあり、L2 が L1 静的呼び出しを統合する場合、アテステーションはまったく必要ないことに注意してください。ただし、L2 が L1 静的呼び出しを統合していない場合、またはキーストアが L2 にある場合 (L1 が高価すぎてユーザーが少しでも使用できないようになると、最終的には統合しなければならない可能性があります)、証明が必要になります。

10. L2 はどのようにして最新の Ethereum 状態ルートを学習するのでしょうか?

上記のスキームはすべて、L2 が最も近い L1 状態ルートまたは最も近い L1 状態全体にアクセスすることを必要とします。幸いなことに、すべての L2 には、最新の L1 状態にアクセスするための機能がすでに備わっています。これは、L1 から L2 へのメッセージ、特にデポジットを処理するためにそのような機能が必要であるためです。 実際、L2 にデポジット関数がある場合、その L2 をそのまま使用して、L1 ステート ルートを L2 上のコントラクトに移動できます。L1 上のコントラクトで BLOCKHASH オペコードを呼び出し、それをデポジット メッセージとして L2 に渡すだけです。 。フルブロックヘッダーは L2 側で受信され、その状態ルートが抽出されます。しかしながら、各Ｌ２は、完全な最新のＬ１状態または最も近いＬ１状態ルートに直接アクセスするための明示的な方法を有することが好ましい。 L2 が最新の L1 状態ルートを受信する方法を最適化する際の主な課題は、セキュリティと低遅延を同時に実現することです。

• L2 が遅延方式で「L1 の直接読み取り」機能を実装し、最終的な L1 状態ルートのみを読み取る場合、遅延は通常 15 分ですが、非アクティブなリークが発生した極端なケース (これは許容する必要があります) では、遅延が 15 分になる可能性があります。数週間。
• L2 は更新された L1 状態ルートを読み取るように設計できますが、L1 は回復できるため (単一ソケットのファイナリティでも非アクティブなリーク中に発生します)、L2 も同様に回復できる必要があります。ソフトウェア エンジニアリングの観点から見ると、これは技術的に困難ですが、少なくとも Optimistic にはその機能があります。
• デポジット ブリッジを使用して L1 ステート ルートを L2 に移動する場合、単純な経済学では、デポジットの更新の間に長い時間がかかる可能性があります。デポジットの全コストが 100,000 ガスの場合、ETH で 1800 ドル、手数料が 200 グウェイであると仮定します。 L1 ルートが 1 日に 1 回 L2 に入る場合、システムを維持するには 1 日あたり L あたり 236 ドル、または年間 L2 あたり 13,148 ドルの費用がかかります。 1 時間の遅延は、L2 あたり年間 315,569 ドルという莫大な費用がかかります。せいぜい、他の人のためにシステムをアップデートして最新の状態に保つために、せっかちな裕福なユーザーが絶えずお金を払っているということです。最悪の場合、一部の利他的な行為者は自らその費用を支払わなければならないだろう。
• 「オラクル」（少なくとも一部の DeFi 人々が「オラクル」と呼ぶテクノロジー）は、ここでは受け入れられる解決策ではありません。ウォレットのキー管理は非常にセキュリティクリティカルな低レベル機能であるため、多くてもいくつかの機能に依存する必要があります。暗号化の信頼を必要としない低レベルのインフラストラクチャ。 また、反対方向 (L1s は L2 と読みます):
• Optimistic Aggregation では、不正行為防止の遅延により、ステート ルートが L1 に到達するまでに 1 週間かかります。 ZK ロールアップでは、検証時間と経済的制約の組み合わせにより、現在では数時間かかりますが、将来のテクノロジーによりこれは短縮されるでしょう。
• 事前確認 (シーケンサー、認証者などからの) は、L1 読み取り L2 に対する許容可能なソリューションではありません。ウォレット管理は非常にセキュリティ クリティカルな低レベル機能であるため、L2 - L1 通信のセキュリティ レベルは絶対的でなければなりません。L2 バリデータ セットを引き継いで間違った L1 状態ルートをプッシュすることさえ不可能です。 L1 が信頼すべき唯一の状態ルートは、L1 上の L2 の状態ルート保持契約によって最終的な状態ルートとして受け入れられたものです。 多くの DeFi ユースケースでは、トラストレスなクロスチェーン操作では許容できないほど遅いものもあり、このようなケースでは、より不完全なセキュリティ モデルを備えたより高速なブリッジが実際に必要になります。ただし、ウォレットキーを更新するユースケースでは、トランザクションを何時間も遅らせるのではなく、キーの変更を遅らせるため、より長い遅延の方が許容されます。古いキーをより長く保持しておく必要があるだけです。キーが盗まれたためにキーを変更した場合、長期間にわたり脆弱性が残りますが、それは軽減することができます。凍結機能を備えたウォレット経由。 最終的に、遅延を最小限に抑える最善の解決策は、L2 に L1 ステート ルートの直接読み取りを最適に実装させることです。各 L2 ブロック (またはステート ルートの計算ログ) には最新の L1 ブロックへのポインターが含まれているため、L1 が回復した場合、L2回復することもできます。キーストア コントラクトは、L1 にすぐにコミットできるように、メインネットまたは ZK ロールアップの L2 に配置する必要があります。

L2 チェーンのブロックは、前の L2 ブロックだけでなく、L1 ブロックにも依存できます。このようなリンクを介して L1 が回復すると、L2 も同様に回復します。これは、以前の (Dank より前の) バージョンのシャーディングの動作が想定されていた方法でもあることに注目する価値があります。コードについては、ここを参照してください。

11. イーサリアムまたは L2 ウォレットにルートされたキーストアを保持するには、別のチェーンがイーサリアムにどれだけ接続する必要がありますか?

驚くべきことに、それほど多くはありません。実際にはロールアップである必要さえありません。L3 または検証の場合は、L1 または ZK ロールアップでキーストアを保持している限り、そこにウォレットを保持しても問題ありません。本当に必要なのは、イーサリアムの状態ルートに直接アクセスするためのチェーンと、イーサリアムが再編成される場合は再編成する意思があり、イーサリアムがハードフォークする場合はハードフォークするという技術的および社会的コミットメントです。 興味深い研究課題は、チェーンが他の複数のチェーン (イーサリアムや Zcash など) とこの形式の接続をどの程度持つことができるかを判断することです。これを単純に行うことは可能です。イーサリアムまたは Zcash が再編成される場合、チェーンは再編成 (イーサリアムまたは Zcash がハードフォークする場合はハードフォーク) に同意することができますが、ノードオペレーターとコミュニティには通常 2 倍の技術的および政治的依存関係があります。したがって、この技術を使用して他のチェーンに接続することもできますが、コストが増加します。 ZK ブリッジベースのスキームには魅力的な技術的特性がありますが、主な弱点は 51% 攻撃やハード フォークに対して堅牢ではないことです。もっと賢い解決策もあるかもしれません。

12. プライバシー保護

理想的には、プライバシーも保護したいと考えています。同じキーストアで管理されるウォレットが多数ある場合は、次のことを確認する必要があります。

• これらのウォレットがすべて相互に接続されているかどうかは明らかではありません。
• 社会更生保護者は、自分がどの住所を保護しているのか知りません。 これにより、いくつかの問題が発生します。
• マークル証明はプライバシーを保護しないため、直接使用することはできません。
• KZG または SNARK を使用する場合、証明では、検証キーの場所を明かさずに、ブラインド バージョンの検証キーを提供する必要があります。
• 集約を使用する場合、集約者は平文内の位置を学習すべきではなく、代わりに集約者はブラインド証明を受け取り、これらの証明を集約する方法を備えている必要があります。
• 「ライトバージョン」（クロスチェーン証明のみを使用してキーを更新する）は使用できません。プライバシー漏洩が発生するためです。更新プロセスにより多くのウォレットが同時に更新されると、時間の経過とともに、ウォレットに関連する可能性のある情報が漏洩します。この財布たち。 したがって、「ヘビーバージョン」（各トランザクションのクロスチェーン証明）を使用する必要があります。 SNARK を使用すると、解決策は概念的に単純です。デフォルトでは、証明は情報が隠蔽されており、アグリゲーターは SNARK を証明するために再帰的な SNARK を生成する必要があります。

このアプローチの現在の主な課題は、集約にはアグリゲーターが再帰的な SNARK を作成する必要があることですが、これは現在非常に遅いです。 KZG を使用すると、開始点としてインデックスなしの明らかに KZG 証明に関するこの作業 (コーク論文のこの作業のより正式なバージョンも参照) を使用できます。ただし、ブラインドプルーフの集計は未解決の問題であり、さらなる注意が必要です。 残念ながら、L2 内から L1 を直接読み取ることはプライバシーを保護しません。ただし、直接読み取り機能を実装することは、遅延を最小限に抑えるためと、他のアプリケーションでの有用性の両方の点で、依然として非常に役立ちます。

13. まとめ

クロスチェーンのソーシャル・リカバリ・ウォレットを実現するための最も現実的なワークフローは、キーストアを1つの場所で管理するウォレットと、複数の場所でウォレットを管理するウォレットです。ウォレットはキーストアを読み取って、(i) 認証キーをローカルで更新します。ビュー、または (ii) 各トランザクションの検証プロセス中。 これを可能にする重要な要素は、クロスチェーン証明です。これらの証明の最適化に取り組む必要があります。 ZK-SNARK または Verkle の証明を待つカスタム KZG ソリューションが最良の選択肢と思われます。 長期的には、コストを最小限に抑えるために、集約プロトコル (ユーザーが送信したすべてのユーザー アクションのバンドル作成の一環として、バンドラーが集約されたプルーフを生成する) が必要です。これはおそらく ERC-4337 エコシステムに統合されるべきですが、ERC-4337 への変更が必要になる可能性があります。 L2 は、L2 内から L1 状態 (または少なくとも状態ルート) を読み取る待ち時間を最小限に抑えるように最適化する必要があります。 L2 が L1 の状態を直接読み取り、証明スペースを節約するのが理想的です。 ウォレットは L2 上に配置できるだけでなく、イーサリアムへの接続レベルが低いシステム (L3、または単にイーサリアム状態のルートと独立したフォーク チェーンを含めることに同意するだけ) にウォレットを配置することもできます。 ただし、キーストアは L1 または高セキュリティ ZK ロールアップ L2 上にある必要があります。 L1 を使用すると複雑さが大幅に軽減されますが、それでも長期的にはコストが高すぎる可能性があるため、キーストアを L2 で使用する必要があります。 プライバシーを保護するには追加の作業が必要となり、特定の選択がより難しくなります。しかし、私たちはおそらく、とにかくプライバシー保護ソリューションに目を向けるべきであり、少なくとも私たちが思いついたものはすべてプライバシー保護と互換性があることを確認する必要があります。