高效的流动性资金池, 2019 年 8 月 20 日

为了鼓励有效的交易策略并激励改善市场可执行流动性的行为,BitMEX 将逐步对本平台引入多个交易规则。这些规则专为提升交易所对用户提供的产品和服务的质量而设,是过去几个月中大量研究的成果。这一概念并非新创,事实上现在多数传统交易所都采用了类似的规则。

您可以在我们关于报价成交率门槛值 的 API 公告上对首个交易规则进行更多了解。这一规则旨在减少向市场提交报价但没有交易意图的策略,由此在为其他的市场参与者提供免费的资源之外,增强平台流动性的质量。

我们认为引入这些规则将是推进行业前进的积极举措,我们致力于在这一领域的继续锐意创新。

背景

多年以来,BitMEX 一直是提供加密货币衍生品的最具流动性的市场。市场质量的一个关键指标,就是委托列表上报价的深度和规模:流动性通常由针对要执行的特定规模的价格滑点衡量。Sk3w.co 呈现了对所有各个不同加密货币市场的价格滑点的对比。在下面的示例中,在 BitMEX 执行价值 1000 XBT 的 XBTUSD 产品合约的买卖价差,浮动范围在 0.5% 左右。其他场所的价格滑点从 3% 到超过 15% 不等,相比之下大致高出了 10 倍。

资料来源:https://www.sk3w.co/liquidity

BitMEX 从一开始,就一直通过我们 行业领先的API  提供访问和使用平台的绝佳通道。所有在 BitMEX.com 网站上执行的操作,也可以通过我们的 API 执行。实际上,BitMEX.com 网站界面就是我们公共 API 的客户端。这一开放的方式一直是 BitMEX 成为业内流动性最强的市场的关键因素。

但流动性只有在是真正可执行的流动性的情况下才有用。6 月份,BitMEX 上不到 2% 的活跃用户占处理委托管理请求的 60% 以上,以及交易量不到 2% 。这类行为特定的用户在使用 API 的效率方面极为低下,他们在每份交易合约上提交的委托数量高到不成比例。

导致这种使用 API 的情况有多个原因。我们经常发现已注册在线自动交易服务(或“机器人”)的账户输入其 API 密钥,然后完全忘记了该账户,但同时它每天继续提交/修改/取消数以千计的的委托。另外,有时候它可能是一个配置错误的交易系统或客户算法,有可能报价太宽而很少交易。

这种行为虽然现在并不违反规则,但从真正期望在平台上进行交易的参与者那里抢走了资源。我们认为,阻止这种行为将进一步增强市场的流动性,并为用户提供更良好的整体体验。

如果您还有任何疑问,请使用我们的联系表格与客服联系:https://www.bitmex.com/app/support/contact

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

关于报价成交率门槛值 (2019 年 8 月 20 日)

为了鼓励有效的交易策略并激励改善市场可执行流动性的行为,BitMEX 将引入一些适用于平台所有用户的高级交易规则。 第一个启用的交易规则是报价成交率门槛值

 

报价成交率

我们将报价成交率(QFR)定义为每个历日已成交报价和已提交给平台报价的比例。一个已提交报价是任何已发送到市场的个别委托。一个已成交报价是一个已成交任何金额的委托。QFR 计算如下:

 

在 T 时间段内已成交报价数量 / 在 T 时间段内已提交报价数量

 

其中 T = 24 小时

 

报价成交率示例

做市商在 XBTUSD 上报价一个双边价格并提交一份批量新委托请求,其中包含 4 个竞买和 4 个竞卖并以不同的价格水平存放在列表中。然后,做市商收到价格信号并提交批量修改请求,以将市场中 4 个竞买价格每个下调一个最小价格。

另一个市场参与者提交了一份大型市价买单,该指令解除了做市商在委托列表中所留下的 3 个竞卖。在当天剩余时间内,这两位参与者都没有再报价或交易。

当天该提供市场流动性者的 QFR 计算如下:

  • 已成交报价数量 = 3
  • 已提交报价数量 = 12
  • QFR = 3/12 = 25%

当天该提取流动性者的 QFR 计算如下:

  • 已成交报价数量 = 1
  • 已提交报价数量 = 1
  • QFR = 1/1 = 100%

 

报价成交率门槛值

平台上的账户需要保持其 QFR 的 7 天的移动平均高于最小 QFR 门槛值 。违反此规则将会收到邮件警告并最终被禁用 API。

每天报价少于 2000 个的账户将不受此交易规则的约束。

以下的 QFR 门槛值将从 2019 年 8 月 30 日开始实施:

  • 最小 QFR 门槛值:0.1% ( 7 天的移动平均)

为了引入此交易规则,QFR 门槛值最初将设置为非常低的 0.1%,以尽量减少对用户的影响。相比之下,传统市场通常强制 QFR 在 1 – 5% 的范围内。在 0.1% 的情况下,根据当前平台报价活动,我们估计不到 0.2% 的活跃交易者会受到影响。我们可能会不时更新最小 QFR 的门槛值和/或机制。在任何更改之前,我们会提前在此处作出通知,以确保用户有时间来调整他们的交易行为。

 

 

 

 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

Efficient Liquidity Pools, 20 August 2019

To encourage efficient trading strategies and incentivise behaviours that improve the executable liquidity of the market, BitMEX will be gradually introducing a number of trading rules for the platform. These rules are specifically designed to improve the quality of the exchange offering for users and are the result of a large amount of research over the past few months. This concept is nothing new and indeed most traditional venues employ similar rules.

You can read more about the first Trading Rule to be introduced in our API Announcement on the Quote Fill Ratio Threshold. This rule aims to discourage the use of strategies that submit quotes to the market without the intent to trade and therefore further strengthen the quality of liquidity on the platform in addition to freeing resources for other market participants.

We believe the introduction of these rules to be a positive step forward for the industry and we are committed to continuing innovation in the space.

Background

