引擎架构

​

摘要

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 异步运行时。每位镜像交易员由独立的监督任务服务，每个跟随者订阅是在 Tokio 执行器上协作调度的轻量级任务。引擎在关键路径上不持有任何同步锁——所有状态交接均使用有界 MPSC 通道，背压是显式的。

​

3.2 每交易员并发流水线

每位被跟随的交易员运行三条并发流，除出站信号通道外互不共享： 由于订单簿流和用户账户流是独立的 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. 对比分析

​

5. 运营边界

​

6. 结论

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