見出し画像

Type 1 ZK-EVM “Taiko”を理解する

sholanaのshohyo

TL;DR

Taikoは、EthereumのスケーリングソリューションであるZK-Rollupの一つで、Ethereumの実行環境と互換性があるため "ZK-EVM"と呼ばれている。ZK-EVMといえば、zkSync Era、Polygon Hermez、Scroll等様々なプレイヤーがまとめて語られることが多いが、実際にはEthereumとの互換性の度合いにおいて非常に大きな違いがある。

Taikoは、これらのソリューションの中でも最もEthereumとの互換性が高い "Type 1"と呼ばれるZK-EVM Rollup Layer2だ。Ethereumとの完全な互換性を持つため、Ethereum上の開発者は一切のコストをかけずにコントラクトをTaikoへmigrateできたり、Ethereum上で動かしていたツール等をそのままTaikoで使用することができる。Ethereumの開発者である Vitalik Buterinは多くのインフラストラクチャーを再利用でき、Ethereumの真のスケーラビリティ向上に寄与できるという点で、このType 1 こそが理想的なZK-EVMであると自身のブログポスト内で述べている。

一方で、Ethereumとの互換性を追い求めることには一定のデメリットも存在する。それがRollupの速度、正確に言えばzk-proofというL2でのトランザクションの正当性証明の生成時間が遅く、コストが高くなることである。zkSync等、他のZK-EVMプロジェクトはこのトレードオフを認識し、Type 1を最初から目指さず、互換性を犠牲にした上でzkpの生成時間・コストを下げようと取り組んでいる。

Taikoはこの Type 1のデメリットに対して明確な回答を持つ。Type 1に固有な生成時間の遅延が起きるのは特定の状況下のみであるとし、それに対して独自の解決策 (instant withdrawals) を考案し、実装に取り組んでいる。この解決策はTwitter上でも大きな反響を呼び、Vitalikもそのロジックに対して肯定的な反応を見せた。また、コスト問題に関してもHyperPlonk, Caulk等の新たなzkpの生成アルゴリズムを実装することにより解決できると楽観的な姿勢を公表している。

更に、Ethereumのハッシュ暗号アルゴリズムやGas costに関する変更を加える Type 1以外のZK-EVMには大きなセキュリティリスクを抱えているということも、TaikoがType1を目指す理由の一つである。Ethereumに実装されているコントラクトは、Ethereumの特性に最適化されたものが多いだけでなく、一部にはKeccakのようなハッシュ暗号アルゴリズムや、EIP1559基準のGas Algorismにセキュリティを依存している場合がある。

本記事は、Ethereumのスケーラビリティ問題、そしてZK-Rollupというソリューションについて聞いたことがある、という方向けにZK-EVMの現状、Type の概念、TaikoがType 1を選択した理由、Type 1のデメリットを克服する方法、その他Taikoが取り組むスケーラビリティ向上等に向けた取り組みについて、TaikoやZK周りの有識者が発表している情報を簡潔にまとめたものである。

比較的長い文章であるので、できるだけこのTL;DRのみで全体像を掴み、Taikoに対する理解が行えるように設計してある。以下の文章はTL;DRにて提示された情報を検証するために利用することを推奨したい。


導入

L1ブロックチェーンであるEthereumのスケーラビリティ問題、そしてそれを解決するために世界中で様々な手法が実装されていることは周知の事実でしょう。そうした解決手法の中でも、ゼロ知識証明を用いたZK-Rollup、特にEVMとの互換性があるZK-EVMなどは現在ホットな領域です。2023年の2月には、zkSyncがZK-EVMのメインネットを公開し、大きな反響を呼びました。zkEVMの実装にはzkSyncの他にも、ScrollやPolygon Helmez等、様々なプロジェクトが取り組んでいます。今回紹介するプロジェクト “Taiko”もその一つですが、実はこれらのプロジェクトは同じZK-EVMというカテゴリの中でも異なる種類に分けられるのをご存知でしょうか。

タイトルにあるType 1というのが、正にこのZK-EVMの種類の一つです。ZK-EVMは、Type 1 / Type 2 / Type 2.5 / Type 3 / Type 4 という5つのタイプに分けられます。これはEthereumの開発者として知られる Vitalik Buterin氏が自身のブログポストで公開した分類方法です。

