Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Multi-Hop Locks

Multi-Hop Locks

暗号通貨輪読会#23

論文「Multi-Hop Locks for Secure, Privacy-Preserving and Interoperable Payment-Channel Networks」の技術的内容の説明用スライドです。

shigeyuki azuchi

October 10, 2018
Tweet

More Decks by shigeyuki azuchi

Other Decks in Technology

Transcript

  1. Copyright ©2018 chaintope, Inc. all rights reserved. 自己紹介 • Shigeyuki

    Azuchi • 株式会社chaintope CTO • BitcoinプロトコルのRuby実装「bitcoinrb」 • Open Assets ProtocolのRuby実装 「openassets-ruby」 • 共著 「ブロックチェーン・プログラミング 仮想通貨入門」 • ブログ「Develop with pleasure!」 https://techmedia-think.hatenablog.com/
  2. Copyright ©2018 chaintope, Inc. all rights reserved. HTLCを使った第三者経由の支払い Secret C

    H(C) アリスが作るHTLC Tx Outputs 1 BTCは以下のいずれかで入手可能 •Secret Cがあればボブの鍵で入手可能 •14日経過したらアリスの鍵で入手可能 Inputs アリスの 1 BTC ボブが作るHTLC Tx Outputs 1 BTCは以下のいずれかで入手可能 •Secret Cがあればキャロルの鍵で入手可能 •10日経過したらボブの鍵で入手可能 Inputs ボブの 1 BTC ① キャロルがランダムなシークレットCを生成しそのハッシュをアリスに共有する。 ②アリスはH(C)を使ってボブに条件付きで コインを支払うTxをブロードキャストする。 ③ボブはH(C)を使ってキャロルに条件付きで コインを支払うTxをブロードキャストする。
  3. Copyright ©2018 chaintope, Inc. all rights reserved. HTLCを使った第三者経由の支払い ③ キャロルはボブがブロードキャストした

    HTLC Txをインプットにし、シークレット Cと  自分の署名でボブのコインを入手する Txを作成しブロードキャストする。 キャロルが作る償還 Tx Outputs キャロルのアドレスへ 1 BTC Inputs ボブのHTLC TxのUTXO 1BTCを Secret Cとキャロルの署名で入手 ボブが作る償還 Tx Outputs ボブのアドレスへ 1 BTC Inputs アリスのHTLC TxのUTXO 1BTCを Secret Cとボブの署名で入手 Secret C Secret C ④ ボブはキャロルがブロードキャストした TxからシークレットCが  分かるので、これを使ってアリスの HTLC Txのコインを入手する。
  4. Copyright ©2018 chaintope, Inc. all rights reserved. HTLCを使った第三者経由の支払い • キャロルが1

    BTCを受け取らないとシークレットCは明らかにならない。 • シークレットCが明らかになれば、ボブはアリスから1 BTCもらえる。 • キャロルがシークレットCを明らかにせず、1 BTCを受け取らなかったら、 ボブは10日待てば自分のコインを取り戻せる。アリスも14日待てば取り戻せる。 • アリス(14日) > ボブ(10日)のタイムロックの関係で、ボブがキャロルにコインを 支払ったが、アリスからコインをもらえないという状況が発生しない仕組みを実現。 OP_CHECKLOCKTIMEVERIFY(OP_CLTV)は このアウトプットのコインを指定時間( block height or unix timestamp)までロックするタイムロックの仕組 み。 OP_HASH160 <H(Secret C)> OP_EQUAL OP_IF <ボブの公開鍵> OP_ELSE <ロック日時> OP_CLTV OP_DROP <アリスの公開鍵 > OP_ENDIF OP_CHECKSIG
  5. Copyright ©2018 chaintope, Inc. all rights reserved. 現在のPCNのマルチホップ決済 HTLC(Hashed Time-Locked

    Contracts) ハッシュのプリイメージの交換とタイムロックを利用して、第三 者を経由したトラストレスな決済をサポートするコントラクト
  6. Copyright ©2018 chaintope, Inc. all rights reserved. Payment Channel Networkの課題

    • Wormhole Attack • Privacy 同一経路に同じユーザーのチャネルが存在することで、 ハッシュ値から、支払い情報の推測が可能になる。 Secret C H(C) ① キャロルがランダムなシークレットCを生成しそのハッシュをアリスに共有する。 ②決済経路を確定し、HTLCを構築する。 ③キャロルはCを明らかにし1 BTCを入手。 ④ 悪意あるユーザーは、 ボブに決済が失敗したと伝える ⑤ 悪意あるユーザーはキャロルから入手したCを 使ってアリスから1.3 BTCを受け取る ユーザーのコインが失われることは無いが、中間ユーザーの手数料 分、悪意あるユーザーが0.3 BTCの手数料を手にする。
  7. Copyright ©2018 chaintope, Inc. all rights reserved. Multi-Hop Locks LNのマルチホップ決済のロック機構を一般化した

    暗号プリミティブで、以下のアルゴリズムで構成される 1. KGen チャネルを構成する2者間の秘密鍵と両者の共有公開鍵を生成するプロトコ ル。 2. Setup 決済経路を決め、各中間者に(ロックフェーズで使用する)状態siを最後のユー ザーにのみ鍵kを与えるプロトコル。 3. Lock 隣り合う2者が、それぞれ持つ状態siと秘密鍵、共有公開鍵から、ロックLiを作 成するプロトコル。ロックはUi+1がある暗号条件を解くとUiがコインを送るという 条件で構成される。 4. Release ロックを解放するプロトコルで、オープン鍵と状態のセットから、 新しいオープン鍵を返す。 5. Verify オープン鍵とロックから、ロックをアンロックできるか検証するプロトコル。
  8. Copyright ©2018 chaintope, Inc. all rights reserved. キーアイディア ① アリスはキャロルまでの経路を決め、セットアッププロトコルを実行。

    セットアッププロトコルにより中継者(ボブ、マイク)は初期状態 siを受け取る。 送金先のキャロルにはオープン鍵 k3を送る。 ② 各中継者(ボブ、マイク)はチャネルの接続相手とロックプロトコルを実行し、 ロックを作成する。このロックは右側のユーザーがロックを解除すると、 左側のユーザーが次のロックを解除できる仕組みになっている。 ③ キャロルはリリースプロトコルを実行し、資金を入手する。 キャロル<->マイク間のロックが解除されると、マイク <->ボブ間、 ボブ<->アリス間の順にロックが解除でき、それぞれ資金を入手できる。
  9. Copyright ©2018 chaintope, Inc. all rights reserved. 3種類の構成方法 • 一般的な構成(一方向準同型関数)

    • Schnorrを利用したScriptless Script構成 • ECDSAを利用したScriptless Script構成
  10. Copyright ©2018 chaintope, Inc. all rights reserved. 一般的な構成 一方向準同型関数 g:

    D → R ランダムな要素x∈Rが与えられた際、g(y) = xとなるような y∈Dを見つけるのが困難な関数で、かつ、(a, b)のペアに対し て g(a ◦ b) = g(a) ◦ g(b) が成立するような準同型性を持つ関数。 ※ 一方向準同型関数を利用した一般的な構成の場合、 そのような関数を実装したBitcoinのopcodeは存在しないた め、想定されるチェーンは任意のコントラクトを記述可能な EthereumやHyperledgerなど。
  11. Copyright ©2018 chaintope, Inc. all rights reserved. 送信者は、LNの支払いの受信者までの経路(n人)を確定し、n個分ランダムな値を サンプリングする(y0, y1,...,yn-1)。

    送信者は、受信者までの各中間者に以下の3つのアイテム を送る。 受信者にのみオープン鍵             を送る。 一般的な構成:Setup
  12. Copyright ©2018 chaintope, Inc. all rights reserved. 一般的な構成:Lock 経路上の各チャネルのユーザーは、送信者から受け取ったデータを使って、 ロックスクリプトを構成する。

    隣り合う両者は共通の一方向準同型関数の出力値を持っているので、 そのプリイメージの数値が明らかになればコインをアンロックできる条件の スクリプトを構成する。 ボブ<->キャロルはy0+y1の値が分かれば、 ボブ→キャロルにコインが支払われる。 アリス<->ボブはy0の値が分かれば、 アリス→ボブにコインが支払われる。 アンロックに使われるプリイメージが経路上のチャネル毎に異なるのが特徴
  13. Copyright ©2018 chaintope, Inc. all rights reserved. 一般的な構成:Release & Verify

    受信者が、Setupフェーズで送信者から送られた3つめのアイテムとオープン鍵を 使って、コインのアンロックに必要な鍵を計算する。 キャロルは、オープン鍵 kから y2を引くとg(y0 + y1)の プリイメージが分かる。 ボブはキャロルから k1を明かされると、 そこからy1を引くとg(y0)の プリイメージが分かる。 左側(受信者)から順にアンロックに使われたデータが 次のロックのオープン鍵を導出するのに使われる。
  14. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成 【Schnorr署名】 •

    楕円曲線のジェネレータ: G • 秘密鍵: x • 公開鍵: P = xG • ハッシュ関数: H() • メッセージ: m 【署名の生成】 1. ランダムなnonce k を選択 2. kを秘密鍵として楕円曲線上の点 R = kGを計算 3. s = k + H(P, R, m)x を計算 4. (R, s)が署名データ 【署名の検証】 sG = R + H(P, R, m)P が成立するか検証 一方向準同型関数を 楕円曲線上の 離散対数に置き換え
  15. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成:KeyGen ユーザーUiとUjはそれぞれ鍵ペア Pi

    = xiG、Pj = xjGを持ち、二者間の共有公開 鍵 P = (xi + xj)Gを共有する。Pに対して有効なSchnorr署名を生成するためには 2人の秘密鍵(xi + xj)の情報が必要 = 2-of-2のマルチシグと同等 • 鍵ペア P1 = x1G • nonce R1 = k1G • 鍵ペア P2 = x2G • nonce R2 = k2G マルチシグの公開鍵 P = P1 + P2 にコインをロック ※Pに対応する秘密鍵は誰も知らない Pにロックされたコインをアンロックする際の署名 (署名に使用する R = R1 + R2) ① s1 = k1 + H(P, R, m)x1 を計算 ① s2 = k2 + H(P, R, m)x2 を計算 ② s = s1 + s2 = k1 + k2 + H(P, R, m)(x1 + x2)を計算 署名データは(R, s) ※ 署名は各ユーザーが計算した各 s値の加算することで計算できる ③ sG = R + H(P, R, m)P を検証
  16. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成:Setup 送信者は、LNの支払いの受信者までの経路(n人)を確定し、n個分ランダムな値 を

    サンプリングする(y0, y1,...,yn-1)。 サンプリングしたn個の値について Yi = Yi-1 + yiG を計算する。 (e.g Y0 = y0G, Y1 = Y0 + y1G, Y2 = Y1 + y2G) 送信者は、受信者までの各中間者に以下の3つのアイテム(Yi-1, Yi, yi)を送る。 受信者にのみオープン鍵             を送る。
  17. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成:Lock 経路上の各チャネルのユーザーは、送信者から受け取ったデータを使って、 ロックスクリプトを構成する。

    • nonceの計算 両者はそれぞれランダムなnonce ki, ki+1を選択し、Ri = kiG, Ri+1 = ki+1 Gを計算・共有し、共通の点 R = Ri + Ri+1 + Yi を計算する。 ※ RにYiを加算しているのがポイント • Yiを無視して、署名データを計算 ◦ Uiは、 si = ki + H(P, R, m)xi を計算 ◦ Ui+1は、 si+1 = ki+1 + H(P, R, m)xi+1 を計算 ◦ 両者のsの値から s’ = si + si+1 = ki + ki+1 + H(P, r, m)(xi + xi+1) を計算 ※ Rに対応した署名にするためにはYiの離散対数の情報が必要
  18. Copyright ©2018 chaintope, Inc. all rights reserved. 各中間者は、受信者(右側)にコインを送金するトランザクションを作成し、 送信者から配布されたYiをその署名作成時のnonceの値の計算に組み込む。 受信者がコインを受け取るためにはYiの離散対数を明らかにする必要がある。

    Schnorrを利用したScriptlessな構成:Lock ボブ<->キャロルはY1の離散対数の値が分かれば、 ボブ→キャロルにコインが支払われる。 アリス<->ボブはY0の離散対数の値が分かれば、 アリス→ボブにコインが支払われる。 アンロックに使われる離散対数は経路上のチャネル毎に異なる
  19. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成:Release 受信者が、Setupフェーズで送信者から送られた3つめのアイテムとオープン鍵を 使って、コインのアンロックに必要な鍵を計算する。

    キャロルは、オープン鍵 kからy2を 引くとY1の離散対数が分かる。 ボブはキャロルから k1を明かされると、 そこからy1を引くとY0の離散対数が分かる ※ 途中でキャロルがボブにY1の離散対数を明らかにせずTxをブロードキャストしても、 ボブはブロードキャストされたTxの署名sを使ってY0の離散対数を計算できる(s - s1)。
  20. Copyright ©2018 chaintope, Inc. all rights reserved. ECDSAを利用したScriptlessな構成 【ECDSA】 •

    秘密鍵: x • 公開鍵: P = xG • メッセージ: m • ハッシュ関数: H() 【署名の生成】 1. ランダムなnonce k を選択。 2. kを秘密鍵とした楕円曲線上の点 R = kGを計算。 3. 点Rのx座標をrとする。 4.            を計算 5. 生成した (r, s)がECDSAの署名データ。 【署名の検証】
  21. Copyright ©2018 chaintope, Inc. all rights reserved. ECDSAを利用したScriptlessな構成:KeyGen ユーザーUiとUjはそれぞれ鍵ペア Pi

    = xiG、Pj = xjGを持ち、二者間の共有公開 鍵 P = (xi ・ xj)Gを共有する。Pに対して有効なECDSA署名を生成するためには2 人の秘密鍵(xi ・ xj)の情報が必要 = 2-of-2のマルチシグと同等。 鍵ペア P1 = x1G nonce R1 = k1G Pにロックされたコインをアンロックするすためには が計算できればいい 鍵ペア P2 = x2G nonce R2 = k2G P1, R1, P2, R2を共有 P = x1 ・ P2 を計算 R = k1 ・R2 を計算 P = x2 ・ P1 を計算 R = k2 ・R1 を計算 計算した点Pと点Rはそれぞれ同じ点になる P宛にコインを送金するとマルチシグへのロックとなる
  22. Copyright ©2018 chaintope, Inc. all rights reserved. Lindellの2-Party ECDSA Signing

    署名(r, s)の内、秘密鍵を使った計算をするのはsの計算↓ 秘密鍵xを2者の秘密鍵から計算する値にすると、署名は 単一だが、有効な署名を生成するためには2者の秘密鍵を 必要とするマルチシグを構成することができる。 x = アリスの秘密鍵 × ボブの秘密鍵 ※両者がお互い自分の秘密鍵を明らかにすることなく sを計算できる必要がある
  23. Copyright ©2018 chaintope, Inc. all rights reserved. Lindellの2-Party ECDSA Signing

    ①アリスは、Paillier暗号用の鍵ペアを生成( priv, pub)  ※Paillier暗号は加法準同型性がある暗号スキーム ②pubを使ってアリスの秘密鍵 x1を暗号化Enc(x1)し、 pubと一緒にボブに送信 Enc(x1) pub ③ ボブは、以下の計算をして pubで暗号化  Enx(x1)を使って以下を計算    c3 = c1⊕c2を計算して、アリスに送る。 ④ アリスはc3を復号して s’ を計算 ⑤ s’をk1^-1 するとアンロックに必要な署名値 s が手に入る 両者ともに秘密鍵 x1, x2を明らかにすることなく、 マルチシグのアンロックに必要な署名値を計算できる。 1
  24. Copyright ©2018 chaintope, Inc. all rights reserved. ECDSAを利用したScriptlessな構成:Setup 送信者は、LNの支払いの受信者までの経路(n人)を確定し、n個分ランダムな値 を

    サンプリングする(y0, y1,...,yn-1)。 サンプリングしたn個の値について Yi = Yi-1 + yiG を計算する。 (e.g Y0 = y0G, Y1 = Y0 + y1G, Y2 = Y1 + y2G) 送信者は、受信者までの各中間者に以下の3つのアイテム(Yi-1, Yi, yi)を送る。 受信者にのみオープン鍵             を送る。 Setupプロトコルは基本的に Schnorrの場合と同じ
  25. Copyright ©2018 chaintope, Inc. all rights reserved. ECDSAを利用したScriptlessな構成:Lock 経路上の各チャネルのユーザーは、送信者から受け取ったデータを使って、 ロックスクリプトを構成する。

    • nonceの計算 両者はそれぞれランダムなnonce ki, ki+1を選択し、Ri = kiG, Ri+1 = ki+1 Gを計算・共有し、共通の点 R = (ki ・ ki+1)Yiを計算する。 ※ 両者のnonceをGでなくYiに乗算してるのがポイント • Yiを無視して、Lindellのプロトコルで署名データs’を計算 rはYiを加味したRのx座標。Yiの離散対数であるyiを使って、 s’ ・ yi^-1を計算すると有効な署名になる。
  26. Copyright ©2018 chaintope, Inc. all rights reserved. ECDSAを利用したScriptlessな構成:Lock 各中間者は、受信者(右側)にコインを送金するトランザクションを作成し、 送信者から配布されたYiをその署名作成時のnonceの値の計算に組み込む。

    受信者がコインを受け取るためにはYiの離散対数を明らかにする必要がある。 ボブ<->キャロルはY1の離散対数の値が分かれ ば、 ボブ→キャロルにコインが支払われる。 アリス<->ボブはY0の離散対数の値が分かれば、 アリス→ボブにコインが支払われる。 アンロックに使われる離散対数は経路上のチャネル毎に異なる
  27. Copyright ©2018 chaintope, Inc. all rights reserved. Schnorrを利用したScriptlessな構成:Release 受信者が、Setupフェーズで送信者から送られた3つめのアイテムとオープン鍵を 使って、コインのアンロックに必要な鍵を計算する。

    キャロルは、オープン鍵 kからy2を 引くとY1の離散対数が分かる。 ボブはキャロルから k1を明かされると、 そこからy1を引くとY0の離散対数が分かる ※ 途中でキャロルがボブにY1の離散対数を明らかにせずTxをブロードキャストしても、 ボブはブロードキャストされたTxの署名sを使ってY0の離散対数を計算できる(s・s1^-1)。
  28. Copyright ©2018 chaintope, Inc. all rights reserved. References • White

    paper ◦ https://eprint.iacr.org/2018/472.pdf • BINARY DISTRICT ◦ https://www.youtube.com/watch?v=VmnVyrz2izg&feature=youtu.b e&t=215 • Scaling Bitcoin ◦ https://youtu.be/3mJURLD2XS8?t=1720 ◦ http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/multi-ho p-locks/ • 日本語解説 ◦ https://techmedia-think.hatenablog.com/entry/2018/08/01/144307 ◦ https://techmedia-think.hatenablog.com/entry/2018/09/03/140403 ◦ https://techmedia-think.hatenablog.com/entry/2018/09/04/084733