5.6.1 Anycall（Multichain）

Mutichain 是入场较早的跨链桥项目，产品上线于 2020 年 7 月，当时的名字叫 Anyswap。2021 年底融资之后，品牌名称改为了 Multichain，治理通证也从 $ANY 置换为了 $MULTI。在遭遇 2022 年初的合约漏洞事件之前，Mutichain 的业务规模是跨链桥领域无可争议的王者，但在漏洞事件造成很多用户的资产损失后，TVL 有所缩减。

现在 Multichain 的业务被规划为三条产品线，分别是

· Swap 桥：Anyswap

· Wrap 桥：Crosschain Router Protocol（CRP）

· 任意消息桥：Anycall

其中 Anycall 是前两者的信任层。

AnyCall 是一个用户交换任意数据的通用跨链传递基础设施，采用 PoA 的方式构建。它由部署在链上的一组智能合约（anycall/anyExec），和一个 SMPC 网络组成。SMPC 的含义是安全多方计算（Secure Multi-Party Computation），Anycall 当中的每个 SMPC 节点独立验证消息，并基于私钥分片和门限签名技术，对消息进行签名，超过 2/3 节点签名的消息被认为通过验证。

SMPC 网络由 24 个节点组成，这些节点将负责监听链上 [anycall] 合约中的待发消息，并进行签名后，中继到目标链的 [anyExec] 合约。Dapp 通过与 anycall/anyExec 合约交互来实现跨链消息的收发。SMPC 节点成员不需要质押，且相对固定，AnyCall 的安全建立在对 SMPC 节点的信任假设基础上。

Multichain 的治理通证 $MULTI 的持有者，可以通过锁仓 $MULTI 获得 veMULTI，用其参与 Anycall 及 Multichain 旗下其他产品的治理，并可以获得 Multichain 的收入分成。

截至 2022 年 9 月，anyCall 支持跨 11 条链的任意消息传递：BNB Chain、Polygon、Ethereum、Optimism、Gnosis Chain、Fantom、Moonriver、IoTeX、Arbitrum、Avalanche、Harmony。明星 DeFi 项目 Curve 集成了 anycall 以支持 Gauge Weights 的跨链计算。

5.6.2 Wormhole

Wormhole 是由 Solana 和 Certus One 联合开发的跨链桥，起初是一座连接以太坊和 Solana 的资产桥。但随着后来的发展，Wormhole 已经演变成了一个支持 14 条异构公链之间传送任意消息的通用 AMB 桥，而资产桥的功能将由作为 Wormhole 应用程序的 Portal Bridge 承担。

和 Multichain 相同，Wormhole 的信任层采用 PoA 机制构建，由一组受信任的 Guardians（守护者)）负责链间消息的验证。这些 Guardians 是特定的具有资本背书和声誉背书的主体。目前，Wormhole 中的 Guardians 有 19 个，其中包括 FTX、Everstake 和 Chorus One 等知名大公司。

Wormhole 的结构非常简洁，其跨链消息格式被称为 VAA（Verifiable Action Approval），在 Wormhole 支持的链上部署了一组被称为 Core Bridge Contract 的合约。该合约将来自应用程序的跨链请求处理为 VAA，19 个 Guardians 监听链上生成的新的 VAA，并对其进行签名。然后被称为 Relayer 的角色负责将签名后的 VAA 中继到目标链。目前链上的 Core Bridge Contract 收到签名后的 VAA 之后，验证其签名，然后转交给目标应用程序。

Guardians 对 VAA 的签名是独立的，每个 Guardians 都单独执行该步骤，然后这些签名最后组合成一个多重签名。一条 VAA 的批准，需要至少 2/3 的 Guardians 签名。Guardians 的成员是相对固定的，如果需要更换，将通过治理投票来完成。

Relayer 负责传送签名后的 VAA，该动作将在目标链上产生 Gas 费用（包括将消息提交给 Core Bridge Contract 存储的 Gas 费，和目标应用程序执行该消息的 Gas 费），Relayer 将垫付这部分费用。Wormhole 没有设置公共的 Relayer，各应用程序需要自己设计对 Relayer 的激励与相应的用户端收费，或者自行运行 Relayer。

对于 PoW 的以太坊，有个最终性确认的问题。在 Wormhole 中，消息需要等待多少个区块追加才能视为确认，是一个可以自定义的安全参数。

截至 2022 年 9 月，Wormhole 支持 14 条链：Solana、Ethereum、Terra Classic、BNB Chain、Polygon、Avalanche、Oasis、Aurora、Fantom、Karura、Acala、Klaytn、Celo 和 Terra。

2022 年 2 月，Wormhole 遭遇黑客攻击，由于合约编写漏洞，致使攻击者通过伪造签名，在 Portal Bridge 上为自己铸造大量资产。该攻击造成的损失超过 3.2 亿美元。在 Jump Crypto 等主要的资方支持者的帮助下，Wormhole 已经从攻击中恢复。

