3.3 Conditional Triggers

在 OES 架构中，状态转移函数 的输入信号 并不局限于简单的资金存取。我们构建了一个模块化的触发器堆栈，支持基于时间、数据和密码学凭证的复杂条件逻辑。

3.3.1 Time-based Triggers

时间是区块链上唯一客观且无需信任的变量。OES 利用以太坊的 block.timestamp 作为不可篡改的时钟源，实现了两类核心逻辑：相对时间锁 (Relative Timelocks) 与 绝对时间窗 (Absolute Time Windows)。

1. 活性保障 (Liveness Guarantees)

为了防止因单方失联导致的资金死锁，协议强制实施基于超时的状态强制流转：

• 卖家超时 (Seller Timeout):

$$Condition: S_{state} = Locked \land t_{now} > T_{deposit} + \Delta t_{delivery}$$

若卖方在 $\Delta t_{delivery}$ 周期内未提交履约证明，买方获得 reclaim() 权限，触发原子退款。

• 自动验收 (Auto-Finalization):

$$Condition: S_{state} = Delivered \land t_{now} > T_{delivery} + \Delta t_{inspection}$$

若买方在冷静期 $\Delta t_{inspection}$ 结束时仍未发起争议，系统假定“默许满意”，允许 Keepers 触发资金释放。

2. 归属权线性释放 (Vesting Logic)

对于服务类或薪酬类担保，OES 支持流支付逻辑：

$$Available(t) = Amount_{total} \times \frac{t_{now} - t_{start}}{t_{end} - t_{start}}$$

这允许资金按区块时间线性解锁，而非一次性交割，降低了买方的预付风险。

---

3.3.2 Oracle-based Triggers (基于预言机的触发器)

这是 OmniPact 实现“现实世界感知”的关键组件。我们深度集成了 Chainlink Functions 和 Automation，将 Web2 API 数据转化为链上可验证的布尔值。

1. 请求-回调模式 (Request-Response Pattern)

OES 不直接发起 HTTP 请求，而是通过去中心化预言机网络 (DON) 代理执行：

1. Request: OES 合约发出事件 OracleRequest(url, query, script)。

2. Consensus: Chainlink DON 节点独立执行 JavaScript 代码（例如查询 FedEx API 物流状态或 FlightAware 航班延误数据），并对结果进行聚合共识。

3. Callback: DON 将共识结果（如 bool isDelivered = true）及其签名写回 OES 的 fulfillRequest() 接口。

2. 数据源验证与多源聚合 (Verification & Aggregation)

为了防止单一 API 源作恶，OES 支持多源聚合策略：

$$Trigger = (\text{API}_A \land \text{API}_B) \lor (\text{API}_C)$$

仅当多个独立数据源（如 DHL + UPS + 本地邮政）交叉验证通过时，才会触发状态的变更。

$$\delta(S_{lock}) \rightarrow S_{del}$$

---

3.3.3 Signature-based Triggers

对于需要人类主观确认的场景，OES 采用了基于 EIP-712 (Typed Structured Data Hashing and Signing) 的多重签名逻辑。这不仅优化了 Gas 成本（链下签名，链上验证），还确保了用户明确知道自己在签署什么内容。

1. 意图验证 (Intent Verification)

所有的手动操作（如 confirmDelivery, cancelOrder）都要求提交符合以下结构的 ECDSA 签名：

Solidity

struct ReleaseIntent {
    bytes32 escrowId;
    uint256 amount;
    string action; // "RELEASE" or "REFUND"
    uint256 nonce;
    uint256 deadline;
}

合约通过 ecrecover 恢复签名者地址，并与 Registry 中的参与者（Buyer/Seller/Arbiter）进行比对。

2. 2-of-3 多签仲裁 (2-of-3 Escrow Multisig)

在某些轻量级模式下（不调用 DAN 网络），OES 可配置为经典的 2/3 多签模式：

• Key A: 买方

• Key B: 卖方

• Key C: 双方共同指定的互信中介（或 DAN 代理）

• 触发逻辑: 资金释放需要 （合作愉快）或 （争议调解）。

这种机制允许双方在不消耗链上 Gas 的情况下进行多次协商，仅在达成最终一致意见时广播一笔交易上链，极大降低了协作成本。

---

OmniPact 在处理复杂商业逻辑时的灵活性：通过时间保证活性，通过预言机连接现实，通过签名锚定人类意图。