本文最早作为 《 PAKA 跨链研究报告 》的 5.8 章节发布。

作者：MiddleX

与我交流：

• Twitter：@middlex0

• VX：xuezhijie156

按照消息验证的机制，我们通常把跨链桥分为三大类型，分别是原生验证（轻客户端验证）、外部验证、本地验证。

三种验证方式中，原生验证的信任假设最小，理论上只要源链和目标链不发生重组，跨链消息传递就是安全的，但原生验证的多链适配成本是最高的。几乎每条链的轻节点方案都要单独设计。外部验证的多链适配成本较低，其缺点是引入新的信任假设，假设外部验证人通过是 m-of-n 投票机制来达成共识，我们需要恶意串通的验证人数量不能超过 n-m 。如果我们想要降低信任假设，那就需要验证人做抵押，这带来的是跨链的成本的增加。本地验证尽管具备无信任假设、多链适配容易的双重优点，但是其适用范围相对狭窄，只能支持 Swap 桥，无法支持 Wrap 桥，更无法支持 AMB 桥。

Connext 创始人 Arjun Bhuptani 是跨链领域的一位非常活跃的研究者和实践者，上述对跨链桥的三分法就是他提出来的，他在文章中还进一步提出了著名的跨链互操作性不可能三角（The Interoperability Trilemma ）理论，即

任何跨链方案设计，最多只能满足以下三者当中的两者：

• 可扩展性（Extensible）：支持任意消息传传递

• 无需信任（Trustless）：不引入新的信任假设

• 易适配性 （Generalizable）：能够轻易适配更多区块链

但 Arjun Bhuptani 很快发现，有一种新的技术范式可以突破这个不可能三角，那就是乐观验证。率先采用乐观验证的跨链桥项目是 Nomad，Arjun Bhuptani 还为 Nomad 撰写了一篇博客。

---

什么是乐观验证

乐观验证的基本逻辑是：在外部验证的基础上，设置一批挑战者和一个挑战窗口期，对不正确的验证进行挑战，验证者需要抵押，当其行为不当时，挑战者将提出挑战，并提供欺诈证明。若挑战成功，验证者的抵押金将成为挑战者的赏金。

乐观验证被人所熟知的应用场景是 Optimistic Rollop ，但乐观验证在用于对等跨链，和用于 Op Rollup 时，情形是完全不同的。首先要明确，乐观验证并不是一个可以单独使用的验证机制，因此要使用欺诈证明的前提条件是，有验证欺诈证明的机制。这意味着我们必须有一个可靠的“真相”来源。这个真相端承担着最终裁决的功能。

在对等跨链中，真相就在源链，不正确的状态转换很容易与源链上的「正确答案」进行比对，从而对欺诈证明进行验证。Op Rollups 则比这复杂，Rollups 要求 L2 继承 L1 的安全性，因此只能以 L1 上的真相作为最终裁决的依据，但矛盾的是，L1 并不天然保有 L2 上的状态转换信息，任何从 L2 提交到 L1 的信息都要经过激烈的证明过程，因此需要一个足够长的时间，让异议者能充分参与博弈，大多 Op Rollups 都把这个时间定为 7 天或以上。

在对等跨链中，乐观验证不需要 7 天这么长时间，只需一个足够挑战者进行反应的时间即可，Nomad 将其设定为 30min 。乐观验证的信任假设是：至少有一个挑战者是诚实的，且会受到经济激励而忠实的履行职责。这相比外部验证而言，是更小的信任假设，在这样的信任假设下，攻击者无论付出多大的经济代价，都不能保证攻击一定成功。

相比外部验证，乐观验证在满足易适配特性的同时，其 Trustless 水平几乎与原生验证相当。代价是几十分钟的延迟。

除了 Nomad 之外，Celer IM 也采用了乐观验证方案，资产桥应用 CounterStake Bridge 的设计中也有乐观验证的因素。

---

Nomad

