题目：Boros: Secure Cross-Channel Transfers via Channel Hub
摘要——支付渠道允许双方在不涉及区块链的情况下执行微支付，它已经成为提高比特币和以太坊等去中心化账本的一个有前途的可扩展性的方案。支付渠道已扩展到支付网络，用户可以通过现有渠道作为中介链接，将硬币路由到他人。然而，通过多个渠道路由支付并不承担重要的管理费用。它要求每个中介渠道锁定其部分可用容量，直到支付结算。这可能会导致并发情况下的死锁。支付路径中的中间节点也可以收取路由支付的费用。路由路径越长，上述问题就越严重。
本文设计并开发了一种新的链外系统来缩短支付网络的路由路径。特别地，我们提出了渠道中心，这是支付中心的扩展，允许将硬币从一个支付渠道直接转移到同一中心内的另一个。也就是说，通道集线器可以被视为底层支付网络的快捷设备。我们设计了一个名为Boros的新协议，通过信道集线器执行安全的离链跨信道传输。我们不仅正式地提出了Boros协议的安全定义，而且使用uc框架证明了它的安全性。为了演示Boros协议的可行性，我们开发了一个在以太坊上运行的概念验证原型。评估结果表明，该系统能有效地缩短链外路由路径。
1.介绍
自2008年比特币问世以来，去中心化加密货币在过去10年里获得了极大的欢迎。去中心化加密货币背后的关键创新是共识机制和区块链的结合。诸如POW和PBFT等共识算法的使用，使得其所有参与者都可以维护一个单一的账本，而不依赖于任何可信任的第三方。哈希链接的块链，也被称为区块链，提高了对试图缓和块内容的对手的计算需求。每个运行共识算法的矿工都需要解决一个计算代价昂贵的散列难题。
解决该难题的那个矿工被赋予向区块链添加新块的权利。受比特币的启发，其他允许用户开发和部署智能合约的加密货币也出现了，这些合约是用图灵完备的编程语言编写的，支持任意复杂性。支持智能合约执行的最著名的加密货币是以太坊，它使用Solidity作为其智能合约的开发语言。
然而，POW等全球共识机制的部署导致了分散加密货币的严重可扩展性问题。在目前的状态下，比特币最多只能支持每秒6到7个交易，而以太坊支持每秒20个交易，并且通过简单的重新参数化，没有数量级的吞吐量增长。如此低的交易吞吐量还远远不足以支持去中心化加密货币的广泛使用。相比之下，Visa每秒可处理多达47,000笔交易。
最近出现了许多尝试来缓解去中心化加密货币的可伸缩性问题，如替代共识机制[13]、[25]、[32]、分片机制[21]、[26]、[39]，可信执行环境[24]、[40]、侧链[2]、[23]，以及支付渠道/网络[7]、[29]、[33]等。特别是，支付通道允许双方私下执行微支付，而无需将所有支付都广播给区块链，从而大大提高了加密货币的可伸缩性。要开通支付渠道，双方需要向区块链广播一笔资金交易以及他们的存款。然后，支付渠道就开通了并且双方可以在不涉及区块链的情况下安全地进行链下交易。开通支付渠道的资金能力等于双方的定金总额。链下交易改变了双方之间的资金分配。在任何时候，每一方都可以决定关闭支付渠道，将资金的最终分配承诺给区块链，并将他们的现金收回到他们的账户。
支付渠道可扩展到 [33]支付网络。与其进行链上交易或建立昂贵的支付渠道，人们可以利用所谓的路由支付，即通过多个现有的中间支付渠道将支付路由，来将比特币转移给其他人。我们一直在努力实现更高效的支付网络。例如，Sprites[30]减少了链外支付的最坏情况下的担保时间。其他的[15]、[27]、[28]、[34]、[35]则专注于改善路由过程的并发性、安全性和隐私性等方面。
与TCP/IP网络等传统数据网络中的路由数据包不同，支付网络中的路由交易面临着更多的挑战。例如，通过多个支付渠道路由支付需要路径中的每个渠道都有足够的容量进行支付。此外，它还要求每个中介渠道锁定该渠道的部分可用抵押品，直到支付结算。然而，这可能会导致并发情况[28]中的死锁。另一个问题是，支付路径中的中间节点可能会为路由支付而收取费用。显然，路由路径越长，上述问题就越严重。
本文提出了一种新的链外系统来缩短支付网络的支付路径。首先，我们提出了渠道中心的概念，它是支付中心[19]的扩展。渠道中心的参与者因不同节点的支付渠道而异。它允许硬币直接从一个支付渠道转移到同一个渠道中心内的另一个支付渠道。因此，通道集线器可以被视为底层支付网络的快捷设备。与传统的节点级支付中心[19]相比，该渠道中心不需要额外的抵押品，并允许重用已建立的支付渠道中的存款。此外，它还可以以相同的成本受益于更多的节点。
其次，基于信道中心的思想，我们设计了一个名为Boros的新协议来执行安全的链外交叉通道转移，它允许硬币在双方之间进行转移。博罗斯协议保证一个诚实的一方尽管具有强大的对抗能力也不会承担任何经济损失。我们不仅使用Canetti[4]提出的通用可组合框架正式地给出了Boros的安全定义，而且还根据我们的定义证明了它的安全性。
第三，我们开发了一个运行于以太坊上的概念验证原型来演示Boros协议的可行性。我们测量了Boros协议在不同规模的支付网络中每次操作的执行成本，实验结果表明，该系统可以有效地降低平均支付路径长度。
论文的组织结构：在第二节中，我们提供了必要的背景资料，并回顾了关于支付渠道和支付网络的相关研究。我们在第三节中介绍了Boros协议的主要思想，并在第四节中给出了其使用uc框架的正式安全定义(由于页面限制，在附录A中提供了Boros协议的正式安全证明)。第五节报告了我们的概念验证实施和Boros协议对以太坊的评估结果。最后，我们在第六节中对本文进行了总结。
2.背景及相关工作
A支付渠道
支付渠道[7]，[33]允许各方在不涉及区块链的情况下私下进行转移，但仍保持诚实各方在任何时间收回其合法数量的资金。双方并没有将每笔付款都支付给区块链，而是将一笔融资交易及其存款一起广播给区块链，以打开一个支付渠道。开通的支付渠道的融资能力等于双方的存款总额。支付通道成功打开后，双方可以不接触区块链就可以安全地进行链外转移。支付渠道协议的核心是就双方最新的资金分配情况达成共识，防止恶意资金回流。Decker等人[7]使用基于区块链的时间锁使过时的资金分配失效，而闪电网络[33]则依靠惩罚来执行最新的分配。当他们中的任何一个人希望收回自己的资金时，他们就会向区块链广播一笔承诺交易，其中包括最终的资金分配，让区块链关闭支付渠道，并将现金拿回自己的账户。由于所有的中介转移都只由双方维护，而不需要写入区块链，所以支付渠道可以显著提高双方之间的交易吞吐量。网络带宽是事务速率的唯一限制。
关于支付渠道协议有几种改进建议。伯彻特等人在[3]的区块链和支付网络之间引入了一个新的通道工厂层，从而可以快速退还一个支付渠道。Green等人[15]提出用Bolt来构建保护隐私的支付渠道，同时降低支付网络上的存储负担。[10]等人设计Perun，建立一个中介连接的虚拟支付渠道。虚拟支付渠道允许这双方执行转移，而不需要中介确认每一个个人支付。这可以显著降低延迟和成本，同时提高隐私性，因为中介不能观察双方之间的个人转移。状态通道[11]允许离链的任意复杂的智能契约的执行。他们还提出了一种新的技术来递归地构建跨越多个账本或虚拟状态通道的虚拟状态通道。
B支付网络
没有支付渠道直接连接的双方可以利用现有的渠道作为在支付网络上路由硬币的中间链接，而不是开放昂贵的支付渠道或进行链上交易。
当通过多个中介渠道路由支付时，最关键的挑战是强制执行原子性。也就是说，要么更新路径中所有中间通道的容量，要么不更改它们。为了安全地跨多个支付通道进行传输，闪电网络[33]采用了一种被称为哈希时间锁合同(HTLC)的技术。
HTLC是一种条件合约，其中条件由区块链强制执行，因此它不需要信任网络中的任何参与者。该合约锁定了一部分硬币，只有当条件得到满足时，其接收方才能释放这些硬币，或者在合同超时时将其退还给其所有者。通过支付网络路由付款时，接收方生成一个秘密值 R，并将 R 的哈希值（表示为 y，其中 y = H（R））发送到路径中的所有中间节点。然后，每个中间通道使用哈希值y设置一个HTLC来锁定其硬币的一部分，该部分等于支付金额加上一些可选的路由费用。最后，接收者披露秘密值R以完成该付款并在每个中间通道释放锁定的硬币。
最近的研究进一步改善了支付网络。Sprites[30]减少了链外支付的最坏情况的担保时间。马拉沃达等人[28]提出了第一个针对支付网络的非阻塞协议，其中至少有一个并发支付可以最终完成，并对隐私和并发性之间的权衡进行了深入的讨论。Revive[18]是第一个针对链外支付网络的再平衡方案，它使扭曲支付渠道网络中的一组成员能够安全地在其支付渠道之间转移余额，以达到平衡状态。还有一些工作关注于提高分散支付网络中路由过程的效率和隐私性，如Flare[34]、沉默低语[27]和快速谋杀[35]。
C支付中心
TumbleBit[12]引入了支付中心的概念，它允许支付人向同一支付中心内的一组收款人执行安全的链外支付。付款是在一个不受信任的中介机构的帮助下进行的。它保证没有人，甚至连大酒杯都不能违反匿名性，并将付款人的付款与收款人联系起来。TumbleBit完全兼容比特币协议。然而，TumbleBit要求Tumbler为每个参与者打开一个定向支付渠道。然而，这将导致抵押物分散，并使支付中心的运营严重复杂化。
TumbleBit[12]引入了支付中心的概念，它允许支付者在同一个支付中心内对一组收款人执行安全的链下支付。在一个名为Tumbler的不受信任的中介的帮助下，支付是脱链的。它保证任何人，甚至是Tumbler，都不能违反匿名性，将付款人与收款人的付款联系起来。TumbleBit完全兼容比特币协议。然而，TumbleBit要求Tumbler为每个参与者打开一个直接支付通道。然而，这将导致抵押物分散，并使支付中心的运营严重复杂化。。
Khalil等人[19]提出NOCUST，允许其参与者的抵押物进行批量集中管理，从而显著降低支付中心的运营成本。NOCUST支付中心由两个基本组件组成：链上验证者合同和链外运营商服务器。链上的验证者合同是一个值得信赖的金融托管人。它维护着支付中心的所有参与者的担保品，并负责解决纠纷。链外操作员服务器定期执行每次传输，并定期与链上验证器合同进行同步，以保持一致性。NOCUST保证诚实的参与者能够始终保持对其资金的保管，并最终实现其实施的转让。
但是，节点级的支付中心不允许重用已建立的支付渠道中的存款。如果一个节点希望加入一个支付中心，它就必须提供额外的担保品，而不是在其支付渠道中重用现有的担保品。.在这项工作中，我们将支付中心的概念扩展到渠道中心，其参与者从单个节点到支付通道。它允许将硬币从一个支付渠道转移到同一渠道中心内的另一个支付渠道。在加入一个通道中心后，一个支付通道的存款可以用于跨通道传输和传统的通道内传输。值得注意的是，与支付中心相比，渠道中心可以在相同的成本下获得更多的节点。更准确地说，支付中心和渠道中心都需要一个链上交易以供参与者加入。但是，由于渠道中心的参与者是支付渠道，所以它允许支付渠道的双方从渠道中心中获益。
3.构造思路
我们采用NOCUST[19]的构造，将支付中心的概念扩展到渠道中心，允许在同一渠道中心内将硬币从一个支付渠道转移到另一个支付渠道。在这里，我们只给出了支付中心的一般描述，并描述了支付中心和我们的渠道中心之间的差异。有关更多细节，我们请向读者咨询[19]。
支付中心由两个基本组件组成：链上验证器智能合约（简称VU/）
和链外运营商服务器（简称OU/）
。链外运营商服务器是一个充当金融中介的交互式服务器，也就是说，在支付中心内执行的所有链外转移都需要由运营商服务器中继和批准。同时，运营商服务器维护一个本地分类帐本BL，其中包含其参与者的余额以及与通过链外运营商服务器（简称OU/）执行的传输相关的所有信息。BL中的信息定期提交给全局账本BG，该账本由链上验证器（VU/）维护，以保持全局一致性。除了维护全局分类帐本BG，链上验证器（VU/）还作为恶意参与者甚至不诚实运营商服务器的争议解决器，以保证诚实参与者的平衡监护权，并执行已实施的转移。
支付中心的核心是一个映射：{0,1}λ→N0，其中固定长度的二进制字符串{0,1}λ表示每个参与者的帐户，N0表示它的余额。推动我们扩展的关键观察结果是，单个节点（称为外部账户）和支付渠道（称为合同账户）的账户共享相同的地址空间。换句话说，外部帐户和合同帐户都由一个固定长度的二进制字符串{0,1}λ表示。因此，我们的扩展可以这样来完成，简单地通过让{0,1}λ表示支付渠道的合同账户，而N0表示其融资能力。具体地说，我们修改了用于NOCUST[19]的 Merklelized interval tree （TU/ ）的数据结构，以便于（TU/ ）树上的每个叶子的存储信息对应于支付渠道βi，这棵树主要是由渠道合同账户αi，融资能力ci，渠道βi参与的最后更新ui组成的。
B：Boros协议的非正式描述
在本节中，我们将非正式地描述Boros协议的基本思想，它使用渠道中心来执行安全的点对点跨信道传输。Boros协议旨在防止任何诚实的节点损失资金，尽管有一套强大的对抗能力。
假设A希望将∆x硬币转移到B。这可以首先使用通道βAC将∆x硬币转移到通道βBD，然后更新通道βAC和βBD的存款分布，使βAC.balance(A)−=∆x；而βBD.balance(B)+=∆x，而C和D的余额保持不变。关键问题是在整个过程中加强平衡的一致性。
我们首先描述了在各方都诚实的情况下跨渠道转移的整个过程。图1显示了该协议的消息流。我们假设通道βAC和通道βBD都已经加入到同一个通道中心（HU/）中。Boros协议包括三个阶段，即准备阶段、容量转移阶段和通道内更新阶段。
在准备阶段，A向C发送一个消息Mpcc，表明A希望将他的∆x硬币从通道βAC转移到通道βBD，同时保持C在βAC上的balance不变。“pcc”一词是“准备跨通道传输”的缩写。当C接收到Mpcc时，C将检查消息Mpcc的有效性，并将消息Mgcc广播给A、B和D，这表明C同意该交叉通道传输。“gcc”一词是“授予跨通道转移”的缩写。B和D之间的相互作用被类似地处理。在准备阶段结束时，A、C、B和D应该保存消息MACgcc和MBDgcc。
在容量转移阶段，A、B分别代表通道βAC和通道βBD，通过通道中心(HU/)在通道βAC和通道βBD之间进行硬币转移。这里我们跟踪NOCUST[19]的操作。首先，A将Miou发送到链外运营商服务器（OU/）。链外运营商服务器（OU/）然后检查Miou的有效性，通知B并等待B的接收。当链外运营商服务器（OU/）通知B时，它还将验证Miou的有效性，然后用签名收据回复。在收到B的收据后，链外运营商服务器（OU/）确认了IOU的执行，并将Mconf发送给A和B。此时，容量转移阶段已经完成。βAC通道的融资能力减少∆x，βBD增加∆x。
在通道内更新阶段，通道βAC和通道βBD都需要更新balance的分布，以保持一致性。具体地说，在通道βAC中，A的balance应该减少∆x，而C的balance保持不变；在通道βBD中，B的balance应该增加∆x，而D的balance保持不变。
以通道βAC为例，在这个阶段，A向C发送一个表示容量传输阶段结果的消息Micu。单词“icu”代表“通道内更新”。当容量转移阶段成功时，消息Micu将包含关于A的balance减少的信息。否则，Mmicu会告诉C不要改变A的balance。在收到Micu后，C检查该消息的有效性，然后用确认确认回复。B和D之间的相互作用以类似的方式处理，然后完成整个转移。
C安全属性
在本节中，我们将描述我们的协议的威胁模型和安全属性。
威胁模型：我们假设存在一个非理性的对手，他们愿意失去部分甚至全部的资金，从而使诚实的各方承担经济损失。这个非理性的对手可能会控制参与跨渠道转移的参与者，除了一人。腐败党的内部状态和以下所有通信都暴露在对手面前。此外，对手可以代表腐败的一方发送任意的消息。另一方面，我们假设诚实方之间的沟通渠道和诚实方身份的完整性不会被对手破坏。
针对上述威胁模型，我们的协议保证了以下安全属性：
就渠道中心的注册和退出达成共识。我们的协议保证，诚实的各方总是可以就一个支付渠道是否已经加入或退出了一个渠道中心达成共识。
渠道容量共识。我们的协议保证诚实的各方能够了解其支付渠道的融资能力。也就是说，一个诚实的一方总是可以了解每个涉及它的跨通道传输的结果
余额安全。直观地说，余额安全保证了一个诚实的一方不会失去他的任何硬币，尽管他有强大的对抗能力，也就是说，一个诚实的一方不会承担经济损失，即使所有其他参与跨渠道转移的参与者都是恶意的。
C不当行为的简要证明
我们现在调查如果某些一方是恶意的会发生什么。让我们首先考虑准备阶段，其主要目的是就A、C、B和d之间的以下转移达成协议。也就是说，这四方在这个阶段结束时应该同时接受mACgcc和mBDgcc。如果存在不发送或回复消息的恶意方，那么一定有人未能收集这两条消息。现在我们讨论以下情况：（1）A不能获得这两个消息。（2）B无法收集这两条消息。（3）C或D无法收集这两个消息。
对于情况（1），其后果是很明显的。如果A不能同时收集MACgcc和MBDgcc，那么他将无法在下一阶段构建消息Miou，这就导致了整个传输的终止。对于情况（2），B是相当宽容的，因为B在收到通道中心（HU/）的通知时，仍然可以从Miou中得到MACgcc和MBDgcc。情况（3）要复杂得多。在这种情况下，C或D不能确定是否准备执行此转移。在最坏的情况下，他们无法知道是否执行了转移。为了消除不一致的可行性，我们不允许任何一方同时参与多次转让。此外，我们引入T来表示最大传输持续时间。当转移开始时，一方应该在T。否则，它会向渠道中心投诉。例如，如果C不能从A得到该传输的结果，那么他将等待，直到T到期，并向通道中心发送一个强制回复消息Mfr。一旦收到消息mfr，通道中心就会通知A，C投诉你了，要求A在固定的时间∆内提供结果Micu。如果A用包含βAC通道资金能力的有效micu及时回复了，通道中心则将Micu转发给C，以便C可以继续进行。否则，通道中心（HU/）认为渠道βAC无响应，然后关闭它，根据跨渠道转移的结果返还现金。
在容量转移阶段，硬币通过通道中心从通道βAC转移到通道βBD。NOCUST[19]保证，一个诚实的P方能够始终保持对其资金的保管，并确保其已实施的转移在渠道中心内正确交付。这种保证适用于我们的通道中心在相同的攻击者模型下。简而言之，NOCUST允许一方P向上链验证者合同V6⊂打开所谓的“平衡更新挑战”和“转移交付挑战”，以强制执行安全保证。前者挑战P（诚实的一方）平衡的完整性，后者挑战渠道中心中链外转移的完整性。有关安全分析的更多细节，我们请向读者咨询[19]。
在通道内更新阶段，通道βAC和通道βBD都需要更新其平衡分布，以保持一致性。在此阶段可能发生的例外情况包括：（1）A不诚实，不将结果Micu发送给C；而（2）C是恶意的，不用确认Mconf回复A。对于情况（1），A不诚实，故意向C隐瞒容量转移阶段的结果，因此C无法确定渠道βAC的融资能力。正如在准备阶段所讨论的，在这种情况下，C只是等到T到期，然后向通道中心（HU/）投诉。对于情况（2），C从A得到Micu，但没有用确认Mconf回复。这种情况类似于（1）。为了解决这个问题，A只等到T到期，然后联系通道中心（HU/）来执行C的确认。
4.形式化描述
通用可组合模型：在UC（通用组合模型）中，协议的安全性是通过比较真实模型中协议的执行情况与理想过程来定义的。在现实模型中，n方协议π由一组各方P∈{P1，P2，…，Pn}执行，该协议被建模为概率多项式时间(PPT)机。在现实世界中存在一个对手A，他可以腐败这些方，使内部状态和腐败方的所有未来行动完全被对手控制。为简单起见，我们只考虑静态腐败，这意味着对手A必须在协议执行开始时决定哪些方要腐败。要腐败的这些方和对手A都接收到环境Z的输入和输出，它用于建模当前协议执行外部的所有因素。在理想世界中，环境Z通过所谓的虚拟方与理想功能F交互，虚拟方简单地将消息从（外部环境）Z转发到（理想功能）F，然后再返回。对手A对应的对手在理想世界是模拟器s，然后我们说协议π被认为是安全的，如果环境Z不能区分它是和对手A交互并且π运行在现实世界模型；还是与模拟器S交互，并且理想的过程的理想功能F。
通信模型：为简单起见，我们假设采用同步通信模型，即各方同步进行，各方同步启动。在这个模型中，每个方都可以向所有其他方发送消息，在i+1轮开始时，i轮发送的消息就已经到达目的地。当涉及到理想功能时，我们简单地假设理想功能的计算和与理想功能的通信是瞬时的。该同步通信模型可以通过一个全局时钟功能来实现。有关详情，请参考[16]，[17]，[20]。
分类帐功能FL：在[9]之后，我们将全局分类帐建模为一个理想的功能FL。FL的内部状态由一个公共访问的帐户空间组成，表示为B：αi→pi，其中αi∈{0,1}λ表示外部帐户或合同帐户，pi∈N0表示帐户αi的余额。分类帐功能FL提供了以下接口：
===转账（transfer）接口，允许通过发送消息(transfer,sid,αi,αj,p)将p硬币从账户αi转账到αj。
为了简化表示法，我们假设每个理想的功能Ff都有一个特殊的帐户αf。当我们说理想的功能Ff从a接收到消息m和p硬币时，我们实际上是指在接收到消息m时，理想的功能Ff向分类账FL发送一个消息(transferred，sid，αA，αf，p)。类似地，当我们说理想的功能Ff将p硬币发回A时，我们实际上的意思是Ff向FL发送一个消息(transfer，sid，αf，αA，p),transfer接口还允许模拟器S模拟“不理性”的方，他们愿意牺牲自己的资金，导致诚实的方失去部分或全部资金。在这种情况下，我们只需让S把硬币从非理性方的账户转移到诚实方的账户上。我们注意到，上面提到的理想分类账FL仅捕获了全局账本的基本理想概念，以便于说明。在[22]中可以找到更准确和更真实的全局账本形式化。
渠道中心功能FN：在图2中，我们概述了渠道中心FN的理想功能。渠道中心功能FN维护一个渠道空间N：βi→ci，其中βi∈{0,1}λ表示βi通道的合同账户，ci∈N0表示βi通道的融资能力。当我们说一个支付通道β被标记为已连接时，我们的意思是一个与通道β对应的条目被添加到N中。类似地，当我们说一个支付通道β被标记为被撤回时，我们的意思是将与通道β对应的条目从N中删除。渠道中心的功能FN为其他理想功能提供连接和退出接口，并为各方提供接口传输。（1）连接（join）：当由一个连接请求和来自理想功能的c硬币一起触发时，其中c表示通道β的资金能力，理想的功能FN将通道β标记为连接。（2）传输(transfer)：在收到来自A的iou请求(iou，βAC，βBD，∆x)和来自B的签名收据后，FN将∆x硬币从通道βAC移动到βBD。（3）退出（withdraw）：支付渠道βi可以通过向FN发送退出请求，随时从频道中心退出。理想的功能FN最终将ci硬币送回β的合同账户，并标记通道βi退出。
合同功能FC：在图4中，我们概述了合同功能FC，这是部署在区块链上的支付渠道合同的理想功能。合同功能FC维护活动的合同实例集。每个合同实例都对应于一个支付渠道。当支付通道打开时创建合同实例，并在支付通道关闭时移除合同实例。合同功能FC为各方提供了开放、加入、退出和关闭的接口。
UC对安全性的定义：让Boros成为一个可以访问全局分类账功能FL、渠道中心理想功能FN和合同功能FC的协议。在安全参数λ上，与Boros和对手A交互的环境Z的输出∈ N，辅助输入x∈ {0, 1}∗
表示为EXECFL、FN、FC Boros，A，Z（λ，x）即
。在理想的世界范围内，我们使用IDEALFL，FN，FC FH，S，Z（λ，x）来表示Z的输出
，运行在理想功能FH和模拟器S上。
定义1：让λ∈N是一个安全参数，让x∈{0,1}∗是一个辅助输入，Boros是一个在(FL，FN，FC)混合世界中运行的协议。如果每一个对手A存在一个模拟器S，对于所有PPT环境Z：
那么我们就说协议Boros实现理想的功能FH。其中
“≈”表示计算不可分辨性。
A理想的功能FH
如图3所示，理想的功能FH维护了两个通道空间。其中的一个通道空间中由尚未加入通道中心的支付通道组成。我们表示为B：β→{c，θw}，其中β∈{0,1}λ，表示β通道的合同账户，c∈N0表示β通道的资金能力，θw表示其总资金的分布函数对应的版本数w。例如，在通道βAC中，我们使用θwAC(A)表示A的balance，使用θwAC©表示C的balance，对应的版本号为w。我们注意到，当它不影响表达式的清晰度时，我们经常会省略上标。此外，我们总是有c=θw(A)+θw©和θw(Pi)≥0。单调递增的版本号w用于跟踪支付通道中的每一次转移，最初设置为1。另一个通道空间，记为(BU/)
：β→{c，θw}，由已经加入通道中心的支付通道组成。当我们说一个支付通道β被标记为连接时，我们的意思是通道β已经从通道空间B移动到（BU/）。同样地，支付通道β被标记为撤回，意味着通道β已从（BU/）移回B。
理想的功能FH为双方提供了以下接口：（1）在双方之间打开了一个支付渠道。当分别收到来自A和C的开放请求以及Xa和Xc硬币时，打开一个融资能力c=Xa+Xc的支付通道βAC。（2）通道内传输。执行链下转移的两阶段过程。当由A通过更新请求触发时，FH要求C确认该传输。一旦C回复了他的确认，FH就更新通道βAC的分布函数和（更新）后的输出结果。（3）加入一个通道中心。只有当双方达成协议且支付通道尚未加入任何通道中心时，支付通道才能加入通道中心。当由A通过加入请求触发时，FH要求C确认该加入。一旦C回复了他的确认，FH将βAC标记为加入，并通过消息（joined）通知结果。
（4）跨通道传输。它只能在已经加入到通道中心的两个支付通道之间执行。这个过程被分为三个阶段。在准备阶段，通道βAC和通道βBD都应就此转移达成协议。在容量转移阶段，如果FH同时接收到来自A的iou消息和来自B的接收，则FH更新其内部状态，使通道βAC的资金容量减少∆x硬币，βBD增加相同的硬币。我们注意到，在这一阶段结束时，βAC通道和βBD通道的分布函数都保持不变。最后一个阶段分别由来自A和B的通道内更新请求触发。FH要求C和D进行确认，最终导致βAC和βBD通道的分布函数发生变化。（5）退出通道中心。只有当支付通道已经加入到通道中心中时，支付通道才能退出通道中心。当接收到来自A或C的退出请求时，FH最终将通道βAC标记为退出和输出（withdraw）。我们理想的功能保证了一个诚实的一方总是会设法在一个固定的时间内从通道中心退出它的支付通道。（6）关闭一个支付通道。当被A或C的关闭请求触发时，FH最终在三轮内用θ(A)硬币退款a并用θ©硬币退款c。我们理想的功能保证了一个诚实的一方将总是设法关闭支付渠道，并在一个固定的时间内获得退款。
现在，我们将讨论我们理想的功能FH如何满足第三节-C节中提到的安全属性.
就通道中心的注册和退出达成共识。一旦支付通道加入或退出通道中心，理想的功能FH将通过消息（joined）、（withdrawn）或（join-failed）通知所有各方结果。因此，很容易看出这个属性总是成立的。
通道容量共识。支付通道的初始融资能力在成功打开该渠道时，由理想的功能FH确定并通知。此外，FH保证通过消息Mct通知诚实的一方。因此，诚实的一方总是可以了解其支付通道的融资能力。
Balance安全。对balance安全性的分析包括两点。一是对支付通道的融资能力的共识。二是对支付通道的最终分布式函数（ distribution function）的共识。前者已经在上面讨论过了。对于分布式函数，FH总是保证在关闭支付通道时，较大版本号w的分布式函数获胜。因此，在关闭支付通道时，总能保证具有最新分布式功能的诚实的一方得到正确数量的硬币支付。
B Boros协议
现在，我们正式描述了Boros协议，它包括如图4所示的合同功能FC，以及如图5和图6所示的所有相关各方的行为规范。
我们首先讨论那些与传统支付渠道共享的操作，如图5所示。为了打开一个支付渠道，A用Xa硬币部署了一个新的合约FC实例。在构造时，合约FC用opening请求通知C。一旦合同在第2轮中得到C和Xc硬币 的确认，支付渠道βAC就被打开。否则，合同FC会将Xa硬币退还给A并输出（open-failed）。
一旦支付通道βAC被打开，A和C就可以不涉及区块链而进行通道内传输。首先，A向C发送一个更新请求，其中包含一个新的分发函数θw+1。当C接收到该请求时，应检查通道βAC容量的有效性，即θ(w+1)(A)+θ(w+1)©应始终等于通道βAC的最新容量。如果是这种情况，那么C就会向环境Z发送一条消息（更新-请求），询问它是否同意进行更新。如果环境响应（更新-确定），那么C发送A并确认完成通道内传输。我们强调，对通道能力的有效性检查是必要的，因为我们的支付通道的融资能力可以通过跨渠道转移来改变。
要关闭close支付通道βAC，A向合同实例FC发送包含其最后一个分布式函数θw1的关闭请求。在收到A的关闭close请求后，合同将该请求转发给C。如果下一轮C用它最后的分布式函数θw2答复，则合同FC选择最新的一个，记为θw的w=max(w1，w2)，并根据θw将硬币发回A和C的帐户。否则，根据θw1，合同FC会将硬币发回A和C的账户。
然后我们讨论这些扩展的操作，如图6所示。我们从加入的过程开始。要加入一个通道中心，A将发送一个包含目标通道中心实例（HU/）的消息，即资金容量c，即通道βAC最新的分布式方法θw，把A的签名a给C。在接收到来自A的加入请求后，C向环境Z发送一条消息（加入请求），询问它是否同意该加入。如果环境响应为(join-ok)，则C就会将包含A和C的签名的连接请求发送到合同FC。一旦合同收到来自C的带签名的加入请求，它就会将带有C硬币一个加入请求一起发送到通道中心FN，以完成加入过程。否则，将认为连接过程失败。
现在我们讨论跨信道转移过程，它被分为三个阶段。在第一阶段，A向C发送一个消息Mpcc，表明它打算进行跨通道转移，通过通道中心（HU/）将通道βAC中A的balance移动∆x硬币到通道βBD上。 当C从A接收到Mpcc消息时，它会检查通道βAC中A的balance是否超过∆x。如果不是这样，那么C将拒绝跨通道传输请求。否则，如果C同意该传输，那么他将在Mpcc上附加他的签名以产生Mgcc，这表明C对该跨通道传输的许可。然后C将消息Mgcc广播到A、B和D，然后进入第三阶段。B和D之间的相互作用被类似地处理。在容量传输阶段，启动器initorA向通道中心（HU/）发送一条iou消息。如 channel hub functionality FN中提到的，, the channel hub (HU/)将iou请求转发给B，获得B的签名收据，然后执行该传输。该执行将导致βAC频道的融资能力减少∆x硬币，而通道βBD增加了相同的数量。如果执行成功，则通道中心（HU/）将通过消息Mct同时通知A和B关于执行结果。在通道内更新阶段，A将第二阶段的结果发送给c。A发送的消息应该包括一个新的分布式函数θw+1，以便θw+1(A)=θw(A)−∆x并且θw+1©=θw©，以及来自信道中心（HU/）的运营商服务器的签名结果。在收到此消息后，C检查其有效性，并回复一个确认，以完成跨信道传输。
最后，我们讨论了退出程序。要退出渠通道中心，A将向合同FC发送一条包含通道βAC的最新融资能力c和分布式功能θw的消息。在收到A的退出请求后，合同FC会通知C该退出请求。一旦收到来自C的签名回复，合同FC将向通道中心FN发送一个退出请求，以完成退出过程。
C安全定义
现在，我们正式声明了我们的Boros协议的安全性。由于页面限制，正式的安全证明在附录1可查看。
定理1：协议Boros安全地实现了(FL、FN、FC)混合模型中的功能FH。
5.实施和评价
我们在以太坊上实现了Boros协议，并测量了Boros协议中每个操作的执行成本。请注意，我们目前的实现旨在证明Boros协议的可行性，我们将在未来的工作中进一步优化它。此外，我们模拟了不同规模的链外支付网络，证明了我们的构建可以有效地缩短平均事务路径长度。
以太坊使用气体来测量用于执行某些操作的计算资源的量。由以太坊虚拟机(EVM)执行的每条指令都需要消耗一定量的气体。天然气和乙醚之间的转换没有固定的价格。由事务的发送方来指定天然气价格，这将影响矿工处理事务的意愿。较低的天然气价格会导致等待事务被挖矿的时间更长。平均汽油价格通常在20克威(或2×10−8Ether)左右。当我们准备本文时，乙醚对美元的汇率是1：243.2。也就是说，
我们的评估采用了以下标准：链上事务的数量、以气体、乙醚和美元衡量的执行成本、链外消息的数量和签名的数量，这在消息长度和计算复杂度方面都占主导地位。表I显示了在这些度量标准下的每个操作的执行成本。
然后，我们模拟了不同大小的支付网络，以评估我们的construction对缩短平均路径长度的有效性。特别是，我们控制了总体的施工成本，然后测量了每种方法的平均路径长度。我们首先建立一个不同规模的底层支付网络，然后(a)开放额外的支付通道，(b)建立一个或多个支付中心，©建立一个或多通道中心。我们确保上述设置彼此之间的成本相同。为了与裸支付网络进行比较，由于连接操作的执行成本在天然气成本方面类似于打开一个新的支付通道（见表一），所以我们在底层支付网络上随机打开相同数量的支付通道。然后，我们从Ripple数据集[36]中提取事务，并在这些设置中重播reply它们。为了找到每个事务的路径，我们分别使用SpeedyMurmurs[35]算法和Floyd-Warshall最短路径算法。
对于只有一个通道中心的情况，由于支付/通道中心不能容纳太多的参与者（受运营商服务器的限制），我们建立了小型支付网络，节点数在200到1000之间。一个重要的系统参数是节点数与支付通道的比值，它决定了支付网络的密度。事实上，支付网络的密度越高，节点之间的平均路径长度就越低，部署通道中心的必要性就越少。我们参考Ripple数据集[36]和Lighting网络[1]。在准备本文时，Ripple数据集包含67149个节点和199574条边，比例为2.97，闪电Lighting网络包含8655个节点和34696条边，比例为4.0。我们选择4作为支付网络的节点数与支付通道的比率进行模拟。另一个重要的系统参数是连接比率，记为α，它表示有多少参与者将被加入到支付中心和通道。表二显示了只有一个通道中心的仿真结果，其中PN表示“支付网络”，PH表示“支付中心”，CH表示“通道中心”，FW表示Floyd-Warshall最短路径算法，SM表示SpeedyMurmurs路由算法。∆1对应于我们在支付中心上的构造改进，∆2对应于在支付网络上的推广。
对于多通道中心的情况，可以进一步扩大底层支付网络的规模。我们模拟了5000个节点和10000个节点的支付网络。在这些情况下，我们限制每个通道中心的最大参与者数量，表示为k，范围从100到200，然后创建多个支付中心和通道中心。通道中心的数量可以很容易地通过【n*a/k】计算出来，其中n表示支付网络的大小。同样，我们将底层支付网络的节点数与支付通道的比值设置为4，并测试不同的α和k对平均路径长度的影响。仿真结果见表2。
6.结论
在本文中，我们提出了通道中心来支持直接从一个支付通道转移到另一个支付通道。在此基础上，我们设计了一种名为Boros的新协议来执行安全的链外跨通道传输。Boros协议保证，一个诚实的一方尽管具有强大的对抗能力，但也不会承担任何经济损失。我们正式地给出了Boros协议的安全定义，并使用uc框架证明了其安全性。此外，我们在以太坊上开发了一个原型，并测量了Boros协议中每个操作的执行成本。我们对不同配置的支付网络的评估表明，我们的协议可以有效地缩短链外路由路径。在未来的工作中，我们将研究如何优化通道中心（channel hub）。例如，在当前的设计中，通道中心中的所有事务都由运营商服务器完全排序并执行，但也有相当数量的事务可以部分排序。利用这一观察结果可以提高性能。