当前位置：
  1. 首页
  2. 币币资讯
  3. 正文

Mercury Layer 的闪电锁交换协议插图

Commerceblock 发布了一种新的原子交换协议，可与 Mercury Layer 协议上的状态链一起使用。 HSM 服务器引入了支持原子交换两个状态链的功能，以及强制执行状态链的原子交换以进行闪电支付。 这是状态链和闪电网络之间具体定义和构建交互的第一个例子。 自从 Ruben Somsen 最初提出状态链的概念以来，两种协议之间的协同作用就被假设出来，特别是作为解决必须立即传输整个状态链 UTXO 的限制的一种方法。

基本状态链互换

为了支持新的交换协议，HSM 服务器需要向其数据库条目添加一些新字段，以跟踪其正在促进的每个状态链。 为了促进状态链到状态链的交换，服务器需要跟踪：

  • Batch_id：用于关联组中正在交换的状态链的值。
  • 批处理时间：启动计数器的时间，之后如果交换失败，可以“回收”状态链。
  • Locked：指示状态链是否被锁定并限制常规传输的值。

这允许 HSM 服务器跟踪并强制执行确保安全原子交换所需的所有变量。 当启动交换时，用户必须直接相互通信，以便在他们之间建立共享的batch_id。 从此时起，他们交换促进正常状态链传输所需的所有必要信息，并将该信息以及批处理 ID 和批处理时间发送到服务器。 它们本质上启动了常规传输过程，但也附加了变量以连接参与交换的各个状态链以及超时时间。

此时服务器将在传输过程中使用相同的batch_id对每个状态链应用锁。 直到超时到期，或者数据库中使用相同batch_id的所有状态链都已被当前所有者解锁，服务器将不会批准任何传输。 HSM 强制执行交换逻辑的方式的一个巧妙之处在于，谁先联系服务器并不重要。 当服务器使用batch_id获取消息时，它会检查其数据库中的每个状态链，如果该batch_id存在预先存在的批处理时间，则会将其设置为相同的。 这确保了无论谁先注册交换，他们都对超时函数使用相同的时间值。

此时参与交换的每个客户端都会检查并下载启动传输协议的消息，并在验证它们正确后向服务器发送一条消息以解锁其状态链，从而消除传输限制。 每当有人尝试在交换所涉及的任何状态链的接收端完成传输时，服务器都会检查以确保具有相同batch_id的所有状态链都已解锁。 如果即使是具有相关batch_id 的单个数据仍被锁定，服务器也不会完成其中任何一个的传输。 如果交换在超时之前没有成功，服务器将继续限制交换传输的完成，但会让当前所有者初始化一个新的传输给自己，以有效地取消交换。

闪电锁

闪电锁存器功能，将状态链交换为闪电支付，其工作原理与状态链到状态链的交换非常相似。 以下是服务器必须跟踪闪电交换的新字段：

  • Batch_id：用于关联组中正在交换的状态链的值。
  • 批处理时间：启动计数器的时间，之后如果交换失败，可以“回收”状态链。
  • 原像：闪电支付的原像，由HSM服务器生成。
  • Locked_1和locked_2：闪电互换有两个锁定字段，每个涉及的用户都授权一个。

就像状态链到状态链的交换一样，用户建立并共享一个随机的batch_id。 然后，当前状态链所有者向服务器发送包含batch_id和所涉及的状态链的消息，并请求其为闪电支付生成哈希锁原像。 然后，该用户使用该原像生成闪电发票，第二个用户联系服务器以确认其生成了原像。 然后，当前状态链所有者开始状态链传输过程并将传输消息上传到服务器。

确认后，第二个尝试交换状态链的用户启动闪电支付。 此时服务器是唯一拥有原像的服务器，因此状态链所有者还无法完成支付。 当前所有者在验证待处理的闪电付款后向服务器发送解锁消息以删除状态链上的第一个锁。 接收方最终验证传输消息，如果消息有效，服务器也会解除其锁定。

现在，两个锁都被移除，HSM 服务器将向当前状态链所有者释放原像以完成闪电支付，并将完成向接收者的状态链传输。

该方案确实需要信任状态链运营商诚实地运作，但这从根本上来说并没有改变一般使用状态链的现有信任模型。 运营商在任何时候都无法控制用户的资金，也不会了解任何有关闪电支付的详细信息。

这有什么用？

该方案与最初提出的状态链和闪电通道之间的交互相去甚远，将一个叠加在另一个之上，但即使作为一个简单的起点，它也为现有闪电用户提供了功能实用性。 对于许多节点来说，重新平衡通道是必要的，如果容量完全被推向一侧或另一侧，则该通道用于路由支付的效用就会受到限制。 由于链上费用上涨并使进出闪电网络的交换变得更加昂贵，许多企业和用户已经开始尝试使用 Liquid 作为一种机制。

状态链提供了联合侧链的替代机制，以减轻与通道平衡管理相关的一些费用支出。 不必直接交换到主链或使用侧链，而是可以将资金交换到状态链并保留在那里，直到需要将资金交换回通道为止。 可以节省类似的费用，同时仍然保持在主链上单方面认领资金的能力。

另一个潜在的用例（触发警告）是更有效的序数交易市场的可能性。 由于序号只是一个索引方案，跟踪交易历史中到特定聪的路径，因此它们可以轻松地从链上转移到状态链上。 这种动态与 Lightning Latch 相结合可以实现更便宜、更快速的链下购买序号。 有人可以建立一个市场，可以通过闪电网络在链下立即出售它们。

甚至有一天，如果闪电客户端能够以某种方式了解哪些状态链运营商特定的闪电节点相信 Latch 可以通过在不同节点之间传递状态链而不是使用传统的闪电通道来帮助路由支付。

在纯状态链到状态链传输的前端，这为消息传递层提供了重新创建像链下混合硬币系统一样的 Coinjoin 的潜力，类似于 Commerceblock 的第一个状态链实现中的原始混合功能。

虽然这是一个非常简单的起点，但闪电锁和状态链交换功能打开了状态链集成到现有闪电网络以及未来其他类似层的第一扇门，让它们无缝集成，并且在支付路由和流动性管理方面充当单一网络。 即使我们争论契约的必要性和有用性，仍然有很大的空间可以继续利用我们已有的东西进行建设。

您可以在此处聆听 Commerceblock 团队解释协议之外的逻辑：

如需更技术性的解释，请点击此处：

#Mercury #Layer #的闪电锁交换协议

上一篇 分析师预测 BNB 和以太坊竞争对手将出现突破性反弹——以下是他的目标
下一篇 柴犬燃烧率一天之内增加 2,300% – 详情

相关文章