The different types of ZK-EVMs

この数字は、各プロジェクトのZK-EVMとEVMの互換性の度合いによって決定されます。数字が小さいほど、EVMとの互換性が高くなります。

Type 1はEthereumと完全に同じロジックを用いて設計されているZK-EVMであり、真の意味でEthereum L1のスケーラビリティ向上を実現します。また、イーサリアムからのスマートコントラクトのmigrateが楽だったり、block explorerやblock productionに使用される様々なツールをそのまま利用できるという、クライアント側のメリットも多くあります。その一方、デメリットも存在します。イーサリアムで使用される暗号は、そもそもzk-friendlyなものではないため、proofの生成に時間とコストがかかってしまうのです。

Type 4はスマートコントラクトのソースコードをZK-SNARKに適した言語にコンパイルしてproofを生成します。迅速で安い手数料を実現できますが、一部のアプリケーションとの互換性が失われていたり、インフラストラクチャーの部分でイーサリアムと一部異なる実装が必用になるため、クライアントに一定の作業を要求する点がデメリットになります。

Vitalik氏曰く、Type 1 ZK-EVMはイーサリアム上の多くのインフラストラクチャーを再利用できるため、roll-upとしては理想的であるとしています。

EVMとZK-EVM

Type毎の説明に入る前に、簡単にEVMとZK-EVMの仕組みを理解しましょう。
EVM (Ethereum Virtual Machine) はスマートコントラクトの仮想実行環境です。人の手で書かれたSolidityのコードを機械語であるBytecodeに変換し、トランザクションを実行してイーサリアムの状態を更新します。

ZK-EVMはEVMと同じようにスマートコントラクトを実行することができますが、イーサリアム上で検証可能なzero-knowledge proof (zkp) を発行できる点でEVMとは異なります。ZK-EVMではトランザクションをバッチ処理してブロックを生成し、その情報をL1へ伝達するのですが、zkpはその圧縮されたデータが正しいことを数学的に証明する証拠 (proof) だと思って頂ければ問題ありません。

Type毎の性質とプロダクト

ここはほとんどがVitalik氏のブログポストからの引用になるため、簡単な概要の和訳にとどめます。Typeを理解する際に重要なのは、互換性とパフォーマンスの間にトレードオフがあることです。基本的にTypeの数値が小さくなれば小さくなるほどイーサリアムとの互換性は向上しますが、その一方でproofの生成にかかる時間・手数料コストも増加することになります。

Type1 (Fully Ethereum-equivalent / EVM相当)

先述した通り、Type 1 ZK-EVMは現在のイーサリアムのシステムを一切変えることなく実装されるため、zk-proofの発行がより容易です。Ethereumベースのアプリケーション全てと互換性があり、block explolerやexecution clientのようなツールを使い回すことができます。ただし、Ethereumの仕組みではzkpを発行するのに大量のコンピューティングパワーを使用するため、コストと時間がかかるのが難点です。現在では、Taikoの他にzkEVM Community Edition等が有名です。

Type 2 (Fully EVM-equivalent)

Type 2は、現行全てのイーサリアムアプリケーションとの互換性がある状態を目指します。しかし、zkpの生成においてはいくらかのマイナーチェンジを行い、より迅速なzkp生成に取り組もうとしています。確かにType 1 zkEVMと比較すれば早い生成が可能ですが、まだ遅すぎるというのが現状の評価です。現在は、ScrollやPolygonの開発するZK-EVMである Polygon HermezなどがType 2を目指していますが、現状ではType 3であるとVitalikは評価しています。

Type 2.5 (EVM-Equivalent Except for Gas Costs)

Type 2.5は基本的な部分ではType 2と同じですが、特定のガスコストを増加させることによって最も生成が困難なzkpの証明時間を短縮できるという点で異なるそうです。しかし、それにより一部のアプリケーションとの互換性がトレードオフになる点が指摘されています。zkSync EraはこのType 2.5を目指しています。

Type 3 (Almost EVM-equivalent)

Type 3は、アプリケーション開発や証明の生成を容易にすることにより重点を置いています。プリコンパイル、VMメモリ、スタック、スマートコントラクトコードの扱い方に変更を加え、EVM機能を一部犠牲にしています。
ほとんどのイーサリアムアプリケーションとの完全な互換性がある一方、一部では書き換えが必用となるケースがあります。
(どのようなアプリケーションが犠牲になりそうかについて解像度がある人がいれば教えて下さい)

