経路
新しさで分割
フルノードコミット済みブロックを型付きレコードで配信
キャッシュ直近データ、メモリから
ファイルストア履歴データ、永続化
データサービス両方をひとつのストリームに
ゲートウェイ → REST · WebSocketアクセス、クォータ、ルーティング
分離している理由先頭の追跡は遅延に敏感で規模が小さく、履歴の問い合わせはスループットに敏感で規模が大きいため、大きなバックフィルがひとつ走るだけでライブ経路が止まります。
真実の源ではなく提供レイヤーカーネルは型付きで帰属の付いた出力を出すため、インデクサーは意味を推論せず整形し直すだけです。チェーンとの食い違いは、インデクサーの不具合です。
分離している理由
チェーンの先頭を追いながら履歴の問い合わせにも答える単一のサービスは、そのどちらもうまくこなせません。先頭の追跡は遅延に敏感で規模が小さく、履歴の問い合わせはスループットに敏感で規模が大きいため、大きなバックフィルがひとつ走るだけでライブ経路が止まります。 分離しておけば、新しい利用者に数か月前からのデータをバックフィルしても、先頭を追うマーケットメイカーへの配信は劣化しません。両者は独立にスケールでき、負荷の性質にまったく共通点がない以上、そうでなければ困ります。どこまで頼ってよいか
頼ってよいもの。インデクサーが提供するもののうち、コミット済みブロックから導かれるものすべてです。約定、注文、ポジション、資金調達の支払い、送金、マーケットデータ。これらはチェーンの出力を整形し直したものです。 同じではないもの。まだコミットされていないものです。メモリプールに受け入れられた注文はまだ順序づけられておらず、インデクサーはそれについて何も言えません。インデクサーに現れないことは、拒否されたという意味ではなく、まだコミットされていないという意味です。 検証できるもの。答えの重みが十分に大きい場合(決済上の争い、監査、会計上の突合)は、インデクサーから受け取るのではなく、チェーンに対して直接検証できます。その最も強い形が自分でフルノードを運用することであり、間違いが許されない参加者が取るべき手段です。ノードを運用するを参照してください。同じコミット済み範囲を読めば、どの利用者も同じ答えを得るはずです。そうならない場合、その食い違いは提供経路にあり、報告すべき不具合です。インデクサー越しにチェーンを読むことの本質的な性質ではありません。
次に読む
ステートモデル
インデクサーが何を読んでいるのか、どの表現が正なのかです。
開発者向け
RESTとWebSocketの提供面、SDK、ツールです。
ノードを運用する
自分でチェーンに対して検証する方法と、バリデータセットが閉じている理由です。
プログラムサービス
このストリームを消費して、派生的なアカウント状態を計算する仕組みです。