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

• 深入解析 zkEVM Bridge
• Polygon zkEVM如何抗审查
• Polygon zkEVM的三种Finality
• 去中心化Sequencer的潜在方案

<aside> 💡 在这篇文章中L2等价于Rollup,L1等价于Ethereum

</aside>

1. 深入解析zkEVM Bridge

在上一篇文章里，我们介绍Ploygon zkEVM的过程中，实际上缺失了很重要的一个部分，就是polygon zkEVM 的原生桥(bridge)。

1.1 跨链数据状态管理

Polygon zkEVM的在L1和L2分别维护了一棵Exit Tree,名字分别为L1 Exit Merkle tree和L2 Exit Merkle tree。

但是为了更好的管理这两棵树，polygon zkEVM 很聪明的将这两棵树结合在了一起，如下图:

也就是用分别把L1 Exit Tree Root 作为Global Exit Tree的左叶子节点，把L2 Exit Tree Root 作为Global Exit Tree 的右叶子节点。

不过需要注意这里L1 Tree Root 和 L2 Tree Root是Sparse Merkle Tree(SMT),而Global Exit Tree是Binary Merkle Tree。

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

  An exit leaf, in particular, is a Keccak256 hash of the ABI encoded packed structure with the following parameters:

  • uint8 leafType: [0] asset, [1] message
  • int32 originNetwork: Origin network ID, where the original asset belongs
  • address originAddress: If leafType = 0, Origin network token address (0x0000...0000) is reserved for ether. If leafType = 1, msg.sender of the message
  • uint32 destinationNetwork: Bridging destination network ID
  • address destinationAddress: Address that will receive the bridged asset in the destination network
  • uint256 amount: Amount of tokens/ether to bridge
  • bytes32 metadataHash: Hash of the metadata, metadata will contain information about asset transferred or the message payload

1.2 跨链流程

在Polygon zkEVM的合约设计中，还是尽可能的将Bridge和Consensus合约尽可能的解耦。

目前其在L1部署的合约主要分为3个，如下图所示:

需要注意，他们之间不是继承关系，都是独立的合约，不过PolygonZkEVMBridge和PolygonPolygonZkEVM都会调用PolygonZkEVMGlobalExitRoot来更新或验证Global Exit Tree Root 。

• PolygonZkEVMBridge.sol
  • 桥合约当用户在源链发起跨链交易时，会调用该合约的bridgeAsset()方法;或者在目标链调用该合约的claimAsset()方法获得对应的跨链资产。
• PolygonZkEVMGlobalExitRoot.sol
  • 用于管理Exit Tree的合约，PolygonZkEVMBridge和PolygonPolygonZkEVM都会调用PolygonZkEVMGlobalExitRoot来更新Global Exit Tree Root 。
  • 需要注意这三个合约之间没有继承关系，都是独立的合约。
• PolygonZkEVM.sol
  • 这个合约是共识合约，主要用于我们第一篇文章讲的上传Batch和验证validity proof

1.2.1 L1 → L2 的跨链流程

L1 → L2的跨链流程对应上图的橙色标识的三个步骤.

1. 用户先调用部署在L1上的PolygonZkEVMBridge.sol 的bridgeAsset() 方法，这个方法会将这次跨链的metadata加入到L1 Exit Tree中并更新L1 Exit Tree Root,
2. 然后调用更新PolygonZkEVmGlobalExitRoot合约中的Global Exit Tree Root 。
3. L2有一个Global Exit Root Manager的角色监听发现L1的L1 Tree Root和Global Exit Tree Root都更新之后，会把这个新的Global Exit Tree Root更新到L2的zkEVM中。
4. 这个时候用户就能在L2的polygonZkEVMBridge合约中调用claimAsset()进行取款(合约会验证用户提供的Merkle Path是否和当前的Tree Root匹配)。

5. 会在下次调用polygonZkEVM.sol 的sequenceBatch() 方法的时候(我们上一篇文章Sequencer上传Batch的流程)，每个Batch都需要加入一个有效的Global Exit Tree Root 或者一个Empty Root,当这个Global Exit Tree Root 结合之后提交的validity proof被验证通过的时候(证明Global Exit Root Manager同步到Rollup的Global Exit Tree Root是正确的)，这个时候才可以认为整个跨链流程正在完结。

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

   struct BatchData {
           bytes transactions;
           bytes32 globalExitRoot;
           uint64 timestamp;
           uint64 minForcedTimestamp;
       }
   
   function sequenceBatches(
           BatchData[] memory batches
       ) public ifNotEmergencyState onlyTrustedSequencer

