Softfork

提供: tezos-wiki
移動先: 案内検索

「ソフトフォーク」は、以前に有効なブロック/トランザクションのみが無効にされるビットココプロトコルへの変更である。 古いノードは新しいブロックを有効と認識するので、ソフトフォークは下位互換性があります。 大多数の鉱夫が新しいルールを適用するためにアップグレードするとき、それは「鉱山活性化ソフトフォーク」(MASF)と呼ばれます。完全なノードが、鉱夫の支援なしに新しいルールを適用するように調整するとき、それは「ユーザー起動ソフトフォーク」(UASF)と呼ばれます。

新しい取引タイプはソフトフォークとして追加することができ、参加者(送信者と受信者)と鉱夫が新しい取引タイプを理解するだけで済みます。 これは、新しい取引を旧式の顧客に「特別な形の」有料取引として見せ、取引が新しい規則の下で妥当性を確認しない限り、取引を含むブロックを拒否することに鉱夫に同意させることによって行われます。 これはBitcoinに[スクリプトハッシュに支払う]]と分離した証人が追加された方法です。

メカニズム[編集]

有効なブロックのセットが与えられると、それらのブロックのサブセットを取ることができ、そのサブセットももちろん有効です。ソフトフォークは、以前有効だったブロックのサブセットのみが残るようにルールを変更します。ソフトフォークは特定のトランザクションを無効にすることがよくあります。たとえば、ソフトフォークは1KB以上のトランザクションを無効にする可能性があります(これは必ずしも望ましいことではありません)。

一般的にソフトフォークは、例えばPay-to-Script-Hash([[P2SH])のようなソフトフォークのような、より有用なものを実現します。もともとハッシュされた値のプリイメージをスタックにプッシュするだけで、スクリプト OP_HASH160 [20バイトハッシュ値] OP_EQUAL </ code>を利用することができました。今押した値は真であると評価されるスクリプトでなければなりません。 OP_HASH160 [20バイトハッシュ値] OP_EQUAL </ code>のスクリプトを使用する新しいトランザクションは、単にスタックにプッシュされたハッシュのプリイメージを持っていれば有効ではなく、有効なスクリプトでなければなりません。有効なスクリプトであるプリイメージの要件は、有効なトランザクションのセットを縮小し、同時に機能を追加しました。

P2SHの例では、2つのオペコードが再定義され、新しい機能が追加されました。もともと何もしなかった新しいオペコードを追加することもできます。新しいルールは、有効なブロックのセットを古いルールの有効なブロックの適切なサブセットにする必要があるため、この新しいオペコードを追加しても一度無効だったトランザクションは有効でないことを確認する必要があります。 BIP12では<code> OP_EVAL </ code>が提案されました。この新しいオペコードをソフトフォークするには、以前は何の効果もなかったオペコードが置き換えられることが提案されました。このスクリプトは、新しい<code> OP_EVAL </ code>の動作を持つオペコードと、何もしないという古い動作の2回で2回評価されます。何もしないという古い振る舞いで実行されているスクリプトは、トランザクションが古いクライアントに対して有効であることを保証します。

セキュリティ[編集]

ソフトフォークを動作させるには、大部分の採掘権がフォークを認識しているクライアントを実行している必要があります。新しいルールを受け入れる鉱夫が多くなればなるほど、ネットワークはより安全にフォークされます。フォークを認識している鉱夫が3/4ある場合、作成された1/4ブロックは新しいルールに従うことが保証されません。これらの1/4ブロックは、新しいルールを認識していない古いノードには有効ですが、新しいノードでは無視されます。これにより、攻撃者は被害者に支払うトランザクションを作成することができますが、新しいルールに従わないブロックで終了する可能性があります。ブロックを新しいルールと互換性のないものにするか、取引を行うために鉱夫に賄賂を与える可能性がありますそれ自体は互換性がありません。ハッシュレートの3/4はブロックの上にありませんので、ブロックとトランザクションは最終的に "メインチェーン"には含まれず、攻撃者は倍増を試みることができます。

これらの攻撃はクライアントをアップグレードすることで回避できますが、大多数の鉱夫(> 95%)が新しいルールを受け入れる場合、攻撃者が多くの偽の確認を作成する可能性は低いです。鉱夫はお金を稼ぎたいと思うので、ブロックをアップグレードしないと、鉱夫がアップグレードされるインセンティブがあり、鉱山労働者がフォークを100%受け入れなければなりません。

2015 BIP66ブロックチェーンフォーク[編集]

2015年にBIP66ソフトフォークを導入した後、ハッシュ・パワーの95%がブロック・バージョンを3に設定してBIP66を受け入れると述べました。理論上、ブロック・バージョンを3に設定することは、バージョン2ブロックが無効で、有効なフォークで更新されておらず、バージョン3のブロックを作成していなかった5%の一部であるBTCNuggetsは、新しいクライアントすべてに対して無効であった(> = 0.9.5)バージョン2のブロックを作成しましたが、古いクライアントには有効です。当時ネットワークの約40%を占めていたAntminerとF2Poolは、バージョン3のブロックを作成していましたが、検証済みの前のブロックは検証されませんでした。これにより、AntminerとF2Poolの両方がBTCNuggetsバージョン2ブロックの上にマイニングされ、無効なフォークが作成されました。ハッシュパワーの40%以上がこのバージョン2のフォークでマイニングしていましたが、95%は「同意していません」。これにより、F2PoolおよびAntminerプールの所有者に連絡した後に解決された6ブロックのフォークが作成されました。

SPVクライアントまたは古いクライアントは、これらの偽の確認に対して脆弱であり、理論的には6回の確認トランザクションが逆転している可能性があります。幸運なことに、確認された二重銀行取引はゼロであり、失われた唯一の金額は、これらのプールが失った鉱業収益であった。 F2Poolは事前に検証せずにマイニングを継続しており、SPVクライアントと古くなったフルノードのクライアントは、そうする限り、さらに高いリスクにさらされます。

含意[編集]

ソフトフォークは、新しいソフトフォークルールを持つすべてのブロックも古いルールに従うため、コンセンサスを維持するためにノードをアップグレードする必要はありません。そのため、古いクライアントはそれらを受け入れます。 ソフトフォークは、定義によると、有効なブロックのセットが有効なプリフォークであったものの適切なサブセットにしかならないため、ハードフォークなしではソフトフォークを元に戻すことはできません。

ユーザーがポストソフトフォーククライアントにアップグレードして何らかの理由で鉱夫の大半がプレソフトフォーククライアントに切り替わった場合、ポストソフトフォーククライアントユーザーは、ブロックが到着するとすぐにコンセンサスを破棄し、 新しいルール。

関連項目[編集]