比特币上的有效性 Rollup

本文讨论了在比特币上构建有效性 Rollup 的可能性和潜在好处,包括提高交易吞吐量、增强隐私性以及实现新的智能合约功能。文章详细探讨了有效性 Rollup 的工作原理,以及与在比特币上实施它们相关的成本和风险,并得出结论:有效性 Rollup 有可能在不牺牲比特币核心价值和功能的前提下,显著提升比特币的可扩展性。

比特币上的有效性 Rollup

作者:John Light

联系作者:<https://lightco.in/contact>

托管于 GitHub

<h2> 目录 <sup id="toc"></sup></h2>

<h2> 致谢 <sup id="acknowledgements"></sup></h2>

本报告是作者参与人权基金会 (Human Rights Foundation) 的 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>

这是一个非常有趣的话题。 如果找到了解决方案,那么比特币的实现将变得更好、更简单、更方便。

最初,一个币可以只是一个签名链。 有了时间戳服务,旧的签名最终可以被丢弃,以免出现过多的回溯扇出,或者可以将币单独保存或以面额保存。 正是检查是否存在双重支出的需求才需要全局了解所有交易。

挑战在于,如何证明不存在其他支出? 似乎一个节点必须了解所有交易才能验证这一点。 如果它只知道输入/输出点的哈希值,它就无法检查签名以查看输出点是否已被支出...

在这种情况下,很难想到如何应用零知识证明。

我们试图证明不存在某事物,这似乎需要了解所有事物并检查该事物是否未包含在内。

—— 中本聪 [^1]

自从比特币创始人中本聪首次考虑如何使用零知识 (zk) 证明技术来改进他发明的电子现金协议以来,已经过去了十年多。zk 证明最初由 Goldwasser、Micali 和 Rackoff 在他们 1985 年的论文“交互式证明系统的知识复杂性”中描述,是一种密码学证明,定义为“除了问题的正确性之外,不包含任何额外知识的那些证明。”[^2] 在那篇开创性论文发表 35 年多后,以及在中本聪首次讨论在比特币中使用 zk 证明 10 年后,密码学证明协议现在已成为前沿区块链扩展和隐私协议的核心组成部分。

