---
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
/>

レイテンシーのコストは、プロダクトが観測したチェーンの状態と、そのアクションが実行される時点の状態とのギャップとして現れる。このギャップは、プロダクトが読み取り、判断し、送信し、確認を待つのに費やす1ミリ秒ごとに広がっていく。

長期的なポートフォリオビューにとっては、このギャップは単なる煩わしさで済むかもしれない。しかし、マーケットメーカー、スワップルーター、清算エンジン、あるいは失効しかけた注文をキャンセルしようとするトレーダーにとっては、戦略のエッジのかなりの部分を失うことになりかねない。[低レイテンシーRPC](/rpc-api)は、こうしたプロダクトがより新しい状態に基づいて行動できるようにするため、成功するトレーディング体験の中核となる。

## 取引が実行される前に見積もりは古くなりうる

スワップの見積もりは、アプリケーションがリクエストした時点でのプール準備金、オーダーブックの流動性、ガス状況、市場状態を捉える。ユーザーがトランザクションを確認している間も、これらの入力は変化し続ける。

基本的な流れはシンプルだ。

1. アプリがチェーンおよび市場の状態を読み取る。
2. 見積もりまたは取引判断を計算する。
3. ユーザーがトランザクションを送信する。
4. ネットワークがそれを伝播、シーケンス、実行する。
5. アプリがレシートを受け取り、表示を更新する。

それぞれの遅延が、最終的なアクションの鮮度を下げる。読み取りが遅ければ古い市場データを使うことになり、送信が遅ければ市場が動く時間を市場に与えることになり、確認が遅ければユーザーは古いステータスを見続けることになる。

[0x](/case-studies/0x)は複数の流動性ソースにまたがって取引の価格を算出している。同チームは、リクエストが処理中の間にも価格が動きうるため、応答性と正確なデータを見積もりの品質に直結させており、1秒未満で見積もりを生成している。

