方舟可能从闪电中学到什么（转）

Ark是第三个主要的第二层协议，在基础层上具有某种形式的单方面退出或执行机制，以接近比特币的启动点。闪电首先出现在2018年C-Lightning在Reckless活动中上线时，在2021年Mercury钱包上线时出现在Statechains上，现在Ark实验室即将推出的Arkade钱包clArk（无契约方舟）正在接近同样的目标线。
7 S0 f+ E/ m! X9 F8 ?6 j) Z! W1 _与完整的Ark实现相比，clArk有一些缺点，即在无信任版本中，要求单个Ark内的每个用户在创建退出交易时在大量的n-of-n多重签名中协同签名。如果我们有CTV或其他同等契约，用户就不需要参与交互式签名过程，方舟服务提供商（ASP）可以简单地使用契约创建方舟，用户可以确保在确认后完全控制自己的资金。
7 S) K7 V. n: U与闪电网络相比，方舟提供了一个有趣的权衡，两者都要求参与者拥有多余的流动性才能收到付款。然而，在闪电网络的情况下，这是一个复杂的游戏，个人用户必须弄清楚在哪里分配自己的流动性，以及如何从他人那里获得流动性，以便在功能上发送和接收。这是一个单独的问题，每个用户都可以独自解决。有了Ark，任何ASP都可以自由地将其部分流动性分配给任何用户。他们仍然需要解决资金来源的问题，但不再存在决定是否值得向该方向分配流动性的每个用户的问题，因为任何个人用户都需要从一个共同的流动性池中获得资金，所以现在就可以简单地完成。
, \/ t, z* V5 V# E不过，方舟的流动性问题仍然存在。对于尚未关闭的方舟上浮动的每一笔付款，ASP必须为这些付款提供流动性，以允许用户将其接收到新的方舟中。当ASP达到流动性不足的程度时，其费用必须开始飙升，以管理该问题，直到他们能够通过关闭方舟来收回锁定的流动性。
我认为解决这种高费用尾部曲线的一种方法可能是探索Lightning的一些经验教训，即可路由拓扑。与闪电相比，这将是非常简单的。Lightning需要通过在成对的个人用户之间建立的流动性路径进行映射和路由，而Ark则只是ASP到ASP。
遇到流动性紧缩的ASP可以将自己的Ark的付款“押注”到另一个流动性更高的ASP，在他们自己的方舟和另一个ASP的方舟之间建立ATLC链接，从而节省用户费用。反过来，当他们关闭现有的Ark并降低自己的费用时，他们能够收回流动性，而当时经历流动性紧缩的其他ASP可以通过向他们的方向押注付款来“回报”。
这可以在ASP之间建立一种循环的、易于分析的“我帮你，你帮我”的动态，在高费用流动性紧缩期间留下一些收入，但总体上会为用户创造更可预测、更实惠的体验。
这确实带来了这样的风险，即跨ASP的支付本质上会将不同ASP的Ark相互关联，这意味着非合作关闭将需要关闭由多个实体运营的Ark，但鉴于合作关闭取决于用户行为，我认为这不会从根本上改变风险状况，除非ASP故意相互伤害。不过，这可以被视为类似于闪电的信道干扰问题。
有一些优点，也有潜在的缺点，但我认为这是一个值得探索的概念，可以改善方舟的流动性紧缩问题。
2 r5 r+ f2 W" S* R' v& X! T

这个倒也是可以学到很多东西啊。

这个到底学的什么？我们还是要了解一下的。

这都是谈的什么东西哟，简直不是给我们看的内容

可以学到什么也是关注一下啦

这么看的话也是要学到什么啊