Cross chain 总览

坐忘道
发布于 14小时前
阅读 54

Crosschainmessaging(2)Crosschain跨链是把一条区块链上的“已发生事实”（状态/事件/余额变动等）以可验证的方式带到另一条链上，使后者可以在自身共识下对该事实作出行动（调用合约/铸造或释放资产/更新状态）。本质是在不同安全域之间做可信消息传递与（可选的）资产迁

# Cross chain messaging (2)

# Cross chain

**跨链**是把一条区块链上的“已发生事实”（状态/事件/余额变动等）以**可验证**的方式带到另一条链上，使后者可以**在自身共识下**对该事实作出行动（调用合约/铸造或释放资产/更新状态）。本质是在不同安全域之间做**可信消息传递**与（可选的）**资产迁移**。

白话文就是

```jsx
谁来验证“链A发生了X”？他能否说谎？说谎的代价是什么？
这决定了安全模型、成本与延迟。
```

## 为何会有跨链的存在呢？

主要在以下几个场景

1. 多链并存和分工：提高效率，也可以通过跨链技术减少重复建设和资源浪费、也可以通过多链分工提高工作效率
2. 资产整合：投资者可能持有不同链上的资产、可以通过跨链将资产整合
3. 提高流动性：讲不通区块链上的资源和流动性链接起来，为用户提供更多的交易和投资选择

## 跨链需要解决的关键问题

- 可验证性：假设是a链到b链，如何在b链上的逻辑里面验证a链传过来的内容是否是正确的
- 最终性与回滚：a链可能短暂重组，需等待最终性或引入挑战期(rainbow bridge引入了挑战期，在四个小时左右)
- 顺序/重放/幂等：消息序列如何保证有序消费、避免被重复执行或跨域重放。
- 费用与延迟：验证的成本（链上计算/外部服务）与消息到达、可执行的时间。

# 主流路线

## Light client

