ビットコインの 2MB フォークは、コードを 1 行変更するだけの問題でしょうか?

ビットコインのブロックサイズ制限を 1 メガバイト (1MB) から 2 メガバイト (2MB) に増やすのは、一見簡単に思えるかもしれません。ソースコード内の数字「1」を「2」に変更するだけで完了する、そうですよね?

スムーズなアップグレードを気にしなければ、おそらくそれはそれほど単純なことでしょう。次のコード行を変更するだけです (src/consensus/consensus.h 内)。

 ... MAX_BLOCK_SIZE=1000000

に：

 ... MAX_BLOCK_SIZE=2000000

変更後に Bitcoin Core を再コンパイルして実行すると、動作します。コンピュータはブロックチェーン全体をダウンロードし、ネットワーク上の他のコンピュータと問題なく相互運用できるようになります。

コンピュータがトランザクションをブロックに組み立てている場合（単独でマイニングしている場合、またはマイニング プールのオペレーターである場合）、状況はさらに複雑になります。この記事の残りの部分では、その複雑さについて説明します。これにより、問題についての理解が深まり、コンセンサス レイヤーへの変更が安全であることが保証されるようになります。

Github には、コードを並べて比較できる便利な機能があります。 2MB フォークのコード変更を確認するには、https://github.com/bitcoin/bitcoin/compare/v0.11.2…gavinandresen:two_mb_bump にアクセスしてください。次のような画面が表示されます。

ブロック サイズの増加を実装する「コミット」（コード変更のグループ）は 5 つあります。最初の David Harding のコミットは無視してください。これは Bitcoin Core 0.11.2 の最後のコミットです。

22 個のファイルに変更があり、約 900 行の新しいコードが追加されました。そのうち半分以上 (500 行) は、新しいコードが適切に動作することを確認するための新しいテストでした。

最初のコミットは「2MB のブロック サイズ増加のための最小限のコンセンサス/マイナーの変更」であり、20 行の新しいコードが含まれています。変更点の 1 つは、 MAX_BLOCK_SIZEが 1,000,000 バイトから 2,000,000 バイトに変更されたことです。残りの変更は、マイナーがより大きなブロックを生成しても安全かどうかを確認するために必要です。 80 バイトのブロック ヘッダーのタイムスタンプに基づいて、古いまたは新しい最大ブロック サイズを返す新しい MaxBlockSize() メソッドが定義されています。ブロックの高さや最後の 11 ブロックの平均時間などではなく、タイムスタンプを使用する理由を説明するブログ記事を 1 つ書くこともできますが、今日はやめておきます。

コンセンサスの変更は main.cpp の 2816 行目に記述されており、MAX_BLOCK_SIZE ではなく CheckBlock() メソッドと新しい MaxBlockSize() メソッドを使用して、ブロックが大きすぎるかどうかを判断します。マイナーがより大きなブロックを作成できるように、miner.cpp の CreateNewBlock() 関数と 'getblocktemplate' RPC にも同様の変更が加えられました。

次のコミット（「テスト インフラストラクチャの修正」）では、いくつかの機能が追加され、Bitcoin ソース コードのテストに使用されるコードの脆弱性が修正されました。

コードテストコードには 2 つのレベルがあります。ユニット テストは src/test/ のツリーに配置され、C++ で記述され、非常に低レベルで、コードの各部分が適切に動作することを確認するために使用されます。 qa/rpc-tests/ のツリーには回帰テストもあります。これらは Python で記述されており、RPC (リモート プロシージャ コール) インターフェイスのコマンド ライン実行「-regtest モード」を使用して、すべてが正しく動作していることを確認します。

「マイナーの投票と猶予期間後の 2 メガバイトのフォーク」はこれまでで最大のコミットであり、約 700 行の新しいコードが含まれています。ロールアウト ルールを実装します。つまり、コンピューティング能力の 75% が特別なビット ブロック バージョン番号を持つブロックを生成し、その 28 日後に、より大きなブロックの生成が許可されます。

75%と28天のはかなり恣意的な選択です。私は恣意的な選択が嫌いです。主な理由は、それぞれの選択について異なる意見が出る（「バイクシェディング」とも呼ばれ、細かい点や周辺的な問題にこだわりすぎて主要な問題を無視する）ことと、無益な問題について何日も議論することだからです。これらの数字がなぜ良い選択であると考えるのかについては、別のブログ投稿で説明しました。

マイナーの投票と猶予期間のコードは、Bitcoin XT 用に私が書いた BIP 101 実装から派生したもので、3 つのレベルでテストされています。

