最近、UASFという言葉が一部で話題になるようになってきました。
UASFとは、ユーザー・アクティベイテッド・ソフトフォークの略です。ご存知の通り、Segwitは、マイナーの９５％のサポートがあってアクティベートされます。しかしながら、現状では、これが達成される見込みはほとんどありません。
そこで、マイナーがこれを後押ししないのであれば、ユーザーが主導でSegwitのアクティベートができないかというのがUASFの試みです。
今回は、研究所のみなさんのような一般ユーザーがUASFに協力するための具体的な方法と、UASFの状況を追っていくためのための情報源についてレポートします。
まずは、基礎知識として、UASFとはなにか、マイナーアクティベイトソフトフォークと、UASFの違いについての説明を行います。
なお、すでにUASFについて理解しているかたは、後半の「UASFに参加するあには？」からお読みください。
マイナーアクティベイトソフトフォーク（MASF）
マイナーアクティベイトというのは、マイナーがブロックを生成する際に、そのブロックに、ソフトフォークへの対応状況のフラグを立てることで行われます。
これは、BIP9という仕様にきめられていて、バージョンビッツと呼ばれています。このビットを立てることによって、特定のソフトフォークへの対応を示します。これがいわゆるシグナリングとよばれているものです。
BIP9で示すソフトフォークでは、一定のスタートと終了の期間を決めて、その間に、ハッシュパワーの９５％が対応を完了した時点で、ネットワーク全体でソフトフォークが有効になるという方式です。
つまり、マイナーにソフトフォークへの対応が求められているわけです。
（直近ふたつのソフトフォーク(OP_TIMELOCK_VERIFY、OP_CSV)は、マイナーアクティベイトソフトフォークにより行われました。それぞれ数カ月から半年以上かかりましたが、マイナーがソフトウェアをアップデートすることで、ソフトフォークが発動しました）
少林氏による批判と、UASF
これに対して、突如現れた匿名のユーザーのShaolin fly氏が異をとなえ、UASFを提案しました。(なおShaolin flyとは、少林飛びのことですｗ）
Segwitへのシグナリングは、あたかもマイナーによる投票のような形に捉えられています。マイナーが投票権を持っていて、プロトコル変更への可否を決めるといった形にとらえられています。
少林氏は、この認識が大きな誤解であるとしています。つまり、もともと、Segwitはコミュニティのひろい希望によって開発が進み、実際に開発者がコードを書いてリリースしました。
マイナーは、これを審査して、採用可否などをする権利などはなく、粛々と採用すべきだとい言っています。
９５％という数字は投票ではなく、マイナーの準備状況をモニターするたもの指標にすぎないと少林氏はいいます。
つまり、もしマイナーが３０％とか５０％しか準備ができてない状況で、Segwitが発動されてしまうと、フォークが起きたり、準備できてないマイナーが困るため、みんなが準備をすすめて、９５％になったら、一斉に発動させましょうね、ということなわけです。
投票ではなくて、安全に発動するための対応状況をモニターする指標が９５％だというわけなんですね。
しかし、これが「マイナーによる投票」と捉えられいて、マイナーに権利があり、意思決定をマイナーに委託しているようにかんがえられているというのが問題だというのが少林氏の指摘です。そこで、Segwitの発動をユーザー主導でおこなおうというのがUASFです。
ユーザー・アクティベイテッド・ソフトフォーク(UASF)
対するUASFでは、マイナーの準備の如何にかかわらず、ユーザーネットワークのアップデートを先に行います。ユーザーというのは、P2Pのフルノードのほか、取引所や、ウォレットといったものも含みます。