For many years now, BitMEX has been the most liquid market offering cryptocurrency derivatives. A key indicator of the quality of a market is the depth and size of the quotes in the order book: liquidity is often measured by price slippage for a given volume to execute. Sk3w.co offers a visual comparison of the price slippage across various cryptocurrency markets. In the sample below, the implied bid-offer spread for executing 1000 XBT worth of contracts on BitMEX’s XBTUSD market fluctuates around 0.5%. Compare this with other venues, where price slippage is roughly 10x higher, ranging from 3% to over 15%.

 

Source: https://www.sk3w.co/liquidity

 

Since day 1, BitMEX has provided unprecedented access to the platform through our industry-leading API. Every action that can be performed on the BitMEX.com website, can also be performed via our API. In fact, the BitMEX.com web interface is just a client of our public API. This open approach has been a key contributor to BitMEX becoming the most liquid market in the industry.

Liquidity is only useful however if it is genuinely executable liquidity. In the month of June, fewer than 2% of active users on BitMEX accounted for over 60% of the order management requests processed, and less than 2% of the volume traded. Users fitting this behaviour profile are incredibly inefficient with their use of the API, submitting a disproportionately high number of orders per contracts traded.

There are a number of explanations for this kind of API usage. We often discover accounts that have signed up to an online automated trading service (or “bot”), entered their API keys, and then forgotten entirely about the account whilst it continues to place/amend/cancel thousands of orders every day. Other times, it could be a misconfigured trading system or client algo, which is quoting too wide and very rarely trades.

This kind of behaviour, whilst not currently against the rules, takes resources away from participants genuinely looking to trade on the platform. We believe that discouraging this kind of behaviour will further strengthen the liquidity of the market and provide a better overall experience for users.

If you have any further questions please contact Support via our contact form: https://www.bitmex.com/app/support/contact.

关于拒绝自成交批量委托 (2019 年 8 月 15 日)

从北京时间 2019 年 8 月 19 日中午 12:00 开始,通过 API 提交包含自成交价格的批量委托请求(至少一个等于或高于卖出委托价格的买入委托)将被拒绝。此功能更新是我们的 API 和交易系统架构持续简化的一部分。

 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

BitMEX 技术扩展,第 2 部分: 通往 100 倍之路

本系列的第 1 部分中,我们讲述了 BitMEX 的起源。 

今天,我们将提供本系列的第 2 部分——深入研究过载和水平扩展固有的问题。 我们将讨论迄今为止在处理前所未有的交易量方面所取得的成果,并详细介绍必须保持串行执行的 BitMEX 引擎部分,可并行化的部分,以及 BitMEX 的 API 优先设计的优势。

在第 3 部分中,我们将解释已经制定的代码优化,已并行化的系统,以及为什么某些功能已经被删除。此外,我们将讨论 BitMEX 对公平和平等访问的承诺——以及这如何转变成我们拒绝提供主机代管服务。

让我们进入正题。

增长

BitMEX 在加密货币领域独树一帜。 为了提供业界领先的杠杆和功能,BitMEX 交易引擎从根本上不同于加密货币和传统金融领域中的大多数引擎。 虽然我们能够提供极其准确的交易和保证金,但速度还不是特别快。

在整个 2017 年,BitMEX 的日均交易量增长了 129 倍。 这种增长令人难以置信,并且这种增长在整个 2018 年和 2019 年还在继续。

2016-2018 年每周处理的委托
2018-2019 年每周处理的委托
请注意,此图表从最后一个图表末端的峰值开始。

如上所示,每周委托数额也从 2017 年开始大幅增加。 尤其值得注意的是,尽管委托率较低,但 2018 年 7 月创下了 80 亿美元的历史最高美元交易纪录! 这个记录直到上周,在 2019 年 5 月 11 日才被打破,当时的交易总额为 110 亿美元。 这些记录仍然是加密货币交易所一天交易最多的记录,而比特币/美元永续掉期合约是有史以来交易量最大的加密货币产品。 它自诞生之日起便被其他加密货币交易所争相模仿,无论这些交易所规模如何或处于何种发展阶段。

2018 年 5 月,我们开始集中精力优化交易引擎中的委托取消、修改和下单操作,重做内部数据结构、算法和审计检查,以专门针对 kdb + 提供的速度进行调整。  这项工作需要高度专注,才能使现有的交易引擎继续运行,但性能得以提升。 我们可以非常自豪地宣布,我们的努力让我们在很短的时间内性能提升超过 10 倍,在前 30 天内就达到了 4.6 倍,并且在 8 月底达到了 10 倍。 到 7 月中旬,交易引擎实现的性能提升几乎消除了所有过载,对于我们的技术团队实现这一令人难以置信的成果,我们感到非常自豪。

下方显示过载占所有写入请求的百分比(委托下达、修改、取消)。更多红色=更多过载。

2018 年 5 月 5 日
 2018 年 7 月 16 日

由于容量增加,BitMEX 的交易量大幅上升。 我们在加密货币行业历史上第一个实现 24 小时交易额达百万比特币备用容量使我们能够推出具有创新性的新产品,例如有史以来首个以太坊/美元双币种永续掉期合约,该产品在上架后的 6 周内成为交易排名第一的以太坊/美元产品。 2018 年 11 月,我们在 24 小时内的交易额接近两百万比特币,并在 2019 年 5 月达到了 110 亿美元的交易额。

虽然 7 月的图表似乎完全清晰,但如果仔细观察,就会发现并不那么完美。 为什么不是完全修复好呢? 为什么不继续努力达到 100 倍或以上?

让我们先了解一些背景。

 

排队

BitMEX 上的服务请求类似于在售票柜台排队等候。 您开始排队,然后在轮到您时发出请求。 

那么,买票需要多长时间? 如果不用排队的话,非常快。 整个互动的持续时间就是服务您的个人请求的时间。 这就是为什么一些流量和交易量明显较低的其他交易服务即使最大容量较低也可能感觉很快:这是因为队列中的请求更少。

现在考虑当队列很长时会发生什么情况。 您不仅需要等待处理您的请求,还必须等待在您前面的每个人。 即使您拥有世界上最有效率的职员,如果队列开始形成,平均的体验就会非常糟糕。

有些请求非常简单,因此非常快,但有些请求比较复杂,需要更多时间。 如果可以完全避免请求(例如,用户没有足够的可用余额来完成请求),则可以用优化来确保其甚至不用排队,类似于自动登机柜台和行李办理。

