拆解MimbleWimble 的隐私魔法-part II
2、CoinJoin 混合交易
在过去有许多人认为在比特币的交易图上,能够看到「哪笔输数对应到哪笔输出」是一件非常容易暴露隐私的地方,因此 Gregory Maxwell(是的,又是他)题出了一个叫做CoinJoin的概念,他要做的事情非常简单,就是将两笔交易混合。
在MW协议以钱,有许多钱包或者额外的服务,就有配置CoinJoin的服务于其间,例如WasabiWallet和Tumblebit、JoinMarket,然而单靠Coinjoin却依旧是不安全的,大家仍旧可以从交易数额中试图去还原,同时因为是个别的服务,参与的人数太少,在资金匹配上也需要花一定的时间。这时候佛地魔在MW协议中将CoinJoin的技术,结合机密交易(CT),就能够避免交易能够从「数字」方面去被推敲出来,同时在交易路径上也可以透过CoinJoin的技术被混淆。而且和过去个别使用CoinJoin的服务不同的地方,是这次Mimblewimble,彻底把CoinJoin写在了协议层,如此一来不需要靠第三方的钱包或者服务帮忙就能完成这一件事情,而且有机会让混合交易变的更有效率。
但现在就要开心的庆祝隐私交易的魔法能够实现,就还太早了,因为即使混合交易数额,我们还是能够知道交易双方的公钥,并且能透过这些公钥址去尝试重构每一笔交易,因此在这样的情境下,我们必须要有新的公私钥系统,来确保隐私安全。
3、OWAS (One-wayAggregate Signatures,单向聚合签名)
Jedusor在他的初略版白皮书中,提出了可以用 Yuan Horas Mouton的单向聚合签名(One-way Aggregate Signatures,简称OWAS)的方式去完成,比较有趣的一点是在Andrew Poelstra在他详细版的白皮书中,却没有用到OWAS这个词,而是在Sinking Signature还有compact chain中去验证这个技术,甚至连后来开发Grin的Ignotus Peverell的Github的MW简介中,也没出现OWAS这个词,而是直接说TransactionAggregation(交易聚合),不知道这个专有名词,为什么在这个三个重要的MW文件中,出现的方式会略有不同,但在此还是以OWAS去代称(我知道在之前已经有如 Boneh等学者在研究聚合签名)。
所谓的聚合签名,就是指当你看到很多交易的输入以及输出时,我们将不能再把这些输入及输出的公钥重新拆解,并且拼凑出一个完整的交易顺序,因此我们将所有签名聚合在一起,并且不能使他逆向被还原。
OWAS由两个部分组成,一是Kernel Excess(内核剩余),一是Kernel Offsets(交易核偏移因子),还记得我们所说的致盲因子之差吗?对的,就是Alice既要传送钱给Bob,又不希望Bob知道他的私钥(致盲因子),于是他给他了(致盲因子差)*G,这时候我们为了避免人家从交易中的公钥推测出交易途径,我们用了单向聚合签名的方式来降低大家知道这个值的可能性,因此我们产生了以下算式
透过这种方式,我们就可以将最后作为的公钥的余项(例如刚才上面在讲机密交易时的50*G)拆分成两部分,例如X*G拆成(x1+x2)*G,这时候大家能构让外界看到的值x1*G就是所谓的Kernel Excess,你可以把它看作是公钥;而另外一部分就是x2*G,称作Kernel Offsets,他会和这个区块中所有交易的KernelOffsets一起被相加,而当他们这么多个KernelOffsets被相加后,你也就看不出来,哪个Kernel Offset是哪一笔交易中的了,所以这个方法才会被叫做单向聚合签名,因为他没办法在做逆向工程了。因此,当一笔MW上的交易在给矿工验证时,我们可以想象KernelExcess就是公钥,而Kernel Offsets是私钥。
到此,隐私交易的部分就彻底完成了,我们在此简短重复一次
1-1、机密交易-加法同态:确保在不知道交易金额的情况下验证等式两边成立
1-2、机密交易-范围证明:确保在零知识证明下,每个输入输出值大于零,避免凭空创造多余金钱。
2、混币交易:让我们无法从交易数额中去回推交易路径
3、单向聚合签名:让交易的公钥不会被暴露出交易路径
三、Cut-through核销:减少矿工储存状态
cut-through是MimbleWimble中一个针对矿工的精巧设计,他能够确保的是矿工不需要长期存储这么多的交易状态,而cut-through的概念就是在一笔交易已经被确定其所有权的情况下(也就是被验证)后,只要能够维持输入等于输出(input=output),那么过程中多余的内容都可以被删除。例如原本的几个交易可能长这个样子
然而在这里必须特别说明,我认为Cut-through的概念并非能够在目前实作的两个项目中(Grin&BEAM),达到很好的隐私,例如在Grin中,其实Cut-through的功能是能够被关掉的,只要将~/.grin/main/grin-server.tomlar的archive_mode从
archive_mode = false
变成
archive_mode = true
in ~/.grin/main/grin-server.toml
如此一来矿工的节点就不会执行核销的动作。因此我认为目前部分外界人士,可能认为Cut-through能够透过删除资料来解决隐私,就目前的实作来看可能会是一个误解。
四、MinbleWimble的后续效应与限制
MimbleWimble不但是一个许多隐私协议所组成的隐私币区块链协议,更是许多过去比特币社群所遇到问题时,一些原本在比特币上无法实现的好方法被应用的好场景,然而MimbleWimble也像是练就了某种神功后,具有某些后遗症的武者,因此在最后,我试图去探讨,MimbleWimble会产生什么后续的影响,以及发展可能有甚么样的限制。
1.挑战其他隐私币的地位和公链设计原则
笔者认为,MimbleWimble协议所影响的,首先是挑战既有隐私币的地位,例如Monero和Zcash,MW协议中不但不需要为了验证交易的合法性,而保留以验证的交易作废列表,同时Cut-through的功用,也让矿工能够减少储存已验证的状态这种较为不合理的手法。另外,我认为MW协议也是少数,用减少数据储存来达到可扩展性的公链设计手法,同时他也减少了许多区块链中应该要被矿工所记载的内容,在MW中,一笔交易里面矿工要知道什么:最主要的就是交易有效性与通货膨胀,可能会影响未来不具高度智能合约需求的货币项目,往这样的方向去发展。
2.限制
虽然MW在隐私协议上采取了非常巧妙的手法,去实现了匿名交易。但其本身依旧有某一些限制,在此我将他分为三点:一是RangeProof所占的容量影响交易状态储存的容量;二是交易实作上的使用体验;三则是智能合约等等货币交易以外的区块链功能实现能力。
2-1、Range Proof所占的容量影响交易状态储存的容量
上文曾经说过,透过Cut-through,我们能够减少矿工的储存内容物,避免状态大量累积的问题,然而,在MW区块链中,无法被删减的,是每笔输入与输出中的范围证明(range proof),Range Proof是一个简单的零知识证明(688bytes),容量相较于交易讯息本身(单个交易约33bytes),相较而言其实是非常大的差距,这也是会影响未来矿工储存数据,以及未来可扩展性的关键。
2-2、共同构建交易的实作体验
在MW协议下的交易,我们必须要交易双方共同去将一笔交易完成,例如Alice寄钱给Bob,Bob必须证明他知道交易金额,并且在回传讯息给Alice,最后交易经过Alice验证运算后才完成,这样的过程不需要同步在在线完成,但需要交易双方共同构建,和比特币、以太坊等等密码货币那种只需一方传送金额签章到区块链上的概念较为不同,因此目前例如在Grin上,有两种方式可以进行交易:
-
寄送档案: Bob需要收到交易档案(transaction file),并且生成一个回应的档案(response file),并且寄回给Alice。
-
网页(HTTP):Bob的Grin钱包必须要监听一个端口。无论Alice的钱包甚么时候寄给他,Bob的钱包都会自动执行既有的步骤。但这却有一个比较苛刻的条件,就是钱包需要在一个固定的IP地址下,并且你的钱包客户端要持续运作才能完成。
-
这些过程其实都是非常不人性,很难在未来普及使用。目前Grin有开发一个新钱包grinbox,目标是能够像比特币一样的交易,但很持续在开发中,如果未来有任何消息,我会持续更新。
2-3、货币交易之外如智能合约等功能的扩展现制
MimbleWimble和比特币较为不同的是其较难支持区块链中的交易脚本,这也导致了如比特币可以实现的简单智能合约、或者闪电网络等等,然而,我认为这或许是大家已经不太震惊的MW缺点所在了,而且目前就笔者所见,已经有一些有趣的项目被展开,例如精确版MW白皮书的撰写人:Blockstream的 Andrew Poelstra,目前正在研究透过无脚本脚本(scriptless-scripts)的方式来创造MimbleWimble上简单的应用,同时也有人实现了Grin上的原子交换。或许未来可能有更轻巧的智能合约实现方式出现。
本文来源: 区块链研究实验室
- 免责声明
- 世链财经作为开放的信息发布平台,所有资讯仅代表作者个人观点,与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论,请提供相关材料,发送到:2785592653@qq.com。
- 风险提示:本站所提供的资讯不代表任何投资暗示。投资有风险,入市须谨慎。
- 世链粉丝群:提供最新热点新闻,空投糖果、红包等福利,微信:juu3644。