一文で理解する：なぜ「コンセンサスレイヤーのZK化」が必要なのか？

執筆：Zoe、Puzzle Ventures

TL; DR

多くのパブリックチェーンが競争を始めて以来、EthereumのロードマップにおけるDanksharding、op/zkなどのレイヤー2ソリューションに至るまで、私たちはブロックチェーンのスケーラビリティについて絶えず議論してきました------大量のユーザーと資金が流入した場合、どうすればよいのでしょうか？次の一連の記事を通じて、データの取得、オフチェーン計算、オンチェーン検証の3つの部分から構成される未来のビジョンを皆さんに示したいと思います。

Trustless Data Access + Off-chain Computation + On-chain Verification

「コンセンサスの証明」は、この青写真の重要な部分です。本記事では、EthereumのPoSを基にしたゼロ知識証明によるコンセンサスの意義について探ります。具体的には：

1. EVMの分散化の重要性。
2. Web3のスケーリングにおける分散型データアクセスの重要性。

Ethereumメインネットの全コンセンサスを証明することは複雑な作業ですが、もし私たちがコンセンサス層のzk化を実現できれば、安全な信頼を確保しつつEthereumのスケーリングを助け、Ethereumエコシステム全体の堅牢性を高め、参加コストを低下させ、より多くの人々を巻き込むことができるでしょう。

一、なぜコンセンサス層の証明が重要なのか？ | Why does proving consensus matter?

zkを利用してEthereum L1のコンセンサス層を検証することには、2つの大きな方向性があります。まず、現在のノードの多様性の欠如を補い、Ethereum自体の分散化と安全性を強化することができます。次に、Ethereumエコシステムの各層プロトコルがより多くのユーザーに対して可用性と安全性の基盤を提供することができます。これには、クロスチェーンの安全性、信頼不要なデータアクセス、分散型オラクル、スケーリングなどが含まれます。

1. Ethereumの視点 | Perspective from Ethereum

Ethereumにとって、その分散化と堅牢性を実現するためには、クライアントの多様性が必要です。つまり、より多くの人々が参加することを意味し、特に一般ユーザーが異なるコード環境に基づくクライアントを運営することが求められます。しかし、すべてのユーザーがフルノードを運営することを要求するのは現実的ではありません。なぜなら、これには大量のリソースが必要で、少数の人々しか少なくとも16GB以上のRAMと2TB以上のFast SSDを負担できないからです。そして、これらの要求は常に増加しています。

現在の目標は、軽ノード（light node）を実現することです。軽ノードは、フルノードと同じ信頼度（信頼最小化）を提供しつつ、メモリ、ストレージ、帯域幅の要求を低く抑えることが求められています。しかし、現在の軽ノードはコンセンサスプロセスに参加しておらず、部分的にしかコンセンサスメカニズムの保護を受けていません（Sync Committee）。

この目標はEthereumのロードマップで「The Verge」と呼ばれています。

目標: **ブロックの検証は非常に簡単であるべきです - Nバイトのデータをダウンロードし、いくつかの基本的な計算を行い、SNARKを検証すれば完了です --- EthereumのロードマップにおけるThe Verge

「The Verge」はクライアントのギャップを埋めることを目的としており、重要なステップは、信頼を必要としない軽ノードを実現する方法です。その安全性は今日のフルノードと同等であるべきで、「the client gap」を埋めることで、より多くの人々がネットワークの分散化と堅牢性に積極的に参加できるようになります。

https://www.ethernodes.org/network-types

https://clientdiversity.org/

2. Ethereumエコシステムの各層プロトコルの視点 | Perspective of Protocol Stacks on Ethereum

第一原理から出発して、私たちはオンチェーンデータアクセスとオフチェーン計算検証の統合問題を解決する必要があります。

現在、オンチェーンデータの使用は比較的初歩的であり、不十分です。多くのケースで、プロトコル調整に必要なデータが複雑すぎてオンチェーン計算ができず、信頼不要な方法でデータを取得するコストが高すぎて、大量の履歴データアクセスや頻繁なデジタル計算が必要です。