Wormhole 文档

5.6.3 Gravity Bridge

Gravity bridge 于 2021 年 12 月份启动，其目标是桥接 Cosmos 和以太坊生态。目前，Gravity 还只是一座资产桥，支持以太坊和 Cosmos 之间的资产传递，不支持任意消息传递。

结构

Gravity Bridge 的信任层以 PoS 的方式构建，Gravity Bridge 的 PoS 验证者同时也是 Gravity Chain 的验证者，因此 Gravity Bridge 可以归为共享验证桥。

Gravity Chain 由 5 个部分组成

· Gravity Chain 及其验证者：一个基于 Cosmos SDK 构建的区块链，其验证者将以 PoS 的方式验证 Gravity Chain 与以太坊之间的跨链消息

· 一个名为 gravity.sol 的以太坊合约：实现以太坊端的 mint-burn/lock-burn 逻辑；

· Gravity Module：实现在 Gravity Chain 端的 mint-burn/lock-burn 逻辑；

· Orchestrator：是 Gravity Chain 上的一串代码，负责向 Gravity Chain 提交交易；

· Relayer：负责向以太坊提交 Gravity Chain 上的交易，并从中获得用户支付的跨链费用。

消息流

要将 Token 从以太坊转移到 Gravity Chain，用户需要调用 sendToCosmos 方法。该方法从用户那里接收一定数量的 ERC20 Token 并将它们锁定在 Gravity.sol 中。它还发出一个事件：SendToCosmosEvent。Gravity Chain 的每个验证者都运行一个以太坊全节点以监控以太坊的事件，当任意一个验证者监控到 SendToCosmosEvent 时，Orchestrator 将向 Gravity Module 提交事件，Gravity Module 将跟踪事件，当该事件被 Gravity Chain 的验证者签名验证并被打包到区块中时，触发 Gravity Module 为目标地址铸造 Token。与 PoA 不同的是，PoS 中，每个验证者的签名权重是不同的，签名权重与他们的质押的 $GRAV 成正比。

如果要将 Token 从 Gravity Chain 转移到以太坊，过程相对简单，只需要 Relayer 将 Gravity Chain 上验证过的 lock 或者 burn 交易，提交到以太坊，gravity.sol 合约将为目标地址铸造 Token。

批处理

由于以太坊上 gas 费用高昂，从 Cosmos 到以太坊上的交易将会实施批处理。

当用户想要将 Token 从 Cosmos 发送到以太坊上的地址时，他们会通过 Gravity Module 将 Token lock（原生资产）或是 burn（非原生资产）。Gravity Module 将 lock/burn 交易放入交易池中。交易池存储所有尚未成批的 Cosmos 到以太坊的交易。（同一批次的交易仅限于一种 Token，不同的 Token 转移会被分配到不同的批次中）

任何人都可以发送请求 Gravity Module 组装一批交易，这往往由希望中继一批 Token 以获取利润的中继者完成。当 Gravity Module 收到此消息时，它会按照以下过程组装批次：

1. 查找该 Token 的所有交易；

2. 选择费用最高的 100 笔交易，并将它们放在一起，组成一个批次；

3. 如果中继该批次有利可图，则将该批次放入批次池，若无利可图，则放弃该批次，批次中的交易会回到交易池中，等待组装到其他批次；

4. 进入批次池中的批次，将被验证者签名，并被打包到区块中；

5.Relayer 持续监控批次池中的批次，一旦有批次的签名超过阈值（2/3），就将其提交给以太坊上的 gravity.sol，并支付以太坊上提交和处理该批次的 gas 费用；

6. 批次处理完成后，Gravity.sol 就会发出一个 TransactionBatchExecutedEvent，验证者观察到该事件后，将其提交给 Gravity Module，触发删除该批次。

验证者集的更新

Gravity.sol 需要了解 Gravity Chain 上的验证者更新，才能判断 Relayer 发送过来的消息或是批次，是否是被正确的验证者集签名。

任何人都可以从 Gravity Chain 发送跨链消息，请求更新 Gravity.sol 中的验证者集。我们在讲原生验证桥时，提到过 PoS 轻客户端掌握最新验证者集的方法，Gravity.sol 用到的方法与之相似，但 Gravity.sol 并不是轻客户端，它不会存储 Gravity Chain 的区块头，而是让 Relayer 将验证者集的变更信息快照中继过来，存储为一个检查点。

所有的 PoS 跨链桥，包括我们后文提到的 Axelar、Hyperlane，用的都是类似的办法。

5.6.4 Axelar

Axelar 发起于 2020 年年底，主要成员来自 Algorand 团队的跨链桥项目，致力于为 Web3 应用提供跨链互操作性。2022 年 2 月 15 日，Axelar 以 10 亿美元估值，完成 3500 万 美元融资，投资方包括 Dragonfly Capital、Polychain Capital 等知名机构。

