deep protocol - dptong.obs.cn-north-4.myhuaweicloud.com

DEEP Protocol 技术白皮书 V1.0

DeepEx [email protected]

Abstract

流动性不足是数字资产交易所面临的最大挑

战，而流动性不足的本质是流动性分散。本文提

出了一个跨交易所流动性共享协议，可以将各个

交易所分散的流动性聚合在一起，从而为交易用

户提供更好的交易深度和最优的成交价格。该协

议通过交易经纪人机制，以去中心化的方式完成

跨交易所流动性共享，不依赖于中心化交易所的

商业授权，具有更好的健壮性。基于该协议，可

以实现跨链、跨交易所、去中心化的新型交易平

台。

DEEP: Decentralized Entrusted Exchange Protocol White Paper V1.0

1 简介

1.1 背景

在数字货币交易所中，影响体验的一个重要因素是流动性不足。流动性不足的本质原因是流动性分散：买家和卖家分布在不同的交易所，而只有在同一个交易所内部的对手单才有可能被撮合，这就导致了在整个市场范围内，有大量的潜在交易无法被满足。

Figure 1: 交易深度

如上图所示，BTC/USDT 交易对的流动性分散在不同的交易所，而且没有哪一个交易所占主导地位。

即使价格匹配，一个 Binance 交易所用户的买单，也无法与一个 Huobi 交易所用户的卖单撮合。因此，如何将分散在不同交易所的流动性进行聚合，是加密货币领域的一个重要课题。

1.2 委托交易

有一些被称为“聚合交易所”的交易平台试图解决这一问题。通常，这些聚合交易所采用委托交易的方式，在其他交易所建立交易商账户，在接到用户的订单后，通过交易所 API，以同样的价格和数量在某个第三方交易所下单。

采用这种委托交易商的模式共享流动性面临如下几个问题：

• 用户资产以中心化形式托管，面临被盗或被挪用的风险；

• 聚合交易所必须在每个第三方交易所都充值足够的交易准备金，才能实现流动性共享。因此，聚合交易所能够接入的第三方交易所数量以及所能实际提供的交易深度均受限于其准备金规模；

• 一旦第三方交易所发生资产安全问题，聚合交易所的准备金将蒙受损失；

• 第三方交易所可以随时阻断聚合交易所的交易账号，导致流动性共享失效；

• 交易所的接入依赖于中心化组织，无法向社区开放。

1.3 去中心化委托交易

为解决这些问题，我们提出了一个新的去中心化委托交易协议。该协议具有以下特性：

• 采用链上结算 + 链下委托交易的方式构建新型去中心化交易所，打破交易所间的流动性壁垒；

https://deepex.org 1


• 用户资产以去中心化方式托管，安全风险低；

• 通过交易经纪人，以去中心化的方式接入第三方交易所，流动性共享难以被人为阻断。聚合交易所的准备金上限等于所有交易经纪人的准备金总和，可以无限扩展；

• 即使第三方交易所发生资产安全问题，损失也将限制在交易经纪人范围内，不会蔓延到用户；

• 第三方交易所的接入可以向社区充分开放。

此外，多交易经纪人模式，还有降低安全风险、提高 API 流量上限、提高交易成功率等优点。

1.4 协议设计难点

由于系统是开放的，交易经纪人可以随时加入或离开，每个交易经纪人的保证金情况也在随时变化，任何委托下单都可能随时失败。

因此，在协议设计时，需要充分考虑的问题包括：如何将订单拆分，并分配给不同的交易经纪人，在不同的第三方交易所下单，以便在确保一定成单概率的前提下，使成交价格最优；如何保管用户和交易经纪人的资产；如何合理的组织订单结构；如何高效追踪订单的状态变化；如何在处理委托下单失败；如何确保订单不会重复执行；如何正确完成订单结算和交易经纪人结算等。

后续的章节将详细论述如何解决这些挑战。

2 协议架构

DEEP 协议 (Decentralized Entrusted Exchange Protocol) 的总体架构如下图所示：

Figure 2: DEEP 协议架构

协议主要由以下几个角色构成：

2.1 客户端

客户端是一个面向终端用户的应用，其交互逻辑类似于数字资产交易所。用户可以像使用普通交易所一样，完成“充值”、“下单”、“提现”等操作。



2.2 跨链结算网络

