mcpField
B
boost

boost

github.com/goldsky-ioクラウド・DevOps124.0k 回インストール今日更新
リポジトリ

boost について

Goldsky Boost は、既存の RPC エンドポイントの前段に置く CDN レイヤーです。対象リクエストにはインデックス済みデータで応答し、それ以外は変更せず転送します。RPC プロバイダーへの課金対象となる呼び出しを減らしたいユーザー向けに、CLI 設定とキャッシュ状況や節約額の指標を提供します。

主な機能

  1. 01対象の JSON-RPC リクエストにインデックス済みデータで応答
  2. 02その他のリクエストを設定済みエンドポイントへ転送
  3. 03キャッシュヘッダーによる応答の確認
  4. 04CLI によるプロバイダーとチェーンの設定
  5. 05リクエスト履歴、指標、節約額の確認

活用シーン

  1. 01キャッシュ可能な読み取りのプロバイダー課金を削減
  2. 02Boost エンドポイント経由で JSON-RPC リクエストを転送
  3. 03キャッシュヒットと転送リクエスト数を測定
  4. 04ブロックタグによる低いキャッシュ率を調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/goldsky-io/goldsky-agent --skill boost

インストール後、Claude Code で/boostを入力して読み込まれたか確認します。

同梱ファイルevals/evals.jsonevals/trigger-eval.json

詳細

Goldsky Boost

Boost は、ユーザーがすでに利用料金を支払っている RPC エンドポイントの前段に置く CDN です。すべてのリクエストは、まず Goldsky のインデックス済みデータと照合されます。Boost に回答があればそれを返し、プロバイダーには呼び出しが届かないため、料金も発生しません。回答がなければ、リクエストは変更されずにユーザーのエンドポイントへ転送され、レスポンスがそのまま返されます。

Boost は無料です。 CDN のヒットも転送されたリクエストも、Goldsky から料金を請求されることはありません。この点を踏まえて説明してください。アップセルはなく、ユーザーにとって重要なのは、現在のプロバイダー料金がどれだけなくなるかだけです。

ほとんどの間違いを防ぐ基本的な考え方

ユーザーからの質問のほぼすべては、次の3つの事実で説明できます。

  1. API キーが Boost エンドポイントです。 設定はリクエストではなく、キーに保存されています。URL 内のキーによって、Boost は転送先のアップストリームを認識します。ユーザー自身のプロバイダー URL がリクエストとともに送信されることはありません。
  2. 1つのプロジェクトにつき Boost は1つだけです。 作成したり一覧表示したりできる、名前付きの Boost エンドポイントはありません。goldsky boost create や goldsky boost list を実行しようとしている場合、それらのコマンドは存在しません。コマンド一覧を参照してください。
  3. Boost はチェーンの最新ブロックを推測しません。 ブロックタグは常に転送されます。これは「なぜキャッシュされなかったのか」という質問で最もよくあるケースであり、バグではなく意図的な設計によるものです。

エンドポイント形式

https://edge.goldsky.com/boost/{chain}?key={GOLDSKY_API_KEY}

{chain} はチェーン名またはチェーン ID で、大文字と小文字は区別されません。/boost/ethereum と /boost/1 は同じエンドポイントです。

?key= はすべてのリクエストで必須です。キーがない場合のエラーは、次の2通りで異なります。どちらも本番環境で確認済みです。

リクエストレスポンス意味
?key= がない、?key= が空、または ?KEY=(名前は大文字と小文字が区別されます)401、空の本文エッジでキーを解決できませんでした
?key=<something unrecognised>404 + {"error":{"code":-32000,"message":"no Boost configuration for this key"}}キーは読み取られましたが、Boost の設定がありません

この違いを確認するのが最も早い診断方法です。本文が空の401は URL の形式が正しくないことを示します(パラメーターがない、空、または名前が誤っている状態です。環境変数が未設定で、展開結果が空になっていないか確認してください)。一方、JSON を含む404は、実在するキーが別のプロジェクトを指しているか、Boost が有効化されていないことを示します。

ドキュメントのページには、キーのない呼び出し元に x402 の支払いチャレンジが返されると記載されています。これは /standard/evm/... における Edge の動作であり、実際に大きな JSON 本文を含む 402 が返されます。/boost/... ではそのようなことはありません。実際の x402 チャレンジは明確に判別できます。そのため、本文が空であること自体が、これが x402 ではない証拠です。ユーザーに支払いチャレンジを想定するよう伝えると、無料の製品では発生し得ない課金問題を探させることになります。