個人ユーザーやプロジェクトにとって、理想的な状況は分散型でエンドツーエンドの信頼不要な仮定データの伝達と読み書きを実現することです。これを基に、将来のより多くのユーザーに対して、できるだけ低い計算コストを実現し、安全性、可用性、経済性を兼ね備える必要があります。

具体的には以下のいくつかの側面が含まれます：

1. 分散型で信頼不要なオラクル（Oracle）：現在のプロトコルは、中央集権的なオラクルを使用して、大量の履歴データへの直接アクセスを避けており、不要な信頼コストを増加させ、可組み合わせ性を低下させています。

2. データおよび資産に敏感な関連プロトコルのデータ読み書き：例えば、DeFiプロトコルは運用中にいくつかのパラメータを動的に調整する必要がありますが、信頼不要で履歴データにアクセスし、より複雑な計算を行うことができるかどうか、例えば最近の市場の変動に基づいてAMM手数料を調整したり、オンチェーンのデリバティブ取引価格モデルや動的変動を設計したり、機械学習手法を用いて資産管理を行ったり、市場の状況に応じて貸出金利を調整することができるかどうかが問題です。

3. クロスチェーンの安全性：現在、zk技術に基づく軽ノードソリューションは、安全性（security）、資金効率（capital efficiency）、状態保持の程度（statefulness）、および情報伝達の多様性において優れています。現在のSuccinctのTelepathyクロスチェーンソリューションやPolehedraがLayerZero上で行っているクロスチェーンソリューションは、Sync Committeeに基づく軽ノードブロックヘッドのzk検証に基づいています。しかし、Sync CommitteeはEthereum PoSコンセンサス層そのものではなく、一定の信頼仮定が存在し、将来的にはさらに完備させる余地があります。

現在、経済的コスト、技術的制約、ユーザー体験などの観点から、開発者はオンチェーンデータを利用する際に通常、中央集権的なRPCサーバー（例えばAlchemy、Infura、Ankrなど）に依存しています。

二、ブロックチェーンデータはどこから来るのか？異なるデータソースの信頼仮定 | Where is Blockchain Data? Trust Assumptions for Different Data Sources

ブロックチェーン内の計算データには2つの出所があります：オンチェーンデータ（on-chain data）とオフチェーンデータ（off-chain data）。これに対応して、計算を行います。例えば、前述のDeFiプロトコルパラメータの調整のニーズです。

データアクセス、計算、証明および検証

オンチェーンデータとオフチェーンデータの読み書きと計算には2つの顕著な特徴があります：

1. 分散化と安全性を実現するためには、取得したデータを検証できることが望ましい、つまり「信じるな、検証せよ（Don't Trust, Verify）」です。

2. 多くの場合、複雑で高価な計算プロセスが関与します。

適切な技術的解決策が見つからなければ、上記の2点はブロックチェーンの可用性に影響を与えます。

異なるデータ取得方法を説明するために、簡単な例を考えてみましょう。自分のアカウント残高を確認したい場合、どうしますか？

最も安全な方法は、自分でフルノードを運営し、ローカルに保存されたEthereumの状態を確認し、そこからアカウント残高を取得することです。

フルノードのベンチマーク。同期モード（sync mode）とクライアントの選択が必要なスペース要件に影響します。参考: https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/; https://docs.google.com/presentation/d/1ZxEp6Go5XqTZxQFYTYYnzyd97JKbcXlA6O2s4RI9jr4/mobilepresent?pli=1\&slide=id.g252bbdac4960109)

しかし、自分でフルノードを運営するコストは非常に高く、維持管理も必要です。手間を省くために、多くの人々は中央集権的なノード運営者にデータを直接要求するかもしれません。このようにすることには問題はありませんが、Web2での操作に似ており、これらの供給者が悪意のある行動をとったことはありませんが、これは私たちが中央集権的なサービスプロバイダーを信頼しなければならないことを意味し、全体の安全仮定を増加させます。

この問題を解決するために、2つの解決策を考えることができます：1つはノード運営のコストを下げること、もう1つは第三者データの信頼性を検証する方法を見つけることです。

