Polygon zkEVM架构组成-思路梳理

2023-04-01 14:06:55

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手续费
当前页面是本站的「Baidu MIP」版。发表评论请点击:完整版 »