1. 引言

前序博客有:

  • Polygon zkEVM——Hermez 2.0简介

Polygon zkEVM网络节点代码见:

  • https://github.com/0xPolygonHermez/zkevm-node(Go语言)

1.1 Polygon zkEVM 关键词

Polygon zkEVM网络中的关键词汇有:

  • 1)L1:是指rollup合约部署的base链——可为以太坊主网或测试网,也可为任意EVM兼容链。
  • 2)L2:为rollup网络,即Polygon zkEVM网络。
  • 3)Batch:为一组使用zkEVM prover来执行或证明的交易,会将batch发送到L1,也会从L1同步batch。
  • 4)Sequencer:该角色负责:选择交易,将交易排序,将交易打包为batch发送到L1。
  • 5)Trusted sequencer:L2中仅可以有一个trusted sequencer,Trusted sequencer具有特殊权限——可预测将提交到L1的batches,从而可在与L1交互之前,commit to a specific sequence(见后面 “7)Sequence” 解释)。这样可实现fast finality,并降低开销(降低gas费)。
  • 6)Permissionless sequencer:可由任何人承担的sequencer角色。相比于trusted sequencer,permissionless sequencer具有竞争性劣势(如slow finality,MEV攻击)。其主要目的是提供censorship resistance和网络的unstoppability特性。
  • 7)Sequence:由trusted sequencer发送到L1以更新state的数据称为sequence,其包含了batches和其它metadata。
  • 8)Force batch:由permissionless sequencers发送到L1以更新state的数据,仅包含了batch。
  • 9)L2 Block:与L1 block类似,但是为L2的。大多由JSON RPC接口使用。当前,所有的L2 Blocks都设置为仅包含一笔交易,这样做的目的是为了实现instant finality;不需要close a batch,以支持JSON RPC expose已处理交易的结果。
  • 10)Trusted state:是指对 由trusted sequencer 分享来的交易 进行处理所达成的state。该状态被认为是可信的,因为trusted sequencer可commit to a certain sequence,然后send a different one to L1。
  • 11)Virtual State:是指对 已提交到L1的交易 进行处理所达成的状态。这些交易已由trusted或permissionless sequencer打包在batches发送到了L1。这些batches也可称为virtual batches。注意,该state是trustless的,因为其依赖于L1的安全假设。
  • 12)Consolidated state加固状态:已提交a ZKP(Zero Knowledge Proof)在链上证明了the execution of a sequence of the last virtual batch 所达成的状态。
  • 13)Invalid transaction无效交易:是指无法处理的交易,无效交易并不会影响状态。注意,无效交易可被包含在virtual batch内。交易无效的原因可与以太坊协议相关,如invalid nonce、balance不足等;也可能是因zkEVM引入的限制,如每个batch可利用的资源有限,因此可计算的keccak哈希总数有限。
  • 14)Reverted transaction:该交易已执行,但是(因智能合约逻辑)被reverted了。reverted交易与无效交易的区别在于,reverted交易会改变状态——至少会增加sender的nonce值。
  • 15)Proof of Efficiency(PoE):为Polygon zkEVM的共识协议,由智能合约强化。

2. Polygon zkEVM网络总体架构