それなら、必要なデータだけを保存することにしましょう。データへの効率的なアクセスを実現し、信頼コストを低下させ、データを独立して検証するために、一部の機関は軽クライアント（light clients）を開発しました。例えば、RustベースのHelio（a16zが開発）、Lodestar、Nimbus、JavaScriptベースのKevlarなどです。軽クライアントはすべてのブロックデータを保存せず、ブロックヘッドのみをダウンロードして保存します------ブロックのすべての情報の「要約」です。軽クライアントは受信したデータ情報を独立して検証できるため、第三者データプロバイダーからデータを取得した場合、そのプロバイダーのデータを完全に信頼する必要はありません。

https://medium.com/coinmonks/ethereum-data-transaction-trie-simplified-795483ff3929

軽ノードの主な特徴には以下が含まれます：

• 理想的には、軽ノードは携帯電話や組み込みデバイス上で運営できます。
• 理想的には、フルノードと同じ機能と安全保障を持つことができます。
• しかし、軽ノードはコンセンサスプロセスに参加せず、部分的にしかコンセンサスメカニズムの保護を受けていません。つまり、同期委員会（Sync Committee）です。

Sync Committeeは軽ノードの信頼仮定です。

The Mergeの前、2020年12月から、Beacon ChainはAltairという名前のハードフォークを行い、その核心的な目的は軽ノードにコンセンサスサポートを提供することでした。PoS全コンセンサスとは異なり、このグループを構成する検証者（512人）は、より小さなデータセットで、より長い時間間隔（256エポック、約27時間）でランダムに抽出されます。

Light clients such as Helios and Succinct are taking steps toward solving the problem, but a light client is far from a fully verifying node: a light client merely verifies the signatures of a random subset of validators called the sync committee, and does not verify that the chain actually follows the protocol rules. To bring us to a world where users can actually verify that the chain follows the rules, we would have to do something different. How will Ethereum's multi-client philosophy interact with ZK-EVMs?, by Vitalik Buterin*

これが、私たちがEthereumの全コンセンサス層を検証する理由であり、より安全で可用性が高く、多様なプロトコルを持ち、大規模に採用される未来を迎えるための最良の解決策がゼロ知識（zero-knowledge）技術であると考えています。

三、ゼロ知識でコンセンサス層を証明する道 | The Path to Prove Consensus Using ZK

信頼不要な仮定の環境を構築するためには、軽ノードの信頼性、分散型データアクセス、オフチェーン計算検証の問題を解決する必要があります。これらの側面において、ゼロ知識証明は現在最も認められているコア技術であり、zkEVM、zkWASM、その他のzkVM、zkコプロセッサなどの基盤となる解決策が含まれます。

コンセンサス層を証明することは、その重要な一環です。

PoSアルゴリズムは非常に複雑であり、ZK方式でそれらを実現するには大量のエンジニアリング作業とアーキテクチャの考慮が必要です。まず、そのコンポーネントを分解してみましょう。

1. Ethereum 2.0におけるコンセンサス形成の核心ステップ | Key Steps in Consensus Formation in Ethereum 2.0

（1）検証者（validator）関連アルゴリズム

以下のステップが含まれます：

• 検証者になる：検証者候補は、デポジット契約に32ETHを送信し、信号チェーン（Beacon Chain）が処理して正式な検証者としてアクティブになるまで、少なくとも16時間から数日または数週間待つ必要があります。（FAQ - 検証者がアクティブになるまでなぜこんなに時間がかかるのかを参照）
• 検証責任を行使する：ランダム数とブロック証明アルゴリズムが関与します。
• 検証者役割を終了する：検証者を終了する方法は、自発的に終了するか、違反により罰せられる（スラッシュ）ことができます。検証者はいつでも自発的に「終了」を開始できますが、各エポックごとに終了する検証者の数には制限があります。過剰な検証者が同時に終了を試みると、彼らはキューに入れられ、順番が来るまで検証責任を果たす必要があります。成功裏に終了した後、1/8エポック後に検証者はステーキング資金を引き出すことができます。

（2）ランダム数関連アルゴリズム

• 各エポックは32のブロック（スロット）を含み、2エポック前にランダムにグループ化し、すべての検証者を32の委員会に分け、現在のエポックで責任を果たし、各ブロックのコンセンサスに責任を持ちます。
• 各委員会には2つの役割があり、1つは提案者（Proposer）、残りはブロック構築者（Builders）で、これもランダムに選ばれます。このように、取引の順序付けとブロック構築の2つのプロセスを分離します（提案者/構築者の分離 - PBSを詳しく見る）。

