---
title: "低延遲最佳 Base RPC 供應商：Base、Arbitrum 與 Optimism 基準測試"
description: "在 Alchemy 保留的公開基準測試期間，於四家受測付費供應商中，Alchemy 在 Base 上的平均與 p95 讀取延遲最低，觀察到的失敗次數也最少。"
---

# 低延遲最佳 Base RPC 供應商：Base、Arbitrum 與 Optimism 基準測試

<ImageBlock
  src="https://media.alchemy.com/blog/best-base-rpc-provider-low-latency-benchmark-hero-16x9-20260821.png"
  alt="最佳 Base RPC 供應商數據"
  width={1920}
  height={1080}
  priority
/>

一個快速的 Base 應用程式,仍然可能讓人感覺很慢。

原因很簡單:一個 RPC 供應商可以在中位數回應時間圖表上表現亮眼,但在你的產品最常呼叫的方法上變慢,或是在最慢的 5% 請求送達時掉速。對錢包、交易應用程式、索引器、區塊瀏覽器和通知系統來說,這正是使用者會察覺到延遲的地方。

所以我們量測了不只一項數字。在 Alchemy 保留的公開基準測試視窗(2026 年 8 月 8 日至 13 日)中,Alchemy 在四個受測的付費端點中,於 Base 上交出了最低的平均與 p95 讀取延遲。它也在約 138 萬次量測請求中,記錄到最少的觀測失敗次數。

這項差異不僅限於基本的餘額查詢。Alchemy 在可見的 Base 方法群組中全面領先,包括日誌查詢和交易收據查詢,這些呼叫通常位於關鍵的產品路徑上。

## 哪個 RPC 供應商支援延遲最低的 Base RPC?

在 2026 年 8 月 8 日至 13 日的比較視窗中,Alchemy、QuickNode、dRPC 和 Infura 之中,Alchemy 的 Base 量測平均延遲與 p95 延遲最低。在此基準測試設定的讀取負載下,其平均值為 15.66 ms,p95 為 49.91 ms。量測結果最接近的競爭者是 QuickNode,平均 56.16 ms、p95 234.18 ms。

