Polygon zkEVM架构组成-思路梳理
Polygon zkEVM架构组成-思路梳理
zkNode
Synchronizer
- 获取Sequencers提交的transactions
- 获取Aggregators提交的validity proofs
- 监听以太坊链上事件，包括new batches{events中读取的信息->存储database}
- 处理可能的reorgs {检查last ethBlockNum 和 last ethBlockHash 是否已同步}
State子模块
实现了Merkle Tree并连接到DB后台
- 在block level检查integrity（即，关于gas、block size等相关信息）
- 检查某些交易相关信息（如签名、足够的balance等）
- 将smart contract（SC）代码存储到Merkle tree中，并使用EVM来处理交易
Sequencer
- 支持模式：Trusted/Permissionless
- 处理流程：接收L2交易+L2用户支付的交易手续费 -> 对L2交易进行排序 ->生成batches -> send tx{sequences形式}（为Aggregator验证支付费用） -> L1合约 {PolygonZkEVM.sol} -> 存储storage slots
经济模型：向L1提交有效交易，以获利
- 根据利润对pool中交易排序
- 向L1提交batches，支付L1系统代币
Aggregator
- 处理流程：L1合约 {PolygonZkEVM.sol} -> 获取Sequencer提交的L2 batches -> zkProver{特殊链下EVM解析器} -> 生成ZK proof{证明该batch的完整性}-> send tx -> L1合约 {PolygonZkEVM.sol} -> 更新 L2 State root
- 经济模型:Sequencers提交L1 batch时支付的手续费
开支
- 向L1提交validity proof交易成本
- 运行aggregator和zkProver服务器成本
Consensus Contract（PolygonZkEVM.sol）
- 存储Sequencers提交的L2 batches
- 对Aggregator新提交的L2 State root进行validity proof验证
zkProver
- 本质：zk virtual machine来仿真EVM
- 功能：为Aggregator使用，来验证batches并提供validity proofs
- 生成proof：以多项式和汇编语言形式
功能包含如下
Main State Machine Executor：处理zkEVM的执行
- 使用zkASM解析EVM Bytecodes
- 为每个transaction batch设置多项式约束
- 对多项式约束使用PIL进行编码
secondary State Machines : zkEVM中证明交易正确性的每一步计算
zkProver是整个项目中最复杂的部分，包含了多个state machines：
- 一些执行bitwise function的state machines（如XOR/Padding等等）
- 执行哈希运算的的state machines（如Keccak、Poseidon等等）
- 执行验签的state machines（如ECDSA等等）
二级状态机有:
- Binary SM
- Memory SM
- Storage SM
- Poseidon SM
- Keccak SM
- Arithmetic SM
STARK-proof builder
- State machines负责生成多项式约束，zk-STARKs用于证明batches满足这些多项式约束条件
- zkProver使用FRI对zk-STARK证明加速
SNARK-proof builder
size: STARK-proof > SNARK-proof
- SNARK-proof来证明STARK-proof的正确性
- SNARK-proof做为validity proof
- 更便宜地在L1上验证该validity proof
L1-to-L2 Bridge
L1 Contract：部署在以太坊，管理rollups之间的资产转移
负责2个操作
- bridge：将资产由一个rollup转移到另一个rollup
- claim：当合约从任意rollup claim时，使用claim操作
需要有2棵Merkle tree
- globalExitTree：包括了所有rollups的exit trees的所有信息
- mainnet exit tree：包含了用户与主网交互的交易信息
global exit root manager L1的合约负责管理跨越多个网络的exit roots
L2 Contract：部署在某特定的rollup上，负责主网与该rollup之间的资产转移
- 处理rollup端的bridge和claim操作
- 与globalExitTree和rollup exit tree交互以更新exit roots
共识算法PoE
Hermez 1.0 PoD共识缺点
- 特定时间，网络由单一actor控制，可能作弊
- 竞价协议，预测复杂性高
- 参与竞争运营门槛高，导致运营集中，抗审查
Proof-of-Efficiency（PoE）实现
- Sequencer：负责将L2的交易打包为batches并添加到L1的PoE智能合约
- Aggregator：之间竞争，负责检查transaction batches的有效性，并提供validity proofs
PoE智能合约基本接口
- sendBatch：用于接收Sequencer的batches
- validateBatch：用于接收Aggregator的validity proof，进行validate batches
batch fee
根据网络负载情况，batch fee将是可变的，可根据protocol合约中的某个参数来计算
PoE的经济模型
- Sequencer赚L2的交易手续费{相应的validity proof提交后}
- Aggregator赚取Sequencer支付的batch MATIC手续费