Solana 應用程式若想再縮短 20 ms，關鍵在專用 RPC 端點與 SWQoS

在高頻交易與任務關鍵型 Solana 應用程式中，即使 20 ms 也能產生決定性的差異。專用 RPC 端點和共享 RPC 端點在根本設計上不同，這 20 ms 的差距永遠無法彌合。本文解釋原因，以及 ERPC 如何端到端解決這一問題。

使用 http 代替 https 削減 20 ms

您可能注意到 RPC 端點 URL 通常以 https 開頭。「s」代表 TLS/SSL 加密，保障通訊安全。然而，這種加密需要握手和持續的加密/解密，每個請求增加約 20 ms 的延遲。

換言之，如果 RPC 通訊使用 http 而非 https，這 20 ms 可以從根源消除。在 Solana 中，區塊拍賣大約在 50 ms 內決出勝負，這個差距至關重要。

有人可能會問：「那為什麼不在共享端點上允許 http？」答案很簡單：這是不可能的。

在共享環境中允許 http 意味著未加密的通訊，將交易暴露在中間人攻擊、封包攔截甚至簽名交易被盜的風險之下。使用同一共享端點的攻擊者完全可以篡改或重放您的交易。

因此，共享端點必須始終強制執行 TLS/SSL。我們的共享 RPC 端點在此限制下已被設計得儘可能快，但 TLS 的 20 ms 開銷在設計上無法消除。

專用 RPC 端點將存取限制在特定且受信任的用戶端。這使我們能夠取消 TLS 要求並允許直接的 http 通訊。

因此，可確實減少 20 ms 延遲。無論使用者負載或攻擊風險如何，這種結構性差異確保共享和專用端點之間的 20 ms 差距永遠不會被消除。

僅有速度是不夠的。Solana 實施了權益加權 QoS（SWQoS），未取得質押信任的節點只能使用 20% 的可用交易通道。

例如，直接向目前領導驗證者傳送交易的 Lite-RPC 設計看起來可能很快，但沒有 SWQoS 仍然被限制在那 20% 的通道中。這意味著即使封包快速到達，其納入率也會顯著降低。

使用專用 RPC 削減 20 ms 很關鍵，但將其與 SWQoS 結合才能同時實現速度和交易成功率。

ERPC 提供了在專用 RPC 端點上啟用 SWQoS 的選項。

這意味著您可以結合專用 RPC + SWQoS同時實現延遲降低和更高的成功率。

ERPC 解決以下問題：

在開發開源 Solana 貢獻專案 Epics DAO 時，我們面臨了建構真正高效能、低延遲 Solana 開發環境的困難。這一挑戰促使我們設計了自己的平台，在此基礎上提供 ERPC 和 SLV。

金融等任務關鍵型應用對延遲與錯誤格外敏感，因為它們直接影響使用者體驗。Solana 環境高度複雜，與傳統網際網路金融不同，驗證者分佈在全球。再加上 Web3 知識的額外複雜性，開發者難以全面掌握，這減緩了最佳化進度。

透過提供高效能 Solana 基礎設施，我們旨在消除這些障礙並提升整個生態系統的使用者體驗。ERPC 和我們的開源 SLV 專案都是這一使命的組成部分。