ブロックチェーン相互運用性(Part 2):ストレージ証明 — 新しいクロスチェーンユースケースの強化

上級12/17/2023, 5:02:55 PM
この論文では、ストレージ証明とそのブロックチェーン取引履歴検証への応用について探求し、最も信頼性の低い検証の概念を使用して過去の取引やユーザーの活動を検証し、多数のクロスチェーンのユースケースを開示します。また、このゼロ知識証明に基づく手法は、一部のL2ブロックチェーンや中央集権ノードサービスプロバイダーが遭遇するデータストレージの問題を効果的に解決できることを指摘しています。

前回の投稿では、実行可能なものとなるでしょうが、ブロックチェーン間の橋渡しを促進するために、この新興の信頼最小化手法のコンセンサス証明の役割について議論しました。

この記事では、信頼度最小化検証の概念を取り入れ、古い歴史的なブロック内の取引に拡張するストレージの証明について探っていきます。この方法で過去の取引とユーザーの活動を検証できる能力は、多数のクロスチェーンのユースケースを開くものです。

In our 前の投稿,私たちはProof of Consensusを導入しました-ブロックチェーン間で資金を橋渡しするための信頼を最小限に抑えるアプローチ。橋のユーザーは通常、トランザクションが最も最近の瞬間に即座に行われることを望んでいるため、コンセンサスの証明は非常に役立ちます。なぜなら、彼らはブロックチェーンの最新の状態を常にチェックしているからです。

この信頼最小化を橋渡しする概念は、過去に戻って古いブロック内のトランザクションとデータを検証するためにゼロ知識証明を使用するという別の方向にも適用できます。これらの「歴史的ストレージ証明」はさまざまなクロスチェーンユースケースをサポートし、この記事ではこれらのユースケース、動作方法、およびこの領域に組み込まれたアクターについて説明します。

過去のデータを取得する

歴史的なブロックチェーンデータには多くの用途があります。資産の所有権、ユーザーの行動、取引履歴を証明するために使用され、それらをオンチェーンのスマートコントラクトやアプリケーションに入力することができます。執筆時点では、1800万以上のブロックがEthereumに書き込まれています。スマートコントラクトは、最新の256ブロック(または過去30分間のデータ)にのみアクセスできるため、「履歴データ」とは最後の256ブロック以外のすべてを指します。

今日、歴史的なデータにアクセスするために、プロトコルはしばしばクエリを実行しますアーカイブノードプロバイダー、つまりInfura、Alchemy、その他のインデクサーなどの第三者に信頼し、それらとそのデータを信頼することを意味します。

歴史的データ

しかし、ストレージ証明書を使用することで、このデータはより信頼を最小限に抑えた方法で緩和される可能性があります。

履歴データ

ただし、このデータは、ストレージ証明を使用してより信頼の低い方法で取得することができます。

ストレージの証明は、ブロックチェーンに保存された過去のデータの検証を可能にするゼロ知識証明です。より具体的には、ストレージの証明は、過去の特定のブロック内の特定の状態の存在を証明するために使用できます。このアプローチには、第三者やオラクルへの信頼が必要ありません。代わりに、その信頼はストレージ証明に組み込まれています。

過去の歴史的なブロックにデータが存在することを検証するのにストレージ証明がどのように役立つか?これには2つのことを検証する必要があります。

  • 最初のステップは、特定のブロックがブロックチェーンの規制履歴の一部であるかどうかをチェックすることです。つまり、そのブロックがソースチェーンの履歴の有効な部分であるかどうかです。
  • 第2ステップは、特定のデータがブロックの一部であるかどうかを確認することです。つまり、情報の一部(特定の取引など)がブロックの一部であるかどうかを確認することです(これは、Merkleが証明を含むことで証明できます)。

受信および検証を受けた後、受信者(ターゲットチェーン上のスマートコントラクトなど)はデータの妥当性を信じ、対応する一連の命令を実行できます。この概念はさらに拡張することができます:検証されたデータでオフチェーンの計算を実行し、その後、データと計算を証明するためのゼロ知識証明が生成されます。

