跨链资产桥机制浅析 : Polygon vs Rollups

概述

近期，Polygon 生态 TVL 持续走高。随着 TVL 的快速放大，Polygon 市值也急速攀升，一度进入加密货币总市值的前 10，超越了 UNI、LINK 等老牌明星项目，这也使的社区对 Polygon 的安全性产生了讨论。

Polygon 希望成为首个以太坊扩容方案聚合器，同时支持多种 Layer 2、侧链等扩容方案。目前，Polygon 拥有一条基于 Plasma 框架和 PoS 共识机制的侧链以及配套的 PoS Bridge、Plasma Bridge 两座桥。

在所有侧链 和 Layer 2 的系统中，无疑 Bridge 的安全性是最重要的，因为所有的资产都被托管在一个 Layer 1 的智能合约中，该合约是否保留管理员权限，是否有紧急退出机制一般是衡量一个 Layer 2 系统是否无需信任的重要标志。本文将对并 Polygon 与 Rollup 方案的 Bridge 在安全性等方面进行对比。

Polygon Bridge

桥是侧链和 Layer2 等扩容方案的核心组件之一，资产必须通过桥才可以在以太坊主链和子链（侧链或 Layer 2）之间进行迁移，同时桥的具体实现机制也决定了扩容方案的安全性。Polygon 同时支持 PoS Bridge 和 Plasma Bridge 两种桥机制。

PoS Bridge 流程机制：

1. 资产（ERC20/ERC721/ERC1155）的所有者首先必须 approve PoS 桥上的托管合约，用来转入一定数量 token，这个合约部署在以太坊主网上，事实上它会锁定所有存入的 token；
2. 一旦 approve 完成，接下来就是存入资产，这会对 RootChainManager 合约进行函数调用，由于状态同步机制的存在，进而触发 Polygon 链上的 ChildChainManager 合约；
3. ChildChainManager 内部调用子 token 合约的存款函数，并铸造相应数量的 token 资产存入特定用户的 Polygon 账户，值得注意的事，只有 ChildChainManager 才可以调用子 token 合约的存款函数；
4. 一旦用户的账户存入了 token，他们可以立刻在 Polygon 网络使用这些 token；
5. 提取 token 回以太坊分成了两步，第一步是在 Polygon 网络销毁这些 token，之后是将销毁交易的证明传回以太坊主网；
6. 需要花费 10-30 分钟，销毁交易的证明才会被加入一个 checkpoint，并传回以太坊主网，这是由 PoS 验证者完成的。
7. checkpoint 被传回主网后，会调用 RootChainManager 合约的 exit 函数，并传入销毁交易的证明；
8. exit 函数将验证这个 checkpoint 中的所有销毁交易，验证通过后触发托管合约；
9. 最后托管合约将之前锁定的 token 释放，并退还到用户的以太坊账户中。

Plasma Bridge 流程机制：

1. 用户在以太坊上的 Polygon 合约中存入 token；
2. 一旦以太坊主网确认了存款成功，Polygon 网络就会铸造相同数量的 token 并存入用户的 Polygon 账户，用户可以立刻使用这些 token；
3. 用户可以随时提取 Polygon 上的 token 到以太坊上，一旦提交请求，需要等待 5 分钟的 checkpoint 时间；
4. 当这个 checkpoint 被提交到以太坊主网后，将铸造一个相同价值的退出 NFT （ERC721）作为凭证；
5. 用户需要等待 7 天的挑战期，这由 Plasma 安全机制决定；
6. 一旦挑战期完成，可以使用退出 NFT claim 你的 token 资产，完成提款。

PoS Bridge 是官方推荐使用的桥，它具有更快的提款时间，支持更多的以太坊资产标准，而 Plasma Bridge 提款时需要等待 7 天的挑战期，但是它在安全级别上会更高。两者主要对比如下：

Bridge 安全性对比

Bridge 安全性的核心其实在于用户是否可以无需信任的存入和提取资产，包括当 Layer 2 节点不可用甚至作恶时，Layer 1 能否独立的恢复 Layer 2 上的交易数据和用户在 Layer 1 上的资产余额（数据可用性），本节我们将 Polygon Bridge 和 Rollup Bridge 进行对比。

Polygon PoS Bridge

Polygon PoS Bridge 由一组外部验证者来保证安全性。在一般的 PoS 系统中，一般安全性是由验证者 bond 的资产和惩罚机制来保证的。

