180 / 736BIP157/158

Compact Block Filters

すべてを取得せずに必要なブロックを見つける仕組み

スマートフォンのウォレットは、自分の支払いを見つけるために全ブロックの全取引を取得する必要はありません。Compact Block Filters の小さな要約を端末内で調べ、一致したら実際のブロックを確認します。一致だけでは入金を意味しません。

Compact Block Filters は、ブロックごとに作られる小さなデータフィルターです。ブロックは、ネットワークで共有する履歴に追加される取引のまとまりです。軽量ウォレットが自分の取引を含みそうなブロックを選び、ダウンロードするか判断するために使います。誤った一致も起こる、省データの案内索引と考えられます。検索はウォレット内で行うので、監視対象の一覧をサーバーに送る必要がありません。

アンナが久しぶりにスマートフォンのウォレットを開きました。アプリは前回の接続以降に入金があったか、資金が使われたかを調べます。全取引の代わりに小さなフィルターを取得し、監視するアウトプットの条件と照合します。アウトプットは、金額と次に使うための条件を定める取引の一部です。一致したらブロック全体を要求し、実際の取引を探します。フィルターの一致だけで残高を増やしてはいけません。フィルターは口座明細でも所有の証明でもないからです。検索前には、ブロックを識別する短い情報であるブロックヘッダーと、連結したフィルターヘッダーを同期します。 [1]

従来の BIP 37 方式では、クライアントが監視対象のデータからフィルターを作り、接続先のノードに送っていました。ここでは逆にサーバーがブロックのフィルターを送り、アンナが端末内で検索します。同じブロックとフィルター種別なら、各クライアントが受け取る内容も同じです。探しているスクリプトを各サーバーに直接明かさずに済みます。ただし匿名になるわけではありません。相手は IP アドレス、接続時刻、その後どの完全なブロックを要求したかを観察できます。取得先を分散すれば一つの相手が集める情報は減りますが、すべての関連付けを防げるわけではありません。 [1]

Compact Block Filters は調べるべきブロックを選びます。BIP 152 の Compact Blocks は別の課題を扱い、受信側がすでに知っていることの多い取引を短い識別子で表してブロック転送量を減らします。受信側は、自分の Mempool、つまり未確認取引のローカルな集合から取引を取り出し、不足分を要求します。どちらの仕組みも単独で Bitcoin の全ルールを検査するものではありません。Full Node、フルノードはネットワークのルールに従い、ブロックと取引を独立に検証します。ヘッダーと自分の取引の収録だけを見る軽量ウォレットの確認範囲は限定的です。通信量の節約と完全な検証は別の性質です。 [1] [5]

形式は BIP 158 で定義されています。basic フィルターには、新しいアウトプットの支出条件を記すスクリプト scriptPubKey が入りますが、OP_RETURN で始まるものは除かれます。そのブロックで使われる過去のアウトプットのスクリプトも含まれます。インプットについての例外は coinbase です。これはマイナーへの報酬を分配するブロック最初の取引で、通常の過去のアウトプットを使いません。その新しいアウトプットは、ほかの新しいアウトプットと同じ規則でフィルターに含めます。空の項目も省かれます。ウォレットはアドレスを正しいスクリプトに変換する必要があり、印字されたアドレス文字列の検索では不十分です。取引識別子 txid、署名などの witness データ、任意のメモを探す汎用検索ではありません。 [2] [3]

取得したブロックに、自分と関係する内容が見つからないこともあります。この誤った一致はフィルターを小さくするための通常の代償で、それだけで不具合とはいえません。技術的には項目を数値の指紋に変換して並べ、隣り合う差を Golomb-Rice 符号化で小さく保存します。basic では P=19、M=784931 です。存在しない一項目を調べたときの一致確率は約 1/M で、監視項目が増えれば一致する機会も増えます。ウォレット全体の固定の誤り率ではありません。正しく作ったフィルターは含まれる項目を見落としません。ただし否定結果を信頼するには、フィルター、対象データの種類、検索する内容が正しくなければなりません。 [2]

BIP 157 はフィルターの送受信と、連結したヘッダーを定めます。各ヘッダーは、現在のフィルターの暗号学的な指紋である hash と前のヘッダーを結び付けます。フィルターを変えると、期待されるつながりが崩れます。しかし、この連鎖は Bitcoin のブロックヘッダーには含まれず、マイニングはその内容を直接固定しません。不正な相手は、偽のフィルターと計算上正しい一連の指紋を用意できます。Bitcoin 自体は変えられなくても、孤立したクライアントに情報を隠せます。数学的な連結の確認には、元データが正しいかの確認も必要です。 [1]

BIP 157 は複数の接続先を比較し、少なくとも一つは正直な情報源であることを前提にします。食い違いがあれば、最初に違う箇所を見つけて元データからフィルターを確かめられます。basic の構築には、新しいブロックだけでなく、その取引が使う過去のアウトプットのスクリプトも必要になることがあります。再編成にも対応が必要です。これはネットワークが、累積作業量のより多い有効なブロックの別分岐に切り替わることです。ウォレットはフィルターを新しい分岐につなぎ直し、履歴と残高を更新します。同じ高さ、つまり同じ順番でも、同じブロックとは限りません。 [1] [3]

ウォレットには、入手できるフィルターと、選んだ完全なブロックを得る経路の両方が必要です。ノードがフィルター作成後に古いブロックを削除していれば、別の情報源から取得します。Bitcoin Core の getblockfilter は、対応するインデックスが有効なら指定ブロックのフィルターとヘッダーを返します。そのコマンドが使えることは、ほかのノードへの公開 P2P サービスや全履歴の取得を保証しません。既存ブロックのフィルターは Mempool の未確認取引も知らせません。保留中の支払いを表示するには別の仕組みが必要です。こうした運用面が、軽量ウォレットの実際の使い勝手を左右します。 [1] [4]

理解を深めるには、この項目とあわせて次もお読みください Compact Block Filters, Neutrino, Full Node, Bitcoin のプライバシー, Compact Blocks, Bitcoin. 次の項目からも参照されています Neutrino, Erlay.

DOC · 001BIP 157 — Client Side Block Filtering仕様 DOC · 002BIP 158 — Compact Block Filters for Light Clients仕様 DOC · 003Bitcoin Core — BasicFilterElements一次資料 DOC · 004Bitcoin Core 30.0 — getblockfilter文書 DOC · 005BIP 152 — Compact Block Relay仕様
改訂日: 一次資料を優先 · 投資助言ではありません