Develop with pleasure!

福岡でCloudとかBlockchainとか。

Lightning Networkの新しいチャネルコントラクトの提案「Generalized Channels」

少し前に発表されたLightning Networkの改善提案のペーパー「Generalized Bitcoin-Compatible Channels」↓

https://eprint.iacr.org/2020/476.pdf

簡単に言うと↓の特性を持つ、現在のLightning NetworkのPoon-DryjaスタイルのPayment Channelの改良

  • 共通のコミットメントトランザクションを構成する。
    Poon-DryjaスタイルのPayment Channelでは、チャネル参加者が保持するコミットメントトランザクションは非対称なもので、それぞれ異なるコミットメントトランザクションを管理するが、Generalized Channelsでは、両者が保持するコミットメントトランザクショントランザクションは同じものになる。これには以下のようなメリットがある。
    • チャネル更新の通信量がより小さくなり、シンプルになる。
    • コミットメントトランザクションがブロードキャストされた場合のオンチェーンフットプリントも小さくなる。
  • 現時点でデプロイ可能である。
    Generalized ChannelsはECDSA + Adaptor Signatureで構成可能なので、現時点でもデプロイが可能である。

相手が古いチャネル状態を公開しようとした場合、チャネル資金が全額没収されるペナルティタイプのPayment Channelである点はPoon-DryjaスタイルのPayment Channelと同じだ。一方で、eltooのように共通のコミットメントトランザクションを構成するようになっている。ただ、eltooの場合、新しいSIGHASH_TYPEの導入が必要で、それにはBitcoinのソフトフォークが必要になるが、Generalized Channelsは、既存のプロトコルで利用可能だ。eltooについて知りたい場合は↓参照。

goblockchain.network

Poon-DryjaスタイルのPayment Channel

Payment Channelを構成する際に登場する主なトランザクションは以下の2種類。

  1. ファンディングトランザクション
    チャネルを構成する際に、チャネル参加者の2-of-2マルチシグアウトプットにコインをロックするためのトランザクションで、オンチェーントランザクション
  2. コミットメントトランザクション
    ファンディングトランザクションのアウトプットを使用するトランザクションで、オフチェーンで支払いをするたびに更新される。基本的にはオフチェーントランザクションだが、相手が応答しないなどでチャネルの協調クローズができない場合に、チェーン上にブロードキャストされる。

2のコミットメントトランザクションは(HTLCを除いた場合、)チャネル参加者のそれぞれの残高を持つ2つのアウトプットを持つ。そのうち自分の残高のアウトプットは以下の2つのいずれかの条件でアンロックされる。

  • タイムロック期間が過ぎれば自分で使用できる。
  • あるシークレット値(per_commitment_secret)を知っていれば相手が使用できる。

オフチェーン支払いをする場合、残高を更新した新しいコミットメントトランザクションを作成し、前のコミットメントトランザクションのシークレット(per_commitment_secret)をお互い相手に通知する。

Generalized Channels

↑の構成だと、参加者はそれぞれ異なるコミットメントトランザクションを持つが、Generalized Channelsでは、両者が同じコミットメントトランザクションを持つ。このコミットメントトランザクションが持つアウトプットは1つのみで、チャネルの資金を全て保持している。このコミットメントトランザクションはタイムロックの後、後続のスプリットトランザクションで使用でき、このスプリットトランザクションは参加者のその時点の残高をそれぞれ保持する複数のアウトプットを持つ。

f:id:techmedia-think:20200807212037p:plain
Generalized Channelsの構成

チャネルのセットアップ

アリスとボブがGeneralized Channelsをセットアップする手順は以下の通り。

アリスの鍵ペアを  {P_{A} = x_{A} G}、ボブの鍵ペアを {P_{B} = x_{B} G}とする。

  1. 両者は最初にファンディングトランザクションを作成する。このトランザクションは、これまでと同様、チャネル資金を {P_{A}, P_{B}}の2-of-2のマルチシグアウトプットにロックするオンチェーントランザクション
  2. 続いてチャネルの初期状態にコミットするコミットメントトランザクションを構成する。
    1. 両者は取り消し用の鍵ペアを作成し、その公開鍵を相手に伝える。
      • アリスは {R_{A} = r_{A} G}を計算し、 {R_{A}}をボブに伝える。
      • ボブは {R_{B} = r_{B} G}を計算し、 {R_{B}}をアリスに伝える。
    2. 両者は公開用の鍵ペアを作成し、その公開鍵を相手に伝える。
      • アリスは {Y_{A} = y_{A} G}を計算し、 {Y_{A}}をボブに伝える。
      • ボブは {Y_{B} = y_{B} G}を計算し、 {Y_{B}}をアリスに伝える。
    3. ファンディングトランザクションをマルチシグアウトプットを使用するコミットメントトランザクションを作成する。アウトプットは1つのみで、このアウトプットを使用できる条件は以下の3つのいずれか。
      • タイムロック期間Δが経過したら、公開鍵 {P_{A}} {P_{B}}に対して有効な署名があれば使用可能(後続のスプリットトランザクション用のアンロック条件)
      •  {r_{A}} {y_{A}}が分かれば、公開鍵 {P_{B}}に対して有効な署名があれば使用可能(アリスが不正をした場合のペナルティ用)。
      •  {r_{B}} {y_{B}}が分かれば、公開鍵 {P_{A}}に対して有効な署名があれば使用可能(ボブが不正をした場合のペナルティ用)。
  3. コミットメントトランザクションのアウトプットを使用するスプリットトランザクションを作成する。
    • このトランザクションは、アリスの残高とボブの残高をそれぞれに送金する2つのアウトプットを持つ(一方の残高が0であれば1つになる)。
    • コミットメントトランザクションのアンロック条件はタイムロック+公開鍵 {P_{A}} {P_{B}}に対して有効な署名。
  4. スプリットトランザクションに対して、アリスは {x_{A}}を使って、ボブは {x_{B}}を使って署名を計算し、お互い交換する。
  5. アリスとボブはコミットメントトランザクションについてAdaptor Signatureをそれぞれ作成し、交換する。
    • アリスは秘密鍵 {x_{A}}とボブから受け取った {Y_{B}}を使ってAdaptor Signatureを作成し、ボブに送信する。この署名を完成させるためにはボブは {y_{B}}を加算する必要がある。
    • ボブは秘密鍵 {x_{B}}とアリスから受け取った {Y_{A}}を使ってAdaptor Signatureを作成し、アリスに送信する。この署名を完成させるためにはアリスは {y_{A}}を加算する必要がある。
  6. 最後に両者はファンディングトランザクションに署名し、ブロックチェーンネットワークにブロードキャストする。

