本文最早作为《?PAKA跨链研报》的5.5章发布，点击查看完整研报
作者：MIDDLE.X
跨链桥一般被归纳为三种技术范式，分别是轻客户端跨链、外部见证人跨链、基于哈希时间锁的原子交换。根据ArjunBhuptani的归纳，这三种技术范式，也可以分别称其为原生验证、外部验证、本地验证。
目前上市面上最受关注的跨链桥，几乎都属于外部见证人桥。
尽管外部见证人跨链桥有更好的兼容性，可以相对轻松的拓展到更多的区块链。但其不可避免了引入了新的信任假设。用户必须相信外部见证人集不会作恶。相比之下，轻客户端桥的信任层更加牢固，无需引入新的信任假设，只要链是安全的，桥就是安全的。在一些仅需连接2条链的场景下，轻客户端桥会更加适用。
本文，我们将盘点目前市面上主要的轻客户端桥以及轻客户端桥跨链技术的发展现状。
轻客户端原理
我们先对轻客户端的原理做一个基本概述。轻客户端，也称轻节点，在链上往往以轻智能合约的形式呈现。轻客户端跨链的基本原理是在目标链部署源链的轻节点合约，对源链来的消息进行验证。如果要实现双向跨链，就需要在两条链上互相部署对方链的轻节点合约。
相比全节点，轻节点是轻量化的节点，它不存储完整区块的序列，而仅存储区块头的序列。尽管区块头体积很小，但它包含了对区块中完整数据的密码学概括。当轻节点需要知道某个交易是否被包含在链中时，可以通过该交易所在区块的区块头及该交易的Merkle路径，对该交易执行?SPV验证。
为了维护目标链上部署的源链轻节点，需要由链下代理将源链的区块头不断同步到目标链。轻节点合约对负责同步区块头的链下代理并没有信任假设。因为轻节点合约会对其同步的区块头执行验证，链下代理无法轻节点。
轻节点验证区块头的逻辑，与全节点、矿工节点别无二致，分为有效性验证和最终性验证两部分。
对于PoW链来说，有效性验证主要是指验证区块的工作量证明，最终性验证则是看该区块头后面有没有更多的有效区块被追加。
对于PoS链而言，有效性验证是指验证该区块是否由被随机选中的出块人生成，最终性验证则是看该区块是否被2/3以上投票权重的验证人签名。但PoS的轻节点并不需要验证有效性，只需要验证最终性。因为PoS链中，最终的区块一定有效，PoW链则未必。
下文我们开始盘点：
BTCRelay
BTC-Relay是最早的轻节点合约，也是最早的轻客户端跨链桥。其工作原理很简单，那就是在以太坊上部署一个BTC的SPV轻节点，用于对BTC链上的交易做SPV验证。
链下角色「Relayer」负责不断的将BTC链的区块头传递到轻节点合约，轻节点合约在对区块头进行有效性验证和最终性验证之后将其正式接受。
Relayer会向以太坊支付存储和验证区块头的Gas费用，与此同时，Relayer从发起跨链请求的用户那里获得费用作为补偿，并获得适当的利润。任何人都可以成为Relayer，并自设置每次调用的收费标准，其他人如果想成为Relayer，可以通过向当前Relayer支付一小笔费用，并设置更少的收费标准来取而代之，用户如果担心收费过高，也可以自己运行Relayer服务。
需要注意的是，BTCRelay是一座单向桥，仅仅支持在以太坊上验证BTC的信息，不支持相反方向的信息验证。因此BTCRelay并没有发行BTC的跨链衍生资产，其用例仅限于支持用户使用比特币支付以太坊上的费用。
当然，BTCRelay可以作为一块积木，作为一个单向信任层，为其他的BTC跨链衍生品提供BTC→以太坊方向上的交易验证服务。
BTCRelay官网BTCRelay文档
WaterlooBridge
WaterLooBridge是由KyberNetwork开发的一座跨链桥，也是首个实现双向轻客户端验证的跨链桥，其实现的是以太坊和EOS之间的双向跨链。尽管随着EOS的衰落，WaterLooBridge目前鲜有问津，但其技术方案依旧具有代表性。
WaterlooBridge通过以太坊智能合约实现了EOS的轻客户端，同时也通过EOS智能合约实现了以太坊的轻客户端。
由于以太坊出块相对较慢，而EOS上的计算和存储资源相对充足，所以WaterLoo在EOS上建立的以太坊轻节点合约是SPV轻节点，与BTCRelay原理一致，会将以太坊的区块头逐个的同步到轻节点合约。
但EOS出块速度较快，且以太坊上的资源紧张，因此在以太坊上的EOS轻节点合约被设计为仅同步BP集有变动的区块，而不去逐个的、连续的同步所有区块。但这样的设计需要解决两个问题：
如何验证历史区块头：当要验证的交易不在已存储区块当中的时候，轻节点合约需要首先从全节点获取相应区块头。但这里还需要一个验证过程，轻节点合约如何验证这些获取到的区块头？
如何验证最新区块头：在不掌握区块头完整历史的情况下，如何验证最新同步的区块头的最终性？
如何验证历史区块头
轻节点合约需要有能力依据已存储的区块头，验证从全节点获取到的区块头。如何做到这一点呢？我们需要了解，EOS的共识协议是DPoS，$EOS的Staker通过投票选出21个BP，这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上有消息需要跨链传递到以太坊，WaterlooBridge会：①.看消息所在区块的区块头在轻客户端中是否已存在，如果不存在则进行步骤②，如果存在则进行步骤③；②.Relayer从全节点获取消息所在区块的区块头，提交给轻客户端，轻客户端根据掌握的最新BP者集来验证该区块头，也就是说，轻客户端通过查看该区块头是否被2/3以上的BP集签名来判断其是否有效；③.用验证通过的区块头，对消息执行SPV验证。
EOS的共识机制属于BFT类共识机制，EOS的轻客户端实现方法，成为了BFT类公链轻客户端的典型范式。
WaterLooBridge简介WaterLooBridge简介
RainbowBridge
Rainbowbridge是Near开发的连接Near生态与以太坊生态的官方跨链桥。Rainbowbridge文档中提到：Rainbowbridge的主要设计者是AntonBukov，他现在是1inch的CTO，尽管已经不在Near全职工作，但他仍然指导着Rainbowbridge的发展。
结构
RainbowBridge的核心组成部分是两个链上合约和三个链下代理：
链上合约：
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的设计很大程度上借鉴了WaterLooBridge中的EosOnEthClient，甚至重用了WaterLooBridge的一部分代码。
但对于NearOnEthClient，还有个技术难题，那就是以太坊不兼容Near所采用的Ed25519签名格式，这使得NearOnEthClient对Near区块头的验证变的很麻烦。因此RainbowBridge引入了乐观验证的方案。
当Near2EthRelay向NearOnEthClient提交区块头时，需要在Near链上抵押一些$NEAR，在4小时的窗口期内，被称为Watchdog的挑战者可以提出挑战，如果所有Watchdog都不提出挑战，窗口期结束时，区块头被NearOnEthClient正式接纳。如果Watchdog提出挑战，并且挑战成功，提交无效区块头的Near2EthRelay将付出经济代价，其抵押金的一半将被销毁，剩余的一半将成为提出挑战的Watchdog的赏金。
乐观验证的引入，带来了新的信任假设：至少有一个Watchdog是忠实的。
在BTCRelay中，同一时间，只有一个Relayer运行，但在RainbowBridge中，无论是Eth2NearRelay，还是Near2EthRelay，都允许多个同时运行。多个Relayer可以相互竞争，尝试同时提交相同的块，每次只有一个成功；多个Relayer也可以相互形成备份，如果某个Relayer没有及时交块，其他Relayer依旧会提交，这样降低了服务不可用的可能性。
激励措施
当前RainbowBridge没有为转发区块头的两组Relay服务提供经济激励，因为Near预期运行在RainbowBridge上的主要应用将自行运行Relay服务，并且至少有一对Relay服务是由Near官方运行的。RainbowBridge的未来版本可能会增加对Relay服务的经济激励，并增加相应的对跨链用户/应用的收费机制。
最新进展
Near发布了EVM兼容环境Aurora，目前RainbowBridge2.0支持的是以太坊与Aurora的跨链，如果需要从以太坊跨链到Near，需要经过Aurora中转。需要注意的是，Aurora尽管维护了一个独立的账本，有独立的区块链浏览器，但并不是一条独立区块链，而是Near上的一个runtime，Aurora没有独立的验证者集，Near与Aurora之间的桥不是跨链桥，而是runtime之间的桥。我们还需要留意的是，在本文写作的时候，以太坊刚刚完成PoS转型。所以RainbowBridge和WaterLooBridge中的针对PoW版本设计的以太坊轻客户端，可能在不久之后被重新设计。
Near介绍文档
Snowbridge
SnowBridge是带有波卡官方性质的跨链桥项目，由Snowfork团队开发，其目的是创建波卡生态和以太坊之间的原生验证桥。
Snowbridge是一个仍在开发中的项目，我们对其的知识源于SnowBridge的现行文档，该文档看起来还未完成，有些地方写的还是“comingsoon”，我们只能基于现有的材料对snowbridge进行分析。
Snowbridge将有一条自己的平行链，未来将作为一条公益平行链运行，称为SnowBridgeParachain，由该平行链负责与以太坊建立桥接，其他的平行链将通过SnowBridgeParachain与XCMP，间接与以太坊桥接。这意味着，将在SnowBridgeParachain上面运行以太坊的轻节点Pallet。
Substrate当中没有合约的概念，开发者通过添加Pallet向链部署应用程序，但其本质与合约是相同的，都是链上的runtime。
Snowbridge将由以下模块构成
部署在以太坊上的合约：
PolkadotRPC：用于处理以太坊上的跨链请请求
波卡及其平行链轻客户端验证器
部署在SnowbridgeParachain上的Pallet：
ETHEREUMRPC用于处理波卡上的跨链请求
以太坊轻客户端验证器
SnowbridgeParachain上的以太坊轻客户端
根据Snowbridge的现行文档，以太坊轻客户端被设计为了一个SPV轻节点，Relayer将负责逐个的将以太坊的区块头同步过来，轻客户端Pallet将检查工作量证明，并遵循最重的分叉。
以太坊上的波卡轻客户端
需要注意的是，由于SnowBridgeParachain的共识是中继链负责的，因此该轻客户端同步的将是中继链的区块头，而非SnowBridgeParachain的区块头。为了随时掌握最新的验证人集信息，必须同步包含验证者集改选的区块头，这意味着每个Epoch至少需要同步一个区块头。当有交易需要验证时，再按需从中继链请求SnowBridgeParachain的区块头，并用包含它的中继链区块头验证其最终性。
相比WaterLoo，Snowfork要面对一个新问题：EOS只有21个验证人，但波卡有1000个左右的验证者，即便刚好有2/3的验证人签名了一个区块，在以太坊验证600多个签名消耗的Gas也高到令人发指。RainbowBridge通过乐观验证机制，绕开了这个问题，而Snowfork选择直面它。
Snowbridge的方案是采取一个抽样机制：在获取区块头时，轻客户端从该区块头对应的验证者集中，随机抽取一个子集，轻客户端将仅仅验证这个子集的签名，而不必验证所有的签名。根据Snowfork的研究论证，这个子集的验证人数量仅需ceil(log2(3*N))个。如果N是1000，那么只需要抽取12个验证人的签名。
BEEFY
Polkadot为了更好的支持与其他公链的桥接，在GRANDPA共识基础上，开发了一个最终性小工具，称为BEEFY。当波卡中继链的区块被GRANDPA终结之后，还有一个BEEFY共识签名环节，在该环节，验证人需要为区块头添加MMR根植，然后对区块头进行单独的一轮共识签名。
有了BEEFY之后，轻客户端将不需要了解GRANDPA的复杂性，只需验证BEEFY签名。最重要的是BEEFY签名格式完全兼容以太坊，方便在以太坊端进行验证。
激励措施
SnowBridge分为两个阶段发布，第一个阶段发布的是BasicBridge，该阶段已具备跨链桥的基本功能，但没有激励层，对于HeadRelayer和MessageRelayer都没有激励措施。如果用户/应用想要保证自己的消息被中继成功，需要自己运行Relayer服务。第二个阶段将过度到IncentiveBridge，该阶段将设立对Relayer的激励措施。
应用层
在Snowfork团队的规划中，在SnowBridge上线之后，将很快发布三座资产桥，分别是DOT资产桥：支持在以太坊上创建snowDOTETH资产桥：支持在波卡端创建snowETHERC20资产桥：支持在波卡端创建ERC20资产的映射版本，命名格式为：snow-。
Snowbridge文档
Beefy文档
LCMP
LCMP是Darwinia开发的异构跨链协议，是一个基于轻客户端方案的通用的、开放的跨链传输协议。该协议目前以SDK的方式，允许Dapp自由集成。Darwinia构筑的跨链生态结构中，有DarwiniaChain、DarwiniaParachain两条链，其中DarwiniaParachain是Polkadot的平行链，二者都有相应的金丝雀网络，CrabChain、CrabParachain，其中CrabParachain是Kusama的平行链。
DarwiniaChain上被部署了一个EVM的兼容环境，称为DarwiniaSmartChain，被称为Chain是因为DarwiniaSmartChain拥有独立的状态机和浏览器，但它并不是一条独立的区块链。相应的，CrabChain上也有一个EVM兼容环境，被称为CrabSmartChain。
轻客户端设计
截止撰文，LCMP已经实现了
DarwiniaChain与以太坊的桥接
CrabChain和CrabParachain的桥接
其中，后者用到的轻客户端方案与Waterloo别无二致，我们重点关注DarwiniaChain与以太坊的桥接用到的这组轻客户端。DarwiniaChainClientOnEth由于Beefy还不可用，基于Substrate开发的DarwiniaChain的区块头签名，不被以太坊兼容。
Darwinia目前采取了一个过渡方案，通过议会的治理选举了一个签名人小组，专门负责签署DarwiniaChain的区块头，轻客户端将通过验证该小组的签名来确认区块头是否合法。尽管DarwiniaChain上有超过100个验证人，但签名人小组不超过10人，验证这些签名，在以太坊端的经济成本是可接受的。
EthClientOnDarwiniaChain
合并之后的以太坊信标链，作为一条PoS链，有数十万个验证人，验证他们的签名显然不现实。因此以太坊在一次被称为Altair的升级中，增设了一个新的共识环节。Altair升级后，以太坊链上每256epoch就会从验证人中选出一个委员会，该委员会有512名验证者，他们将负责对已经终结的区块头进行签名。轻客户端仅需验证委员会当中是否已经有2/3签署，就可以验证一个区块头。不过512个仍然有些多，因此以太坊还采用BLS技术，将委员会的众多签名聚合为一个签名，这进一步降低了轻客户端的验证成本。
Darwinia已经基于Altair升级，在DarwiniaChain上实现了以太坊的轻客户端，该轻客户端只需每27小时同步一个区块头。这应该是基于PoS转型后的以太坊实现的第一个链上轻客户端。
费用与激励
跨链发起者在发送跨链消息时需要支付费用，费用将包含三个部分：
执行源链交易的Gas费用。
支付给Relayer的费用。
具体定价由市场决定，众多的Relayer可以展开价格竞争。需要注意的是，Relayer需要支付目标链上的Gas费用，Relayer会在定价中体现这部分成本，也就是说，跨链发起者无需再单独支付目标链上的Gas费用。
支付给Treasure的费用。
跨链发起者支付的跨链费用中，会有一定比例进入DarwiniaTreasure。Treasure会有部分资金用于补贴HeadRelayer。
DarwiniaDocs
以太坊Altairfork
zkBridge
在撰写本文时，zkBridge是一个刚启动不久的项目，只完成了少量的开发。但该项目是目前为止，为数不多的将零知识证明技术用于跨链桥构建的项目之一。zkBridge将ZK-SNARK证明用于轻节点的扩容。
目前zkBridge已经以Solidity在以太坊上实现了一个CosmosClient的实例，据测试，可以在2分钟内生成一个CosmosZone区块头的ZK-SNARK证明，然后在以太坊端，仅仅花220kgas就可以验证它，对比来看，如果不用ZK-SNARK证明，这个费用将是64MillionGas。
zkBridge的主要创新是：
deVirgo：采用分布式的方法来生成ZK-SNARK证明，该方法称为deVirgo，该方法通过将计算工作进行拆分，分配给更多的设备，大幅度提升了在链下生成ZK-SNARK证明的时间。
递归证明：为了降低链上成本，zkBridge使用递归证明的方案，通过两次递归，将ZK-SNARK证明的体积压缩到131字节左右
批处理：zkBridge实现了一个区块头的更新合约，它以区块高度为输入，返回相应区块头。但zkBridge并不会在每个新区块产生时，调用更新合约，证明者可以先收集N个区块头，生成一个单一的证明。N值可以设置，N越大，用户等待时间越长但系统运行成本越低。
不得不说，零知识证明技术是一项可以创造奇迹的技术。限制其采用的主要瓶颈在于技术门槛高，开发难度大，但在零知识证明技术的开发上，回报与付出总是相称的。
zkBridge推特长文
zkbridge论文
MAPProtocol
MAPProtocol是一个基于轻客户端和中继链的通用异构跨链协议。
与前述的众多项目不同，MAP选择建立一条中继链MAPChain，作为跨链消息传递的中转站。接入链之间无需直接建立连接，而是都与MAPChain建立连接，也就是说：每条接入链只需部署MAPChain的轻节点合约，MAPChain上部署每条接入链的轻节点合约。
MAPProtocol的架构分为三层，分别是协议层，跨链服务层、应用层。其中：
协议层：我们可以理解为信任层，包括MAPChain和各个接入链轻客户端程序；
跨链服务层：为应用层提供一些通用模块，让应用层不必“重造车轮”，例如一个通用的Vault模块，可以替一些资产桥应用程序锁定资金，不过应用程序也可以选择自建Vault而不使用该模块。
应用层：是指使用MAPprotocol作为跨链消息传输媒介的应用程序。
此外，MAPProtocol包括三个链下角色
维护者：负责更新各轻节点合约的区块头，可以获得$MAP通胀奖励。
信使：负责传递跨链消息，可以获得用户支付的跨链费用，但需要垫付目标链和中继链上的Gas费用。
MAPChain验证者：负责MAPChain共识过程，需要质押$MAP，可以获得$MAP通胀奖励。MAPChain目前采用IBFT-PoS共识机制。
跨链消息流
MAPProtocol的文档中对消息传输机制没有过多着墨，从目前的只言片语中看，消息流应该是这样的：当源链上的应用程序发起跨链请求时，跨链消息M被包含在一笔交易T1中，被信使发送到中继链上，中继链收到交易T1之后，将交易T1及其携带的消息M，包含在交易T2中，信使将T2中继到目标链，目标链收到T2，将其验证之后发给目标应用程序。
尽管MAPProtocol是一个2019年发起的项目，但迄今为止，支持的链也只有以太坊，BSC和Polygon，于“通用”二字，还有所名不副实。事实上，由于轻节点合约在拓展上不同链上时，不能重用，需要单独做开发，基于轻节点合约的跨链桥很难做到“通用”。
MAPProtocol文档
CosmosIBC
IBC是一个设计非常精巧的同构跨链协议，是Cosmos跨链网络的重要组成部分，Cosmos跨链网络主要由Hub和Zone组成，Zone与Hub之间通过IBC协议建立桥接，Zone与Zone之间以Hub为中继建立桥接。Cosmos跨链网络还包括PegZone与异构桥接的部分，不属于IBC的范畴。
Hub和Zone都是开放准入的，任何基于CosmosSDK构建的区块链都可以成为一个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的建立遵循三次握手原则，握手完成后，Conenction开启。
此时，可以在Connection之上，建立Channel。ChannelConnecion连接的是两个Zone，而Channel连接的则是分别在两个Zone上的一对应用程序。两个应用程序通过三次握手原则建立Channel，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的讯息。需要注意的是，CosmosIBC与MAPProtocol不同，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。
CosmosIBCDocs
CosmosIBC代码分析
小结
目前来看，在轻客户端方案的设计上，PoW轻客户端还是以SPV轻客户端为主，逐个同步源链的所有区块头，PoS轻客户端则大多采用跳跃式同步区块头的方案，仅同步验证者集发生变化的区块头，我们只需要让轻客户端在初始化正确的情况下，掌握验证者集的变化，就可以让轻客户端掌握最新的验证者集。
实践中，轻客户端的构建还会遇到区块头验证成本过高，签名方案不兼容等问题，不同的项目会采取不同的方法应对，包括乐观验证、验证者集抽样、链下生成零知识证明，此外，公链为了更好的支持跨链，也有动力对自身进行改造和升级，例如以太坊Altair升级和Polkadot开发Beefy模块。
总之，轻客户端技术依旧处于激烈的演化之中，随着更多研究与探索的进行，未来构建轻客户端的难度会逐步降低。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。