---
title: "鏈上交易中延遲的成本"
description: "延遲成本表現為觀察到的狀態與執行之間的落差。本文說明延遲出現的位置、p95 為何重要,以及如何評估你的 RPC 路徑。"
---

# 鏈上交易中延遲的成本

<ImageBlock
  src="https://media.alchemy.com/blog/the-cost-of-latency-in-onchain-trading-hero.png"
  alt="延遲的代價"
  width={1024}
  height={480}
  priority
/>

延遲成本體現在產品所觀察到的鏈上狀態，與其動作實際執行時的狀態之間的落差。產品每花費一毫秒讀取、判斷、提交、等待確認，這個落差就會擴大。

對於長線的資產組合檢視來說，這個落差可能只是個小麻煩。但對於做市商、swap router、清算引擎，或是想取消過時訂單的交易者來說，這個落差可能吃掉策略優勢中相當大的一部分。[低延遲 RPC](/rpc-api) 是打造成功交易體驗的核心，因為它能幫助這些產品依據更新的狀態來行動。

## 報價可能在交易執行前就已經過時

swap 報價在應用程式請求當下，擷取了資金池儲備量、訂單簿流動性、gas 狀況以及市場狀態。而在使用者確認交易的過程中，這些輸入值持續在變動。

基本流程很簡單：

1. 應用程式讀取鏈上與市場狀態。
2. 計算出報價或交易決策。
3. 使用者提交交易。
4. 網路傳播、排序並執行該交易。
5. 應用程式收到回執並更新畫面。

每一段延遲都會讓最終動作更加過時。讀取慢，用的就是較舊的市場資料；提交慢，市場就有更多時間變動；確認慢，使用者看到的就是過時的狀態。

[0x](/case-studies/0x) 跨多個流動性來源進行交易報價。由於請求傳輸過程中價格可能隨時變動，其團隊將即時且準確的資料與報價品質緊密相連，並能在一秒內產生這些報價。

