Polygon zkEVM网络节点-Toy模板网

这篇具有很好参考价值的文章主要介绍了Polygon zkEVM网络节点。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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的共识协议，由智能合约强化。

Polygon zkEVM网络节点

2. Polygon zkEVM网络总体架构

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实现在同一仓库内）。