MIDDLE.X：一文盤點輕客戶端跨鏈橋的發展現狀_CHA:BADGER

本文最早作為《?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

Cardano創始人：rollups部署正在迅速推進，Midnight將成為首個采用項目:7月23日消息，Cardano創始人Charles Hoskinson提供了關于該網絡rollups部署的更新。一位推特用戶指出，Hoskinson今年在YouTube視頻中兩次談到了rollups，并進一步詢問他具體指的是哪個項目。對此，Hoskinson談到了需要rollups的側鏈項目。他補充說，團隊正在執行一個非常積極的時間表，Midnight將成為第一個用戶。

去年，Cardano開發公司Input Output Global推出了隱私區塊鏈Midnight，它將作為Cardano區塊鏈的側鏈運行。Midnight將利用零知識證明以及私有和公共計算的結合，提供一個無需信任的生態系統，在合規的同時保護敏感的個人和商業數據。用例可能包括財務工作流、醫療保健數據和供應鏈操作等。

據悉，在4月份的一次AMA活動上，Hoskinson暗示將在Cardano上發布ZK-rollups，并補充說一個“美好的計劃”正在準備中。[2023/7/24 15:54:00]

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集，輕客戶端就可以自行完成以后的驗證工作。

安全團隊：Polygon上的Midas Capital項目被攻擊，損失約66萬美元:1月16日消息，據Beosin-Eagle Eye態勢感知平臺消息，Polygon上jarvis項目中的Midas Capital礦池項目被黑客使用的view重入和價格操控組合漏洞攻擊，黑客獲利663101 MATIC（約66萬美元）。攻擊之后，Beosin Trace追蹤發現黑客將663101MATIC發送給地址0xe53......59be，然后分散至其他10個其他的地址，這些地址總共又將15935的MATIC發送至0x04Ec......46F2地址中，目前14581枚MATIC轉入Kucoin交易所，1671MATIC枚轉入幣安交易所。

其他代幣仍然留在上述地址上。[2023/1/16 11:14:35]

消息驗證過程

當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的賞金。

加密貨幣投資公司Midas在虧損后關閉平臺:金色財經報道，由于Celsius和FTX的破產，導致專注于DeFi收益的加密貨幣投資公司Midas超過60%的管理資產陷入困境，該公司在遭遇重大投資虧損后不得不關閉平臺。

Midas首席執行官兼創始人Iakov“Trevor” Levin已在博客文章中確認了此事，并表示去年春天旗下DeFi投資組合就損失了5000萬美元，占其2.5億美元管理資產(AUM)的20%，在Celsius和FTX破產后，60%的管理資產又遭到打擊。不過，Iakov“Trevor” Levin透露，通過將競爭協議與流動性聯系起來，他們后續將會專注于一個“符合對集中式去中心化金融（CeDeFi）愿景”的新項目。（coindesk）[2022/12/28 22:11:40]

樂觀驗證的引入，帶來了新的信任假設：至少有一個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：用于處理以太坊上的跨鏈請請求

波卡及其平行鏈輕客戶端驗證器

前谷歌CEO Eric Schmidt：比特幣技術是加密領域的一項重大成就:金色財經報道，2014年在計算機歷史博物館演講時，前谷歌CEO Eric Schmidt稱贊比特幣技術是加密領域的一項重大成就。Schmidt指出，比特幣的技術很重要，但對該資產作為貨幣的用途表示懷疑。比特幣的技術設置可以在未來為更多企業提供動力。

比特幣是一項了不起的密碼學成就，創造數字世界中不可復制的東西的能力具有巨大的價值比特幣架構，從字面上看，擁有這些不可復制的賬本的能力，是一個驚人的進步。很多人將在此基礎上建立業務。

此外，Schmidt分享了目前對Web3的興趣。 Schmidt稱，一個新的互聯網模式，你作為個人可以控制你的身份，而且你沒有一個集中的管理者，是非常強大的。它非常有誘惑力，而且非常分散。（finbold）[2022/8/8 12:10:05]

部署在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-。

Midas平臺成功添加Zap新功能:據Midas團隊表示，已經成功在其平臺上添加了Zap功能。Zap是一個自動化的工作流程，可以將用戶的應用程序和服務連接在一起，每個Zap由一個觸發器和一個或多個動作組成，社區可以更容易地通過Zap參與流動性挖礦。Zap流程只包括從購買MDS代幣到提供流動性與ETH匹配的操作，如果想要得到更多$MDS，則必須將LP代幣指南加入到ZAP中。[2020/11/3 11:31:55]

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模塊。

總之，輕客戶端技術依舊處于激烈的演化之中，隨著更多研究與探索的進行，未來構建輕客戶端的難度會逐步降低。

Tags：CHADGEBRIDGEBRIybchainBADGERPolkaBridgeBridge Network

TUSD