120 / 736CMPCT

Compact Blocks

ブロックをコンパクトに届ける仕組み

隣のノードは、新しいブロックに入った取引の多くをすでに知っていることがあります。Compact Blocks は全部を送り直す代わりに組み立て方を伝え、不足分を補います。完成後の検証は同じ厳しさです。

Compact Blocks は、BIP 152 に基づき、同じデータの再送を減らして Bitcoin のブロックを届ける方法です。ブロック自体を小さくしたりルールを緩めたりはしません。受信側は内容全体を復元し、採用前に検証します。

アンナがペーターに新しいブロックを送りたいとします。ブロックは、共有する履歴に追加する取引のまとまりです。しかし、その取引の多くはすでにペーターの手元にあります。全部を送れば同じ情報の繰り返しです。Compact Blocks は代わりにブロックヘッダーと短い目印の一覧を送り、既知の取引を探せるようにします。ヘッダーはブロックの短い部分で、前のブロックへの参照や取引の検査用の指紋など、基本情報を含みます。技術的には、目印は 48 ビット、つまり 6 バイトで、SipHash-2-4 関数の結果を切り詰めて作ります。関数のパラメーターはヘッダーと、この転送用に加えた数値 nonce から導きます。そのため目印は、Bitcoin ネットワーク全体で永久に使う取引名ではありません。 [1] [2] [7]

一覧ですべてを置き換えるわけではありません。アンナは選んだ取引を丸ごと送り、ブロック内の位置も伝えます。通常の例は Coinbase Transaction です。ブロックの最初にあり、採掘報酬を割り当てる取引で、同名の取引所とは無関係です。そのブロックのために作られるので、ペーターの待機中の取引には通常含まれていません。完全な取引と短い目印が、復元の際に補い合います。 [1] [2]

ペーターの Mempool は、ノードが知っているものの、採用したチェーンではまだ承認されていない取引の手元の集合です。利用できる取引について同じ短い目印を計算し、アンナの一覧と照合します。全員が同じ集合を持つとは考えません。また、一つの目印がまれに複数の取引に当てはまるため、一致しただけでは内容の正しさが確定しません。 [1] [2]

空欄や曖昧な位置が残れば、ペーターはその位置を指定して取引を要求します。要求メッセージは getblocktxn、取引を返す応答は blocktxn と呼びます。名前を暗記する必要はありません。大事なのは推測ではなく、実際のデータを取得することです。通信がもう一往復すれば時間がかかり、復元できなければブロック全体をダウンロードできます。 [1] [3]

ペーターは正確な取引を正しい順序で復元し、ヘッダーとの結び付きを確認します。Merkle Tree は取引を検査用の指紋にまとめる構造で、その結び付きの確認に役立ちます。ただし正しく組み立てても、ルールの検査は必要です。Full Node は、資金を使う権限や報酬額などの Bitcoin のルールを、ペーターが自分で検証するためのプログラムです。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。コンパクトな転送でも無効なブロックに例外はありません。 [1] [8]

隣接ノードは sendcmpct で方式を決めます。速い方式では、復元用データを含む cmpctblock メッセージが新しいブロックの通知を兼ねます。送信側は所定の事前検査を終えれば、すべての取引検証が終わる前に転送できます。検証済みチェーンとの接続、計算上の仕事の証拠である Proof of Work、ヘッダーと取引の結び付きなどを確認する必要があります。受信側も、自分の履歴に採用する前にブロックを完全に検証します。 [1] [4]

もう一つの方式では、検証済みブロックの存在を inv または headers で先に知らせます。ペーターは必要ならコンパクトなデータを要求します。別の経路で受け取ったブロックを再び送ってもらわずに済む反面、通信手順が増えます。どちらの方式も全取引の再送よりデータを節約できる可能性があります。違いは送る時点と事前の要求が必要かどうかであり、有効性の基準ではありません。 [1] [7]

異なる二つの取引が同じ短い目印になることがあります。これを衝突と呼びます。同じイニシャルを持つ二人のように、略称だけでは区別できません。ソフトウェアは問題が起きた場所に応じて追加データを要求するか、ブロック全体の取得に切り替えます。衝突は Bitcoin の署名を破ることでも、無効なブロックを有効にすることでもありません。目印の一致だけでなく、実際の内容を検証します。 [1] [2]

コンパクトプロトコルのバージョン 2 は SegWit に対応します。SegWit は署名などの検証用データを witness 部分に分離する変更です。この方式では、そのデータを含まない txid ではなく、含めた識別子 wtxid を使います。完全な取引は BIP 144 に従い、必要な witness データとともに送られます。見かけの転送量を減らすために捨てているわけではありません。また、転送プロトコルのバージョンは、ブロック自体のバージョン番号とは別です。 [1] [6]

アンナとペーターが多くの取引を共通して知っていれば、重複するデータを大幅に減らしてブロックを届けられます。ブロックが突然届く際の家庭回線の負荷にも役立ちます。共通の取引が少なければ追加要求が増え、節約効果は下がります。主な目的は転送データの削減です。速く届く可能性はあっても、待ち時間ゼロや一定のメッセージサイズを保証しません。Bitcoin のブロックサイズ制限を変更するものでもありません。 [5] [7]

理解を深めるには、この項目とあわせて次もお読みください Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, コインベース取引. 次の項目からも参照されています Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.

DOC · 001BIP 152 — Compact Block Relay仕様 DOC · 002Bitcoin Core — BIP 152 implementation文書 DOC · 003Bitcoin Developer Reference — P2P文書 DOC · 004Bitcoin Core v29.0 — net processing文書 DOC · 005Bitcoin Optech — Compact block relay文書 DOC · 006BIP 144 — SegWit peer services仕様 DOC · 007Bitcoin Core — Compact Blocks FAQ文書 DOC · 008Bitcoin Developer Guide — Block Chain文書
改訂日: 一次資料を優先 · 投資助言ではありません