MIDDLE.X：一文盘点轻客户端跨链桥的发展现状

本文最早作为《 PAKA跨链研报 》的5.5章发布，点击查看完整研报

作者：MIDDLE.X

 

跨链桥一般被归纳为三种技术范式，分别是轻客户端跨链、外部见证人跨链、基于哈希时间锁的原子交换。根据 Arjun Bhuptani 的归纳，这三种技术范式，也可以分别称其为原生验证、外部验证、本地验证。

目前上市面上最受关注的跨链桥（诸如LayerZero、Multichain、Axelar、Hyperlane），几乎都属于外部见证人桥。

尽管外部见证人跨链桥有更好的兼容性，可以相对轻松的拓展到更多的区块链。但其不可避免了引入了新的信任假设。用户必须相信外部见证人集不会作恶。相比之下，轻客户端桥的信任层更加牢固，无需引入新的信任假设，只要链是安全的，桥就是安全的。在一些仅需连接2条链（或略多于2条链）的场景下，轻客户端桥会更加适用。

本文，我们将盘点目前市面上主要的轻客户端桥以及轻客户端桥跨链技术的发展现状。

 

轻客户端原理

 

我们先对轻客户端的原理做一个基本概述。轻客户端，也称轻节点，在链上往往以轻智能合约的形式呈现。轻客户端跨链的基本原理是在目标链部署源链的轻节点合约，对源链来的消息进行验证。如果要实现双向跨链，就需要在两条链上互相部署对方链的轻节点合约。

相比全节点，轻节点是轻量化的节点，它不存储完整区块的序列，而仅存储区块头的序列。尽管区块头体积很小，但它包含了对区块中完整数据的密码学概括。当轻节点需要知道某个交易是否被包含在链中时，可以通过该交易所在区块的区块头及该交易的 Merkle 路径，对该交易执行 SPV 验证。

为了维护目标链上部署的源链轻节点，需要由链下代理将源链的区块头不断同步到目标链。轻节点合约对负责同步区块头的链下代理并没有信任假设。因为轻节点合约会对其同步的区块头执行验证，链下代理无法欺骗轻节点。

轻节点验证区块头的逻辑，与全节点、矿工节点别无二致，分为有效性验证和最终性验证两部分。

对于 PoW 链来说，有效性验证主要是指验证区块的工作量证明，最终性验证则是看该区块头后面有没有更多的有效区块被追加（在 BTC 链中，一般认为 6 个区块的追加可以确认一个区块的最终性，在以太坊中，则一般认为 25 个区块的追加可以确认一个区块的最终性）。

对于 PoS 链而言，有效性验证是指验证该区块是否由被随机选中的出块人生成，最终性验证则是看该区块是否被 2/3 以上投票权重的验证人签名。但 PoS 的轻节点并不需要验证有效性，只需要验证最终性。因为PoS链中，最终的区块一定有效，PoW链则未必。

下文我们开始盘点：

 

BTC Relay

 

BTC-Relay 是最早的轻节点合约，也是最早的轻客户端跨链桥。其工作原理很简单，那就是在以太坊上部署一个 BTC 的 SPV 轻节点，用于对 BTC 链上的交易做 SPV 验证。

链下角色「Relayer」负责不断的将 BTC 链的区块头传递到轻节点合约，轻节点合约在对区块头进行有效性验证和最终性验证之后将其正式接受。

Relayer 会向以太坊支付存储和验证区块头的 Gas 费用，与此同时，Relayer 从发起跨链请求的用户那里获得费用作为补偿，并获得适当的利润。任何人都可以成为 Relayer ，并自设置每次调用的收费标准，其他人如果想成为 Relayer ，可以通过向当前 Relayer 支付一小笔费用，并设置更少的收费标准来取而代之，用户如果担心收费过高，也可以自己运行 Relayer 服务。