単純に言えば、ストレージの証明は、信頼を最小限に抑えながら、過去のチェーン上のデータの取得をサポートします。これは重要です。なぜなら、最初の投稿で述べたように、Web3は今後数年でより多様なチェーンと複数階層の空間になると見込まれるからです。複数のレイヤー1プロトコル、ロールアップ、およびアプリケーションチェーンの出現により、ユーザーのオンチェーン活動が複数のチェーンに分散される可能性があります。これは、複数のドメインをまたがるユーザー資産、アイデンティティ、および取引履歴の相互運用性を維持する、信頼を最小限に抑えたソリューションの必要性をさらに強調しています。これは、ストレージの証明が解決に役立つ問題です。

Proof of storageのユースケースは何ですか?

ストレージの証明は、クロスチェーンアプリの設計をより柔軟にするために、スマートコントラクトが前提条件として任意の過去の取引やデータをチェックできるようにします。

最初に、証拠を保存することで、ソースブロックチェーン上の任意の過去データを証明できます。

  1. 口座残高とトークン所有権
  2. ユーザーの取引活動または静的状態
  3. 指定された時間期間にわたる資産取引の歴史的価格
  4. クロスチェーン流動性プールのリアルタイム資産残高

その後、証明は送信され、クロスチェーンの使用例の範囲を解除するためにターゲットチェーンに送信されます。

  1. ユーザーが低コストのレイヤー2契約でガバナンス提案に投票できるようにします
  2. 新しいチェーンでNFTホルダーが新しいNFTミントやコミュニティ特典を受け取ることを許可する
  3. 特定のdAppsとの履歴や相互作用に基づいてユーザーに報酬を提供する(たとえば、エアドロップを通じて)
  4. ユーザーの総取引と信用履歴に基づいてカスタム金利を提供するローン
  5. 休眠アカウントのアカウント回復をトリガーします
  6. 先物スワップTWAPの履歴を計算する
  7. マルチチェーン流動性プールに基づいて、より正確なAMMスワップ価格を計算します

基本的に、ストレージ証明は、アプリが複数のチェーン上のユーザーのオンチェーン活動や履歴を問い合わせてポートし、スマートコントラクトや別のチェーン上のアプリケーションに入力することを可能にします。

ストレージ証明の使用事例

詳細な例を取って、ストレージ証明がどのように機能するかを理解しましょう。

ストレージプルーフの動作原理:詳細な例

「X」と仮定し、これはイーサリアム上のトークンを持つDeFiプロトコルです。ガバナンス提案が提出される予定で、低コストのターゲットチェーンでのオンチェーン投票を促進したいと考えています。ユーザーは特定の時点(「スナップショット」と呼びます)でイーサリアム上のXトークンを保有している場合にのみ投票できます。たとえば、ブロック#17,000,000です。

チェーン上での投票は現在どのように行われていますか?

現在のアプローチは、アーカイブノードにクエリを送信して、ブロック#17,000,000での適格トークン保持者の完全なリストを取得することです。その後、DAO管理者はそのリストをターゲットチェーンのスマートコントラクトに保存して、誰が投票できるかを決定します。このアプローチにはいくつかの制限があります:

  1. 投票者リストは非常に長くなる可能性があり、各スナップショットが変わるたびに、各投票提案をチェーン上に格納および更新するコストがかかります;
  2. アーカイブノードプロバイダーとその提供するデータには、暗黙の信頼があります;
  3. DAOを管理するメンバーは、投票者リストを改ざんしないように信頼されなければなりません

証明書の保存はこの問題をどのように解決しますか?

記事2で説明したように、高価な計算はチェーン外のゼロ知識証明に移行できます。

zkアテスターは簡潔な証明を生成し、それを検証のためにターゲットチェーンに送信します。上記のDAO投票者の適格性の例には、以下があります:

  1. attestorは、Ethereumの履歴の一部であるブロック#17,000,000のゼロ知識証明を生成します(上記の最初のステップと同様に)。
  2. ブロックの妥当性を証明した後、私たちはMerkleを使用して、ブロックが最終化されたときにユーザーがDAOトークンを保持していたことの証明を含めることができます(上記のステップ2と同様に)

クロスチェーン投票を可能にするために、過去のデータを検証します

その後、証明は検証のためにターゲットチェーン上のスマートコントラクトに送信されます。検証が成功した場合、レイヤー2プロトコル上のスマートコントラクトはユーザーに投票することを許可します。

このアプローチはいくつかの問題を解決しました。次のものが必要ありません:

