昨年11月にようやくアクティベーションまでこぎ着けたTaprootですが、現時点ではまだ使用は広がっておらず、直近3ヶ月では全トランザクションによるアウトプットの0.5%程度にとどまります。Native Segwit (bech32)のときと同じく取引所やウォレットの対応に時間がかかっていることも理由の１つですが、Taprootアドレスの利用によるマルチシグの費用削減効果の大きいライトニングチャネルにも現時点では使用できません。
その理由はTaproot利用上のLNのいくつかの仕様がまだ定まっていないためです。今日はどのような仕様変更が検討されているかまとめます。
Taprootの使用はライトニングチャネルの協力的閉鎖時の手数料を40%削減する効果があります。
ゴシッププロトコルの改変
ゴシッププロトコルとはチャネルの開設や手数料変更など、ライトニングノード同士がネットワークについての情報を全体に伝播していく際のメッセージに関する取り決めです。現在のゴシッププロトコルではチャネルの開設メッセージを配信する際にチャネルのオンチェーンでの(UTXO)所有を署名によって証明する必要がありますが、Taprootチャネルの所有を証明・検証する方法はまだ定められていません。
そこで、Taprootチャネルに対応するようゴシッププロトコルをどう改変するかについて、大きく分けて２つの方針が考えられます。１つは、現状のプロトコルに最低限の変更を加えるだけでなるべく早く使用できるようにするもの("Kick the can" = より根本的な変更は先延ばし)。もう１つは、この機会に数年間の知見を元にゴシッププロトコルを刷新してプライバシー面での改善などを盛り込むものです。
前者は比較的簡単に行えるでしょう。従来のchannel_announcementメッセージではチャネル両端のノード秘密鍵による署名(メッセージが本人によるものである確認)と、マルチシグUTXOの鍵による署名(実際にUTXOを所有している確認)の合わせて4つの署名と、その検証用に4つの公開鍵が求められますが、Taprootチャネルの場合はこれら4つを加算した1つの署名と4つの公開鍵で済みます。
また、このうち2つのオンチェーンの公開鍵を加算したものを実際のUTXOと照らし合わせるシンプルなモデルの他に、tapscript_root欄を加えることでUTXO自体に他に使用条件があったとしても秘匿したまま検証可能になります。個人的にはとりあえずはこの案で進めるのがいいと思っています。