需要注意的是，BTC Relay 是一座单向桥，仅仅支持在以太坊上验证 BTC 的信息，不支持相反方向的信息验证。因此 BTC Relay 并没有发行 BTC 的跨链衍生资产，其用例仅限于支持用户使用比特币支付以太坊上的费用。

当然，BTC Relay 可以作为一块积木，作为一个单向信任层，为其他的 BTC 跨链衍生品提供 BTC→以太坊方向上的交易验证服务。

BTC Relay 官网

BTC Relay 文档

 

Waterloo Bridge

 

WaterLoo Bridge 是由 Kyber Network 开发的一座跨链桥，也是首个实现双向轻客户端验证的跨链桥，其实现的是以太坊和 EOS 之间的双向跨链。尽管随着 EOS 的衰落，WaterLoo Bridge 目前鲜有问津，但其技术方案依旧具有代表性。

Waterloo Bridge 通过以太坊智能合约实现了 EOS 的轻客户端，同时也通过 EOS 智能合约实现了以太坊的轻客户端。

由于以太坊出块相对较慢，而 EOS 上的计算和存储资源相对充足，所以 WaterLoo 在 EOS 上建立的以太坊轻节点合约是 SPV 轻节点，与 BTC Relay 原理一致，会将以太坊的区块头逐个的同步到轻节点合约。

但 EOS 出块速度较快，且以太坊上的资源紧张，因此在以太坊上的 EOS 轻节点合约被设计为仅同步 BP 集 （出块人集）有变动的区块，而不去逐个的、连续的同步所有区块。但这样的设计需要解决两个问题：

• 如何验证历史区块头：当要验证的交易不在已存储区块当中的时候，轻节点合约需要首先从全节点获取相应区块头。但这里还需要一个验证过程，轻节点合约如何验证这些获取到的区块头？

• 如何验证最新区块头：在不掌握区块头完整历史的情况下，如何验证最新同步的区块头的最终性？

如何验证历史区块头

轻节点合约需要有能力依据已存储的区块头，验证从全节点获取到的区块头。如何做到这一点呢？我们需要了解，EOS 的共识协议是 DPoS ，$EOS 的 Staker 通过投票选出 21 个 BP（Block Producer），这 21 个 BP 以循环方式轮流出块，每生成一个区块，都会由 21 个 BP 进行签名，有 15 个以上 BP 签署的区块被认为具备最终性，这些签名会在区块头中体现。

尽管 EOS 出块速度较快，但 BP 集的变动却不会很频繁，轻客户端只要掌握 BP 集的名单（公钥列表），就可以验证该 BP 集任期内的所有区块头。也就是说，从全节点获取的区块头已被相应任期内的 BP 集当中的 15 个签署，就会被轻客户端合约接受。

如何验证最新区块头

由于对 BP 集的选举投票发生在链上，投票结果会反映在某个区块 Block{i} 的区块头中，Block{i} 的区块头中会体现该 BP 集的名单，以及他们的任期。在 Block{i} 及其中包含的新 BP 集被生成时，这个新的 BP 集还未生效，Block{i} 会被旧的 BP 集签名。

简单来讲，我们也可以这样理解，旧的 BP 集通过签署某个包含新 BP 集选举结果的区块，批准了新的 BP 集。轻客户端只要正确的掌握最初始的 BP 集，并且掌握每次 BP 集发生变化的区块，通过这样一个「批准关系链条」，就可以一路追溯到最新的 BP集。掌握最新 BP 集，就可以验证最新的区块。

所以，只要轻客户端合约在初始化的时候，被输入了正确的初始BP集，轻客户端就可以自行完成以后的验证工作。

消息验证过程

当 EOS 上有消息需要跨链传递到以太坊，Waterloo Bridge 会： ①. 看消息所在区块的区块头在轻客户端中是否已存在，如果不存在则进行步骤 ② ，如果存在则进行步骤 ③ ； ②. Relayer 从全节点获取消息所在区块的区块头，提交给轻客户端，轻客户端根据掌握的最新 BP 者集来验证该区块头，也就是说，轻客户端通过查看该区块头是否被 2/3 以上的 BP 集签名来判断其是否有效； ③. 用验证通过的区块头，对消息执行 SPV 验证。

