|
5、去中心化交易所（DEX） 一组用户可使用点对点的方式在彼此之间中继提议，以维护一个去中心化的订单簿，这将是一个去中心化的交易所（DEX）。 当我们确信这个想法实际上是可行的之后，我们就开始对越来越复杂的原型进行迭代。 原型1：Unblinded第一次迭代的所有输入和输入都是非盲的。它需要一个 Elements Core 节点以及一个没有额外依赖项的小型 Python 脚本来运行协议。 原型 2：Makers Blinds然后我们增加了对taker使用盲输入和输出的支持。 这需要一个额外的依赖项wally来执行一些加密操作。 原型3：Blinded Case（遇到了问题）剩下的步骤是允许maker 也使用盲输入，我们这样做了，但不幸的是，实际的实现失败了。 使用保密交易（CT），非盲信息在输出字段之一（范围证明——rangeproof）中加密。当收到交易时，这个非盲信息被解密并用于支出。然而，交易签名不涵盖此类字段。因此，Taker 可以替换其价值，而 Maker 将无法blind这笔交易。 解决这个问题的一个方法，是在本地保存每个提议的非盲信息，而不依赖于rangeproof数据。不幸的是，这与elements-cli 是不兼容的。 因此，我们不得不寻找新的想法来完成我们的实施。 BEWallet我们需要一个让我们能以最少的开销进行实验的钱包。我们选择从使用 Electrum 服务器的Blockstream GDK Rust 实现开始。这个想法是去除所有不需要的功能，以获得一个非常简单但有效的 Liquid Electrum 钱包。经过了数个月的努力之后，我们搞出了BEWallet。 然后我们添加了 LiquiDEX 支持，在这样做的同时，我们试图最大限度地减少用户应该备份的数据量。Electrum 钱包（单签名）备份通常包含一个BIP39助记词，但LiquiDEX还需要其他的东西。琐碎的办法是坚持所有提出的提议，但我们可以做得更好。 首先，我们可以确定性地推导出资产blinder以及金额blinder 。此外，交易有一个 Maker 不使用的字段，即 nonce commitment。此字段已签名，因此可用于存储一些有用的数据。我们想为资产存储 32 个字节，为数量存储 8 个字节，但我们只有 32 个字节（和 1 个位）可用。 我们选择使用 AES GCM IV 加密 nonce 字段中的金额，因为我们已经将其作为加密本地数据库的依赖项。 相反，资产将被迫违背资产承诺。当提出提议时，钱包将保留它可能在本地收到的资产。在揭盲时，它会尝试所有先前保留的资产，直到找到匹配项为止。 如果我们在另一台设备上恢复钱包呢？我们可以导出上一个钱包中的资产列表，如果丢失了，我们可能会记住它，因为我们可能只交易最受欢迎的资产，或者我们甚至可找到在 Liquid 上发行过的所有资产并尝试所有这些资产。 (责任编辑：admin) |