跨链结算网络是一个区块链账本，用于管理用户和交易经纪人的数字资产，并负责订单成交或撤销后的结算。

这是一个跨链的去中心化网络，由一组公证人（Notary）节点来维护，通过多重签名和智能合约，实现资产的跨链转移。

跨链结算网络将连接多个公链网络，例如比特币、以太坊、莱特币、EOS 等，以支持建立在这些公链之上的代币的充值和提现。

用户通过私钥控制自己在交易所的 IOU，而这些 IOU 所对应的真实资产，必须经过公证人节点的共识才能完成转移。即使少数公证人节点是恶意的，也无法挪用或盗取用户资产。

2.3 中继节点

中继节点是一个链下系统，负责将用户订单进行拆分，转化为一组子订单，通过多个交易经纪人，在不同第三方交易所执行。

多个中继节点可以组成一个中继网络，通过分片的方式进行扩展。与 0x 协议或者路印协议的中继节点不同，DEEP 协议的中继节点不进行本地订单撮合，而是通过委

托交易的方式，将流动性共享给第三方交易所。

2.4 跨交易所网关

跨交易所网关通过 API 连接到多个第三方交易所，获取不同交易所的行情和订单簿信息，并通过交易经纪人的账户，实现跨交易所委托下单。不同的交易所可以通过对应的适配器，将接口转化为统一的协议。这样，无论是下单、撤单、读取行

情还是查询订单状态，其他模块都可以不用关心第三方交易所的接口格式的差异。跨交易所网关会将实时的变更消息（Update Message）推送给其他模块，例如价格变化、订单状态变

化等。如果第三方交易所支持 WebSocket API，可以直接将异步消息转发；如果只支持 REST API，网关会通过轮询（polling）的方式获取最新状态，并与前一次轮询的状态快照进行比较，如有差异，就将变更消息推送到其他模块。

2.5 交易经纪人网关

交易经纪人网关管理交易经纪人的注册信息以及他们在第三方交易所的 API Key 和 API Secret，以便在系统调用跨交易所网关下单/撤单时，完成第三方交易所 API 的签名。

交易经纪人可以是第三方交易所的普通用户。只要申请第三方交易所的 API 权限，任何人都可以成为交易经纪人，赚取委托交易的佣金。

3 核心算法

3.1 订单分配模型

假设某用户提出在不超过 $100 的价位买入 10 个 Token A。订单分配候选方案为：交易所 Ei，交易经纪人 Aj , 下单量为 Vij，（平均）成交价格为 Pij，其中 i= 1, 2, · · · ,m，j=1, 2, · · · , n。需满足以下约束条件：

• 下单量限制 ∑i,j

Vij = 10



• 价格限制Pij ≤ 100

• 交易经纪人准备金余额限制Pij ∗ Vij ≤ Bi,j

其中，Bi,j 是交易经纪人 Aj 在交易所 Ei 中用于可用于买入 Token A 的报价货币余额。

• 成交概率限制Prob(limit_orders_being_executed | bid_price = Pij) > p

• 其他限制因素: 例如交易所 API 访问频次限制、对同一账户自买自卖的限制等。

订单分配策略：首先筛选出满足上述约束条件的候选方案，在剩余方案中选择用户实际支付的总费用最低的一个。

3.2 成交概率估计

我们通过交易所的深度数据 API获取 Token A的订单簿。然而，即使订单簿中存在报价不超过 $100的卖单，并不意味着我们的限价单能与之撮合成功，主要原因在于交易所 API、订单分发系统存在一定的时延。因此，在制定订单分配策略的时候，能否准确预估订单的成交概率，将成为是否按照用户的要求买入足够数量 Token A 的关键因素。

估计成交概率的核心问题在于，能否对短时间内价格的波动做出准确的量化。学术领域对金融市场价格波动的研究主要分为两个流派：

• 传统的计量经济学家采用的概率、随机过程等工具，以价格时间序列为分析对象，代表性成果有Black-Sholes 期权定价公式；

• 经济物理学家以金融市场统计规律的微观机理为目标，对经济个体行为和市场结构进行建模。

由于市场波动存在随机性，这两种方法的表现并没有一个能绝对胜出。因此，在预估成交概率时，我们会综合考虑这两种方法输出的结果，通过强化学习框架动态地优化权重关系，以达到适应市场变化的最优策略。

