ERPC

ERPC 將 Solana v4 的 XDP 高速路徑與 zero-copy 在全區域的 RPC 節點與 Geyser gRPC 節點正式上線 — 把在 NY 的實證擴展至所有區域，同時提升串流送達與 RPC 狀態鮮度

ERPC 將 Solana v4 的 XDP 高速路徑與 zero-copy 在全區域的 RPC 節點與 Geyser gRPC 節點正式上線 — 把在 NY 的實證擴展至所有區域，同時提升串流送達與 RPC 狀態鮮度

ERPC 將 Solana v4 的 XDP 高速路徑與 zero-copy 在全區域的 RPC 節點與 Geyser gRPC 節點正式上線 — 把在 NY 的實證擴展至所有區域，同時提升串流送達與 RPC 狀態鮮度
營運 ERPC 的 ELSOUL LABO B.V.（總部：荷蘭阿姆斯特丹；CEO：川崎文武）與 Validators DAO，謹此宣布 ERPC 已將 Solana v4（Agave 4.x）的 XDP 高速路徑與 AF_XDP zero-copy，正式套用於全區域的 RPC 節點以及 Solana Geyser gRPC 節點。這是把率先在紐約（NY）區域的 Geyser gRPC 來源端實證的最佳化，擴展至所有區域的正式環境基礎設施。
XDP 高速路徑與 AF_XDP zero-copy，是在 Solana v4（Agave 4.x）開始可用的針對 Turbine 的最佳化。至於啟動旗標，Agave 4.1 系列已將 --experimental-retransmit-xdp-* 系列標記為棄用，並整理為 --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy。ERPC 在這個針對 Turbine 的 XDP 高速路徑與 zero-copy 的基礎上，不僅將其套用於支撐 Geyser gRPC 的來源端節點，也套用於 RPC 節點的正式環境。RPC 節點與 Geyser gRPC 節點，都經由 Turbine 接收構成區塊的 shred。透過 XDP 與 zero-copy 降低該 shred 傳播與接收路徑上的核心開銷，Geyser gRPC 的串流送達延遲得以縮短，而 RPC 則獲得更佳的狀態鮮度，以及更能跟上最新狀態的能力。本次更新已在全區域的正式環境中運行。重視 first-arrival 效能的客戶，可立即試用全區域的 RPC 與 Geyser gRPC — 無論是透過時間計費（以每小時為單位），或是 Crypto Pay（SOL / USDC / EURC）。
ERPC 官方網站: https://erpc.global/zh-tw ERPC 儀表板: https://dashboard.erpc.global/zh-tw

全區域展開改變了什麼 — 讓抓取 shred 的路徑，在任何地方都更快

在 Solana 上，負責區塊生成的 leader 會以短週期輪替，因此通訊的起點始終在移動。在這樣的結構下，實務上真正重要的，並非靠近某個固定的單一點，而是有高機率靠近主要節點與驗證者高度集中的網路 — 這會直接影響實際營運中的延遲、重送率與失敗率。正因如此，ERPC 認為有意義的，不是只讓單一一台機器變快，而是把每個區域的正式環境節點都提升到相同的水準。
本次展開的重點，在於最佳化的對象放在「Turbine 上的 shred 傳播與接收路徑」。無論是 RPC 還是 Geyser gRPC，最終的速度都取決於「節點能多快抓取一個區塊」。XDP 與 zero-copy 正是降低那個抓取階段 — 也就是經由 Turbine 接收、retransmit 與傳播 shred — 之開銷的最佳化。將其套用於每個區域的正式環境節點後，無論客戶使用哪個區域的連線點，都能在經過最佳化的路徑上接收資料。

Solana v4 的 XDP 高速路徑與 zero-copy 是什麼

