次の記事は久しぶりにアルトコイン系のものを書こうと思っていたのですが、なかなか調べるのが進まないので、引き続きビットコインの話題です。
内容は数日前から話題になっているASICBOOSTについて。Bitcoin Unlimitedとかスケーラビリティの話はExtension Blocksとか新しいワードが毎日のように出てきていて正直ついていけなくなっていたので、ほとんど調べずにスルーしていましたが、今回の話はSegwitの採用プロセスが始まってから初めてのCore側からの具体的なアクションになるので、調べてみることにしました。
ASICBOOSTについては既に以下のような記事が書かれており、概要を掴むには同記事を読むだけで十分です。何も知らない人は以下の記事を参照すると良いかと思います。実際はもう少し複雑で勘違いするひとも多そうな話なので、ここでは詳細に内容を説明してみます。
ASICBoost＝中国マイナーがSegWitに反対する理由が判明する | ビットコインの最新情報 BTCN｜ビットコインニュース
ASIC BOOSTの手法と対策について | ビットコイン研究所
ASICBOOSTとは
技術的なことはなるべく省略して説明したいと思います。簡単に言えば、ハッシュ計算（SHA-256）の対象であるブロック内のデータをちょっといじくることにより、消費電力を20～30%を節約することを「ASICBOOST」と呼びます。マイニング工場のハッシュレートのボトルネックが電力である場合（おそらくほとんどの場合そうなっている？）、ハッシュレートも上昇することになります。
covert ASICBOOSTとovert ASICBOOST
今回特に問題とされているのが、ASICBOOSTの中でも「covert ASICBOOST」と呼ばれているものです。covertというのは、hiddenとかsecretに似た意味であり、要するに非公開のASICBOOSTのことを指します。covertなので、ASICBOOSTを実際にやっているかどうかは、採掘されたブロックの情報を分析しても分かりません（ブロックの情報がcovert ASICBOOSTの証拠にできるという情報が一部に流れていますが、可能性があるということがわかるだけで、ASICBOOST搭載のマイニングチップに不備でもない限り断言できる確実な証拠が見つかることはありませんし、はっきり分かった時点で「covert」とは言えません。）。
overtというのはcovertの対義語で公開のASICBOOST、つまり誰にでもASICBOOSTを行っていると分かるかたちのものです。現在のところ採掘に際しovert ASICBOOSTを行っているマイニングプールはありません。
技術的にはcovert ASICBOOSTはブロックの中のMerkle rootという部分をいじくることで効率を上げ、overt ASICBOOSTはversion bitsという部分をいじくることで効率を上げるという違いがありますが、どちらも20～30%の効率化というパフォーマンス面での大きな違いはありません。
covert ASICBOOSTの問題点
最大の問題点はcovert型はSegwitをはじめとするビットコインプロトコルの「改善」に互換性がない、ということです。詳細は説明しませんが、現在採用プロセス中のSegwitだけではなく、(U)TXO Commitment、Committed Bloom filters、Fraud Proofsなどの今後実装が期待される技術にも互換性がないとされており、covert ASICBOOSTを許してしまうとこれらの新技術がすべて実装できないことになってしまいます。
特許の問題
一連の話のなかで重要なキーとなっており、かつ上記の互換性がない問題と並んで大きい問題となっているのが特許です。正直特許の話については、各国の特許や法律の関係については詳しくありませんし、具体的な内容が不明なこともあり、軽く調べただけではよくわかりませんでしたが、わかる限り説明してみたいと思います。
ASICBOOSTはそもそも2014年にTimo HankeとSergio Demian Lernerという人が考案したものであり、二人がアメリカでの特許を持っているとされています（現在はSergioは放棄してTimo一人が持っているという話もあり）。
ただし、その後二人の考案者が関わっているのか完全に別々な動きなのかはよくわかりませんが、2015年に中国のASIC製造業者であり75%ともいわれるシェアを持っているBitmainも同じようなASICBOOSTの特許を中国で取得しているとされています。
特許を持っているというのは、つまりその技術を独占できるということを意味します。BItmain自体は今回の騒動の中で、ASICBOOSTの機能がマイニングチップに含まれていることを認めながら、testnetでテストしたことはあるがmainnetで使用したことはないと主張しています。この主張が本当であれば大きなインパクトはないのですが、嘘であった場合は今までSegwitに反対してきた本当の理由はcovert ASICBOOSTが使えなくなるからではないか、ということが推測されるわけです。
ASICBOOSTについては全員が使っていれば違いが生まれないので大きな問題はないのですが、ビットコインに対する特許の悪影響として、特許の制限により一部しか使えないためにマイニングプールの集中化がより進むことが考えられます。
また特許の保有者（Timo及びBitmain）から訴えられる恐れが少ないという点で、マイニングプールが基本的には同じ性能であるovert型ではなく証拠が出てこないcovert型を秘密裏に使用するインセンティブにもなり得ています。
特許の問題は、特許がフリーライセンスであれば解決される可能性が高いと考えられますが、現在のところTimoのアメリカの特許もBitmainの中国の特許も有料になっているようです。
実際に法律的にどうかとか細かい話は、専門家ではありませんし、Timoの特許は保留中であるとか、Bitmainの特許は実は無効なんじゃないかとかいろいろな話が出てきていることもあって複雑なのでよく分かりません。
ASICBOOSTに対する対策の提案
ということで、前述のASICBOOST対策の提案が数日前にCore開発者の代表格であるgmaxwellより出されました。
ASICBOOSTは「攻撃」なのかそれとも「最適化」であるかという議論がありますが、gmaxwellは提案の中ですべてが攻撃であると記述しながらも、特に緊急で重要度の高いビットコインプロトコルの改善の障害となるcovert ASICBOOSTのみをブロック、無効にする提案を出しています。過去にもASICBOOSTの対策の議論がありましたが、現状では他のovert型については特許の問題は残されているもののコミュニティの議論に委ねるとしています。
overt型は特許の関係でマイニングの集中化がすすむリスクや、version bitsを利用するためBIP9によるソフトフォークプロセスに軽微な影響がでるリスク（同時にできるソフトフォーク実行数が29個から十数個に減る程度）が考えられますが、現在のところ実際には行われていませんし、covert型とは異なりSegwitのような新技術との互換性があり、特許が完全にフリーライセンスになれば実質的に無意味なものと化すので、重要度は低いということです。
ASICBOOSTすべてが攻撃であるとか逆に最適化であると考える人もいるでしょうが、プロトコルの改善を阻害するcovert型のみが攻撃で対策すべきと考える人や特許による独占が問題だと考える人もいると考えられますし、白か黒かの単純な話でもないのでここらへんの議論には注意が必要です。
なお、この提案はSegwitでも利用されている95%のマイナーの賛成を必要とするBIP9ソフトフォークではなく、最近話題になっており前回も記事に書いたいわゆるUASFのようなかたちで、特定のブロック高でマイナーのハッシュレートに関係なくソフトフォークを実行する予定のものとなっています。
提案は出されたばかりであり、具体的な日付は決まってませんし詳細が変更される可能性もありますが、他の中心的なCore開発者たちは概ね賛成のようですし、BIP9のより安全なソフトフォークではないため「コミュニティのサポート」が必要としながらも、支持しない場合は新バージョンのCoreを利用しなければ良いという論理で、次々バージョンの0.14.2以降に組み込まれる可能性が高いと考えられます。
なお、covert ASICBOOSTはSegwitと互換性がなく、Segwitが有効化されることでも自動的に対策されることになるので、その場合は提案のソフトフォークの必要はなくなることになります。
Segwit有効化のためのシナリオ
また一ヶ月後には全く状況が変わっていてこの内容も的外れになっているかもしれませんが、この提案により今まで考えていた状況と大きく変わってきたので、Segwit有効化のために考えられるシナリオを最後に書いておきます。もちろんSegwitが永久に有効化されなかったり、Coreチームが解散してBitmain coinになってしまったりする最悪の可能性もあります。
①11月までに現在のBIP9下で賛成ハッシュレートが95%に達し有効化
最も理想的ですが最も楽観的で可能性も低そうなシナリオです。ASICBOOSTを反対派のマイナーが利用していて実はSegwit反対の真の動機であったという仮説が誤っていれば絶望的ですが、正しければマイニングプールが降参して賛成に転じたり、先の提案が11月までに実行されれば反対の動機がなくなって95%に達する可能性もないわけではないと考えられます。
②UASF(BIP148)によりSegwitが有効化
前回の記事でUASFについて書いた時は詳細が明らかになっていませんでしたが、その後BIP148というかたちで明確化し、BIP148適用のノードを運用できるパッチまでリリースされるようになりました。Core側に実装される予定のものではなくshaolinfryという例の人が書いたコードですが、BIP148の仕様の決定後はいくつかのCore開発者の中には意見を言う人も出ており、luke-jrやpetertoddなどは割と前向きな雰囲気を出しています。
ただし、ASICBOOSTへの対策の提案も行ったgmaxwellはBIP148に対して単純なUASFからやや離れた仕様やそもそも性急すぎる（今年の8月より開始）ことに否定的なコメントを出していますし、Coreノードに直接BIP148が実装される雰囲気は全くありません。
UASFの有効化は単純なノード数ではなくいわゆる「economic majority」と呼ばれる世界の取引所や決済サービス企業などの適用が最重要となるので、先日のハードフォークに対する声明でも見られたように特に中立性を強調することが多い取引所を考えると、Coreにもマージされていないパッチが圧倒的支持を得る可能性はかなり低いと思っています。
③11月のSegwit期限以降に再度ソフトフォークプロセスを実行、有効化
一連の騒動を受けて改めて考えると、この可能性が最も高くかつ比較的安全であると思うようになってきました。Segwit採用期限の11月15日までに有効化されなければもうSegwitは終わりだと思われている節がある気がしますが、今回の採用プロセスが終わりというだけで、CoreチームがコミュニティのSegwitに対する賛成状況を見てBIP9のプロセスをやり直すことなどは理論的には十分あり得るのではないでしょうか。
最も安全・確実な方法だった95%の賛成率を要するBIP9ソフトフォークは失敗したが、それはマイナーの攻撃によるためで、ノード数の状況などからコミュニティのSegwitに対するサポートは十分あるため、条件を緩くして再度実行という論理で、BIP9ソフトフォークで閾値を下げるかUASFソフトフォークのコードをBIP148とは別に書いてCoreに実装という流れが実際には考えられます。
④Segwit反対派がハードフォーク、Core側でSegwit有効化
ハードフォークシナリオ。最近はもうないだろうという風潮になっていますが、可能性としてはゼロになった訳ではないと思います。前回の記事ではいっそハードフォークと書いては見たものの、やはりあらゆる面で大変なので止めてほしいです。ただし、Core開発チーム的には攻撃されてもいくらでも対処法はあるというような余裕な雰囲気を醸し出している気がするので、怖いもの見たさに見てみたいドラマというのは言えます。
