zkEVM 系列（2）：Polygon zkEVM 关于 Sequence 和 Bridge 更多的技术细节

作者: 0xhhh，EthStorage （Twitter:@hhh69251498)

在pogon zkEVM的第一篇文章里（zkEVM系列（1）｜Pogon zkEVM的整体架构和交易执行流程），我们总结了Pogon zkEVM 的整体框架以及交易执行流程，同时也分析了Pogon zkEVM是如何实现计算扩容的同时继承了L1的安全性的；在这篇文章里，我们将依托上篇文章建立的框架，深入pogon zkEVM关于Sequencer和Bridge更多的技术细节，同时也探讨未来潜在的去中心化Sequencer架构的不同特点。

在上一篇文章里，我们介绍Ploygon zkEVM的过程中，实际上缺失了很重要的一个部分，就是Pogon zkEVM 的原生桥。（注：在本文L2特指Rollup, L1特指Ethereum。）

1.跨链数据状态管理

Pogon zkEVM在L1和L2分别维护了一棵Exit Tree,名字分别为L1 Exit Merkle tree和L2 Exit Merkle tree。但是为了更好的管理这两棵树，Pogon zkEVM 很聪明的将这两棵树结合在了一起，如下图:

也就是用分别把L1 Exit Tree Root 作为Global Exit Tree的左叶子节点，把L2 Exit Tree Root 作为Global Exit Tree 的右叶子节点。不过需要注意这里L1 Tree Root 和 L2 Tree Root是Sparse Merkle Tree(T),而Global Exit Tree是Binary Merkle Tree。

L1/L2 Exit Tree叶子节点的基本信息如下:

在Pogon zkEVM的合约设计中，还是尽可能的将Bridge和Consensus合约尽可能的解耦。目前其在L1部署的合约主要分为3个，如下图所示:

1）L1 → L2 的跨链流程

对应以下代码中的BatchData的结构体中的globalExitRoot:

PogonZkEVMBridge在L2的合约

https://testnetzkevm.pogonscan.com/address/0x39e780d8800f7396e8b7530a8925b14025aedc77#code

用户调用部署在L2的Bridge合约(PogonZkEVMBridge.sol)中的Bridge()函数发送一笔L2-Bridge-Tx，这会更新添加一个新节点在L2 Exit Tree中，然后依次更新L2 Exit Tree Root和 Global Exit Tree Root。

然后在之后Aggregator调用trustedVerifyBatches()往L1提交validity proof的时候，实际上也会把L2 Exit Root也一并作为Input进行上传，也就是以下函数的中的NewLocalExitRoot，它代表了L2有新的BridgeToL1的交易，但是这些交易目前在L1还不能提款，需要等待这个新的NewLocalExitRoot被验证成功。

接下来这个传入的New Local ExitRoot也会作为验证电路的一部分，输入这个验证逻辑是我在L2发生的这些新的BridgeToL1的交易是不是导致L2Exit Tree Root变成当前这个提交的New Local ExitRoot。

如果这个这个Validity Proof验证通过，那么L1的Global Exit RootManager 会更新L2 Exit trre Root和Global Exit Tree Root： globalExitRootManager.updateExitRoot(newLocalExitRoot);

二、 Pogon zkEVM如何抗审查

而实际上用户还可以通过另一种方式直接提交交易到L1的合约中，而不需要通过Trusted Sequencer，从而保证了整个网络仍然具备一定的抗审查的特性。

1）用户调用L1合约中的Force Batch函数，通过这个函数可以用户可以把自己想要执行的L2交易直接送到L1的合约中的。

2）合约中会将这些Transactions打包成一个Batch，并且记录在合约中一个Force Batches的Mapping中。

3）Trusted Sequence 监听到Force Batches中有新的Force Batch的时候，会将其同步到本地的节点中，然后会在下次往L1提交Batches的时候包含这个ForceBatch。

不过这里推荐大家尽可能不要通过Force Batch的方式提交Rollup的交易，因为通过这种方式，你在调用Force Batch往L1提交自己的交易的时候会暴露你的交易内容，而这个时候交易顺序还没被确认(需要等待Sequence同步ForceBatch并通过Sequence Batch()再一次提交到L1的时候交易顺序才被真正确认)同时你已经没办法取消你的交易了，这个时候你有很大的可能被抢跑。

