シグネットチェーンを検証するフルノードの機能を維持しながら、複数の提案されたソフトフォークを使用してシグネットで実験できますか？
Signetの目標の1つは、提案されたソフトフォークをメインネットでアクティブ化する前にテストすることです。これは、執筆時点（2020年8月）で進行段階にあるTaprootなどの提案されたソフトフォーク（BIPのレビュー、ビットコインコアコードベースでのPRのレビュー、アクティベーションの議論の開始）を意味するだけでなく、潜在的に他の提案されたソフトフォークあまり進んでいない段階で。Taprootが進んだ段階にあるにもかかわらず、BIPの変更についてまだ議論が行われていることも注目に値します（340）。あまり進んでいない提案されたソフトフォークでは、メインネットでアクティブ化されるか、完全に拒否される前に、複数のポイントで変更および更新される可能性があります。
シグネットは、完全なノードがジェネシスからシグネットチェーンを検証する機能を維持しながら、提案されたソフトフォークでこの実験とテストをどのように可能にしますか？
回答
シグネットがこれに対処する可能性が高い方法は、2つのクラスのシグネットフルノードを持つことです。シグネットフルノードの最初のクラスは、安定したシグネットバージョンのままであり、提案されたソフトフォークがメインネットでアクティブ化された後にのみ更新されます。シグネットフルノードの2番目のクラスは、実験的なシグネットバージョンを実行するため、新しい提案されたソフトフォークが追加されるか、既存の提案されたソフトフォークへの変更が追加されるたびに、更新する必要があります。そうしないと、シグネットチェーンから分岐するリスクがあります。これは、通常のハードフォークがあったと仮定して、すぐに更新する必要があるフルノードに似ています。
例として（この説明はAJ Townsの功績です）、フルノードのクラスが3つあると想像してください。
- Taprootをまったく強制しません
- ブロック800から現在のTaprootルールを適用します
- ブロック2400からの将来の新しい一連のTaprootルールを適用します（Rタイブレーカーの変更を想定）
クラス1は、メインネット上のビットコインコアのSegWit以前のバージョンがSegWitの支出を誰でも使えるものとして扱うことができるのと同じ方法で、新しいソフトフォークの制限を無視することによってチェーン全体を検証できます。提案されたソフトフォークがメインネットでアクティブ化されると、これらのシグネットフルノードは、新しい安定した非実験的なシグネットバージョンになる可能性が高いものに安全にアップグレードできます。
ただし、クラス2はブロック800からTaprootルールの適用を開始します。クラス2ノードが更新されない限り、これらのTaprootルールがブロック2400で変更されると、新しいTaprootルールを認識しないため、トランザクションの拒否を開始します。彼らは古いTaprootルールに従ってそれらのトランザクションを評価し、それらはそれらの古いルールに従って有効なTaproot支出ではありません。
したがって、クラス2シグネットのフルノードは、新しい実験的なシグネットバージョンがあるたびにアップグレードする必要があります。明らかにこれは理想的ではありませんが、Signetの全体的な目的が実験とテストであり、実際の価値がないことを考えると、合理的なトレードオフのようです。シグネットをハードフォークすることを恐れて物事をテストできない場合、数千億ドルの回線でメインネットの変更が検討される前に必要なテストベッドとステージンググラウンドを提供していません。