先週は寄稿をお休みさせていただいたので前回から間隔が空いてしまいましたが、その間にビットコインの世界は一大論争が巻き起こっています。本稿でも何度か登場している独創的なビットコイン開発者、Jeremy Rubin氏が自身の提案するOP_CTVという機能のソフトフォークによる導入をSpeedy Trial方式で目指すと発表したのです。

ところが同じくSpeedy Trial方式で導入されたTaprootと異なり、まだユーザーやビットコイン開発者の中でOP_CTVに対して広く支持が得られていないこと、Speedy Trial自体がソフトフォークの導入方法として好ましくないことが意見の対立につながっています。

今日はOP_CTVの概要と論争となっているポイントを整理し、個人的な意見も交えながら現在の論争がビットコインの将来にどのような影響を与えうるかを考察します。

TAPROOT導入時のおさらい

Taprootの導入にあたって、2017年にユーザーの大半が支持したSegwitの導入にマイナーが抵抗したことを踏まえ、導入に際してマイナーに依存しないソフトフォークのアクティベーション方法が長期間にわたって検討されていました。

しかし、Taprootの導入自体にはマイナーを含めほとんど反対意見がなかったこと、導入方法の議論に決着が見えずいたずらに時間が経過していたことから、最終的には早期の決着が期待できるSpeedy Trial方式が採用されました。Speedy Trial方式とは特定期日までに数回マイナーによるシグナリングの期間を設け、いずれかの期間でハッシュレートの90%が準備完了をシグナリングするとロックインし数カ月後アクティベーションする、という方式です。もしマイナーの協力が得られないなどして期日までにロックインできなければ失敗となり、導入方法の議論を継続するという計画でしたが、結果的には無事アクティベーションしました。

つまりTaprootにおいてSpeedy Trialの採用はよりよいソフトフォーク導入方法の選定を放棄しアクティベーションを急いだ結果だったといえるでしょう。なぜなら、Speedy Trialは大半のマイナーがネットワークのアップグレードに協力的であるという、2017年に反証された前提に依存するからです。

Segwitにはトランザクション展性というtxidが後から変えられるバグを修正する内容が含まれており、LNの実現に必要なものです。しかし、当時Bitmainが製造するASICにこれを利用してマイニングの効率を改善する機能が搭載されていたため、Bitmainや多くのマイナーが機材の優位性を損なうSegwitの導入に消極的でした。これに反発し、UASF (User Activated Soft Fork)といってユーザーがマイナーの協力なしでもソフトフォークを導入する宣言をし、最終的にマイナーが折れたという経緯があります。

OP_CTVの内容

さて、OP_CTVの内容ですが、過去にも何度か本稿で触れているように、ビットコインUTXOの使用条件を記述する言語Bitcoin Scriptに、使用時の支払先や金額などを限定できるオペコード(関数)OP_CTVを追加するものです。

このオペコードを使うことで、あるUTXOからの支払先や金額等をあらかじめ指定でき(Covenantsといいます)、Bitcoin Scriptで表現できるコントラクトの幅がかなり広がります。簡単なものでは、コールドウォレットに保管するUTXOからの送金先アドレスを自身の所有する別のアドレスに限定することで盗難リスクを削減できるVaultsなどが挙げられます。

Covenantsを実現するオペコードの提案は多数存在していますが、OP_CTVはその中でも有力なものの１つです。

アクティベーション方法に対する批判

Speedy Trialによるアクティベーションはマイナーに主導権を委ねるため、ソフトフォークに反対するユーザーのノードが取れる行動というのは規定されていません。古いノードは新しく追加されたルールが理解できないため、ソフトフォーク後も対応しなければノードの検証機能が低下してしまいます。
したがって一般のノードユーザーがソフトフォークの導入に消極的なのは当然でしょう。マイナーの結託で導入されうるなら脅威ですらあります。

この脅威を感じた一部のユーザーから、ソフトフォークを支持するノードに対してトランザクション伝播を拒否するというURSF (User-rejected soft fork)というコンセプトまで出てきています。これはネットワークの分裂も辞さない混乱リスクの高い運動である点を含め、2017年のUASFに対応するものです。(マイナーとユーザーの意見が逆ですが)

私の意見

