在0xArc,我们需要获取每个链上的每一条数据,包括过去、现在和未来。因此,我们的数据仓库规模达到数百TB。为了获取这些数据,我们已经进行了数十亿次RPC调用,每月继续进行数亿次跨多个区块链网络的调用。不幸的是,我们发现RPC调用节点的成功率平均约为80%,价格也存在10倍的波动!本文分享了我们的一些发现,希望对社区其他人有所帮助。
节点如何工作
在讨论数字之前,了解加密货币中节点行业的工作原理很重要,这样我们就可以正确理解我们正在讨论的内容。虽然每个人都能运行自己的节点,并遵循去中心化的完美原则,但事实是,运行节点是复杂的,需要专业知识。因此,我们将这一责任委托给了节点提供商。这个图表是基于2024年加密货币中商业节点行业的工作方式。
总的来说,你有运行在特定节点实现(geth/reth/erigon)上的完整或归档节点,这些节点由Alchemy或Quicknode等提供商托管在每个支持的区块链网络上。作为RPC消费者,你最终访问所有这些内容。
最佳节点选择
当你分解这个逻辑链时,你有4个主要维度会极大地影响性能:
你发出RPC请求的链:每个链的节点网络表现不同,活跃程度也不同。
你调用的方法:这取决于你是在进行完整节点还是归档节点调用,以及节点客户端实现。
你使用的提供商:托管节点供你访问的实体。
你何时调用节点:节点性能随着上述所有维度的变化而变化,并非恒定。
能够检测和理解这些数据可能很有挑战性。然而,在0xArc,这是我们的工作,因为我们进行了数十亿次RPC调用,并仔细监控我们接触的所有内容。性能、可靠性和成本对我们至关重要。我们在大多数市场参与者之前就知道某条链或某个RPC提供商出现故障。以下是我们在本文中将要研究的数据背景:
日期范围:2024年8月1日至10月20日
请求数:1,492,103,937
成功数:1,171,952,063
失败数:320,793,140
平均成功率:78.5%
为了正确理解超过10亿行数据发生的情况,我们需要从多个维度对其进行切片和分析。幸运的是,我们知道这些维度是什么,正如我上面提到的。
接下来的文章将展示性能如何在每个维度上以不可预测的方式发生变化的独特实例。
链路性能
假设你正在构建一个依赖于与各种网络交互的跨链应用程序。你的节点性能将根据你调用的链以及调用的时间而显著不同。
第一个图显示了每天每个链的平均成功率,这是跨所有提供商和方法汇总的结果。如你所见,从图表中可以看出,每个月链的平均成功率都有很大差异。我们不确定这可能是由什么原因造成的,但我们可以看到,8月份Polygon调用的成功率平均为60%,但最近几周已经上升到80%以上。
在评估这些数据时,需要注意的一个关键警示是:"Polygon是一个糟糕的链,RPC调用平均只有70%的成功率"。这是在大约2.5个月的时间内,跨所有链、所有提供商和所有方法的加权平均成功率。当我们深入研究这些维度中的任何一个时,数据都会发生显著变化。
这是同样的图表,但只涵盖了17天的时间,并按单一提供商进行了过滤。如你所见,图表要平滑得多,与整体汇总有所不同。
如果我们发现某个单一提供商表现良好,那么我们为什么不一直依赖于他们呢?下一节将更细致地解决这个问题。
提供商性能
这个下一个图表我简化了,因为我想避免出现太多线条。每一个都代表一个主要的RPC提供商网络,其成功率是跨所有链和方法汇总的结果。如你从下面的图表中看到的,橙色提供商相对于其他提供商是最可靠的,差异相当惊人!
再次,显而易见的可能就是"使用橙色提供商",因为它表现良好。不幸的是,这也并不太管用。当我们只看橙色提供商在以太坊上的性能时,归档节点方法的性能可能会出现戏剧性下降。如你所见,在将近一个月的时间里,在我们上面所谓的"最佳提供商"上,归档节点的性能都非常糟糕。
所以,如果我们要追求某些方法的最佳性能,我们需要更仔细地观察。
方法性能
下面的最终图表显示,各种方法的成功率在月度之间发生了相当大的变化。根据你是在调用完整节点还是归档节点,你的性能会有很大不同。我们在上面针对单个链上的单个提供商看到了这一点,但现在我们有了一个更广泛的视角。
如果我们平均这些数据,我们会得到下面按方法划分的平均成功率,以及显示归档节点与非归档节点调用比例的面积图。从这种方式来看,你会意识到节点的不可靠性是多么严重,尤其是当你跨多个维度进行衡量时。许多时候,节点提供商使用有限时间框架内的华丽营销数字来推广他们的性能。直到你大规模地攻击他们,才能看到真实的指标。
最佳策略
那么,选择节点的最佳方式是什么?一种论点可能是只使用我们上面提到的橙色提供商,但当他们的系统开始失败并出现大幅下降时,你的下游系统也会因为他们而失败。
避免这种情况的一种方法是在系统中设置备用提供商。但是,这些备用提供商需要手动维护,并通过次优路由增加延迟。理想情况下,你希望以动态、智能的方式拥有这些路由的性能数据,而不是在代码库中使用静态的if/else子句。
更让事情变得更加复杂的是,每个提供商在每个链和方法上的定价都在变化。这些差异可能高达每种方法/链10倍的成本。突然,10-20%的性能差异最终会让你付出更多!每个提供商都想让你锁定在一个年度计划或每月配额中,这会产生额外的成本。几乎没有提供商是纯使用量付费的,这意味着你必须对一个单一的提供商下注 - 没有任何数据!一个表面上"简单"的服务,实际上在仔细检查时表现差异很大。
如果你正在为RPC付费或考虑你的基础设施的可靠性,让我们探讨如何最大化跨链和提供商的性能。请联系我们,了解我们的发现或看看我们如何为您提供帮助。
目前正在为RPC付费,想了解如何提高可靠性
是一个RPC提供商,想知道你的节点表现如何
正在考虑注册RPC服务,想得到一些建议
直接通过这封电子邮件或发送电子邮件至k@0xarc.io与我联系,我们可以安排时间进行交流。
