什麼是以太坊 RPC？

2026 年第一季，以太坊網路處理了 2.004 億筆交易，較前一季成長 43%。每一次餘額查詢、每一次智慧合約呼叫、每個錢包和 DeFi 協定提交的每一筆交易，都經由某個 RPC 端點完成。這就是大規模場景下以太坊 RPC 的真實樣貌：應用程式與區塊鏈之間的介面。

RPC 代表遠端程序呼叫（Remote Procedure Call）。在以太坊的語境中，它是一種機制，讓應用程式——錢包、交易所、DeFi 協定——能夠與以太坊節點通訊並取得結果，而無需自行運行節點。為這種通訊定義結構的協定是 JSON-RPC，這是一種輕量級標準，將請求與回應格式化為透過 HTTP 或 WebSocket 傳送的 JSON 物件。

對在以太坊上建構的開發者來說，RPC 不是可以略過的細節。它是你的應用程式觸及區塊鏈的最低層級——你用來與以太坊互動的每一個函式庫、每一個框架、每一個工具，底層都在進行 JSON-RPC 呼叫。

以太坊 RPC 的運作原理

以太坊 RPC 基於 JSON-RPC 2.0 規範——這是一種無狀態、與傳輸方式無關的協定，由 ethereum.org 維護與撰寫文件。你的應用程式傳送一個描述意圖的 JSON 物件，節點處理後回傳 JSON 回應。

每個請求都遵循相同的結構：方法名稱（你要呼叫的操作）、params（輸入參數）、jsonrpc 版本欄位，以及一個由你指派的 id，用來把回應與請求對應起來。

以下是一個最小示例——查詢最新區塊號：

{
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": [],
"id": 1
}

節點回傳：

{
"jsonrpc": "2.0",
"id": 1,
"result": "0x13f8a4c"
}

結果以十六進位編碼。0x13f8a4c 換算成十進位是區塊 20,939,852。所有方法的模式都一致：你描述呼叫，節點針對當前區塊鏈狀態執行，然後你得到結果。

JSON-RPC 之所以適合以太坊，在於它的簡單。這個協定是無狀態的——沒有持久連線階段，用戶端與伺服器之間也沒有持續協商。每個請求都是自包含的。這使它容易實作、容易快取，也便於除錯。開發者只需 curl 就能重現任何 RPC 呼叫。

由Ethereum Execution API 規範定義了所有相容執行用戶端的標準方法全集。無論你連接的節點運行的是 Geth、Nethermind、Besu 還是 Erigon，方法都相同——而且與你使用哪家 RPC 供應商也無關。

常用以太坊 RPC 方法

這些是你最常會用到的方法，涵蓋任何以太坊應用所需的核心操作：讀取狀態、提交交易、查詢事件和檢查區塊。

• eth_blockNumber ——回傳最新的區塊號。用於鏈同步狀態檢查與區塊輪詢。
• eth_getBalance ——回傳某地址在指定區塊時的 ETH 餘額。用於錢包餘額顯示。
• eth_call ——執行唯讀合約呼叫而不建立交易。用於讀取合約狀態——不耗 Gas。
• eth_sendRawTransaction ——廣播已簽署的序列化交易。用於傳送 ETH、ERC-20 轉帳和合約寫入。
• eth_getTransactionByHash ——按雜湊值回傳交易詳情。用於追蹤已提交的交易。
• eth_getTransactionReceipt ——回傳已確認交易的回執。用於確認成功並讀取產生的事件日誌。
• eth_getLogs ——回傳依地址、主題和區塊範圍符合篩選條件的日誌。用於監聽合約事件。
• eth_getBlockByNumber ——按區塊號或標籤回傳區塊詳情。用於索引與鏈上分析。
• eth_estimateGas ——估算一筆交易所需的 Gas。用於提交前的預先檢查。
• net_version ——回傳目前的網路 ID。用於區分主網與測試網。

