Bolt: Anonymous Payment Channels for Decentralized Currencies 学习笔记

1. 引言

Matthew Green和Ian Miers 发表于2017年论文《Bolt: Anonymous Payment Channels for Decentralized Currencies》。

相关代码实现见：

• https://github.com/boltlabs-inc/libzkchannels

使用payment channel进行链下支付的典型方案有：

• Lightning Network：Joseph Poon 和 Thaddeus Dryja 2016年论文 The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
• Duplex Micropayment Channels：Christian Decker 和 Roger Wattenhofer 2015年论文 A fast and scalable payment network with Bitcoin duplex micropayment channels

无需将每笔交易提交到链上，channel在2方初始建立a shared deposit时会使用链，然后2方可直接进行支付——调整该deposit中相应的ownership shares，仅 在需要关闭channel 或 存在争议需要解决 时，才会再与链上通讯。

若2方之间无直接的payment channel，可通过中间peer路由实现支付。

payment channel的最大优势在于，可在无需引入可信第三方和中心化机制的情况下，大幅减少链上的交易存储空间。

尽管payment channel可解决扩容问题，但是存在一些隐私弱点：尽管交易发生在链下，任何人都可获知 the pseudonymous identities and initial (resp. final) channel balances of the participants。更严重的是，对于交易对手方，payment channel可提供的隐私保护有限。 更严重的是，通过建立channel来为Tor bandwidth 或 web content 付费，用户可含蓄地将该channel的每笔交易 关联 到其通过该channel的其他所有支付信息。

Bolt（Blind Off-chain Lightweight Transactions）中，包含了一系列技术，用于构建privacy-preserving unlinkable payment channels for a decentralized currency。本文提出了三种实现方式：【将通道内双方的角色分别称为customer客户 和 merchant供货商。】

• 1）单向支付通道：在单向支付通道中，客户向供货商付款，不会暴露客户身份信息，供货商也无法关联该通道内的其他交易。
• 2）双向支付通道：在双向支付通道中，客户与供货商之间可相互付款。支持exchange任意正负值，适于 需提供退款功能 或 交易发起方不是支付收款人 等场景。
• 3）间接通道：将双向支付通道 扩展为 支持第三方支付，引入不可信中介扮演“bridge”角色，使得未连接的双方可进行价值交换。中介无法知道交易中各方的身份，也无法知道交易的金额。可将 M M M方之间的通道数由 O ( M 2 ) O(M^2) O(M2) reduce为 O ( M ) O(M) O(M)。

链的作用主要为：

• 验证published transactions
• 根据public rules解决争端

1.1 payment channel背景知识

• 开通channel时，双方需对channel内各自的balance share达成一致，分别表示为非负整数 B 0 m e r c h B_0^{merch} B0merch​ 和 B 0 c u s t B_0^{cust} B0cust​。通过向链上发起一笔支付交易来建立channel。 若交易结构正确，链上会将提交的金额存入escrow中。
• 然后，customer可发起向merchant的链下支付。 对于某正数或负数支付金额 ϵ i \epsilon_i ϵi​，第 i i i笔支付可看成是a request to update B i c u s t = B i − 1 c u s t − ϵ i B_{i}^{cust}=B_{i-1}^{cust}-\epsilon_i Bicust​=Bi−1cust​−ϵi​ 和 B i m e r c h = B i − 1 m e r c h + ϵ i B_{i}^{merch}=B_{i-1}^{merch}+\epsilon_i Bimerch​=Bi−1merch​+ϵi​，同时限制 B i m e r c h ≥ 0 B_i^{merch}\geq 0 Bimerch​≥0 以及 B i c u s t ≥ 0 B_i^{cust}\geq 0 Bicust​≥0。
• 任何时间，任何一方或双方都可申请关闭通道——通过向链上提交channel closure message。 若closure message中表明双方对channel的当前state未达成共识，则链上会运行dispute resolution算法来决定最终的channel balances。 设置一个足够的delay期限，使得每一方都有机会贡献其closure message。各方可使用链上支付交易将channel中的final share balance恢复到各自的账号内。

任何payment channel必须满足2个条件：

• universal arbitration通用仲裁：若双方对channel的share state未达成共识，链上可在无需任何private信息的请看看下进行争端仲裁。
• succinctness：为了使支付可扩展，提交到链上的信息必须是紧凑的，即，不应与channel balance、交易数量、以及交换的金额 等呈线性关系。

payment channel的隐私性：

• 1）payment channel的隐私性不是绝对的。双方都知悉channel的建立或关闭，也必须知道channel的初始和最终value。
• 2）channel的一方，假设为customer，必须负责发起支付，从而知道该channel的当前balance以及历史支付记录。
• 3）隐私性主要体现在：当收到一笔来自某merchant的支付时，merchant仅知道在该open channel中发生了一笔有效的支付（正值或负值）。链仅知道具有某balance的channel已开启或关闭。【延伸为对中介路由来说也适用，中介路由仅知道在openchannel中2个用户之间发生了一笔有效的交易。】

