Sebuah tuntutan yang beredar di media sosial bahawa nod RPC XRP Ledger mampu memproses 30,000 mesej per saat kelihatan mengesankan. Masalahnya, tolok ukur yang disahkan sebenarnya tidak menyokong nombor itu.
Apa nombor sebenar yang menunjukkan
XRPL Labs, salah satu pembangun infrastruktur utama untuk XRP Ledger, telah berfokus pada latensi daripada throughput mesej mentah. Endpoints awam mereka semasa ini menunjukkan latensi p50 sekitar 371 milisaat untuk panggilan ledger_current, menjadikannya pilihan dengan latensi paling rendah di antara pelayan XRPL awam.
Kumpulan pelayan awam telah diperhatikan menangani lebih daripada 10,000 bacaan per saat semasa tempoh penggunaan puncak. Itu adalah nombor yang kukuh untuk infrastruktur blok rantai, tetapi ia hanya sepertiga daripada angka 30,000 yang diklaim.
GetBlock, penyedia infrastruktur lain, mengklaim nod XRPL-nya boleh memproses lebih daripada 1,000 permintaan per saat tanpa had kadar pada pengaturan khas.
Yang paling dekat dengan angka utama melibatkan pesan validator, yang merupakan kategori trafik yang berbeza secara asas. Penanganan pesan validator telah merekodkan purata sekitar 3,260 pesan per saat di bawah keadaan ujian optimum, dengan puncak melebihi 6,100 pesan per saat. Tetapi trafik konsensus antara validator-ke-validator dan permintaan RPC klien-pelayan adalah seperti apel dan oren.
Dalam persekitaran pengeluaran, throughput transaksi sebenar rangkaian XRPL secara sejarah berkisar antara 100 hingga 230 transaksi per saat semasa puncak harian. Maksimum teoritikal dalam persekitaran ujian terkawal telah mencapai lebih daripada 1,500 TPS, yang masih satu peringkat di bawah angka 30,000 yang dipertikaikan.
Mengapa jurang itu penting
Perbezaan antara mesej per saat dan transaksi per saat adalah penting di sini. Nod RPC mungkin menangani ribuan permintaan bacaan (pemeriksaan baki, soalan buku besar, kemas kini langganan) yang tidak pernah menghasilkan transaksi yang ditulis ke dalam buku besar. Membilang semua mesej masuk, termasuk ping, pemeriksaan status, dan permintaan gagal, akan sentiasa menghasilkan nombor yang lebih besar daripada membilang transaksi yang sebenarnya diproses.
Khusus untuk XRP, ini penting kerana Ripple telah menempatkan XRPL sebagai infrastruktur untuk pemprosesan pembayaran institusi dan aktiviti bursa terdesentralisasi. Kedua-dua kes penggunaan ini memerlukan prestasi yang boleh diramalkan dan boleh disahkan di bawah beban berterusan, bukan puncak teori yang dicapai dalam keadaan makmal.
Ke arah mana infrastruktur XRPL sebenarnya akan pergi
Angka latensi p50 371ms menunjukkan kemajuan bermakna bagi rangkaian terdesentralisasi yang menangani pengesahan kriptografi pada setiap permintaan. Rangkaian pembayaran yang secara konsisten memproses permintaan dalam masa kurang daripada 400 milisaat lebih berguna kepada bank atau penyedia pembayaran berbanding yang mengklaim throughput sangat tinggi tetapi memberikan masa respons yang tidak dapat diramalkan.
Tiang infrastruktur juga semakin pelbagai. Pelbagai penyedia kini menawarkan perkhidmatan nod XRPL khas, yang menyebarkan beban dan mengurangkan titik kegagalan tunggal. 10,000+ bacaan per saat yang diperhatikan pada kelompok awam menunjukkan bahawa rangkaian mampu menangani volum soalan yang signifikan walaupun sebelum penyelesaian perniagaan khas masuk ke gambaran.

