跳转到主要内容
本页面解释 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 路由时：
  1. 路由引擎识别需要哪些协议和操作
  2. eDSL 将这些交互表达为类型化程序
  3. 编译器将此程序转换为链上 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 的关键安全功能之一是执行前模拟。在返回报价之前，后端：
  1. 模拟完整执行路径 使用当前链状态的分叉
  2. 验证所有步骤成功 — 代币兑换、授权、存款
  3. 计算确切输出金额 — 用户将收到的估计金库代币
  4. 检测潜在失败 — 流动性不足、不兼容的代币、协议特定问题
如果模拟失败，API 返回错误而不是会在链上回滚的交易。这保护用户免于在失败交易上浪费 gas。

​
Composer 作为 LI.FI 工具

在 LI.FI 架构中，Composer 被分类为工具 — 类似于跨链桥和 DEX 聚合器如何是工具。这意味着：
  • Composer 路由与跨链桥和兑换路由一起出现在 API 响应中
  • 当 Composer 是最优路径时，路由引擎自动选择它
  • 与任何 LI.FI 工具一样，集成商可以使用 allowTools / denyTools 来包含或排除 Composer 从他们的路由偏好中

​
下一步

API 集成指南

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

跨链模式

了解如何组合跨链 DeFi 操作

错误处理

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

支持的协议

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