本文介绍了10101项目,该项目旨在将非托管交易功能引入闪电网络,允许用户在不放弃资金控制权的前提下进行比特币交易。文章详细解释了非托管交易的原理、谨慎日志合约(DLC)的概念,以及如何在闪电网络中实现DLC,从而实现无对手方风险的交易。
作者:Lucas Soriano 及 Philipp Hoenisch
我们一直在开发 10101,让你可以 使用 你的比特币。毋庸置疑,你可以发送和接收比特币支付,链上可以收比特币,链下可以收闪电支付。但是,我们最感兴趣的,还是给闪电网络加入非托管的交易功能(non-custodial trading)。
使用比特币作为标的资产、参与交易,是极为常见的事,但是,几乎所有的选项,都必须接受交易平台卷款跑路的风险。就我们所知,只有我们最新的产品 ItchySats,提供了非托管的比特币交易功能。
在 10101,我们进一步加码,将非托管式交易带入了闪电网络、带到了你的手机上。在这篇文章中,我会解释我们是怎么做到的。
如果你曾经在 托管式 交易平台上交易过,那么某些时候,你会不得不放弃自己的资金的保管权。一些平台会强制你存入比特币;还有一些会在你下订单或者说开仓位的时候要求你存入。
而 非托管式 交易就是说,你 永远 无需放弃你的资金的完整保管权。为了实现这一点,我们起码要做到三件事情:
10101 的关键创新就在第2 步中。其他平台会托管你的资金,以保证可以强制执行合约的规则,而 10101 则依赖于一种密码学协议,来保证你的资金总在你的掌控之下。此外,上述的多签名输出也保管着你的对手方所提供的保证金,因此在 10101 上交易 没有对手方风险。
这种保证合约条款总是能得到执行的机制叫做 “谨慎日志合约( Discreet Log Contract,DLC)”。
一个 DLC 就是一个 2-of-2 的多签名输出,其花费条件基于在比特币区块链 之外 发生的事件。它非常强大,因为在这种范式提出之前,我们只能基于(1)在比特币链上发生的事件、(2)其它链上发生的事件,以及(3)纯粹时间事件 表达可编程的条件式支付。
为了让 DLC 运行,我们还需要引入一个受信任的第三方,叫做 “ 断言机(oracle)”。断言机见证真实世界里发生的事件。这样的见证消息会被用来(密码学意义上的)解锁 DLC 输出中的资金。这是通过参与 DLC 的双方在将 DLC 上链(形成多签名输出)之前、签名多笔花费该 DLC 输出的 “合约执行交易(CET)”来实现的;这些合约执行交易,每一笔都在只能在所用断言机见证了某一个结果的时候激活。
关键在于,断言机根本 无法意识到 任何 DLC 的存在。你没法通过观察区块链来知晓哪个 DLC 正在使用哪个断言机。
这无法防止断言机跟参与 DLC 的某一方勾结。但是,作为公开的实体,行为不轨的断言机将被识别为不值得信任的,无法再得到任何人的使用。
此外,在单个断言机上投注太多信任是不推荐的,尤其在合约的体量较大的时候。因此,你可以创建使用多个断言机的 DLC,仅在某个子集(例如 2-of-3 或 5-of-9)都同意一个事件结果时,资金才会以特定的方式分配。
如前所述,ItchySats 已经提供了非托管式交易功能。你可以在 Umbrel、 RaspiBlitz 和 桌面 系统上安装这款应用,享受比特币主网上的 DLC 所提供的差价合约(CFD)交易。现在就可以!
作为一款闪电网络至上钱包,10101 将, 在闪电网络上,提供由 DLC 赋能的非托管式交易。这意味着,这样的 DLC 是嵌在通道中的,就像其它闪电交易输出一样。结合闪电网络和 DLC 的主要好处在于,你可以在闪电通道中结算,无需在链上结算。
闪电网络当前并不能开箱即用地支持 DLC。这意味着,我们需要改造常规的闪电节点以支持 DLC 。这正是我们在由 BOLT.FUN 组织的 Legends of Lightning 锦标赛中起步时为我们的 项目 做的事。以 10101 为名,我们开发了一个用于概念验证的手机闪电钱包,CFD 交易是其主打功能。
有许多方式可以解决这个问题,与闪电网络的集成程度和难度各不相同。回到 10 月份,我们在开始开发之前思考了其中几种:
我们最终选择了最后一个,因为它是三者中最大胆的一个。我们的愿景是创造一种闪电通道,它可以闪电般加入、修改了移除 DLC。这种方法不会给闪电网络添加任何新的交易,而且它允许你将 DLC 的收益直接用于支付。
一笔闪电承诺交易代表了你的某一条闪电通道中的一个状态,它只能包含三种输出:
这意味着,我们需要延伸承诺交易所支持的输出,以引入 DLC。
我们当前的设计是加入一个可以带有任意花费条件的可撤销输出,我们称之为 “ 定制化输出”。我们将管理这种定制化输出的责任交给了闪电节点之上的层级。但闪电节点依然负责在通道状态改变时撤销这样的输出。
- 为闪电协议添加定制化输出 -
除了任意脚本,这种定制化输出也有别于标准的闪电输出,它是用来自通道双方的资金创造的(而不只来自某一方)。它的重要性在于,DLC 通常会锁定来自两方的资金。
在结算一个 DLC 时,闪电节点不需要知道其中的细节。它只需要被指示以合作的方式移除一个定制化输出、并以特定的方式分割其中的资金。
- 在闪电协议中移除定制化输出 -
这就类似于在一笔支付被申领之后移除一个 HTLC 输出的操作。
技术必须支持强制关闭功能,这样你才不必信任你的 DLC 对手。你必须能够单方面关闭通道,并在这个过程中将 DLC 承诺到区块链。
一旦那个断言机(或者断言机们)见证了相关事件的特定结果,某一笔 CET 就会变成可花费的;它广播到链上,就可以根据合约的初始条款分割资金。
因为闪电节点不理解 DLC 协议,这也要由闪电节点之上的层级来完成,在 DLC 可以退款之前 2 将正确的 CET 发布到链上。
在提出这种设计的时候,我们知道,我们修改之后的闪电节点必须依然跟其它常规的闪电节点兼容。与闪电网络集成的一个主要吸引力在于成为网络的一部分,利用它正在快速成长的用户基础。
因为我们现在只制作了增量式变更,这种兼容 DLC 的闪电节点依然能跟网络上的其他人收取和发送交易。
在花费几个月的事件开发这个课题之后,我们学到了一些可能影响我们 10101 走向下一步的东西。
能在闪电节点层面忽略 DLC 的详情当然很好,但它也让通道状态的更新变得非常复杂。比如,每次要路由一笔新的支付时,都需要在闪电节点、DLC 管理层和对手方之间做大量的通信。
我们还没有解决这部分的实现,所以我们应该在继续之前重新思考闪电节点对 DLC 的理解。
如上所述,DLC 是来自双方的资金所形成的共享输出。因为当前的闪电网络仅支持开启单方注资的通道 3,希望在创建通道时就能开启 DLC 是不现实的。
用户可以使用 “ 潜水艇互换” 来绕过这个问题,但对闪电网络规范的修改将可以启用双向注资通道,而且这样就的提议已经被 提交 了,正在接受审核。
如果你也像我们一样,为非托管式交易以及所有这些使用 DLC 的东西(免信任的稳定币,对不对!)感到激动,你可以:
1.我们在 Crypto Garage 的同行最近 发表 了他们在闪电网络上开发 DLC 的经验。我们正在联系他们,看看我们是否能在这个主题上合作。 ↩
2.纯理论上来说,如果参与的双方不同意结算且断言机没有为相关事件见证结果,DLC 也可能变得无法花费。因此,我们必须给 DLC 增加一个退款路径,让所有的资金在一个足够长的超时事件后退还给参与者。 ↩
3.特定的闪电实现(例如 Core Lightning,前身为 C-Lightning)支持双向注资通道。 ↩
(完)
- 本文转载自: btcstudy.org/2023/04/14/... , 如有侵权请联系管理员删除。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!