Revive: Rebalancing Off-lockchain Payment Networks 阅读笔记

最新推荐文章于 2022-05-10 08:34:58 发布

YzYzYzzzzz

最新推荐文章于 2022-05-10 08:34:58 发布

阅读量2.8k

点赞数

分类专栏：论文阅读笔记文章标签：区块链

本文链接：https://blog.csdn.net/m0_46501404/article/details/117125200

版权

论文阅读笔记专栏收录该内容

16 篇文章 3 订阅

订阅专栏

Revive: Rebalancing Of-Blockchain Payment Networks（链下支付网络的再平衡）

一、文中总结的一些关键参考资料

Sprites（旨在解决最坏情况下的链外交易完成时间）： Andrew Miller, Iddo Bentov, Ranjit Kumaresan, and Patrick McCorry. Sprites:Payment channels that go faster than lightning. arXiv preprint arXiv:1702.05812,2017
Flare（提出路由策略，旨在优化平均花费在确定付款路线上的时间）： Pavel Prihodko, Slava Zhigulin, Mykola Sahno, Aleksei Ostrovskiy, and Olaoluwa Osuntokun. Flare: An approach to routing in lightning network. 2016
Duplex Micropayment Channels（双向微支付通道）： Christian Decker and Roger Wattenhofer. A fast and scalable payment network with bitcoin duplex micropayment channels. In Symposium on Self-Stabilizing Systems, pages 3–18. Springer, 2015.
Bitcoin Lightning Network （闪电网络）： Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant payments, 2015
Raiden Network（雷电网络）： Raiden network. http://raiden.network/
线性规划： H.A. Eiselt and C.L. Sandblom. Linear Programming and its Applications. Springer
Berlin Heidelberg, 2007.

二、论文重点内容摘录

在这里插入图片描述

上图是一个不平衡支付网络的举例。简单来说， $A\rightarrow C\rightarrow B$ 这条支付路径能够支付最多100的金额，而 $B\rightarrow C\rightarrow A$ 这条支付路径不能进行任何金额的支付，问题就出现在C节点的通道余额不平衡。
在作者这篇文章之前的支付网络平衡工作： Jameson Lopp. Lightning’s balancing act: Challenges face bitcoin’s scalability savior. http://www.coindesk.com/lightning-technical-challenges-bitcoin-scalability/
上图是树形结构的支付通道网，没有环形的通道，所以是无法运用，环路支付的方式进行Rebalance。
上图支付通道网络是存在环路结构的，所以是可以进行Rebalance的。

本文提出的Rebalance步骤：

$P$ ：参与者集合标识
$p$ ：参与者标识 , $p\in P$
$T_{s}$ ：参与者形成一个自我再平衡网络的时间点
实线虚箭头：需要leader回应的请求，以便让参与者参与协议
虚线虚箭头：参与者的回答
实线实箭头：不需要回复的请求
leader的选择： 第一个leader选择时，要求该参与者的ID要是所有参与者集合里最小的，第二轮时将选择第二小的参与者，以此类推，遍历完所有参与者之后再从第一个参与者开始循环选择。
上图的流程介绍：
1. 参与者向leader发送请求Rebalance的信号
2. leader向参与者发送Rebalance初始化请求
3. 参与者向leader发送确认参与Rebalance的确认
4. leader向参与者发送冻结通道的请求
5. 参与者冻结自己的通道并确认Rebalance的具体目标
6. leader向参与者发送完整的事务集
7. 参与者签名确认后发给leader
8. 如果参与者之间有异议产生的话就需要上链处理
Rebalance的具体步骤：
1. Triggering（触发）： leader 会等待网络中参与者的Rebalance请求，当请求的数量达到一定的伐值，则leader就会向参与者们发送启动Rebalance任务请求。
2. Participation（参与）： 参与者回复leader的启动请求，leader 制定并公布Rebalance的参与者名单，然后让名单上的参与者暂时冻结自己需要Rebalance的通道。
3. Transaction Set Generation（生成事务集） 参与者回复leader自己已冻结的通道，然后参与者需要跟通道共同拥有者达成共识（包括：冻结通道，通道余额，Rebalance方向）。leader需要计算出一系列的交易，这些交易需要保证每个参与者的总余额不变，且按照参与者的要求去Rebalance。
4. Consensus（达成一致）： leader将事务集和成员列表以承诺的形式发送给所有节点进行验证和签名。当leader收到所有人的签名之后他就会把这些东西广播给所参与者，这时候参与者就可以考虑解除账户冻结了。
5. Dispute（争议） 如果参与者对Rebalance的余额分配有异议的话，那么这个参与者就可以向链上进行申诉。总的来说如果在规定时间内leader以及所有参与者没有达成一致的话，那么他们的余额将会回到之前的最新状态。