EOS 的共识机制属于 BFT 类共识机制，EOS 的轻客户端实现方法，成为了 BFT 类公链轻客户端的典型范式。

WaterLoo Bridge 简介（上）
WaterLoo Bridge 简介（下）

 

Rainbow Bridge

 

Rainbow bridge 是 Near 开发的连接 Near 生态与以太坊生态的官方跨链桥。Rainbow bridge 文档中提到：Rainbow bridge 的主要设计者是 Anton Bukov ，他现在是 1inch 的 CTO，尽管已经不在 Near 全职工作，但他仍然指导着 Rainbow bridge 的发展。

结构

Rainbow Bridge 的核心组成部分是两个链上合约和三个链下代理：

链上合约：

• EthOnNearClient：在 Rust 中作为 Near 合约实现的以太坊轻节点

• NearOnEthClient：在 Solidity 中作为以太坊合约实现的 Near 轻节点

链下代理：

• Eth2NearRelay：负责将以太坊区块头传递给 EthOnNearClient

• Near2EthRelay：负责将Near区块头传递给 NearOnEthClient

• Watchdog：负责向提交无效区块头的 Near2EthRelay 提出挑战，稍后详述

EthOnNearClient 需要跟踪以太坊上的每一个区块头。NearOnEthClient 只需要每个 Epoch 跟踪一个区块头，Near 的一个 Epoch 大约是 43,000 个区块，4 小时左右。如果全部同步的话是不现实的，幸运的是，Near 的验证人集每个 Epoch 只会变更一次，每个 Epoch 只有一个包含验证者集改选信息的区块头。NearOnEthClient 的设计很大程度上借鉴了 WaterLoo Bridge 中的 EosOnEthClient ，甚至重用了 WaterLoo Bridge 的一部分代码。

但对于 NearOnEthClient，还有个技术难题，那就是以太坊不兼容 Near 所采用的 Ed25519 签名格式，这使得 NearOnEthClient 对 Near 区块头的验证变的很麻烦。因此 Rainbow Bridge 引入了乐观验证的方案。

当 Near2EthRelay 向 NearOnEthClient 提交区块头时，需要在 Near 链上抵押一些 $NEAR ，在 4 小时的窗口期内，被称为 Watchdog 的挑战者可以提出挑战，如果所有 Watchdog 都不提出挑战，窗口期结束时，区块头被 NearOnEthClient 正式接纳。如果 Watchdog 提出挑战，并且挑战成功，提交无效区块头的 Near2EthRelay 将付出经济代价，其抵押金的一半将被销毁，剩余的一半将成为提出挑战的 Watchdog 的赏金。

乐观验证的引入，带来了新的信任假设：至少有一个 Watchdog 是忠实的。

在 BTC Relay 中，同一时间，只有一个 Relayer 运行，但在 Rainbow Bridge 中，无论是 Eth2NearRelay ，还是 Near2EthRelay ，都允许多个同时运行。多个 Relayer 可以相互竞争，尝试同时提交相同的块，每次只有一个成功；多个 Relayer 也可以相互形成备份，如果某个 Relayer 没有及时交块，其他 Relayer 依旧会提交，这样降低了服务不可用的可能性。

激励措施

当前 Rainbow Bridge 没有为转发区块头的两组 Relay 服务提供经济激励，因为 Near 预期运行在 Rainbow Bridge 上的主要应用（例如：$ETH 资产桥、$NEAR 资产桥、ERC20 资产桥、NFT 桥）将自行运行 Relay 服务，并且至少有一对 Relay 服务是由 Near 官方运行的。Rainbow Bridge 的未来版本可能会增加对 Relay 服务的经济激励，并增加相应的对跨链用户/应用的收费机制。

最新进展

