> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0x.one/llms.txt
> Use this file to discover all available pages before exploring further.

# 引擎架构

> 0x1 基于 Rust 的镜像跟单引擎技术白皮书，对比传统跟单交易系统的串行执行与无界滑点问题。

## 摘要

0x1 运营一套原生 Rust 镜像跟单引擎，专为将镜像交易员的成交结果以亚秒级延迟、有界滑点和账户级风险隔离的方式，复制到异构跟随者账户群而构建。本文档详述该引擎的架构，并与传统跟单交易技术栈所具有的串行执行和无界滑点模式进行对比。以下设计决策——每交易员独立并发流水线、并行扇出、订单簿感知预检，以及非托管 EIP-712 签名——正是 0x1 压缩镜像交易员到跟随者复制窗口、并保留跟随者所期望 PnL 形态的核心机制。

## 1. 问题陈述：传统跟单交易

现有主流跟单交易实现继承了一套并非为高频衍生品场所设计的架构，由此导致的执行问题可归结为四类反复出现的模式。

### 1.1 串行下单

传统系统在单线程循环中逐一遍历跟随者。当镜像交易员成交时，系统枚举 `N` 个跟随者并依次提交订单，每次 HTTP 往返和交易所确认都会阻塞后续推进。在稳态下，第 k 个跟随者的成交时间约为：

$$
t_k \approx t_{\text{leader}} + k \cdot (t_{\text{rtt}} + t_{\text{match}})
$$

对于 `N = 500` 名跟随者、30 ms 往返延迟、10 ms 撮合延迟，最后一位跟随者将在镜像交易员成交后 **20 秒** 才能成交——对于永续合约场所而言，这是一段极其漫长的时间。

### 1.2 无界滑点

由于订单以镜像交易员名义规模定价，并按市价即时提交，后续跟随者会反复穿透自己的订单簿。每次成交都以越来越差的价格消耗流动性，而系统没有任何反馈机制来在实际滑点超出跟随者容忍度时中止扇出。同一笔镜像交易员交易在跟随者间产生的 PnL 分布呈现严重的左偏态。

### 1.3 基于轮询的信号检测

许多系统通过每隔数秒轮询交易所 REST API 来检测镜像交易员活动，而非订阅用户数据流。镜像交易员的成交因此以已过时的时间戳进入复制流水线，进一步加剧了上述排队延迟。

### 1.4 共命运式故障模式

串行循环中的单个格式错误订单、速率限制拦截或 HTTP 超时，都会阻塞其后所有跟随者。不同镜像交易员的流水线之间没有隔离舱，也没有针对单个跟随者的熔断器来防止一个账户的异常状况级联扩散。

## 2. 0x1 引擎：设计目标

0x1 引擎以四项不变量为目标：

| 不变量       | 定义                                  |
| --------- | ----------------------------------- |
| **低复制延迟** | 跟随者成交中位数在镜像交易员成交后一秒内落单。             |
| **有界滑点**  | 所有跟随者的成交均不超出其配置的滑点容忍度。              |
| **比例定仓**  | 跟随者头寸变化量是镜像交易员保证金变化量的固定比例，而非镜像绝对规模。 |
| **故障隔离**  | 任一镜像交易员流水线或任一跟随者账户的故障，不会阻塞其他任何账户。   |

## 3. 架构

### 3.1 运行时