キーによって認証ヘッダーも区別されます。プロバイダー独自の認証情報の送信を参照してください。

そのまま置き換える

この製品の価値は、それ以外を何も変更しなくてよい点にあります。移行ガイドではなく、次の内容をユーザーに示してください。

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://edge.goldsky.com/boost/ethereum?key=YOUR_KEY'),
})

メソッドもパラメーターもレスポンスの形式も同じです。

動作確認
curl -i "https://edge.goldsky.com/boost/ethereum?key=YOUR_KEY" \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x1b4",false]}'

2回実行してください。 Boost が最近配信していないブロックへの最初の呼び出しは、リーダーがストレージからその範囲を読み込む間、MISS を返すことがあります。1回だけテストして MISS が表示されると、ユーザーは Boost が壊れていると判断してしまいます。そのように判断する前に、もう一度実行するよう伝えてください。

CDN が提供するもの

MethodCDN から提供される条件
eth_getBlockByNumberブロックが具体的な 16 進数の高さである
eth_getBlockByHash常に対象になる
eth_getTransactionByHash常に対象になる
eth_getTransactionReceipt常に対象になる
eth_getLogsfromBlock と toBlock が具体的な 16 進数の高さである、または blockHash が設定されている
eth_getBlockReceiptsブロックが具体的な 16 進数の高さである

eth_chainId と net_version は、どちらのバックエンドにもアクセスせず、エッジで応答します。

それ以外はすべて無料で転送されます。 書き込み、トレース、eth_call、eth_getBalance はすべてパススルーです。対象であっても、必ず提供されるとは限りません。Boost にまだ特定のデータがない場合、この表にあるメソッドでも転送されます。

ブロックタグは常に転送されます

latest、pending、safe、finalized、earliest を指定したリクエストが CDN から提供されることはありません。Goldsky が把握しているヘッドは、ユーザーのプロバイダーよりブロック 1、2 個分遅れることがあるため、latest を提供すると、古いブロックやまもなく再編成されるブロックを返してしまうことがあります。ヘッドの正確な情報はユーザーのエンドポイントが基準です。

範囲の指定にタグを使った eth_getLogs にも同じことが当てはまります。そのため、fromBlock: "0x..." から toBlock: "latest" までを指定すると、ヒット率は 0% になります。toBlock を具体的な高さに固定すると、CDN が利用されます。

ヒット率が低いという報告があったときに、最初に確認すべき最も重要な点です。

レスポンスヘッダーの読み方

Header値意味
x-cacheHIT、MISSBoost が提供したか、転送したか
x-edge-sourcecache、static、endpoint実際に応答したもの
x-edge-billable整数Boost が提供した項目数。この名前は Boost が無料になる前から使われており、料金ではなく件数を示します
x-edge-duration-ms整数Boost が提供に費やした実時間
x-edge-regionAWS リージョン提供したエッジリージョン
x-edge-versionビルド文字列提供に使われた Boost のビルド

グラフ化するなら x-cache が適しています。標準の CDN ヘッダーなので、既存のツールですでに扱えます。HIT の数を集計すれば、プロバイダーに課金されなかった呼び出しの正確な数がわかります。

すべてのレスポンスヘッダーは、ブラウザーの JavaScript から読み取れます(Access-Control-Expose-Headers: *)。

バッチ処理

Boost は JSON-RPC バッチを項目ごとに処理します。キャッシュ可能な項目は CDN から提供し、それ以外は単一の転送バッチでプロバイダーに転送します。有効化は不要です。同じアドレスに配列を送信してください。

注意が必要な点が 2 つあります。

  • すべての項目が提供された場合にのみ、x-cache は HIT になります。 45 項目中 44 項目が CDN から提供されたバッチでも、MISS と報告されます。バッチの場合は x-cache ではなく、提供された項目数を示す x-edge-billable を確認してください。
  • 100 項目を超える配列は全体が転送されます。CDN を検索せず、無料のパススルーとして一括転送されます。ヒットを維持するには、大きなバッチを 100 項目ずつに分割してください。

各項目には一意の id を付けてください。JSON-RPC ではレスポンスの順序が保証されないため、位置ではなく id で照合します。