3.2.1 传统经济学的研究方法

通常假设中间价格服从带漂移项的几何布朗运动，其中漂移速率可能为零。

dSt = µStd + σStdBt

St = Soexp(σBt + (µ− σ2

2)t)

设 {Vt, t ≥ 0} 为几何布朗运动，即Vs = eσ

2νs+σWs

其中，Ws(0) = x。设 Hz = min{s : Vs = z} 为时间序列首次触达 z 的时间，Hz 服从如下的概率分布：

Px(Hz ∈ dt) = | ln(z/x)|σ√2πt

32

(z

x)νexp(−ν2σ2t

2− ln2(z/x)

2σ2t)dt

利用以上结论，可以估算出订单在某时间区间内可被撮合成功的概率。



3.2.2 经济物理学的研究方法

作为一门定量地研究经济问题的学科，经济物理学的思想方法主要来源于统计物理学。通过构建微观经济个体模型，研究金融市场的重要规律及其成因。假设 {Np

t , t ≥ 0} 表示以不高于 p 的价格能够买入 Token A 的数量。时间序列 {Npt , t ≥ 0} 可视为

强度为 λ 的 Poisson 过程：

N0 = 0

P (Nt+s −Ns = n) = e−λt (λt)n

n!

所以，限价单未被撮合成功，或者满足价格要求的卖单与其他用户的买单撮合的概率为：

P (Nt −N0 = 0) = e−λt

为了推导强度 λ 的表达式，需要利用经济物理学中关于金融市场交易统计规律的三个研究成果，即Token A 在交易所 Ei 交易数据的统计规律：

• 交易频数，设为 Λ

• 单次交易量的概率分布，大量研究资料表明，单次交易量服从幂律分布：

fQ(x) ∝ x−1−α, α > 0

• 交易量对价格的影响，即为滑点：

∆p ∝ ln(Q)

∆p = pQ − s

设 δ = p− s 为目标价位与中间价格之间的差异，于是

λ(δ) = ΛP (∆p > δ) = Aexp(−kδ)

其中，A = Λ/α，k = αK。

4 订单

不同于传统的 taker-maker模型，DEEP协议中的订单成交对手来自于多个不同的第三方交易所，因此，我们需要将订单定义为可拆分的递归结构，以便维护委托交易过程中复杂的订单状态变化。

4.1 原子订单 (Atom Order)

不能被拆分的订单称为原子订单。原子订单与第三方交易所订单一一对应。

4.2 聚合订单 (Aggregated Order)

可以被拆分成一个或两个子订单的订单称为聚合订单。聚合订单既可以被拆分为聚合订单，也可以被拆分为原子订单。



4.3 订单树 (OrderTree)

订单树一个二叉树结构，维护拆分出来的父子订单关系。订单树的数据结构定义如下：

s t r u c t Order {// order IdSt r ing id ;// root to the l e f t sub−t r e eOrder l e f t ;// root to the r i g h t sub−t r e eOrder r i g h t ;// order s t a t eint s t a t e ;// t rue − atomic order ; f a l s e − aggrega ted orderboolean atomic ;// t rue − buy order ; f a l s e − s e l l orderboolean sideBuy ;// p r i c e to t radedouble p r i c e ;// t rad ing currencySt r ing tradingCurrency ;// quote currencySt r ing quoteCurrency ;// t rad ing amountdouble amount ;// t rad ing amount executeddouble amountExecuted ;// t rad ing va lue by quote currencydouble value ;// t rad ing va lue executed by quote currencydouble valueExecuted ;

}

订单树的结构如下图所示：



buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

2.0 2.0

broker1 broker2 broker3 broker4

Exchangea Exchangeb

Figure 3: 订单树

在上图的例子中，用户以 8324.15 USD/BTC 的价格，购买 10 BTC，该订单被拆分成 6 BTC 和4 BTC 两个聚合订单。其中，前者又被拆分为 5 BTC 和 1 BTC 的两个原子订单；后者也被拆分为2 BTC 和 2 BTC 的两个原子订单。最终，4 个原子订单将分别由 broker1、broker2、broker3、broker4

四个交易经纪人，在 Exchangea 和 Exchangeb 同时执行。

4.4 订单调度 (Order Dispatching)

根据前文所述算法，将一个聚合订单拆分成一个或多个子订单的过程，称为“订单调度”。订单调度将在中继节点中完成。