[Jupiter](https://developers.jup.ag/docs/transaction/submit)は、このタイミングのギャップを端的に示している。同社の直接着地パスは50〜400ミリ秒(Solanaブロック0〜1個分)を目標としているのに対し、標準的なRPC送信では400ミリ秒〜1.2秒(ブロック1〜3個分)かかる。見積もりから実行までのブロック数が少ないほど、状態が変化する余地は少なくなる。

## レイテンシーが積み重なる4つの段階

すべての取引はこれらの段階を経て進む。いずれかの段階での遅延は、最終結果の鮮度や確実性を損なう。

<EmbeddedTable
  table={{
    columns: [
      { key: "stage", width: 200, title: "Stage", dataType: "object" },
      {
        key: "measures",
        width: 280,
        title: "What it measures",
        dataType: "object",
      },
      {
        key: "cost",
        width: 300,
        title: "What a delay can cost",
        dataType: "object",
      },
    ],
    data: [
      {
        stage: { title: "Read latency", tooltip: "", icon: "" },
        measures: {
          title:
            "Time to receive a valid answer about balances, pool state, quotes, receipts, or the latest block through a Node API call.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "A strategy or user makes a decision on older state. A quote may already be stale.",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        stage: { title: "Decision latency", tooltip: "", icon: "" },
        measures: {
          title:
            "Time spent calculating a route, applying risk checks, signing, or preparing a transaction.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "The execution window widens before the transaction leaves the application.",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        stage: {
          title: "Submission and inclusion latency",
          tooltip: "",
          icon: "",
        },
        measures: {
          title:
            "Time from broadcast until the relevant chain or matching engine accepts and sequences the action.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "Liquidity changes, a cancel arrives too late, or another participant gets priority.",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        stage: {
          title: "Confirmation and refresh latency",
          tooltip: "",
          icon: "",
        },
        measures: {
          title: "Time to learn the outcome and show current state.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "Users see stale balances or ambiguous transaction status, and automated systems react later.",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

これらの段階は互いに作用し合う。市場の読み取りが古ければ、書き込みパスがどれだけ速くても古いままだ。変動が激しい局面では、平均値よりも最も遅いリクエストの方が重要になる。失敗そのものも独自のリスクを生む。リトライ、古い画面表示、アクションの取りこぼしなどだ。

レイテンシーに敏感なプロダクトは、成功率とあわせてp95およびp99の応答時間を評価すべきだ。公開されている[ベンチマーク手法](/blog/how-we-benchmark-rpc-performance)は、ウォームアップ済みのメソッド単位のEVM読み取りを測定し、成功時のレイテンシーを失敗とは分けて報告している。[Node API](/rpc-api)は、プロダクトがチェーンとやり取りする際に使う読み取りと書き込みをカバーする。これは特定のプロバイダーのパスを測定するものであり、トレーディングチームは自身の読み取り、書き込み、リージョン、トラフィック形状をテストする必要がある。

## オンチェーントレーディングにおいて、レイテンシーはどのように経済的コストになるのか?

レイテンシーが経済的コストになるのは、それが実行結果を変えるときであり、その変わり方はワークロードによって異なる。以下は、オンチェーントレーディングシステムで繰り返し見られるパターンだ。

### スワップ:古くなった見積もりはスリッページまたはリバートになる

価格インパクトとスリッページはしばしば一括りに扱われるが、両者は異なるコストを示している。[DeFiインフラガイド](/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale)は、こうしたコストが実際の見積もりフローにどう現れるかを示している。価格インパクトは、あるサイズの取引がプールの価格に与える予測可能な変化だ。スリッページは、見積もられた出力と実行時に実際に受け取る出力との差であり、レイテンシー、同時実行中のトランザクション、ブロックへの取り込み順序に左右される。

この区別はプロダクト設計において重要だ。価格インパクトは見積もり時点で可視化される。スリッページはトランザクションが未確定の間に拡大する。最小出力を保証するガードは、過度な価格変動をリバートに変換することでユーザーを保護する。手数料が低いトランザクションは価格環境が変化する間より長く待つことができ、最小出力、最大入力、期限の設定によってユーザーが許容する最悪の実行条件を定めることができる。

ユーザーから見た結果は、より悪い価格、取引の失敗、あるいは変動する市場への露出を減らすためのより厳しい実行パスとなる。読み取りと送信を高速化することで、この露出時間の一部を縮小できる。

### マーケットメイキングと注文管理:キャンセルの遅れがトキシックフローになりうる

マーケットメーカーは価格の動きに合わせて継続的に見積もりを更新している。システムが価格変動を検知するのが遅れたり、キャンセルの送信が遅れたりすると、指値注文が採算が合わなくなった後で約定してしまうことがある。成行注文を出すトレーダーは逆のリスクに直面する。注文が市場に届く頃には、利用可能だった流動性が失われている可能性がある。

### 清算とアービトラージ:時間そのものが機会の一部になる

清算エンジンとアービトラージシステムは、状態の変化を観測し、機会が閉じる前に行動しようと競い合う。ここで争われるのは、新しいオラクル価格、変化したヘルスファクター、プールの不均衡、あるいは取引所間の価格差といったものだ。これを逃すことは収益の損失を意味しうる。繰り返し失敗した試行は、手数料を浪費し、ブロックスペースを消費することにもなる。

チェーンの設計は、この競争の形を変える。先着順でシーケンスするシステムでは、低レイテンシーのパスが順序に直接関わってくる。優先手数料を使うシステムでは、手数料とタイミングの両方が重要になる。プライベートなオーダーフローやバンドルを用いるシステムでは、可視性とアトミックな実行がさらなるトレードオフをもたらす。インフラはこうした市場のルールの中で機能する。その役割は、戦略がそのルールに参入する前に不要な遅延を生じさせないことだ。

### ウォレットとトレーディングインターフェース:遅延は信頼の問題になる

レイテンシーが影響するのは約定価格だけではない。ウォレットやトレーディングアプリは、ユーザーに有用な画面を見せる前に多くの呼び出しを行う。残高、許可(allowance)、ルートの見積もり、ガス見積もり、レシート、トランザクション履歴などだ。これらの呼び出しが遅かったり、断続的に失敗したりすると、ユーザーには変動する価格、遅延したステータス、あるいはフリーズしたように見えるインターフェースが表示される。

これはボラティリティの高い局面では特に問題になる。静かな市場では単なる不便に過ぎない遅い残高更新が、ユーザーがリスクを管理しようとしているときにはヘッジやキャンセルの判断、入金確認を遅らせることになる。

## テールレイテンシーが平均値より重要な理由

レイテンシーの分布にはテールがある。エンドポイントが負荷下で遅くなると、プロダクトはトラフィック増加時、ボラティリティ時、あるいはチェーンの混雑時にその遅いパスを経験することになる。

だからこそ、プロバイダーの評価では次の4つの問いに答える必要がある。

- どのメソッドがクリティカルパス上にあるか?最新ブロックの読み取り、`eth_call`、`eth_getLogs`、レシート検索、トランザクションのブロードキャストはそれぞれ振る舞いが異なるため、個別に評価すること。
- ユーザーやサービスはどのリージョンから接続しているか?地理的条件によってネットワークパスは変わる。
- 成功した呼び出しのp95とp99はどれくらい遅いか?こうした値は平均値では見えないリクエストを明らかにする。
- リクエストはどれくらいの頻度で失敗またはタイムアウトするか?タイムアウトは信頼性に関わる事象であり、リトライ、古いUI、アクションの取りこぼしを引き起こしうる。

ベンチマークはこうした条件を明示し、購入者が実際に運用するプロダクトのパスを測定すべきだ。[ベンチマーク手法](/blog/how-we-benchmark-rpc-performance)では、メソッド単位の比較ごとにリクエストの発生元、メソッド、ペイロード、タイムアウト、成功判定基準、接続状態を固定し、開発者のインフラ選定を支援している。

## 低レイテンシーRPCで解決できること、できないこと

より高速なRPCレイヤーは、より早く現在の状態を返し、より早く署名済みトランザクションを送信し、トレーディングインターフェースの応答性を維持できる。それでも約定の質は、市場の動き、流動性、手数料、ルート選択、トランザクション保護、チェーンのシーケンスポリシーに左右される。プロバイダーの[読み取りベンチマーク](/benchmarks)は読み取り性能を測定するものであり、エンドツーエンドのスワップ性能、トランザクションの取り込み、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. プロダクトが実際に使用しているメソッドとペイロードを、サービスとユーザーが動作しているリージョンからテストする。プロダクトが依存している[RPC API](/rpc-api)と[サポートされているチェーン](/rpc)から始める。通常時と、ボラティリティやトラフィックが高い時期の両方で同じテストを実行する。
3. p50、p95、p99、成功率、タイムアウト率、見積もりから結果までの時間を記録する。読み取り、送信、取り込みのレイテンシーは分けて記録する。
4. これらの測定値を結果と結びつける。見積もりと約定のずれ、リバート、約定の取りこぼし、キャンセルの成功率、サポートへの問い合わせ、ユーザーの離脱などだ。

これにより、自社の戦略、資産、ユーザーに合わせたコストモデルが構築され、より速いパスがどこで実行結果を変えるかが見えてくる。

## よくある質問

### RPCのレイテンシーはトレーディングパフォーマンスにどう影響するか?

レイテンシーは、トレーディングアプリが観測した状態と、そのトランザクションが実行される時点の状態とのギャップを広げる。読み取りが遅ければ、署名する前に見積もりが古くなる。送信が遅ければ、市場が動く時間を市場に与えることになる。確認が遅ければ、ユーザーは古い画面を見ながら行動することになる。結果として、より悪い約定、取引の失敗、あるいはリバートが生じる。

### RPCのレイテンシーが低ければ、より良い約定が保証されるか?

RPCのレイテンシーが低いことは、送信前および送信中の回避可能な遅延を減らす。約定の質は、市場の動き、流動性、手数料、プライベートなオーダーフロー、ルート選択、チェーンのシーケンス、トランザクション保護にも左右される。

### トレーディングアプリにとって、なぜ平均RPCレイテンシーよりp95の方が有用なのか?

平均値は、負荷やボラティリティの局面で集中する遅いリクエストを覆い隠してしまうことがある。p95は、測定条件下で成功した応答の95%が少なくともこの速さだったことを示す。失敗とタイムアウトには別の信頼性測定が必要なため、成功率とあわせて読むこと。

### トレーディングアプリ向けにRPCプロバイダーをベンチマークするにはどうすればよいか?

プロダクトが実際に使用しているメソッドとペイロードを、ユーザーとサービスが動作しているリージョンからテストする。再現可能な出発点として[ベンチマーク手法](/blog/how-we-benchmark-rpc-performance)を利用する。p50、p95、p99、成功率、タイムアウト率を記録し、読み取り、送信、取り込みのレイテンシーは分けて記録する。ボラティリティが高くトラフィックの多い時間帯と、静かな市場状態の両方でテストを繰り返す。

### 価格インパクトとスリッページは同じものか?

いいえ。価格インパクトは、取引サイズが現在のプールに与える予測可能な影響だ。スリッページは、見積もられた出力と実行時にユーザーが実際に受け取る出力との差だ。[Raydiumのドキュメント](https://docs.raydium.io/algorithms/slippage-and-price-impact)には、それぞれの明確な技術的定義が記載されている。

### トレーディングチームは読み取り、書き込み、全体のワークフローを別々にベンチマークすべきか?

その通りだ。メソッド単位の読み取りテストは、特定のリクエストにおけるプロバイダーの挙動を比較できる。一方、見積もりの鮮度、意思決定、送信、取り込み、確認を一体として理解するには、全体のトレーディングフローテストが必要だ。それぞれの結論は分けて扱うこと。