Axelar 基于 PoS 机制构建桥梁的信任层，Axelar 本身也是一个基于 Cosmos-SDK 创建的 PoS 公链。需要注意的是，Axelar 本身是公链，但它并不是中继链，只是桥接链，这两个概念在本系列第一篇中有过辨析。

结构

Axelar 由以下部分构成：

· PoS 验证器网络：由 $AXS 驱动，承担双重职责 负责验证网络正在处理的所有跨链活动，这需要验证器运行接入链的节点（可以是全节点，也可以是轻节点）； 负责 Axelar Chain 的交易验证和共识出块；

· 网关合约（Gateway Smart Contracts）：部署在每条接入链上，以实现跨链消息收发功能；

· 开发者工具：包括一套软件开发工具包（SDK）和应用程序编程接口（API），借助这些工具，开发人员可以轻松部署跨链 dApp，并使用 Axelar 网络实现跨链任意消息传输。

此外，为了改善用户体验，Axelar 还提供了两组 Relayer 服务和 Gas Reciever 合约。

Relayer 服务：其中一组 Relayer 负责监听源链网关合约上发起的跨链消息并提交给 Axelar 网络，另一组 Relayer 负责将被验证过跨链消息提交给目标链的网关合约，垫付目标链上存储和执行消息的 Gas 费。Relayer 服务是可选的，用户和应用也可以执行这两组 Relayer 承载的任务。专设一组 Relayer 负责监听源链消息，是为了降低验证者的负荷。

Gas Reciever：用户的跨链操作将产生三笔 Gas 费用，分别是源链上的 Gas 费用，Axelar 验证器网络的费用（$AXS 形式），目标链的 Gas 费用，如果要求用户分别支付这三笔费用，那么用户体验将相当糟糕，Axelar 在源链上提供 Gas Reciever 服务，用户仅需以源链的 Token 支付一笔跨链费用，Gas Reciever 会自动将其中的一部分兑换为 $AXS 和目标链的 Token。

消息流

一旦 dApp 用户发起跨链消息发送请求，其第一站是与源链上的网关合约交互，网关接收到消息将发出一个事件，Relayer 监听到事件，然后将消息提交给 Axelar 验证器网络。

验证器网络对该消息进行签名，签名权重与他们质押（包含被委托质押）的 $AXS 数量有关。但签名权重与质押的 $AXS 数量并不是线性关系，Axelar 采用的是二次方投票（Quadratic Voting）机制，签名权重将与验证人质押的 $AXS 数量的平方根成正比。需要注意的是，二次方投票仅针对跨链消息的投票，Axelar Chain 自身的交易签名和区块签名仍遵循一 $AXS 一票原则。

消息被签名后，Relayer 将消息提交到目标链 Gateway 合约，并由目标应用程序处理。

Axelar 作为一个基于 Cosmos-SDK 构建的公链，除了通过验证器网络桥接了一众 EVM 链的跨链以外，还通过 IBC 进行扩展，接入了更多 Cosmos 链。目前接入 Axelar 的网络已经有 22 个。Axelar 之所以能有现在的成就，与其深度融入 Cosmos 生态系统有很大关系，Axelar 在开发和治理过程中，有 Cosmos 社区的积极参与，而且通过将 Terra、Classic、Osmosis、Secret Network 和 Jun 等 Cosmos Zone 连接到 EVM 世界，获得了大量的跨链业务量。

5.6.5 Hyperlane（曾用名：Abacus）

Hyperlane 被人所熟知的名字是 Abacus，它拥有一个阵容豪华的创始团队。团队中有 Celo 的首批工程师 Asa Oines 和 Nam Chu Hoai 以及之前共同领导 Galaxy 风险投资业务的 Kol。顾问包括 NFX 的合作伙伴 Morgan Beller、Facebook 的 Stablecoin Diem 的联合创始人，以及 Cosmos 联合创始人 Zaki Manian。2022 年 9 月 22 日，Hyperlane 宣布完成 1850 万美元融资，加密风投 Variant 领投。

Hyperlane 将致力于提供一组 API 接口，让应用程序通过调用它实现跨链消息的收发。

结构

Hyperlane 包括以下组成部分：

· 链上负责消息收发处理的合约：分别是 outbox 合约和 inbox 合约，每条接入链上都有一个 outbox 合约，outbox 合约中维护了一个由所有消息作为叶子节点的默克尔树（称为消息树），需要发送的消息将提交到 outbox 合约，作为新的叶子节点插入消息树，使消息树产生一个新的根（称为消息根）。每条接入链上都有（n-1）个 inbox 合约（n 为接入链的数量），inbox 合约将负责接收和验证跨链消息，并将其转交给目标应用程序。

· 多个 PoS 验证者集：每条接入链都有一个验证者集，负责签署从该链发出的消息的默克尔根，PoS 验证者需要在其负责验证的链上抵押 $ABC（可能来自其他用户的委托），签署任何消息根之外的内容都被视为欺诈行为，其抵押金将被削减；

