原文:https://arxiv.org/pdf/1911.12929.pdf
学习一下人家的论文怎么写的
摘要:针对支付网络通道的主要问题——多条路由的交易需要路径上节点锁定一笔交易,来辅助完成这笔跟他无关的交易,这样的设计一方面限制了中间节点的资金流动性,一方面有时会导致死锁进而交易失败。多跳支付的路径越长,以上问题越明显。
论文设计了一个channel hub,是payment hub(Nocust)的拓展。在一个hub内的支付通道之间可以直接进行交易,作者设计了一个Boros协议,让跨支付通道的交易可以依赖channel hub,安全快速地进行。作者还使用UC框架对协议进行了形式化安全证明,提出了一套概念验证测试方案,来验证Boros的可行性,最终实验结果表明channel hub可以有效减少多跳路径长度。
1、比特币和以太坊给互联网之上的价值交换提供可贵方案,以太坊甚至允许图灵完备程序的运行
2、区块链系统通量太低,比特币的tps为6~7,以太坊的tps为20,并且无法通过简单地设置共识算法参数来提升tps,这通量低得跟中心化系统差远了,visa的tps为47000
3、最近已经有很多扩展方案了,包括共识机制改良(bitcoin-ng、Scp-BFT算法、[32])、分片(OmiLedger、rapidChain、[39])、可信运行环境(TeeChain、[40])、侧链([2, 23])、支付通道/网络(闪电网络、雷电网络)([7, 29])
4、支付通道工作原理:通过在链上锁定资金,两个节点就加入了一条通道,然后可在通道内进行多笔私密、快速、低成本的交易,最后提交最终状态的证据即可重新将锁定资金提取至链上,通道关闭成功
5、支付通道网络的多跳支付,依赖多个中间节点提前锁定资金,最终完成一笔没有直接相连节点(没有建立支付通道的节点)之间的交易。已经有很多研究:Sprites[30]致力于减少最坏情况下中间节点的锁定资金时长,还有各种工作致力于隐私、并行、安全等方面研究([15, 27-28, 34-35])
6、在支付通道网络的路由比传统的TCP/IP网络更困难,因为要考虑路径上的节点锁定的资金容量是否足够完成这一笔交易,不协调好就会导致死锁[28],甚至中间节点会损失资金,并且路由路径越长,以上问题越严重
7、介绍本文的工作:提出了一个新的链下系统,旨在减少路由跳数。
首先,提出了channel hub的概念。channel hub的参与者既可以是单个节点,也可以是支付通道,它允许一个hub中的节点之间直接进行交易。它无需中间节点的抵押担保,也使得支付通道的资金流动性增强,可被多次重用,同一笔资金的交易范围扩大很多
其次,提出了配套channel hub的协议Boros,来支持交易安全地进行。其安全性保证了诚实节点无论如何都不会损失资金,最终作者使用UC框架证明了其安全性,也做实验验证了
最后,作者开发了在以太坊运行的概念证明原型,用来证明Boros的可行性,也证明了它确实可以减少路由跳数
8、论文的组织结构
A. 支付通道[7,33]
支付通道允许节点锁定资金后,使用这笔资金在区块链外进行交易,且锁定的资金随时可以退回链上账户。打开:广播打开通道交易,锁定资金。交易:只能使用锁定资金限额内的数量进行交易,通道打开后就可以进行多笔微服务费交易;协议的核心就是双方就各自在链下通道的资金分布状态达成共识,避免恶意的一方将全局状态回滚到过期的状态,[7]使用时间锁来抛弃过期状态,闪电网络[33]使用惩罚博弈来强迫全局保持最新状态。退出:任何一方想要退出通道,就广播一笔提交交易给区块链,其中包括最新全局状态,锁定的资金就回到了链上账户。
这样的设计就使得中间交易不必在区块链网络流转、执行和上链,通量大大提升,唯一的性能瓶颈就是网络带宽。
几个改进方案:[3]提出支付通道工厂的概念,其位于区块链和支付通道网络之间,实现通道的快速关闭。[15]提出的Bolt可以建立隐私保护支付通道,并且同时可以减少通道中节点的存储压力。[10]提出的虚拟通道借助以恶搞中间节点建立,具有隐私保护特性。[11]提出的状态通道不仅可用于支付交易,也可用于智能合约调用交易,还提出虚拟通道的递归建立,从而形成多人通道。
B.支付通道网络[29, 33]
没有建立支付通道的节点之间想要进行交易,可以不去建立昂贵的新支付通道,而去进行多跳路由的交易。
此间最严峻挑战就是保障原子性,闪电网络使用哈希时间锁HTLC来保证这一点,包括正向解锁(交易成功)和反向解锁(交易失败)两种过程。
改进方案:Sprites减少最坏情况下的中间节点资金锁定时间。[28]提出了在支付通道网络中并行执行交易的方案,能够实现一组并行执行的交易中,至少一笔能成功,还讨论了隐私安全和并行执行之间的优化冲突。Revive[18]提出让资金在不同的支付通道之间安全转移,从而达到一种“平衡”状态。Flare[34]、SilentWhisper[27]、SpeedyMurmurs[35]等致力于效率和隐私安全的提升。
C. Payment Hub
Tumblebit[12]首次提出这个概念,一个paument hub中的节点之间可以进行安全交易,交易依托于一个无信任中间节点(领导者)——Tumbler,它无法破坏交易双方身份隐私性,但Tumbler需要和所有交易节点之间建立支付通道。NOCUST[19]将所有参与者资金统一管理在链上合约,链下所有交易处理和同步链上账本由一个服务器(领导者)负责,链上合约还会处理争议。
然而在以上的payment hub中,只有节点参与,每次有新节点加入,就必须存入一笔新的资金,不可重用已经锁定过的资金,资金流动性被限制。本论文提出的channel hub就可以容纳节点和支付通道。一旦一个支付通道加入了channel hub,其中锁定的资金就可以用于和别的通道交易,不必新建支付通道或以多跳路由形式交易。相比于payment hub,channel hub可以使用等量资金成本,方便更多节点进行跨通道交易。因为,这两种协议中,想要加入hub都需要发布1条链上交易,而一个支付通道加入channel hub,实际上意味着2个节点的加入,也只需要1条链上交易。
主要参考NOCUST的工作,将payment hub扩展为channel hub。
payment hub主要包括两个部分:链上合约+链下中心化服务器。链上合约维护全局账本,负责争议处理;链下服务器负责处理自己所在hub的交易,更新hub内局部账本,定期更新到全局账本中。账本的结构就是一个map,key为账户地址,value是锁定资金余额。
channel hub的改进点就是发现单节点(外部地址)与支付通道(实际上是合约地址)的账户地址共享一个地址空间,即账本中的key既可以为单节点账户,也可以为支付通道账户。所以对NOCUST中的账本结构进行改造,让叶结点包含更多的信息,当叶节点代表一个通道的时候,要包含通道内部的最新状态信息等。
用处:进行跨支付通道交易,且保证无论如何(敌手遍布),诚实节点不会损失资金
例如A给B转账 △ x \triangle x △x,A和B分别在通道 β A C \beta_{AC} βAC和 β B D \beta_{BD} βBD中,要做的就是:现在channel hub中进行通道 β A C \beta_{AC} βAC给通道 β B D \beta_{BD} βBD转账 △ x \triangle x △x,然后更新两个通道内部状态: x A = x A − △ x , x B = x B + △ x x_A=x_A-\triangle x, x_B=x_B+\triangle x xA=xA−△x,xB=xB+△x,C和D的余额不变
最重要的就是保持两边资金状态是匹配的,也就是保证原子性。
首先,当所有节点诚实,Boros协议运作流程如下:
阶段一:prepare
A和B分别向C和D发送 m p c c m_{pcc} mpcc消息,表明自己要和B或A进行交易,交易金额为 △ x \triangle x △x,若C或D验证通过并同意就向ABD或ABC发送 m g c c m_{gcc} mgcc消息,最终所有节点持有 m g c c A C m_{gcc_{AC}} mgccAC和 m g c c B D m_{gcc_{BD}} mgccBD消息
阶段二:capacity transfer
A代表通道 β A C \beta_{AC} βAC向 H ⊄ \mathcal{H}_{\not\subset} H⊂(链下中心化服务器)发送iou消息, H ⊄ \mathcal{H}_{\not\subset} H⊂验证后传递给B,B验证后回复receipt(包含B的签名)给 H ⊄ \mathcal{H}_{\not\subset} H⊂,然后 H ⊄ \mathcal{H}_{\not\subset} H⊂更新本地账本里2个通道地址对应的余额,回复A和B确认消息conf
阶段三:in-channel update
A向C发送icu(res)消息,包括上一阶段的执行结果——A需要减少的金额数 △ x \triangle x △x,C收到后验证有效性,回复确认消息conf。B和D之间的消息交换类似
敌手模型:
敌手可以付出一些资金来搞破坏,可以控制多个节点(除了一个诚实节点,可以控制剩下所有节点),已经被控制的节点所在的hub和通道内账本状态都会暴露给敌手,可以代替被控制节点发送任意消息。假设诚实节点回一直保持诚实,不会被贿赂成为恶意节点。
Boros可以保证以下安全特性:
1、诚实节点们对于某通道或节点是否加入了channel hub总是能达成一致
2、诚实节点们对于某通道或节点在hub的余额总是能达成一致
3、诚实节点绝不会损失资金
先来看prepare阶段,其主要目的就是对“A将要和B进行交易,他们所在通道为AC和BD”这件事达成共识,也就是所有4个节点拿到 m g c c A C m_{gcc_{AC}} mgccAC和 m g c c B D m_{gcc_{BD}} mgccBD消息,若有节点故意不回复或发送消息,就会导致有的节点无法获得这两条消息,分成以下几种情况:
1)A没拿到2条消息
直接导致下一阶段的iou消息构造失败,整个交易直接失败
2)B没拿到2条消息
B稍微坚强一点,可以通过后面 H ⊄ \mathcal{H}_{\not\subset} H⊂发送的iou消息得到2个gcc所包含的信息
3)C或D没拿到2条消息
这个稍显复杂,C或D无法确定交易是否准备好被执行了,最严重情况是,交易执行都结束了,C或D都不知道,作者们引入一个最大交易时限 T T T来解决问题。以C为例,当一笔交易开始,C受到pcc消息,开始计时,直到T结束都没收到最终交易执行的结果——icu消息,那么C发送消息force-reply给 H ⊄ \mathcal{H}_{\not\subset} H⊂, H ⊄ \mathcal{H}_{\not\subset} H⊂收到后要求A在固定时间范围内回复 H ⊄ \mathcal{H}_{\not\subset} H⊂执行结果icu消息,若A及时回复了有效的icu消息,则 H ⊄ \mathcal{H}_{\not\subset} H⊂将其转发给C,让C能过同步跟上,否则 H ⊄ \mathcal{H}_{\not\subset} H⊂直接关闭AC通道,将其资金返回链上。
再看第二阶段,跟NOCUST一样,我们的合约也提供两种情况的争议处理:balance update challenge和transfer delivery challenge,前者是对发起节点自己余额的争议,后者是对某条交易有争议
最后看第三阶段,2个通道的账本都要更新,以保持一致。会出现的恶意情况如下:
1)A恶意不发送icu消息给C
C无法获知交易后AC通道的余额分布,解决方法跟prepare的一样,设置超时时间,向 H ⊄ \mathcal{H}_{\not\subset} H⊂请求解决
2)C恶意不回复conf消息给A
解决方法跟上面的一样
写在另一篇里面:https://blog.csdn.net/weixin_48288539/article/details/125316347
作者在以太坊实现了boros,并且计算了每个操作的执行成本,实验的重点在于整个设计的可行性,未来会继续优化。进一步地,作者们在不同规模的链下支付通道网络运行了boros协议,证明了他们的设计可以很好地极少多跳交易路由的长度。
解释一下为啥要估算操作的执行成本:在以太坊中,每笔交易的执行都需要支付gas费,用于给矿工的奖励,宏观上来讲就是EVM执行指令所花费的成本。交易是否会被及时执行,进入新块,很大一方面取决于交易发起方预设的gas费数量,gas费较低的话,矿工们不愿意执行交易,挣得太少。所以尽量减少链上操作(EVM执行成本),就可以有效降低用户的交易费花费。
作者将对交易费的评估转移为对下列指标的评估:链上交易数量、执行成本(gas量、以太币数量、美元数量)、链下消息数量、签名数量。如表一所示,对应着前面的具体流程。
表2显示了只建立一个channel hub的对比结果,第一列是网络成员加入hub的比例,第二列是网络共有多少节点。对于某固定大小的支付通道网络,其中存在的支付通道的密度用 e d g e N u m / n o d e s N u m edgeNum/nodesNum edgeNum/nodesNum衡量,统一选用4(跟闪电网络一样)为这个比例。作者使用了Ripple的数据集进行试验,计算各种配置情况下的平均路由跳数
从第三列开始,各列的意义为:
1、PN-FW:原生支付通道网络+Floyd-Warshall路由算法路由多跳交易
2、PH-FW:Payment hub+Floyd-Warshall路由算法路由多跳交易
3、CH-FW:channel hub+Floyd-Warshall路由算法路由多跳交易
4、 △ 1 \triangle 1 △1-FW:boros比payment hub的提升
5、 △ 2 \triangle 2 △2-FW:boros比支付通道网络的提升
6、PN-SM:原生支付通道网络+SpeedyMurmurs路由算法路由多跳交易
···
对于有多个hub的情况,固定每个hub中的节点个数为k(100~200),hub的数量是用 n × α k \frac{n\times \alpha}{k} kn×α向下取整算出来的,可见对比还是挺明显的
解释一下,为什么payment hub的路由跳数多于channel hub?因为3个实验都是基于已有的payment network做的。在payment hub方案中,跨通道交易优先通过交易双方在payment hub之内进行,若交易双方中的一方或两方都没有加入同一个payment hub,就需要新加入一个hub,但有种情况,某一方的资金已经不允许它加入新的hub,就只能通过多跳路由进行交易,就是这一部分使得payment hub比channel hub平均路由跳数更多。channel hub由于可以重用已有双人通道内的资金,就不存在被迫只能跨双人通道进行多跳路由交易。
注意到:Floyd比speedymurmurs的路由长度更短
参考文献:
[2] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Tim´on, and P. Wuille, “Enabling blockchain innovations with pegged sidechains,” URL: http://www.opensciencereview. com/papers/123/enablingblockchain-innovationswith-pegged-sidechains, 2014.
[3] C. Burchert, C. Decker, and R. Wattenhofer, “Scalable funding of bitcoin micropayment channel networks,” Royal Society open science, vol. 5, no. 8, p. 180089, 2018.
[7] C. Decker and R. Wattenhofer, “A fast and scalable payment network with bitcoin duplex micropayment channels,” in Proceedings of the 17th International Symposium on Stabilization, Safety, and Security of Distributed Systems - Volume 9212, 2015, pp. 3–18.
[10] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski, “Perun: Virtual payment channels over cryptographic currencies,” IACR Cryptology ePrint Archive, 2017: 635, Tech. Rep., 2017.
[11] S. Dziembowski, S. Faust, and K. Host´akov´a, “General state channel networks,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’18. New York, NY, USA: ACM, 2018, pp. 949–966. [Online]. Available:
http://doi.acm.org/10.1145/3243734.3243856
[12] H. Ethan, F. Baldimtsi, L. Alshenibr, A. Scafuro, and S. Goldberg, “Tumblebit: An untrusted tumbler for bitcoin-compatible anonymous payments,” in Network and Distributed System Security Symposium (NDSS), 2017.
[15] M. D. Green and I. Miers, “Bolt: Anonymous payment channels for decentralized currencies,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, vol. 2016, 2017, pp. 473–489.
[16] D. Hofheinz and J. M¨uller-Quade, “A synchronous model for multiparty computation and the incompleteness of oblivious transfer,” in Proceedings of FCS. Citeseer, 2004, pp. 117–130.
[17] J. Katz, U. Maurer, B. Tackmann, and V. Zikas, “Universally composable synchronous computation,” in Theory of Cryptography Conference. Springer, 2013, pp. 477–498.
[18] R. Khalil and A. Gervais, “Revive: Rebalancing off-blockchain payment networks,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2017, pp. 439–453.
[19] ——, “Nocust–a non-custodial 2 nd-layer financial intermediary,” Cryptology ePrint Archive, Report 2018/642, 2018. https://eprint. iacr. org , Tech. Rep., 2018.
[20] A. Kiayias, H.-S. Zhou, and V. Zikas, “Fair and robust multi-party computation using a global transaction ledger,” in Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 2016, pp. 705–734.
[22] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,” in 2016 IEEE symposium on security and privacy (SP). IEEE, 2016, pp. 839–858.
[23] S. D. Lerner, “Drivechains, sidechains and hybrid 2-way peg designs,” 2016.
[27] G. Malavolta, P. Moreno-Sanchez, A. Kate, and M. Maffei, “Silentwhispers: Enforcing security and privacy in decentralized credit networks.” in Network and Distributed System Security Symposium, vol. 2016, 2017, p. 1054.
[28] G. Malavolta, P. Moreno-Sanchez, A. Kate, M. Maffei, and S. Ravi, “Concurrency and privacy with payment-channel networks,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, vol. 2017, 2017, pp. 455–471.
[29] P. McCorry, M. Mser, S. F. Shahandasti, and F. Hao, “Towards bitcoin payment networks,” australasian conference on information security and privacy, vol. 2016, pp. 57–76, 2016.
[30] A. Miller, I. Bentov, R. Kumaresan, and P. McCorry, “Sprites: Payment channels that go faster than lightning.” 2017.
[32] R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the permissionless model,” international conference on distributed computing, vol. 91, p. 16, 2017.
[33] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off-chain instant payments,” See https://lightning. network/lightning network-paper. pdf, 2016.
[34] P. Prihodko, S. Zhigulin, M. Sahno, A. Ostrovskiy, and O. Osuntokun, “Flare: An approach to routing in lightning network,” White Paper (bitfury. com/content/5-white-papersresearch/whitepaper flare an approach to routing in lightning network 7 7 2016. pdf), 2016.
[35] S. Roos, P. Moreno-Sanchez, A. Kate, and I. Goldberg, “Settling payments fast and private: Efficient decentralized routing for path-based transactions.” in Proceedings 2018 Network and Distributed System Security Symposium, 2018.
[39] M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scaling blockchain via full sharding,” in CCS ’18 Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 931–948.
[40] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier: An authenticated data feed for smart contracts,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, vol. 2016, 2016, pp. 270–282.