# 區塊鏈的跨鏈：以 Polkadot 為核心視角
# 1. 跨鏈的起源與需求
## 1.1 為什麼需要跨鏈？
在區塊鏈的早期階段，每條鏈都是孤島（如 Bitcoin、Ethereum），無法彼此溝通。
比特幣是一座島，以太坊是另一座，Solana、BNB、Aptos 又是其他島嶼。每座島都有自己的規則、語言和資產系統，島與島之間**不會自動互通資料，也無法直接交換資產**。
這就是為什麼需要「跨鏈技術（Cross-chain）」，它像是是區塊鏈的橋樑、通信的信差，是讓這些孤島**成為互聯大陸**的關鍵技術。
## 1.2 跨鏈帶來的好處
### **1 . 資產整合**
假設你在三條鏈上都有資產：
- Ethereum 上有 ETH
- Solana 上有 SOL
- BNB Chain 上有 BNB
但你要投資一個只支援 Ethereum 的 DeFi 項目，這時你需要「跨鏈橋」幫你把 SOL 或 BNB 移動到 Ethereum 上換成 ETH。
沒有跨鏈，你就得人工提幣、換幣、手續費重複被吃，還要自己操作好幾個介面。
### 2. 提升流動性
跨鏈橋能讓原本封閉在某條鏈上的資金，流入另一條鏈。這樣一來，整體 DeFi 生態的資金使用率會提高。
更多鏈共享同一池資金 → TVL（Total Value Locked, 總鎖倉價值）提高 → 協議效率變高 → 使用者體驗變好
### 3. 應用協作：組成跨鏈 DApp
想像一個 DApp：
- 前端部署在 Polygon
- 智能合約結算在 Ethereum
- 資料儲存（如 NFT 圖片）在 Arweave
- 用戶身份來自 zkSync 錢包驗證
這種「**多鏈組合式應用**」正是 Web3 正在發展的趨勢，沒有跨鏈通訊協定，這根本無法運作。
### 4. 節省成本與開發效率
每條鏈都不一樣：EVM、Move VM、WASM、獨立共識機制……
如果每次要溝通就重做一份相容程式碼，不只是工程師的地獄，也是開源社群的浪費。
跨鏈技術（像 XCM、IBC、GMP 等）就像定義好一套**跨平台通訊協議**，讓各鏈開發者只要對接一次，就能互通百鏈。
# 2. 三大跨鏈實作方式：資產橋、通訊協議、原生多鏈架構
不同區塊鏈之間無法直接互動，就像兩個國家法律不同、語言不同，誰也不懂誰在說什麼。
為了解決這個問題，開發者們發明了**三種不同的跨鏈方式**，來讓這些鏈彼此「對話」、「轉帳」、「合作」。
### 2.1 資產橋（Asset Bridge）
Asset Bridge 是最早期也最常見的跨鏈方式。它的基本作法是把原鏈上的資產「鎖起來」，然後在另一條鏈上發行一個代表這筆資產的包裝代幣（wrapped token）。舉例來說，wBTC（wrapped BTC）就是用比特幣作為抵押，在以太坊上鑄造的 ERC-20 代幣。這種設計讓你能在不離開 Ethereum 的情況下，間接「使用」BTC。
資產橋的優點是實作簡單、使用門檻低，因此非常普及。不過它的風險在於，大多數資產橋會使用中心化或多簽的錢包託管資產。如果託管方被攻擊、內部出錯或惡意舞弊，原本鎖住的資產就可能消失，而你手上的包裝代幣也就失去了價值。這種設計本質上需要「信任」中介，因此也被稱為 trusted bridge。像 Ronin Bridge（Axie Infinity 所屬）就曾因多簽密鑰被盜而損失超過 6 億美元，是此類風險的代表案例。
### 2.2 跨鏈通訊協議（Messaging Protocol）
這類機制的重點不在於轉移資產，而是能讓兩條鏈之間交換各種訊息，例如通知事件、執行合約、同步狀態等等。它像是一個鏈與鏈之間的 API 層。開發者可以透過這種通訊協議，讓 DApp 橫跨多條鏈協作。例如一個遊戲的角色資訊存在 BNB Chain，但道具合成的邏輯則部署在 Ethereum，通訊協議就可以讓兩者互相傳訊，完成跨鏈邏輯。
這種系統的好處是彈性高，幾乎不受限於資產格式，也不綁定特定鏈種。不過它的風險與挑戰在於：訊息要能被正確且安全地驗證。不同協議設計不同，有些仰賴 Oracle + Relayer 雙重路徑（如 LayerZero），有些是由一群驗證者投票決定訊息的真偽（如 Axelar）。這些機制如果設計不當，就可能被惡意驗證錯誤的訊息，導致錯誤的跨鏈操作。換句話說，雖然這類協議更去中心化、更靈活，但安全驗證邏輯也更複雜，開發者需要特別留意底層的信任模型。
### 2.3 原生多鏈架構（Multi-chain Platform）
這一類設計像是從底層就為跨鏈而生的系統。代表性項目包括 Polkadot 和 Cosmos，它們的核心理念是：不要「事後補橋」，而是從一開始就設計一個可以讓多條鏈並存、互通的系統，就像蓋高鐵時就設好每站共用的軌道與系統。
以 Polkadot 為例，它的主鏈稱為 Relay Chain，負責維護整個系統的共識與安全；其他的平行鏈（Parachains）透過 Relay Chain 互相傳遞訊息。這種設計的好處是安全性強、互通性高，所有鏈都共享同一個安全保障，也可以用官方協定（如 XCM）實現訊息與資產的傳遞。
不過，它的缺點也很明確，就是開發門檻高。這類系統通常需要使用特定的開發框架（如 Substrate for Polkadot、Cosmos SDK for Cosmos），開發者必須重新適應這些框架的設計方式。雖然未來擴展性好、安全性強，但初期學習與建構成本並不低。
# 3. 信任機制與底層驗證方式—Trusted vs Trustless 跨鏈橋與中介訊息層協議
當兩條區塊鏈要溝通或交換資產時，最大問題就是 —— **我要怎麼知道你說的是真的？**
在現實世界，如果有人說他在某銀行有 1 萬元，我們會要求對方出示帳戶證明，或找銀行來背書。在鏈上也一樣，不同鏈之間彼此不信任，沒辦法直接讀取對方的帳本，所以需要透過「橋（Bridge）」來傳遞訊息或資產。但這座橋到底要不要信任它？這就分成兩種設計思路：
## 3.1 Trusted Bridge（以信任為基礎的橋）
你可以把 trusted bridge 想成是「跨鏈仲介商」。
它會找一群人來「擔任見證人」，幫你把一邊的資產鎖起來，然後在另一邊鑄造代表的資產。
流程像這樣：
1. 你把 BTC 傳給橋方指定的比特幣地址（通常是多簽錢包）
2. 這群見證人觀察到這筆交易，確認你確實存進去了
3. 他們在 Ethereum 上幫你發行一顆 wBTC
4. 將來你要提回 BTC，就燒掉 wBTC，這群人再把 BTC 解鎖還你
這聽起來很簡單，但有個本質問題：**你必須信任這些人會照規則做事，不偷不騙不被駭。**
### 有哪些風險？
- 如果見證人被攻擊（像 Ronin 事件），資產可能被盜
- 如果這些人串通作弊，也可能偷偷發行多餘的代幣
- 若機構倒閉或失聯，你可能無法拿回原鏈資產
這種橋的設計風險主要是「**信任集中在少數人身上**」，所以才叫 trusted bridge。
## 3.2 **Trustless Bridge（不需要信任的橋）**
trustless bridge 的核心哲學是：
「不需要相信誰，只相信密碼學證據。」
它的目標是讓「接收方鏈」自己就能**驗證你給的證據是真是假**，不需要任何中間人幫你說話。這種驗證通常依賴一個重要角色：**light client**。
### light client 是什麼？
你可以把 light client 想成是一個「只下載摘要資料的小型驗證器」。
完整節點（full node）會下載整個區塊鏈，太重；而 light client 只下載：
- 每個區塊的區塊頭（block header）
- 區塊中的 Merkle root（交易資料的數位指紋）
只要你能提供一個交易的 **Merkle proof**，light client 就能檢查這筆交易是否真的存在過。
- Block header
區塊鏈的每個區塊都會有一個「標頭（header）」，它像是該區塊的**身份證與摘要報告**，裡面通常會包含：
- 該區塊的編號（height）
- 時間戳記（timestamp）
- 前一個區塊的 hash
- 本區塊的 Merkle root（所有交易的總摘要）
這些資訊是整條鏈能串接起來的基礎。
圖源：https://vitalflux.com/blockchain-linked-list-like-data-structure/#google_vignette
- Merkle root
Merkle root 是一個用哈希運算（hash）方式，把區塊內所有交易壓縮成一個摘要值的技術。
想像你有 8 筆交易，Merkle Tree 就會這樣處理：
1. 每筆交易 hash 成一個值
2. 兩兩合併再 hash，往上做出一棵樹
3. 最頂端的那個 hash，就是 Merkle root
只要你提供一筆交易＋它的「樹枝路徑證明」（Merkle proof），任何人都可以用 Merkle root 來驗證這筆交易是否真的存在。
總結：Merkle root 是用來快速驗證某筆交易有無出現在區塊裡的數位指紋，不需要重跑整個區塊，也不需信任任何人。
圖源：https://medium.com/coinmonks/merkle-trees-concepts-and-use-cases-5da873702318
Merkle root 的簡單程式範例（Python）
```python
import hashlib
def hash(data):
return hashlib.sha256(data.encode()).hexdigest()
def merkle_root(transactions):
# 初始每筆交易先做一次 hash
level = [hash(tx) for tx in transactions]
# 持續往上合併直到只剩一個 hash（root）
while len(level) > 1:
next_level = []
for i in range(0, len(level), 2):
left = level[i]
right = level[i+1] if i+1 < len(level) else level[i] # 如果奇數就重複自己
combined = hash(left + right)
next_level.append(combined)
level = next_level
return level[0]
# 範例交易
txs = ["Alice pays Bob", "Bob pays Carol", "Carol pays Dave", "Dave pays Eve"]
root = merkle_root(txs)
print("Merkle root:", root)
```
### 例子：Snowbridge（Polkadot ↔ Ethereum）
Polkadot 上要跟 Ethereum 說：「我這邊某個合約收到了 100 顆 DOT。」
- Polkadot 提供一段證據（Block header + Merkle proof）
- 這段證據會被送到 Ethereum
- Ethereum 上跑著 Polkadot 的 light client，自己驗證這筆證據是否有效
- 驗證正確後，再執行對應動作（如發放資產或觸發事件）
整個過程中，沒有人能作弊，因為目標鏈自己就能看懂證據，不需要信任誰。
### Trustless bridge 雖然安全，但也有挑戰：
- 每個鏈的 light client 設計不同，技術門檻高
- 驗證 proof 需要消耗計算資源，執行速度較慢
- 有些鏈共識設計複雜，不容易做成 light client（像 Solana）
- 為什麼有些鏈像 Solana 不容易做成 light client？
Light client 要能「只靠區塊頭就驗證交易證據」，這前提是：
區塊頭（block header）中要有能代表整個區塊資料的摘要（如 Merkle root），而且這些摘要要結構清晰、格式穩定，否則目標鏈就很難根據這些摘要驗證交易。
但 **不是每條鏈都適合這種設計**，像 **Solana 就非常難做 light client：**
1. 並行共識架構（parallel execution）
Solana 使用的是並行共識架構（Proof of History + Turbine + multi-threaded runtime），導致：
- **同一個區塊內，交易是同時並行處理的**，不會產生清楚的執行順序
- 並不是所有交易都有穩定、可驗證的位置與順序
- 這讓 Merkle tree 的構造非常困難，或乾脆沒有
2. 缺乏穩定的區塊頭格式
Solana 的 block header（區塊頭）不像 Ethereum 一樣標準化，裡面可能缺少：
- Merkle root（用來驗證交易）
- state root（用來驗證執行後的狀態變化）
少了這些重要欄位，light client 根本無法獨立驗證某筆交易或狀態。
light client 需要「格式穩定、資訊摘要化、可計算」的區塊頭，但像 Solana 這種設計為追求速度犧牲了結構明確性，因此難以支援 trustless 跨鏈。
好做 light client 的鏈：
| 鏈 | 原因 |
| --- | --- |
| **Ethereum** | 有明確 Merkle root、交易順序、state root |
| **Bitcoin** | 區塊結構簡單，Merkle root 清楚 |
| **Polkadot（Relay chain）** | 每個平行鏈的 state 封裝成 Merkle leaf，方便驗證 |
| **Cosmos（IBC 支援鏈）** | 標準化區塊頭（Tendermint block header）支援輕節點 |
難做 light client 的鏈：
| 鏈 | 原因 |
| --- | --- |
| **Solana** | 並行交易 + 無標準 Merkle root |
| **Aptos / Sui** | 使用 Move VM、物件導向模型，狀態碎片化，不好驗證 |
| **Cosmos 某些鏈** | 雖然 Cosmos hub 支援 IBC，但其他 Appchain 並非都有標準 header（需個別處理） |
| **Optimistic rollups（如 Optimism）** | L2 區塊不是用 Merkle root 封裝，而是打包在 calldata，light client 無法單獨驗證 |
| **ZK Rollup（部分）** | 雖然有 validity proof，但沒標準 Merkle tree 讓你對照交易內容（偏向整體驗證） |
因此，雖然 trustless 可能是未來趨勢，但目前真正做到的還不多，Snowbridge 是 Polkadot 生態中非常罕見的範例之一。
Trusted vs Trustless 跨鏈橋比較：
| 類型 | 比喻 | 核心原則 | 安全風險 | 舉例 |
| --- | --- | --- | --- | --- |
| Trusted | 有人幫你代轉資產 | 信任一群節點或機構 | 若他們出錯或被駭，你就完了 | Ronin, Binance Bridge |
| Trustless | 自己帶證據給目標鏈驗證 | 信任密碼學與證據本身 | 安全高但實作難，執行較慢 | Snowbridge, BTC Relay |
## 3.3 Relayer 是什麼角色？
Relayer 是一種「郵差」，負責把訊息或證據從 source chain 傳到 target chain。
他不需要被信任，因為重點是他送的那包資料能不能通過驗證。
- 若是 trusted bridge，Relayer 有可能是可信的運營者
- 若是 trustless bridge，Relayer 是純轉送資料的角色，安全性不依賴他
舉例說明：你買東西但要先付錢
你想從 source chain（Ethereum）轉幣到 target chain（Avalanche）
你先在 source chain 上「鎖幣」 → 相當於你把錢交給店家
source chain 上會出現一筆交易紀錄（event）
**Relayer 負責觀察這筆紀錄，然後通知** target chain
target chain 接收到通知，就在你帳號裡「鑄造對應數量的 wETH」
如果沒有 relayer，這封信就永遠不會送達。
### 具體任務包含：
1. **監看** source chain
監聽是否有新事件發生（例如：某人鎖了 token、發了訊息）
2. **製作 proof 或收集資料**
把來源鏈的事件轉換成目標鏈能理解的格式，可能要搭配 Merkle proof、Oracle 資料或經簽名的訊息
3. **向目標鏈遞交訊息**
把訊息與證明資料打包送到目標鏈的智能合約，請它驗證與執行動作
### Relayer 可以是誰？
很多協議（例如 LayerZero）允許 **任何人都可以當 relayer**，這讓系統更去中心化。但這也代表：
- 需要某種機制來懲罰惡意 relayer（例如送錯資料、蓄意拖延）
- 有些系統會要求 relayer 抵押保證金，以防出錯時無成本作惡
- 也有協議會讓 relayer 和 Oracle 相互驗證，兩者需一致才執行跨鏈操作
在一些設計中（如 trusted bridge），relayer 是少數被信任的機構；而在去中心化設計中（如 LayerZero、Hyperlane），relayer 是開放角色，讓所有人都可以參與
## 3.4 中介訊息層協議（Middle-layer Messaging Protocols）與混合式橋接（Hybrid Approaches）機制：功能分工與信任折衷
在多鏈生態系逐漸成熟的過程中，跨鏈需求已不再侷限於資產轉移，更多元的應用場景需要鏈與鏈之間的「訊息溝通」。因此，除了傳統的橋（Bridge）機制之外，出現了兩種發展方向：
- 一種是完全不碰資產、專注於訊息傳遞的「中介訊息層協議（Middle-layer Messaging Protocols））」
- 另一種是針對不同場景，彈性調整信任來源與驗證方式的「混合式橋接機制（Hybrid Approaches）」
## 3.4.1 中介訊息層協議（Middle-layer Messaging Protocols）：專注訊息傳遞的 middleware
這類協議的設計理念很單純：**只處理訊息，不碰資產**。
它們不會在某條鏈鎖定資產、也不會發行 wrapped token，而是透過「讀資料 + 驗證事件」來實現鏈與鏈之間的安全通信。
### 技術架構：
- **Oracle（預言機）**：讀取來源鏈上事件（如交易、事件）
- **Relayer（訊息轉送者）**：攜帶資料與證明，送往目標鏈驗證執行
這種設計像是在區塊鏈之間搭一層「快遞公司」，幫你遞送訊息與執行請求。
### 開發者角度：
開發者可透過統一介面如 SDK 發送跨鏈訊息，不需關心背後 proof 或共識邏輯：
```jsx
crossChain.sendMessage({
from: Ethereum,
to: Avalanche,
payload: "mint NFT to 0xABC"
});
```
### 適用場景：
- 跨鏈觸發合約（如 DAO 治理傳遞）
- 資訊同步（如鏈 A 決策 → 鏈 B 執行）
- NFT 跨鏈互動（如 event minting）
### 常見協議：
- **LayerZero**：雙軌 Oracle + Relayer，需兩者一致才執行
- **Axelar**：用 PoS 驗證者群驗證訊息
- **Chainlink CCIP**：利用 oracle 網路共識
- **Wormhole Messaging Layer**：分離資產橋與訊息層
- **Hyperlane**：模組化安全，可自訂 relayer 與驗證者
## 3.4.2 混合式橋接機制（Hybrid Approaches）：靈活的信任設計
Hybrid Bridge 並非專注「純訊息」或「純資產」，而是根據場景混合設計出最合適的驗證與傳輸路徑。可說是介於完全中心化（trusted）與去中心化（trustless）之間的「灰階選擇」。
### 設計特點：
- **多層驗證結構**：可能同時使用 Oracle、Relayer、治理仲裁等
- **可調信任模型**：重要交易加強驗證、不重要操作降低 gas 費
- **實用導向**：適合 Layer 2、App Chain、遊戲與多鏈部署應用
案例：LayerZero 作為 Hybrid 代表
- **Oracle**：傳遞訊息（如 Chainlink）
- **Relayer**：提供交易與事件的 Merkle proof
- 兩者需一致，才會執行跨鏈指令
但 LayerZero **並未強制實施去中心化驗證者機制**，因此仍需信任特定 Oracle 與 Relayer 的正確性。
**中介訊息層協議與混合式橋接機制的差異：**
| 項目 | 中介訊息層協議 | 混合式橋接機制 |
| --- | --- | --- |
| 核心功能 | 訊息傳遞 | 訊息 + 資產雙功能 |
| 是否接觸資產 | ❌ 不接觸 | ✅ 視應用而定 |
| 驗證來源 | Oracle + Relayer | Oracle + Relayer + 仲裁治理（可調） |
| Trustless 程度 | 高度專注安全傳訊 | 根據設計可能有信任假設 |
| 適用場景 | 跨鏈合約呼叫、治理同步 | 多鏈 dApp、資產操作、遊戲 |
| 彈性與擴展性 | 高（專注通信） | 更高（可混搭安全機制） |
- **Message Layer 協議**會建立自己的一整套跨鏈驗證邏輯，像是：
- validator network（Axelar）
- relay network + arbitration（Wormhole）
- Oracle + Relayer 分離機制（LayerZero）
- **Hybrid Bridge**則更像是一種**架構設計範式**，它可能：
- 用兩套來源交叉驗證（像 Oracle + Relayer）
- 或讓應用開發者選擇自己信任的驗證人群
- 而不一定建一整個訊息網路平台
**與傳統 Bridge 比較：**
| 功能 | 傳統 Bridge | 中介訊息協議 |
| --- | --- | --- |
| 主要目的 | 資產轉移（lock & mint） | 訊息傳遞、跨鏈操作 |
| 是否接觸資產 | 需要鎖資產 | 不接觸資產 |
| 安全依賴 | Bridge 自身、multi-sig | 資料來源（oracle）、proof 驗證 |
| 速度與彈性 | 慢、操作繁瑣 | 快速、通用性高 |
| 應用場景 | 轉帳、存款 | 呼叫合約、跨鏈 NFT 或 DAO 協議 |
## 常見中介訊息協議
- **LayerZero**
採用 Oracle + Relayer 雙通道架構，要求兩者對同一筆訊息達成共識才執行，避免單一資料來源造假。支持多鏈應用（如 Stargate）。
- **Axelar**
使用類似 PoS 鏈的驗證者群（validators）來投票驗證跨鏈訊息與交易的 proof，再由 relayer 傳遞。主打安全與通用性，整合 Cosmos 與 EVM 多鏈。
- **Chainlink CCIP（Cross-Chain Interoperability Protocol）**
建立在 Chainlink 強大的 oracle 網路上，透過多節點共識與治理機制傳遞跨鏈訊息。除了訊息傳遞，也開始支援資產轉移（如 Swift 測試案）。
- **Wormhole Messaging Layer**
雖然最早是資產 bridge，但後來分離出 Messaging Layer，支援 Solana 等鏈的跨鏈呼叫，讓開發者可利用現有 bridge 路徑做輕量級呼叫。
- **Hyperlane**
主打 Modular Security，讓應用可以自訂 relayer 和驗證邏輯。也是以訊息傳遞為核心，不主打資產 custody。
# 4.平行鏈與共享安全： Polkadot 的跨鏈設計與三條跨鏈—Snowbridge、Hyperbridge、Kusama Bridge
當其他鏈在為了互通性傷腦筋時，Polkadot 從設計之初就把「多鏈互通」放在核心地位。它不是用橋來「後補」跨鏈問題，而是設計了一整個「鏈的聯邦」體系來解決。
### Polkadot 是什麼？
Polkadot 是一個 **多鏈架構平台**，由兩部分組成：
1. **中繼鏈（Relay Chain）**：唯一的主鏈，負責安全性、共識與跨鏈訊息傳遞。
2. **平行鏈（Parachains）**：獨立的區塊鏈，可依需求設計自己的邏輯，但共享中繼鏈的安全性與訊息傳遞能力。
你可以想像中繼鏈是一台主機，平行鏈是插在主機上的模組卡，每張卡可以跑不同的應用，但都透過同一套主機處理資料與溝通。
### 為什麼 Polkadot 的跨鏈比較「原生」？
其他鏈需要在之後「額外建橋」，但 Polkadot 的跨鏈邏輯早就寫進它的共識協議與架構中。
Polkadot 的跨鏈原理大致如下：
1. 每一條平行鏈自己產區塊，但由中繼鏈的 validator 驗證 → 達到 **共享安全**。
2. 若 A 鏈要與 B 鏈互動，透過 **XCMP（Cross-chain Message Passing）** 傳遞訊息，由中繼鏈協調驗證 → 避免偽造與重放攻擊。
3. 各鏈之間不需要橋，不需要額外信任機制，因為共識與驗證早就「寫死」在中繼鏈上。
這就像是：
- **以太坊 / Solana 等鏈** → 像不同國家，要辦護照、簽證、兌幣，才能跨境。
- **Polkadot 的平行鏈** → 像同一個聯邦內的不同城市，共用國防（安全）、同一語言（協議）、內部轉帳無痛（XCMP）。
- XCMP
XCMP 是 Polkadot 生態系設計的一套跨鏈訊息傳遞機制，全名為 **Cross-Chain Message Passing（跨鏈訊息傳遞）**。它讓不同的平行鏈（parachain）之間可以直接互相溝通、傳送訊息，不需要經過智能合約或外部橋接協議。這是一種原生設計，建構在 Polkadot 的中繼鏈（Relay Chain）之上，確保所有資訊交換都受到中繼鏈的安全保護。
想像每一條平行鏈像是一個「地鐵車站」，而中繼鏈就是「控制中心」，負責協調所有車站的溝通。當一條鏈想要對另一條鏈發送訊息，它會先把訊息提交給中繼鏈，然後中繼鏈會協助把這個訊息安全地送到目的鏈。整個過程中，訊息會經過中繼鏈的共識驗證，保證內容沒有被竄改。
XCMP 的訊息內容可以是「請轉帳某個資產」、「請執行某段邏輯」、「通知某個事件已經完成」等等。而且因為不需要經過智能合約或其他第三方驗證者，整個流程又快又便宜。
和一些跨鏈橋（如 LayerZero、Axelar）相比，XCMP **不是點對點鏈與鏈之間各自驗證，而是統一由中繼鏈協調**。這樣設計的好處是：
1. 安全性由 Polkadot 的 validator 保證，不需額外信任第三方。
2. 所有參與的鏈都在同一個共識架構下，訊息驗證更快。
3. 不用為每一對鏈各自建一條橋（像 LayerZero 每個鏈都要配置 relayer、oracle）。
XCMP 是實現 Polkadot「多鏈未來」的關鍵拼圖。它讓資產與訊息能夠在不同平行鏈之間自由流通，無需繁瑣設定或重複部署橋接程式。舉例來說，一條 DeFi 鏈可以直接從另一條 NFT 鏈接收轉帳通知並回應用戶操作，這在其他公鏈生態是需要額外橋、或在應用層模擬的事情，但在 Polkadot 裡是系統層支援的功能。
## 4.1 Snowbridge：Polkadot ↔ Ethereum 的信任最小橋（Trust-minimized bridge）
### 開發背景與目的
Snowbridge 是由 **Snowfork 團隊** 與 Polkadot 核心開發者 **Parity Technologies** 合作開發的一條「信任最小橋」（trust-minimized bridge），專門讓 **Polkadot ↔ Ethereum 主網** 之間可以直接互通資產與訊息。它屬於「trustless bridge（去信任橋）」架構的一種，強調不依賴中心化中介（如多簽或驗證人組），而是雙邊鏈都直接驗證對方區塊資訊的 **light-client 驗證模式**。
https://app.snowbridge.network/
### 技術架構：雙向 light client 設計
它是一條 **light client-based 的 trustless bridge**，意思是：
- Polkadot 跑一個 Ethereum 的 light client → 能驗證 ETH 鏈上的共識與交易。
- Ethereum 跑一個 Polkadot 的 light client → 能驗證 DOT 鏈上的共識與訊息。
整體橋接過程完全去中心化，不依賴第三方 validator 或 relayer，使用者自己在鏈上就能驗證跨鏈訊息。
### 跨鏈流程（以從 Ethereum → Polkadot 為例）
1. 使用者在 Ethereum 發起一筆交易，把 ETH 或 ERC20 token 傳進 Snowbridge 合約（也可執行某個事件）。
2. Ethereum 這邊的 light client 會產生該區塊的 Merkle proof，並將其資訊透過訊息提交至 Polkadot。
3. Polkadot 上的 light client 會驗證該 Ethereum 區塊頭與該事件存在於其中。
4. 驗證成功後，Polkadot 上就會「鑄造一份等值資產」或觸發對應的行為。
這種方式的優點是完全不需要信任外部 relayer，只要兩邊都能成功同步區塊資訊與驗證邏輯即可。
### 技術難點與現狀
- Ethereum 與 Polkadot 的共識機制非常不同：Ethereum 是 PoS + Finality Gadget（Casper），Polkadot 則是 BABE + GRANDPA。
- 在 Ethereum 上跑 Polkadot 的 light client 非常困難（執行環境差、gas 貴），Snowbridge 透過模組化、壓縮區塊頭與遞延驗證方式，盡力降低成本。
- 開發進度緩慢，目前主要由 Snowfork 團隊在開發，但並未正式進入大量使用階段。
## 4.2 Hyperbridge：Polkadot ↔ 外部多鏈的總控橋
### Hyperbridge是什麼？
**Hyperbridge** 是一種專為 Polkadot 設計的 **模組化跨鏈橋（modular cross-chain bridge）**，它的主要特色是想做成一個「跨鏈中繼站」，把 Polkadot 跟多條外部鏈（如 Ethereum、BNB Smart Chain、Arbitrum、Optimisum等）接起來。
與 Snowbridge 不同，**Hyperbridge 並不強調每條鏈都部署 light client**，而是讓 Hyperbridge 本身成為一個 **中介層（middleware）**，集中處理不同鏈之間的互動、驗證與訊息轉送。
https://app.hyperbridge.network/
### 架構總覽
Hyperbridge 是由一個名為 **Hyperbridge parachain（平行鏈）** 承載所有跨鏈功能，在 Polkadot 生態中，它本身就是一條擁有獨立共識與驗證邏輯的平行鏈。
它運作的方式類似「訊息總站」，接收並驗證來自外部鏈的資訊，再根據設定好的邏輯，把結果傳回目標鏈。
簡單比喻：Snowbridge 是雙方直接通訊，Hyperbridge 則像一個總站收發室，負責從 A 鏈收到包裹 → 檢查真偽 → 再轉寄給 B 鏈。
### 運作方式（以從 Ethereum → Polkadot 其他 parachain 為例）
- 使用者在 Ethereum 發送一筆交易或鎖定資產。
- Ethereum 上某個橋接模組（或與 Hyperbridge 合作的預言機／驗證者集）把該事件打包成訊息送往 Hyperbridge。
- Hyperbridge 上會執行驗證：確認該訊息來自合法來源（例如有足夠權威的多簽、ZKP、驗證者共識等）。
- 驗證成功後，Hyperbridge 再把這個訊息轉發給目標 Polkadot 平行鏈（如 Moonbeam）。
- 目標鏈收到訊息後執行對應操作（如鑄造資產、觸發功能等）。
### 技術特徵
- **模組化設計**：可插入不同鏈的接收器模組（adapters），根據不同鏈的驗證方式做調整。
- **支援多鏈**：不只是 Ethereum，也有BNB Smart Chain、Arbitrum、Optimisum。
- **非 trustless**：目前大多數驗證方式仍需依賴 validator set、多簽或第三方 proof 機制，尚未做到完全 trustless。
- **可編程驗證邏輯**：驗證邏輯可根據目標鏈不同設計，彈性較高。
## 4.3 Kusama Bridge（也稱為 KSM-Relay Chain Bridge）
Kusama Bridge 是 Polkadot 與其姐妹鏈 Kusama 之間的官方原生橋接機制，設計目的在於實現兩鏈之間的訊息與資產互通。由於 Polkadot 與 Kusama 採用相同的 Substrate 技術堆疊與類似的共識架構，因此這條橋主要用於治理協調、升級測試與資源調度，而非單純跨鏈資產轉移。
### 運作模式
Kusama Bridge 建構於 BEEFY 協議之上，透過 validator 對 finalized block 所簽署的最終性證明（finality proof），將 Polkadot 上的確定狀態安全地轉譯至 Kusama，反之亦然。這使得每當 Polkadot 上有治理議案通過、某個事件發生，Kusama 都能在不需要同步整條鏈的情況下快速驗證並做出對應反應。這類「單向訊息驗證」搭配 Merkle proof，可支援指定事件驗證與精準觸發。
### 特性：雙向原生與共享安全
與 Snowbridge 等鏈間橋不同，Kusama Bridge 是由 Polkadot 與 Kusama 兩邊共管、原生實作的橋接模組。這代表兩鏈彼此對彼此都有基本信任，不需要依賴中介協議或額外信任假設。由於雙方都採用 GRANDPA 共識與 BEEFY 結構，這條橋的安全性與效率高於一般異構鏈橋接機制。
### 用途與定位
Kusama Bridge 不僅是 Polkadot 生態中的測試與實驗橋，也是實現多鏈治理協同的重要工具。未來，Polkadot 若實作全鏈治理變更（如 runtime 升級、橋接新鏈），可以先透過 Kusama Bridge 測試流程與回應時間，確保主鏈安全無虞。此外，它也是連接更大區塊鏈網路的節點之一，可作為對外擴展的中繼層。
## 4.4 BEEFY 協議
**BEEFY（Bridge Efficiency Enabling Finality Yielder）** 是 Polkadot 專為跨鏈橋接設計的一種「最終性證明協議」，用來在不需同步所有區塊的情況下，將 Polkadot 網路的最終狀態高效、安全地傳遞給其他鏈。簡單說，BEEFY 就像是一個「輕量級的共識轉譯器」，讓外部鏈可以相信 Polkadot 上的某一筆資料確實已經最終確定，且不會再被回滾。
### BEEFY 為什麼重要？
傳統區塊鏈跨鏈設計時，若一方需要完全驗證另一條鏈的狀態，往往得同步大量區塊資料與共識邏輯，成本高昂。例如，要讓 Ethereum 信任 Polkadot 上一筆轉帳是否已確認，理論上要跑完整個 Polkadot 區塊驗證邏輯。但這樣幾乎等於自己再跑一個 Polkadot，極度不切實際。
BEEFY 的誕生就是為了避免這種「重鏈」成本。它將區塊最終性抽象成一種可攜帶、可驗證的格式，只需提交少量被 validator 簽署的檢查點（checkpoint），就能讓其他鏈驗證其真實性。這種方式稱為 **「最終性證明（finality proof）」**。
### BEEFY 如何運作
1. **Polkadot 每個 epoch（例如每 6 秒）會生成一個 finalized block**，代表該區塊前的所有交易都不會再被更改。
2. 一組專門的 validator（BEEFY validator）會對該 finalized block 做簽章。
3. 所有簽章資訊與該區塊的 Merkle root 被包裝成一筆 BEEFY payload。
4. 這個 payload 可以被送到外部鏈（例如 Ethereum、Kusama），供那邊的 light client 驗證。
5. 驗證成功後，就能在對方鏈上執行相關操作（例如放行資產轉移、觸發治理訊息等）。
### BEEFY 的特色與優點
- **節省成本**：只傳送 checkpoint 和簡化簽章，不需要整鏈同步。
- **增強安全**：驗證基礎是 Polkadot 的 GRANDPA 最終性共識，攻擊門檻高。
- **可擴展性強**：支援多條外部鏈的接入與驗證（如 Ethereum、Kusama、Snowbridge 等）。
- **開放可組合**：搭配 Merkle proof，可以進一步驗證特定事件或交易。
### 哪些橋有用到 BEEFY？
目前 Polkadot 官方與生態系內，已有多個橋接機制導入 BEEFY 作為核心驗證邏輯：
- **Kusama Bridge**：Polkadot ↔ Kusama 的原生雙向橋，使用 BEEFY 作為基礎最終性驗證。
- **Snowbridge**：Polkadot ↔ Ethereum 的資產橋接與訊息傳遞，BEEFY 提供 Ethereum 能信任 Polkadot 狀態的根據。
- **Hyperbridge**：設計用於接入非平行鏈的外部鏈，透過 BEEFY 將 Polkadot 的安全性輸出給其他鏈。
**BEEFY 就是 Polkadot 世界對外「出口信任」的標準協議**。它不僅讓跨鏈橋能夠運作，更是實現 Polkadot 作為「多鏈網路安全核心」的基石。沒有 BEEFY，就無法有效、安全地把 Polkadot 的最終性資訊輸出給其他鏈，也就難以達成真正去中心化的跨鏈溝通。
# 五、跨鏈技術全景圖（依技術核心分類）
我們可以將目前的跨鏈技術分為幾大類型，根據其運作原理與安全假設大致可分為以下幾種：
### 1. Trusted Bridges
- **代表：Binance Bridge、Wormhole（前期）**
- **運作方式**：依賴一組中心化或半中心化的節點（custodians）代為鎖幣與釋幣，節點需獲得使用者信任。
- **優點**：部署快速、效率高。
- **缺點**：極度依賴節點誠信，曾發生過重大資金損失（如Wormhole遭駭）。
### 2. Trustless Bridges
- **代表：IBC、Snowbridge、BTC Relay**
- **運作方式**：鏈與鏈之間透過共識驗證或 light client 技術來彼此驗證對方狀態，不依賴中介者。
- **優點**：安全性高，沒有中心化單點風險。
- **缺點**：技術實作複雜，不是每條鏈都能支援。
### 3. Middle-layer Messaging Protocols（中介訊息層協議）
- **代表：LayerZero、Axelar、Chainlink CCIP**
- **運作方式**：
- LayerZero：oracle + relayer 雙軌驗證模型，使用者可自選服務提供者。
- Axelar：類似 Cosmos Hub 的 validator 共識群，接收 Proof 再轉發訊息。
- Chainlink CCIP：與 LayerZero 類似，但強調 Chainlink 自有 oracle 網絡與服務層的治理整合。
- **優點**：彈性高、鏈支援範圍廣、可以快速佈署。
- **缺點**：仍須信任 oracle、relayer 或 validator 群，非絕對 trustless。
### 4. Relay Chain Models（中繼鏈架構）
- **代表：Polkadot、Cosmos Hub（部分）**
- **運作方式**：由一條主鏈（Relay Chain）負責驗證所有連接鏈的交易與訊息，形成一個共識安全圈。
- **優點**：訊息傳遞原生整合、效能穩定、安全可控。
- **缺點**：加入此模型需要重新設計鏈的共識與架構，非 plug-and-play。
### 5. Hybrid Approaches（混合式橋接）
- **代表：Hyperlane、Wormhole（後期）、Celer cBridge**
- **運作方式**：結合多種驗證模式（如 optimistic + oracle + 多簽），根據需求調整安全與效率的平衡。
- **優點**：具彈性，能同時支援多種鏈與用例。
- **缺點**：邏輯複雜，使用者需理解背後風險假設。
Sign in with Wallet
Connect another wallet