如果你对加密货币交易感兴趣，你可能知道服务器位置在交易速度和效率方面可以起到决定性作用。几年前，我尝试了解更多关于这个主题的信息，但当时信息有限。因此，我自己进行了一些研究。随着时间的推移，深入分析的需求变得显而易见，我认为有必要分享这些见解。

我从Binance开始，但我计划很快研究其他交易平台。

研究方法

我使用Hummingbot来运行测试。作为一个包罗万象的开源解决方案，它配备了多个交换连接器。它还易于用户创建加密货币交易机器人，只需一个 Python 脚本即可实现

主要目标不是找到确切的延迟时间，而是确定最佳的AWS区域。为了实现这一目标，我设计了一个简单的Hummingbot脚本，用于比较订单创建、取消和执行的时间持续时间。

1. 时间戳：对于每个订单（无论是创建、取消还是执行），脚本都会记录两个时间戳以及订单ID，保存在CSV文件中。

   • 传输前时间戳：这标志着在API请求发送到交易所之前的时间。

   • 传输后时间戳：这是从交易所收到成功确认的时间。

   By analyzing the difference between the pre-transmission and post-transmission timestamps, one can determine the round-trip time for each order activity.

2. 订单类型和频率：:

   • 限价订单：我测试了每30秒生成一个限价订单的创建和取消。

   • 市价订单：执行是使用每5分钟创建一个市价订单来评估的。

3. Websocket和REST API：像订单创建、取消和执行这样的操作是使用API请求传输的，而确认是通过Hummingbot事件获取的，这些事件依赖于Websocket连接。

AWS设置

我在各个区域设置了相同的t3.small实例，都使用相同的镜像以保持一致性。它们之间唯一的区别是与不同的Binance子账户的连接。这是为了确保在API请求中没有混淆或重叠。

我的测试分为两个阶段：首先进行了一个快速的跨洲测试，然后深入研究表现最佳的地区。

第一个测试在4小时内跨越了8个地区：

• 亚太地区：东京、新加坡

• 欧洲：伦敦、法兰克福

• 北美洲：加拿大

• 南美洲：圣保罗

• 中东：阿联酋

• 非洲：开普敦

以下是特定于订单创建的箱线图结果:

从结果来看，亚洲地区的表现明显优于其他地区。

在此基础上，我决定深入研究亚洲，在七个不同的地区运行服务器：

东京、大阪、首尔、香港、新加坡、孟买、悉尼

这次，机器人运行了整整 24 小时。每个机器人处理约 4000 个限价订单（包括创建和取消），并成功执行约 200 个市价订单。

下面是说明订单创建、取消和执行的箱线图：

附上统计表：

亚洲地区订单创建往返延迟统计：

亚洲地区订单取消往返延迟统计：

亚洲地区订单执行往返延迟统计：

令我惊讶的是，获胜者不是东京，而是大阪。总体而言，首尔有时也表现出比东京更好的结果。我决定再进行一次测试，在另外 24 小时内仅关注这三个区域。结果是一致的：大阪表现更好，而首尔和东京则激烈争夺第二名。

结论

总之，该分析阐明了服务器位置对各个 AWS 区域的币安交易机器人延迟的重大影响。调查结果特别强调了亚洲地区的服务器在订单创建、执行和取消延迟方面的卓越性能，特别是大阪、东京和首尔。对于希望优化交易机器人以实现更快、更高效的订单处理的加密货币交易者来说，这种洞察力至关重要。随着加密货币交易格局的发展，了解不同地区服务器延迟的细微差别对于在市场上获得竞争优势仍然至关重要。

下一步是什么？

接下来，我计划对其他交易所进行类似的测试。我很想知道您希望我探索哪些 请在评论中留下您的建议！此外，任何增强该方法的见解将不胜感激。我始终乐于接受反馈、建设性批评和建议。如果您想聊天甚至快速通话，请随时通过 Discord 与我联系。

资源

https://github.com/supervik/crypto-exchanges-latencies-test/tree/main

原文地址：https://viktoriatsybko.substack.com/p/an-analysis-of-binance-exchange-across

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的Discord 中文频道，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

什么是马丁格尔策略

马丁格尔，英文名称Martingale或缩写MG（Martigues是或曾经是法国的一个村庄，最早的时候马丁格尔应该是指马身上用于控制马车的马具），是一种基于18世纪流行于法国的赌博方式的交易策略。它在赌场游戏系统中盛行至今，是一种著名的策略，被称为“永远不亏钱的马丁格尔”。