例如，下图所示的订单树，一个总量为 10 BTC 的订单，被拆分为三个原子订单，分别由 broker1、broker2、broker3 在 Exchangea、Exchangeb、Exchangec 执行：

buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

broker1 broker2

broker3

Exchangea Exchangeb

Exchangec

Figure 4: 展开前的订单树

如果因为某种原因，4 BTC 的原子订单在 Exchangec 执行失败，那么，该节点将重新变成待分配的聚合订单。中继节点根据订单调度算法，将该订单分成 1 BTC 和 3 BTC 的两个原子订单，分别由broker4、broker5 在 Exchanged 和 Exchangee 执行。此时，订单树的右下节点被展开成为一棵新的子树，如下图所示：



buy,BTC, $8324.15, 10.0

10.0

6.0

5.0 1.0

4.0

1.0 3.0

broker1 broker2 broker4 broker5

Exchangea Exchangeb Exchanged Exchangee

Figure 5: 展开后的订单树

4.5 订单状态

4.5.1 订单状态枚举

订单树中的每个订单都有一个状态，订单状态枚举如下表所示：状态状态名称描述

Pending 等待中订单已提交，等待撮合Partially Filled 部分成交订单部分成交

Filled 已成交订单已完全成交Cancelling 取消中订单正在等待取消Cancelled 已取消订单已取消

Failed 失败订单执行失败

4.5.2 订单状态机

订单在各种状态之间的转换关系，可以用下图所示的订单状态机（Order State Machine）表示：

Pending

PartiallyFilled

Cancelling

Filled

Failed

Cancelled

Figure 6: 订单状态机



4.5.3 父订单状态计算

根据两个子订单的状态，可以计算出父订单的状态。例如：两个子订单，其状态分别为 Filled 和 Failed，则父订单状态为 PartiallyF illed。计算规则详

见附录。

4.6 订单更新

订单更新相当于对订单树进行后序遍历（Postorder Traversal），先计算两个子订单的状态，再计算父订单的状态。

算法伪代码如下：

void updateOrder ( Order root ) {i f ( root == null )

return ;

Order l e f t = l e f t ;Order r i g h t = r i g h t ;

updateOrder ( l e f t ) ;updateOrder ( r i g h t ) ;

i f ( l e f t == null && r i g h t == null )return ;

i f ( l e f t == null ) {root . s t a t e = r i g h t . s t a t e ;root . amountExecuted = r i g h t . amountExecuted ;root . valueExecuted = r i g h t . valueExecuted ;return ;

}i f ( r i g h t == null ) {

root . s t a t e = l e f t . s t a t e ;root . amountExecuted = l e f t . amountExecuted ;root . valueExecuted = l e f t . valueExecuted ;return ;

}

root . s t a t e = getParentState ( l e f t . s ta te , r i g h t . s t a t e ) ;root . amountExecuted = l e f t . amountExecuted + r i g h t . amountExecuted ;root . valueExecuted = l e f t . valueExecuted + r i g h t . valueExecuted ;

}

5 中继节点

在 DEEP 协议中，中继节点是整个系统的核心和枢纽。因此，下面将着重论述中继节点的设计细节。



5.1 中继节点架构设计

中继节点可以划分为以下几个模块：订单簿、订单调度引擎、任务池。同时，它也会和协议的其他组成部分，例如跨链结算网络、跨交易所网关和交易经纪人网关等协同交互。总体架构如下图所示：

Figure 7: 中继系统架构

5.2 中继节点主要模块

5.2.1 订单簿（Order Book）

订单簿负责维护用户的交易订单。与传统的交易所订单簿不同，DEEP 订单簿并不是基于 Taker-Maker模型，不能在本地实现多个对手单的撮合。DEEP中的每一个订单都需要拆分成若干个子订单，通过交易经纪人（broker），在远程交易所完成委托交易。因此，订单簿中的每一个订单，实际上是一个由父子订单组成的树状结构。当子订单的状态发生变化时，可以自底向上（bottom-up）的计算父节点的状态，直到根节点为止。

5.2.2 订单调度引擎（Order Dispatching Engine）

