Develop with pleasure!

福岡でCloudとかBlockchainとか。

TumbleBitに代わる新しいPayment Channel Hubプロトコル「Anonymous Atomic Locks」

Bitcoin Scaling Bitcoin Payment Channel Cryptography

Scaling Bitcoin 2019復習シリーズ第二弾は、Payment Channelの最近の研究といえばこの人、Pedro Moreno-Sanchezの「A2L: Anonymous Atomic Locks for Scalability and Interoperability in Payment Channel Hubs」

BitcoinのScalingソリューションとしてはペイメントチャネル技術にHTLCベースのマルチホップ決済を組み合わせたLightning Networkが有名だが、ベースとなるペイメントチャネル技術はLN固有の技術ではない。LNに可変サイズのマルチホップ決済はサポートしないが、誰かがハブ（タンブラー）となることでユーザー間のオフチェーン決済をサポートするPayment Channel Hubというコンセプトもある。Lightning Networkに比べてネットワーク情報を維持するコストは無いが、反面Hubという集中化モデルになる。

また、Lightning Networkはオニオンルーティングにより支払い経路の中継者は前後のノード情報しか分からないため、実際の支払い経路がA→B→Cという経路であったとしてもBからはAが実際の送信元で、Cが実際の受信者であるか知ることはない。反面Hub型のモデルはハブとなるBがAとCがそれぞれ送信元、受信者であることが分かるので、これを秘匿するための別の仕組みが必要になる。Payment Channel Hub（PCH）には以下の特性が求められる。

  • アトミック性
    A→B→Cの決済において、A→Bの支払いが行われた場合からなずB→Cの支払いも行われることが保証されること。
  • リンク不可能性
    A→B→Cの決済において、Aの送金先がCであることをBがリンクできないことが保証されること。
  • 値のプライバシー
    送金額のプライバシーが保証されること。
  • Fungibility
    各コインはそれぞれ区別されるべきではなく、PCHのタンブラーを使用したことが（スクリプトなどから）分からないことが保証されること。
  • インターオペラビリティ
    タンブラーを介して異なる暗号通貨で送金ができること。A→BはBTC、B→CはEtherのような。

PCHの提案としては、これらの要素を全て満たすような技術は現状存在しない。１番有力なPCHの実装はTumbleBitだが、コインがHTLCをサポートするコインに限定されるという意味でインターオペラビリティが限定的で、TunbleBitを利用したことがトランザクションからわかることからFungibilityにも課題が残る（Fungibilityに関してはTaprootの技術なんかと組み合わせると影響は限定できると思う）。

今回の提案では、上記の特性をできるだけカバーする新しいPCHのプロトコルAnonymous Atomic Locks（A2L）が提案されている。

Anonymous Atomic Locks（A2L）

A2LプロトコルはTumbleBitに結構似ていて、Promise（ロック）フェーズとPayment（リリース）フェーズの２つのフェーズで構成される。

Adaptor Signatureの利用

A2LではHTLCに依存しないよう、暗号チャレンジの入手とコインの引き換えはAdaptor Signature*1を使いスクリプトレスに実現するようになっている。Adaptor Signatureを利用したA→タンブラー→Bの基本的な支払いは流れは：

  1. タンブラーがまずシークレットskを生成する。
  2. アリスとタンブラー、タンブラーとボブの間でskの値が分かれば完全な署名が完成する＝skを除外しないと正しい署名にならないHalf-signatureを作成する2P-Adaptorロックを完成させる。この時、2つのAdaptor Signatureには同じskの情報が使われ、これによりアトミック性が保証される。
  3. アリスとタンブラーの支払いが行われれば、その署名値からskを計算し、タンブラーからボブの署名を完成させることができる。

2つのAdaptor Signatureを利用することで、支払いのアトミック性が得られるが、課題になるのはタンブラーによるリンク不可能性だ。このリンク不可能性を保証するため、アリスとボブはそれぞれ秘匿されているskのデータをランダム値を使ってマスキングする。