马丁格尔策略的操作准则很简单：在任何一张可以买大小(单双)的赌桌上，你从一单位赌注开始，在每次输钱后，将赌注加倍，而在任何一次赢钱后，下一次又回归到一单位赌注。因此，无论你在赢钱之前输了多少次，只要概率让你赢一次，你就能够收回先前的损失，并且还会获得第一次赌注总额的收益。

马丁格尔策略最初用于赌场，后来移植到金融交易市场中，创造了许多盈利奇迹，但更多的是爆仓破产的消息。马丁格尔策略的优缺点可以说是对立的，因为它们都与该策略最根本的理论依据相关：认为行情永远会回调。尽管这种观点在非常大的时间跨度上来说或许是正确的，然而真实的市场情况远比这复杂，价格行情既不是随机的，交易者也不可能有无限的资金。因此，马丁格尔策略适用范围主要是震荡行情。一旦走出震荡进入单边行情，马丁格尔策略就会面临非常大的风险。

马丁格尔策略的进化

因为原版的马丁格尔策略存在巨大风险，研究者开始不断改进策略。

以下是一些实际应用的方法：

• 择时马丁：跟随手气旺的玩家下注，提高胜率。

• 顺势马丁：连续开出五大后继续下注大。

• 逆势马丁：连续开出五小后下注大。

• 双向马丁：在轮盘桌子上买大，骰宝桌子上买小

• 止损：限制倍投次数，例如第十次倍投后不管输赢，下一次下注从一单位开始。

• 修改赌注加倍的比例：例如改为1.5、1.2或者使用斐波那契数列。

• 寻找震荡市场：如果一张桌子有连续开出20个大的记录，则不在这张桌子上下注。

• 圣杯马丁：用别人的钱玩马丁。

下面是使用Hummingbot Script开发马丁格尔策略的步骤：

1. 首先，需要编写一个Python脚本，实现马丁策略的交易逻辑。具体而言，就是开仓后通过上下挂止盈和补仓订单，达到止损金额后平仓离场，开始下一个循环。

2. 将编写好的Python脚本保存至本地，例如martingale_strategy.py。

3. 将策略上传至Hummingbot scripts目录下。

4. 启动Hummingbot，运行start -scripts martingale_strategy.py开始运行策略。

策略设计

用户需要哪些变量来运行脚本：

• 交易所

• 交易对

• 初始下单金额

• 最大加仓次数

• 加仓比例

• 止盈比例

• 杠杆倍数

总结

使用马丁格尔策略模拟运行的结果，尽管结果不尽相同，只要时间周期够长，最终的结局似乎都是相同的。

尽管马丁格尔策略有很大的局限性，但仍有很多赌徒和投资者继续使用它来提高自己的赌博和交易胜率，甚至在一些网站上也能看到很多关于马丁格尔策略的介绍和讨论。然而，理性的投资者应该意识到，无论是在赌场还是证券市场，投资并不是简单的赌博游戏，在搏取高收益的同时，要控制好风险，更要建立起完善的投资理念和科学的风险管理体系。

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的 Discord 中文频道，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

加入蜂鸟爱好者社区星球，获取本文源码。

概述：

这篇文章旨在解释什么是流动性以及为什么流动性在金融工具（如加密货币、股票和外汇）中至关重要。首先，文章采用菜市场的比喻来说明流动性是什么以及如何产生。接着，它讨论了做市商在中心化交易所中创造流动性的作用。此外，文章还强调了流动性对 Web3 项目的重要性，并提供了做市商如何创造流动性的信息。

流动性：

Investopedia将流动性定义为“资产或证券在不影响其市场价格的情况下能够转换为现金的效率或便利性”。

流动性通常由以下特征衡量：

• 交易时间：您能够以当前价格多快地满足订单。

• 深度：您是否能够买入或卖出大额订单而不会显著改变价格。

• 价差紧密度：高的紧密度表示您可以以非常接近的价格（买入价和卖出价之间的价差）买入和卖出。

• 滑点：交易的预期价格和实际成交价格之间是否存在差异？

有些人错误地将交易量（24小时交易量）称为流动性。虽然它们两者有关联，但并不是同一件事。高交易量并不一定表示良好的流动性或导致更好的流动性，而良好的流动性通常会导致更多的24小时交易量。

用一个通俗易懂的比喻向我奶奶解释：

类比词典：

菜市场：交易所

顾客：使用市价单在交易所购买代币的用户

市场摊位：订单簿中的限价卖单，以特定价格出售代币

水果：项目的代币（Token/Coin），例如BTC或ETH

库存：限价单卖出量