网络服务上的流量运作方式大相径庭。 即使处理单个请求的速度非常快,当单个资源需要排队时,体验也会降低。

大家以前经历过这种情况。 亚马逊和阿里巴巴的假期停工时间很长。 推特有臭名昭著的 “失败鲸”。 许多平台包括 BitMEX,都会不时出现不利的排队行为。

 

过载

“系统过载”,您可能熟识它,它是 BitMEX 解决问题的一种机制。不认同吗? 怎么可能过载是解决方案,而不是问题? 过载是一种防御机制,在业界被称为 “卸载” ,一种在信息系统中使用的技术,通过忽略某些请求来避免系统过载,而不是令到系统崩溃,从而无法满足任何请求。

我们发布了一份文件,显示了关于卸载的明确规则并解释了该机制:

未完成请求队列未满时下单
未完成请求队列已满时下单(过载)

要理解这一点,假设有一个不存在卸载的系统。 随着需求的增加,队列形成并开始增长。

这会发生什么呢? 当市场发生变化时,大批交易者竞相下单以增加或减少其仓位。 有人可能认为这种延迟将会自我调节:随着服务质量的下降,交易者将开始以较慢的速度下单,等待每个委托确认后,下达下一个委托。 但事实恰恰相反:随着响应时间增加,自动套利者无法迅速介入来让现行价格与其他交易所保持一致。 其他感知到定价差异的精明交易者会试图手动交易,这进一步增加了队列的长度。

在没有安全措施的情况下,队列可能会延迟许多分钟。 由于用户无法有效地下达挂单指令,因此委托列表价差会扩大。 当委托实际通过队列并执行时,良好的市场价格变得非常糟糕。 在这种环境下,交易实际上是不可能的。 这不仅仅是假设的;这是其他加密货币市场也面临的一个普遍问题。

BitMEX 的解决方案是限制了排队等待交易引擎的委托管理请求的最大数量。 在交易引擎前面有一个服务,它将请求标识为读取(即数据提取,如 GET / api / v1 /持仓)和写入(例如,委托下达/修改/取消,以及杠杆更改)。 如果是写入,则将其委托给主引擎,并形成队列。 如果此队列太长,您的委托将立即被拒绝,而不是排队等待。 此队列的深度根据引擎性能调整,以将延迟的最差情况限制为延迟 3-5 秒。

根据我们的卸载文件,某些类型的请求(如取消)无论其大小如何都允许进入队列,但它们会像任何其他请求一样排在队列的后面。

结果:交易者立即知道系统正处于滞后状况,而不是在委托排队后才发现,从而需要花费很多秒才能执行。 引擎没有减速:实际上在过载期间,引擎的委托率达到峰值,委托列表和交易的数据源都非常快。

 

过载期间的交易

一些交易者沮丧的认为过载期间交易还是继续的。 事实上,我们已经在推特和交易者聊天室中看到了很多关于这方面的阴谋论,认定有一些交易者有系统访问特权这是无稽之谈:BitMEX 上的每个交易者的访问权限都是平等的并在同一队列的后面排队。 交易引擎始终以尽可能快的速度处理来自队列的请求。

如果进入系统的委托数量是系统可以处理的数量的 5 倍,则只接受 20% 的委托,而 80% 将被拒绝。 至于哪些委托被拒绝以及哪些委托被接受,这只是委托到达时队列中是否有空间的问题。 如果您的请求恰好在响应已送达之后就到达队列,促使队列低于最大深度,则请求将被接受。 在您之后提交的下一个委托又可能不是这种情况。

在交易高峰时段,BitMEX 的委托输入率平均增加 20 至 30 倍! 执行交易达到了超过 1 亿美元/分钟的峰值。 这个速率如果持续,将形成每小时 60 亿美元交易量,或每天超过 1440 亿美元! 这是 BitMEX 或任何其他加密货币平台上历史单日最高交易量记录的 13 倍。

顶部: 总请求数。 紫色= API,蓝色=前端。
底部: 每 10 秒时段被拒绝委托的百分比。 本示例显示出异常高的百分比,表示最坏情况的过载。 实际上,每天提交给 BitMEX 的所有委托中只有 2-3% 会因减载而被拒绝。
市场大幅波动,导致上面显示的委托率大幅上升。

为了始终提供顺畅的交易体验,BitMEX 需要有很大的容量储备来处理这些严峻的事件。 下面,我们将记录我们在实现这一目标时面临的一些挑战。

 

高可扩展性和阿姆达尔定律

如何解决扩展问题? 两种扩展类型:“垂直” 和 “水平”。 垂直扩展能够使单个系统更快。 你可以通过购买更快的处理器(祝你好运;摩尔定律对 CPU 无效),或通过寻找减少工作量的方法来实现这一点。 另一方面,水平扩展是 “投入更多资金” 的类型:启动更多服务器,并在其中分散负载。

Web 服务器是水平可扩展服务的一个很好的例子。 在大多数设计合理的系统中,您可以添加更多 Web 服务器来处理客户需求。 当一个回复不依赖于另一个回复时,服务器并行工作是安全的,例如杂货店的结账员。

这是大规模简化,但对于许多人来说,可扩展性解决方案是更长版本的“在问题上投入资金”。 许多系统是水平扩展的。 大多数客户的体验完全相互独立,只需要更多的 Web 服务器便能为他们提供服务。 支持数据库通常可以水平扩展,将其数据彼此复制。

可以水平扩展的程度有限制,这通常表示为阿姆达尔定律。 简而言之:系统的水平扩展性受到所需的串行操作(或必须在特定序列中发生的操作)的限制。 举例而言:想象您有一个简单的单线程服务,您想通过并行的方式加速运行它,例如通过多个服务器。 通过一些性能分析,您会发现只有 25% 的工作必须按顺序完成。 其余的可以并行完成。 这意味着,无论您为这个问题投入多少核芯或服务器,它都只能加速 4 倍,因为 1/25% = 4。 这一点是串行工作的瓶颈所在。

学习单元: https://learnyousomeerlang.com

