详解 ZKP 桥接新方案：将 Optimistic 引入 zk 的“请求者-证明者“分离模型

ChainCatcher 精选

2023-11-03 15:23:20

Optimistic ZK 假设所有状态转换都是正确的，不需要立即的有效性证明。这种设计降低了 ZKP 项目的总证明成本，同时通过激励去中心化的挑战者监控系统和挑战欺诈行为来确保安全性。

分享至

微信扫码

原文标题：ZKP Requester-Prover Separation model to support Full ZK and Optimistic ZK

原文作者：0x3d18，ZKPool

编译：倩雯，ChainCatcher

零知识证明有很多应用场景，包括 Rollup、桥接和预言机。这导致了 ZK-Rollup、ZK-bridge 和 ZK-oracle 等项目的开发。

Hybrid（混合）和 Optimistic（乐观）设计最近已应用于 ZKP 技术。例如，Orbiter Finance 提出了 Optimistic ZK 桥接协议，而 Taiko 提出了一个渐进的混合 Rollup 解决方案。

Optimistic ZK 假设所有状态转换都是正确的，不需要立即的有效性证明。但是它建立了一个预定的挑战窗口，在此期间，任何参与者都可以通过提交有效性证明或欺诈证明来对欺诈活动提出争议。

这种设计降低了 ZKP 项目的总证明成本，同时通过激励去中心化的挑战者监控系统和挑战欺诈行为来确保安全性。

Optimistic ZK 桥接协议

Orbiter Finance 是一个比较知名的跨 Rollup 项目。它提出了“Orbiter 跨 Rollup 协议：对顺从的多数持乐观态度，对恶意的少数进行严厉仲裁”。

Optimistic Rollup 交叉交易流程 (来自 Orbiter Finance)

它定义了一种去中心化、安全、具有成本效益越的跨 Rollup 设计，由 ZKP 技术支持。

Orbiter 的去中心化设计

这样的设计有几个重要的因素需要考虑：

首先，过去的桥接工程经历了多重安全问题，给用户造成了重大损失。中心化也带来了安全隐患。因此，去中心化对桥接至关重要。

其次，需要有一种机制来确保源链/Rollup 和目的链/Rollup 之间事务流程的准确。

此外，必须找到一种具有成本效益的方式来生成这样的证明。与链上默克尔树相比， ZKP 是一个可行的选择，gas 费更少。

特别是，对于跨 Rollup 桥来说，成本是首要考虑的因素，整个设计的目标都是最小化费用。这意味着减少链上交易和尽可能降低每笔链上交易的 gas 量至关重要。

在 Orbiter 的设计中，除了桥接支付方案，还有另一个方案需要 ZKP 。在这个场景中，一个名为“提交者 ”（submitter）的角色将交叉汇总的交易信息聚合并发送给 L1 ，以确保去中心化的交易商（dealer）获得精准的奖励。

Orbiter 的去中心化提交者设计

Orbiter 的协议假设大多数参与者都是不会犯错，并乐观地处理跨 Rollup 事件，以确保及时执行。如果每个跨 Rollup 事务都需要证明，那么整个桥接事务的执行将会很慢。因此，在没有恶意行为的情况下，不需要生成证明，节省了成本。但是，如果在制造者（maker）或提交者（submitter）检测到恶意行为，挑战者可以生成证明，被质疑的提交者也应该提交证明。

Orbiter Optimistic zk 桥接设计

ZKPool 请求者-证明者分离模型（Requester Prover Separation Model）

当涉及到使用 ZKP 技术时，有不同的模式可用:

1. 全 zk：在这种模式下，每次转换需要一个 ZKP。这可以通过像 ZK-bridge（如 Polyhedra）或 ZK-Rollup（如 Scroll）这样的项目来实现。

2. Optimistic zk：在这种模式下，仅在转换受到挑战时需要 ZKP。 Taiko 和 Orbiter 就是这种模式的一个例子。

全 zk 和 Optimistic zk

在定义抽象模型时，很明显 ZK-bridge 和 ZK-Rollup 有一些相似之处。具体来说，这种不同体现在 ZKP 请求者和 ZKP 证明者之间的关系，如下图所示。这里， ZKP 请求者引用具有生成 ZKP 需求的模块。

场景如下:

1. 在 ZK-Rollup 项目中:

在全 zk 模式下，序列器作为 ZKP 请求器工作。
在 Optimistic zk 模式下，挑战者作为 ZKP 请求者。

2. 在 ZK-bridge 项目中:

在全 zk 模式下，做市商（maker）作为 ZKP 请求者。
在Optimistic zk 模式下，挑战者作为 ZKP 请求者。

ZKP 请求者和 ZKP 证明者

如前所述，在 Optimistic型 zk 中，可能并不总是有证明任务。因此，如果将 ZKP 请求者和 ZKP 证明者合并到同一个模块中，证明者可能处于空闲状态，其计算能力可能没有得到充分利用。

如果我们设计一个请求者-证明者分离模型，并使证明者成为一个共享池，我们就可以提高证明者的利用率。当 Optimistic 场景没有受到挑战时，证明者可以从承担其他 ZKP 项目的证明任务。这意味着 ZKPool 在 zk-bridge 项目中发挥着重要作用，特别是在将 Optimistic 与其他结合的情况下。