専用ブロックチェーンインフラの仕組み

ほとんどのプロダクションワークロードは共有のブロックチェーンRPCインフラストラクチャで問題なく動作する。しかし、一部のワークロードはそうはいかない。シーケンサー（ロールアップのトランザクション順序付けサービス）へのラウンドトリップレイテンシーが、注文が次のブロックに入るかどうかを左右するトレーディングデスク。共有プロバイダーではホストしてくれないカスタムEVMトレーサーをシミュレーションエンジンで動かすセキュリティ企業。他社のワークロードと共有されたハードウェアにコンプライアンスチームがサインオフしない規制対象のフィンテック企業。

こうしたワークロードに対する答えが専用ブロックチェーンインフラストラクチャだ。

Dedicatedは同じインフラストラクチャを、1テナントに限定して提供するものだ。RPCスタックも、データサービスも、APIも同じだが、キャパシティ、ホスト、ランタイムは自分たち専用となる。BlockaidのようなチームはAlchemy Dedicated Clustersを利用して、顧客が求めるパフォーマンスと一貫性を保ちながら3,120億ドル以上の資産を保護している。

この違いこそが、限られた一部のワークロードにとってdedicatedがその価格に見合う理由であり、それ以外の全員にとって共有がデフォルトとして正しい理由でもある。考えるべき問いは、dedicatedの方が優れているかどうかではない。自分のワークロードが、共有インフラストラクチャが想定する範囲を超えているかどうかだ。

専用ブロックチェーンインフラストラクチャとは何か

専用ブロックチェーンインフラストラクチャとは、シングルテナントのRPCおよびインデックスクラスターのことだ。すなわち、1つのワークロードのために確保されたハードウェア上に構築された、ブロックチェーンノード群、ルーティングインフラストラクチャ、データサービスの集合である。APIサーフェスはデフォルトでは共有インフラストラクチャと同じなので、既存のインテグレーションはコード変更なしに移行できる。カスタマイズはこのサーフェスを置き換えるのではなく拡張する形で行われる。カスタムトレーサーやバイナリ、リージョンの選択、リクエスト単位課金ではなくキャパシティベースの料金体系などだ。

典型的なクラスターには以下が含まれる。

• チェーン用のフルーノードのプールで、顧客のピークリクエストレートに加えて、ノード再起動時にトラフィックが落ちないよう1台余分に確保されたもの。これはN+1パターンとも呼ばれる。
• 履歴状態へのアクセス用のオプションのアーカイブノード。直近のブロックだけでなく、ジェネシスからの完全な状態を提供する。
• ノードプールの前段に置かれるエッジプロキシとロードバランサー。すべてのリクエストを受け取り、どのノードに処理させるかを決めるルーティング層として機能する。
• 可観測性スタック。通常はノードの健全性、リクエストレイテンシー、エラーレートを表示するGrafanaダッシュボード。
• クラスターが想定していないトラフィックスパイクに対する、共有インフラストラクチャへのフェイルオーバーパス。

このインフラストラクチャは、共有プロバイダーが内部で運用しているものと同じ形をしている。違うのはリースのされ方だ。Dedicatedとは、キャパシティが1つの顧客に確約されており、ランタイムは顧客が設定でき、データパスが他の誰のワークロードとも共有されないことを意味する。

どのようなワークロードでdedicatedインフラストラクチャが必要になるか

4つのワークロードパターンが、共有インフラストラクチャでできることの限界を超える。

カスタムトレーサーとバイナリ

EVMトレーサーとは、トランザクション実行を計測する関数のことだ。内部コールトレース、ストレージ読み取り、struct log、revertの理由などを抽出する。callTracerやprestateTracerのような標準トレーサーは、大半の分析用途をカバーする。しかしセキュリティツール、シミュレーションエンジン、フォレンジックプラットフォームはさらに踏み込んだものを必要とする。自社の内部スキーマに合わせたカスタムJavaScriptトレーサーや、共有プロバイダーが決して公開しない実行状態を露出させる改変版のgethやerigonバイナリなどだ。

これらを共有ホスト上で動かすことは、ホストにとってもテナントにとっても安全ではない。だからこそシミュレーションやセキュリティのベンダーはdedicatedクラスターを運用している。

リージョンに縛られるレイテンシー

ほとんどのアプリケーショントラフィックにとって、数ホップ分の余分なネットワーク経路は気づかれることもない。しかし、1秒あたり数十リクエストを発行し、その1つ1つを重視するワークロードにとっては、クライアント、ノード、シーケンサーの間の物理的な距離が、トランザクションが間に合って着地するかどうかを左右することがある。

