基礎からの解説、ソフトフォークとは？、Segwitのデプロイをめぐる動き(UASF、Segwit2x)、２Mハードフォークの行く末まで
今週は質問特集に加えまして、UASFとSegwit2xの動きについての続報を解説します。
基礎から時系列に辿って解説しますので、これで、わからなかった方も分かっていただけると思います。
そもそもソフトフォークとは？
まず、そもそものソフトフォークについて、簡単に理解をしましょう。
ビットコインは日々改善されているのはご存知のとおりです。バグが取れたり、新しい機能が追加されたりと。その中でも、大きな改修や、アップデートになる機能が追加されることがあります。
たとえば、過去で見ると、「マルチシグ機能」です。大きなアップデートですよね。
最近でいうと、CHECK LOCKTIME VERIFYとCSVと呼ばれる機能。これはマニアックな機能ですが、有る特定の日やブロックが訪れると有効になるといった時限トランザクションを作ることができる機能です。
とりわけ、マルチシグや、CHECK LOCKTIME VERIFYとCSVというのは、新しいルールの追加になります。これらを「コンセンサスレイヤーの改修」と呼びます。コンセンサスというのは、つまり、ブロックチェーンの根本の部分に関わる改修で、これをミスしてしまうと、チェーンが分岐してしまうことがあるので、慎重にしないといけません。
これらの改修の方法には、ハードフォークとソフトフォークがあります。ハードフォークは、前の仕様と互換性がなく言ってみれば何でも出来てしまう改修です。たとえばイーサリアムのDAO事件後のハードフォークでは、盗まれたコインを、盗みがなかったことにしました。そういう巻き戻しみたいなこともハードフォークをやればできます。コインの発行上限を変えたり、ブロックタイムを変えたり、ハードフォークではどのようなルールでも変えることができます。
一方で、ハードフォークは新コインを作るのと同義です。新コインをつくり、過去のコインは放棄し、全員が新しいコインをつかうという約束をしてはじめてハードフォークによる移行が可能になります。
しかしながら、旧コインを使い続ける人が居ると、２つのコインにわかれてしまいます。
ユーザー全員にとってメリットしか無いハードフォークならば旧コインをつかいつづける理由がないので、成功します。モネロなどは頻繁にハードフォークを繰り返してアップデートしています。
しかし、イーサリアムのように、DAOの救済に反対する人がいる状態でのハードフォークといった、意見が割れているハードフォークは、確実に２つのコインへの分岐を意味します。
ですので、ハードフォークが危険か危険でないかは、そのアップデートをめぐってのコミュニティの意見によるところが大きいと思います。
ソフトフォーク
ソフトフォークは、互換性をたもったままアップデートする方法です。下の図をみてください。
この図で、緑の部分がソフトフォーク前のルール、赤い部分がソフトフォーク後のルールです。たとえば、マルチシグの導入ということであれば、緑の部分はマルチシグが使えないルール、赤い部分はマルチシグのトランザクションが作れるようにしたルールです。
これは、ルールの追加または厳格化になっています。マルチシグのトランザクションを許すというのは、旧来のルールから見ると条件がより増えたことになります。いままでは、普通のトランザクションだけチェックすればよかったのに、マルチシグの仕様に関しても追加でチェックをして、それを処理しないといけないからです。
このように、ルールを追加、厳格化する方向でのアップデートを、ソフトフォークといいます。
新旧ルールが混在してはいけないため、ソフトフォークでは、新ルールに対応するノードやマイナーが大多数に達してからでないと、新しいルールを使うということはしません。なので、マイナーの９５％とかそういう高いハードルをもうけていて全員がアップデートしたら、新ルールがつかえるようにするということにしています。そうでないと、ブロックチェーンが分岐してしまうわけです（まさにハッシュレートが少ない場合のUASFで起こることです）
ソフトフォークのデプロイメント方法？
では、このソフトフォークは、どのようにして適用するのがよいのでしょうか？適用をデプロイといいます。アクティベートもほぼ同義語です。
あるソフトフォークをデプロイするとき（ある新機能をアクティベートさせるとき）、の方法には代表的に２つあります。
フラッグデイ方式
ひとつは、フラッグデイ・デプロイというもの。これは、期日を決めて、この日から新ルールを適用しますから、その日までに皆さん準備してくださいというものです。法律の施行に似ていますね。日付がきまっていて、その時までにやらなくてはいけません。
普通はこの方法でも大丈夫なので、ずっとこの方法が取られていました。が、問題は、アップデートをし忘れるひとがいて、フォークが起きてしまうこともあるのです。
BIP66「署名の厳格化」という仕様で事件がおきました。これは、ビットコインでつかっているECDSAという電子署名の安全性を強化するために、署名の条件をより厳格化するという改修でした。これは有る特定の日を境に適用されたのですが、このアップデートを知らなかったのか、するのを忘れていたマイナーがかなり多くいて、旧ルールのブロックを掘り続けました。その結果、６ブロックにわたりフォークが発生してしまったのです。
結局、そのマイナーがソフトをアップデートしたので解消されましたが、この分岐チェーンは消えてなくなり、そこで発生したトランザクションとコインはなくなってしまいました。
(追記)BIP66のデプロイはフラッグデイでないという指摘がありました。確かに確認したところ、BIP66は現行のBIP9シグナリングとほぼ同様にブロックヘッダのバージョンを用いた仕組みでデプロイされました（ただしこの方式はあるソフトフォークのデプロイが完了しないと次のデプロイができませんでした。そのためBIP9ではこの点が改良され、並行して29個のソフトフォークを同時デプロイできるようになっています）
最後にフラッグデイが使われたのは、マルチシグの導入(P2SH)のデプロイ時のようです。
シグナリング方式
この教訓から、考えだされたのが、BIP9という新デプロイ方法です。
日付を決めてのデプロイではなく、ユーザーのアップデートが広く行われたのを確認した後にデプロイしようというもので、より「安全側」に振った方法です。
具体的には、例のシグナリングというやつです。マイナーは、自信が作成するブロックにシグナルというものを含めることができます。普通は恣意的にシグナルを入れるのではなく、新バージョンのソフトに変更することで、シグナルを含めるようになります。
ネットワークはシグナルをカウントし、全体のXX％がアップデートを済ませたら、もう安全だろうと判断し、ロックインおこなって、その２週間後に実際にルールが使えるようになる（アクティベート）というようにします。
要するに、アップデートの準備を先にしておいて、それをモニターする機能をとおして準備OKが確認できた時点で、実際に使えるようにするというもの。これは非常に安全なやり方です。
こうした仕組みがBIP9というもので、最近導入されたものです。
しきい値には95%が選ばれました。95％という数字は、めちゃくちゃ安全側に振った結果です。95%のハッシュレートがアップデートを済ませていれば、チェーンが分岐する可能性は極めて少ないからです。
理論的にはこの数字は95%でなくてもよく、51％以上であれば、いずれチェーンは統一されるのですが、一時的に分岐する可能性は否めません。ですので、チェーン分岐を防ぐための安全策として95%という数字が選ばれました。
また、BIP9では、並行デプロイという機能があります。いままではソフトフォークをデプロイするにはあるソフトフォークのデプロイが完了してからでないと次のソフトフォークがデプロイできないという制約がありました。ようするにアップデートは順番にひとつづつ、ということだったんですが、BIP9のシグナリングの仕組みは、複数の異なるソフトフォークを同時並行でデプロイが可能になりました。
BIP9では、シグナルが1〜29番まであって、それぞれ別々のソフトフォークに対応させることができます。これにより２９種類のソフトフォークを同時に行うことができるようになりました。
CSVのソフトフォークは、BIP9を用いて行われ、それぞれ95%のアップデートが終わった時点で無事にアクティベートされました。
BIP9による方法は、非常に安全です。ですので、Segwitも同じ方式で、デプロイされました。Segwitも、過去のBIP9によるデプロイと同様にに、バージョンビッツに1番が選ばれ、95%のしきい値で、デプロイされるということになりました。
ここまでが背景として知っておくべき知識になります。
ここまでをまとめると、
- Segwitは、ソフトフォークである
- このデプロイには、BIP9を使うことになった
- パラメータとして、バージョンビッツ１、９５％しきい値が選ばれた
ということです。
なお、Segwitの仕様は、技術敵にはBIP141という番号で呼ばれています。
BIP141=Segwitと覚えてください。ですので、上記のまとめを、技術的に言うと、「BIP141を、BIP9のバージョンビッツ１、９５％でデプロイする」といった表現がつかわれます。このような技術用語もいままでの解説で理解できるようになったはずです。
マイナー投票という誤解
しかしながら、Segiwitのデプロイは前２つのソフトフォークと違いました。つまり反対するマイナーが多数だったわけです。
本来ネットワークの準備状況をモニターするための仕組みを、マイナーは自分たちの意思を表明する投票手段として、利用し始めました。つまり、バージョンビッツのシグナルを、投票だとして政治的な意見の表明につかったのです。
開発者としては、そういう使われ方は想定しておらず、単に、準備状況のモニターのためにもうけた仕組みですから、困惑したわけです。
これにより、プロトコルの仕様をきめるのは、開発者なのかマイナーなのかといった議論も起こるようになりました。
結局、Segiwitのバージョンビッツ１を準備したマイナーは２０〜３０％程度にとどまり、ネットワークの準備が整う状況には程遠い状況が続きました。
一方で、ユーザーとしては、Segiwitのデプロイを望む声が増えていて、マイナーとの対立がつづきました。
UASF(BIP-148）、BIP149、BIP91
SegwitのBIP9によるデプロイが絶望的になったので、人々はどうしたら良いのかを考えはじめました。
ぱっと思いつく方法は、もう一回デプロイを設定しなおせばいいんじゃないの？というもの。BIP9は複数並行デプロイできるんだから、たとえば、バージョンビッツを2にして、80%なりにしきい値を下げて、もう一回やればいいのでは？という話です。
しかし、これは技術的には難しいのです。同じ機能のソフトフォークを、別のバージョンビッツを用いて行うことは非常にややこしく、出来ないことは無いものの、ソフトウェアに同じ機能を重複して２つ独立して差し込んで、さらに競合を防止するなど、とても開発がややこしいものになるとのことです。
ですので、しきい値を下げるには、現行の方式が期限切れになる11月15日を待ってから、その後に、改めてしきい値を下げてデプロイを行うという方法しかかんがえられません。
（Segwit2xの合意では技術者によるものではなかったので最初これを理解できておらず、virsion bits 2で、80%の並行デプロイをするという合意をしていました。しかしながら、これは不可能なため、後で解説するBIP91を採用することになりました）
また、BIP9は、シグナリングが投票につかわれるという欠陥が露呈しました。今後のデプロイには、BIP9の方式が採用されることは無いでしょう。改良版として考えられているのが、BIP8で、これは、フラッグデイ方式と、シグナリング方式を組み合わせたものです。
基本はフラッグデイ方式で最終的な期日を設けるものの、それ以前にシグナリング方式でネットワークの準備が整えば早期にアクティベートも可能というものです。良い所どりしたものですね。
BIP8を用いた、再デプロイ提案には、「Segwitの再デプロイ(BIP149)」があります。これは11月の現行期限切れ後、、フラッグデイトを2018年６月に再設定して再デプロイするものです。（それ以前にアクティベートするなら、シグナル80%でアクティベートもできる）
いずれにしても、11月を待つ必要があるのは長いです。さらに、再デプロイの提案でも、期日が来年６月となると、もっと早くなんとかならないのか・・・と思います。
２階建てデプロイ
なんとか早くできないものか？しかし、普通のやり方では、現行のBIP9によるデプロイ方式自体は変更できないのです。BIP9で一旦デプロイを開始した以上、１１月のBIP９の期限切れを待つしかありません。
しかし、これに対して、裏ワザ的な考えを編み出されました。それがBIP148と、BIP91です。
BIP９で、バージョンビッツ１、９５％という条件を変えられないとするならば、じゃあ、全員がバージョンビッツ１をシグナリングするほかないという状況に持っていけばいいんじゃないか。ということです。
具体的には、バージョンビッツ１をシグナルしないブロックは不正としてNGにする、というソフトフォークをかまします。このソフトフォークが有効になれば、全員がバージョンビッツ１をシグナルせざる得ない。その結果、当初のBIP9によるデプロイが成功するというものです。
このように２階建てのデプロイを考え出しました。
１階部分：BIP9のシグナルバージョンビッツ１の強制
２階部分：BIP9によるSegwitデプロイ
ということになります。
２つの提案、BIP148とBIP91
「バージョンビッツ１をシグナルしないブロックは不正としてNGにする」という仕様には、２つの提案があります。BIP148と、BIP91です。
「バージョンビッツ１をシグナルしないブロックは不正としてNGにする」というルール自体が（「ビッツ１ルール」と呼びましょう）追加ルールですから、これ自体がソフトフォークになります。つまり、ビッツ１ルールのデプロイにも２つの方式が有るということになります。フラッグデイによるものと、マイナーシグナリングによるものです。
（２方式の違い）
BIP148は、UASFとよばれ、Shaolinfly氏が提案しました。
これは、8.1を期限にしたフラッグデイトにて、ビッツ１ルールを適用するものです。もうシグナリング方式は勘弁なので、8.1にフラッグデイトでやりましょうというものです。
BIP91は、ビッツ１ルールの適用自体を、さらにBIP9を用いたシグナリング方式を使うというものです。８０％のしきい値で、バージョンビッツ４番をつかってこれをシグナルするという提案です。
この２つですが、もしアクティベートされた場合、どちらの方式でも、同じく「ビッツ１ルール」がアクティベートされることになります。ゴールは一緒です。
ビッツ１ルールがアクティベートされれば、それにより、現行方式のBIP9による95%しきい値が達成され、最終的にSegwitがアクティベートされます。
整理：プロトコル仕様、デプロイ形式、開発体制
さて、BIPやらSegwit2xやらと用語が錯綜していて、なにがどれをさすのかわかりにくいですね。
問題は、仕様と、デプロイ形式と、開発体制がごっちゃになっていることでしょう。
ここまでのレポートの内容を整理すると、こうなります。
まず、Segwitはプロトコル仕様の名前で、BIP141という番号で呼ばれます。
BIP141のデプロイの方法していくつか論じられています。既に始まっているのがBIP9による現行デプロイ形式。さらに、現行方式を加速させるための２階建て方式として、BIP148、BIP91があります。
これとは別に、開発体制（ソフトウェア名）としてのビットコインコア、Segwit2xがあります。もう影がうすくなりましたが、Bitcoin Unlimitedも開発体制の名前です。
どの開発体制・ソフトが、どの仕様やデプロイ方式を採用するかというのはまた別の話です。
下記に、それぞれの開発体制がどのような仕様・デプロイ方式に賛成しているのかの下記に示します。
それぞれに支持する方法が違う。図にしたほうがわかりやすいので図にする。
Bitcoin Coreは、あくまでオリジナルのBIP141(Segwit)を現行方式でデプロイ実現を考えています。Coreの開発者は、BIP148によるUASFを支持している人も多いです。ただし、個人的な支持にとどまり、CoreのソフトウェアにBIP148が取り込まれているわけではありません。同様に、Coreの開発者はBIP91に対しても、リーズナブルであると容認です。
Segwit2xチームは、BIP141の現行方式でのデプロイにはなぜか強硬に反対しています。わざわざ二階建てにせずとも、これらのマイナーの95%がシグナルを出せば良いのですが、そうはせずにBIP91ならば賛成ということになっています。（これは8.1のUASFに対抗して、あくまで自分たちでSegwitをアクティベートさせたんだ、ユーザーに強制されたのではない、という言い訳づくりをしているようにも見えて、なんだかなあと思うところもあります）
なおBitcoinUnlimitedは、Segwitの導入自体に反対です。
Segwit2x
Segwit2xは、Segwitのアクティベートと、２Mハードフォークをバンドルして目指すという動きです。NYのコンセンサス2017の会議の期間中に合意したことから、NY合意（NYA）と呼ぶことが有ります。NYAにより発動したプロジェクトがSegwit2xであり、新ソフトウェアの名前だと解釈してください。
- NYAーSegwit2xーJeff Gazikらによる別の開発チームーSegwit2xというソフト
です。
Segwit2xは、プロジェクトの名称であり、BIPうんたらという仕様の名前ではないです。ですので、Segwit2xチームが、どのような仕様を採用するかは彼らの開発方針によります（究極の話をいえばBitcoin Unlimitedを採用というのだってありえるわけです）
Segwit2xの開発経緯について簡単にメモします。
まず、Segwit2xチームは、当初の合意では別のバーションビッツを用いて８０％のしきい値にて、Segwitを再デプロイするということを謳っていました。また、８０％の時点で、その３ヶ月後の２Mハードフォークもロックインするといったような仕様を謳っていました。
しかしながら、これはどうもアジェンダ有りきで合意しただけで、技術的には不可能な合意をしていたようです。
開発のGithubなどでもこの点については指摘や議論がなされて、結局のところ、最終的には、前述のBIP91が採用されソフトウェアにマージされました。
Segwit2xチームとしては、Coreが開発したSegwitとは別の修正バージョンを作ってそれをデプロイするみたいな案もあったんですが、それはなくなりました。
BIP91を使いますので、Segwit2xで実現するのは、オリジナルのSegwit(BIP141)です。
今後は、Segwit2xのソフトウェアを採用したマイナーが８０％以上になり、BIP91のアクティベートにむけた、バージョンビッツ４がシグナリングされるというのが最初の動きになります。
Segwit2xの工程表と、Segwitアクティベート時期
Segwit2xチームの工程表を元に、アクティベートまでの時系列を追っていきましょう。（Jimmy Song 氏のブログの工程表を参考）
7.14
Segwit2xのソフトウェアがリリース。マイナーは随時これを採用し、シグナリングをする準備をすること。
7.21
マイナーは、この日以降BIP91のために、bits 4をシグナル開始することになっている
7.23ごろ
BIP91は、80%のしきい値で３日経つとロックインされるというスピード仕様です。最速で、7.23にロックインされます。
7.26ごろ
BIP91がアクティベートされます。これにより、マイナーは、Segwitのアクティベートにむけて、version bits 1をシグナルし始めます。
7.26-27ごろSegwitのアクティベーションを測る新しい統計期間（難易度調整期間と同一）がスタートするのがこのころです。ここから２週間（2016ブロック）を区切って、95%のマイナーの対応を待ちます。
(8.1) UASF
UASFの当日ですが、この日までにBIP91がアクティベートされているので、UASFと同じ効果がすでに発動されています。UASFを行う必要性がなくなっています。
8.10ごろ
Segwitの統計期間が終わります。この日までに95%に達していれば、Segwitがロックインされます。ロックイン後、2016ブロック後（２週間）にアクティベートされます
8.23ごろ
Segwitがアクティベートされます。
11.18ごろ
Segwitのアクティベートから約３ヶ月後に、2Mハードフォークが予定されています
この工程表をみるに、8.1までにBIP91を発動させるには、かなりギリギリのスケジュールだということがわかります。特に、ソフトウェアのリリースが間に合うのか、また、それがマイナーにすぐに採用されてスムーズに進むのかといったあたりが肝になるでしょう。
（マイナーは、Segwit2xのソフトを実際には走らせないで、Coreクライアントを走らせたまま、bits 4だけをシグナルするという方法もありますが・・・。こうなるとホントの政治パフォーマンスにしか見えなくなってしまいますけれども）
Segwit2xのハードフォークパートについて
Segwit2xがBIP9を採用した時点で、Segwitのアクティベートは確実になりました。
問題は、次の２Mハードフォークのパートです。これは、Segwitとは別の工程をふまないといけません。
そもそもマイナーは、No Segwit without 2M（２Mハードフォークがなければ、Segwitもない）といっていますので、２Mハードフォークの実現にむけての動きが加速していくものと考えられます。
２Mハードフォークの形式ですが、どのような形式でおこなわれるのかはNYAの時点では明らかではありませんでした。（一説によると、Bitcoin Unlimitedが使われることになるのではという憶測もありました）
Jimmy Song氏によれば、Segwit2xの開発レポジトリをみると、２Mハードフォークの仕様がほぼ固まったと指摘しています。
この仕様というのは、
- BIP102の改造版
だとのことです。
BIP102とはなにか？どういう仕様なのか？ということを簡単に解説します。
特徴をかいつまんで言うと、
- Jeff Garzik氏による最も古い２Mフォーク提案
- 一回だけ単純に２Mに拡張する
- フラッグデイトによるアクティベート
- フラッグデイトは、Segwitアクティベートの日から３ヶ月後に自動セット
という感じです。
以上で、説明はほぼ終わりなのですが、補足の説明をします。
これが、オリジナルのBIP102です。
元コア開発者のJeff Garzik氏が、2015年に提案した２Mフォーク案です。これは実際にコードがかかれ、プルリクエストもされましたが、結局のところ採用されず、これをめぐって、現行のCoreチームと、Jeff Garzik氏の距離が離れていくことになりました。
BIP102の仕様ですが、
“Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB.”
とあります。つまり、ワンタイムの２Mへの拡張であるとのこと。Bitcoin Unlimitedのようにブロックサイズを可変したり、さらに４Mへのフォークを準備すると言ったことではなく、今回限りの２Mへの拡張というシンプルなソリューションです。
フォークの日ですが、Segwitがアクティベートされた日を基準点にして、そこから３ヶ月後の特定のブロックに値をセットして、そこからフォークをするという仕様になっています。つまり、フラッグデイトによるフォークということになります。先ほの工程表どおりに進めば、11/18前後がハードフォークの日になりそうです。
ハードフォークの仕様はいろいろあるとおもうのですが、考えられる限りもっともシンプルな案であることは間違いないでしょう。
ハードフォークは実現するのか？
さて、このハードフォークは実現するのでしょうか？
考えられる前提をまず書きます。
まず７月１４日にリリースされるSegwit2xのソフトウェアには、ハードフォーク部分のコードが含まれていることは間違いないでしょう。つまり、Segwitアクティベート後３ヶ月後のフォークを含んだコードです。
これをマイナーの８０％が採用したとすると、およそ１１月１８日に、マイナーの８０％をもって２Mハードフォークがおこなわれるのだ、という「宣言」であると読み取ることができます。
さて、だからといって、これは本当に行われるのでしょうか？
まだ未知数な部分が有ると思います。
いくつかフォークに対する疑念点として、論点にあがりそうなものを指摘します。
- 安全にフォーク出来るのか？つまり、８０％のマイナーでフォークして大丈夫なのか？反対のマイナーが少数でもいたら確実にビットコインは２つに分岐することになるが・・・
- リプレイプロテクションほか、安全なフォークのための対策が、7/21までの急づくりのソフトウェアで十分対策とテストができているのか？（追記：現状ののβ版ではリプレイプロテクションは施されていないことがわかりました）
- 3ヶ月後という期限は早急すぎないか？それまでに、ウォレットや、取引所ほか、ユーザーが対応できるのだろうか？
- マイナーと一部の企業で密室できめたものでプロトコルの変更をしていいのか？ユーザーが置いて行かれているのでは？
- 開発体制はどうなるのか？Segiwt2xチームは実質Jeff Garzikひとりがコードを書いており、今後Core開発者の支援が得られれないと仮定した場合、フォーク版に価値があるのか？（またはBitcoin Unlimitedチームが引き継いだとして、技術力的にも方向性的にも大丈夫なのか？）
どれも指摘としては十分ありえそうなものです。これらにSegwit2xチームは合意をとっていくのか、それともハッシュパワーとNYAが合意なんだとしてフォークに突き進むのか。マイナーの面子を考えるとNYAの取り下げも難しいですし、延期や取り下げをするにしても、すでにコードに含まれた日程を変える場合、再びソフトウェアの更新と、再採用が必要になります。
Segiwitのアクティベートで一息ついて問題は解決したのではなく、２Mハードフォークをめぐって、本当の論争と権力争いのクライマックスが１１月までに繰り広げられるのではないでしょうか。
P.S 個人的には上記の理由から2Mのハードフォークは頓挫すると予想しています。
＜著作権表示＞
(c) 2017 大石哲之本レポートの著作権はすべて大石哲之に帰属します。本レポートはビットコイン＆ブロックチェーン研究所の会員のみが閲覧できます。本レポートの研究所外への転載および無断引用は固くお断り致します。また、本レポートは、会員本人のみが閲覧いただけます。会員以外へのシェアや法人内での回覧・シェアは固くお断りしております。（回覧人数分の料金を申し受けます）。無断の転載などを見つけた場合、著作権者までご連絡ください。
次の記事
読者になる
一緒に新しい世界を探求していきましょう。
ディスカッション