XCMP docs

5.6.11 外部验证桥小结

以上我们举了若干个外部验证桥的案例，包括：

两个 PoA 桥，分别是 AnyCall、Wormhole；

五个 PoS 桥，分别是 Axelar、Hyperlane、Gravity Bridge、pNetwork V2、Bool Network；

两个 TEE 桥，分别是 pNetwork V2、Bool Network；

一个采用外部 Oracle 的桥，LayerZero，还有一个预言机服务商亲自建设的桥 CCIP；

两个共享验证桥：分别是 Gravity Bridge 和波卡的 XCMP。

读者可能发现，我们列举的两个 PoA 桥，都遭遇了非常严重的黑客攻击。尽管外部验证桥在安全假设上的确有验证人联合作恶的风险敞口，但事实上，被攻击的原因并非安全假设层面，而是代码实现上的漏洞。而 PoA 桥更容易吸引黑客攻击，恰恰是因为其实现简单，入场较早且发展较快，TVL 很高，成为了黑客眼中的肥肉。因此，我们不会因为某个项目遭遇了黑客攻击，而否认该项目的整体结构设计。关于跨链桥如何提高安全性和防范黑客攻击的话题，我们会有专门的章节。

PoS 桥的实现也并不困难，但守护桥梁的通证需要有较大的市值，才能充分保障网络的安全，否则攻击桥梁的经济成本将会很低。因此，PoS 桥的发展可能会将 PoA 方案作为过度阶段，在 TVL 上升，推高通证价格之后再转 PoS。PoS 桥要面对的一个问题是验证者的不均衡性，例如 Axelar 有 50 个验证者，但想要达到 2/3 的签名阈值，只需要 10 个左右的头部验证者签名就可以了，为了缓解这个问题，Axelar 采用了二次方投票的方案；Hyperlane 则采用「可验证欺诈证明」方案，验证人联合作恶将立即被发现并执行 Slash；pNetwork 和 Bool Network 则直接要求所有节点质押相同数额的 Token。

pNetwork 和 Bool Network 要求 PoS 验证者用 TEE 来存储私钥、执行签名，以防止外部攻击者窃取私钥，攻击跨链桥，Bool Network 还通过 TEE 节点的轮换机制和匿名机制，让内部的节点串谋也变的十分困难。LayerZero 独具特色的构建了两个信任层，一个是外部 Oracle 网络，一个是负责传递消息的 Relayer，只要二者不串通，就可以保证跨链的安全。LayerZero 还通过应用程序负责制，在各应用程序之间实现跨链的风险隔离。CCIP 同样构建了两个信任层，一个是预言机网络，一个是反欺诈网络，此外，Chainlink 丰富的节点资源将为其赋能。

Gravity Bridge 和波卡的 XCMP 都是共享验证的案例，Gravity Bridge 依旧可以用 PoS 桥的范式去理解，只是桥的安全性与 Gravity Chain 的安全性一致，Gravity Bridge 正在计划从 Cosmos Hub 中租用安全性（这是 Cosmos 2.0 的新功能），将桥的安全性进一步提升。XCMP 则是基于波卡被深度定制，致力于实现波卡平行链间的同构跨链，与其说跨链，更像是跨分片，我们最好以跨分片的视角去理解它。

5.7 本地验证桥

本地验证仅适用于 Swap 桥。目前来看，采用本地验证方案的桥主要是以太坊跨层资产桥，我们已经在本系列第二篇 5.2.3 小节 列举了 cBridge、Connext、StarEx Bridge 三个典型案例。因此本小节不再举例。

5.8 乐观验证桥

5.8.1 Nomad（前身 Optics）

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

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

5.8.1.1 核心概念及结构

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

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

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

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

需要注意的是，接入 Nomad 的区块链中，每条链上只有一个 Home 合约，但可以有 n-1 个 Replica 合约，n 是接入链的数量。这样的设计与 Hyperlane 似曾相识。

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

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

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

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

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

Channel

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

