ブロックサイズ戦争

二つの身近な希望を考えてみましょう。アンナは長く待たず、高い手数料も払わずに Bitcoin を送りたいと考えています。パヴェルはブロックと取引を自分で検証するコンピューター、つまりフルノードを動かしています。高価な機器に頼らず自分のお金を確かめたいのです。どちらももっともな希望ですが、各ブロックのデータを増やすと、転送して検証するデータも増えます。このバランスが Block Size War の中心でした。 ブロックとは、ネットワークで共有する支払い履歴に追加される取引のまとまりです。 アンナとパヴェルは説明用の架空の人物です。実際の2015～2017年の議論には、開発者、採掘事業者、取引所、ウォレット提供者、利用者が参加しました。容量だけでなく、安全に変更を導入する方法でも意見が分かれました。Bitcoin には一案を選び、全員に移行を命じる社長はいませんでした。 [1] [11] [13]

SegWit 以前のルールでは、ブロックは 1 MB、つまり 1 000 000 バイトまででした。支払い件数の固定上限ではありません。取引ごとに必要な容量が異なるからです。新しいブロックは平均すると約10分に一度生まれます。需要が容量を超えると、マイナーは通常、手数料率の高い取引を優先し、ほかの取引は待つことになります。 大きなブロックの支持者は、基盤ネットワークに直接容量を追加し、安価な支払いを維持したいと考えました。反対側は通信環境、コンピューター性能、ブロックを素早く伝えるための負担を懸念しました。自分で検証できる人が減れば、外部サービスを信用する人が増えるためです。上限を上げるだけでは生成間隔は短くならず、手数料がずっと低い保証もありません。需要と実際の使用量にも左右されます。 [1] [2] [13]

開発者は新しいプログラムを書けます。マイナーはそれに従ってブロックを作れます。しかし Full Node の運営者は、自分のノードが検証するルールを選びます。計算能力の過半数があっても、変更されていないノードに規則違反のブロックを受け入れさせることはできません。計算能力は有効なチェーンの選択に関わりますが、無効なブロックがそれだけで有効にはなりません。 これは世界規模の投票で各ノードが一票を持つという意味でも、一人が他の人の離脱を禁止できるという意味でもありません。企業は受け入れるもの、マイナーは採掘するもの、利用者は価値を認めるものを選びます。両立しないルールから二つのネットワークが生まれることもあります。業界の合意は変更を後押しできても、全員のプログラムと判断を自動的に書き換えられません。 [11] [12]

提案は BIP、つまり Bitcoin Improvement Proposal（ビットコイン改善提案）として文書化されました。内容を説明し、ほかの人が検討・議論できるようにする文書です。番号が付いただけでネットワークに採用されたことにはなりません。 Gavin Andresen は BIP 101 で上限を 8 MB に引き上げ、その後も予定に沿って増やす案を示しました。およそ2年ごとの倍増と有効化条件を定めた提案です。Mike Hearn と Andresen は、この方向を選べる代替ソフトウェア Bitcoin XT を推進しました。ただしプログラムの公開は、ネットワーク全体のルール変更そのものではありません。 従来の上限を超えるブロックは古いノードに拒否されます。これは許されるブロックの範囲を広げる Hard Fork であり、受け入れる側には異なるルールが必要です。そのため議論は、容量をどれだけ増やすかだけでは済まなくなりました。誰が移行し、どう調整し、大きな集団が反対したらどうするのかが問われたのです。 [1] [18] [13]

Eric Lombrozo、Johnson Lau、Pieter Wuille は BIP 141 で別の方法を説明しました。SegWit は取引データの配置を変え、上限 4 000 000 weight units のブロック重量を導入しました。witness と呼ぶ部分には、資金を使う権限の確認に必要なデータなどが入ります。それらが消えたり検証されなくなったりしたのではなく、重量計算での扱いが変わりました。容量は取引の構成に依存し、通常の4メガバイトのブロックを単純に許可したわけではありません。 重量は、ブロックの上限に対してデータをどう数えるかを表します。基本データの各バイトは 4 単位、追加の witness 関連データの各バイトは 1 単位です。そのため、バイト数が同じ取引でも消費する重量は異なります。処理容量は、利用する取引の種類にも左右されます。 対象となる取引では、署名データを変えて取引識別子を変えることも防げるようになりました。これは Lightning Network の基礎となる支払いチャネルの構築を容易にしました。SegWit は Soft Fork として設計され、新たに有効なブロックも古いルールに収まります。ただし古いノードは新しい制限をすべて検証するわけではありません。Bitcoin Core 0.13.1 に有効化の仕組みが入りましたが、公開だけで SegWit が稼働したわけではありません。 [2] [3]