サポート対象ネットワーク

Boost が提供するのは、CDN がジェネシスからカバーしているチェーンのみです。カバー範囲が後のブロックから始まるチェーンは、CDN が直近の履歴には応答する一方で、それより前のすべての履歴を気付かれないまま取りこぼします。これは Boost の目的とは正反対であるため、提供されません。

ネットワークパス名チェーン ID
Ethereumethereum1
Basebase8453
Polygonpolygon137
Optimismoptimism10
Avalancheavalanche43114
HyperEVMhyperevm999
Arcarc5042
Robinhood Chainrobinhood4663
Ethereum Sepoliasepolia11155111
Base Sepoliabase-sepolia84532

Goldsky がインデックス化しているものの、現在 Boost で提供していないチェーンには、Arbitrum、BNB Chain、Celo、Gnosis、Sei、Tron、Abstract、Monad があります。いずれもジェネシスよりかなり後のブロックからカバーされています。ユーザーがこれらのいずれかを求めた場合、その理由を説明し、代替として Edge(/edge)を案内してください。

goldsky boost chains は最新の一覧です。バックフィルが行われた時点で、この表よりも優先されます。記憶に頼って断言せず、実行してください。

コマンド一覧

プロジェクトごとに Boost は 1 つだけなので、名前を指定するコマンドはありません。 古いドキュメントには boost create <name>、list、pause、resume、delete の説明がありますが、これらは削除されています。ユーザーがこれらのコマンドを掲載したページに従っている場合、そのページは古いものです。現在のコマンドは以下のとおりです。見解が異なる場合は、goldsky boost --help で確認してください。

コマンド機能
goldsky boost enableプロジェクトの Boost を有効にします。初回の有効化では、プロバイダーの設定を順に行います
goldsky boost disable設定とキーを保持したまま、配信を停止します
goldsky boost getチェーンごとのプロバイダー、配信 URL、ステータスを表示します
goldsky boost update--allowed-domains、--provider-rate を設定します
goldsky boost revealBoost が使用する API キーを表示します
goldsky boost metricsヒット数、レイテンシ、ミスの理由、プロバイダーごとの統計、削減額を JSON 形式で表示します
goldsky boost requestsリクエストごとの履歴を表示します。メソッド、チェーン、ヒットまたは転送、使用プロバイダー、所要時間を確認できます
goldsky boost chainsBoost がキャッシュできるチェーンと、それぞれのキャッシュ対象期間を表示します
goldsky boost validate <url>プロバイダー URL を調べ、チェーンを検出して応答を確認します
goldsky boost set --chain <c>チェーンの有効・無効を切り替え、--forward-timeout/--cache-timeout を設定します
goldsky boost provider …アップストリームを管理します。以下を参照してください

便利なフラグ:

  • boost enable --chain <c> --provider-url <url> --header k:v — Boost の有効化直後に最初のプロバイダーを設定する、一度限りのセットアップです。
  • boost metrics --from <iso> --to <iso> --bucket-size 1m|5m|1h|6h|1d --chain <c>
  • boost requests --chain <c> --method eth_getLogs --errors --limit <n>(50 件ずつページ分割されます)
  • boost validate <url> --chain <c> は、URL のチェーンがユーザーの意図したものと一致するかを確認します。
プロバイダー(アップストリーム)
コマンド必須フラグ
boost provider connect--vendor quicknode|alchemy、--key、繰り返し指定可能な --chain
boost provider add--chain、--url、繰り返し指定可能な --header k:v、任意の --id
boost provider replace--chain、--id、--url、--header、--clear-headers
boost provider activate--chain、--id
boost provider remove--chain、--id、--force
boost provider set--chain、--id、--timeout、--vendor
boost provider disconnect--vendor、--force

provider connect では --key を省略してください。 CLI が入力を求めるため、認証情報がシェルの履歴に残りません。プロバイダーの認証情報をチャットに貼り付けるよう、ユーザーに求めてはいけません。/auth-setup の Goldsky トークンにも同じルールが適用されます。

チェーンごとに複数のアップストリームを設定できますが、有効にできるのは 1 つだけです。フェイルオーバーには provider activate の明示的な実行が必要です。Boost が自動で切り替えることはありません。ユーザーが自動フェイルオーバーを想定している場合は、その認識を訂正してください。

設定

方法は 2 つあります。決めつけず、どちらを希望するかユーザーに尋ねてください。

