Krążące w mediach społecznościowych twierdzenie, że węzły RPC XRP Ledger mogą przetwarzać 30 000 komunikatów na sekundę, brzmi imponująco. Problem w tym, że zweryfikowane testy wcale nie potwierdzają tej liczby. To wzorzec znany w ekosystemach blockchain, gdzie nagłówkowe liczby przepustowości krążą oderwane od pierwotnych warunków testowych — często są to pomiary laboratoryjne, liczby wewnętrznych komunikatów lub optymistyczne prognozy — i są powtarzane jako możliwości produkcyjne.

Co pokazują rzeczywiste liczby

XRPL Labs, jeden z głównych deweloperów infrastruktury XRP Ledger, koncentruje się na opóźnieniu, a nie na surowej przepustowości komunikatów. Jego publiczny punkt końcowy notuje obecnie opóźnienie p50 na poziomie około 371 milisekund dla wywołań ledger_current, co czyni go opcją o najniższym opóźnieniu wśród publicznych serwerów XRPL.

Zaobserwowano, że publiczne klastry serwerów obsługują ponad 10 000 odczytów na sekundę w okresach szczytowego obciążenia. To solidny wynik dla infrastruktury blockchain, ale stanowi jedną trzecią z deklarowanej liczby 30 000.

GetBlock, inny dostawca infrastruktury, twierdzi, że jego węzły XRPL mogą przetwarzać ponad 1 000 żądań na sekundę bez limitów częstotliwości w konfiguracjach dedykowanych.

Najbliżej nagłówkowej liczby doszto w przypadku komunikatów walidatorów — fundamentalnie innej kategorii ruchu. Obsługa komunikatów walidatorów osiągała średnio około 3 260 komunikatów na sekundę w optymalnych warunkach testowych, ze szczytami powyżej 6 100 komunikatów na sekundę. Jednak ruch konsensusowy między walidatorami a żądania RPC klient-serwer nie są porównywalne.

W środowiskach produkcyjnych rzeczywista przepustowość transakcyjna sieci XRPL historycznie mieściła się w przedziale od 100 do 230 transakcji na sekundę podczas dziennych szczytów. Teoretyczne maksima w kontrolowanych warunkach testowych osiągnęły ponad 1 500 TPS — wciąż o rząd wielkości mniej niż cytowana liczba 30 000.

Dlaczego ta różnica ma znaczenie

Rozróżnienie między komunikatami na sekundę a transakcjami na sekundę jest istotne. Węzeł RPC może obsługiwać tysiące żądań odczytu — sprawdzanie sald, zapytania do rejestru, aktualizacje subskrypcji — które nigdy nie skutkują zapisaniem transakcji w rejestrze. Zliczanie wszystkich komunikatów przychodzących, w tym pingów, sprawdzeń statusu i nieudanych żądań, zawsze da większą liczbę niż zliczanie faktycznie przetworzonych transakcji.

W przypadku XRP ma to szczególne znaczenie, ponieważ Ripple pozycjonuje XRPL jako infrastrukturę do instytucjonalnego przetwarzania płatności i działalności zdecentralizowanej giełdy. Oba zastosowania wymagają przewidywalnej, weryfikowalnej wydajności przy stałym obciążeniu, a nie teoretycznych szczytów osiągniętych w warunkach laboratoryjnych. Ma to również znaczenie dla deweloperów wybierających infrastrukturę: planowanie pojemności oparte na zawyżonych liczbach prowadzi do niedoposażonych systemów i awarii przy skokach zapotrzebowania.

Dokąd faktycznie zmierza infrastruktura XRPL

Liczba 371 ms opóźnienia p50 oznacza znaczący postęp dla zdecentralizowanej sieci wykonującej weryfikację kryptograficzną przy każdym żądaniu. Sieć płatnicza, która konsekwentnie przetwarza żądania w czasie poniżej 400 milisekund, jest bardziej użyteczna dla banku czy dostawcy płatności niż taka, która deklaruje kosmiczną przepustowość, ale zapewnia nieprzewidywalne czasy odpowiedzi.

Stos infrastrukturalny również się dywersyfikuje. Wielu dostawców oferuje już dedykowane usługi węzłów XRPL, co rozprasza obciążenie i zmniejsza pojedyncze punkty awarii. Ponad 10 000 odczytów na sekundę zaobserwowane na klastrach publicznych sugeruje, że sieć jest w stanie obsłużyć znaczną liczbę zapytań jeszcze zanim do gry wejdą dedykowane konfiguracje korporacyjne.

Wraz z uruchomieniem natywnego automatycznego market makera (AMM) XRPL na mainnecie i rozwojem kompatybilnego z EVM sidechaina zapotrzebowanie na infrastrukturę RPC prawdopodobnie wykrroczy poza proste zapytania płatnicze. To sprawia, że weryfikowalne, dobrze udokumentowane testy — takie jakie publikuje XRPL Labs z opóźnieniami percentylowymi — są bardziej użyteczną miarą niż wirusowe deklaracje przepustowości, i to właśnie ta metryka będzie warta obserwacji wraz ze skalowaniem adopcji tych nowszych funkcji.