1. 引言
前序博客有：
Polygon zkEVM网络节点代码见：
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版实现：尽管
Prover/Executor是完全相同的软件/服务，但是，实际运行时具有不同的目的：- （a）作为
Executor：提供EVM实现，支持交易处理，并获得所需result metadata（如state root、receipts、logs） - （b）作为
Prover：生成ZKPs
- （a）作为
-
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运行在分离的实例之上，因其对硬件有重要的要求。此外，其它模块可运行在单一实例上。