作者：PaperMoon团队

加密货币历史上损失最惨重的五起安全事件，四起都指向同一个位置：跨链桥。根据 Chainalysis 的报告，仅中心化跨链桥的失败就造成了超过 20 亿美元的损失，占所有加密黑客事件的 60% 以上。这是结构性缺陷，不是偶发事故——只要系统依赖一个可以被攻破的中间人，这个中间人就会被攻破。

理解 Polkadot 的跨链桥设计，核心不在于"如何连接两条链"，而在于"由谁来担保这个连接的可信度"。想清楚这个问题，后面的三条路径就都说得通了。

一、中心化桥为何成为最大漏洞

多签中继的本质问题

当前市场主流的跨链桥大多依赖中心化中介——通常是一组由多签方案控制的中继节点。工作流程是：用户在链 A 锁定资产，中继节点监听到事件后在链 B 铸造等价资产。

这种设计的问题在于，安全性完全取决于那一组多签持有者。用户表面上在做"跨链交易"，实质上是在信任几个人或几个组织不作恶、不被攻破。

区块链的核心价值主张是"不需要信任特定个体"，中心化桥在这里打了一个洞。

数字说明了问题的严重性

- Chainalysis 统计：中心化桥事故占所有加密黑客损失的 60%+，累计 20 亿美元以上
- [rekt leaderboard](https://rekt.news/tr/leaderboard/)（链上最大损失排行榜）前五名中，四起直接与桥相关

一个系统的安全性取决于它最薄弱的环节，而桥反复证明了自己就是那个环节。

 二、无信任桥的技术基础

什么是无信任

无信任（Trustless）不是说系统没有任何假设，而是说用户不需要信任特定个体或组织——他们只需要信任数学、代码、密码学和协议本身。

一个完整的双向无信任桥可以拆解为两个单向桥的组合。每个单向桥都包含两类组件：桥的链上部分是部署在各链 runtime 上的模块，负责验证对方链的最终确认状态；链下部分是称为 Relayer（中继器）的独立进程，负责在两链之间传递消息。

两者缺一不可。链上验证由代码自动完成，不依赖任何中继器的诚实性——这才是无信任的核心。

三、三条实现路径

根据目标链的技术特性，Polkadot 生态的无信任桥有三条路径，按优先级排列：

路径一：Bridge Pallets（Substrate 原生链）

适用场景：目标链也基于 Substrate 框架，使用 GRANDPA 共识。

GRANDPA 是 Polkadot/Substrate 的最终确认共识协议，保证区块在达到某个阈值后不可逆转。

原理很直接：在目标链的 runtime 里内置一个源链的 GRANDPA 轻客户端（Light Client）。这个轻客户端可以独立验证源链上的区块最终性，不需要任何外部中介。

Bridge Hub 是 Polkadot 的专用桥接系统平行链，运行多个链的轻客户端，统一处理跨链消息。它目前运行了 Kusama 的 GRANDPA 轻客户端，可以独立验证 Kusama 及其所有平行链的交易最终性。

最典型的案例是 [Kusama ↔ Polkadot 双向桥](https://wiki.polkadot.com/learn/learn-DOT-KSM-bridge/)：两条链都基于 Substrate + GRANDPA，Bridge Pallet 方案是最自然的选择。

路径二：智能合约（以太坊等非 Substrate 链）

适用场景：目标链不基于 Substrate，但支持图灵完备的智能合约语言。

以以太坊为例：在以太坊上部署 Polkadot 轻客户端智能合约可以实现无信任验证，但直接运行 GRANDPA 轻客户端的 Gas 成本太高，经济上跑不通。

解决方案是 BEEFY，一个构建在 GRANDPA 之上的共识层，专门为跨链桥设计，提供更轻量的 Polkadot 状态证明格式，把在以太坊验证 Polkadot 状态的成本压到可行范围内。

[Snowbridge](https://wiki.polkadot.com/learn/learn-snowbridge/) 就是这套方案的实现：以太坊侧部署基于 BEEFY 的 Polkadot 轻客户端智能合约，Bridge Hub 侧运行 Ethereum 轻客户端，两侧均可独立验证对方链的状态。

连接 Cosmos、Avalanche、NEAR 等链需要为各自共识协议开发定制的 pallet 部署在 Bridge Hub 上，思路相同。

路径三：高阶协议（比特币等无智能合约链）

适用场景：目标链不基于 Substrate，且不支持智能合约，比如比特币。

此时前两条路径均不适用，需要使用更高层次的协议方案。代表性协议是 XCLAIM。

XCLAIM 的核心机制：任何可兑换的跨链资产都必须有高于其价值的抵押品作为背书。用户在比特币侧锁定 BTC，在 Polkadot 侧铸造等价的 iBTC；赎回时销毁 iBTC 并解锁对应 BTC。抵押品机制确保即便中间某个环节出问题，用户损失也有兜底保障。

代价是资本效率的损耗：必须有人锁定超额抵押品来支撑整个系统，不如前两条路径轻量。

[Interlay 的 iBTC](https://app.interlay.io/btc?tab=issue) 是当前主网运行的比特币 ↔ Polkadot 桥，基于 XCLAIM 设计规范，包含两个核心模块：XCLAIM 组件维护持有 iBTC 的所有账户，BTC-Relay 负责提交新交易时验证比特币链上状态。

四、Snowbridge vs Hyperbridge：主流方案对比

Polkadot 目前有两个无信任跨链桥方案处于运行状态，各有侧重：

对比维度	Snowbridge	Hyperbridge
覆盖链	仅支持 Ethereum ↔ Polkadot	支持 多链互通
轻客户端架构	Ethereum 轻客户端运行在 Bridge Hub；Polkadot 轻客户端运行在 Ethereum 合约	通过 独立平行链实现跨链验证
原生代币	使用 DOT	使用 Hyperbridge 原生代币
证明方式	BEEFY 随机采样证明	零知识证明（ZKP）
代码复杂度	代码库相对简单，但验证逻辑分析较复杂	代码库复杂，但验证逻辑更直接
硬件要求	低配置硬件即可运行证明者，完全无许可	ZK 计算需求高，需要 高性能硬件
Ethereum → Polkadot 确认时间	数十分钟	约 10–20 分钟
Polkadot → Ethereum 确认时间	较高延迟（约 30 分钟，需等待两个 Ethereum epoch）	较低延迟（约 5–7 分钟，取决硬件）
消息协议	XCM（跨共识消息格式）	ISMP（Hyperbridge 跨链协议）
当前状态	已上线	已上线

几个值得注意的细节：Snowbridge 依赖 Milagro BLS 库做签名验证，Hyperbridge 依赖 ZK 相关库（如 PLONK），两者都有外部依赖，不是哪一个更"纯粹"。Snowbridge 部署在系统链上，其发行的 WETH 被视为 Polkadot 上的"官方 WETH"，但这是技术定位，不是信用背书。

五、用桥必知：资产不兼容陷阱

这是跨链桥生态中最容易被忽视、也最容易造成实际损失的问题：

**通过不同桥发送的同种资产，是两种不同的资产。**

举例：用 Snowbridge 将 WETH 从以太坊转入 Polkadot，得到的是 Snowbridge-WETH；用 Hyperbridge 转的是 Hyperbridge-WETH。这两种 WETH 在 Polkadot 上无法互换。如果用 Snowbridge 存入，却试图用 Hyperbridge 取回，除非目标协议专门实现了兼容逻辑，否则资产无法正确赎回。

操作建议很简单：进出使用同一座桥，跨链前确认资产标识符，不要混用。

小结

- **中心化桥是最大漏洞**：多签中介引入了可攻击的信任假设，已造成 20 亿美元以上损失
- **三条无信任路径**：Substrate 原生链用 Bridge Pallets，以太坊等链用智能合约（Snowbridge/BEEFY），比特币用 XCLAIM 高阶协议
- **Snowbridge vs Hyperbridge**：两者均已上线，Snowbridge 仅覆盖以太坊、用 BEEFY 证明；Hyperbridge 覆盖多链、用 ZK 证明，Polkadot → 以太坊方向延迟更低
- **资产不兼容风险**：不同桥发行的同种资产不可互换，进出务必使用同一座桥

用数学替代信任，这件事比听起来难得多。Polkadot 现在有了架构上的答案，工程上的答案还在继续写。

**参考资料**：
- [Polkadot Wiki - Blockchain Bridges](https://wiki.polkadot.com/learn/learn-bridges/)
- [Chainalysis - Cross-chain Bridge Hacks 2022](https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/)
- [Rekt Leaderboard](https://rekt.news/tr/leaderboard/)