Type 4 (High-Level-Language Equivalent)

Solidityのようなイーサリアムのスマートコントラクトに使用される高級言語を、ゼロ知識証明に最適な言語 にコンパイルするシステムを持ちます。これらの言語は非常に似た性質を持ちますが、EVMでは動作しない言語を利用するため、コントラクトアドレスが変わるなどのデメリットが発生しえます。しかしながら、他のTypeのZK-EVMと比較してもはるかに早い速度で証明の生成が行えるようになり、コストも削減できます。zkSync Eraは最初Type 4から実装を始め、最終的に2.5を目指す予定です。

https://blog.chain.link/zkevm/ より画像引用

Type 1 ZK-EVM Taiko

さて、ようやく今回の記事の本題、Taikoの解説に入ります。Taikoは先述した通り、Type 1 即ちイーサリアムとの完全な互換性 (= Ethereum Equivalent) を目指すZK-EVMになります。

VitalikはType 1こそが理想的なRollupというものの、実際にはコストとのトレードオフが存在することを忘れてはいけません。事実、現在最も注目を集めるZK-Rollupである "zkSync Era"は、現段階ではType 4のZK-EVMを構築しながらType 2.5を目指しています。というのも、Type 1, Type 2はイーサリアムのガスコストアルゴリズム (EIP1559) を参照するため、ガス代やスループットの向上といった、Rollupの主目的を達成することが難しいと考えているからです。彼らは2022年の9月に、"compatability vs equivalence" というテーマでこれを題材に講演を行っています。

Type 2 would mean that your gas calculation is exactly the same as in Ethereum, with every opcode metered in the same way as on layer one. However, this approach is disadvantageous and counterproductive, as the cost profile in layer twos will always be in favor of cheaper computation and storage over layer one.
タイプ2は、ガス計算がイーサリアムと全く同じで、すべてのオペコードがレイヤー1と同じ方法で計測されることを意味します。しかし、レイヤー2におけるコストプロファイルは、常にレイヤー1よりも安い計算とストレージが有利になるため、この方法は不利で逆効果です。

ZK8: zkEVM: compatibility and equivalence - Alex Gluchowski - zkSync / youtube.com

Taikoは、Type 1 ZKEVM Rollupとして、この問いへの明確な解答を持っています。なぜ彼らはType1 という部分にこだわりを持ち、そしてどのようにしてコスト、スループットの限界を突破しようとしているのでしょうか。

Why Type 1?

Taikoが Type1 ZK-EVMにこだわる理由は大きく分けて、① 開発者の利便性、② イーサリアムエコシステムへの貢献、そして③互換性を失うことで得られる不利益の回避の3つに分かれます。

① 開発者の利便性 : Type 1 ZK-EVMはイーサリアムのアーキテクチャーと完全な互換性を持つため、開発者はコードや開発環境の変更を一切行わずに、イーサリアムL1上のプロトタイプ、開発、テスト、監査、デプロイを行った後、Taikoに移行することができます。また、逆にTaikoで開発をしてから、イーサリアムL1や別のEVM互換チェーンに移行することも容易になります。

② イーサリアムエコシステムへの貢献 : Type 1 ZK-EVMは、現行のイーサリアムアーキテクチャとの互換性を維持するだけではなく、将来のイーサリアム
アップグレードも継承します。常に最新の改善に追従するため、イーサリアムL1のスケーラビリティ改善に常に貢献することができます。

