詳解Watchtower: Lightning Networkノードの守り方

本記事ではWatchtowerの仕組みについて詳しく解説します。

以前の記事でWatchtowerの概要と現状について解説する記事を投稿しました。Watchtowerとは何か、ということを学びたい方は、以前の記事から読むことをお勧めします。

今回の記事では、「Watchtowerがどのように暗号化したトランザクションデータを保管し、違反発見時に公開するのか」や「ユーザーのバランスやトランザクションの中身を把握しないWatchtowerによる監視保護の実現方法」について詳しく解説します。

前回記事を読んで詳細が気になった方や、Bitcoin / Lightning をもとにしたアプリケーション設計・実装を検討している方に読んでいただけると嬉しいです。

Watchtowerの実装

Watchtowerの実装として主にThe Eye of Satoshi, LND Watchtower, Electrumの3つの実装があります。

The Eye of Satoshi (TEOS)

c-lightningのプラグインとして実装されており、Watchtowerのファレンス実装として参照されることもあるようです。Watchtowerの標準仕様（後述）を意識した作りになっているため、操作することで標準の学習・理解が進みます。

LND Watchtower

LNDのオプションとして提供されおり、ビルド/起動時の設定によりWatchtower機能を有効化できます。広く使われているLND実装なだけあって、最初に触るWatchtower実装としてはハードルが低く使いやすいです。筆者としては一番お勧めの実装です。

Electrum Watchtower

Watchtower仕様であるBOLT13（後述）とは独立したElectrum独自仕様であり、LNDやTEOSとは大きく設計が異なる実装です。

BOLT13: Watchtowerのプロトコル仕様

Watchtowerには一応プロトコル仕様があります。Lightning Networkの標準仕様であるBOLTに提案されている BOLT 13 です。

正確にはこの仕様はドラフト状態であり、公式なWatchtowerの仕様はまだありませんが、前述したThe Eye of SatoshiやLND WatchtowerはBOLT 13を元にして実装されています。

💡

残念なことに5年前からドラフトの更新がストップしており、おそらく公式な仕様になる見込みは今のところありません。筆者が読んだ印象としても、かなり内容の詰めが甘いです。

Watchtowerの仕組み

Watchtowerの仕組みの説明に入ります。本記事における仕組みの説明はBOLT 13のプロトコルを参照したものとなっています。クライアントが監視を委託し、Watchtowerが監を実施、罰則を実行をするまでを以下の順序で説明します。

前提 / 背景
Watchtowerの探索・発見
Watchtowerへの認証情報の登録
監視の依頼情報の作成
監視の依頼
監視の開始
違反の発見と罰則の実行

0. 前提 / 背景

Alice と Eva がすでにLNのチャネルを開設していると仮定します。

また本記事ではそれぞれの役割を以下のように設定します。

Alice: オフラインになる想定でWatchtowerに監視保護を委託するユーザー　（Watchtowerクライアント）。
Eva: Aliceのオフライン時に不正を狙うユーザー

チャネル開設時はオフチェーン上でEvaの方が多くの資金を保管していましたが、オフチェーン決済を繰り返すうちに、チャネルの資金状態を表す最新のコミットメントトランザクションではAlice の方が多くの資金を持っています。

この状態でAliceが気をつけるべきことは、Aliceのオフライン時にEvaが古いコミットメントTX をオンチェーン上に公開し、Evaが不正に得をした状態でチャネルを強制的に閉鎖する状況です。(いわゆるUgly Way)

1. Watchtowerの探索・発見

Alice は監視を依頼する Watchtower を探すところから始めます。

Watchtower が理想とする世界観では、何らかの探索システムやプロトコルに基づき、依頼可能な Watchtower がいくつも発見でき、Watchtower ごとに異なる依頼金、支払い形態やサポートする拡張機能などをAliceは取得し、条件に見合ったWatchtowerを選択することができる状態です。

しかし、今のところそのような探索システムや、Watchtower への報酬の仕組みは整っていません。そのため、Alice は自前で Watchtower を建てる、もしくは自力で発見した Watchtower サービスに対して監視を依頼する必要があります。

💡

Lightning Network+ がLightning Watchtower Swapsという、2者間で相互に監視し合うWatchtowerを建てるサービスを提供しています。

2. Watchtowerへの認証情報の登録

Alice は Watchtower への監視依頼を始める前に、自身の認証用の情報をWatchtowerに登録する必要があります。これは Alice が今後Watchtowerへ送る監視依頼などのメッセージを Watchtower が認証した上で処理する必要があるためです。認証用の情報としてはAliceの公開鍵のみをWatchtowerに共有します。この時Watchtowerは、Aliceについて公開鍵とピア接続情報のみしか知らないため、Watchtowerが取得するプライバシー情報は最小化されています。

3. 監視の依頼情報の作成

AliceはWatchtowerに対してLNノードの監視依頼をする前にWatchtowerが監視に用いるデータセットの整理を始めます。

監視依頼を作成するための情報には、主に「監視対象となる相手の違反コミットメントTXのID」と「違反発見時に公開する自身のコミットメントTX(罰則トランザクション)」を用います。

