了解两步原子交换协议liquidex

注:原文作者是blockstream研究员Leonardo Comandini。长话短说:LiquiDEX 是一个在 Liquid网络上执行两步原子交换(原子交换)的协议,它只需要交换方的单次交互,这极大地改善了用户体验。而使用该协议,我们可以构建出更复杂系统的构建块,例如自动 OTC 交易柜台、拍卖系统甚至去中心化交易所 (DEX)。注:LiquiDEX的产品还不可用。
Liquid网络是一个具有发行资产和保密交易(CT)的 比特币 侧链。Liquid 的原生资产是 L-BTC(Liquid bitcoin),它相当于 比特币 的一个锚定币。和 比特币1 一样,用户也可以在Liquid 网络上发行代表数字资产的token,一个例子就是Tether USD(USDT)。和 比特币 一样,Liquid使用了一种UTXO模型,而它们的交易结构也相似。下面是一笔简化的 比特币 交易,其中Alice 发送 1 BTC 给 Bob:下面则是一笔简化的Liquid 交易,Alice 向 Bob 发送 0.5 L-BTC以及1000 USDT:然而,因为使用了保密交易(CT)技术,Liquid网络的输入和输出是不可见的,因此外部观察者无法看到实际金额和资产。这对交易者来说特别有用,通常而言,交易者并不想透露他们的操作,因为这些信息可能会影响到市场价格。在上面的例子中,所有的输入都属于Alice,但情况并非一定如此:一些输入可能属于Alice,而另一些输入可能属于 Bob。假设 Alice 想用L-BTC交换一些USDT,而Bob 想做相反的事情,则Alice 和 Bob 可以合作构建这样的交易:交易完成后,Alice 发送了0.5 L-BTC 并收到了600 USDT, 而Bob 发送了 600 USDT,并收到了 0.5 L-BTC。交易要么发生,要么不发生(它不会部分发生),这使得交易是“原子”的,这就是一笔P2P 原子交换交易,Alice 和 Bob 交换了一些资产,他们之间彼此并不信任,也不需要信任一个第三方。

在 Liquid 上支持原子交换的第一个实现是Liquid Swap Tool,它使用了一个三步协议。其中第一步是 Alice 提出一笔swap交易:第二步是Bob 接受这个提议:然而这笔交易还没有准备好被广播,我们需要第三步,其中Alice来最终确定这个提议:这 3 个步骤是使swap交易与标准交易无法区分的必要步骤。但是,它也存在着一些缺点。该协议分析起来会更复杂。由于不同的原因,它可能会在不同的步骤失败,也许是提议格式不正确,交易不再有利可图,那么一方可能会中止协议。Alice 还需要在线才能完成协议。 如果 Alice 花费太多时间来完成,Bob 可能会进行另一次swap交易并使他接受的提议无效。这使得用户体验变得繁琐,并且很难将这些swap交易集成到其他服务中。而一个两步协议将解决大多数的问题,事实上,两步协议的用户体验非常类似于“发送交易”:Alice询问她想要交换什么,然后最终交换发生。在过去的几个月里,我们构建出了LiquiDEX这个想法。

LiquiDEX 是一个在 Liquid 网络上执行原子交换的两步协议。该协议涉及到了两方:制造商接受者,其中Maker 想要发送一些资产并接收一些其他资产作为交换,它创建 LiquiDEX 提议并发送给 Taker。Taker 接受该提议,并在 Liquid网络上结算swap交易。Asset、assetblinder 和 amountblinder 与 Elements Core 一致地进行十六进制序列化,这与它们的字节序列化相反。LiquiDEX 提案格式定义了 Maker 和 Taker 必须达成一致的内容。其他一切都可以由双方任意选择以实现所需的行为。让我们分析一个他们可能选择做什么的例子。Maker 有一个UTXO U_xA公司持有数量的A.资产,而他想要将其资产交换成Y数量的B资产。Maker创建了一笔交易,花费单个UTXO U_xA公司并接收Y数量的B资产。Maker屏蔽(blinds)这个输出。在实践中,这有一些重要的挑战,权衡和实现细节将在下一节中讨论。Maker 使用单身|单身|任何人都可以支付 对(唯一)输入进行签名,这允许 Taker 添加更多的输入和输出,而不会使 Maker 签名无效。其他Maker按照上述规定创建 LiquiDEX 提议,并将提议发送给 Taker。Taker 收到提议,并进行一些验证,其中可能包括:Taker 添加一个输出,该输出接收数量的A.资产。Taker为交易提供资金,即他为资产B和费用添加输入,根据需要更改输出,以及显式费用输出。Taker使用提议中的非盲信息来屏蔽交易。Taker用叹气对新添加的输入进行签名。Taker广播交易,一旦这笔交易被纳入一个区块,这笔swap交换交易就被结算了。LiquiDEX 有一些权衡,我们在这里总结一下。优点:缺点:

现在,我们来展示一些 LiquiDEX 支持的应用例子。假设Maker想要把L-BTC卖掉换成USDT或L-CAD,他可以使用相同的 UTXO提出两个提议,一个发送L-BTC 并接收 USDT,另一个发送L-BTC 并接收 L-CAD。由于 UTXO 只能使用一次,所以他要么是收到USDT,要么是收到L-CAD。Taker可以使用多个提议构建其交易,例如:我们还可以实现一项服务,它接受用户的提议并负责匹配它们,这种服务既可以使用其他用户的资金,也可以使用自己的流动性资金。Alice 发行了一种新资产,我们称之为 NFT。Alice 可以为此举行拍卖会,她公布了自己想要发送的输出的资产、数量和盲注(blinder),并将接受交换L-BTC(或她想要接收的任何其他资产)的提议。过了一段时间后,她会接受对她来说更有利可图的提议。如果她想以一定的价格出售该NFT资产,那么她可以提出提议并希望有人接受它。一组用户可使用点对点的方式在彼此之间中继提议,以维护一个去中心化的订单簿,这将是一个去中心化的交易所(DEX)。当我们确信这个想法实际上是可行的之后,我们就开始对越来越复杂的原型进行迭代。第一次迭代的所有输入和输入都是非盲的。它需要一个 Elements Core 节点以及一个没有额外依赖项的小型 Python 脚本来运行协议。然后我们增加了对taker使用盲输入和输出的支持。这需要一个额外的依赖项wally‌来执行一些加密操作。剩下的步骤是允许maker 也使用盲输入,我们这样做了,但不幸的是,实际的实现失败了。使用保密交易(CT),非盲信息在输出字段之一(范围证明——rangeproof)中加密。当收到交易时,这个非盲信息被解密并用于支出。然而,交易签名不涵盖此类字段。因此,Taker 可以替换其价值,而 Maker 将无法blind这笔交易。解决这个问题的一个方法,是在本地保存每个提议的非盲信息,而不依赖于rangeproof数据。不幸的是,这与元素cli是不兼容的。 因此,我们不得不寻找新的想法来完成我们的实施。我们需要一个让我们能以最少的开销进行实验的钱包。我们选择从使用 Electrum 服务器的Blockstream GDK Rust‌ 实现开始。这个想法是去除所有不需要的功能,以获得一个非常简单但有效的 Liquid Electrum 钱包。经过了数个月的努力之后,我们搞出了BEWallet。然后我们添加了 LiquiDEX 支持,在这样做的同时,我们试图最大限度地减少用户应该备份的数据量。Electrum 钱包(单签名)备份通常包含一个BIP39助记词,但LiquiDEX还需要其他的东西。琐碎的办法是坚持所有提出的提议,但我们可以做得更好。首先,我们可以确定性地推导出资产blinder以及金额blinder 。此外,交易有一个 Maker 不使用的字段,即 nonce commitment。此字段已签名,因此可用于存储一些有用的数据。我们想为资产存储 32 个字节,为数量存储 8 个字节,但我们只有 32 个字节(和 1 个位)可用。我们选择使用 AES GCM四 加密 nonce 字段中的金额,因为我们已经将其作为加密本地数据库的依赖项。相反,资产将被迫违背资产承诺。当提出提议时,钱包将保留它可能在本地收到的资产。在揭盲时,它会尝试所有先前保留的资产,直到找到匹配项为止。如果我们在另一台设备上恢复钱包呢?我们可以导出上一个钱包中的资产列表,如果丢失了,我们可能会记住它,因为我们可能只交易最受欢迎的资产,或者我们甚至可找到在 Liquid 上发行过的所有资产并尝试所有这些资产。不管怎样,这可能会在未来进行一些改进,我们只是想要一些现在有效的东西。BEWallet 在早期仍然是一个附带项目,它可能会存在漏洞,因此要测试的话,请使用少量的资金。安装BEWallet钱包:Maker 列出其代币以选择要交换的代币:然后制作提议:并将该提议发送给接受它的Taker:$bewallet cli--mainnet--electrum url blockstream。info:995 --data-root $PWD—助记符"$MNEMONIC" liquidex take—建议';{"版本":0, "tx":"020000010123E4F67AAF6FB5EEBC35512E030F23CCBFDD9FC1A0EDB42E8044595FC0757CAA000000000171600149FEC3992EA13A5E29FD55BD38050BFE83D5C4FFFF010AA630E1848D2C5853AAEF9A36AB0E5F677ED3C9642825ACC3F3E3CD5E2F63098AF87F31F095E416A8A32BAC715F2D3920F51A93D9295FBF149010B1A38702D30DA456E26FF055F8D69EAD144AAFFC36314D1552B0C217D6ECB04F817A914B9EAB96318EF4F7B60858A0586FF474A7024061B8700000000000283045022100A91C9D744D19FE22231561B9EE89AA0674B6B876D63835FB807A441A041C0C5B02201E36469CAD394B0A73B609D1E73DE93E6068A93E44A08720FB1BC6F6948321034A6C4485C1B5A26F61225A3FF0DDA62BFB52C7008E9C592E68AA87D557F2000000","输入A66035:[{"资产6035:"BEEE1A548FBB20280E539B697DE076D87859A25C2983EBC55F2D8BEC40ABC3","ASSETR":"2999A36875BDB950A232DE77F4D81FECF7FC073BB93E28940929E4B130EDBC","金额:"C44F9BDB17A0754231305BCD046DE5672106CC6DE1EB11778A51B921D52","amount":5}],"输出A66035:[{"资产6035:"8026fa969633b7b6f504f99dde71335d633b43d18314c501055fcd88b9fcb8de","资产盲板6035:"ee390be3dd1e53d1f723e1007234fa3074691a7d5f1cfdbd75e0255284ee40b1","金额盲板6035:"70B0D48BC015E4930D688CA6779E4A637A78C70F573FC009CF1C1BFE32E3A3A",":5}&Šx27;--广播1980年ADEB659579E3D5FCA673AB00E2F9A4FB933BFCABC0D52946AD3260552882这导致了这笔交易‌,它可以被maker 部分揭盲,而被taker完全揭盲。请注意,可以使用 taker-cli.py公司 和一个Elements 节点执行 Taker 步骤。