Near 发布了 EVM 兼容环境 Aurora，目前 Rainbow Bridge 2.0 支持的是以太坊与 Aurora 的跨链，如果需要从以太坊跨链到 Near，需要经过 Aurora 中转。需要注意的是，Aurora 尽管维护了一个独立的账本，有独立的区块链浏览器，但并不是一条独立区块链，而是 Near 上的一个 runtime ，Aurora 没有独立的验证者集，Near 与 Aurora 之间的桥不是跨链桥，而是 runtime 之间的桥。 我们还需要留意的是，在本文写作的时候，以太坊刚刚完成 PoS 转型。所以 Rainbow Bridge 和 WaterLoo Bridge 中的针对 PoW 版本 设计的以太坊轻客户端，可能在不久之后被重新设计。

Near 介绍文档

 

Snowbridge（Snowfork）

 

SnowBridge 是带有波卡官方性质的跨链桥项目，由 Snowfork 团队开发，其目的是创建波卡生态和以太坊之间的原生验证桥。

Snowbridge 是一个仍在开发中的项目，我们对其的知识源于 SnowBridge 的现行文档，该文档看起来还未完成，有些地方写的还是“coming soon” ，我们只能基于现有的材料对 snowbridge 进行分析。

Snowbridge 将有一条自己的平行链，未来将作为一条公益平行链运行，称为 SnowBridge Parachain ，由该平行链负责与以太坊建立桥接，其他的平行链将通过 SnowBridge Parachain 与 XCMP ，间接与以太坊桥接。这意味着，将在 SnowBridge Parachain 上面运行以太坊的轻节点 Pallet 。

• Substrate 当中没有合约的概念，开发者通过添加 Pallet 向链部署应用程序，但其本质与合约是相同的，都是链上的 runtime。

Snowbridge 将由以下模块构成

部署在以太坊上的合约：

• Polkadot RPC：用于处理以太坊上的跨链请请求

• 波卡及其平行链轻客户端验证器（POLKADOT AND PARACHAIN LIGHT CLIENT VERIFIER）

部署在 Snowbridge Parachain 上的 Pallet ：

• ETHEREUM RPC 用于处理波卡上的跨链请求

• 以太坊轻客户端验证器（ETHEREUM LIGHT CLIENT VERIFIER）

Snowbridge Parachain 上的以太坊轻客户端

根据 Snowbridge 的现行文档（2022.10.14），以太坊轻客户端被设计为了一个 SPV 轻节点，Relayer 将负责逐个的将以太坊的区块头同步过来，轻客户端 Pallet 将检查工作量证明，并遵循最重的分叉。（但为了适配转型为 PoS 之后的以太坊，Snowbridge 应该会有新的方案。）

以太坊上的波卡轻客户端

需要注意的是，由于 SnowBridge Parachain 的共识是中继链负责的，因此该轻客户端同步的将是中继链的区块头，而非 SnowBridge Parachain 的区块头。为了随时掌握最新的验证人集信息，必须同步包含验证者集改选的区块头，这意味着每个 Epoch 至少需要同步一个区块头。当有交易需要验证时，再按需从中继链请求 SnowBridge Parachain 的区块头，并用包含它的中继链区块头验证其最终性。

相比 WaterLoo ，Snowfork 要面对一个新问题：EOS 只有 21 个验证人，但波卡有 1000 个左右的验证者，即便刚好有 2/3 的验证人签名了一个区块，在以太坊验证 600 多个签名消耗的 Gas 也高到令人发指。Rainbow Bridge 通过乐观验证机制，绕开了这个问题，而 Snowfork 选择直面它。

Snowbridge 的方案是采取一个抽样机制：在获取区块头时，轻客户端从该区块头对应的验证者集中，随机抽取一个子集，轻客户端将仅仅验证这个子集的签名，而不必验证所有的签名。根据 Snowfork 的研究论证，这个子集的验证人数量仅需 ceil(log2(3*N)) 个（N 为验证总数）。如果 N 是 1000 ，那么只需要抽取 12 个验证人的签名。

