T15 · Crypto のバックエンド

現実の問題

「自分の資産」ページの要件は簡単です。保有トークンを一覧にし、残高、現在価格、24 時間の変動を表示します。

20 種類持っていると仮定して数えます。

• 残高照会 20 回
• 小数桁数照会 20 回（トークンによって異なる）
• 名前とシンボル照会 20 回
• 別のデータ源から 20 の価格

ブラウザーから 80 回以上のネットワーク要求が送られます。

初期表示に 6 秒かかり、壊れたと思って更新するとまた 80 回です。3 人が同時に更新すると RPC の割当が 429 を返します。サイトには 3 人しかいないのにです。

さらに考えると、結果はすべてのユーザーで同じです。名前、シンボル、小数桁数は変わらず、価格も共通です。同アドレスの同ブロック高の残高も確定しています。

全員に、世界中で同じ答えをそれぞれ計算し直させています。

バックエンドが必要な理由は、もはや哲学ではありません。チェーンが行わず、フロントエンドではうまく行えず、バックエンドが担うしかない仕事があるからです。

思考実験

RPC を、窓口が一つしかない資料館として考えます。

特徴は次の通りです。

• 読み取り専用で、厳密です。 聞いたことだけ答え、集計や並べ替えをせず、「このアドレスの一か月の純流入」も教えません。
• あなたを覚えません。 毎回最初からで、セッションも文脈もありません。
• 順番待ちがあります。 全体で列を共有し、一人が頻繁に聞くと全員が待ちます。
• 回数ごとの料金です。 聞くほど高くなります。

製品の要件を窓口へ持っていきます。

「20 トークンの残高をドル価値順に」なら、自分で取得して並べます。 「入金したら通知して」なら、繰り返し聞きます。 「3 回押した引き出しは一度だけ」なら、窓口は業務上の一度を知らず、3 取引を実行します。 「一人につき一分で 10 回まで」なら、窓口は人を識別しません。

これが、集約、ポーリングと通知、冪等性、レート制限という 4 つの役割です。同じ問いの答えがしばらく変わらないことから、キャッシュも加わります。

バックエンドはチェーンを置き換えるのではなく、チェーンができない部分を担います。 逆側の境界も重要です。チェーンができること、特に何が真実かの判断を奪ってはいけません。

あなたが決める

資産ページに層を追加します。何から始めますか？

結果を観察する

一つを選ぶのではなく、順に積み重ねる層です。同じ問題の両面を解決します。

ここで境界を設けます。

チェーンが事実の源で、バックエンドは投影と流量制御の層です。

キャッシュ、集約、加工、事前計算はできますが、すべての数値をチェーンの特定の高さへたどれる必要があります。独自の残高を増減してチェーンにない事実を作ると、二つの真実ができ、いずれ分かれます。T16 で表構造に落とし込みます。

モデルを作る

チェーンの両側に、異なる失敗を持つ経路があります。

読み取り：キャッシュの 3 層

キャッシュ自体よりキーの設計が重要です。

第一は最大の無料の恩恵です。80 要求中、名前、シンボル、桁数の照会が 40 回あります。一生変わらない値なので、一度保存すれば十分で、要求が半減します。

第二の技法は、キーにブロック高を含めることです。高さが変わればキーが変わり、自然に問い合わせ直すので、古いデータをその高さの答えとして返しません。ただし高さ更新でヒット率が下がり、最新照会より過去照会向きです。

初版で見落としがちなのが、シングルフライトです。100 要求が同時にミスすると、100 回取得し、キャッシュは役立たず、集中負荷を起こします。同じキーは一要求だけが取得し、残りが結果を共有します。

書き込み：冪等性の 3 段階

重複クリック、ネット再送、キュー再配送、クライアント再試行など、重複要求は例外でなく日常です。チェーンでの重複は実際の損失になります。

3 段階すべてで成立させます。

第 1 層  要求の冪等性：同じキーでは一つのタスクのみ
         一意インデックスと挿入競合時の元結果返却で実装

第 2 層  タスクの冪等性：複数回処理しても副作用は一度のみ
         タスク状態機械と条件付き更新を使い、読み取り後の書き込みを避ける

第 3 層  チェーンの冪等性：一業務操作で収録される取引は最大一つ
         キーを nonce に固定して結び付ける

第三は最も漏れやすく、高くつきます。 バックエンドが一度送っても、再起動した worker が新 nonce で再構築すれば、二つともチェーンへ入り成功します。

逆に、キーを nonce に固定すれば、再構築した取引は同 nonce で置き換わり、チェーンへ入るのは最大一つです。チェーンの規則から得る保険です。

要求の冪等性の表構造です。SQL は安定しているので、具体的に示します。

create table submissions (
  idempotency_key text        primary key,
  request_digest  text        not null,       -- 同じキーで異なる内容を識別する要求本文のハッシュ
  status          text        not null,       -- queued | broadcast | confirmed | failed
  nonce           bigint,                     -- 割当後は固定
  tx_hash         text,
  result          jsonb,
  created_at      timestamptz not null default now(),
  updated_at      timestamptz not null default now()
);

先に照会せず、一文で挿入します。

insert into submissions (idempotency_key, request_digest, status)
values ($1, $2, 'queued')
on conflict (idempotency_key) do nothing
returning idempotency_key;

• 一行返る：新要求なので投入します。
• ゼロ行：重複要求なので元記録を読み、クライアントへ返します。
• request_digest が違う：同じキーを別要求に使っています。競合エラーを返します。多くはクライアントのキー生成バグで、黙って受け入れません。

先に SELECT し、なければ INSERT する方法は誤りです。 同時要求が両方「なし」を読み、同時挿入します。一意インデックスが信頼できるロックです。

レート制限は 2 系統

外向けと内向けは別で、半分しか行わない例が多くあります。

• 下流のユーザー向け：ユーザー、アドレス、IP 単位で悪用を防ぎ、超過時は 429 と再試行時刻を返します。
• 上流の RPC 割当向け：出口にも制限し、急増で一日の割当が消費され、全体停止しないようにします。

上流では捨てず、待ち行列とタイムアウトを使います。トークンを待ち、得られなければ速く終了して旧キャッシュ値を返します。少し古い答えは、エラーページより有用です。

何と呼ぶか

実践

AI Lab

第 1 段階：
チェーンへ取引を送るバックエンド API の冪等方式を設計してください。
- キーの生成者、形式、有効期限
- 保存構造と同時実行の正確性保証
- 重複要求で返すもの
- 同じキーで異なる本文の場合
- 失敗後の再試行と終状態の判定
具体的な表構造と SQL を示してください。

第 2 段階：
worker が送信済み、レシート未取得で異常終了し、再起動したとします。
この記録を読んだ後、何をすべきですか？
取引を再構築して送った場合、チェーンでは何が起きますか？
一業務要求でチェーンへ入る取引を最大一つにするには、どうしますか？

実例

変数を一つ変える

持ち帰る問い

章末チェック