【CTO Tech Blog】Bitcoinの長年の課題を解決するコンセンサスクリーンアップ提案（BIP-54）
- CTO Tech blog
Bitcoinに長年存在している複数の脆弱性および弱点に対処するために長年議論されていたコンセンサスクリーンアップの提案が最近BIP-54として最近マージされた↓
コンセンサスクリーンアップ
コンセンサスクリーンアップがソフトフォークで解決しようとしている課題は、以下の4つ
- タイムワープ攻撃への対応
- ブロックの検証時間のワーストケースの短縮
- マークツリーの悪用の防止
- 重複トランザクションの回避
それぞれ、どんな課題でこのソフトフォークによってどう解決しようとしているのか見ていく。
タイムワープ攻撃への対応
タイムワープ攻撃に対しては、以前testnet4の導入にあたって対策が行われた↓
techmedia-think.hatenablog.com
BIP-94では、難易度調整期間の最初のブロックのタイムスタンプが、直前のブロック（前の期間の最後のブロック）のタイムスタンプの600秒（10分）より前に設定してはならないというルールを追加することで、タイムワープ攻撃を防止しようとした。
これはいずれmainnetにも導入する予定とされていたけど、testnet4の展開後、この新しいアルゴリズムを悪用する攻撃手法が新たに発見された（Murch–Zawy脆弱性）。3つの難易度調整期間を1つのサイクルとして攻撃を繰り返すことで、理論的には最終的に秒間6ブロック生成できるまでに難易度を下げることができるというもの。いずれにしてもmainnetで成功させるには非常にハードルが高い。
BIP-54では、↑の理論上の懸念にも対応するため、以下の2つのルールをコンセンサスルールに追加する。
- 難易度調整期間の最初のブロックのタイムスタンプは、直前のブロック（前の期間の最後のブロック）のタイムスタンプの7,200秒（2時間）より前に設定してはならない。
- 難易度調整期間の最後のブロックのタイムスタンプは、難易度調整期間の最初のブロックタイムスタンプ以上でなければならない。
前者は、BIP-94のルールの10分という時間を2時間にするもの。10分だと悪用されるとブロックのタイムスタンプを未来に進めて一部のプールソフトウェアが10分の猶予期間を遵守しないブロックを生成する可能性があるのと、10分→2時間にしてもブロック間隔は2.2秒しか短縮されないという理由からみたい（出典）。
後者は、Murch–Zawy脆弱性に対応するためのもの（このルールにより、↑のOptechの記事のNew time warpの図のブロック15が無効になる）。あくまで理論上の懸念だけど、このチェックを入れるリスクも低いため今回追加されるみたい。
ブロックの検証時間のワーストケースの短縮
ワーストブロックの問題は、Segwit以前の特別に細工されたトランザクションを作成することで、検証に数分から低スペックマシンでは1時間以上かかるようなブロックを作成できるという問題。レガシートランザクションのSIGHASHの計算ロジックの問題や、OP_CODESEPARATORを悪用する↓ことで検証に時間がかかるトランザクションを作成することができる。
techmedia-think.hatenablog.com
これに対し、BIP-54では、トランザクションの検証において、実行される署名演算の数を最大2,500に制限するルールを追加する。この数のカウントは、
- トランザクションのインプットのscriptSigとインプットが参照するscriptPubkey（P2SHのredeem scriptを含む）の
CHECKSIG/CHECKSIGVERIFY演算をそれぞれ1とカウントし、 CHECKMULTISIG/CHECKMULTISIGVERIFYについては、関連付けられた公開鍵の数をカウントする（16個より多ければ20とカウント）。
この制限により、ワーストケースのブロックの検証時間が1/40に短縮されると。
マークツリーの悪用の防止
マークルツリーの悪用というのは、64 byteのトランザクションを作成することで、SPVノードに対するトランザクションの包含証明を偽装したり、ツリーの内部ノードをトランザクションのように偽装したりする攻撃で、以前から問題視されている↓
techmedia-think.hatenablog.com
BIP-54では、（witnessを除いた）シリアライズしたトランザクションのサイズが64 byteとなるトランザクションを無効とするルールを追加することでこの問題に対処する。実際にそんなサイズのトランザクションはanyone can spendなトランザクションだったり資金を焼却するトランザクションで、2019年以降既に非標準トランザクションとして扱われている。
※ ↑のような問題があったので、その後のTaprootのスクリプトツリーやSchnorr署名のハッシュ計算ではタグ付きハッシュ関数が用いられている。
ちなみに、この対応はBIP-53として独立したBIPとしても提案されてるみたい（BIP-54のように複数の対応をまとめるのではなく、あくまで単一の対応として）↓
重複トランザクションの回避
重複トランザクションというのは、TXIDが一致するトランザクションで、そのようなトランザクションが作成されるとそのTXIDで参照されるUTXOが一意に識別できなくなってしまうという問題↓
techmedia-think.hatenablog.com
↑の投稿で書いたように、BIP-30の導入後にBIP-34が導入されたため、Bitcoin Coreではパフォーマンスの観点からBIP-30のチェックをスキップするようになったけど、その後BIP-34では将来ブロック高1,983,702でブロック164,384のコインベーストランザクションとTXIDが重複するコインベーストランザクションを作成できる余地があることが判明した（ただ、現実的に作成するのは難しい）。
BIP-54では、コインベーストランザクションについて、
nLocktimeフィールドにブロック高 - 1の値をセットし、nSequenceフィールドに0xffffffffをセットしてはならない
というルールを強制する（結果、ブロック高164,384のコインベーストランザクションと異なる）ことで、この問題に対処する。
ブログ元記事へのリンク
Chaintopeでブロックチェーンの未来を共に創りませんか？
Chaintopeは、独自のブロックチェーン「Tapyrus」と、開発プラットフォーム「Tapyrus Platform」を活用し、デジタル社会の信頼基盤を構築しています。
私たちは、ブロックチェーン技術の可能性を最大限に引き出し、社会に新しい価値を提供することを目指しています。
募集職種：
ブロックチェーンエンジニア
アプリケーションエンジニア
インフラ・保守エンジニア
プロジェクトマネージャー
フィールドセールス
Chaintopeで働く魅力：
最先端のブロックチェーン技術に触れる機会
リモートワークやフレックスタイム制による柔軟な働き方
専門性の高いチームとの協働
ブロックチェーン技術に情熱を持つあなたのスキルを、私たちのチームで活かしませんか？
詳細は、採用情報をご覧ください。
https://www.chaintope.com/recruit/