本文属于老雅痞原创文章，转载规矩不变，给我们打声招呼～
转载请微信联系：yaoyaobigc，更多DAO、Web3、NFT、Metaverse资讯请关注老雅痞👇
导读
今日FastDaily共推送3篇文章。
我们知道，闪电网络上的支付在数学上对应于(最低成本)流量，本文中所讨论的，损耗是支付失败和降低网络可靠性的主要原因。
第一条是对项目 EFFORCE 的原创分析文章。 从创始人，行业背景，技术层面，解决什么问题等方面，告诉你这个项目的方方面面。
疫情让全球咻的一下进入了远程分布式办公的时代，再加上Web3的buff，仿佛一切都可以上网上链，各行各业都跃跃欲试。房地产租赁也不例外。终于不用在办公室打卡坐班，人们设想了一种可以边旅行边工作的生活模式。第三条是对这样一个把房屋所有权与租赁相结合，带动了房地产的流动的项目Worldhaus的原创分析文章。
RR丨编译
简介和动机
我们知道，闪电网络上的支付在数学上对应于(最低成本)流量，而闪电服务提供商将流动性作为实现合理高服务水平目标的一个主要主题。此外，众所周知，渠道经常枯竭。当向一个方向的发送比向相反方向多时，就会发生损耗。正如我们在本文中所讨论的，损耗是支付失败和降低网络可靠性的主要原因。
目前，从事流动性管理的闪电节点运营商主要通过以下两种策略来缓解渠道损耗带来的问题：
补充枯竭的渠道：已知有几种技术可以重新填充流动性。节点运营商可以进行循环支付或进行链下swap。此外，渠道可以被关闭和重新开启，或者可能存在一个未宣布的并行影子渠道。未来对协议的改进也可能允许将新的流动资金注入渠道。所有这些机制的特殊之处在于，它们对节点运营商来说成本高昂。此外，在全球范围内，使用链上交易进行此类操作的可能性非常有限，因为区块空间稀缺，而且Mempool的拥堵高峰可能不仅会大大增加此类策略的成本，还会延迟它们的执行。
减少损耗/寻找平衡渠道：CLBOSS等工具试图收取节点在其渠道上就损耗收取的路由费用。这种理念主要可以归结为一个经济论点：如果一个运营渠道出现流失，这意味着对流动性存在需求，因此提高路由费用一方面会增加收入，另一方面可能会降低需求，减少流失。遵循类似的理念，协议开发人员建议在协议中添加负费用和各种费率卡。
在本文中，我们将看到似乎有第三种非常有前景的策略来建立更好的流量控制(流动性管理)，它已经被嵌入到协议中' channel_update '消息中的' htlc_maximum_msat '字段。我们展示了' htlc_maximum_msat '可以并且应该作为一个阀门来实现流量控制。我们注意到，目前几乎所有的渠道都将“htlc_maximum_mset”设置成了其渠道容量，或者在两个方向上都具有相同的值。我们将说明，这两种设置都是不可取的，因为它们往往会放大具有一定消耗的渠道的消耗。根据这些统计数据，我们假设截至本文撰写时，几乎没有节点会主动利用我们在本文中提出和讨论的机会。
阀门是一种通过打开、关闭或部分阻塞各种渠道来调节、引导或控制流体流动的装置或自然物体。在开启的阀门中，流体沿高压向低压流动。现代控制阀可以调节下游的压力或流量，并在复杂的自动化系统上运行。
作为一个阀门，“htlc_maximum_msat”理论上具有显著降低网络中预期支付失败率，并导致渠道平衡的潜力。
在继续解释“htlc_maximum_msat”如何充当控制阀之前，关于平衡渠道有一个重要的附带说明：有一种广泛的误解认为如果一个渠道中50%的流动性属于每个peer，那么这个渠道就是平衡的。我们已经证明，50/50的渠道是不可取的，实际上也几乎不可能实现和维持。你可以想象一下西西弗斯的神话，人们可能会重新平衡一个渠道，使其达到50/50的平衡，但却发现渠道上存在流失，渠道再次枯竭。因此，平衡渠道的一个更好的定义是，当且仅当流动性分布接近均匀分布时，渠道才是平衡的。
' htlc_maximum_msat '作为缓解(高)流失支付渠道上的流动性枯竭的阀门
现代控制阀可以调节压力或流量。与支付渠道的压力相当的是它的消耗。我们将Alice在她与Bob的渠道上的消耗定义为Alice应该转发给Bob的付款与渠道上发生的所有支付请求的比值。消耗值0.9意味着如果在渠道上有10个支付转发请求，其中9个请求要求Alice将sat转发给Bob。同时，只有一个支付请求要求Bob向Alice发送sat。在短时间内，我们假设所有的支付都是同等规模的。很容易看出，由于来自外流的压力，大部分流动性将很快到达Bob所在的渠道一端。这也将导致Alice无法完成大多数支付路由请求。这可以在操作过程中被测量和观察为渠道上的高支付失败率。
由于我们可以把渠道上的流出看作压力，并且从现实世界中了解到通过网络的流量可以由控制阀调节，所以我们应该在闪电网络上寻找这样的阀门。如果预期10次支付中有9次是从Alice支付给Bob，那么Alice可以采取的降低渠道失败率的明显措施就是减少她愿意转发的付款的规模，并限制在满足支付请求时从渠道中被消耗的流动性。这可以通过在gossip协议上通过' channel_update '宣布一个较低的' htlc_maximum_msat '值来实现。这有效地降低了从Alice到Bob的渠道吞吐量。
以下是我们所知的第一个数学上合理的描述和分析，它解释了控制阀对闪电网络的影响。虽然目前绝大多数节点似乎忽略了使用' htlc_maximum_msat '作为阀门的潜力，但我们注意到使用' htlc_maximum_msat '的想法并不新鲜。一些运营商一直在考虑通过“htlc_maximum_msat”来显示渠道中可能有多少可用或剩余的流动性。
有了这些动机和直观的描述，让我们深入研究付费渠道的数学计算，以研究使用阀门实现更好流量控制的潜力：
马尔可夫过程用于描述具有给定流量的支付渠道中的流动性的不确定性。
假设Alice和Bob之间有一个容量为c的渠道。这意味着在任何给定时间，Alice在渠道中的流动性可以是0,1,...,c-1或c satoshis。像往常一样，为了简化表述，我们忽略了渠道储备和运行中的htlc。我们将Alice的sat建模为有限马尔可夫过程的一种状态。马尔可夫过程具有c+1个状态，Alice可以将这些值中的任何一个作为她的流动性。
在短时间内，我们做了一个强有力的简化假设，即渠道上的支付只能是1个satoshi大小。
如果Alice有a sat的流动性，马尔可夫过程将处于a状态。此外，我们将渠道的流失视为Alice应发送给Bob的付款中与渠道上请求发送的所有付款相关的部分。
这意味着对于a在1和c-1之间的任意值，我们有以下两个转移概率。
P(X=a-1| X=a)=1-d
P(X=a+1|X=a = d
我们可以用下面的图表来直观看到这一点：
如果渠道的容量是无限的，我们可以将其建模为随机游走。然而在闪电网络中，渠道的容量是有限的，因此我们必须看看当我们到达(耗尽)渠道的极限时，马尔可夫链会发生什么。在这种情况下，付款不能被转发，状态也不会改变。在数学公式中，这意味着：
P(X = 0 | X = 0)= 1 - d
P(X = c | X = c) = d
从视觉上看，容量为5的渠道如下图所示。
请注意，唯一的区别是在状态0中，Alice没有sat，保持状态的概率等于“1-d”，而状态“c=5”中，Alice有“5”个sat，保持状态的概率等于流失的“d”。
马尔可夫过程的稳态和平稳向量
关于马尔可夫过程的主要问题是，如果过程运行时间足够长，它处于给定状态的可能性有多大。在闪电网络的情况下，这转化成了一个问题：“给定固定的流失和渠道容量，并且只有1个sat支付，Alice最终有x个sat流动性的可能性有多大?”
通过数学我们可以相当容易地计算出这一点。假设我们有一个维度为“c+1”的向量空间，其中马尔可夫过程的每个状态(Alice的潜在流动性值)都是一个基本向量，并且有一个按照描述的方式编码为转换矩阵的随机映射。这将导致容量为5sat的渠道出现以下转换矩阵
我们注意到这是一个三对角矩阵。我们将在后面描述较大的支付如何形成带状矩阵。在没有正式证明的情况下，我们可以看到，对于非0.5的流出值，马尔可夫过程不应该振荡，而是收敛到一个稳定状态。创建一个将能量矩阵提高到一个非常高的功率，并计算任何初始状态向量乘以矩阵高功率的小程序很容易(但计算效率非常低)。这导致了一种编码流动性分布中不确定性的固定状态。
特别是该马尔可夫过程导致的流动性分布与我们之前用来估计渠道流动性分布的模拟随机游走相同，如下图所示：
改变马尔可夫过程的参数
我们确定了马尔可夫过程的3个主要参数：
渠道的容量，比向量空间的维度小1
与跃迁概率相对应的渠道损耗
“htlc_maximum_msat”(以及支付规模的分布)，在上述例子中我们人为地将其设置为1。
上述考虑的主要限制是我们将“htlc_maximum_msat”设置为1，只允许1-satoshi的支付。这可以通过多种方式解决。我们提出了一个相当合理的概括。为了理解要点，让我们看看2-satoshi的情况，并假设不同的支付规模(1 sat和2 sat)是均匀分布的，因此对于给定的支付路由请求来说，发生的可能性是相同的。这种假设可以通过设计不同的马尔可夫链来解决。例如，在我们的代码中，我们还研究了Zipf分布，因为它似乎更可能是小额支付。在任何情况下，要说明这一切如何运作，使用统一的支付规模分布来解释这些概念是最容易的。
对于给定的流失' d '和状态' a '，我们现在有两个跃迁概率：
P(X=a+1 | X=a) = d/2
P(X = a+2 | X = a) = d/2
这是因为对于两个satoshi的情况下，我们要么发送1个satoshi，要么发送2个，这两个概率之和就等于我们的流失d
反过来，我们得到：
P(X=a-1 | X=a) = (1-d)/2
P(X = a-2 | X = a) = (1-d)/2
在1个satoshi的情况下，当渠道枯竭时，我们必须谨慎对待。因为我们允许的支付规模最多为2，在状态0和1下，这种情况可能会发生。因此，我们得到：
P(X = 0 | X = 0) = 1-d #状态0下请求1或2 sat支付
P(X = 0 | X = 1) = (1-d)/2 #状态1下请求1 sat支付
P(X = 1 | X = 1) = (1-d)/ 2 #状态1下请求2 sat支付，但无法完成
结果如下图所示：
设q = (1-d)，我们可以再次查看该过程的矩阵表示：
同样地，我们可以为容量更大的渠道创建更大的链，或为更高的“htlc_maximum_msat”值创建更多的带状矩阵。github上的lnresearch repo包含一个笔记本，其中的代码可以做到这一点，并为你计算出结果的静态分布。
特别是，我们可以在流出的方向上设置与相反方向不同的“htlc_maximum_msat”。下图展示了Alice将她的“htlc_maximum_msat”设置为1的马尔可夫过程。与此同时，Bob将其保持在2，因为Alice和Bob都希望Alice比Bob有更多的支付路由请求，但希望保持一个不应流失的平衡通道：
对应的转换矩阵如下所示。
当然，我们可以将此延伸到Alice和Bob的' htlc_maximum_msat '的任意值。Alice的' htlc_maximum_msat '编码了对角线上方使用的频带数量，Bob的' htlc_maximum_msat '编码了对角线以下使用的频带数量。
对于给定的消耗，我们会寻找一个使渠道上稳态向量的预期支付失败率最小的马尔可夫过程。
虽然支付规模分布及其采用“htlc_maximum_msat”值时的变化只能在节点运行期间和实际数据中了解到，但我们继续进行理论观察。在下一节中，我们将研究如何计算预期的支付失败率。
计算在流动性不确定的情况下的渠道预期支付失败率
一旦我们有了一个编码了关于流动性不确定性的概率分布，我们可以通过以下公式计算规模为“a”的支付失败的可能性：
failure_rate(a) = drain*P(X>c-a) + (1-drain)*P(X<a)< span="">
通过意识到规模为“a”的支付在两种情况下会失败，我们可以很容易地理解这一点。
如果它与流出的方向相反，且渠道的可用流动性不足“a”sat。发生这种情况的概率计算为(1-drain)*P(X<a)< font="">
如果它是在流出的方向上，而渠道伙伴有超过“c-a”sat的流动性。发生这种情况的概率计算为' drain*P(X>c-a) '。
这两个概率的和就是上述规模为“a”的支付的预期失败率。
平均预期失败率是“a”的所有可能值的平均值，如果我们假设金额分布不均，则可以对“a”进行加权。在任何情况下，支付规模都会受到' htlc_maximum_msat '的限制，所以我们可以通过以下方法计算预期的支付失败率：
假设在两个方向上都有相同的“htlc_maximum_msat”，我们可以看到通过改变设置，预期支付失败率是如何发生变化的。特别是我们看到，更强的消耗需要更高的“htlc_maximum_msat”值来最小化预期支付失败率。
我们可以看到，当为给定的流出增加' htlc_maximum_msat '时，预期错误率会在将' htlc_maximum_msat '增加到其最小值时下降，然后再次开始增加。然而，我们可以注意到，除非我们处于几乎没有任何消耗的场景中，否则' htlc_maximum_msat '的变化似乎对降低错误率没有明显帮助。
然而，如果我们假设' htlc_maximum_msat '的值不对称，其中Alice设置' htlc_maximum_msat_A '为她愿意转发的最大数量，Bob通过' htlc_max_size_B '做同样的设置，我们得到以下预期失败率公式和一个Bob和Alice对给定流失都有共同兴趣解决的二维优化问题。
研究这个的动机很简单。假设您有一个从A到B的耗损为0.75的渠道。这意味着从统计上看，4笔付款中有3笔从A到B，而只有1笔从B到A。如果节点运营商现在将从A到B的支付规模的吞吐量限制在允许从B路由到A的一小部分，那么从统计上看，渠道将保持平衡，从而降低了预期付款失败率。对于高达0.95的流失值，我们计算了最佳的`htlc_maximum_msat`对，并在下图中描述了预期的支付失败率。
我们可以观察到，当流失值达到0.90时(即10次支付中有9个流向相同方向)，预期支付错误率将下降到3%以下。这是相当大的进步。假设所有流失值出现的频率相同，中位失败率现在是2.18%。如果渠道在两个方向上使用相同的“htlc_maximum_msat”值，则该值为40.88%时，这是一个显著的改进。正如预期的那样，当流失值接近1时，故障率会急剧增加，而从平均值来看，改进并不是很明显。当在两个方向上选择' htlc_maximum_msat '的最优值时，在所有流失值上支付的平均预期失败率为5.43%，这与43.1%相比仍有很大的改进。
我们还可以看到，流动性的分布如何变得更加接近均匀分布：
当绿色曲线在更大的流失下变得更加倾斜时，我们可以看到蓝色曲线始终更接近流动性的均匀分布，从而形成了平衡的渠道和较低的故障率。
当然，人们应该对这些结果保持谨慎。我们不知道准确的支付金额分布，也不知道如果节点运营商开始通过这个参数建立流量控制，它们将如何变化。这将改变马尔可夫模型和优化问题中的权重。
目前似乎有大量的节点运营商没有意识到有目的地选择' htlc_maximum_msat '的重要性。在撰写本文时，73.1%的渠道在两个方向上都使用相同的“htlc_maximum_msat”值。正如本文所讨论的，这预示着总体上更高的故障率，并表明节点运营商在改善流量控制、增加网络可靠性和降低预期支付故障率方面还有未利用的潜力。
讨论：该模型的局限性和机会
与任何模型一样，该模型存在着严重的局限性和不足。为了创建马尔可夫链，我们假设了解渠道的流失情况以及在1 sat和“htlc_maximum_msat”之间支付规模的分布。虽然这两者都可能在节点运行期间进行估计，但这些假设可能会动态变化。特别是' htlc_maximum_msat '中的变化也可能会改变模型的这些假设。在最后，我们提供了两种实验算法，节点运营商可以使用或采用它们来为' htlc_maximum_msat '找到合适的值。特别是我们有一种算法，其中节点运营商不需要创建马尔可夫链。这个想法是在过去1万次支付的渠道中构建流动性分布，并衡量这种分布与统一分布之间的差距。如前所述，如果该分布距离均匀分布很远，这可能是一个指标，这可能表明我们有一个流失和潜在枯竭的渠道。在这种情况下，采用' htlc_maximum_msat '值可以缓解这种情况(通过马尔可夫模型进行激励)。因此，虽然该模型具有典型局限性，但它可以引导节点运营商采用其设置的简单策略。
当然，节点运营商必须在主网上测试更改“htlc_maximum_msat”是否有用，是否确实通过降低其渠道上预期的支付失败率提高了可靠性。从马尔可夫模型中我们可以看到，较低的“htlc_maximum_msat”值产生的差异较小，从而可以降低预期支付失败率。当然，在现实中，我们不想让这个参数选得太低。因此，节点运营商可能需要在这里进行一些权衡。虽然我们怀疑每个渠道的' htlc_maximum_msat '对可能相当稳定，但不清楚它需要多久更新一次。当然，gossip协议平均每天只允许有4次更新。此外，一些与我们讨论过本文观点的人指出，这可能涉及隐私问题。当然，如果节点运营商开始使用' htlc_maximum_msat ' pari作为阀门，那么他们将隐式地在其渠道上发出流失信号。这对竞争的路由节点来说可能很有趣，因为它们现在可以了解哪里可能需要流动性。虽然这总体上有利于提高网络的可靠性，但节点运营商可能没有兴趣教育他们的竞争对手。
结论
我们已经看到，对于给定的渠道流失，选择非对称的“htlc_maximum_msat”对可能会显著降低渠道的预期支付失败率。网络的广泛采用有望提高网络的整体可靠性。同时，使用' htlc_maximum_msat '作为阀门的渠道往往更加平衡。即使是高流失渠道，我们也可以看到与没有流量控制措施的渠道相比，它们的流动性分布更接近均匀分布。互联网上的流量控制通过传输控制协议的滑动窗口机制来实现，以解决互联网协议的一些可靠性问题。虽然' htlc_maximum_msat '可能会让人想到TCP中的window_size，但它是一个闪电网络的原生参数，用于实现更好的流量控制。未来可能会出现其他用于改进流量控制的闪电网络原生参数。虽然我们希望节点运营商可以根据我们提供的算法中的想法自行选择它们的“htlc_maximum_msat”，但我们注意到，为了在协议层面上实现流量控制过程的自动化，可能需要一个交互式通信协议来查找“htlc_maximum_msat”值。
就我个人而言，我对闪电网络是否能达到预期的服务水平目标抱有怀疑态度。基于目前的结果，我再次充满了希望。无论如何，我仍然相信我们将需要一种机制来实现冗余的超额支付，并需要其他工具和机制来提高协议的可靠性。
