开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 区块链 -> Bolt: Anonymous Payment Channels for Decentralized Currencies 学习笔记 -> 正文阅读

[区块链]Bolt: Anonymous Payment Channels for Decentralized Currencies 学习笔记

1. 引言

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

1.1 payment channel背景知识

开通channel时，双方需对channel内各自的balance share达成一致，分别表示为非负整数 $B_0^{merch}$ 和 $B_0^{cust}$ 。通过向链上发起一笔支付交易来建立channel。
若交易结构正确，链上会将提交的金额存入escrow中。
然后，customer可发起向merchant的链下支付。
对于某正数或负数支付金额 $\epsilon_i$ ，第 $i$ 笔支付可看成是a request to update $B_{i}^{cust}=B_{i-1}^{cust}-\epsilon_i$ 和 $B_{i}^{merch}=B_{i-1}^{merch}+\epsilon_i$ ，同时限制 $B_i^{merch}\geq 0$ 以及 $B_i^{cust}\geq 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$
$Init_{\mathcal{C}}$
$Init_{\mathcal{M}}$
$R e f u n d$
$R e f u t e$
$R e s o l v e$

以及2个交互协议：

Establish
Pay

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

1）merchant $\mathcal{M}$ 生成一组长期有效的keypair $(pk_{\mathcal{M}}, sk_{\mathcal{M}})\leftarrow KeyGen(pp)$ ，并将该身份告知所有customers。
merchant将其初始状态设置为 $\mathbf{S}\leftarrow \text{\O}$ 。
2）customer $\mathcal{C}$ 会生成一次性keypair $(pk_{\mathcal{C}}, sk_{\mathcal{C}})$ ，用于某single channel。
3）customer和merchant对各自的initial channel balances $B_0^{cust}, B_0^{merch}$ 达成共识。
4）customer和merchant对达成共识的initial channel balances 各自执行 $Init_{\mathcal{P}}$ 算法，分别派生出channel token $T_{\mathcal{C}}, T_{\mathcal{M}}$ 。
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$ 算法，将结果channel closure message $rc_{\mathcal{C}}$ 与channel identifier 一起提交到链上。
9）merchant基于customer的closure message $rc_{\mathcal{C}}$ ，运行 $R e f u t e$ 算法，来获得merchant closure message $rc_{\mathcal{M}}$ 。
10）链上执行 $R e s o l v e$ 算法来决定final channel balance，使得每方可获得已托管资金的确定份额。

2.2 APC的正确性和安全性

