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