少し時間が空いたけど、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を計算することでこの問題を解決する。
修正されたプロトコルは以下のようになる。
- アリスとボブはP1, P2, R1 = gk1, R2 = gk2, m', について同意する。
- ボブはを計算し、k2の値を明らかにすることなくのゼロ知識証明と一緒にアリスに送る。アリスも同様にを計算し、k1の値を明らかにすることなくのゼロ知識証明と一緒にボブに送る。
- アリスはでRを計算し、ボブはでRを計算する。計算した同じ楕円曲線上の点Rのx座標をrとする。
- ボブはとを計算する。続いてボブはを計算する。このはPaillier暗号の加法準同型演算を表す。結果、となるc3をアリスに送る。
- アリスはc3を復号しs'を取得する。ここでアリスはボブが暗号化中に不正行為をしていないか確認する必要がある。これは、が成立するか検証すればいい。問題なければ、を計算しs''をボブに送る。
- 少ししてボブはペイメントパス上のキャロルから値αを得る(キャロルがボブからの送金と引き換えにαをボブに公開する)。ボブはを計算し、署名
(r, s)
を出力する。 - ボブが作成した署名が公開されると、アリスはを計算する。
という形で、ECDSAベースでもHTLCを利用した中間者決済をするScriptless Scriptが実装できると。
(ほとんどAdaptor Signatureのプロトコルと同じなのでサンプルコードは割愛)
タイムロックの取り扱い
Payment Channelを構成するもう1つの要素がタイムロックだが、こちらはおそらくScriptless Scriptとして実装するのは難しいので、スクリプトとは別にタイムロックを担保する仕組みが必要になるだろう。
ちなみに、MimbleWimbleの最小実装をするGrinではトランザクションのタイムロックを実現するのに以下のような変更を提案している。
https://github.com/mimblewimble/grin/blob/master/doc/contracts.md