Develop with pleasure!

福岡でCloudとかBlockchainとか。

中継者の協力なしにチャネルの更新を可能にするVirtual Channel

Payment Channel Bitcoin

これまで、Multi-Hop LocksやAtomic Multi-Channel Update、Anonymous Atomic Locksなど、多くのペイメントチャネル系の提案をしてきたPedro Moreno-Sanchezが新しいペーパー

Donner: UTXO-Based Virtual Channels Across Multiple Hops

を発表してたので、見てみる。

Virtual Channelとは？

LNのようなオフチェーンでマルチホップ支払いをするようなケースでは、支払いの都度、支払いの経路上にいる全参加者のチャネルの状態を更新する必要がある。これに対し、Virtual Channelは、ペイメントチャネル上に構築するチャネルで、一度チャネルを開くと、チャネルの更新はいつでも何度でも中継者が関与することなく、支払いのエンドポイント（送信者と受信者）のみで行うことができる。中継者の操作が必要になるのは、チャネルを開く時と閉じるときのみ。

ペイメントチャネル上に構築され、（協調クローズする限り）オンチェーン上にはチャネルのファンディング・トランザクションが登場しないことから、Virtual Channelと名付けられている。

このVirtual Channelのメリットは、

  • 支払い時に中継者はオンラインでなくも良い
  • 支払いのレイテンシーは、直接関係する送信者と受信者の間のみに低減される
  • 中継者への手数料は、チャネルのオープン/クローズ時のみで、各支払いでは手数料は発生しない。
  • 各支払いにおける支払金額を中継者が知ることはない。

同じ相手と何度も支払いをするようなユースケースにおいては、有用なソリューションになる。

Donner

Virtual Channel（VC）の提案は、もともとチューリング完全なコントラクトを記述可能なEthereum向けに提案されたPerunが最初。その後、UTXOベースのブロックチェーンでVCを構築するLightweight Virtual Payment Channelsが提案される。また、再帰的な構造を導入することで複数人の中継者（マルチホップ）にも対応している。ただ、このプロトコルには、強制クローズ攻撃やグリーフィング攻撃の可能性が考えられ、中継者の数に比例してトランザクション数やストレージスペースも増加する。

再帰構造をやめ、これらのLVPCの課題を解消するプロトコルとして提案されたのが、今回のペーパーのDonner。

VCの主な操作は、

  • VCのオープン
  • VCの更新
  • VCのクローズ
    VCの最終残高で、各参加者のペイメントチャネルの状態を更新することで、VCをクローズする。
  • VCのオフロード
    紛争時などでVCのファンディング・トランザクションをオンチェーンに公開することでVCを決済する。

またこのVCは、LNなどのペイメントチャネルと違い、 有効期間が定められ、それがVCのライフタイムとなる。

各操作について具体的にみていこう。

文字だけだと分かりづらいので、アリスがキャロルと経路アリス→ボブ→マイク→キャロルを使ってVCを構成するフローを図示してみた↓

f:id:techmedia-think:20210709164012p:plain
Donnerのトランザクションフロー

VCのオープン

送信者は、まずVCにロックするコインの量αとチャネルのライフタイムTを決定する。続いて送信者は、VCをオープンするためのファンディング・トランザクションTx VCを作成する。

  • Tx VC：
    • インプット：送信者の管理下にあるUTXO
      （オンチェーン/オフチェーンどちらのUTXOでもOK）
    • アウトプット：
      • αコインを保持し、アンロック条件は送信者と受信者のマルチシグ
      • 送信者から受信者までのパス内の中継者の数分（ホップ数）のアウトプット
        各アウトプットはεコインを保持し、ロックスクリプトは {中継者_iの署名 \land 相対的ロックタイム（t + Δ）}

VCのファンディング・トランザクションは、受信者を除くペイメントチャネルのパスの数分のアウトプットを持つのが特徴。εの量については小額でよく、ただトランザクション・ポリシーからdust以上でなければならないので、最低546 satoshi以上になる。

続いて、送信者と受信者は、Tx VCの先頭のアウトプット（VCの資金）をインプットとした、VCのコミットメント・トランザクションTx VC Commitmentを作成する。これがVCの状態を表すトランザクションになる。

  • Tx VC Commitment：
    • インプット：Tx VCのαコイン UTXO
    • アウトプット：
      • VC内の送信者の残高
      • VC内の受信者の残高