这种串行要求是 BitMEX 与大多数一般 Web 服务的巨大差别之处。 BitMEX 交易引擎具有更多的串行要求,从而严重限制了并行化机会。

顺序问题: 委托和重新确定保证金

BitMEX 交易引擎按顺序,先进先出(FIFO)方式处理委托。 就像您最喜爱的有线电视提供商让您等候一样,对交易引擎的调用将按接收顺序进行处理。

这是市场的基本原则,不能改变。 委托列表必须按顺序处理委托——也就是说,顺序很重要。 当下达主动委托时,它会从委托列表中获取流动性,而其他任何委托都不会消耗它。 因此,个别市场的撮合不能有效地分配;但是,撮合可以委托给每个市场的单个进程。

在撰写本文时,BitMEX 运行大约 150 个 API 服务器,直接与引擎前的代理进行通信。 此代理将读取请求委托给数据镜像,将 websocket 数据委托给 pub / sub 系统,和将写入请求直接委托给引擎。

正如您所料,写入是系统中成本最高的部分,也是最难扩展的部分。 为了使交易系统有效运作,必须满足以下条件:

  • 所有参与者必须同时收到相同的市场数据。
  • 任何参与者都可以随时发送写入。
    • 如果此写入有效并更改公共状态,则必须在接受并执行经修改的世界状态后,将其发送给所有参与者。

未经优化,该系统经历二次扩展: 每分钟发送 1 个委托的 100 个用户产生10,000(100 * 100)个市场数据包,每个参与者一个。 增加 10 倍到 1,000 个用户会产生 100 倍的市场数据(1000 x 1000),依此类推。

正如本文开头所提到的,BitMEX 在 2017 年增长了 129 倍。 在此期间,我们的用户群等比扩大。 这意味着,与 2017 年 1 月 1 日相比,在 2017 年 12 月 31 日我们发送的消息大约为 16,641 倍(129 * 129)。

 

系统一致性

扩展 BitMEX 是一项艰巨的任务。 我们不是一般的现货或衍生品平台:我们对整个客户生命周期负责,从注册、到入金到交易。

为了安全地提供 100 倍的杠杆,BitMEX 的系统必须不出错且必须快速。 BitMEX使用合理价格标记,这是一种原始且经常被模仿的系统,通过该系统,合约所依据的现货交易价格的综合指数被用于重新确定用户的保证金,而不是合约的最后交易价格。 这使 得BitMEX 市场更难以通过参考外部流动性来被操纵。

为了使其正常工作,BitMEX 引擎必须保持一致。 每次标记价格变化时,系统会重新确定所有持有未平仓持仓的用户。 此时,整个系统由控制程序审核。 所有未平仓持仓,所有未成交委托和所有剩余保证金的成本必须与所有存款完全相等。 没有一个 satoshi 丢失,否则系统会关闭! 这在我们早期发生过几次;每次是由于加盟收入或费用的一些 satoshis 的舍入误差所致。 虽然试图建立小额资金缓冲来预防误差,但我们的团队认为系统偿付能力才是至关重要:他们以最高的标准来要求自己。 今天,在每次状态出现重大变化后,该系统仍然会审计出一个确切的 satoshi 总和。

在 BitMEX 平台,恶意行为者即便使用数据库访问权限也无法更改自己的余额。:系统会立即识别出资金是无中生有,发出致命错误,并关闭。

在审计之前,必须从头开始重新计算整个帐户的现值;也就是说,以新价格计算所有未平仓持仓和未成交委托的的价值。 这可以确保交易者无法买到他们买不起的东西。 交易者在 BitMEX 的余额不会变为负值。

加速这个系统是我们扩展工作的主要目标之一。 撮合需要相对较少的时间且容易扩展;保证金计算不是。 BitMEX一直致力于“先重优再重速”——因此,这里所需的时间很大程度上归功于做事正确的承诺。 我们对不正确的结果零容忍,因此正确的分配系统必须能够在紧迫的时间预算内检测出缓慢或失败的原因,重新平衡负载,以及完成必要的处理。 这需要仔细且有条不紊的注意力和严格的测试。

我们的工程师已经确定了可以安全地进行优化的几个关键领域,并且正在不懈地努力提供新的,强大的架构,以大幅提高平台的容量。

 

API 优先的设计

BitMEX 在同行中独树一帜:它实施了 API 优先。 BitMEX 架构由三个主要部分组成:交易引擎、API 和 Web 前端。 请注意,我们没有使用术语“这种”前端。 这是为什么呢?

在构建 BitMEX 时,我们希望我们的 API 能够成为同类最佳的。 一个优秀的 API 使开发人员可以轻松构建强大的工具。 它甚至可以实现我们可能从未想象过的替代可视化和界面。 在我们开始编码的时候,加密货币交易 API 还低于次平值。 许多缺少任何规律性、文档或预写入适配器,关键数据经常丢失,重要的功能只能通过网站完成。 更糟糕的是,大多数甚至没有 websocket 数据源,并且很少经常将它们保密,和只能通过网站访问。

 

在 BitMEX ,我们逆市而行,为加密货币交易 API 设立了新标准。 我们通过规定网站必须使用任何其他程序可能使用的 API 来实施深思熟虑的内部测试政策。 这意味着没有 “这种” 前端,只有一个官方的 BitMEX 前端。 BitMEX 网站作为一个项目,除了 API 开发人员和一些登录/注册反滥用机制之外,没有任何特殊访问权限。

 

这也意味着用于访问 BitMEX 的机制没有比其他机制更快或更慢。 所有用户都输入相同的数据路径和相同的队列,无论他们是通过移动设备、浏览器、自定义编写的 API 连接器访问,还是通过 Sierra Chart 的 DTC 集成。 这确保了每个人的公平体验。

从一开始,BitMEX 就有:

  • 所有表格的 websocket 更改数据源,包括委托、交易、委托列表,持仓、保证金、工具等,其中所有表格都遵循相同的格式,
  • 完整记录的 API,既可由人工使用,也可由机器通过 Swagger spec(现在称为 OpenAPI )使用
  • GitHub上的多个示例项目,以及
  • 网站和 API 使用者的统一数据路径。