高頻度取引、オラクルフィード、そしてトランザクションがブロックへ順序付けされる過程から価値を抽出するボットであるMEVサーチャーは、こうした僅差を競い合っている。dedicatedクラスターであれば、顧客はシーケンサーや消費者と同じリージョンにノードプールを配置できる。

規制上の分離

一部のコンプライアンスフレームワークはシングルテナントのコンピュートを要求する。顧客データの分離に関するSOC 2 Type IIの統制、特定の銀行・証券業の規制体制、そして大手金融機関の社内リスクレビューは、しばしば同じ要件に行き着く。他の顧客のワークロードが同じホスト上で動いてはならない、というものだ。

共有インフラストラクチャは設計上、同じホスト上で多数の顧客を動かす。dedicatedインフラストラクチャはそうではない。

無制限のクエリ範囲

共有RPCプロバイダーは、クエリボムからクラスターを守るためにeth_getLogsの範囲に上限を設けている。それはユーザーの最近のトランザクションを読み取るウォレットにとっては問題ないし、だからこそほとんどの分析ワークロードは生のeth_getLogsではなく、インデックス化されたData APIへルーティングされる。

しかし、生ログの大規模な履歴範囲をスキャンする必要があるエクスプローラー、インデクサー、チェーン分析チームにとっては、この上限がボトルネックになる。dedicatedクラスターではこの上限を解除できる。なぜなら、その上限は他のテナントを守るために存在するものであり、シングルテナントクラスターには守るべき他のテナントが存在しないからだ。

判断のための簡単な指針を示す。

ワークロードがこの4つのdedicatedパターンのいずれにも当てはまらない場合、共有インフラストラクチャの方がほぼ常に安価で、シンプルで、導入も速い。

dedicatedクラスターはどのように機能するか

dedicatedクラスターのアーキテクチャは、6つの選択に集約される。誰と同じボックスで動くか、ボックスがどこにあるか、いくつあるか、状態についてどう合意するか、どのソフトウェアを動かすか、そしてどう課金するか、である。

シングルテナント分離

シングルテナントとは、顧客のノードがその顧客のワークロードのために確保されたコンピュート上で動くことを意味する。実務上、コンプライアンスレビューでは、ワークロード分離、アクセス制御、監査可能性、鍵の取り扱いに関する文書化がしばしば求められる。

この分離が実際に何を排除するかが重要だ。共有ホスト上のノイジーネイバーが顧客のテールレイテンシーを悪化させることはない。なぜなら隣人がいないからだ。他のテナントからのサイドチャネル漏洩が顧客のプロセスに到達することもない。コンプライアンスレビュアーは、「プロバイダーがワークロードを分離してくれると信じている」ではなく、文書化された統制を示すことができる。

リージョンデプロイメント

クライアントからRPCノードまでのレイテンシーはネットワーク距離によって制約される。ほとんどのアプリケーショントラフィックにとって、それは気づかれることもない。しかし、レイテンシーに敏感なリクエストを頻繁に発行するワークロードにとっては、ノードをスタック、ユーザー、シーケンサー、バリデーターに近づけて配置することが、競争力のあるプロダクトと遅いプロダクトの違いになり得る。

当社は197カ国の顧客にサービスを提供しており、Dedicated Clustersではワークロードが必要とするリージョンにノードプールを配置できる。主要なユーザー地理圏ごとに1つのクラスターを置く場合も、特定のロールアップのシーケンサーと同じ場所に1つ置く場合も同様だ。トレードオフは運用面にある。リージョンが増えるほど、監視、パッチ適用、支払いが必要なクラスターが増える。ほとんどのワークロードには1つか2つで十分だ。

N+1冗長性とフェイルオーバー

dedicatedクラスターは、顧客の目標キャパシティに加えて1台の予備ノードを動かす。いずれかのノードが劣化または再起動した場合、トラフィックは顧客が気づかないうちに予備ノードへ移る。これがN+1パターンであり、単一ノード障害でも可用性を失わずに耐える必要があるあらゆるサービスの標準的な形だ。

より難しい問題は、負荷がクラスターを超えたときに何が起こるかだ。これを引き起こす現実のケースは2つある。1つはチェーンの混雑で、チェーンが混んでいることによりクラスターのリクエスト量が急増するケース。もう1つは、キャンペーン、イベント、あるいはインテグレーションの開始による顧客トラフィックの急増だ。定常状態の負荷に合わせてサイジングされたクラスターは、大きなスパイクの下でレート制限にかかることがある。