· Relayer：负责传递被签署后的消息根，传递消息以及消息的默克尔路径；

· 瞭望塔（Watchtower）：负责监控和报告验证者的欺诈行为。

消息流

发送和接收跨链消息需要四个步骤：

1.用户通过源应用程序调用源链上的 outbox.dispatch 函数，将消息 M 插入到消息树中；

2.源链的 Hyperlane 验证者签署包含消息 M 的新的消息根；

3.Relayer 聚合验证者的签名，并将新的消息根连同消息原文（含默克尔路径）传送到目标链；

4.目标链上的 inbox 合约用消息根和消息的默克尔路径验证消息，然后将验证后的消息传递给目标应用程序。

失败处理：Relayer 可以配置为在处理失败时重试消息。第一次尝试处理失败的消息将导致 Relayer 以指数退避重试。在达到最大重试次数后，Relayer 将不再尝试处理该消息。

Hyperlane 的一大特点是采用消息树结构，这样做的好处有两个：一是验证者不知道消息的具体内容，防止验证者审查消息；二是便于瞭望塔发现欺诈行为，瞭望塔将不需要观察消息本身有没有被篡改，只要被签署的消息根没有篡改，消息就不可能被篡改。

Hyperlane 的另一个特点是每条链上都有独立的验证者集，而不是复用同一个验证者集，这可能导致从不同链发出的消息传递安全性不一致，因此 Hyperlane 为应用程序提供灵活的选择，如果 dApp 项目方认为某个特定链安全性不足，可以选择不集成该链。

费用与激励

PoS 验证者每个 epoch 可以从网络中获得 $ABC 通胀奖励。

Relayer 可以自定义费用结构，以在源链上接受用户的付款，并用其中的一部分支付目标链上的 Gas。Relayers 将组成一个开放的市场，而发起跨链请求的应用程序用户作为买方，自由选择适合的 Relayer。

「可验证欺诈证明」

Hyperlane 将其核心机制描述为「可验证的欺诈证明」，所有的消息根都存储在 outbox 合约中，PoS 验证者集的工作仅仅是为其附上自己的签名，如果在目标链上发现 PoS 验证者签署了篡改后的消息根，瞭望塔就可以把不正确的签署作为欺诈证明提交到源链上，源链上的合约很容易对欺诈进行验证。

这样的机制与乐观验证颇有相似之处，但 Hyperlane 没有乐观验证窗口期，这意味着瞭望塔报告欺诈行为的时候，很有可能行为的后果已经产生（例如不正确的铸币），我们还是需要相信，每条链上 2/3 以上的验证者是诚实的。因此，我们依旧将 Hyperlane 归为外部验证。

但相比其他类型的 PoS 桥，「可验证的欺诈证明」还是有一些明显的不同：

Axelar 这样的 PoS 桥，尽管也会对恶意的验证人进行 Slash，但对恶意验证人的判定方法是「多数原则」，也就是说，如果个别验证人签署了某个消息，而该消息最终没有被 2/3 以上的投票权验证，那么签署该消息的个别验证人将被认为是恶意的，从而触发 Slash。如果发生「真理掌握在少数人手中」的极端情况，那么系统将产生误判，需要治理流程参与进来进行纠错。Hyperlane 的机制可以保证，只要有一个 WatchTower 是诚实的，即便有 2/3 以上的验证人作恶，且导致传输了错误的跨链消息，系统依然可以自动发现错误并对作为多数派的作恶验证人执行 Slash。

与 Hyperlane 机制比较相似的另一个项目 Nomad，是乐观验证的典型案例，我们将在后文介绍。

截止 2022 年 9 月，Hyperlane 支持 7 个链的任意消息传递：Arbitrum、Avalanche、BNB 链、Celo、以太坊、Optimism 和 Polygon。Hyperlane 以 DAO 的方式治理，$ABC 持有者可以通过治理投票对 Hyperlane 协议进行更改。

5.6.6 LayerZero

明星团队，加上明星投资者，让 LayerZero 成为 2022 年上半年最火爆的一个跨链项目，跨链底层协议的叙事，再加上迅速上线若干个落地产品的执行力，让 LayerZero 被业界普遍看好。在 LayerZero 的白皮书中，LayerZero 被描述为一个去信任的全链互操作协议，一个功能强大的基础层的通信原语。

结构

LayerZero 由三个核心组件构成，分别是 Oracle（预言机）、Relayer（中继器）、Endpoint（终端）

· Oracle 是一个第三方服务，它提供一种独立于其他 LayerZero 组件的机制，从一个链读取块头并将其发送到另一个链。

· Relayer 是一个脱链服务，其功能类似于预言机，但是它不是获取块头，而是获取指定交易及其默克尔证明。

· 终端 是一系列链上智能合约的组合，LayerZero 会在每个支持的链上部署终端，以支持跨链消息的有效传递。终端分为四个模块：Communicator（通信器）、Validator（验证器）、Network（网络）和 Libraries（库）。