アーカイブノードプロバイダーを信頼してください;

  1. 合意を維持して高価なオンチェーン有権者リストを維持する;
  2. ユーザーが目的のチェーンに資産を転送するため

Proof of Storageにはどの設定が必要ですか?

これまで、ストレージ証明の複雑さの一部を抽象化してきました。ただし、それらを使用するには、サービスプロバイダーによる注意深い初期セットアップも必要です。これにより、プロバイダーを信頼せずに使用できることが保証されます。このプロセス中には2つのものが生成され、チェーン上に保存されます。

  1. フルチェーンゼロ知識証明(「zkプロミス」):サービスプロバイダは、ソースチェーン上のすべての過去のブロックを連続した固定サイズの「ブロック」(Merkleツリーを使用)にグループ化しますそして、各ブロックにゼロ知識証明を生成し、それらはグループを検証するために使用されます。これらの証明は、最終的なゼロ知識証明である「zk promise」が得られるまで再帰的に結合されます。これにより、プロバイダーがチェーンの完全な履歴を正しくインデックス化していることが証明されます。

「zk promise」とは、イーサリアムの全歴史を説明しています

  • **Merkle Mountain Range: ** プロバイダーは、Merkle Mountain Range (MMR) と呼ばれるオンチェーンのデータ構造にまとめられたソースチェーンのブロックハッシュ (ブロック) の Keccak Merkle ルートも保持しています。このデータ構造は、簡単にクエリおよび更新が可能であり、プロバイダーが特定のブロックがチェーンの履歴に存在することを効果的に証明できるため使用されます。MMR は Keccak256 ハッシュ、Poseidon ハッシュ、またはその両方を使用して作成されます。Poseidon ハッシュはよりゼロ知識に優しいものであり、歴史データの計算をサポートします。データと計算の妥当性は後でゼロ知識を用いて証明することができます。

Merkel Mountain Range (MMR) イラストレーション

新しいブロックがソースチェーンに追加されるたびに、サービスプロバイダーは定期的に(毎時または毎日など)「zkコミットメント」とMMRを更新して、チェーンのペースに遅れずに追いつくようにします。これにより、過去のブロックが常にEVMからアクセス可能な256ブロックのうちの1つにリンクされるようにします。これにより、過去のデータがEthereumで現在利用可能なブロックの1つにリンクされることが保証されます。

以下の画像では、セットアップの完了方法について詳しく説明しています:

要約すると、前述のDAO投票の例を元に、セットアップが完了した後にストレージ証明をどのように使用するかを示しています。

  1. サービスプロバイダーは、全体のチェーン(つまり、Ethereumの履歴)および対象チェーンのMMRのために「zk promises」を作成および保存します
  2. プロバイダーは、APIを介してアプリケーションがチェーン上またはチェーン外で過去のデータをクエリできるようにします
  3. ゴールチェーン上の投票dAppは、プロバイダーのスマートコントラクトにクエリを送信して、ユーザーがEthereumのブロック#17,000,000でDAOトークンを保持しているかどうかを調べます。

プロバイダーは2つのことをチェックします:

  1. 問い合わせられたブロックは、イーサリアムの規制履歴の一部です(上記の最初のステップ);次に、プロバイダーは、Merkle Mountain Rangeを介してブロックの内容のゼロ知識証明を生成します
  2. ユーザーは、ブロック#17,000,000(上記のステップ2)でDAOトークンを保持しており、次に、プロバイダーはユーザーがブロック内でDAOトークンを保持していることを示す別のゼロ知識証明を生成します
  3. プロバイダーは、上記で生成された証拠をゼロ知識証明に集約します
  4. 集計されたZKプルーフは、その後、検証が成功した場合にユーザーに投票を許可するために、対象チェーン上の投票dAppスマートコントラクトに送信されます。

この分野でのチームビルディング

一部の参加者は、信頼を最小限に抑えつつ、過去のチェーン上のデータにアクセスできるスマートコントラクトを構築しています。

現在、アクシオムEthereumで実行され、Ethereum上のスマートコントラクトの提供と、zkベースのストレージ証明を介した過去のEthereumデータへのアクセスに取り組んでいます。チームはまた、過去のデータに基づいたオフチェーン計算能力を向上させ、これらのデータと計算の正確性を証明するためにゼロ知識を使用しています。

