LayerZero《Building Omnichain Apps》知识体系

来源：LayerZero 开发者生态负责人 Matt（@unkrakable）在 Ethereum Engineering Group Meetup #60 的演讲《Building Omnichain Apps —— Omnichain Messaging Protocol》，配套幻灯片约 30+ 页。 说明：本文严格按课件的讲解脉络组织，忠实还原每页要点，并在必要处补全技术细节与背景（补充部分会标注），使之成为一套可对照学习、逻辑自洽的知识体系。主题即视频标题所指的"LayerZero V2 模块化跨链安全"。

---

目录 #

• 第一部分　问题的提出：为什么跨链这么难
• 第二部分　单体桥安全（Monolithic Bridge）及其致命风险
• 第三部分　LayerZero 的设计哲学：三原则与三层协议栈
• 第四部分　不可变的 Endpoint 与验证/执行架构
• 第五部分　模块化安全栈：X of Y of N 与 DVN
• 第六部分　应用层：OApp / OFT 的编解码与安全
• 第七部分　七大自定义配置（工程落地的旋钮）
• 第八部分　技术栈全景与生态
• 第九部分　一体化知识图 · 术语表 · 学习延伸

---

第一部分　问题的提出：为什么跨链这么难 #

1.1 跨链现实：速度、成本、安全的三角权衡（课件 "Cross-Chain Reality"） #

课件用一句话点题：开发者和用户始终在"速度 / 成本 / 安全"三者之间做权衡，取决于每个应用的具体场景。

• 速度（Speed）：以 Solana、高性能 L1/L2 为代表。
• 成本（Cost）：以 Optimism、Arbitrum、Polygon 等 L2 为代表，低 gas。
• 安全（Security）：以 Bitcoin、Ethereum 为代表，最强共识但相对慢/贵。

核心洞见（贯穿全篇）：不存在一条链、也不存在一套安全模型能同时满足所有需求。既然应用被迫要在多链间取舍，就需要一种能"按场景可配置"的跨链方案——这正是 LayerZero 的立意起点。

1.2 多链已成常态（课件数据页） #

课件引用 2023 年数据：34% 的开源加密开发者在一条以上的链上工作。部署分布为：单链 65.8%、两链 16.4%、三链 6.4%、四链 3.3%、五链及以上 8.2%。

结论：开发者主动向新链扩张，以解锁新用例、新用户群和新机会。多链/全链是趋势，而非可选项——这奠定了对跨链基础设施的刚性需求。

1.3 先看简单情形：单链上的代币转账如何工作（课件 "How Token Transfers Work"） #

在单条链（如以太坊）上，ERC-20 转账本质是账本上两行余额的增减：

// 发送方账户被扣减
_balances[from] = fromBalance - amount;   // -100
// 接收方账户被记入
_balances[to] += amount;                  // +100

关键点：发送与接收发生在同一个账本、同一次原子交易里，天然一致、无需信任第三方。这是理解跨链困难的对照基准。

1.4 跨链转账的根本困难（课件 "How Cross-Chain Transfers Work"） #

现在把场景换成两条互相隔离的链，各自有一份 ERC-20。用户在 A 链发起 Transfer()（扣掉 100），但 B 链上什么也不会自动发生——B 链的合约看不到 A 链的状态。要在 B 链 Receive()（记入 100），就必须有人"告诉"B 链："A 链确实扣了 100"。

这一步"跨链告知"就是全部风险的来源：B 链凭什么相信这条消息是真的？

1.5 最致命的风险：没有可信验证 = 无限铸造（课件 "infinite mint" 页） #

课件用一个刺眼的画面说明后果：如果 B 链在没有可靠验证的情况下，谁都能反复调用 Receive()，那么接收方余额会被灌成 +100000000000000000000000…——凭空无限铸造代币。跨链桥被盗的经典剧本正是如此。

因此，跨链协议真正要解决的核心命题是：如何让目标链只在"源链事件真实发生"时、且"恰好一次"地执行 mint/credit。 这把问题从"如何搬运资产"升华为"如何可信地验证一条跨链消息"。

---

第二部分　单体桥安全（Monolithic Bridge）及其致命风险 #

2.1 单体安全模型（课件 "How Monolithic Bridge Security Works"） #

传统跨链桥采用单体（monolithic）安全：由一组固定的验证者（课件画成一个圆圈里的几个勾）统一负责所有消息的验证。正常时，它们签名放行，B 链据此 mint。