これに対するアーキテクチャ上の答えは2つある。1つはクラスターをピークに合わせてサイジングすることで、これはほとんどの時間をアイドルキャパシティに対して支払うことを意味する。もう1つは共有インフラストラクチャへの自動フェイルオーバーだ。クラスターが飽和すると、429を返す代わりに、トラフィックはプロバイダーの共有フリートへ流れる。顧客は同じAPI、同じ認証、同じレスポンス形式を維持できる。フェイルオーバーの方が効率的なパターンだが、これにはdedicatedプロバイダーがファーストクラスの共有インフラストラクチャも運用している必要がある。

ブロック完全な一貫性

ロードバランスされたプール内の異なるノードは、数百ミリ秒の間、最新ブロックについて食い違うことがある。最速のノードはブロックNを見ているが、最も遅いノードはまだN-1にいる、といった具合だ。残高を確認するウォレットにとっては、これは気づかれることもない。しかし、同じブロックを異なるノード経由で2回読み取り、矛盾した状態を取得してしまうトレーディングボットにとっては、実際のバグとなる。

ブロック完全な一貫性とは、クラスターがノードプール全体で一貫したチェーン状態のビューを返すことを意味し、これによりステートフルなクライアントは古い、あるいは矛盾した読み取りを見ることがなくなる。トレードオフは、クラスターが速度だけでなく正確性にも最適化されることであり、これはワークロードが最新のチェーン状態から意思決定を行う場合に最も重要になる。

カスタムトレーサーとバイナリ

dedicatedランタイムであれば、顧客はカスタムJavaScriptトレーサーを動かしたり、パッチ済みのgethビルドを出荷したり、クライアントを入れ替えたり、共有プロバイダーがグローバルに固定しているクライアント設定を変更したりできる。共有プロバイダーはこのサーフェスを公開できない。なぜなら、クライアントのバージョンや設定を変更すると、そのホスト上のすべてのテナントに影響するからだ。

これは、シミュレーション、フォレンジック、分析プロダクトが依拠している能力だ。それらの価値は、標準のトレーサーインターフェースが公開しない実行状態を抽出できることから生まれる。dedicatedランタイムなしには、そのプロダクトは存在し得ない。

キャパシティベースの料金体系

共有インフラストラクチャはリクエスト単位で課金され、通常は呼び出しごとのコンピュートユニットとして計算され、より重いメソッドには倍率がかかる。dedicatedインフラストラクチャはクラスター単位で課金される。つまり、確約されたキャパシティに対する固定の月額料金であり、顧客がそこに対してどれだけのリクエストを送るかには関係しない。

このモデルは、予測可能なピーク負荷を持ち、そうでなければ共有コンピュートユニットを大量に消費してしまうワークロードに適合する。dedicatedクラスターでは、追加リクエストの限界コストは、ワークロードがクラスターの上限に達するまでゼロだ。ワークロード固有のしきい値を超えると、キャパシティベースの料金は、dedicatedが解放する他の能力を考慮に入れる前ですら、リクエスト単位課金よりも安価になり得る。

どのような場合に共有がデフォルトとして正しいか

共有とdedicatedのどちらを選ぶかを決める際に重要な点は3つある。トレードオフについてのより詳しい説明は、Node RPCとDedicated Clustersの選択に関する概要を参照してほしい。

Dedicatedは本質的にRPCスタックを速くするわけではない

背後にあるRPCスタックは同じなので、静かなシステム上での単一リクエストのベンチマークだけでは全体像はわからない。dedicatedがレイテンシーを改善するのは、クラスターがワークロードに近い場所に配置される場合であり、予測可能性を改善するのは、持続的な負荷の下でP99（最も遅い1%のリクエスト）を分離が守っている場合だ。

各プロバイダー間での共有RPCパフォーマンスの現在の公開データについては、AlchemyのRPCプロバイダーベンチマークを参照してほしい。

マルチリージョンの共有は、シングルリージョンのdedicatedより生き残りやすいことがある

単一リージョンのクラスターを停止させる地域的なクラウド障害は、グローバルに分散した共有フリートではほとんど問題にならない。実用的なデプロイメントは、主要リージョンでのdedicatedと、グローバルなデフォルトとしての共有を組み合わせるものだ。

4パターンのテストは厳格だ

ワークロードがカスタムランタイム、リージョン要件、規制上の分離、クエリ範囲の上限のいずれにも該当しない場合、共有の方が安価で、シンプルで、通常はより信頼性が高い。dedicatedへの移行は、通常は好みの問題ではなく、必然的な要請によるものだ。

