Mimblewimble可实现非交互式交易,莱特币、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)。与添加到输入的签名不同,每笔交易只有一个签名,它是交易内核的一部分。
为了使交易有效,必须满足以下条件(为简单起见,忽略交易费用和交易补偿):
-
输出承诺的总和减去输入承诺的总和必须等于内核承诺,即
(r_out1..n*G +v_out1..n*H) - (r_in1..n*G +v_in1..n*H) = r_kern*G
; -
对某些已知消息基点G的内核excess value
(rk = sum(ro1..n) - sum(ri1..n))
的一种签名; - 一种证明所有输出值都不是负的范围证明(rangeproof);
而这种协议就要求发送者(Alice)与接收者(Bob)进行交互以构建交易,以避免暴露彼此输入和输出的盲因子。这是一个三步过程:
- Alice用她的输入创建一笔未签名交易,改变输出和范围证明(rangeproof),一个包含输出和输入盲因子差异的中间内核,并提交给schnorr签名的nonce;
- Bob创建他的输出和范围证明(rangeproof),添加他在内核承诺(commitment)中的份额以生成实际的交易内核,提交到nonce,并提供交易内核的部分签名;
- Alice签署她的内核签名,并聚合这两个签名;
建立非交互式交易
长期以来,绝大多数人都认为在mimblewimble协议中不可能实现非交互式交易,因为知情输出盲因子对于创建范围证明(rangeproof)和构建schnorr签名而言是必要的。而要解决这个问题,我们必须首先找到一种方法,让发送者和接收者都知道盲因子,而不是其他人。而Diffie-Hellman密钥交换算法很适合解决这一问题。发送方只需生成一个密钥对,使用接收方的pubkey(公钥)执行ECDH,并生成一个共享密钥,该密钥可用作盲因子。然后,发送方可以生成接收方的输出、盲因子和签名,以创建有效的交易。
但这种方案,也带来了两个明显的问题。
第一个问题是,发送方仍需要将其公钥和值传递给接收方,因此我们需要在不影响隐私的情况下将其作为输出的一部分包含进来。但是没有明显的方法可提交数据。我们不能将它作为内核的一部分,因为它会将内核链接到输出,从而消除隐私的好处。
第二个问题是Alice和Bob最终都拿到了资金的密钥,这意味着Bob没有成为资金的独家所有人,也不可能解决纠纷。我们需要一种方法来验证只有Bob才能花费输出。
新的提案
事实证明,在范围证明(rangeproof)中可以加密近32字节的数据。例如,如果我们使用一个已知的密钥
blake2b(output_commitment)
,我们就可以公开提交一些额外的数据。如果我们在范围证明(rangeproof)中“加密”的数据是哈希,那么我们实际上就可以公开提交所需的数据。这允许我们纳入一个新的数据块 (
output_data
),其中包含:
- 发送人的短暂公钥;
- 接受者公钥;
-
输出值(使用
ECDHE(sender's key, receiver's key)
加密); -
输出的盲因子(使用
ECDHE(sender's key, receiver's key)
加密);
-
每个范围证明(rangeproof),通过使用
blake2b(output_commitment)
都是可重绕(rewindable)的; -
每个输出都必须包含
output_data
(其中包括sender_pubkey
、receiver_pubkey
和一些附加加密数据); -
ripemd160(blake2b(output_data))
必须与重绕的范围证明数据的前20个字节匹配;
output_data
,因此在之后使用时,我们还可以要求1个新的共识规则来验证输入:
-
每个输入都必须包含一个有效的签名:
sig(receiver_pubkey, input_commitment)
安全性
因为发送方和接收方都知道输出的盲因子,所以仅仅根据内核验证当前的UTXO集是不够的。这需要验证所有最近输入的签名,我们建议新节点验证最近X区块的所有输入签名,其中X=coinbase成熟值,因为风险是相似的。而这仍然会留下一个在今天看来不太可能实现的攻击点。这种攻击的工作方式如下(假设过去一天的输入签名经过验证 ):
- Alice创建一笔包含用于Bob输出的交易;
- Bob将Alice买的东西寄给对方;
- 几天(甚至可能几年)过去了,而Bob仍旧没有花掉他的币;
- Alice强制对过去一天+1个区块进行一次大的重组。然后,她可以将Bob的输出发回给自己,因为她知道盲因子,并且未对超过1天的区块中的交易进行签名验证;
隐私问题
只要密钥对不被重用,上面提到的方案就不会泄露任何额外的隐私。为了确保这一点,我们建议对输出数据进行一个相当小的修改,以支持某种形式的隐秘地址( 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对以上设计提供的宝贵反馈意见。原文:https://litecointalk.io/t/mimblewimble-progress-update-thread/26678/13 https://gist.github.com/DavidBurkett/32e33835b03f9101666690b7d6185203 作者:David Burkett 编译:洒脱喜 稿源(译):巴比特资讯(http://www.8btc.com/article_551018)