Ark 是第三个主要的第 2 层协议,在基础层上具有某种形式的单方面退出或执行机制,以接近在比特币上启动的点。当 C-Lightning 在 2018 年的 Reckless 活动中上线时,闪电网络首次出现;2021 年 Mercury Wallet 上线时,状态链首次出现;现在 Ark Lab 即将推出的 clArk(无契约方舟)Arkade 钱包实现也正在接近同样的目标线。
与完整的 Ark 实现相比,clArk 有一些缺点,即在去信任版本中,单个 Ark 内的每个用户在创建时需要在大规模的 n-of-n 多重签名中协作签署退出交易。如果我们有 CTV 或其他同等的契约,用户就不需要参与交互式签名过程,方舟服务提供商 (ASP) 可以简单地使用契约创建方舟,用户可以确保他们在使用后可以完全控制自己的资金已得到证实。
与闪电网络相比,方舟提出了一个有趣的权衡,两者都要求参与者拥有过剩的流动性才能接收付款。然而,就闪电网络而言,这是一个复杂的游戏,个人用户必须弄清楚在哪里分配自己的流动性,以及如何从其他人那里获取流动性,以便能够正常发送和接收。这是每个用户单独解决的个人问题。有了方舟,任何 ASP 都可以自由地将其部分流动性分配给任何用户。他们仍然需要解决资金来源的问题,但不再存在每个用户决定是否值得朝该方向分配流动性的问题,只需在任何个人用户需要时即可完成共同的流动性罐。
但方舟的流动性问题仍然存在。对于方舟上尚未关闭的每笔付款,ASP 必须为这些付款提供流动性,以允许用户将其接收到新的方舟中。当 ASP 达到流动性耗尽的程度时,其为了解决这个问题,费用必须开始飙升,直到他们能够通过关闭方舟来收回锁定的流动性。
我认为解决较高费用尾部曲线的一种方法可能是探索闪电网络的一些经验教训,即可路由拓扑。与闪电相比,这将非常简单。闪电网络需要通过成对的个人用户之间建立的流动性路径进行映射和路由,而对于方舟来说,它只是 ASP 到 ASP。
遇到流动性紧缩的 ASP 可以将付款从自己的 Ark“转投”到另一个具有更多可用流动性的 ASP,从而在自己的 Ark 之间建立 ATLC 链接,将付款发送到另一个 ASP 的 Ark 进行接收,从而节省用户费用。反过来,由于他们能够在关闭现有方舟时收回流动性,并且自己的费用下降,其他经历流动性紧缩的 ASP 可以通过将付款转回他们的方向来“回报”。
这可以在 ASP 之间建立一种循环和易于分析的“我帮你的背,你帮我的”动态,在高费用流动性紧缩期间保留一些收入的同时,总体上将为他们创造更可预测和负担得起的体验。用户。
这确实带来了这样的风险,即像这样的跨 ASP 支付本质上将不同 ASP 之间的 Arks 相互链接,这意味着非合作关闭将需要关闭由多个实体运营的 Arks,但考虑到合作关闭取决于用户行为,我认为这不会如果没有 ASP 故意互相伤害,就会从根本上改变风险状况。不过,这可以被视为类似于闪电网络的信道干扰问题。
有一些优点,也有潜在的缺点,但我认为这是一个在改善方舟流动性紧缩问题方面值得探索的概念。