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 sequencer的broadcast获取数据并更新state（为trusted state）。同时synchronizer还会发现并处理reorgs，reorgs情况仅发生在：trusted sequencer通过broadcast发送的数据 与 发送到L1的sequences数据 不同时（即trusted state与virtual state不同时，会进行reorg）。

• 8）State：负责管理存储在StateDB的状态数据（batches、blocks、transactions等），同时State还会处理与executor和Merkletree服务的集成。

• 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运行在分离的实例之上，因其对硬件有重要的要求。此外，其它模块可运行在单一实例上。