2.2 一旦被攻破 = 存亡级灾难（课件红叉页 + Exploit 页） #

问题在于：这组验证者是唯一的信任点，也是唯一的攻击面。 一旦：

• 验证者集体作恶，或
• 被恶意攻击者（Malicious actor）攻破，

攻击者就能伪造"源链已扣款"的消息，在 B 链无限 mint 整片 ERC-20（课件画成攻击者一次 Exploit 后，目标链铺满伪造代币）。

2.3 血淋淋的数据（课件 "Monolithic Risks"，来源 rekt.news/leaderboard） #

课件列出行业史上五大漏洞造成的资金损失：约 -$624M、-$611M、-$586M、-$477M、-$326M，并强调：五大加密漏洞中有 4 起与单体桥安全相关。

补充背景：这几起通常对应 Ronin、Poly Network、BNB Bridge、Wormhole、Nomad 等历史级跨链桥事件，共同点几乎都是"验证权过度集中于少数签名者/单一模型"。这正是 LayerZero 要用模块化安全来规避的。

2.4 隐喻：从"黑暗森林"到"黑暗海洋"（课件 "Dark Forest / Dark Ocean"） #

• "如果说以太坊是一片黑暗森林……"：单链上已充满 MEV/抢跑等掠食者（借用经典 "Dark Forest" 比喻）。
• "跨链则是一片黑暗海洋"：多条链像散落的岛屿，各有自己的 ERC-20。桥就是连接岛屿的港口与航道。
• 存亡级威胁有两种形态：
  1. 恶意："如果恶意者控制了港口和所有航道，岛屿面临存亡威胁。"
  2. 意外："如果一个中心化实体不小心摧毁了港口，岛屿同样面临存亡威胁。"

隐喻的落点：跨链的安全既要防作恶，也要防单点故障/中心化脆弱性。 解法必须去中心化、抗审查、且不可被单方破坏——引出下一部分的三原则。

---

第三部分　LayerZero 的设计哲学：三原则与三层协议栈 #

3.1 一个全球账本的三原则（课件 "A Global Ledger"） #

LayerZero 把目标定为构建一个连接所有链的"全球账本"，遵循三条原则：

1. Principle 1：Permissionless（无需许可）——任何人都能接入、运行验证/执行角色、部署应用。
2. Principle 2：Censorship Resistant（抗审查）——没有任何单点能阻止合法消息的最终投递。
3. Principle 3：Immutable（不可变）——核心协议合约一经部署不可更改，安全与可组合性不因升级而漂移。

这三条直接回应了第二部分"黑暗海洋"的两类威胁：无需许可 + 抗审查对抗"恶意控制港口"，不可变对抗"意外摧毁港口"。

3.2 全链协议栈：三个层次（课件 "Omnichain Protocol Stack"） #

LayerZero 把能力分成自上而下三层，每层职责清晰：

① Omnichain Messaging（全链消息层）

确保"信息可以被验证为确实来自某条特定区块链"。 LayerZero 允许应用层自行选择：BLOCK CONFIRMATIONS（区块确认数）、REQUIRED VERIFIERS（必选验证者）、OPTIONAL VERIFIERS（可选验证者）、以及判定消息为 Verified 所需的 THRESHOLD（门槛）。 —— 这就是后面 X of Y of N 安全模型的来源。

② Omnichain Function Calls（全链函数调用层）

在链间执行函数调用。应用控制 GAS LIMIT、MSG.VALUE、执行顺序，以及使用哪个 Executor。 LayerZero Executor 在源链收取对应目标链 gas 的费用，并自动完成目标链的调用。

③ Omnichain Applications（全链应用层）

由跨链运行的应用组成。LayerZero 的合约库提供通用标准：OApp、OFT、ONFT，让复杂应用的构建更简单。

补充：三层的对应实现——消息层=Endpoint + MessageLib + DVN；函数调用层=Executor + lzReceive/lzCompose；应用层=OApp(BYTES)/OFT(ERC-20)/ONFT(ERC-721)。

---

第四部分　不可变的 Endpoint 与验证/执行架构 #

4.1 Endpoint 的定义与不可变性（课件 "Immutable LayerZero Endpoint"） #

LayerZero Endpoint 是一份不可变的智能合约，实现了发送、接收、配置消息的标准接口。其不可变性确保协议的可组合性与安全性不会因接口更新而改变。

Endpoint 部署在每条支持的链上，是应用与协议交互的统一入口（_lzSend 发、_lzReceive 收、setConfig 配）。

