Polygon zkEVM Node
1. 全体像
https://scrapbox.io/files/62efb9752f7392001d8dff65.pnghttps://scrapbox.io/files/62efb97c5e5bd4001d4ed88f.png
1.1 PoE : Proof of Efficiency
誰が次のバッチ作成者になるかを決定するもの
チームはまだ、最適なコンセンサス構成やDA戦略を確定していない
1.2 Tusted Sequencer
Txをまとめる人(トランザクションを選択し、特定の順序に並べ、L1 にバッチで送信する役割)
この役割は、単一のエンティティによってのみ実行することができる
これはスマートコントラクトで強制され、Tusted Sequencerの関連メソッドは、特定の秘密鍵の所有者によってのみ実行可能
1.3 Permissionless sequencer
TBD
ScrollではSequencer+Aggregator = Roller。また、Sclrollでは同名のSequencerはL1-L2の人として定義される
1.4 Aggregator
Proof作る人
この役割は誰でも行うことができる
1.5 Syncronizer
L1-L2のやりとりする人
2. AggregatorとZKP
https://scrapbox.io/files/62efb98328c7fa0023dd5e47.pnghttps://scrapbox.io/files/62efb98806cccc002186cacb.png
具体的には以下のようなZKP機構となる
https://scrapbox.io/files/62f0e4f6539b17002393607f.png
2.1 PIL
VMのオーバーヘッドを吸収し、計算量を大幅に削減する
Lookup Table的なもの
2.2 STARK
ステートマシンは多項式制約を生成する。それらのバッチに対し、制約を満たすことを証明することが目的
FRI
2.3 SNARK
STARK PloofはSNARK Ploofより大きいので、STARK Ploofをはるかに安価なSNARK Ploofに変換したものをValidity Proofとして公開することが目的
PLONK(Plonky2)とGROTH16のどちらのSNARK証明がzkEVMに使用されるかは、今後議論されるべき問題
Groth16がセキュリティの根拠として記述されている部分もあるので、真偽はわからない.実装はgroth16だった 2.4 Circom
SNARK Ploofの生成や検証に使用できる回路を生成することが目的
Circomでコンパイルすると、検証用Solidityファイルが生成され、それがデプロイされる
3. Aggregatorが持つProver以外の役割
Aggregatorは以下の三つのサービスを提供する
3.1 Proverサービス
EVMトランザクションのバッチ(input)を実行し、結果のstateを計算し、PIL多項式の定義とその制約に基づく計算の証明を生成するProverコンポーネントを呼び出す
Proverサービスから呼び出されたExecutorコンポーネントは、入力データを処理する14個のステートマシンを組み合わせて、証明の生成に必要なコミット型多項式の評価を生成する。
各ステートマシンは計算の証拠データを生成し、より複雑な計算の実証は次のステートマシンに委ねられる。
ProverコンポーネントはStarkコンポーネントを呼び出し、Executorステートマシンがコミットした多項式の証明を生成する。
3.2 Executorサービス
EVMトランザクションのバッチを実行し、結果のstateを計算するExecutorコンポーネントを呼び出す
証明が生成されるわけではない
3.3 StateDBサービス
システムの状態（Merkle木）と状態が保存されているデータベースにアクセスするためのインターフェイスを提供する
これは、stateの単一のソースとして、上記二つのサービスによって使用される
実装を見ると全てのサービスはRPCを介してnodeに提供される より詳細には、以下のアーキテクチャとなる。Etherman:はEthereumネットワークおよび関連するスマートコントラクトと対話するために必要なメソッドを実装するもの
https://scrapbox.io/files/62f270f06f3d29001da68ec4.png
4. State Machinesについて
https://scrapbox.io/files/62efb98fbd8617001dffe2e5.pnghttps://scrapbox.io/files/62efb995b0a31c001d8e4cdd.png
4.1 Main Executor
zkEVMの実行を処理するもの
特別に開発した新しいゼロ知識アセンブリ言語（zkASM）を用いてEVMバイトコードが解釈される
また、Executorは、有効なトランザクションの各バッチが満たさなければならない多項式制約を設定する
多項式制約の符号化には、チームが特別に開発したPIL（Polynomial Identity Language）と呼ばれる別の言語が使用される
4.2 Secondary State Machines
トランザクションの正しさを証明するために必要なすべての計算は、zkEVMの中でステートマシンとして表現される。
zkProverは、ビット単位の機能（XOR処理、パディングなど）を実行するものから、ハッシュ処理（Keccak、Poseidonなど）、署名の検証（ECDSAなど）まで、複数のステートマシンで構成される
したがって、Secondary State Machinesのコレクションは、zkProverのすべてのステートマシンのコレクションを意味する
それ自体はサブコンポーネントではなく、個々のSecondary State Machinesのための様々なExecutorのコレクションである
zkASMとPILの両方を使用するSMもあれば、各SMが担当する特定の処理に応じてどちらか一方の言語のみに依存するSMもある
ステートマシンの集合は以下の通り。
(a) Binary SM
(b) Memory SM
(c) Storage SM
(d) Poseidon SM
(e) Keccak SM
(f) Arithmetic SM
5. Aggrigator 実装
Aggrigatorの実装を見ていく
code:structure
/*
Prover (available via GRPC service)
|\
| Executor (available via GRPC service)
| |\
| | Main State Machine
| | Byte4 State Machine
| | Binary State Machine
| | Memory State Machine
| | Mem Align State Machine
| | Arithmetic State Machine
| | Storage State Machine------\
| | |--> Poseidon G State Machine
| | Padding PG State Machine---/
| | Padding KK SM -> Padding KK Bit -> Nine To One SM -> Keccak-f SM -> Norm Gate 9 SM
| \
| State DB (available via GRPC service)
| |\
| | SMT
| \
| Database
|\
| Stark
|\
| Circom
*/
5.1Prover class
5.1.1準備
マルチスレッド立てる→リクエスト→シーケンサからバッチを受け取る→JSONにパース
committed polynomialsを格納するためにメモリを確保
5.1.2 実行(Executor)
全てのSM(State Machine)を実行する
5.1.3 STARK Batch
Plookupを使ってる
1. Calculate p_cm1_2ns
2. Caluculate plookups h1 and h2
3. Compute Z polynomials
4. Compute C Polynomial
5. Compute FRI Polynomial
楕円曲線暗号を使って、rowを節約
bit列がテーブルの中にあれば、その多項式は証明される
5.1.4 Proof 2 zkIn
JSON形式でFRIの中身をSNARK用に移し替える作業
5.1.5 Verifier
Proof 2 zkIn
rapid SNARK = FFT 使ったSNARKっぽい
groth16が生成したproofはJSONに置き換えられた後、ディスクに保存される
Circomを使ってる
6. 参考文献