XDP（eXpress Data Path）是一項 Linux 核心技術，讓高效能的網路程式碼能夠繞過核心通常的封包處理路徑的大部分。透過減少資料複製與情境切換，它能以遠比標準網路堆疊更低的開銷處理封包。
在 Agave（Solana 的驗證者用戶端）中，XDP 被套用於 Turbine — 也就是在驗證者節點之間傳播區塊的協定。接收到的 shred 會由附掛在網路介面卡（NIC）附近的 eBPF 程式處理，並經由 AF_XDP 對映到使用者空間的緩衝區。當使用 zero-copy 模式時，接收到的資料會直接從核心交付給使用者空間，無需複製。對於外送的 shred，同樣會運用 AF_XDP 的傳送路徑，以降低熱路徑上的複製與系統呼叫開銷。
Anza 在 Agave 3.x 系列（自 v3.0.9 起）為 Turbine 導入了 XDP，並將其延續至 Solana v4（Agave 4.x）的基礎。啟動旗標已透過歷次發布逐步整理：Agave 4.1 系列將 --experimental-retransmit-xdp-* 系列標記為棄用，並整理為 --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy。根據 Anza 的設定指南，在使用 XDP 的情況下，大型驗證者可透過 Turbine 的 fanout，使外送封包逼近每秒 150,000 個。
Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

套用於 Geyser gRPC 節點 — 加速來源端的接收

Geyser gRPC 是一條以串流而非輪詢的方式，接收帳戶、slot、區塊與交易更新的路徑。在這裡，一毫秒的差距直接關係到捕捉成交機會，以及前端所感受到的速度。Geyser 的延遲，最終取決於「來源端能多快抓取一個區塊」。
XDP 與 zero-copy 正是降低那個來源端 shred 傳播與接收路徑開銷的最佳化。當來源端能更快地接收與傳播 shred，便能在更早的階段觀測與重建區塊，從而縮短這些更新經由 Geyser gRPC 串流送達客戶的延遲。在我們率先套用的紐約（NY）區域，我們已透過開源量測確認，這項最佳化對送達延遲的尾端區段確實有效。如今，我們已將相同的最佳化擴展至所有區域的 Geyser gRPC 節點。

套用於 RPC 節點 — 提升狀態鮮度與跟上最新狀態的能力

本次展開的新意，在於我們也把這項最佳化套用於 RPC 節點。RPC 節點同樣經由 Turbine 接收構成區塊的 shred，並更新自身的帳本與狀態。當 XDP 與 zero-copy 降低了那個基於 Turbine 的 shred 接收與傳播開銷，RPC 節點便能更快地接收更新的區塊。
對使用 RPC 的客戶而言，這並非所有 RPC 方法都會一致變快，而是會以節點所持有狀態的鮮度呈現出來。當你查詢最近的 slot 或區塊，或某個帳戶的最新狀態時，節點已接收的資訊更新這一點，直接關係到回應中資料的鮮度。此外，傳播與接收路徑上更低的開銷，也意味著節點在高負載下能毫無遺漏地處理更新的餘裕。與 Geyser gRPC 串流送達相同的最佳化，同樣作為支撐 RPC 所回傳資料鮮度的基礎而運作 — 這正是我們這次將範圍擴展至 RPC 節點的原因。

推進到每個區域的正式環境節點 — 我們啟用了什麼

ERPC 將全區域的 RPC 節點以及 Geyser gRPC 節點遷移至 Solana v4（Agave 4.x），並把針對 Turbine 的 XDP 高速路徑與 AF_XDP zero-copy 投入正式環境。在 Agave 4.1 系列整理出的 --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy 啟動旗標體系的基礎上，我們依各區域的組態加以啟用。
啟用 XDP 需要高階且容易出錯的調校：較新的核心、支援 XDP 的 NIC、驗證者程序所需的正確 systemd capabilities、正確的啟動旗標，以及適當的 CPU 核心釘選。要將其部署的不是單一節點，而是每個區域的正式環境節點 — 同時驗證各區域不同的 NIC、核心與網路組態 — 更進一步提高了營運的難度。ERPC 將在網路頂端營運驗證者所累積的營運知識，直接應用於各區域來源端節點與 RPC 節點的建置與營運。
而這項最佳化的營運知識，已作為配方匯整於開源的 Solana 營運工具 SLV 之中。SLV 提供從啟用 XDP（透過 xdp_enabled / xdp_zero_copy 等組態變數）到量測送達延遲（slv check geyserbench）的一切，並以任何人都能透過與 AI 代理對話或經由 CLI 重現的形式呈現。ERPC 在全區域達成的最佳化，並非為單一機器準備的一次性技巧，而是建立在可重現的營運配方之上。
SLV GitHub: https://github.com/validatorsDAO/slv