BEEFY

Polkadot 为了更好的支持与其他公链的桥接，在 GRANDPA 共识基础上，开发了一个最终性小工具，称为 BEEFY（截止撰文，BEEFY 的代码还在完善中）。当波卡中继链的区块被 GRANDPA 终结之后，还有一个 BEEFY 共识签名环节，在该环节，验证人需要为区块头添加 MMR 根植，然后对区块头进行单独的一轮共识签名。

有了 BEEFY 之后，轻客户端将不需要了解 GRANDPA 的复杂性，只需验证 BEEFY 签名。最重要的是 BEEFY 签名格式完全兼容以太坊，方便在以太坊端进行验证。

激励措施

SnowBridge 分为两个阶段发布，第一个阶段发布的是 Basic Bridge ，该阶段已具备跨链桥的基本功能，但没有激励层，对于 Head Relayer 和 Message Relayer 都没有激励措施。如果用户/应用 想要保证自己的消息被中继成功，需要自己运行 Relayer 服务。 第二个阶段将过度到 Incentive Bridge ，该阶段将设立对 Relayer 的激励措施。

应用层

在 Snowfork 团队的规划中，在 SnowBridge 上线之后，将很快发布三座资产桥，分别是 DOT 资产桥：支持在以太坊上创建 snowDOT ETH 资产桥：支持在波卡端创建 snowETH ERC20 资产桥：支持在波卡端创建 ERC20 资产的映射版本，命名格式为：snow-[资产名] 。

Snowbridge 文档

Beefy 文档

 

LCMP（Darwinia）

 

LCMP（Light-client Cross-chain Messaging Protocol ）是 Darwinia 开发的异构跨链协议，是一个基于轻客户端方案的通用的、开放的跨链传输协议。该协议目前以 SDK 的方式，允许 Dapp 自由集成。 Darwinia 构筑的跨链生态结构中，有 Darwinia Chain、Darwinia Parachain 两条链，其中 Darwinia Parachain 是 Polkadot 的平行链，二者都有相应的金丝雀网络，Crab Chain、Crab Parachain，其中 Crab Parachain 是 Kusama 的平行链。

Darwinia Chain 上被部署了一个 EVM 的兼容环境，称为 Darwinia Smart Chain，被称为 Chain 是因为 Darwinia Smart Chain 拥有独立的状态机和浏览器，但它并不是一条独立的区块链。（参见 Aurora 与 Near 的关系） 相应的，Crab Chain 上也有一个 EVM 兼容环境，被称为 Crab Smart Chain 。

轻客户端设计

截止撰文， LCMP 已经实现了

• Darwinia Chain 与 以太坊的桥接

• Crab Chain 和 Crab Parachain 的桥接

其中，后者用到的轻客户端方案与 Waterloo 别无二致，我们重点关注 Darwinia Chain 与以太坊的桥接用到的这组轻客户端。 Darwinia Chain Client On Eth 由于 Beefy 还不可用，基于 Substrate 开发的 Darwinia Chain 的区块头签名，不被以太坊兼容。

Darwinia 目前采取了一个过渡方案，通过议会的治理选举了一个签名人小组，专门负责签署 Darwinia Chain 的区块头，轻客户端将通过验证该小组的签名来确认区块头是否合法。尽管 Darwinia Chain 上有超过 100 个验证人，但签名人小组不超过 10 人，验证这些签名，在以太坊端的经济成本是可接受的。

Eth Client On Darwinia Chain

合并之后的以太坊信标链，作为一条 PoS 链，有数十万个验证人，验证他们的签名显然不现实。因此以太坊在一次被称为 Altair 的升级中，增设了一个新的共识环节。Altair 升级后，以太坊链上每 256 epoch（大约 27 小时）就会从验证人中选出一个委员会，该委员会有 512 名验证者，他们将负责对已经终结的区块头进行签名。轻客户端仅需验证委员会当中是否已经有 2/3 签署，就可以验证一个区块头。不过 512 个仍然有些多，因此以太坊还采用 BLS 技术，将委员会的众多签名聚合为一个签名，这进一步降低了轻客户端的验证成本。

