🤖 最新推出:《Quicknode 人工智慧實戰手冊》 10 個經過實測的 AI 程式設計食譜agents 。
查看食譜 什麼是 RPC(endpoint )?JSON-RPC、WebSockets 以及gRPC |Quicknode
我們的電子報內容豐富,包含免費資源、Quicknode 最新動態、Web3 洞見等。
CLI、Admin API 、MCP、SDK ,以及適用於 75 條以上區塊鏈的 AI 原生工具。由開發者打造,為開發者而生。
涵蓋 Python、Ruby 及 JavaScript 的最新程式碼範例。關於智慧合約、NFT 及去中心化應用程式(dApps)的深入指南。
答案 > 了解 RPC 與 API > 什麼是 RPC(endpoint )? // Tags
RPCendpoint 什麼是 RPC JSON-RPC
簡而言之: RPCendpoint 是一組網址, 您的應用程式會透過它與區塊鏈節點進行通訊。RPC 代表「遠端程序呼叫」(Remote Procedure Call),這是一種讓一個程式能透過網路向另一個程式請求資料或執行動作的協定。在區塊鏈中,RPC 端點是錢包查詢餘額、去中心化應用程式(dapps)執行智慧合約,以及開發者讀寫鏈上資料的途徑。您進行的每一次區塊鏈互動,無論您是否察覺,都會透過 RPCendpoint 進行。
簡單的解釋 當您開啟錢包應用程式並查看您的 ETH 餘額時,您的錢包並非以某種方式「位於」區塊鏈上。它只是運行在您的手機或瀏覽器上的普通應用程式,需要向區塊鏈查詢您的餘額。為了進行這項查詢,它會向 RPC(endpoint )發送請求。endpoint 接收該請求後,其背後的節點會查詢答案,並將回應傳回。接著,您的錢包便會顯示該結果。
不妨將 RPCendpoint 視為餐廳的大門。廚房(區塊鏈節點)才是實際運作的地方:驗證交易、維護狀態、生成區塊。但您不會直接走進廚房。您會從大門(RPCendpoint )進入,下單(您的請求),然後由服務生(RPC 協定)將餐點(回應)送上。 RPCendpoint 是讓節點的功能對外界開放的存取點。
從技術層面來說,RPCendpoint 是一個 URL(例如 https://your-endpoint.quiknode.pro/your-token/),您的應用程式會將依照 JSON-RPC 規範格式化的 HTTP 或 WebSocket 請求傳送至此處。JSON-RPC 是一種輕量級協定,用以定義如何將請求與回應結構化為 JSON 物件。 每條主要區塊鏈都採用此標準的某個版本,這意味著一旦您理解了如何在Ethereum 上進行 RPC 呼叫,那麼在Solana 、Polygon 、Arbitrum 、Base 以及其他數十條區塊鏈上,其運作模式也大同小異。
RPC 呼叫的運作原理 典型的 RPC 互動遵循簡單的請求-回應模式。您的應用程式會建立一個 JSON-RPC 請求,其中指定要呼叫的方法及其所需的任何參數,然後透過 HTTP POST 將其傳送至endpoint 這個 URL。該節點會處理該請求、執行相應的邏輯,並回傳包含結果的 JSON 回應。
已通過 SOC 2 Type II 認證 · ISO 27001
例如,若要取得 EVM 鏈上的最新區塊編號,您的應用程式需傳送一個方法為「eth_blockNumber」、參數陣列為空的請求。節點會以十六進位制回傳當前的區塊編號。若要查詢某個帳戶的 ETH 餘額,您需呼叫「eth_getBalance」,並傳入錢包地址及區塊參數(例如傳入「latest」以取得當前區塊)。 若要發送交易,請傳遞已簽名的交易資料並呼叫「eth_sendRawTransaction」。
這些標準的 JSON-RPC 方法是由各區塊鏈的規格所定義的。Ethereum 的 JSON-RPC API 包含用於讀取區塊資料、查詢帳戶與合約狀態、估算 gas 費用、提交交易、透過 WebSocket 訂閱事件等方法。Solana 則採用一套類似但略有不同的 RPC 方法集,這些方法已針對其基於帳戶的架構進行了優化。每條鏈都有其專屬的 API 介面,但透過 RPC 端點進行的底層通訊模式仍保持一致。
WebSocket 連線是基本 RPC 模式的延伸,可實現即時、雙向的通訊。與其讓您的應用程式反覆輪詢節點以取得更新(這種做法既低效又緩慢),WebSocket 連線能讓節點將新資料推送至您的
即時應用程式。這對於諸如監控新區塊生成、即時監聽特定智慧合約事件,以及接收交易確認通知等使用情境而言,至關重要。
公開與私有 RPC 端點 公開 RPC 端點是由區塊鏈基金會或社群專案維護的免費、開放式 URL。任何人皆可無需驗證即可連線至這些端點。它們適用於快速測試、原型開發及教育目的,但不適合用於生產環境的應用程式。公開端點受到嚴格的速率限制(意即限制每秒可發送的請求數量),經常因數千名同時在線的用戶而超載,且無法保證系統可用性、延遲或資料新鮮度。 若您的應用程式依賴某個公開的endpoint ,而該端點在流量激增時發生故障,您的應用程式也將隨之癱瘓。
私有 RPC 端點是專為您的應用程式預留的專用連線,通常由基礎架構服務提供。它們提供更快的回應時間、更高的速率限制、穩定的效能,以及由服務水準協議 (SLA) 背書的正常運作時間保證。私有端點通常還包含其他功能,例如基於憑證的驗證、IP 白名單、分析儀表板,以及超越標準 JSON-RPC 規格的進階 API 存取權限。
對於任何處理真實使用者、真實資金或即時資料的應用程式而言,私有 RPC 端點是基本要求,而非進階選項。在生產環境中,公開與私有endpoint 之間的差異,就像是共用公共 Wi-Fi 網路與專用光纖線路之間的差異。兩者雖都能在技術上讓您連上網際網路,但只有其中一種適合用於營運業務。
超越基礎 RPC雖然標準的 JSON-RPC 方法涵蓋了讀寫區塊鏈數據的基本功能,但大多數生產環境中的應用程式需要更多功能。增強型 API 透過更高階的方法擴展了基礎 RPC 規範,這些方法能彙整數據並減少應用程式所需的呼叫次數。例如,與其透過數十次獨立呼叫來重建錢包中的代幣持有量,增強型 API 只需單次請求即可回傳所有代幣餘額。
串流與事件驅動架構代表了超越請求-回應式 RPC 的下一階段演進。與其讓您的應用程式不斷輪詢 RPCendpoint 以檢查是否有新的區塊或事件,串流服務會在資料準備就緒時主動將其推送至您的應用程式。這不僅能降低延遲、消除無謂的請求,還能簡化您的後端架構。
gRPC 這是另一種可在特定區塊鏈上與 JSON-RPC 並行使用或替代 JSON-RPC 的通訊協定。例如,Solana 的Yellowstone gRPC 便提供超低延遲的資料傳輸服務,專為交易機器人及即時分析等高頻率應用場景進行優化。gRPC 採用 Protocol Buffers 取代 JSON,其序列化過程更為緊湊且速度更快,因此非常適合在每毫秒延遲都至關重要的應用場景中使用。
Quicknode 的定位為何 Quicknode其核心 API 提供橫跨 80 多個區塊鏈網路的生產級 RPC 端點。當您在Quicknode 上建立一個endpoint 時,您將獲得一個 HTTPS 和 WebSocket URL,該 URL 可將您的應用程式連接到一個全球分散式、高效能的節點基礎架構,其服務水準協議 (SLA) 保證 99.99% 的正常運行時間,且平均響應時間比競爭對手快 2.5 倍。 每個endpoint 皆包含完整資料與存檔資料存取權限、即時分析、基於代幣的驗證,以及來源網址白名單和網域遮罩等安全功能。
除了標準的 RPC 之外,Quicknode 還透過 Streams 即時與歷史區塊鏈資料傳輸, Yellowstone gRPC 超高速的Solana 資料、涵蓋 DeFi 資料、NFT API 及安全工具的 Marketplace 附加元件生態系統,以及Quicknode SDK ,可簡化 JavaScript 與 TypeScript 的整合流程。無論您是需要單一的endpoint 來進行週末專案,還是需要多鏈、多區域的基礎架構來建構企業平台,Quicknode 皆提供作為所有其他元件建構基礎的 RPC 層。
RPCendpoint 與節點之間有何區別? 這些術語雖有關聯,但並非完全相同。節點(node)是指負責維護區塊鏈副本、驗證交易並追蹤狀態的軟體。RPC 遠端程序呼叫介面(endpoint )則是您用以連線並與該節點通訊的網路位址。一個節點可以對應多個端點,而一個 RPC 端點(endpoint )則可將請求路由至一組經過負載平衡的節點,以實現冗餘。當您使用託管服務供應商時,您將透過 RPC 端點(endpoint )進行互動,完全無需自行操作節點。 若要深入了解 URL 背後運作的機制,請參閱「什麼是區塊鏈節點 」;若要了解完整的請求生命週期,請參閱「RPC 請求如何運作 」。
您應該使用哪種 RPC 傳輸協定:HTTP、WebSocket 還是gRPC ? RPC 端點會提供多種傳輸協定,而選擇哪種協定取決於您是進行一次性查詢,還是訂閱持續性的資料串流。HTTP 是請求-回應呼叫的通用預設選項。WebSocket 會維持一個持久連線,以便節點能將更新推送給您。gRPC 則在受支援的區塊鏈上,為高頻率工作負載提供最低的延遲。下表提供這三種選項的快速比較。
運輸
連接模型
最適合
權衡
HTTP
無狀態的請求與回應
標準讀取、交易提交、批次呼叫
沒有伺服器推送功能,因此您必須透過輪詢來檢查更新
WebSocket
持久性、雙向
對新區塊、日誌及待處理交易的訂閱
必須維持連線狀態,並在連線中斷時重新建立連線
gRPC
持久化與 Protocol Buffers 的串流處理
超低延遲的資料串流,例如交易機器人和分析工具
設定較為複雜,且僅限於支援此功能的連鎖店
如果您的應用程式需要持續的資料傳送,而非反覆輪詢,像Quicknode Streams 便能將區塊、收據和追蹤資料直接傳送至您的後端,而無需您自行管理套接字的生命週期。
是什麼原因導致 RPCendpoint 出現延遲和速率限制? 有兩個因素最常影響使用 RPCendpoint 的體驗:回應速度以及允許的請求數量。 延遲取決於與節點之間的地理距離、所呼叫方法的複雜程度,以及底層基礎設施的繁忙程度。速率限制的存在是因為每個節點的容量都是有限的,因此服務提供商會對每秒請求數設限,以保護共享資源。了解這兩項因素,有助於您在流量增長之前正確評估endpoint 的規模。請參閱「何謂 RPC 延遲 」及「何謂 RPC 速率限制 」以了解更多資訊。
何時應該使用索引功能,而非原始 RPC? 原始 RPC 非常適合讀取當前狀態和提交交易,但在處理「這個錢包過去一年內進行的所有轉帳」這類分析性查詢時卻顯得力不從心。 若僅靠 RPC 來回答此問題,將需要進行數千次連續的呼叫。索引技術透過將鏈上資料預先處理成可查詢的資料庫來解決此問題,因此歷史資料與彙總資料的查詢皆可透過單一查詢完成。請參閱《RPC 與索引技術的比較 》一文,了解為何在查詢區塊鏈資料時 ,大型查詢會如此困難。
常見問題
RPC 代表什麼? RPC 代表「遠端程序呼叫」(Remote Procedure Call)。這是一種協定,可讓一個程式透過網路向另一個程式請求資料或觸發動作,其運作方式猶如呼叫本機函式一般。在區塊鏈中,您的應用程式會使用 RPC 來要求節點讀取狀態或提交交易。
RPCendpoint 和 API 是同一回事嗎? RPCendpoint 是一種特定類型的 API。它透過 JSON-RPC 標準,在單一 URL 上提供區塊鏈節點的功能。許多服務供應商會在基礎 RPC 介面上疊加增強版的 REST 或更高階的 API,但核心的endpoint 才是能與節點進行 JSON-RPC 通訊的介面。
在生產環境中使用免費的公開 RPC 端點是否安全? 這些端點雖然適合用於測試和學習,但並非為生產環境而設計。公開端點受到嚴格的速率限制,經常處於超載狀態,且不提供正常運作時間或延遲的保證。如果公開的endpoint 在流量激增時效能下降,您的應用程式也會隨之受影響;這就是為什麼生產環境中的應用程式都依賴專用的私有端點。
一個 RPCendpoint 能否連線至多個區塊鏈? 單一的endpoint URL 通常對應至一個網路,例如Ethereum 、mainnet 或Solana 、mainnet 。若要支援多個鏈,您需建立獨立的端點,每個網路各一個。由於大多數鏈都採用 JSON-RPC 模式,您為某個endpoint 所編寫的程式碼,通常只需稍作修改即可套用至其他鏈。
如何在不需不斷輪詢的情況下,接收鏈上事件的通知? 請採用推送式機制,而非輪詢。WebSocket 訂閱以及事件驅動型服務(例如 Quicknode Webhooks 會在相關區塊或事件發生之際立即通知您的後端,從而降低延遲並消除無謂的請求。若需逐步教學指南,《建構者指南 》將帶您逐步了解常見的設計模式。
延伸閱讀 // Tags
RPCendpoint 什麼是 RPC JSON-RPC
// Publisher
Quicknode
更新於 2026 年 6 月 3 日
2026年2月3日 — 閱讀時間 10 分鐘