LayerZero 的核心设计思想在于 Relayer（中继者）和 Oracle（预言机）的分离，在 LayerZero 中，Relayer 负责传递消息及消息证明，Oracle 负责根据消息所在区块，按需从源链获取区块头，然后目标链上的终端根据 Oracle 获取的区块头验证 Relayer 传递的交易。

尽管 Layerzero 将其技术方案称为超轻节点（Ultra Light Node），但其方案与轻客户端跨链毫无关系。LayerZero 并不会在支持的链上部署任何链的轻节点，从验证方式来讲，LayerZero 通过 Oracle 提供的区块头来验证 Relayer 提供的交易证明，验证过程在目标链的终端发生，属于原生验证，但是对区块头本身的验证却是由作为外部验证人的第三方 Oracle 网络来完成的，验证过程发生在链下，从本质上讲，LayerZero 采取的方案，依旧属于外部验证。

dApp 责任制

LayerZero 的定位更多是一个中立的信息总线和传递标准，dApp 才是跨链服务的主体。dApp 有充分的自主权，可以自己决定选择哪个 Relayer，以及决定选择哪家预言机。在 LayerZero 当中，Relayer 和 Oracle 都是开放准入的，任何人都可以运行一个 Relayer，任何第三方 Oracle 网络也都可以加入（目前默认的 Oracle 是 Chainlink）。但 LayerZero 期待的理想状态是：每个 dApp 都要运行自己专有的 Relayer。在这种状态下，如果预言机网络想要串通 Relayer 作恶，构建虚假交易并验证它，必须串通控制 Relayer 的主体——dApp 项目方，而 dApp 项目方不太可能做毁灭自己的事情。

此外，即便出现了联合作恶的情况，风险依旧可以限制在 dApp 内部，不会波及其他使用不同 Relayer 的 dApp，这是一种风险隔离措施。

尽管如此，我们认为上述的串通并不是完全不可能，虽说 dApp 项目方大多数时候不会反对自己，但这不排除那些打算 rug-pull 的 dApp 项目方。因此，我们要认识到，LayerZero 并不是像其所宣称的那样，完全去信任化。但与此同时，我们也要看到，Oracle 和 Relayer 分体的设计，和 dApp 责任制的思想，相比单纯的外部验证人网络直接负责消息传递，安全性还是得以大幅提高，LayerZero 的创新是有积极意义的。

消息流

LayerZero 的另一大特点是模块化的终端，为了理解终端的工作机制，接下来我们来深入看下 LayerZero 的跨链信息流。

一个跨链信息的传递被分为 13 个步骤，为了让逻辑更加清晰，我们来分组表述。

步骤1-5：是当链 A 上发生一个跨链请求后，链 A 的终端通知 Oracle 和 Relayer，分别从链 A 获取相应信息，具体如下：

1.用户通过 dApp-X 在链 A 上产生了一笔需要跨链传递到链 B 的交易 T，并向链 A 终端上 Communicator（后简称 Communicator A）发起跨链请求，请求内容为 [t,dst，payload,relayer-args]

2.Communicator A 将跨链请求处理为一个数据包，包含 [packet(dst,payload),t,relayer-args]，发送给 Validator A ；

3.Validator A 将 [t,dst] 发送给 Network A，通知 Network A 获取当前区块 ID ；

4.Validator A 将 [packet(dst,payload),t,relayer-args] 发送给 Relayer，通知 Relayer 获取交易证明；

5.Network A 将区块 ID 发送给 Oracle，通知 Oracle 获取区块头；

步骤6-9: Relayer 和 Oracle 分别获取到对应信息，并提交给链 B 上的 终端，详细如下：

6.Oracle 从链 A 获取到区块头；

7.Relayer 从链 A 读取到交易 T 及其交易证明 proof(t)，存储到本地；

8.Oracle 将区块头提交到 Network B ；

9.Network B 将区块头中的哈希值发送给 Validator B ；

步骤10-11: 由于除了当前跨链请求，在同一区块内，可能还有其他跨链请求，因此 Relayer 会获取区块头，然后将所有该区块相关的跨链请求内容全部获取过来，详细如下：

10.Validaor B 将区块头哈希发给 Relayer ；

11.Relayer 收集当前区块内所有跨链请求及相关交易证明 [Packet(dst,payload),t,proof(t)]，返回给 Validator B ；

步骤12-13： 链 B 的终端用区块头验证这些相关的交易，并发给目标应用程序 dApp Y，跨链消息传递完成：

12.Validator B 用区块头验证接收到的所有交易，验证不通过的交易将被丢弃。验证通过的交易 [packet(dst,payload)] 发送给 Communicator B ；

13.Communicator B 将验证后的交易 [packet(dst,payload)] 发给 dApp Y。

我们发现，终端各模块的工作方式类似于网络堆栈，在发送端上，消息从 Communicator 到 Validator 再到 Network，在接收端上则刚好反过来。这样的设计是高度通用的，LayerZero 在支持新的接入链时，这三个模块是不用改动的，只需要在 Libarary 中添加关于新链的参数即可，这样的设计使得 LayerZero 十分便于扩展到新的区块链。

