Ang mga claim tungkol sa throughput ng XRP Ledger RPC ay nasa ilalim ng pagsusuri dahil ang mga benchmark ay nagpapakita ng ibang kuwento

Isang klaim na kumikilos sa social media na ang XRP Ledger RPC nodes ay kayang prosesuhin ang 30,000 na mensahe bawat segundo ay tila nakakaimpresyon. Ang problema ay ang mga napatunayang benchmark ay hindi talaga sumusuporta sa numero na iyon.

Ang XRPL Labs, isa sa mga pangunahong developer ng infrastruktura para sa XRP Ledger, ay nakatuon sa latency kaysa sa karaniwang throughput ng mensahe. Ang kanilang pampublikong endpoint ay nagpapakita ng p50 latency na humigit-kumulang 371 milisegundo para sa mga ledger_current calls, gawing ito ang pinakamababang latency na opsyon sa mga pampublikong XRPL server.

Nakikita ang mga public server cluster na nagdadala ng higit sa 10,000 na pagbasa bawat segundo sa mga panahon ng pinakamataas na paggamit. Ito ay isang matibay na bilang para sa blockchain infrastructure, ngunit iyon ay isang ikatlo ng sinasabing 30,000.

Ang GetBlock, isa pang provider ng infrastruktura, ay nagsasabing ang kanilang XRPL nodes ay kayang prosesuhin ang higit sa 1,000 na kahilingan bawat segundo nang walang limitasyon sa bilis sa mga dedicated na setup.

Ang pinakamalapit na nakamit ng sinuman sa headline figure ay may kinalaman sa validator messaging, na isang magkakaibang kategorya ng trapiko. Ang pag-handle ng validator message ay nagsasalaysay ng mga average na halos 3,260 na mensahe bawat segundo sa optimal na mga kondisyon ng pagsubok, kasama ang mga peak na higit sa 6,100 na mensahe bawat segundo. Ngunit ang validator-to-validator consensus traffic at client-server RPC requests ay iba’t ibang bagay.

Sa mga production environment, ang tunay na transaction throughput ng XRPL network ay nasa pagitan ng 100 at 230 na transaksyon bawat segundo noong mga daily peaks. Ang teoretikal na maximum sa mga controlled testing setting ay nakakamit ng higit sa 1,500 TPS, na nananatiling isang orden ng magnitude sa ilalim ng 30,000 na numero na pinapag-uusapan.

Mahalaga ang pagkakaiba sa pagitan ng mga mensahe bawat segundo at mga transaksyon bawat segundo. Maaaring hawakan ng isang RPC node ang libo-libong mga kahilingan sa pagbabasa (paghahanap ng balanse, mga katanungan sa ledger, mga pag-update ng pagsubskrisyon) na hindi nagresulta sa pagsulat ng anumang transaksyon sa ledger. Ang pagbilang ng lahat ng mga pumasok na mensahe, kabilang ang mga ping, pag-check ng estado, at mga nabigo na kahilingan, ay laging magbibigay ng mas malaking bilang kaysa sa pagbilang ng tunay na prosesadong transaksyon.

Para sa XRP partikular, mahalaga ito dahil ang Ripple ay nagpapakilala sa XRPL bilang imprastruktura para sa pagproseso ng mga bayad ng mga institusyon at aktibidad ng decentralized exchange. Kailangan ng parehong paggamit ang makabuluhang, mapapatunayang performance sa ilalim ng patuloy na load, hindi ang teoretikal na peak na natutupad sa mga kondisyon ng laboratorio.

Ang 371ms p50 latency ay nagpapakita ng makabuluhang progreso para sa isang decentralized network na nagdadala ng cryptographic verification sa bawat request. Isang payment network na patuloy na nagproseso ng mga request sa ilalim ng 400 millisecond ay mas kapaki-pakinabang sa isang bangko o payment provider kaysa sa isang network na nagsasabi ng napakataas na throughput ngunit nagbibigay ng hindi maipagkakailang mga oras ng pagtugon.

Ang infrastructure stack ay nagdudiversify din. Maraming provider ngayon ang nag-aalok ng mga espesyal na serbisyo para sa XRPL node, na nagpapalaganap ng load at nagpapababa ng mga tanging puntos ng pagkabigo. Ang 10,000+ na basa bawat segundo na nakita sa mga pampublikong cluster ay nagpapakita na ang network ay kayang harapin ang malaking volumen ng query kahit bago pa pumasok ang mga espesyal na enterprise setup.