交易所可以比作一个菜市场。在这个菜市场中，卖家在摊位上交易，顾客则来到市场想购买水果。如果没有来到这个菜市场的顾客，没有人会有动力设立一个特定类型水果的市场摊位，如果没有市场摊位，这个菜市场就不会吸引顾客。

假设每个摊位出售一种水果，每种水果代表一个代币。出售苹果的摊位可以看作是以特定价格出售x数量BTC的人。因此，这些市场摊位代表了市场上的限价卖单。顾客可以被看作是想立即执行市价买单的交易者。

这个菜市场允许苹果进行交易。对于菜市场说，幸运的是，有许多顾客愿意购买苹果，也有许多市场摊位可以容纳这些顾客。这样每个顾客都可以得到自己想要购买的苹果的公平价格，许多交易可以进行，这有利于菜市场。

市场上出现了新的水果：

一种名为“山竹”的新水果正在寻求在这个菜市场上进行交易。此水果在其他菜市场上并未交易，请求在此市场上进行上市。市场的所有者同意允许交易此水果，但要求缴纳一次性费用5000美元（上币费用）。

‍存在问题:

目前存在一个问题：有购买者有兴趣在菜市场购买山竹，但是当前没有市场摊位售卖山竹。这可能是因为没有人有 山竹可以出售，或者没有人愿意开设市场摊位并以特定价格开始销售。尽管山竹现在被允许交易，但由于没有交易对手（卖家/市场摊位）为购买者提供服务，因此没有产生任何交易。

第二天，山竹的所有者决定向许多人免费提供 山竹（类似于空投），希望他们会开设市场摊位并将他们的山竹出售给有兴趣购买 山竹的任何人。虽然有些人确实开设了市场摊位（放置限价卖单并以特定价格提供他们的代币），但他们的库存（订单簿深度或要出售的代币）不多，价格差异很大。一个市场摊位以1.00美元的价格销售 山竹，下一个以1.35美元的价格销售，最后一个以1.65美元的价格销售。

尽管购买者有交易对手，人们现在可以从市场摊位购买山竹，但由于库存有限和高达1.65美元每个山竹的高价，购买者无法购买大量的山竹。

库存不足和高昂的价格不会吸引新的山竹购买者，也不会鼓励人们购买大量的山竹。

市场仍被认为是“没有流动性”的。项目最初的“上市”未获得预期的效果。

解决方案：

山竹的所有者决定雇用一家经营规模更大的公司来开设摊位。他把他的山竹借给该公司，操作员随后开设几个市场摊位。做市商确保始终有足够的库存可供任何类型的顾客（大型和小型）购买山竹。

此外，做市商确保他们的价格彼此接近。例如，一个摊位可能以1.00美元的价格提供山竹，下一个摊位以1.01美元的价格提供，下一个以1.02美元的价格提供，以此类推，这样如果一个摊位库存不足，价格上没有显著的上涨。

为什么重要：

现在，对于买家来说，他们可以以公平的价格和大量购买到山竹。这个菜市场表示，他们将会始终具备充足的库存，并且顾客们更倾向于在该菜市场购买。它可以通过拥有的市场摊位和大量的库存及价格相近来实现这一点。这样可以使得买家们能够更加轻松的以公平的价格购买到山竹，同时这也有利于山竹的所有者。现在该市场被认为是“有流动性”的市场，就是说买家们可以大量购买而不会对价格有显著影响。这使得所有者可以专注于营销活动，因为他们知道有兴趣的买家可以在菜市场上以公平的价格轻松购买到山竹（代币）。如果没有流动性市场，营销工作的影响将不会很大，因为人们可能听说过山竹，但会发现很难购买或在大量购买时价格太高，这限制了山竹的应用。此外，由于存在着大量的买家，人们更倾向于自己开设市场摊位，从而提高了市场的“流动性”。

回到Web3:

在Web3项目中，除了买卖市场外，还有销售市场。这种市场运作方式与传统市场类似，但具有更多的技术特性。例如，Web3项目可能支付上市费用，以在交易所上进行交易，并且社区成员也可能拥有代币。但即使如此，也不能保证人们会主动提供自己的代币出售，或者以特定价格提供自己的美元进行购买。

因此，对于项目而言，为了管理其流动性，必须聘请做市商来管理市场。这可以确保人们可以在交易所上轻松地购买和出售资产，从而为项目的发展提供支持和推动。综上所述，在Web3项目中，流动性是一个至关重要的因素，需要精心管理和维护。

不只是Web3:

流动性不仅对加密货币重要，对股票和外汇（欧元、美元、英镑等）也同样重要。事实上，最有流动性的资产就是货币。货币可以轻易地兑换任何东西。

