Gunosy Blockchain Blog

Gunosyの開発メンバーが知見を共有するブログです。

ビットコインのフォークとアクティベート方法のまとめ

はじめに

こんにちは。開発本部の @yamarkz です。

昨今ビットコインのスケーリング問題がさらに顕在化してきていますね。

最近では主要取引所での手数料改定も行われました。

スケーリング問題を解決するための手段は日々IRCで議論され、現在も改善へ向けた開発が進められています。

直近では2017/8にアクティベートされた「segwit」や、2017/11に中止となった「segwit2x」などが解決手段として注目を浴びました。

今回はこれらの解決手段がどういったフローでアクティベートに到っているのかを紹介したいと思います。

※ 今回紹介するのはソフトフォークによるコンセンサスレイヤーの新規機能追加、バグ改善のフローです。

本文中の各用語は以下のように棲み分けています。

  • リリース
    • ソフトウェアのリリースのこと (例: bitcoin core 0.15.1)
  • ソフトフォーク
    • 特定の機能をアクティベートに到るまでのフロー全般
  • アクティベート
    • ソフトフォークを実施した際のゴール。 機能が実際に本番環境のノードで適用されることを意味します。
  • クライアント
    • マイナーなどのフルノードを想定しています

ソフトフォークとハードフォーク

アクティベートに到るまでの流れを見て行く前に、前提知識として必要な「フォーク」について触れておきます。 ビットコインに興味がある人なら「フォーク」と呼ばれるワードは1度は耳にしたことがあるのではないでしょうか。 フォークには大きく分けて2種類存在します。「ソフトフォーク」と「ハードフォーク」です。

ソフトフォーク

ソフトフォークとは、ブロックチェーン後方互換性のある ソフトウェアのアップデートのことです。 「後方互換性のある」という部分がポイントで、これは既存の仕様よりも厳しい規約を設けることです。

ハードフォーク

ハードフォークとは、ブロックチェーン後方互換性のない ソフトウェアのアップデートのことです。 「後方互換性がない」とは、既存の仕様よりも緩い規約を設けることです。

上記2つのフォークの仕組みについては、Blockchain Tokyo #2 のLTで発表していただいた @sonatard さんの資料がとてもわかりやすくまとめてられています。 理解に不安がある方は下記スライドを参考にしてみてください。

speakerdeck.com

それでは、ソフトフォークを行う方法を見ていきます。

ソフトフォークを行う3つの方法

ソフトフォークを行う方法は主に3つ存在します。

  • flag day activation (フラグデイ)
  • IsSuperMajority (ISM)
  • version bits (BIP9)

※ 現在はBIP9を用いてソフトフォークが行われています。

flag day activation (フラグデイ)

初期のビットコインで用いられていたソフトフォークの方法がflag day activation (以下、フラグデイ) です。

フラグデイは特定の期日を設け、「期日以降に新しいルールを適用しますよ。」と事前にマイナーに勧告を行ってからアクティベートを実施します。 マイナーは事前の勧告を受け、期日前にクライアントのアップデート対応を行います。

実際にフラグデイを用いて行われた BIP16 のソフトフォークは 2012/04/01 09:00:00 にアクティベートされました。 BIP16の実行コードは こちら に記載されています。

f:id:yamarkz:20171227144544p:plain:w400

フラグデイの仕組みはシンプルですが、これは危険なソフトフォークの方法でもあります。なぜなら、フラグデイはマイナーのハッシュパワーのバランスを全く考慮していないソフトフォークだからです。

ハッシュパワーのバランスを考慮していないソフトフォークでは、リオーガニゼーションの問題が発生する可能性があります。

リオーガニゼーション (Reorganization)

リオーガニゼーション (以下、reorg) とは「チェーンの再編成」という意味で、分岐したブロックチェーンが1つのメインチェーンに収束することです。

f:id:yamarkz:20171228094847p:plain:w400

ビットコインでは 「チェーンが分岐した場合、長い方のチェーンを有効なものとする」 というルールがあります。このルールにより、reorgが発生します。 reorgは実は頻繁に発生している現象で、同じタイミングでマイナーがブロックを生成した時にも起きています。 この場合、reorg自体は一時的なもの (2~3ブロック分) で最終的に1つの長いチェーンに収束するためそれほど問題にはなりません。 reorgが発生したチェーンは収束時に削除されます。

問題はソフトフォークをきっかけに中途半端 (1日単位 約144ブロック分など) にチェーンが伸びてしまった場合です。

この問題を下記で解説します。※ わかりやすさを求め単純な例を用いています。

リオーガニゼーションにより起こる問題