Rebalancing Objectives：

$\Delta_{u,v}$ ：表示在通道 $u, v$ 上， $u$ 所愿意接受的，v向他转移的最大金额。（资金转移方向： $\rightarrow u$ ）
$\delta_{u,v}$ ：表示在通道 $u, v$ 上，进行Rebalance之后， $u$ 将要收到 $v$ 的转移金额。（资金转移方向： $\rightarrow u$ ）
注意： $\delta_{a,b}$ 和 $\delta_{b,a}$ 是不能共存的，一个通道中重平衡方向只能是单向的。
$∀_{u,v}: ∆_{u,v}> 0 \wedge ∆_{v,u} < 0 \Leftrightarrow 0 \leqslantδ_{u,v} \leqslant min(∆_{u,v},−∆_{v,u})$ :
1. $∀_{u,v}: ∆_{u,v}> 0 \wedge ∆_{v,u} < 0$ 表示在 $u v$ 通道上，余额平衡的方向是由 $v$ 向 $u$ 转移金额。
2. $\leqslantδ_{u,v} \leqslant min(∆_{u,v},−∆_{v,u})$ 表示当Rebalance事务执行完毕后， $u v$ 通道内 $v$ 向 $u$ 实际转移的金额是要大于0，小于u的期待值和v的欲付值中的最小值的。
$\forall u : \sum_{v}δ_{v,u}= \sum_{v}δ_{u,v}$
这个公式应该是表示v这个节点得到的金额和失去的金额是相等的（自己的总余额在Rebalance前后是没有变化的）
$\Delta_{u,v}$ 的计算公式： $\Delta_{u,v} = \frac{1}{2} (bal_{u}+ bal_{v}) − bal_{u}$ 化简后的公式为： $\Delta_{u,v} = \frac{1}{2}(bal_{v}-bal_{u})$
这个 $\Delta_{u,v}$ 并不是最终转移的金额，后面最后具体的转移金额是要用线性规划方法求解
（作者提到由于计算结果的精度很高，他们在处理数据时会将计算结果四舍五入，并假设造成的损失可以忽略不计）

从局部到整体的平衡假设：
在这里插入图片描述

由于链下支付通道数量很庞大，作者提到很难通过一次协议的运行去Rebalance整个网络的通道，所以通过并行的平衡局部节点的方式去达到平衡整个网络的目的（但是效果会稍微差一点），上图便是从局部到整体的Rebalance假设示意图。
a图是协议运行前的状态，b是协议运行后的状态。
方框旁边的虚线连接其他节点，绿色的无箭头边代表平衡的支付通道，红色带有箭头的边代表不平衡的通道。
从上图可以看出左边本来很多不平衡的通道，在运行协议之后变成右图这种比较平衡的状态了。

协议安全性的分析：

可能的攻击一：领导者发布不公平的Rebalance事务集，让某些诚实的节点失去他们原本的余额。
解决办法：每个参与者收到Rebalance协议之后，都会检查自己的总余额是否会变化，如果不会变化，那么他就会在协议上签名，如果变化了就不会在协议上签字，只有所所有参与者签字这个协议才会奏效，所以对于诚实的参与者来说是安全的。
可能的攻击二：攻击者发布的Rebalance方案对一些合伙人有利对其他人不利。
解决办法：任何感兴趣的参与者都将使用相同的随机种子重新求解线性规划，以验证商定的目标函数确实是优化的目标函数。