• PolygonZkEVMBridge在L2的合约

zkEVM Transaction Hash (Txhash) Details | zkEVM

PolygonZkEVMBridge | Address 0x39e780d8800f7396e8b7530a8925b14025aedc77 | zkEVM

1.2.2 L2 → L1 的跨链流程

• 用户调用部署在L2的Bridge合约(PolygonZkEVMBridge.sol)中的Bridge()函数发送一笔L2-Bridge-Tx，这会更新添加一个新节点在L2 Exit Tree中，然后依次更新L2 Exit Tree Root和 Global Exit Tree Root。
• 接下来当Sequencer会把这笔L2-Bridge-Tx放到某一个Batch中发送到L1的共识和DA合约(PolygonZkEVM.sol)中。
• 然后在之后Aggregator调用trustedVerifyBatches()往L1提交validity proof的时候，实际上也会把L2 Exit Root也一并作为Input进行上传，也就是以下函数的中的newLocalExitRoot，它代表了L2有新的BridgeToL1的交易，但是这些交易目前在L1还不能提款，需要等待这个新的newLocalExitRoot被验证成功。

• 接下来这个传入的newLocalExitRoot实际上也会作为验证电路的一部分输入，这个验证逻辑应该是我在L2发生的这些新的BridgeToL1的交易是不是导致L2ExitTreeRoot变成当前这个提交的newLocalExitRoot。

• 如果这个这个Validity Proof验证通过，那么L1的globalExitRootManager会更新L2 Exit trre Root和Global Exit Tree Root。
  • globalExitRootManager.updateExitRoot(newLocalExitRoot);
• 这个时候，用户就可以调用部署在L1的Bridge合约(polygonZkEVMBridge.sol)的claimAsset()函数并给出相应的MerklePath进行提款，跨链交易的也就完美结束。

2. polygon zkEVM如何抗审查

在上篇文章，我们介绍了Trusted Sequencer ，由官方运行的Single Sequencer，基本上L2网络的交易都会提交给这个Trusted Sequencer，并且可以获得一个及时Sequencer Finality。

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

2.1 执行流程:

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

function forceBatch(
    bytes memory transactions ,
    uint256 maticAmount
) public ifNotEmergencyState isForceBatchAllowed

1. 合约中会将这些transactions打包成一个batch，并且记录在合约中一个forceBatches的mapping中。

forcedBatches[lastForceBatch] = keccak256(
            abi.encodePacked(
                keccak256(transactions),
                lastGlobalExitRoot,
                uint64(block.timestamp)
            )
        );

1. Trusted Sequence 监听到forceBatches中有新的forceBatch的时候，会将其同步到本地的节点中，然后会在下次往L1提交Batches的时候包含这个forceBatch。
2. 不过这里还存在一种特殊情况，如果Trusted Sequence如果宕机了，或者故意不提交某个用户提交的forceBatch, 那么在五天之后用户可以自己调用L1合约中的sequenceForceBatches() 函数，让这笔forceBatch进入到L1合约中的sequencedBatches ，也就意味着这笔forceBatch在rollup中的交易顺序被L1合约最终确定，即便是Trusted Sequence也无法再更改这个forceBatch的交易顺序。(实际上所有rollup都会有这样的特性来提供抗审查特性比如Arbitrum的sequence Inbox和Inbox)

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

<aside> 💡 似乎这并不能真正的抗审查，因为forceBatch的方式存在被抢跑的风险，用户真的会用这个功能吗？

</aside>

2.2 Sequencer的真正状态

从上文我们可以得知，sequence会从L1同步forceBatch中的交易到本地节点进行执行，于是Sequence的真正状态如下图所示:

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

FBn表示Sequence同步forceBatch的交易进行执行后得出的结果

Polygon zkEVM State Management | Polygon Wiki

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

接下来我们回顾下Ploygon的整体架构，为接下来的去中心化sequencer思考做好铺垫。

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

3.1 三种Finality