1.2 构建隐私支付通道总览

本文提出了2种构建隐私支付通道的方案：

• 1）基于e-cash方案，实现在单向支付通道中，构建由customer到merchant的固定金额的succinct 支付。保留了传统支付通道的功能和隐私性。
• 2）引入了更复杂的abort condition，实现双向支付通道内任意金额（可为正值或负值）的支付。可支持path payment，用户可通过untrusted 中介实现隐私支付。

1.2.1 e-cash的单向支付通道

e-cash scheme中有一个名为bank的可信第三方，bank会issue one-time tokens（又名coins），customer可一次性赎回这些one-time tokens。

merchant承担bank的角色，会issue a “wallet” of anonymous coins to the customer，customer可spend这些coins back to the merchant。 关闭channel时，customer会将剩余的coins发给自己，然后向链上提供相应的证据。merchant可通过提交双花证明来抗议customer的statement。

以上方案存在如下弱点：

• 1）最明显的，不是succinct的，关闭过程中customer需要提交其所有unspent coins。-》借助compact e-cash[CHL05]机制可解决。本文将关闭通道的开销reduce为a single fixed-size message。增加了merchant 和 customer 链下的沟通开销。
• 2）存在时差：只有customer的资金在链上托管了，merchant才能为该customer issue a wallet。整个过程需要数分钟到数小时。与此同时，当merchant issue wallet失败 或 终止wallet激活 时，要确保customer可将其资金拿回。
• 3）应可避免customer "framing"攻击（此时merchant为其自身issue coins，然后指控是customer双花了），协议应具有排他性，即在链上应可区分是cheating customer真的双花了，还是merchant创建了错误的双花。

1.2.2 双向支付通道

单向支付通道限制了：所有支付仅能由customer 到 merchant。

因此，基于现有（non-anonymous）支付通道 + 盲签名和zkProofs，来实现双向隐私支付通道。

关键点在于： 防止dishonest customer在通道关闭时使用老版本的refund token。

为此，在每次支付时，customer都需要给merchant一个revocation token for the previous state。如果customer表现honest，则该revocation token将永远不会关联channel 或 任何previous transactions。 一旦customer misbehave——将过期的refund token提交上链，则merchant可立即监测到该情况，将该revocation token提交到链上作为customer恶行的证明，链上会将该channel的balance都奖励给merchant。

1.2.3 由直接支付 到 第三方支付

基于双向支付通道可构建第三方支付。A 通过 untrusted中介I 向 B 支付。 本文的主要优势在于，中介I 无法将交易关联到用户，也不知道特定交易包含的金额。即使I compromised，其也无法claim any transactions passing through it。

1.2.4 Aborts

对于单项支付通道，当通道关闭时，最终channel balances将公开。customer和merchant之间的支付为non-interactive的，为完全匿名的。

对于双向支付通道，在执行过程中终止时，merchant可让customer处于无法再发起支付交易的状态，这无法阻止merchant向链上求助来关闭通道，但需要考虑2方面的隐私：

• 1）merchant可通过人为终止来驱逐他人，以减少anonymity set。
• 2）merchant可关联用户与a repeating sequence of transactions，通过aborting the user in the middle of the sequence。

对于传统商业设置，abort的后果可很小：无论是何种支付机制，若供货商无法提供合适的商品，customer可终止交易。对于微支付场景，应考虑abort的情况。customer应扫描链上未成熟的关闭，若customer的open channels数低于其最小anonymity set，则abort该channel。

2. 相关定义

2.1 匿名支付通道 APC

APC（Anonymous Payment Channel）匿名支付通道为2方基于某链（支付网络，该支付网络应可conditionally escrowing funds and binding these transactions funds to some data，如记录Bitcoin链上）构建的链下支付通道。 APC中包含了一组probabilistic算法：

• K e y G e n KeyGen KeyGen
• I n i t C Init_{\mathcal{C}} InitC​
• I n i t M Init_{\mathcal{M}} InitM​
• R e f u n d Refund Refund
• R e f u t e Refute Refute
• R e s o l v e Resolve Resolve

以及2个交互协议：

• Establish
• Pay

实例化匿名支付通道的流程为：