遺物プロトコルAxiomに類似した技術アプローチを提供し、プロトコルはEthereumとzkSync Eraで実行されます。Relicは、データの含有を証明するためにMerkle包含証明を使用します(Axiomのゼロ知識でのMerkle包含を証明する方法とは対照的)。

ヘロドトスは、レイヤー2プロトコルのEthereumの過去のデータを提供するために取り組んでいます。テスト実装は現在、StarknetとzkSync Eraで利用可能です。OP Foundationの資金援助を受け、Herodotusチームが次にどこに向かっているかを私たちは知っていると思います。

ラグランジュラボラボ最近のZK MapReduce(ZKMR)イノベーションを通じて、完全に更新可能な証明を導入しました。新しいベクトルプロミスを使用していますRecproofsデータ計算に更新可能性の概念を拡張する。

ストレージ認証に取り組んでいるチーム

エピローグ

この記事では、サードパーティを信頼せずに過去のチェーン上のデータの検証をサポートするために証明書の保存がどのように役立つかについて説明しました。これにより、オンチェーンの構成やクロスチェーンの相互運用性にとって貴重なツールとなります。

総ロックされた価値(TVL)がイーサリアムからティア2エコシステムに移行し続ける中、過去のオンチェーンデータをストレージ証明を通じて利用するより表現豊かなアプリケーションの台頭を予想しています。

ゼロ知識技術がますます高速で安くなる一方で、オンチェーンにあるコストに追いつくために保管証明を継続的に生成することはまだ課題です。このようなサービスの利益性は、クエリアプリケーションによって生成されるクエリの量に依存します。

さまざまな課題にもかかわらず、ゼロ知識技術によってサポートされたコンセンサスの証明とストレージの証明の重要性は過小評価できません。これらの技術が信頼を最小限に抑えたマルチチェーンの未来を構築するためにどのように活用されるかを楽しみにしています。

免責事項:

  1. この記事は[から転載されましたミラー]. すべての著作権は元の著者に帰属します [Jacob、Hitesh、Ji Hao]. If there are objections to this reprint, please contact the Gate Learn team(gatelearn@gate.io), そして彼らは迅速に対処します。
  2. 責任の免責事項:この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。

ブロックチェーン相互運用性(Part 2):ストレージ証明 — 新しいクロスチェーンユースケースの強化

上級12/17/2023, 5:02:55 PM
この論文では、ストレージ証明とそのブロックチェーン取引履歴検証への応用について探求し、最も信頼性の低い検証の概念を使用して過去の取引やユーザーの活動を検証し、多数のクロスチェーンのユースケースを開示します。また、このゼロ知識証明に基づく手法は、一部のL2ブロックチェーンや中央集権ノードサービスプロバイダーが遭遇するデータストレージの問題を効果的に解決できることを指摘しています。

前回の投稿では、実行可能なものとなるでしょうが、ブロックチェーン間の橋渡しを促進するために、この新興の信頼最小化手法のコンセンサス証明の役割について議論しました。

この記事では、信頼度最小化検証の概念を取り入れ、古い歴史的なブロック内の取引に拡張するストレージの証明について探っていきます。この方法で過去の取引とユーザーの活動を検証できる能力は、多数のクロスチェーンのユースケースを開くものです。

In our 前の投稿,私たちはProof of Consensusを導入しました-ブロックチェーン間で資金を橋渡しするための信頼を最小限に抑えるアプローチ。橋のユーザーは通常、トランザクションが最も最近の瞬間に即座に行われることを望んでいるため、コンセンサスの証明は非常に役立ちます。なぜなら、彼らはブロックチェーンの最新の状態を常にチェックしているからです。

この信頼最小化を橋渡しする概念は、過去に戻って古いブロック内のトランザクションとデータを検証するためにゼロ知識証明を使用するという別の方向にも適用できます。これらの「歴史的ストレージ証明」はさまざまなクロスチェーンユースケースをサポートし、この記事ではこれらのユースケース、動作方法、およびこの領域に組み込まれたアクターについて説明します。

過去のデータを取得する

歴史的なブロックチェーンデータには多くの用途があります。資産の所有権、ユーザーの行動、取引履歴を証明するために使用され、それらをオンチェーンのスマートコントラクトやアプリケーションに入力することができます。執筆時点では、1800万以上のブロックがEthereumに書き込まれています。スマートコントラクトは、最新の256ブロック(または過去30分間のデータ)にのみアクセスできるため、「履歴データ」とは最後の256ブロック以外のすべてを指します。