5.8.1.2 消息流

我们来看下 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 将消息移出待定池，发送给目标应用程序。

Nomad 和 Hyperlane 一样都采用消息树的结构，这样可以防止 Updater 审查消息，还可以方便 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 来完成作恶行为。

5.8.1.3 深入理解 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 集。

5.8.1.4 Nomad 的安全特性

我们来回顾下跨链互操作不可能三角：以下三者，最多只能得其二。

· 可扩展性（Extensible）：支持广义跨链计算

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

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

Nomad 在以一个独特的方式破解跨链互操作不可能三角，Nomad 具有外部验证方案的两大优势：可扩展性（Extensible）和普适性（Generalizable），在此基础上，Nomad 使用欺诈证明机制，使得跨链桥的 Trustless 水平接近于原生验证（只需要有一个 Watcher 是诚实的，系统就是安全的）。我们发现，在 Nomad 中，跨链互操作不可能三角的三个条件被神奇的同时满足了！

当然，这不是没有代价的，代价是 30min 以上的延迟，这可能导致某些类型的应用不适合使用 Nomad 实现其跨链功能。

5.8.1.5 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 能早日渡过难关，重振旗鼓。

Optimistic Bridges：A New Paradigm for Crosschain Communication

5.8.2 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 服务在运行。

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

5.8.3 乐观验证小结

乐观验证作为一种全新范式，突破了跨链不可能三角，成为了跨链桥信任层构建的全新选择。乐观验证桥最大的弊端是挑战窗口期的延迟，这会给用户体验带来不利的影响。但无论 Nomad 还是 Celer IM，都在尝试弥合这个问题：

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

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

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

5.9 跨链桥的一般性

行文至此，我们是时候来总结一下跨链桥的一般性了。不同的跨链桥有不同的设计，但基本上有一个通用的结构，我们可以将其分为三层：

· 信任层

· 传输层

· 应用层

5.9.1 信任层

任何跨链桥，首先要解决的都是不同链间传输消息的信任问题。我们根据信任层构建方式的不同，对桥的类型进行了最基本的划分，本篇文章的行文结构也照此进行。

对于原生验证桥，信任层是链上的轻客户端程序，以及负责传递区块头的 Head Relayer ；

对于外部验证桥，信任层是一个 PoA/PoS 网络，或是一个外部 Oracle 网络；

对于本地验证桥，信任层是交易流程本身；

对于乐观验证桥，信任层则是负责报告欺诈行为的观察者。

5.9.2 传输层

在确定信任层的构建方式后，传输层的设计成了跨链桥的重头戏。有的跨链桥构建了较为完善的传输层，有的跨链桥的传输层则相对简单，更多传输层的事务交给了应用层去设计。相对完善的传输层更便于应用程序的接入。

传输层的基本任务是构建消息传输的秩序，管理消息的时序、状态，如果是多链跨链，还要管理消息的寻址和路由，制定统一的消息格式。传输层一般由一组负责管理消息队列的一组链上智能合约和一套消息状态更新逻辑组成。不同的跨链桥对这一组链上智能合约的称呼不同，但其职能是相同的。

如何理解跨链消息

跨链的应用场景可能是多样的，包括

· 跨链合约调用：一条链调用另一条链上的合约执行某种功能，并返回执行结果

· 跨链计算：将多条链上的参数作为输入，计算一个值作为应用程序的输入

· 跨链治理执行：将应用程序在一条链上的治理投票结果，同步在多条链上执行

· 跨链资产映射：将资产在一条链上锁定的消息传递给另一条链，触发映射资产的铸造

但所有的场景，其本质或者说实现途径都是跨链消息的传输，也就是说如果能实现消息在链间的可信传输，以上的跨链应用场景，就都可以实现。

跨链消息的本质是一条链上发生的事情，体现为一笔或多笔交易，当然「交易」一词并不意味着一定有资产的转移，「交易」在区块链中往往指的是任意形式的状态转换。跨链桥会为消息制定一个统一的格式，其中会包含「交易」的相关元数据、应用程序为交易写入的备注信息（payload）等，对于原生跨链桥，或者采用消息树结构的跨链桥，消息还包括「交易」的默克尔路径。

