イーサリアムL1のエンドゲームへ向けて、Taikoのマルチプルプロファイラインマップ

2024.01.23

共有先

TechFlow厳選深潮セレクト

イーサリアムL1のエンドゲームへ向けて、Taikoのマルチプルプロファイラインマップ

Taikoは、ZKにおけるマルチプロービングが将来のイーサリアムL1におけるSNARK化ノードの多様性の基盤となると考えている。

2024.01.23 - 12:23:16

Web3業界の深掘り報道に専念し潮流を洞察

Taikoは、ZKにおけるマルチプロービングが将来のイーサリアムL1におけるSNARK化ノードの多様性の基盤となると考えている。

執筆：Taiko

翻訳：Frank、Foresight News

最近、我々は「なぜmulti-proverが重要なのか」という題名の詳細な記事を共有し、マルチプルプルーフ（Multi-Proofs）の重要性について説明しました。その中でSGXもマルチプルプルーフの選択肢の一つとして紹介しています。

この記事のインスピレーションは、VitalikとのX Spaceでの対談と、その後彼が発表したブログ記事に由来します。そこでは、Taikoのマルチプルプルーフに関する全体的なロードマップ、それがイーサリアムの終局（endgame）とどのように関係しているか、私たちのビジョンとは何か、そしてそれをどう実現していくかについて紹介されています。

我々は、ZKにおけるmulti-proofはmulti-SNARKs＋multi-Clientの活用へと変換できると考えており、つまり複数の異なるイーサリアムノードに対して複数のZK-SNARK証明を使用することで、将来のイーサリアムL1におけるSNARK化されたノードの多様性の基盤を築くことができるのです。

マルチプルプルーフの必要性を極めてシンプルに説明するためには、以下の2点を挙げておくべきです：

マルチプルプルーフにより、ノード実装や証明システム内のバグ・リスクへのヘッジが可能になる。ある脆弱性が発生した場合でも、たとえ一つの証明が破られたとしても、他の証明が同じ脆弱性を悪用することを許容する可能性は低くなる；
イーサリアムの終局とは、L1の検証にゼロ知識証明（ZK）を使うことを前提としている；

イーサリアムのマルチクライアント実装と同様に、このアプローチはこれまで何度もネットワークのクラッシュを防いでおり、L1ブロックにはマルチバリデーションの手法が必要であることを示しています。ZKおよび非ZKのシナリオにおいても、これはすなわち複数のノードと異なる証明システムを使用する必要があるということです。

Multi-Client システムと L1 の終局

Vitalikが自身の記事『What might an "enshrined ZK-EVM" look like?』で述べているように、Multi-Clientシステムには二つのアプローチがあります。「オープン型」と「クローズド型」です。

クローズド型のMulti-Clientシステムでは、プロトコル内で一連の固定された証明が事前に定義され、「ホワイトリスト」に登録されており、それらのみが証明生成に使用される。Vitalikの分類によれば、すべてのZK L2はクローズド型に該当する。なぜなら、それらは自らの実装による証明だけを受け入れるからである；
一方、オープン型のMulti-Clientシステムでは、証明は「ブロック外」に配置され、各ノードが個別に検証を行う。任意のユーザーが自身が望むノードを使ってブロックを検証できる；

ユーザーが特定のブロックを検証したい場合、最も単純な方法は対応するノードを直接実行してブロックを再実行するか、既知のProverに有効性証明を要求することです。一定数の「ホワイトリスト」準拠の証明を受け取った場合、そのブロックは正当であると見なされます。しかし、もし「ホワイトリスト」準拠のゼロ知識証明（ZKP）が存在せず、かつ再実行を避けたい場合は、どのようなZKPを使えばよいのでしょうか？

Vitalikのビジョンによれば、この問題はプロトコル外でソーシャル（または暗号経済的）コンセンサスによって解決されるのです：

コンセンサス層に次のような検証ルールを追加します。すなわち、ノードがブロック内の各状態変化に対して有効な証明を見た場合にのみ、そのブロックを受け入れる。この証明は、transaction_and_witness_blobsの連結が(Block, Witness)ペアのシリアライズであること、およびpre_state_rootとWitnessに基づいて(i)ブロックの実行が有効であり、(ii)正しいpost_state_rootが出力されることを証明するZK-SNARK証明でなければならない。潜在的には、ノードはM-of-N方式で複数種類の証明を待つことも可能である。

正直なBuilderがtype-1のブロックを持っており、その有効性を提供したいと仮定しましょう。L2レイヤーにはすでにPolygon、ZkSync、Scrollといったいくつかの選択肢があります。