プロバイダーアカウントを接続する — Boost がチェーンごとにエンドポイントを作成します。

ベンダー認証情報Boost が作成するもの
QuickNodeAdmin API へのアクセス権を持つ API キー(Dashboard → API Keys)。有料プランのみアカウント内にチェーンごとのエンドポイントを 1 つ
AlchemyAdmin API の App Management に対する読み取り・書き込み権限を持つアクセスキー(Dashboard → Settings → Security)。アプリの API キーではありません選択したチェーンを許可リストに登録したアプリを 1 つ

Boost が操作するのは、自ら作成したものだけです。接続を解除すると、それらのエンドポイントが削除され、ほかのものには影響しません。

または URL を貼り付ける — 自分で運用するノードや Goldsky 独自の Edge RPC など、https でアクセス可能なエンドポイントを使用できます。プライベート、ループバック、リンクローカルのアドレスは拒否されます。

確定する前に検証してください。

goldsky boost validate https://my-provider.example/rpc --chain ethereum

検証ゲート

Boost の有効化と、その後の設定変更には、検証済み組織が必要です。Viewer より上位のメンバーのうち 1 人がビジネス用メールアドレスを持っていれば、チームは自動的に要件を満たします。個人用メールアドレス(gmail.com、outlook.com、proton.me)は対象外です。フォームへの入力も審査も不要です。操作の実行時にチェックされ、承認は恒久的に有効です。

ユーザーにこの条件について尋ねられたときに重要なのは、検証はコントロールプレーンのゲートであり、ランタイムのゲートではないということです。

操作検証が必要
Boost を有効にする、プロバイダーを接続または切断する、アップストリームを追加・置換・有効化・削除する、チェーンを切り替えるかタイムアウトを変更する、API キーを表示するはい
設定、チェーン、メトリクスを読み取るいいえ
Boost を無効化または削除するいいえ
既存のエンドポイントでトラフィックを配信するいいえ

すでに設定済みのエンドポイントは、検証の状態にかかわらず応答を続けます。ユーザーがすでに配信しているトラフィックが、ここで中断されることはありません。「検証が必要」という表現は停止のリスクがあるように受け取られますが、実際にはそうではないことを明確に伝えてください。

通常は、ビジネス用メールアドレスを持つチームメイトを追加すれば、直ちに解決します。それが適さない場合(ドメインの共有、設定前の評価、ドメインの誤分類)は、ダッシュボード URL に記載されているチーム ID を添えて [email protected] に連絡するよう案内してください。検証を確認できない場合、変更は拒否ではなく再試行を求める形で拒まれ、状態は書き込まれません。

プロバイダー独自の認証情報を送信する

Goldsky のキーはクエリ文字列に含まれるため、リクエスト上の Authorization と X-API-Key ヘッダーがプロバイダーのものであることは明らかです。これらは変更せずに転送されます。この動作は ?key= が存在する場合にのみ有効です。これがないと、Boost は Authorization ヘッダーの認証情報が誰のものか判別できません。

変更されない認証情報には、エンドポイントに設定したヘッダー(provider add --header k:v)を使用してください。一度保存すれば、すべての転送に適用され、呼び出し元が認証情報を持つ必要はありません。