今日、歴史的なデータにアクセスするために、プロトコルはしばしばクエリを実行しますアーカイブノードプロバイダー、つまりInfura、Alchemy、その他のインデクサーなどの第三者に信頼し、それらとそのデータを信頼することを意味します。

歴史的データ

しかし、ストレージ証明書を使用することで、このデータはより信頼を最小限に抑えた方法で緩和される可能性があります。

履歴データ

ただし、このデータは、ストレージ証明を使用してより信頼の低い方法で取得することができます。

ストレージの証明は、ブロックチェーンに保存された過去のデータの検証を可能にするゼロ知識証明です。より具体的には、ストレージの証明は、過去の特定のブロック内の特定の状態の存在を証明するために使用できます。このアプローチには、第三者やオラクルへの信頼が必要ありません。代わりに、その信頼はストレージ証明に組み込まれています。

過去の歴史的なブロックにデータが存在することを検証するのにストレージ証明がどのように役立つか?これには2つのことを検証する必要があります。

  • 最初のステップは、特定のブロックがブロックチェーンの規制履歴の一部であるかどうかをチェックすることです。つまり、そのブロックがソースチェーンの履歴の有効な部分であるかどうかです。
  • 第2ステップは、特定のデータがブロックの一部であるかどうかを確認することです。つまり、情報の一部(特定の取引など)がブロックの一部であるかどうかを確認することです(これは、Merkleが証明を含むことで証明できます)。

受信および検証を受けた後、受信者(ターゲットチェーン上のスマートコントラクトなど)はデータの妥当性を信じ、対応する一連の命令を実行できます。この概念はさらに拡張することができます:検証されたデータでオフチェーンの計算を実行し、その後、データと計算を証明するためのゼロ知識証明が生成されます。

単純に言えば、ストレージの証明は、信頼を最小限に抑えながら、過去のチェーン上のデータの取得をサポートします。これは重要です。なぜなら、最初の投稿で述べたように、Web3は今後数年でより多様なチェーンと複数階層の空間になると見込まれるからです。複数のレイヤー1プロトコル、ロールアップ、およびアプリケーションチェーンの出現により、ユーザーのオンチェーン活動が複数のチェーンに分散される可能性があります。これは、複数のドメインをまたがるユーザー資産、アイデンティティ、および取引履歴の相互運用性を維持する、信頼を最小限に抑えたソリューションの必要性をさらに強調しています。これは、ストレージの証明が解決に役立つ問題です。

Proof of storageのユースケースは何ですか?

ストレージの証明は、クロスチェーンアプリの設計をより柔軟にするために、スマートコントラクトが前提条件として任意の過去の取引やデータをチェックできるようにします。

最初に、証拠を保存することで、ソースブロックチェーン上の任意の過去データを証明できます。

  1. 口座残高とトークン所有権
  2. ユーザーの取引活動または静的状態
  3. 指定された時間期間にわたる資産取引の歴史的価格
  4. クロスチェーン流動性プールのリアルタイム資産残高

その後、証明は送信され、クロスチェーンの使用例の範囲を解除するためにターゲットチェーンに送信されます。

  1. ユーザーが低コストのレイヤー2契約でガバナンス提案に投票できるようにします
  2. 新しいチェーンでNFTホルダーが新しいNFTミントやコミュニティ特典を受け取ることを許可する
  3. 特定のdAppsとの履歴や相互作用に基づいてユーザーに報酬を提供する(たとえば、エアドロップを通じて)
  4. ユーザーの総取引と信用履歴に基づいてカスタム金利を提供するローン
  5. 休眠アカウントのアカウント回復をトリガーします
  6. 先物スワップTWAPの履歴を計算する
  7. マルチチェーン流動性プールに基づいて、より正確なAMMスワップ価格を計算します

基本的に、ストレージ証明は、アプリが複数のチェーン上のユーザーのオンチェーン活動や履歴を問い合わせてポートし、スマートコントラクトや別のチェーン上のアプリケーションに入力することを可能にします。

ストレージ証明の使用事例

詳細な例を取って、ストレージ証明がどのように機能するかを理解しましょう。

ストレージプルーフの動作原理:詳細な例