[Jupiter](https://developers.jup.ag/docs/transaction/submit) 展示了這種時間落差：其直接上鏈路徑的目標是 50 到 400 毫秒（即 0 到 1 個 Solana 區塊），相較之下，標準 RPC 提交需要 400 毫秒到 1.2 秒（即 1 到 3 個區塊）。報價與執行之間經過的區塊數愈少，狀態發生變化的機會就愈少。

## 延遲累積的四個階段

每筆交易都會經過這些階段。其中任何一個階段的延遲，都會讓最終結果變得更加過時或更不確定。

<EmbeddedTable
  table={{
    columns: [
      { key: "stage", width: 200, title: "階段", dataType: "object" },
      {
        key: "measures",
        width: 280,
        title: "衡量的內容",
        dataType: "object",
      },
      {
        key: "cost",
        width: 300,
        title: "延遲可能造成的成本",
        dataType: "object",
      },
    ],
    data: [
      {
        stage: { title: "讀取延遲", tooltip: "", icon: "" },
        measures: {
          title:
            "透過 Node API 呼叫，取得餘額、資金池狀態、報價、回執或最新區塊等有效回應所需的時間。",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "策略或使用者根據較舊的狀態做出決策。報價可能已經過時。",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        stage: { title: "決策延遲", tooltip: "", icon: "" },
        measures: {
          title:
            "計算路徑、套用風險檢查、簽署或準備交易所花費的時間。",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "交易離開應用程式前，執行窗口就已經變寬。",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        stage: {
          title: "提交與納入延遲",
          tooltip: "",
          icon: "",
        },
        measures: {
          title:
            "從廣播到相關鏈或撮合引擎接受並排序該動作所花費的時間。",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "流動性發生變化、取消指令來得太晚，或其他參與者取得優先權。",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        stage: {
          title: "確認與更新延遲",
          tooltip: "",
          icon: "",
        },
        measures: {
          title: "取得結果並顯示最新狀態所需的時間。",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "使用者看到的是過時的餘額或模稜兩可的交易狀態，自動化系統的反應也會延後。",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

這些階段彼此互相影響。即使寫入路徑再快，舊的市場讀取資料依然是舊的。在波動劇烈的時刻，最慢的那些請求比平均值更重要。失敗本身也會帶來額外風險：重試、畫面顯示過時，以及錯失動作時機。

對延遲敏感的產品，應該同時評估 p95、p99 回應時間與成功率。我們公開的[基準測試方法](/blog/how-we-benchmark-rpc-performance)衡量的是已預熱、按方法分類的 EVM 讀取，並將成功回應的延遲與失敗情況分開統計。底層的 [Node API](/rpc-api) 涵蓋了產品用來與鏈互動的讀取與寫入操作。它衡量的是特定供應商的路徑，而交易團隊則需要測試自己的讀取、寫入、地區與流量型態。

## 延遲如何在鏈上交易中轉化為經濟成本？

延遲會在改變執行結果時轉化為經濟成本，而具體方式則取決於工作負載類型。以下是鏈上交易系統中反覆出現的幾種模式。

### Swap：過時的報價變成滑點或 revert

價格衝擊（price impact）與滑點（slippage）經常被混為一談，但兩者描述的是不同的成本。我們的 [DeFi 基礎設施指南](/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale)展示了這些成本如何在實際運作的報價流程中出現。價格衝擊是某個交易規模在特定資金池上造成的可預期價格變化。滑點則是報價輸出與執行時實際獲得輸出之間的額外落差，它取決於延遲、並發交易，以及區塊納入順序。

這個區別在產品設計上相當重要。價格衝擊在報價當下就能看見。滑點則會在交易待處理期間持續擴大。最低輸出保護機制能保障使用者，把過大的價格變動轉化為 revert。手續費較低的交易可以等更久、讓價格環境有更多變化空間；而最低輸出、最高輸入或截止時間，則設定了使用者能接受的最差執行結果。

面向使用者的結果，可能是更差的價格、錯失交易，或是更嚴格的執行路徑以降低對變動市場的曝險。更快的讀取與提交，能縮減這個曝險窗口的一部分。

### 做市與訂單管理：延遲的取消可能變成有毒訂單流

做市商會隨著價格變動持續更新報價。如果系統延遲得知市場變動，或延遲送出取消指令，掛單可能在已經無利可圖之後才成交。而下即時單的交易者面臨的則是相反的風險：等訂單抵達市場時，可用的流動性可能已經消失。

### 清算與套利：時間本身就是機會的一部分

清算引擎與套利系統彼此競爭，比的是誰能先觀察到狀態變化並在機會結束前採取行動。這場競賽可能圍繞著新的預言機價格、變動的健康係數、資金池失衡，或跨平台的價格變動。錯過機會可能意味著收益損失。重複失敗的嘗試也會消耗手續費與區塊空間。

鏈的設計會改變這場競賽的樣貌。在依先到先得排序的系統中，較低的延遲路徑可能直接影響排序結果。在採用優先費的系統中，費用與時機都很重要。在有私有訂單流或 bundle 的系統中，可見性與原子執行又會帶來額外的取捨。基礎設施在這些市場規則之內運作，它的任務是在策略進入這些規則之前，避免加入不必要的延遲。

### 錢包與交易介面：延遲會變成信任問題

延遲影響的不只是成交價格。錢包或交易應用程式在使用者看到有用畫面之前，可能會發出許多呼叫：餘額、額度、路徑報價、gas 估算、回執、交易紀錄。如果這些呼叫回應緩慢或間歇性失敗，使用者看到的就會是變動中的價格、延遲的狀態，或是看似當機的介面。

這在波動期間特別有害。在平靜市場中只是稍嫌不便的緩慢餘額更新，在使用者試圖管理風險時，可能會延遲避險、取消決策，或存款確認。

## 為何尾端延遲比平均值更重要

延遲分布是有尾端的。當某個端點在負載下變慢時，產品會在流量上升、波動加劇或鏈上壅塞期間，正好碰上這條慢速路徑。

這就是為什麼供應商評估需要回答以下四個問題：

- 哪些方法位於關鍵路徑上？分別評估最新區塊讀取、`eth_call`、`eth_getLogs`、回執查詢與交易廣播，因為每一種行為都不同。
- 使用者與服務是從哪些地區連線的？地理位置會改變網路路徑。
- 成功呼叫的 p95 與 p99 有多慢？這些數值會揭露平均值所掩蓋的那些請求。
- 請求失敗或逾時的頻率有多高？逾時是一種可靠性事件，可能觸發重試、畫面過時或錯失動作。

基準測試應該明確呈現這些條件，並衡量買家實際會執行的產品路徑。我們的[基準測試方法](/blog/how-we-benchmark-rpc-performance)在每個方法層級的比較中，固定了請求來源、方法、payload、逾時時間、成功判定規則與連線狀態，協助開發者做出基礎設施決策。

## 低延遲 RPC 能解決什麼、不能解決什麼

更快的 RPC 層能更早回傳最新狀態、更早提交已簽署的交易，並讓交易介面維持回應靈敏。但成交品質仍取決於市場變動、流動性、手續費、路徑選擇、交易保護機制，以及鏈的排序政策。供應商的[讀取基準測試](/benchmarks)衡量的是讀取效能；端對端的 swap 效能、交易納入、WebSocket 行為與策略 PnL，則需要另外進行測試。

這個範圍界定讓基礎設施的宣稱保持誠實，也幫助團隊選擇符合自身工作負載的衡量方式。目標是在產品經濟效益對時間最敏感的路徑上，去除可避免的延遲。

我們圍繞這個目標打造了[低延遲 RPC 相關工作](/blog/how-we-built-low-latency-rpc-infrastructure)。[Alchemy Edge Proxy](/blog/alchemy-edge-proxy) 消除了入口處固定的請求路徑開銷，在其遷移測量中將 APAC 地區的 p99 從 150 毫秒降到 20 毫秒。[Cortex](/cortex) 的路由機制會依每個請求選擇健康的節點，而非僅以地理鄰近性作為唯一依據。Cortex 同時也是維持請求路徑在負載下保持回應靈敏的容量與機群運作的核心。我們的低延遲基礎設施工作橫跨邊緣節點、路由、容量、節點運作與衡量等各個層面，每一層都經過細部調校，為你提供可靠的低延遲服務。

## 如何評估你自己的執行路徑

從延遲造成最大使用者或經濟成本的流程開始著手。

1. 繪製從狀態讀取到使用者可見結果的完整路徑，包括路徑計算、簽署、提交、納入與狀態更新。
2. 從你的服務與使用者所在的地區，測試產品實際使用的方法與 payload。從你產品所依賴的 [RPC API](/rpc-api) 與[支援的鏈](/rpc)開始著手。在正常時期與高波動或高流量時期都執行相同測試。
3. 記錄 p50、p95、p99、成功率、逾時率，以及從報價到結果的時間。讀取、提交與納入延遲要分開記錄。
4. 將這些量測結果與實際結果連結起來：報價到成交的漂移、revert、錯失成交、取消成功率、客服聯繫次數，以及使用者流失率。

這樣一來，你就能針對自己的策略、資產與使用者建立一套成本模型——並清楚看出更快的路徑會在哪些地方改變執行結果。

## 常見問題

### RPC 延遲如何影響交易表現？

延遲會擴大交易應用程式所觀察到的狀態，與其交易實際執行狀態之間的落差。讀取緩慢會讓報價在簽署前就已過時，提交緩慢會給市場更多時間變動，確認緩慢則會讓使用者根據過時畫面採取行動。結果就是更差的成交、錯失交易或 revert。

### 較低的 RPC 延遲能保證更好的成交結果嗎？

較低的 RPC 延遲能減少提交前後可避免的延遲。但成交品質同時也取決於市場變動、流動性、手續費、私有訂單流、路徑選擇、鏈的排序機制，以及交易保護機制。

### 為何對交易應用程式而言，p95 比平均 RPC 延遲更有用？

平均值可能掩蓋在負載或波動期間聚集出現的緩慢請求。p95 顯示的是在測量條件下，95% 的成功回應至少有多快。應搭配成功率一起解讀，因為失敗與逾時需要獨立的可靠性衡量。

### 該如何為交易應用程式對 RPC 供應商進行基準測試？

從你的使用者與服務所在的地區，測試產品實際使用的方法與 payload。可以使用我們的[基準測試方法](/blog/how-we-benchmark-rpc-performance)作為可重現的起點。記錄 p50、p95、p99、成功率與逾時率，並將讀取、提交與納入延遲分開記錄。在波動劇烈、高流量的時段以及平靜市場狀況下，都重複執行這項測試。

### 價格衝擊和滑點是同一回事嗎？

不是。價格衝擊是交易規模對當前資金池造成的可預期影響。滑點則是報價輸出與使用者實際收到金額之間，在執行時產生的差異。[Raydium 的文件](https://docs.raydium.io/algorithms/slippage-and-price-impact)對兩者都提供了清楚的技術定義。

### 交易團隊應該分別對讀取、寫入與完整流程進行基準測試嗎？

是的。方法層級的讀取測試可以比較供應商在特定請求上的表現。而要理解報價新鮮度、決策、提交、納入與確認之間的整體關係，則需要完整交易流程的測試。這兩者的結論應該分開來看。