block_size_tests.cpp に新しい単体テストがあります。 CheckBlock() 呼び出しをテストし、古いサイズ制限または新しいサイズ制限とまったく同じブロック、または古いブロック サイズ制限または新しいブロック サイズ制限より 1 バイト大きいブロックを作成し、そのタイムスタンプが、より大きなブロックが許可される時間の前か後か (または正確に) に基づいて、ブロックが受け入れられるかどうかをテストします。

新しい回帰テストbigblocks.pyもあります。 4 つの bitcoind のコピーを実行し、開発者のマシン上でテスト専用のブロックチェーンを作成し (–regtest モードでは、ブロックはオンザフライで作成されます)、次にフォーク アクティベーション コードをテストして、マイナーの投票が正しくカウントされ、ブロックチェーンの再構築が適切に処理され、移行期間後により大きなブロックを作成できることを確認しました。これにより、2018 年 1 月の期限までにハッシュレートの 75% が変更を受け入れない場合、コード全体が壊れていると報告されることも保証されます。

私の開発時間のほとんどは、回帰テストとユニットテストの実施に費やされています。その後、回帰テストと単体テストに合格すると、テスト ネットワークでさらにテストが行​​われました。コードを書くのは簡単な部分です。

最後に、ロールアウト コードのこの部分は、8MB ブロックと Bitcoin XT テスト ネットワーク (中国のグレート ファイアウォールを含む) で広範なテストを実行した Jonathan Toomim によって検証されました。

コードの変更点の調査を続けましょう…

main.cpp のIsSuperMajority()関数にもいくつかの変更があり、block.h の新しい VersionKnown() 関数も追加されています。これらは、さまざまな変更をサポートするブロックの数をカウントするために使用される関数です。ブロックサイズが増加すると、BIP 009 およびさまざまなソフトフォーク BIP (68、112、113、141) の「バージョン ビット」と同時に発生する可能性があります。

新しいコード（テスト以外）の最大量はtxdb.cppにあります。マイナーの投票が成功すると、トリガーとなるブロックのハッシュがブロックチェーン インデックスに書き込まれます。これは厳密には必須ではありませんが、コードのこの部分はブロックチェーン内のすべてのブロック ヘッダーをスキャンして、投票が実行されるたびに投票が成功したかどうかを判断します。情報の一部をブロックチェーン インデックス データベースに保存するよりも効率的です。

残念ながら、これらすべての可能性のあるコード変更を記述するには、コードを記述するよりもはるかに時間がかかります。ここで説明するコミットがあと 2 つあります。

「正確な sigop/sighash の計算と制限」は重要です。これがないと、ブロック サイズの制限を増やすと危険になる可能性があるためです。昨年 11 月に開催された DevCore カンファレンスでの私のプレゼンテーションで詳細の一部を確認できますが、基本的に、サトシはトラ​​ンザクションの署名方法について十分に考慮していなかったため、ビットコインは検証コストが高すぎる非常に大きなトランザクションを作成する可能性がありました。このコミットでは、いくつかの技術的負債をクリーンアップし、トランザクションの検証に費やされた作業量を追跡する新しいValidationCostTrackerを実装し、それを新しい制限 (MAX_BLOCK_SIGHASH) と組み合わせて使用​​することで、ネットワークを混乱させようとして検証に非常にコストのかかるブロックを作成できないようにしました。

検証にコストのかかるブロックを作成しないようにする強いインセンティブがあります (マイナーはブロックができるだけ早くネットワークを通過することを望み、孤立ブロック率を最小限に抑えるために懸命に働きます)。ただし、セキュア コーディングの原則の 1 つは「ベルトとサスペンダー」です (プロフェッショナルな印象を与えたい場合やサスペンダーという用語が気に入らない場合は、代わりに「多層防御」という用語を使用してください)。

MAX_BLOCK_SIGHASH 、もう 1 つの厄介な恣意的な制限です。これは1.3 GBに設定されており、現在この制限に達するブロックがないほど十分に大きいですが、検証に数分かかるポイズン ブロックを作成できるほど十分に小さいです。

最後のコミット「過剰な sighash トランザクションを中継またはマイニングしない」は、もう 1 つの「万全の対策」スタイルのセキュリティ対策です。非常に大規模で検証コストのかかるトランザクションを拒否する制限はすでに設定されていますが、このコミットでは別のチェックが追加され、巧妙な攻撃者がマイナーを騙してブロックに非常にコストのかかるトランザクションを入れさせることが絶対にできないようになります。

もしあなたがこれを乗り越えられるなら、あなたは私よりも集中力が持続する人です。この記事を読んでいる非プログラマーの皆さんにとって、この記事から「1」から「2」に進むときに注意すべき点を学んでいただければ幸いです。

元記事: http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
ギャビン・アンドレセン
翻訳者: Satuoxi
出典（翻訳）：バビット情報（http://www.8btc.com/guided-tour-of-the-2mb-fork ‎）