以上表示的是由trusted sequencer运行的单个节点的架构图。实际网络中会有多种角色运行节点,详情后续再补充。
以上架构图中:

  • 1)(JSON)RPC:为用户(如metamask、etherscan等)与节点交互的接口。与以太坊RPC完全兼容,并附加了一些额外的端口。如与state交互可获得数据的接口;处理交易的接口;与pool交互存储交易的接口。

  • 2)Pool:通过RPC来存储交易的DB,pool中所存储的交易后续可由sequencer来选中或丢弃。

  • 3)Trusted Sequencer:从pool中获取交易,使用state对交易处理以检查交易是否有效,创建sequences。一旦交易被添加到state中,可立刻对broadcast服务可用。sequences可通过etherman发送到L1。

  • 4)Broadcast:由非trusted sequencer运行的节点中的synchronizer使用的API,用于同步trusted state。

  • 5)Permissionless Sequencer:待续。。。。

  • 6)Etherman:对 需与以太坊网络和相关合约 交互的方法的抽象。

  • 7)Synchronizer:通过etherman从以太坊获取数据更新state(为virtual state 或 consolidated state)。若该节点不是trusted sequencer,还会从trusted sequencerbroadcast获取数据并更新state(为trusted state)。同时synchronizer还会发现并处理reorgs,reorgs情况仅发生在:trusted sequencer通过broadcast发送的数据 与 发送到L1的sequences数据 不同时(即trusted state与virtual state不同时,会进行reorg)。

  • 8)State:负责管理存储在StateDB的状态数据(batches、blocks、transactions等),同时State还会处理与executorMerkletree服务的集成。

  • 9)StateDB:为状态数据的持久层。例外情况是,Merkle tree由Merkletree服务处理。

  • 10)Aggregator:通过生成ZKPs(Zero Knowledge proofs)来consolidate强化batches。它会通过向state发送请求来获得prover所需输入数据。一旦proof生成,可通过etherman发送到以太坊。

  • 11)Prover/Executor:生成ZK proofs的服务。注意Prover/Executor并未在 https://github.com/0xPolygonHermez/zkevm-node 中实现,而是从节点的角度将其当成是“黑盒”。
    当前Prover/Executor有2版实现:

    • (a)JS参考版本实现——zkevm-proverjs库
    • (b)C语言生产版本实现——zkevm-prover库

    尽管Prover/Executor是完全相同的软件/服务,但是,实际运行时具有不同的目的:

    • (a)作为Executor:提供EVM实现,支持交易处理,并获得所需result metadata(如state root、receipts、logs)
    • (b)作为Prover:生成ZKPs
  • 12)Merkletree:该服务中存储Merkle tree,包含了所有的账号信息(如balances、nonces、smart contract code 和 smart contract storage)。Merkletree模块也并未在 https://github.com/0xPolygonHermez/zkevm-node 中实现,而是作为节点的一个外部服务。Merkletree的实现见https://github.com/0xPolygonHermez/zkevm-prover(即与Prover/Executor实现在同一仓库内)。

3. Polygon zkEVM节点角色

Polygon zkEVM节点软件支持以多种角色运行,不同的角色启动不同的服务。zkEVM节点软件内的大多数服务都可以不同实例运行,而JSON RPC服务可运行在多个实例中(而所有其它服务仅能有一个实例)。

Polygon zkEVM的角色主要有:

  • 1)RPC角色
  • 2)Trusted sequencer角色
  • 3)Permissionless sequencer角色
  • 4)Aggregator角色

3.1 RPC角色

任何人都可承担RPC角色。
运行RPC角色所需服务和模块有:

  • 1)JSON RPC:可运行在分离的实例中,可具有多个实例。
  • 2)Synchronizer:为单个实例,可运行在分离的实例之上。
  • 3)Executor & Merkletree:为服务,可运行在分离的实例之上。
  • 4)StateDB:为Postgres SQL,可运行在分离的实例中。

必须仅能有一个synchronizer,且推荐对executor实例具有独占访问(并不是必须的)。

RPC角色可运行在单一实例内,但是,若随着收到请求数的增加,性能有所下降的话,将JSON RPC和executor服务运行在多个实例内 是有益的。

3.2 Trusted sequencer角色

Polygon zkEVM网络中仅能有一个实体承担trusted sequencer角色。该角色在智能合约内强化,合约内trusted sequencer的相关方法仅可由具有特定私钥的owner执行。

运行Trusted sequencer角色所需服务和模块有:

  • 1)JSON RPC:可运行在分离的实例中,可具有多个实例。
  • 2)Sequencer & Synchronizer:为一起运行的单个实例。
  • 3)Executor & Merkletree:为服务,可运行在分离的实例之上。
  • 4)Broadcast:可运行在分离的实例之上。
  • 5)Pool DB:为Postgres SQL,可运行在分离的实例中。
  • 6)StateDB:为Postgres SQL,可运行在分离的实例中。

注意,JSON RPC需要接收交易,推荐将JSON RPC运行在分离的实例之上,具体取决于网络负载,可有多个JSON RPC。同时推荐JSON RPC和Sequencer不共享相同的executor实例,以确保sequencer对executor具有独占性访问。

3.3 Permissionless sequencer角色

待续。。。

3.4 Aggregator角色

任何人都可承担Aggregator角色。

运行Aggregator角色所需服务和模块有:

  • 1)Synchronizer:为单一实例,运行在分离的实例之上。
  • 2)Executor & Merkletree:为服务,可运行在分离的实例之上。
  • 3)StateDB:为Postgres SQL,可运行在分离的实例中。
  • 4)Aggregator:为单一实例,运行在分离的实例之上。
  • 5)Prover:为单一实例,运行在分离的实例之上。
  • 6)Executor:为单一实例,运行在分离的实例之上。

推荐将prover运行在分离的实例之上,因其对硬件有重要的要求。此外,其它模块可运行在单一实例上。