在消息流设计方面，LayerZero 会直接一次处理掉同一区块内所有的跨链请求，这样避免不必要的重复工作。

费用与激励

第三方 Oracle 服务有自己的经济模型，与 LayerZero 自身相互独立，第三方 Oracle 也将向使用 LayerZero 的 dApp 收费。

LayerZero 希望 dApp 项目方自己运行 Relayer，当然，dApp 项目方也可以制定一个付费标准，然后将其外包给社区。LayerZero 可以要求 Relayer 质押资金作为安全保障，目前 LayerZero 尚未做这样的要求。根据 LayerZero 的「dApp 责任制」的核心思想，我们推测未来 LayerZero 应该会让 dApp 项目方自己决定是否要质押，质押多少钱，质押越多，对 dApp 自身的用户而言，安全保障越高。

LayerZero 的应用现状

LayerZero 的生态发展很快，迄今为止，已支持的公链 有 Ethereum、Polygon、BSC、Avalanche、Fantom、DFK、Harmony，还有以太坊二层网络 Arbitrum、Optimism，Avalanche 子链 Swimmer Network、波卡平行链 Moonbeam。

LayerZero 上的生态应用也开始蓬勃发展，除了 LayerZero 自建的跨链 DEX 产品 Stargate，第三方创建的跨链 DEX 产品 Hashflow、Interswap 也陆续启动。跨链 DEX 之外，LayerZero 上最先发力的是 NFT 类应用，例如 NFT 收藏品 Gh0stly Gh0sts、Tiny Dinos、Yakuza Pandas、跨链 NFT 桥 parakeet.dao，还有 NFT 养猫游戏 Catddle。

此外，面向机构的去中心化借贷项目 Clearpool 也宣布接入 LayerZero 以实现跨链相关功能。

5.6.7 CCIP（Chainlink）

CCIP 是 Chainlink 于 2021 年底公布，目前还在开发的一个跨链堆栈。

Chainlink 是预言机领域的龙头，拥有非常丰富的节点资源，足以组成一个分布式程度更高的节点委员会、或者说 PoS 验证者集，因此，Chainlink 做跨链桥基础设施应该是水到渠成的事情。

CCIP 的跨链逻辑与 PoS 桥大致相同：

来自源链的应用程序调用 Chainlink 的消息路由器，Chainlink DONs（去中心化预言机网络）将监听到消息并对消息进行共识签名，再由 Relayer 中继到目标链，目标链的消息路由器对消息的签名进行验证并发送到目标应用程序完成执行。

但在这之外，CCIP 还引入了「反欺诈网络」风险管理系统。反欺诈网络与预言机网络相独立，作为一个新的验证层，在系统运行时定期提交心跳检查。如果反欺诈网络停止发送心跳，抑或是报告恶意行为，就会自动触发紧急关停机制。

CCIP 与 LayerZero 的设计有一个相同之处，那就是构建了两个独立的信任层。

Chainlink 目前只发布了一个非常粗略的 CCIP 文档，更细节的资料还有待披露。

5.6.8 pNetwork v2

pNetwork 是有 Provable Things 团队开发的一个跨链桥，pNetwork V1 于 2020 年 3 月推出，是一座 Wrap 桥，Wrap 资产被称为 pTokens，2021 年 10 月，pNetwork V2 发布，该版本将 pNetwork 拓展为了一座 AMB 桥。

pNetwork V2 延续了 V1 的核心特性，那就是使用 TEE 节点组成的 MPC 网络来验证跨链消息。TEE 全称为 Trusted Execute Environment，中文译为可信执行环境，它对于我们的日常生活而言并不陌生，手机上的指纹验证就是在 TEE 中运行的。

TEE 是在给定设备上运行的与主操作系统隔离的计算环境，就像一块飞地（Encalve）。这种隔离是通过硬件强制实现的。在 TEE 中运行程序的过程是隐蔽的，外界不可感知，这减少了 TEE 遭受黑客攻击的可能性。程序在 TEE 中运行完成后，输出的计算结果会被附上一个由设备生成的签名，该签名将被设备供应商远程验证，并生成远程验证证明。远程验证证明能够向外界证实该程序在 TEE 中被完整的执行，没有被篡改和干预。正因为如此，TEE 可以运行具有高安全性要求的应用程序，例如加密密钥管理、生物特征认证、安全支付处理等。

结构

pNetwork V2 主要包括以下部分

· TEE 节点网络：任意拥有 TEE 设备的主体可以质押 200 $PNT（至少 3 个月），即可成为 pNetwork 的 TEE 节点。pNetwork 中的 TEE 节点网络将负责对跨链消息进行共识签名。在初始化时，TEE 节点集需要共同参与秘钥的计算，以生成公钥和私钥碎片，其中公钥只有一个，处于公开状态，私钥碎片则是在本地生成后，存入 TEE 中「密封」。

