元のリンク:

元のリンク:

https://bitcoinops.org/en/topics/soft-fork-activation/

ソフトフォークの有効化ビットコインのフルノードが 1 つ以上のコンセンサス ルールを追加し始める瞬間を指します。この移行により、ノード間の調整リスクが生じます。したがって、開発者は問題の可能性を最小限に抑えるために、ソフト フォークのアクティブ化メカニズムを作成および改善するために長年にわたって多大な努力を費やしてきました。

歴史

歴史

副題

[2009] ハードコードされた高さ: コンセンサス層の nLockTime が有効になりました

知られている最も古いソフト フォークは、ビットコイン ソフトウェア バージョン 0.1.6 (2009 年 11 月リリース) に実装され、ブロック高さ 31000 でアクティブになるようにハードコードされており、実際の時刻は 2009 年 11 月 22 日でした。このハードコードされたアクティベーションの高さは、開発作業のほとんどがサトシ ナカモトによって行われたときに、少なくとも 1 つの他の初期のソフト フォークで使用されました。

[2011] ハードコーディングされた時間と手動介入: BIP12OP_EVAL が失敗する

サトシ・ナカモトがビットコインを去った後、ビットコインにマージされた最初のソフトフォークコードはBIP12OP_EVALでした。当初の計画では、変更をサポートするコンピューティング能力が 50% 未満の場合は、ハードコーディングされた時間を使用し、手動介入を使用する予定でした。 BIP12からの引用:

[...] 新しいクライアントとマイナーは、2012 年 2 月 1 日まで OP_EVAL を no-op として解釈します。これに先立って、サポートされているマイナーは、生成するブロックに「OP_EVAL」を書き込むことができます。これは、サポートされているコンピューティング能力の割合を計算するのに便利です。 2012 年 1 月 15 日までにこの変更に対するサポートが 50% を超えない場合、OP_EVAL のサポートが 50% を超えるまでアクティベーションが延期されます (サポートの大部分がこのアップグレードをアクティベートしないことが明らかな場合、アップグレードはキャンセルさせていただきます）。

アクティベーション コードがマージされた後、ロールアウトされる前に OP_EVAL に重大な脆弱性があることが判明したため、手動による介入が必要だった可能性があります。バグは修正されましたが、一部の開発者は、この強力な新しいオペコードには他にも問題があるのではないかと懸念し、ソフト フォークを放棄しました。

[2012 年] ハードコーディング時間と手動介入に関する別の試み: BIP16 P2SH

OP_EVAL を置き換える簡略化された提案がいくつかあります (BIP13/16、17、18、19 などのアイデアを参照)。そして、BIP13/16 Pay to Script Hash (P2SH) は、ほとんどの開発者の支持を獲得しました。 P2SH は、OP_EVAL と同じアクティブ化メカニズムを使用します。当初予定されていた有効化時期は 2012 年 3 月 1 日でしたが、2 月 15 日の請求日までに、最後の 100 ブロックのマイナーの 50% 未満が 3 月までに BIP16 ルールを実装すると表明しました。これにより、3月1日時点でもBIP16を実装していた一部のマイナーが大多数のマイナー（新しいルールを実装しなかった）からのブロックを拒否したため、「かなり長い置換チェーン」（チェーンの分割）が発生した。 2 回目の投票日は数千ブロック後の 3 月 15 日でしたが、今回は十分な支持がありました。そこで開発者は3月30日にビットコイン0.6.0をリリースし、アクティベーション時間を4月1日に設定した。

[2012] ハードコーディングされた時間: BIP30 は txid のコピーを拒否します

P2SH のアクティベーションが完了すると、複数のトランザクションが同じ txid を共有する可能性があることがわかります。このバグは、それ自体では単にバグを悪用しようとするユーザーの資金を破壊するだけですが、ビットコインのマークル ツリー構築における奇妙な動作と組み合わされて、ノード間の合意を破る可能性もあります (CVE-2012-2459 を参照)。 。この脆弱性を修正する最初のソフト フォークは BIP30 で、前のトランザクションに未使用の出力があった場合に、同じ txid を持つ後続のトランザクションを無効としてマークするだけです。この修正は開発チームの間で議論の余地がなかったので、P2SH アクティベーション パラメータを含むビットコイン 0.6.0 でハードコーディングされた時間でアクティベートされました。

[2012] IsSuperMajority (ISM): BIP34 コインベース プレフィックス

BIP30 は txid の重複によって引き起こされる短期的な問題を修正しますが、ビットコイン開発者は、これが一時しのぎの措置であり、新しいトランザクションを受信するたびにソフトウェアが未使用の出力を持つすべてのトランザクションのインデックスを検索する理由がないことを知っています。そこで、txid レプリケーションを実際的な攻撃ベクトルにする弱点を排除することを目的とした 2 番目のソリューションが提案されました。こちらはBIP34です。このアップデートでは、開発者は BIP16 P2SH と同様のマイナー投票方法を使用しましたが、今回は、EIP34 をサポートする準備ができているマイナーはブロックの nVersion 値を増やす必要があります。さらに、開発者はビットコイン コードへの新しいルールの実装を自動化したため、マイナーがアップグレードするのを待っている間にソフト フォークをサポートするソフトウェアをリリースできるようになりました。 BIP34 のこのルールは、IsSUperMajority() という関数で実装されます。当初、これには単一のアクティブ化しきい値が含まれていましたが、そのしきい値に到達すると、BIP34 の新しいコンセンサス ルールが実装され始めました。

75% ルール: 最新 1000 ブロックの 75% がビジョン 2 以上の場合、無効なビジョン 2 ブロックの拒否を開始します。

この機能の開発中に、BIP34 が解決しようとしていた問題を決定的に修正する 2 番目のアクティブ化しきい値を追加することが決定されました。

95% ルール: 最新 1000 ブロックのうち 950 ブロックがビジョン 2 以上の場合、ビジョン 1 ブロックをすべて拒否します

古いバージョンのブロックを拒否するルールに関する既知の問題は、すべてのマイナーがアップグレードしていない限り、1 日にいくつかの無効なブロックが存在する可能性があることです (マイナーの 95% が正確にアクティブ化した場合、各ブロックが無効である確率は 5% になります)。 ISM ルールを適用するようにアップグレードされたノードはこれらのブロックを拒否しますが、古いノードとライト クライアントはルールを認識せず、それらを受け入れます。これにより、ネットワークは、無効なブロックの後に採掘を続行しないマイナーに通常よりも依存するようになります。

[2015] ISM および検証不要マイニング: BIP66 の厳格な DER アクティベーション

2014 年 9 月、Pieter Wuille は、OpenSSL によるさまざまなプラットフォームの DER エンコード署名の処理に矛盾があることを発見しました。これは、たとえば、Linux オペレーティング システムでは検証に合格するが、Windows オペレーティング システムでは失敗するブロックを作成するために悪用される可能性があり、攻撃者はその時点でチェーン分割を作成します。 Wuille と他の数人の開発者は秘密裏にパッチを開発し、すべての署名が同じ形式を使用するようにソフト フォークとしてアクティブ化することに取り組みました。 BIP66 はまさにこの目的のために作成され、ビットコインの OpenSSL への依存を取り除くためのステップとして公表されました (これは 2019 年に最終的に達成された本当の目標です)。 BIP66 はユーザーや開発者から十分な支持を得た後 (セキュリティ ホールの存在すら知らなかった人も多かった)、BIP34 と同じ ISM アクティベーション メカニズムを使用し、ブロックのバージョン番号を v3 に増やし、v2 以下の 95% のしきい値ブロックを要求しました。その後、バージョン番号は拒否されます。

2015 年 7 月 4 日に 75% のしきい値に到達し、ブロック高さ 363725 で 95% のしきい値に到達しました。すべてのノードで Bitcoin Core v0.10.0 以降のソフトウェア (または互換性のある実装) が実行されており、実装により新しいルールが開始されます。ただし、ブロック高さ 363731 では、アップグレードされていないマイナーが現在のバージョン番号を含まないブロックを生成しました。これは、新しい ISM アクティベーション ルールでは有効なブロックではありません。しかし、他のマイナーはこの無効なブロックの後も生成を続け、最終的に 6 つの無効なブロックを持つチェーンを生成しました。これは、アップグレードされていないノードと多くのライト クライアントは、その時点でまだ有効なブロックの確認すら取得していない場合でも、最初の無効なブロック内の 96 個のトランザクションを、6 つのブロック確認が蓄積されたトランザクションとして扱うことを意味します。結局、開発者にはマイニングプールの運営者に連絡してソフトウェアを手動で再起動してアクティブなチェーンに戻す以外に選択肢はありませんでした。このような出来事は翌日も繰り返され、一部の取引では 3 件の無効な確認が残されました。幸いなことに、これら 6 ブロックと 3 ブロックの通常のトランザクションはすべて、後に有効なブロックにパッケージ化されたため、一般のユーザーには損失がありません。

高さ 363731 の元の無効なブロックは、古いバージョン番号を使用しているという理由だけで無効になる、毎日発生すると推定されるブロックの約 5% のうちの 1 つです。次のブロックがアップグレードされていないマイナーによってマイニングされる確率も 5% であるため、連続する 2 つのブロックがバージョン番号がキャンセルされたブロックである確率は 0.25% になります。マイナーの 95% がアップグレードしたことを考えると、6 連続するブロックが無効なバージョン番号を持つブロックである確率は 0.000002% ですが、原因はまだ極端な不運ではありません。考慮されていないのは、マイナーが「検証なしでマイニング」を行う可能性があることです。つまり、マイナーが新しいブロックを受け取った後、検証なしで生産を続けるため、効率が少し向上する可能性があります。検証不要のマイニング ソフトウェアは理論的には無効なブロック バージョン番号を簡単に処理できますが、この機能は当時これら 5 つのブロックをマイニングしたマイナーが使用していたソフトウェアにはまだ実装されていませんでした。最終的に、十分な数のマイナーがプルーフレス マイニング ソフトウェアをアップグレードするか、ノードをアップグレードするようになり、BIP66 のアクティベーションに関連する偶発的なチェーンの分割はなくなりました。

2015 年 7 月のフォークにつながったこれらの問題に対応して、開発者は検証不要のマイニングの必要性を減らす努力を倍増させ、BIP152 圧縮ブロックや FIBER ソフトウェアの中継などの成果をもたらしました。開発者は、より優れたアクティベーション メカニズムについても検討し始めました。これは、後述する BIP9 プロトコルです。

[2015] 最後の ISM: BIP65OP_CHECKLOCKTIMEVERIFY がアクティブ化されました

BIP66 の厳密な DER ソフト フォークの前に、ソフト フォークを使用して新しいオペコード OP_CHECKLOCKTIMEVERIFY (CLTV) をビットコインに追加することが提案されましたが、OpenSSL の脆弱性が修復されたため延期されました。これは、増分バージョン番号を使用する ISM メカニズムの別の弱点を示しています。マイナーが最新の提案 (ビジョン n) のサポートを通知すると、以前のすべての提案 (ビジョン n-1 など) を暗黙的にサポートします。これにより、ISM を使用して複数のアップグレードを同時に調整する機能が制限されます。

ただし、BIP 66 のアクティブ化にいくつかの問題があったにもかかわらず、BIP65 の遅延アクティブ化では ISM が再び使用されました。今回はそれ以上の問題はありませんでした。

[2016] BIP9 バージョンビット: BIP68/112/113 相対ロック時間アクティブ化

BIP9 は、ISM のいくつかの問題を解決するための新しいアクティブ化メカニズムを提案しています。

• マイナーに不必要にペナルティを与える: ISM をアクティブ化するとブロックのバージョン番号が増加し、バージョン番号を増加させないマイナーによって生成されたブロックは、ブロックがソフト フォークの他のルールに違反していない場合でも無効とみなされます。一例として、2015 年 7 月 4 日のチェーン分割では、すべてのトランザクションがソフト フォーク ルールに従いました。これらのマイナーが 500,000 ドルを失った唯一の理由は、アップグレードではブロック ヘッダーに 3 が含まれている必要があり、マイナーが 2 を使用したためです。 。

• 並列化が難しい: ISM では、開発者が必要と判断した場合でも、1 つのフォークが終了するまで待ってから、別のフォークがシグナルの収集を開始する必要があります。

• 失敗は許可されません: ISM は有効期限を設定しません。アクティブ化信号を待っているノード ソフトウェアが解放されると、新しいソフトウェアを実行しているノードはアクティブ化が完了するまで信号を監視します。人々がこのソフトフォークを全く必要としていないと確信する方法はありません。

• 予測できないアクティベーション時間: 正確なアクティベーション時間を事前に知ることはできません。つまり、迅速な対応が必要な緊急事態が発生した場合でも、プロトコル開発者、マーチャントシステム管理者、マイニングプール運営者がアクティベーション直後にそれを使用することが困難であることを意味します。応答の質問。

BIP9 バージョンビットは、これらの問題を解決しようとします。ブロックヘッダー内のビジョンフィールドをビットフィールドとして使用します。このフィールドのデータはシグナリングにのみ使用され、無効なブロックの基礎としては使用されず、並行して設定できます。この測定は 2016 ブロックごとに実行され、幸運にもハッシュ パワーのごく一部が 95% のサポートを回避できる可能性を圧縮します。最後に、95% のシグナリングしきい値に達すると、すべての関係者がアップグレードの準備をするために、アクティベーション前に追加の 2016 ブロック (約 2 週間) の「ロックアップ期間」が設けられます。有効期限が切れる前にアクティブ化のしきい値に達しない場合、ソフト フォークの試行全体が終了し、未使用のコードは後のソフトウェア リリースで削除できます。

このアクティブ化メソッドは、BIP68 コンセンサス強制シーケンス番号、BIP112OP_CHECKSEQUENCEVERIFY、および BIP113 で定義された nLockTime のソフト フォークで初めて使用されました。フォークはすぐにロック フェーズに入り、その後自動的にアクティブ化フェーズに入りました。

[2016-7] BIP9、BIP148、BIP91: BIP141/143 隔離された証人のアクティベーション

Segregated Witness ソフト フォークは、BIP9 アクティベーション パラメーターを使用してリリースされました。少数のマイナーがすぐに支持を表明しましたが、支持率は 95% の基準を大きく下回っていました。一部のビットコイン ユーザーは、マイナーが有用な新機能を不当に遅らせていると感じたため、BIP148 として知られる自主的なアクティベーションが開発されました。 BIP148 の最終形式は、特定の日付以降、segwit をサポートしないすべてのブロックが拒否されることを指定します。

BIP148 を実装するソフトウェアの出現後、ネットワークには 3 種類のノード (アップグレードしないノード、BIP9/141 ノード、BIP148/141 ノード) が存在し、コンセンサス エラーに陥る可能性はさらに高くなります。マイナーが segwit をサポートしておらず、大多数のユーザーがこれらのブロックを有効なものとして扱い続ける場合、BIP148 ユーザーは、他のユーザーが無効とみなすビットコインを受け取る可能性があります。さらに、大多数のユーザーが BIP148 をサポートしているにもかかわらず、マイナーが BIP148 によって無効とみなされるブロックを多数生成し続ける場合、BIP148 を実装していないユーザーは、BIP148 ユーザーが無効とみなすビットコインを受け入れることになります。ユーザーが同じルールに従い、ほ​​とんどのコンピューティング能力が BIP148 ルールをサポートしている場合にのみ、アップグレードは安全です。

リスクを軽減する 1 つの方法は、ユーザーが segwit のアクティベーションを強制するノードにアップグレードするのに十分な時間を与えることです。しかし、BIP148 の目標は既存の BIP9 プロセス (つまり ) をトリガーすることであるため、BIP148 はこれを行うことができません。これにより、マイナーはずっと前に BIP9 のサポートを通知する必要があります。その有効期限。 BIP148 の潜在的に不人気な代替手段として、BIP149 はユーザーにアップグレードのための追加の 1 年を与えることを提案しています。 BIP149 は世論の多くの支持を得ることはありませんでしたが、これは BIP8 を使用する最初の提案であり、その後数年でさらなる議論を引き起こしました。

BIP148 が大きな国民の支持を獲得し始めると、複数のマイナー、取引所、業界関係者が、BIP148 をサポートするノードとのコンセンサスを維持しながら分離監視をアクティブ化する 2 段階の提案への支持を表明しました。最初のステップは BIP91 で書かれており、BIP9 のルールを改良しています。マイナーは BIP9 ビットフィールドを使用して、BIP141/143 Segregated Witness のサポートを通知しないすべてのブロックを拒否するという一時的なルールを適用するかどうかを示すことができます。 BIP9 とは異なり、BIP91 のしきい値は 95% から 80% に引き下げられ、監視およびロック期間の長さは 2016 ブロックから 336 ブロックに短縮されました。

BIP91 がロックされ、アクティブ化されました。その後、BIP141/143がロックされ、アクティブになります。ロックされると、BIP148 の必須サポート措置が期限切れになります。

マイナー、取引所、業界関係者らによるこの提案の第 2 段階ではハードフォークが必要でしたが、多数の個人ユーザーや企業が激しく反対したため、提案の署名者によってハードフォークは撤回されました。

これらの出来事や、ほぼ同時期に起こった他の出来事が、隔離された証人の活性化にどの程度の役割を果たしたかについては、今日に至るまで人々が議論を続けている。

緊急起動

コンセンサスコードで重大なバグが発見され、開発者がアクティベーションプロセスを経ずにパッチをリリースしたことが一度ならずありました。これを行うとコンセンサスが失敗する可能性がありますが、アップグレードされたノードの脆弱性も即座に排除されます。重要なイベントには次のようなものがあります。

• チェーンワークを使用して高さを置き換える (2010 年 7 月): ビットコインは当初、ブロック数が最も多いチェーン (「最長チェーン」) が有効なチェーンであると考えていました。すべてのブロックの難易度が同じである場合、そのような最長のチェーンは、最も多くのプルーフ・オブ・ワークを蓄積したチェーンでもあります。しかし、異なるブロックには異なる困難があるため、チェーンワークのソフトフォークはビットコイン 0.3.3 でリリースされ、最も蓄積されたプルーフ・オブ・ワークを持つチェーンが有効なチェーンとみなされます。

• スクリプトをバイパスするバグを排除する (2010 年 7 月): ビットコインは当初、UTXO を消費するスクリプト (scriptSig) と UTXO を保護するスクリプト (scriptPubKey) を組み合わせて、それらを同時に評価しました。この設計により、ロック メカニズムが評価される前にスクリプトを終了することができ、たとえば、OP_CHECKSIG を実行して署名をチェックする前に成功ステータスで終了できます。このバグは当初、OP_TRUE OP_RETURN を使用する scriptSig が誰のビットコインも使い果たしてしまう可能性があるとして報告されました。このバグは、OP_RETURN が常に失敗するようにし、スクリプト内の他の表示に番号を割り当てることで、Bitcoin 0.3.6 で最初に修正されました。これらの変更はすべてソフト フォークでしたが、同じコードへの変更 (後に特定の制限が削除されました) により、ハード フォーク スタイルの変更も行われました。このような大きな変更があっても、scriptSig が scriptPubKeys の操作を改ざんできるという根本的な問題は依然として存在するため、2 番目のソフト フォークが Bitcoin 0.3.8 に実装され、2 つが独立して実行できるようになりました。

• オーバーフローのバグを修正 (2010 年 8 月): 誰かが 0.5 btc を使うトランザクションを作成し、92,233,720,368.54277039 BTC 相当の 2 つの出力を作成しました。ビットコインでは、出力値が入力値を超えることはできませんが、検出方法は、最大 9,223,372,036,854,776 サトシ (約 9,200 万 btc) を表すことができる 64 ビット整数に出力値を加算することです。これは、トランザクションのコストが合計 -0.1 btc のみであるように見えることを意味します。これにより、個別の負の出力は禁止されますが、合計の負の値は禁止されないという別のルールもバイパスされます。これは、正の値の合計が依然として正であると想定しているためです。これにより、誰かが 1,840 億 btc を作成することができ、このトリックはコストをかけずに繰り返され、無数のビットコインが生成されます。数時間以内に、ビットコイン 0.3.10 は、出力を 2,100 万 btc に制限するソフト フォーク パッチをリリースしました。また、トランザクションが溢れているチェーンを放棄することも必要です。これは意図的なコンセンサスの失敗ですが、ビットコインが依然として意味をなすためには必要です。

• BDB ロック問題の一時的な修正 (2013 年 3 月): 2012 年の初めに、ビットコイン開発者は、UTXO データベース (チェーン状態) に同時に行われた変更が多すぎると、チェーン状態データのデフォルトの容量制限の 1 つが次のようなものになる可能性があることに気づきました。超えた。当時のビットコインブロックは比較的小さかったため、これはブロックチェーンが再編成され、複数のブロックからのトランザクションを同時に処理する必要があるときにのみ観察されました。当時は単純な解決策が実装されていました。つまり、再編成中に一度に 1 つのブロックからのトランザクションのみを処理するというものでした。その後、一部の人々はマイナーにオプションのデフォルトのブロック サイズを 250 KB から増やすよう要求し始めました。 2013 年 3 月 12 日、マイナーは 1,700 を超えるトランザクションを含む約 1 MB のブロック（これまでで最大のビットコイン ブロック）を生成しました。これは多くのノード上のデータベースの容量を超えたため、マイナーは、ブロックが完全に準拠しているにもかかわらず、そのブロックが無効であるとみなしました。ビットコインの明示的なコンセンサスルール。水をさらに濁らせるために、新しいバージョンのビットコインコアがリリースされました。この制限なしで別のデータベースエンジンを使用するため、この大きなブロックを安全に受け取ることができます。そのため、ノードの異なるバージョンではコンセンサスエラーが発生しました。状況を簡単に分析した後、開発者はユーザーに、古いバージョンに一時的にダウングレードし（この大きなブロックを含むバージョンが拒否される）、その後、ブロック サイズの上限を一時的に 500 KB に下げる緊急バージョンに更新することを推奨しています。ソフト フォークは、すべてのユーザーが新しいデータベース エンジンにアップグレードする時間を確保するためのもので、この一時的なダウングレードは数か月後に自動的に期限切れになります。

将来のアクティベーション

Segwit のアクティベーションに関する問題が何ヶ月も続いた後、一部の人々は BIP8 について考え始めました。 BIP8 の支持者は、BIP9 の問題のいくつかを BIP8 で解決できると信じています。

• 強制的なアクティベーションを許可する: BIP8 は BIP148 を一般化したもので、マイナーはアクティベーションを待機している期間中に自発的にサポートのシグナルを送信できますが、マイナーがサポートのシグナルを送らなければならない最後までの期間も設定します。そうしないと、生成されたブロックが無効になる可能性があります。その後、このアクションをトリガーするパラメーター LockinOnTimeout (LOT) が設計されました。LOT=true を使用するノードでは、アクティブ化がタイムアウトになりそうな最後の期間にマイナーがシグナルを送信する必要がありますが、LOT=false を使用するノードではその必要はありません。ただし、十分なブロックが通知された場合には、新しいルールが引き続き適用されます。

• 時間の代わりに高度を使用する: BIP9 は、マイナーがブロックを書き込む時間の平均に基づいて、アクティベーション シグナルの監視を開始および停止します。したがって、マイナーが時間を操作する可能性があり、LOT=true の機能が妨げられるため、BIP8 は時間の代わりにブロックの高さを使用することを提案しています。

BIP8 の柔軟性により、BIP8 はタップルート ソフト フォークの多数のアクティブ化提案の 1 つとなっていますが、批評家は、コミュニティの幅広い支持を得ている提案のアクティブ化をマイナーが拒否できる特定の設定など、その一部の側面も批判しています。別のグループが使用するシグナリングメカニズムを「キャプチャ」し、マイナーが生成されたブロックに実質的な変更を加えることを要求し、開発者にコンセンサスルールに対する権限を与え、コンセンサス失敗のリスクを高めているように見えます。この記事の執筆時点では、taproot のアクティベーション方法についての議論はまだ進行中です。

「確率的ソフトフォーク アクティベーション (スポーク)」、「多段階ソフトフォーク アクティベーション (MSFA)」、「しきい値減少アクティベーション (decthresh)」、「ハードコードされた高さまたは回数を返すアクティベーション」など、他のアイデアも議論されています。 「（フラグ日）」「発動遅延後の信号期間短縮（スピードトライアル）」。

メインコードとドキュメント

• BIP9

• BIP8

オプテックのニュースと Web サイトの関連セクション

(多い、少し)

こちらも参照

• BIP アクティベーションの高度、時間、およびしきい値

• Taproot