订单调度引擎负责将一个订单拆分成多个订单，以便分配给不同远程交易所中的多个交易经纪人来执行委托交易。订单调度引擎中会保存一份关于远程交易所最近成交价格、当前深度、交易经纪人当前可用余额等“上下文”数据，用于订单调度算法。这份上下文数据由交易所网关模块负责实时更新。

5.2.3 任务池（Task Pool）

任务池负责维护一组任务。每一个任务对应于一个可以在远程交易所执行的订单。每个任务都有独立的状态，两个任务之间没有任何关联。需要注意的是，任务池中的每一个任务，都对应一个订单簿中的原子订单，也就是订单树展开后的一个叶子节点。



5.3 工程实现

5.3.1 模块间通信

为提高性能，各模块间采用异步方式进行通信。在工程实现中，建议采用消息队列。

5.3.2 查询服务（Query Service）

上图只包含协议的核心模块，未将信息聚合及查询服务包含在内。在实践中，建议采用 CQRS（Com-mand Query Responsibility Segregation）模式。前端所展示的价格、深度、订单状态等信息，均通过独立的查询服务来获取数据。

5.3.3 幂等性（idempotency）

大部分模块的实现均需要认真考虑幂等性问题。例如，如果一个订单任务被重复两次发送给远程交易所，将会导致交易经纪人额外成交，即使事后通过执行逆向交易冲正（correct），仍有可能蒙受由价格波动所带来的损失。

6 核心流程

下图是 DEEP 协议的核心流程，描述了协议各模块之间如何交互。

Figure 8: 核心流程

下面我们来解释一下这些流程的细节：

1. 第三方交易所充值: 交易经纪人在第三方交易所充值足量的交易保证金。

2. API 注册: 交易经纪人在第三方交易所申请 API，开通读取和交易权限。并将 API Key 和 APISecret 注册到跨交易所网关中。



3. 委托交易保证金充值: 交易经纪人在 DEEP 聚合交易所充值足量的交易保证金，用于和聚合交易所用户的实时结算。

4. 用户充值: 与普通交易所类似，聚合交易所用户在下单前，也需在聚合交易所中预先存入足额的交易保证金。

5. 用户下单: 聚合交易所用户下单后，订单进入订单簿模块。此时，订单是一个聚合订单，订单树只有一个根节点。

6. 上下文数据更新: 系统通过跨交易所网关模块获取最新的行情和订单信息，实时更新订单调度模块的上下文数据。

7. 用户保证金锁定: 在用户订单被执行之前，系统先尝试锁定订单对应的保证金。例如，若用户请求卖出 1 BTC，在执行前，需成功锁定 1 BTC 的保证金。如因保证金余额不足等原因，导致锁定失败，则订单进入失败状态，不会继续执行。

8. 订单树展开: 系统从订单簿中读取未展开的聚合订单，调用订单调度模块，对聚合订单进行拆分。

9. 订单调度: 根据订单调度算法，订单调度模块将聚合订单分割成多个子订单返回。订单簿根据调度结果，重新构造展开的订单树。

10. 交易经纪人保证金锁定: 系统从订单簿中读取未提交任务的原子订单，依次尝试对交易经纪人的保证金进行锁定。若锁定失败，该原子订单进入失败状态。

11. 提交任务: 对第 10 步中锁定成功的原子订单，在任务池中建立一个任务，用于实际执行委托交易。

12. 任务执行: 任务池模块负责调度任务的执行，针对未执行的任务，调用跨交易所网关模块完成下单。任务池模块必须确保每个任务只会被执行一次。

13. 任务状态更新: 跨交易所网关负责监控远程交易所中的订单执行情况，并实时更新对应任务的状态。

14. 原子订单状态更新: 任务状态更新后，任务池模块向订单簿模块发送消息，更新对应的原子订单状态。

15. 订单树更新: 原子订单状态更新后，该订单树变为“脏”（Dirty）状态，必须自下而上（Bottom-Up）的更新整棵树的状态。

7 附录

7.1 父订单状态计算

Pending Partially Filled Filled Cancelling Cancelled FailedPending Pending

Partially Filled Partially Filled Partially FilledFilled Partially Filled Partially Filled Filled

Cancelling Pending Partially Filled Partially Filled CancellingCancelled Pending Partially Filled Partially Filled Cancelling Cancelled

Failed Pending Partially Filled Partially Filled Cancelling Cancelled Failed


deep protocol - dptong.obs.cn-north-4.myhuaweicloud.com

Documents