技术详解 Polygon zkEVM Bridge 和 Sequencer 框架

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

一、深入解析 zkEVM Bridge

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

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 叶子节点的基本信息如下:

2.跨链流程

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

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

1）L1 → L2 的跨链流程

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

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

PolygonZkEVMBridge 在 L2 的合约

• https://testnet-zkevm.polygonscan.com/tx/0x2a742f2f8a7b8635a76cc70b4574bebb1a81b2c0c1a618188773a1f8f2283bb8
• https://testnet-zkevm.polygonscan.com/address/0x39e780d8800f7396e8b7530a8925b14025aedc77#code

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 被验证成功。

接下来这个传入的 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);

这个时候，用户就可以调用部署在 L1 的 Bridge 合约 (PolygonZkEVMBridge.sol) 的 ClaimAsset() 函数并给出相应的 Merkle Path 进行提款，跨链交易的也就完美结束。

二、 Polygon zkEVM 如何抗审查

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

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

1.执行流程

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

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

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

4）不过这里还存在一种特殊情况，如果 Trusted Sequence 如果宕机了，或者故意不提交某个用户提交的 Force Batch, 那么在五天之后用户可以自己调用 L1 合约中的 SequenceForceBatches() 函数，让这笔 ForceBatch 进入到 L1 合约中的 Sequenced Batches ，也就意味着这笔 Force Batch 在 Rollup 中的交易顺序被 L1 合约最终确定，即便是 Trusted Sequence 也无法再更改这个 Force Batch 的交易顺序。( 实际上所有 Rollup 都会有这样的特性来提供抗审查特性比如 Arbitrum 的 Sequence Inbox 和 Inbox)。

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

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

2.Sequencer 的真正状态

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

• Bn 表示用户直接提交给 Sequence 的交易执行后得出的结果；
• FBn 表示 Sequence 同步 Force Batch 的交易进行执行后得出的结果。

https://zkevm.polygon.technology/

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

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

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

1 ) 三种 Finality

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

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

Sequencer 接受到用户交易之后，执行后给出的状态，这是最不安全的状态；但是在目前官方 Single Sequencer 的场景下，却可以在保证安全的同时带来极致的用户体验。在目前单一 Sequencer 的 Rollup 网络中，基本上都可以体验到即时确认的快乐。不过，Single Sequencer 最大的风险就是 Sequencer 宕机，这会导致整个 L2 网络基本瘫痪，不过由于 DA 层是位于以太坊上的，依然可以在之后部分恢复 L2 网络宕机前的状态；不过那部分来不及发送到 L1 的 L2 交易将无法被恢复。

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

Trusted Sequencer 已经调用 Sequence Batch 将交易发送到 L1 上，在这种情况下，交易已经被 DA 层包含；在 Polygon 的设计中, 由于单一 Trusted Sequencer 的原因，所以可以确保上传到 L1 合约上进行 DA 的交易都是有效交易。我们可以认为当一笔交易被 Trusted Sequencer 上传到 L1 合约中的时候, 这个时候它已经被 Rollup 网络承认了，并且在之后 Aggregator 会提供 Validity Proof 让这笔交易真正无法被 Revert( 除非 L1 Reorg)。

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

当 Aggregator 为一批上传到 DA 层的交易提供的 Validity Proof 被合约验证通过的时候，这个时候我们认为这些交易已经无法被 Revert 了 ( 除非 L1 Reorg)。我们在上一篇文章里提到过，目前提交到 DA 层的交易到验证 validity proof 的通过的时间是 30 分钟，同时 Aggregator 也可以通过提供 Validity Proof 从而获得足够的 Matic 报酬。

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 的工作。

https://zkevm.polygon.technology/

四、Sequencer 的未来

接下来，我们继续是关于去中心化 Sequencer 的思考。首先第一个问题是我们为什么需要去中心化的 Sequencer">当收集到一定量的交易之后，会把它们封装成 Batches 上传到 L1 合约中对应的 DA 的位置，并且在第一篇文章中我们也提到了这些了 Sequencer 上传的 Batch 中实际上已经通过在后一个 Batch 包含前一个 Batch 的哈希的方式确定了交易的顺序。因此我们认为 Sequencer 的工作类似 L1 Proposer 的工作，提议了一批交易，并且确认了交易的顺序。

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

1.Proof-0f-Efficiency

1) 方案描述

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

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

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

• Sequencer 成本 = L1 gas cost+ generate zkProof fee
• Sequencer 收入 = L2 gas fee

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

2) 方案可行性

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

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

3) 为什么携带状态承诺就不能运用 POE">

https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/11988

8 ) 总结

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

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 的安全性。

3.Share Sequencing

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

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 的流程。

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 合约内。

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

b.当用户向 Shared Sequencers 提交这样一个交易的时候，每一轮的 Seuqnecer Leader 实际上可以将 Arbitrum Lock 的操作 +Optimism Mint 的操作放在同一时刻的 Rollup Block 进行执行，这样可以带来巨大的用户体验提升；

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

d.所以我们可以认为接入到这个 Shared Sequencers 网络中的 Rollup 们是一个接近于完全同步的系统；

e.接近完全同步的系统有什么作用呢？

f.可以提供原子跨链服务，因为每一轮选出的 Sequencer Leader 拥有排序所有 Rollup 交易的权力，所以他有能力构建原子跨链的交易。

4) 跨链 MEV 的角度

因为每一轮的 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

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

6) 从生态的角度

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

b.对于不同的正在构造 Shread Sequencer 的项目而言，可能就是你死我活的竞争，因为从用户角度和目前各个 Rollup 都是 Signle Sequencer 的角度而言，似乎在 Shared Sequencer 这条赛道会出现赢家通吃的问题。

7)Finality 角度

因为本质上还是 Single Sequencer，所以无论是 Sequencer Finality 还是 Verified Finality 都跟原来是一样的。

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 无成本铸造了很多跨链资产。

3.4 总结

优势:

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

b.用户跨 Rollup 体验好，并且能让 Rollup 之间由竞争关系转为共生关系，每个 Rollup 都可以提供自己独特的价值，然后与其他 Rollup 网络组合成可以为用户提供各种各样定制化服务的网络；

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

d.网络的三种 Finality 都跟原来 Single Sequencer 保持一致。

劣势:

本质上还是 Single Sequencer 的模型，并且也引入了新的攻击向量。

五、总结

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