Nomad 的技术方案脱胎于 Celo 旗下的跨链桥项目 Optics，Nomad 的几名核心成员也来自被 cLabs 收购的 Summa 跨链研究团队。但 Nomad 从一开始就已作为一个通用跨链项目而独立发展，已不再使用 Optics 的基础设施。2022 年 4 月 13 日，Nomad 以 2.25 亿美元估值完成 2200万 美元种子轮融资，领投方是 Polychian Captical 。

Nomad 在试图通过一个全新的方式，解决跨链不可能三角问题。Nomad 意识到轻节点客户端跨链方案在易适配性上的缺陷，也意识到外部验证人跨链方案在安全性上的妥协。于是 Nomad 采用了欺诈证明的方式来验证跨链信息。在 Nomad 中，跨链消息在传递成功后，有一个争议窗口期（30min），如果在争议窗口期，没有人报告欺诈行为，消息将被接收端正式接受。

结构

Nomad 协议由链上的智能合约和链下代理角色两个核心部分组成：

链上智能合约实现了 Nomad 的消息发送和消息接收的逻辑，链上智能合约包括 Home 和 Replica 两部分，其中 ：

• Home 负责处理消息发送逻辑，可以理解为 Nomad 跨链消息的「发件箱」，Home 合约也负责管理 Updater 的保证金（bond）；

• Replica 则负责处理消息接收的逻辑，可以理解为 Nomad 跨链消息的「收件箱」。

需要注意的是，接入 Nomad 的区块链中，每条链上只有一个 Home 合约，但可以有 n-1 个 Replica 合约，n 是接入链的数量。

链下代理负责以可信的方式传递跨链消息，链下代理包括 Updater（更新者）、Watcher（观察者）、Relayer（中继者）、Prosessor（执行者）四个角色。其中：

• 每个 Home 合约会对应一个 Updater，Updater 负责签名 [update] ，此处 [update] 一词被当作名词使用，是 Nomad 语境下的一个专用名词，表示一个特定的数据结构，我们统一加中括号“[]”进行表示，一个 [update] 包含上一个消息树的根 _oldroot，和新的消息树的根 _newRoot ，被签名后还会包含 Updater 的数字签名。

[ update ] = [ _oldRoot , _newRoot, _Updater‘s Signature]

• Watcher 负责观察和报告欺诈行为；

• Relayer 负责在链间传递签名后的 [update] ；

• Prosessor 负责在 [update] 传递成功之后，将对应的跨链消息原文（包括默克尔路径）传递到目标链，并触发目标链 Replica 合约用 [update] 验证跨链消息，然后将验证过的消息发送给最终的目标应用程序执行。

Channel

在 Nomad 中，一个 Home 合约和一个对应该 Home 合约的 Replica 合约可以组成一个 Channel ，这个 Channel 是单向的，如果要进行双向的跨链传输，需要两个成对的 Channel 。一个 Home 合约可以对应多个 Replica ，因此从一个源链出发，面向多个目标链，会有多个 Channel 。

消息流

我们来看下 Nomad 中的跨链消息传递过程：

1. 应用程序调用源链 Home 合约，将需要跨链的消息 T 排入发送队列；

2. 源链 Home 合约中在 T 消息之前最新的消息根，我们设为 _oldroot，步骤 1 完成后，Home 合约将消息 T 进行格式化处理，作为叶子节点插入消息树，计算出新的消息根 _newRoot，_newRoot 和 oldRoot 唯一的区别就是  _newRoot 包含了消息 T ；

3. Updater 调用 Home 合约中的 update 函数，对 _oldRoot、 _newRoot 进行签名后传回 Home 合约。该行为被称为 update（这里作为动词，我们不加中括号 ），每有一个新消息根产生，就可以 update 一次，但为了节约成本，updater 也可以在多个新消息根产生后，进行批量 update ；

4. Relayer 将被 Updater 签名后的 [update] 传入目标链，并调用目标链  Replica 合约将传入的 [update] 放入待定池，启动争议窗口期；

5. 争议窗口期内，Wactcher 对欺诈行为进行检查，主要是看 Home 合约中被 Updater 签名的 update 和 Relayer 传递到目标链上的 update 是否一致，防止消息根被篡改；