4.2 两大层次：执行层 vs 验证层（课件右侧架构图） #

课件的架构图把 Endpoint 上下分成两层，这是理解 V2"解耦"的关键：

Execution Layer（执行层 / Transport）

• 参与者：OAPP、EXECUTOR(S)（标注 Permissionless）。
• 接口：_lzSend（发送入口）、_lzReceive（接收执行入口）。
• 职责：负责消息的发送触发与目标链上的实际执行。

Verification Layer（验证层）

• 接口：_send、_commitVerified。
• 组成：MessageLib Registry（追加式）、Security Stack (DVNs)。
• 流程：emit（源链发出待验证消息）→ DVN verify（各自验证）→ _commitVerified（满足门槛后提交）。

要点：执行与验证被彻底分开——验证由 DVN 承担、执行由 Executor 承担，二者互不干涉。这带来后文反复出现的安全隔离与活性保证。

4.3 Endpoint 内部三大组件（课件架构图内框） #

不可变的 Endpoint 内部含三块：

1. LOSSLESS CHANNEL（无损通道）：负责 nonce 管理与"恰好一次（exactly-once）"投递，防重放、防遗漏、防通道被单条失败卡死。
2. OAPP CONFIG（应用配置）：存储每个 OApp 选择的安全/执行配置（DVN、门槛、库、Executor 等）。
3. MESSAGELIB MANAGER（消息库管理器）：管理该 OApp 当前启用的消息库版本。

4.4 可追加的消息库（课件 "Appendable Message Libraries"） #

MessageLib Registry 是一个"只增不改（append-only）"的智能合约集合，控制着 OApp 的配置接口与消息验证。只有 OApp 自己能强制启用某个特定的 Message Library。

设计意图（课件原话精髓）：保证应用永远不会被自上而下强推新的协议代码；同时又允许既有 OApp 主动升级到新的配置。

• 配置方式：endpoint.setConfig(bytes _config)。
• 注册表中并存多套库，分别对应不同的验证模型：
  • 新模型：Security Stack (DVNs) + Executor（V2 的验证/执行分离范式）。
  • 旧模型：Oracle + Relayer（V1 的传统范式）。

准确性补充（重要）：LayerZero 生产环境中，V1 的默认库是 ULN 301（对应 Oracle + Relayer），V2 的默认库是 ULN 302（对应 DVNs + Executor）。课件中以 "ULN" 版本框示意"注册表可并存多库、由 OApp 自选"这一点即可，具体版本号以官方文档为准。核心不变：库不可变、可追加、由应用选择。

---

第五部分　模块化安全栈：X of Y of N 与 DVN #

这是"模块化跨链安全"的心脏，对应第三部分消息层里"应用可选 Required/Optional/Threshold"的落地。

5.1 应用自选的安全参数 #

回到消息层给应用的四个旋钮：

• Block Confirmations：等待源链多少个区块确认后再验证（抗重组）。
• Required Verifiers（X）：必选 DVN，每一个都必须通过。
• Optional Verifiers（N） 与 Threshold（Y）：从 N 个可选 DVN 中，至少 Y 个通过。

一条消息被判定为 Verified 的充要条件：所有 X 个必选 DVN 通过，且可选池 N 中至少 Y 个通过。 这就是 X of Y of N 模型（例如 "1 of 3 of 5"）。

补充：必选 DVN 具有事实上的否决权——任一必选不通过，消息无法验证。应用据此把"绝对信任的验证者"放进必选位，其余用可选池平衡成本与冗余。

5.2 什么可以成为 DVN（课件 "What Can Be A Decentralized Verifier Network"） #

DVN 的精髓是验证方式无限可插拔。课件列出的现成 DVN 及其"类型"生动展示了这种多样性：

含义：从 ZK 证明、轻客户端、地理分散验证者，到 Web2 巨头、预言机、第三方桥，都能作为 DVN 插入并自由组合。应用因此能针对不同价值、不同风险偏好，"搭配"出最合适的信任组合。

5.3 隔离性：一条路径被攻破，不殃及其他（课件 "Omnichain Transfers Simplified" 多链页） #

课件用多链图展示：即使某一条路径所用的 DVN 集合被攻破（画成红叉），其他路径与其他应用的安全配置完全不受影响——因为每个 OApp / 每条路径的 Security Stack 是独立选择、独立生效的。这与"单体桥一处失守、全盘皆输"形成鲜明对比。

---

