この記事では、コンセンサスフォーク史上の記事から、ゲストライターのジョンソン・ラウ博士が、政策ルールとコンセンサス・フォークの区別について説明しています。なぜなら、提案されたルールがポリシールール（非標準的な振る舞い）によってすでにカバーされている場合、新しいソフトフォークを導入する方が安全である理由を説明しているからです。
ソース：gryb25
ソフトフォークは、新しいBitcoinのコンセンサスルールを修正し導入する主要な方法です。Bitcoinのソフトフォークがどのように設計されているかについて、以下の一連の記事で説明します。
コンセンサスのルールとソフトフォーク
コンセンサス規則は、トランザクションまたはブロックが有効かどうかを決定します。Bitcoinネットワーク上のすべてのユーザーとマイナーは、同じコンセンサスルールに従うことが予想されるため、すべてが単一の元帳に同意します。
ソフトフォークは、大部分のユーザーおよび/または鉱夫がより合理的な合意ルールを採用することを決定し、それ以前の有効なトランザクション/ブロックを無効にするが、その反対ではないイベントである。大部分が新しいルールセットを実施すると、違反しているフォークは、（統計的に）完全な作業証明の観点から、より厳しいフォークに追いつくことはありません。古いルールが設定されている少数派は常に長くて厳しいフォークに従うので、ネットワーク上のすべての人は引き続き1つの元帳に同意します。
政策ルールとコンセンサスルール
コンセンサスルールは取引の正当性を判断する唯一の基準ですが、リレーやマイニングノードは他の取引よりもいくつかの種類の取引を優先します。例えば：
- スパム制御として、非常に低い料金または「砂の出力」（非常に低い価値の出力）を伴う取引は拒否されます。
- 一部の鉱夫はスパムを考慮して、「オンザチェーンカジノ」取引を含むことを拒否しました。
- 未知のバージョンのトランザクションは拒否されます（現在、バージョン1と2のみが「既知」です）。
- エキゾチックなスクリプト（P2PKH、P2SH、v0 segwit、または他のいくつかのケースではない）と未知のNOPxコード（現在のところOP_NOP2とOP_NOP3のみが既知）とのトランザクションは拒否されます。
- 「手数料の交換」と「親の子供払い」も、鉱業者が優先する取引を決定するため、ポリシールールです。
定義上、政策ルールは少なくともコンセンサスルールと同じくらい厳密でなければならない（MUST）。明らかに、鉱山者はブロック内に無効な取引を含める（鉱業報酬の喪失につながる）、またはそれらを中継する（同業者によって禁止される）ことは望んでいない。
ポリシールールはコンセンサスルールよりも厳しいものですが、ポリシールールはトランザクションの有効性を判断しないことに注意することが重要です。有効なブロックにトランザクションが含まれると、すべてのネットワークノードはそれがいくつかのポリシールールに違反してもそれを受け入れます。
政策ルールはローカルであり、コンセンサスルールは普遍的であることに注意することも重要である。これは、異なるネットワークノードが異なるポリシールールを持つ可能性があることを意味しますが、同じコンセンサスルールを実行している限り、同じブロックチェーン元帳には引き続き同意します。
ポリシールールに違反するトランザクションは、「非標準トランザクション」と呼ばれ、「無効トランザクション」と区別されます。
ポリシールールとソフトフォーク
理想的には、すべての鉱夫は、ソフトフォークの起動時または起動前に、より厳密で新しいルールセットにアップグレードする必要があります。財政的に、彼らはこれを行う強いインセンティブを持っています。無効なブロックを採掘すると（新しいルールの点で）、大幅な金銭的損失を招くことになります。しかし、Bitcoinのような分散システムでは、これは保証されません。
鉱夫は提案された規則の変更に注意を払い、タイムリーな行動をとることが期待されますが、無効なブロックチェーンを構築する鉱夫は、通常のユーザーにとって市場の混乱と金銭的損失を招く可能性があります。したがって、適切に計画されたソフトフォークは、これを念頭に置いてリスクを最小限に抑える必要があります。
このトリックは、広く普及している既存のポリシールールでカバーされている場合にのみソフトフォークを作ることです。新しいコンセンサスルールに気付かない方針規則を持つ鉱夫は、デフォルトでそのような取引を含めることを拒否するため、新しいコンセンサス規則の点で無効な取引は絶対に含まない。Bitcoinの歴史の中には、これを説明するものもあります。
作業者は、標識が配置される前に存在していた障害のために使用されていない経路に「道路閉鎖」標識を追加しています。新しいトラフィックルールでは、すでに「非標準」だった動作のみが阻止され、混乱は最小限に抑えられます。
| ケーススタディ | 説明 |
| BIP65：ロック時間検証を確認する | OP_NOP1〜OP_NOP10はもともとBitcoinスクリプト言語では意味を持ちませんでした。それらは1つの操作としてカウントされますが（スクリプトでは201の操作の制限があります）、実際には、トランザクションの検証中にスキップされます。ただし、デフォルトでOP_NOPxを拒否するポリシールールがバージョン0.10以降のBitcoin Coreに含まれています。 BIP65はBitcoin Core 0.12でOP_NOP2をOP_CHECKLOCKTIMEVERIFY（OP_CLTV）として再定義するために導入されたソフトフォークです。OP_CLTVは、スタックの最上位値がトランザクションのnLockTimeフィールドよりも大きいかどうか（さらにいくつかの条件とともに）をチェックします。いずれかの条件が一致すると、そのトランザクションは無効とみなされます。それ以外の場合、OP_CLTVはOP_NOP2のようにスキップされます。
ソフトフォークの起動後、新しいノードは常に新しいコンセンサスルールを適用します。しかし、ソフトフォークがアクティブ化される前であっても、元のOP_NOP2ポリシールールはOP_CLTVルールに置き換えられました（これは、OP_CLTVルールが元のOP_NOP2コンセンサスルールよりも厳しいためです）。 従来のマイニングノードでは、nLockTimeチェックは実行されませんでした。しかし、バージョン0.10以上を実行している限り、デフォルトのOP_NOP2ポリシールールはOP_CLTVとの間でANYトランザクションを有効または無効にすることを防ぎます。結果として、0.10以上のレガシーマイニングノードは、新しいOP_CLTVコンセンサスルールに関して無効ブロックを積極的に生成しません。 |
| BIP68：シーケンス番号を使用した相対ロック時間 | nSequenceは、基本的には使用されていないBitcoinトランザクションのフィールドです。BIP68のアイデアは、相対ロック時間を目的としてnSequenceフィールドを使用することでした。これは、支払いチャネルやLightning Networkなどの高度なトランザクションの非常に重要なビルディングブロックです。 しかし、BitCinの最初のバージョン以降、nSequenceフィールドは無視されており、鉱夫はnSequence値を持つトランザクションを受け入れます。nSequence値を管理するポリシールールはないため、安全なソフトフォークは単にOP_CLTVと同じように実行できませんでした。
トリックはトランザクションバージョンフィールド（nVersion）を使用することでした。バージョン0.7以降、非バージョン1トランザクションはポリシールールによって拒否されます。これを利用するには、トランザクションバージョンが2以上（または正確には0未満）の場合にのみ、nSequenceの新しいルールが適用されるようBIP68が要求します。したがって、従来のマイニングノードでは、デフォルトで非バージョン1トランザクションは含まれないため、BIP68違反ブロックは生成されません。 バージョンが署名によってカバーされているため、攻撃者は取引バージョンを単に変更するだけでBIP68を無効にすることはできませんでした。これは、トランザクションバージョンがコンセンサスルールに関連付けられている唯一のインスタンスでもあります。 |
| BIP141：隔離された目撃者 | 分離監視（segwit）は、特定のスクリプトパターンを再定義してトランザクションの可用性を修正するためのソフトフォークです。BIP141では、パターンは出力スクリプト（またはP2SH redeemscript）で、1つのOP_x（x = 0〜16）で始まり、次に2〜40バイトの標準データプッシュが続きます。 しかし、これはもともと提案されたものではありません。最初のドラフト、証人プログラムパターンは2と41バイトとの間の単一のプッシュました。
エキゾチックなスクリプトを使用するトランザクション（P2PKH、P2SHなどではない）を拒否するポリシーがv0.6以降に実装されています。証人養成プログラムの最初の草案は、実際にはこの点で非標準的だった。 この問題は、P2SHでラップされた証人プログラムにあります。v0.10より前には、ポリシールールによってエキゾチックP2SHスクリプトも拒否されました。このルールはv0.10で大幅に緩和され、元の証人プログラムの設計はカバーされませんでした。 いくつかの代替提案が検討された。
最終版では、BIP62のいわゆる「クリーンスタック」ポリシールールを使用しました。BIP62は現在廃止されているが、その規則は引き続きポリシーとして実施されている。「クリーンスタック」では、スクリプト評価は1つのスタックアイテムで終了する必要があります。しかし、最終的な目撃者プログラムの設計では、2つのアイテムがスタックに残されます。これはコンセンサスで有効ですが、 "クリーンスタック"ポリシーに違反しています。 |
| 失敗例： BIP16 とPay-to-Scriptハッシュ（P2SH） | BIP16は、Bitcoinで最初に計画されたソフトフォークでした。ハッシュ・パワーの55％が準備完了を通知したときにアクティブになりました（現在使用中の80〜95％と比較して）。P2SHが導入される前は、支出出力の形態をチェックする政策ルールはなかった。その結果、かなりの数の鉱夫がソフトフォークの活性化の数ヶ月後に無効なブロック、時には長い鎖を作り続けました。 |
| 失敗例：Litecoinの目撃者を分離 | Bitcoin segwitの実装が完了した後も、Litecoinはsegwitコードの統合を開始しました。しかし、SegwitはBitcoin Core 0.13.1でリリースされましたが、その時点の最後のLitecoinバージョンは0.10.4でした。これは"クリーンスタック"ルールを含んでいませんでした。 Litecoinの開発者は、ブロックバージョンを少なくとも0x20000000にする必要があるsegwitに余分なコンセンサスルールを追加することで問題を解決しようとしました。すべての鉱夫が活性化の直前にアップグレードされたことが判明しました（最後の大規模な鉱夫は数時間前にアップグレードされました）。最後のリリースでは "クリーンスタック"がないためにフォークが作成されませんでした。
大規模な鉱山プールが直前にアップグレードに失敗した場合、エクストラブロック版のルールはほとんど保護を提供しなかったでしょう。これについては、今後の記事で説明します。 |
ポリシー保護は万能薬ではない
この時点で、読者は、上記のポリシー保護の仕掛けは、ソフトフォークのアクティブ化後にアップグレードされていない鉱夫が積極的に最初の無効なブロックを作成することを防ぐだけであることが分かります。しかし、このような無効なブロックが何らかの形で作成された場合、アップグレードされていない鉱夫はそれを受け入れて、そのブロックチェーンを拡張します。これはソフトフォークの起動時に偶発的なチェーン分割の可能性を減らすだけですが、排除する方法ではありません。多数の鉱夫が、同じポリシールールを持たない異なるフルノードの実装を使用している場合、この問題は特に問題になります。
興味ある方は登録してください。
■yobit net
https://yobit.net/en/
●XRPブログ作者に募金
アドレス：rE86FEdaEXsKJ6GVvNJHwKdAq757nuJdom
Source: 仮想通貨情報局