（3）ブロック証明（Block Attestation）とBLS署名関連アルゴリズム

• 署名部分はコンセンサス層の最も核心的な部分です。
• 各スロットの検証委員会は投票を行い（BLS署名を使用）、2/3の通過率を得る必要があります。
• Ethereum PoSコンセンサス層では、BLS署名はBLS12--381楕円曲線を使用し、ペアリングに優れ、すべての署名を集約し、証明時間とサイズを削減します。
• プルーフオブワークでは、ブロックが再編成される可能性があります（re-org）。マージ後、実行層に「最終化（finalized）ブロックと安全ヘッド（safe head）」の概念が導入されました。対立するブロックを作成するには、攻撃者は少なくとも総ステーキングEtherの1/3を破壊する必要があります。大部分において、PoSはPoWよりも信頼性が高いです。

https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer

2023年6月末、『Puzzle Venturesの夜間授業』でHyper OracleのzkPoS（zkを用いてEthereum全コンセンサス層を検証する方法）が紹介されました。詳細はzkPoS: End-to-End Trustlessを参照してください。

（4）その他：弱主観性チェックポイント（weak subjectivity checkpoints）

信頼不要なPoSコンセンサス証明が直面する課題の1つは、主観性チェックポイントの選択であり、社会的合意（social consensus based on social information）に関与します。これらのチェックポイントはリバート制限（revert limits）であり、弱主観性チェックポイント以前のブロックは変更できません。詳細は：https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

チェックポイント（checkpoints）もコンセンサス層のzk化において考慮すべき点です。

2. コンセンサス層のZK技術スタック | Tech Stacks to Prove Consensus

コンセンサス層を証明する際、証明署名や他の計算自体は非常に高価ですが、ゼロ知識証明の検証は非常に安価です。

ゼロ知識証明を用いたコンセンサス層の方法を選択する際、プロトコルは以下の要素を考慮する必要があります：

• 何を証明したいのか？
• 証明後のアプリケーションシナリオは何か？
• 証明の効率をどう向上させるか？

Hyper Oracleを例にとると、BLS署名を証明するためにHalo2を選択しました。彼らはHalo2を選んだ理由は以下の通りです：

• CircomとHalo2はどちらもBLS署名（BLS12--381楕円曲線）のゼロ知識証明を生成できます。
• Hyper OracleはzkPoSだけを行うわけではなく、そのコア製品はプログラム可能なオンチェーンゼロ知識オラクル（Programmable Onchain zkOracle）です。ユーザー向けにはzkGraph、zkIndexing、zkAutomationがあり、zkWASM仮想マシンを利用してオフチェーン計算を検証しています。Circomはエンジニアにとって使いやすいですが、互換性が低く、すべての機能のロジックが使用できることを保証できません。
• Circom-pairingはR1CSにコンパイルされ、zkWASMや他の回路のPlonkish制約システムと互換性がありませんが、Halo2 Pairing回路はzkWASM回路に非常に簡単に統合できます。対照的に、R1CSはバッチ証明（Proof Batching）にも理想的ではありません。
• 効率の観点から、Halo2-pairingが生成するBLS回路は小さく、証明時間が短く、ハードウェア要件が低く、ガス料金も低いです。

https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE

ゼロ知識を用いてコンセンサス層を証明するもう1つの重要な点は、再帰的証明（recursive proof）------すなわち証明の証明（proofs of proofs）であり、以前に発生した事象を1つの証明にパッケージ化します。

再帰的証明がなければ、最終的にはO(block height)サイズの証明が出力されます。つまり、各ブロック証明（block attestation）とそれに対応するzkpです。再帰的証明を通じて、初期状態と最終状態を除いて、任意の数のブロックに対してO(1)サイズの証明のみが必要です。

証明Nを検証し、ステップN+1を実行して証明N+1を得る。つまり、N+1の知識を持っていることになり、すべてのNステップを個別に検証する必要はありません。

最初の目標に戻ると、私たちの解決策は計算とメモリ制限のある「軽クライアント」に対して設計されるべきです。各証明が固定の時間内に検証できる場合でも、ブロックと証明の数が累積すると、検証時間は非常に長くなります。