Speedy Trialがマイナーとユーザーで意見が合致している場合にしか使えず、ほとんどすべてのユーザーが合意している場合にしか適さないという意見には同意します。

ビットコインへの機能追加手順のあるべき姿について様々な意見がありますが、私が面白いと感じたのはいっそ自由にハードフォークしてはという意見です。実際、ハードフォークであれば賛成か反対かをはっきりと選択でき、さらにBitcoin Cashの分裂、Segwit2x騒動のときのように分裂コインの先物市場がマーケットの評価を客観的に反映できるかもしれません。また、個人的にはハードフォークとして失敗するような提案はソフトフォークとしても成功しなさそうな感覚があります。

ビットコインには負担や混乱を避けるためハードフォークを避ける傾向があるので、実際にこの仕組みが採用される可能性は低いでしょう。ハードフォーク方式ではなかったとしても、何らかの予測市場の登場が解決するかもしれません。

CTV自体に対する批判

こちらは見かける数がやや少ない印象で、やはり一般ユーザーには判断が難しいところが大きな原因でしょう。開発者間でも意見の相違があることが”Technical Consensus”がないと表現されているのを見かけます。

まず、Covenantsを導入する提案がいくつもある状況で、どの方法でCovenantsを実装すべきかについてはまだ意見が割れており、そもそもCovenantsの実装が望ましいかさえ決着がついていません。

その合意を得る上で特に難しいのはCovenantsの導入がビットコインに与える副次的な影響についての分析です。Covenantsがどのように使われうるか、将来的にビットコインやそのユーザーにとって不利な作用がないかなどを検討する必要があります。深慮を優先する意見は保守的なビットコインならではですし、ビットコインの良さの１つでしょう。
しかし、どれだけ議論すれば出尽くしたといえる基準があるわけではない点は難しく、どうしても長い時間がかかってしまいます。

個人的意見

Covenantsの導入によって、様々な新しいことができたり、ライトニングが改善できるところもあるので、個人的には期待しているところです。それがCTVであれ、ANYPREVOUTであれ、それ以外の提案であったとしても、いずれ導入されることがビットコインにとってマイナスになる理由は思い当たりません。

また、CTVは他のCovenants導入提案に対してなされた意見を取り込んであえて機能性を制限しているところなど、慎重派の意見に寄り添ったものであるところも評価すべきだと感じます。Jeremy Rubin氏本人も、OP_CTVでなくてもいいので何らかのCovenantsが導入されるのを心待ちにしていると発言しているように、問題提起という側面は非常に応援したくなるものです。

実際に他のCovenants導入提案も含めて建設的な議論も活発化しており、好影響が出ていると感じています。

ビットコインは変わらないほうがいいのか

ビットコインユーザーの中に機能追加はもういらない、現状で十分、保守だけしてくれという意見が散見されます。確かに、2100万枚という発行上限や安定性だけを求めているユーザーにとっては機能追加はリスクと捉えられるでしょう。

一方で、開発者はまだ追加すべき機能があると考えている人が割と多いです。これは例えばプライバシーの改善につながるものであったり、スケーラビリティの向上につながるもの、レイヤー２を強化するのに必要なものです。

このような違いから、ビットコインが普及するにつれ開発者が欲しがる機能追加についてユーザーの合意を得ることは難しくなっていくと予想されています。考えてみればSegwitも、多くの人にとってはトランザクション展性問題ではなく、手数料高騰期において事実上のブロックサイズ拡張が見込めたことで支持されたのかもしれません。

まとめ

・Jeremy Rubin氏がCovenantsを導入するOP_CTVのソフトフォークをとりあえずSpeedy Trialで実施すると宣言
・開発者コミュニティからはCovenants導入是非、OP_CTVの選択について合意が形成されていないとの批判が多い
・ユーザーからは導入反対の声が多く、反対強硬策URSFを示唆する声も
・Speedy Trial自体は全体的に嫌悪されている手段で、失敗する可能性が非常に高いと考えられる
・Taproot導入でくすぶっていたビットコインへの機能追加方法に関する議論が再燃
・Covenantsの導入議論、導入すべき提案の選定が進みそうなので個人的には応援している
・Speedy Trialに対する反感がビットコインへの機能追加手順に関する議論再燃の起爆剤になっただけでも今回の騒動には価値があると感じる