· Portal：pNetwork 管理跨链消息传输队列的一组链上合约；

· Postman：类似于 Relayer；

· pNetwork DAO：pNetwork 采用 DAO 的方式进行治理，$PNT 持有人可以质押 $PNT，参与治理投票，决定 pNetwork 的费用参数和发展方向。

消息流

1.用户通过源应用程序在源链调用 Portal 合约，发起跨链消息发送请求；

2.TEE 节点监听到请求，将跨链消息放到 TEE 节点中验证（TEE 中需要运行源链的轻节点），并用自己的私钥碎片签名，当签名的私钥碎片数量达到门限（2/3），将合成一个完整的签名，(不会暴露明文私钥)，这代表消息被验证通过；

3.Postman 把验证通过的跨链消息送达目标链的 Portal 合约，Portal 合约在检查签名后转交给目标应用程序。

为什么要用 TEE 节点

2022 年 3 月 23 日，Axie Infinity 的官方跨链桥 Ronin Bridge 被黑客攻击，起因是 9 个多签节点中有 5 个节点的私钥被黑客盗取。我们在该事件中，看到即便多签节点没有主动串谋，外部攻击者还是有可能从物理层面攻破多签节点的设备，窃取私钥，进而攻击跨链桥。

由于多签节点需要用程序来执行对跨链消息的签名，这使得私钥不得不暴露在网络中，极易成为黑客攻击的目标。如果让多签节点使用 TEE 设备来存储私钥、验证和签名交易，那就可以很大程度上规避这个问题，让攻击者很难下手。

pNetwork 支持节点使用不同厂商的 TEE 设备接入网络。不同厂商的 TEE 设备的具体技术方案有可能是不同的，如果众多节点的 TEE 设备来自多元化的厂商，将进一步阻止黑客攻击。因为黑客需要攻破不同的 TEE 设备，才有可能实施攻击。

应用现状

截止 2022 年 9 月份，pNetwork 支持 9 条链的任意消息跨链，包括以太坊、Polygon、Gnosis Chain、Telos、Libre、EOS、BSC、Arbitrum、Algorand，同时支持在这些链上铸造 pBTC。

尽管 pNetwork V2 已经作为任意消息桥发布，但依目前而言，pNetwork 的「主营业务」还是 资产桥，目前尚未有第三方的跨链应用基于 pNetwork V2 搭建。

5.6.9 Bool Network

Bool Network 是另一个采用 TEE 节点网络作为外部验证者的 AMB 桥项目。Bool Network 在此基础上做了进一步的创新——增加了 TEE 节点的轮值和匿名机制。这样不仅让外部攻击难上加难，而且几乎可以杜绝内部串谋。

Bool Network 参考 Cosmos IBC，引入了 Channel 的概念，部署在不同链上的两个应用程序之间可以建立 Channel，以实现二者之间消息的有序传递。每个 Channel 都会对应至少一个 MPC 委员会。该委员会在当前 epoch 内负责对该 Channel 内的跨链消息进行共识签名。这个 MPC 委员会是轮值的，任期只有 1 个 epcoh，每个 epcoh 都会重新选举。

· Bool Network 目前会为每个 Channel 分配两个委员会，互为备份，以提高服务可用性。

任何人都可以通过质押 $BOL 成为候选的 TEE 节点。每个 epoch 开始前，Bool Network 会通过 Ring VRF 算法，为每个 Channel 选举 MPC 委员会。被选为 MPC 委员会成员的节点会获得一个用于通讯的临时身份（公私钥对），用于在共识签名过程中与同一委员会中的其他 TEE 节点通讯。当一个 epoch 结束时，所有的临时身份都会失效，然后网络将重新进行节点选举，选出新的轮值 MPC 委员会，赋予他们新的临时身份。

尽管每个候选的 TEE 节点在注册的时候，需要提供永久身份信息（设备编码），但节点在通讯时使用的临时身份并不会暴露永久身份信息。换句话说，节点在通讯时是相互匿名的。如果候选节点有 100 个，那么你只能知道与你通讯的节点是这 100 个当中的 1 个，而不知道具体是哪一个。

每个 Channel 的 MPC 委员会需要多少个 TEE 节点，签名的门限是多少，是由 Channel 创建人自定义的。常用的门限数值有 15-of-21、13-of-19、5-of-9。

同一个 Epoch 内，不同 Channel 的 MPC 委员会成员可能会有重叠，也有可能有部分候选节点没有被选入任何一个委员会，而出现闲置的状态。这些情况都是正常的。

我们发现，Bool Network 通过 TEE、轮值机制、匿名机制的组合，构建了一个牢不可破的黑箱。由于签名程序运行在匿名节点的 TEE 中，而且它们之间的通讯内容是 DH 加密的，只要不是闲置状态，TEE 节点的运营者本人都无从知晓自己被选入哪个 Channel 的 MPC 委员会，与哪些节点进行了共识通讯，签名了哪些消息，连「自知」都做不到，更谈不上「知人」。这基本上让节点串谋变的不可能。