Locator
罰則のトリガーとなる コミットメントTX ID の前半部分の16バイトデータをLocatorと呼びます。「ブロックチェーン上にこのTX IDを持つTXが現れたら罰則を開始してください」という目印になります。WatchtowerはTX IDの前半しか知らないため、オンチェーン上でこれと一致するTXを見つけて初めてTX IDの後半部分を知ることなります。

encrypted_blob
コミットメントTX IDの後半部分を暗号鍵としてAES-GCMで暗号化した暗号化済みトランザクションデータです。Watchtowerに対してプライベートな取引内容を極力知られないように暗号化された罰則用トランザクションです。

4. 監視の依頼

監視の依頼メッセージデータは appointment と呼ばれます。appointment には「3.監視の依頼情報の作成」で生成したLocator、encrypted_blobを含めます。

さらに、この appointment データに対して Alice の署名を加えて、Watchtower に対して送信します。Watchtower は「2. Watchtowerへの認証情報の登録」時にAliceから共有された公開鍵で署名検証を行いappointmentデータの認証を実施します。認証に成功するとWatchtowerはそのappointmentを保管します。

💡

appointment はコミットメントTXごとに作成します。そのため、中継ノードとして使用され、コミットメントTXが更新された場合も改めてappointment の更新を行う必要があります。

5. 監視の開始

Watchtower はオンチェーン上のトランザクションを監視し、Locator と一致する TX ID がないかを常時監視します。

💡

実際はオンチェーンだけでなくmempoolも監視している。これにより迅速に罰則の実行が可能になる。

6. 違反の発見と罰則の実行

Evaが古いコミットメントTXを公開する違反を試みたと仮定します。

オンチェーン上を監視していたWatchtowerは、Locator と TX ID の前半部分が一致する違反TXを発見し、すぐさま違反の罰則を開始します。

Watchtower は発見した違反トランザクションから初めてフルのTX IDを知ることになります。暗号化されたコミットメントTX はTX IDの後半部分の文字列をキーとして暗号化されているため、WatchtowerはTX IDの後半部分でコミットメントTXを復号することができます。

Watchtower は復号したコミットメントTXを罰則用トランザクションとしてオンチェーン上に公開します。その後、LNにおける一般的な罰則用トランザクションの処理と同じ流れで処理が進みます。

💡

Watchtowerによる罰則の実行はクライアント（Alice）がオンラインかオフラインかは関係なく、罰則用トランザクションを公開します。Watchtower はクライアントの情報を知り得ないため、クライアントが SPV ノードなどの場合はトランザクションの検出ができない場合もあるからです。

Watchtowerへの監視報酬の支払い

Watchtowerが理想とする世界観では、Watchtower対する報酬支払いの方法としてさまざまな方法が提案されています。例えば、**「成果報酬としてペ罰則用トランザクションのOutputでWatchtowerに出金する」「定期的なサブスク支払い」「任意のジョブが発生する度にマイクロペイメント」**などがあります。しかし、BOLT13では具体的な報酬支払いにおけるプロトコルや金額の設定方法などの詳細が記載されていません。

さらに、現在BOLT 13で詳細に定義された仕様には「2. Watchtowerへの認証情報の登録」時に、Watchtowerからクライアントへのレスポンスにinvoiceを含め、Watchtowerへの報酬金の支払い先を設定する方法のみが定義されています。ただ、invoiceを指定するだけなので未払いは容易に起こり得ます。

また、Watchtowerのinvoice設定の機能もThe Eye of Satoshi実装では実装されているものの、LNDでは未実装です。

拡張機能

BOLT13ではWatchtowerの拡張機能について述べられており、現在は「領収書機能」(accountability)のみが定義されています。

Watchtowerが署名入りの領収書をクライアントに渡すことができます。これはクライアントがWatchtowerに依頼した証明として利用でき、Watchtowerがサボり「ペナルティ取引を中継していないことの証明」や「返金の請求」など、追加のアプリケーションやサービスに利用できます。

Watchtowerの課題：プライバシー重視によるストレージの圧迫

Watchtowerがクライアントから受け取るTXは暗号されており、WatchtowerはTXの中身を把握できないためチャネルにおいてどのTXが最新のものか把握することができません。そのため、古いコミットメントTXも保管して必要があり、Watchtowerサーバーのストレージの圧迫が課題となっています。

まとめ

Watchtowerは、Lightning Networkにおける不正なチャネル閉鎖を防ぐための仕組みで、ユーザーがオフラインでも古いコミットメントトランザクションの公開を検知し、罰則トランザクションを代わりに公開します。Watchtowerの標準仕様としてBOLT13が草案として存在しますが正式採用には至っていません。

ユーザーは、罰則の契機となるコミットメントTXIDの一部であるLocatorと、罰則トランザクションを暗号化したencrypted_blobをappointmentとしてWatchtowerに送信し、Watchtowerはこれを保管しながらオンチェーンやmempoolを監視します。不正が発生した場合にのみ復号が可能となる設計のため、Watchtowerはユーザーの資金状態や取引内容を把握せずに監視を引き受けられます。

今後の記事ではWatchtowerの機能拡張を提案した論文や最新の議論についても詳解します。