APC的正确性是指：若整个过程中都是是正确且honest执行的，则每次运行Pay协议都是成功的，且最终的 $R e f u t e$ 输出可反应正确的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$ 算法，任何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^{'})$ 使得 $F_s(x)=F_{s'}(x')$ 成立的概率可忽略。本文推荐使用Dodis-Yampolskiy PRF，有 $f_s(x)=g^{1/{(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$ coins。customer的wallet基于tuple $(k, s k, B)$ ，其中：

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

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

$s$ 为“serial number”，计算方法为 $s=F_k(i)$ 。
$T$ 为“double spend tag”，计算方式为，若某一coin被双花，则该结合该double spend tag来reveal customer的key $p k$ （或 $s k$ ）。
$\pi$ 为non-interactive zero-knowledge proof of the following statements：
- 1） $0<i\leq B$
- 2）Prover知道 $s k$
- 3）Prover具有wallet $(k, s k, B)$ 的签名
- 4）pair $(s, T)$ 为correctly structured with respect to the signed wallet。

整个构建过程，可保证Verifier可立即发现双花，因为2笔交易使用相同的serial number $s$ 。
结合double-spend tags，Verifier可恢复spender的public key。
与此同时，各个coin spends无法与用户或其他coin spends 进行关联。

基于compact e-cash构建的单向支付通道，merchant承担bank角色，会为customer issue a wallet of $B$ coins，customer可将其匿名地 spend back to the merchant。
在关闭通道时，customer可简单滴spends any unused coins “to herself”，从而向merchant证明其没有该通道的spending capability（若后续再尝试spend这些coins，merchant可将其看作是双花行为）。
但是compact e-cash提供了succinct wallet，但是未能在关闭通道时提供succinct protocol。因为customer无法在不影响wallet中之前花费coin隐私性的情况下，简单地公开wallet secrets。因此，需要一种机制来succinctly reveal only a fraction of the coins in a wallet，而无需reveal all the coins。与此同时，还希望避免复杂的证明。

本文的方案为：merchant会存储必要的信息来验证通道关闭，因此需要对[CHL05]中的compact e-cash scheme进行改进。
具体为：
在这里插入图片描述

其中的Establish和Pay协议为：

4.2 双向支付通道

4.1节的单向支付通道，存在如下缺陷：

1）仅支持由customer向merchant发起支付
2）仅支持fixed-value coins

因此需要构建双向支付通道，支持：

compact closure
compact wallet
a single run of the Pay protocol to transfer arbitrary values (受限于最大支付金额)

双向支付通道的customer wallet 与单向支付通道的customer wallet 结构类似，包含了：

$B_0^{cust}$
a random wallet public signature key $w p k$

当merchant为wallet的内容提供盲签名后，该wallet被激活。

Signed wallets are obtained as in the previous protocol, with a commitment being placed in the anchor transaction and signing happening once the transaction is confirmed.

不同于之前协议中使用a series of individual coins来支付 $\epsilon$ ，此处，customer和merchant简单地将现有价值为 $B^{cust}$ 的signed wallet 交换为价值 $B^{cust}-\epsilon$ 的新signed wallet（对应有a fresh wallet public key $wpk_{new}$ ）。此时的 $\epsilon$ 可为正值，也可为负值。
customer采用zero knowledge proof和签名来证明 the contents of the new requested wallet are constructed properly，该新wallet的balance与之前的balance之差为 $\epsilon$ ，且 $(B^{cust}-\epsilon)\geq 0$ 。
与此同时，customer需要公开 $wpk_{old}$ ，以此向merchant保证该wallet不会双花。old wallet将由customer使用相应的私钥 $w s k$ 进行“revoked” message签名来使其失效。
关闭通道时，customer需要向链上提供由merchant签名的valid wallet。

构建过程中的调整在于：使现有wallet失效的同时，签名一个新的wallet。若merchant在old wallet失效之前签名了新wallet，则customer可retain the funds in the old wallet while continuing to use the new one。若merchant在签名新wallet之前使old wallet失效，若merchant拒绝签名新的wallet，则customer没有办法来关闭通道。

为此，需要通过interactive payments，区分在关闭通道时提供的value，采用2个子阶段协议来获取每组值。不公开最新的wallet $w$ ，customer使用包含了 $B^{cust}$ 、当前wallet公钥以及 merchant签名的 refund token $r t$ 来关闭通道，
即，将Pay协议分为2个阶段：

1）第一阶段：customer获取来自于merchant对refund token的盲签名。
2）第二阶段：customer使老钱包失效，然后merchant签名新钱包。若merchant拒绝签名新钱包，则customer可使用 $r t$ 来安全地关闭通道。

双向支付通道整个构建过程为：
在这里插入图片描述

其中双向支付通道中的Establish和Pay协议为：

双向支付通道的一个主要限制在于：

malicious merchant可abort the protocol。但是，该协议本身可保证，当abort发生时，customer的资金不会遭受损失，因为customer可简单地向链上提供其refund token $rt_{w'}$ 来恢复其balance。
customer的匿名信。merchant可将customer置于无法继续spend，只能关闭通道的状态，从而可link the payment to the channel。不过，若通道使用匿名currency，则该影响可很有限。
malicious merchant可利用abort来减少系统的anonymity set，使得多个channel进入无法正常工作的状态。实际上，这种攻击可在链上生成visible signal，使得customer可终止其支付。

4.3 双向第三方支付通道

若A与中介I开通了双向支付通道，B与中介I开通了双向支付通道，则A可通过中介I向B进行支付。

双向第三方支付通道的主要挑战在于支付的原子性，即：
一旦中介I向接收方B付款，则A才向中介I付款。这将给中介I带来风险，若A无法完成整个支付。同时，若中介disonest，也会给A带来风险。

回忆下4.2节双向支付通道Pay协议的2个阶段：

1）交换refund tokens来reclaim escrowed funds。
2）为后续支付生成匿名钱包。

为了保证chained transaction $A\rightarrow I\rightarrow B$ 的安全，要求这2个环节中的第一阶段为原子式成功或失败。

为此，需要给refund tokens增加条件，这些条件为simple statements for the network to evaluate on examining a token during the Resolve protocol。
特别地，为了避免接收方 $B$ claiming funds form $I$ if 付款方 $A$ has not delivered a corresponding payment to $I$ ，为此，需要给 $B$ 的refund token引入如下条件：

1） $B$ 必须为 $A$ 的previous wallet生成a revocation message（即a signature using $A$ 的 $w s k$ ）。可保证，一旦 $B$ force a payment on $I\rightarrow B$ ，由于 $I$ 具有相应的revocation token， $A\rightarrow I$ 无法被reverse。
2） $A$ 未向链上提交包含 $w s k$ 的revocation token。若 $A\rightarrow I$ 已被reverse，因为 $w p k$ 已在链上，则 $B$ 无法force the payment on $I\rightarrow B$ 。

4.3.1 隐藏支付金额

在第三方支付通道中，由于 $I$ 作为积极参与者，并不维护channel的状态， $I$ 也无需知道支付的金额。只要 $A, B$ 对支付金额 $\epsilon$ 达成共识（即双方在各自的channel中有足够的金额），任何一方都无法向 $I$ 透露 $\epsilon$ 。 $I$ 仅确信the balance of funds is conserved。

为了隐藏支付金额，需要将图3 Pay协议中构建 $\pi_2$ 的proof statement进行修改：
不再向merchant公开 $\epsilon$ ，customer需对 $\epsilon$ 进行commit，然后在支付中将该值作为secret input。同时，也要调整协议中 $B$ 的wallet， $B$ 需要证明其wallet已调整了 $-\epsilon$ 。
整个 $\pi_2$ 调整为：
在这里插入图片描述
然后 $A$ 向 $I$ 证明that the two payments cancel or (if $f e e$ is non-zero)，leave $B$ with $f e e$ extra funds via a proof：

第三方支付通道整个流程为：

第三方支付通道中的Pay协议为：

第三方支付通道的主要挑战在于：
malicious $I$ 可选择性地在交易中终止协议，从而迫使 $A$ 和 $B$ 向链上提交交易以恢复其资金。可link该payment到 $A, B$ 的channel。这种问题，在交互式协议中，很难从根本上避免。

可在通道中冲入匿名currency，以尽可能地减少匿名信的威胁。关联2个不同的channel并不会泄露参与者的身份。最重要地是，由于中介仅可在每个通道使用一次abort技术，merchant无法关联同一通道内的不同支付。最后，执行abort的中介会在链上产生公开记录，使得参与者可回避该malicious中介。

4.4 隐藏支付balance

以上三种创建方式，当通道关闭时，存在channel balance将会被公开的隐私问题。
While individuals can protect their identities and initial channel balances by using an anonymous currency mechanism to fund channels, the information about channel balances leaks useful information to the network.

注意，对于不存在争议的通道关闭流程，可按如下方式隐藏信息：

通道关闭时，customer向链上提交a commitment to the final channel balance，以及 a zero-knowledge proof that she possesses a valid channel closure token（即，为a signature on the channel balance in our bidirectional construction）。

在类似Zerocash [SCG+14]的系统中，the final payment redeeming coins to the merchant and customer can be modified to include an additional statement: the amounts paid in this transaction are consistent with the commitment, and do not exceed the initial funding transaction that created the channel.【本文未来将进一步研究】