第六部分　应用层：OApp / OFT 的编解码与安全 #

6.1 一切皆 BYTES：OApp 发送（课件 "Omnichain Applications"） #

每个 Omnichain Application 都以 BYTES 的格式发送消息；进阶应用需要深入理解字节操作与 abi.encode 的工作方式。

发送入口 _lzSend 的签名（课件原文）：

_lzSend(
    uint32 _dstEid,            // 目标 Endpoint ID
    bytes _message,           // 编码后的消息负载（BYTES）
    bytes _options,           // 执行选项（gas、value 等）
    MessagingFee _fee,        // 费用（原生币 + 可选 ZRO）
    address _refundAddress    // 多余费用退款地址
) internal virtual returns (MessagingReceipt receipt);

6.2 接收解码：OApp 接收与 OFT 的 MSGCODEC（课件接收页） #

接收时，目标应用需要知道如何解码 BYTES。以 OFT 为例，它定义了一个 MSGCODEC 库，用于从编码消息中"切分（splice）"出各数据类型。

接收入口 _lzReceive 的签名（课件原文）：

function _lzReceive(
    Origin calldata _origin,  // 来源信息（srcEid、sender、nonce）
    bytes32 _guid,            // 全局唯一消息 ID
    bytes calldata message,   // 消息负载
    address,                  // 该 OApp 配置的 Executor
    bytes calldata            // Executor 传入的额外数据
) internal override {}

6.3 应用层安全：peers 映射（课件 "Application Layer Security"） #

即便协议层验证无误，应用层还要确保消息只在"可信对端"之间收发。LayerZero 通过 peers 映射实现双向校验：

接收侧（ILayerZeroReceiver 接口内的检查）：

function setPeer(uint32 _eid, bytes32 _peer) public virtual onlyOwner {
    peers[_eid] = _peer;
    emit PeerSet(_eid, _peer);
}
// 投递前校验：来源必须与登记的对端一致
function allowInitializePath(Origin calldata origin) public view virtual returns (bool) {
    return peers[origin.srcEid] == origin.sender;
}

发送侧（_lzSend 接口内的检查）：发送前通过 _getPeerOrRevert(_dstEid) 确认目标链已登记可信对端，否则回滚。

含义：peers 是应用层的"白名单锚"，防止消息被发往/伪装成错误的合约。配错 setPeer 是应用层最常见的安全隐患之一（协议安全 ≠ 应用安全）。

6.4 OFT 全链转账的简化视图（课件 "Omnichain Transfers Simplified"） #

OFT（Omnichain Fungible Token，ERC-20 的全链扩展）把跨链转账抽象为源链 _debit、目标链 _credit 两步，中间经由 LZ Endpoint + Security Stack：

// 源链：扣减发送者余额
_debit(
    uint256 _amountLD,     // 转账数量（Local Decimals，本地精度）
    uint256 _minAmountLD,  // 可接受的最小到账（滑点保护/精度截断下限）
    uint32  _dstEid        // 目标 Endpoint ID
);

// 目标链：记入接收者余额
_credit(
    address _to,           // 接收地址
    uint256 _amountLD,     // 到账数量（本地精度）
    uint32  _srcEid        // 来源 Endpoint ID
);

补充要点：

• LD = Local Decimals（本地精度）。不同链上代币小数位可能不同，OFT 用 sharedDecimals（共享精度）做归一，_amountLD/_minAmountLD 是各链本地精度下的量。超出共享精度的部分成为"尘埃（dust）"退还发送者。
• OFT 的本质是源链 burn、目标链 mint（对无法改造的老 ERC-20 则用 OFTAdapter：源链锁仓、目标链铸造），从而维持全局统一供应量、消除包装资产风险。

---

第七部分　七大自定义配置（工程落地的旋钮） #

课件用 "Custom Configurations" 一节，把应用可调的所有能力做成一个索引菜单。这是把前面理念转化为可操作参数的落点，逐一梳理：

① Block Confirmations（区块确认数） #

发送后等待源链达到指定确认数再进入验证，降低链重组（reorg）带来的伪最终性风险。

实践建议：以太坊主网建议 15+，Arbitrum/Base/Optimism 等 L2 建议 5+。

② Modular Security Stack（模块化安全栈） #

即第五部分的 X of Y of N：自选必选/可选 DVN 与门槛，按价值与风险定制信任强度。

③ Modular Message Executor（模块化执行器） #

课件区分两种执行方式：

