社群媒體上流傳一項說法，指 XRP Ledger RPC 節點每秒可處理 30,000 則訊息，聽起來相當驚人。問題在於，經驗證的基準測試實際上並不支持這個數字。這是區塊鏈生態系中常見的模式：聳動的吞吐量數據在流傳過程中與原始測試條件脫鉤——往往是實驗室測量值、內部訊息計數或樂觀推估——最後被當成實際產能重複引用。

實際數據顯示什麼

XRPL Labs 是 XRP Ledger 的主要基礎設施開發商之一，其重點一直放在延遲而非原始訊息吞吐量。其公開端點目前對 ledger_current 呼叫提供約 371 毫秒的 p50 延遲，是公開 XRPL 伺服器中延遲最低的選項。

公開伺服器叢集在高峰使用時段曾觀察到每秒處理超過 10,000 次讀取。對區塊鏈基礎設施而言，這是相當不錯的數字，但僅為所稱 30,000 的三分之一。

另一家基礎設施供應商 GetBlock 則聲稱，其 XRPL 節點在專屬設定下每秒可處理超過 1,000 次請求，且無速率限制。

最接近該聳動數字的數據來自驗證者訊息傳遞，但這是完全不同類別的流量。驗證者訊息處理在最佳測試條件下平均約每秒 3,260 則，峰值超過每秒 6,100 則。然而，驗證者之間的共識流量與用戶端—伺服器 RPC 請求並不具可比性。

在實際生產環境中，XRPL 網路的實際交易吞吐量歷來在每日高峰時介於每秒 100 至 230 筆之間。受控測試環境下的理論上限曾達到超過 1,500 TPS，仍比被引用的 30,000 低了一個數量級。

為何差距至關重要

每秒訊息數與每秒交易數之間的區別在此非常重要。一個 RPC 節點可能處理數千次讀取請求——餘額查詢、帳本查詢、訂閱更新——而這些請求從不會產生寫入帳本的交易。統計所有入站訊息（包括 ping、狀態檢查與失敗請求）所得到的數字，必然大於實際處理交易數。

對 XRP 而言，這一點尤其重要，因為 Ripple 一直將 XRPL 定位為機構支付處理與去中心化交易活動的基礎設施。這兩種應用場景都需要在持續負載下可預測、可驗證的效能，而非實驗室條件下達成的理論峰值。這對選擇基礎設施的開發者同樣重要：基於灌水數據進行容量規劃，會導致系統資源不足，並在需求高峰時發生故障。

XRPL 基礎設施的實際發展方向

371 毫秒的 p50 延遲數據，對一個對每個請求執行密碼學驗證的去中心化網路而言，代表實質進展。一個能穩定在 400 毫秒內處理請求的支付網路，對銀行或支付服務商而言，比一個聲稱超高吞吐量但回應時間難以預測的網路更加實用。

基礎設施堆疊也在多元化發展。多家供應商如今提供專屬 XRPL 節點服務，分散負載並降低單點故障風險。公開叢集上觀察到的每秒 10,000 次以上讀取顯示，即使在專屬企業級服務到位之前，該網路也能應付可觀的查詢量。

隨著 XRPL 原生自動做市商（AMM）已在主網上線，且 EVM 相容側鏈正在開發中，RPC 基礎設施的需求可能將超越單純的支付查詢。這使得可驗證、文件完善的基準測試——如 XRPL Labs 公布的百分位延遲數據——成為比病毒式吞吐量說法更有用的衡量標準，也是隨著這些新功能採用規模擴大時值得關注的指標。