Заявление, распространяемое в социальных сетях о том, что RPC-узлы XRP Ledger могут обрабатывать 30 000 сообщений в секунду, звучит впечатляюще. Проблема в том, что проверенные бенчмарки на самом деле не подтверждают эту цифру. Это типичная картина для блокчейн-экосистем: громкие цифры пропускной способности циркулируют в отрыве от исходных условий тестирования — зачастую это лабораторные замеры, внутренние подсчёты сообщений или оптимистичные прогнозы — и повторяются как производственные возможности.

Что показывают реальные цифры

XRPL Labs, один из основных разработчиков инфраструктуры XRP Ledger, сосредоточился на задержке, а не на сырой пропускной способности сообщений. Её публичный эндпоинт в настоящее время показывает p50-задержку примерно в 371 миллисекунду для вызовов ledger_current, что делает его вариантом с наименьшей задержкой среди публичных серверов XRPL.

Наблюдения показывают, что публичные кластеры серверов в пиковые периоды использования обрабатывали более 10 000 операций чтения в секунду. Это солидный показатель для блокчейн-инфраструктуры, но он составляет лишь треть от заявленных 30 000.

GetBlock, ещё один инфраструктурный провайдер, утверждает, что его узлы XRPL могут обрабатывать свыше 1 000 запросов в секунду без ограничений по частоте на выделенных конфигурациях.

Ближе всего к громкой цифре подошёл показатель обмена сообщениями валидаторов — принципиально иной категории трафика. В оптимальных условиях тестирования средняя обработка сообщений валидаторов составила около 3 260 сообщений в секунду с пиками выше 6 100 сообщений в секунду. Однако консенсусный трафик между валидаторами и RPC-запросы «клиент-сервер» несопоставимы.

В производственных условиях фактическая пропускная способность транзакций сети XRPL исторически колебалась от 100 до 230 транзакций в секунду в ежедневные пики. Теоретические максимумы в контролируемых тестовых условиях достигали более 1 500 TPS — всё равно на порядок ниже цитируемой цифры в 30 000.

Почему этот разрыв важен

Различие между сообщениями в секунду и транзакциями в секунду здесь принципиально. RPC-узел может обрабатывать тысячи запросов на чтение — проверку балансов, запросы к реестру, обновления подписок — которые никогда не приводят к записи транзакции в реестр. Подсчёт всех входящих сообщений, включая пинги, проверки статуса и неудачные запросы, всегда даст большую цифру, чем подсчёт фактически обработанных транзакций.

Для XRP это особенно важно, поскольку Ripple позиционирует XRPL как инфраструктуру для институциональной обработки платежей и децентрализованных биржевых операций. Оба сценария требуют предсказуемой, верифицируемой производительности при устойчивой нагрузке, а не теоретических пиков, достигнутых в лабораторных условиях. Это также важно для разработчиков, выбирающих инфраструктуру: планирование мощности на основе завышенных цифр ведёт к недоукомплектованным системам и сбоям при всплесках спроса.

Куда на самом деле движется инфраструктура XRPL

Показатель p50-задержки в 371 мс означает значимый прогресс для децентрализованной сети, выполняющей криптографическую проверку каждого запроса. Платёжная сеть, стабильно обрабатывающая запросы менее чем за 400 миллисекунд, полезнее для банка или платёжного провайдера, чем сеть, заявляющая запредельную пропускную способность, но обеспечивающая непредсказуемое время отклика.

Инфраструктурный стек также диверсифицируется. несколько провайдеров уже предлагают выделенные сервисы узлов XRPL, что распределяет нагрузку и сокращает единые точки отказа. Более 10 000 операций чтения в секунду на публичных кластерах свидетельствует, что сеть способна выдерживать значительный объём запросов ещё до подключения выделенных корпоративных решений.

Теперь, когда нативный автоматизированный маркет-мейкер (AMM) XRPL запущен в основной сети, а совместимая с EVM сайдчейн находится в разработке, нагрузка на RPC-инфраструктуру, вероятно, выйдет за рамки простых платёжных запросов. Это делает верифицируемое, хорошо задокументированное бенчмаркинг — такой, какой публикует XRPL Labs с перцентилями задержек, — более полезной мерой, чем вирусные заявления о пропускной способности, и именно этот показатель стоит отслеживать по мере масштабирования adoption этих новых функций.