诸如此类的情况，我们常常遇到：即使第三方平台基本可以满足我们 99% 的需求，但仍有 1%，不能尽如人意。尽管那 1% 对我们而言至关重要，第三方平台也不会为此去改变他们的基础设定——可以说，这是很无奈的客观事实。

说到这里让我来再举另一个例子。去年有一个月左右的时间，我们的数据库出现了问题，我们一直在努力寻找根本原因，但是很难找到。其问题表现为：数据库连接数量激增，写入延迟增加，数据库负载平衡器拒绝了许多内部请求等 ...... 这些问题都像和平常出现的一些普通数据库问题类似。但导致 FTX 数据库问题的原因和普通数据库问题的原因却毫不相关。我们的数据库负载有时看起来运行良好，但是它却会突然莫名其妙地激增。

为了搞清楚到底是什么原因导致数据库出现了问题，我们团队花耗了约 100 小时进行深入挖掘后发现我们使用的一个数据库只将一些特定的信息分配给了其内存的一个非常小的子集。但其实所有的连接点都需要获取这些信息，并且问题会随着每一次未解决的获取而指数级增长。 因此偶尔它会超出特定内存子集的限制并存入磁盘——这显然速度极慢。因为这个问题增加了写入延迟并且在任何给定时间都会使未解决写入次数激增，使得问题变得更加严重！

当我们完全了解发生了什么后，我们就可以做出解决方案：我们可以检测到它何时做出错误决定并暂停它的运行，但我们仍然无法真正控制它并了解它如何分配内存。 唯一真正的、永久的解决方案是完全停止使用这个行业通用的数据库系统，并构建我们自己的数据库系统。

随着时间的推移，我们开始相信，如果我们想要完全依赖一个系统，我们必须了解其中的方方面面，并进行亲手搭建。

你可以看到这种理念渗透到了 FTX 的方方面面：当涉及到保证金和清算，我们从头开始构建系统，并且从未出现过穿仓分摊（clawback）。 当涉及到保证金，我们摒弃了使用单一保证金和独立清算的旧方式，而是采取稳定币保证金和统一保证金的全仓模式。这样用户能够完全控制其余额，可以将不同资产用作 FTX 任何合约的保证金，或者通过子账户来实现逐仓。 同时，我们正向、交叉保证金以及美元稳定币结算的合约模式取代了反向合约。 另外，我们将所有可相互替代的稳定币合并到一个稳定币篮子的钱包中，以方便用户组合其流动性，并将我们的场外交易（OTC）流动性直接与钱包进行整合。

判断一个团队打造的产品是否成功的最重要标志之一是你是否可以看到其产品的设计理念开始在整个行业中盛行。 现在许多交易所都在尝试使用稳定币交叉保证金的合约方式，模仿我们的兑换（CONVERT）功能，以及实施更合理的保证金率。 我们的代币化产品也已在数十家交易所上市，并且与 FTX 展开合作的公司也一直不断在增加。 (责任编辑：admin1)