③ 互換性を失うことで得られる不利益の回避 : Type 2+のZK-EVMは、暗号アルゴリズムや、ガスコストのロジック等、様々なところでzkpの生成に最適化させたアップデートを行います。彼らは、これらの更新により起こる副作用を回避するために、互換性への強いこだわりを持ちます。以下では、Taikoチームが考える、イーサリアムのシステムに変更を加えることによる不利益をいくつか解説していきます。

  • ガスコストの仕組みを変更することによる不利益 (主にType 2.5+)

    • セキュリティの仕組みが変わる可能性があります。Ethereumには、いくつかのガスコストを用いてセキュリティを担保する仕組みがあります。例えば、ETHの transfer関数を利用する際に固定ガス上限を設定し、宛先のアドレスで状態変更ができないようにすることなどが挙げられます。いくつかのスマートコントラクトは、このセキュリティに依存しており、そうしたコントラクトは、Type 2.5+の L2上ではもはや安全ではなくなる可能性があります。

    • ガスコストが最適化されない可能性があります。基本的に、スマートコントラクトは、L1のガスコストの仕組みに最適化されています。そのためL2上でガスコストの仕組みを変更した場合に、ガス代が最適化されず、実行に余計なガスコストを支払う必用が出てきます。また、コントラクトのガス使用量を調整するためのツールを使用している場合には、そのようなツールが再利用できないという問題点もあります。

  • ハッシュ暗号の仕組みを変更することによる不利益 (主に Type2+)

    • Type 2+のZK-EVMは、異なるハッシュ関数を使用し、異なる state-tree を生成する可能性があります。この変更により、ブロックハッシュに依存するスマートコントラクトの互換性が失わてしまうかもしれません。例えばブリッジのコントラクトでは、検証にMarkle proofを利用している可能性があり、ハッシュ関数をKeccakから変更した場合に、これらの証明が機能しなくなる可能性があります。

    • Keccakを使用しなくなることによる危険性

      • Keccakは広く世界で使われている、歴戦の暗号の一つです。これを代替関数に変更することにより、多くの互換性の消失やセキュリティリスクが発生する可能性があります。

このように、イーサリアムとの完全な互換性を持つことによって得られるメリットと、完全な互換性を捨てることで生じるデメリットがあり、それらを考慮した上で彼らはType 1を目指すことを選択しています。

How solve the problems?

彼らは、Type 1 ZK-EVMに固有の問題であるzkpの生成時間の遅延に対して、そもそもzkp生成の遅延は一部のユースケースでしか問題にならないという前提の下で、その特定のユースケース (ブリッジ) における独自の解決策である、instant withdrawalsを提示しています。この解決策には、Vitalk Buterinも肯定的な反応を示しており、一定の信頼性を持つソリューションの一つであることが伺えます。
また、生成コストに関して、現在開発されているHyperPlonk, Caulk等の新しい低コストな生成手段が生まれていることを根拠に楽観的な姿勢を持っています。以下はその引用になります。

We are not concerned about the longer time to finality because we achieve instant finality through our protocol design, by circumventing the need to wait for a proof when on the rollup (proposed blocks have the same finality as the enclosing Ethereum L1 block, see: Layer 2 Finality). In the case where a proof is needed, such as moving assets to another layer, we are optimistic about new methods for bridging that don’t require a full proof.

The Type 1 ZK-EVM / mirror.xyz

以下に論点を整理した簡単な箇条書きと、各種理解を深めるための画像・tweetを添付しておきます。

  • そもそもzkpの生成 / 証明時間は最大の問題ではない

    • 現状でzkp生成の遅さを感じるペインポイントは、ブリッジによるLayer2からのwithdrawくらいしかない

      • instant withdrawalsによって解決可能

        • = あるstateXが証明されているとき、withdrawが行うことができる資産がなってしまうような変更がなければ、stateXのアカウントから即座に資金を引き出すことができる。

        • Vitalikもこの考え方について肯定的な意見を示している

https://hackmd.io/@taikolabs/HkN7GR64i#/

  • 他の一般的なユースケースでは、既に迅速なzkp生成に成功している。

  • FTの流動性提供者もinstant withdrawalsの恩恵を受けられる。

    • 上記3つより、zkp生成に於ける本当の問題は生成時間ではなく、どちらかといえばコストであることがわかる

  • zkpの生成コストに関しては、Taikoチームは楽観的。

    • より効率的なzkp証明システムが生まれている (HyperPlonk, Caulk, 等)

    • proofの最適化とtricks (??) が行える。

    • 完全にEthereumをSNARK-friendlyにするためのコミュニティの取り組みを行っている

    • zkp計算に特化したハードウェアの開発が進んでいる

https://twitter.com/finestonematt/status/1588599348765786113/photo/1

https://twitter.com/finestonematt/status/1588599264862576640?s=20

Taikoが行うzk-rollupとしての取り組み