实时数据

BitMEX 对 API 优先设计的承诺在实时数据的实现中得到体现,这些实时数据通过我们的 websocket 展现。 如上所述,所有表格都有可用的实时数据源,这是加密货币行业中的第一个,在今天非常罕见。 此外,所有表格都遵循相同的格式,这意味着您可以编写少至 30 行代码来处理任何流。 或者,使用我们在 GitHub 的现成品

此数据来自引擎本身生成的变更流,该变更流针对各个用户订阅进行过滤。 当在 BitMEX 上构建接口时,流程可以非常舒适:订阅您的表格,发出请求,并在流上监听变更。 通常,除非是错误,否则可以忽略对 HTTP 请求的响应。 这避免了在必须单独读取和合并 websocket 流和 HTTP 响应的应用程序中的常见二元性,从而导致尴尬的代码和错误。

我们认为,构建顶级应用程序界面的这一理念不仅可以实现最佳的用户空间集成,还可以使 BitMEX 网站和即将推出的移动应用程序发挥最佳能力。

我们的实时数据源对 BitMEX 平台的有序运行至关重要。 为此,我们正在进行该系统的主要内部重,我们期望在不进行外部更改的情况下显着改善延迟和流量。 我们将很快宣布该启动及其结果。

 

下一步

我们希望上述内容让大家了解,BitMEX 在为下一次的 100 倍增长扩展平台时所面临的挑战。 虽然我们为平台的成功感到自豪,并感谢我们的用户,但我们需要不断改进,以便在未来几年能继续独立发展。

BitMEX 交易引擎团队每周多次发布平台更新。  这些增量变化既是交易平台持续长期重新架构的一部分,也是对引擎的战术性适当容量改进。 这些努力、成功和失败将在本系列的第 3 部分中讨论。

我们的引擎团队能够定期对我们系统的流量进行重大升级。 就在最近,2019 年 5 月 23 日团队推动了一项重大的基础架构升级,将新的委托处理容量提升高达 70% 。  这样的重大容量改进将在未来几个月继续实行,而平台的大规模重新架构将同时继续进行。

新委托中位数,平均值和第 99 百分位处理时间。 升级代码大约在协调世界时间 01:20 发布。
取消委托处理时间在第 95 个百分位(对于通过 API 可用的 3 种不同类型的取消操作)

我们在快速扩展我们的交易引擎的同时,我们也在扩展我们的团队。 BitMEX 聘请了世界知名的电子交易系统、扩展、基础架构、安全和网络方面的专家,并为那些热爱学习和吃苦耐劳的人提供初级和中级职位。 如果您对这篇文章感兴趣,您可能就是我们想要招募的人;请查看我们的招贤纳士页面令人心动的职业机会。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

BitMEX Technology Scaling, Part 2: The Road to 100x

In Part 1 of this series, we told stories of the origin of BitMEX.

Today, we’re offering Part 2 of this series – a deep dive into overload and problems inherent to horizontal scaling. We will discuss the results from our efforts so far in handling unprecedented volumes and will detail the parts of the BitMEX engine that must remain serial, the parts that can be parallelised, and the benefits of BitMEX’s API-first design.

In Part 3, we’ll explain code optimizations that have already been put in place, systems that have been parallelised, and why certain features have been removed. Additionally, we’ll talk about BitMEX’s commitment to fair and equal access – and how that translates to our refusal to offer co-location.

Let’s get started.

Growth

BitMEX is a unique platform in the crypto space. In order to offer industry-leading leverage and features, the BitMEX trading engine is fundamentally different than most engines in crypto and in traditional finance. And while we’re able to offer exceptionally accurate trading and margining, it hasn’t been particularly fast – yet.

Throughout 2017, BitMEX’s average daily trading volume grew by 129x. This is incredible growth, and it continued to grow throughout 2018 and 2019.

Orders handled per week, 2016-2018
Orders handled per week, 2018-2019.
Notice that this chart begins at the peak of the last chart’s end.

As you can see above, orders per week have also sharply increased from 2017. Of particular interest is that an all-time USD trading record of $8B was hit in July 2018, despite the lower order rate! This record wasn’t broken until just last week, on 11 May 2019, where $11B was traded. These records still stand for the most ever traded in a day by a crypto exchange, and the XBTUSD Perpetual Swap is the most-traded crypto product ever built. It has since been imitated over a dozen times by crypto exchanges, both aspiring and established.

In May 2018, we began a focused effort to optimize order cancellation, amend, and placement actions in the trading engine, reworking internal data-structures, algorithms and audit checks to tune specifically for the kind of speed kdb+ can offer.  This was a hyper-focused effort to make the existing trading engine continue to do what it does, only a lot faster. We’re very proud to say that this effort yielded us over 10x performance improvement in a very short time, with 4.6x achieved in just the first 30 days, and 10x by the end of August. By mid July, the performance enhancements delivered to the trading engine had resulted in the elimination of virtually all overloads, and we’re very proud of our technology teams for achieving this amazing result.

Below, overloads as a percentage of all write requests (order placement, amend, cancel). More red = more overloads.

5th May, 2018
16th July, 2018

The market reacted to the increased capacity, pushing BitMEX volumes into the stratosphere. We had the crypto industry’s first-ever million bitcoin trading day.  The spare capacity enabled us to continue to launch innovative new products like the first ever ETHUSD quanto perpetual swap, which became the number 1 traded ETHUSD product within 6 weeks of listing. In November 2018, we nearly touched two million bitcoin in 24 hours and achieved $11B in trading in May 2019.

While the July graph looks completely clear, if you’re reading this, you know that it didn’t stay that way. Why isn’t it completely fixed? Why haven’t we simply continued that effort to get to 100x and beyond?

Let’s get into some background.

Queuing

Servicing requests on BitMEX is analogous to waiting in line at a ticket counter. You join the queue, and when the queue clears, you make your request.

How long does it take to buy a ticket? Well, if there’s no queue, it’s going to be very quick. The entire interaction lasts only as long as it takes to service your individual request. This is why some other trading services, which have significantly lower traffic and volume, may feel snappier even if their maximum capacity is lower: there are fewer requests in the queue.