一个不流动的资产的例子是偏远地区的房地产或收藏品。对于这些资产，很难快速找到买家或卖家。

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的 Discord 中文频道，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

【彩蛋】

街坊：你孙子是做什么的？

我奶奶：应该是在菜市场卖山竹

话不多说，直接上图：

与原作者和众多移植版本的结果差不多：

• 成交量大，日成交量大约是总资金的100倍

• 平均买入价和卖出价基本相等，趋势策略在这个BTC-USDT这个竞争激烈的市场基本不赚钱

• 手续费(0.1%)比利润高得多，正如原作者所说，原版的韭菜收割机已经不适合当前的市场了。

尽管如此，我们还是有一些方法能优化这个策略：

• 用合约代替现货，减少融币和代码中平衡资产的环节

• 用maker 取代 taker进行买入(开仓)操作

• 调整优化参数，例如爆发百分比，tick间隔时间

• 使用hummingbot内建方法重写获取交易量模块

• 找到手续费更合适的市场进行交易，如果手续费是(-0.01%)，那么这个策略将会是一个可以盈利的策略。

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的 Discord 中文频道，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

https://link.zhihu.com/?target=https%3A//t.zsxq.com/0aDr4ZAfk

1. 更新交易量

2. 更新订单簿

3. 平衡资产

4. 判断市场状况并下单

更新交易量

万事开头难，第一步我们就遇到了问题，因为Hummingbot Script并没有提供直接获取历史交易的方法，

我们只能直接用交易所的API去获取这个数据，不过据说Hummingbot的开发人员已经在着手写一个和Trade相关的模块，以便让用户更方便地调用：

    def update_vols(self):
        trades = pd.DataFrame(self.fetch_historical_trades(self.trading_pair, 15))
        self.vol = 0.7*self.vol+0.3*trades.size.sum()
        if len(self.prices) == 0:
            self.prices = list(trades['price'].astype('float'))    
    def fetch_historical_trades(self, trading_pair: str, limit) -> List[Decimal]:
        url = "https://api.binance.com/api/v3/trades"
        params = {
            "symbol": trading_pair.replace("-", ""),
            "limit": f"{limit}"
        }
        trades = requests.get(url=url, params=params).json()
        return trades

这段程序实现了以下功能：update_vols()函数中，使用pd.DataFrame(self.fetch_historical_trades(self.trading_pair, 15))获取近15条交易的信息，存储在trades变量中。使用trades.size.sum()获取trades中交易数量的总和，并使用0.7self.vol+0.3trades.size.sum()更新self.vol的值。判断self.prices列表是否为空，如果为空，将trades中price列转化为浮点数后存储在self.prices中。fetch_historical_trades()函数中，使用requests.get(url=url, params=params).json()获取最近15条交易的信息。其中url是API的URL，params是请求参数，包括交易对和交易数量。最后返回获取到的交易信息。注意：这段代码与Binance交易所相关，需要确保你有Binance的API访问权限。

更新订单薄

Hummingbot有一个获取订单薄的方法，我们可以直接使用：

    def update_orderBooks(self):

        orderBook = self.connectors[self.connector_name].get_order_book(self.trading_pair)
        ask_entries = orderBook.ask_entries()
        bid_entries = orderBook.bid_entries()

        Asks1 = float(next(ask_entries).price)
        Asks2 = float(next(ask_entries).price)
        Asks3 = float(next(ask_entries).price)

        Bids1 = float(next(bid_entries).price)
        Bids2 = float(next(bid_entries).price)
        Bids3 = float(next(bid_entries).price)

        Asks = Bids1*0.618 + Asks1*0.382 + 0.01
        Bids = Bids1*0.382 + Asks1*0.618 - 0.01

        PriceGetIn = (Bids1+Asks1)*0.35 + (Bids2+Asks2)*0.1 + (Bids3+Asks3)*0.05
        self.prices.pop(0)
        self.prices.append(PriceGetIn)

        return Asks,Bids,Asks1,Bids1

这段程序实现了以下功能：使用self.connectors[self.connector_name].get_order_book(self.trading_pair)获取交易对的订单簿。使用ask_entries()和bid_entries()方法分别获取卖盘和买盘的订单。使用next(ask_entries).price和next(bid_entries).price获取卖盘和买盘的价格。其中Asks1, Asks2, Asks3, Bids1, Bids2, Bids3分别表示第一第二第三档卖盘和买盘的价格。使用Asks1和Bids1算出Asks和Bids的值。使用Bids1, Asks1, Bids2, Asks2, Bids3, Asks3算出PriceGetIn的值。将PriceGetIn的值加入self.prices列表中。最后返回Asks, Bids, Asks1, Bids1四个值。注意：程序中的0.618，0.382，0.01和0.35，0.1，0.05是预先设定的常量，他们对于程序的结果有影响。