URL のユーザー情報(https://user:pass@…)として指定された認証情報は、リクエストが Goldsky を離れる前に Authorization: Basic に変換されます。URL とヘッダーは保存時に暗号化され、ログ、エラー、メトリクスに記録されることはありません。

トラブルシューティング

実際の原因である頻度が高い順に並んでいるため、上から順に確認してください。

症状考えられる原因と対処法
本文が空の 401キーを解決できていません。?key= がない、空、または名前が間違っています(大文字小文字を区別するため、?KEY= では失敗します)。通常は、未設定の環境変数が展開されて何も入っていないことが原因です。課金の問題ではありません。Boost は無料です。
-32000 no Boost configuration for this key を伴う 404キーは読み取られていますが、Boost の設定がありません。プロジェクトが違うか、Boost が有効になっていません。goldsky boost get で確認し、正しいキーは goldsky boost reveal で取得してください。
ヒット率がほぼゼロリクエストにブロックタグが含まれています。latest/pending/safe/finalized/earliest は、eth_getLogs の範囲指定に使われている場合も含め、常に転送されます。具体的な 16 進数の高さを指定してください。
最初の呼び出しが MISS になり、ユーザーがそこで止めてしまうリーダーはストレージから対象範囲をウォームアップします。同じ呼び出しを繰り返してください。
明らかにヒットがあるのに、大きなバッチが MISS を返すバッチでは、すべての項目が処理された場合に限り x-cache が HIT になります。x-edge-billable も確認してください。また、配列が 100 項目以下であることを確認してください。それを超えると、全体が転送されます。
対象メソッドなのに転送されるBoost がまだそのデータを保持していません。対象であっても、必ず処理されるとは限りません。boost requests --method <m> でミスの理由を確認してください。
チェーンへのリクエストが拒否されるチェーンに有効なアップストリームがないか、無効になっています。goldsky boost get でチェーンごとの状態を確認してください。boost set --chain <c> --enabled true で再度有効にできます。
チェーンがまったく利用できないBoost が提供するのはジェネシスまでカバーされたチェーンのみです。goldsky boost chains を確認してください。表示されない場合は、Edge(/edge)が代替手段になります。
設定変更が拒否される検証ゲートによるものです。上記を確認し、既存のトラフィックに影響がないことも確かめてください。
プロバイダーが転送された呼び出しを拒否する許可リストに登録できる固定の送信元 IP アドレス一覧はありません。Boost は us-east-1、us-west-2、eu-central-1 の Fargate タスクから転送し、アドレスは変動します。許可リストに登録する代わりに、認証情報(エンドポイント URL または設定済みのヘッダー)を使って Boost を認証してください。
サブスクリプションが機能しないBoost は HTTP のみで、WebSocket には対応していません。eth_subscribe/wss:// はプロバイダーを指定したままにしてください。
ブラウザーからの呼び出しが CORS でブロックされる許可するドメインはプロバイダーではなく、エンドポイントで設定します(boost update --allowed-domains)。認証情報を含むリクエストは許可されません。
レート制限に関する質問Boost の予算は Goldsky が管理しており、API は Boost エンドポイントに送られたレート制限予算を拒否します。Edge とは異なります。公正利用の範囲内では無制限です。

実際の問題の診断は、次のコマンドから始めてください。

goldsky boost get                                  # per-chain status and active upstreams
goldsky boost requests --limit 50                  # what actually happened, with miss reasons
goldsky boost metrics --from <iso> --bucket-size 1h

ヘッダーの転送

転送時には、呼び出し元のヘッダーに加え、エンドポイントに設定されたヘッダーもプロバイダーに送られます(名前が重複する場合は、設定済みのヘッダーが優先されます)。Boost が取り除くのは、自身で管理する次のヘッダーのみです。X-ERPC-Secret-Token、Host、Content-Type/Accept(application/json に固定)、Content-Length、Accept-Encoding/Content-Encoding、Cookie、Proxy-Authorization、およびホップバイホップヘッダーです。トレースコンテキスト(traceparent、tracestate、b3、baggage)、User-Agent、カスタムの x-* はそのまま転送されます。

X-Forwarded-For は、変更されず、チェーン全体がプロバイダーに届きます。最後のエントリを参照してください。これが Goldsky のロードバランサーが観測したアドレスです。それより前のエントリは呼び出し元が指定したもので、信頼できません。

レスポンスでは、プロバイダーの Cache-Control、Retry-After、ETag、カスタムの x-* がそのまま引き継がれます。破棄されるヘッダー:Content-Encoding、Content-Type、Content-Length、Set-Cookie、Access-Control-*、x-cache/x-edge-*、x-goldsky-*。

Boost と Edge のどちらを選ぶ?

ホストを共有しているため、混同しやすいサービスです。

  • Boost は、ユーザーがすでに利用しているプロバイダーを前段で処理します。無料で、独自のアップストリームを使用し、ジェネシスまでカバーされたチェーンのみ、HTTP のみです。既存の請求額を抑える場合に使用します。
  • Edge(/edge)は、ユーザーがプロバイダーの代わりに購入する、Goldsky独自のマネージド RPC です。対応チェーンが大幅に多く、設定可能なレート制限、ヘッジ、フェイルオーバーに対応しています。

「Alchemy の利用料金を下げたい」→ Boost。「Alchemy の利用をやめたい」→ Edge。Boost のアップストリームとして Edge を指定することもできます。

関連情報

コメント