プロトコルの概要

具体的にどのようにランダム性を利用しているのかプロトコルについて見てみよう。A2LプロトコルはSchnorr署名を利用する構成と、ECDSA署名を利用する2つの構成が提案されている。

Schnorr署名を利用した構成

署名データに線形特性のあるSchnorr署名の方が構成としてはシンプルになる。A→タンブラー→Bの支払いを行うステップは以下のようになる（アリスとタンブラー、ボブとタンブラーは既にそれぞれPayment Channelを開いていると仮定する）。

Promiseフェーズ

まず最初に暗号チャレンジの解（↓の手順でタンブラーが生成するランダム値α）と交換にタンブラーはボブにコインを支払う（αが分かればボブはこの送金Txの署名を完成させられる）Promiseフェーズを実行する。

  1. アリスとタンブラー、タンブラーとボブの間で共有公開鍵をそれぞれセットアップする。ボブとタンブラー間についてはボブの秘密鍵を {sk_b}、タンブラーの秘密鍵を {sk_{t1}}とすると共有公開鍵は {pk_{bt} = (sk_b + sk_{t1})G}。タンブラーとアリス間についてはタンブラーの秘密鍵を {sk_{t2}}とし、アリスの秘密鍵を {sk_a}、共有公開鍵は {pk_{at} = (sk_a + sk_{t2})G}。(このセットアップには分散鍵生成プロトコルを使用する)
  2. 続いてタンブラーは、ボブとのペイメントチャネルを新しい状態に更新する（ボブに資金を送金する）ため、新しいコミットメントトランザクションを作成し、内容についてボブと同意する。トランザクションに同意するだけで、この時点では未署名。
  3. タンブラーはランダムな値αを選択し、Paillier暗号で暗号化する（暗号化に使用するのはタンブラーのPaillier暗号用の公開鍵）cα = {Enc(pk_T, α)}。このcαとA = αGをボブに送信する。※ 正確にはAが秘密の値αを使って生成されたことであるゼロ知識証明も一緒に送信され、ボブにより検証される。
  4. 続いてタンブラーとボブはコイントスプロトコルを実行して、 {R' = k'_1G + k'_2G + A}に同意する。R'はタンブラーが持つ秘密の値 {(α, k'_2)}とボブが持つ {k'_1}の値を使って構成されるが、それぞれ相手の秘密の値は知らない。
  5. 続いてタンブラーは、2で作成したコミットメントTxのタンブラー側の署名をR'を使って計算する。コミットメントTxから生成するSchnorr署名にしようするハッシュ値をe'とする。ただし、この時αを含めない。そのため計算した値は {k'_2 + e' \cdot x_2}となる。これをボブに送る。
  6. ボブは送られた値に対して、自身の持つ値を使って {s' = k'_1 + k'_2 + e \cdot (sk_{t1} + sk_b)}を計算する。署名値は（R', s'）となるがこれはまだ不完全で、完全に有効な署名にするためには（R', s' + α）を算出する必要があるが、この段階ではボブはαを知らないので署名を完成させることはできない。
  7. 続いてボブは、ランダムな値βを選択する。3でタンブラーから受け取った暗号化されたcαおよびタンブラーの公開鍵 {pk_T}を使い、 {c'α = cα \cdot Enc(pk_T, β) = Enc(pk_T, α + β)} *2 および {A' = A + βG = (α + β)G}を計算しランダム化する。
  8. 最後にランダム化した値をアリスの送信する。

以上がPromise（ロック）フェーズで、図にまとめると↓な感じ。

f:id:techmedia-think:20191007170526j:plain
A2L-Promiseフェーズ

Paymentフェーズ

続いて、アリスとタンブラー間で、ボブから受け取ったランダム化された値を使ってアリスがタンブラーから秘密の値αの解をボブにしか分からない形で購入する。

  1. アリスはまずランダムな値τを選択し、ボブから受け取ったランダム化された値を再度ランダム化し、 {c''α = c'α \cdot Enc(pk_t, τ) = Enc(pk_t, α + β + τ)}およびA'' = A' + τG = (α + β + τ)Gを得る。
  2. アリスとタンブラーはPromiseプロトコルで行われたようにコイントスプロトコルを実行し、 {R'' = k'_3G(= R_a) + k'_4G(= R_{ta}) + A''}に同意する。R''はタンブラーが持つ秘密の値 {(α, k'_4)}とアリスが持つ {k'_3}の値を使って構成されるが、それぞれ相手の秘密の値は知らない。
  3. アリスはランダム化したc''αをタンブラーに送信する。
  4. タンブラーは自身がもつPaillier暗号の秘密鍵でc''aを解凍し、γ ＝ （α + β + τ）を入手する。
  5. アリスはタンブラーとのチャネルを使ってタンブラーに送金する新しいCommitment Tx Aを作成し、内容についてタンブラーと同意する。
  6. タンブラーはCommitment Tx Aについてタンブラー側の署名 {k_4 + e'' \cdot sk_{t2}}を計算し、アリスに送る（e''はコミットメントTxから生成するSchnorr署名にしようするハッシュ値）。
  7. アリスはタンブラーから貰った署名値にGを乗算して、 {R_{ta} + e'' \cdot P_{t2}}と一致するか検証する。
  8. アリスはCommitment Tx Aのアリス側の署名を計算し、タンブラーから受け取った署名と合算した {s'' = k_3 + k_4 + e'' \cdot (sk_a + sk_{t2})}を計算しタンブラーに送信する。
  9. タンブラーはアリスから受け取ったs''とγを使って有効な署名データ {s = s'' + γ = k_3 + k_4 + e'' \cdot (sk_a + sk_{t2}) + γ}を完成させ、アリスに公開する。
  10. アリスはタンブラーが公開したsからs''を引いてγを入手する {s - s'' = γ = α + β + τ}。
  11. アリスはγから自身が付与したランダム値τを差し引いたα' = γ - τ = α + βを計算しボブに送信する。
  12. ボブはアリスから受信したα'から自身が付与したランダム値βを差し引き、αを入手する。
  13. ボブはαが分かったので、Promiseフェーズで作成したCommitment Tx Bの有効な署名 {s = k_1 + k_2 + e' \cdot (sk_{t1} + sk_b) + α}を完成させ、タンブラーから資金を得る。

以上がPayment（リリース）フェーズで、図にまとめると↓な感じ。

f:id:techmedia-think:20191007180117j:plain
A2L-Paymentフェーズ

ECDSA署名を利用した構成

結構なボリュームになったので、詳細なプロトコルに関してはホワイトペーパー参照。

基本的なプロトコルの流れはSchnorrの構成と同じで、ただECDSA署名にはSchnorrのような署名データの線形特性が無いので、鍵生成の方式が変わっており、Lindellのプロトコルで秘密鍵もPallier暗号で渡す仕組みになっている。

所感

A2Lプロトコルは、

  • 暗号チャレンジに解凍と引き換えにコインを渡すという仕組みでアトミック性を担保し
  • 暗号チャレンジをする際に、送信者と受信者で解答に対するランダム化を行うことでタンブラーに送金元と送金先のリンク不可能性を担保し
  • 暗号チャレンジの解答をAdaptor Signatureの要素として組み込みスクリプトレスにすることで、相互運用性およびFungibilityを担保する

Payment Channel Hubの提案だ。ただ値のプライバシーについては十分ではない。

基本的な構造はTumbleBitと同じだが、Adaptor Signature使ってスクリプトレスにしてる部分が追加の特性になっている。ただ、リンク不可能性やFungibilityに関しては、TumbleBitと同様利用者が少なければリンクできたり、異なる金種を用いるとリンクできたりする可能性はそのまま残るように思える。

*1:参考動画：https://goblockchain.network/2018/12/adaptor_signature/

*2:Paillier暗号の準同型特性により暗号化したままデータの計算が可能になる。