「X」と仮定し、これはイーサリアム上のトークンを持つDeFiプロトコルです。ガバナンス提案が提出される予定で、低コストのターゲットチェーンでのオンチェーン投票を促進したいと考えています。ユーザーは特定の時点(「スナップショット」と呼びます)でイーサリアム上のXトークンを保有している場合にのみ投票できます。たとえば、ブロック#17,000,000です。

チェーン上での投票は現在どのように行われていますか?

現在のアプローチは、アーカイブノードにクエリを送信して、ブロック#17,000,000での適格トークン保持者の完全なリストを取得することです。その後、DAO管理者はそのリストをターゲットチェーンのスマートコントラクトに保存して、誰が投票できるかを決定します。このアプローチにはいくつかの制限があります:

  1. 投票者リストは非常に長くなる可能性があり、各スナップショットが変わるたびに、各投票提案をチェーン上に格納および更新するコストがかかります;
  2. アーカイブノードプロバイダーとその提供するデータには、暗黙の信頼があります;
  3. DAOを管理するメンバーは、投票者リストを改ざんしないように信頼されなければなりません

証明書の保存はこの問題をどのように解決しますか?

記事2で説明したように、高価な計算はチェーン外のゼロ知識証明に移行できます。

zkアテスターは簡潔な証明を生成し、それを検証のためにターゲットチェーンに送信します。上記のDAO投票者の適格性の例には、以下があります:

  1. attestorは、Ethereumの履歴の一部であるブロック#17,000,000のゼロ知識証明を生成します(上記の最初のステップと同様に)。
  2. ブロックの妥当性を証明した後、私たちはMerkleを使用して、ブロックが最終化されたときにユーザーがDAOトークンを保持していたことの証明を含めることができます(上記のステップ2と同様に)

クロスチェーン投票を可能にするために、過去のデータを検証します

その後、証明は検証のためにターゲットチェーン上のスマートコントラクトに送信されます。検証が成功した場合、レイヤー2プロトコル上のスマートコントラクトはユーザーに投票することを許可します。

このアプローチはいくつかの問題を解決しました。次のものが必要ありません:

アーカイブノードプロバイダーを信頼してください;

  1. 合意を維持して高価なオンチェーン有権者リストを維持する;
  2. ユーザーが目的のチェーンに資産を転送するため

Proof of Storageにはどの設定が必要ですか?

これまで、ストレージ証明の複雑さの一部を抽象化してきました。ただし、それらを使用するには、サービスプロバイダーによる注意深い初期セットアップも必要です。これにより、プロバイダーを信頼せずに使用できることが保証されます。このプロセス中には2つのものが生成され、チェーン上に保存されます。

  1. フルチェーンゼロ知識証明(「zkプロミス」):サービスプロバイダは、ソースチェーン上のすべての過去のブロックを連続した固定サイズの「ブロック」(Merkleツリーを使用)にグループ化しますそして、各ブロックにゼロ知識証明を生成し、それらはグループを検証するために使用されます。これらの証明は、最終的なゼロ知識証明である「zk promise」が得られるまで再帰的に結合されます。これにより、プロバイダーがチェーンの完全な履歴を正しくインデックス化していることが証明されます。

「zk promise」とは、イーサリアムの全歴史を説明しています

  • **Merkle Mountain Range: ** プロバイダーは、Merkle Mountain Range (MMR) と呼ばれるオンチェーンのデータ構造にまとめられたソースチェーンのブロックハッシュ (ブロック) の Keccak Merkle ルートも保持しています。このデータ構造は、簡単にクエリおよび更新が可能であり、プロバイダーが特定のブロックがチェーンの履歴に存在することを効果的に証明できるため使用されます。MMR は Keccak256 ハッシュ、Poseidon ハッシュ、またはその両方を使用して作成されます。Poseidon ハッシュはよりゼロ知識に優しいものであり、歴史データの計算をサポートします。データと計算の妥当性は後でゼロ知識を用いて証明することができます。

Merkel Mountain Range (MMR) イラストレーション

新しいブロックがソースチェーンに追加されるたびに、サービスプロバイダーは定期的に(毎時または毎日など)「zkコミットメント」とMMRを更新して、チェーンのペースに遅れずに追いつくようにします。これにより、過去のブロックが常にEVMからアクセス可能な256ブロックのうちの1つにリンクされるようにします。これにより、過去のデータがEthereumで現在利用可能なブロックの1つにリンクされることが保証されます。