f:id:yamarkz:20171228121242p:plain:w400

フラグデイによりアクティベートが実施され、旧仕様チェーンAと新仕様チェーンBが作られた場合を想定します。例えとして、マイナーグループA (50%) とマイナーグループB (50%) に別れてマイニングが行われました。これはハッシュパワーが拮抗している状況です。

AとBは元々同じ仕様のチェーンでマイニングしていましたが、グループAがフラグデイのアップデート勧告を忘れるなどして、アップデートを行わず、そのまま旧仕様チェーンでマイニングを続けてしまいます。

グループBは勧告通りアップデートを行い、期日後は新仕様が適用されたチェーンでマイニングを続け、チェーンを伸ばして行きます。

f:id:yamarkz:20171228121932p:plain:w400

グループAは途中でこの状況に気づき、急遽ソフトウェアのアップデートを行いグループBに合流します。(チェーンAはこの時点で、既にいくつかのブロックがマイニングされています。)

AからBにマイナーが移動したため、チェーンAは止まり、ハッシュパワーが100%になったチェーンBが伸び続けメインチェーンとして認識されることになります。 これにより、新仕様のチェーンBがメインチェーンとなりソフトフォークは成功します。

しかし、この状況で問題が発生します。問題として注目すべき点はチェーンAが伸びた後、グループAのマイナーがグループBに移るタイミングです。

f:id:yamarkz:20171228121901p:plain:w400

このタイミングでは既にマイニングされたブロックがチェーンAにはいくつか存在しています。これらのブロックはマイニングとして成功し、チェーンAに繋がれたものです。この時、メインチェーンとして認められなかったチェーンAは最終的に 削除される (reorgされる) ことになります。

reorgが起きることで、「チェーンAでは承認済みトランザクションが、チェーンBでは未承認トランザクションとして存在している」という状況が生まれます。これにより送金の整合性が保たれていない混乱した状況が引きおこされる可能性があります。

具体的には、ある商品を購入した対価としてビットコインを支払ったにもかかわらず、reorgにより支払いのトランザクションが参照している未使用トランザクションアウトプットが消失します。 その結果、ビットコインの受け取り側は無効なトランザクションを受け取ったことになり、受け取り側に損失が生まれます。

また、チェーンAのマイニングで得られた報酬もなくなるため、この報酬を参照しトランザクションを作成したとしてもそのトランザクションは無効なトランザクションになります。

f:id:yamarkz:20171228132918p:plain:w400

このようにソフトフォークを起点に途中まで繋がれたチェーンAが削除される (reorgされる) ことによって、送金の整合性が保たれない混乱した状況が生まれてしまう可能性があります。

フラグデイは一見シンプルなソフトフォークの実施方法に見えますが、一歩間違えると送金の整合性が保たれないという危険なソフトフォークの手段なのです。 こういった状況が想定されるソフトフォークはやめるべきだとして、新たに考えられたのがIsSuperMajorityと呼ばれるソフトフォークの手段です。

flag day activationを用いて行われたソフトフォーク

IsSuperMajority (ISM)

IsSuperMajority (以下、ISM) とは、直近マイニングされた1,000ブロックの内、950ブロックがソフトフォークのversion値に対応したブロックであった場合に、アクティベートが実施される方法のことです。

f:id:yamarkz:20171226182744p:plain:w400

ISMを用いてソフトフォークが実施される場合、クライアントをソフトフォークの実装が含まれた最新バージョンにアップデートすると、生成されるブロックのversion値が変わります。

この特定のversion値が含まれたブロックが直近1,000ブロック中何ブロックに含まれているのかをカウントし、アクティベートを実施する判定に用いています。

そして、1,000ブロック中、950ブロック (全体の95%) に特定のversion値が含まれていた場合にアクティベートが実行されます。

このように完全にマイナーの準備が整った段階 (95%の準備) でアクティベートが実施されるため、フラグデイの様にブロックチェーンが中途半端に伸びることで混乱が発生する問題を防ぐことができるようになりました。

実際にどういったブロックがソフトフォークに対応しているのか見てみます。↓

f:id:yamarkz:20171226121413p:plain:w400

2016/02/25に生成されたブロック高400,000のブロックでは、version値が4となっています。 このversion値4は BIP65 のソフトフォークに対応したマイナーが生成したブロックということになります。 ISMではこの値が含まれるブロックの数をカウントしています。

ISMの実行コードは こちら に記載されています。