Consider what happens when the queue is very long. Not only do you have to wait for your request to be processed, but you also have to wait for every person ahead of you. You could have the world’s most efficient clerks, but if a queue starts forming, the average experience is going to be very poor.

Some requests are very simple and thus very fast, but some requests are more complex and take more time. If a request can be avoided altogether (say, the user doesn’t have enough available balance to complete it), optimisations can be employed to ensure it never even joins the queue, similar to automated check-in counters and bag drops.

Traffic on a web service behaves in many of the same ways. Even when processing an individual request is very fast, when a queue forms for a single resource, the experience degrades.

You’ve seen this before. Amazon and Alibaba have had major downtime on holidays. Twitter had the infamous failwhale. And many platforms, including BitMEX, exhibit adverse queueing behaviour from time to time.

Overload

“System Overload”, as you might know it, is one mechanism we at BitMEX use to address this problem. Are you shaking your head? How could overload be the solution, not the problem? Overload is a defence mechanism, better known in the industry as “load shedding,” a technique used in information systems to avoid system overload by ignoring some requests rather than crashing a system and making it fail to serve any request.

We’ve published a document showing the definitive rules around load shedding and explaining the mechanism:

Placing an order when the queue of outstanding requests is not full
Placing an order when the queue of outstanding requests is full (overload)

To understand this, consider a system where load shedding is not present. With increasing demand, a queue forms and begins to grow.

How bad can it get? When the market moves, giant swarms of traders race to place orders to increase or decrease their position. One might think that the delay would regulate itself: as service quality decreases, traders will start placing orders at a slower pace, waiting for each one to confirm before placing the next. But in fact the opposite happens: as response time increases, automated arbitrageurs are unable to step in quickly to keep the prevailing price in line with other exchanges. Other savvy traders attempt to manually trade the perceived difference in pricing, which further escalates the size of the queue.

Without safeguards, the queue can reach delays of many minutes. Orderbook spreads increase as users fail to effectively place resting orders. A great market price becomes a terrible one by the time an order actually makes it through the queue and executes. In this environment, trading is effectively impossible. This isn’t just hypothetical; it is a common issue also faced by other crypto markets.

BitMEX’s solution to this is to limit the maximum number of order management requests that can be in queue for the trading engine. There is a service in front of the trading engine that identifies requests as reads (i.e. data fetches, like GET /api/v1/position) and writes (e.g. order placement/amend/cancel, and leverage changes). If it is a write, it is delegated to the main engine, and a queue forms. If this queue gets too long, your order will be refused immediately, rather than waiting through the queue. The depth of this queue is tuned to engine performance to cap latency at a worst-case latency of 3-5 seconds.

As per our Load Shedding documentation, certain types of requests like cancels are allowed to enter the queue no matter its size, but they enter at the back of the queue, like any other request.

The result: traders know immediately that the system is experiencing lags, rather than finding out after the order is in the queue, taking many seconds to execute. The engine isn’t slowing down: in fact, during overload, the engine reaches a peak order rate, and the orderbook and trade feeds move very quickly.

Trading During Overload

Some traders have expressed frustration that trading continues during overload. In fact, we’ve seen many conspiracy theories on Twitter and in trader chat rooms about it, arguing that this must be because certain traders have unequal access to the system. That is fundamentally untrue: every single trader on BitMEX has equal access and enters the back of the same queue. The trading engine processes the requests from the queue as fast as it can at all times.

If the number of orders entering the system is 5 times what the system can handle, only 20% of orders will be accepted and 80% will be rejected. As to which orders are rejected and which are accepted, it is simply whether there is space in the queue at the moment when the order arrives. If your request happens to hit the queue just after a response has been served, bringing the queue below the maximum depth, it will be accepted. The next order submitted after yours may not be.

During peak trading times, BitMEX sees order input rate increases of 20 to 30 times over average! Executed trades have reached peaks of over $100M/minute. This rate, if sustained, would lead to $6B trading volume per hour, or over $144B per day! This is 13x the top volume ever recorded in a single day on BitMEX, or on any other crypto platform.

Top: Total request counts. Purple = API, Blue = Frontend.
Bottom: Percentage of orders rejected per 10-second slice. This example shows an unusually high percentage, indicating a worst-case overload. In practice, only 2-3% of all orders submitted to BitMEX per day are rejected by load shedding.
Sharp market movement, causing the large increase in order rate shown above.

In order to always provide a smooth trading experience, BitMEX needs to have a large reserve of capacity to handle these intense events. Below, we’ll document some of the challenges we’ve faced in achieving this goal.

High Scalability & Amdahl’s Law

How do scaling problems get solved? There are two types of scaling: “vertical”, and “horizontal”. Scaling vertically involves making an individual system faster. You can do this by buying a faster processor (good luck; Moore’s Law for CPUs is dead), or by finding ways to do less work. On the other hand, scaling horizontally is of the “throw more money at it” variety: spin up more servers, and spread the load among them.

Web servers are a good example of a horizontally-scalable service. In most properly-architected systems, you can add more web servers to handle customer demand. When one reply does not depend upon another, it is safe for servers to work in parallel, like check-out clerks at a grocery store.

This is a massive simplification, but for many, the scalability solution is a longer version of “throw money at the problem”. Many systems scale horizontally. Most customers’ experiences are completely independent of one another, and can simply be served by more web servers. The backing databases often can be scaled horizontally, replicating their data to one another.

There’s a limit to how much horizontal scaling is possible, which is often expressed as Amdahl’s Law. In short: a system’s horizontal scalability is limited by the serial operations (or the operations that must happen in a specific sequence) required. To illustrate: imagine a simple, single-threaded service you want to speed up by running it in parallel e.g. through multiple servers. Through some performance analysis, you find that only 25% of the work must be done in-order. The rest can be done in parallel. This means that, no matter how many cores or servers you throw at the problem, it can only be sped up by 4x, as 1/25% = 4. That bit of serial work becomes the bottleneck.

Credit: https://learnyousomeerlang.com

