比特币上的有效性汇总
- john-light
- 发布于 2022-11-03 16:39
- 阅读 25
该文章深入探讨了比特币上的有效性汇总（Validity Rollups），这是一种 Layer 2 技术，旨在提高比特币的可扩展性、隐私性和可编程性。文章详细介绍了有效性汇总的历史、工作原理、构建方法，以及相关的优势、成本和风险，分析了其在不牺牲比特币核心价值和功能的前提下，改进比特币的潜力，并探讨了潜在的风险和折衷方案。
比特币上的有效性 Rollup
John Light 著
联系作者：<https://lightco.in/contact>
托管在 GitHub
<h2> 目录 <sup id="toc"></sup></h2>
- 致谢
- 前言
- 第 0 节. 有效性 Rollup 的历史和前史
- 第 1 节. 有效性 Rollup 简介
- 第 2 节. 有效性 Rollup 用户体验
- 第 3 节. 启用新功能
- 第 4 节. 扩展改进
- 第 5 节. 在比特币上构建有效性 Rollup
- 第 6 节. 有效性 Rollup 的成本和风险
- 结论
- 附录 A. 比较有效性 Rollup 与其他协议
- 附录 B. 比较替代加密货币隐私技术
- 附录 C. 通过链下数据可用性提高吞吐量
- 附录 D. 进一步了解有效性侧链
- 附录 E. 通过有效性证明启用额外的吞吐量增加
- 附录 F. 减轻来自受损的密码学证明协议和有毒废物的危害
- 许可证
- 参考文献
<h2> 致谢 <sup id="acknowledgements"></sup></h2>
本报告是作者参与人权基金会 ZK-Rollup 研究奖学金 的成果。ZK-Rollup 研究奖学金的资金支持由 Starkware 和 CMS Holdings 提供。作者感谢这些组织的支持。
作者还要感谢以下个人，他们回答了问题、提供了见解和想法，和/或提供了有助于本报告产出的反馈：Alex Gladstein、Eric Wall、Olaoluwa Osuntokun、Dario Sneidermanis、Jameson Lopp、Pete Eyre、Jeremy Rubin、Ruben Somsen、Patrick Dugan、Eli Ben-Sasson、Matt Corallo、Francis Corvino、Louis Guthmann、Vitalik Buterin、Trey Del Bonis、Alberto Garoffolo、Sebastián Gustavo Reca。（姓名顺序已 随机化。）
请注意，包含在本致谢部分不应被解释为对本报告内容的认可。任何声明、结论、意见、错误，等等，均属于作者本人，除非另有明确说明。
<h2> 前言 <sup id="preface"></sup></h2>
自从中本聪首次公开发布比特币以来，它的支持者、批评者和怀疑者都质疑该协议将如何随着时间的推移随着使用量的增加而扩展。 这个问题在今天比以往任何时候都更加重要，因为区块越来越多地被交易填满或接近填满。 所谓的“Layer 2”（L2）协议（如闪电网络）已被部署以将一些交易量“链下”处理，但即使闪电网络也需要使用一些比特币区块空间。 显而易见的是，随着比特币被世界上越来越多的人口（包括人类和机器！）采用，将需要更多的区块空间。 另一个问题是比特币有限的脚本功能是否有助于或阻碍其作为电子现金的价值。 研究人员和发明家已经表明，通过提高交易隐私、支持新型智能合约，甚至创建全新的基于区块链的资产，可以为比特币首次实现的电子现金交易赋予新的形式。
十多年来对扩展和扩展比特币等区块链功能的研究所产生的结果之一是有效性 Rollup 的发明。 鉴于已经实施有效性 Rollup 的区块链所观察到的好处，现在的注意力转向了它们是否也有利于比特币和现有的比特币 L2 协议（如闪电网络）的问题。 我们通过从多个角度检查有效性 Rollup 来探索这个问题，包括它们的历史、它们在技术层面上如何工作、它们如何在比特币上构建，以及在比特币上构建它们的益处、成本和风险可能是什么。 我们的结论是，有效性 Rollup 有可能提高比特币的可扩展性、隐私性和可编程性，而不会牺牲比特币作为点对点电子现金系统的核心价值或功能。 鉴于有效性 Rollup 作为其父链的密码学安全扩展的“无需信任”性质，并且鉴于比特币作为最安全的结算层的地位，甚至可以说这些协议彼此天作之合。
<h2> 第 0 节. 有效性 Rollup 的历史和前史 <sup id="section-0-the-history-and-prehistory-of-validity-rollups"></sup></h2>
<h3> 第 0.1 密码学证明在加密货币中的早期应用 <sup id="section-01-early-applications-of-cryptographic-proofs-in-cryptocurrencies"></sup></h3>
> 这是一个非常有趣的话题。 如果找到了解决方案，那么比特币的实现会更好、更简单、更方便。
>
> 最初，币可以只是一个签名链。 通过时间戳服务，旧的签名最终可以被删除，以避免过多的回溯扇出，或者币可以单独或以面额保存。 需要检查是否存在双重支出，这需要全局了解所有交易。
>
> 挑战在于，如何证明不存在其他支出？ 似乎一个节点必须知道所有交易才能验证这一点。 如果它只知道 input/output 点的哈希值，它就无法检查签名以查看 output 点是否已被使用过...
>
> **在这种情况下，很难想到如何应用零知识证明。**
>
> 我们试图证明不存在某物，这似乎需要了解所有内容并检查是否未包含该物。
>
> — 中本聪 [^1]自从比特币的创造者中本聪首次考虑如何使用零知识 (zk) 证明技术来改进他发明的电子现金协议以来，已经过去了十多年。 Zk 证明最初由 Goldwasser、Micali 和 Rackoff 在他们 1985 年的论文“交互式证明系统的知识复杂性”中描述，是一种密码学证明，定义为“除了所讨论命题的正确性之外，不包含任何其他知识的证明”。[^2] 在那篇开创性论文发表 35 年后，以及中本聪首次讨论在比特币中使用 zk 证明 10 年后，密码学证明协议现在是前沿区块链扩展和隐私协议的核心组成部分。
在比特币环境中首次使用 zk 证明的具体提议来自 Greg Maxwell，他在 2011 年的比特币维基中写了关于“零知识条件支付”的文章。 Maxwell 后来与 Sean Bowe、Pieter Wuille 和 Madars Virza 合作，于 2016 年实施了该协议。[^3][^4] 2013 年 5 月，Miers 等人发表了 Zerocoin 论文，展示了如何将 zk 证明直接集成到比特币协议中以隐藏比特币交易中涉及的地址。[^5] 同月，Eli Ben-Sasson 在加利福尼亚州圣何塞举行的比特币 2013 大会上发表了一篇演讲，描述了除了提高隐私之外，通用（图灵完备）密码学证明也可以用于扩展比特币。[^6] 这些早期提案预示并激发了后来密码学证明的实现，这些证明已用于为 “主网” 生产环境中的真实用户改进区块链的隐私性和可扩展性。
第一个将 zk 证明技术部署到主网的加密货币是 Firo（前身为 Zcoin，前身为 Moneta），它是 Zerocoin 协议的实现，于 2016 年 9 月推出。[^7] 紧随其后的是 Zcash 的推出，它是第一个使用 Zerocash 协议实现 zk-SNARK 证明的加密货币，于 2016 年 10 月推出。[^8] Zcoin 和 Zcash 中 zk 证明在生产中用于隐私，以及 Ben-Sasson 等人在改进区块链可扩展性的密码学证明方面展示的潜力，导致了对改进该技术的投资和研究的增加。 这种增加的投资反过来又导致了密码学证明的能力和性能的显着提高。[^9]
<h3> 第 0.2 通往有效性 Rollup 之路 <sup id="section-02-the-road-to-validity-rollups"></sup></h3>
在对密码学证明技术在加密货币中的适用性进行一般研究的同时，一项平行的研究也在进行中，专门用于提高加密货币的可扩展性。 这条扩展研究的道路最终将与密码学证明研究结合。
扩展研究人员需要解决的根本问题是，为了避免中心化（审查、双重支出、腐败等）的危险，几乎所有加密货币用户都必须能够轻松地在网络上运行“完整节点”，并有助于确保区块生产者遵循加密货币共识协议规则，并且如果需要或必要，可以自己成为区块生产者。[^10][^11] 为了让几乎所有用户都能轻松运行完整节点，验证区块链的计算工作必须受到限制。 这使得去中心化与规模化相矛盾。 随着加密货币（尤其是比特币）的普及多年来不断增长，这种紧张关系变得越来越重要。 尽管多年来提出了和实施了各种各样的方法，但加密货币开发人员和研究人员主要集中在四种主要技术上，试图解决去中心化和规模化之间的紧张关系：链上优化、网络优化、分片和链下交易执行。
链上优化技术减少了处理和存储完整节点必须执行的交易所需的资源量。 这可以通过减少每个区块中交易占用的字节或 gas 大小，和/或通过减少验证交易所需的计算资源来实现，例如通过优化用于签名验证的库。 这种优化已显着改善了比特币核心中的交易验证和初始区块下载时间。[^12] 对于支持更具表现力的智能合约语言的区块链，“gas 优化”技术同样可以显着节省成本并提高吞吐量。[^13]
网络优化扩展技术有两个主要目标：一个是减少区块传播延迟，另一个是降低作为比特币网络上的完整节点参与的带宽成本。[^14] 减少区块传播延迟的好处是，通过减少孤块的数量来提高确认的确定性，并通过消除更快带宽速度的优势来使挖矿更加“公平”。 这有助于可扩展性，因为如果可以更快地中继更大的区块，那么它们对矿工中心化的负面影响就会更小。 这种技术的一个例子是 FIBRE，这是一个由 Matt Corallo 开发的协议，可以将区块传播时间缩短到比光速慢几毫秒。[^15] 降低作为网络中的完整节点参与的成本的好处是，运行完整节点的成本更低且更容易，从而提高了网络的去中心化。 这有助于可扩展性，因为可以在不增加带宽成本的情况下增加交易容量。 这种技术的一个例子是 BIP-152，也称为“紧凑区块中继”，它也是由 Matt Corallo 基于 Greg Maxwell 的早期工作开发的。[^16] BIP-152 减少了通过比特币点对点网络传播区块时需要发送的数据量，从而降低了完整节点的带宽成本。
分片是一种技术，其中加密货币的区块处理和存储被分成两个或多个节点组。 安全在分片之间共享，因此没有一个分片比任何其他分片更容易受到攻击。 分片的效果是，完整节点可以确信所有加密货币的共识规则都得到遵循，而只需要存储和执行网络上发生的所有交易的一小部分。 分片越多，在不增加任何给定完整节点的计算负担的情况下可以支持的吞吐量就越多。 Vitalik Buterin 在 2014 年 10 月发表的一篇博客文章中首次提出分片作为扩展以太坊协议的一种手段。[^17] 分片区块链的第一个实现是 Zilliqa，它于 2019 年 1 月上线。[^18] 以太坊开发人员仍在计划实施分片，尽管它的具体工作方式随着时间的推移而发生了变化。[^19]
链下交易执行协议旨在减轻“基础层”完整节点网络的资源负载。 当链上加密货币交易广播到网络时，完整节点必须“执行”该交易，以确保其根据协议的共识规则有效。 交易的执行方式取决于协议的具体细节； 例如，某些协议要求完整节点执行脚本以确定交易的有效性，而某些协议仅要求完整节点检查签名的有效性。[^20] 如果遵循所有协议规则，则可以确认交易，并将其转发给其他节点以进行验证。 如果违反任何协议规则，则该交易将被删除。
链下交易执行协议将交易执行转移到单独的“更高层”网络。 然后，“基础层”上的完整节点只需要执行一系列在下一个更高层链下执行的交易中的第一笔（存款）和最后一笔（提款或最终结算）交易。 第一个链下执行协议是比特币支付通道的一个版本，由中本聪在 2011 年发给 Mike Hearn 的一封私人电子邮件中首次描述，后来由 Mike Hearn 和 Matt Corallo 于 2013 年 6 月在 bitcoinj 中实现。[^21][^22] 今天，为比特币构建的最流行的链下交易执行协议是闪电网络，这是一个去中心化协议，通过双向支付通道网络路由链下支付。[^23]
2017 年，以太坊上的代币销售和繁殖小猫的普及导致区块空间拥堵，导致 gas 价格飙升和交易确认延迟。[^24] 就在以太坊首次尝到“主流”采用之际，其设计的局限性阻止了区块链的使用量进一步增加。 可扩展性成为优先事项，应用程序和协议开发人员开始寻找解决方案。[^25] 安全性换取吞吐量的短期解决方案，例如侧链，Swift 被实施。[^26][^27] 开发人员社区不满足于侧链，并继续寻找圣杯：一种扩展解决方案，可以在不放弃自我托管或损害完整节点去中心化的情况下实现更多使用。 虽然社区预计以太坊最终的分片升级将显着提高可扩展性，但迫切需要一个更近期的解决方案，并且人们理解可以通过将分片与其他扩展解决方案相结合来获得更大的扩展收益。[^28]
深入探索的一种拟议解决方案是状态通道，这是首先在比特币上实现的支付通道协议的概括。[^29][^30] 状态通道有几个局限性，使其不适合作为以太坊上正在构建的所有不同类型应用程序的通用扩展解决方案：它们难以构建用于许多用户在不同时间来来去去的 多方应用程序，它们需要昂贵的资本锁定，并且它们要求用户在线接收更新和提出争议。
另一个备受关注的提议解决方案是 Plasma。 Plasma 最初在 Vitalik Buterin 和 Joseph Poon 于 2017 年 8 月发布的白皮书中描述，是一种将交易执行转移到链下的技术，同时仍将安全性植根于以太坊“Layer 1”（L1）区块链中。[^31] 与状态通道相比，主要的改进是，像侧链一样，与状态通道不同，用户不必锁定大量流动性并管理通道余额。 然而，像状态通道一样，Plasma 存在一些问题，使其无法被视为圣杯扩展解决方案。
早期版本的 Plasma 存在“大规模退出问题”，如果 Plasma 运营商行为不端，可能会导致 L1 拥堵并将提款延迟数周。[^32] 大规模退出问题是另一个问题，即数据可用性问题的结果。[^33] 问题在于，为了能够单方面从 L2 协议退出，用户需要能够证明他们目前拥有他们试图退出的资产。 然而，如果构成 L2 协议当前状态的任何数据丢失，即使是单个数据位，例如，因为区块生产者已经提交了最新区块的状态根，但尚未发布区块本身，那么用户将没有生成退出所需密码学证明所需的所有数据，并且他们的资金将被冻结，直到数据可用为止。
Plasma 通过使用户能够在节点检测到提交到 L1 的最新状态的数据不可用时以他们最后已知的余额退出，从而解决了数据可用性问题。 该解决方案的代价是用户必须将一些 plasma 链数据放在 L1 上才能退出，如果许多用户必须同时退出，这将需要在 L1 上进行大量数据和交易，从而导致 批量退出问题。 后来版本的 Plasma 使批量退出问题减少了，但仍然要求用户在线并验证 plasma 链和提款以监控不当行为。[^34] Plasma 最重要的问题可能是难以添加对图灵完备智能合约的支持，例如以太坊 L1 上支持的智能合约。[^35][^36] 这使得 Plasma 对希望以太坊虚拟机 (EVM) 的灵活性的开发人员没有吸引力。
2019 年，以太坊开发人员开始思考如何以解决 Plasma 和状态通道存在的其他问题（例如在线/交互性要求）的方式解决数据可用性问题和 EVM 兼容性问题。 这导致开发人员重新审视旧的提案，这些提案要求用户为每个 L2 交易在 L1 上发布最少量的数据。[^37] 这种在链上放置最少数据但保持链下交易执行的协议类别被称为“rollup”（其名称来自 Barry Whitehat 对有效性 rollup 的首次实施）。[^38]
Rollup 根据确定状态转换是否有效的方式分为两个主要变体：乐观 rollup，它使用错误证明来强制执行正确的状态转换，以及有效性 rollup，它使用有效性证明来强制执行正确的状态转换。 （有效性 rollup 通常也称为“zk-rollup”，但由于并非所有有效性 rollup 都使用 zk 证明，因此这可能用词不当。）[^39] 由于它们依赖于密码学有效性证明，可以自动防止无效的状态转换和提款，因此有效性 rollup 被认为是“无需信任的”，即，除了正常的 L1 信任假设之外，没有其他信任假设。 相比之下，如果有人试图从乐观 rollup 中进行无效提款，那么为了阻止无效提款，至少必须有一个诚实的一方在线，注意到无效提款尝试，构建并提交错误证明交易，并且能够 在乐观 rollup 协议定义的挑战期内确认错误证明交易。 实际上，乐观 rollup 用户信任区块生产者不会从乐观 rollup 智能合约中窃取资金，而有效性 rollup 用户不信任区块生产者不会窃取资金，因为他们无法做到。 请参阅第 6.4 节中的 “多数易受攻击合约”。
通过解决先前可扩展性提案的最重要缺点，以太坊开发人员开始推动 rollup 功能的极限。 例如，Fuel 和 Loopring 团队分别为 p2p 支付和原子交换构建了乐观 rollup 和有效性 rollup，Aztec 团队为 Zerocash 风格的“屏蔽”交易构建了有效性 rollup。[^40][^41][^42] 最终，以太坊开发人员甚至弄清楚了如何构建完全 EVM 兼容的 rollup，首先使用乐观 rollup，然后使用有效性 rollup。[^43][^44]（应该注意的是，截至撰写本文时，以太坊上除 Fuel 之外的所有实时 rollup 都依赖于多重签名来保护其桥合约，这是一种不同于“真正的”rollup 的安全模型，后者完全依赖于其父链的共识 安全 – Edan Yago 开玩笑地称这些 rollup 为“非常乐观的”rollup。[^45][^46] 期望随着这些协议的成熟，它们将过渡到“真正的”rollup 安全模型。）
这就把我们带到了今天。 以太坊开发人员已经围绕 rollup 重新设计了他们的整个路线图，其他区块链也采取了类似的以 rollup 为中心的方法。[^47][^48][^49][^50] 鉴于对 rollup 技术的大量兴奋和投资，并且鉴于无需信任的有效性 rollup 与比特币的无需信任精神的一致性，人们可能会想：有效性 rollup 也适合比特币吗？ 为了回答这个问题，我们必须首先退后一步并回答更基本的问题：在技术上是否可以在比特币上构建有效性 rollup？ 如果在技术上可以在比特币上构建有效性 rollup，那么这样做的好处、成本和风险是什么？[^51]
<h2> 第 1 节. 有效性 Rollup 简介 <sup id="section-1-an-introduction-to-validity-rollups"></sup></h2>
Rollup 是一种区块链，它将状态根和至少足够的交易数据存储在不同的“父”区块链的区块内，以从创世区块重新计算当前状态，同时将交易执行“链下”转移到单独的节点网络。 这与其他相关协议（如状态通道、侧链和 validia 链）形成对比，这些协议也链下执行交易，但也将绝大多数（如果不是全部）交易数据保留在链下。 Rollup 的操作与其他区块链完全相同：交易被捆绑到区块中，这些区块被广播到网络进行验证，有效区块被添加到先前区块的链“顶部”。 （与其他区块链一样，如果存在多个有效区块竞争添加到链顶部，如何选择将哪个区块添加到链顶部的区块取决于 rollup 共识规则。）
有效性 rollup 是迄今为止发明的两个主要 rollup 变体之一。[^52] 有效性 rollup 之所有被称为有效性 rollup，是因为它们使用密码学“有效性证明”来确保新的 rollup 区块遵循 rollup 协议的规则。 每次 rollup 区块生产者创建有效性 rollup 区块时，区块生产者都会向父链提交状态更新交易。 Rollup 状态更新交易包含有关 rollup 区块中每个状态转换的数据、应用区块中状态转换后的新 rollup 状态根，以及证明数据可用性并证明新 rollup 状态根是对上次在父链上确认的有效 rollup 状态根的有效更新的有效性证明。 只有附带有效证明的状态更新交易才能在确认时成功推进 rollup 状态。 具有无效证明的状态更新交易将被确认，但交易将还原并失败（或者它们将被完整节点完全拒绝，并且永远不会被确认；这取决于实现）。
rollup 的另一个变体是乐观 rollup，之所以如此命名，是因为 rollup 提款被“乐观地”认为有效，并且只有在受到质疑时才被证明为有效或无效。[^53] 乐观 rollup 依赖于至少一方进行观察 rollup 智能合约是否存在无效状态更新，并在发现无效状态更新时提交质疑交易。 为了质疑乐观 rollup 状态更新的有效性，必须在挑战窗口期间（通常持续数小时到数天之间）在父链上确认有效的“错误证明”。 如果错误证明有效并在挑战窗口内得到确认，则无效更新将被取消，从而保护 rollup 用户免受潜在盗窃。 通常，保证金会在提交更新和质疑交易时发布在 rollup 合约中，以防止恶意攻击。 如果保证金的所有者行为不端，例如通过提交无效状态更新或无效质疑，则他们的保证金将被“削减”，即删除或重新分配给诚实方。
无论 rollup 是有效性 rollup 还是乐观 rollup，rollup 的安全性都强烈依赖于其与父链的关系。 这种关系为 rollup 提供了其他“链下”协议所缺乏的两个关键特性：继承的双重支出安全性和安全的双向桥。
有关比较有效性 rollup 与其他链下协议的表格，请参见 附录 A。
<h2> 第 2 节. 有效性 Rollup 用户体验 <sup id="section-2-the-validity-rollup-user-experience"></sup></h2>
<h3> 第 2.1 部署有效性 Rollup <sup id="section-21-deploying-a-validity-rollup"></sup></h3>
要创建有效性 rollup，需要在父区块链上实现一个协议，该协议定义了有效性 rollup 的工作方式。 该协议包括详细信息，例如 rollup 共识规则、如何验证 rollup 区块是否遵循共识规则、如果有多个竞争的区块生产者，如何选择 rollup 区块生产者、用于将资产从父链移动到 rollup 并返回到父链的协议 等。Rollup 协议通常实现为部署到父链的智能合约，但是 rollup 也可以直接在父链的共识规则中实现，使其成为“永久 rollup”。[^54]
一旦在父链上定义了 rollup 的规则，就可以发布 rollup 的创世区块，并且区块生产者可以开始推进 rollup 的状态。 如今，所有在生产中部署的 rollup 都使用中心化区块生产者，通常是为了降低实现的复杂性和上市时间。 这被认为是可接受的权衡，因为即使中心化的区块生产者完全停止区块生产，用户仍然可以在父链上确认一笔交易，这允许他们单方面退出 rollup。[^55] 这种单方面退出机制在 第 2.3 节 中有更详细的描述。 随着现有在生产中的 rollup 成熟，预计它们将过渡到去中心化区块生产。[56][^57]
对于生成的每个 rollup 区块，rollup 交易数据都存储在父链上的状态更新交易中，以及 rollup 区块有效性的密码学证明（“有效性证明”——可能也可能不是“零知识”性质）。 一旦状态更新交易在父链上得到确认，rollup 区块就被认为已通过 rollup 完整节点确认，并被添加到 rollup 链顶部。 为了重新组织已在父链上确认的 rollup 区块，也必须重新组织确认该 rollup 区块的父链区块。 这为 rollup 提供了继承的双重支出安全性功能。
<h3> 第 2.2 使用有效性 Rollup <sup id="section-22-using-a-validity-rollup"></sup></h3>
要开始使用 rollup，新用户有两个选择：要么将现有资产从父链转移到 rollup，要么接收来自已经在 rollup 上拥有资产的人的转移。 将资产从父链转移到 rollup 很简单：用户向父链上的 rollup 合约发送一个存款交易，指定要从其地址存款的资产和数量，以及应该接收存款的 rollup 地址。 一旦存款交易在父链上得到确认，用户将在指定的 rollup 地址中收到他们的资产，然后他们可以像使用基础层区块链一样自由地将资产转移到任何其他 rollup 地址。
能够自由地将rollup上的资产转移到任何其他rollup地址，使得新用户很容易上手，他们要么在父链上没有资产，要么不想支付将资产从父链转移到rollup的成本。 接收来自已经在rollup上拥有资产的人的转移就像共享一个rollup地址并等待rollup区块确认一样容易。 新的rollup用户无需像使用诸如闪电网络之类的状态通道协议那样，首先建立入站流动性。
可选功能：即时确认
为了完全继承父链的双重支出安全性，必须在父链区块中确认rollup区块。 这将rollup交易确认延迟与父链的确认延迟联系起来。 因此，例如，如果父链区块时间平均为十分钟，则rollup区块的确认速度平均不会低于十分钟。
为了提供更好的用户体验，rollup区块生产者可以提供由密码经济安全保证支持的~即时确认。 区块生产者将首先将抵押品存入智能合约作为安全保证金。 当区块生产者收到要包含在区块中的交易时，他们将向交易接收者发出已签名的收据，承诺该交易将包含在下一个区块中。 如果该交易未按承诺包含在下一个区块中，则签署收据的区块生产者将有他们的抵押品由安全保证金智能合约重新分配，其中一部分抵押品用于补偿未按承诺确认交易的用户，而任何剩余的抵押品 都将被烧毁。
经济处罚为交易接收者提供了强有力的保证，即累计价值低于安全保证金价值的未决交易将按承诺确认。 因此，接收者可以将来自区块生产者的已签名收据视为“像现金一样好”，从而为他们的交易提供~即时确认。[^58]
<h3> 第 2.3 退出有效性 Rollup <sup id="section-23-exiting-a-validity-rollup"></sup></h3>
要将rollup上的资产转移回父链上的地址，rollup用户向rollup提交一个提款交易，指定要提款的资产和数量，以及应该接收提款的父链地址。 一旦提款交易在rollup上得到确认，提款的资产将从rollup账本中删除，父链上的rollup智能合约会将提款的资产发送到指定的父链地址。
如果rollup区块生产者不合作，例如拒绝将用户的提款交易包含在rollup区块中，则用户可以单方面从rollup中提取资金。 他们可以使用已存储在父链上的rollup区块数据来创建一个有效性证明，这将说服父链完全节点，他们当前拥有一定数量的他们想要提款的资产，然后通过将其直接提交到父链上的rollup智能合约来推动他们的提款交易 。 通过将rollup状态根更新和rollup区块数据存储在父链上，并使用有效性证明来确保提款的有效性，有效性rollup为其用户提供了一条通往父链的安全桥梁（并通过扩展，其他建立在父链上的有效性rollup）。[^59]
有效性rollup桥梁为用户提供了两项重要保证：1) 只有可以加密证明资产所有权的用户才能在rollup上转移该资产或将该资产提取回父链，以及 2) 只要用户可以获得必要的交易在父链上确认，用户始终可以推进rollup的状态，包括单方面从rollup中退出返回到父链，即使rollup区块生产由于任何原因完全停止。 这些保证使rollup上持有的资产与父链上持有的资产具有相同级别的所有权安全性。
<h3> 第 2.4 案例研究: 传递 #tBTCzkSyncTorch <sup id="section-24-case-study-passing-the-tBTCzkSyncTorch"></sup></h3>
有效性rollup的第一个多用户应用程序之一是#tBTCzkSyncTorch，这是一个由Eric Wall于2020年9月发起的社交媒体游戏。游戏很简单：Wall将一些TBTC（以太坊上的“无需信任的BTC”）存入zkSync，一个L2有效性rollup，然后告诉他的粉丝：
要接收火炬（价值100美元，可以兑换由ETH抵押品保护的真正的mainnet BTC），只需发布你的以太坊地址。 无需设置。 然后我将把火炬转移给我信任的人，他们不会带着它逃跑。 然后你也会这样做。 我们看看它能走多远。[^60]
图 1. #tBTCzkSyncTorch 的可视化
图片来源: [^61]
然后，Wall 从他信任的人那里挑选了一个地址，并使用 zkSync 将一些 TBTC 发送到该地址。 接收者在他们自己的 Twitter 帐户上发布了类似的消息，并将“火炬”转移到下一个地址。 如此等等，直到火炬最终返回到 Wall 手中。 他一直持有 TBTC，直到他对它有其他用处。 2022年2，在俄罗斯政府入侵乌克兰之后，乌克兰政府公布了一个以太坊地址，用于收集来自世界各地人们的捐款，以协助他们的抵抗行动。Wall 决定使用 torch 资金进行捐赠，并在 zkSync 上提交了一笔交易，将 TBTC 提回到以太坊 L1。
图2. Eric Wall 的 zkSync 提款，如 zkscan.io 区块浏览器所示
图片来源: [^62]
当时，zkSync 只有一个由 zkSync 的开发公司 Matter Labs 运营的区块生产者，并且 Matter Labs 每隔几个小时才发布一次区块。因此，在 Wall 于 zkSync rollup 上提交提款交易大约五个小时后，提款在以太坊 L1 上得到确认，他收到了 L1 地址中的 TBTC。然后，Wall 将 TBTC 换成 ETH 并将 ETH 捐赠给了乌克兰政府。[^63]
现在让我们将 #tBTCzkSyncTorch 体验与 #tBTCzkSyncTorch 所基于的社交媒体游戏 #LNTrustChain 进行比较。#LNTrustChain 游戏的工作方式类似：笔名为 Hodlonaut 的人从比特币闪电网络上的 0.001 BTC 开始，然后将 torch 传递给其他人，后者添加少量 BTC，然后将 torch 传递给其他人，依此类推，形成一个长长的“信任链”。[^64] 信任链之所以得名，是因为 torch 的每个接收者都被信任不会仅仅将 BTC 据为己有，而是添加更多 BTC 并将其传递给他们信任的会这样做的其他人。
由于闪电网络是一个支付通道网络，因此 #LNTrustChain 中的用户必须在彼此之间建立通道，或者沿着具有足够出站和入站流动性余额的通道路径连接，以便他们可以发送和接收 torch。在许多情况下，这种流动性需求给 torch 的潜在接收者带来了问题。[^65]
图3. #LNTrustChain 参与者寻求入站流动性以确保可以传递 torch。
图片来源: [^65]
相比之下，#tBTCzkSyncTorch 参与者从未遇到任何流动性问题。根据设计，不可能发生此类流动性问题。Rollup 的功能类似于区块链，用户可以发送价值高达其钱包全部余额的付款，而无需担心路由流动性，并且用户可以接收付款，而没有入站容量限制。无需在通道中锁定资金或管理入站/出站流动性即可在 rollup 上发送和接收付款，就像在闪电等支付通道网络中所需的那样。这些功能使有效性 rollup 具有更高的资金效率，并且至少对于新用户而言，比闪电更用户友好。
应该注意的是，这是一个苹果与橙子的比较：zkSync 是一个使用具有全局状态的区块链数据结构的 rollup，而闪电是一个具有点对点本地状态的支付通道网络。这些协议表面上相似，因为它们都被认为是 L2 协议，并且都促进支付。除此之外，它们在“底层”具有重要的根本区别。因此，将两者进行比较并不是说闪电与有效性 rollup 相比没有其自身的优势，例如极低的成本、高度安全、高速/高吞吐量的链下交易。但是，正如 #LNTrustChain 用户体验所证明的那样，让闪电达到 p2p 支付可用状态的挑战揭示了其设计中固有的权衡和粗糙之处，而 rollup 由于其基于区块链的设计而避免了这些问题。
更全面地了解闪电网络以及它与有效性 rollup 相比如何，对比和补充（反之亦然），可以在 第 4.4 节 中找到。
<h2> 第 3 节. 启用新功能 <sup id="section-3-enabling-new-functionality"></sup></h2>
有效性 rollup 的一个有趣的特性是，它们可以为父链添加全新的功能，而无需任何额外的共识规则更改。之所以成为可能，是因为父链全节点不需要知道 rollup 的具体共识规则，也不需要知道如何按照这些规则执行交易，只需要知道如何验证 rollup 的有效性证明。因此，例如，在比特币 L1 上构建的 L2 有效性 rollup 可以实现一个执行环境，该环境支持更灵活的智能合约语言或更高级的隐私技术，而无需对比特币进行任何其他更改。[^66]
<h3> 第 3.1 节. 新的智能合约语言 <sup id="section-31-new-smart-contract-languages"></sup></h3>
自从比特币早期以来，人们就设想了额外的脚本功能，以实现比比特币原生支持的更多类型的资产和智能合约。[^67] 此后的几年中，新的功能已作为脚本（比特币的原生脚本语言）的扩展或使用全新的智能合约语言来实现。以下是一些已提出的新智能合约语言：
- Cairo: https://www.cairo-lang.org/cairo-welcome-on-board/
- Clarity: https://clarity-lang.org/
- Huff: https://docs.huff.sh/get-started/overview/
- Lexon: http://www.lexon.tech
- Move: https://github.com/MystenLabs/awesome-move
- Michelson: https://tezos.b9lab.com/michelson
- Noir: https://noir-lang.github.io/book/index.html
- Simplicity: https://blog.blockstream.com/en-simplicity-github/
- Sway: https://fuellabs.github.io/sway/v0.18.1/
- Yul: https://docs.soliditylang.org/en/latest/yul.html
- zkMove: https://www.zkmove.net/
如今，有两种方法可以在比特币环境中使用这些编程语言：
- 将对它们的支持构建到比特币中，作为“嵌入式共识”层（例如，Omni，Counterparty）[^68]
- 将对它们的支持构建到替代区块链中（例如，一种 altcoin 或一条侧链）[^69]
在这两种情况下，这些替代编程语言都将无法在本机上操作 BTC。相反，需要构建一个桥（在文献中也称为“双向锚定”），该桥将锁定比特币主链上的 BTC，在新执行环境内释放等量的 BTC IOU，并实施一些机制来将 IOU 转换回主链上的 BTC。[70] 如今，可以构建往返于任意复杂执行环境的桥的类型受到比特币共识规则的限制，并且通常被认为不如直接使用比特币主链安全。[^71][^72]
如果可以在比特币上构建具有替代执行环境的有效性 rollup，那么比特币用户可以在保留比特币 L1 的完整“自我托管”所有权安全性的同时，尝试这些替代执行环境。由于在比特币上构建的有效性 rollup 能够在本机上操作 BTC，因此有效性 rollup 将消除对 BTC IOU 的需求。此外，由于比特币全节点仅需验证正确计算的证明，而无需实际重放执行 rollup 交易所需的完整计算，因此在有效性 rollup 中实施这些替代执行模型对比特币全节点几乎没有额外的计算负担。
第 3.2 节. 新的隐私保护 <sup id="section-32-new-privacy-protections"></sup></h3>
比特币的透明性使得建立在链上的隐私协议本质上是脆弱的，因此不足以长期保持隐私。[^73] 链下 L2 协议（例如，闪电和 zkChannels）具有其自身的隐私挑战和限制，这在很大程度上是由于这些协议所基于的比特币基础层的透明性和有限的脚本功能。[^74][^75] （有关最近提出的对支付通道网络隐私的改进，请参阅 2022 年 8 月的 zk-PCN 论文。[^76]） 由于比特币固有的隐私限制以及现有工具的不成熟，比特币用户必须遵循冗长而详细的指南，以了解如何获得某种程度的隐私，仔细地遵循每个步骤，并希望其他用户也这样做，以便他们可以保留其匿名集，否则将其 BTC 放弃给中心化或联合的链下系统，以便在其他地方获得更强大、更易于使用的隐私。[^77][^78][^79]
自从中本聪首次考虑如何使用 zk 证明来提高比特币隐私以来，密码学家们发明了新的协议，大大提高了私有加密货币交易的质量和可用性。有效性 rollup 使得可以在比特币上实施这些新的隐私协议，同时继承 L1 上拥有的 BTC 的完整所有权安全性。这将为比特币用户提供最先进的隐私，而无需放弃对其 BTC 的自我托管。此外，通过在比特币共识规则中实施足够灵活的证明验证系统，可以使比特币具有面向未来的特性，从而可以在无需对比特币进行任何进一步的共识级别更改的情况下采用隐私协议的新进展。
可以实施的一种新的隐私技术示例是零知识、端到端加密的交易技术，该技术最初在 Zerocash 白皮书中进行了描述，后来在 Zcash 中得到了实施。[^80] Zerocash 端到端加密交易（也称为“屏蔽交易”）提供了当今最好的隐私，以加密方式隐藏了交易金额、发送方地址和接收方地址。屏蔽交易还提供了最大的理论匿名集，其上限为 匿名集等于使用屏蔽协议进行的屏蔽交易总数。[^81]
例如，如果到目前为止已经进行了 1,000,000 笔屏蔽交易，则下一次交易的匿名集上限为 1,000,000，因为每次之前的交易都可能由不同的用户收到。因此，下一个发送者可能是多达 1,000,000 个先前接收者中的任何一个，从而为他们提供了一个包含 1,000,000 个可能用户的匿名集，可以在其中隐藏自己。（当然，与同一唯一接收者关联的每次先前交易都会降低匿名集的上限。还必须考虑区块链之外的去匿名化技术，例如在网络层。）
2021 年 3 月，Aztec rollup 在以太坊上启动，成为第一个在生产中实施 Zerocash 协议的 rollup。[^82] Aztec 的开发人员将该协议称为“zk-zk-rollup”，因为 zk 证明既用于为用户提供强大的隐私，又用于向 L1 上的 Aztec 智能合约证明 rollup 交易的有效性。[^83] 通过将受保护的交易转移到 rollup 中，Aztec 能够为用户提供比在 L1 上执行相同类型的交易显着的成本节省。通过转移到 zk-zk-rollup 而不是在比特币 L1 上进行交易，比特币用户同样可以获得强大的隐私和私有交易的成本节省。
图4. 在 aztec.network 区块浏览器中显示的 Aztec 屏蔽交易
图片来源: [^84]
可以在 附录 B 中找到对可以在有效性 rollup 中实施的新链上私有交易技术的比较。
由于其客观上优越的隐私保护，在第4节中的可扩展性讨论中，屏蔽交易被用作在比特币上的有效性 rollup 中实施新的私有交易协议的示例。
<h2> 第 4 节. 扩展改进 <sup id="section-4-scaling-improvements"></sup></h2>
<h3> 第 4.1 节. 通过有效性 rollup 提高吞吐量 <sup id="section-41-increasing-throughput-with-validity-rollups"></sup></h3>
James Prestwich 在区块链环境中将扩展定义为“在相同的硬件上验证更多交易”。[^85] 按照此定义，有效性 rollup 可以通过增加获得父链完整安全性的交易数量来改进扩展，而父链全节点无需（或只需少量）额外的计算成本。有效性 rollup 改进扩展的确切程度取决于实施细节。（请注意，本节中的交易大小和吞吐量数字是近似值，可能会因实施细节而异。）
如果有效性 rollup 的设计方式类似于比特币，具有未使用的交易输出 (UTXO) 模型且没有地址重用，则每个 rollup 交易将为 113.5 个权重单位 (WU)。这等于具有 1 个输入和 2 个输出的 pay-to-witness-public-key-hash (P2WPKH) 交易的权重，其中见证已删除（因为见证已替换为涵盖所有 rollup 交易的有效性证明），并假设见证折扣应用于交易中的所有数据（因为父链全节点不需要执行这些交易或将其存储在 UTXO 集中）。
如果有效性 rollup 使用具有地址重用的帐户模型（即，每个用户一个地址），则可以将每个 rollup 交易的权重减少到 12 WU。[^86] 这是因为可以将公钥分配给 rollup 上的帐户号码，然后可以以高度压缩的格式安全地表示这些公钥。然后，发送方和接收方只需通过其帐户号码来引用，而无需在每笔交易中包含公钥或地址。在父链上确认的状态更新交易中，也可以删除或压缩在非 rollup 交易中使用更多字节的其他 rollup 交易详细信息。
如果有效性 rollup 使用基于 UTXO 的屏蔽交易模型，则必须考虑交易数据的两个组成部分：加密的交易注释详细信息 (530 WU) 和连接拆分数据 (129 WU)，从而使每个 1 输入 2 输出的屏蔽 rollup 交易的总权重为 659 WU。[^87] 这使得屏蔽交易比原生隔离见证 1 输入 2 输出的 P2WPKH 交易略重（以 WU 为单位）。考虑到它们可能具有 更大 的匿名集，并且超过“2”的匿名集后，透明的 P2WPKH 交易变得比屏蔽交易重得多，因此屏蔽交易的更大的链上占用空间可能会被认为是此类交易的可接受成本，从而显着提高了私有交易的质量和可用性。
按 WU 比较每种交易类型：
表 1. 按权重单位比较不同的交易类型
| 交易类型 | 未折扣数据权重 (4x) | 折扣数据权重 (1x) | 总计 (WU) |
|---|---|---|---|
| Rollup 帐户模型 | 0 | 12 | 12 |
| Rollup 1 输入 2 输出 UTXO | 0 | 113.5 | 113.5 |
| 主链 1 输入 2 输出 P2WPKH | 453 | 108 | 561 |
| Rollup 屏蔽 1 输入 2 输出 UTXO | 0 | 659 | 659 |
表 1 说明：有效性 rollup 帐户模型是高度压缩格式的 L2 交易。[86] 有效性 rollup 1 输入 2 输出 P2WPKH 是 L2 P2WPKH 交易，其中删除了 27 字节的见证（因为见证已替换为涵盖所有 rollup 交易的有效性证明），并且见证折扣应用于交易中的所有数据（因为父链全节点不需要执行这些交易或将其存储在 UTXO 集中）。[^88] 主链 1 输入 2 输出 P2WPKH 是比特币 L1 上的原生隔离见证交易。[88] Rollup 屏蔽 1 输入 2 输出是加密的 L2 交易，其中见证折扣应用于交易中的所有数据。[^^87]
为了以“最小可能的 rollup 交易的倍数”来直观地比较每种交易类型，我们可以像在图 5 中那样将它们表示为块。
图 5. 以最小可能的 rollup 交易类型的倍数来直观地比较相似的交易。
图 5 说明：假设 12 WU 帐户模型有效性 rollup 的最小交易规模，比特币主链 1 输入 2 输出的 P2WPKH 交易比最小可能的 rollup 交易类型大 46.75 倍，该交易类型提供相同的功能（向单个接收者发送付款，并将一些找零返回给发送者）。
如果父链是比特币，并且每个区块的可用容量与今天相同（4,000,000 WU 或 1,000,000 vbytes），那么与 1 输入 2 输出的 P2WPKH 主链交易相比，没有地址重用的类似比特币的 UTXO 模型有效性 rollup 可以在每个区块中放入多达约 3.7 倍的交易。这假设 3,000,000 WU 被 rollup 区块中所有 rollup 交易的数据占用，而 1,000,000 WU 留给有效性证明、交易脚本和其他杂项交易数据。[^89] 在相同的假设下，帐户模型有效性 rollup 可以在每个区块中放入多达约 35 倍的交易。受保护的 rollup 每个区块可以减少约 36% 的交易，但如本节前面所述，这些交易的隐私配置文件和匿名集比类似大小的 P2WPKH 主链交易好得多，这可能使每个区块的交易减少成为可接受的权衡。
（如果地址比今天的比特币 L1 地址更短，则每个区块可能可以放入更多的 UTXO 模型 rollup 交易。Francois Grieu 提出了一种密码图设计，该设计长度为 16 个字符，具有高达 117 位的安全性。[^90] 如果地址为相对较短的时间内存储相对较少的价值，这可能是一个可接受的安全性权衡。）
<h4> 表 2. 根据给定的交易类型比较每个比特币主链区块可以放入多少交易 <sup id="table-2-comparing-how-many-transactions-can-fit-per-bitcoin-mainchain-block-based-on-a-given-transaction-type"></sup></h4>
| 交易类型 | 1,000,000 WU | 3,000,0000 WU | 总计 (tx/区块) |
|---|---|---|---|
| Rollup 帐户模型 | 有效性证明、脚本、其他 tx 数据 | 250,000 txs (12 WU/tx) | 250,000 |
| Rollup 1 输入 2 输出 UTXO | 有效性证明、脚本、其他 tx 数据 | 26,432 txs (113.5 WU/tx) | 26,432 |
| 主链 1 输入 2 输出 P2WPKH | 1,782.5 txs (561 WU/tx) | 5,347.6 txs (561 WU/tx) | 7,130 |
| Rollup 屏蔽 1 输入 2 输出 UTXO | 有效性证明、脚本、其他 tx 数据 | 4,552 txs (659 WU/tx) | 4,552 |
表 2 说明：请注意，这些数字假定见证折扣应用于作为 rollup 区块一部分的所有交易数据。该表将 L1 主链区块分为 1,000,000 WU 和 3,000,000 WU 两部分，以说明在 rollup 交易的情况下，必须将部分权重限制用于 rollup 有效性证明和脚本数据，而其余部分可用于 rollup 交易数据。
到目前为止，我们仅根据每个比特币区块中当前可用的数据存储空间来讨论吞吐量的增加。但是与比特币交易（即使是在具有交易规模优化（例如跨输入签名聚合）的假设世界中）不同，比特币全节点不必执行每个有效性 rollup 交易来确定它们是否有效。比特币全节点为验证一个区块的有效性 rollup 交易而必须执行的唯一计算是验证有效性证明。无论它是证明一笔交易的有效性还是证明完整区块的交易有效性，Rollup 有效性证明都花费相同的时间和计算量来验证。为了进一步利用计算效率的提高，可以为每个比特币区块提供额外的“哑存储”空间以用于 rollup 交易。这将使每个比特币区块可以容纳更多的 rollup 交易，而无需对比特币全节点施加任何额外的 CPU 负担。
有关如何通过实施链下和链上/链下混合数据可用性协议来获得更多吞吐量和成本节省的详细信息，请参阅 附录 C 和 附录 D。
有关有效性证明如何能够比单独的有效性 rollup 实现更大的吞吐量提高的说明，请参阅 附录 E。
<h3> 第 4.2 节. 使用 rollup 进行分形扩展 <sup id="section-42-fractal-scaling-with-rollups"></sup></h3>
有效性 rollup 提供的扩展收益不会在 L2 停止。有效性 rollup 可以叠加在有效性 rollup 之上，从而为几乎无限的扩展级别提供“分形扩展”。一旦比特币 L1 区块填满了 L2 有效性 rollup 交易，就可以在 L2 有效性 rollup 之上构建第 3 层 (L3) 有效性 rollup。然后，一旦 L2 有效性 rollup 区块填满了 L3 有效性 rollup 交易，就可以在 L3 有效性 rollup 之上构建第 4 层 (L4) 有效性 rollup，依此类推。[^91]
图 6. 分层 rollup
图 6 说明：一个图形，用于直观显示 rollup 如何相互叠加。在此示例中，有两个 L2 rollup：一个专门用于提供数据可用性（可能具有激励措施来惩罚数据不可用性攻击），另一个专门用于提供高安全性支付和合同。在 L2 数据可用性 rollup 之上，有三个 L3 rollup，每个都专门用于不同的用例：私有 p2p 支付、金融合约和游戏内资产所有权和转让。由于 L3 rollup 依赖 L2 全节点来实现数据可用性，因此它们可能被认为不如依赖比特币 L1 全节点来实现数据可用性安全性的 L2 rollup 安全。这种降低安全性的折衷方案是由于 L2 上数据存储成本较低而导致交易成本降低。需要高安全性的用例可以使用 L2 rollup，例如此处的高安全性支付和合同 rollup。
<h3> 第 4.3 节. 水平扩展有效性 rollup <sup id="section-43-horizontally-scaling-validity-rollups"></sup></h3>
随着需要在每个 rollup 层验证更多交易，创建必要的有效性证明的难度会增加。可以使用递归证明组合来并行化创建这些证明所需的计算。递归本质上是“证明证明的有效性”，因此许多计算机可以致力于证明不同交易的有效性，然后可以将这些证明最终组合成一个证明，从而允许多台计算机同时为证明 rollup 区块的有效性做出贡献来实现水平扩展。使用 SNARK 和 STARK 证明已经可以实现无需信任的递归证明组合。[^92][^93]
图 7. 递归证明工作流程
图片来源: [^93]
<h3> 第 4.4 节. 使用有效性 rollup 扩展闪电网络 <sup id="section-44-scaling-the-lightning-network-with-validity-rollups"></sup></h3>
闪电网络是一个去中心化的双向支付通道网络，该网络通过链下路由支付，并使用基础层区块链上的智能合约来进行争议解决和最终结算。[23] 闪电网络使任何两个通过具有足够流动性的通道路由连接的用户都能够近乎即时地发送和接收价值，并且通常比在结算层区块链上进行交易的成本要低得多。要以自我托管的方式加入闪电网络，用户必须首先确认一笔与另一闪电网络用户打开通道的交易。可以使用双重资助通道以单笔交易实现双向流动性。[^94] 打开通道后，以后可能需要额外的链上交易来进行维护，例如通道重新平衡或通道关闭以进行最终结算。
打开和结算（偶尔重新平衡）自我托管的闪电通道所需的链上交易会占用有限比特币区块空间的可测量数量。这种区块空间占用会导致可以在给定时间内加入闪电网络的自我托管用户数量存在硬性上限。[^95] 有效性 rollup 实现的额外交易容量可用于支持更多的闪电交易，从而增加可以以自我托管方式加入和使用闪电网络的潜在用户数量。确切的数字取决于用于闪电通道的交易类型。对于 2-P2WPKH-输入-1-P2WSH-输出-2-P2WPKH-输出双重资助通道，rollup 可以为多达 3.8 倍的闪电通道打开交易创造空间。
表 3. 比较不同类型的 UTXO 模型双重资助闪电通道打开交易的大小
| 交易类型 | 未折扣数据权重 (4x) | 折扣数据权重 (1x) | 总计 (WU) |
|---|---|---|---|
| Rollup LN 通道打开 | 0 | 197.5 | 197.5 |
| 主链 LN 通道打开 | 795 | 211 | 1006 |
表 3 说明：Rollup 交易是一种 2-P2WPKH-输入-1-P2WSH-输出-2-P2WPKH-输出交易，其中从每个输入中剥离了 27 字节的见证。主链交易是一种 2-P2WPKH-输入-1-P2WSH-输出-2-P2WPKH-输出交易。[^96]
表 4. 比较不同类型的 UTXO 模型双重资助闪电通道打开交易的每个区块容量
| 交易类型 | 1,000,000 WU | 3,000,0000 WU | 总计 (tx/区块) |
|---|---|---|---|
| Rollup LN 通道打开 | 有效性证明、脚本、其他 tx 数据 | 15,190 txs (197.5 WU/tx) | 15,190 |
| 主链 LN 通道打开 | 994 txs (1006 WU/tx) | 2,982 txs (1006 WU/tx) | 3,976 |
表 4 说明：区块分为 1,000,000 WU 和 3,000,000 WU 两部分，以说明在 rollup 交易的情况下，部分权重限制保留给有效性证明和脚本数据，而其余部分可用于 rollup 交易数据。
在彼此之上分层有效性 rollup 的能力也意味着可以根据需要添加闪电网络容量。每次 rollup 达到其最大容量时，都可以部署另一个 rollup 作为额外层，然后可以继续进行闪电网络加入，直到该层填满为止，依此类推。
尽管闪电网络最出名的是在比特币主链上结算，但是可以在任何与闪电网络兼容的区块链上打开和结算闪电通道。此外，如果有一个闪电网络节点在两个或多个链上打开了通道，则可以在这些不同链的用户之间路由支付，就像这些用户在同一链上打开了通道一样。如果通过闪电通道路由发送和接收不同的资产（例如，BTC 和 LTC），则存在“无意看涨期权问题”。[^97] 但是，在整个路由中使用相同资产的闪电通道路由，即使路由跨越多个链，也不会遇到此问题，或者至少在考虑到不同链上相同资产的不同版本之间的任何小价格差异时，此问题可以忽略不计。因此，在比特币 L1 上打开了闪电网络 BTC 通道的用户可以与在 L2+ 有效性 rollup 上打开了闪电网络 BTC 通道的用户无缝交易，前提是发送者和接收者之间存在具有足够流动性的路由。
图 8. 跨链闪电网络交易
图 8 说明：有三个闪电网络节点：闪电网络节点“A”在比特币主链上打开了一个通道，闪电网络节点“B”在比特币主链和专注于闪电网络的 rollup 上都打开了通道，闪电网络节点“C”在 rollup 上打开了一个闪电网络通道。B 与 A 和 C 都打开了一个双重资助通道，因此可以在它们之间路由支付，即使 A 和 C 各自在不同层上打开了通道。
<h2> 第 5 节. 在比特币上构建有效性 rollup <sup id="section-5-building-validity-rollups-on-bitcoin"></sup></h2>
在撰写本文时，几乎所有部署到生产环境中的有效性 rollup 都是在支持以图灵完备编程语言编写的智能合约的区块链上构建的。图灵完备编程语言的灵活性打开了一个广阔的设计空间，rollup 开发人员可以利用该空间将独特的特性和限制编程到 rollup 智能合约中，例如脚本功能、存款限制和可升级性。灵活性还意味着，随着有效性证明技术的改进以及发现实施或优化某些功能的新方法，rollup 开发人员可以升级其智能合约或部署新的智能合约，以跟上最新技术的发展。
尽管使用图灵完备编程语言构建 rollup 智能合约很流行，但可以使用比特币的原生图灵不完备编程语言 Script 在比特币上构建有效性 rollup，只需对 Script 支持的操作码进行相对较小的更改（就代码占用空间而言）。2022 年 3 月，Trey Del Bonis 发表了一篇文章，详细描述了比特币上的有效性 rollup 如何工作。[^98] 根据 Del Bonis 的说法，在比特币上支持有效性 rollup 所需的更改是一些额外的操作码，这些操作码启用了他的 rollup 设计的两个主要原语——有效性证明验证和递归盟约。Del Bonis 表示，即使并非严格要求，还有其他更改可以显着降低成本并提高 rollup 的效率，例如 OP_EVAL 和 P不太明显的是对递归约定(recursive covenants)的需求，至少在 Del Bonis 比特币 rollup 设计中是这样。 递归约定 是智能合约的一种类型，它限制了 BTC 一旦被花费后可以发送到的脚本类型。 Del Bonis 使用递归约定 来推动 rollup 结构随着每次状态更新向前发展，确保锁定在 rollup 脚本中且尚未被所有者提取的 BTC 从一个 rollup 状态更新到下一个状态更新仍然保留在该脚本中。 一旦 rollup 上的 BTC 所有者在 rollup 上确认有效的提款交易，他们就可以使用其 BTC 退出递归约定 脚本到他们指定的 L1 提款地址。
对比特币脚本的递归约定 更改长期以来一直被比特币社区考虑。[^99][^100][^101] 然而，目前还没有具体的提案在比特币开发者社区中达成广泛共识以实施递归约定 。 有一些提案，如 BIP-118 和 BIP-119，可以实现更有限的约定，但它们不具备确保发送到 rollup 的 UTXO 在其所有者准备将其提取回比特币 L1 之前保留在 rollup 中的递归属性。[^102][^103]
Del Bonis 的rollup 设计中另一个重要的更改是增加或删除堆栈元素大小限制。 这将使 rollup 脚本更容易处理 validity rollup 数据。 通过增加可以容纳在每次rollup 状态更新中的交易数量，它还可以降低 rollup 的使用成本，从而使 rollup 更新的成本可以由更多数量的交易分摊。[^98] 在“锦上添花”的更改方面，Del Bonis 建议使用 OP_EVAL 和 PUSHSCRIPT 操作码来减少某些区域中 rollup 脚本的大小，从而减少使用的块空间量，从而降低 rollup 的使用成本，在所有其他条件相同的情况下。
Del Bonis rollup 设计是在比特币上构建 validity rollup 的一种方式，但不是唯一的方式。 例如，可以向比特币添加一个扩展块，其中包含自定义逻辑，该逻辑支持创建特定的或任意的 rollup 设计。 在他的文章中，Del Bonis 讨论了几种可以在比特币上构建 rollup 的替代方法，无论是对他更详细的设计进行微小的调整，还是使用完全不同的机制来确保rollup 中持有的资金的安全。[^98] 除了为所需的操作码添加直接支持外，可以使用 Jets 在 Simplicity 中实施对 validity rollup 原语的支持，例如。[^104] Anthony Towns 还建议使用 Chialisp 作为 Simplicity 的替代方案，用于类似的用例。[^105]
Elements 侧链项目（以及基于 Elements 的 Liquid 区块链）尚未支持支持 validity rollup 所需的 validity 证明，但它确实支持递归约定 。[^106][^107] 因此，在 Elements 中实施对 validity 证明的支持，以及 Del Bonis 确定的一些其他不错的更改，可能是测试最终旨在部署在比特币上的 validity rollup 协议的途径。
到目前为止的研究表明，通过一些更改，可以在比特币上构建 validity rollup 。 某些设计在技术上比其他设计更难以实现，但即使使用提出的更简单的实现，比特币用户也可以获得显着的扩展优势，并可能获得更多的隐私和其他理想的功能。
第 6 节。 validity rollup 的成本和风险 <sup id="section-6-the-costs-and-risks-of-validity-rollups"></sup>
虽然 validity rollup 可以为比特币带来的好处，包括提高交易吞吐量、更好的交易隐私以及更大灵活性的 BTC 承担方式，这些在纸上听起来都不错，但这些好处并非没有成本或风险。 除了与比特币软件更新以及特别是共识更改相关的常见成本（开发人员审查时间、用户测试时间等）和风险（链分裂、BTC 价格下跌等）之外，validity rollup 还有其独特的成本和风险需要考虑。
本节将检查在编写本报告时发现的成本和风险，但未来可能存在或出现此处未涵盖的其他成本和风险。 与比特币 validity rollup 相关的成本和风险的重要性很大程度上取决于实施细节。 在某些情况下，此处检查的风险是理论上的，而不是已知或已证实的风险。 理论风险在适用时会注明，包括在内是为了完整起见，并促使进一步研究其潜在危害。
第 6.1 增加带宽和存储成本 <sup id="section-61-increased-bandwidth-and-storage-costs"></sup>
如果 不 增加块空间以允许更多 rollup 交易，那么向比特币添加 validity rollup 不会导致 L1 完整节点的任何固有带宽或存储成本增加。 相同的可用块空间和带宽将更有效地用于以相同的带宽和存储成本打包更多交易。 然而，尽管今天理论上的最大块大小约为 4 MB，但实际上到目前为止记录中最大的带有“正常”交易的块约为 2.7 MB（块 #748918）。 Rollup 可以更有效地利用比特币块空间，如果对 rollup 块空间有足够的需求，可能会导致 L1 块定期达到理论上的最大大小 4 MB。 这将导致比当前平均块更大的块，从而增加 L1 完整节点的带宽和存储成本。
如果 增加 块空间以允许更多 rollup 交易，并且对 rollup 块空间的需求导致使用额外的空间， 那么这将进一步增加 L1 完整节点的带宽和存储成本。 在广播交易和区块时，需要在比特币网络中传递更多数据。 当包含 rollup 交易数据的区块被添加到区块链时，还需要在磁盘上存储更多数据。 这很容易衡量，具体取决于块空间限制增加了多少以为更多 rollup 交易腾出空间。 有关每个 rollup 交易的数据成本计算，请参见第 4.1 节。
第 6.2 管理完整节点验证成本 <sup id="section-62-managing-full-node-verification-costs"></sup>
无论是否增加块空间以允许更多 rollup 交易，validity rollup 都会对 L1 完整节点施加一项新成本：验证 rollup 状态更新的 validity 证明的成本。 在所有其他条件相同的情况下，此验证成本可能会因证明的复杂性和已实施的性能优化而差异很大。 在文献中很难找到现代证明的基准验证时间。 引用的证明验证时间范围从基于 PLONK 的两年期 SNARK 的 5 毫秒到两年期 STARK 的 2 毫秒。[^108][^109] 较新的证明实现可能在相同的硬件上验证速度更快，但总的来说，优化受益最多的是证明时间，而不是验证时间。
根据发布到 Bitcoin Wiki 的基准测试，比特币交易在四核 i7 CPU 上验证大约需要 0.125 毫秒，这比两年期 STARK 的 2 毫秒验证时间快约 16 倍。[^110] 因此，如果 16 个交易进入一个 validity rollup 状态更新，那么与单个 L1 比特币交易相比，rollup 将在验证成本上实现盈亏平衡。
如果在比特币上实施对 validity rollup 的支持，开发人员将不得不考虑一种对抗性的最坏情况，即攻击者将尽可能多的 validity 证明打包到一个区块中，以尝试最大化其验证成本。 这将使较弱的完整节点更难以验证该区块，并减慢其在网络中的传播速度。
假设 rollup 状态更新交易的基本成本（验证密钥 + 证明 + 脚本大小）为 2848 WU，正如 Del Bonis 所估计的那样，这相当于每个 4,000,000 WU 比特币区块最多 1404 个 rollup 状态更新交易。[^98] 以每个 rollup 状态更新 2 毫秒的验证时间计算，每个区块的总验证时间为 2.8 秒。 目前记录中验证时间最长的区块是区块 #364292，其中包含单个非 coinbase 交易，验证需要约 1 秒。[^111] 因此，验证一个包含该大小的 validity rollup 更新的区块的最坏情况比目前记录中验证速度最慢的比特币区块慢大约三倍。
如果有人要在比特币中实施对 validity rollup 的支持，他们可能还希望以某种方式限制每个区块中可以包含的 validity 证明的数量，以便他们可以限制最坏情况下的验证成本。 他们可以通过使用尺寸自然更大的证明（例如 STARK 或更大的 SNARK）或通过要求共识更重地“加权”证明（“证明溢价”，与 SegWit 的“见证折扣”相反）来实现此目的。 在每个区块允许的 rollup 状态更新数量与施加在 L1 完整节点上的额外验证成本之间存在一个平衡点。
第 6.3 矿工可提取价值 <sup id="section-63-miner-extractable-value"></sup>
比特币的推出前提是矿工在经济上是理性的、自私的利润最大化者，并且他们的利润最大化行为将导致一个运行良好的点对点电子现金系统的出现。 到目前为止，这种设计运行良好。 关于双重支付攻击的谣言（结果证明是一件小事）导致了迅速的经济报复，告诫矿工永远不要偏离故意为了自私的利益而重新组织区块链的规范。[^112] 即使仅仅是能够发起所谓的“51% 攻击”的可能性也导致矿工将其算力从主要的矿池中重新分配出去。[^113]
话虽如此，矿工在比特币规范内运营以最大化其利润是正常和期望的。 例如，仅将支付最高费用的交易放入他们的区块中，而不包括支付较低费用的交易，这是可以容忍甚至庆祝的。[^114][^115] 然而，在过去的几年中，我们看到了一种新的矿工行为出现，特别是在支持金融合约的区块链中，例如借贷和交易。 这种行为已被称为“非基于费用的矿工可提取价值”或简称“MEV”。[^116] MEV 包含越来越多的不同类型的价值，矿工可以通过对区块中的交易进行排序来获取这些价值，从而使他们获得唯一的利益（通常以其他区块链用户的利益为代价）。
一个例子是“三明治攻击”，这是一种抢先交易的形式，可以针对基于链上自动做市商的算法交易所的用户执行。 它的工作方式如下：一名观察 mempool 的矿工看到 Alice 在 AMMSwap 交易所下了一个针对资产 ABC 的“市价买入”订单。 矿工将在 AMMSwap 上下他们自己的等额的资产 ABC 市价买入订单，从而使矿工的平均成本基础为 X。 矿工构建他们的区块，以便他们的市价买入订单在该区块中紧接在 Alice 的市价买入订单之前。 结果，当 Alice 的市价买入订单执行时，她以 X+1 的成本基础接收到资产 ABC。 在同一区块中，矿工然后在区块中紧接在 Alice 的市价买入订单之后为资产 ABC 下一个等额的 AMMSwap 市价卖出订单，从而捕获 Alice 的买入订单提供给资产 ABC 的“+1”流动性。 最终结果：Alice 为资产 ABC 支付了比她本来要支付的更多的费用，并且矿工获得了 +1 的无风险利润。
MEV 正被应用于各种不同的场景中，包括套利、清算、削减惩罚、代币销售等等。 鉴于在支持高级金融合约的区块链上发生的所有 MEV，并且鉴于 validity rollup 能够使此类合约在构建于比特币上的 L2 rollup 中使用，对于比特币社区来说，在实施 validity rollup 支持之前可能要考虑的最相关的问题是：比特币上的 validity rollup 是否创造了在其他情况下原本不存在的 MEV 机会？ 如果是这样，创造的 MEV 机会是否会削弱比特币 L1 的安全性？
尽管可以使用嵌入式共识层（例如 CounterParty 和 Omni）甚至使用离散日志合约的原生比特币在比特币上构建金融智能合约，但这种类型的用法并没有像在以太坊、BSC、Solana 等其他区块链上那样流行。[ ^117] 如果在比特币协议中启用了对 validity rollup 的支持，则可能会解决阻碍比特币金融智能合约的开发和采用的任何缺陷，从而增加 MEV 在比特币上发生的可能性。
要回答比特币上的 validity rollup 是否创造了新的 MEV 机会这一问题，我们首先必须具体说明我们要在比特币上启用哪种 validity rollup。 可以通过限制比特币完整节点需要验证的 validity 证明中可以表示的信息量来限制可以在比特币上构建的 validity rollup 支持的脚本功能的表达性。 如果比特币社区愿意，他们可以将 validity rollup 限制为不超过（或不多于）今天的比特币的表达性。 这很可能 不会导致在 L2 上引入任何新的 MEV 机会。
比特币社区还可以决定支持在比特币上构建更具表现力的 validity rollup。 也许这些 rollup 具有足够的表达力，可以启用容易受到 MEV 攻击的合约类型。 在这种情况下，将在比特币上创建新的 MEV 机会。 这种 MEV 主要由 L2 上的 rollup 区块生产者捕获。 由于比特币较长的区块时间，L1 矿工尝试重新组织区块以便从 L2 捕获一些 MEV 的风险相对较高，因为挖掘区块的成本很高。 即使在区块时间相对较短的以太坊等区块链上，也没有关于矿工重新组织 L1 区块以捕获 L2 上的 MEV 的报告。 L2 rollup 过渡到分散的区块生产后，这种情况将如何变化或者是否会变化还有待观察。
在为本报告进行访谈时，几位开发人员和研究人员被问及此事，并且一致认为比特币 validity rollup 上的 MEV 可能会由于 MEV 机器人引起的交易量增加而导致 L1 交易费用增加，但 L1 用户不会受到 MEV 的影响。 熟悉此事的人指出，L2 rollup 对 L1 以太坊用户没有负面影响，这可以证明比特币 L1 用户也可能 不会受到构建在比特币上的 L2 rollup 的负面影响。 鉴于 L2 rollup 是以太坊上相对较新的现象，因此需要更多的时间和研究来更好地了解 L2 上的 MEV 与 L1 上的共识安全和激励措施之间的相互作用。
即使在 L2 上没有启用新的 MEV 形式，根据 validity rollup 在比特币上的实施方式，仍然可以在 L1 上启用新的 MEV 形式。 如果在比特币上使用递归约定 启用 validity rollup，则可以使用递归约定 在 L1 上构建新型的易受 MEV 攻击的协议。 例如，去中心化交易所协议 BitMatrix 是一种使用递归约定 构建的恒定乘积做市商协议。[^118] BitMatrix 最初是为 Liquid 区块链设计的，该区块链支持递归约定 并支持机密资产，因此使 BitMatrix 交易能够抵抗 MEV。 比特币不支持 L1 上的机密资产，如果在启用递归约定 的比特币 L1 上部署 BitMatrix 的一个版本，则会产生 MEV 的可能性。 用户应该明智地将此活动转移到可以在其中实施 MEV 防护的 L2 协议，但事实是他们将能够在 L1 上产生新的 MEV 机会，因此应予以考虑。
研究人员已经能够开发出许多解决方案来减少甚至防止 MEV 的负面影响。 其中一些解决方案是对共识的结构性更改，这些更改阻碍了区块生产者以对其有利的方式对交易进行排序的能力。[^119] 其他技术隐藏交易信息，以便区块生产者和“搜索者”无法看到容易受到 MEV 攻击的交易。[^120] 不想自己的午餐被 MEV 机器人吃掉的用户可以并且应该要求开发人员在其 rollup 和Based Rollup 的金融应用程序中实施这些 MEV 对策。 如果这些对策得到广泛实施，那么 MEV 作为一个普遍关注的问题可能会成为过去。
第 6.4 算法激励操纵合约 <sup id="section-64-algorithmic-incentive-manipulation-contracts"></sup>
通过启用“算法激励操纵”（AIM）攻击，在比特币上添加对 validity rollup 的支持可能会产生意想不到的负面影响，而 MEV 只是其中之一[^121]。 AIM 攻击使用智能合约来激励矿工互相攻击或攻击特定用户，从而破坏 Nakamoto 共识的正常激励机制。 本节将介绍一些可以使用足够有表现力的 validity rollup 在比特币上构建的 AIM 合约的示例。 这不是此类合约的详尽目录。 同样值得注意的是，即使无法直接在比特币上构建 AIM 合约，AIM 攻击也是可能的。[^122] 最重要的一点是，与在比特币和 validity rollup 等新层之上启用更具表现力的脚本功能相关的风险是已知和未知的（未知风险的可能性本身就是一种风险）。
TxWithhold 合约
AIM 智能合约的一个例子是“TxWithhold”合约。 在BitMEX Research 的一篇文章中，Gleb Naumenko 描述了如何使用约定 构建智能合约，该合约激励矿工扣留（即不确认）交易一定数量的区块。[^123] 如第 5 节所述，在比特币上构建 validity rollup 的一些设计需要 使用递归约定 。 即使启用的 rollup 在功能上相对有限，例如，不比今天的比特币更具有表现力的合约能力，通过在比特币 L1 上为这些类型的 validity rollup 启用递归约定 ，某些 TxWithhold 合约也可能是可能的。 这些类型的 TxWithhold 合约在实践中可能造成的危害程度是一个需要进一步研究的领域。
重组战争
如果比特币上的 validity rollup 支持足够有表现力的智能合约，它们可以被用来煽动“重组战争”，智能合约相互竞争以激励和不鼓励矿工重新组织区块链。[^124][^125] 这种类型的 AIM 攻击已证明可以使用以太坊 L1 上的“HistoryRevision 合约”来实现。[^126] 目前尚不清楚部署到 L2 的此类合约是否会对 L1 产生相同的影响，或者 是否 有可能，但 仅在 某些条件下 （例如，两个层上的区块生产者之间存在大量重叠）。 即使 L2 上的此类重组合约可能对 L1 产生相同的影响，如果它们既可以激励也可以阻止重组，那么它们也许会相互抵消，并且不会造成任何损害。 同样，这是一个需要进一步研究的领域。
大多数易受攻击的合约
一类智能合约，研究人员已经详细讨论了它们的积极用途，但它们潜在的危害可以说尚未得到充分探索，那就是“SPV 桥”（也称为“算力托管”）和类似的“乐观”智能合约类别。[^127][^128] SPV 桥和乐观合约在此统称为“大多数易受攻击的合约”，因为这些合约的用户信任大多数区块生产者（根据用于保护区块生产者集条目的任何 Sybil 防护资源来衡量，例如，算力、权益、身份等）不会窃取合约中持有的资金。
显而易见的风险是，大多数易受攻击的合约会启用 AIM 攻击，这可能导致用户被区块生产者抢劫。 也许更令人担忧的是一个更微妙的风险： 大多数易受攻击的合约的存在和使用会激励区块生产者勾结以实施盗窃，这使得大多数易受攻击的合约可能对区块链本身的安全性有害 。 通过创造一种勾结以形成“不诚实”多数的动机，否则就不会存在这种动机，因此可以认为大多数易受攻击的合约直接破坏了 Nakamoto 共识的诚实、正确、激励兼容的运作。
如果大多数易受攻击的合约使用与 L1 不同的区块生产者集，例如，在 validity rollup 中实施的算力托管合约使用不同的矿工集来保护算力托管，那么比特币 L2 上大多数易受攻击的合约的存在可能对 L1 比特币用户来说不是什么大问题。 但是，如果用于在比特币上添加对 validity rollup 支持的实施路径启用了 L1 上的新型大多数易受攻击的合约，那么比特币社区可能需要考虑是否值得通过大多数易受攻击的合约引入的潜在风险来获得此特定实施路径的好处。 例如，ZmnSCPxj 指出，可以使用递归约定 在比特币上构建算力托管合约。[^129] 因此，如果使用可递归约定 在比特币上实施对 validity rollup 的支持，那么比特币社区将需要考虑是否还希望启用 L1 算力托管合约。
经验观察表明，尽管存在大多数易受攻击的合约，但区块生产者尚未勾结进行盗窃，这表明存在一些其他的激励或抑制因素阻止他们进行盗窃。[^130] 也有可能只是尚未达到一个临界点，并且他们最终会发生勾结和盗窃只是时间问题。 凭借足够有表现力的智能合约功能，可以创建一个 AIM 合约，该合约自动将从大多数易受攻击的合约中盗窃 proceeds 分配给参与攻击的区块生产者，从而降低风险和协调成本，并有可能增加尝试和成功进行攻击的可能性。 由于大多数易受攻击的合约已部署到生产环境，因此只有时间才能证明它们是否真的对其主机网络构成威胁。
第 6.5 全自动极权主义 <sup id="section-65-fully-automated-totalitarianism"></sup>
在这里，我们再次参考第 5 节的 rollup 设计，这些设计需要 使用递归约定 。 递归约定 的定义性特征是，它不仅定义了锁定在约定 脚本中的 UTXO 可以被花费的条件，而且还定义了 UTXO 在花费后可以受到哪种类型的脚本的限制（因此得名“递归”约定 ）。 从理论上讲，递归约定 可以要求 UTXO 永远锁定到同类型的限制性脚本中，无论 UTXO 被花费多少次。
一些评论员引用了递归约定 启用的递归限制作为反对在比特币中实施约定 的理由。[^131][^132] 他们指出，独裁政府可以使用这种能力来强迫其管辖范围内的比特币用户将其 BTC 锁定到递归约定 中，在这种情况下，政府已经永久性地对其 BTC 的控制权进行了编程。 虽然这确实可以通过递归约定 在技术上实现，但这只是实施此类控制的一种方式。
目前，政府可以使用一种十多年来一直是比特币标准的智能合约来实现对其公民拥有的 BTC 如何转移的限制，而且递归约定 允许的方式更加灵活：多重签名。[^133] 基本思想是，政府将要求其公民拥有的 BTC 受到多重签名脚本的限制，该脚本需要来自政府控制的私钥和实际所有者的私钥的签名，才能将 BTC 转移到另一个地址。 在政府共同签署交易之前，控制政府私钥的计算机会检查以确保交易遵循在政府计算机上存储的普通文本文件中链下定义的转让策略。 如果交易符合此转让策略，则政府计算机会共同签署交易。 如果交易不符合转让策略（例如，试图将 BTC 转移到政府未批准的地址），则政府计算机会不共同签署交易，并且交易将被有效阻止。 如果政府想要更新其转让策略以添加或删除限制，那么只需更新定义该策略的链下文本文件即可。
在Blockstream AMP中可以找到一个工作示例，该示例展示了如何使用多重签名来实现转让限制，Blockstream AMP是由Blockstream公司开发的平台，用于支持在Liquid 区块链上资产的管理发行和转让。[^134] 尽管Liquid 区块链已经支持递归约定 ，但Blockstream仍然决定使用多重签名来实现转让限制。Blockstream 在其文档中解释说，在智能合约级别实现的转让限制“很难适应全球快速变化的法规”。[^135] 相比之下，“Blockstream AMP通过简单的多重签名授权设置来实现转让限制，为[用户]提供了适应不断变化的法规的灵活性”。[同上]
使用多重签名在链下实施支出限制将使政府能够在他们想要的时候更改限制，并使限制尽可能复杂。 如果政府使用递归约定 直接在智能合约中实施限制，那么他们的限制将受到比特币脚本的大小限制和功能的约束。 允许更改转让限制的可能性，以反映链下政府政策的不可避免的变化，将需要额外的脚本复杂性。 如果将对recursive covenants的支持添加到比特币，并且一个政府想要对其公民如何转让其BTC实施集权控制，那么由于链下转让政策提供的灵活性，他们更有可能使用多重签名而不是recursive covenants 来实施此类控制。
有些人可能会争辩说：是的，虽然多重签名可能更灵活，但递归约定 很可怕，因为它们可能会被用来将BTC永远锁定到脚本中；至少使用今天实现的多重签名，BTC理论上可以离开多重签名脚本。将BTC永远锁定到脚本中的可能性仍然不是一个新的风险。Anthony Towns指出，可以使用proof-of-burn来燃烧BTC，并在嵌入式共识协议（类似于XCP在比特币上的创建方式）或专用spacechain中铸造一定数量的govt-BTC。[^136] 一旦被烧毁，govt-BTC将永远无法转换回常规BTC，并且将永远锁定在政府的转让限制中，无论它们是如何实现的。
这里的主要观点是，与普遍观点相反，从实际的角度来看，当涉及到政府强制执行的转让限制时，递归约定 不会引入任何新的风险。 多重签名已经被用来启用这种转让限制，并且XCP风格的proof-of-burn可以被用来不可逆转地将BTC锁定到这种转让限制中。 可能有合理、充分的理由反对在比特币上启用递归约定 ；它们被用来实施政府强制执行的转让限制的能力并不是其中之一。
第 6.6 激怒独裁者 <sup id="section-66-provoking-authoritarians"></sup>
虽然比特币本身的存在是对那些试图控制其他人如何赚钱、储蓄和花费的独裁者的挑衅，但 validity rollup 可能会为比特币增加全新的挑衅维度。
私人支付
屏蔽交易将实现点对点交易，这些交易几乎与实物现金一样私密且无法追踪。 在某些情况下，由于在线远程、匿名互动的可能性，屏蔽交易可能比实物现金更私密且无法追踪。 这将使一个专制政权下的人民（在他们的政府或他们的家中）能够私下地赚钱和消费，使用小型计算设备上的隐藏钱包，这些设备不会引起怀疑，或者比实物现金更容易隐藏。
政府已经开始镇压为加密资产用户提供隐私保护的协议的使用。 日本和韩国政府已经有效地禁止交易几种已经实施隐私协议的特定加密资产，例如DASH、XMR和ZEC。[^137][^138] 最近，在莱特币社区实施了对选择加入 Mimblewimble 扩展区块协议的支持后，韩国监管机构迫使交易所将LTC下架。[^139] 奇怪的是，尽管比特币和以太坊都支持选择加入隐私协议，其特性与DASH（在比特币的coinjoin实现的情况下）和ZEC（在以太坊上的Aztec等屏蔽协议的情况下）相似，但BTC和ETH仍然可以在韩国进行交易。 尽管 BTC 和 ETH 已经逃脱了在这些司法管辖区的禁令，尽管它们支持与几种被禁加密资产几乎相同的隐私协议，但这种好运可能不会永远持续下去。 例如，如果比特币开发者要在比特币上构建具有强大隐私性的 validity rollup，这可能会增加这些以及其他对金融隐私怀有敌意的司法管辖区的政府审查。
另一种彻底禁止使用和交易隐私保护型加密资产的方法是继续允许它们的使用，但对交易所、区块生产者和其他可识别的瓶颈施加监管压力，以禁止与选择加入隐私协议的互动。 例如，当美国财政部将 Tornado Cash 智能合约地址添加到指定制裁个人和组织的特别指定国民名单时，它产生了一种令人不寒而栗的效果，促使人们主动过度合规。[^140] 据报道，交易所 FTX 开始阻止来自之前与 Tornado Cash 互动过的地址的存款，然后更进一步地标记与（未受制裁的）隐私协议 Aztec 相关的存款。[^141][^142] 以太坊矿池 Ethermine 甚至开始将 Tornado Cash 交易从其区块中排除。[^143]
法律倡导团体 Coin Center 发表了一份分析，质疑将 Tornado Cash 智能合约地址添加到 SDN 名单的合法性。[^144] 投资集团 Paradigm 发表了一份单独的分析，表明尽管存在制裁，但 Ethermine 和其他区块生产者没有法律依据在其区块中排除 Tornado Cash 交易。[^145] 即使这些分析是正确的，这也不意味着未来不会对区块链隐私协议发起其他更强烈的法律攻击，特别是在自由言论或法治保护少于美国的司法管辖区。 尽管对隐私协议用户的攻击可能仍然集中在应用层，但一些政府可能会将他们的斗争转移到区块生产者和共识层。 比特币旨在抵御此类攻击，但尽管如此，比特币开发者和社区成员将不得不决定，提示此类攻击的风险是否值得通过构建在比特币上的 validity rollup 添加强大、无需信任的隐私的优势。
为更自由的未来提供资金
抗审查智能合约提供对专制控制之外的金融的无需许可的访问，使企业家能够为其企业筹集资金，使活动家能够为其运动提供资金，并使受压迫的少数群体能够规避他们生活中专制者强加给他们的金融控制。 控制金融就是控制经济和人们生计的很大一部分。 为金融活动提供中立、可编程、全球可访问的基础设施，可以使受专制者控制的人们能够建立财富，并为自己和他们的社区资助一个更自由的未来。
真正的言论自由
去中心化域名系统为网站提供抗审查的难忘身份。 当与用于支付去中心化文件共享协议（如 Bittorrent 或 IPFS）上的文件主机的屏蔽 BTC 结合使用时，就可以创建几乎无法删除的网站。 在活动家和记者因其发布的信息而成为目标的社会中，这可能成为独裁者眼中真正的眼中钉。
成为（一个强大而私密的智能合约平台）还是不成为...
为人们提供对抗独裁者的新工具是一件好事。 风险在于这些强大的新工具会引起人们对比特币的更多负面关注。 就自由与专制主义而言，反专制比特币社区可能愿意说“放马过来”。 但是这些由 validity rollup 启用的强大的新工具也可以用于有害的目的。 正如私人支付可以被某人用来逃避其虐待家庭伴侣的窥探一样，私人支付也可以用来促成无法追踪的赎金支付。 正如抗审查的网站可以用来托管令人不舒服的政治真相一样，它也可以用来托管使无辜者受害的非自愿材料。 比特币社区已经必须处理这些类型的关注，但 validity rollup 可能会进一步放大它们。[^146][^147]
这是另一个问题，如果启用了vality rollup，比特币社区将不得不就是启用 哪种 rollup做出决定：比特币社区是否邀请潘多拉魔盒的全部内容在L2上发布，还是比特币用户 永远不应该被允许以无需信任的方式访问某些功能或智能合约？ 我以这种方式提出问题，强调“无需信任”，因为直接在比特币上（通过L1扩展或作为L2上的新协议）支持这些强大而有争议的用例的替代方案并不是这些用例永远不会发生，并且这些用例的所有风险和危害都将被消除。 替代方案是现状，在这种情况下，比特币用户必须将对其BTC的控制权移交给受信任的“桥梁”，以换取侧链或山寨币链上的IOU，在这些侧链或山寨币链上实际支持这些用例。[70] 在这个问题上，比特币社区面临的选择不是 risk 还是 no risk"，而是在 没有受信任的第三方/受信任的第三方更少的情况下承担风险 或 在有受信任的第三方/受信任的第三方更多的情况下承担风险"。
第 6.7 新颖的密码学 <sup id="section-67-novel-cryptography"></sup>
validity 证明中使用的密码学的新颖性或“林迪”因子取决于所指的 validity 证明的类型。[^148] 基于 STARK 的 validity 证明依赖于最古老的密码学原语，并且具有各种 validity 证明系统中 最弱的安全假设。 基于 SNARK 的 validity 证明依赖于较新的密码学原语，例如椭圆曲线（如比特币中）并且具有 更强的安全假设。[^149]
图 9. 密码证明族谱 - 年龄和密码学假设
> 图片来源：[^149]
另一个需要考虑的因素是给定有效性证明实现的年龄和“实战强化”。随着最老的生产环境实现已经有几年的历史（大约和集成到比特币核心中的 Schnorr 算法实现一样古老），有几种有效性证明系统可以被使用，或者至少可以从中获得灵感。[^150] 也就是说，在某些密码学证明协议的生产环境中已经发现了漏洞。[^151][^152] 每次在一个给定的密码学证明实现中发现这样的漏洞，该实现的“林迪时钟”就会重置为零。
虽然生产中加密货币使用的最古老有效性证明和 Schnorr 协议的实现现在年龄相仿，但有效性证明实现所基于的**协议设计**相对于 Schnorr 签名算法来说还比较新。这意味着有效性证明设计获得审查的时间较少。我们可以普遍预期，如果一个协议设计中存在漏洞，那么随着时间的推移，协议收到的审查次数增加，发现该漏洞的可能性也会增加。例如，在 2018 年对 Zcash 的 "Sprout" 密码学证明协议的细节进行审查，以便进行关于该协议的技术演讲时，Ariel Gabizon 发现了一个关键的设计缺陷，该缺陷将使攻击者能够无法检测地伪造受保护的币。[^153]
在生产密码学证明系统的设计和实现中发现的漏洞表明，当在比特币这样的区块链中部署这样的系统时，需要额外的谨慎、时间、审查和测试，因为在没有共识级别的软件更新的情况下，可能无法修复漏洞。密码学证明协议中的漏洞会使该协议保护的币面临风险，要么导致有效性证明在应该成功验证时验证失败（有效地冻结了受该证明协议保护的资产），要么导致有效性证明在应该验证失败时成功验证（使攻击者能够伪造和/或窃取受该证明协议保护的资产）。
<h3> 第 6.8 节 受损的 "有毒废料" <sup id="section-68-compromised-toxic-waste"></sup></h3>
一些密码学证明协议依赖于 "参数生成仪式"（也称为 "可信设置"）来实例化该协议. [^154] 仪式的目的是生成 "公共参数"，这些参数可用于验证协议用户产生的有效性证明。为了生成公共参数，必须使用随机数作为输入。如果用户知道用于生成公共参数的所有随机数，他们将能够生成看起来有效的伪造证明，即使该证明所验证的交易违反了协议的基本预期，例如，拥有所有随机数的用户可以 "凭空" 铸造币，而不是通过挖矿协议铸造币。由于这些随机数对于协议的完整性至关重要，并且是协议设置的必要副产品，必须始终小心地将它们相互分开，因此它们通常被称为 "有毒废料"。
基于 STARK 的证明协议本质上是 "透明的"，因此不需要参数生成仪式，因此不会产生有毒废料.[^155] 相比之下，大多数基于 SNARK 的证明协议，包括今天生产中基于 SNARK 的有效性 Rollup 使用的所有证明协议，都确实需要参数生成仪式。然而，在 2019 年，Sean Bowe 发现了如何在普通的椭圆曲线上进行零知识证明构造，令人兴奋的结果是，可以生成 zk-SNARK，而无需参数生成仪式。[^156] 同年晚些时候，Bowe 与合作者 Daira Hopwood 和 Jack Grigg 发表了一篇论文，描述了新的协议，他们将其命名为 "Halo" 。[^92] Halo 协议的发明开启了基于 SNARK 的有效性 Rollup 的可能性，而无需参数生成仪式，从而消除了有毒废料漏洞。
有关如何减轻受损的密码学证明和有毒废料的风险，以防止对 L1 比特币用户造成损害，请参见[附录 F](#appendix-f-mitigating-harm-from-compromised-cryptographic-proof-protocols-and-toxic-waste)。
<h2> 结论 <sup id="conclusion"></sup></h2>
[↩](#toc)
在本报告中，我们描述了有效性 Rollup 的历史、它们的工作原理以及如何在比特币上构建它们。我们描述了即使在最简单的形式下，有效性 Rollup 也可以在比特币上实现超过 100 倍的交易吞吐量，与在比特币 L1 上交易的所有权安全性相比，有效性 Rollup 用户的自托管所有权安全性没有任何损失。 然而，如此巨大的吞吐量提升并非没有代价。虽然有效性 Rollup 不一定会增加 L1 全节点的验证成本，但这取决于实现的细节，由于 Rollup 有效地利用了 L1 区块空间，Rollup 交易可能会比今天的比特币交易更容易、更频繁地将 L1 比特币区块填充到其最大容量，这可能会导致 L1 全节点区块链存储成本的增加。考虑到所有因素，鉴于有效性 Rollup 在设计上是 "无需信任的"，并且可以在不引入新风险或牺牲比特币的任何核心价值或功能的情况下实现，我们认为最简单的有效性 Rollup 实现将非常适合比特币。
可选地，在比特币上实现有效性 Rollup 还可以支持验证更强大的有效性证明。这将为比特币用户提供新的功能，例如支持更具表现力的智能合约和更强大的隐私协议。根据支持这些更强大的有效性证明的实现方式，可以在几乎不增加运行 L1 全节点的成本的情况下启用这些新功能。然而，这些新功能也可能带来新的风险，例如启用新型 AIM 和 MEV 攻击，以及可能引发专制政府对比特币的打压，因为这些政府可能反对这些协议启用的强大隐私和抗审查应用程序。 这些新功能中的每一个，以及随之而来的风险，都应在单独的基础上进行审查，每个都进行自己的成本-收益-风险-回报分析，以确定它们是否值得在比特币上启用，即使是在 L2 上的有效性 Rollup 中。本报告中介绍或引用了一些对此类问题的分析，但不应将其视为该主题的最终定论。这些是值得更多研究、实验和观察的领域。
<h2> 附录 A. 比较有效性 Rollup 与其他协议 <sup id="appendix-a-comparing-validity-rollups-to-other-protocols"></sup></h2>
[↩](#toc)
有效性 Rollup 是旨在提高基于区块链的数字资产和智能合约的可扩展性和功能的十年历史的协议的一部分。
我们可以在[表 5](#table-5-protocol-comparison-table)中看到，有效性 Rollup 如何通过链上数据可用性和有效性证明的独特组合进行设计，使其没有通道或面额限制，并且所有权安全性与其父链的安全性相同。另请参阅 Gudgeon 等人在 2019 年 4 月的论文 "SoK: Layer-Two Blockchain Protocols" 中进行的类似比较（没有 Rollup）。[^157]
<h4> 表 5. 协议比较表 <sup id="table-5-protocol-comparison-table"></sup></h4>
| 协议 | 子类别 | 桥接安全模型 | 数据可用性 | 通道/面额限制 | 单方面退出 | 父链矿工可以窃取* |
| ---------------------- | :---------------------------: | :---------------------: | :-------------------------------------: | :---------------: | :-------------: | :--------------------------: |
| CoinWitness | | 托管或联盟式 | 链下（自托管） | 否 | 是 | 是 |
| 状态通道 [a, b] | | 故障证明 | 链下（自托管） | 是（通道） | 是 | 是 |
| 状态链 [c] | | 半托管 | 链下 | 是（面额） | 是 | 否 |
| Plasma [d] | | 故障证明 | 链下（自托管） | 否 | 可能** | 是 |
| Rollup | | | | | | |
| | 有效性 Rollup [e] | 有效性证明 | 链上 | 否 | 是 | 否 |
| | 乐观 Rollup [f] | 故障证明 | 链上 | 否 | 是 | 是 |
| Validia 链*** | | | | | | |
| | Adamantium [h] | 有效性证明 | 链下（主要），链上（回退） | 否 | 是 | 否 |
| | Validium [g] | 有效性证明 | 链下 | 否 | 可能 | 否 |
| | 有效性 Valutia [i] | 有效性证明 | 链下（抵押数据托管人） | 否 | 可能 | 否 |
| | Volition [g] | 有效性证明 | 链上或链下（用户配置） | 否 | 可能 | 否 |
| 乐观 Valutia [j] | | 故障证明 | 链下（抵押数据托管人） | 否 | 可能 | 是 |
| Softchain [k] | | 工作量证明故障证明 | 链下 | 否 | 是 | 是 |
| 侧链 [l] | | | | | | |
| | 乐观侧链 [m] | 故障证明 | 链下 | 否 | 是 | 是 |
| | Drivechain [n] | 哈希率托管 | 链下 | 否 | 是 | 是 |
| | 抵押侧链 [o] | 抵押多重签名 | 链下 | 否 | 否 | 否 |
| | 联盟式侧链 [p] | 联盟式多重签名 | 链下 | 否 | 否 | 否 |
| | 中心化侧链 [q] | 托管 | 链下 | 否 | 否 | 否 |
| | Zendoo [r] | 有效性证明 | 链下，带有链上检查点 | 否 | 可能** | 否 |
> 表 5 注释：
> [ * ] "父链矿工可以窃取" 在这里指的是，如果有足够多的父链区块生产者，也就是 "矿工" 串通一气，那么他们可以在未经被盗用户合作的情况下（就像他们审查并勒索用户所需的那样）或者不需要重新组织父链区块（就像他们对用户进行双花攻击所需的那样）从该协议的用户那里窃取资金。另请参见 <a href="https://lightco.in/2021/06/21/miners-can-steal/" target="_blank">https://lightco.in/2021/06/21/miners-can-steal/</a>
>
> [ ** ] "可能" 在此列中指的是，只有在用户需要创建提款交易所需的数据可用时，单方面退出才有可能。
>
> [ *** ] 有关 validia 链的更多详细信息，请参见[附录 C](#appendix-c-increasing-throughput-with-offchain-data-availability)。
> 表 5 参考：
> [a] <a href="https://lightning.network/lightning-network-paper.pdf" target="_blank">https://lightning.network/lightning-network-paper.pdf</a>
>
> [b] <a href="https://l4.ventures/papers/statechannels.pdf" target="_blank">https://l4.ventures/papers/statechannels.pdf</a>
>
> [c] <a href="https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39" target="_blank">https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39</a>
>
> [d] <a href="https://plasma.io/plasma.pdf" target="_blank">https://plasma.io/plasma.pdf</a> 注意：<a href="https://medium.com/onther-tech/plasma-world-map-ba8810276bf2" target="_blank">Plasma 有很多变种</a>，但它们都具有上表中所述的基本特性。
>
> [e] <a href="https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477" target="_blank">https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477</a>
>
> [f] <a href="https://ethresear.ch/t/minimal-viable-merged-consensus/5617" target="_blank">https://ethresear.ch/t/minimal-viable-merged-consensus/5617</a>
>
> [g] <a href="https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb" target="_blank">https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb</a>
>
> [h] <a href="https://ethresear.ch/t/adamantium-power-users/9600" target="_blank">https://ethresear.ch/t/adamantium-power-users/9600</a>
>
> [i] <a href="https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf" target="_blank">https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf</a>
>
> [j] <a href="https://blog.celestia.org/celestiums/" target="_blank">https://blog.celestia.org/celestiums/</a>
>
> [k] <a href="https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1" target="_blank">https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</a>
>
> [l] <a href="https://blockstream.com/sidechains.pdf" target="_blank">https://blockstream.com/sidechains.pdf</a>
>
> [m] <a href="https://near.org/blog/eth-near-rainbow-bridge/" target="_blank">https://near.org/blog/eth-near-rainbow-bridge/</a>
>
> [n] <a href="https://www.truthcoin.info/blog/drivechain/" target="_blank">https://www.truthcoin.info/blog/drivechain/</a>
>
> [o] <a href="https://github.com/nomic-io/bitcoin-peg/blob/master/bitcoinPeg.md" target="_blank">https://github.com/nomic-io/bitcoin-peg/blob/master/bitcoinPeg.md</a>
>
> [p] <a href="https://www.rsk.co/Whitepapers/RSK-White-Paper-Updated.pdf" target="_blank">https://www.rsk.co/Whitepapers/RSK-White-Paper-Updated.pdf</a>
>
> [q] <a href="https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf" target="_blank">https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf</a>
>
> [r] <a href="https://arxiv.org/abs/2002.01847" target="_blank">https://arxiv.org/abs/2002.01847</a>
<h2> 附录 B. 比较替代加密货币隐私技术 <sup id="appendix-b-comparing-alternative-cryptocurrency-privacy-techniques"></sup></h2>
[↩](#toc)
由于比特币的许多当前限制（例如，有限的脚本功能）和特性（例如，透明的交易金额），减少比特币交易的可追溯性并提高隐私性的努力总是一场艰苦的战斗。为此构建的比特币协议示例包括 Cahoots、CoinJoin、CoinSwap、PayJoin、TumbleBit、隐形地址及其变体或衍生产品。
比特币最大的隐私弱点也许也是比特币最大的优势之一：交易金额的透明性，即比特币的公开可审计性。由于比特币交易金额是透明的，并且在区块链上公开可见，因此它们可用于关联发送者和接收者，并将接收者地址与更改地址和自我发送区分开来。[^158][^159] 比特币隐私协议试图通过将币与一个或多个其他用户混合，并通过创建等额输出来对抗这些启发式方法，以增加每笔交易的匿名集。但是，如果混合中的任何参与者做了任何去匿名化自己的事情，他们就会从匿名集中删除（有时甚至其他混合参与者都不知道）。最终，匿名集可以缩小到不大于单输出交易。[^160] 匿名集这种逐渐降级的特性使比特币隐私本质上是脆弱的，需要持续的成本（以挖矿费用形式产生）才能通过重新混合或其他 "混合后" 隐私技术来维持匿名集的大小。
维持匿名集大小的成本，加上等待足够数量的用户混合等额输出来获得足够大的匿名集的要求，可能会使比特币隐私技术不适用于销售点交易或低价值交易。有理由希望链下协议（如 Lightning）可以提供改进：由于 Lightning 交易是链下的，因此交易的详细信息仅为支付通道路径上的每个节点所知，并且在某些情况下，只有部分交易详细信息为位于该路径上的每个节点所知。原子多路径路由可以为 Lightning 支付添加更多模糊性，因为路由节点将不知道它们是路由全部支付还是仅路由部分支付。然而，这里启用的隐私充其量只是概率性的，并且对于发送者和接收者来说都难以量化：可能存在这样一种情况，即他们在路径上的交易对手对他们的支付知之甚少或一无所知。更不用说与余额探测和通道打开/关闭交易相关的隐私问题了。[^161] 就目前的形式而言，Lightning 最好被认为是一种快速和高吞吐量的支付解决方案，而不是隐私解决方案。（这将来可能会改变！）[^76]
研究人员已经研究了比特币隐私协议的缺点，并发明了他们认为可以显着改进以保护用户隐私的新协议。在这里，我们考察了三个最着名的替代隐私协议，并比较了每个协议揭示的有关其用户的数据量，从而为比较它们的相对隐私改进提供了基础。
#### Grin
Grin 是 Mimblewimble 协议的第二个独立实现。虽然 Mimblewimble 确实具有一些可以被认为是隐私改进的功能，例如隐藏交易金额的机密交易，以及可以从公共交易图中删除一些交易的非交互式交易截断，但在其最简单的形式中，Mimblewimble 交易仍然会揭示构建公共交易图所需的所有信息。通过监视通过点对点网络发送的交易，观察者可以跟踪输入和输出，以构建关于币来自何处以及去向何处的图。由于这些原因，Mimblewimble 作为一种扩展解决方案最有效，而不是隐私解决方案。
##### 图 10. 以其最简单的形式显示的 Grin 交易
> 图片来源：[^162]
引用 Grin 文档中的话：
> ...[I]可以监视点对点网络活动，并在交易包含在区块中并与其他交易聚合之前获取交易。通过设置连接到许多对等方的嗅探节点，你可以确定哪些输出正在被什么交易花费，从而让你可以通过分离在区块级别完成的聚合来构建部分交易图... 截至今天，可以构建几乎完整的交易图。[^162]
目前正在进行一些工作，通过将该协议与其他隐私技术相结合来提高基于 Mimblewimble 的加密货币的隐私性。例如，请参见 Chaidos 和 Gelfer 的 Lelantus-MW 协议。[^163]
#### Monero
Monero 作为 Bytecoin 的一个分支启动，Bytecoin 是 CryptoNote 协议的第一个实现。CryptoNote 协议的定义性隐私功能是一次性环签名和隐形地址。[^164] 环签名使发送者可以使用来自其他交易的输出来作为 "诱饵输入"，以模糊其交易的真实输入或来源，实际上是与其他协议用户进行非交互式 coinjoin。隐形地址使接收者可以共享一个静态公钥地址，然后发送者使用该地址来派生一次性私钥地址，这样出现在区块链上的接收者地址就无法链接到接收者最初共享的公钥隐形地址。
Monero 自此通过实施 RingCT 改进了原始 CryptoNote 协议，RingCT 是一种将环签名和机密交易相结合以隐藏交易金额的协议。[^165] RingCT 的添加意味着输入不再需要选择等额诱饵，这使得每个环签名的匿名集可以像用户愿意支付的那样大（或者像协议允许的那么大；截至 Monero 0.13.0，所有环的大小必须为 11，以确保统一）。[^166]
尽管与比特币相比，Monero 在隐私性方面有显着改进，但 RingCT 和隐形地址创建的交易网络并不像区块链上的大量元数据最初显示的那样坚不可摧。存在基于常见使用模式的攻击，例如监督者攻击、闪光灯攻击和受污染灰尘攻击，这些攻击可用于取消匿名化交易的发送者或接收者。[^73] 与基于比特币的隐私协议一样，基于诱饵的协议（如 Monero 中实现的协议）在实践中已被证明是脆弱的（尽管由于多层密码隐藏和混淆，可以说比比特币更宽容 "错误"）。
##### 图 11. 在 explorermonero.com 浏览器中 Monero 交易的样子
> 图片来源：[^167]
#### Zcash
Zcash 是 Zerocash 协议的第一个实现。Zerocash 协议的定义性隐私功能是使用 zk-SNARK 来加密特殊制作的 "受保护" 交易的金额、发送者和接收者，从而完全隐藏这些细节，使其不被公开。发送者不是在区块链中引用特定的公共帐户或透明的未花费交易输出，而是创建一个零知识证明，以说服网络全节点发送者拥有并且因此可以花费一定数量的 "笔记"（相当于加密的未花费交易输出），并且加密输入的金额等于加密输出加上透明挖矿费的总和。[^168]
##### 图 12. 在 zcha.in 浏览器中 Zcash 受保护交易的样子
> 图片来源：[^169]
虽然 Zerocash 交易隐藏了所有当前已知技术中最多类型的交易信息，但仍然存在一些链上元数据泄露，这些泄露可能用于取消匿名化交易。例如，Zerocash 交易会公开显示交易中使用的输入和输出数量。实际上，这已被证明足以取消匿名化 Zerocash 交易的发送者。[^170] 虽然此演示是人为设计的，并且有一种方法可以在将笔记发送到最终目的地之前将它们合并在一起以缓解此攻击，并且随着具有类似输入和输出笔记金额的更多交易隐藏在交易中，去匿名化的风险会降低，但模拟攻击表明 Zerocash 确实泄露的少量元数据可用于取消匿名化用户。因此，Zerocash 的用户（或用户的钱包）在交易受保护的币时需要保持身份不明时，必须采取针对存在的链上（和链下）元数据泄漏的对策。
#### 关于 "选择退出" 与 "选择加入" 隐私的说明
有些人可能会争辩说，在有效性 Rollup 中实施的加密协议的 "选择加入" 性质使得对于使用它的人来说隐私效果较差，并且在 Beam 或 Monero 等区块链上的 "选择退出" 加密协议（其中加密 "默认开启"，用户必须显式 "选择退出" 才能删除加密）将始终提供卓越的隐私，其他所有条件相同。这是一种误解。实际上，根本没有纯粹的 "选择退出" 加密，因为**所有**协议，无论是否加密，最初都是 "选择加入" 的，除非受到外部胁迫。人们通过选择下载 Monero 钱包并购买、接收或挖掘 XMR 来 "选择加入" 使用 Monero 加密其交易，就像人们通过下载兼容的比特币钱包并将他们的透明 BTC 存入加密的有效性 Rollup 或购买或接收加密的 BTC 来 "选择加入" 使用比特币上的加密有效性 Rollup 一样。同样，加密的 BTC 用户可以选择永不接触透明的 BTC，就像 Monero 用户可以选择永不接触透明的 BTC 一样。在这两种情况下，人们首先 "选择加入" 加密协议，然后他们可以选择是否想要 "选择退出"。在这些情况下，对最终用户的唯一有意义的区别是所涉及的记账单位。
<h2> 附录 C. 通过链下数据可用性提高吞吐量 <sup id="appendix-c-increasing-throughput-with-offchain-data-availability"></sup></h2>
[↩](#toc)
有效性 Rollup 旨在提高交易吞吐量，并可能提供替代执行环境，而不会放弃相对于直接在其 Rollup 的父链上持有资金和交易的安全性。正如[第 1 节](#section-1-an-introduction-to-validity-rollups)解释的那样，这种高度的安全性是通过将有效性证明的使用与 Rollup 交易数据存储在其父链区块内相结合来实现的。有效性证明提供与父链接受的任何其他有效数字签名相同的安全所有权保证，链上数据存储提供与存储在其父链中的每个其他交易相同的数据可用性保证。
直接将其 Rollup 的交易数据存储在其父链的区块中成本很高。 如果父链是比特币主链，则该成本最直接地以每个占用主链区块空间的交易收取的 sat/vbyte 市场费用率来衡量。即使 Rollup 交易数据占用的空间可以享受费用率折扣，一种可能的实现细节，因为这些交易仅由主链全节点存储而不是执行，这可能是合理的，但如果主链区块空间的市场费用率相对较高，那么使用 Rollup 的每笔交易成本也可能相对较高。此外，区块大小的限制本质上限制了构建在比特币上的有效性 Rollup 的交易吞吐量。
这就是_validia 链_的概念的用武之地。validia 链是一种区块链，就像有效性 Rollup 一样，它通过使用按顺序由父链全节点验证的有效性证明来推进其状态，从而从父链继承双重支出安全性。与有效性 Rollup 不同，validia 链不完全使用父链进行数据可用性，而是使用一种或多种链下数据可用性解决方案。此处的权衡是，吞吐量可能会超过比特币的区块大小限制，并且由于使用了更便宜的数据可用性解决方案，可能会降低每笔交易的成本，但代价是可能降低数据可用性保证的确定性和安全性。比特币可以通过实现足够灵活的 Rollup 脚本来支持各种链下数据可用性解决方案，从而在添加对有效性 Rollup 的支持的同时添加对这些 validia 协议的支持。这将让用户选择高度安全但昂贵的链上数据可用性，或安全性较低但成本较低的链下数据可用性。
到目前为止发明的 validia 链变体有：
- Validium：链下无抵押数据可用性
- 有效性 Valutia：链下抵押数据可用性
- Volition：每个交易都可以在链下或链上数据可用性之间进行选择
- Adamantium：在托管或自托管链下数据可用性之间进行选择，带有链上回退
（“Validia 链” 和 “valutia” —— 发音为 “vuh-loo-sha” —— 是为本报告开发的新命名法，用于对先前未命名的区块链类别进行分类。由于此处提到的其他类别都有很酷的名称，因此似乎有必要在需要时分配一些新的酷名称。）
由于数据可用性不再由父链提供，因此 validia 链不被认为是 Rollup。但是，与替代方案相比，validia 链仍然提供许多好处：
- 没有通道限制（与状态通道不同）
- 没有面额限制（与状态链不同）
- 双重支出安全性从父链继承（与侧链不同）
- 第三方可以冻结用户资产，但不能以零成本任意窃取它们（与 Plasma 链、状态链或无抵押侧链不同）
（有关更详细的比较，请参见[表 5](#table-5-protocol-comparison-table)。）
为了扩展每个选项：
#### Validium
Validium 是一种 validia 链，其中数据可用性由一个或多个无抵押的第三方数据托管人提供。 为了使 validium 的状态前进，数据托管人（如果是数据托管人联盟，则是 m-of-n 托管人）必须签署新的状态根，证明他们拥有数据的副本。如果 validium 由于某种原因停止生成区块，用户可以查询数据托管人以接收他们需要生成有效性证明并单方面退出 validium 并将其资产提回到父链的数据副本。只要至少有一个数据托管人拥有必要的数据，单方面退出仍然是可能的。如果 validium 状态数据的完整副本不可用，那么 validium 所有用户的资产将被冻结，直到数据再次可用。
部署的第一个主网 Validium 是 DeversiFi，一个构建在以太坊上的非托管交易所。[^171]
#### 有效性 Valutia
有效性 valutia 是一种 validia 链，它依赖于_抵押价值风险_来激励数据托管人保持数据可用性。用户将锁定一些资产作为抵押品在一个智能合约中，以换取承担数据托管人角色的权利。然后，父链会验证来自数据托管人的数据可用性证明，并在每次新的 valutia 状态更新时进行验证，就像对 validium 进行验证一样。
如果在任何时候应该可用的数据变得不可用，那么数据托管人的抵押品将被冻结，直到数据再次可用。冻结抵押品的威胁旨在保持数据托管人诚实，并激励他们确保在需要时用户单方面退出所需的数据 vata 可用。
由于数据可用性在链下提供，因此预计存储 valutia 数据将比直接在父链上存储它便宜，就像使用 Rollup 一样。与此同时，抵押的价值风险应提供比 validium 的无抵押数据托管人更强的数据可用性保证。这为用户在成本和安全性的权衡空间中提供了更多选择。
在 2021 年 4 月的一篇博客文章中，Matter Labs 提出了第一个有效性 valutia，zkPorter。[^172] Matter Labs 提出的设计使用以太坊作为结算层，使用 zkSync 代币质押者网络进行数据可用性。在 2022 年 2 月的一篇博客文章中，Celestia Labs 提出了一个类似的 valutia 设计，称为 Celestium，它可以与有效性证明或故障证明保护的桥梁一起使用。[^173] Celestia Labs 提出 Celestium 将使用以太坊作为结算层，使用一个名为 Celestia 的单独区块链专门用于数据可用性。
在 Celestia 所基于的 2019 年 5 月的 "LazyLedger：具有客户端智能合约的分布式数据可用性账本" 论文中，Al-Bassam 建议使用 "数据可用性采样"，以便依赖 LazyLedger 进行数据可用性的 valutia 链节点不必下载整个 LazyLedger 区块链来确认数据是否可用。[^174] 这种数据可用性采样技术基于 Al-Bassam 等人在 2018 年 9 月的论文 "欺诈证明：最大限度地提高轻客户端安全性并通过不诚实的大多数人扩展区块链" 中较早的工作。[^175] Joachim Neu 在 2022 年 8 月发表的最新研究表明，数据可用性采样并不是万能药，关于这种技术在大规模上的有效性仍然存在一些悬而未决的问题。[^176]
#### Volition
Volition 允许用户在每个交易的基础上选择是将数据存储在链上（“rollup 模式”）还是链下（“validium/valutia 模式”）。如果用户选择 rollup 模式，那么他们单方面退出 Volition 所需的数据会像有效性 rollup 一样存储在父链区块中。如果用户选择 validium/valutia 模式，那么数据将使用 Volition 配置的任何链下数据可用性解决方案进行存储。
Volition 提供的每个交易的可选性意味着用户可以根据给定的应用程序调整其交易的安全性和成本。对于低风险应用程序，例如娱乐游戏或低价值支付，可以使用 validium/valutia 模式。对于高风险应用程序，例如稀有艺术品收藏或高价值交易，可以使用 rollup 模式。为了降低决策成本，应用程序可以根据交易的价值或上下文建议使用哪种模式，甚至可以根据用户可配置的设置自动为用户做出该决定。
Volition 最早由 StarkWare 在其 2020 年 6 月的帖子 “Volition and the Emerging Data Availability Spectrum” 中描述。[171] zkPorter 是第一个提出的 Volition 实现。[172]
#### Adamantium
Adamantium 是一种 validia，用户可以选择 validium/valutia 模式、自托管数据可用性或指定第三方数据可用性，并回退到父链的保护性提款。默认情况下，Adamantium 作为 validium/valutia 运行。但是，如果用户不想依赖 validium/valutia 的默认链下数据可用性解决方案，则可以选择成为超级用户 (Power User)。
如果用户选择成为超级用户，他们必须像 validium/valutia 定义的每个数据保管人一样签署每个新的状态根，从而证明用户拥有新状态的副本，这是能够单方面退出 Adamantium 所需的。可以选择地，用户可以指定一个或多个第三方代表他们成为超级用户，在这种情况下，用户指定的至少一个超级用户必须保留数据可用性并代表用户签署新的状态根。
如果超级用户没有及时签署新的状态根，那么他们的资金和/或他们未能代表签署的任何用户的资金将自动提取到父链。这可以保护受影响的用户免受新状态不可用的影响，确保他们可以访问自己的资金。
Adamantium 模型并非没有风险：尽管超级用户必须证明他们拥有启用单方面退出所需的必要数据，但他们可能实际上在证明时没有该数据，或者他们后来由于某种原因失去了对该数据的访问权限。用户必须权衡计算状态和保护此数据的备份（或付费让其他人为他们执行此操作，并承担此外包的风险）的成本，与使用具有内置强大数据可用性保证的有效性 rollup 的成本。
Adamantium 模型最早由 Starkware 在其 2020 年 6 月的帖子 “Volition and the Emerging Data Availability Spectrum” 中以“Trustless Off-Chain Data Availability”或简称 “TODA” 的名称描述。[171] 后来，Avihu Levy 在 2021 年 5 月的 Ethereum 研究论坛中将其命名为“Adamantium”并进行了深入描述。[177]
#### 数据可用性安全谱系
##### 表 6. 有效性桥的分类
| 桥类别 | 数据可用性模型 |
| ------------------------- |:----------------------------------------------------------------------------------------------------------:|
| 有效性 Rollup | 链上数据 |
| Adamantium | 链下数据（抵押、非抵押或自托管），回退到父链提款 |
| 有效性侧链 | 链下数据，带链上检查点 |
| 抵押的 Volition | 链上或链下数据（抵押） |
| 有效性 Valutia | 链下数据（抵押） |
| 非抵押的 Volition | 链上或链下数据（非抵押） |
| Validium | 链下数据（非抵押） |
> 表 6 描述：基于使用的数据可用性解决方案对有效性桥进行分类。按安全性从高到低排序，这是作者的拙见。灵感来自 Brand 等人 [^171] 中的表格。链上结算 + 链上数据可用性是一种有效性 rollup，可提供最强的安全保证。链上结算 + 链下数据可用性为数据可用性开辟了多样化的选择范围，最终用户可以考虑不同程度的成本和安全性。有关有效性侧链的更多信息，请参见 [附录 D](#appendix-d-a-closer-look-at-validity-sidechains)。
<h2> 附录 D. 仔细研究有效性侧链 <sup id="appendix-d-a-closer-look-at-validity-sidechains"></sup></h2>
[↩](#toc)
在 Back 等人于 2014 年 10 月发表的论文 “Enabling Blockchain Innovations with Pegged Sidechains” 中，作者将锚定侧链定义为：
> 一种侧链，其资产可以从其他链导入并返回到其他链；也就是说，一种支持双向锚定资产的侧链。[178]
在同一篇论文中，Back 等人还为锚定侧链提出了以下所有权安全要求：
> 1. 在侧链之间转移的资产应该能够由其当前持有者转移回来，而不是其他任何人（包括以前的持有者）。
> 2. 资产应该在没有交易对手风险的情况下转移；也就是说，不应该有不诚实的一方阻止转账发生的可能性。[同上]
在锚定侧链论文的第 3 节中，Back 等人继续详细说明了使用 SPV 证明来促进父链和锚定侧链之间代币转账的侧链的设计。[同上] SPV 证明设计的问题在于它实际上不满足为锚定侧链定义的两个所有权安全要求。要求 (1) 被违反，因为大多数父链哈希算力管理者（矿工或矿池运营商）能够伪造 SPV 证明，将其不是“当前持有者”的代币（根据当前的侧链状态）从侧链脚本中转移到他们选择的一个或多个父链地址中。这就是本报告的 [表 5](#table-5-protocol-comparison-table) 中提到的“父链矿工可以窃取”问题，在本报告的 [第 6.4 节](#majority-vulnerable-contracts) 中对此进行了描述，并且还在锚定侧链白皮书的第 4.2 节中进行了描述。[178] 要求 (2) 被违反，因为“不诚实”的哈希算力多数可以审查合法的提款交易，以阻止用户将其代币从侧链转移回父链地址。
有效性 Rollup 满足要求 (1)，但不满足要求 (2)，原因与 SPV 证明设计不满足要求 (2) 的原因相同。比特币的一个基本特征是，51% 攻击者能够在他们获得哈希算力多数的时刻 _完全_ 控制区块链的内容，因此他们可以阻止交易被确认，直到“诚实”的多数重新获得控制权是一个既定的事实。因此，实际上要求 (2) 是不可能满足的，只要比特币依靠 Nakamoto 共识来保证安全并且交易扣留不受惩罚。
另一种满足要求 (1) 的协议是有效性侧链。这是锚定侧链白皮书第 6.1 节中描述的锚定侧链的一种变体：
> 学术密码学领域最近的一项令人兴奋的进展是 SNARK 的发明。SNARK 是一种节省空间、可快速验证的零知识加密证明，证明已完成某些计算……然后可以构建区块，证明它们对未花费输出集的更改，但实际上以零知识的方式在交易中进行。他们甚至可以承诺完全验证所有先前的区块，从而允许新用户仅通过验证单个最新区块来加快速度。这些证明还可以通过证明发送链根据先前定义的某些规则有效来代替用于将代币从另一个链转移的 DMMS。[同上]
有效性侧链协议的第一个生产实现是 Zendoo，它于 2021 年 12 月在 Horizen 主网上激活。[179] Zendoo 协议的工作原理是要求在父链上注册侧链，然后在每个侧链“epoch”结束时将“提款证书”作为检查点提交到父链上。每个 epoch 都包含自上一个 epoch 结束以来添加到链顶部的侧链区块的数量，以及与侧链之间的正向和反向传输请求。提款证书包含有关侧链的数据，例如侧链 ID、epoch ID、证书的质量（表明它代表规范链的状态）、侧链当前状态的哈希值、最后一个侧链区块的哈希值、定义所有已修改（消耗和创建）的 UTXO 的位向量以及有效性证明，该证明证明提款证书根据侧链规则和在父链上实施的 Zendoo 协议均有效。
如果大多数侧链区块生产者继续为 epoch 生产区块，但他们不与其他人共享这些区块的数据，并且他们在 epoch 结束时确认了此 epoch 的提款证书，则可能会出现问题。这可能会产生数据可用性问题。如果侧链遇到此数据扣留故障，则在不可用区块中确认了交易并且 _没有_ 交易数据的任何用户都将失去对其所涉及的 UTXO 的访问权限，直到数据可用为止。但是，使用在父链上确认的提款证书中的信息，所有 _有_ 交易副本的用户，其中他们在当前 UTXO 集中收到 UTXO（甚至只是通过 p2p 网络广播的原始交易的副本），将有足够的数据来生成证明，表明他们拥有截至上次确认的侧链状态的 UTXO。然后可以使用有效性证明来单方面退出侧链返回到父链。
Zendoo 协议在数据可用性和可扩展性之间接受细微的权衡。回想一下，在父链区块中确认的每个状态更新中，有效性 Rollup 会存储用户生成自己的有效性证明并单方面退出返回到父链所需的所有交易数据。因此，比特币上的有效性 Rollup 最多可以在比特币 400 万 WU 区块大小限制内确认约 250,000 个交易（请参阅 [表 2](#table-2-comparing-how-many-transactions-can-fit-per-bitcoin-mainchain-block-based-on-a-given-transaction-type) 中的详细信息）。相比之下，Zendoo 在父链区块中存储侧链当前状态的高度压缩表示。侧链状态的这种压缩表示使一些用户面临数据不可用的风险，并限制了侧链上可能存在的 UTXO 数量。这使 Zendoo 在所有权安全强度和可扩展性潜力方面介于有效性 Rollup 和 validia 链之间。
Zendoo 的当前实现每个提款证书的固定成本约为 152 千字节 (KB)，假设有效性证明的大小约为 45 KB，位向量的大小约为 106 KB（尽管这会根据位向量的参数而变化），以及 1 KB 用于包含在证书中的其他各种侧链信息。106 KB 位向量的参数化设置为最多存储 4,000,000 个侧链 UTXO 和每个 epoch 100,000 个 UTXO 更新。这意味着可能会在 Zendoo 侧链上发生 100,000 个交易，并且只要侧链 UTXO 集永远不超过 400 万个 UTXO，则在父链区块空间方面的成本将为每个 epoch 152 KB。
##### 表 7. 使用比特币作为父链，比较 UTXO 模型有效性 Rollup 和有效性侧链的交易吞吐量
| 交易类型 | 1,000,000 WU | 3,000,0000 WU | 总计（tx/区块） |
| ---------------------------- |:-------------------------------------:|:-----------------------------------:|:----------------:|
| Rollup 1 输入 2 输出 UTXO | 有效性证明、脚本、其他交易数据 | 26,432 个交易（113.5 WU/tx） | 26,432 |
| Zendoo 1 输入 2 输出 UTXO | 有效性证明、脚本、其他交易数据 | 100,000 个交易（106,000 WU/位向量） | 2,500,000 |
> 表 7 描述：区块被分成 1,000,000 WU 和 3,000,000 WU 两部分，以说明在 Rollup 交易的情况下，一些权重限制用于有效性证明和脚本数据，而其余部分可以用于 Rollup 交易数据。在 Zendoo 状态更新的情况下，有效性证明和脚本数据也有固定成本。Zendoo 状态更新目前每个提款证书最多约为 100,000 个交易，每个提款证书的成本约为 152,000 WU（假设类似于 [第 4.1 节](#section-41-increasing-throughput-with-validity-rollups) 中描述的有效性 Rollup 数据，见证折扣应用于所有 Zendoo 数据）。假设每个状态更新脚本的额外成本约为 2000 WU，这意味着每个比特币 L1 区块可以容纳大约二十五个 154,000 WU Zendoo 状态更新，每个 L1 区块最多可以容纳 2,500,000 个交易。
<h2> 附录 E. 使用有效性证明启用额外的吞吐量增加 <sup id="appendix-e-enabling-additional-throughput-increases-with-validity-proofs"></sup></h2>
[↩](#toc)
除了有效性 Rollup 能够实现的之外，有效性证明还可以用于帮助比特币进一步扩展。使用递归证明，可以使用单个聚合证明来证明高达给定区块高度的区块链的有效性。[180] 这意味着可以增加区块大小限制，而不会使完整节点验证区块链变得更加困难。区块大小限制无法增加 _太多_，并且开发人员仍然需要确保区块传播时间保持合理，但即使增加 50-100% 也可能意味着每个区块最多可以增加 125,000-250,000 个 Rollup 交易。
今天，有几个因素阻碍了比特币区块大小限制的增加。其中之一是允许区块变得越大，验证所需的时间就越长。[181] 唯一格式化的区块可能很容易被强大的计算机验证，但对于较弱的机器来说更难验证。这使功能更强大的计算机在挖矿方面具有优势，因为它们可以挖掘这些唯一格式化的区块之一，将其广播到网络，并在功能较弱的矿工完成验证区块之前开始处理下一个区块。与此相关的是初始区块下载 (IBD) 所需的时间。随着更大的区块添加到链顶端，完整节点需要更长的时间才能同步到链顶端，然后才能跟上新区块被挖掘时的链顶端。
阻碍区块大小限制增加的另一个因素是由于网络带宽限制而导致的区块传播时间。相对于网络上对等方可用的带宽速度而言，较大的区块由于其较大的大小而在网络中传播得较慢。[同上] 这种效应可能会激励挖矿在专用高速网络中中心化，甚至在同一数据中心内中心化，以便矿工可以快速地将区块传播给彼此，而不会因 p2p 网络带宽限制而引入延迟。
区块链有效性的证明通过消除完整节点下载和执行每个区块中的每个交易以同步到链顶端的要求，从而解决了任意大小区块的 IBD 问题。相反，可以生成截至给定区块高度 `n` 的有效性证明，该证明可用于说服完整节点：1) UTXO 集的副本派生自截至区块 `n` 的权重最大的有效链，以及 2) 新收到的区块 `n+1, n+2, etc` 正确地建立在权重最大的有效链之上。这意味着完整节点只需下载截至区块 `n` 的 UTXO 集的副本，验证 `n` 的证明，并执行在 `n` 之上构建的区块中的交易，直到下一个证明，而不是执行从创世区块开始的所有区块中的所有交易。可以继续为每个区块或批量区块生成证明，以保持完整节点的快速 IBD 和同步时间。
这种“证明同步”技术可以解决大区块的 IBD 问题，但不能解决挖矿中心化问题。仍然需要完成工作以降低增加的 L1 交易量的带宽成本和传播时间，例如通过实施或进一步优化诸如 Compact Block Relay 和 Erlay 等协议，这些协议即使在交易量增加的情况下也能降低带宽要求。[182][183] 并且无法避免存储区块链数据的要求，该数据随着区块链大小的增加而增加。尽管如此，少解决一个问题（IBD 问题）是一个不错的改进。最好的部分是，无需更改共识规则即可实施和开始使用证明同步客户端。在撰写本文时，有两个项目正在构建用 Cairo 编写的证明同步比特币客户端实现，一个名为 Khepri，另一个名为 Zerosync。[184][185]
<h2> 附录 F. 减轻受损的加密证明协议和有毒废物造成的危害 <sup id="appendix-f-mitigating-harm-from-compromised-cryptographic-proof-protocols-and-toxic-waste"></sup></h2>
[↩](#toc)
在讨论为比特币实施加密证明以保护隐私的想法时，经常提出的一个问题是意外通货膨胀的可能性。如果有人发现用于隐私协议的密码学中的这种漏洞，他们可以利用该漏洞来铸造任意数量的 BTC。此外，由于使用隐私协议的交易以某种方式加密，因此在一段时间内将无法检测到通货膨胀。这种担忧源于基于加密证明的加密货币隐私协议设计中的一个基本权衡：加密证明可以是完全隐藏的，也可以是完全绑定的，但不能两者兼得。[186] 这种权衡意味着协议设计者必须允许通过假冒来增加货币供应量，但如果密码学被破解，则保持隐私（完全隐藏），或者他们保持货币供应量的完整性，但允许隐私被破解（完全绑定）。加密交易的生产实现，包括 [附录 B](#appendix-b-comparing-alternative-cryptocurrency-privacy-techniques) 中涵盖的那些，通常设计为完全隐藏。
当使用计算证明进行交易验证而不是交易隐私时，例如验证未加密的汇总交易时，也存在相同的风险。如果加密证明被破解，那么任何利用该漏洞的人都将能够伪造证明，即使他们没有根据汇总账本控制这些资产的地址的私钥，也可以从汇总中提取资产。在这种情况下，可以立即检测到伪造，但如果 L1 完整节点和矿工没有做出反应以防止伪造的证明在 L1 上得到确认，则仍有可能造成灾难性的危害。
在比特币上的有效性汇总的背景下，减轻这些加密漏洞造成的危害的主要因素是有效性汇总是可选择加入的。 因此，从技术层面上讲，只有将 BTC 存储在有效性汇总中的用户才会受到加密证明漏洞利用的影响。 比特币 L1 的共识规则可以阻止攻击者从汇总中提取比最初存入的更多的 BTC，从而保持 L1 货币供应的完整性。
有些人可能会争辩说，由于可能发生无法检测到的通货膨胀，因此在比特币上构建加密的有效性汇总会威胁货币供应的完整性。 实际上，发生的任何意外的、无法检测到的通货膨胀都可能被隔离到加密的汇总中，以便完全可审计的“透明”BTC 供应保持完整无损。 如上所述，比特币共识规则可以阻止从加密的汇总中提取比存入的更多的 BTC，从而确保加密汇总之外的货币供应的完整性得到维护。
因此，如果你不想担心因为有人利用通货膨胀漏洞并从汇总中提取了最大可用余额而剩下毫无价值的加密 BTC，你可以将所有 BTC 保存在完全可审计的透明 BTC 层中。 如果你愿意冒险保留一些消费 BTC 加密以便你可以用强大的隐私进行交易，但又想保持其余 BTC 透明，这样你就不会让你的储蓄面临无法检测到的通货膨胀风险，那么你也可以这样做。 而且，如果你根本不担心通货膨胀漏洞，或者发现隐私收益值得冒险，你可以根据需要保留所有加密的 BTC。 加密的汇总为你提供了几个选项，具体取决于你的风险承受能力。
重要的是要注意，加密协议中无法检测到的通货膨胀_已经成为可能_，因为已经存在加密协议，其中与 BTC Hook的加密资产的供应量面临通货膨胀漏洞的风险。 例如，如果存在被利用的通货膨胀漏洞，则 Liquid 上的 L-BTC 和 Aztec 上的 renBTC 都可能被意外且无法检测地膨胀。[187][78] 这些现有加密协议和有效性汇总之间唯一相关的区别是，就本文讨论的目的而言，对于 L-BTC 和 renBTC，比特币用户必须信任第三方来托管他们的 BTC，而有效性汇总在设计上是自我托管的。 由于担心无法检测到的通货膨胀而反对在比特币上实施加密有效性汇总的人所能达到的结果不是阻止用户将 BTC 置于通货膨胀漏洞的风险中，而是阻止用户 _ 以自我托管的方式 _ 这样做，而是将 BTC 推入受信任的托管人的控制之下 — 反作用意外(?)的结果。[188]
<h2> 许可证 <sup id="license"></sup></h2>
[↩](#toc)
本报告中产生的所有原创作品的版权和相关权利已通过 [CC0](https://github.com/john-light/validity-rollups/blob/main/LICENSE) 放弃。
本报告中引用的第三方产生的所有作品的版权和相关权利仍归相应的权利持有人所有。
<h2> 参考文献 <sup id="references"></sup></h2>
[↩](#toc)
[^1]: https://bitcointalk.org/index.php?topic=770.msg8637#msg8637
[^2]: https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf
[^3]: https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
[^4]: https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
[^5]: https://zerocoin.org/media/pdf/ZerocoinOakland.pdf
[^6]: https://yewtu.be/watch?v=Q4nWoEKUtgU
[^7]: https://explorer.firo.org/block/c0c53331e3d96dbe4a20976196c0a214124bef9a7829df574f00f4e5a1b7ae52
[^8]: https://electriccoin.co/blog/zcash-sprout-launch/
[^9]: https://medium.com/starkware/the-cambrian-explosion-of-crypto-proofs-7ac080ac9aed
[^10]: https://en.bitcoin.it/wiki/Block_size_limit_controversy#Damage_to_decentralization
[^11]: https://github.com/fresheneesz/bitcoinThroughputAnalysis/blob/master/README.md#general-goals
[^12]: https://blog.lopp.net/bitcoin-core-performance-evolution/
[^13]: https://btctranscripts.com/greg-maxwell/2017-11-27-gmaxwell-advances-in-block-propagation/
[^14]: https://bitcoinmagazine.com/technical/how-falcon-fibre-and-the-fast-relay-network-speed-up-bitcoin-block-propagation-part-1469808784
[^15]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
[^16]: https://www.researchgate.net/publication/340300470_Design_Patterns_for_Gas_Optimization_in_Ethereum
[^17]: https://blog.ethereum.org/2014/10/21/scalability-part-2-hypercubes/
[^18]: https://blog.zilliqa.com/zilliqa-mainnet-the-launch-and-beyond-4cd7e113369f/
[^19]: https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum
[^20]: https://mimblewimble.cash/
[^21]: https://www.plan99.net/~mike/satoshi-emails/thread4.html
[^22]: https://bitcointalk.org/index.php?topic=244656.0
[^23]: https://lightning.network/lightning-network-paper.pdf
[^24]: https://www.bbc.com/news/technology-42237162
[^25]: https://medium.com/web3foundation/scalingnow-scaling-solution-summit-summary-be30047047bf
[^26]: https://medium.com/giveth/tackling-ethereum-scalability-issues-29bd700b5060
[^27]: https://medium.com/poa-network/poa-bridge-launch-live-demo-e3e7c9e4f08
[^28]: https://vitalik.ca/general/2019/06/12/plasma_vs_sharding.html
[^29]: https://www.ibtimes.co.uk/ethereums-vitalik-buterin-explains-how-state-channels-address-privacy-scalability-1566068
[^30]: https://medium.com/statechannels/counterfactual-generalized-state-channels-on-ethereum-d38a36d25fc6
[^31]: http://plasma.io/plasma-deprecated.pdf
[^32]: https://ethereum.org/en/developers/docs/scaling/plasma/#the-mass-exit-problem-in-plasma
[^33]: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
[^34]: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
[^35]: https://medium.com/@kelvinfichter/why-is-evm-on-plasma-hard-bf2d99c48df7
[^36]: https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741
[^37]: https://vitalik.ca/general/2019/08/28/hybrid_layer_2.html
[^38]: https://github.com/barryWhiteHat/roll_up
[^39]: https://twitter.com/EliBenSasson/status/1450173650041245699
[^40]: https://twitter.com/fuellabs_/status/1344707195250896899
[^41]: https://medium.loopring.io/loopring-deployed-protocol-3-0-on-ethereum-a33103c9e5bf
[^42]: https://medium.com/aztec-protocol/launching-aztec-2-0-rollup-ac7db8012f4b
[^43]: https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306
[^44]: https://vitalik.ca/general/2022/08/04/zkevm.html
[^45]: https://twitter.com/krzKaczor/status/1524753291912962048
[^46]: https://twitter.com/EdanYago/status/1527808313689354241
[^47]: https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698
[^48]: https://research-development.nomadic-labs.com/tezos-is-scaling.html
[^49]: https://jsidhu.medium.com/blockchain-idealisms-b61c5781ddc3
[^50]: https://blog.celestia.org/sovereign-rollup-chains/
[^51]: https://hrf.org/zkrollups
[^52]: https://medium.com/starkware/redefining-scalability-5aa11ffc5880
[^53]: https://medium.com/@deaneigenmann/optimistic-contracts-fb75efa7ca84
[^54]: https://web.archive.org/web/20220330031608/https://polynya.medium.com/updated-thoughts-on-modular-blockchains-ce1b159fa1b3
[^55]: https://docs.zksync.io/userdocs/security/#priority-queue
[^56]: https://fuel-labs.ghost.io/token-model-layer-2-block-production/
[^57]: https://www.alexbeckett.xyz/decentralized-sequencers-where-do-we-go-next/
[^58]: https://blog.matter-labs.io/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58
[^59]: https://blog.celestia.org/clusters/
[^60]: https://twitter.com/ercwl/status/1311452208127447044
[^61]: https://twitter.com/statelayer/status/1311851018741846017
[^62]: https://twitter.com/ercwl/status/1497801246295605250
[^63]: https://twitter.com/ercwl/status/1497966811928801282
[^64]: https://twitter.com/hodlonaut/status/1086703428791865345
[^65]: https://twitter.com/hodlonaut/status/1091987050675490818
[^66]: https://twitter.com/ercwl/status/1497307148317044741
[^67]: https://bitcointalk.org/index.php?topic=1790
[^68]: https://counterparty.io/docs/faq-smartcontracts/#can-ethereum-smart-contracts-run-on-counterparty
[^69]: https://medium.com/iovlabs-innovation-stories/bitcoin-sidechains-74a72ceba35d
[^70]: https://lightco.in/2020/08/02/bitcoin-pegs/
[^71]: https://eprint.iacr.org/2019/1128
[^72]: https://blog.rsk.co/noticia/blockchain-bridges-an-industry-overview/
[^73]: https://yewtu.be/watch?v=9s3EbSKDA3o
[^74]: https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy
[^75]: https://medium.com/boltlabs/zkchannels-for-bitcoin-f1bbf6e3570e
[^76]: https://arxiv.org/abs/2208.09716v1
[^77]: https://bitcoiner.guide/privacy/
[^78]: https://medium.com/aztec-protocol/introducing-private-bitcoin-1cd9d895c770
[^79]: https://blog.blockstream.com/blockstream-sponsors-federated-e-cash-as-a-bitcoin-scaling-technology/
[^80]: http://zerocash-project.org/paper
[^81]: https://fc21.ifca.ai/papers/243.pdf
[^82]: https://medium.com/aztec-protocol/launching-aztec-2-0-rollup-ac7db8012f4b
[^83]: https://medium.com/aztec-protocol/aztecs-zk-zk-rollup-looking-behind-the-cryptocurtain-2b8af1fca619
[^84]: https://explorer.aztec.network/tx/994d892ebc203949e632add016796f69a88a42d3f4a40a58cae60c09ecc3e46d
[^85]: https://twitter.com/_prestwich/status/1284174486674083840
[^86]: https://vitalik.ca/general/2021/01/05/rollup.html
[^87]: https://medium.com/aztec-protocol/privacy-for-pennies-scaling-aztecs-zkrollup-9f2b36615cc6
[^88]: https://bitcoinops.org/en/tools/calc-size/
[^89]: https://en.bitcoin.it/wiki/Weight_units
[^90]: https://crypto.stackexchange.com/a/6375
[^91]: https://medium.com/starkware/fractal-scaling-from-l2-to-l3-7fe238ecfb4f
[^92]: https://eprint.iacr.org/2019/1021.pdf
[^93]: https://medium.com/starkware/recursive-starks-78f8dd401025
[^94]: https://blog.blockstream.com/c-lightning-opens-first-dual-funded-mainnet-lightning-channel/
[^95]: https://twitter.com/JohnCantrell97/status/1478794694159220747
[^96]: https://jlopp.github.io/bitcoin-transaction-size-calculator/
[^97]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
[^98]: https://tr3y.io/articles/crypto/bitcoin-zk-rollups.html
[^99]: https://bitcointalk.org/index.php?topic=278122.0;all
[^100]: https://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-vaults/
[^101]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019885.html
[^102]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[^103]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[^104]: https://blockstream.com/simplicity.pdf
[^105]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020036.html
[^106]: https://blog.blockstream.com/en-covenants-in-elements-alpha/
[^107]: https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
[^108]: https://dusk.network/news/zero-knowledge-plonk-demo
[^109]: https://twitter.com/EliBenSasson/status/1275423886788694018
[^110]: https://en.bitcoin.it/wiki/Scalability#CPU
[^111]: https://bitcoin.stackexchange.com/a/60008
[^112]: https://bitcoinist.com/double-spend-fud-crashes-bitcoin-below-30000-return-of-bear-trend/
[^113]: https://web.archive.org/web/20211026122447/https://www.coindesk.com/markets/2014/01/09/bitcoin-miners-ditch-ghashio-pool-over-fears-of-51-attack/
[^114]: https://www.erisian.com.au/wordpress/2016/01/07/bitcoin-fees-in-history
[^115]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015455.html
[^116]: https://arxiv.org/abs/1904.05234v1
[^117]: https://dci.mit.edu/research/smart-contracts-discrete-log-contracts
[^118]: https://docs.bitmatrix.app/v1/11_21_21/Bitmatrix_Paper_Early_Preview.pdf
[^119]: https://hackmd.io/ivUzk3piQEG8ALzCGbxlag#311-Fair-ordering
[^120]: https://hackmd.io/ivUzk3piQEG8ALzCGbxlag#312-Privacy-solutions
[^121]: https://eprint.iacr.org/2020/1614
[^122]: https://eprint.iacr.org/2019/775
[^123]: https://blog.bitmex.com/txwithhold-smart-contracts/
[^124]: https://github.com/0xbunnygirl/request-for-reorg
[^125]: https://github.com/DZGoldman/Deorg
[^126]: https://eprint.iacr.org/2018/581.pdf
[^127]: https://www.truthcoin.info/blog/drivechain/
[^128]: https://medium.com/@deaneigenmann/optimistic-contracts-fb75efa7ca84
[^129]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html
[^130]: https://lightco.in/2022/06/15/miners-can-steal-2/
[^131]: https://yewtu.be/watch?v=vAE5fOZ2Luw (快进到 11:01)
[^132]: https://bitcoinmagazine.com/culture/bitcoin-songsheet-private-property
[^133]: https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki
[^134]: https://docs.blockstream.com/blockstream-amp/overview.html
[^135]: https://docs.blockstream.com/blockstream-amp/case-studies.html#case-study-2-exordium-security-token
[^136]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019923.html
[^137]: https://www.forbes.com/sites/adelsteinjake/2018/04/30/japans-financial-regulator-is-pushing-crypto-exchanges-to-drop-altcoins-favored-by-criminals/
[^138]: https://asiatimes.com/2020/11/south-korea-bans-privacy-coins/
[^139]: https://finance.yahoo.com/news/litecoin-anonymity-gets-booted-south-031233431.html
[^140]: https://home.treasury.gov/news/press-releases/jy0916
[^141]: https://twitter.com/batuhan_katirci/status/1558086141273722880
[^142]: https://twitter.com/WuBlockchain/status/1560989831307890690
[^143]: https://twitter.com/takenstheorem/status/1560479290264883201
[^144]: https://www.coincenter.org/analysis-what-is-and-what-is-not-a-sanctionable-entity-in-the-tornado-cash-case/
[^145]: https://www.paradigm.xyz/2022/09/base-layer-neutrality
[^146]: https://www.pymnts.com/cryptocurrency/2022/privacy-coin-moneros-use-in-ransomware-fuels-growing-security-concerns/
[^147]: https://fc18.ifca.ai/preproceedings/6.pdf
[^148]: https://en.wikipedia.org/wiki/Lindy_effect
[^149]: https://twitter.com/allenyhsu/status/1203879946591981568
[^150]: https://tradelayer.substack.com/p/trade-offs-in-zk-design-space
[^151]: https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/
[^152]: https://medium.com/aztec-protocol/vulnerabilities-found-in-aztec-2-0-9b80c8bf416c
[^153]: https://hackmd.io/@aztec-network/disclosure-of-recent-vulnerabilities
[^154]: https://vitalik.ca/general/2022/03/14/trustedsetup.html
[^155]: https://medium.com/starkware/stark-math-the-journey-begins-51bd2b063c71
[^156]: https://yewtu.be/watch?v=8qSA29vWWds
[^157]: https://eprint.iacr.org/2019/360
[^158]: https://en.bitcoin.it/wiki/Privacy#Amount_correlation
[^159]: https://en.bitcoin.it/wiki/Privacy#Change_address_detection
[^160]: https://arxiv.org/abs/2109.10229v2
[^161]: https://abytesjourney.com/lightning-privacy/
[^162]: https://docs.grin.mw/about-grin/privacy/
[^163]: https://docs.beam.mw/Lelantus-MW.pdf
[^164]: https://bytecoin.org/old/whitepaper.pdf
[^165]: https://www.getmonero.org/2016/09/19/monero-0.10.0-released.html
[^166]: https://www.getmonero.org/2018/10/11/monero-0.13.0-released.html
[^167]: https://www.exploremonero.com/transaction/9942cb34786bbb46f106ed31a6bb67eeb6e946d592def0900cab60ca83199f22
[^168]: https://z.cash/technology/zksnarks/
[^169]: https://explorer.zcha.in/transactions/169b903466119c78653eaf94d8d4b69eb51c38a3a6fcaa318f21f41adcec59ea
[^170]: https://twitter.com/socrates1024/status/1224434578149888000
[^171]: https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb
[^172]: https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf
[^173]: https://blog.celestia.org/celestiums/
[^174]: https://arxiv.org/abs/1905.09274
[^175]: https://arxiv.org/abs/1809.09044v4
[^176]: https://www.paradigm.xyz/2022/08/das
[^177]: https://ethresear.ch/t/adamantium-power-users/9600
[^178]: https://blockstream.com/sidechains.pdf
[^179]: https://blog.horizen.io/horizens-cross-chain-protocol-zendoo-is-live-on-mainnet-build-on-the-zero-knowledge-network-of-blockchains/
[^180]: https://eprint.iacr.org/2020/352.pdf
[^181]: https://bitfury.com/content/downloads/block-size-1.1.1.pdf
[^182]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
[^183]: https://arxiv.org/abs/1905.10518
[^184]: https://github.com/bitcoin-stark/khepri
[^185]: https://github.com/zerosync/zerosync
[^186]: https://web.archive.org/web/20201105045447/https://old.reddit.com/r/Bitcoin/comments/izj4a3/technical_confidential_transactions_and_their/
[^187]: https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf
[^188]: https://www.econlib.org/library/Enc/UnintendedConsequences.html
>- 原文链接： [github.com/john-light/va...](https://github.com/john-light/validity-rollups/blob/main/validity_rollups_on_bitcoin.md)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