此外，该 Bridge 合约留有了管理员权限，由一个多签钱包通过代理控制，这个多签钱包起初是 2/3 多重签名，现在则升级为 5/8 方案。在这 8 个签名者中，4 个是 Polygon 联合创始人，另外 4 个则是来自其他 Polygon Defi 项目的主要成员。

通过我们对合约代码的检查，合约的 Owner 可以随时升级替换合约（没有延迟期），也即意味着 Owner 具备随时提取合约中所有用户资产的能力，这无疑是一个潜在的安全风险。所以 Polygon 通过 Pos Bridge 转移至 Polygon 网络的资产现阶段并不是无需信任的。

Polygon Plasma Bridge

Polygon Plasma Bridge 的退出机制基于 Plasma exit mechanism，由于同样使用了欺诈证明，用户提现时和 Optimistic Rollup 一样都需要等待 7 天的挑战期。

但 Plasma 方案相比 Rollup 方案的一个重要不足是数据不可用（data unavailability），即 Plasma 的 operator 只会把交易数据生成一个 hash 值存储到 Layer 1 上，因此 Layer 1 是不具备可用的数据来验证 operator 是否作恶以及恢复 Layer 2 上的所有交易的。

Optimistic Rollup Bridge

在 Optimistic Rollup 方案中，主要由第三方的 sequencer 负责 Layer 2 与 Layer 1 之间的交互。当用户在 Layer 1 存入资产时，由 Sequencer 在用户的 Layer2 账户中计入相应资产；与此同时，sequencer 周期性的将它在二层上收到的交易生成新状态根发布到以太坊上。当用户提现时，只要提供一个基于最新发布的状态根得到的，自身账户拥有足够多资产的默克尔证明，即可完成提现。为了防止 sequencer 提交无效的状态转换，Optimistic Rollup 引入了 verifier 和挑战期的概念，任何一个 sequencer 发布的新状态根都不会立刻生效，而是需要经过一个 7 天的挑战期，在挑战期内，只要 verifier 发现其中一个状态转换无效时，就可以发布欺诈证明，如果证明成功，就会取消这个状态转换，并且将 sequencer 的押金奖励给 verifier。

同时，为了避免 sequencer 作恶或者离线，sequencer 被要求将 Layer 2 所有的交易数据保存到 Layer 1 的 calldata 中，这样即使这个 sequencer 消失，一个新的 sequencer 也可以基于这些数据还原所有的 Layer 2 上发生的交易，并从中断处重新开始工作。

zkSync Bridge

Rollup 方案都会将 Layer 2 上的交易压缩提交到 Layer 1 上的 calldata 中，这首先确保了 Layer 2 网络数据在 Layer 1 上的数据可用性。

1. 同时当 zkSync 整个系统不可用的时，比如 Layer 2 无法收到用户的签名，Layer 2 不再将交易数据提交到 Layer 1 时，任何人都可以触发进入紧急退出模式：
2. 任何用户都可以在 Layer 1 通过调用 requestFullExit，发起提现请求，请求顺序存储，且有超时时间（目前设计为 3 天）；
3. 当 1 中请求序列中的第 1 个请求过了超时时间还未被 zkSync 的 operator 处理时，任何用户都可以通过调用 activateExodusMode 来激活 Exodus Mode；
4. 在链下可以使用官方提供的的工具通过爬取 Layer 1 上的 calldata 数据来最终同步到 Exodus Mode 时的 zkSync 状态， 并基于此状态对用户拥有的资产产生 zkProof；
5. 最后，用户通过调用 performExodus, withdrawPendingBalance 两个方法来完成最后的提现（需要用到第 3 步中产生的 zkproof 和一些数据做为参数）。

可见，zkSync 设计了非常完善的退出机制，即使 Layer 2 节点彻底不可用，用户仍然可以利用 Layer 1 上的 calldata 数据提取桥中存储的资产。

详情请阅读 : A Test of zkSync 1.0’s Exodus Mode on Ropsten

三者的主要对比：

最后

DeGate 致力于打造以太坊 Layer2 上，交易体验最佳的去中心化交易所，团队将深入研究市面上的各种 Layer2 方案，并综合性能、安全性、用户体验等指标，选择在其中一个或多个方案上部署 DeGate 产品。

转载自：https://www.chainnews.com/articles/820895255443.htm