6. 计时结束，没有 Watcher 报告欺诈，Prosessor 将从源链获取消息 T 及 T 的默克尔路径，传入目标链，在目标链上调用 Replica 合约，验证 _newRoot 对消息 T 的包含性。证明完成后，Prosessor 将消息移出待定池，发送给目标应用程序。

• 验证仅需用到 _newRoot，_oldRoot 的作用应该是定序。

消息树的结构可以防止 Updater 审查消息，还可以方便 Watcher 发现欺诈行为。

欺诈处理流程

以上过程是我们先假设没有欺诈行为发生，如果Watcher发现欺诈：

• 源链 Home 合约中的 [update] 与被 Relayer 中继到目标链上的 [update] 不一致，被篡改的 _newRoot 中可能包含了一个把大量资金转给 Updater 的交易。

那么 Watcher 将需要在 30min 内，先向目标链上的 Replica 合约提交欺诈证明，将欺诈的 [update] 标记为不可信状态，然后向源链上的 Home 合约提交欺诈证明，触发 Home 合约 Slash 掉不诚实 Updater 的保证金并停止处理新的待发消息。这意味着从该链向其他链发送消息的 Channel 被关闭。需要注意的是，此时，从其他链向此链发送消息的 Channel 仍是开启状态。

后续 Nomad 将通过治理来擦除错误的 [update] ，改选 Updater，重启 Channel。

你可能会疑惑，明明是 Relayer 向目标链上传递了被篡改的消息根，为什么要处罚 Updater ？原因很简单：Relayer 无法伪造 Updater 的签名，如果 Relayer 传递了被一个篡改的 [update] ，一定是 Updater 签名了这个被篡改的 [update] 。作恶的来源只能是 Updater ，作恶的 Updater 完全可以自己运行一个 Relayer 服务或者串谋一个 Relayer 来完成作恶行为。

深入理解 Nomad 的 4 个链下代理

我们看到，Nomad 的链下代理有4种之多，看起来似乎有些复杂，但这四个角色缺一不可，我们来为它们的职责做一个进一步的辨析。

• Updater 仅仅负责签署 [update] ，并传回源链，不负责消息本身的传递；

• Relayer 则仅仅负责在链间传递 [update] ，消息原文及默克尔路径的传递则是由 Prosessor 完成；

• Prosessor 是 Nomad 独有的一个链下代理角色，为什么要单独增设这么一个角色呢？这是因为欺诈证明完成之前，Relayer 传递到目标链的 [update] 处于待定状态，此时传递消息 T 是没有意义的。Prosessor 要负责在欺诈证明完成后（争议窗口计时结束后），手动去触发目标链结束这种待定状态，此时再将消息T传递过去，让 Replica 合约用确定后的 [update] 来验证消息 T。对于常规的外部验证跨链桥，是没有这些过程的，传递到目标链的消息可以直接被处理，因此并不需要 Prosessor 这样一个角色。

• 无论是 Relayer 还是 Prosessor ，都是完全无需信任、无需准入的角色，因此 Nomad 并不关心谁去完成它，实践中，它可能是应用程序项目方或者任何第三方。

• Nomad 对 Relayer 并没有任何信任假设，只有活性假设，这是因为 Relayer 无法伪造 Updater 的数字签名（Updater 的公钥已在目标链的 Replica 中注册），只能忠实的履行其职责，Relayer 能对系统造成最大的伤害也仅仅是离线，使得跨链服务暂时不可用。正如前文所说，欺诈的来源只能来自于 Updater ，不可能是 Relayer 。

• 由于信任的基础是至少有一个诚实的watcher，因此，在 Nomad 中，不需要 Updater 层面的去中心化。事实上，每个 Home 合约只需要对应一个 Updater ，并不需要像外部验证方案那样，需要一个足够多元化的验证者集，这有助于降低开销。如果应用程序项目方联合了更加多元化的主体，更好的选择是让他们去做 Watcher 。Nomad 没有系统级的 Watcher 集，需要应用程序自定义自己的 Watcher 集。

Nomad 的应用

