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

版权属于：区块链中文技术社区 / 转载原创者

本文链接：https://bcskill.com/index.php/archives/1814.html

相关技术文章仅限于相关区块链底层技术研究，禁止用于非法用途，后果自负！本站严格遵守一切相关法律政策！