從你自己的連線、用你自己的數字驗證

這項最佳化能帶來多大的差距，會隨連線來源、路徑、時段與 leader 分布而變動。正因如此，ERPC 重視的，是透過任何人都能以相同方法驗證的量測來呈現送達品質，而非主觀的主張或宣傳文案。客戶能夠確認的，並非固定的數字，而是量測方法本身。
關於 Geyser gRPC，ERPC 的基準測試工具已開源公開。在 first-arrival 的比較上，你可以使用 slv check geyserbench --kind grpc；而要確認個別端點的連通與延遲，則可使用 slv check grpc，在接近自身工作負載的條件下直接進行比較。RPC 也是如此 — 最可靠的做法，是用你自己的 bot 或應用程式實際送出的請求，從你自己的連線點量測並觀察回傳資料的鮮度以及回應的行為。
能夠依據自己量測出的數字，而非廠商的主張來做決策，是重視 first-arrival 效能的客戶的起點。從安裝 SLV 到執行量測的步驟，已公開於 SLV 的 Getting Started 指南。
SLV 官方網站: https://slv.dev/zh-tw SLV Getting Started: https://slv.dev/zh-tw/doc/general/getting-started/ Solana Geyser gRPC 速度比較: https://erpc.global/zh-tw/doc/geyser-grpc/speed-comparison/

從設計上抑制距離造成的延遲 — AS200261 Solana 專用資料中心

ERPC 的延遲優勢，並非僅來自軟體最佳化。透過將來源端節點、接收端點與處理節點，配置於 Solana 驗證者高度密集的優質資料中心內，ERPC 在設計階段就抑制了距離造成的延遲。
ELSOUL LABO 以 RIPE NCC 所核配的自有 ASN（AS200261），營運一座 Solana 專用資料中心，作為 ERPC 平台的一部分。像今日的 XDP 與 zero-copy 這類軟體最佳化，唯有建立在這樣的物理與網路近接設計之上，才能發揮最大的效果。當設計層級的近接，與節點側的軟體最佳化兩者兼備，first-arrival 效能、低延遲的串流品質，以及鮮度高的 RPC 回應便得以實現。

持續強化基礎設施的脈絡

本次的全區域展開，位於 ERPC 持續推進的基礎設施強化脈絡之中。它是繼 2025 年 12 月全區域 Geyser gRPC 基礎設施升級、2026 年 1 月法蘭克福（FRA）區域的大規模強化，以及 2026 年 6 月在紐約（NY）區域率先套用 XDP 與 zero-copy 之後，最新世代的最佳化。在 NY 實證的最佳化，如今已把 RPC 節點納入範圍，並擴展至所有區域的正式環境基礎設施。
ERPC 一貫採取的方針，是面對需求增長時，不以限制或降級因應，而是藉由強化基礎設施本身來加以吸收。我們在反覆驗證相容的 NIC、核心與網路組態的同時，持續將最新世代的最佳化反映到正式環境基礎設施中。ERPC 的 RPC 與 Geyser gRPC，今後也將持續演進。

用時間計費，從一小時開始驗證

ERPC 的 RPC 與 Geyser gRPC，可透過時間計費方案從一小時開始試用。如此一來，便能成立一個風險受控的驗證循環：只簽約一小時，在那段時間內確認從你自己的 bot 或應用程式連線點所見的實際行為，並依結果決定是否轉為月繳或年繳方案。前述以 slv check 進行的量測，也可在這一小時的試用中直接執行。
當你的組態與使用量逐漸明朗，即使切換至月繳或年繳方案，仍可維持在相同的儀表板與相同的端點品質下繼續進行。
ERPC 儀表板: https://dashboard.erpc.global/zh-tw

支援 Crypto Pay（SOL / USDC / EURC）

