莱特币内的MW代码审核

英文原文

翻译：DeepL，Google translate 校对：李林

Litecoin基金会授权Quarkslab审核MimbleWimble协议在Litecoin区块链中的实施。该协议作为一个侧链，其隐私性比经典链更好。

介绍

自2016年中MimbleWimble协议（MW）的白皮书发表以来1 2，人们对它的兴趣越来越大，因为它提供了更强的交易匿名性和更好的网络扩展性。这个名字的灵感来自于哈利波特的一个舌头打结的咒语3。有一些关于MW的文献4和它的基本概念，如无脚本的脚本5, 6。为了使MW在专用区块链中切实可行，人们提出了两种实现方式。GRiN和Beam。

Litecoin基金会已经决定在Litecoin中整合这种隐私功能。然而，Litecoin是一个基于UTXO的区块链，而MW的内部运作方式则完全不同。尽管如此，MW的操作还是可以被整合到侧链中。在基于比特币的区块链的现有侧链中，有闪电网络（LN）和Liquid。LN是为了扩容，而MWEB（MimbleWimble扩展区块）则主要侧重于隐私。

侧链必须采用自己的验证步骤，主链必须验证到侧链的交易是否有效。MWEB项目7预计将在未来几个月内部署。

对莱特币内部使用MW的审计由两位工程师进行，总时长为45天（每位审计师22.5天）。像往常一样，审计并不能证明代码没有错误，而是反映了在分配的时间内可以付诸实践的理解和攻击方案。重点是LIPs（Litecoin改进建议）的实施，描述了MW交易的验证和两个链之间的互动。评估的完整报告可以在这里找到。

莱特币的侧链

扩展块

Litecoin基金会没有为MW专门修改Litecoin，而是在LIP0028中提出了一个实现挂钩侧链9的一般框架，可以通过比特币10的标准BIP009矿工信号机制来激活。双向挂钩是一种机制，可以在一侧锁定硬币，在另一侧释放硬币，反之亦然。这个过程确保了两个链之间硬币的1-1映射。

在这个机制中，UTXO可以被挂入侧链上，使其可以在侧链上使用，也可以被挂出，离开侧链，在经典链上被释放。这样的建议需要以下两个主要部分。

  • 一个集成交易（ExtTxn），它是典型链上的一个专门交易，与侧链进行挂入、挂出交易。矿工创建的那个交易具体是区块的最后一个。

  • 一个扩展地址（ExtAddr），一个任何人都可以花费的bech32地址，作为扩展区块（EB）的接口。因此，在每个区块中，该地址正好包含侧链中的硬币数量。币被挂在这个地址，并从这个地址挂出。它在每个区块都会改变。

一个EB更新也可以定义额外的共识规则，以便接受一个经典区块和它的EB对应物。这些规则只能是更具限制性的。在这个框架中，矿工负责开采整个区块集（经典区块和EB区块）。作为开采过程的一部分，矿工必须创建连接两个区块的ExtTxn。

莱特币内的MimbleWimble

MWEB（MimbleWimble扩展区块）是MW在Litecoin中使用EB框架提案的整合。该集成在LIP00311中描述，并进一步定义了侧链上硬币的处理。

MW利用保密交易12和防弹13来对抗单独的保密交易或ZK-STARKs或ZK-SNARKs，因为它提供了最紧凑的交易，避免了可信的设置。

作为EB实现，ExtTx被称为HogEx，代表霍格沃茨快递交易，ExtAddr被称为HogAddr，代表霍格沃茨地址。后者将使用新版本（版本9）的见证程序。下面的模式显示了一个LTC块和它的MW对应物的简化视图。

如图所示，用户的peg-in交易表示在MWEB世界中作为接收者的承诺（在MWEB区块中作为内核记录）。在HogEx交易中，矿工将这些硬币花费到新的HogAddr。同样地，币可以通过在MWEB端创建一个peg-out来挂出，该peg-out表明一个金额和要发送硬币的LTC地址。这个内核在canonical侧被具体化为来自先前HogAddr的输出。

在MWEB世界中的交易（MW-to-MW）看起来不像传统的Litecoin交易，但遵循相同的工作流程。事实上，它们会进入mempool 14，但会被开采到MWEB区块而不是LTC区块中。

关于MW扩展块集成和对Litecoin代码库的修改的更多细节可以在报告15的第四部分找到。

MW中的密码学组件

MW广泛地使用Pedersen承诺16、Schnorr签名1718和Bulletproofs13。所有这些方案的基础操作之一是基于secp256k1 19，它允许重用已经包含在Litecoin中的底层密码库的一部分。然而，这些方案（还）没有包含在Litecoin的核心密码库中：新的基元被包含在secp256k1-zkp目录中，接近于这个实现。我们特别审查了LIP00420的一些元素，以及通过代码中的C++包装器的API调用。

另外，为了使原始的MW协议更加可用，还对其进行了一些修改。例如，LIP00420描述了一种使MW非交互式的方法，这是一种让发送者单独建立交易并通过隐形地址21向接收者传输信息的方法，用于花费硬币。