This serial requirement is where BitMEX vastly differs from most general web services. The BitMEX trading engine has far more serial requirements, thereby seriously limiting parallelisation opportunities.

Sequential Problems: Orders and Re-margining

The BitMEX trading engine processes orders in a sequential, First-In-First-Out (FIFO) fashion. Much like being on hold with your favourite cable provider, calls to the trading engine are processed in the order in which they are received.

This is a fundamental principle to a market and cannot be changed. Orderbooks must have orders applied to them sequentially – that is, the ordering matters. When an aggressive order is placed, it takes liquidity out of the book and no other order may consume it. For this reason, matching on an individual market cannot be effectively distributed; however, matching may be delegated to a single process per market.

At the time of writing, BitMEX operates approximately 150 API servers talking directly to a proxy in front of the engine. This proxy delegates read requests to data mirrors, websocket data to the pub/sub system, and write requests directly to the engine.

Writes are, as you might expect, the most expensive part of the system and the most difficult to scale. In order for a trading system to work effectively, the following must be true:

  • All participants must receive the same market data at the same time.
  • Any participant may send a write at any time.
    • If this write is valid and changes public state, the modified world state must be sent to all participants after it is accepted and executed.

Unoptimised, this system undergoes quadratic scaling: 100 users sending 1 order each per minute generates 10,000 (100 * 100) market data packets, one for each participant. A 10x increase to 1,000 users generates 100x the market data (1000 x 1000), and so on.

As mentioned at the beginning of this article, BitMEX grew 129x in 2017. During that time, our user-base scaled proportionally. This means that, on December 31, 2017, compared to January 1 2017, we were sending roughly 16,641x (129 * 129) more messages.

System Consistency

Scaling BitMEX is a difficult undertaking. We aren’t a typical spot or derivatives platform: we handle the entire customer lifecycle, from sign-up, to deposit, to trading.

In order to offer 100x leverage safely, BitMEX’s systems must be correct and they must be fast. BitMEX uses Fair Price Marking, an original and often imitated system by which composite indices of spot exchange prices underlying a contract are used to re-margin users, rather than the last traded price of the contract. This makes BitMEX markets much more difficult to manipulate by referencing external liquidity.

In order for this to work properly, the BitMEX engine must be consistent. Upon every mark price change, the system re-margins all users with open positions. At this time, the entirety of the system is audited by a control routine. The cost of all open positions, all open orders, and all leftover margin must be exactly equal to all deposits. Not a single satoshi goes missing, or the system shuts down! This happened a few times in our early days; each time due to a few satoshis’ rounding error on affiliate revenue or fees. While there was temptation to build in a small buffer of funds in case of error, our team believes system solvency to be paramount: they hold themselves to the highest possible standard. The system still audits to an exact satoshi sum today after every major change in state.

It is not possible for a malicious actor with database access on BitMEX to simply edit his or her balance: the system would immediately recognise that money had appeared from nowhere, emit a fatal error, and shut off.

Before auditing, the current value of your entire account must be recalculated from scratch; that is, the value of all your open positions and open orders at the new price. This ensures traders are not able to buy what they cannot afford. Traders don’t reach negative balances on BitMEX.

Speeding up this system is one of the primary goals of our scaling effort. Matching takes comparatively little time and scales easily; margining does not. BitMEX has always strived for “correct first, fast later” – and thus, the time this has taken is largely due to our commitment to getting it right. Incorrect results are not tolerable, and therefore a correctly distributed system must be able to detect slow or failed producers, rebalance load, and complete essential processing within a tight time budget. This requires careful, methodical attention and rigorous testing.

Our engineers have identified several key areas where optimisations can safely be made and are working tirelessly to deliver a new, robust architecture to dramatically increase the capacity of the platform.

API-First Design

BitMEX is rather unique among its peers: it was implemented API-first. The BitMEX architecture is comprised of three main parts: the trading engine, the API, and a web frontend. Notice that we didn’t use the term “the” frontend. Why is that?

When building BitMEX, we wanted our API to be best-in-class. A great API makes it easy for developers to build robust tools. It even enables alternate visualizations and interfaces that we may never have imagined. At the time we began coding, it was generous to say that crypto trading APIs were less than subpar. Many were missing any semblance of regularity, documentation or pre-written adapters, critical data was often missing, and vital functions could only be done via the website. Worse yet, most didn’t even have websocket feeds, and the few that did often kept them private and only accessible via the website.

At BitMEX we bucked the trend and set a new standard for crypto trading APIs. We engaged in a deliberate policy of dogfooding, by stipulating that the website must use the API as any other program might use it. This means there is not “the” frontend, there is simply an official BitMEX frontend. The BitMEX website, as a project, has no special access other than the ear of the API developers and a few login/registration anti-abuse mechanisms.

This also means that no mechanism for accessing BitMEX is faster or slower than another. All users enter the same data path and the same queues, whether they are accessing via a mobile device, a browser, a custom-written API connector, or even through Sierra Chart’s DTC integration. This ensures a fair experience for everyone.

From the beginning, BitMEX had:

  • A websocket change feed for all tables, including orders, trades, orderbook, positions, margin, instruments, and more, where all tables follow the same format,
  • A fully documented API, both usable by humans and by machines via the Swagger spec (now referred to as OpenAPI),
  • Multiple example projects on GitHub, and
  • A unified data path for both website and API consumers.

Real-Time Data

BitMEX’s commitment to API-first design shines in its implementation of real-time data, which is exposed through our websocket. As mentioned above, all tables have real-time feeds available, a first in the crypto industry and extremely rare today. Additionally, all tables follow the same formatting, meaning you can write as little as 30 lines of code to be able to process any stream. Or, use one of ours off-the-shelf from GitHub.

This data flows from a change stream generated by the engine itself, which is filtered for individual user subscriptions. This allows for a very comfortable flow when building interfaces on top of BitMEX: subscribe to your tables, make requests, and listen on the stream for changes. Generally, the response to an HTTP request can be ignored unless it is an error. This avoids a common duality in applications where both websocket streams & HTTP responses must be read separately and coalesced, resulting in awkward code and bugs.

We believe that this philosophy of building a top-tier application interface not only makes for the best userland integrations, it makes the BitMEX website and upcoming mobile apps the best they can be.

