今日はかなり地味な話題ですが、ライトニングノード運営者が困る可能性のあるDoS攻撃対策として提案されているStateless Invoicesというものを解説します。
問題：インボイス発行にはデータ保管が伴う
ライトニング上の支払いは基本的には送金を受け取る側のノードがインボイスを生成するところから始まります。インボイスの生成に使用したプリイメージ(秘密データ)は実際にビットコインが送られてきた際にそれを受け取るのに必要なため、インボイスの生成にはデータ保管が伴います。(さもなくば受け取ることができず、生成した意味がない)
インボイスの期限が切れた後は受け取る予定がないので削除しても問題ありません。別の話題にはなりますが、送金や中継があるたびに当該チャネルの「過去のステート(状態)」が生まれ、相手による不正なチャネル閉鎖を防ぐセキュリティモデル上、チャネルを閉じるまでこれを削除できないのもLNノードのデータ保管問題の１つです。
そこでLNノードに対する１つのDoS攻撃ベクトルとして、短時間に非常に大きな数のインボイスをリクエストすることで相手のノードに膨大な量のデータを保管させるというものが考えられます。こうしてストレージの余裕が全くなくなってしまうと、新たなインボイスの発行が妨害されたり、ノード自体の動作の不安定化につながります。
アプリケーションのバックエンドとして通常利用する分には、アプリケーション自体にインボイスを短期間に大量生成するユーザー対策を施せば良いでしょう。しかし、DoS攻撃と実際の利用者の区別がつきにくいケース(例えば日付が変わると同時に「サトシタイム」が始まってみんなが一斉に10 satsもらうインボイスを発行するなど)があったり、そもそも対策の実装が手間でライトニングの導入を面倒にしてしまうので、インボイス発行時のデータ保管を発行ノードではなく送金者に任せる方法が提案されました。これがStateless Invoicesです。
STATELESS INVOICESの仕組み
ライトニング慣れしている読者の皆さんは疑問に思うでしょう。「最初からプリイメージをユーザーに渡してしまうと、ライトニングのトラストレス性が損なわれるのではないか」と。でも大丈夫です。なぜなら、Stateless Invoicesではインボイス自体にプリイメージではなく「プリイメージの導出に使うパラメータ」を盛り込むからです。
具体的に見ていきましょう。