フラグデイの問題点を解決したISMですが、ここにもいくつかの問題がありました。

  • ISMには期限 (limitTime) という概念が存在しません。その結果、ソフトフォークが完了しない限り実質無限にアクティベート待ちの判定が続きます。
  • ISMでは同時並行で複数のソフトフォークを行えません。その結果、前に開始されたソフトフォークが完了しない限り次のソフトフォークが実施できないため改善サイクルが止まっています。

これらの問題を解決し、現在用いられている方法がBIP9として定義されている「version bits」と呼ばれるものです。

ISMを用いて行われたソフトフォーク

version bits (BIP9)

version bits (以下、BIP9) とは、ブロックのnVersionフィールドの値に含まれるbits値 (以下、シグナル値) を元にマイナーの対応状況を把握し、一定期間中に生成されたブロックの内、全体の95%のブロックにシグナル値が含まれている場合にアクティベートを実施する方法です。

BIP9では、クライアントをソフトフォークの実装が含まれた最新バージョンにアップデートすると、生成するブロックのnVersionフィールドの値にシグナル値が追加されます。 このシグナル値が含まれたブロックを retarget period と呼ばれる区切りでカウントします。(retarget periodとは2016ブロックごとの区切りのこと)

カウント期間中に全体のブロックに対して95%のブロックにシグナル値が含まれた段階でアクティベートがロックインされます。(95%という値は2016ブロック中、1916ブロック以上に特定のシグナル値が含まれているということ)

ロックインとはソフトフォークの導入が確定することで、ロックインされた次のretarget periodでアクティベートが実施されます。 法律で例えると、ロックインは「法案成立」ということになり、アクティベートは「法律施行」の部分に該当します。

f:id:yamarkz:20171227144627p:plain:w400

また、BIP9ではstartTimeとtimeoutという値を設定します。

startTimeはシグナルの集計が開始する時間で、このstartTime以降の最新のretarget period以降から集計が始まります。

timeoutはシグナルの集計が終了する期限で、基本的にはstartTimeの1年後を設定するようになっています。

f:id:yamarkz:20171226143902p:plain:w400

そして、BIP9では複数並行でソフトフォークを進めることができます。

ISMでは前に開始されたソフトフォークが完了していない限り、次のソフトフォークが行われない仕様でした。(順番通りソフトフォークを行わなければいけない)

その結果、1つのソフトフォークの実施に時間がかかってしまった場合、改善のサイクルが遅くなるという問題が発生します。

この問題をBIP9では解決し、前のソフトフォークの完了を待たずに後方のソフトフォークを行うことが可能になりました。

例えると、「ソフトフォークA(シグナル値 1) の浸透率は30%だが、ソフトフォークB(シグナル値 4) の浸透率は95%を超えたため、先にBをロックインする。」といった感じです。

実際に複数のソフトフォークが走っていた時のシグナル値を見て見ます。↓

f:id:yamarkz:20171227151244p:plain:w400

ブロック高 #477039 は 2017/7/22 にマイニングされました。

このブロックのバージョンは 0x20000012 となっています。このバージョン値の下2桁に注目です。

1(bits4)と2(bits1)という値はシグナル値で、このブロックは複数のソフトフォーク(bits4とbits1)のシグナルを発しています。

ちなみに、この時のbits1は「BIP141」のシグナルで、bits4は 「 BIP91 」のシグナルです。

シグナル値は1~29番まで変えることができるので、最多で29個のソフトフォークを同時並行で実施すること可能です。

BIP9を用いて行われたソフトフォーク

まとめ

今回の内容をまとめると。

ソフトフォークの実施手段は主に3つある。「flag day activation (フラグデイ) 」「IsSuperMajority (ISM) 」「version bits (BIP9)」。

これらの手段は実行して挙げられた問題点を解決し、改善されてきている。

最後に

今回はビットコインのソフトフォークの手段を見てきました。フラグデイから始まり、ISM、BIP9と手段の進化を本記事で掴んでいただければ嬉しいです。ビットコインはまだまだ発展途上で今後もソフトフォークを実施し、機能改善が続いて行くと思われます。今回の内容を踏まえ、今後ソフトフォークが実施される際にはどういった手段で、進んでいるのかウォッチしてみてください。

宣伝

Gunosyでは、blockchain.tokyo を主催するなど、ブロックチェーンや仮想通貨に関する調査を行っています。

次回は来月、メルカリさんに会場をお借りしてイベントを開催する予定ですので、興味がある方はぜひ下記のイベントページからのご参加お待ちしております。

blockchain-tokyo.connpass.com

また、弊社ではブロックチェーンを始めとしてスマートスピーカー、VR/ARと言った新規領域での研究・開発を進めており、メンバーを募集しています。

www.wantedly.com