今週、ライトニングネットワークにおいてZero-confチャネルを可能にする仕様変更がライトニングの仕様群であるBOLTに正式にマージ(採用)されました。BOLTはライトニングノード同士の通信やインボイスなどの形式を定めた仕様群で、多数あるライトニングノードの実装は最大限の相互運用性を実現するにはすべてに対応する必要があります。(逆に、相互運用性に関係のないデータの保存形式やAPI、UIなどは規定されていません。)
https://github.com/lightning/bolts/pull/910
さらに、Spiral (旧Square Crypto)がRustという言語を使って開発するオープンソースのライトニングノード実装「LDK」にはすでにzero-confチャネルの機能が追加されました。BOLTの策定を主導したRusty Russell氏とともにSpiralのMatt Corallo氏が中心となって推し進めた機能の１つだからです。
主にLSPとユーザーの間での利用を念頭に置いたZero-confチャネルについて、概要と長所・短所を見ていきます。
LSP（ライトニングサービスプロバイダー）とは、ライトニングネットワークを利用する上で便利なサービスをエンドユーザーに提供する事業者のことです。例えばノンカストディアルウォレットでオフラインの支払い受け取りを可能にするなど、一般的には「ある程度信用できる相手」としてLNのユーザビリティを改善する事業者のことを言います。
ゼロ承認とは
ビットコインでは署名されたトランザクションは各ノードを伝播していき、その過程で各ノードのメモリ上の未承認トランザクション領域(メモリプール) に保持されます。ゼロ承認取引とは、支払いの受け手のメモリプール上での確認をもって決済と見なすことを言います。5年くらい前までは聞くことがありましたが、今では強く非推奨されているため見かけません。
もちろんブロックチェーンに取り込まれたわけではなく、確実に取り込まれる保証もありません。例えば手数料相場が急騰して未承認取引が増え、そのままサイズ上限に達したメモリプールから脱落してしまったり、あるいは送金者がより高い手数料で同じコインを自身に送るトランザクションを配信し、それが先に取り込まれることで当初の未承認取引が無効となる可能性があります。
このことからゼロ承認取引を受け付けても良い相手は「そのトランザクションがもし決済されなかった場合、再び請求すれば払ってもらえる」という信用のある相手のみです。
ZERO-CONFチャネル
さて、ライトニングチャネルの開設もFunding Txというトランザクションを伴います。従来はすべてのライトニングチャネルについて開設に必要な承認数を一律に扱っていたノードがほとんどでしたが、今回はチャネル開設に必要な承認数minimum_depthを相手毎に設定するための変更が追加されました。
珍しい反例としては、ライトニングノード実装のEclairは従来より金額によって必要な承認数を調整しているようです。
https://github.com/.../eclair/channel/HelpersSpec.scala...