Composer 工作原理

本页面解释 LI.FI Composer 的内部架构：多步骤 DeFi 操作如何被编译、模拟并作为单笔交易执行。

架构概览

Composer 将用户的意图（例如，“将 USDC 存入 Base 上的 Morpho”）转换为优化的、可执行的链上交易。系统有三个层次：

┌─────────────────────────────────────────────────────────────┐
│                      LI.FI API 层                        │
│  接收报价/路由请求 → 识别 Composer 路径    │
├─────────────────────────────────────────────────────────────┤
│                   编译器层 (eDSL)                      │
│  在 TypeScript 中表达合约交互 → 编译   │
│  为链上 VM 生成字节码                             │
├─────────────────────────────────────────────────────────────┤
│                   链上 VM (执行引擎)              │
│  执行编译字节码的智能合约，调用    │
│  目标协议在单笔交易中按顺序执行           │
└─────────────────────────────────────────────────────────────┘

核心组件

1. 链上 VM（执行引擎）

链上 VM 是部署在支持的 EVM 链上的智能合约。它作为通用执行引擎，可以：

调用任何其他链上协议或协议系列
将一个步骤的输出作为下一个步骤的输入传递
在步骤之间处理代币授权、转账和余额检查
原子执行整个序列（同链）

VM 接收编译的字节码并在单笔交易中执行它，抽象化了多协议交互的复杂性。 合约地址（Ethereum）： 0xD214A2eB3799076791A4Cde4F0AB184A49dB832d

2. eDSL 和编译器

嵌入式领域特定语言（eDSL）是一个专门构建的语言，用于在 TypeScript 中表达合约交互。当请求 Composer 路由时：

路由引擎识别需要哪些协议和操作
eDSL 将这些交互表达为类型化程序
编译器将此程序转换为链上 VM 可以执行的字节码

这种方法提供了类型安全、可组合性以及在编译时优化执行路径的能力。

3. 动态调用数据注入

许多 DeFi 操作需要来自前一步骤的数据。例如，存入金库需要知道从前一步骤兑换收到的确切代币数量。Composer 通过动态调用数据注入处理这个问题：

编译器识别步骤之间的依赖关系
在执行时，VM 自动拦截已完成步骤的输出
这些输出作为输入注入到后续步骤中
这完全在链上发生，在同一笔交易内

交易生命周期

这是 Composer 交易的完整生命周期，从用户请求到链上执行：

用户请求                    LI.FI 后端                     区块链
     │                               │                                │
     │  1. GET /quote                 │                                │
     │  (toToken = 金库地址)     │                                │
     │──────────────────────────────▶│                                │
     │                               │  2. 路由优化          │
     │                               │  (找到最佳路径)              │
     │                               │                                │
     │                               │  3. eDSL 编译           │
     │                               │  (生成 VM 字节码)        │
     │                               │                                │
     │                               │  4. 执行前模拟   │
     │                               │  (验证路径成功)        │
     │                               │                                │
     │  5. 报价响应             │                                │
     │  (transactionRequest +         │                                │
     │   估计输出)           │                                │
     │◀──────────────────────────────│                                │
     │                               │                                │
     │  6. 用户签署并发送 tx      │                                │
     │──────────────────────────────────────────────────────────────▶│
     │                               │                                │
     │                               │     7. 链上 VM 执行     │
     │                               │     编译字节码：         │
     │                               │     • 兑换代币              │
     │                               │     • 授权金库            │
     │                               │     • 存入金库       │
     │                               │     • 返还金库代币      │
     │                               │                                │
     │  8. 交易已确认      │                                │
     │◀──────────────────────────────────────────────────────────────│
     │                               │                                │
     │  9. GET /status (可选)     │                                │
     │──────────────────────────────▶│                                │

逐步分解