eth_call 是你讀取合約資料的方式。它依節點目前狀態模擬呼叫並回傳結果，不向網路廣播任何內容。無需簽章，也不耗 Gas。每當你查詢 view 函式——代幣餘額、池儲備、價格資料——底層用的就是 eth_call。

eth_sendRawTransaction 用於寫入操作。你在用戶端建構並簽署交易，將其序列化，然後提交簽署後的位元組。節點驗證簽章並把交易廣播到 mempool。用戶端簽署與廣播兩者分離是有意為之：你的私鑰永遠不會離開你的應用程式。

eth_getLogs 功能強大但需要一些紀律。對繁忙合約的大區塊範圍查詢在公共端點上可能成本高昂，還可能觸發速率限制。請依合約地址和特定事件主題篩選，並在有限範圍內查詢。

如何連接以太坊 RPC 端點

連接以太坊 RPC 歸結起來就是一個 URL。每家供應商在你註冊時都會給你一個：

https://rpc.yourprovider.com/YOUR_API_KEY

你可以直接向該 URL 發送原始 HTTP POST 請求，也可以把它傳給某個函式庫。以下是使用 ethers.js 的簡單版本：

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://rpc.yourprovider.com/YOUR_API_KEY");

async function getBalance(address) {
const balance = await provider.getBalance(address);
console.log(ethers.formatEther(balance), "ETH");
}

getBalance("0xYourAddressHere");

如果你想要最少的相依套件和最大的透明度，直接用 fetch 也同樣可行：

const response = await fetch("https://rpc.yourprovider.com/YOUR_API_KEY", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
method: "eth_blockNumber",
params: [],
id: 1
})
});

const data = await response.json();
console.log(parseInt(data.result, 16)); // current block number as decimal

無需安裝節點，無需等待同步。把應用程式指向端點 URL，你就能完整存取以太坊主網——或供應商支援的任何測試網。

公共與私有以太坊 RPC 端點

取得以太坊 RPC 端點有兩種方式：使用第三方服務提供的端點，或自行營運節點。

公共端點由供應商代管，他們代替你運行並維護節點基礎設施。你註冊、取得 API 金鑰、完成連接。營運負擔留在供應商那邊。對大多數開發工作和各種正式環境部署而言，這是務實的選擇：幾分鐘內即可上線，無需管理本地節點，而且當以太坊用戶端軟體演進時，供應商會負責升級。

代價是速率限制。公共端點是共享基礎設施，因此高流量的查詢——大範圍的 eth_getLogs 呼叫、熱門應用帶來的爆量流量——可能被限流。大多數供應商提供分級方案，隨規模擴大提高速率上限。

私有端點意味著運行自己的以太坊節點。回報是完全的掌控權：沒有速率限制，不依賴第三方的正常運轉時間，可完整存取封存資料，並能依自身需求精確設定節點。代價在營運面。一個完整的以太坊節點需要大量儲存空間（封存節點需要數 TB，因為它保留全部歷史狀態）、持續的記憶體與運算資源，以及隨用戶端軟體演進而不斷進行的維護。

架構選擇並非一成不變。許多團隊從公共端點起步，驗證產品，待規模與特定需求足夠時再遷移到私有基礎設施。

以太坊 RPC vs. WebSocket：該用哪個？

HTTP 和 WebSocket 都是 JSON-RPC 的傳輸方式，各自適合不同情境。在做出選擇之前，值得先理解兩者的區別。

HTTP RPC 是請求-回應模式。你的應用程式傳送請求、收到結果，連線隨即關閉。設計上就是無狀態的。它適用於大多數以太坊互動：餘額查詢、交易提交、合約讀取、區塊查詢。如果你的應用主動發起呼叫並處理回應，HTTP 是正確的預設選擇——更容易使用，也更容易快取和除錯。

WebSocket 在你的應用程式與節點之間保持一條持久的雙向連線。這帶來了訂閱能力：應用程式可以告訴節點「有新區塊到達時通知我」或「這個合約發出這個事件時通知我」，節點會在事件發生時推送更新，應用程式無需輪詢。相關方法是 eth_subscribe，它只能透過 WebSocket 使用。