Our real-time feeds are of paramount importance to the orderly functioning of the BitMEX platform. To that end, we are staging a major internal rework of this system that we expect to improve latency and throughput significantly, without external changes. We will announce that launch and its results soon.

Next Steps

We hope the above has given all of you an idea of the challenges BitMEX faces while scaling the platform for the next 100x growth. While we are proud of the platform’s success and thankful to our users, we need to continue to improve in order to be viable in the years to come.

The BitMEX Trading Engine Team releases updates to the platform multiple times per week.  These incremental changes are both part of the ongoing longer term re-architecture of the trading platform as well as tactical in-place capacity improvements to the engine. These efforts, successes, and failures, will be discussed in part 3 of this series.

Our Engine Team has been able to deliver major upgrades to our system’s throughput on a regular cadence. Just recently, on 23 May 2019, the team pushed through a major infrastructure upgrade that increased the new order handling capacity by up to 70%.  Significant capacity improvements like these will continue to be delivered over the coming months whilst the larger scale re-architecture of the platform continues in parallel.

New order median, mean, and 99%-ile processing time. Upgraded code was launched at roughly 01:20 UTC.
Cancel order processing times at 95%-ile (for the 3 different types of cancel operation available via the API)

While work proceeds quickly on scaling our trading engine, we are also scaling our teams. BitMEX employs both world-renowned experts in electronic trading systems, scaling, infrastructure, security, and web, and has junior and intermediate roles for people who aren’t afraid to learn and get their hands dirty. If this article interests you, you might be the kind of person we want on our team; take a look at the exciting opportunities on our Careers Page.

关于 2019 年第二季度季度期货上架

于 2019 年 3 月 15 日,BitMEX 将上架新的季度期货。

有关 2019 年第二季度当前和即将上架的期货合约的上架日期和结算日期,请参阅下表。粗体显示的是新合约。

 

代码 货币对 上架日期 结算日期
ADAH19 卡尔达诺 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
ADAM19 卡尔达诺 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
BCHH19 比特币现金 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
BCHM19 比特币现金 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
EOSH19 EOS 代币 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
EOSM19 EOS 代币 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
ETHH19 以太币 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
ETHM19 以太币 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
LTCH19 莱特币 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
LTCM19 莱特币 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
TRXH19 波场币 / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
TRXM19 波场币 / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
XRPH19 瑞波币代币 (XRP) / 比特币  2018 年 12 月 17 日   2019 年 3 月 29 日 
XRPM19 瑞波币代币 (XRP) / 比特币  2019 年 3 月 15 日   2019 年 6 月 28 日 
XBTH19 比特币 / 美元  2018 年 9 月 26 日   2019 年 3 月 29 日 
XBTM19 比特币 / 美元  2018 年 12 月 17 日   2019 年 6 月 28 日 
XBTU19 比特币 / 美元  2019 年 3 月 15 日   2019 年 9 月 27 日 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

关于批量委托请求功能的更新

从北京时间 2 月 20 日中午 12:00 开始,系统将不再允许通过 API 提交的批量委托请求中的市价委托。 这包括使用 ordType = Market 提交的委托和隐性的市价委托(提交但没有价格的委托)。 在此之后,在批量委托请求中包含市价委托将导致整个请求被拒绝。 此功能更新是我们的 API 和交易系统架构的持续简化的一部分。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

不再支持 MarketWithLeftoverAsLimit 委托

随着我们不断简化 API 和交易系统架构, 在北京时间 2019 年 2 月 8 日星期五中午 12:00 后,系统将不再支持下列委托:
  • MarketWithLeftoverAsLimit
在此时间之后使用 MarketWithLeftoverAsLimit 字段提交的委托将被拒绝。此外,任何未成交的委托将在上述截止日期不久后自动取消。因此,请确保更新所有使用该委托的交易策略来面对该变更。

 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

Websocket API 内部更新公告

为了提高平台的容量,系统将在北京时间 2019 年 1 月 17 日午夜 00:00 进行 Websocket API 的预定更新。
对于此更改,交易系统没有计划的停机时间。但请注意在Websocket数据源上发布的变化预计会在午夜 00:00 时受到短暂的中断。在此之后不久,所有 WebSocket 连接都将被强制断开,以确保在重新连接时没有任何 WebSocket 客户端会留下不一致的委托,仓位或公共委托列表。 否则,此更改应对用户透明。

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

不再支持条件委托

随着我们的不断简化 API 和交易系统架构,北京时间 2018 年 11 月 10 日星期六晚上 20:00  后,系统将不再支持下列委托:

 

  • OCO: One Cancels the Other
  • OTO: One Triggers the Other
  • OUOA: One Updates the Other Absolute
  • OUOP: One Updates the Other Proportional

 

在此时间之后使用 contingencyType 字段提交的委托将被拒绝。此外,任何未成交的条件委托将在上述截止日期不久后自动取消。因此,请确保更新所有使用该委托的交易策略来面对该变更。

 

 

 

 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)

不再支持 SimpleOrderQty 功能

自北京时间 2018 年 10 月 26 日星期五早上 08:00 起, BitMEX 将不再支持使用 simpleOrderQty 字段提交的委托。在此时点后使用 simpleOrderQty 字段提交的所有委托都将被拒绝。目前使用 simpleOrderQty 提交的委托将在上述时间节点后不久自动取消。

 

另请注意,在接下来的几周内,通过 Websocket API 的更新或 GET 的请求发送到 REST API ,以下字段将返回 null 值:

 

  • 仓位:simpleQty,simpleCost,simpleValue,simplePnl,simplePnlPcnt
  • 委托:simpleOrderQty,simpleLeavesQty,simpleCumQty
  • 执行:simpleOrderQty,simpleLeavesQty,simpleCumQty

 

这些字段也可能在将来完全被删除。在从该模式中完全删除字段之前,我们将另发声明。我们强烈建议 API 用户在上述截止日期之前更新使用这些字段的任何客户端,以避免任何交易中断。

 

 

 

欢迎转载,请注明文章来自

BitMEX (www.bitmex.com)