【完全保存版】zkEVMについて、基礎からしっかり理解しよう！
０ はじめに
本日は、zkEVMについて学んでいきたいと思います。
ちなみに、「zk」とは「zero-knowledge（ゼロ知識）」の略です。
そのためゼロ知識証明を用いたEVMの話となってきます。
１ そもそも、なぜzkEVMが必要なの？
１ ブロックチェーンのトリレンマについて
「ブロックチェーンのトリレンマ」はヴィタリックが提唱した概念です。
「スケーラビリティ」「分散化」「セキュリティ」が全て同時には実現できないという概念です。
そのため、どれか一つを犠牲にするしかありません。
２ イーサリアムにおけるスケーラビリティ
そして、イーサリアムは「スケーラビリティ」を犠牲にしています。
この課題を解決してくれるのが、zkEVMです。
２ ゼロ知識証明とは
具体的な内容に入る前に、ゼロ知識証明についても学んでいきましょう。
ゼロ知識証明（ZKP） とは、ある情報の所有権や有効性を、その情報自体を明らかにすることなく証明する技術です。
よく例に出るのが、「洞窟の問題」です。
私が「とびらの合言葉」を知っていた場合、その合言葉を相手に教えずに、私が知っていることを証明するといった感じです。
詳しくは、こちらをご確認ください。
３ ゼロ知識証明の関係者
ゼロ知識証明では証明者（Pさん）と検証者（Vさん）が出てきます。
合言葉を例にすると、証明者が合言葉を知っていることを証明し、検証者が、それが正しいかを検証します。
４ ゼロ知識証明の条件
ゼロ知識証明には次の３つの条件が必要です。
① 完全性
② 健全性
③ ゼロ知識性
１ 完全性
証明者が正直である時、正しく証明できることが完全性です。
例えば、私が本当に合言葉を知っているのであれば、それが証明できなければなりません。
２ 健全性
証明者が嘘をつこうとする時、それを見破れることが健全性です。
例えば、私が合言葉を知らないのに知っているふりをすれば、検証者は見破れなければなりません。
３ ゼロ知識性
検証者が追加情報なしで検証できることがゼロ知識性です。
例えば、検証者は、ヒントとして合言葉の最初の１文字を要求することができません。
５ ゼロ知識証明の種類
ゼロ知識証明には大きく「対話型」と「非対話型」の２種類があります。
１ 対話型
よく例に出てくるのが「対話型」です。
例えば先ほどの、「洞窟の問題」も対話型です。
何度かやりとりをすることによって、証明者が本当に合言葉を知っているかを確かめていきます。
しかし、やりとりが必要となってしまうので、実際にはブロックチェーンではあまり使われません。
２ 非対話型
ブロックチェーンでは、こちらがメインです。
その名の通り、対話することなく、相手の主張を検証します。
ポイントは２つのアルゴリズムを使うことにあります。
２-１ 証明（proof）の作成
まずは証明者がアルゴリズムに情報を送り、証明（proof）を作成します。
ちなみに、zkEVMが「EVMのルールに則って計算している」という証明の作成に使われることになります。
２-２ 証明（proof）の送付
次は、この証明（proof）を証明者が検証者に送ります。
これはzkEVMで作られた証明(proof)をイーサリアム上のコントラクトに送付する際に出てきます。
２-３ 証明（proof）の検証
最後に、検証者が証明（proof）を検証する関数を使って、証明（proof）を検証します。
関数からは結果が返ってきます。
これはzkEVMで作られた証明(proof)をイーサリアム上のコントラクトの関数で検証する際に出てきます。
６ 非対話型の種類
さらに、非対話型には、有名なものとして、「zk-SNARK」と「zk-STARK」があります。
１ zk-SNARKについて
zk-SNARKは2012年に登場し、Zcashを始めとした多くのプロジェクトやコード、開発者が存在しています。
実際に、下の記事で扱った３つのプロジェクトは、全て「zk-SNARK」です。
一方、次の２つの問題もあります。
①量子耐性がない
②信頼されたセットアップが必要
詳細はこの記事をご参照ください。
２ zk-STARKについて
一方、zk-STARKは2018年に登場しました。
zk-SNARKが抱えていた問題であった、量子耐性を持ち
「信頼されたセットアップ」も必要ありません。
有名なプロジェクトとしては「StarkNet」などがあります。
一方、zk-STARKは現時点で、ドキュメントや開発者が少ないという欠点もあります。
７ EVMの機能について
では、ここからは、EVM（イーサリアム・バーチャル・マシン）の話にいきましょう。
このEVMには大きな２つの役割があります。
１ コントラクト計算（smart contract computation）
EVMは、Ethereumブロックチェーン上でスマートコントラクトを実行するソフトウェア環境です。
これを「コントラクト計算（smart contract computation）」 と呼びます。
つまり、各ノードが計算を行わなければなりません。
２ 状態計算(state computation)
EVMはまた、各スマートコントラクトを実行した後、イーサリアムチェーンの有効な状態を計算し更新します。
これは 「状態計算(state computation)」 と呼ばれます。
３ なぜ上の２つをEVMでやる必要があるのか
EVMで①計算と②状態の更新をしなければいけないのは大変そうです。
なぜそれを基本的にはオフチェーンでできないのでしょうか？
それは、オフチェーンでやると、「本当にEVMのルールに則ってやっているのかが証明できない」ためです。
逆い言えば、EVM内でこの２つを行えば、EVMのルールに則ってやっていることが明らかです。
４ zkEVMを使った解決
上の問題は、オフチェーンでやることで、「本当にEVMのルールに則ってやっているのかが証明できない」ということでした。
ということは、オフチェーンであっても、それが証明できれば、オフチェーンでやることが可能です。
下のような構成になります。
計算はオフチェーンで行いますが、その証明（proof）をEVMに送ります。（実際には、特定のコントラクト）
ゼロ知識証明によって、この検証が可能であるため、EVMのルールに則ったまま、オフチェーンで行うことが可能です。
８ 実際にzkEVMでコントラクトを作ってみよう！
理論が分かりましたら、後は作ってみましょう！
エンジニアの方でなくても、この記事に沿っていただければ、zkEVMでコントラクトのデプロイを行うことが可能です。
なお、フロントエンドとの連携などについては、こちらをご参照ください。
ぜひやってみてください。
９ 証明（proof）の検証の部分を見てみよう
では、実際の検証の部分をpolygon zkEVMを例に見てみましょう。
ちなみに、以下、テストネットで行っているので、イーサリアムとあるところは、実際にはGoerliです。
まず、下が実際のデータです。
１ 送信者について
コントラクトに送るのは、アグリゲータです。
64173番から64261番までのバッチをコントラクトに送ります。
バッチの中にはトランザクションが入っています。
２ 送付先コントラクトについて
送り先はイーサリアムチェーンの検証を行うコントラクトのプロキシです。
（プロキシについてイメージが湧きにくい場合は、一旦は、検証を行うコントラクトに送ると考えて良いと思います。）
このコントラクトにある、検証を行う関数で証明（proof）の検証を行います。
ここまでのイメージは、このようになります。
３ 証明（proof）の送付について
最後に、証明（proof）を送る箇所を見てみましょう。
下のように入力データの一つに証明（proof）が含まれています。
４ コントラクト内での検証について
では、コントラクトのコードを簡単に見てみましょう。
下の、「verifyBatchesTrustedAggregator」を実行しています。
そして、この中で、「_verifyAndRewardBatches」という関数を実行しています。
「_verifyAndRewardBatches」関数はこちらになります。
この中で、proofを用いて、下のように検証を行っていることが確認できました。
以上が検証の部分になります。
詳細はこちらをご確認ください。
以上で、zkEVMについての記事を終わりにします。
最後までありがとうございました！
いいなと思ったら応援しよう！