在比特币背景下使用 zk 证明的第一个具体提议来自 Greg Maxwell,他在 2011 年在 Bitcoin Wiki 上撰写了关于“零知识条件支付”的文章。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 的推出,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 大小,和/或通过减少验证交易所需的计算资源来实现,例如通过优化用于签名验证的库。此类优化已显着改善了 Bitcoin Core 中的交易验证和初始区块下载时间。[^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] 迅速实施了以牺牲安全性来换取吞吐量的短期解决方案,例如侧链。[^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 节中的“[多数容易受到攻击的合约](#majority-vulnerable-contracts)”。

有了解决先前可扩展性提案中最重要缺陷的解决方案,以太坊开发人员开始推动 Rollup 功能的极限。例如,Fuel 和 Loopring 团队分别为 p2p 支付和原子交换构建了乐观和有效性 Rollup,而 Aztec 团队为 Zerocash 风格的“屏蔽”交易构建了一个有效性 Rollup。[^40][^41][^42] 最终,以太坊开发人员甚至弄清楚了如何构建完全 EVM 兼容的 Rollup,首先使用乐观 Rollup,然后使用有效性 Rollup。[^43][^44](应该注意的是,截至撰写本文时,以太坊上的所有实时 Rollup(除了 Fuel)都依赖于多重签名来保护其桥接合约,这是一种不同于“真正” 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,是因为 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 抵押品保护的真实主网 BTC),只需发布你的以太坊地址。无需设置。然后我将火炬转移给一个我信任不会带着它逃跑的人。然后你会做同样的事情。我们将看看它能走多远了。[^60]

图 1. #tBTCzkSyncTorch 的可视化

figure1_vr

图片来源:[^61]

然后 Wall 从他信任的人中选择了一个地址,并使用 zkSync 向该地址发送了一些 TBTC。接收者在他们自己的 Twitter 帐户上发布了类似的消息,并将“火炬”转移到下一个地址。等等等等,直到最终火炬回到了 Wall 手中。他持有 TBTC,直到他有其他事情要做。 2022 年 2 月,在俄罗斯政府入侵乌克兰之后,乌克兰政府公布了一个以太坊地址,以收集世界各地人民的捐款,协助他们的抵抗行动。Wall 决定使用 torch 资金进行捐赠,并在 zkSync 上提交了一笔交易,将 TBTC 提现回以太坊 L1。

图 2. Eric Wall 的 zkSync 提款,如 zkscan.io 区块浏览器所示

figure2_vr

图片来源:[^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 传递给其他人,如此循环形成一个长的 "trust chain" (信任链)。[^64] 信任链之所以得名,是因为 torch 的每个接收者都被信任不会将 BTC 据为己有,而是会添加更多 BTC 并将其传递给他们信任的其他人,让他们也这样做。

由于闪电网络是一个支付通道网络,因此 #LNTrustChain 中的用户必须在彼此之间建立通道,或者沿着具有足够出站和入站流动性余额的通道路径连接,以便他们可以发送和接收 torch。在许多情况下,这种流动性需求给 torch 的潜在接收者带来了问题。[^65]

图 3. #LNTrustChain 参与者寻求入站流动性,以确保 torch 能够传递。

figure3_vr

图片来源:[^65]

相比之下,#tBTCzkSyncTorch 参与者从未遇到任何流动性问题。根据设计,不可能出现此类流动性问题。Rollup 的功能类似于区块链,用户可以发送价值高达其钱包全部余额的付款,而无需担心路由流动性,并且用户可以接收付款,而没有入站容量限制。无需像闪电这样的支付通道网络那样,在通道中锁定资金或管理入站/出站流动性,即可在 rollup 上发送和接收付款。这些功能使 validity rollups 比闪电更具资本效率,并且至少对于新用户而言,更易于使用。

应该注意的是,这是一个苹果与橙子的比较:zkSync 是一个使用具有全局状态的区块链数据结构的 rollup,而闪电是具有点对点本地状态的支付通道网络。这些协议表面上相似,因为它们都被认为是 L2 协议,并且都促进付款。除此之外,它们在“底层”具有重要的根本差异。因此,对两者的比较并不是说闪电与 validity rollups 相比没有其自身的优势,例如极低的成本、高度安全、高速/高吞吐量的链下交易。但是,如 #LNTrustChain 用户体验所示,使闪电达到可用于 p2p 支付的状态的挑战揭示了其设计固有的权衡和粗糙之处,由于其基于区块链的设计,rollups 避免了这些问题。

第 4.4 节中可以找到对闪电网络的更深入的了解,以及它与 validity rollups 的比较、对比和补充(反之亦然)。

<h2> 第 3 节. 启用新功能 <sup id="section-3-enabling-new-functionality"></sup></h2>

validity rollups 的一个有趣的特性是,它们可以向其父链添加全新的功能,而无需任何额外的共识规则更改。之所以成为可能,是因为父链完整节点不需要了解 rollup 的特定共识规则并知道如何按照这些规则执行交易,而只需要知道如何验证 rollup 的 validity proof。因此,例如,在比特币 L1 上构建的 L2 validity rollup 可以实现一个执行环境,该环境支持更灵活的智能合约语言或更高级的隐私技术,而无需对比特币进行其他更改。[^66]

<h3> 第 3.1 节. 新的智能合约语言 <sup id="section-31-new-smart-contract-languages"></sup></h3>

自从比特币早期以来,人们一直设想增加额外的脚本功能,以支持比比特币原生支持的更多类型的资产和智能合约。[^67] 从那以后的几年中,新功能已实现为 Script(比特币的原生脚本语言)的扩展,或使用全新的智能合约语言。以下是已经提出的一些新的智能合约语言:

如今,有两种方法可以在比特币环境中使用这些编程语言:

  1. 将对它们的支持构建到比特币中,作为“嵌入式共识”层(例如 Omni, Counterparty)[^68]
  2. 将对它们的支持构建到替代区块链中(例如,一种山寨币或侧链)[^69]

在这两种情况下,这些替代编程语言都将无法原生处理 BTC。相反,需要构建一个桥梁(在文献中也称为“双向Hook”),该桥梁会将 BTC 锁定在比特币主链上,在新执行环境中释放等量的 BTC IOU,并实施某种机制将 IOU 转换回主链上的 BTC。[70] 如今,比特币共识规则限制了可以构建到和来自任意复杂执行环境的桥梁的类型,并且通常认为它们不如直接使用比特币主链安全。[71][72]

如果可以在比特币上构建带有替代执行环境的 validity rollups,那么比特币用户就可以试验这些替代执行环境,同时保留比特币 L1 的完整“自我托管”所有权安全性。Validity rollups 将消除对 BTC IOU 的需求,因为在比特币上构建的 validity rollups 将能够原生处理 BTC。此外,由于比特币完整节点只需要验证正确计算的证明,而实际上不必重放执行 rollup 交易所需的完整计算,因此在 validity rollup 中实现这些替代执行模型几乎不会给比特币完整节点带来额外的计算负担。

<h3> 第 3.2 节. 新的隐私保护 <sup id="section-32-new-privacy-protections"></sup></h3>

比特币的透明性使得链上构建的隐私协议本质上是脆弱的,因此不足以长期保护隐私。[73] 闪电和 zkChannels 等链下 L2 协议有其自身的隐私挑战和局限性,这主要是由于这些协议构建在其上的比特币基础层的透明性和有限的脚本功能。[74][75](有关最近提出的对支付通道网络隐私的改进,请参见 2022 年 8 月的 zk-PCN 论文。[76])由于比特币固有的隐私限制以及现有工具的不成熟,比特币用户要么必须遵循关于如何获得某种程度的隐私的漫长而详细的指南,一丝不苟地遵循每个步骤并希望其他用户也这样做,以便他们可以保留其匿名集,否则将其 BTC 屈服于中心化或联邦式链下系统,以在其他地方获得更强大、更易于使用的隐私。[77][78][79]

自从中本聪首次考虑如何使用 zk 证明来提高比特币隐私以来,密码学家们发明了新的协议,大大提高了私有加密货币交易的质量和可用性。Validity rollups 使得可以在比特币上实施这些新的隐私协议,同时继承 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 中,与在 L1 上执行相同类型的交易相比,Aztec 能够为用户节省大量成本。通过转移到 zk-zk-rollup 而不是在比特币 L1 上进行交易,比特币用户同样可以为私有交易获得强大的隐私保护和成本节省。

图 4. Aztec 屏蔽交易,如 aztec.network 区块浏览器所示

figure4_vr

图片来源:[^84]

可以在附录 B中找到可以在 validity rollup 中实施的新链上私有交易技术的比较。

由于其客观上优越的隐私保护,出于第 4 节中可扩展性讨论的目的,屏蔽交易被用作在比特币上的 validity rollup 中实施新的私有交易协议的示例。

<h2> 第 4 节. 扩展改进 <sup id="section-4-scaling-improvements"></sup></h2>

<h3> 第 4.1 节. 通过 validity rollups 提高吞吐量 <sup id="section-41-increasing-throughput-with-validity-rollups"></sup></h3>

James Prestwich 将区块链环境中的扩展定义为“在同一硬件上验证更多交易”。[^85] 根据此定义,validity rollups 可以通过增加获得父链完全安全性的交易数量来改善扩展,而父链完整节点无需(或略有增加)计算成本。Validity rollups 提高扩展的确切程度取决于实施细节。(请注意,本节中的交易大小和吞吐量数字是近似值,可能会根据实施细节而变化。)

如果将 validity rollup 设计为像比特币一样工作,具有未花费的交易输出 (UTXO) 模型且没有地址重用,则每笔 rollup 交易将为 113.5 weight units (WU)。这等于删除见证的 1 输入 2 输出 pay-to-witness-public-key-hash (P2WPKH) 交易的权重(因为见证已替换为涵盖所有 rollup 交易的 validity proof),并假设见证折扣适用于交易中的所有数据(因为父链完整节点不需要执行这些交易或将其存储在 UTXO 集中)。

如果 validity rollup 使用具有地址重用的账户模型(即,每个用户一个地址),则可以将每笔 rollup 交易的权重降低到 12 WU。[86] 这是因为可以将公钥分配给 rollup 上的账号,然后可以以高度压缩的格式安全地表示它们。然后,发送者和接收者只需通过其账号来引用,而不是在每笔交易中都包含公钥或地址。在父链上确认的状态更新交易中,也可以删除或压缩原本会在非 rollup 交易中使用更多字节的其他 rollup 交易详细信息。

如果 validity rollup 使用基于 UTXO 的屏蔽交易模型,则必须考虑交易数据的两个组成部分:加密的交易记录详细信息 (530 WU) 和连接拆分数据 (129 WU),从而使每笔 1 输入 2 输出的屏蔽 rollup 交易的总权重达到 659 WU。[87] 这使得屏蔽交易比原始 segwit 1 输入 2 输出 P2WPKH 交易略重(以 WU 为单位)。鉴于它们可能具有更大的匿名集,并且超过 "2" 的匿名集后,透明 P2WPKH 交易变得比屏蔽交易重得多,因此屏蔽交易的更大的链上 footprint 可能会被认为是接受这种对私有交易的质量和可用性的显着改进的可接受成本。

按 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 描述:Validity rollup 账户模型是以高度压缩格式的 L2 交易。[86] Validity rollup 1 输入 2 输出 P2WPKH 是一个 L2 P2WPKH 交易,其中删除了 27 字节的见证(因为见证已替换为涵盖所有 rollup 交易的 validity proof),并且见证折扣应用于交易中的所有数据(因为父链完整节点不需要执行这些交易或将其存储在 UTXO 集中)。[^88] 主链 1 输入 2 输出 P2WPKH 是比特币 L1 上的原始 segwit 交易。[88] Rollup 屏蔽 1 输入 2 输出是加密的 L2 交易,其中见证折扣应用于交易中的所有数据。[87]

为了以“最小可能的 rollup 交易的倍数”来直观地比较每种交易类型,我们可以像图 5 中那样将它们表示为块。

图 5. 以最小可能的 rollup 交易类型的倍数来直观地比较类似的交易。

figure5_vr

图 5 描述:假设 12 WU 账户模型 validity rollup 的最小交易大小,比特币主链 1 输入 2 输出 P2WPKH 交易比提供相同功能的最小可能的 rollup 交易类型大 46.75 倍(将付款发送给单个接收者,并将一些更改返回给发送者)。

如果父链是比特币,并且每个区块的可用容量与今天相同(4,000,000 WU 或 1,000,000 vbytes),则与 1 输入 2 输出 P2WPKH 主链交易相比,类似于比特币的 UTXO 模型 validity rollup 且没有地址重用可以使每个区块容纳多达约 3.7 倍的交易。这假设 3,000,000 WU 被 rollup 区块中所有 rollup 交易的数据占用,而 1,000,000 WU 留给 validity proof、交易脚本和其他杂项交易数据。[89] 在相同的假设下,账户模型 validity 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 账户模型 Validity proof, script, other tx data 250,000 txs (12 WU/tx) 250,000
Rollup 1 输入 2 输出 UTXO Validity proof, script, other tx data 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 Validity proof, script, other tx data 4,552 txs (659 WU/tx) 4,552

表 2 描述:请注意,这些数字假设见证折扣应用于作为 rollup 区块一部分的所有交易数据。该表将 L1 主链区块分为 1,000,000 WU 和 3,000,000 WU 的部分,以说明在 rollup 交易的情况下,必须将一些权重限制用于 rollup validity proof 和脚本数据,而其余部分可用于 rollup 交易数据。

到目前为止,我们仅基于每个比特币区块中当前可用的数据存储空间讨论了每个区块交易数量的吞吐量增加。但是与比特币交易不同——即使是在一个假设的世界上,交易规模也进行了优化,例如跨输入签名聚合——比特币完整节点不必执行每个 validity rollup 交易来确定它们是否有效。比特币完整节点必须执行的唯一计算,才能验证一个区块的 validity rollup 交易的价值,是验证 validity proof。无论是在验证一个交易还是在验证一个具有完整区块价值的交易的有效性,rollup validity proof 都需要花费相同的时间和计算量来进行验证。为了进一步利用计算效率的提高,可以为每个比特币区块中的 rollup 交易提供额外的“哑存储”空间。这将使每个比特币区块容纳更多的 rollup 交易,而不会给比特币完整节点带来任何额外的 CPU 负担。

有关如何通过实施链下和链上/链下混合数据可用性协议来获得更多吞吐量和成本节省的详细信息,请参见附录 C附录 D

有关 validity proof 如何实现比单独的 validity rollups 更多的吞吐量增加的详细信息,请参见附录 E

<h3> 第 4.2 节. 使用 rollups 进行分形扩展 <sup id="section-42-fractal-scaling-with-rollups"></sup></h3>

validity rollups 提供的扩展增益不会在 L2 处停止。Validity rollups 可以分层在 validity rollups 之上,以提供“分形扩展”到几乎无限的规模级别。一旦比特币 L1 区块被 L2 validity rollup 交易所填满,就可以在 L2 validity rollup 之上构建一个 Layer 3 (L3) validity rollup。然后,一旦 L2 validity rollup 区块被 L3 validity rollup 交易所填满,就可以在 L3 validity rollup 之上构建一个 Layer 4 (L4) validity rollup,依此类推。[91]

图 6. 分层 rollups

figure6_vr

图 6 描述:一个可视化 rollups 如何彼此分层的图形。在此示例中,有两个 L2 rollups:一个专门用于提供数据可用性(可能具有激励措施来惩罚数据不可用性攻击),另一个专门用于保证安全支付和合约。在 L2 数据可用性 rollup 之上,有三个 L3 rollups,每个 rollup 专门用于不同的用例:私有 p2p 支付、金融合约以及游戏内资产所有权和转移。由于 L3 rollups 依赖于 L2 完整节点来实现数据可用性,因此与依赖于比特币 L1 完整节点来实现数据可用性安全的 L2 rollups 相比,它们可以被认为是不太安全的。这种降低的安全性的权衡将是由于 L2 上数据存储成本降低而导致的更低的交易成本。需要高安全性的用例可以使用 L2 rollup,例如此处的高安全性支付和合约 rollup。

<h3> 第 4.3 节. 水平扩展 validity rollups <sup id="section-43-horizontally-scaling-validity-rollups"></sup></h3>

随着需要在每个 rollup 层证明更多交易有效,创建必要的 validity proof 的难度也会增加。可以使用递归证明组合来并行化创建这些证明所需的计算。递归本质上是“证明证明的有效性”,因此许多计算机可以致力于证明不同交易的有效性,然后可以将这些证明最终组合成一个证明,从而允许使用多台计算机同时贡献于证明 rollup 区块有效性的水平扩展。使用 SNARK 和 STARK 证明已经可以实现无需信任的递归证明组合。[92][93]

图 7. 递归证明工作流程

figure7_vr

图片来源:[^93]

<h3> 第 4.4 节. 使用 validity rollups 扩展闪电网络 <sup id="section-44-scaling-the-lightning-network-with-validity-rollups"></sup></h3>

闪电网络是一个去中心化的双向支付通道网络,它将链下支付路由并使用基础层区块链上的智能合约进行争议解决和最终结算。[23] 闪电网络使任何两个通过具有足够流动性的通道路线连接的用户都能够近乎即时地发送和接收价值,并且通常比在结算层区块链上进行交易的成本低得多。为了以自我托管的方式加入闪电网络,用户必须首先确认与另一位闪电网络用户打开通道的交易。可以使用双重资助通道在单个交易中启用双向流动性。[94] 打开通道后,以后可能需要额外的链上交易来进行维护,例如通道重新平衡或通道关闭以进行最终结算。

打开和结算(以及偶尔重新平衡)自我托管闪电通道所需的链上交易会占用有限的比特币区块空间的可测量数量。这种区块空间占用导致在给定时间段内可以加入闪电网络的自我托管用户数量存在硬性上限。[95] Validity rollups 实现的额外交易容量可用于支持更多闪电交易,从而增加可以加入并以自我托管方式使用闪电网络的潜在用户数量。确切的数字取决于用于闪电通道的交易类型。对于 2-P2WPKH 输入-1-P2WSH 输出-2-P2WPKH 输出的双重资助通道,rollups 可以为多达 3.8 倍的闪电通道打开交易创建空间。

表 3. 比较不同类型的 UTXO 模型双重资助闪电通道打开交易的大小
交易类型 非折扣数据权重 (4x) 折扣数据权重 (1x) 总计 (WU)
Rollup 闪电网络通道打开 0 197.5 197.5
主链闪电网络通道打开 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 闪电网络通道打开 Validity proof, script, other tx data 15,190 txs (197.5 WU/tx) 15,190
主链闪电网络通道打开 994 txs (1006 WU/tx) 2,982 txs (1006 WU/tx) 3,976

表 4 描述:该区块分为 1,000,000 WU 和 3,000,000 WU 的部分,以说明在 rollup 交易的情况下,一些权重限制是为 rollup validity proof 和脚本数据保留的,而其余部分可用于 rollup 交易数据。

将 validity rollups 分层堆叠在彼此之上的能力也意味着可以根据需要增加闪电网络的容量。每次 rollup 达到其最大容量时,都可以部署另一个 rollup 作为附加层,然后闪电网络加入可以继续进行,直到该层填满,依此类推。

尽管闪电网络以在比特币主链上结算而闻名,但闪电通道可以在任何与闪电网络兼容的区块链上打开和结算。此外,如果有闪电网络节点在两个或多个链上打开了通道,它可以将这些不同链的用户的付款路由,就像这些用户在同一链上打开了通道一样。如果通过闪电网络通道路线发送和接收不同的资产(例如 BTC 和 LTC),则存在“无意看涨期权问题”。[^97] 但是,即使路线跨越多个链,在整个路线中使用相同资产的闪电网络通道路线也不会遭受此问题的影响,或者至少在考虑不同链上相同资产的不同版本之间存在的任何微小价格差异时,该问题可以忽略不计。因此,如果发送者和接收者之间存在具有足够流动性的路线,则在比特币 L1 上打开闪电网络 BTC 通道的用户可以与在 L2+ validity rollups 上打开闪电网络 BTC 通道的用户无缝交易。

图 8. 跨链闪电网络交易

figure8_vr

图 8 描述:有三个闪电网络节点:闪电网络节点“A”在比特币主链上打开了一个通道,闪电网络节点“B”在比特币主链和以闪电网络为中心的 rollup 上都打开了通道,闪电网络节点“C”在 rollup 上打开了一个闪电网络通道。B 与 A 和 C 都打开了一个双重资助通道,因此可以在它们之间路由付款,即使 A 和 C 各自在不同的层上打开了通道。

<h2> 第 5 节. 在比特币上构建 validity rollups <sup id="section-5-building-validity-rollups-on-bitcoin"></sup></h2>

在撰写本文时,几乎所有部署到生产环境的 validity rollups 都是在支持以图灵完备的编程语言编写的智能合约的区块链上构建的。图灵完备的编程语言的灵活性开辟了广泛的设计空间,rollup 开发者可以利用这些设计空间将特殊的特性和限制编程到 rollup 智能合约中,例如脚本功能、存款限制和可升级性。这种灵活性还意味着,随着 validity proof 技术的改进以及发现实施或优化某些功能的新方法,rollup 开发者可以升级他们的智能合约或部署新的智能合约,以跟上最新的技术发展。

尽管使用图灵完备的编程语言来构建 rollup 智能合约非常流行,但可以使用比特币的原生图灵不完备的编程语言 Script 在比特币上构建 validity rollup,只需对 Script 支持的操作码进行相对较小的更改(就代码占用空间而言)。2022 年 3 月,Trey Del Bonis 发表了一篇文章,详细描述了比特币上的 validity rollup 如何工作。[98] 根据 Del Bonis 的说法,在比特币上支持 validity rollups 所需的更改是一些额外的操作码,这些操作码启用了他的 rollup 设计的两个主要原语——validity proof 验证和Recursive Covenants。虽然不是严格要求,但 Del Bonis 表示还有其他更改可以显着降低成本并使 rollup 更高效,例如 OP_EVAL 和 PUSHSCRIPT 操作码,以及增加甚至完全移除堆栈元素大小限制。

赋予比特币完整节点验证 validity proof 的能力是支持 validity rollups 所需的明显更改,因为 validity proof 是 validity rollups 工作方式的重要组成部分。对于此组件,无论谁编写代码以在比特币中启用 validity proof 验证,都需要就他们想要启用的 rollup 类型做出一些决定。实施验证更复杂程序的证明的能力将启用具有更多功能的 rollups(例如,像 Rootstock 或 Stacks 这样更具表现力的智能合约),而更简单的证明将启用具有更少功能的 rollups(例如,像 Liquid 或比特币这样简单的支付和有限的操作码)。 不那么明显的是对递归 covenant 的需求,至少在 Del Bonis 的比特币 Rollup 设计中是这样。递归 covenant 是一种智能合约,它限制了 BTC 在支出后可以发送到的脚本类型。Del Bonis 使用递归 covenant 来推进rollup结构的演进,每次状态更新都确保锁定在rollup脚本中的 BTC,并且尚未被其所有者提取,在一次rollup状态更新到下一次状态更新之间仍然保留在脚本中。一旦rollup上的 BTC 所有者确认了rollup上有效的提款交易,他们就可以使用他们的 BTC 退出递归 covenant 脚本到他们指定的 L1 提款地址。

递归 covenant 是对比特币社区长期以来一直在考虑的 Script 的一项更改。[^99][^100][^101] 但是,目前还没有具体的提案在比特币开发者社区中达成广泛共识以实施递归 covenant。有一些提案,例如 BIP-118 和 BIP-119,可以实现更有限的 covenant,但是这些提案不具有确保发送到rollup的 UTXO 在其所有者准备将其提取回比特币 L1 之前保留在rollup中的递归属性。[^102][^103]

Del Bonis 的 Rollup 设计中另一个重要的更改是增加或删除堆栈元素大小限制。这将使有效性Rollup数据更易于Rollup脚本使用。通过增加可以容纳在每个Rollup状态更新中的事务数量,它还可以降低Rollup的使用成本,从而使Rollup更新的成本可以由更多的事务分摊。[^98] 在“锦上添花”的更改方面,Del Bonis 建议使用 OP_EVAL 和 PUSHSCRIPT 操作码来减小Rollup脚本在某些区域的大小,从而减少使用的区块空间量,从而降低Rollup的使用成本,在所有其他条件相同的情况下。

Del Bonis 的Rollup设计是在比特币上构建有效性Rollup的一种方法,但不是唯一的方法。例如,可以向比特币添加一个扩展块,其中包含自定义逻辑,以支持创建特定的或任意的Rollup设计。在他的文章中,Del Bonis 讨论了几种在比特币上构建Rollup的替代方法,无论是对他更详细的设计进行微小的调整,还是使用完全不同的机制来确保Rollup中持有的资金的安全。[^98] 与其直接添加对所需操作码的支持,不如使用 Jets 在 Simplicity 中实现对有效性Rollup原语的支持,例如。[^104] Anthony Towns 还建议使用 Chialisp 作为 Simplicity 的替代方案,用于类似的使用场景。[^105]

Elements 侧链项目(以及基于 Elements 的 Liquid 区块链)尚不支持支持有效性Rollup所需的有效性证明,但它确实支持递归 covenant。[^106][^107] 因此,在 Elements 中实施对有效性证明的支持,以及 Del Bonis 认为锦上添花的其他一些更改,可能是一条测试有效性Rollup协议的途径,该协议最终旨在部署在比特币上。

到目前为止,研究表明,通过一些更改,可以在比特币上构建有效性Rollup。一些设计在技术上可能更难实现,但是即使使用提出的更简单的实现,比特币用户也可以获得显着的扩展优势,并可能获得更多的隐私和其他理想的功能。

第 6 节。有效性Rollup的成本和风险 <sup id="section-6-the-costs-and-risks-of-validity-rollups"></sup>

虽然有效性Rollup可以为比特币带来的好处,例如提高交易吞吐量、提高交易隐私以及在 BTC 的使用方式上提供更大的灵活性,这在纸面上听起来都不错,但是这些好处并非没有成本或风险。除了与比特币软件更新和共识更改相关的通常成本(开发者审查时间、用户测试时间等)和风险(链分裂、BTC 价格下跌等)之外,有效性Rollup还有其自身的独特成本和风险需要考虑。

本节将研究在准备本报告时发现的成本和风险,尽管将来可能存在或出现此处未涵盖的其他成本和风险。与比特币有效性Rollup相关的成本和风险的意义在很大程度上取决于实施细节。在某些情况下,此处检查的风险是理论上的,而不是已知或已证实的风险。理论风险在适用时已注明,包括完整性和提示进一步研究其潜在危害的实际可能性。

第 6.1 增加带宽和存储成本 <sup id="section-61-increased-bandwidth-and-storage-costs"></sup>

如果 增加区块空间以允许更多的 Rollup 交易,那么向比特币添加有效性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 交易,有效性Rollup都会对 L1 完整节点施加一项新的成本:验证Rollup状态更新的有效性证明的成本。在所有其他条件相同的情况下,此验证成本可能会因证明的复杂性和已实施的性能优化而异。在文献中很难找到现代证明的基准验证时间。引用的证明验证时间范围从基于 PLONK 的两年 SNARK 的 5 毫秒到两年 STARK 的 2 毫秒。[^108][^109] 更新的证明实现可能在相同的硬件上验证速度更快,但总的来说,受益于优化最大的是证明时间,而不是验证时间。

根据发布到 Bitcoin Wiki 的基准测试,比特币交易在四核 i7 CPU 上大约需要 0.125 毫秒才能验证,这比两年前 STARK 的 2 毫秒验证时间快大约 16 倍。[^110] 因此,如果 16 笔交易进入有效性Rollup状态更新,那么与单个 L1 比特币交易相比,Rollup 将在验证成本上达到盈亏平衡。

如果在比特币上实现了对有效性Rollup的支持,开发者将不得不考虑一种对抗性的最坏情况,即攻击者将尽可能多的有效性证明打包到一个区块中,以尝试最大化其验证成本。这将使较弱的完整节点更难验证该区块,并减慢其在网络中的传播速度。

假设 Rollup 状态更新交易的基本成本(验证密钥 + 证明 + 脚本大小)为 2848 WU,正如 Del Bonis 估计的那样,这相当于每个 4,000,000 WU 的比特币区块最多有 1404 个 Rollup 状态更新交易。[^98] 以每次 Rollup 状态更新 2 毫秒的验证时间计算,每个区块的总验证时间为 2.8 秒。当前有记录的最长验证时间的区块是 #364292,其中包含一个大约需要 1 秒才能验证的非 coinbase 交易。[^111] 因此,验证一个包含这种大小的有效性Rollup更新的区块的最坏情况比当前有记录的最慢验证比特币区块慢大约三倍。

如果有人要在比特币中实现对有效性Rollup的支持,他们可能还希望以某种方式限制每个区块中可以包含的有效性证明的数量,以便他们可以限制最坏情况下的验证成本(如果某个区块中充满了有效性证明)。他们可以通过使用自然大小更大的证明(例如 STARK 或更大的 SNARK)或通过要求共识对证明进行更重的“加权”(“证明溢价”,与 SegWit 的“见证折扣”相反)来实现这一点。在此,每个区块允许的 Rollup 状态更新数量与强加给 L1 完整节点的额外验证成本之间需要取得平衡。

第 6.3 矿工可提取价值 <sup id="section-63-miner-extractable-value"></sup>

比特币的推出前提是矿工是经济理性的、自私的利润最大化者,并且他们的利润最大化行为将导致运作良好的点对点电子现金系统的出现。到目前为止,这种设计效果很好。关于双重支付攻击的谣言(结果证明是非事件)导致了迅速的经济报复,警告矿工永远不要偏离正常情况,即为了自私的利益而故意重新组织区块链。[^112] 即使仅仅是能够实施所谓的“51% 攻击”的可能性也导致矿工将其哈希算力从主要的矿池中重新分配出去。[^113]

话虽如此,矿工在比特币规范内运作以最大化其利润是正常且可预期的。例如,仅将支付最高费用的交易放入其区块中,而不包括支付较低费用的交易,这是被容忍甚至庆祝的。[^114][^115] 然而,在过去几年中,我们看到出现了新的矿工行为,尤其是在支持金融合约的区块链中,例如借贷和交易。这种行为已被称为“非基于费用的矿工可提取价值”,或简称“MEV”。[^116] MEV 包含越来越多的不同类型的价值,矿工可以通过对其有利地对区块中的交易进行排序来提取这些价值(通常以其他区块链用户的成本为代价)。

一个例子是“三明治攻击”,这是一种抢先交易的形式,可以针对基于链上自动做市商的算法交易所的用户执行。它的工作原理如下:观察内存池的矿工看到Alice在 AMMSwap 交易所下了 Asset ABC 的“市价买入”订单。矿工将在 AMMSwap 上下达他们自己的等额的 Asset ABC 市价买入订单,从而使矿工的平均成本基数为 X。矿工构建他们的区块,以便他们的市价买入订单紧接在区块中Alice的市价买入订单之前。结果,当Alice的市价买入订单执行时,她以 X+1 的成本基数收到 Asset ABC。在同一个区块中,矿工然后在区块中Alice的市价买入订单之后立即下达等额的 AMMSwap Asset ABC 市价卖出订单,从而获得Alice的买入订单赋予 Asset ABC 的“+1”流动性 。最终结果:Alice为 Asset ABC 支付了比她原本应该支付的更多的钱,并且矿工无风险地赚取了 +1 的利润。

MEV 正在应用于各种不同的场景,包括套利、清算、削减惩罚、代币销售等等。鉴于在支持高级金融合约的区块链上发生的所有 MEV,并且鉴于有效性Rollup能够使在比特币上构建的 L2 Rollup 中使用此类合约,也许比特币社区在实现对比特币上的有效性Rollup的支持之前要考虑的最相关的问题是:比特币上的有效性Rollup是否会产生原本不存在的 MEV 机会?如果是这样,MEV 机会的产生是否会削弱比特币 L1 的安全性?

尽管可以使用嵌入式共识层(例如 CounterParty 和 Omni)甚至使用离散日志合约的本地比特币在比特币上构建金融智能合约,但这种用法的普及程度不如以太坊、BSC、Solana 等其他区块链。[^117] 如果在比特币协议中启用了对有效性Rollup的支持,则可能会解决阻碍比特币上金融智能合约开发和采用的任何缺点,从而增加 MEV 在比特币上发生的可能性。

要回答比特币上的有效性Rollup是否会创造新的 MEV 机会的问题,我们首先必须明确我们要在比特币上启用哪种有效性Rollup。可以通过限制比特币完整节点需要验证的有效性证明中可以表示的信息量来限制可以在比特币上构建的有效性Rollup支持的脚本功能的表达能力。如果比特币社区愿意,他们可以将有效性Rollup限制为不比(或没有多大)比特币今天的表达能力更强。这很可能不会导致在 L2 上引入任何新的 MEV 机会。

比特币社区还可以决定在比特币上构建表达能力更强的有效性Rollup。也许这些Rollup的表达能力足以支持容易受到 MEV 攻击的合约类型。在这种情况下,将在比特币上创建新的 MEV 机会。这些 MEV 主要由 L2 上的 Rollup 区块生产者捕获。由于比特币的区块时间很长,L1 矿工试图重新组织区块以便从 L2 捕获一些 MEV 的风险相对较高,因为挖掘区块的成本很高。即使在区块时间相对较短的以太坊等区块链上,也没有关于矿工重新组织 L1 区块以捕获 L2 上的 MEV 的报告。L2 Rollup 过渡到去中心化区块生产后,这种情况如何变化或是否会发生变化还有待观察。

在为本报告进行访谈时,有几位开发者和研究人员被问及此事,共识是比特币有效性Rollup上的 MEV 可能会由于 MEV 机器人产生的交易量增加而导致 L1 交易费用增加,但除此之外,L1 用户不会受到 MEV 的影响。熟悉此事的人士指出,L2 Rollup 对 L1 以太坊用户没有负面影响,这证明了为什么 L1 比特币用户也可能不会受到构建在比特币上的 L2 Rollup 的负面影响。但是,鉴于 L2 Rollup 是以太坊上相对较新的现象,因此需要更多的时间和研究来更好地了解 L2 上的 MEV 与 L1 上的共识安全和激励措施之间的相互作用。

即使在 L2 上没有启用新的 MEV 形式,根据有效性Rollup在比特币上的实现方式,仍然可以在 L1 上启用新的 MEV 形式。如果使用递归 covenant 在比特币上启用有效性Rollup,则递归 covenant 可用于在 L1 上构建新型的易受 MEV 攻击的协议。例如,去中心化交易所协议 BitMatrix 是一种使用递归 covenant 构建的恒定产品做市商协议。[^118] BitMatrix 最初是为 Liquid 区块链设计的,该区块链支持递归 covenant,并且还支持机密资产,因此使 BitMatrix 交易能够抵抗 MEV。比特币在 L1 上不支持机密资产,如果将 BitMatrix 的版本部署到启用递归 covenant 的比特币 L1,则会产生 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) 攻击,在比特币上添加对有效性Rollup的支持可能会产生意想不到的负面副作用,而不是 MEV。[^121] AIM 攻击使用智能合约来激励矿工攻击彼此或特定用户,从而破坏中本聪共识的正常激励。本节将介绍一些可以使用足够表达能力的有效性Rollup在比特币上构建的 AIM 合约的示例。这不是此类合约的详尽目录。同样值得注意的是,即使无法直接在比特币上构建 AIM 合约,AIM 攻击也是可能的。[^122] 最重要的是,与在比特币上启用更具表达能力的脚本功能以及建立在比特币上的新层(例如有效性Rollup)相关的风险是已知和未知的(未知风险本身可能是风险)。

TxWithhold 合约

AIM 智能合约的一个例子是“TxWithhold”合约。在一篇 BitMEX Research 文章中,Gleb Naumenko 描述了如何使用 covenant 来构建智能合约,该智能合约激励矿工扣留(即不确认)交易一定数量的区块。[^123] 如第 5 节中所述,在比特币上构建有效性Rollup的一些设计需要使用递归 covenant 。即使启用的 Rollup 在功能上相对有限,例如,其表达能力不比亚于今天比特币的表达能力,但是通过在 L1 上为这些类型的有效性Rollup 启用递归 covenant ,某些 TxWithhold 合约也可能实现。这些类型的 TxWithhold 合约实际上会造成多少危害是一个需要进一步研究的领域。

重组战争

如果比特币上的有效性Rollup支持足够表达能力的智能合约,则可以使用它们来煽动“重组战争”,在这种情况下,智能合约会相互竞争,以激励和阻止矿工重组区块链。[^124][^125] 在以太坊 L1 上使用“HistoryRevision 合约”表明了这种类型的 AIM 攻击是可能的。[^126] 目前尚不清楚部署到 L2 的此类合约是否会对 L1 产生相同的影响,或者 是否 有可能,但仅在 特定条件下 才会产生相同的影响(例如,两个层上的区块生产者严重重叠)。即使 L2 上的此类重组合约会对 L1 产生相同的影响,但是如果它们既可以激励也可以阻止重组,那么也许它们会相互抵消,并且不会造成任何危害。同样,这是一个需要进一步研究的领域。

大多数易受攻击的合约

研究人员已经详细讨论了一类智能合约的积极用途,但是可以说其潜在危害尚未得到充分探索,该合约是“SPV 桥”(也称为“哈希率托管”)和类似的“乐观”智能合约类别。[^127][^128] SPV 桥和乐观合约在此统称为“大多数易受攻击的合约”,因为这些合约的用户信任大多数区块生产者(通过用于保护进入区块生产者集的任何 Sybil 保护资源来衡量,例如哈希算力、权益、身份等)不会窃取合约中持有的资金。

明显的风险是,大多数易受攻击的合约会启用 AIM 攻击,这可能导致用户被区块生产者抢劫。可能更令人担忧的是一种更微妙的风险:大多数易受攻击的合约的存在和使用会激励区块生产者串通起来实施盗窃,从而使大多数易受攻击的合约可能对区块链本身的安全性有害。通过创建串通起来形成“不诚实”多数的动机,否则这种动机本不应该存在,因此可以认为大多数易受攻击的合约直接破坏了中本聪共识的诚实、正确、激励兼容的运作。

如果大多数易受攻击的合约使用与 L1 不同的区块生产者集,例如在有效性Rollup中实施的哈希率托管合约使用不同的矿工集来保护哈希率托管,那么在比特币 L2 上存在大多数易受攻击的合约可能对 L1 比特币用户来说不是什么大问题。但是,如果用于在比特币上添加对有效性Rollup支持的实现路径在 L1 上启用了新型的大多数易受攻击的合约,那么比特币社区可能需要考虑大多数易受攻击的合约带来的潜在风险是否值得这种特定实现路径的好处。例如,ZmnSCPxj 指出递归 covenant 可用于在比特币上构建哈希率托管合约。[^129] 因此,如果使用递归 covenant 在比特币上实现了对有效性Rollup的支持,那么比特币社区将需要考虑他们是否也希望启用 L1 哈希率托管合约。

经验观察表明,尽管存在大多数易受攻击的合约,但区块生产者尚未串通起来进行盗窃,这表明存在一些其他的激励措施或阻碍措施阻止他们进行盗窃。[^130] 也有可能只是尚未达到一个临界点,而这些合约最终激励的勾结和盗窃只是时间问题。通过足够表达能力的智能合约功能,可以创建一个 AIM 合约,该合约自动将盗窃所得从大多数易受攻击的合约分配给参与攻击的区块生产者,从而降低风险和协调成本,并可能增加尝试和成功进行攻击的可能性。由于大多数易受攻击的合约已经部署到生产环境中,因此只有时间才能证明它们是否确实对其托管网络构成威胁。

第 6.5 全自动极权主义 <sup id="section-65-fully-automated-totalitarianism"></sup>

在这里,我们再次引用第 5 节中需要使用递归 covenant 的Rollup设计。递归 covenant 的决定性特征在于,它不仅定义了 covenant 脚本中锁定的 UTXO 可以在何种条件下被花费,而且还定义了 UTXO 在被花费后可以被何种类型的脚本所束缚(因此得名“递归” covenant)。从理论上讲,一个递归 covenant 可以要求一个 UTXO 永远锁定在同一种限制性脚本中,无论 UTXO 被花费多少次。

一些评论员引用了递归 covenant 启用的递归限制作为推迟在比特币中实施 covenant 的理由。[^131][^132] 他们指出,极权主义政府可能会利用这种能力来迫使其管辖范围内的比特币用户将其 BTC 锁定到递归 covenant 中,政府已在其中永久性地对其 BTC 进行了编程控制。虽然这确实在技术上可以通过递归 covenant 来实现,但这只是实施此类控制的一种方式。

目前,各国政府可以使用一种已经成为比特币标准十多年之久的智能合约:多重签名,来对公民拥有的 BTC 的转移方式实施限制,并且比递归 covenant 允许的方式更加灵活。[^133] 基本思想是,政府将要求其公民拥有的 BTC 受到多重签名脚本的约束,该脚本需要来自政府控制的私钥和实际所有者的私钥的签名,才能将 BTC 转移到另一个地址。在政府共同签署交易之前,控制政府私钥的计算机会检查以确保交易遵循了在政府计算机上存储的普通文本文件中以离线方式定义的转移策略。如果交易符合此转移策略,则政府计算机将共同签署该交易。如果交易不符合转移策略(例如,试图将 BTC 转移到政府未批准的地址),则政府计算机将不共同签署交易,并且该交易将被有效阻止。如果政府想要更新其转移策略以添加或删除限制,则只需更新定义该策略的离线文本文件即可。

在 Blockstream AMP 中可以找到一个工作示例,展示了如何使用多重签名来实现转移限制,Blockstream AMP 是 Blockstream 公司开发的一个平台,用于支持在 Liquid 区块链上托管发行和转移资产。[^134] 尽管 Liquid 区块链已经支持递归 covenant,但 Blockstream 仍然决定使用多重签名来实现转移限制。Blockstream 在其文档中解释说,在智能合约级别实施的转移限制“非常难以适应全球快速变化的法规”。[^135] 相比之下,“Blockstream AMP 通过一个简单的多重签名授权者设置来实现转移限制,为 [用户] 提供了灵活性,以适应不断变化的法规。”[同上]

使用多重签名以离线方式实施支出限制将使政府能够随时更改限制并使限制尽可能复杂。如果政府使用递归 covenant 直接在智能合约中实施限制,那么他们的限制将受到比特币 Script 的大小限制和功能的限制。允许更改转移限制的可能性,以反映离线政府政策的不可避免的变化,将需要额外的脚本复杂性。如果将对递归 covenant 的支持添加到比特币中,并且政府想要对其公民如何转移其 BTC 实施极权主义控制,那么他们更有可能使用多重签名而不是递归 covenant 实施此类控制,这是因为离线转移策略提供了灵活性。

有些人可能会争辩说:是的,虽然多重签名可能更灵活,但递归 covenant 很可怕,因为它们可以用来将 BTC 永远锁定到脚本中;至少对于今天的多重签名实现而言,BTC 理论上可以离开多重签名脚本。将 BTC 永远锁定到脚本中的可能性仍然不是一种新的风险。Anthony Towns 指出,可以使用燃烧证明来燃烧 BTC 并在嵌入式共识协议(类似于在比特币上如何创建 XCP)或专用 Spacechain 中铸造一些数量的 govt-BTC。[^136] 一旦被燃烧,govt-BTC 将永远无法转换回 regular BTC,并且将永远被锁定到政府的转移限制中,无论它们是如何实施的。

这里的主要要点是,与普遍的看法相反,从实际的角度来看,在政府强制转移限制方面,递归 covenant 不会引入任何新的风险。多重签名已经用于启用此类转移限制,并且 XCP 风格的燃烧证明可用于不可逆转地将 BTC 锁定到此类转移限制中。可能有合理的、充分的理由反对在比特币上启用递归 covenant;它们被用于实施政府强制转移限制的能力不是其中之一。

第 6.6 挑衅专制主义者 <sup id="section-66-provoking-authoritarians"></sup>

虽然比特币本身的存在是对试图控制他人如何赚钱、储蓄和花钱的专制主义者的挑衅,但有效性Rollup可能会为比特币增加全新的挑衅维度。

私人支付

屏蔽交易将使点对点交易像物理现金一样具有几乎一样的隐私性和不可追踪性。在某些情况下,由于可以在线进行远程、匿名互动,屏蔽交易可能比物理现金更具隐私性和不可追踪性。这将使生活在专制政权(在其政府或在其家庭中)下的人们能够私下赚钱和花钱,使用小型计算设备上的隐藏钱包,该设备要么不会引起怀疑,要么比实物现金更容易隐藏。

各国政府已经开始打击为加密资产用户提供隐私保护的协议的使用。日本和韩国政府已经有效地禁止交易几种已经实施隐私协议的特定加密资产,例如 DASH、XMR 和 ZEC。[^137][^138] 最近,韩国监管机构已向交易所施压,要求其在 Litecoin 社区实施对选择加入 Mimblewimble 扩展区块协议的支持后将其下架 LTC。[^139] 奇怪的是,尽管比特币和以太坊都支持具有与 DASH(在比特币的 coinjoin 实现的情况下)和 ZEC(在以太坊上的 Aztec 等屏蔽协议的情况下)具有相似特征的选择加入隐私协议,但 BTC 和 ETH 仍然可以在韩国进行交易。尽管 BTC 和 ETH 已经逃脱了在这些管辖区被禁止的命运,尽管它们支持与几种被禁止的加密资产几乎相同的隐私协议,但这种好运可能不会永远持续下去。例如,如果比特币开发者要在比特币上构建具有强大隐私性的有效性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] 即使这些分析是正确的,这并不意味着在未来不会对区块链隐私协议发动其他更强大的法律攻击,尤其是在与美国相比拥有较少的言论自由或法治保护的管辖区中。虽然对隐私协议用户的攻击可能仍然集中在应用层,但某些政府可能会将他们的斗争带到区块生产者和共识层。比特币旨在抵御此类攻击,但尽管如此,比特币开发者和社区成员将不得不决定,提示此类攻击的风险是否值得通过构建在比特币之上的有效性Rollup增加强大的、无需信任的隐私所带来的优势。

为更自由的未来提供资金

抗审查的智能合约提供了不受专制控制的金融许可访问权限,使企业家能够为其企业筹集资金,使活动家能够为其运动提供资金,并使受压迫的少数群体能够绕过专制主义者强加在他们生活中的金融控制。控制金融就是控制经济和人民生计的很大一部分。为金融活动提供中立的、可编程的、全球可访问的基础设施,可以使受专制主义者压迫的人们能够建立财富并为一个更自由的未来为其自身及其社区提供资金。

真正的言论自由

去中心化域名系统为网站提供了抗审查的难忘身份。当与用于支付 Bittorrent 或 IPFS 等去中心化文件共享协议上的文件主机的屏蔽的 BTC 结合使用时,就有可能创建几乎不可能被删除的网站。在活动家和记者因其发布的信息而成为攻击目标的社会中,这可能成为专制主义者的一根真正的眼中钉。

成为(一个强大且私有的智能合约平台)还是不成为......

为人们提供对抗专制主义者的新工具是一件好事。风险是这些强大的新工具会引起人们对比特币的更多负面关注。就自由与专制主义而言,反专制主义的比特币社区可能愿意说,“放马过来吧”。但是,有效性Rollup启用的这些强大的新工具也可以用于有害的目的。正如私人支付可以被某人用来逃避其虐待家庭伴侣的窥探一样,私人支付也可以用于促进不可追踪的赎金支付。正如抗审查网站可用于托管令人不安的政治真相一样,它也可用于托管伤害无辜人民的非自愿材料。比特币社区已经不得不处理这些类型的担忧,但有效性Rollup 可能会进一步放大它们。[^146][^147]

这是另一个问题,如果启用有效性Rollup,比特币社区将不得不决定究竟要启用 哪种类型 的 Rollup:比特币社区是否邀请发布 L2 上的潘多拉魔盒的全部内容,或者比特币用户是否永远不应该被允许以一种无需信任的方式访问某些功能或智能合约?我是这样措辞这个问题的,并强调“无需信任”,因为直接在比特币上支持这些强大且有争议的用例(通过 L1 扩展或作为 L2 上的新协议)的替代方案并不是这些用例将永远不会发生,并且将避免来自此类用例的所有风险和危害。替代方案是现状,比特币用户必须放弃对其 BTC 的控制权以信任的“桥梁”换取侧链或山寨币链上的 IOU,在这些侧链或山寨币链上,这些用例实际上得到了支持。[70] 关于这个问题,摆在比特币社区面前的选择不是 风险无风险,而是在 没有受信任的第三方/具有较少受信任的第三方 的情况下承担风险,或者在 具有受信任的第三方/更多受信任的第三方 的情况下承担风险。

第 6.7 新型密码学 <sup id="section-67-novel-cryptography"></sup>

有效性证明中使用的密码学的新颖性或“林迪”因子取决于所指的有效性证明种类。[^148] 基于 STARK 的有效性证明依赖于最古老的密码学原语,并且具有各种有效性证明系统中最弱的安全假设。基于 SNARK 的有效性证明依赖于更新的密码学原语,例如椭圆曲线(如比特币中)并且具有更强的安全假设。[^149]

图 9. 密码学证明族谱 - 年龄和密码学假设

```![crypto-family-tree](https://img.learnblockchain.cn/2025/07/13/186959627-1f09a5d3-a4d5-4d06-980b-bd0791bd1543.png)

> 图片来源:[^149]

另一个考虑因素是给定有效性证明实现的实施时间和“实战考验”。随着最早的生产实现已经有几年的历史(大约与集成到比特币核心中的 Schnorr 算法实现一样古老),有几种有效性证明系统可以被使用,或者至少可以从中获得灵感。[^150] 也就是说,在密码学证明协议的一些生产实现中已经发现了漏洞。[^151] [^152] 每次在给定的密码学证明实现中发现此类漏洞时,该实现的“林迪时钟”都会重置为零。

虽然加密货币在生产中使用的最古老的有效性证明和 Schnorr 协议的实现现在年龄相仿,但有效性证明实现所基于的**协议设计** 与 Schnorr 签名算法相比相对较新。这意味着有效性证明设计的审查时间较短。我们可以普遍预期,如果协议设计中存在漏洞,那么随着时间的推移以及协议收到的审查数量的增加,发现漏洞的可能性也会增加。例如,在 2018 年对 Zcash 的 "Sprout" 密码学证明协议的细节进行审查时,Ariel Gabizon 发现了一个关键的设计缺陷,该缺陷本可能使攻击者能够无法察觉地伪造受保护的币。[^153]

在生产密码学证明系统的设计和实现中发现的漏洞表明,在将此类系统部署到比特币等区块链中时,需要更加谨慎,投入更多时间、审查和测试,因为在没有共识级别的软件更新的情况下,可能无法修复漏洞。密码学证明协议中的漏洞会使协议保护的币面临风险,要么导致有效性证明在应该成功验证时未能通过验证(有效地冻结了受证明协议保护的资产),要么导致有效性证明在应该失败时成功验证(使攻击者能够伪造和/或窃取受证明协议保护的资产)。

&lt;h3> 第 6.8 节 泄露的“有毒废料” &lt;sup id="section-68-compromised-toxic-waste">&lt;/sup>&lt;/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)。

&lt;h2> 结论 &lt;sup id="conclusion">&lt;/sup>&lt;/h2>

[↩](#toc)

在本报告中,我们描述了有效性 rollup 的历史、它们的工作原理以及如何在比特币上构建它们。我们描述了即使在其最简单的形式下,有效性 rollup 也可以在比特币上实现超过 100 倍的交易吞吐量,与在比特币 L1 上进行交易的所有权安全相比,有效性 rollup 用户的所有权安全没有任何损失。然而,如此大的吞吐量增加并非免费获得。虽然有效性 rollup 不一定会增加 L1 完整节点的验证成本,但根据实现细节,由于 rollup 有效地利用 L1 区块空间,rollup 交易可能比今天的比特币交易更容易更频繁地将 L1 比特币区块填充到其最大容量,这可能会导致 L1 完整节点区块链存储成本的增加。考虑到所有因素,鉴于有效性 rollup 在设计上是“无需信任”的,并且可以在不引入新风险或牺牲比特币任何核心价值或功能的情况下实现,我们认为最简单的有效性 rollup 实现非常适合比特币。

可选地,在比特币上实现有效性 rollup 还可以支持验证更强大的有效性证明。这将为比特币用户启用新功能,例如支持更具表现力的智能合约和更强大的隐私协议。根据实施对这些更强大的有效性证明的支持方式,可以在几乎不增加 L1 完整节点运行成本的情况下启用这些新功能。但是,这些新功能也可能带来新的风险,例如启用新型 AIM 和 MEV 攻击,以及可能引发专制政府对比特币的镇压,这些政府可能反对这些协议启用的强大隐私和抗审查应用程序。每一个新功能以及随之而来的风险都应单独进行审查,每个功能都有自己的成本效益风险回报分析,以确定它们是否值得在比特币上启用,即使是在 L2 上的有效性 rollup 中。本报告中介绍或引用了一些对此类问题的分析,但不应将其视为对此问题的最终结论。这些领域值得更多的研究、实验和观察。

&lt;h2> 附录 A. 将有效性 rollup 与其他协议进行比较 &lt;sup id="appendix-a-comparing-validity-rollups-to-other-protocols">&lt;/sup>&lt;/h2>

[↩](#toc)

有效性 rollup 是一项长达十年之久的协议历史的一部分,该协议旨在提高基于区块链的数字资产和智能合约的可扩展性和功能。

我们可以在 [表 5](#table-5-protocol-comparison-table) 中看到有效性 rollup 如何通过链上数据可用性和有效性证明的独特组合进行设计,从而使它们没有通道或面额限制,并且所有权安全等于其父链的所有权安全。另请参阅 Gudgeon 等人在其 2019 年 4 月的论文“SoK: Layer-Two Blockchain Protocols”中进行的类似比较(不包括 rollup)。[^157]

&lt;h4> 表 5. 协议比较表 &lt;sup id="table-5-protocol-comparison-table">&lt;/sup>&lt;/h4>

| 协议                   | 子类别                     | 桥接安全模型        | 数据可用性                          | 通道/面额限制    | 单方面退出 | 父链矿池可以窃取* |
| ----------------------- | :---------------------------: | :-------------------: | :------------------------------------: | :------------: | :----------: | :-------------------: |
| CoinWitness            |                               | 托管式或联盟式      | 链下(自我托管)                    |      否      |     是     |         是         |
| 状态通道 [a, b]        |                               | 故障证明             | 链下(自我托管)                    | 是(通道)      |     是     |         是         |
| 状态链 [c]             |                               | 半托管式           | 链下                                | 是(面额)      |     是     |         否         |
| Plasma [d]             |                               | 故障证明             | 链下(自我托管)                    |      否      |   可能**   |         是         |
| Rollup                  |                               |                     |                                     |                |              |                     |
|                        | 有效性 rollup [e]           | 有效性证明           | 链上                                |      否      |     是     |         否         |
|                        | 乐观 rollup [f]           | 故障证明             | 链上                                |      否      |     是     |         是         |
| Validia 链***         |                               |                     |                                     |                |              |                     |
|                        | Adamantium [h]              | 有效性证明           | 链下(主要),链上(备用)          |      否      |     是     |         否         |
|                        | Validium [g]                | 有效性证明           | 链下                                |      否      |    可能    |         否         |
|                        | Validity valutia [i]        | 有效性证明           | 链下(有抵押的数据保管人)          |      否      |    可能    |         否         |
|                        | Volition [g]                | 有效性证明           | 链上或链下(用户配置)              |      否      |    可能    |         否         |
| 乐观 valutia [j]     |                               | 故障证明             | 链下(有抵押的数据保管人)          |      否      |    可能    |         是         |
| Softchain [k]          |                               | 工作量证明故障证明 | 链下                                |      否      |     是     |         是         |
| 侧链 [l]               |                               |                     |                                     |                |              |                     |
|                        | 乐观侧链 [m]              | 故障证明             | 链下                                |      否      |     是     |         是         |
|                        | Drivechain [n]              | 哈希率托管           | 链下                                |      否      |     是     |         是         |
|                        | 有抵押的侧链 [o]           | 有抵押的多重签名   | 链下                                |      否      |     否     |         否         |
|                        | 联盟侧链 [p]              | 联盟多重签名         | 链下                                |      否      |     否     |         否         |
|                        | 中心化侧链 [q]            | 托管式               | 链下                                |      否      |     否     |         否         |
|                        | Zendoo [r]                  | 有效性证明           | 链下,有链上检查点                    |      否      |   可能**   |         否         |

> 表 5 注释:
> [ * ] 此处“父链矿池可以窃取”指的是这样一种观点,即如果足够多的父链区块生产者(又名“矿工”)串通,那么他们可以在未经被盗用户合作的情况下(如果他们正在审查和勒索用户,则需要这样做)或无需重新组织父链区块(如果他们正在对用户进行双花攻击,则需要这样做)从该协议的用户那里窃取资金。另请参阅 &lt;a href="https://lightco.in/2021/06/21/miners-can-steal/" target="_blank">https://lightco.in/2021/06/21/miners-can-steal/&lt;/a>
>
> [ ** ] 此列中的“可能”指的是只有在必要的数据可供需要它来创建其提款交易的用户使用时,才有可能单方面退出。
>
> [ *** ] 有关 validia 链的更多详细信息,请参见 [附录 C](#appendix-c-increasing-throughput-with-offchain-data-availability)。

> 表 5 参考文献:
> [a] &lt;a href="https://lightning.network/lightning-network-paper.pdf" target="_blank">https://lightning.network/lightning-network-paper.pdf&lt;/a>
>
> [b] &lt;a href="https://l4.ventures/papers/statechannels.pdf" target="_blank">https://l4.ventures/papers/statechannels.pdf&lt;/a>
>
> [c] &lt;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&lt;/a>
>
> [d] &lt;a href="https://plasma.io/plasma.pdf" target="_blank">https://plasma.io/plasma.pdf&lt;/a> 注意:有 &lt;a href="https://medium.com/onther-tech/plasma-world-map-ba8810276bf2" target="_blank">多种 Plasma&lt;/a>,但它们都具有上表中描述的基本共同特征。
>
> [e] &lt;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&lt;/a>
>
> [f] &lt;a href="https://ethresear.ch/t/minimal-viable-merged-consensus/5617" target="_blank">https://ethresear.ch/t/minimal-viable-merged-consensus/5617&lt;/a>
>
> [g] &lt;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&lt;/a>
>
> [h] &lt;a href="https://ethresear.ch/t/adamantium-power-users/9600" target="_blank">https://ethresear.ch/t/adamantium-power-users/9600&lt;/a>
>
> [i] &lt;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&lt;/a>
>
> [j] &lt;a href="https://blog.celestia.org/celestiums/" target="_blank">https://blog.celestia.org/celestiums/&lt;/a>
>
> [k] &lt;a href="https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1" target="_blank">https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1&lt;/a>
>
> [l] &lt;a href="https://blockstream.com/sidechains.pdf" target="_blank">https://blockstream.com/sidechains.pdf&lt;/a>
>
> [m] &lt;a href="https://near.org/blog/eth-near-rainbow-bridge/" target="_blank">https://near.org/blog/eth-near-rainbow-bridge/&lt;/a>
>
> [n] &lt;a href="https://www.truthcoin.info/blog/drivechain/" target="_blank">https://www.truthcoin.info/blog/drivechain/&lt;/a>
>
> [o] &lt;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&lt;/a>
>
> [p] &lt;a href="https://www.rsk.co/Whitepapers/RSK-White-Paper-Updated.pdf" target="_blank">https://www.rsk.co/Whitepapers/RSK-White-Paper-Updated.pdf&lt;/a>
>
> [q] &lt;a href="https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf" target="_blank">https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf&lt;/a>
>
> [r] &lt;a href="https://arxiv.org/abs/2002.01847" target="_blank">https://arxiv.org/abs/2002.01847&lt;/a>

&lt;h2> 附录 B. 比较替代加密货币隐私技术 &lt;sup id="appendix-b-comparing-alternative-cryptocurrency-privacy-techniques">&lt;/sup>&lt;/h2>

[↩](#toc)

由于比特币的许多当前局限性(例如,有限的脚本功能)和品质(例如,透明的交易金额),减少比特币交易的可追踪性和提高隐私的努力始终是一场艰苦的斗争。为此目的构建的比特币协议的例子包括 Cahoots、CoinJoin、CoinSwap、PayJoin、TumbleBit、隐形地址及其变体或衍生产品。

比特币使隐私变得困难的最重要的弱点也许也被视为比特币最大的优势之一:交易金额的透明性质,即比特币的公共可审计性。由于比特币交易金额是透明的,并且在区块链上公开可见,因此它们可用于关联发送者和接收者,并将接收者地址与找零地址和自发送区分开来。[^158] [^159] 比特币隐私协议试图通过与其他一个或多个用户混合币以及创建等额输出来对抗这些启发法,以增加每个交易的匿名集。但是,如果混合中的任何参与者做任何事情来取消自己的匿名性,则他们会从匿名集中删除(有时其他混合参与者甚至不知道)。最终,匿名集可以减少到不大于单输出交易。[^160] 混合匿名集逐渐退化使得比特币隐私本质上是脆弱的,需要 Constant 费用(作为挖矿费用产生)通过重新混合或其他“混合后”隐私技术来维持匿名集的大小。

维护匿名集大小的成本,加上等待足够数量的用户混合等额输出以获得足够大的匿名集的要求,使得比特币隐私技术对于销售点交易或低价值交易来说不切实际。有理由希望像闪电网络这样的链下协议可以提供改进:因为闪电网络交易是链下的,交易的细节仅为支付通道路径上的每个节点所知,并且在某些情况下,只有部分交易细节为路径上的每个节点所知。原子多路径路由可以为闪电网络支付增加更多模糊性,因为路由节点不知道它们是路由全部支付还是仅路由部分支付。然而,这里启用的隐私充其量是概率性的,并且对于发送者和接收者来说都难以量化:可能的情况是,他们在路径上的交易对手对他们的支付知之甚少或一无所知。更不用说与余额探测和通道打开/关闭交易相关的隐私问题了。[^161] 就目前而言,闪电网络最好被视为一种快速且高吞吐量的支付解决方案,而不是一种隐私解决方案。(这将来可能会改变!)[^76]

研究人员已经研究了比特币隐私协议的缺点,并发明了他们认为可以为保护用户隐私提供重大改进的新协议。在这里,我们研究了三个最著名的替代隐私协议,并比较了每个协议揭示其用户的数据量,从而为比较它们的相对隐私改进提供了基础。

#### Grin

Grin 是 Mimblewimble 协议的第二个独立实现。虽然 Mimblewimble 确实有一些可以被认为是隐私改进的功能,例如隐藏交易金额的机密交易,以及可以从公共交易图中删除某些交易的非交互式交易截断,但在它们最简单的形式下,Mimblewimble 交易仍然揭示了构建公共交易图所需的所有信息。通过观察交易在点对点网络上的发送情况,观察者可以跟踪输入和输出,以构建币的来源和去向的图。由于这些原因,Mimblewimble 作为一种扩展解决方案最有效,而不是一种隐私解决方案。

##### 图 10. 以其最简单的形式显示的 Grin 交易

![figure10_vr](https://img.learnblockchain.cn/2025/07/13/186960781-6f0abb70-3efa-4670-863d-9cf1e79875cb.png)

> 图片来源:[^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. Monero 交易在 explorermonero.com 浏览器中的外观

![figure11_vr](https://img.learnblockchain.cn/2025/07/13/186961096-4d5c4718-36c6-4fc3-906c-2bc6058bfbd7.png)

> 图片来源:[^167]

#### Zcash

Zcash 是 Zerocash 协议的第一个实现。Zerocash 协议的定义隐私特征是使用 zk-SNARK 加密专门制作的“屏蔽”交易的金额、发送者和接收者,从而完全向公众隐藏这些详细信息。花费者不是指区块链中的特定公共帐户或透明的未花费交易输出,而是创建一个零知识证明,以说服网络完整节点发送者拥有并且因此可以花费一定数量的“notes”(未花费交易输出的加密等效项),并且加密输入的金额等于加密输出的总和加上透明的挖矿费用。[^168]

##### 图 12. Zcash 屏蔽交易在 zcha.in 浏览器中的外观

![figure12_vr](https://img.learnblockchain.cn/2025/07/13/186961677-5b858ee8-9d44-4208-8d9a-f456693c9581.png)

> 图片来源:[^169]

虽然 Zerocash 交易隐藏了所有已知技术中最大的交易信息,但仍然存在一些链上元数据泄漏,可用于取消交易的匿名性。例如,Zerocash 交易公开显示了交易中使用的输入和输出量。实际上,这已被证明足以取消 Zerocash 交易发送者的匿名性。[^170] 虽然此演示是人为设计的,并且有一种方法可以通过在将 notes 发送到最终目的地之前将它们合并在一起来缓解此攻击,并且匿名化风险会随着具有类似输入和输出 note 金额的交易越多而降低,模拟攻击表明了 Zerocash 确实揭示的少量元数据如何可用于取消用户的匿名性。因此,需要保持在屏蔽币交易时无法识别的用户(或用户的钱包)必须采取针对链上(和链下)元数据泄漏的对策。

#### 关于“选择退出”与“选择加入”隐私的说明

有些人可能会争辩说,在有效性 rollup 中实施的加密协议的“选择加入”性质降低了其使用者的隐私有效性,并且在 Beam 或 Monero 等区块链上的“选择退出”加密协议(其中加密“默认开启”,用户必须显式“选择退出”以删除加密)将始终提供更好的隐私,在所有其他条件相同的情况下。这是一种误解。实际上,没有纯粹的“选择退出”加密,因为**所有**协议,无论加密与否,最初都是“选择加入”的,不包括外部强制。人们通过选择下载 Monero 钱包并购买、接收或挖掘 XMR 来“选择加入”使用 Monero 加密其交易,就像人们通过下载兼容的比特币钱包并将透明 BTC 存入加密的有效性 rollup 或购买或接收加密的 BTC 来“选择加入”使用比特币上的加密有效性 rollup 一样。同样,加密的 BTC 用户可以选择永远不接触透明的 BTC,就像 Monero 用户可以选择永远不接触透明的 BTC 一样。在这两种情况下,人们首先“选择加入”加密协议,然后他们可以选择是否曾经想“选择退出”。在这些情况下,对最终用户的唯一有意义的区别是所涉及的记账单位。

&lt;h2> 附录 C. 通过链下数据可用性提高吞吐量 &lt;sup id="appendix-c-increasing-throughput-with-offchain-data-availability">&lt;/sup>&lt;/h2>

[↩](#toc)

有效性 rollup 旨在提高交易吞吐量,并可能提供替代执行环境,而不会放弃相对于直接在 rollup 的父链上持有资金和交易的安全性。正如[第 1 节](#section-1-an-introduction-to-validity-rollups) 中所解释的,这种高度的安全性是通过将有效性证明的使用与 rollup 交易数据存储在父链区块中相结合来实现的。有效性证明提供与父链接受的任何其他有效数字签名相同的 所有权保证,并且链上数据存储提供与存储在父链中的每个其他交易相同的数据可用性保证。

直接在其父链的区块中存储 rollup 的交易数据成本很高。如果父链是比特币主链,则该成本最直接地以每个占用主链区块空间的交易收取的 sats-per-vbyte 市场费用率来衡量。即使对 rollup 交易数据占用的空间的市场费用率打折 - 这种实现细节可能是合理的,因为这些交易仅由主链完整节点存储,而不是执行 - 如果主链区块空间的市场费用率相对较高,那么使用 rollup 的每笔交易成本也可能相对较高。此外,区块大小限制本质上限制了建立在比特币上的有效性 rollup 的交易吞吐量。

这就是 **Validia 链** 的概念发挥作用的地方。Validia 链是一种区块链,与 有效性 rollup 一样,通过使用由父链完整节点顺序验证的有效性证明来推进其状态,从而从父链继承避免双重支付的安全性。与有效性 rollup 不同的是,Validia 链不是专门使用父链来实现数据可用性,而是使用一个或多个链下数据可用性解决方案。此处的权衡是,吞吐量可以增加到超过比特币的区块大小限制 - 由于使用了更便宜的数据可用性解决方案,也可能会降低每笔交易的成本 - 但代价是数据可用性保证的确定性和安全性可能会降低。比特币可以通过实现足够灵活的 rollup 脚本以支持各种链下数据可用性解决方案,从而在添加对有效性 rollup 的支持的同时添加对这些 validia 协议的支持。这将为用户提供在高安全性但成本高的链上数据可用性或安全性较低但成本较低的链下数据可用性之间进行选择的机会。

到目前为止发明的 validia 链的变体是:
- Validium:链下非抵押数据可用性
- Validity 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]

#### Validity valutia

Validity valutia 是一种 validia 链,它依靠**抵押价值风险** 来激励数据保管人维护数据可用性。用户将锁定某些资产作为抵押品以换取承担数据保管人角色的权利,从而进入智能合约。然后,父链验证数据保管人的数据可用性证明,每次新的 valutia 状态更新时,就像使用 validium 一样。

如果在任何时候数据变得不可用,那么数据保管人的抵押品将被冻结,直到数据再次可用。冻结抵押品的威胁旨在保持数据保管人的诚实,并激励他们确保数据 valuum 用户单方面退出所需的仍可在需要时可用。

由于数据可用性是在链下提供的,因此预计存储 valutia 数据的成本将低于像使用 rollup 那样直接在父链上存储数据。与此同时,抵押价值风险应提供比 validium 的非抵押数据保管人更强的数据可用性保证。这为用户在成本和安全性的权衡空间中提供了一个额外的选择。

在 2021 年 4 月的一篇博客文章中,Matter Labs 提出了第一个 validity valutia zkPorter。[^172] Matter Labs 提出的设计使用以太坊作为结算层,并使用 zkSync 代币权益质押者的网络来实现数据可用性。在 2022 年 2 月的一篇博客文章中,Celestia Labs 提出了一个类似的 valutia 设计,称为 Celestium,它可以与有效性证明或故障证明保护的桥接器一起使用。[^173] Celestia Labs 提出 Celestiums 将使用以太坊作为结算层,并使用一个单独的区块链 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 模式,那么他们单方面退出该意志所需的数据会像有效性 rollup 一样存储在父链区块中。如果用户选择 validium/valutia 模式,那么数据会使用该意志配置的任何链下数据可用性解决方案来存储。

意志提供的每个交易的可选性意味着用户可以根据给定的应用程序定制其交易的安全性和成本。对于低风险的应用程序,如娱乐游戏或低价值支付,可以使用 validium/valutia 模式。对于高风险的应用程序,如稀有艺术品收藏或高价值交易,可以使用 rollup 模式。为了降低决策成本,应用程序可以根据交易的价值或上下文建议使用哪种模式,甚至可以根据用户可配置的设置自动为用户做出决定。

StarkWare 在其 2020 年 6 月的帖子“Volition and the Emerging Data Availability Spectrum(意志和新兴的数据可用性范围)”中首次描述了意志[^171]。zkPorter 是第一个被提议的意志实现[^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          | 链下数据(抵押、非抵押或自我托管),具有回退到父链的提款                                                  |
| 有效性侧链           | 链下数据,带有链上检查点                                                                                     |
| 抵押意志             | 链上或链下数据(抵押)                                                                                    |
| 有效性 Valutia       | 链下数据(抵押)                                                                                       |
| 非抵押意志          | 链上或链下数据(非抵押)                                                                                  |
| Validium            | 链下数据(非抵押)                                                                                        |

> 表 6 描述:根据使用的数据可用性解决方案对有效性桥进行分类。按从最多到最少的安全性排序,这是作者的拙见。灵感来自 Brand 等人在 [^171] 中的表格。链上结算 + 链上数据可用性是一种有效性 rollup,可提供最强大的安全保证。链上结算 + 链下数据可用性为数据可用性开辟了多种选择,最终用户可以考虑不同程度的成本和安全性。有关有效性侧链的更多信息,请参见 [附录 D](#appendix-d-a-closer-look-at-validity-sidechains)。

&lt;h2> 附录 D. 进一步了解有效性侧链 &lt;sup id="appendix-d-a-closer-look-at-validity-sidechains">&lt;/sup>&lt;/h2>

[↩](#toc)

在 Back 等人 2014 年 10 月的论文《使用锚定侧链实现区块链创新》中,作者将锚定侧链定义为:

> 一种侧链,其资产可以从其他链导入并返回到其他链;也就是说,一种支持双向锚定资产的侧链。[^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% 的攻击者能够从他们获得哈希算力多数的那一刻起**绝对**控制区块链的内容,因此可以肯定的是,他们可以阻止交易被确认,直到“诚实”的多数重新获得控制权。因此,实际上,只要比特币依赖 Nakamoto 共识来保证安全并且扣留交易的行为不受惩罚,要求 (2) 就不可能得到满足。

另一种满足要求 (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/block) |
| ------------------------------ |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------:|
| Rollup 1 输入 2 输出 UTXO     | 有效性证明、脚本、其他交易数据                                                                                                                                                           | 26,432 txs (113.5 WU/tx)                                                                                                                                                    | 26,432        |
| Zendoo 1 输入 2 输出 UTXO     | 有效性证明、脚本、其他交易数据                                                                                                                                                           | 100,000 txs (106,000 WU/bit vector)                                                                                                                                           | 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 区块可以容纳大约 25 个 154,000 WU Zendoo 状态更新,每个 L1 区块最多可容纳 2,500,000 笔交易。

&lt;h2> 附录 E. 通过有效性证明实现额外的吞吐量增加 &lt;sup id="appendix-e-enabling-additional-throughput-increases-with-validity-proofs">&lt;/sup>&lt;/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 交易量增加的带宽成本和传播时间,例如通过实施或进一步优化诸如紧凑区块中继和 Erlay 之类的协议,即使交易量增加,也可以降低带宽要求[^182][^183]。而且无法避免对区块链数据进行存储的要求,这会随着区块链规模的增长而增加。尽管如此,少解决一个问题(IBD 问题)是一个不错的改进。最好的是,无需任何共识规则更改即可实施和开始使用证明同步客户端。截至撰写本文时,有两个项目正在致力于构建用 Cairo 编写的证明同步比特币客户端实现,一个名为 Khepri,另一个名为 Zerosync[^184][^185]。

&lt;h2> 附录 F. 减轻受损的密码学证明协议和有害废物造成的危害 &lt;sup id="appendix-f-mitigating-harm-from-compromised-cryptographic-proof-protocols-and-toxic-waste">&lt;/sup>&lt;/h2>

[↩](#toc)

在讨论为比特币实施密码学证明以实现隐私的想法时,经常提出的一个担忧是意外通货膨胀的可能性。如果有人在用于隐私协议的密码学中发现了这种漏洞,他们可以利用该漏洞来铸造任意数量的 BTC。此外,由于使用隐私协议的交易以某种方式加密,因此在一段时间内无法检测到通货膨胀。这种担忧源于基于密码学证明的加密货币隐私协议设计中的一个基本权衡:密码学证明可以是完全隐藏的,也可以是完全绑定的,但不能两者兼得[^186]。这种权衡意味着协议设计者必须要么允许资金供应通过伪造来膨胀,但如果密码学被破坏,则保持隐私(完全隐藏),要么保持资金供应的完整性,但允许隐私被破坏(完全绑定)。加密交易的产品实现,包括 [附录 B](#appendix-b-comparing-alternative-cryptocurrency-privacy-techniques) 中介绍的实现,通常设计为完全隐藏的。

当使用计算证明进行交易验证而不是交易隐私时,也存在同样的风险,例如验证未加密的 rollup 交易。如果密码学证明被破解,那么任何利用该漏洞的人都将能够伪造证明,从 rollup 中提取资产,即使他们没有私钥来根据 rollup 账本控制这些地址。在这种情况下,可以立即检测到伪造,但如果 L1 完整节点和矿工没有采取行动来阻止伪造的证明在 L1 上得到确认,仍然可能造成灾难性的危害。

在比特币上的有效性 rollup 的上下文中,减轻这些密码学漏洞造成的危害的主要因素是有效性 rollup 是可选的。因此,只有存储在有效性 rollup 中的 BTC 用户才会受到密码学证明漏洞利用在技术层面的影响。比特币 L1 的共识规则可以阻止攻击者从 rollup 中提取超过最初存入的 BTC,从而保持 L1 资金供应的完整性。

有些人可能会认为,由于存在无法检测到的通货膨胀的可能性,在比特币上构建加密的有效性 rollup 将威胁到资金供应的完整性。实际上,发生的任何意外的、无法检测到的通货膨胀都可能被隔离到加密的 rollup 中,以便完全可审计的“透明”BTC 供应保持完整。如上所述,比特币共识规则可以防止从加密的 rollup 中提取超过存入的 BTC,从而确保加密 rollup 之外的资金供应的完整性得到维护。

因此,如果你不想担心因为有人利用通货膨胀漏洞并从 rollup 中提取了最大可用余额而持有毫无价值的加密 BTC,你可以将所有 BTC 保留在完全可审计的透明 BTC 层中。如果你愿意冒险保留一些用于消费的加密 BTC,以便你可以进行具有强大隐私的交易,但又想保持其余 BTC 的透明性,这样你就不会将你的储蓄置于无法检测到的通货膨胀的风险中,那么你也可以这样做。如果你根本不担心通货膨胀漏洞,或者发现隐私收益值得冒险,你可以根据需要将所有 BTC 加密。加密的 rollup 为你提供了几种选择,具体取决于你的风险承受能力。

在此需要注意的是,加密协议中无法检测到的通货膨胀**已经成为可能**,因为已经存在加密协议,其中与 BTC Hook的加密资产的供应量存在通货膨胀漏洞的风险。例如,如果存在已利用的通货膨胀漏洞,Liquid 上的 L-BTC 和 Aztec 上的 renBTC 都可能意外地且无法检测地膨胀[^187][^78]。为了本次讨论的目的,这些现有加密协议与有效性 rollup 之间唯一相关的区别在于,使用 L-BTC 和 renBTC,比特币用户必须信任第三方来保管他们的 BTC,而有效性 rollup 在设计上是自我托管的。由于担心无法检测到的通货膨胀而反对在比特币上实施加密的有效性 rollup 的人所能达到的结果不是阻止用户将他们的 BTC 置于通货膨胀漏洞的风险中,而是阻止用户以**自我托管的方式**这样做,而是将 BTC 转移到受信任的托管人的控制之下——这就是行动中意想不到的(?)后果[^188]。

&lt;h2> 许可证 &lt;sup id="license">&lt;/sup>&lt;/h2>

[↩](#toc)

本报告中所有原创作品的版权和相关权利均已通过 [CC0](https://github.com/john-light/validity-rollups/blob/fecc3433d8e95ab40263db8c2941794e0115d2d5/LICENSE) 放弃。
本报告中引用的第三方制作的所有作品的版权和相关权利仍归各自的权利持有人所有。

&lt;h2> 参考文献 &lt;sup id="references">&lt;/sup>&lt;/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/fecc3433d8e95ab40263db8c2941794e0115d2d5/validity_rollups_on_bitcoin.md)
>- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
john-light
john-light
江湖只有他的大名,没有他的介绍。