為什麼我的 Solana 應用這麼慢？網路距離為何如此重要
為什麼我的 Solana 應用這麼慢？網路距離為何如此重要
我們經常聽到交易者和構建者這樣說：
- "我在執行類似的策略，但只有我的機器人成交延遲。"
- "價格更新正常，但我的交易來不及提交。"
- "我換過 RPC 提供商了，但效能並沒有真正改變。"
面對這些情況，第一反應通常是：
- "我的程式碼一定是太慢了。"
- "我的伺服器配置可能不夠好。"
這兩者確實都很重要。
但在 Solana 這樣的高速環境中，有一個更根本的瓶頸往往最先出現：網路距離。
在 Solana 上，有無數 dApp、DeFi 協議和市場在鏈上執行，其中許多依賴機器人進行自動化交易。在這種實質上的高頻交易（HFT）環境中，能否比競爭對手更快地檢測事件、更快地執行操作，將決定你的優勢和盈利機會。
在本文中，我們將探討為什麼在 Solana 上追求快速檢測和低延遲執行時，網路距離會成為決定性因素，以及 ERPC 的 Bundle 方案和 VPS 產品是如何設計來解決這些需求的。
為什麼感覺"只有我的應用很慢"？
首先，讓我們整理一些常見的情況：
- 你的伺服器有充足的 CPU 和記憶體，但交易反應仍然比競爭對手慢。
- 你透過 getProgramAccounts 或日誌訂閱看到了新事件，但你的交易提交總是慢半拍。
- 你嘗試了多個雲環境和多個 RPC 提供商，但沒有感到突破性的改善。
面對這些情況，許多開發者試圖從程式碼或演算法中擠出更多效能。
這是有效且重要的努力，但有一個更深層的結構性問題可能依然未解：
- 你可能一開始就在一個"遙遠的網路"中作戰。
- 從領導者驗證者的角度來看，你的應用可能位於物理上不利的位置。
如果這些條件成立，無論你怎麼最佳化軟體，都永遠無法完全達到你期望的效能水平。
要真正利用 Solana 的速度優勢，你需要同時考慮三個層面：
- 程式碼
- 硬體
- 網路
其中，你通常應該首先調優的是"網路距離"。
決定速度的三個層面
程式碼（軟體和策略）
對於 Solana 上的機器人和 HFT 類系統，你的程式碼和策略直接影響結果：
- 使用哪些事件作為觸發器
- 在什麼條件下建倉和平倉
- 去除了多少不必要的 I/O，以及並行處理的效果如何
這些是許多開發者最直觀的最佳化手段。程式碼層面的改進至關重要，但它只是拼圖的一塊。
硬體
下一個重要因素是伺服器效能。僅僅"容量足夠"是不夠的。你需要關注：
- 高主頻 CPU（單核處理任務的速度有多快）
- 核心數量（能同時執行多少任務）
- 記憶體容量和通道數（大型工作集能否無阻塞地訪問）
- NVMe 等快速儲存（確保日誌和資料寫入不會成為瓶頸）
交易工作負載通常需要處理大型索引和狀態。在這種場景下：
- 大容量 CPU 快取
- 充足的 RAM，無交換風險
可以帶來更穩定的效能。
當然，更高效能的環境成本也更高。最終，你需要找到一個平衡點，使策略的預期收益能夠支撐硬體投入。
網路
最容易被忽視、但往往對延遲影響最大的因素是網路。
透過 CPU 最佳化，你可能節省幾百納秒到幾微秒。
透過網路最佳化，你可能實現的差異突然就在幾百毫秒的範圍內。從量級上看，網路變化的影響可能是 CPU 最佳化的千倍。
即使你擁有：
- 強大的伺服器
- 高效的軟體
- 精心設計的策略
將資源放在錯誤的網路位置會使大部分努力化為烏有。第一步應該是為你的應用選擇正確的資料中心和正確的網路。
重建對網路距離的直覺認知
因為網路不像 CPU 或 RAM 那樣可見，所以很難建立對它的直覺。為了使其更容易理解，可以用交通運輸來類比。
當你思考網際網路時，想象：
- 你的伺服器是出發點
- Solana 驗證者或 RPC 端點是目的地
然後想象在這兩點之間駕車或乘飛機。
短途旅程：
- 紅綠燈和十字路口更少
- 更少受到擁堵影響
- 到達時間變化不大，通常準時
長途旅程：
- 需要高速公路、隧道和樞紐機場
- 經過許多中間點
- 更容易受到施工、事故或交通擁堵的影響
因此，到達時間的變化要大得多。
網路的行為方式相同：
- 更短的光纖電纜
- 更少的中間路由器和交換機（十字路口和樞紐）
意味著更短的往返時間和更少的抖動。
頻寬（1Gbps、10Gbps、25Gbps）就像道路的車道數。
更多車道允許更多資料並行流動並減少擁堵。但即使有很多車道，如果路線過長或迂迴，總行程時間仍然會很大。
在 Solana 上，如果你想要真正的速度，你需要兩者兼備：
- 足夠的車道（頻寬）
- 短距離和高效的路由
Solana 的結構如何放大距離的影響
在 Solana 上，區塊由每個 slot 輪換的領導者驗證者產生，領導者分佈在世界各地。
目前，許多驗證者集中在法蘭克福等地區。然而即便如此，領導者仍會在以下地區間輪轉：
- 法蘭克福
- 紐約
- 東京
- 新加坡
以及全球其他地區。
在這種結構中：
- 當領導者在法蘭克福時，法蘭克福網路內的節點具有明顯優勢。
- 當領導者在東京時，靠近東京的節點具有優勢。
這是一個非常簡單但非常強大的現實。
洲際通訊僅往返 ping 就通常需要超過 100ms。例如：
- 從法蘭克福追趕東京的領導者
- 從東京追趕紐約的領導者
這意味著當你加上 Shreds 流的接收和處理時，你的有效檢測時機可能輕易延遲 1000ms 或更多。對於交易和監控應用來說，這個時間差距是巨大的。
為什麼僅追求平均延遲是不夠的
許多使用者首先關注的指標是：
- 平均 ping
- 平均響應時間
這些是有用的，但在像 Solana 這樣領導者逐 slot 在全球移動的網路中，以下兩者之間存在巨大差異：
- 擁有良好的平均值
- 在關鍵時刻保持快速
即使某種配置顯示平均延遲為 200ms，實際上你可能看到：
- 某些 slot 20ms
- 其他 slot 600ms
對於 0-slot 交易或任何依賴在 200-400ms 視窗內完成的策略，重要的不是平均值：
- 而是你能否以低延遲執行
- 在確切的關鍵時刻
- 在你的目標地區內
每當你試圖命中位於另一個大洲的領導者時，總會有一些 slot 你在物理上無法跟上。
如果你只關注平均延遲而忽略這個現實，你將始終停留在"不知道為什麼總在輸"的狀態。
定位你的應用實際在哪裡變慢
接下來，讓我們看看如何識別你的應用在哪裡丟失了時間。
測量你當前的延遲
首先，用數字而不是感覺來測量到你當前端點的距離。
- 你當前的 RPC / gRPC / Shredstream 端點
- 位於與這些端點相同地區的節點
對它們執行 ping 測試並記錄往返基準。
不要依賴單次測量。
在短時間間隔內執行多次 ping，檢視中位數而不僅僅是均值。這能更好地反映當天的"路況"。
分離網路時間和應用處理時間
在你的應用中，記錄：
- 請求傳送時間戳
- 響應接收時間戳
- 內部處理的開始和結束時間
然後分離：
- 網路往返花了多少時間
- 實際業務邏輯花了多少時間
在許多情況下，你會發現：
- 你的程式碼在幾毫秒到幾十毫秒內就完成了
- 網路往返消耗了幾百毫秒
典型瓶頸模式
一些常見模式包括：
- 從世界各地使用同一個 RPC 端點
- 從家裡或辦公室透過多層 VPN 和代理連線
- 將伺服器部署在單一地區，試圖從那裡追趕全球的每個領導者
在這些配置中，Solana 的結構幾乎保證你總是在從不利位置攻擊某些領導者。
讓網路距離為你所用的設計方法
要讓網路距離為你服務而非與你作對，有幾個關鍵步驟。
確定你實際在哪個網路中競爭
對於 Solana，你關心的"網路"是由驗證者構建的網路。
領導者 slot 的頻率與質押量成正比，因此：
- 託管大量質押驗證者的網路
在實踐中實際上成為"主要網路"。
首先了解：
- 哪些地區接近對你策略重要的市場或 dApp
- 你計劃如何覆蓋法蘭克福等質押密集地區
這就是你決定實際要在哪些網路中競爭的方式。
資料中心和網路選擇
對於 Solana 工作負載，瞭解以下幾點至關重要：
- 你是否與關鍵驗證者或 Jito Block Engine 在同一資料中心
- 還是透過 PNI（專用網路互聯）與它們連線
網際網路是全球性的，原則上你的應用放在哪裡都能"工作"。
然而，對於 HFT 或近實時檢測，主要問題變成了：
- 你能消除多少外部網路流量？
- 你能多接近零距離配置？
這些選擇創造了第一個重大效能差距。
邁向多地區架構
理想情況下你會在每個地方都有部署，但你不需要從第一天就覆蓋所有地區。
一個實際的第一步可以是：
- 法蘭克福（主要網路）
- 加上一個對你策略重要的地區（紐約、東京、新加坡等）
從少量地區開始，你可以逐步擴充套件。
在每個地區，你：
- 在本地接收 Shreds 和 gRPC
- 在本地完成處理，或透過你自己的網路以最短路徑轉發
這使得維持"在任何給定時間在某處保持最快"的狀態變得容易得多。
ERPC 的網路設計以及 Bundle / VPS 如何融入
現在，讓我們將上述思路對映到 ERPC 的設計和產品線。
專為 Solana 打造的網路和基於 PNI 的架構
ERPC 是作為專為 Solana 設計的網路而構建的。我們精心選擇：
- 質押集中的地區
- 託管主要驗證者和 Jito Block Engine 的資料中心
- 透過 PNI 直接連線到這些核心位置的資料中心
構建出能夠為 Solana 工作負載提供最大輸出的拓撲結構。
網際網路是全球性的，你的應用無論部署在哪裡都能執行。
但當你關心 HFT 或快速檢測時，必須首先選對資料中心和網路。ERPC 正是專門為 Solana 解決這個問題而設計的。
基於 Ping 的自動路由
對於共享 Solana RPC 端點，ERPC 不依賴 IP 地理定位。
相反，我們：
- 自動測量從每個地區到每個白名單 IP 的 ping
- 根據實際測量結果選擇最近的地區
這避免了以下問題：
- 地圖上看起來很近但實際走了遠路的路由
- 基於過時地理定位資料庫的路由決策
確保你始終透過我們能在實踐中測量到的最短路徑連線。
Solana RPC Bundle 方案
Solana RPC Bundle 方案為你提供：
- RPC（HTTP / WebSocket）
- Geyser gRPC（無過濾限制）
- Shredstream gRPC
整合在一個套餐中。
大多數團隊透過 Geyser gRPC 開始他們的實時 Solana 之旅。由於它提供已解碼的資料：
- 實現更簡單
- 有許多示例和參考
- 學習曲線相對平緩
同時，專業團隊會新增 Shredstream 以將檢測和執行推向前沿。
透過 Bundle：
- 你可以保持現有的生產 RPC / gRPC 配置
- 可以以較小的額外成本新增 Shredstream
定價設計使你能夠：
- 使用 RPC + gRPC 構建穩定的基礎應用
- 然後在相同環境中開始試驗 Shredstream，逐步進入更高效能
所有這些都不需要停止你的生產系統。
EPYC VPS / Premium Ryzen VPS
為了進一步縮短網路距離，ERPC 還在與 ERPC 端點相同的網路內提供 VPS 服務。
產品線包括：
- 價效比優異的 EPYC VPS
- 基於 5.7GHz Ryzen CPU 的 Premium Ryzen VPS
這些環境提供：
- 高主頻 CPU
- ECC DDR5 記憶體
- NVMe4 儲存
- 25Gbps × 2 網路
全部針對 Solana 工作負載進行調優。
這些 VPS 例項執行在與以下元件相同的網路中：
- Jito Block Engine
- Shredstream 節點
- Geyser gRPC 節點
這種"零距離"配置允許你在不跨越外部網路的情況下，在領導者附近執行你的應用。
透過將 Bundle 方案與這些 VPS 產品結合，你可以同時最佳化：
- 網路距離
- 硬體效能
- 資料流質量
為延遲敏感的用例構建堅實基礎。
從哪裡開始（檢查清單）
以下是你閱讀完本文後可以立即採取的步驟：
-
測量到你當前 RPC / gRPC / Shredstream 端點的 ping 在短時間內多次測量，檢視中位數而非單次樣本。
-
在你的應用中新增日誌以分離網路時間和處理時間 測量請求傳送 → 響應接收，以及這兩個時間點之間的內部處理。
-
檢查哪些地區實際上靠近你的目標市場或 dApp 如果可能，從多個候選地區測量 ping，使你的決策基於資料而非直覺。
-
在靠近關鍵目標的地區部署單個 VPS 或 Bundle 並執行對比測試 記錄並比較你的延遲相比現有環境改善了多少。
-
根據需要擴充套件到多地區架構 例如：法蘭克福 + 紐約，法蘭克福 + 東京，或法蘭克福 + 新加坡，取決於你的策略。
-
長期來看，收集有關領導者時間表和驗證者位置的資料 建立你自己對哪些地區在什麼時間有優勢的理解，並根據 epoch 變化持續調優你的網路佈局。
總結：為什麼應該從網路距離開始
如果你想在 Solana 上構建快速的交易或監控系統，你需要同時考慮程式碼、硬體和網路。其中，網路距離是：
- 最大的改進槓桿之一
- 最常被忽視的延遲來源之一
只要你從遙遠的網路追趕領導者，總會有一些 slot 你在物理上無法贏得，無論你的程式碼和伺服器最佳化得多好。
因此你應該：
- 正確測量你的網路距離
- 瞭解你實際在哪些網路中競爭
- 將應用遷移到對 Solana 有意義的位置
這些是通往真正效能的第一步。
ERPC 和 Validators DAO 提供專為 Solana 設計的網路和伺服器資源，使這些架構在實踐中切實可行且易於獲取。
如果你想討論網路距離最佳化或如何配置你的 Bundle 和 VPS 方案，歡迎透過 Validators DAO 官方 Discord 聯絡我們。
- ERPC 官方網站：https://erpc.global/en
- Validators DAO 官方 Discord：https://discord.gg/C7ZQSrCkYR