ERPC 為購買 ERPC credit 以及支付各項方案提供 Crypto Pay，並同樣支援時間計費方案。你可選擇 SOL，或穩定幣 USDC / EURC 作為支付資產。EURC 可直接轉帳，而 USDC 或 SOL 則會經由 Orca 兌換為 EURC，並在同一流程中完成轉帳。
對於在 Solana 上開發與營運的團隊而言，能以接近既有錢包式資金管理流程的方式處理基礎設施費用，是一項降低開始驗證之摩擦的實務改善。前述以時間計費進行的驗證，同樣可直接從你 Solana 錢包中的資產開始。

在單一平台上訂購、付款並管理 Solana 專用基礎設施

ERPC 讓你能在單一平台上，組合運用 Solana RPC、WebSocket、Solana Geyser gRPC、Solana Shredstream、Direct UDP Stream（Raw Shreds）、VPS、裸機伺服器、專用 RPC、SWQoS、支援 Pyth 的 Price API，以及 Jet Analytics & Indexed RPC。
ERPC 儀表板支援 16 種語言，讓你能從同一畫面處理方案選擇、區域選擇、庫存確認、加入購物車、credit 加值、結帳、查看 API 金鑰與端點、確認使用狀況，以及建立支援工單。

Solana 專用基礎設施的研發與持續改善

ERPC 的背後，是 ELSOUL LABO 持續推進的 Solana 專用基礎設施研發。ELSOUL LABO 自 2022 年起，已連續五年在荷蘭政府的研發支援制度 WBSO 下獲得核准。它持續就 Solana RPC 基礎設施、驗證者營運、即時資料配送，以及 AI 代理輔助的營運與開發進行研發，而那些成果則反映在包括 ERPC、SLV、SLV AI，以及 AS200261 Solana 專用資料中心在內的各項服務之中。
今日在全區域對 Solana v4 / XDP / zero-copy 的支援，同樣是在網路頂端營運驗證者的過程中成形的。ERPC 今後也將持續在貼近 Solana 網路的位置提供低延遲的基礎設施，並以任何人都能用相同方法驗證的量測來證明其品質。

關於使用與諮詢

關於包含全區域 RPC 與 Geyser gRPC 在內的最佳區域組態、在 gRPC 單獨方案與 gRPC Bundle 方案之間的選擇、時間計費／月繳／年繳的取捨，以及從既有組態的遷移設計，我們在 Validators DAO 官方 Discord 提供個別諮詢。
ERPC 儀表板: https://dashboard.erpc.global/zh-tw ERPC 官方網站: https://erpc.global/zh-tw Validators DAO 官方 Discord: https://discord.gg/C7ZQSrCkYR
我們由衷感謝所有持續使用 ERPC 的用戶。

連結一覽

下一頁

ERPC 將 Solana Geyser gRPC 最快產品線「Burst」新增至東京 / Singapore — 把 ERPC 首批亞洲 Burst 邊緣帶到呼聲最高的兩個區域

新聞

ERPC 將 Solana Geyser gRPC 最快產品線「Burst」新增至東京 / Singapore — 把 ERPC 首批亞洲 Burst 邊緣帶到呼聲最高的兩個區域

ERPC 將 Solana Geyser gRPC 最快產品線「Burst」新增至東京 / Singapore — 把 ERPC 首批亞洲 Burst 邊緣帶到呼聲最高的兩個區域

ERPC 為其 Solana SWQoS Endpoint 新增 Amsterdam — 繼 Frankfurt 之後的第二個區域，呼聲最高的城市，現在可從 Dashboard 直接指派

ERPC 為其 Solana SWQoS Endpoint 新增 Amsterdam — 繼 Frankfurt 之後的第二個區域，呼聲最高的城市，現在可從 Dashboard 直接指派

ERPC 發布《How to be faster on Solana?》——一份以「網路距離的物理學」視覺化呈現 Solana 速度決定因素的報告，並附帶即時數據

ERPC 發布《How to be faster on Solana?》——一份以「網路距離的物理學」視覺化呈現 Solana 速度決定因素的報告，並附帶即時數據