Taikoは、zkp生成のコスト・時間の削減に向けた取り組みの他にも、完全な互換性を持つイーサリアムスケーリングソリューションとしての役割を果たすため、いくつかの固有な取り組みを行っています。ここではそれぞれについて簡単な説明を行います。

  • Proposer / Proverのインセンティブ設計

Taikoでは、L2上での新たなブロックの生成、そしてそのブロックの正当性証明のためにそれぞれProposer, Proverというプレイヤーが存在します。彼らはそれぞれ異なるリワード設計によりネットワーク貢献のインセンティブを持ちます。今回は特にProposerのリワード設計が、スケーリングを意識した、ユニークな仕組みなので紹介します。
Proposerはブロックの生成者ですが、Taikoはプロトコル初期段階で彼らのインセンティブを最大化し、チェーンの拡大に伴って徐々にそれを減らしていくことでProposerの数をバランス良く保とうとしています。 (Bitcoinの半減期と思想的には似ています) この仕組みを用いることでプロトコル開始時にProposerが利益のあるブロックを作成しやすくなります。
Taikoはこのインセンティブを時間経過によって調整する仕組みである、ディスカウント関数とディスカウント乗数を導入しました。

ディスカウント関数d(t)は、初期ディスカウント率定数Kdisc ∈ (0, 1]と、半減期定数KHalving > 0を用いて計算されます。
d(t) = Kdisc · (1/2)^(⌊t/KHalving⌋)
ここで、tは経過時間を表します。
ディスカウント乗数γ+(t)は次のように計算されます：
γ+(t) = 1 − d(t)
時間が経つにつれて、この乗数は1に近づくため、その効果は時間とともに減少します。ディスカウント乗数は、全体的な提案手数料計算に適用されます。
f(t) = fbase · α+(t) · β+(n) · γ+(t)

Taiko ホワイトペーパーより計算式引用

  • データ圧縮 / シグネチャ圧縮

この二つは、Taikoの将来的なアップデートの中で実装される要素です。L1に格納されるデータ量を削減することで、コストを大幅に削減できます。

  • データ圧縮

    • DEFLATE等のデータ圧縮アルゴリズムを回路 (zk-SNARKやzk-STARK等のゼロ知識証明スキームで使用される計算プロセス) 内に効率的に実装することで、L1に公開するデータを大幅に圧縮し、コストを削減することが可能です。

      • Taiko ホワイトペーパー 9.4. Block Data Compression

  • シグネチャ圧縮

    • シグネチャ圧縮では、ブロック提案者が提案されたブロック内のすべてのトランザクションに有効な署名があることを示すことができれば、ブロックデータからシグネチャ (署名) を削除できます。これは、ブロック生成と同時に生成されるzk-proofによって可能になります。

      • Taiko ホワイトペーパー 9.3. Signature Compression

  • その他 (比較的一般的な論点なので個別の解説は割愛します) ※一般的な論点 : Taiko以外でも議論される論点

    • EIP-1559によるレート制限およびプルーバー手数料の動的なバランス調整

      • Taiko ホワイトペーパー8.1. Motivation

    • EIP-4844が有効になることによる、スループットの向上

      • txListデータを Transaction Dataではなく、Data Blobに格納することで保存コストを削減する。

        • 9.1. Taiko ホワイトペーパー Ethereum Data Blobs

終わりに

今回はType 1ZK-EVMであるTaikoについて記事を書いていきました。基本的には "Type 1 : Ethereum Equivalence" という概念に焦点を当て、そのポジショニングの妥当性を検証するという目的の下で全体の構成を行いました。読者の皆様にとって有益な情報が提供できていれば幸いです。

筆者個人の意見としては、Type 1を目指すTaikoは最も注目すべきZK-EVMとして間違いないと思いますし、まだまだUndervalueされているな〜〜ということでかなーり力を入れて書いたつもりです。彼らはこのETH TOKYO期間は日本におり、自身のイベントも主催しているので、是非興味がある！という方は彼らにアタックしてみてください。(4/16夜です https://lu.ma/azi3jj9r)

Taikoの面白さは正直、この記事では全く書ききれておらず、さらなる他プロジェクトとの差異やProposerの分散性等についても今後書いていきたいな〜〜と言った次第です。

それでは皆さん！よきL2ライフを！

Reference


この記事が気に入ったらサポートをしてみませんか？