从外部攻击者的角度，如果要攻击某个特定的 Channel，攻击者无从知晓当前的 MPC 委员会背后是哪些设备，也无法从通讯中截获这些信息。

无论是内部串谋，还是外部攻击，都只能选择攻破所有候选节点中的大多数，才有可能攻击成功，这无疑代价是巨大的。

Bool Network 是一个仍在开发中的项目，还有些技术细节没有完全确定，我们在本小节中阐述的只是其技术概要。

5.6.10 XCMP（Polkadot）

我们前文提到，波卡的跨链模式可以归结为外部验证中的一个特殊类型：共享验证。波卡的基本模型是分片，这是波卡实现共享安全性的途径。每个平行链是一个分片，平行链没有自己的验证者，而是由中继链分配一个验证者子集作为平行链的验证者集，这种分配是随机的，动态的，每个 epoch 都会重新分配。在任何一个时刻，中继链的验证者集是所有平行链验证者集的并集，这符合共享验证的特征。

但我们要理解波卡的跨链传输机制，还需读懂 XCMP 的细节。XCMP（Cross-Chain Message Passing）是 Polkadot 上的跨链消息传输协议，用于平行链/平行线程之间的跨链通讯，XCMP 还在开发中，目前已经部署的是 HRMP（Horizontal Relay-routed Message Passing）。此外，波卡使用 VMP（包含 UMPDMP）来实现平行链/线程与中继链之间的消息传递。

HRMP 提供与 XCMP 相同的接口和功能，但跨链消息是放在中继链存储的，这将给中继链带来负荷，因此这是一个过渡方案，后续将被 XCMP 替代。

我们需要了解 XCMP 和 XCM 的区别：Gawin 在一次采访中提到，XCMP 只是波卡跨链解决方案的一半，另外一半是 XCM，XCM 是波卡制定的一个跨共识消息通用格式，其效用是表达消息接收者应该做什么。

本小节的关注点在 XCMP。接下来我们将对 XCMP 的跨链传输模型做一个拆解。

5.6.10.1 主要概念

Channel

与 Cosmos IBC 类似，XCMP 当中也有 Channel（通道）的概念，但 XCMP 当中的通道是单向的，两条平行链（A 和 B）之间如果想要双向通讯，就需要建立两条通道（AB Channel，BA Channel）。

Egress 和 Ingress

当平行链 A 与平行链 B 建立 AB Channel 时，平行链 A 上会被创建一个平行链 B 的 egress（出口队列），而平行链 B 上会被创建一个平行链 A 的 ingress（入口队列）。

MR（Message Root）

每一个出口队列里除了存储待发消息队列的原文之外，还需要维护一个 MR 队列（Message Queue Hash Chain）。XCMP 在这里也采用了消息树的结构，所有的待发消息作为叶子节点构成一个默克尔树，树的根值被称为 MR（Massage Root），每有一个新的消息作为叶子节点插入，都会产生一个新的 MR。

5.6.10.2 消息流

（以 AB Channel 为例）

1.Chain A 上用户通过源应用程序发起跨链请求，想要将消息 M 送到 Chain B。该消息会被放入 Chain A 上为 Chain B 专设的出口队列（我们简写为：Egress AB）。该消息将被包含进最新的 MR 中。

2.Chain A 的收集者在打包当前区块的时候，会将最新的 MR 放入区块头。当区块被中继链分配给 Chain A 的验证者验证后，会被提交到中继链，并被中继链的区块包含。此时，我们认为该 MR 被中继链验证了。

3.Chain B 的收集者会不断轮询所有其他链上为 Chain B 建立的出口队列，这里就包括 Egress A B，Chain B 的收集者将 Egress A B 中的消息原文及 MR 队列放入自己对应的入口队列：Ingress AB。（* 有另一种说法，该过程不是收集者完成，而是验证者完成的，这点的设计在 XCMP 中还没有完全确定，但谁来完成并非 XCMP 设计的关键点，因为这项任务是无信任的，谁来完成都可以）。

4.Chain B 的验证人从中继链获取 Channel AB 的最新被中继链验证的 MR，以及该 MR 已经被中继链验证的证明。由于 Chain B 的验证人本就来自于中继链的随机分配，所以这个过程不存在信任问题。

5.Chain B 用该 MR 来判断 Ingress AB 哪些消息已经被包含到中继链中，然后更新这些消息的状态为已验证。

6.已验证的消息可以被目标应用程序执行了。

我们为了表达方便，只描述一个 Channel 的消息流，事实上 XCMP 在处理跨链消息的时候，所有的 Channel 是同时处理的。中继链会维护一个 CST 表格（Channel State table），用于存储所有 Channel 的 MR。

UMP 和 DMP 大致与 XCMP 同理，不再赘述。