これらのZK-EVMがすでにtype-1にまで進化しており、信頼性が高く実戦経験もあると仮定すると、Builderは利用可能な証明システムの中から選択でき、そのブロックを検証する人々は対応する検証ソフトウェアを実行し、理想としては複数種類の証明を作成し、多重検証を行うことになります。同じL1チェーン仕様のもとで、もしいずれかの検証者が異議を唱えた場合、ブロック検証はコンセンサスの問題となり、オープン型システムではコンセンサスを通じて検証結果の一致が図られます。

証明システムは、プロトコルガバナンスを説得するのではなく、ユーザーに自身を信頼させることで影響力を獲得します。

Vitalikによれば、これはZKPエコシステムが市場原理に基づいた開放的なものになりつつあることを意味します。インセンティブがあれば、既存のL2実装がL1証明市場に参入して競争する可能性があるのです。

Taikoにおけるマルチプルプルーフの実現可能性

Taikoプロトコルでは、Proposerはブロックを提案するためにProverを見つけなければならず、指定されたProverは証明に問題がないようにTKOをステーキングとして預けます。Taikoプロトコルは、ProposerがどのようにProverを見つけ、報酬を与えるかについては規定していないため、彼らは実際に会って現金で取引することさえ可能です。

そのため、我々のサプライチェーンは自由市場のように機能し、Proposerは好きなProverを自由に選べます。

経済的な利点に加えて、TaikoにはMulti-Clientシステムに理想的な技術的特徴もあります：

Taikoはtype-1のZK-EVMであり、二つの利点があります。第一に、実行の多様性に関して、既存のEVM実装（Geth、Besu、Rethなど）をそのままL2に適用できる。第二に、L1設計の実現可能性をテストするためには、検証者が同じ変換に基づいて合意し、結果を検証できるよう、標準化されたZK-EVMによるオープン型Multi-Client検証が必要です。この場合、type-1 ZK-EVMが最適な選択肢となります。なぜなら、それは明確にイーサリアムの仕様に従っているからです。Rollup特有のロジックに関して、VitalikはZK-EVMをプリコンパイルで修正する方法にも言及しており、それらのプリコンパイルを利用すれば、TaikoのBBR（Based Booster Rollup）設計をサポートするのに十分です；
Taikoはデータ可用性をイーサリアム上に発行しており、一部のL2が代替のデータ可用性オプションを探求するのとは異なります。データがL1に発行されていれば、TaikoはVitalikの提案するZKEVMClaimTransaction（状態遷移、証明、データ可用性をカバーする）を容易に採用できます；

Taikoは複数の証明システム上で動作しており、既存のテストネットはPSEのZK-EVM、SGX、Rethをすでにサポートしています。インフラは複数の実行ノードと証明システムに対応するように構成されており、これは後述するセクションで詳しく説明します。このインフラの上に、Taikoはゼロ知識証明に関してモジュラーコンパイルを中心に展開していきます。

モジュラーかつオープンなロードマップ

モジュラリティ

ゼロ知識証明（ZKP）の文脈において、Multi-Clientを考慮すると、TaikoはRisc-VやWASMなどの現代コンパイラによる汎用コンポーネントを活用します。その後、これらの命令をさまざまな証明システム（AIRやPIL）の算術表現に変換し、最終的に異なるSNARKsを使って算術化された実行トレースを符号化します。

要するに、このプロセスはマルチプルプルーフシステムの中で最も実現可能なアプローチであり、両面の利点を最大限に活かしています。ノードコンパイルプロセスにおいて、現代コンパイラは以下のような利点をもたらします：

ノードのアップグレードは証明とは無関係になる。最新のEIPやハードフォークのために回路を実装する必要はなく、ソースコードの更新だけで済む；
LLVMのようなツールチェーンからコード最適化を無料で得られる；
クロスコンパイルによりさらに多様性が生まれる。前述の例では、TaikoがGethやRethをRICS-VやWASM命令セットにコンパイルすることで、すでに4種類の証明を備えている；

SNARKsコンパイルは今後のTaikoの重点分野です。PLONKやR1CSといった算術化手法とHalo2、eSTARK、Supernovaといったバックエンドの間で符号化を行う際、特定の単一ZKプロトコルに制限されないことがポイントです。一方、一体型のZK-VM/EVMは特定のZKP向けにバックエンド実装が行われます。多くのプロジェクトが互いのコンポーネントを採用して性能向上を目指す中で、技術スタック全体がモジュラー化されていくでしょう。