實用建議：從 HTTP 開始。如果你發現自己反覆輪詢 eth_blockNumber 來偵測新區塊，或在迴圈中輪詢交易回執，那就是把該互動遷移到 WebSocket 訂閱的訊號。兩者可以並行——HTTP 用於按需查詢，WebSocket 用於事件監聽。

免費以太坊 RPC 端點——該注意什麼

大多數正式等級的供應商都提供免費方案。他們的狀況如下：

• Infura ——由 ConsenSys 支持，與 MetaMask 直接整合，提供免費方案，註冊開發者超過 40 萬。
• Alchemy ——免費方案額度大方（每月約 3000 萬運算單元），提供包含交易模擬在內的增強開發者 API。
• QuickNode ——在主要供應商中公開基準測試延遲最低（全球平均約 86ms），合規表現穩健。
• CoinsDo ——免費以太坊 RPC 端點，無前期成本，無需信用卡即可開始。專為想在產品獲得驗證之前不必擔心帳單的開發者而設。

免費方案是真實可用的。差別在於上限在哪：每秒請求數、每日請求限額、是否包含封存資料，以及 WebSocket 支援程度。

在為正式環境選擇供應商之前，檢查三件事：相對於預期請求量的速率限制、應用需要歷史查詢時封存資料的可用性，以及正常運轉時間保障的 SLA 條款。如果你的應用對延遲敏感，延遲也很重要——各家基準表現不一，地理因素也會影響結果。

在早期開發階段，CoinsDo 的免費 RPC 端點 是乾淨的選擇：入門毫無摩擦，在你還在摸索正式環境架構時，也不會有升級付費方案的壓力。

常見問題

以太坊 RPC 節點和 RPC 端點有什麼區別？

節點是以太坊用戶端軟體——Geth、Nethermind、Besu 或 Erigon——負責運行區塊鏈：同步區塊、驗證交易、維護狀態。RPC 端點是你用來與該節點通訊的網路位址。當你使用 CoinsDo、Infura 或 Alchemy 這類公共供應商時，節點由他們營運，你拿到的是端點 URL。

以太坊 RPC 是免費的嗎？

透過公共供應商，是的。大多數主要供應商提供的免費方案，流量足以涵蓋開發和中等規模的正式使用。CoinsDo 提供免費端點，無需信用卡。付費方案則隨應用規模擴大提供更高的速率限制與額外功能。

以太坊主網預設的 RPC URL 是什麼？

並不存在統一的預設值。以太坊不內建公共端點。你要連接由供應商（Infura、Alchemy、QuickNode、CoinsDo）營運的端點，或連接自行運行的節點。URL 格式依供應商而異，並包含你的 API 金鑰。

以太坊 RPC 與 WebSocket 有什麼區別？

HTTP RPC 是無狀態的請求-回應：應用程式傳送請求並收到結果。WebSocket 保持持久連線，並透過 eth_subscribe 支援訂閱，因此節點可以向你的應用推送即時更新——新區塊、合約事件——無需輪詢。按需查詢用 HTTP；需要即時事件通知時用 WebSocket。

不運行節點也能用以太坊 RPC 嗎？

可以，這正是公共 RPC 端點的核心功能。供應商運行節點基礎設施，你的應用程式連接到他們的端點 URL。無需安裝用戶端、等待鏈同步或管理本機儲存，即可完整存取以太坊主網。

eth_call 是做什麼的？

eth_call 對智慧合約執行唯讀呼叫。它依節點目前狀態執行合約程式碼並回傳結果，不建立交易，也不向網路廣播任何內容。不耗 Gas，也不改變鏈上狀態。每當你需要從合約讀取資料——代幣餘額、池價格、治理狀態，以及任何透過 view 或 pure 函式揭露的內容——都可以使用它。