Nomad 已经创建了自己的 Swap 桥，并将其与 Connext 集成在同一个界面中。用户可以使用该界面自由的进行跨链资产交换。如果用户要跨链的资金较小，Connext 可以实现更快的速度，如果用户要跨链的资金较大，Nomad 可以提供更低的费率，二者互为补充。我们可以预期，大多数用户都将使用「快速通道」—— Connext ，而为「快速通道」提供流动性的 LP 则通过「慢速通道」—— Nomad  来调节不同链上的流动性。这与以太坊跨层项目中「原始通道」与「快速通道」的配合如出一辙。

资产发行者可以通过 Nomad ，让自己的资产变成多链资产。例如，Covalent 将他们的网络质押通证 $CQT 从以太坊迁移到了 Moonbeam ；Hummingbot 将他们的治理通证 $ HBOT 从以太坊迁移到了 Avalanche 。

应用开发者可以通过 Nomad 部署多链应用，Nomad 将其称为 xAPP（读作Zap），xApp 可以调用 Home 合约和 Replica 合约，实现跨链消息的收发。Nomad 的开发者文档里提供了代码示例。

Nomad 与 Gnosis 合作开发了 Zodiac Nomad Module（ZNM），一个专注于跨链治理的通用模块。DAO 可以通过在 Nomad 支持的链上部署 ZNM ，实现治理决议在多链同时执行。

截至 2022 年 9 月，Nomad 支持六个链：Ethereum、Moonbeam、Evmos、Milkomeda、Gnosis Chain 和 Avalanche ，我们认为 Nomad 跨链桥的设计是有开创意义的。但不幸的是，由于合约代码的漏洞，Nomad 托管合约中的资金遭遇黑客洗劫，损失超过 1.9 亿美元，本文撰写时，Nomad 正在致力于回收损失资金，相关跨链桥功能处于停用状态，我们希望 Nomad 能早日渡过难关，重振旗鼓。

Nomad Docs

https://docs.nomad.xyz/nomad-101/introduction

Celer IM

Celer 在 2022 年 3 月发表的一篇博客中，提到了一个新的混合框架 Celer IM ，该框架将外部验证和乐观验证结合在一起，让应用程序可以自行选择合适的安全模型。我们来看看具体设计：

Celer IM 主要包含以下几个部分

• State Guardian Network（SGN）: 这是一个基于 Cosmos SDK 开发的 PoS 区块链，具有一组抵押 $CELR 的验证者，负责验证并签署跨链消息；

• Message Bus 合约：部署在接入链上的一组合约，负责管理跨链消息的收发；

• Executor：负责将被验证过的跨链消息中继到目标链。

消息流

1. 用户通过源链的应用程序将其需要发送的跨链消息提交给源链上的 Message Bus 合约；

2. SGN 中的验证者监听到消息并对消息进行共识签名；

3. Executor 将跨链消息中继到目标链上的 Message Bus 合约；

4. 目标链上的 Message Bus 合约在确认消息签名有效之后默认立即推送给目标应用程序进行执行。

应用程序可以选择不立即处理收到的跨链消息，而是使用双重确认模式。这种模式下，消息被目标链上的 Message Bus 合约一次确认后，会被提交到一个「隔离区」，过了一定的窗口期，才能认为这条消息被二次确认，并推送给目标应用程序。

在窗口期，应用程序可以运行 App Guardian 服务来检查隔离区中消息的真实性，如果发现与源链发出的消息有不一致的情况，可以阻止消息被目标应用程序执行，并在源链报告欺诈行为。

不同于 Nomad ，报告欺诈行为并不能自动触发 Slash ，因为验证人没有在源链抵押。如果出现欺诈行为，如何对验证者进行惩罚和替换，Celer IM 文档中没有说明，笔者认为，应该需要治理流程的介入。

我们看到 Celer IM 提供了外部验证和乐观验证两种安全模型，前者的信任假设是SGN 网络中诚实验证者掌握 2/3 以上的投票权，后者的信任假设则是至少有一个诚实的 App Guardian 服务在运行。

双模型的设计给应用程序开发者提供了灵活的选择。例如资产桥应用可以根据跨链的资产价值来触发不同的流程，执行不同的安全模型，这样小额资产跨链可以保持迅速，而大额资产跨链则可以被充分保障安全。