2.Sequencer的真正状态

Bn表示用户直接提交给Sequence的交易执行后得出的结果；

三、L2网络存在的三种不同的Finality

对于Sequencer 和 Aggregator来说，他们的状态都是通过Syschronizer从一层合约中进行同步的，他们之间并不是直接通信的。

1 )三种Finality

a. 第一种 Sequecer Finality，在有一些文章中也将这种Finality称为Soft Finality,但是我觉得叫做Sequenecer Finality更为合适，因为这个Finality其实是Single Sequencer 给的状态承诺。

b. 第二种 DA Finality，代表这些交易已经被提交到L1的DA层合约上，此时交易顺序也被确定了。

c. 第三种 Verified Finality指的是这笔交易已经通过Validity Proof的验证了，属于真正的Finality；在一些文章中也把它叫做Hard Finality。

2)Aggregator同步状态的取舍

不过目前实际上Pogon跟Trusted Sequencer角色一样，也有一个Trusted Aggregator, 来处理生成和提交Validity Proof的工作。https://zkevm.pogon.technology/

接下来，我们继续是关于去中心化Sequencer的思考。首先第一个问题是我们为什么需要去中心化的Sequencer?因为我们希望Rollup能在扩容以太坊的计算能力的同时，继承以太坊的安全性和去中心化程度。而当前 Single Sequencer的方案显然达不到继承以太坊的去中心化程度的目标。再继续勾画去中心化Sequencer的未来之前，我们先来回顾Sequencer的工作。以Pogon zkEVM为例，目前Trusted Sequencer对交易的处理会遵循FCFS,先到的交易先进行处理，并行Mempool也是私有的，尽可能保护用户的交易不被MEV。

因为我们是从Pogon zkEVM 开始介绍去中心化Sequencer的，我们就先介绍Pogon zkEVM的去中心化Sequencer方案Proof Of Efficiency(效率证明)。

Sequencer 成本 = L1 gas cost + generate zkProof fee

所以Sequencer 需要考量将至少多少笔交易打成一个Batch提交L1才是有利可图的。但是Sequencer还需要考虑另外一个问题，时效性问题，如果一个Sequencer的提交交易速度过慢，那么它的用户可能会流失到其他提供更快确认的Sequencer那里。

首先这个方案能运转的核心原因是Pogon的DA部分没有做任何状态承诺，仅仅确定了交易顺序；状态承诺(Sequencer承诺交易执行后对应的新的世界状态，但是这个状态未被Validity Proof或者Fraud Proof验证的状态)是在提交Validity Proof的时候才会给出,这是这个方案能执行的核心原因。

3) 为什么携带状态承诺就不能运用POE?因为在多个Sequencer几乎同时往L1提交Batch的时候，实际上没有一个Sequencer可以保证最终在DA合约上L2的交易顺序到底是怎样，所以如果携带状态承诺，大概率会导致整个Batch无法通过Validity Proof或者Fraud Proof的验证。

无效交易指的是比如账户的Nonce过低，账户余额不足以支付Gas费用的交易，当这些交易在L1(Geth)是不会被放入到区块的，因为如果一个区块中包含一笔无效交易，都会导致整个区块变成无效区块，Validator不会给这种区块投票，Propoer也不会提案这种区块。

但是采用POE之后，Sequencer实际上失去了辨别这种无效交易的能力，因此在L1的验证交易带来的状态变更过程中，也需要将这种情况考虑进去，并且Sequencer提交无效交易是无法获得用户的手续费的。

采用POE之后，如果这些去中心化的Sequencer之间会存在Public Mempool，那么会导致用户一笔交易被不同的Sequencer提交多次，当然只有第一次提交的交易是有效交易，也只有这交易最终能获得用户的手续费。

在这种Permissonless Sequencer的模型下，一个Sequencer是无法给用户提供及时的Sequencer Finality，因为Sequencer预测的最终上链的的交易顺序和实际的交易顺序会有偏差，这个偏差是由于可能有多个Sequencer在几乎同个时刻向L1的DA合约提交了交易Batch，在这种情况下很难保证这些交易Batch的实际顺序是否跟预测顺序相同。