Alchemyは専用ブロックチェーンインフラストラクチャをどのようにサポートしているか

ほとんどのワークロードは共有から始まり、共有にとどまる。AlchemyのRPC APIとData APIは、dedicatedを支えるのと同じCortexプラットフォーム上で動作しており、無料ティア、契約不要、最低利用料も不要だ。ダッシュボードからAPIキーを取得すれば、数分でリクエストの送信を始められる。

ワークロードが4つのパターンのいずれか、すなわちカスタムトレーサー、リージョン要件、規制上の分離、クエリ範囲の上限のいずれかに該当する場合、Alchemy Dedicated Clustersは同じインフラストラクチャ上でシングルテナントのキャパシティを提供する。カスタムトレーサーとバイナリ、リージョンデプロイメント、共有への自動フェイルオーバーを伴うN+1冗長性、ブロック完全な一貫性、初日からのGrafanaダッシュボード、そして規制環境向けのSOC 2 Type II準拠インフラストラクチャをサポートしている。料金はリクエスト単位の使用量ではなく、プロビジョニングされたキャパシティに基づくため、予測可能な負荷を持つチームは固定の月額インフラストラクチャコストを見込んで計画を立てられる。

dedicatedクラスターは、あなたのワークロードに合わせて限定された、同じインフラストラクチャだ。共有インフラストラクチャで十分なら、共有にとどまればよい。あなたのワークロードが、それでは足りない少数のケースに該当するなら、チームに相談してほしい。

FAQ

専用ブロックチェーンインフラストラクチャと共有RPCの違いは何か

共有RPCは、管理されたフリート全体で多数の顧客を動かす。専用ブロックチェーンインフラストラクチャは、1つのワークロードのためにランタイム、キャパシティ、データパスを確保する。APIサーフェスは同じままにできるが、dedicatedはシングルテナント分離、カスタムランタイムのオプション、リージョン配置、キャパシティベースの料金体系を追加する。

dedicatedのEthereumノードでカスタムトレーサーを実行できるか

できる。dedicatedクラスターはシングルテナントなので、共有エンドポイントではホストできないカスタムトレーサーを実行できる。callTracerやprestateTracerのような標準トレーサーに加えて、dedicatedランタイムでは独自のJavaScriptトレーサーや、標準インターフェースが公開しない実行状態を露出させる改変版のgethまたはerigonバイナリをデプロイできる。セキュリティ、シミュレーション、フォレンジックのチームがdedicatedを運用する理由はここにある。彼らのプロダクトは、共有インフラストラクチャがグローバルに固定しているトレーシングに依存している。

dedicatedインフラストラクチャはプライベートRPCエンドポイントと同じものか

必ずしもそうではない。プライベートRPCエンドポイントは、共有インフラストラクチャ上の顧客固有のURLやアクセスポリシーを意味することがある。dedicatedインフラストラクチャはさらに踏み込んだもので、ノードプールとそれを支えるランタイムが1つの顧客のワークロードのために確保されている。

チームはどのような場合にdedicatedインフラストラクチャを避けるべきか

ワークロードがカスタムバイナリ、規制上の分離、リージョン固有の配置、あるいは異常に大きな生のクエリ範囲を必要としない場合は、dedicatedインフラストラクチャを避けるべきだ。そうしたケースでは、共有RPCの方が通常シンプルで、安価で、柔軟性があり、導入も速い。

dedicatedと共有のインフラストラクチャを併用することはできるか

できる。Dedicated Clustersを利用しているほとんどのチームは、ハイブリッドな構成を運用している。厳格な要件があるチェーンやワークロードにはdedicatedを、それ以外には共有RPCを使う、というものだ。APIは一致しているため、ワークロードを両者の間で移動させることは、主にエンドポイントとルーティングの選択の問題になる。

dedicatedクラスターの料金体系はどうなっているか

dedicatedクラスターは、リクエスト単位の使用量ではなく、プロビジョニングされたキャパシティに基づいて課金される。料金はチェーン、ノードの種類、スループット、リージョン、含まれる機能によって決まる。持続的に高い負荷のワークロードでは、固定キャパシティの料金体系の方がリクエスト単位課金よりも見通しを立てやすい場合がある。

dedicatedクラスターはどのくらいの速さでプロビジョニングできるか

プロビジョニングにかかる時間は、チェーン、クライアント、リージョン、設定によって異なる。要件が標準的なものであれば、迅速にデプロイできるクラスターもある。カスタムバイナリ、特殊なハードウェア、新しいリージョンなど、より複雑な構成にはより多くの計画が必要となる。