跳转到主要内容
LI.FI 意图系统将跨链意图流程的三个组件模块化：
  1. 输入结算器 – 处理源链资金。
  2. 输出结算器 – 处理目标链资金。
  3. 预言机系统 – 使输出结算声明可用于输入结算器。
LI.FI 意图调用图 从历史上看，这些组件一直交织在一起，这带来了扩展挑战。组件化方法允许更大的灵活性和可扩展性，使不同的输入和输出结算方案以及验证层能够混合和匹配。

​
输入结算

输入结算方案管理用户存款，并在意图完成后将资金释放给求解器。LI.FI 意图目前实现了两种输入结算方案： 意图系统对输入结算的实现没有限制。输入结算可以通过调用 efficientRequireProven 通过验证层访问已证明的输出。如果订单包含多个输出，并且输出由不同的求解器填充，则订单规范中第一个输出的填充者被视为规范求解器。 了解有关输入结算的更多信息 →

​
输出结算

输出结算方案处理目标链上的资产交付。它不施加接口要求、订单结构或订单类型，除了必须提供验证有效负载的接口： 
interface IPayloadCreator {
    function arePayloadsValid(
        bytes[] calldata payloads
    ) external view returns (bool);
}
这使得输出结算方案非常灵活；它可以支持任何虚拟机上的任何订单类型，只要填充的订单可以表示为不透明的字节数组。 意图系统的初始版本使用 MandateOutput，编码由 MandateOutputEncodingLib.sol 描述。 如果输入结算可以验证此调用，则可以将输入适当地支付给求解器。但是，此信息仅存在于输出链上的输出结算中。 了解有关输出结算的更多信息 →

​
预言机系统

预言机系统将有效负载从输出链传送到输入链。它充当确认输出交付已发生的桥梁。 只要支持验证来自远程链的有效负载，就可以添加任何验证层。当前可用的验证层包括： 在发出消息之前，预言机应检查一个或多个有效负载是否有效，然后将它们发送到输入链： 
function submit(address proofSource, bytes[] calldata payloads) external payable {
    // 检查有效负载是否有效。
    if (!IPayloadCreator(proofSource).arePayloadsValid(payloads)) revert NotAllPayloadsValid();

    // 有效负载有效。我们可以代表 proofSource 提交它们。
    _submit(proofSource, payloads);
}
预言机可以使用自定义消息编码、自定义中继属性、自定义接口或其他特殊集成问题。内部预言机消息传递未标准化。 在输入链上，预言机系统应通过虚拟机本地哈希验证有效负载： 
interface IValidationLayer {
    /**
     * @notice 检查是否已证明一系列数据。
     * @dev 不返回布尔值；相反，如果为 false，则回滚。
     * 如果 proofSeries 为空，则此函数返回 true。
     * @param proofSeries remoteOracle、remoteChainId 和 dataHash 以 32*4=128 字节的块编码。
     */
    function efficientRequireProven(
        bytes calldata proofSeries
    ) external view;
}
仅使用有效负载哈希使系统更高效，因为传递的数据更少。没有尝试标准化有效负载。因此，输入和输出结算层之间可能存在不兼容性。 了解有关验证层的更多信息 →

​
安全假设

意图系统包括资源锁，它在关键参与者之间创建信任边界：
  • 赞助商（用户）信任仲裁者不会欺诈性地完成已发行的锁。
  • **仲裁者和求解器**信任分配者不会共同签署超过用户存款的重叠锁。
没有单个参与者可以独立访问资金，为跨链交易创建了安全的环境。 有关安全性和意图验证的更多信息，请参阅订单验证 →

​
集成点

LI.FI 意图旨在高度可组合，不同的组件能够根据需要进行交换：
  • 输入结算：可以集成新的资源锁标准和标准意图接口。
  • 输出结算：可以添加新的订单类型和履行机制。
  • 预言机系统：可以支持不同的跨链消息传递协议和证明层。
集成商可以自由选择要用于哪些交换的组件。这为意图发行者提供了最大的灵活性来描述他们所需的最终状态。

​
未解决的问题

虽然初始版本在标准化意图堆栈方面比竞争解决方案有了显著改进，但标准内仍存在互操作性问题。为了透明起见，下面列出了已知的规范问题。

​
标准化消息格式

目前，输入结算方案和输出结算方案必须就订单类型特定的有效负载达成一致。如果新的订单类型或结算系统需要超出已实现消息有效负载的更多功能，则需要重新部署这些组件。这破坏了这些层之间的可组合性。 假设输出描述可以表示为： 
struct OutputDescription {
    bytes32 oracle;
    bytes32 settler;
    uint256 chainId;
    bytes32 token;
    uint256 amount;
    bytes32 recipient;
    bytes call;
    bytes context;
}
建议的消息格式如下： 
编码的 FillDescription
     SOLVER                          0               (32 字节)
     + ORDERID                       32              (32 字节)
     + TIMESTAMP                     64              (4 字节)
     + TOKEN                         68              (32 字节)
     + AMOUNT                        100             (32 字节)
     + RECIPIENT                     132             (32 字节)
     + CALL_LENGTH                   164             (2 字节)
     + CALL                          166             (LENGTH 字节)
     + CONTEXT_LENGTH                166+RC_LENGTH   (2 字节)
     + CONTEXT                       168+RC_LENGTH   (LENGTH 字节)
不对验证层如何在它们之间传递消息做出假设。它们可以随意打包填充描述。打包有效负载的示例。

​
原子交换和 HTLC 作为验证层

HTLC 的工作方式与普通意图方案非常不同，因为它们需要一轮强承诺。这预先烘焙了某些系统假设，这些假设无法通过 OIF 意图系统抽象掉。因此，不考虑这些。

​
集成开销

由于接口和验证层未标准化，每个新的订单类型、验证层或结算方案都会带来额外的集成开销。但是，由于组件被急切地重用，系统复杂性以 O(n) 而不是 O(n^3) 的速度扩展，其中 n 大致是组件的数量。

​
乐观验证层

当前的验证层主要支持显式验证。可以实现乐观验证，但需要每个输出都有链上存储，这会增加 gas 成本。理想情况下，规范应定义一种方法，让一个证明验证多个_订单_，而不仅仅是输出。 这可能涉及使用 Merkle 树或类似的构造来传递已验证的消息
⌘I