3. 最終目標：多様性のあるレベル1 zkEVM | The End Game: Diversified Level 1 zkEVM

Ethereumの目標は、コンセンサス層を証明するだけでなく、zkEVMを通じて全体のLayer 1仮想マシンのゼロ知識化を実現し、最終的には多様なzkEVMを実現してEthereumの分散化と堅牢性を強化することです。

これらの問題に対して、Ethereumの現在の解決策とロードマップは以下の通りです：

「軽量化 light」------ より小さなメモリ、ストレージ、帯域幅の要求

• 現在、軽ノード（light node）を通じてブロックヘッド（block header）のみを保存し、検証する方法を実現しています。
• 将来的な発展には、verkle treeやstateless clientsに関するさらなる努力が必要であり、メインネットのデータ構造の改善が含まれます。

「安全去信任 trustless」------ フルノードと同じ最小信頼（trust-minimization）を実現

• 現在、基本的な軽ノードコンセンサス層、つまり同期委員会（Sync Committees）が実現されていますが、これは一時的な解決策に過ぎません。
• SNARKを使用してEthereum Layer 1を検証し、実行層のVerkle Proofを検証し、コンセンサス層を検証し、全体の仮想マシンをSNARK化します。
• レベル1 zkEVMは、Ethereum Layer 1仮想マシン全体のゼロ知識化を実現し、zkEVMの多様化を実現します。

考えられるリスク

理想的には、zk時代に入ると、さまざまなオープンソースのzkEVMが必要です------異なるクライアントが異なるzkEVM実装を持ち、各クライアントはブロックを受け入れる前に、自身の実装と互換性のある証明を待つ必要があります。

しかし、さまざまな証明システムは、いくつかの問題に直面する可能性があります。なぜなら、各証明システムにはピアツーピアネットワークが必要であり、特定の証明システムのみをサポートするクライアントは、対応するタイプの証明を待つ必要があり、それが検証者（verifier）によって認識されるためです。ここで発生する可能性のある2つの主要な課題は「遅延課題（latency challenge）」と「データ非効率（data inefficiency）」です。前者は、証明生成が遅いために生じ、異なる証明システムに対する証明を生成する際に、悪意のある者が一時的なフォークを作成するための時間差が生じます。後者は、さまざまなタイプのzk証明を生成するために元の署名を保存する必要があるため、理論的にはzkSNARK自体の利点は元の署名などのデータを削除できることですが、ここで最適化と解決が必要な矛盾が生じます。

四、未来展望 | What is the Future?

Web3がより多くのユーザーを迎え、よりスムーズな体験を提供し、より高い可用性を創出し、アプリケーションの安全性を確保するためには、分散型データアクセス、オフチェーン計算、オンチェーン検証のためのインフラストラクチャを整備する必要があります。

コンセンサス層の証明は、その重要な構成要素の1つであり、Ethereum PSEや前述のzkEVM layer2に加えて、いくつかのプロトコルがゼロ知識証明によるコンセンサスを通じて自らのアプリケーション目標を実現しようとしています。これには、Hyper Oracle（Programmable zkOracle Network）がゼロ知識証明を用いてEthereum PoSの全コンセンサス層からデータを取得する計画や、Succinct LabsのTelepathyが軽ノードブリッジ（Light Node Bridge）を通じてSync Committeeコンセンサスを検証し、状態の有効性証明を提出してクロスチェーン通信を実現することが含まれます。また、Polyhedraも元々は軽ノードブリッジでしたが、現在はdevirgoを利用してフルノード全コンセンサスのzk証明を実現したと宣言しています。

クロスチェーンの安全性や分散型オラクルに加えて、このようなオフチェーン計算とオンチェーン検証の方法は、Optimism rollupの詐欺証明（fraud proof）にも参加し、OP L2と相互に融合する可能性があります。また、意図ベースのアーキテクチャ（intent-based architecture）において、より複雑な意図構造に対してオンチェーン証明を提供することも考えられます。

ここで私たちが話しているのは、Ethereumのオフチェーンエコシステムに限らず、Ethereum以外のより広範な市場にも関わるものです。