以下の画像では、セットアップの完了方法について詳しく説明しています:

要約すると、前述のDAO投票の例を元に、セットアップが完了した後にストレージ証明をどのように使用するかを示しています。

  1. サービスプロバイダーは、全体のチェーン(つまり、Ethereumの履歴)および対象チェーンのMMRのために「zk promises」を作成および保存します
  2. プロバイダーは、APIを介してアプリケーションがチェーン上またはチェーン外で過去のデータをクエリできるようにします
  3. ゴールチェーン上の投票dAppは、プロバイダーのスマートコントラクトにクエリを送信して、ユーザーがEthereumのブロック#17,000,000でDAOトークンを保持しているかどうかを調べます。

プロバイダーは2つのことをチェックします:

  1. 問い合わせられたブロックは、イーサリアムの規制履歴の一部です(上記の最初のステップ);次に、プロバイダーは、Merkle Mountain Rangeを介してブロックの内容のゼロ知識証明を生成します
  2. ユーザーは、ブロック#17,000,000(上記のステップ2)でDAOトークンを保持しており、次に、プロバイダーはユーザーがブロック内でDAOトークンを保持していることを示す別のゼロ知識証明を生成します
  3. プロバイダーは、上記で生成された証拠をゼロ知識証明に集約します
  4. 集計されたZKプルーフは、その後、検証が成功した場合にユーザーに投票を許可するために、対象チェーン上の投票dAppスマートコントラクトに送信されます。

この分野でのチームビルディング

一部の参加者は、信頼を最小限に抑えつつ、過去のチェーン上のデータにアクセスできるスマートコントラクトを構築しています。

現在、アクシオムEthereumで実行され、Ethereum上のスマートコントラクトの提供と、zkベースのストレージ証明を介した過去のEthereumデータへのアクセスに取り組んでいます。チームはまた、過去のデータに基づいたオフチェーン計算能力を向上させ、これらのデータと計算の正確性を証明するためにゼロ知識を使用しています。

遺物プロトコルAxiomに類似した技術アプローチを提供し、プロトコルはEthereumとzkSync Eraで実行されます。Relicは、データの含有を証明するためにMerkle包含証明を使用します(Axiomのゼロ知識でのMerkle包含を証明する方法とは対照的)。

ヘロドトスは、レイヤー2プロトコルのEthereumの過去のデータを提供するために取り組んでいます。テスト実装は現在、StarknetとzkSync Eraで利用可能です。OP Foundationの資金援助を受け、Herodotusチームが次にどこに向かっているかを私たちは知っていると思います。

ラグランジュラボラボ最近のZK MapReduce(ZKMR)イノベーションを通じて、完全に更新可能な証明を導入しました。新しいベクトルプロミスを使用していますRecproofsデータ計算に更新可能性の概念を拡張する。

ストレージ認証に取り組んでいるチーム

エピローグ

この記事では、サードパーティを信頼せずに過去のチェーン上のデータの検証をサポートするために証明書の保存がどのように役立つかについて説明しました。これにより、オンチェーンの構成やクロスチェーンの相互運用性にとって貴重なツールとなります。

総ロックされた価値(TVL)がイーサリアムからティア2エコシステムに移行し続ける中、過去のオンチェーンデータをストレージ証明を通じて利用するより表現豊かなアプリケーションの台頭を予想しています。

ゼロ知識技術がますます高速で安くなる一方で、オンチェーンにあるコストに追いつくために保管証明を継続的に生成することはまだ課題です。このようなサービスの利益性は、クエリアプリケーションによって生成されるクエリの量に依存します。

さまざまな課題にもかかわらず、ゼロ知識技術によってサポートされたコンセンサスの証明とストレージの証明の重要性は過小評価できません。これらの技術が信頼を最小限に抑えたマルチチェーンの未来を構築するためにどのように活用されるかを楽しみにしています。

免責事項:

  1. この記事は[から転載されましたミラー]. すべての著作権は元の著者に帰属します [Jacob、Hitesh、Ji Hao]. If there are objections to this reprint, please contact the Gate Learn team(gatelearn@gate.io), そして彼らは迅速に対処します。
  2. 責任の免責事項:この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
  3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.