ZKP研究分野は急速に進展しており、柔軟性は最新成果の直接実装よりも重要です。この柔軟性を保つために、Powdr LabsやRisc Zeroなどのプロジェクトと協力し、クロスコンパイルパイプラインを開発し、可能な限りモジュラー化を進めています。

技術に詳しい読者のために、具体的な利点を以下に列挙します：

コンパイラを最適化して、高度ゲート（high-degree gates）を好むようなバックエンドターゲットや、より多くのルックアップパラメータを使用するものに最適化できる；
KeccakやPoseidonハッシュ関数などの高速化回路をライブラリとして実装できる；
LogUpのようなZK機能を段階的に言語に追加し、対応するバックエンドを有効化できる；
新しいZKバックエンドフレームワークを統合することでスピードアップできる。研究志向のZKプロジェクトでは、概念実証（PoC）がコードとしてしか開発されておらず、実運用環境での使用が難しいことが多い。コンパイラが主要な作業を担うことで、初期段階のフレームワークも容易に適用できる；
Halo2で書かれたPSEのZK-EVMコンポーネントなど、既存のバックエンド回路も直接呼び出して再利用できる；

共同の取り組みにより、Taikoは開発過程でRisc ZeroのzethおよびZK-VMを統合し、それにSGXバックエンドを追加開発しました。また、TaikoのエンジニアはPowdrをマルチプルプルーフシステムに統合し、PIL言語とライブラリを開発し、コンパイルを最適化し、さらに多くのバックエンドを追加し、一般的な低レベルの高速化処理を行っています。ハードウェアレベルでは、Taikoのゼロ知識アクセラレーションレイヤー（ZAL）は、証明システム（Halo2、Arkworks、Risc Zero、Polygonなど）とアクセラレーションライブラリ（CPU、GPU、FPGAなど）間の協働関係を標準化することを目指しています。

オープン性

ノード、証明システム、統合バックエンドが多ければ多いほど、オープン性は高まります。そこでTaikoは、コミュニティ全体を結集しようと努力しています。Taikoチームは他プロジェクトとの長い協力歴を持っており、例えばPSEとはZK-EVMおよびRisc Zeroの分野で協力しています。

今後、よりモジュラーなZKスタックを構築することで、TaikoはAPIの抽象化を効果的に行い、普及と統合を促進できます。Taikoはプラットフォームとして、実証システムを本番環境に届け、オンチェーンで実戦テストを行う。Taikoはあらゆるプロジェクトに心から参加を呼びかけ、より良いゼロ知識技術を共に創り上げましょう。

Taiko Stack

Taikoのmulti-proofパラダイムにとって、スケーラブルで柔軟なインフラストラクチャは極めて重要です。

ZK有効性証明の源となるのはノードのステートログ（Execution Trace）とストレージ証明（Storage Proofs）であり、これらはwitnessデータと公開入力の構築に使われます。ここで注意すべきは、witnessesは証明ごとに固有のものである一方、公開入力はプロトコルに関連するものだということです。witnessesの生成を扱う強力なインフラを持つことは非常に重要です。そこで、我々は軽量ホストを使ってMulti-Clientからステートログを取得し、それを複数の証明システムに対応する複数のwitnessに変換します。

証明側では、この設計はモジュラー式および一体型スタックの両方をサポートしており、現在のターゲットノード（Geth）から同じ公開入力を抽出しています。

将来、ステートログのフォーマットが互換性を持っていれば、GethはTaikoノードとして別のノードに置き換え可能になります。また、証明システム上で動作しているライトノード（現時点ではReth）も、アセンブリ言語を受け入れる任意の実装にコンパイルして置き換え可能です。

キーポイント

Taikoは、マルチプルプルーフ＝Multi-Client＋複数のSNARKs（およびSGXのようなTEE）だと信じている；
Taikoプロトコルは、オープンなmulti-proofサプライチェーンを持ち、type-1実行をサポートし、L1上にデータ可用性を発行するため、Multi-Clientシステムに非常に適している；
Taikoは、モジュラーかつオープンなmulti-proofアーキテクチャを描いており、Powdr Labsと協力してノードとZKPのクロスコンパイルを活用し、Risc Zeroと協力してZK-VMおよびTEE上でのTaikoの実行を実現している。また、PSEとも連携し、ZK-EVMプロジェクトの改善に継続的に取り組んでいる；
Taikoの柔軟なインフラには、モジュラー式および一体型のZKPスタックが含まれている；