XRP Ledger RPC 吞吐量声明面临审查，因为经过验证的基准讲述了不同的故事
核心要点
- 另一家基础设施提供商 GetBlock 声称其 XRPL 节点每秒可以处理多达 1,000 个请求，且专用设置没有速率限制。
- XRPL 基础设施的实际发展方向 371 毫秒的 p50 延迟数字代表了去中心化网络在处理每个请求的加密验证方面取得了有意义的进步。
- 在公共集群上观察到的每秒 10,000 多次
仔细观察 XRPL 基础设施性能就会发现总体数据与已确认的指标之间存在巨大差距。
社交媒体上流传的 XRP Ledger RPC 节点每秒可以处理 30,000 条消息的说法听起来令人印象深刻。问题是经过验证的基准测试实际上并不支持这个数字。
实际数字表明什么
XRPL Labs 是 XRP Ledger 的主要基础设施开发商之一，一直关注延迟而不是原始消息吞吐量。他们的公共端点目前发布的 ledger_current 调用的 p50 延迟约为 371 毫秒，使其成为公共 XRPL 服务器中延迟最低的选项。
Gloria One 应用程序，一个屏幕 - 每天早上，Gloria Finance 都会向您简要介绍发生的事情以及它如何影响您的投资组合。阅读您的简介 →
据观察，公共服务器集群在高峰使用期间每秒处理超过 10,000 次读取。对于区块链基础设施来说，这是一个可靠的数字，但它只是声称的 30,000 数字的三分之一。
另一家基础设施提供商 GetBlock 声称其 XRPL 节点每秒可以处理多达 1,000 个请求，且专用设置没有速率限制。
最接近标题数据的是验证者消息传递，这是一个根本不同的流量类别。在最佳测试条件下，验证器消息处理记录平均每秒约 3,260 条消息，峰值每秒超过 6,100 条消息。但验证器到验证器的共识流量和客户端-服务器 RPC 请求就像苹果和橘子一样。
在生产环境中，XRPL 网络的实际交易吞吐量历史上在每日高峰期间处于每秒 100 到 230 笔交易之间。受控测试设置中的理论最大值已超过 1,500 TPS，这仍然比人们猜测的 30,000 数字低一个数量级。
为什么差距很重要
每秒消息数和每秒事务数之间的区别在这里很重要。一个 RPC 节点可能会处理数千个读取请求（余额查找、账本查询、订阅更新），这些请求永远不会导致事务写入账本。对所有入站消息进行计数（包括 ping、状态检查和失败的请求）所产生的数字始终会比对实际处理的事务进行计数要大。
特别是对于 XRP 来说，这一点很重要，因为 Ripple 一直将 XRPL 定位为机构支付处理和去中心化交易活动的基础设施。这两种用例都需要在持续负载下实现可预测、可验证的性能，而不是在实验室条件下实现的理论峰值。
XRPL 基础设施的实际发展方向
371 毫秒的 p50 延迟数字代表了去中心化网络在处理每个请求的加密验证方面取得了有意义的进步。对于银行或支付提供商来说，能够在 400 毫秒内持续处理请求的支付网络比声称具有极高吞吐量但响应时间不可预测的支付网络更有用。
基础设施堆栈也在多样化。多个提供商现在提供专用的 XRPL 节点服务，这可以分散负载并减少单点故障。在公共集群上观察到的每秒 10,000 多次读取表明，即使在专用企业设置出现之前，网络也可以处理大量查询。