原文标题：《Mimblewimble 可实现非交互式交易，莱特币、Grin 等将受益》
撰文：David Burkett，Grin++开发者
编译：洒脱喜
一项技术如果是难用的，或者说对用户不友好的，那么它就很难被广泛采用。而此前的 Mimblewimble 协议，其交易就要求发送方和接收方同时在线交互才能实现，从而阻碍了相关项目的大规模应用。而在今日，Grin++钱包开发者 David Burkett 提出了一种支持 Mimblewimble 非交互式交易的提案，其可适用于莱特币、Grin 等区块链项目。
David Burkett 在莱特币论坛开发者板块中提到：
一月份最大的消息是，我找到了一种方法来支持 Mimblewimble 的非交互式交易！使用 MW 协议最大的困难，是需要发送方和接收方进行通信，这需要双方在线。而新的提议，可消除这种需要，由此可清除掉主要的用户体验障碍，同时支持通过冷存储进行接收，从而使硬件钱包更易于支持。
在开发方面，已经为 libmw 确定了构建过程，并且本地构建正在为 libmw-ltc 工作（将 libmw-core 和 libmw-ltc 检出到同一父目录，并且你应该能够构建 libmw-ltc）。我将在下个月左右设置 CI/CD。
另外，我还构建了一个具有交易处理功能的健壮数据库框架，以支持跨多个 table 的原子更新，并实现了与币无关的区块数据库查询和更新，并且已使用特定于 LTC 的区块头和区块模型进行了部分测试。
安全审计结果是从 Grin++得出的，因此我已将所有修复程序应用于 Grin ++和 libmw，并将等待审计人员的最终审查。事实证明，C++的实现是非常复杂的，相关的审计给了我教训。作为这个过程的一部分，我学到了很多，因此 Grin++& libmw 代码库明显变得更好了。再次感谢 Grin、Beam 和 LTC 社区的贡献者，他们使审计成为可能。
在 Grin++方面，我们已完成了一个成功的计划硬分叉，解决了硬分叉前的同步问题，并且 Grin ++ 0.7.5 现在已经可用，它是迄今为止最稳定的版本。
而二月份的首要任务，就是实施莱特币扩展区块（EB）的共识规则，包括所有验证和一整套测试。这是代码中最重要的部分，因此要确保所有详细信息正确无误，并且代码具有完整的测试覆盖范围，而这将非常耗时。一旦完成，我将为扩展区块（EB）开发 API，这样我们就可以开始将 LBMW 集成到现有的莱特币代码库中。
我还将集中精力全面审查新的单侧交易提案，如果未发现重大的安全问题，我将创建一个 LIP （莱特币改进提议）以供社区反馈。
从这个帖子当中，我们可以看到，目前 David Burkett 正在为莱特币开发的 Mimblewimble 应用方案正处于初期阶段，而其中最大的进展就是非交互式交易提案。
那么，这个神奇的方案具体是如何实现的呢？下面我们来看提案译文：
Mimblewimble 离线交易提案
Mimblewimble 区块链协议通过使用 pedersen 承诺、schnorr 签名和一种称为‘cut-through’的新技术，可提高比特币等加密货币的隐私性和可扩展性。而带来这些好处的同时，也需要付出一些昂贵的代价。到目前为止，构建 MW 交易需要发送方和接收方之间的交互来创建输出并集体签署交易。本文提出了一种在最小化影响 mimblewimble 协议可扩展性及隐私性条件下，实现单侧交易的方法。
当前的 Mimblewimble 协议
和比特币一样，Grin 也使用了 UTXO 模型。交易是通过包含要花费的输入、创建相等或较低价值的新输出，以及签名和构建验证输入所有权的范围证明（range proof）来创建的。
与比特币不同的是，Grin 使用了保密交易（CT）技术，因此输入和输出是 pedersen 承诺（rG + vH）。与添加到输入的签名不同，每笔交易只有一个签名，它是交易内核的一部分。
为了使交易有效，必须满足以下条件（为简单起见，忽略交易费用和交易补偿）：
这三者的结合，证明了发送者（ sender）是输入的所有者，并保证在交易中没有新的币被创造出来。
而这种协议就要求发送者（Alice）与接收者（Bob）进行交互以构建交易，以避免暴露彼此输入和输出的盲因子。这是一个三步过程：
1.Alice 用她的输入创建一笔未签名交易，改变输出和范围证明（rangeproof），一个包含输出和输入盲因子差异的中间内核，并提交给 schnorr 签名的 nonce；
2.Bob 创建他的输出和范围证明（rangeproof），添加他在内核承诺（commitment）中的份额以生成实际的交易内核，提交到 nonce，并提供交易内核的部分签名；
3.Alice 签署她的内核签名，并聚合这两个签名；
虽然该协议可以运作，并且允许 Alice 不受限制地将资金转移到 Bob，但是交互属性带来了一些安全性、可用性和隐私方面的挑战。构建交易要么需要用户保持密钥在线，要么需要某种形式的带外通信，而这可能导致隐私泄露和 MITM 攻击。
建立非交互式交易
长期以来，绝大多数人都认为在 mimblewimble 协议中不可能实现非交互式交易，因为知情输出盲因子对于创建范围证明（rangeproof）和构建 schnorr 签名而言是必要的。
而要解决这个问题，我们必须首先找到一种方法，让发送者和接收者都知道盲因子，而不是其他人。而 Diffie-Hellman 密钥交换算法很适合解决这一问题。发送方只需生成一个密钥对，使用接收方的 pubkey （公钥）执行 ECDH，并生成一个共享密钥，该密钥可用作盲因子。然后，发送方可以生成接收方的输出、盲因子和签名，以创建有效的交易。
但这种方案，也带来了两个明显的问题。
第一个问题是，发送方仍需要将其公钥和值传递给接收方，因此我们需要在不影响隐私的情况下将其作为输出的一部分包含进来。但是没有明显的方法可提交数据。我们不能将它作为内核的一部分，因为它会将内核链接到输出，从而消除隐私的好处。
第二个问题是 Alice 和 Bob 最终都拿到了资金的密钥，这意味着 Bob 没有成为资金的独家所有人，也不可能解决纠纷。我们需要一种方法来验证只有 Bob 才能花费输出。
新的提案
事实证明，在范围证明（rangeproof）中可以加密近 32 字节的数据。例如，如果我们使用一个已知的密钥 blake2b(output_commitment)，我们就可以公开提交一些额外的数据。如果我们在范围证明（rangeproof）中「加密」的数据是哈希，那么我们实际上就可以公开提交所需的数据。这允许我们纳入一个新的数据块 (output_data)，其中包含：
然后，我们就可以添加以下用于验证输出的共识规则：
3.ripemd160(blake2b(output_data)) 必须与重绕的范围证明数据的前 20 个字节匹配；
节点必须存储所有 UTXO 的 output_data，因此在之后使用时，我们还可以要求 1 个新的共识规则来验证输入：
每个输入都必须包含一个有效的签名：sig(receiver_pubkey, input_commitment)
输入和输出可以继续像往常一样被修剪，我们现在提供了一种向接收者发送资金的方法，并保证发送者无法重花费这些资金。
安全性
因为发送方和接收方都知道输出的盲因子，所以仅仅根据内核验证当前的 UTXO 集是不够的。这需要验证所有最近输入的签名，我们建议新节点验证最近 X 区块的所有输入签名，其中 X=coinbase 成熟值，因为风险是相似的。
而这仍然会留下一个在今天看来不太可能实现的攻击点。这种攻击的工作方式如下（假设过去一天的输入签名经过验证 ）：
尽管这种攻击在理论上允许你花费任何币龄的币，但它们必须是攻击者之前发送的币，而且没有被接受者花费掉。然而，这种攻击能够带来的效益，不太可能覆盖掉进行重组攻击的代价。不过，为了谨慎起见，当你收到大量币时，你只需要自己花掉这些币，就可以防止这种攻击，而所需的额外内核成本却很小。
隐私问题
只要密钥对不被重用，上面提到的方案就不会泄露任何额外的隐私。为了确保这一点，我们建议对输出数据进行一个相当小的修改，以支持某种形式的隐秘地址（ISAP 或 DKSAP）。
支付证明
现在，支付可相当容易地进行证明。要证明一笔支付的所有必要条件，是原始输出、范围证明（rangeproof）、output_data 以及显示范围证明（rangeproof） MMR 成员身份的 merkle 证明。
多重签名钱包
目前，要安全地将资金发送到多重签名钱包，需要发送者和所有接收方进行交互。而新提案消除了这种需要，代价是造成多重签名钱包隐私性方面的损失。
其他改进
由于我们现在有一种方法来提交额外的数据，并将其作为输出的一部分，我们可以将费用或者其它数据从内核移到 output_data 结构当中，这就允许进行修剪，从而减少区块链的大小。
致谢
感谢 John Tromp 对重组攻击的详细描述，感谢 Jasper van der Maarel 关于防弹证明（ bulletproofs）和多重签名钱包技术方面提供的建议，感谢 Phyro 提出的将内核细节移动到输出数据结构中的建议。同时，非常感谢 Daniel Lehnberg、Antioch Peverell、Phyro 以及 Vladislav Gelfer 对以上设计提供的宝贵反馈意见。
微信扫一扫 