因此我们可以认为目前整个网络存在三种不同程度的Finality，我们给他命名成Sequencer Finality, DA Finality和Verified Finality。

1. 第一种 Sequecer Finality，在有一些文章中也将这种Finality称为Soft Finality,但是我觉得叫做Sequenecer Finality更为合适，因为这个Finality其实是Single Sequencer 给的状态承诺。
   1. Sequencer接受到用户交易之后，执行后给出的状态，这是最不安全的状态；但是在目前官方Single Sequencer的场景下，却可以在保证安全的同时带来极致的用户体验。在目前单一Sequencer的Rollup网络中，基本上都可以体验到即时确认的快乐。不过，Single Sequencer最大的风险就是Sequencer宕机，这会导致整个L2网络基本瘫痪，不过由于DA层是位于以太坊上的，依然可以在之后部分恢复L2网络宕机前的状态；不过那部分来不及发送到L1的L2交易将无法被恢复。
2. 第二种 DA Finality，代表这些交易已经被提交到L1的DA层合约上，此时交易顺序也被确定了。
   1. Trusted Sequencer已经调用sequenceBatch 将交易发送到L1上，在这种情况下，交易已经被DA层包含；在polygon的设计中, 由于单一 Trusted Sequencer的原因，所以可以确保上传到L1合约上进行DA的交易都是有效交易。我们可以认为当一笔交易被Trusted Sequencer 上传到L1合约中的时候, 这个时候它已经被rollup网络承认了，并且在之后Aggregator会提供validity proof让这笔交易真正无法被revert(除非L1 reorg)。
3. 第三种 Verified Finality指的是这笔交易已经通过validity proof的验证了，属于真正的Finality；在一些文章中也把它叫做Hard Finality。
   1. 当Aggregator为一批上传到DA层的交易提供的validity proof被合约验证通过的时候，这个时候我们认为这些交易已经无法被revert了(除非L1 reorg)。我们在上一篇文章里提到过，目前提交到DA层的交易到验证validity proof的通过的时间是30分钟，同时Aggregator也可以通过提供validity proof从而获得足够的Matic报酬。

3.2 Aggregator同步状态的取舍

假如我们这里假设提供validity proof是有利可图的，那么对于Aggregator来说，最好的同步交易的方式，不是在L1的DA层合约中同步，而是直接跟Trusted Sequencer建立rpc链接，直接从Trusted Sequencer获取最新的交易，这样生成validity proof会更快，从而相比其他从DA合约中获取交易的Aggregator更有竞争优势，因为提供validity proof这件事情是先到先得，对于一批交易来说也仅仅需要一个聚合的validity proof，第一个提交validity proof的Aggregator可以拿走对应交易的Matic奖励，其他Aggregator生成的validity proof也无法再获得任何奖励。

不过目前实际上polygon跟Trusted Sequencer角色一样，也有一个Trusted Aggregator, 来处理生成和提交validity proof的工作。

zkNode | Polygon Wiki

4. Sequencer 的未来

接下来，我们续接来是关于去中心化Sequencer的思考。

首先第一个问题是我们为什么需要去中心化的Sequencer?

因为我们希望Rollup能在扩容以太坊的计算能力的同时，继承以太坊的安全性和去中心化程度。

而当前 Single Sequencer的方案显然达不到继承以太坊的去中心化程度的目标。

再继续勾画去中心化Sequencer的未来之前，我们先来回顾Sequencer的工作。

以Polygon zkEVM为例，目前Trusted Sequencer对交易的处理会遵循FCFS,先到的交易先进行处理，并行mempool也是私有的，尽可能保护用户的交易不被MEV。

当收集到一定量的交易之后，会把它们封装成batches上传到L1合约中对应的DA的位置，并且在第一篇文章中我们也提到了这些了Sequencer上传的Batch中实际上已经通过在后一个batch包含前一个batch的哈希的方式确定了交易的顺序。

因此我们认为Sequencer的工作类似L1 proposer的工作，提议了一批交易，并且确认了交易的顺序。

4.1 Proof-of-Efficiency

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

4.1.1 方案描述

在POE的设计中，允许任何人成为Sequencer并且向L1提交 Rollup Block的，Rollup网络的交易顺序取决于交易被提交到L1的Rollup DA 合约的顺序。