• 1）merchant M \mathcal{M} M生成一组长期有效的keypair ( p k M , s k M ) ← K e y G e n ( p p ) (pk_{\mathcal{M}}, sk_{\mathcal{M}})\leftarrow KeyGen(pp) (pkM​,skM​)←KeyGen(pp)，并将该身份告知所有customers。 merchant将其初始状态设置为 S ← Ø \mathbf{S}\leftarrow \text{\O} S←Ø。
• 2）customer C \mathcal{C} C 会生成一次性keypair ( p k C , s k C ) (pk_{\mathcal{C}}, sk_{\mathcal{C}}) (pkC​,skC​)，用于某single channel。
• 3）customer和merchant对各自的initial channel balances B 0 c u s t , B 0 m e r c h B_0^{cust}, B_0^{merch} B0cust​,B0merch​达成共识。
• 4）customer和merchant对达成共识的initial channel balances 各自执行 I n i t P Init_{\mathcal{P}} InitP​算法，分别派生出channel token T C , T M T_{\mathcal{C}}, T_{\mathcal{M}} TC​,TM​。
• 5）customer和merchant将各自的channel token以交易的形式提交到链上，以托管合适的金额。
• 6）一旦资金被verifiably escrowed，customer和merchant双方运行Establish协议来激活支付通道。若双方不认可the initial channel balances，则协议返回 ⊥ \perp ⊥，且可关闭通道。
• 7）若通道激活成功，customer可发起Pay协议任意多次，直到一方 或 双方关闭该通道。
• 8）若customer想要关闭通道，可执行 R e f u n d Refund Refund算法，将结果channel closure message r c C rc_{\mathcal{C}} rcC​ 与channel identifier 一起提交到链上。
• 9）merchant基于customer的closure message r c C rc_{\mathcal{C}} rcC​，运行 R e f u t e Refute Refute算法，来获得merchant closure message r c M rc_{\mathcal{M}} rcM​。
• 10）链上执行 R e s o l v e Resolve Resolve算法来决定final channel balance，使得每方可获得已托管资金的确定份额。

2.2 APC的正确性和安全性

APC的正确性是指：若整个过程中都是是正确且honest执行的，则每次运行Pay协议都是成功的，且最终的 R e f u t e Refute Refute输出可反应正确的final channel balance。

APC的安全性主要体现在：

• 1）Payment anonymity：支付匿名性是指，即使merchant与一组malicious customers一起串通，也无法知悉某customer的spending pattern。
• 2）Balance：分为merchant的balance 和 customer的balance。是指若honest执行 R e s o l v e Resolve Resolve算法，任何adversary无法获取多于其应得份额的资金。

3. APC的技术要点

APC中涉及的技术要点有：

• 1）Commitment scheme：本文使用基于DLP的Pedersen commitment scheme。
• 2）对称加密scheme 和 one-time 对称加密scheme：要求可提供IND-CPA（Ciphertext indistinguishability）安全性。
• 3）伪随机函数PRF：在构建单向匿名支付通道时，需要PRF提供efficient proofs of knowledge。PRF除具有标准的伪随机属性之外，还应具有strong pre-image resistance属性，即找到不同的 ( s ′ , x ′ ) (s',x') (s′,x′)使得 F s ( x ) = F s ′ ( x ′ ) F_s(x)=F_{s'}(x') Fs​(x)=Fs′​(x′)成立的概率可忽略。本文推荐使用Dodis-Yampolskiy PRF，有 f s ( x ) = g 1 / ( s + x ) f_s(x)=g^{1/{(s+x)}} fs​(x)=g1/(s+x)。
• 4）签名机制：具有的特征为：1）a protocol for a user to obtain a signature on the value(s) in a commitment without the signer learning anything about the message(s)；2）a protocol for (non-interactively) proving knowledge of knowledge of a signature。具体可使用基于Strong RSA假设的[CL02] 或 基于blinear groups的[BCKL08, CL04]。安全性上，这些签名机制应满足existential unforgeability under chosen message attack (EU-CMA)。
• 5）Non-Interactive Zero-Knowledge Proofs：如用于证明：1）a proof of knowledge of a committed value；2）a proof that a committed value is in a range。

4. APC协议

本文实际实现了3种APC协议：

• 1）基于e-cash技术的单向匿名支付通道：仅支持固定金额。
• 2）双向匿名支付通道：支持任意金额，支持abort。
• 3）通过中介的第三方匿名支付通道。

4.1 单向匿名支付通道

主要对[CHL05]中的compact e-cash技术进行改进实现的高效、succinct单向匿名支付通道。

4.1.1 compact e-cash

在compact e-cash scheme中，customer withdraw a fixed-size wallet capable of generating B B B coins。customer的wallet基于tuple ( k , s k , B ) (k,sk, B) (k,sk,B)，其中：

• k k k为（interactively generated）seed for伪随机函数 F F F
• s k sk sk为customer的私钥。
• B B B为wallet中的coins数量。

customer的wallet一经merchant签名，即可用于生成最多 B B B coins： 第 i t h i^{th} ith coin包含了tuple ( s , T , π ) (s,T,\pi) (s,T,π)，其中：

• s s s为“serial number”，计算方法为 s = F k ( i ) s=F_k(i) s=Fk​(i)。
• T T T为“double spend tag”，计算方式为，若某一coin被双花，则该结合该double spend tag来reveal customer的key p k pk pk（或 s k sk sk）。
• π \pi π为non-interactive zero-knowledge proof of the following statements：
  • 1） 0 < i ≤ B 0