Darwinia 已经基于 Altair 升级，在 Darwinia Chain 上实现了以太坊的轻客户端，该轻客户端只需每 27 小时同步一个区块头。这应该是基于 PoS 转型后的以太坊实现的第一个链上轻客户端。

费用与激励

跨链发起者（可能是用户，也可能是 Dapp）在发送跨链消息时需要支付费用，费用将包含三个部分：

• 执行源链交易的 Gas 费用。

• 支付给 Relayer 的费用。

具体定价由市场决定，众多的 Relayer 可以展开价格竞争。 需要注意的是，Relayer 需要支付目标链上的 Gas 费用，Relayer 会在定价中体现这部分成本，也就是说，跨链发起者无需再单独支付目标链上的 Gas 费用。

• 支付给 Treasure 的费用。

跨链发起者支付的跨链费用中，会有一定比例进入 Darwinia Treasure 。Treasure 会有部分资金用于补贴 Head Relayer 。

Darwinia Docs

以太坊 Altair fork

 

zkBridge

 

在撰写本文时，zkBridge 是一个刚启动不久的项目，只完成了少量的开发。但该项目是目前为止，为数不多的将零知识证明技术用于跨链桥构建的项目之一。zkBridge 将 ZK-SNARK 证明用于轻节点的扩容。

目前 zkBridge 已经以 Solidity 在以太坊上实现了一个 Cosmos Client 的实例，据测试，可以在 2 分钟内生成一个 Cosmos Zone 区块头的 ZK-SNARK 证明，然后在以太坊端，仅仅花 220k gas 就可以验证它，对比来看，如果不用 ZK-SNARK 证明，这个费用将是 64 Million Gas 。

zkBridge 的主要创新是：

• deVirgo：采用分布式的方法来生成 ZK-SNARK 证明，该方法称为 deVirgo ，该方法通过将计算工作进行拆分，分配给更多的设备，大幅度提升了在链下生成 ZK-SNARK 证明的时间。

• 递归证明：为了降低链上成本，zkBridge 使用递归证明的方案（生成证明的证明），通过两次递归，将 ZK-SNARK 证明的体积压缩到 131 字节左右

• 批处理：zkBridge 实现了一个区块头的更新合约，它以区块高度为输入，返回相应区块头。但 zkBridge 并不会在每个新区块产生时，调用更新合约，证明者可以先收集 N 个区块头，生成一个单一的证明。N 值可以设置，N 越大，用户等待时间越长但系统运行成本越低。

不得不说，零知识证明技术是一项可以创造奇迹的技术。限制其采用的主要瓶颈在于技术门槛高，开发难度大，但在零知识证明技术的开发上，回报与付出总是相称的。

zkBridge 推特长文

zkbridge 论文

 

MAP Protocol

 

MAP Protocol 是一个基于轻客户端和中继链的通用异构跨链协议。

与前述的众多项目不同，MAP 选择建立一条中继链 MAP Chain ，作为跨链消息传递的中转站。接入链之间无需直接建立连接，而是都与 MAP Chain 建立连接，也就是说：每条接入链只需部署 MAP Chain 的轻节点合约，MAP Chain 上部署每条接入链的轻节点合约。

MAP Protocol 的架构分为三层，分别是协议层，跨链服务层、应用层。其中：

• 协议层：我们可以理解为信任层，包括 MAP Chain 和各个接入链轻客户端程序；

• 跨链服务层：为应用层提供一些通用模块，让应用层不必“重造车轮”，例如一个通用的 Vault 模块，可以替一些资产桥应用程序锁定资金，不过应用程序也可以选择自建 Vault 而不使用该模块。

• 应用层：是指使用 MAP protocol 作为跨链消息传输媒介的应用程序。