报告15的第5节包含了更多关于审查Litecoin内部的MW密码学的信息。

安全审计

审计区块链会引起具体的安全问题，但增加侧链功能会带来一系列新的潜在问题，例如，共识问题或链之间的资产数额差异。值得庆幸的是，MWEB是一个同步的侧链，因为它们都以同步的方式生成一个新的区块，这减少了可能出现的问题的范围。这明显避免了分叉相关的问题。评估的安全方面有两个方面，侧链的安全问题和MW实施的保密性问题。应该保留的基本安全属性有以下几点。

  • 所有在Litecoin中已经定义的共识规则（政策）必须被保留下来;
  • 新的共识规则需要对所接受的区块有更多的限制，以便通过软分叉来接受;
  • 在任何时候，挂入的硬币之和都应该等于侧链上的硬币数量;
  • 侧链上的交易金额应该在排放者和接受者之间保持保密.

与大多数区块链一样，威胁模型认为由矿工产生的交易和区块是不可信任的。完整的审计报告 here:

发现

多个低影响的缺陷已经被发现，但在影响共识的区块验证过程中，一个更重要的安全问题被发现。如图所示，著名的比特币核心功能CheckBlock、CheckTransaction、AcceptBlock或ConnectBlock在侧链代码中找到了它们的对应物。

即使执行验证的代码已经实现，MW侧的CheckBlock函数也没有从典范侧正确调用。从理论上讲，它能够实现微妙的验证问题和共识问题，允许接受被破坏的块。值得庆幸的是，这个问题可以轻而易举地被解决。报告中提到的问题已被仔细修复。

结论

我们要感谢莱特币基金会使这项评估成为可能，并感谢大卫-伯克特在审计过程中的承诺和反应。

  1. Tom Elvis Jedusor (anonymous), MIMBLEWIMBLE, 19 July 2016. https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt ↩︎

  2. Andrew Poelstra, Mimblewimble, 6 October 2016. https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf ↩︎

  3. Harry Potter fandom, Tongue-Tying Curse. https://harrypotter.fandom.com/wiki/Tongue-Tying_Curse ↩︎

  4. TariLabs, Mimblewimble Implementation. https://tlu.tarilabs.com/learning-paths/mimblewimble ↩︎

  5. Andrew Poelstra, Mimblewimble and Scriptless Scripts, RWC 2018. https://www.youtube.com/watch?v=ovCBT1gyk9c ↩︎

  6. TariLabs, Introduction to Scriptless Scripts. https://tlu.tarilabs.com/cryptography/introduction-to-scriptless-scripts ↩︎

  7. Litecoin Core integration/staging tree. https://github.com/ltc-mweb/litecoin ↩︎

  8. Andrew Yang, David Burkett and Charlie Lee, Extension Blocks (Consensus layer), 22 October 2019. https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki ↩︎

  9. Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón and Pieter Wuille, Enabling Blockchain Innovations with Pegged Sidechains, 22 October 2014. https://blockstream.com/sidechains.pdf ↩︎

  10. Shaolin Fry and Luke Dashjr, Version bits with lock-in by height, 01 February 2017, https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki ↩︎

  11. Andrew Yang, David Burkett and Charlie Lee, MimbleWimble via Extension Blocks (Consensus layer) 2021. https://github.com/DavidBurkett/lips/blob/master/lip-0003.mediawiki ↩︎

  12. Greg Maxwell, Confidential Transactions. http://diyhpl.us/wiki/transcripts/gmaxwell-confidential-transactions/ ↩︎

  13. (1, 2) Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille and Greg Maxwell, Bulletproofs: Short Proofs for Confidential Transactions and More, IEEE S&P 2018. https://crypto.stanford.edu/bulletproofs/ ↩︎

  14. temporary storage of transactions yet to be included in a block. ↩︎

  15. (1, 2) Full report of the assessment ↩︎

  16. Torben Pryds Pedersen, Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing, CRYPTO 1991. https://doi.org/10.1007/3-540-46766-1_9 ↩︎

  17. Claus-Peter Schnorr, Efficient Signature Generation by Smart Cards, Journal of Cryptology 4(3), pp 161-174. http://www.neven.org/papers/schnorr.pdf ↩︎

  18. Pieter Wuille, Jonas Nick and Tim Ruffing, Schnorr Signatures for secp256k1, 17 May 2021. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki ↩︎

  19. Daniel R. L. Brown, SEC 2: Recommended Elliptic Curve Domain Parameters, version 2.0, 27 January 2010. https://www.secg.org/sec2-v2.pdf ↩︎

  20. (1, 2) David Burkett, One-Sided Transactions in Mimblewimble, 28 December 2020. https://github.com/DavidBurkett/lips/blob/master/lip-0004.mediawiki ↩︎

  21. Peter Todd, [Bitcoin-development] Stealth Addresses, 6 January 2014. https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03613.html ↩︎