![image.png](https://img.learnblockchain.cn/attachments/2025/10/KgSUbiJV69006c9c783e8.png)

1. 通过raibow bridge在链上部署互相的light client，也就是说拿以太坊跟NEAR链举例，如果是以太坊要转资产进NEAR的话，流程架构
    1. EthOnNearClient，在NEAR合约里维护以太坊header，他只保存最近一段时间（大概七天）最终已经确定的header，来避免状态(stateles cryptocurrency？)无限膨胀。因此用户需要在这个窗口内完成提交证明
    2. prover合约也是部署在NEAR上，拿到以太坊的log、merkle proof等证明来对照EthOnNearClient存储的header，其中含 receiptsRoot），在 NEAR 上验证“ETH 侧真的发生了某事件”  
![image 1.png](https://img.learnblockchain.cn/attachments/2025/10/vpg8ZX6B69006ce4dd9ba.png)
    1. Token Locker（ETH ）/ Token Connector（NEAR ）：前者锁定用户的 ERC-20 并产生事件；后者在 NEAR 侧铸造/释放对应的 NEP-141 代表资产。    
    流程如下：转 ERC-20 为例    
    - 授权 & 锁定（ETH 侧）        
        用户先给 TokenLocker approve，随后调用 TokenLocker 把 X 枚 ERC-20 转入托管。合约会在以太坊链上发出 Locked 事件（记录发送者、金额、目标链接收者等）。        
    - 等待以太坊最终性        
        需等 ETH 区块达到“不可逆”的安全阈值（PoS 下通常取最终确定区块），这样 NEAR 侧验证时不必担心回滚。EthOnNearClient 在 NEAR 上持续接收 ETH 区块头并维护规范链。        
    - 生成并提交“事件存在性证明”        
        中继/提交者从 ETH 全节点取到这笔锁定交易的收据与日志，连同MPT（收据树）证明与所在区块头（含 receiptsRoot），打包成证明，提交给 NEAR 上的 Prover 合约。        
    - NEAR 上链验证（Prover ↔ EthOnNearClient）
        - Prover 调用 EthOnNearClient：确认该区块头在其已跟踪的规范链里；
        - 用区块头里的 receiptsRoot 验证“这条 Locked 事件日志确实包含在该区块的收据树中”；
        - 做去重（双花问题）。            
            验证通过，即在 NEAR 侧得到“ETH 上已锁定”的可验证承诺。
         - 在 NEAR 侧铸造/释放代表资产
        Token Connector（NEAR）据此给用户铸造/释放等额的 NEP-141（例如 nDAI），完成从 ETH 到 NEAR 的资产映射迁移。用户在 NEAR 钱包中看到余额增加。

![image 2.png](https://img.learnblockchain.cn/attachments/2025/10/dCHIqilp69006d2a5f01e.png)

### 一句话总结：

**锁（ETH）→ 证（NEAR 上验证“ETH 确实锁了”）→ 铸（NEAR）**。轻客户端提供“**信区块头**”的根，Prover 提供“**信事件**”的证；NEAR 因此能在**不信任第三方**的前提下，相信以太坊上真的发生了那件事。

## Relay chain

是一条专门用于跨链的“中间链/枢纽链”。它自己跑共识、出块、记账，同时**托管和运行多条外部链的轻客户端**

把“跨链消息的验证与转发”收束到自己这里来做——再由各业务链只需要**验证 Relay Chain 的状态**即可完成跨链。这类设计把“谁来证明别的链上发生了什么”集中到了中继链的链上逻辑中。以 MAPO 的表述：底层的 **MAP Relay Chain** 提供“**纯信任最小化的跨链消息验证能力**”，其上**部署各链的轻客户端**；同时，各业务链上也部署 **MAPO 的轻客户端** 来验证来自 Relay Chain 的消息，实现“双向轻LC的嵌入”。

## 已经有Light Client，为何还要 Relay Chain？

**轻客户端法（LC）通常是“每对链彼此在对方链上部署对方的轻客户端，再在目的链验证源链事件”。这在多链网络里会出现两两对接的 N² 复杂度**与**在高成本链上做重验证**的问题。

**Relay Chain** 的做法是：

- 在 **Relay Chain 上集中维护“各链轻客户端”**，负责对“源链事件”做链上验证；
- 在**各业务链上只部署**“**Relay Chain 的轻客户端**”，这样业务链只需验证“Relay Chain 的结论”即可，不再每对链互相部署。MAP 官方集成文档直说：跨链消息经 **map-relay-chain** 中转，因此“集成链**只需部署 relay-chain 的 light-client** 来验证来自 relay 的消息”，自身则实现“**自己的轻客户端部署到 relay-chain**”。

结果是：

- **连接复杂度**：由“每对链各自对接”降为“每条链对接一次 Relay”（从 N² 降到 ~N）。
- **验证成本**：把多链验证集中到一条可控的链环境（可做预编译/电路优化）以**降低目的链上的 gas 压力**。
- **可扩展性**：新链入网，只需接入 Relay 的轻客户端体系，就能与已接入的所有链互通。

### 解决的关键问题

1. 验证发正在链上
2. 双向的LC，可以让任意两条已经接入的链经过relay互通
3. MAPO使用iBFT和PoS共识，具有及时的区块最终性
4. 使得Dapp可以进行复用

### relay chain流程如下

- **源链产生事件**（如锁定资产/发出跨链消息）。应用侧调用 **MOS.transferOut** 写入跨链意图，并产生可证明的链上日志。
- **Relay 链验证源链事件**：
    - Messenger 从源链节点取到**收据+MPT 证明+区块头**；
    - 把证明提交给 **Relay 链上该源链的轻客户端**（统一由 **LightClientManager** 管理）；
    - 通过后，在 Relay 链上形成“**已验证的跨链消息承诺**”。
- **目标链只验证 Relay**：
    - 在目标链，**MAPO 轻客户端（MAPO-on-Target）**验证“这条消息已被 Relay 链最终确认”；
    - 目标链上的 MOS/应用合约据此**执行实际动作**（释放/铸造/回调业务逻辑）。

### 一句话总结

**Relay Chain**= “把多对多跨链验证，转成到一条带最终性的公共验证层上”。**MAPO**中，体现在**“Relay 链上托管各链LC + 各链上托管 Relay 的LC”**的双向嵌入：**验证集中、信任最小、集成成本低**；业务只需面向 Relay 的结论再在目标链执行即可

# Message bridge和Asset bridge

**Message bridge**

![截屏2025-10-27_17.22.25.png](https://img.learnblockchain.cn/attachments/2025/10/smLnZerJ69006d6b1db6b.png)

- 做什么：在链 A 产生一段**可验证**的 message/intent，让链 B 在**本链共识下**执行对应逻辑（调用合约、更新状态、触发回调）。
    
![截屏2025-10-27_17.05.45.png](https://img.learnblockchain.cn/attachments/2025/10/pCmLSQM769006d7206261.png)
    
- 不做什么：**不直接托管或铸造资产**，也**不承担供给一致性**职责。
    
![截屏2025-10-27_17.07.04.png](https://img.learnblockchain.cn/attachments/2025/10/BJQvlu1t69006d7f347a9.png)
    
- 关注点：verification（谁证明消息正确）、ordering（顺序/幂等）、replay protection、finality/challenge。
- 一句话：**只搬“指令/事实”，不搬“价值本体”。**

**Asset bridge**

- 做什么：让同一经济实体跨域“可达”，必须定义**供给与赎回语义**：
    - **Lock–Mint**：源链锁（custody），目标链铸“映射资产”（wrapped）。
    - **Burn–Mint**：源链销毁，目标链铸“原生资产”（canonical，多链原生发行）。
    - **Liquidity model**：两侧做市/库存对冲，“到手即有”，更像结算网络。
- 必做的：**供应一致性**（1:1）、**赎回路径**、失败补偿与恢复。
- 一句话：**搬“value”，必须对总量与赎回负责。**

> 快速判别：谁能 mint/burn？谁在 custody？ 只要桥本身能决定 mint/burn 或托管锁仓，它就是 Asset bridge；反之仅传递“证明/intent”，就是 Message bridge。
>

# Layerzero

是一个跨链消息层，它提供每条链上的Endpoint，并让OApp在每一条路径上米昂自定义Security Stack，选择哪些DVN(Decentralized Verifier Networks)来做验证，以及通过哪个执行者来‘执行/传递’。

Endpoint 负责形成带 **lossless、exactly-once** 语义的消息通道。

## 解决了什么关键问题

- 核心验证问题，因为跨链首先就是要回答“How can Chain B verify an event from Chain A?”，因为区块链彼此不能直接读取对方的状态，所以每一个跨链系统都必须选择一种验证路径，比如多签、ZK proofs等一旦选择了验证方法则会反过来决定接口设计、以及能覆盖哪些链的问题：所选验证法决定 **security model / interface design / execution semantics / chain coverage**。
- 一条链没有办法覆盖所有链，不得不用N个bridge，**N bridges = N integrations**，每条桥接口不兼容，**无法做动态安全选择或汇聚多桥**形成统一抽象。
- 运维复杂度极高：每条桥一套监控、不同错误格式/失败模式，**跨桥追踪一次交易**变成困难的“关联分析”问题。并且**N 个 API、N 套日志/排障工具**，debug难度呈指数级上升。各自独立的升级流程与安全审核，团队被迫同时维护多套系统与知识栈。

### 如何解决

将这些部分进行解耦

![截屏2025-10-27_18.00.56.png](https://img.learnblockchain.cn/attachments/2025/10/caJZdAp569006d8dc86db.png)

![截屏2025-10-27_18.01.38.png](https://img.learnblockchain.cn/attachments/2025/10/z8V4WAcM69006d9344ee1.png)

Layerzero结构

- Endpoint
    - 相当于一个标准的接口来给LZ用户的
    - 不可更改的
    - 每个链上只有一个
    - 用户只会与这个Endpoint打交道
    - 有UA接口
- **UltraLightNode（ULN）**
    - 可升级的合约
    - 有自己的版本号和对应的地址会被endpoiont记录下来
    - 核心的智能和鱼可以emit XCC event和验证XCC proof
- Oracle
    - 获取区块链数据
- Relayer
    - 构造proof，并提交到dst链上的ULN
- VerifyLibrary
    - 不需要完整的知道header就可以知道另一个链上的数据是否有效
    - 数据来自两个链下组件
    - 实现了另一条链的merkle proof的验证逻辑

### 工作流程

- **Send（srt）**：OApp 调用 Endpoint 发送消息，支付费用；Endpoint 为该 path 分配**单调 nonce**并生成 GUID；options中携带所选 **DVN/Executor** 等参数。
- **Verify（dst）**：所选 **DVNs** 各自向目的链的接收库**提交验证**；当达到配置的门限（如 X-of-Y）即视为通过。
- **Commit to channel（目的链 Endpoint）**：任何人可将满足门限的结果**提交到 Endpoint**；Endpoint 记录 **payload-hash**、推进通道状态，确保 **lossless / exactly-once** 与**无缺口有序**。
- **Execute**：**Executor** 付 gas 调用目标 OApp 的receive完成投递；即便 Executor 故障，第三方也可触发执行，**安全与活性分离**。

### 一句话总结

Layerzero v2 = 统一接口(Endpoint) + 可验证和执行的跨链消息层。解决了接口耦合的问题。

Cross chain messaging (2)

Cross chain

跨链是把一条区块链上的“已发生事实”（状态/事件/余额变动等）以可验证的方式带到另一条链上，使后者可以在自身共识下对该事实作出行动（调用合约/铸造或释放资产/更新状态）。本质是在不同安全域之间做可信消息传递与（可选的）资产迁移。

白话文就是

谁来验证“链A发生了X”？他能否说谎？说谎的代价是什么？
这决定了安全模型、成本与延迟。

为何会有跨链的存在呢？

主要在以下几个场景

多链并存和分工：提高效率，也可以通过跨链技术减少重复建设和资源浪费、也可以通过多链分工提高工作效率
资产整合：投资者可能持有不同链上的资产、可以通过跨链将资产整合
提高流动性：讲不通区块链上的资源和流动性链接起来，为用户提供更多的交易和投资选择

跨链需要解决的关键问题

可验证性：假设是a链到b链，如何在b链上的逻辑里面验证a链传过来的内容是否是正确的
最终性与回滚：a链可能短暂重组，需等待最终性或引入挑战期(rainbow bridge引入了挑战期，在四个小时左右)
顺序/重放/幂等：消息序列如何保证有序消费、避免被重复执行或跨域重放。
费用与延迟：验证的成本（链上计算/外部服务）与消息到达、可执行的时间。

主流路线

Light client

通过raibow bridge在链上部署互相的light client，也就是说拿以太坊跟NEAR链举例，如果是以太坊要转资产进NEAR的话，流程架构
1. EthOnNearClient，在NEAR合约里维护以太坊header，他只保存最近一段时间（大概七天）最终已经确定的header，来避免状态(stateles cryptocurrency？)无限膨胀。因此用户需要在这个窗口内完成提交证明
2. prover合约也是部署在NEAR上，拿到以太坊的log、merkle proof等证明来对照EthOnNearClient存储的header，其中含 receiptsRoot），在 NEAR 上验证“ETH 侧真的发生了某事件”
3. Token Locker（ETH ）/ Token Connector（NEAR ）：前者锁定用户的 ERC-20 并产生事件；后者在 NEAR 侧铸造/释放对应的 NEP-141 代表资产。
  流程如下：转 ERC-20 为例
  - 授权 & 锁定（ETH 侧）
    用户先给 TokenLocker approve，随后调用 TokenLocker 把 X 枚 ERC-20 转入托管。合约会在以太坊链上发出 Locked 事件（记录发送者、金额、目标链接收者等）。
  - 等待以太坊最终性
    需等 ETH 区块达到“不可逆”的安全阈值（PoS 下通常取最终确定区块），这样 NEAR 侧验证时不必担心回滚。EthOnNearClient 在 NEAR 上持续接收 ETH 区块头并维护规范链。
  - 生成并提交“事件存在性证明”
    中继/提交者从 ETH 全节点取到这笔锁定交易的收据与日志，连同MPT（收据树）证明与所在区块头（含 receiptsRoot），打包成证明，提交给 NEAR 上的 Prover 合约。
  - NEAR 上链验证（Prover ↔ EthOnNearClient）
  - Prover 调用 EthOnNearClient：确认该区块头在其已跟踪的规范链里；
  - 用区块头里的 receiptsRoot 验证“这条 Locked 事件日志确实包含在该区块的收据树中”；
  - 做去重（双花问题）。
    验证通过，即在 NEAR 侧得到“ETH 上已锁定”的可验证承诺。
    - 在 NEAR 侧铸造/释放代表资产 Token Connector（NEAR）据此给用户铸造/释放等额的 NEP-141（例如 nDAI），完成从 ETH 到 NEAR 的资产映射迁移。用户在 NEAR 钱包中看到余额增加。

一句话总结：

锁（ETH）→ 证（NEAR 上验证“ETH 确实锁了”）→ 铸（NEAR）。轻客户端提供“信区块头”的根，Prover 提供“信事件”的证；NEAR 因此能在不信任第三方的前提下，相信以太坊上真的发生了那件事。

Relay chain

是一条专门用于跨链的“中间链/枢纽链”。它自己跑共识、出块、记账，同时托管和运行多条外部链的轻客户端

把“跨链消息的验证与转发”收束到自己这里来做——再由各业务链只需要验证 Relay Chain 的状态即可完成跨链。这类设计把“谁来证明别的链上发生了什么”集中到了中继链的链上逻辑中。以 MAPO 的表述：底层的 MAP Relay Chain 提供“纯信任最小化的跨链消息验证能力”，其上部署各链的轻客户端；同时，各业务链上也部署 MAPO 的轻客户端 来验证来自 Relay Chain 的消息，实现“双向轻LC的嵌入”。

已经有Light Client，为何还要 Relay Chain？

轻客户端法（LC）通常是“每对链彼此在对方链上部署对方的轻客户端，再在目的链验证源链事件”。这在多链网络里会出现两两对接的 N² 复杂度与在高成本链上做重验证的问题。

Relay Chain 的做法是：

在 Relay Chain 上集中维护“各链轻客户端”，负责对“源链事件”做链上验证；
在各业务链上只部署“Relay Chain 的轻客户端”，这样业务链只需验证“Relay Chain 的结论”即可，不再每对链互相部署。MAP 官方集成文档直说：跨链消息经 map-relay-chain 中转，因此“集成链只需部署 relay-chain 的 light-client 来验证来自 relay 的消息”，自身则实现“自己的轻客户端部署到 relay-chain”。

结果是：

连接复杂度：由“每对链各自对接”降为“每条链对接一次 Relay”（从 N² 降到 ~N）。
验证成本：把多链验证集中到一条可控的链环境（可做预编译/电路优化）以降低目的链上的 gas 压力。
可扩展性：新链入网，只需接入 Relay 的轻客户端体系，就能与已接入的所有链互通。

解决的关键问题

验证发正在链上
双向的LC，可以让任意两条已经接入的链经过relay互通
MAPO使用iBFT和PoS共识，具有及时的区块最终性
使得Dapp可以进行复用

relay chain流程如下

源链产生事件（如锁定资产/发出跨链消息）。应用侧调用 MOS.transferOut 写入跨链意图，并产生可证明的链上日志。
Relay 链验证源链事件：
- Messenger 从源链节点取到收据+MPT 证明+区块头；
- 把证明提交给 Relay 链上该源链的轻客户端（统一由 LightClientManager 管理）；
- 通过后，在 Relay 链上形成“已验证的跨链消息承诺”。
目标链只验证 Relay：
- 在目标链，MAPO 轻客户端（MAPO-on-Target）验证“这条消息已被 Relay 链最终确认”；
- 目标链上的 MOS/应用合约据此执行实际动作（释放/铸造/回调业务逻辑）。

一句话总结

Relay Chain= “把多对多跨链验证，转成到一条带最终性的公共验证层上”。MAPO中，体现在“Relay 链上托管各链LC + 各链上托管 Relay 的LC”的双向嵌入：验证集中、信任最小、集成成本低；业务只需面向 Relay 的结论再在目标链执行即可

Message bridge和Asset bridge

Message bridge

做什么：在链 A 产生一段可验证的 message/intent，让链 B 在本链共识下执行对应逻辑（调用合约、更新状态、触发回调）。

不做什么：不直接托管或铸造资产，也不承担供给一致性职责。

关注点：verification（谁证明消息正确）、ordering（顺序/幂等）、replay protection、finality/challenge。
一句话：只搬“指令/事实”，不搬“价值本体”。

Asset bridge

做什么：让同一经济实体跨域“可达”，必须定义供给与赎回语义：
- Lock–Mint：源链锁（custody），目标链铸“映射资产”（wrapped）。
- Burn–Mint：源链销毁，目标链铸“原生资产”（canonical，多链原生发行）。
- Liquidity model：两侧做市/库存对冲，“到手即有”，更像结算网络。
必做的：供应一致性（1:1）、赎回路径、失败补偿与恢复。
一句话：搬“value”，必须对总量与赎回负责。

快速判别：谁能 mint/burn？谁在 custody？只要桥本身能决定 mint/burn 或托管锁仓，它就是 Asset bridge；反之仅传递“证明/intent”，就是 Message bridge。

Layerzero

Endpoint 负责形成带 lossless、exactly-once 语义的消息通道。

解决了什么关键问题

核心验证问题，因为跨链首先就是要回答“How can Chain B verify an event from Chain A?”，因为区块链彼此不能直接读取对方的状态，所以每一个跨链系统都必须选择一种验证路径，比如多签、ZK proofs等一旦选择了验证方法则会反过来决定接口设计、以及能覆盖哪些链的问题：所选验证法决定 security model / interface design / execution semantics / chain coverage。
一条链没有办法覆盖所有链，不得不用N个bridge，N bridges = N integrations，每条桥接口不兼容，无法做动态安全选择或汇聚多桥形成统一抽象。
运维复杂度极高：每条桥一套监控、不同错误格式/失败模式，跨桥追踪一次交易变成困难的“关联分析”问题。并且N 个 API、N 套日志/排障工具，debug难度呈指数级上升。各自独立的升级流程与安全审核，团队被迫同时维护多套系统与知识栈。

如何解决

将这些部分进行解耦

Layerzero结构

Endpoint
- 相当于一个标准的接口来给LZ用户的
- 不可更改的
- 每个链上只有一个
- 用户只会与这个Endpoint打交道
- 有UA接口
UltraLightNode（ULN）
- 可升级的合约
- 有自己的版本号和对应的地址会被endpoiont记录下来
- 核心的智能和鱼可以emit XCC event和验证XCC proof
Oracle
- 获取区块链数据
Relayer
- 构造proof，并提交到dst链上的ULN
VerifyLibrary
- 不需要完整的知道header就可以知道另一个链上的数据是否有效
- 数据来自两个链下组件
- 实现了另一条链的merkle proof的验证逻辑

工作流程

Send（srt）：OApp 调用 Endpoint 发送消息，支付费用；Endpoint 为该 path 分配单调 nonce并生成 GUID；options中携带所选 DVN/Executor 等参数。
Verify（dst）：所选 DVNs 各自向目的链的接收库提交验证；当达到配置的门限（如 X-of-Y）即视为通过。
Commit to channel（目的链 Endpoint）：任何人可将满足门限的结果提交到 Endpoint；Endpoint 记录 payload-hash、推进通道状态，确保 lossless / exactly-once 与无缺口有序。
Execute：Executor 付 gas 调用目标 OApp 的receive完成投递；即便 Executor 故障，第三方也可触发执行，安全与活性分离。

一句话总结

Layerzero v2 = 统一接口(Endpoint) + 可验证和执行的跨链消息层。解决了接口耦合的问题。

原创
学分: 2
分类: 跨链技术
标签: cross chain 跨链 LayerZero v2

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。

Cross chain 总览

Cross chain messaging (2)

Cross chain

为何会有跨链的存在呢？

跨链需要解决的关键问题

主流路线

Light client

一句话总结：

Relay chain

已经有Light Client，为何还要 Relay Chain？

解决的关键问题

relay chain流程如下

一句话总结

Message bridge和Asset bridge

Layerzero

解决了什么关键问题

如何解决

工作流程

一句话总结

0 条评论

文章目录