Develop with pleasure!

福岡でCloudとかBlockchainとか。

ECDSAベースのScriptless Lightning Network

少し時間が空いたけど、Scriptless Scripts with ECDSAのホワイトペーパーについて

techmedia-think.hatenablog.com

techmedia-think.hatenablog.com

と見てきたので、最後のLightning Networkへの適用について見てみる。

Lightning NetworkのベースとなるのはPayment Channelで、このPayment ChannelはBitcoinスクリプトで

  • タイムロック
  • ハッシュプリイメージのチャレンジ

を組み合わせて実装されているコントラクトだ。

↑のホワイトペーパーでは、LNの後者のハッシュプリイメージのチャレンジをマルチホップを意識してECDSAでスクリプトレスに実装するプロトコルについて説明している。基本的なハッシュプリイメージのチャレンジは↑のAdaptor Signatureのプロトコルでも利用されているが、第三者を経由するマルチホップ決済をするため、このプロトコルとは若干異なったものになる。

Scriptless Lightning Network with ECDSA

三者を経由した決済をするHTLCを考える。この基本的な動作は↓

techmedia-think.hatenablog.com

ここでアリスがボブを経由してキャロルに送金する場合、キャロルが作成したシークレットを使ってトラストレスに三者間の決済が行われる。

(タイムロックの部分は置いといて)このハッシュプリイメージのチャレンジを3者間で行うのを、Scriptless Scriptでどう実現するかというのが課題になる。

ベースは↑のAdaptor Signatureのプロトコルで、シークレットαの取り扱いだけ変更する必要がある。Adaptor Signatureではシークレットαの値をボブが生成していたけど、これを生成するのがキャロルになり、アリスとボブは最初αの値を知らない。

アリスとボブの両者がαの値について知らない場合、Adaptor Signatureのプロトコルの手順3でRを計算できないという問題が出てくる。この問題を解決すれば残りのプロトコルはそのままで良い。

解決策を簡単に言うと、αを生成したキャロルは、楕円曲線上の点(=公開鍵) A = gαをアリスとボブに公開して、そのAを使ってRを計算することでこの問題を解決する。

修正されたプロトコルは以下のようになる。

  1. アリスとボブはP1, P2, R1 = gk1, R2 = gk2, m',  {Q = g^{x1 \cdot x2}}について同意する。
  2. ボブは {R3 := (A)^{k2}}を計算し、k2の値を明らかにすることなく {R2 = g^{k2} \land R3 = (A)^{k2} }のゼロ知識証明と一緒にアリスに送る。アリスも同様に {R'3 := (g^{α})^{k1}}を計算し、k1の値を明らかにすることなく {R1 = g^{k1} \land R'3 = (g^{α})^{k1} }のゼロ知識証明と一緒にボブに送る。
  3. アリスは {R \gets (R3)^{k1}}でRを計算し、ボブは {R \gets (R'3)^{k2}}でRを計算する。計算した同じ楕円曲線上の点Rのx座標をrとする。
  4. ボブは {c1 \gets Enc_{pkA}((k2)^{-1} \cdot m' + pq)} {c2 \gets (ckey) \odot (x2 \cdot r \cdot (k2)^{-1})}を計算する。続いてボブは {c_3 = c_1 \oplus c_2}を計算する。この {\oplus}はPaillier暗号の加法準同型演算を表す。結果、 {c3 = EncpkA((k2)^{-1} \cdot m' + pq + x1 \cdot x2 \cdot r \cdot (k2)^{-1})}となるc3をアリスに送る。
  5. アリスはc3を復号しs'を取得する。ここでアリスはボブが暗号化中に不正行為をしていないか確認する必要がある。これは、 {(R_2)^{s' mod q} = Q^{r} \cdot g^{m'}}が成立するか検証すればいい。問題なければ、 {s'' \gets s' \cdot (k1)^{-1}}を計算しs''をボブに送る。
  6. 少ししてボブはペイメントパス上のキャロルから値αを得る(キャロルがボブからの送金と引き換えにαをボブに公開する)。ボブは {s \gets (α)^{-1} \cdot s''}を計算し、署名(r, s)を出力する。
  7. ボブが作成した署名が公開されると、アリスは {α \gets (s \cdot (s'')^{-1})^{-1}}を計算する。

という形で、ECDSAベースでもHTLCを利用した中間者決済をするScriptless Scriptが実装できると。
(ほとんどAdaptor Signatureのプロトコルと同じなのでサンプルコードは割愛)

タイムロックの取り扱い

Payment Channelを構成するもう1つの要素がタイムロックだが、こちらはおそらくScriptless Scriptとして実装するのは難しいので、スクリプトとは別にタイムロックを担保する仕組みが必要になるだろう。

ちなみに、MimbleWimbleの最小実装をするGrinではトランザクションのタイムロックを実現するのに以下のような変更を提案している。

https://github.com/mimblewimble/grin/blob/master/doc/contracts.md

  • 署名対象のメッセージMについて、そのトランザクションが使用可能になるブロック高をhとし手数料と結合してM = fee | hとする。
  • ロックするブロック高はトランザクションカーネルに含まれる。
  • 現在のブロック高より大きいブロック高が設定されているカーネルを含むブロックはリジェクトされる。