<aside> 💡 在polygon zkEVM 里 Batch 等价于Block

</aside>

如下图，用户都可以自行选择将交易发送给哪个Sequencer,甚至可以自己成为Sequencer, 这些Sequencer在收到足够的交易之后，会将这些交易打包成Batch，然后往L1上提交。

这些Sequencer需要考虑利润问题:

Sequencer 成本 = L1 gas cost + generate zkProof fee

Sequencer 收入 = L2 gas fee

所以Sequencer 需要考量将至少多少笔交易打成一个Batch提交L1才是有利可图的。

但是Sequencer还需要考虑另外一个问题，时效性问题，如果一个Sequencer的提交交易速度过慢，那么它的用户可能会流失到其他提供更快确认的Sequencer那里。

4.1.2 方案可行性

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

实际上像Arbitrum在提交交易到DA合约中的时候也没有做任何状态承诺，但是Optimism在提交交易到DA层的时候是携带状态承诺的，所以理论上Arbitrum也可以运用POE来实现去中心化Sequencer，但是Optimism则不行。

4.1.3 为什么携带状态承诺就不能运用POE?

因为在多个Sequencer几乎同时往L1提交Batch的时候，实际上没有一个Sequencer可以保证最终在DA合约上L2的交易顺序到底是怎样，所以如果携带状态承诺，大概率会导致整个Batch无法通过validity proof或者fraud proof的验证。

4.1.4 如何处理无效交易？

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

</aside>

在当前Single Sequencer的情况下，L2网络是有能力辨别这种无效区块的，并且可以避免在L1 DA合约中避免包含这种交易，这可以避免浪费L1的区块空间。

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

4.1.4 Public Mempool(公共交易池)？

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

4.1.5 Sequencer为何无法预测执行结果

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

因此Sequencer同步自身状态的时候，也会从L1的DA合约上同步最新被提交的交易Batch并执行来获得最新状态，而不是其他Sequencer那里同步状态。

4.1.6 L2的MEV流失到L1

由于交易任何人都可以成为Sequencer提交Rollup网络的交易, 并且提交交易Batch的交易实际上跟L1的普通交易无异，因此它实际上还是会经过MEV Boost的整个流程，意味着L2网络的MEV都会流失到MEV Boost模块。

4.1.7 Aggregator的设计

在POE的设计上，Aggregator同样也是permissionless的，但是由于validity proof实际上只需要一个正确的交易，也就意味着只有第一个为交易提交正确的validity proof的Aggregator才能获得奖励。因此作为Aggregator,你需要权衡提交的validity proof的证明范围，提交时间以及提交validity proof可以获得的Matic奖励之间的关系，最终找出一个最有竞争力的策略。

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

Proof of Efficiency: A new consensus mechanism for zk-rollups

4.1.8 总结

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

4.2 Based Rollup

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

因此L1 网络的Block Builder需要运行一个Rollup的全节点用来接受L2的交易，并且构建最大价值的Rollup Block。

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

4.3 Share Sequencing

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

4.3.1 具体流程如下:

1. 不同Rollup的用户都可以直接向Shared Sequencers所在的网络直接发送Rollup的交易
2. Shared Sequencers会在内部运行一个BFT共识，在每一轮选出一个Sequencer Leader来对交易进行排序并构建对应的Rollup Block.
3. 然后将这些Rollup Block提交到不同的Rollup网络对应在L1上的DA合约
4. 不同的Rollup网络再通过L1的DA合约同步网络中的最新交易，然后进入到他们自身验证validity proof或者fraud proof的流程。

4.3.2 Shared Sequencer 架构的潜在影响