消息流

跨链消息的传输一般会经历这样的过程：

1.应用程序向源链上管理发送队列的合约提交格式化后的消息；

2.消息被传递到目标链上的管理接收队列的合约，当然，消息必须经过信任层的验证，可能在传递到目标链之前，也可能在传递到目标链之后；

3.目标链上管理接收队列的合约将被验证后的消息转发给目标应用程序进行执行；

4.消息执行成功的回执返回源链，更新消息在发送队列中的状态为已发送或直接删除。

消息队列结构

大多数跨链桥的消息队列是消息原文的队列，一些跨链桥会在消息队列的基础上，构建消息树，形成一个根值队列，例如 Hyperlane、Nomad、XCMP，这样做可以分离根值的传输和消息原文的传输，以实现消息的抗审查性和防篡改性，还可以降低根值传输层的负荷。

Channel

在一些多链跨链桥当中，还存在 Channel 的概念，Channel 的概念是虚构的，其本质是建立在两条链上的一对消息队列。Channel 概念的存在，意义在于

· 组织消息时序：Channel 内部的消息将有时序关系，不同 Channel 之间的消息则没有时序属性；

· 管理消息收发权限：没有 Channel 的链间无法传输消息，如果某条链不想接受另一条链的消息，可以拒绝打开对应的 Channel。

包含 Channel 概念的跨链桥有 Cosmos、XCMP、Nomad，但它们各自的设计又有所不同。在 Comsos 中，Channel 是建立在应用程序之间的（建立在链之间的 Channel 被称为 Connection）而且是双向的，两条链之间建立 Channel 意味着二者可以进行消息的双向传输。但在 XCMP 和 Nomad 中，Channel 是单向的，双向跨链传输需要成对的两个 Channel。在 XCMP 中，一个 Channel 对应一个出口消息队列 Egress ；但在 Nomad 中，多个 Channel 对应一个出口消息队列（Home 合约），这意味着 Nomad 的 Home 合约中管理的是从该链发出的所有消息，不区分目的地（目的地字段在消息正文中），这使得 Nomad 可以支持一对多的消息传输模式。

5.9.3 应用层

应用层往往是 AMB 桥才会有的，AMB 桥往往会为应用提供一套组件，应用程序通过集成这些组件、调用相关模块来实现跨链消息的收发。如果跨链桥是作为一个独立的应用程序运行的，那么它就没必要考虑为其他应用的接入提供便利。

5.9.4 激励层

无论是信任层还是传输层，都可能会涉及到激励的问题。我们不妨把它单独拿出来作为一个新的层讨论。

· 信任层激励：对于原生跨链桥，需要激励 Relayer 提交区块头以维护轻客户端；对于外部验证桥（PoS），需要激励验证者忠实的履行职责；对于乐观验证桥，需要激励观察者忠实履行职责；对于本地验证桥，则需要激励公共交易对手提供充足的流动性。

· 传输层激励：需要激励有关角色向目标链提交跨链消息，垫付目标链上跨链消息验证和执行产生的费用。

激励的方式可能是多种多样的，可以是将用户端的收费直接支付给激励对象，也可以是跨链桥项目方用自身金库或是通胀奖励来补贴激励对象，还有一种情况是，应用层为激励对象制定激励规则，或者应用层直接承担激励对象的职责。

5.9.5 总结

以上，我们通过跨链桥的分类、举例、分析，对跨链桥的构建方式有了更深的认识。这就是 PAKA 跨链研究报告系列的第三篇。我们将在不久后发布第四篇，也就是最终篇。在最终篇当中，我们将着重探讨一些应用层的实现，尤其是 Wrap 桥、Swap 桥以及其他类型的跨链 DeFi 应用，然后进一步讨论一些重要的跨链衍生命题。