BEWallet LiquiDEX 实现现在已经可以工作了,但它远非完美,我们削减了一些内容,在不久的将来,我们还会实施很多可能的优化和界面改进。其中有几个改进是我们很想去实现的,但我们必须要多等待一点时间。我们想摆脱自定义JSON 格式以使用部分签名Elements交易,但是这还没有准备好。那么我们宁愿降低 Maker 及其揭盲程序的复杂性,这可以使用 SIGHASH_RANGEPROOF‌ 来完成,这是一种新的sighash类型,其也涵盖了范围证明(rangeproof),但是,我们需要等待它的部署。一旦我们同时拥有两者,任何支持 PSET 的钱包都可以以最少的更改实现LiquiDEX。

Liquid网络是具有原生资产的区块链,它允许两方或多方合作构建交易。这种交易可能包括双方之间的资产交换,换言之即一笔P2P原子交换。这个swap交换协议的初始实现分为3个步骤。然而,它有几个问题,主要是用户体验会变糟。LiquiDEX 是一种执行两步 P2P 原子交换的协议。这通过要求 Maker 和 Taker 之间的单次交互来改进用户体验,并做出合理的妥协。LiquiDEX 更容易集成到其他系统中,并且可以成为实施 OTC 交易柜台、拍卖系统、DEX等的构建块。而BEWallet则是一个支持LiquiDEX的可用Liquid Electrum 钱包。感谢我要感谢 Riccardo Casatta,是他提出了最初的想法,Luca 和 Valerio Vaccaro 帮助我进行了测试,特别是 Valerio 建立了liquidex.it,这是一个上传提案的网站,此外他还提出了拍卖系统的想法。

文章原文地址:了解两步原子交换协议liquidex

此文章来源于网络,如有侵犯,请联系我们删除文章

原创文章,作者:比特火炬,如若转载,请注明出处:https://www.btc978.com/1876.html

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注