平衡资产

    def get_balance(self):

        df = self.get_balance_df()
        self.base_asset = float(df.loc[df['Asset'] == self.base, 'Total Balance'])
        self.price = float(self.connectors[self.connector_name].get_mid_price(self.trading_pair))
        self.base_value = self.base_asset * self.price
        self.quote_asset = float(df.loc[df['Asset'] == self.quote, 'Total Balance'])
        total_value = self.quote_asset + self.base_value

        if self.base_value >= total_value * 0.52:
            self.sell(self.connector_name, self.trading_pair, Decimal(total_value/self.price * self.threshold),
                      OrderType.LIMIT, Decimal(self.price * 1.0001))
        elif self.base_value < total_value * 0.48:
            self.buy(self.connector_name, self.trading_pair, Decimal(total_value/self.price * self.threshold),
                     OrderType.LIMIT, Decimal(self.price * 0.9999))

这段程序实现了以下功能：1.使用self.get_balance_df()获取账户资产信息并存储在df中。2.使用df.loc[df['Asset'] == self.base, 'Total Balance']获取基准资产的余额并存储在self.base_asset中。3.使用self.connectors[self.connector_name].get_mid_price(self.trading_pair)获取基准资产和报价资产的中间价格，并存储在self.price中。使用self.base_asset * self.price计算基准资产的总价值并存储在self.base_value中。使用df.loc[df['Asset'] == self.quote, 'Total Balance']获取报价资产的余额并存储在self.quote_asset中。使用self.quote_asset + self.base_value计算总价值并存储在total_value中。判断基准资产的总价值是否大于等于总价值的52%，如果是，调用self.sell()函数卖出指定比例的资产；如果基准资产的总价值小于总价值的48%，调用self.buy()函数买入指定比例的资产。注意：程序中使用了self.connector_name，self.trading_pair，self.threshold，self.base，self.quote等变量，需要确保这些变量已经被正确赋值。

判断市场状况并下单

这一部分的代码比较长，就不贴出来了，简单说就是通过定义好的爆发阈值判断当前市场是牛市或者是熊市，并根据交易量、价格波动、盘口价差等因素进行下单力度调整，具体可以原始代码。

最后我们在on_tick函数中调用上面几个函数，程序就基本完成了。

下一节，我们将展示实际的机器人绩效，并提出一些优化改进的想法。

本文参考了以下内容：

Script入门指南 - Hummingbot Docs

Hummingbot Script速查表

ChatGPT

Binance API Documentation

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的 Discord 中文频道

，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

目标

移植OKCoin韭菜收割机

原项目地址：

https://github.com/richox/okcoin-leeks-reaper

前提

有哪些假设可以证明该战略的逻辑是合理的?

原始版本说明：

这是一个在OKCoin比特币交易平台上的高频交易机器人程序，从2016年6月策略基本定型，到2017年1月中旬，这个策略成功的把最初投入的6000块钱刷到了250000。由于近日央行对比特币实行高压政策，各大平台都停止了配资，并且开始征收交易费，该策略实际上已经失效了。

最近有很多交易所都在做0手续费的活动，或许这个策略最近能复活。

描述

本机器人程序基于两个主要策略：

趋势策略：在价格发生趋势性的波动时，及时下单跟进，即俗话说的追涨杀跌。平衡策略：仓位偏离50%时，放出小单使仓位逐渐回归50%，防止趋势末期的反转造成回撤，即收益落袋，不吃鱼尾。本程序要求平衡仓位，即（本金+融资=融币），使得仓位在50%时净资产不随着价格波动，也保证了发生趋势性波动时涨跌都赚。

策略设计

输入

用户需要哪些变量来运行脚本：

• burst threshold（爆发阈值）

• burst vol （爆发成交量）

• min stock （最小下单量）

格式

策略运行时，当你在客户端输入status命令，能看到哪些信息：

• 市场状态

• 当前持仓

逻辑

下一节，我们将会讲解具体的代码。

如有任何问题获想参与讨论，请加入我们的社区

我们的社区有众多的做市商和套利者，他们愿意互相帮助，充分利用 Hummingbot。 您可以加入我们的 Discord 中文频道，讨论 Hummingbot、策略、流动性挖坑以及与加密货币世界有关的任何其他内容，并获得我们团队的直接支持。

加入中文微信群，请添加ID：amtf202004

加入蜂鸟爱好者社区星球，获取本文源码。