1. 多个Rollup网络共用一个Shared Sequencer Committee
2. 从单个Rollup的角度来看，只是把把官方运行的Single Sequencer委托给了这个Shared Sequencer Committee
3. 在每一轮从Shared Sequencer Committee中会选出一个Sequencer Leader,负责对接入这个Shared Sequencers网络的Rollup Block进行构建，并且依次将这些Rollup Block提交到对应Rollup 在以太坊上的DA合约内。
   1. 所以我们可以认为接入到这个Shared Sequencers网络中的Rollup们是一个接近于完全同步的系统。
   2. 接近完全同步的系统有什么作用呢？
   3. 可以提供原子跨链服务，因为每一轮选出的Sequencer Leader拥有排序所有Rollup交易的权力，所以他有能力构建原子跨链的交易。
      1. 比如A需要将Arbitrum上USDC跨链到Optimism上，那么正常流程是它会在Arbitrum上先进行Lock，等待Lock成功之后，再去Optimism上提交自己在Arbitrum的Lock Proof(e.g. Merkle Tree Path + Tree Root)，然后在Optimism上Mint出来对应的USDC资产。
      2. 当用户向Shared Sequencers提交这样一个交易的时候，每一轮的Seuqnecer Leader实际上可以将Arbitrum Lock的操作+Optimism Mint的操作放在同一时刻的Rollup Block进行执行，这样可以带来巨大的用户体验提升。
      3. 但是它依旧无法做到像同一个Rollup网络的用户体验，比如Mint的时候你依然需要提供你的Lock Proof。
4. 跨链MEV的角度
   1. 因为每一轮的Leader Sequencer拥有所有Rollup Block的排序权力，所以理论上可以捕获所有的跨链MEV，感觉之后Shared Sequencer也需要引入或者直接接入MEV Boost这种MEV架构，因为从目前看各个Rollup 网络的区块间隔都会远远快于以太坊的区块间隔，比如optimism的2s每一块，Arbitrum最快是0.25s出一块。因此作为每一轮的Sequencer Leader构造Rollup Block的计算量其实并不小，因此感觉生态成熟起来之后也会有相应的MEV架构来辅助构造最大价值的Rollup Block。
5. 从Decentralization和Liveness的角度看Shared Sequencers.
   1. 因为Shared Sequencer Committee内部会用BFT共识来在每一轮选择出一个Sequencer Leader来提案所有的Rollup Block，所以Decentralization 和 Liveness 都要比目前的Single Sequencer方案强大不少。
6. 从生态的角度
   1. 对于不同的Rollup拥有了更好的共存的理由，因为用户可以很方便的在各个Rollup的网络中进行资产转移，也可以更好的对实现以太坊生态的负载均衡。
   2. 对于不同的正在构造Shread Sequencer的项目而言，可能就是你死我活的竞争，因为从用户角度和目前各个Rollup都是Signle Sequencer的角度而言，似乎在Shared Sequencer这条赛道会出现赢家通吃的问题。
7. Finality角度
   1. 因为本质上还是Single Sequencer，所以无论是Sequencer Finality还是Verified Finality 都跟原来是一样的。

4.3.3 潜在风险

因为Rollup之间不一定是同构Rollup，比如Arbitrum和polygon zkEVM之间的跨链，那么意味着跨链交易对应在Arbitrum和polygon zkEVM之上交易的Verified Finality并不一致，比如我在polygon zkEVM之上的mint交易已经获得Verified Finality(提交了validity proof),但是此时我在Arbitrum上的Lock交易仅获得了DA Finality(需要等待7天挑战期)，如果我在这个时候成功revert了我在Arbiturm的交易,那么也就意味着:我实际上在polygon zkEVM无成本铸造了很多跨链资产。

4.3.4 总结

• 好处:
  • MEV可以被Rollup网络获取，并且还可以额外获取更多的跨链MEV。
  • 用户跨Rollup体验好，并且能让Rollup之间由竞争关系转为共生关系，每个Rollup都可以提供自己独特的价值，然后与其他Rollup网络组合成可以为用户提供各种各样定制化服务的网络。
  • 相比Signle Sequencer，网络的去中心化程度得到了大幅度增强，并且网络的稳定性大大增强了，在某一个Sequencer Leader不出块的时候，会及时轮换一个新的Sequencer Leader进行出块。
  • 网络的三种Finality都跟原来Single Sequencer保持一致。
• 坏处:
  • 本质上还是Single Sequencer的模型，并且也引入了新的攻击向量。

5 总结

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

未完待续…

如果大家觉得写得不错的话，欢迎大家关注我的推特 0xhhh，可以的话也给我的Thread一个like ,感激不尽(写文章真的太需要正反馈了)。

Polygon zkEVM的下一篇文章也会继续在推特发布,也欢迎大家在推特催更。

本文首发于：https://literate-wolfsbane-bf0.notion.site/polygon-zkEVM-f0915b65aa784593a77b1938ddf34755