這使得 Alchemy 成為此基準測試中,尋求低延遲 [Base RPC](https://www.alchemy.com/rpc-api) 供應商的團隊支援度最佳的選擇。但這不代表每一種工作負載、地區或未來的量測都會得出相同的排名。方法、流量模式、供應商層級與客戶端所在位置仍然重要,因此我們會公開這些條件與量測視窗的日期,並搭配一個每 24 小時滾動更新的儀表板。

快速回答:就這個量測的 Base 工作負載與 2026 年 8 月 8 日至 13 日的視窗而言,Alchemy 在平均與 p95 回應時間上都是受測供應商中延遲最低的,同時也記錄到最少的觀測失敗次數。

## Base 正面對決

下表彙整了在此基準測試設定的 EVM 讀取負載下,Base 主網的效能表現。此測試使用 Alchemy、QuickNode、dRPC 和 Infura 的標準付費帳號。每個供應商都從相同的執行端地區(US East、US West、EU Central、AP Southeast)收到約 138 萬次相同設定的請求呼叫。

<EmbeddedTable
  table={{
    columns: [
      { key: "provider", width: 140, title: "Provider", dataType: "object" },
      {
        key: "average",
        width: 150,
        title: "Average latency",
        dataType: "object",
      },
      { key: "p50", width: 110, title: "p50", dataType: "object" },
      { key: "p95", width: 110, title: "p95", dataType: "object" },
      {
        key: "successRate",
        width: 150,
        title: "Success rate",
        dataType: "object",
      },
    ],
    data: [
      {
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "15.66 ms", tooltip: "", icon: "" },
        p50: { title: "9.34 ms", tooltip: "", icon: "" },
        p95: { title: "49.91 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "56.16 ms", tooltip: "", icon: "" },
        p50: { title: "22.45 ms", tooltip: "", icon: "" },
        p95: { title: "234.18 ms", tooltip: "", icon: "" },
        successRate: { title: "99.998915%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        provider: { title: "dRPC", tooltip: "", icon: "" },
        average: { title: "73.89 ms", tooltip: "", icon: "" },
        p50: { title: "38.71 ms", tooltip: "", icon: "" },
        p95: { title: "254.38 ms", tooltip: "", icon: "" },
        successRate: { title: "99.802490%", tooltip: "", icon: "" },
        id: 2,
      },
      {
        provider: { title: "Infura", tooltip: "", icon: "" },
        average: { title: "118.16 ms", tooltip: "", icon: "" },
        p50: { title: "104.93 ms", tooltip: "", icon: "" },
        p95: { title: "276.39 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999132%", tooltip: "", icon: "" },
        id: 3,
      },
    ],
  }}
/>

數據來自 2026 年 8 月 8 日至 13 日的視窗。[即時 Base 基準測試](https://www.alchemy.com/benchmarks)顯示的是每 24 小時滾動更新的視圖,而非此固定視窗,因此其目前的數字會有所不同。

Alchemy 的 15.66 ms 平均值,比次快的受測供應商 QuickNode 低了 40.50 ms。對正式環境流量而言更重要的是,Alchemy 的 49.91 ms p95,比 QuickNode 的 234.18 ms p95 低了 184.27 ms。

這個尾端差異才是實際影響所在。平均值描述的是工作負載的中段表現。p95 顯示的是 95% 成功請求都能勝過的回應時間。當報價更新、交易狀態輪詢或事件驅動的 UI 落在這個較慢的尾端區間時,使用者會感受得到。

在這個視窗中,Alchemy 的 Base p95 約為其 p50 的 5.3 倍。QuickNode 的 p95 約為其 p50 的 10.4 倍。結果不只是典型回應快,而是觀測到的尾端表現明顯更緊密。

## 為什麼單一 RPC 延遲數字並不足夠

「延遲最低」只有在指明工作負載時才有意義。

餘額查詢、最新區塊讀取、收據查詢,以及跨歷史區塊的日誌查詢,走的是不同路徑。一個供應商可能在某一項表現良好,卻在另一項表現不佳。這很重要,因為真實的應用程式很少只由單一種請求類型組成。

公開的 Base 基準測試按方法與負載類型分開了設定的讀取項目。在可見的群組中,Alchemy 在 2026 年 8 月 8 日至 13 日的視窗中交出了最低的平均延遲。

<EmbeddedTable
  table={{
    columns: [
      { key: "read", width: 240, title: "Base read", dataType: "object" },
      { key: "alchemy", width: 130, title: "Alchemy", dataType: "object" },
      { key: "quicknode", width: 130, title: "QuickNode", dataType: "object" },
      { key: "drpc", width: 110, title: "dRPC", dataType: "object" },
      { key: "infura", width: 110, title: "Infura", dataType: "object" },
    ],
    data: [
      {
        read: {
          title: "<p><code>eth_getBalance</code></p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "7.56 ms", tooltip: "", icon: "" },
        quicknode: { title: "11.74 ms", tooltip: "", icon: "" },
        drpc: { title: "19.42 ms", tooltip: "", icon: "" },
        infura: { title: "101.94 ms", tooltip: "", icon: "" },
        id: 0,
      },
      {
        read: {
          title: "<p><code>eth_getBlockByNumber</code>, earliest</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "9.61 ms", tooltip: "", icon: "" },
        quicknode: { title: "45.07 ms", tooltip: "", icon: "" },
        drpc: { title: "64.82 ms", tooltip: "", icon: "" },
        infura: { title: "113.47 ms", tooltip: "", icon: "" },
        id: 1,
      },
      {
        read: {
          title: "<p><code>eth_getBlockByNumber</code>, latest</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "9.06 ms", tooltip: "", icon: "" },
        quicknode: { title: "12.26 ms", tooltip: "", icon: "" },
        drpc: { title: "18.90 ms", tooltip: "", icon: "" },
        infura: { title: "104.26 ms", tooltip: "", icon: "" },
        id: 2,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 1 block</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.31 ms", tooltip: "", icon: "" },
        quicknode: { title: "46.39 ms", tooltip: "", icon: "" },
        drpc: { title: "85.14 ms", tooltip: "", icon: "" },
        infura: { title: "115.71 ms", tooltip: "", icon: "" },
        id: 3,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 10 blocks</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.98 ms", tooltip: "", icon: "" },
        quicknode: { title: "80.10 ms", tooltip: "", icon: "" },
        drpc: { title: "85.91 ms", tooltip: "", icon: "" },
        infura: { title: "114.54 ms", tooltip: "", icon: "" },
        id: 4,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 100 blocks</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "16.12 ms", tooltip: "", icon: "" },
        quicknode: { title: "84.29 ms", tooltip: "", icon: "" },
        drpc: { title: "93.01 ms", tooltip: "", icon: "" },
        infura: { title: "119.34 ms", tooltip: "", icon: "" },
        id: 5,
      },
      {
        read: {
          title: "<p><code>eth_getTransactionReceipt</code></p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.71 ms", tooltip: "", icon: "" },
        quicknode: { title: "50.57 ms", tooltip: "", icon: "" },
        drpc: { title: "84.40 ms", tooltip: "", icon: "" },
        infura: { title: "120.03 ms", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

在資料量大的產品最看重的項目上,差距進一步拉大。在 100 區塊的 `eth_getLogs` 測試中,Alchemy 平均為 16.12 ms,相較於 QuickNode 的 84.29 ms、dRPC 的 93.01 ms,以及 Infura 的 119.34 ms。在交易收據查詢上,Alchemy 平均為 10.71 ms,相較於次快的受測供應商的 50.57 ms。

這不代表每個應用程式的請求組合都相同。這代表這項比較足以讓你採取行動:如果你的應用程式會輪詢收據、渲染活動紀錄、監聽事件歷史,或頻繁刷新鏈上狀態,就該測試最貼近你自身產品路徑的方法。

## 為什麼延遲與可靠性應該放在同一張圖表裡

快速的回應,只有在它真的送達時才有意義。

這正是為什麼我們的基準測試會將延遲與失敗結果一併回報。它會將 HTTP 錯誤、JSON-RPC 錯誤、解析失敗、網路錯誤、速率限制,以及超過 8 秒逾時的請求都計為失敗。我們不會重試失敗的請求直到它變成成功。

在 2026 年 8 月 8 日至 13 日的 Base 比較視窗中,Alchemy 在約 138 萬次量測請求中,記錄到約兩次觀測失敗。方法層級的視角在這裡也很重要。Base 日誌查詢群組記錄到約零到一次 Alchemy 觀測失敗,而 dRPC 在每個可見的日誌範圍群組中都記錄到數百次失敗。

這並不是在宣稱失敗永遠不會發生。而是一個更有力、也更實用的結論:在相同的量測條件下,此基準測試觀測到 Alchemy 既有較快的成功回應,也有較少的失敗嘗試。

## 這項結果是否適用於其他 L2?

Base 並不能代表所有 L2。不同的鏈、供應商架構和網路路徑,可能會產生不同的結果。因此,我們在同一個基準測試系列下分別比較每條鏈,而不是把所有 L2 混合成單一分數。下表比較了 Alchemy 與 QuickNode 在 Base、Optimism 和 Arbitrum 上的表現。

<EmbeddedTable
  table={{
    columns: [
      { key: "chain", width: 120, title: "Chain", dataType: "object" },
      { key: "provider", width: 130, title: "Provider", dataType: "object" },
      {
        key: "average",
        width: 150,
        title: "Average latency",
        dataType: "object",
      },
      { key: "p95", width: 110, title: "p95", dataType: "object" },
      {
        key: "successRate",
        width: 150,
        title: "Success rate",
        dataType: "object",
      },
    ],
    data: [
      {
        chain: { title: "Base", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "15.66 ms", tooltip: "", icon: "" },
        p95: { title: "49.91 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        chain: { title: "Base", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "56.16 ms", tooltip: "", icon: "" },
        p95: { title: "234.18 ms", tooltip: "", icon: "" },
        successRate: { title: "99.998915%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        chain: { title: "Optimism", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "24.94 ms", tooltip: "", icon: "" },
        p95: { title: "97.65 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999917%", tooltip: "", icon: "" },
        id: 2,
      },
      {
        chain: { title: "Optimism", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "53.16 ms", tooltip: "", icon: "" },
        p95: { title: "246.97 ms", tooltip: "", icon: "" },
        successRate: { title: "99.984778%", tooltip: "", icon: "" },
        id: 3,
      },
      {
        chain: { title: "Arbitrum", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "10.52 ms", tooltip: "", icon: "" },
        p95: { title: "19.15 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 4,
      },
      {
        chain: { title: "Arbitrum", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "46.61 ms", tooltip: "", icon: "" },
        p95: { title: "145.17 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999566%", tooltip: "", icon: "" },
        id: 5,
      },
    ],
  }}
/>

在 2026 年 8 月 8 日至 13 日的視窗中,Alchemy 在四個受測的付費端點中,於 Base 平均與 p95 延遲上領先。在 Optimism 和 Arbitrum 上,它在這兩項指標上都領先 QuickNode。領先幅度因鏈而異,這正是為什麼開發者不該假設某個 L2 的結果可以自動套用到其他鏈。

對跨這些網路建構應用的團隊來說,實務上的啟示很直接:供應商的選擇應該在你的產品擴展到多條鏈時,依然能維持效能。公開結果顯示 Alchemy 在這三條 L2 上都領先 QuickNode,並且在 Base 的四家供應商比較中也領先,而不只是在單一網路上表現突出。

## 哪個 RPC 供應商在全球各地區提供最低延遲?

此基準測試的全球結果彙整了來自 US East、US West、EU Central 和 AP Southeast 的相同設定讀取測試。在 2026 年 8 月 8 日至 13 日的 Base 視窗中,Alchemy 在受測供應商中擁有最低的全球平均與 p95 延遲。

對於評估要在分散式部署地區使用單一供應商的團隊來說,這是正確的答案。但這不能取代針對特定地區的決策。亞太地區的使用者和在歐洲運行的服務,可能會走上不同的網路路徑,得出不同的結果,因此在選擇端點之前,應搭配基準測試的地區儀表板一併查看全球視圖。[開啟即時 Base 基準測試](https://www.alchemy.com/benchmarks)以查看目前每 24 小時滾動更新的視圖。

## Base 協定速度與 RPC 速度的量測方式不同

有兩個時鐘構成了 Base 上的使用者體驗,但它們量測的是旅程中不同的部分。

**Base 協定速度**是從交易抵達鏈上之後開始計算。它量測的是:定序器何時對其進行預確認、它何時出現在 L2 區塊中、該區塊何時被批次提交到 Ethereum,以及它何時達到最終性。根據 [Flashblocks](https://docs.base.org/base-chain/flashblocks) 的文件,Base 記錄約 200 ms 達到定序器預確認、約 2 秒讓 L2 區塊分發給驗證者,以及約 2 分鐘完成 L1 批次提交。Ethereum 等級的最終性則出現得更晚;提領回 Ethereum 另有獨立的 7 天詐欺證明視窗。

**RPC 速度**量測的是供應商路徑:一個端點接收讀取請求、對其基礎設施執行查詢,並回傳結果所需的時間。這正是此基準測試所量測的時鐘。

<EmbeddedTable
  table={{
    columns: [
      { key: "clock", width: 240, title: "Clock", dataType: "object" },
      {
        key: "measures",
        width: 420,
        title: "What it measures",
        dataType: "object",
      },
    ],
    data: [
      {
        clock: { title: "RPC response latency", tooltip: "", icon: "" },
        measures: {
          title: "Time for a provider to return a JSON-RPC read response",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        clock: { title: "Flashblock preconfirmation", tooltip: "", icon: "" },
        measures: {
          title: "Sequencer commitment, roughly 200 ms",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        clock: { title: "L2 block production", tooltip: "", icon: "" },
        measures: {
          title: "Block distributed to validators, roughly 2 s",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        clock: { title: "L1 batch posting", tooltip: "", icon: "" },
        measures: {
          title: "Data posted to Ethereum, roughly 2 min",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        clock: { title: "Finality and withdrawals", tooltip: "", icon: "" },
        measures: {
          title: "Ethereum finality and the fault-proof process",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
    ],
  }}
/>

簡單來說:即使一筆已送出的交易正在走 Base 獨立的入塊與結算時程,供應商仍然可以很快地回傳最新區塊的查詢結果。快速的鏈上執行和快速的 RPC 回應都很重要,但它們並非可以互換的效能量測指標。

## 我們如何進行量測

我們建置了[公開基準測試](https://www.alchemy.com/benchmarks),讓比較可重現、易讀。

- 本文中的數據涵蓋 2026 年 8 月 8 日至 13 日。
- 連結的公開基準測試頁面顯示的是每 24 小時滾動更新的視圖,而非此固定視窗。目前的儀表板數字不會與上方表格相符。
- 我們對每個供應商,針對同一項測試送出相同設定的 EVM JSON-RPC 讀取負載。
- 我們從受控的 AWS ECS 地區執行測試,地區包括 US East、US West、EU Central 和 AP Southeast。
- 我們使用標準付費服務帳號,以及已預熱、重複使用的 HTTP 連線。
- 每個請求只嘗試一次,不進行重試。
- 一個成功的請求必須在 8 秒內回傳、回傳 HTTP 2xx 狀態、可解析為 JSON,且不含 JSON-RPC 錯誤物件。
- 我們根據成功的回應計算平均值、p50 與 p95 延遲。失敗的嘗試則另外回報。

這是一項方法層級的基礎設施基準測試。它並未量測完整的應用程式工作流程、寫入提交、WebSocket 傳遞、冷連線建立、自訂流量組合,或交易的入塊與最終性。這些界線並非附帶的小字說明,而是讓這項結果具有實用性的關鍵。

你可以查看[完整的基準測試方法論](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance),並在[公開基準測試頁面](https://www.alchemy.com/benchmarks)開啟目前每 24 小時滾動更新的 Base、Optimism 和 Arbitrum 儀表板。

## 如何測試適合你應用程式的 RPC

從使用者會感受到的請求路徑開始。

如果你在打造錢包,就測試餘額查詢、最新區塊的新鮮度,以及交易收據。如果你在打造索引器,就測試你實際的 `eth_getLogs` 範圍與回應大小。如果你在打造交易應用程式,就測試驅動你的報價、狀態與交易狀態輪詢迴圈的那組讀取請求。從使用者所在的地區執行每項測試,並採用與你的應用程式相同的逾時與連線行為。

然後一併評估以下四項:

1. 常見情況下的平均延遲。
2. 較慢的成功呼叫的 p95 延遲。
3. 成功率與失敗請求數。
4. 針對定義你使用體驗的請求的方法層級結果。

最新的公開結果提供了一個明確的起點。在 Base 上,Alchemy 在 2026 年 8 月 8 日至 13 日的視窗中,於平均延遲、p95 延遲和觀測可靠性上,領先四個受測的付費端點。在 Optimism 和 Arbitrum 上,它在平均與 p95 延遲上領先 QuickNode。

如果延遲是你產品的重要一環,這正是值得做的比較。

## 低延遲的 Base 應用程式需要專屬基礎設施嗎?

此公開基準測試比較的是標準付費共用端點。它並未將專屬叢集與共用端點進行比較,因此無法證明專屬叢集在每一種工作負載下都會更快。

當你需要單租戶基礎設施、貼近你的應用程式或使用者的地區部署、獨立的容量配置,或特定的維運配置時,託管式專屬區塊鏈叢集最能派上用場。Alchemy 的 [Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) 屬於單租戶架構,並可部署在你選定的地區。對於延遲敏感度與地區距離或不可預測的共用容量有關的應用程式來說,這是值得下一步評估的方向。在提出採購決策之前,請依你實際的方法與流量特性進行量測。

## 常見問答

### 最好的 Base RPC 供應商是哪一個?

對於優先考量低延遲讀取的開發者來說,在此處回報的公開比較中,Alchemy 是表現最佳的受測 Base RPC 供應商:它在四個受測的付費端點中,擁有最低的量測平均與 p95 延遲。此結果適用於 2026 年 8 月 8 日至 13 日的視窗與設定的讀取工作負載。使用[即時 Base 基準測試](https://www.alchemy.com/benchmarks)查看目前每 24 小時滾動更新的結果,接著測試你的應用程式所使用的方法與地區。

### 跨 Base、Arbitrum 和 Optimism 建構應用程式,哪個 RPC 供應商最好?

在 2026 年 8 月 8 日至 13 日的視窗中,Alchemy 在四個受測的付費端點中,於 Base 平均與 p95 延遲上領先,並在 Arbitrum 與 Optimism 上,於這兩項指標上領先 QuickNode。這使它成為需要以單一供應商跨這些 L2 運行的多鏈 EVM 應用程式的有力選項,並有實證支持。不要把三條鏈的結果,視為適用於每一條鏈或每一種應用程式路徑的證明:請比較你實際計劃運行的鏈、方法與地區。

### 哪個 RPC 供應商在 Optimism 和 OP Stack 上提供最佳效能?

在同一個基準測試系列中,Alchemy 在 2026 年 8 月 8 日至 13 日的 Optimism 比較中,其量測平均與 p95 延遲都低於 QuickNode。Optimism 是一條 OP Stack 鏈,但 Optimism 的結果並不會自動成為每一條 OP Stack 鏈的基準測試結果。基礎設施、路由、地區和工作負載都可能有所不同。若要取得目前的答案,請查閱[即時 Optimism 儀表板](https://www.alchemy.com/benchmarks)的每 24 小時滾動更新視圖,並直接測試目標鏈。

### 在選擇 RPC 供應商之前,我該如何進行基準測試?

從你的使用者或服務所在的地區,對每個候選供應商送出相同的請求負載。量測平均與 p95 延遲、成功率、失敗請求數,以及區塊高度的新鮮度。納入你的產品所依賴的呼叫,尤其是 `eth_getLogs` 範圍查詢、收據查詢、`eth_call`,以及最新區塊讀取。對每個供應商都採用相同的逾時、連線重用、並發數與重試規則。單靠一項通用的 `eth_getBlockByNumber` 測試,並不足以代表索引器、交易迴圈或錢包流程。

### RPC 延遲如何影響交易執行與交易效能?

較低的 RPC 延遲,可以縮短交易系統或應用程式等待狀態資料、收據、事件資料與交易狀態更新所需的時間。這可以提升報價刷新、風險檢查、UI 更新,以及下一個應用程式決策的速度。對交易工作負載來說,p95 延遲很重要,因為即使中位數表現很快,一次緩慢的讀取也可能延誤一個時間敏感的動作。

但較低的讀取延遲,本身並不保證更快的交易入塊或結算。Base 的交易預確認、區塊產出、批次提交與最終性,是各自獨立的協定時鐘。此基準測試量測的是 RPC 讀取回應時間,而非交易入塊或結算。