每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
今天，聊聊（支付通道的）并发与隐私问题。
比特币神奇但非完美，比方说，扩展问题（10笔/秒）、数据要求高（135GB）、交易费高、无法实现小额支付等等。于是乎，有人提出了支付通道的概念。
支付通道
简言之，支付通道就是不用（双方）每笔交易都上链。好比，Alice赶个新潮，不用传统方法给Bob转BTC，而是在两人间创建一个（链下的）支付通道。毕竟交易不在链上了，万一俩人不熟，那么谨慎起见，需要各自掏点钱当押金，交由Bob保管。支付通道中使用合约，允许一定时间后交易双方拿回押金。这步也就是通道开通，然后就能愉快的来回交易了。交易毕，关闭通道，将两人间全部交易提交至网络。这步中，两人根据最后一笔交易后的状态拿回各自相应数量的币。
总结起来就是：通道以交易始，以交易终。
这样说来，有交易需求，就得开新通道么？
也不一定，要知道，开的人多了，就成了个通道网络，蹭个通道也无妨。那么Alice可以借助其他节点的通道中转/转发一下自己的BTC。
比如，Alice跟Bob间开通道，转账路径是A->B
懒得开，就可以找其他节点，比如C、D，转账路径就成了A->C->D->B，这里有个前提，就是需要相信这些中间人节点。
也有无信任情形的中间人传输，就叫多跳支付好了（multi-hop payment）。
哈希定时锁合约（HTLCs）
使用哈希定时锁合约，是为了实现用户间的有条件支付，特别是在用户间无信任的情形下。好比，Alice给Fabi转1 BTC，有个前提是什么呢，Fabi首先要出示满足条件H（R）=y 的R值。 那么，Fabi这边的标准动作是：出示R值->提交R值至比特币网络， 说明Alice这笔1BTC的支付是有条件的。
提出HTLCs是为了打造闪电网络的多跳支付。
举个例子：
转账路径：Alice->Bob->Edward->Fabi
转账金额：1BTC
转账均为有条件支付，且无手续费。
从发送者到接收者的付款金额设为挂起（on hold）状态，后由接收人反向解挂。具体来说，Fabi把条件发送给Alice后，Alice接着与邻居Bob“签”个HTLC，将合约金额（1BTC）挂起。然后Bob用一样的套路跟下家Edward签HTLC，挂起转账金额，这样一路签到Fabi这。这时候，Fabi就知道了，路径上各种通道上都挂着1BTC呢，随后透露出R值，使得y=H(R)，这一步下来，路径通道里的1BTC全部解挂，相当于对通道内资金做出清算。
背景介绍完了，下面正式进入支付通道并发性的话题。
安全属性
这里考虑了两个安全问题。 第一个是余额安全，需要确保转账路径上的诚实节点不能出现丢币的情况。 好比， 用户的通道余额是D，那么，通道充当中间人时，不应出现转账后通道余额变化的情形。 第二个属性是可序列化，意思是支付是顺序的。
隐私属性
从隐私的角度来看，有两方面考虑。 第一个是异常路径价值隐私。好比，转账路径中有个攻击者，那么攻击者肯定知道转账金额的。另一个问题是路径关系的匿名性。 还说路径中有个攻击者，那么攻击者不应该知道真正发送方的具体地址。 所以，发送人、接收人应该各自有个集，是发送方也是接收方那种，起到混淆视听的作用。
通道中的隐私
有鉴于所有付款都是在链下进行的。那么隐私方面怎么样？
这里有这么个问题，说有条件支付的情形下，不管中间过了几次通道，条件都是不变的。也就是说，通过查看条件，可以确定正在使用哪些通道。这个问题有个解决方案，叫Fulgor，是个多跳HTLC。 方案使用了标准哈希定时锁合约，将剩下的加密操作都挪到链下进行。这波方案与当前比特币脚本完全兼容的。
多跳HTLCs
Fulgor使用了一个叫非交互式零知识的构建块（ZKBoo [GMO16]）。
这种零知识玩法下，目的是确保中间人不丢币，也不能盗币，对转账金额不知所以，但通道的余额还核得上。
通道中的并发性
研究发现，链上交易的并发性解决起来相对容易些。原因是，链上好歹有矿工看着。链下就不好说了，因为没人能完全掌握通道网络中的全部交易。有人提到屏蔽方案（blocking solution），但是这种可能引发死锁。
举个例子，看图先：
设每个通道的内只有1BTC，且通道被先到达的交易染色。
结果就是两笔交易都要被迫中止。
于是乎，又提出了一个非屏蔽方案（non-blocking solution）Rayo。 追求的是并发交易中，至少保一笔交易通过。 使用了全局交易标识符。 每笔交易都有一个能被网络中所有节点识别的标识符。 那么，套用到上面的例子中，红、蓝色交易都有标识符，节点可以对交易进行本地检查及排序。 然后再定个规矩，说标识符低的交易则中止。那么，节点也就知道该中止哪些支付了。
不太理想的地方
标识符这厮可能会干扰到交易隐私。 研究表明，又是屏蔽方案又能完全照顾到隐私是不可能实现的。所以，只能在并发、隐私这两个问题里挑一样解决。
上数据
这种多跳方案的运行时间主要看非交互知识要玩多久。比如，创建证明需要309毫秒，证明验证需要130毫秒。 再则，证明大小约1.65MB。 闪电网络上的测试结果显示，5跳的交易耗时609毫秒。Fulgor方案用时约1929毫秒，节点间通信大小在5MB。
结论
支付通道的安全与隐私讨论中，有人认为并发和隐私之间存在固有tradeoff，意思是说只能顾一样。 好比文中的Fulgor和Rayo方案，前者走隐私路线玩炫酷零知识证明，后者专业防并发三十年。
注：文章整理自论文Concurrency and Privacy with Payment-Channel Networks
链接：https://eprint.iacr.org/2017/820.pdf