此外，MAP Protocol 包括三个链下角色

• 维护者（Maintainer）：负责更新各轻节点合约的区块头，可以获得 $MAP 通胀奖励。

• 信使（Messager）：负责传递跨链消息，可以获得用户支付的跨链费用，但需要垫付目标链和中继链上的 Gas 费用。

• MAP Chain 验证者：负责 MAP Chain 共识过程，需要质押 $MAP ，可以获得 $MAP 通胀奖励。MAP Chain 目前采用 IBFT-PoS 共识机制。

跨链消息流

MAP Protocol 的文档中对消息传输机制没有过多着墨，从目前的只言片语中看，消息流应该是这样的： 当源链上的应用程序发起跨链请求时，跨链消息 M 被包含在一笔交易 T1 中，被信使发送到中继链上，中继链收到交易 T1 之后，将交易 T1 及其携带的消息 M ，包含在交易 T2 中，信使将 T2 中继到目标链，目标链收到 T2 ，将其验证之后发给目标应用程序。

尽管 MAP Protocol 是一个 2019 年发起的项目，但迄今为止，支持的链也只有 以太坊，BSC 和 Polygon ，于“通用”二字，还有所名不副实。事实上，由于轻节点合约在拓展上不同链上时，不能重用，需要单独做开发，基于轻节点合约的跨链桥很难做到“通用”。

MAP Protocol 文档

 

Cosmos IBC

 

IBC 是一个设计非常精巧的同构跨链协议，是 Cosmos 跨链网络的重要组成部分，
Cosmos 跨链网络主要由 Hub 和 Zone 组成，Zone 与 Hub 之间通过IBC（InterBlcokChain）协议建立桥接，Zone 与 Zone 之间以 Hub 为中继建立桥接。Cosmos 跨链网络还包括 Peg Zone 与异构桥接的部分，不属于 IBC 的范畴。

Hub 和 Zone 都是开放准入的，任何基于 Cosmos SDK 构建的区块链都可以成为一个 Hub ，或成为一个 Zone 并向任意一个 Hub 注册为接入链。不同于波卡的中继链，Cosmos 的 Hub 不是唯一的。

轻客户端

每个向 Hub 注册的 Zone 都需要部署一个 IBC 模块，该模块中包含了 Hub 的轻客户端合约，Hub 当中的 IBC 模块也会集成每个接入的 Zone 的轻客户端合约。

Tendermint 共识机制中没有 epoch 的概念，每个区块都有可能会产生验证者的变动。但 IBC 中的轻客户端合约中有一个 TrustPeriod（信任期）的概念，这是轻客户端在初始化时需要设置的一个参数，在一个 TrustPeriod 内，允许验证者集产生微小的变化，个别验证者可能加入或者退出，但不会有大的变动。

这种微小的变化是可以接受的，因为每次签名几乎不会只有刚好 2/3 的投票权签名，总会有一定的溢出，即便个别验证者加入或者退出，轻客户端按照变化前的验证者集去检查该区块头，大概率还是能观察到 2/3 权重的投票权签了名。

因此 IBC 中的轻客户端合约，只需每个 TrustPeriod 更新一次验证人集的信息即可，这意味着每个 TrustPeriod 只需同步一个区块头。

同步区块头的工作将由 Relayer 来执行。

核心概念与原理

IBC 构建了三个抽象概念，分别是 Connection（连接）、Channel（信道）、Packet（数据包）。

• Connection

Connection 是指两个 Zone 之间的连接，建立 Connection 可以理解为将两个 Zone 进行配对，此时，两个 Zone 向 Hub 请求对方的轻客户端的最新区块头。Connection 的建立遵循三次握手原则（握手通讯均由 Relayer 触发），握手完成后， Conenction 开启。

此时，可以在 Connection 之上，建立 Channel 。 Channel Connecion 连接的是两个 Zone，而 Channel 连接的则是 分别在两个 Zone 上的一对应用程序（这一对应用程序可能来自同一个应用，也可能来自不同的应用）。两个应用程序通过三次握手原则建立 Channel（握手通讯由 Relayer 触发）， Channel 建立之后，这两个应用程序就可以相互发送 Packet 了。

