常見問題 - Solana Shreds
問：我的 Shreds / getBlock 輸出突然壞掉，或是回傳 -32015，發生了什麼變化？
Solana Transaction v1（SIMD-0385）已於 2026 年 9 月 15 日在 Solana 主網上線，對應 epoch 1035。v1 交易的 wire 格式以版本前綴位元組
0x81 開頭，簽章位於訊息之後，而且不再有 legacy 的長度前綴。如果您自行解碼 ShredStream 或 UDP Forwarding 的 entry，低於 4.2 版的
bincode 或 solana-entry 解碼器會把這個 0x81 位元組誤判為簽章數量，表現為 EOF 錯誤、compact-length 溢位，或 "invalid message version" 錯誤。使用 4.2 之前的 crate 反序列化原始交易的 Geyser gRPC 使用者也會碰到同樣的問題。以 maxSupportedTransactionVersion: 0 呼叫 getBlock 和 getTransaction 時，RPC 會回傳 -32015 Transaction version (1) is not supported by the requesting client；getTransactionsForAddress 在 full 模式下會對每一筆受影響的資料列回報同樣的錯誤。如果您已經在讀取 ERPC 解析後的 JSON 回應並設定了 version 1，則不受影響。在 options 物件中把
maxSupportedTransactionVersion 設為 1，也就是 getBlock 和 getTransaction 的第二個參數，以及 getTransactionsForAddress 的 options：json
將 Solana Stream SDK 升級到
2.0.0：crates.io 上的 Rust solana-stream-sdk，或 npm 上的 @validators-dao/solana-stream-sdk 與 @validators-dao/solana-shreds-client。@validators-dao/solana-entry-decoder 需另外升級到 2.5.0。1.4.0 與 entry-decoder 2.4.0 不支援 v1。自行撰寫的 Rust 解碼器應改用 solana-entry 4.2.x。- 遷移指南
- SDK 2.0.0 版本說明
- Solana Stream SDK 儲存庫
- SIMD-0385：Transaction v1 提案
- Solana 升級：Larger Transaction Sizes
- Solana RPC 文件：getBlock
- Solana RPC 文件：getTransaction
- ERPC 文件：ShredStream 快速入門
- ERPC 文件：Geyser gRPC 快速入門
- ERPC 文件：RPC
問：你們的節點位於哪些區域？
我們目前在以下區域營運節點：
- 法蘭克福（FRA）
- 阿姆斯特丹（AMS）
- 倫敦（LON）
- 都柏林（DUB）
- 紐約（NY）
- 芝加哥（CHI）
- 鹽湖城（SLC）
- 東京（TY）
- 新加坡（SGP）
- 雪梨（SYD）
ERPC 基於實際路由路徑測量網路延遲，自動選擇延遲最低的區域，而不是依賴直線距離。這種方法不僅能改善單個使用者的延遲，還能提高整體網路效率，並增強 ERPC 對潛在攻擊的全球抵禦能力。
如果您的環境未能自動選擇最佳區域，請透過 ERPC Web Dashboard 聯絡我們。
ERPC Web Dashboard: https://dashboard.erpc.global/zh-tw
問：延遲顯示 9999ms 且選擇了非最佳區域。該怎麼辦？
選擇 Shreds 區域時，ERPC 會從下列代理主機向您已註冊的 IP 傳送 ICMP 延遲探測。請允許來自所有列出來源 IP 的傳入 ICMP Echo Request。如果防火牆（ufw、雲端防火牆、安全性群組等）阻擋這些要求，測量結果可能變為
9999ms，並可能選到非最佳區域。同一區域中的多個 IP 分別屬於不同的探測主機，必須全部允許。已選擇 Far Point
Shared Shreds 的 Far Point 是容量有限的備援選項。每個端點為所有客戶提供的同時代理串流總數最多為 32 條，而不是每位客戶各有 32 個名額。訂閱端在所選 Shreds 端點附近執行時，串流效能最佳；長距離串流會更長時間占用共用連線、流量控制視窗與輸出容量。為協助維持共用環境的回應能力，請允許所有列出的區域 ICMP 探測來源 IP 位址，並再次執行區域選擇。如需持續使用，請考慮在所選端點附近使用 ERPC VPS。UDP Forwarding 提供 Standard 與 Premium。無論使用哪一種，UDP Forwarding 的區域都在 ERPC Web Dashboard 中選擇，原始 Shreds 則透過 UDP 送達您設定的公開 IPv4 位址與連接埠。
問：我已經將 IP 加入白名單，但仍然無法連線。應該檢查什麼？
使用 Dashboard 中選取的加密 HTTPS 端點；HTTPS 使用 443 連接埠。HTTP 使用 80 連接埠，仍是未加密的低延遲選項。
兩種傳輸方式使用相同的已註冊 IP 白名單。使用 Dashboard 中選取的端點：HTTPS 使用 443，HTTP 使用 80。
- HTTPS 端點：使用 Dashboard 中選取的端點和 443 連接埠。
- HTTP 端點：使用 Dashboard 中選取的端點和 80 連接埠。
- 使用 Dashboard 中顯示的 URL，並採用
https://或http://格式。
認證基於您已註冊的 IP 位址。除非特定產品頁面明確要求，否則不要加入
x-token、token 或 Authorization 標頭。問：我以前只用過 WebSocket 或 Geyser gRPC（YellowStone）。你們有示例嗎？
有。您可以使用 SLV 快速開始測試 Shreds 連線和應用程式開發。
請參閱以下指南瞭解詳情：
問：我可以註冊兩個 IP 位址嗎？
每個訂閱可以使用一個端點。如果您希望使用兩個 IP 位址，則需要兩份獨立的訂閱。
問：推薦哪個區域？
沒有一個永遠最好的區域。Solana 是全球網路，leader 角色依照 Leader 排程在驗證者之間轉移。驗證者數量和質押量較多的區域中，leader slot 出現的頻率更高，這有助於交易更快上鏈。但相應地，競爭流量也會同步集中，因此根據您的策略，競爭相對較少的區域有時反而能取得更好的效果。
一個實用的起點是：當穩定的 leader slot 供給最為重要時，選擇驗證者集中的區域，例如法蘭克福或美國東海岸；當最短路徑執行是首要目標時，則將基礎設施部署在特定目標驗證者附近。請使用 Validators Solutions 瞭解 Solana 網路的公開分佈，然後結合 ERPC Leader Slot API 和實際測量判斷單區域、雙區域或全球部署是否合適。
問：我需要約 400ms 或更低的延遲。
要實現約 400ms 以內的延遲，請考慮以下要點：
-
對 Ping 值的現實理解：Ping 值表示理想條件，不反映串流通訊中的實際延遲，後者通常約為 ping 延遲的 5 倍。例如，跨洲 100ms 的 ping 實際上會導致約 500ms 的延遲。因此，必須在同一區域內建立基礎設施才能實現約 400ms 的延遲。
- 典型 Ping 值參考：
- 同一網路：~0.1ms
- 私有網路互連（PNI）：~0.2ms
- 同一資料中心：~0.3ms
- 同一城市：~1ms
- 鄰國：~5–10ms
- 跨洲：~100–300ms
- 典型 Ping 值參考：
-
避免平均延遲的陷阱：Solana 驗證者分佈在全球各地，且 Leader 排程在每個 epoch 隨機變化。依賴平均延遲來實現約 400ms 是不切實際的。相反，您應該精確追蹤特定區域的驗證者排程，以識別延遲最低的 slot。要持續實現最小延遲，需要在所有相關區域部署基礎設施。在同一區域內，資料取得可以在幾十毫秒內完成，傳輸可以在幾毫秒內完成。
-
追蹤 Leader 排程：透過 ERPC Leader Slot API（
getLeaderSlots），監控您所在區域的 Leader 驗證者排程。 它會回傳即將到來的 Leader 排程、目前 epoch 的質押權重、推估的驗證者地理位置以及參考 ping 值，讓您能趕在延遲最低的 slot 到來之前識別出它們，並將其設為目標。 公共地圖型資料來源和原生 RPC API 適合瞭解網路整體分佈，但精確度不足以用於判斷執行時機。Leader Slot API 補足了路由和交易判斷所需的粒度。
Solana 網路資料：Validators Solutions
問：如何實現零區塊（零 slot）交易？
成功實現零區塊（零 slot）交易需要更複雜的策略，如下：
-
識別機會區域：Solana 驗證者分佈在全球各地，物理上不可能對每個 slot 都實現最佳延遲。因此，監控您基礎設施所在區域的驗證者 Leader 排程，並識別最有利的機會區域。在多個區域部署基礎設施也可能有利。例如，法蘭克福是關鍵區域，因為其驗證者密度高，Leader 選擇更頻繁，交易機會更多。透過 ERPC Leader Slot API（
getLeaderSlots），查詢即將到來的 Leader 排程、目前 epoch 的質押權重、推估的驗證者地理位置資料以及參考 ping 值，精確度遠高於公共地圖型資料來源或原生 RPC API。如此一來，您就能在相應 slot 到來之前預先標出機會區域，並執行接近零延遲的交易。 -
部署專用節點：如果您難以競爭，請考慮部署專用節點。共享節點由於其他使用者的流量會產生延遲，因此不建議使用。此外，將您的專用節點放置在與應用程式相同的網路中可以顯著降低網路延遲並最佳化效能。
問：我可以使用特定端點嗎？
為了維持低延遲環境，我們的系統會自動選擇最近的可用節點。如果您希望使用特定端點，我們建議租用距離該端點最近的伺服器。
問：為什麼專用端點更快？
共享端點由多個客戶共同使用相同的資源。隨著流量增加，延遲往往會出現。伺服器資源有物理限制，它們能處理的工作量是有限的。當太多請求同時到達時，必須按順序處理，這會導致回應時間變慢。
儘管我們採取了各種措施來最佳化共享端點的效能，但使用專用端點時您是資源的唯一使用者。這意味著您完全不受其他使用者的影響，確保始終穩定且快速的回應。
此外，專用端點提供無 TLS 的通訊選項，如 HTTP。透過跳過 TLS 握手（約 20ms），通訊比 HTTPS 更快。
問：簽約後價格會被上調嗎？
在訂閱有效期內，您簽約時鎖定的價格將保持不變。能夠承擔 Solana 即時工作負載的執行環境在全球範圍內都很稀缺，我們計劃隨著硬體和網路需求的持續成長，分階段上調價格。高規格配置和需求集中的區域庫存會更快售罄，因此以目前的價格鎖定訂閱是長期控制成本最有利的選擇。
問：我想用加密貨幣支付
當註冊帳單地址的國家/地區屬於歐盟成員國時，即可在 ERPC Web Dashboard 中使用加密貨幣付款。如果帳戶中註冊的支付卡片全部由歐盟以外發行，則無法使用加密貨幣付款。您可以使用 SOL、USDC 或 EURC 購買 ERPC Credits。
這些 ERPC Credits 可用於啟用或續用 ERPC 方案。開啟儀表板，選擇「Crypto 付款」，從您的錢包發起轉帳，儀表板會驗證這筆交易，並將 Credits 記入您的帳戶。
支援國家/地區：奧地利、比利時、保加利亞、克羅埃西亞、賽普勒斯、捷克、丹麥、愛沙尼亞、芬蘭、法國、德國、希臘、匈牙利、愛爾蘭、義大利、拉脫維亞、立陶宛、盧森堡、馬爾他、荷蘭、波蘭、葡萄牙、羅馬尼亞、斯洛伐克、斯洛維尼亞、西班牙、瑞典。
如果您的國家/地區不在清單中，請使用信用卡付款。
問：為什麼 ShredStream 不包含所有交易？
按設計，Shreds 不包含 Solana 區塊鏈上的每一筆交易。監控所有交易需要在全球部署大量代理並從每個驗證者接收 Shreds，這在實踐中不可行。
通常，使用者使用可用資料的子集進行操作，因為這種方法對於大多數實際應用已經足夠。如果您的使用場景需要完整的資料覆蓋而不能有任何遺漏，Shreds 可能不適合。
對於需要更全面監控的場景，Geyser gRPC 提供比 Shreds 更高的可靠性。不過，要在 Solana 區塊鏈上達到 100% 的資料覆蓋率，仍需部署大量邊緣伺服器，這在實務上可能不切實際。
Geyser gRPC 的可靠性超過 99%，明顯高於 Shreds，這一點已獲得包括我們在內的眾多使用者證實。而 Shreds 的可靠性通常在 90% 以上。
雖然它們不能捕獲每一筆交易，但其關鍵優勢在於能夠比 Geyser gRPC 更快地檢索大多數交易。
如需更深入瞭解，我們推薦探索 Solana 的 Turbine 和 Gulf Stream 協定：
問：我想要最好的環境。
UDP Forwarding 提供 Standard 與 Premium。兩者都從您所選區域將 Shreds 送達您的接收端。使用 Standard 時，ERPC 從該區域的一個節點將 Shreds 轉送給您，因此您會從單一來源 IP 收到 Shreds。使用 Premium 時，網狀網路轉送每個 Shred 的副本中最先抵達該網路的那一份。無論使用哪一種，都請在 ERPC Web Dashboard 中選擇區域，並設定接收原始 Shreds 的公開 IPv4 位址與連接埠。
如需瞭解更多詳情，請透過 ERPC Web Dashboard 聯絡我們。
問：延遲是怎樣的？
延遲因測量方法和您的具體使用環境而異。與其關注精確的數值，更重要的是確保延遲滿足您的實際營運需求。
我們提供易於使用的 TypeScript 和 Rust 延遲測量工具。
問：這個 RPC（gRPC、Shreds）比其他的快嗎？
我們在每個價格檔位都以速度為設計目標，歡迎您把我們與任何其他供應商放在同等條件下比較。結果會隨區域、使用共享端點或專用端點、所用協定（WebSocket、gRPC 或 Shreds）以及用戶端的程式語言而變化。
如果您發現我們的服務更慢，請透過 ERPC Web Dashboard 告訴我們您比較的具體條件和競爭對手。我們將找出原因並進一步提高速度。
問：哪個方案提供最快的效能？
通常，我們最高等級的方案由於更優秀的 CPU、更大的記憶體容量和強大的硬體配置而提供最快的效能。
如果您需要更強大的伺服器，我們還提供客製化解決方案，但我們的標準方案旨在提供最佳的價效比。
我們有信心在每個價位都提供世界級的效能。如果您在相同價格範圍內找到更快的供應商，請告訴我們，以便我們調查和改進。
問：我遇到了高延遲。為什麼？
問：WebSocket、gRPC 和 Shreds 哪個最快？
根據客戶回饋，效能排序如下：
Shreds > gRPC > WebSocket
如果您的體驗與此不同，請告訴我們。
問：延遲不如預期。
效能會因所使用的程式語言而有顯著差異。一般而言，效能排序如下：
Rust > Go > TypeScript (JavaScript) > Python
詳細比較請參閱：
為了獲得最高效能，我們強烈推薦使用 Rust。