7) L2的MEV流失到L1

8) Aggregator的设计

似乎，利用这种自由市场竞争策略，可以让交易对应的Validity Proof的生成速度达到最快。

https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechani-for-zk-rollups/119888 )

POE可以带来完全PermissionLess的网络，并且整个网络可能也不会有宕机的风险，但是L1的DA合约中可能包含无效交易(比如相同Nonce的交易)，MEV都被L1网络获取,并且只能提供DA Finality和Verified Finality。

Based Rollup 是期望将Rollup网络的Single Sequencer的工作委托给以太坊的proposer去完成。它会要求每个Proposer提案L1的区块需要包含一个有效的Rollup 区块。

这样的方案的好处是可以****的继承了L1的安全性以及去中心化程度，但是也会导致只能提供Sequencer Finality和Verified Finality，L2的MEV也会都流失到L1 同时也需要对以太坊客户端的代码进行修改，这也可能会影响L1的安全性。

Shared Rollup 相比Based Rollup将构建和提交Rollup Block的工作交给以太坊的Propoer，则是将这个工作交给Share Sequencers中的委员会。

a.不同Rollup的用户都可以直接向Shared Sequencers所在的网络直接发送Rollup的交易b.Shared Sequencers会在内部运行一个BFT共识，在每一轮选出一个Sequencer Leader来对交易进行排序并构建对应的Rollup Block.

d.不同的Rollup网络再通过L1的DA合约同步网络中的**交易，然后进入到他们自身验证Validity Proof或者Fraud Proof的流程。

3.2.Shared Sequencer 架构的潜在影响

2)从单个Rollup的角度来看，只是把把官方运行的Single Sequencer委托给了这个Shared Sequencer Committee

a.比如A需要将Arbitrum上USDC跨链到Optimi上，那么正常流程是它会在Arbitrum上先进行Lock，等待Lock成功之后，再去Optimi上提交自己在Arbitrum的Lock Proof(e.g. Merkle Tree Path + Tree Root)，然后在Optimi上Mint出来对应的USDC资产；

c.但是它依旧无法做到像同一个Rollup网络的用户体验，比如Mint的时候你依然需要提供你的Lock Proof；

e.接近完全同步的系统有什么作用呢？f.可以提供原子跨链服务，因为每一轮选出的Sequencer Leader拥有排序所有Rollup交易的权力，所以他有能力构建原子跨链的交易。

因为每一轮的Leader Sequencer拥有所有Rollup Block的排序权力，所以理论上可以捕获所有的跨链MEV，感觉之后Shared Sequencer也需要引入或者直接接入MEV Boost这种MEV架构，因为从目前看各个Rollup 网络的区块间隔都会远远快于以太坊的区块间隔，比如Optimi的2s每一块，Arbitrum最快是0.25s出一块。因此作为每一轮的Sequencer Leader构造Rollup Block的计算量其实并不小，因此感觉生态成熟起来之后也会有相应的MEV架构来辅助构造**价值的Rollup Block。

因为Shared Sequencer Committee内部会用BFT共识来在每一轮选择出一个Sequencer Leader来提案所有的Rollup Block，所以Decentralization 和 Liveness 都要比目前的Single Sequencer方案强大不少。

a.对于不同的Rollup拥有了更好的共存的理由，因为用户可以很方便的在各个Rollup的网络中进行资产转移，也可以更好的对实现以太坊生态的负载均衡。

7)Finality角度

3.3.潜在风险

3.4总结

a.MEV可以被Rollup网络获取，并且还可以额外获取更多的跨链MEV；

c.相比Signle Sequencer，网络的去中心化程度得到了大幅度增强，并且网络的稳定性大大增强了，在某一个Sequencer Leader不出块的时候，会及时轮换一个新的Sequencer Leader进行出块；

五、总结

在这篇文章我们详细结构了Pogon zkEVM的bridge以及Sequencer更多的技术细节，在下篇文章也是**一篇文章，会继续解剖zkEVM的技术细节，敬请期待。

本文由会员发布，不代表本站立场，如有侵权请联系我们删除！