2017年5月23日、Digital Currency Group は企業とマイナーの New York Agreement を公表しました。SegWit 支持と、6か月以内の 2 MB への Hard Fork を組み合わせる合意です。後者は SegWit2x と呼ばれ、btc1 プロジェクトが実装しました。一部には、双方が求めるものの一部を得られる妥協案と映りました。 一方で、二つ目の変更と進め方の両方に反対する人もいました。企業の支持は全顧客の同意ではありません。Bitcoin Core は後に、btc1 は自らのソフトウェアの必須更新ではなく、SegWit 支持は SegWit2x 支持と同じではないと明言しました。当時の報道を読む際も、一つの合意に含まれた二つの変更は別々のルール変更だったと区別する必要があります。 [6] [7] [11]

Shaolin Fry という仮名の作者は、利用者が有効化する Soft Fork、UASF の一案として BIP 148 を提案しました。Median Time Past を基準に2017年8月1日以降、まだ SegWit が確定または有効になっていなければ、そのルールを実施するノードは SegWit を示さないブロックを拒否するというものです。採掘とブロックの受け入れが分かれれば、ネットワーク分裂の危険がありました。全利用者が一緒に操作する安全なスイッチではありません。 Median Time Past は、直近 11 ブロックのタイムスタンプを並べたときの中央の値です。各利用者の時計の時刻ではありません。ここでのシグナルは、その導入へのマイナーの支持を示すブロックヘッダー内の印であり、印だけで新ルールが有効になるわけではありません。 James Hilliard の BIP 91 は、336ブロック中269ブロック、約80％という低い閾値でのマイナー調整を示しました。稼働後は、既存の SegWit 導入への支持を示さないブロックを参加者が拒否します。7月の調整は8月の期限をめぐる衝突の危険を減らしましたが、SegWit 自体が7月に確定または有効化されたわけではありません。引き続き独自の BIP 9 の仕組みに従っていました。 [4] [5] [9] [19]

Bitcoin Cash は2017年8月1日に分離しました。Bitcoin ABC はその分岐でより大きなブロックを扱い、当時の既定上限は 8 MB でした。分離以降はルールも通貨も別です。以前の履歴を共有していても、その後の支払いを BTC と BCH の間で自由に移せるわけではありません。 Bitcoin Cash は SegWit2x ではなく、Bitcoin ABC は btc1 でもありません。名前を混同すると、8月の分離と後に中断された別計画を取り違えます。別のチェーンで取引が再実行されるのを防ぐ replay protection の扱いも異なりました。利用者にとっては、一方の操作で他方の資金まで意図せず使わないことが重要でした。共通の鍵を、新しいコインを受け取れると称する任意のツールに入力するのも危険です。 [8] [15] [11]

SegWit は2017年8月9日、ブロック 479 808 から LOCKED_IN 状態になりました。判断期間が終わり、新ルールの適用までさらに一期間待つ状態です。実際の有効化は8月24日のブロック 481 824 でした。両者は 2 016 ブロック離れています。7月の BIP 91、8月の確定、有効化はそれぞれ別の出来事です。 残る SegWit2x の二段階目は、高さ 494 784 で予定されていました。11月8日、Mike Belshe ら主催者は中断を発表しました。声明では円滑な移行に必要な合意が得られていないと説明しています。既に有効な SegWit が失われたわけでも、Bitcoin Cash が消えたわけでもありません。企業とマイナーの支持をこの Bitcoin の上限変更につなげる、特定の計画が終わったのです。 [9] [10] [12] [14] [16] [17]

この対立は、Bitcoin を変えることは可能でも、コードを書くこと、企業の署名を集めること、ルールを受け入れてもらうことは別だと示しました。開発者に影響力がない、マイナーが重要でない、将来も必ず同じ結末になると証明したわけではありません。容量、無理なく行える検証、参加者の合意は、更新の名前を変えるだけでは解決できません。 新提案を読むときは、何を変えるのか、どのノードが一致しなくなるのか、どう有効化するのかをまず確かめましょう。そのうえで提案文、公開ソフトウェア、実際に適用されるルールを区別します。当時の BIP やコードは仕組みを、各陣営の声明はその立場を示します。参加者の声明一つで、歴史全体を中立に説明できるわけではありません。 [1] [6] [11] [12]