• Automatic Execution（自动执行）：OApp Sender → Endpoint；Executor → Endpoint → OApp Receiver，由 Executor 自动在目标链调用。
• Manual Execution（手动执行）：无 Executor 自动触发，由用户/任意地址自行在目标链完成执行（消息已验证即可，任何人可推）。

意义：Executor 是 permissionless 且可替换的；即便所选 Executor 失效，也能退回手动执行，保证活性。

④ Execution Gas Settings（执行 gas 选项） #

通过 _options 精细指定目标链的 gas 行为，课件给出三种：

• .lzReceiveOption(gas, msg.value)：为调用 OApp 的 _lzReceive 指定 gas 与附带原生币。
• .lzComposeOption(index, gas, msg.value)：为 lzReceive 之后执行目标合约的 lzCompose 指定 gas。
• .nativeDropOption(amount, receiver)：向目标链上的某合约或 EOA 空投一笔原生 gas（方便收款方后续有 gas 可用）。

常见坑：gas 给太低，Executor 会在目标链 out-of-gas，消息虽已验证但执行失败。

⑤ Strict Nonce Ordering（严格 nonce 顺序） #

课件用两组对照说明：

• Unordered Delivery（无序投递，默认）：nonce 1 成功、nonce 2 失败，不影响 nonce 3、4 继续独立成功。吞吐最高。
• Ordered Delivery（有序投递，可选）：nonce 2 失败，则 nonce 2、3、4 全部被阻塞，严格按序。适合状态敏感场景（如账务同步）。

底层机制：借助 Lazy Inbound Nonce（惰性入站 nonce） 实现"无序但无遗漏、恰好一次"。

⑥ Max Message Size（最大消息大小） #

限制 _lzSend(_message) / _lzReceive(_message) 的负载上限，防止过大消息带来的 gas/DoS 风险。

⑦ Message Composability（消息可组合性） #

课件示例：接收 OFT 转账（OFT _lzReceive）→ 把 OFT 兑换成 ERC20（App 1 lzCompose）。

• 机制：lzReceive 完成交付后，经 LZ Endpoint 用 lzCompose 把后续动作封装为独立步骤触发（横向可组合 horizontal composability）。
• 好处：后续外部调用与"接收回执逻辑"隔离，后续失败不阻塞原消息投递；可无限串联（A→B→C…）。

---

第八部分　技术栈全景与生态 #

8.1 Omnichain Technology Stack（课件全景页） #

课件用一张分层总表把全部内容收束为四层 + 一列可调项：

一句话概括：任意链之上，Endpoint 做消息层，合约标准做应用层，所有安全/执行细节都由应用通过自定义配置掌控。

8.2 生态与覆盖（课件 Partner Ecosystem / Seamless Connection 页） #

• 金融服务：JP Morgan Onyx、WisdomTree、Apollo、Republic Crypto、Aave 等。
• 企业：Japan Open Chain、Google、Sony、Hedera、BCW 等。
• 稳定币：USDe（Ethena）、USDV、PYUSD、crvUSD、AUSD、M^0 等。
• 代币桥：Stargate、Aptos Bridge、Decent、BTC.b、Scroll、LI.FI、Socket 等。
• 游戏：Gunzilla、Shrapnel、XAI、Nine Chronicles、Tiltyard、Heroes of Mavia、Portal、AMGI 等。
• DeFi：Uniswap、Curve、PancakeSwap、Venus、Radiant、Trader Joe、Ethena、Angle、Abracadabra、Balancer 等。
• 网络覆盖：连接大量公链（Public Networks）与部分私有链（Private Networks），主打"无缝连接任意区块链"。

补充（截至 2026 年的公开数据）：LayerZero 已部署在 90–130+ 条链上，累计承载超 2 亿条跨链消息（据 LayerZero Scan）。

---

第九部分　一体化知识图 · 术语表 · 学习延伸 #

9.1 消息完整生命周期（对照课件 Send / Verification / Execution 三页） #

课件最后用三张同构大图分别讲 发送 / 验证 / 执行，串起来即完整生命周期：