• Channel

Channel 是 IBC 中最核心的概念，他让应用程序直接建立连接。作为一个抽象概念，Channel 并不存在一个实体，对于接受端应用程序而言，Channel 定义了发件者，知道消息从哪个 Channel 传过来，就知道消息来自哪个 Zone 上的哪个应用程序，对于发送端应用程序而言，Channel 定义了收件端，想要向哪个应用程序发送消息，就把消息放进对应的 Channel 。

Channel 还定义了消息时序，同一个 Channel 当中的消息遵循一个队列，具有严格的时序关系，先发的消息始终先到。不同 Channel 中的消息之间则没有时序关系。

这里需要注意的是，一个应用程序最好稳定的使用一个 Channel。例如，一个资产桥应用如果使用多个 Channel 来在目标链创建映射资产，那么多个 Channel 会生成不同的映射资产，这将带来不必要的麻烦。

• Packet

Packet 是一个规范的数据结构，是在 Channel 中被允许传送的跨链消息的规定格式。Packet 的传送分为三个步骤：

• sendPacket：发送端的应用程序在源链上创建一个序号为 N 的 Packet ，并加入待发队列；

• recvPacket：Relayer 将该 Packet 中继到目标链，由接收端的应用程序存储。

• acknowledgePacket：Relayer 将接收端应用程序已经存储该 Packet 的证明，传回源链，源链在待发队列中删除序号为 N 的 Packet 。

如果接收端合约长时间没有存储该 Packet ，Relay 返回 timeout 的讯息。 需要注意的是，Cosmos IBC 与 MAP Protocol 不同，Packet 的发送是直接从源 Zone 抵达目标 Zone 的，并不需要在 Hub 中转。这是因为目标 Zone 可以向 Hub 直接 query 源 Zone 的区块头，然后执行对 Packet 的验证。这意味着，Hub 只需中转区块头就可以了。

具体来说，Hub上有源 Zone 的轻节点，可以验证源 Zone 的区块头，目标 Zone上有 Hub 的轻节点，可以验证 Hub 的区块头，当目标 Zone 需要某个源 Zone 区块头 SourceZoneBlockHead{i} 的时候，可以让 Relayer 从 Hub 去获取，目标 Zone 上的轻节点验证 HubBlockHead{i} ，并用 HubBlockHead{i} 验证 SourceZoneBlockHead{i} 之后，就可以用 SourceZoneBlockHead{i} 验证源 Zone 的 Packet 了。

费用与激励

IBC 当中有一个可配置的费用模块，Connection 的发起方可以自定义收费标准及对 Relayer 的支付标准。不过根据我们的观察，Zone 的项目方和应用程序项目方往往都有动力自己运行 Relayer 。

Cosmos IBC Docs

Cosmos IBC 代码分析

 

小结

 

目前来看，在轻客户端方案的设计上，PoW 轻客户端还是以 SPV 轻客户端为主，逐个同步源链的所有区块头，PoS 轻客户端则大多采用跳跃式同步区块头的方案，仅同步验证者集发生变化的区块头，我们只需要让轻客户端在初始化正确的情况下，掌握验证者集的变化，就可以让轻客户端掌握最新的验证者集。

实践中，轻客户端的构建还会遇到区块头验证成本过高，签名方案不兼容等问题，不同的项目会采取不同的方法应对，包括乐观验证（RainbowBridge）、验证者集抽样（Snowfork）、链下生成零知识证明（zkBridge），此外，公链为了更好的支持跨链，也有动力对自身进行改造和升级，例如以太坊 Altair 升级和 Polkadot 开发 Beefy 模块。

总之，轻客户端技术依旧处于激烈的演化之中，随着更多研究与探索的进行，未来构建轻客户端的难度会逐步降低。