実際、私たちは皆、アドレスのこの「偽りの設定」に依存しています。つまり、ユーザーが初めてイーサリアムを使用するとき、そのユーザーは ETH アドレスを生成でき、他のユーザーはブロックチェーンに登録することなくこのアカウントに支払うことができます。アドレス（ただし、取引手数料を支払う必要があるため、ある程度のETHを保持する必要があります）。
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
V God Blog: ウォレットとその他のアプリケーションケースについての理解 レイヤ 2 クロスレイヤの読み取り
著者: Vitalik Buterin、編纂者: Bulu 氏
記事 The Three Transitions の中で、イーサリアムの創設者ヴィタリック・ブテリンは、「メインネットワーク (以下、L1 と呼ぶ) + レイヤー 2 クロスチェーン (以下、クロス L2 と呼ぶ)」について明確に詳しく述べています。 「サポート」「ウォレットのセキュリティ」「プライバシー」は、エコシステムスタックに必要な機能として重要な値です。これらは単なる追加コンポーネントであるべきではなく、別のウォレットが関連する機能を提供します。
そして、この記事は重要な技術的問題、つまり、L2 から L1 データをより簡単に読み取る方法、L1 から L2 データを読み取る方法、または L2 から L2 データをより簡単に読み取る方法、別の L2 からデータを読み取る方法に焦点を当てていると Vitalik Buterin 氏は指摘しました。 。 **
Vitalik Buterin 氏は、上記の問題を解決する鍵は、アセットとキーストアの分離をどのように実現するかにあると指摘しました。このテクノロジーには、L1 と L2 間の資産のモビリティなど、スケーリング以外の分野でも非常に貴重なユースケースがあります。
**これを行う目的は何ですか? **
L2 が主流になると、ユーザーは複数の L2 上で資産を所有できるようになり、場合によっては L1 上でも資産を所有できるようになります。
スマートコントラクトウォレットが主流になると、現在一般的な「キー」は使用されなくなります。
これら 2 つのことが同時に発生すると、ユーザーは異なるアカウントのキーを変更するために大量のトランザクションを必要としない方法が必要になります。
特に、「反事実」のアドレス (「仮想アドレス」とも呼ばれる) に対処する方法が必要です。つまり、まだオンチェーンに「登録」されていないものの、資産を安全に受信して保持する必要があるアドレスです。 。
実際、私たちは皆、アドレスのこの「偽りの設定」に依存しています。つまり、ユーザーが初めてイーサリアムを使用するとき、そのユーザーは ETH アドレスを生成でき、他のユーザーはブロックチェーンに登録することなくこのアカウントに支払うことができます。アドレス（ただし、取引手数料を支払う必要があるため、ある程度のETHを保持する必要があります）。
外部アカウント (EOA) の場合、実際には、すべてのアドレスは「偽りの設定」のアドレスから始まります。
「事実に反して設定された」アドレスは、主に CREATE2 のおかげで、スマート コントラクト ウォレットで引き続き可能です。これにより、特定のハッシュ充填に一致するスマート コントラクト コードによってのみ作成できる ETH アドレスを持つことができます。
△ EIP-1014 (CREATE2) アドレス計算アルゴリズム。
ただし、スマート コントラクト ウォレットの導入は、次のような新たな課題ももたらします。 **アクセス キーは変更される可能性があります。 **この変更は、アドレスが initcode のハッシュ値であり、ウォレットの初期検証キーのみを含めることができ、現在の検証キーはウォレットのストレージに保存されますが、ストレージ レコードは保存されません。自動的に他の L2 に転送されます。
ユーザーが多くの L2 にアドレスを持っている場合、ユーザーがキーを変更できるのは 資産とキー ストレージ アーキテクチャの分離 だけです。
この分割アーキテクチャの構造は、各ユーザーが (i) すべてのウォレットの検証キーとキー変更のルールを保存する「キー ストレージ コントラクト」 (L1 チェーンまたは特定の L2 チェーンのいずれか)、および (ii) 「ウォレット コントラクト」を持っていることです。 「L1 チェーンと多くの L2 チェーンで、クロスチェーン読み取りを通じて検証キーを取得します。
資産とキーのストレージ分離アーキテクチャを実装するには、次の 2 つの方法があります。
軽量バージョン (つまり、更新されたキーのみをチェックします): 各ウォレットは検証キーをローカルに保存し、キーストアの現在の状態のクロスチェーン証明をチェックし、ローカル ストレージを更新するための呼び出し可能な関数を含みます。一致するキー。 L2 で初めてウォレットを使用する場合は、この関数を呼び出してキーストアから現在の認証キーを取得する必要があります。
フルバージョン (つまり、すべてのトランザクションがチェックされます): すべてのトランザクションには、キーストア内の現在のキーを示すクロスチェーン証明が必要です。
**クロスチェーンプルーフとは何ですか? **
クロスチェーン証明の複雑さを実証するために、この技術原則を実証および説明するために最も複雑なアプリケーション シナリオの 1 つを選択しました。この複雑なアプリケーション シナリオは次のとおりです: キーは 1 つの L2 に保存され、ウォレットは 1 つの L2 に保存されます。もう一つのL2。ウォレットのキーストアが L1 にある場合、この設計の半分だけが必要になります。
キーストアが Linea にあり、ウォレットが Kakarot にあると仮定します。ウォレット キーの完全な認証プロセスには次のものが含まれる必要があります。
ここには実装上で主に 2 つの厄介な問題があります。「どのような種類の証明を使用する必要があるか? (マークル証明ですか? それとも他のものですか?)」と「L2 はどのようにして最も近い L1 状態ルートを学習するのですか?」または「L1 はどのように学習するのですか?」 L2 の状態ルートを学習するには?」
では、どちらの場合も、一方の側で事件が発生してから他方の当事者が証拠を提出できるまでにどれくらいの時間がかかるのでしょうか?
**どのような証明スキームが利用可能ですか? **
選択できる主な方法は次の 5 つです。
*マークル証明
必要なインフラストラクチャ作業とユーザー コストの観点から、大まかに次のようにランク付けできます。
「集約」とは、各ブロックでユーザーが提供したすべてのプルーフを 1 つの大きなメタプルーフに集約し、マージすることを指します。これは SNARK と KZG では機能しますが、Merkle フォークでは機能しません。
実際、「集約」は、ソリューションに多数のユーザーが含まれる場合にのみ価値があります。 ♀️♀️♀️♀️♀️
**マークル証明はどのように機能しますか? **
この問題は非常に単純なので、前のセクションの図に直接従うことができます。それぞれの「証明」 (ある L2 が別の L2 であることが証明されると仮定します。これは最も困難なアプリケーション シナリオです) には次のものが含まれます。
L2 キーストアのステート ルート、つまり L2 に知られているイーサリアムの最新のステート ルートを保持していることを証明するマークル フォーク。 L2 キーストアを保持するステート ルートは、既知のアドレス (L2 を表す L1 契約) の既知のストレージ スロットに格納されるため、パスをハードコーディングできます。
L2 キーストアを保持するステート ルートに従って、現在の検証キーを証明するマークル ブランチ。また、認証キーは既知のアドレスの既知のスロットに保存されるため、パスをハードコーディングできます。
ただし、イーサリアムにおける状態証明は複雑ですが、それを検証できるライブラリがあり、それを使えば仕組みはそれほど複雑ではありません。
ただし、より大きな課題はコストです。 **マークルは非常に長いことが判明し、パトリシア ツリーは必要な長さの 3.9 倍でした。これは、トランザクションあたりの現在の基本価格である 21,000 ガス料金よりもはるかに高かったです。
ただし、証明が L2 で検証されると、不一致はさらに悪化します。 L2 内の計算はオフチェーンで、L1 よりもノード数が少ないエコシステムで実行されるため、低コストです。
これが何を意味するかは、L1 ガス料金コストと L2 ガス料金コストの比較から計算できます。
現在、比較的単純な送信動作であれば、L1ネットワークのコストはL2の15～25倍程度、Token交換のコストはL2の20～50倍程度となります。
単純な送信操作には大量のデータが含まれ、交換操作にはより高い計算能力が必要となるため、交換操作は L1 計算と L2 計算のコストを概算するためのより良いベンチマークです。
上記をまとめると、L1 の計算コストと L2 の計算コストのコスト比が 30 倍であると仮定すると、L2 にマークル証明を配置するコストが通常のトランザクション約 50 回に相当する可能性があることを意味しているようです。
もちろん、バイナリ マークル ツリーを使用するとコストは約 4 分の 1 に削減されますが、それでもほとんどの場合、コストは依然として法外なものになるでしょう。また、イーサリアムの現在のヘキサ ステート ツリーとの互換性を放棄するつもりであれば、それは可能性があります。より良い選択肢を探します。
**ZK-SNARK 証明はどのように機能しますか? **
ZK-SNARK の使用も概念的に理解しやすいです。上の図のマークル証明を、それらのマークル証明の存在を証明する ZK-SNARK に置き換えるだけです。 ZK-SNARK の計算量は約 400,000 Gas Fee、約 400 バイトで、基本トランザクションには 21,000 Gas Fee、約 100 バイトが必要です。
したがって、計算の観点から見ると、ZK-SNARK のコストは現在の基本トランザクション コストの 19 倍ですが、データの観点から見ると、ZK-SNARK のコストは現在の基本トランザクション コストの 4 倍、将来のトランザクション コストの 16 倍になります。基本的な取引コスト。
これらの数値はマークル証明に比べて大幅な改善を示していますが、それでもかなり高価です。 この状況を改善するには 2 つの方法があります。 (i) 特別な目的の KZG 証明、または (ii) ERC-4337 集約と同様の集約。
**特殊用途の KZG 証明はどのように機能しますか? **
まず、KZG Promise がどのように機能するかを要約します。
*[D_1 ...D_n] は、多項式 KZG 証明が導出されるデータのセットを表します。 *
*具体的には、多項式 P、P(w) = D_1、P(w²) = D_2 ... P(wⁿ) = D_n。ここでの w は、何らかの評価フィールドの「一様根」です。サイズ N、値 wN = 1 (これはすべて有限フィールドで行われます)。 *
G は曲線の生成点です
Pi は多項式 P の i 番目の係数です
Si は信頼できる設定の i 番目のポイントです
*そして、P(z) = a を証明するために、商多項式 Q = (P - a) / (X - z) を作成し、コミットメント com(Q) を作成します。このような多項式を作成できるのは、P(z) が実際に a に等しい場合のみです。 *
次のような重要なプロパティについても知っておく必要があります。
証明は 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) 値のセットに対して KZG コミットメントを作成できます。これにより、誰かがオンチェーンのツリーを更新する必要があるときはいつでも、 Proper com(L_i) に送信するだけで、その正当性が証明されます。 *
したがって、一定のサイズ制限を設けて、増加するリストの末尾に値を追加し続ける構造を用意します。次に、この構造を、(i) 各 L2 上のキーのリストへのコミットメント (その L2 に保存され L1 にミラーリングされる)、および (ii) L2 キーへのコミットメントのリストへのコミットメント（Ethereum に保存される）のデータ構造として使用します。 L1 と各 L2 にミラーリングされます。
コミットメントを更新し続けることは、コア L2 ロジックの一部とすることも、L2 コア プロトコルを変更せずに入金および出金ブリッジを介して実装することもできます。
完全な証明には次のものが必要です。
実際、上記の 2 つの KZG 証明は、合計サイズがわずか 100 バイトの 1 つに結合できます。
詳細に注意してください。キーリストはリストであり、状態のようなキーと値のマップではないため、キーリストには順番に位置を割り当てる必要があります。キー プロミス コントラクトには、各キーストアを ID にマッピングする独自の内部レジストリが含まれ、キーごとにキーだけではなくハッシュ (キー、キーストアのアドレス) を保存して、他の L2 に明示的に通知します。特定のエントリが参照するキーストア。
この手法の利点は、L2 で非常に優れたパフォーマンスを発揮することです。 ZK-SNARK よりも約 4 倍短く、マークル証明よりもはるかに短い。計算コストは約119,000ガス代となります。
L1 では、データよりもコンピューティング能力が重要であるため、KZG はマークル証明よりもわずかに高価です。
**バークルの木はどのように機能するのですか? **
Verkle ツリーには、基本的に KZG コミットメントを積み重ねることが含まれます。2⁴⁸ 値を格納するには、2²⁴ 値のリストに対して KZG コミットメントを作成できます。それぞれの値自体が 2²⁴ 値に対する KZG コミットメントになります。
Verkle ツリーはキーと値のマップを保持するために使用できるため、Verkle ツリーはイーサリアム状態ツリーとして考慮されます。
Verkle ツリーの証明は KZG 証明よりも長く、長さは数百バイトになる場合があります。
実際、Verkle ツリーは Merkle ツリーと同様に考慮されるべきですが、SNARKing なしの方がより実現可能ですが、SNARKing の方が証明コストが低いことが示されています。
Verkle ツリーの大きな利点は、データ構造を調整できることです。そのため、L1 または L2 に直接使用でき、重ね合わせ構造がなく、まったく同じメカニズムが L1 と L2 に使用されます。
量子コンピューターが問題になるか、マークル ブランチが十分に効率的であることが証明されれば、バークル ツリーの用途はさらに広がります。
重合
N 人のユーザーが N 個のトランザクションを実行し、N 個のクロスチェーン請求を証明する必要がある場合、これらの証明を集約することでガス料金を大幅に節約できます。これは次のことを意味します。
3 つのケースすべてにおいて、各証明にかかる費用は数十万のガス料金のみです。
開発者は、L2 のユーザーごとにそのような証明を 1 つ作成する必要があります。したがって、この証明が役立つためには、スキーム全体が少なくとも数回のトランザクションが存在するのに十分な使用量が必要です。
ZK-SNARK を使用する場合、各ユーザーは数千の L2 ガス料金を支払う必要がある場合があります。 KZG マルチプルーフが使用される場合、検証者はブロックで使用される各キーストアの L2 に 48 ガス料金を追加する必要があります。
それでも、これらのコストは、集約しない場合よりもはるかに低くなります。集約すると、ユーザーごとに 10,000 以上の L1 ガス料金と数十万の L2 ガス料金が必然的に発生します。
Verkle ツリーの場合、ユーザーは Verkle multi-proof を直接使用でき、各ユーザーは約 100 ～ 200 バイトを追加するか、Verkle multi-proof ZK-SNARK を実行できます。コストは Merkle ブランチの ZK-SNARK と同様です。しかしその証拠に明らかに安っぽく見えます。
実装の観点から見ると、バンドラーに ERC-4337 アカウント抽象化標準を介してクロスチェーン証明を集約させるのが最善かもしれません。 ERC-4337 には、ビルダーがユーザー操作の一部をカスタム方法で集約するメカニズムがすでに組み込まれています。 BLS シグネチャ集約の実装もあり、L2 ガス料金を 1.5 倍から 3 倍削減できます。
ステータスを直接読み取る
最後の可能性は、(L1 が L2 を読み取るのではなく) L2 が L1 を読み取る場合にのみ適用され、L1 のコントラクトに対して静的呼び出しを直接行うように L2 を変更することです。
これは、ターゲット アドレス、ガス、およびコールデータを指定する L1 への呼び出しを許可するオペコードまたはプリコンパイルを使用して実行でき、出力が返されます。ただし、これらの呼び出しは静的であるため、実際には L1 の状態を変更することはできません。デポジットを処理するには、L2 が L1 で何が起こっているのかを知る必要があるため、これを妨げる根本的な要因はなく、主に技術的な実装上の課題です。
キーストアが L1 上にあり、L2 に L1 の静的呼び出し機能が組み込まれている場合、認証はまったく必要ないことに注意してください。
ただし、L2 に L1 静的呼び出しが組み込まれていない場合、またはキーストアが L2 上にある場合は、証明が必要です。
**L2 はどのようにして最新のイーサリアム状態ルートを学習しますか? **
上記のスキームはすべて、L2 が最も近い L1 状態ルートまたは最も近い L1 状態全体にアクセスすることを必要とします。
実際、L2 にデポジット関数がある場合、その L2 をそのまま使用して、L1 ステート ルートを L2 上のコントラクトに移動できます。L1 上のコントラクトで BLOCKHASH オペコードを呼び出し、それをアセットとしてデポジットするだけです。メッセージが渡されます。 L2へ。フルブロックヘッダーは L2 側で受信され、その状態ルートが抽出されます。
しかしながら、各Ｌ２は、完全な最新のＬ１状態または最も近いＬ１状態ルートに直接アクセスするための明示的な方法を有することが好ましい。
L2 が最新の L1 状態ルートを受信する方法を最適化する際の主な課題は、セキュリティと低遅延を同時に実現することです。
また、反対方向 (L1 が L2 を読み取る):
それらの中には、多くの DeFi ユースケースにおけるトラストレスクロスチェーン操作では許容できないほど遅いものもあります。ただし、ウォレットキーを更新するユースケースでは、トランザクションを遅らせるのではなくキーの変更を遅らせるため、より長い遅延の方が許容されます。
ユーザーは古いキーを長期間保持するだけで済みます。キーが盗まれたためにユーザーがキーを変更した場合、確かに長期間にわたって脆弱性が残りますが、それは軽減することができます。凍結機能を備えたウォレット経由。
最終的に、遅延を最小限に抑える最善の解決策は、L2 に L1 ステート ルートの直接読み取りを最適に実装させることです。各 L2 ブロック (またはステート ルートの計算ログ) には最新の L1 ブロックへのポインターが含まれているため、L1 が回復した場合、L2回復することもできます。キーストア コントラクトは、L1 にすぐにコミットできるように、メインネットまたは ZK ロールアップの L2 に配置する必要があります。
**他のチェーンがイーサリアムまたは L2 ウォレットに保存されているキーストアを保持するには、イーサリアムへの接続がどのくらい必要ですか? **
驚くべきことに、それほど多くはありません。実際、ロールアップである必要さえありません。
L3 またはバリディウムの場合、そこにウォレットを保存しても問題ありません。ユーザーがキー ストレージを L1 または ZK ロールアップに保存している限り、ユーザーはイーサリアムのステート ルートに直接アクセスする必要があり、ウォレットをそこに保存することを望んでいます。イーサリアム リファクタリングの場合、イーサリアムがハードフォークする場合はハードフォークします。
ZK ブリッジベースのスキームには魅力的な技術的特性がありますが、51% 攻撃やハード フォークに対して堅牢ではないという重大な弱点があります。
プライバシー保護
理想的には、ユーザーはプライバシーも望んでいます。ユーザーが同じキーストアによって管理されるウォレットを多数所有している場合、次のことを確認する必要があります。
しかし、これでは問題が発生します。
※マークル証明はプライバシーが保護されないため、直接使用することはできません。
SNARK の場合、解決策は概念的には単純です。デフォルトでは証明は情報を隠しており、アグリゲーターは SNARK を証明するために再帰的な SNARK を生成する必要があります。
このアプローチの現在の主な課題は、集約にはアグリゲーターが再帰的な SNARK を作成する必要があり、これがかなり遅いことです。
KZG の場合、非インデックスを使用して KZG 証明の作業を明らかにできます。ただし、ブラインド集計は未解決の問題であり、さらなる注意が必要です。
ただし、L2 内から L1 を直接読み取ることはプライバシーを保護しませんが、この直接読み取り機能を実装することは、遅延を最小限に抑えるだけでなく、さらに多くのユースケースにとっても非常に役立ちます。