flowchart TD
    subgraph A["CHAIN A · 源链"]
        S1["OApp 调用 _lzSend<br/>(message + dstEid + options + fee)"]
        S2["Endpoint 分配 nonce，生成 GUID"]
        S3["源 MessageLib 编码<br/>OApp Send Config: 等待确认数 / 指派 DVN 与 Executor"]
        S1 --> S2 --> S3
    end

    S3 -->|emit 待验证消息| OFFCHAIN["OFF-CHAIN 基础设施"]

    subgraph SEC["模块化安全栈 X of Y of N"]
        D1["必选 DVN (X) 全部验证 payloadHash"]
        D2["可选 DVN 池 (N) 中 ≥ Y 个验证"]
        D1 --> G{"满足门槛?"}
        D2 --> G
    end
    OFFCHAIN --> SEC

    G -->|否| STOP["不投递（任一必选否决 / 门槛不足）"]
    G -->|是| C1["Executor 调 commitVerification → Endpoint 标记 Verified"]

    subgraph B["CHAIN B · 目标链"]
        C1 --> C2["Lossless Channel: Lazy Inbound Nonce 校验（前序均已验证? 恰好一次?）"]
        C2 --> C3["Executor 调 _lzReceive → 交付 OApp（Delivered）"]
        C3 --> C4["可选: lzCompose 触发后续动作（如 OFT→swap）"]
    end

    style SEC fill:#eef,stroke:#66f
    style G fill:#ffe,stroke:#cc0
    style STOP fill:#fdd,stroke:#c33

三条主线（把整份课件收成三句话）：

1. 验证与执行解耦——DVN 验证、Executor 执行，恶意 Executor 无法破坏安全或活性。
2. 安全模块化且按应用可配——X of Y of N + 任意 DVN，告别单体桥"一处失守全盘皆输"。
3. 核心不可变、库可追加、配置在应用手里——Endpoint 不可变保证长期稳定，MessageLib 可追加保证可演进，setConfig/setPeer/options 把主权交给应用。

9.2 术语速查表 #

• Omnichain（全链）：应用/代币原生存在于多链、共享统一状态或供应，而非在孤立链间搬运。
• Endpoint：每链一份的不可变核心合约；含 Lossless Channel、OApp Config、MessageLib Manager。
• Execution Layer / Verification Layer：执行层（_lzSend/_lzReceive + Executor）/ 验证层（_send/_commitVerified + MessageLib + DVN）。
• MessageLib / ULN：消息编解码与验证规则库，追加式、不可改；ULN301≈V1、ULN302≈V2。
• DVN（去中心化验证网络）：验证 payloadHash 的角色，可为 ZK 轻客户端、验证者集、Web2 实体、预言机、第三方桥等任意方案。
• Security Stack：应用为某路径选定的 DVN（含门槛）+ Executor + MessageLib 组合。
• X of Y of N：X 个必选全须通过 + 可选池 N 中至少 Y 个通过，方为 Verified。
• Executor：permissionless 的执行器，在目标链调 _lzReceive，代付 gas；支持自动/手动执行。
• Lossless Channel / Lazy Inbound Nonce：保证恰好一次、无遗漏、抗重放的 nonce 机制。
• OApp / OFT / ONFT：通用消息标准（BYTES）/ 全链同质化代币（ERC-20）/ 全链 NFT（ERC-721）。
• peers / setPeer / getPeerOrRevert / allowInitializePath：应用层可信对端白名单及其收发双向校验。
• _debit / _credit / amountLD / minAmountLD / sharedDecimals：OFT 转账的扣减/记入与精度归一。
• lzReceiveOption / lzComposeOption / nativeDropOption：目标链执行的 gas 与空投选项。
• lzCompose：横向可组合调用，把后续动作封装为独立步骤，隔离失败、可无限串联。

9.3 分角色的学习延伸 #

• 开发者：跑通 OApp/OFT Quickstart；实操 setPeer、DVN/Executor 的 setConfig、quoteSend 费用估算、_options 三种 gas 选项；用 @layerzerolabs/oapp-evm（V2），切勿混用 V1 的 solidity-examples。
• 安全审计：重点审 DVN 独立性（生产环境必选 DVN ≥ 2 且来自不同运营方）、setPeer 配置、lzCompose 中对 composer 地址与 payload 的校验、Owner/Delegate 权限（建议多签）。
• 研究/架构：精读 V2 白皮书的 lossless channel、Sent/Verified/Delivered 状态机与 exactly-once 证明，理解"验证/执行解耦"为何同时改善安全、活性与吞吐。

---

本文严格对照《Building Omnichain Apps》课件逐页整理，并在标注处补充了官方文档级的技术细节与截至 2026 年的背景数据，力求成体系、可落地、科学完整。若需针对其中某一部分（如 X of Y of N 配置脚本、OFT 部署、DVN 自建）展开为动手教程，可在此基础上继续深化。