XRP 帳本 RPC 吞吐量聲稱受到質疑，因基準測試呈現不同結果

社交媒體上流傳一則聲稱 XRP 帳本 RPC 節點每秒可處理 30,000 則訊息的聲明，聽起來令人印象深刻。但問題在於，經過驗證的基準測試實際上並不支持這一數字。

XRPL Labs 是 XRP 帳本的主要基礎設施開發商之一，其重點放在延遲而非原始訊息吞吐量。其公共端點目前對於 ledger_current 調用的 p50 延遲約為 371 毫秒，成為公共 XRPL 伺服器中延遲最低的選擇。

在使用高峰期，公共伺服器叢集每秒處理的讀取次數超過 10,000 次。對於區塊鏈基礎設施來說，這是一個穩健的數字，但僅為聲稱的 30,000 次的三分之一。

GetBlock 這家基礎設施供應商聲稱，其 XRPL 節點在專用設置下可每秒處理超過 1,000 個請求，且無速率限制。

最接近該頭條數字的情況涉及驗證者訊息，這是一種本質上不同的流量類別。在最佳測試條件下，驗證者訊息處理的平均值約為每秒 3,260 則訊息，峰值超過每秒 6,100 則訊息。但驗證者之間的共識流量與客戶端-伺服器 RPC 請求是完全不同的兩回事。

在生產環境中，XRPL 網絡的實際交易吞吐量歷史上在每日高峰期間介於每秒 100 至 230 筆交易之間。在受控測試環境中的理論最大值已達到每秒超過 1,500 筆交易，這仍比被隨意提及的 30,000 數字低一個數量級。

這裡區分每秒訊息數和每秒交易數非常重要。一個 RPC 節點可能處理數千個讀取請求（餘額查詢、帳本查詢、訂閱更新），但這些請求從未導致任何交易被寫入帳本。統計所有入站訊息（包括心跳、狀態檢查和失敗的請求）所得到的數字，永遠會大於實際處理的交易數量。

對於 XRP 而言，這至關重要，因為 Ripple 一直將 XRPL 定位為機構支付處理和去中心化交易所活動的基礎設施。這兩種使用情境都需要在持續負載下具備可預測且可驗證的性能，而非僅在實驗室條件下達到的理論峰值。

371 毫秒的 p50 延遲數據，代表了在每個請求上進行加密驗證的去中心化網絡所取得的實質進展。一個能持續在 400 毫秒內處理請求的支付網絡，對銀行或支付提供商而言，比聲稱擁有極高吞吐量但響應時間不穩定的網絡更有用處。

基礎設施堆棧也在多元化。目前有多家供應商提供專用的 XRPL 節點服務，從而分散負載並減少單點故障。公共叢集每秒超過 10,000 次讀取量表明，即使在專用企業設置進入市場之前，該網絡也能處理大量的查詢量。