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

白话文就是

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

主要在以下几个场景

1. 多链并存和分工：提高效率，也可以通过跨链技术减少重复建设和资源浪费、也可以通过多链分工提高工作效率

2. 资产整合：投资者可能持有不同链上的资产、可以通过跨链将资产整合

3. 提高流动性：讲不通区块链上的资源和流动性链接起来，为用户提供更多的交易和投资选择

• 可验证性：假设是a链到b链，如何在b链上的逻辑里面验证a链传过来的内容是否是正确的

• 最终性与回滚：a链可能短暂重组，需等待最终性或引入挑战期(rainbow bridge引入了挑战期，在四个小时左右)

• 顺序/重放/幂等：消息序列如何保证有序消费、避免被重复执行或跨域重放。

• 费用与延迟：验证的成本（链上计算/外部服务）与消息到达、可执行的时间。

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 侧真的发生了某事件”

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 钱包中看到余额增加。

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

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

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

轻客户端法（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可以进行复用

• 源链产生事件（如锁定资产/发出跨链消息）。应用侧调用 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

• 做什么：在链 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。

是一个跨链消息层，它提供每条链上的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难度呈指数级上升。各自独立的升级流程与安全审核，团队被迫同时维护多套系统与知识栈。

将这些部分进行解耦

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) + 可验证和执行的跨链消息层。解决了接口耦合的问题。

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

白话文就是

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

主要在以下几个场景

1. 多链并存和分工：提高效率，也可以通过跨链技术减少重复建设和资源浪费、也可以通过多链分工提高工作效率

2. 资产整合：投资者可能持有不同链上的资产、可以通过跨链将资产整合

3. 提高流动性：讲不通区块链上的资源和流动性链接起来，为用户提供更多的交易和投资选择

• 可验证性：假设是a链到b链，如何在b链上的逻辑里面验证a链传过来的内容是否是正确的

• 最终性与回滚：a链可能短暂重组，需等待最终性或引入挑战期(rainbow bridge引入了挑战期，在四个小时左右)

• 顺序/重放/幂等：消息序列如何保证有序消费、避免被重复执行或跨域重放。

• 费用与延迟：验证的成本（链上计算/外部服务）与消息到达、可执行的时间。

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 侧真的发生了某事件”

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 钱包中看到余额增加。

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

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

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

轻客户端法（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可以进行复用

• 源链产生事件（如锁定资产/发出跨链消息）。应用侧调用 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

• 做什么：在链 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。

是一个跨链消息层，它提供每条链上的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难度呈指数级上升。各自独立的升级流程与安全审核，团队被迫同时维护多套系统与知识栈。

将这些部分进行解耦

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) + 可验证和执行的跨链消息层。解决了接口耦合的问题。