概述

简介

这篇文章是对先前关于隔离见证的好处文章的补充,概述了通过BIP141激活隔离见证可能产生的技术成本和风险。

目标

为了便于理解,我们用成本来描述如果隔离见证被部署和激活,必然会发生的负面结果,而风险则描述可能不会发生,或者并非所有人都认为是负面变化的负面影响。

在分析风险时,我们考虑采取的避免风险的措施(即,最大程度地减少风险发生的可能性),以及采取的缓解风险的措施(即,如果风险发生,如何最大程度地减少负面影响)。

这篇文章并没有试图得出结论,即好处是否大于成本,或者隔离见证是否应该被部署或激活,而是通过提供背景信息来帮助利益相关者做出明智的决定。

序列化成本

交易和区块信息被序列化用于三个主要目的

  1. 通过对等网络传输;

  2. 将区块链存储在磁盘上;以及

  3. 评估区块限制。

隔离见证以两种方式影响序列化

  • 见证承诺包含在 coinbase 交易中,添加了 38 到 47 字节,约占区块的 0.005%。 (见BIP 141 - 承诺结构

  • 定义了一种新的交易序列化,其中包含隔离见证数据(见BIP 141,或BIP 144)。这为每个交易增加了 2 字节的开销,以便轻松区分序列化格式,并为每个输入的见证项目计数增加了 1 字节的开销。这些开销加起来约占每个交易的 1%。

隔离见证交易格式(见BIP 141 - 见证程序)在序列化时具有以下影响

  • 与 P2PKH 相比,P2WPKH 在 scriptPubKey 中减少了 3 字节(-1%),并且与 P2PKH scriptSig 具有相同的见证字节数。

  • 与 P2SH 相比,P2WSH 在 scriptPubKey 中增加了 11 字节(6%),并且与 P2SH scriptSig 具有相同的见证字节数。

  • 与 P2PKH 相比,P2WPKH/P2SH 增加了 21 字节(11%),因为在 scriptPubKey 中使用了 24 字节,在 scriptSig 中比 P2PKH scriptPubKey 少 3 字节,并且与 P2PKH scriptSig 具有相同的见证字节数。

  • 与 P2SH 相比,P2WSH/P2SH 增加了 35 字节(19%),因为在 scriptPubKey 中使用了 24 字节,在 scriptSig 中比 P2SH scriptPubKey 多了 11 字节,并且与 P2SH scriptSig 具有相同的见证字节数。

上述百分比基于一个具有一个输入和一个输出的 180 字节交易。随着输入/输出数量的增加,这些比例大致保持不变,但如果使用更复杂的交易脚本(例如多重签名),则会降低。

基本原理

交易大小开销是由两个因素造成的

  1. 对 P2WSH 使用 256 位哈希,而不是对 P2SH 使用 160 位哈希;以及
  2. 通过 P2SH 编码,以便不支持隔离见证的旧钱包可以发送可以使用隔离见证花费的资金,让接收者获得隔离见证的好处。

如果没有这两个因素,开销将很小,P2WPKH 为 -3 字节,P2WSH 为 +1 字节。

第一个因素背后的动机在通过支付到脚本哈希 (P2SH) 提高多重签名的安全性中讨论。

第二个因素是用户在发布接收地址时可以做出的权衡,选择 P2WPKH/P2SH 或 P2WSH/P2SH 的用户将支付与开销成比例的更高费用。从长远来看,这应该会自然地限制这种开销的影响。

未来减少

可以通过更改网络和存储序列化格式来消除大部分开销:可以通过一个简单的标志来恢复完整的序列化,该标志指示使用哪种格式(P2PKH、P2WPKH、P2WPKH/P2SH 等),以及实际数据(公钥和签名)。(例如,compacted_txn.txt

区块验证成本

使用隔离见证,在验证区块时会引入额外的处理,以便检查见证默克尔树,并处理 P2SH 编码的见证交易。这需要每个交易大约五个额外的 SHA256 哈希,每个 P2SH 编码的 P2WSH 输入一个额外的 SHA256,以及每个 P2SH 编码的 P2WPKH 输出一个额外的 HASH160。然而,这最多只相当于对最多 4MB 的数据进行六次 SHA256 运行,总计大约 24MB 的 SHA256 数据,这应该转化为在 Raspberry Pi v1 上每个区块最多增加 15 秒,或者在功能更强大的硬件上不到 1/10 秒。

引入漏洞的风险

隔离见证补丁集是对比特币的重大改变,它在 Bitcoin Core 0.13.0 中推出,尽管没有在比特币主网上激活。这种重大的改变带来了各种风险,包括

  • 完全的漏洞:设计或实现中可能会出现错误,导致意外或有害的结果。例如 PR#8525

  • 用户错误:系统更改会导致用户混淆,导致系统使用不当,进而可能导致有害结果。

  • 生态系统交互:比特币生态系统的不同部分可能存在硬编码的假设,这些假设会在更新后被违反。例如,解析 bitcoind 区块存储的应用程序需要更新,才能理解新的序列化。

避免

为了降低隔离见证激活时这些风险发生的可能性,已采取以下措施

  • 同行评审:隔离见证中的所有更改,包括设计和实现,都已公开展示,并由多位独立专家进行评审;通常会导致建议的改进被采用。

    公开演讲包括

    技术评审包括

  • 测试用例:如下一步文章中所述,“对共识规则和 P2P 网络代码的组合更改包括 1,486 行新增或修改的代码。隔离见证补丁还包括在单元测试和集成测试中新增或修改的 3,338 行代码,这些代码有助于确保隔离见证在 Bitcoin Core 程序的每次完整构建中都能按预期运行。”

  • 测试网络:在开发过程中,隔离见证已部署到多个测试网络,允许对代码进行验证,并允许更广泛生态系统的开发者(例如区块浏览器和钱包)确保其软件与隔离见证正确交互。这些测试网络包括
    • Elements 项目 - 作为硬分叉,以及许多其他更改,测试了隔离见证的概念
    • segnet1 到 segnet4 - 在 2016 年 1 月到 5 月之间,测试了隔离见证作为软分叉的实现
    • testnet3 - 隔离见证在 2016 年 5 月在标准测试网上激活
  • 替代实现:隔离见证 BIP 已在btcd(Go)和Bcoin(Javascript)中重新实现,以及在各种钱包和库中重新实现。独立重新实现有助于发现设计中未说明的假设和歧义,并避免可能由这些假设和歧义引起的漏洞。

缓解

减轻任何漏洞影响的一个主要因素是隔离见证是作为软分叉实现的。这意味着

  • 比特币用户可以简单地避免使用新引入的功能,直到他们亲自确信这些功能已正确实现,而不会丢失任何功能。

  • 所有有效的隔离见证区块对于隔离见证前的软件也是有效的区块,因此不包括隔离见证更改的早期版本的比特币(因此不包括这些更改中引入的任何漏洞)可以用来验证区块,以提供第二级保障,防止可能发生的共识倒退。

此外,对“脚本”语言进行版本控制的可能性为修复比特币脚本语言中的漏洞提供了可能性,包括现有漏洞,以及隔离见证可能引入的任何潜在新漏洞。

技术债务的概念是指,现在容易的修复可能会在长期造成足够的困难和问题,以至于现在花费更多的时间和精力最终会更经济。

在比特币的背景下,技术债务有两种类型

  • 难看或复杂的代码,可以在不影响用户或共识的情况下进行重构;以及
  • 糟糕的设计决策,其中许多决策必须无限期地保留,否则比特币用户将无法访问其现有的代币。

避免

如上所述,隔离见证代码已接受严格的评审,这有助于抵抗在代码和设计级别引入技术债务。

同样如上所述,隔离见证有多个独立的重新实现,这有助于发现任何不必要的复杂性和技术债务,以便在仍然可以避免的时候发现它们。

为了支持现有的通过重构和改进比特币代码库来偿还技术债务的努力,隔离见证被合并为代码更新,作为实现 0.13.0 版本发布的努力的一部分。

缓解

比特币已经存在一些重大的设计债务,隔离见证的具体设计旨在减少这些债务的影响(尤其是交易可塑性、签名哈希的二次缩放以及输入值的非签名)。

隔离见证提供的脚本版本控制方法提供了一种优雅的方式,允许未来的软分叉更新进一步减少设计债务,包括通过修复现有操作码中的漏洞(例如 CHECKMULTISIG)、重新启用禁用的操作码(例如 CAT),或切换到更优的验证方法(例如 Schnorr 签名或聚合签名)。

一般而言,比特币脚本中的设计债务无法完全偿还,因为总有可能存在一些未花费的交易,这些交易支付到使用“丑陋”功能的 P2SH 地址。禁用这些功能将使这些交易无法花费,实际上是窃取了用户的资金。脚本版本控制允许通过将这种“丑陋”的功能划分为仅适用于“旧”脚本版本的功能来减少这种设计债务的“成本”,从而允许新的开发工作在很大程度上忽略旧代码。

软分叉是对比特币共识规则的任何更改,该更改会使某些先前有效的交易无效。处理不当的软分叉可能会导致比特币生态系统出现许多问题,并且由于隔离见证使附加的见证数据对于建立比特币的分布式共识至关重要,因此处理不当的升级可能会导致系统以更多方式发生故障。主要的潜在故障模式包括

  1. 使某些比特币持有者无法花费他们的钱
  2. 导致旧节点和升级后的节点对哪些未确认交易有效以及可能被挖掘有不同的看法
  3. 矿工错误地挖掘了在新的规则下无效的区块
  4. 激活,具有一定的实际用途,然后撤回
  5. 由于旧节点无法转发见证数据,导致点对点网络实际上断开连接,从而允许大型区块链分叉

避免

比特币中已经激活了许多软分叉(包括 BIP 1634656668112113),这种经验已在 BIP9 激活软分叉的过程中得到总结。BIP9 进程用于部署 CSV 软分叉(BIP 68、112 和 113),并导致对该更改的共识规则进行了快速且无问题的升级。

隔离见证设计和 BIP9 部署以以下方式避免了上述问题

  1. 隔离见证施加的新限制仅影响目前无人使用的交易,因为

    • 受影响的交易将是非标准的,因此不会被绝大多数节点中继或被大多数矿工挖掘。

    • 目前,任何受影响的交易都将被视为明显的“任何人可以花费”的支付,并且可以立即被任何监控区块链的人员认领,因此应该预计会“丢失”。

  2. 旧节点将认为花费隔离见证输出的交易是非标准的,因为明显违反了 BIP62 CLEANSTACK 规则,因此不会包含在旧节点的内存池中。同样,具有 P2WPKH 或 P2WSH 输出的交易(尽管不是通过 P2SH 编码的 P2WPKH/P2WSH)也将被认为是非标准的,因为它们是一种新的输出类型。

    这使得通过旧节点中继一个交易,而通过隔离见证节点中继另一个交易,无法对隔离见证输出进行双重花费。

    但是,这些差异仍可用于尝试双重花费,例如,通过在一个交易中组合非隔离见证输出和隔离见证输出(该交易只能通过升级后的隔离见证节点中继),然后尝试通过仅使用非隔离见证输出的更高费用交易来双重花费它,该交易可能通过旧节点成功中继。

    这些问题仅影响内存池中的未确认交易;一旦交易得到确认并在区块中挖掘,双重花费将变得不可能。现有的监控双重花费的方法应该仍然同样有效,前提是监控工具能够跟踪所有隔离见证花费。

  3. 确保矿工挖掘有效的区块显然是所有相关人员的高度优先事项,并且已经投入了大量工作来保证隔离见证的有效性。这包括在 BIP145 下进行的直接工作以及间接工作,例如紧凑区块 (BIP152)。

  4. 如果隔离见证软分叉在激活后被还原,这可能会导致任何进行隔离见证交易的人损失资金 - 例如,恶意矿工可以在没有启用隔离见证的情况下,在链上重播交易,此时该交易将变为任何人可以花费,然后矿工可以通过将其花费给自己来窃取资金。在激活隔离见证软分叉后,在允许窃取隔离见证启用交易的同时,有两种方法可以还原隔离见证软分叉

    • 矿工可以放弃启用隔离见证的链,并从隔离见证激活之前开始挖掘。根据 BIP9 激活规则,这将需要放弃超过 2016 个区块(锁定期限,以及足以确保未达到 95% 阈值的区块)。这将要求矿工放弃超过 25,200 个 BTC 的区块奖励,按当前价格计算,这超过了 15,000,000 美元。

    • 矿工可以简单地使用无法识别隔离见证规则的软件(例如早期版本的 Bitcoin Core)来在已激活隔离见证的链上挖掘区块。就隔离见证感知软件而言,这将是一个硬分叉,因此这些区块将被使用隔离见证感知验证节点的比特币用户忽略。如果使用隔离见证节点的用户足够多,这种硬分叉将不会比引入新的山寨币更有效。

    因此,这两种方法似乎都不太可能。

  5. 已经投入了大量工作来确保启用隔离见证的节点将形成比特币点对点网络的强连接子图。这包括为启用见证的节点提供专用的服务位,并优先连接到这些节点。

由于区块变大而产生的风险

隔离见证将 1MB 区块大小限制更新为 4M 单元区块权重限制,将序列化见证数据计为一个单元,将核心区块数据计为四个单元。随着使用隔离见证功能的交易开始使用,这种变化将允许每个区块包含更多数据(如果 100% 的交易使用隔离见证功能,预计每个区块约为 2MB 数据,但最坏情况下可能高达 4MB 数据)。就其允许更大的交易量而言,可以预期它会更快地增加 UTXO 数据库(如果 100% 的交易使用隔离见证功能,增加速度可能会大约翻倍;但是,由于隔离见证是一个软分叉,因此最坏情况下的 UTXO 增长保持不变)。

这些结果可能具有积极的属性(例如,更大的交易量允许更多用户参与),但也可能具有重大负面影响

  • 更大的区块可能导致区块传输速度变慢,从而导致矿工的孤儿率更高 - 这反过来可能导致安全性降低(接管网络所需的哈希算力更低),或集中度更高(大型矿工能够更多地降低其孤儿率)。

  • 更大的区块将导致完整节点的资源需求更高,这可能会导致用户关闭其节点,从而导致集中度更高。

  • 更大的 UTXO 集将导致矿工的资源需求更高,这可能会导致矿工共享验证资源,从而导致集中度更高。

避免

更大的区块的负面影响在很多方面是有限的

  • 由于部署了 libsecp256k1,区块的验证时间已大幅减少。

  • 通过 BIP152 部署紧凑区块有助于限制更大的区块对区块传输的影响,从而减少孤儿率,并且还降低了完整节点的带宽使用量。

  • 修剪支持允许用户运行完整节点而不存储整个区块链历史记录,这允许存储资源有限的用户继续运行完整节点,即使区块大小更大也是如此。

  • 隔离见证签名使用签名哈希算法的更改,以避免二次缩放,这为一些大型交易提供了显著的成本降低。

UTXO 增长加快的负面影响受到以下因素的限制

  • 隔离见证作为软分叉的部署,以确保最坏情况下的 UTXO 增长不会变得更糟。

  • 见证数据的权重降低以重新平衡 UTXO 的生命周期成本,降低了引入花费隔离见证输出的额外输入的成本,因此(相对地)提高了引入创建新 UTXO 的额外输出的成本,将创建/花费成本比从大约 1:4.5 更改为大约 1:2。这应该适度降低增加 UTXO 集的激励措施,既可以抑制 UTXO 的创建,也可以鼓励 UTXO 的花费。

缓解

  • 由于每个区块的最大数据量上限不超过当前速度的四倍,因此解决大型区块带来的问题的缓解工作应该在相对简单的工程工作的范围内。此外,由于每个区块的预期数据量仅约为当前速度的两倍,这意味着任何必要的缓解工作都应该进一步简化。

  • 正在进行工作以改进交易和区块的磁盘上和网络序列化,进一步降低运行完整节点的存储和带宽要求。

由于费用降低而产生的风险

比特币区块链的安全性由哈希算力提供,哈希算力通过固定的区块奖励以及来自各个交易的费用来奖励。因此,费用收入的下降有可能降低用于开采比特币的哈希算力,这反过来可能会降低比特币区块链的安全性。

就单个交易费用由市场力量和供求关系决定而言,隔离见证引入的更改可能会通过增加供应来降低价格(假设需求没有因为或至少与隔离见证部署同时上升),而较低的价格可能会导致整体挖矿收入降低(如果需求价格弹性在非弹性范围内)。

此外,隔离见证中进行的更改可能会使“第二层”解决方案(如闪电网络)更具吸引力。如果这导致用户将第二层解决方案视为链上交易的替代方案,这可能会显着降低对链上交易的需求,这将对交易费用水平造成额外的下行压力。

避免

目前,费用约为每区块 0.5 BTC,而区块补贴为每区块 12.5 BTC,约占矿工收入的 4%,因此短期内对矿工收入和网络安全的影响可能很小。

此外,过去 12 个月,费用一直在上升,无论是以 BTC 面值(从一年前的每区块不到 0.2 BTC 上升)还是以实际价值(从一年前的每 BTC 低于 300 美元上升到今天的每 BTC 超过 600 美元),因此费用水平的适度下降将仅相当于恢复到最多 12 个月前的费用收入水平,这应该不会造成重大影响。

缓解

矿工可以单独或集体限制供应,无论是通过单独设置他们生产的区块的最大权重软限制(“blockmaxweight”设置,默认值为 3M),还是通过集体使用软分叉来有效降低共识限制,通过将超过特定权重的区块视为孤块。这种方法有可能防止由于供应增加而导致的任何手续费下降(或者实际上通过减少供应来增加单个手续费,尽管这可能不会增加总收入),但不能防止由于替代效应(例如第二层网络的采用)而导致的手续费收入下降。

虽然第二层网络可能作为链上交易的替代品,但它们无法完全避免链上交易,在某些情况下,即使来自第二层网络的这些相对较少的链上交易也可能轻易地用 SegWit 启用后饱和链上容量。即使仅通过链上交易手续费捕获这些网络价值的一小部分,这也很可能大大超过当前的手续费价值。

如上所述,所有交易完全采用 SegWit 预计将使容量翻倍。这将提供短期或中期容量的重大一次性增加,具体取决于采用速度。此外,通过添加功能来启用第二层网络,可以实现一些额外的中长期扩展。通过修复二次 sighash 缩放错误,SegWit 还降低了未来容量增加带来的负面影响的风险。

然而,SegWit 并没有提供任何直接的机制来进一步扩展链上交易量,除了那一次性的翻倍之外。

这存在着长期扩展方法可能被阻止或延迟的风险:利益相关者可能会认为 SegWit 足够“扩展”,并拒绝参与或支持进一步的扩展工作。

避免

为避免这种风险所做的努力包括

此外,使 SegWit 允许的规模增加变得可实现的工作(例如 libsecp256k1 和紧凑区块)也显然使进一步的潜在规模增加变得更加可实现。

缓解

SegWit 在技术层面上并没有使进一步的扩展变得更加困难——这里的风险完全是社会性的。因此,最有效的缓解努力也可能本质上是社会性的:例如,让支持长期扩展的公司投入开发资源来实现这一点。

SegWit 使交易量增加到目前水平的两倍左右,这也提供了机会来展示扩展的实际影响,例如对节点性能、去中心化和交易需求的影响,以及生态系统升级的速度。这些数据可以合理地收集并用于支持未来的扩展工作,无论是通过表明一些人们担心的结果比预期更不可能发生,还是通过确认有效的问题,并允许将工作重点放在解决这些问题上。

替代方法

本节简要比较了实现 SegWit 部分或全部益处的几种替代方法,以及这些不同方法如何改变所涉及的成本和风险。

硬分叉隔离见证

任何硬分叉实现 SegWit 都将增加重大新成本和风险,因为需要所有节点在激活之前升级以理解新规则,并冒着将链分叉成“旧比特币”和“新比特币”的风险,从而导致混乱和价值损失。由于比特币社区缺乏硬分叉经验,也可能出现意外的风险和成本,尽管这本身就很难分析。

SegWit 的硬分叉实现实际上可以通过两种方式实现

  1. SPV 不可見:如果将见证承诺从 coinbase 移动到区块交易默克尔树中,大多数非验证客户端和钱包将继续工作而无需升级。这将节省 coinbase 交易中的 38-47 字节,但不会提供任何其他优势。

  2. SPV 可見:如果将交易哈希的计算改为不包括 scriptSig,这可能允许更简单的实现,并减少每笔交易的开销;但是,这将使所有现有的比特币软件在更新之前无法与这些交易一起使用。此外,需要保留用于管理旧式交易的单独代码路径,这会增加代码复杂性和出现错误的可能性。 BIP 134,灵活交易 展示了一种通过 SPV 可见硬分叉实现 SegWit 部分益处的替代方法。

硬分叉的任何一种方法都将使同时大幅更改区块的共识限制成为可能。

更简单的隔离见证

SegWit 的许多益处在逻辑上可以分离成独立的更改,并分别进行评估和部署。然而,各种功能的实现要求密切相关

  • sighash 操作的线性缩放:CHECKSIG 和 CHECKMULTISIG 操作码需要替换。
  • 输入值的签名:CHECKSIG 和 CHECKMULTISIG 操作码需要替换。
  • 通过 P2SH 增强多重签名的安全性:P2SH 支付格式需要替换。
  • 脚本版本控制:P2SH 支付格式需要替换。

独立执行这些修复将增加比特币代码库的复杂性,因为需要处理在区块链上不同时间激活的不同功能;而同时部署它们则消除了这种复杂性。

由于使用现有 CHECKSIG 和 CHECKMULTISIG 操作码,sighash 操作的二次缩放会导致增加容量具有危险性,因此需要对这些操作进行一些限制。由于 SegWit 仅通过更新的操作码允许增加签名操作,因此旧操作码自然仍然受到限制。相比之下,如果独立地应用容量增加,则需要实施额外的限制以确保增加是安全的,这很可能会增加挖掘和手续费计算的复杂性。