Celer IM 介绍文章

https://blog.celer.network/2022/03/07/optimistic-or-fast-your-choice-celer-inter-chain-messages-two-flexible-security-models/

CounterStake Bridge

CounterStake Bridge 是一个很有意思的 Wrap 资产桥项目，它采用一种被称为「增筹挑战」的游戏机制来维护跨链的安全。这是一个纯粹依靠经济假设而成立的安全模型。由于存在乐观挑战期，我们也将其归类为乐观验证。

假设用户 A 需要将 Obyte Chain 上的 1000 $BYTES 铸造为以太坊上的 1000 $wBYTES，用户需要在 Obyte Chain 上锁定 1000 $BYTES 的同时，在以太坊上质押等价的 $ETH（默认质押资产是目标链上的原生资产），我们假设为 1 ETH 。

此时将开启一个挑战期，如果没有人挑战，那么用户A将在目标链上获得 1000 $wBYTES，并拿回质押的 1 ETH。

如果用户 B 认为用户 A 的行为存在欺诈，比如说用户 B 认为用户 A 可能没有在源链足额质押，那么用户 B 可以在以太坊质押 1.5 ETH 发起挑战，开启一个新的挑战期（比前一个挑战期略长），该挑战期内如果没有人挑战用户 B 的挑战，则用户 B 挑战成功。如果用户 B 挑战成功，用户 A 将无法在以太坊上获得 1000 $wBYTES，与此同时，用户 B 除了可以拿回自己质押的 1.5 ETH 之外，还可以拿到用户A质押的 1 ETH 作为挑战赏金。

当然，如果有人认为用户 B 的挑战是欺诈的，也可以对用户 B 发起挑战，这个人可以是用户 A 本人，也可以是其他任意用户。如果要对用户 B 发起挑战，那么需要质押 2.25 ETH，挑战期也会进一步延长。

这个挑战的链条可以一直持续下去，每多一轮挑战，挑战质押金都会增加 50%，挑战期都会延长。最终，当没有人再继续挑战时，游戏结束，质押的资金将在胜者一方当中分配，获胜方的 ROI 为 66.7% 。

CounterStake Bridge 认为：实践中大多数的资产跨链铸造都会在一轮挑战后结束，真相会成为谢林点。

此外，资产的跨链铸造和跨链返回的流程是一致的，也适用于增筹挑战游戏。

为了减少用户跨链转移资产的时间，CounterStake Bridge 当中还有一个被称为 Assistant（助理）的角色。任何人都可以成为 Assistant，在用户发起跨链资产转移时，为用户垫付资产和抵押金，并从中获得一部分手续费。

用户如果希望通过 Assistant 加速交易，可以在发起交易时，设置给 Assistant 的佣金比例。如果有 Assistant 接手你的交易，那么你将立即获得跨链铸造的资产和质押金，然后 Assistant 将替你在增筹挑战游戏中守护你的交易。Assistant 可以是独立的个体，也可以是一个社区资产池，以 DAO 的方式运行。

现在 CounterStake Bridge 支持的链有 Obyte、Ethereum、BSC、EOS、Fabric。CounterStake Bridge 在实际运行中会如何？真相会成为谢林点吗？会不会出现巨鲸决定结果的局面？还有待验证。

CounterStake Bridge 简介

https://counterstake.org/how-it-works

小结

乐观验证作为一种全新范式，突破了跨链不可能三角，成为了跨链桥信任层构建的全新选择。乐观验证桥最大的弊端是挑战窗口期的延迟，这会给用户体验带来不利的影响。但可以通过混合架构来弥合这个延迟。

• Nomad 与 Connext 合作，为用户提供一条快速通道；

• Celer IM 则将乐观验证与外部验证组合在一起，让应用程序可以根据跨链请求的不同，为用户提供一重验证和双重验证两个不同的选择；

• CounterStake 则设置 Assistant 来帮助用户加速交易。

我们看到，乐观验证最大的应用场景，似乎是与其他验证方式组合在一起，把安全和效率的权衡，交给用户。这种组合式的信任层构建，或许是跨链桥未来的发展方向之一。