步骤	发生什么	位置
1. 报价请求	开发者请求以金库代币作为 `toToken` 的报价	客户端 → API
2. 路由优化	LI.FI 的路由引擎在 DEX、跨链和协议中找到最优路径	API 后端
3. eDSL 编译	Composer 编译器为链上 VM 生成字节码	API 后端
4. 执行前模拟	完整执行路径被模拟以验证它会成功并估计输出	API 后端
5. 报价响应	API 返回 `transactionRequest`（准备签署的交易）加上估计金额	API → 客户端
6. 交易提交	用户签署并将交易提交到区块链	客户端 → 链
7. 链上执行	链上 VM 执行编译的字节码，原子地执行所有步骤	链上
8. 确认	交易被确认；金库代币在用户钱包中	链 → 客户端
9. 状态检查	可选地轮询 `/status` 进行跨链转账	客户端 → API

同链 vs 跨链

Composer 的行为根据源和目标是否在同一条链上而有所不同。

同链组合

单笔交易
┌──────────────────────────────────────────┐
│  兑换 ETH → USDC (如果需要)             │
│  将 USDC 存入金库                 │
│  接收金库代币                    │
└──────────────────────────────────────────┘
         所有步骤都是原子的
    (要么全部成功，要么全部回滚)

原子执行 — 所有步骤要么都成功，要么都不成功
单次 gas 支付 — 一笔交易费用
即时完成 — 在一个区块中确认
模拟保证 — 如果模拟通过，执行就会成功（除非极端情况如内存池抢跑）

跨链组合

源链                          目标链
┌─────────────────────┐              ┌─────────────────────┐
│  兑换代币         │              │  接收跨链     │
│  跨链到目标      │─── 跨链 ──▶│  代币              │
│  链               │              │  如果需要兑换      │
└─────────────────────┘              │  存入金库  │
                                     │  返还金库代币 │
                                     └─────────────────────┘
   步骤 1：原子                       步骤 2：原子
   (在源链上)                    (在目标链上)

两阶段执行 — 源链交易触发跨链，然后目标链操作执行
每阶段原子性 — 每个阶段在其链内是原子的，但整体流程是最终一致的
跨链延迟 — 总时间取决于使用的跨链桥（秒到分钟）
需要状态跟踪 — 使用 /status 端点监控跨链进度

Composer 本身在单条链上操作。跨链流程是通过将 LI.FI 的跨链路由与 Composer 在目标链上的链上执行相结合来实现的。从开发者的角度来看这是无缝的 — 无论它是同链还是跨链，您都进行相同的 API 调用。

执行前模拟

Composer 的关键安全功能之一是执行前模拟。在返回报价之前，后端：

模拟完整执行路径 使用当前链状态的分叉
验证所有步骤成功 — 代币兑换、授权、存款
计算确切输出金额 — 用户将收到的估计金库代币
检测潜在失败 — 流动性不足、不兼容的代币、协议特定问题

如果模拟失败，API 返回错误而不是会在链上回滚的交易。这保护用户免于在失败交易上浪费 gas。

Composer 作为 LI.FI 工具

在 LI.FI 架构中，Composer 被分类为工具 — 类似于跨链桥和 DEX 聚合器如何是工具。这意味着：

Composer 路由与跨链桥和兑换路由一起出现在 API 响应中
当 Composer 是最优路径时，路由引擎自动选择它
与任何 LI.FI 工具一样，集成商可以使用 allowTools / denyTools 来包含或排除 Composer 从他们的路由偏好中

下一步

API 集成指南

通过 REST API 集成 Composer 的分步指南

跨链模式

了解如何组合跨链 DeFi 操作

错误处理

了解失败模式以及如何处理它们

支持的协议

支持的协议和功能的完整列表

​架构概览

​核心组件

​1. 链上 VM（执行引擎）

​2. eDSL 和编译器

​3. 动态调用数据注入

​交易生命周期

​逐步分解

​同链 vs 跨链

​同链组合

​跨链组合

​执行前模拟

​Composer 作为 LI.FI 工具

​下一步

API 集成指南

跨链模式

错误处理

支持的协议

架构概览

核心组件

1. 链上 VM（执行引擎）

2. eDSL 和编译器

3. 动态调用数据注入

交易生命周期

逐步分解

同链 vs 跨链

同链组合

跨链组合

执行前模拟

Composer 作为 LI.FI 工具

下一步