热路径以 Rust 实现，基于 [Tokio](https://tokio.rs) 异步运行时。每位镜像交易员由独立的监督任务服务，每个跟随者订阅是在 Tokio 执行器上协作调度的轻量级任务。引擎在关键路径上不持有任何同步锁——所有状态交接均使用有界 MPSC 通道，背压是显式的。

### 3.2 每交易员并发流水线

每位被跟随的交易员运行三条并发流，除出站信号通道外互不共享：

```mermaid theme={"system"}
flowchart LR
  subgraph Leader pipeline
    OB["Orderbook stream<br/>(WebSocket)"]
    UA["User-account stream<br/>(WebSocket)"]
    EX["Executor task"]
  end
  UA -->|fill event| SG["Signal generator"]
  OB -->|top-of-book| SG
  SG --> RG["Risk guard"]
  RG -->|sized & validated| FA["Parallel fanout"]
  FA -. task .-> F1["Follower A<br/>signer task"]
  FA -. task .-> F2["Follower B<br/>signer task"]
  FA -. task .-> F3["Follower C<br/>signer task"]
```

由于订单簿流和用户账户流是独立的 WebSocket 订阅，镜像交易员成交会通过推送路径而非轮询周期被观测到。信号生成器在 Aster 发布成交的瞬间即产生类型化的 `MirrorIntent`，而无需等待下一个 REST 周期。

### 3.3 并行扇出

扇出步骤以 `FuturesUnordered` 覆盖所有合格跟随者实现。每位跟随者是独立的 Tokio 任务，拥有自己的签名器和到 Aster 的独立出站 HTTP 连接。第 k 个跟随者不再等待第 k-1 个——每次签名、风控检查和下单提交均并发进行。

在串行模型中，最后一位跟随者的延迟随 `N` 线性增长。在 0x1 模型中，延迟随 `N` 对数增长（受调度器和连接池限制），主要由单次 RTT 决定：

$$
t_k \approx t_{\text{leader}} + t_{\text{rtt}} + t_{\text{match}} \quad \forall k \text{（并发上限内）}
$$

### 3.4 订单簿感知预检

在跟随者任务提交前，风控守卫会重新读取当前订单簿快照，并根据跟随者配置的滑点容忍度计算预期成交结果。预计会突破容忍度的订单将被**跳过**，而非发送——跳过操作会以结构化原因码写入跟随者的活动日志。传统模式中 500 名跟随者依次穿透各自订单簿的故障情形不会发生，因为一旦预期标记价格突破界限，该订单就不会被派发。

### 3.5 比例定仓

跟随者规模是跟随者配置的配资与镜像交易员保证金变化量的函数：

$$
\text{size}_{\text{follower}} = \text{size}_{\text{leader}} \cdot \frac{\text{alloc}_{\text{follower}}}{\text{margin}_{\text{leader}}}
$$

受跟随者的杠杆上限和 Aster 最小下单规模的双重约束。引擎不镜像绝对名义价值，而是将镜像交易员风险承诺的形态映射到跟随者的资产负债表上。

### 3.6 非托管签名

引擎在热路径上从不接触跟随者的原始私钥。每位跟随者预置一个代理密钥，用于签署范围限定于交易账户的 EIP-712 ECDSA 载荷；代理密钥在静态时加密存储，并可按需轮换。跟随者同时保留其 Aster 余额和授权代理的主密钥的托管权。

## 4. 对比分析

<Tabs>
  <Tab title="扇出延迟">
    | 属性             | 传统串行                    | 0x1 引擎          |
    | -------------- | ----------------------- | --------------- |
    | 第 k 个跟随者成交     | $O(k \cdot \text{RTT})$ | $O(\text{RTT})$ |
    | N=500 时最后一位跟随者 | ≈ 20 s                  | ≈ 1 s           |
    | 信号检测           | REST 轮询                 | WebSocket 推送    |
  </Tab>

  <Tab title="滑点特征">
    | 属性           | 传统串行  | 0x1 引擎   |
    | ------------ | ----- | -------- |
    | 派发前检查        | 无     | 订单簿重新读取  |
    | 滑点界限         | 隐式，无界 | 每跟随者显式设定 |
    | 后续跟随者 PnL 偏差 | 严重左尾  | 受容忍度限制   |
  </Tab>

  <Tab title="故障隔离">
    | 属性       | 传统串行    | 0x1 引擎  |
    | -------- | ------- | ------- |
    | 跨跟随者阻塞   | 是       | 否（按任务）  |
    | 跨镜像交易员阻塞 | 是（共享循环） | 否（按监督器） |
    | 错误订单遏制   | 整批停滞    | 单一任务失败  |
  </Tab>

  <Tab title="托管">
    | 属性        | 传统串行        | 0x1 引擎       |
    | --------- | ----------- | ------------ |
    | 服务器上的密钥材料 | 明文 / KMS 托管 | 仅加密代理密钥      |
    | 签名范围      | 无范围限定       | EIP-712 范围载荷 |
    | 吊销权       | 平台方         | 跟随者方         |
  </Tab>
</Tabs>

## 5. 运营边界

<AccordionGroup>
  <Accordion title="镜像交易员停止交易">
    监督器不合成退出信号。跟随者的未平仓头寸将持续开放，直至镜像交易员平仓或跟随者从控制台手动平仓。引擎绝不从缺席中推断意图。
  </Accordion>

  <Accordion title="跟随者保证金耗尽">
    风控守卫在任何订单签名前返回 `MarginBreach` 跳过。不会以跟随者名义发出任何加杠杆补充操作。活动日志记录此次突破，包含尝试规模和配置的上限。
  </Accordion>

  <Accordion title="交易所速率限制">
    每个跟随者连接携带独立的令牌桶速率限制器。当某跟随者触达其令牌桶时，仅该跟随者的任务产生背压；其他跟随者和其他镜像交易员不受影响。
  </Accordion>

  <Accordion title="镜像交易员部分成交">
    信号生成器为每次部分成交发出增量 `MirrorIntent` 消息。跟随者定仓规模在每次发出时均根据新的镜像交易员保证金变化量重新计算。
  </Accordion>
</AccordionGroup>

## 6. 结论

传统跟单交易技术栈是批处理、REST 轮询、单线程假设的产物，与现代永续合约场所的要求格格不入。0x1 引擎以推送驱动、每交易员并发、订单簿感知的设计取而代之——增加每位额外跟随者的代价仅为一个任务句柄而非一次 RTT。其结果是一个复制界面，跟随者的实际 PnL 分布以有界、显式的偏差追踪镜像交易员，而任一账户的不良时刻永远不会演变为下一个账户的危机。

<Note>
  引擎为非托管设计。所有跟随者余额均保留在 Aster；所有签名均使用跟随者可随时吊销的跟随者范围代理密钥。
</Note>