Утверждение, распространяемое в социальных сетях, что RPC-ноды XRP Ledger могут обрабатывать 30 000 сообщений в секунду, звучит впечатляюще. Проблема в том, что проверенные тесты на самом деле не подтверждают это число.
Что показывают фактические цифры
XRPL Labs, один из основных разработчиков инфраструктуры для XRP Ledger, сосредоточился на задержке, а не на максимальной пропускной способности сообщений. Их публичная точка доступа сейчас показывает p50 задержку около 371 миллисекунды для вызовов ledger_current, что делает её вариантом с наименьшей задержкой среди публичных серверов XRPL.
Публичные серверные кластеры демонстрировали более 10 000 чтений в секунду в периоды пиковой нагрузки. Это надежный показатель для инфраструктуры блокчейна, но в три раза меньше заявленных 30 000.
GetBlock, еще один провайдер инфраструктуры, утверждает, что его ноды XRPL могут обрабатывать более 1000 запросов в секунду без ограничений по скорости на выделенных настройках.
Ближе всего к цифре в заголовке подошли сообщения валидаторов, которые относятся к совершенно другой категории трафика. Обработка сообщений валидаторов показала средние показатели около 3 260 сообщений в секунду при оптимальных тестовых условиях, с пиками выше 6 100 сообщений в секунду. Однако трафик консенсуса между валидаторами и RPC-запросы клиент-сервер — это разные вещи.
В производственных средах реальная пропускная способность сети XRPL исторически варьировалась от 100 до 230 транзакций в секунду во время дневных пиков. Теоретические максимумы в контролируемых тестовых условиях достигали более 1500 TPS, что все еще на порядок ниже цифры в 30 000, которую иногда упоминают.
Почему разница имеет значение
Здесь важно различать сообщения в секунду и транзакции в секунду. RPC-нода может обрабатывать тысячи запросов на чтение (проверки баланса, запросы к реестру, обновления подписок), которые никогда не приводят к записи транзакции в реестр. Подсчет всех входящих сообщений, включая пинги, проверки статуса и неудачные запросы, всегда даст большее число, чем подсчет фактически обработанных транзакций.
Для XRP это особенно важно, поскольку Ripple позиционирует XRPL как инфраструктуру для обработки платежей институциональными участниками и деятельности децентрализованных бирж. Оба варианта использования требуют предсказуемой и проверяемой производительности при постоянной нагрузке, а не теоретических пиков, достигнутых в лабораторных условиях.
Куда на самом деле движется инфраструктура XRPL
Показатель задержки p50 в 371 мс свидетельствует о значительном прогрессе для децентрализованной сети, обрабатывающей криптографическую верификацию при каждом запросе. Платежная сеть, которая последовательно обрабатывает запросы менее чем за 400 миллисекунд, более полезна для банка или платежного провайдера, чем сеть, заявляющая о чрезвычайно высокой пропускной способности, но обеспечивающая непредсказуемое время отклика.
Инфраструктурный стек также диверсифицируется. Множество провайдеров теперь предлагают специализированные сервисы нод XRPL, что распределяет нагрузку и снижает количество единичных точек отказа. Более 10 000 чтений в секунду, зафиксированных на публичных кластерах, свидетельствуют о том, что сеть способна обрабатывать значительный объем запросов даже до того, как на сцену выйдут специализированные корпоративные решения.