当ブログではSegwitに関する記事をいくつか（解説、発展）書いてきたわけですが、そのSegwitの有効化のためのマイナーの投票がそろそろ始まろうとしています。これまでもビットコインでは、同様の手順を経て何回かソフトフォークが実行されてきましたが、ここまで注目されるのは初めてではないでしょうか。
というわけで、最近ハードフォークの記事を書いたこともあり、「ソフトフォーク」というワードを重点的に見ながらSegwitに関する内容を書いていきたいと思います。
なお、今回のソフトフォークによるSegwit実装に関連してビットコイン開発チームも気合を入れてbitcoincore.orgに関連記事を書いており、今回の内容はその記事の大体のまとめ的なもの＋補足です。最後に参考リンクとして貼っておきます。
Segwitの有効化はいつどのように始まる？
Segwitは95%以上のマイナーの賛成により実装されるかどうかが決定されます。具体的には11月15日以降の最初のdifficulty（採掘難易度）の調整期間中に95%以上のブロックがSegwit支持のマイナーにより採掘された場合に、実装されることになります。
最近ではフルノードのSegwit支持が25%程度になった！なんてニュース記事が出ていたこともありましたが、投票のおいてマイナー以外のフルノードは関係なく、過去のソフトフォークでも半分程度のフルノード支持でも問題なく有効化されています。25%と聞くとかなり少ないように聞こえるかもしれませんが、そもそもフルノードは、単にバージョンアップに気が付かないでそのままSegwit未対応の旧バージョンを利用し続けているというケースも多く、過去の例を見渡してもこの時点の25%というのはまあ普通の数字ではないかと思います。
ビットコインのdifficultyの調整期間は2016ブロック（約2週間）ごとであるため、2016の95%である1916ブロック以上がSegwit支持のマイナーに採掘された場合、ということになります。最初の期間のスタートは日本時間の11月20日頃と推定されており、実際の状況は以下のページより確認できます。
Bitcoin Core :: Segregated Witness Adoption
採用が決定された場合は、さらに2016ブロックおいて実際にSegwitが稼働することになります。逆に95%に達しなかった場合は、次の調整期間の2016ブロックに持ち越し、1年間たっても達しなかった場合は、不採用ということになります。
実際に投票期間が始まってからでないと分かりませんが、一部Segwit不支持のマイニングプールがあるため、すぐ採用されるのは難しいのでは？という見方も多いようです。
Segwitの欠点とリスク
Segwitはいいことづくめでメリットやらはいろんなところで解説されていますが、意外と欠点やリスクについては書かれていません。簡単にその欠点とリスクをまとめておきます。
①トランザクションサイズ、ブロックサイズ
たまに勘違いされることがありますが、Segwitはトランザクションのサイズを小さくするものではなく、より多くのサイズ（現在の1MB制限から理論的には最大4MB、実質的には2MB程度まで）が1ブロックに含められるようになるものです。
むしろ、Segwitによりトランザクションのサイズは増加します。ただし、これは無視できるほど微々たるものなので、1ブロック当たりの実質的なサイズ上限が2倍程度になるという点が主でしょう。
サイズが上昇すれば、それだけコンピュータのリソースを消費するという意味であり、マイナーやノードの集中化のリスクがあります。また、ブロック情報の転送時間もより長くなることになり、マイナー間のタイムラグによるブロックチェーンの分岐（孤立ブロック、orphan blockの生成）が発生する確率がより高くなり、セキュリティが低下する可能性が考えられます。
②ブロックの検証時間の増加
Segwitという新しい要素が追加されることにより、ブロックの検証作業も増加することになります。通常のPCなどでは無視できるレベルなので、今回はほとんど影響がないと思われますが、同様にノードの負担が増え集中化のリスクとなり得ます。
③バグのリスク
バージョンアップの際には新しいバグがつきものであり、今回も当然リスクはゼロではありません。とはいえ全く何もいじらないという訳にはいかないので（中にはビットコインは簡単に新技術を実装できるのが逆に問題だという人もいますが）、なるべく可能性を減らすように努力するしかありません。
ご存知のとおり、Segwitはかなり長い期間テスト・検証が行われているので、重大なバグが発生する可能性は低いと言えるでしょう。
④手数料の低減によるリスク
Segwitのメリットとしてよく紹介されてきた一つに、送金手数料が下がるというものがあります。一見いいことしかないように思えますが、ビットコインネットワークのセキュリティの根幹の役割を果たしているマイナーからみれば、採掘報酬が減ることになり、採掘のインセンティブが減りハッシュレートが低下する可能性もあるので、ネットワーク全体としてはデメリットにもなり得ます。
さらに、最近はSegwitの導入により実装が容易になると言われているLightning NetworkなどのOff chain（ブロックチェーン外）で取引を行う技術の開発が活発ですが、これはより大きいマイナーの報酬減少につながります。
現在はマイナーの報酬全体に対する手数料の割合は小さいので、問題にはならないと考えられますが、数十年後などの長期的な視点で見ると問題となってくるかもしれません。
⑤ソフトフォークによるリスク
Segwitはソフトフォークにより実装される予定です。そのため、ソフトフォーク自体のリスクがあります。今回の本題ということで次にソフトフォークについて説明していきましょう。
ソフトフォークとは何か
ハードフォークの説明はこれまでも何回かしてきましたが、バージョン前後で互換性がない、というわかりやすいものです。しかし、ソフトフォークは前方互換性があるとか後方互換性があるとかわかりにくいものになってしまっています。
ソフトフォークの定義がいくつか考えられる中でわかりやすいのは、（ビットコインの場合）「新バージョンで新ルールを導入し、以前は有効だったブロックが無効になる」というものです。ハードフォークでは逆にルールが削除され、以前は無効だったブロックが有効になります。
例えば、新しく「1トランザクション当たりのサイズ上限を1KBにする」というルールをプロトコル自体に導入するとします。新ルールの導入なのでソフトフォークです。このとき、新バージョンではすべてのトランザクションが1KB以下となります。旧バージョンから新バージョンのトランザクションを見ると、もちろんすべて有効です。そのため互換性があることになります。しかし、逆に新バージョンから旧バージョンを見ると、1KB以上のトランザクションは無効になってしまいます。つまり、旧バージョンのマイナーにより生成された（有効と見なされたトランザクションを含む）ブロックは新バージョンから見ると無効になるのです。
よって、もし旧バージョンのマイナーがブロックを生成すると、一時的にブロックチェーンが分岐することになります。しかし、旧バージョンから見ると新バージョンのブロックも有効であるため、一番長いブロックチェーンを優先するというルールに基づき、旧バージョンのブロック生成速度が新バージョンのブロック生成速度を上回らない限り、新バージョンで生成されたブロックチェーンが最終的には有効となり、ハードフォークのような永続的な分岐にはなりません。
ちなみに、上述したようにルールを削除する際はハードフォークとなります。一度導入した「1トランザクション当たりのサイズ上限を1KBにする」というルールを撤廃するとします。このときは、旧バージョンではすべて1KB以下のトランザクションです。しかし、新バージョンでは1KB以上のトランザクションも生成されるので、そのようなトランザクションを含んだブロックは旧バージョンからは無効と見なされてしまいます。つまり互換性がなく、永続的なブロックチェーンの分岐が発生する可能性があります。
一度Segwitをソフトフォークにより導入した後に、やっぱり実装をとりやめるとなったときは、ハードフォークになるというのはなかなか面白いと言えるでしょう。
Segwitと並んでよく議論されるブロックサイズ上限1MBの引き上げは、1MBという上限ルールを「削除」した後に新たな上限を新設しなければいけないので、ハードフォークが必須といわれています。（Segwitによる今回の実質的なサイズ上限の引き上げは、1MB制限自体が削除されたり変更されるわけではありません。）
ソフトフォークによるリスク
それではソフトフォークを実施する際のリスクを考えていきましょう。
①旧バージョンのウォレットでビットコインが使用できない、同期や表示が正しく行われない
先の例をそのまま使うと、新バージョンで1KB以上のトランザクションが無効とみなされる場合、旧バージョンのウォレットをそのまま使っていると、1KBを超える無効な取引を作成してしまう可能性があります。
ただし、今回のSegwitの場合は、なるべく互換性を保てるかたちでの実装であるため、そのようなことはなく、ウォレットを使用する一般ユーザーは旧バージョンでも問題なく使用できます。新たなSegwitのトランザクションは旧バージョンから見ると全く訳の分からない謎のトランザクションということになるので、新バージョンから送られたビットコインは旧バージョンのウォレットでは無効と見なされて使用できないんじゃないの？と思いがちですが、Segwitのトランザクションは、旧バージョンからは「誰にでも使用できる」ビットコインに見えるように実装されています。つまり旧バージョンのままでも誰でも使用できる＝自分でも使用できるということで、問題なく送金が可能です（新バージョンのマイナーから見ると所有者は決まっているので、実際に誰でも使用できるわけではありません。）。
もちろん、ブロックに取り込まれていない未確認状態のトランザクションは無効とみなされたり正しく表示されない可能性があります。その他これらの新旧ノードでの認識の不整合を悪用して、二重支払い攻撃のリスクも高まりますので、ソフトフォークの実施直後は特に最低1確認をもって支払い完了と見なすことが推奨されています。また、アップデートしなくてもよいとはいってもできるだけ更新するのが良いと思います。
②ブロックチェーンの分岐
最低1確認は必須だけど、もっといえば特にソフトフォーク実施直後は6確認以上待った方がいいというのが、このリスクです。
ビットコインではソフトフォークを行う場合、95%以上のマイナーの同意が必要としています。これは、ブロックチェーンの分岐を防ぐためです。しかし、95%の同意があったとしても5%は旧バージョンのままであり、つまり20ブロックに1ブロック程度はブロックチェーンが分岐する確率があることになります。先に説明したように分岐が永続することはありませんが、運が悪ければ何ブロックかは分岐が続く可能性もあります。。
分岐してしまうと、ちょうど分岐時に送金した取引が無効とみなされる可能性があり、二重支払いのリスクなどがあります。
実際に2015年に同様にソフトフォークによりBIP66という新技術を実装した際には、6ブロック分の一時的なブロックチェーンの分岐が発生してしまいました。このときの直接の原因は「SPVマイニング」と呼ばれるマイニング方法であり、ソフトフォークによる5%の旧バージョンの存在が引き金となったかたちでした。
事件の発端は、5%いる旧マイナーがブロックを生成したところからはじまります。通常なら新マイナーからは無効と見なされて終わりなのですが、このとき「SPVマイニング」を行っていた新マイナーから、旧マイナーのブロックが有効と誤って判定されてしまい、無効なブロックの上に新バージョンのブロックを積み重ねるということが行われてしまったのです。SPVマイニングとは、ブロックの一部だけを検証して無効か有効化を判定し採掘を行う方法です（マイナーは必ずしもフルノードである必要はありません。）。SPVウォレットという言葉をご存知の方も多いと思いますが、そのSPV（簡易検証）と同じ意味です。このときの検証にBIP66が適用されてるかいないかが含まれていなかったために、新バージョンのマイナーであったにもかかわらず古いバージョンブロックが有効と判定されてしまったのです。約半分程度のマイナーがSPVマイニングを行っており、6ブロックという長い分岐となりました。
この例はソフトフォーク固有の問題ではありませんが、様々なかたちで分岐のリスクは高まることになります。
③ルール撤回によるハードフォーク
一度ソフトフォークにより導入されたルールが撤廃されることにより、強制的にハードフォークが行われてしまうリスクです。例えばSegwitのトランザクションは旧バージョンから見ると「誰にでも使える」ので、撤回されてしまえばSegwitを利用したビットコインはすべて盗まれてしまうことになります。その他特に説明はしませんが、大きな混乱となることが簡単に予想できると思います。
しかし、ルールを撤回するには一度有効化された後にマイナーが旧バージョンに再び戻って採掘を行うしかなく、現実問題として可能性はゼロではありませんがかなり低いと考えられます。万が一そのようなマイナーが現れた上にある程度のユーザーも味方した場合、Ethereum Classicのような状況になる可能性も考えられますが、The DAOの件と今回のSegwitではまるで質が違うので、低いと言えるでしょう。また、ハードフォークなので、従来のSegwit有効後のブロックチェーンが消滅するわけではありません。マイナーがただ勝手に切り替えるだけでは、人知れず新しいアルトコインを作るのと一緒で無価値なコインが新しく生まれるだけで、その他の既存ユーザーに影響はないと言えます。
ハードフォークとソフトフォーク
ハードフォークとソフトフォークを比較した際、ソフトフォークのほうが安全であるというのが一般的です。それは、ハードフォークにも上記の①②③のリスクが同じかそれ以上あるためです。ノードがアップグレードしていなくても、ソフトフォークでは重大な問題にはなりませんが、ハードフォークはウォレット利用の一般ユーザーを含めた全ノードのアップデートが必須となり様々な混乱要因となります。
もちろんソフトフォークも気軽に行えるようなものではなく、開発チームも95%の投票という非常に高い支持率を要求することで安全を確保しようとしています。
唯一ハードフォークが優れているのはコードをより柔軟にできるという点でしょう。例えば、Segwitをハードフォークにより実装するとトランザクションのサイズ自体をソフトフォーク実装よりも小さくすることも可能です。コードという点から見た時により安全にできる場合もあるかもしれません。
しばらく前にSegwitはハードフォークで実装すべきかソフトフォークで実装すべきかという議論が巻き起こったことがありましたが、結局ソフトフォークでやるべきという意見が大勢でした。安全を考えると、ソフトフォークでは実装できない、または実装にかなり無理があるという場合に限って、ハードフォークが検討されることになるのだと思います。
