【论文笔记】Boros: Secure Cross-Channel Transfers via Channel Hub

原文：https://arxiv.org/pdf/1911.12929.pdf

学习一下人家的论文怎么写的

摘要：针对支付网络通道的主要问题——多条路由的交易需要路径上节点锁定一笔交易，来辅助完成这笔跟他无关的交易，这样的设计一方面限制了中间节点的资金流动性，一方面有时会导致死锁进而交易失败。多跳支付的路径越长，以上问题越明显。
论文设计了一个channel hub，是payment hub（Nocust）的拓展。在一个hub内的支付通道之间可以直接进行交易，作者设计了一个Boros协议，让跨支付通道的交易可以依赖channel hub，安全快速地进行。作者还使用UC框架对协议进行了形式化安全证明，提出了一套概念验证测试方案，来验证Boros的可行性，最终实验结果表明channel hub可以有效减少多跳路径长度。

1 介绍

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、论文的组织结构

2 背景和相关工作

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条链上交易。

3 本文工作 A. channel hub

主要参考NOCUST的工作，将payment hub扩展为channel hub。

payment hub主要包括两个部分：链上合约+链下中心化服务器。链上合约维护全局账本，负责争议处理；链下服务器负责处理自己所在hub的交易，更新hub内局部账本，定期更新到全局账本中。账本的结构就是一个map，key为账户地址，value是锁定资金余额。

channel hub的改进点就是发现单节点（外部地址）与支付通道（实际上是合约地址）的账户地址共享一个地址空间，即账本中的key既可以为单节点账户，也可以为支付通道账户。所以对NOCUST中的账本结构进行改造，让叶结点包含更多的信息，当叶节点代表一个通道的时候，要包含通道内部的最新状态信息等。

B. Boros的不正式描述

用处：进行跨支付通道交易，且保证无论如何（敌手遍布），诚实节点不会损失资金

例如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之间的消息交换类似

C. 敌手模型+Boros安全性保证

敌手模型：
敌手可以付出一些资金来搞破坏，可以控制多个节点（除了一个诚实节点，可以控制剩下所有节点），已经被控制的节点所在的hub和通道内账本状态都会暴露给敌手，可以代替被控制节点发送任意消息。假设诚实节点回一直保持诚实，不会被贿赂成为恶意节点。

Boros可以保证以下安全特性：
1、诚实节点们对于某通道或节点是否加入了channel hub总是能达成一致
2、诚实节点们对于某通道或节点在hub的余额总是能达成一致
3、诚实节点绝不会损失资金

D. 恶意情况分析

先来看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
解决方法跟上面的一样

4 UC框架下安全性分析

写在另一篇里面：https://blog.csdn.net/weixin_48288539/article/details/125316347

5 实验和分析

作者在以太坊实现了boros，并且计算了每个 *** 作的执行成本，实验的重点在于整个设计的可行性，未来会继续优化。进一步地，作者们在不同规模的链下支付通道网络运行了boros协议，证明了他们的设计可以很好地极少多跳交易路由的长度。

解释一下为啥要估算 *** 作的执行成本：在以太坊中，每笔交易的执行都需要支付gas费，用于给矿工的奖励，宏观上来讲就是EVM执行指令所花费的成本。交易是否会被及时执行，进入新块，很大一方面取决于交易发起方预设的gas费数量，gas费较低的话，矿工们不愿意执行交易，挣得太少。所以尽量减少链上 *** 作（EVM执行成本），就可以有效降低用户的交易费花费。

作者将对交易费的评估转移为对下列指标的评估：链上交易数量、执行成本（gas量、以太币数量、美元数量）、链下消息数量、签名数量。如表一所示，对应着前面的具体流程。

作者还实验显示了boros的多跳路由交易的路径更短。

表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.