チャネルの更新

チャネルを更新する(オフチェーン支払いを行う)際の手順は、

  1. ↑のように新しいコミットメントトランザクションを作成する。それぞれYとRの鍵は新しく生成したものになる。
  2. さらに新しいコミットメントトランザクションのコインを使用するスプリットトランザクションを作成する。アウトプットはそれぞれ支払いにより更新した残高を持つ。
  3. ↑と同様スプリットトランザクションの署名と、コミットメントトランザクションのAdaptor Signautreを交換する。
  4. 最後に古いコミットメントトランザクションを無効にするため、両者ともに前のコミットメントトランザクションの取り消し用のシークレット {r_{A}, r_{B}}を交換する。

チャネルのクローズ

チャネルのクローズは、既存のPayment Channelの実装と同様、2つの方法がある。

  • 協調クローズ
    両者が協力し、ファンディングトランザクションのアウトプットをチャネルの最終残高に応じてそれぞれに分配するクロージングトランザクションを作成し、ブロードキャストする。
  • 一方的なクローズ
    最新のコミットメントトランザクションをブロードキャストする。この場合コミットメントトランザクションがブロックに格納されてから指定されたタイムロック期間経過すればそれぞれチャネルの最終残高が手に入る。

不正をした場合の動作

どちらかが古いコミットメントトランザクショントランザクションをブロードキャストした場合(アリスが不正したと仮定すると)、その状態の残高が配分されるスプリットトランザクションをブロードキャストできるようになるまでタイムロックが設定されているので、その間に不正をされたボブは、

  • チャネル更新時に交換したそのコミットメントトランザクションの取消用の鍵 {r_{A}}
  • アリスがブロードキャストしたコミットメントトランザクションと、事前に受け取ったAdaptor Signatureの差分を計算し {y_{A}}を入手する。

の2つのデータ( {r_{A}, y_{A}})と自身の {x_{B}}を使って、ブロードキャストされたコミットメントトランザクションのアウトプットの資金=チャネルの全資金を自身に送金するパニッシュメントトランザクションを作成しブロードキャストする。

ポイント

Generalized Channelsのポイントはコミットメントトランザクショントランザクションの構成方法で、このアウトプットの使用条件に

  • 取消用のシークレットを組み入れる
  • コミットメントトランザクションが公開された時に初めて明らかになるシークレットを組み入れる

この2つの条件を組み入れたことだろう。これにより

  • 単純に最新のコミットメントトランザクションをブロードキャストする分には、取消用のシークレットは交換されていない=相手のシークレットを知らない状態なので、コミットメントトランザクションのペナルティ条件は使えない。
  • 古いコミットメントトランザクションをブロードキャストする=自身のが不正した証拠( {y_{A} もしくは y_{B}})を提供することになり、それを使ってペナルティ条件が利用可能になる。

を実現できる。

Generalized Channelsだと、冒頭に書いたように既存のコミットメントトランザクションの複雑さとトランザクションサイズも削減されるし、ペナルティをトランザクションを発行する際のトランザクションサイズも削減できメリットは大きい。Bitcoinの次のソフトフォーク(Schnorr + Taproot)にはSIGHASH_NOINPUTは導入されないので、当分eltooも導入できないだろうし。

実装方法と今後

↑のコミットメントトランザクションのアウトプットのスクリプトを実装する方法はいくつかあるが、すぐにデプロイするのであればECDSAのAdaptor Signatureに限定される。この場合、Lindellの2P-ECDSAをスクリプトレスに行うことも考えられるけど、Paillier暗号などの追加の暗号仮定の導入とかを考慮すると、少し前に提案されたOP_CHECKMULTISIGを使ったAdaptor Signature↓が現実的だと思う。

techmedia-think.hatenablog.com

もちろんSchnorrベースのAdaptor Sinatureの方が効率的ではあるので、実際のデプロイはSchnorrのアクティベートを待つという選択肢もある。