続いて、送信者は、VCを構築するためのパス上の中継者の内、自身の隣のユーザー {U_1}にTx VCを提示して、ペイメントチャネルの状態を更新する。つまりペイメントチャネルのコミットメント・トランザクションを更新する。このトランザクションをTx Stateとする。Tx Stateには（HTLCを除くと）両者の残高を表すアウトプットが２つあるので、その内の送信者の残高をαコイン減らし、αコイン保持するアウトプットを新しく追加する。

  • Tx State：
    • インプット：送信者と {U_1}のペイメントチャネルのUTXO
    • アウトプット：
      • {α_1}コイン。ロックスクリプトは、 {（U_1の署名 \land 絶対的タイムロック（T））\lor（送信者とU_1のマルチシグ \land 相対的タイムロック（Δ））}
      • ペイメントチャネル内の送信者の残高（金額は、送信者の残高 - {α_1}コイン）
      • ペイメントチャネル内の {U_1}の残高

ここで、 {α_1}コインは、VCのキャパシティαに加えて、中継者全員分の手数料を加算した金額（この金額は {U_1}から右のチャネルに行くにつれ、手数料分減っていく）。

続いて、VCにロックされるTx Stateの {α_1}コインのUTXOをインプットとした、取り消し用のトランザクションTx Refundと、支払いを行うTx Payトランザクションの２つのトランザクションを作成する。

  • Tx Refund：

    • インプット：
      • Tx VCの {U_1}用のεコイン
      • Tx StateのVC用のUTXO、 {α_1}コイン
        この時使用するアンロック条件は、 {送信者とU_1のマルチシグ \land 相対的タイムロック（Δ）}の方。
    • アウトプット：
      • インプットの {ε + α_1}コインを送信者に返金

  • Tx Pay：

    • インプット：Tx StateのVC用のUTXO、 {α_1}コイン
      この時使用するアンロック条件は、 {U_1の署名 \land 絶対的タイムロック（T）}の方。
    • アウトプット： {α_1}コインを {U_1}に送金

↑のTx Stateの更新と、Tx RefundとTx Payの作成をパス上の各チャネルで行っていき、受信者まで続ける。最終的に受信者まで更新が終わり、Tx VCを送信者に送りもどし、それが最初に送信者が {U_1}に送ったものと同じであればVCはオープンする。

チャネルの担保

ここで、送信者はチャネルのキャパシティαをTx VCとTx State（こちらは実際に手数料が加算されている）で提供していることが分かる。実際のチャネルキャパシティは、Tx VCの方だが、Tx Stateにはそれと同額が担保としてロックされている状態になっている。

この担保は、Tx RefundおよびTx Payの原資になっており、

  • 送信者がVCのライフタイムTより前にVCを閉じるかオフロードすれば、Tx Refundにより担保は送信者に戻る。
  • 送信者が何もしなければ、Tを過ぎると担保された資金は全額チャネルを左から右に流れ、最終的に受信者がその担保を得る。

VC上の支払い

VCはTx VCによりファンディングされ、VCの実態はTx VC Commitmentであるため、送信者と受信者は、これを両者で更新することで、パス上の中継者を関与させることなく、VCの資金を使って送金のやりとりが可能になる。

Tx VC Commitmentは、両者の残高をそれぞれ表す２つのアウトプットを持ち、そのロックスクリプトは通常のペイメントチャネルと同様のものだと思われる。

VCの更新

VCのライフタイムの更新をする場合は、パス上でTx Stateを更新していくことでVC自体の更新も可能。

VCのクローズ

VCをクローズする場合、受信者が、パス上の右隣のユーザーとTx Stateの更新を開始する。この時、VC用のUTXOのコインの量は、VC内の送信者の最終残高（実際には手数料が加味）になる。この更新を送信者まで続ける。

送信者は更新した残高がVCの残高と等しいことを確認する。VCをそのまま閉じる場合は、Tx Stateを更新し、VC用の残高を送信者側のアウトプットにマージする。つまりペイメントチャネル上でVCを決済する。この場合、VCに関連するオフチェーントランザクションはオンチェーンに現れることはなく、オンチェーン手数料という意味でも最も効率的。

VCのオフロード

もし、受信者が更新してきた残高が不正な場合など、紛争が発生した場合は、送信者はTx VCをオンチェーンで公開しVCをオフロードする。

VCがオフロードされると、VCを利用していた両者は、VCの正しい残高を確定することになり（最新のTx VC Commitmentを適用する）、かつ送信者はTx Refundで担保を回収することができる。また、パス上の中継者は、Tx VCがオンチェーン上に公開されるか監視する必要がある。Tより前にオンチェーン上に公開されている場合、各自Tx Refundを請求する必要がある。

送信者は、VCのライフタイムTまでにVCをクローズするかオフロードしないと担保を失うので、VCを閉じるインセンティブは送信者にある。

Donnerのポイントは、

ところかと思う。この担保と返金のトリガーにより、マルチホップなVCを機能させている。

ステルスアドレスの利用

VCのファンディング・トランザクションTx VCには、各中継者が使用するUTXOが含まれるが、中継者の公開鍵の情報からパスの情報が明らかにならないよう、これらの中継用のアウトプットの生成にはステルスアドレスが用いられる。