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手续费