为什么比特币需要通过Segwit和Taproot进行改造

  • Shinobi
  • 发布于 12小时前
  • 阅读 39

文章深入解释了比特币的SegWit和Taproot这两项关键升级,分析了它们如何解决了交易延展性、脚本限制和多重签名效率等核心问题。它详细阐述了SegWit改变交易结构、Schnorr签名的优势以及Taproot如何通过MAST和密钥调整提高隐私和效率,并强调了这些升级对比特币扩展性解决方案的重要性。

《核心问题》:回顾隔离见证(Segregated Witness)和 Taproot,比特币的两次最大升级,以及它们为何如此设计。

核心问题:为什么比特币需要通过 Segwit 和 Taproot 进行重塑

隔离见证(由 Pieter Wuille、Eric Lombrozo 和 Johnson Lau 提出的 BIP)和 Taproot(由 Pieter Wuille、Jonas Nick、Tim Ruffing 和 Anthony Towns 提出的 BIP)是比特币协议有史以来最大的两次更改。

前者从根本上改变了比特币交易的结构,并在此过程中改变了比特币区块,以解决之前交易结构的固有局限性。后者重新设计了比特币脚本语言的某些方面,复杂脚本的构建和验证方式,并引入了一种创建加密签名的新方案。

与仅仅允许接收者选择阻止其币在一定时间内移动的 CHECKTIMELOCKVERIFY (CLTV) 等单个操作码相比,这些都是巨大的更改。

这些更改旨在解决比特币作为系统所存在的非常真实的缺点和局限性。作为维护比特币整体状态(即所有未花费的币)全球共识的基础层,比特币是一项无价而卓越的创新。然而,作为直接让每个人都能通过这些币进行交易的手段,它在任务上严重不足。

自隔离见证和 Taproot 激活以来,它们解决的许多缺点已被遗忘。随着时间的推移,这些设计决策背后的原因和原理也在口耳相传中被扭曲。

对比特币协议的这两项更改本身都是解决大问题的方案,但它们也各自为将来解决其他问题或进行其他改进奠定了基础。

在这些更改激活后,许多新用户加入了网络,现在值得回顾并重新审视这些设计选择。

隔离见证 (BIP 1411)

当一笔比特币交易花费币时,它通过创建这些币的交易的输出索引和交易 ID (TXID) 来引用它们。这确保了交易的输入可以被唯一识别,并能以绝对确定性验证这些币以前从未被花费过。

在隔离见证之前,交易结构如下所示:

[Version] [Inputs] [Outputs] [Locktime]

TXID 是这些数据的哈希值。问题在于,证明交易有效的 ScriptSig(签名、哈希原像等)是输入的一部分。你可以更改 ScriptSig 中的小程序指令,甚至可以更改加密签名本身而不会使其失效。

这些“可塑性”(malleations)会改变 TXID。这对预签名交易来说是一个大问题。

闪电网络、Ark、Spark、BitVM、Discreet Log Contracts (DLCs),所有这些扩展工具都依赖于预签名交易。它们要求创建一个未签名的资金交易,并在签名并确认资金交易之前预先签署所有保证资金正确执行和安全的交易。所有这些系统都使用多重签名认证来保证双重花费的安全性(这在后面会很重要)。

如果该资金交易被篡改,并且其交易 ID 在区块中确认之前被更改,那么所有保护第二层资金的预签名交易都将失效。在任何人都可以在你的资金 TXID 在网络中传播时对其进行更改的环境中,这些工具都无法工作。

隔离见证使用一个未定义的操作码作为一种遮蔽帘,将其放置在 ScriptSig 之前所在的输入位置,并将所有这些数据移动到一个名为“witness”的新交易字段中。新的交易结构如下所示:

[Version] [Marker/Flag] [Inputs] [Outputs] [Witness] [Locktime]

输入中的“遮蔽帘”允许旧节点默认将其后面的所有内容标记为有效,而新节点则可以实际应用适当的验证逻辑。现在,传统的 TXID 不会再因更改 witness 中的 ScriptSig 数据而改变。这解决了预签名交易的问题,并为当今所有使用它们的扩展解决方案打开了大门。

但区块头中的交易默克尔树只承诺了交易的传统 TXID,这造成了一个问题。区块中没有对任何 witness 数据的承诺。这需要 witness 承诺和 witness 交易 ID (WTXID)。就像构建 TXID 的普通默克尔树一样,每个交易的 WTXID 树被构建并提交到 coinbase 交易的 witness 中。

唯一的区别是树的根与一个保留值进行哈希,而这正是包含在 coinbase witness 中的内容。这使得该值将来可以用于在共识规则中提交其他新数据字段。在发明这种 witness 树承诺(由 Luke Dashjr 提出)之前,人们曾认为由于交易结构的变化以及区块头中需要单独的 witness 承诺,隔离见证将需要硬分叉。

“遮蔽帘”设计也允许对脚本系统进行任意升级,因为所有新数据都会被不支持它的节点忽略而不被验证。这使得新的脚本系统能够绕过传统脚本系统的所有限制。这里升级路径的灵活性使得 Schnorr 签名得以集成,并在必要时将允许抗量子签名(抗量子公钥通常大于传统的 520 字节数据项限制,签名也是如此)。

隔离见证解决了交易 ID 可塑性的根本问题,该问题曾阻碍了可扩展第二层的开发,这些第二层可以将比特币带给更多用户,但它也为支持和改进这些第二层所需的任何脚本改进奠定了基础。

Schnorr 签名2

Schnorr 签名于 1991 年由 Claus Schnorr 发明,并迅速获得专利。事实上,ECDSA 签名方案的发明就是因为 Schnorr 签名的专利。Schnorr 签名的专利于 2010 年 2 月到期,距离比特币网络启动仅一年多一点。

如果不是因为专利,中本聪(和世界其他地方)很可能从一开始就使用了 Schnorr 签名。

Schnorr 签名相对于 ECDSA 有几个主要优势:

  • Schnorr 签名是可证明安全的。Schnorr 签名不可伪造/不可破解的数学证明比 ECDSA 的证明更强,并且假设更少。对于作为比特币核心的密码学拥有更强的安全保证显然是一个巨大的优势。
  • Schnorr 签名本质上是不可塑的,这意味着 ECDSA 中允许在不使签名失效的情况下更改签名的问题在 Schnorr 签名中根本不可能发生。
  • Schnorr 签名具有线性特性,可以实现简单高效的加性密钥构造、分布式密钥生成和分布式签名生成。这允许用户简单地将各个 Schnorr 公钥“相加”,并作为一个组为这些聚合公钥生成签名。

它们更安全,不易被第三方篡改,并为各种高效灵活的密码学方案打开了大门,以改进多重签名认证。

前面在讨论交易可塑性时,我提到所有使用预签名交易进行链下构建都依赖于多重签名认证来保护用户资金。这在资金的共享控制方面造成了一个隐式的扩展上限。传统的 multisig 只能达到一定的规模。存在交易大小限制,对于版本 0 (隔离见证) 的 witness,存在 witness 大小限制。只有有限数量的参与者可以加入多重签名地址,因此隐式地只有有限数量的参与者可以共享资金控制权。

基于 Schnorr 的多重签名方案通过将公钥聚合到一个单一的组公钥中,而不是用每个成员密钥单独明确包含来构建脚本,从而突破了这一限制。在隔离见证之前,一个多重签名地址最多只能有 15 个参与者,而在隔离见证之后,最大规模可能达到 20 个参与者。

通过 MuSig5 和 FROST6 等基于 Schnorr 的多重签名方案,这些限制至少在共识层面不再存在。多重签名脚本可以像用户希望的那样大,只要在所选规模的组内协调签名过程是实际可行的,而不会中断或拒绝参与。

允许这种密钥聚合的相同属性也允许高效的适配器签名(adaptor signatures),这是一种允许某人生成一个签名,该签名在秘密信息被揭示之前一直无效的方案。这些属性还允许签名者为他们看不到的消息生成签名的零知识证明驱动方案。

Taproot3,4

Taproot 是一个名为 Merklized Abstract Syntax Trees (MAST)7 的旧概念的演变,MAST 本身是 Pay-to-script-hash (P2SH)8 的一种扩展。P2SH 最初是为了解决两个主要问题而创建的:

  • 当使用大型自定义脚本时,产生的未花费输出更大,需要在 UTXO 集中存储更多空间。
  • 当使用大型自定义脚本时,发送方支付更高的费用,因为其交易中的支付输出更大,从而抑制了人们支付可能更安全的自定义脚本的意愿。

不是在输出中明确包含整个脚本,而是包含该脚本的哈希值,在花费时,接收方必须在被花费的输入中提供整个脚本以对照哈希值进行验证。这解决了未花费输出存储空间的问题,并将使用大型脚本的成本转嫁给使用它们的人,而不是那些发送资金的人。

这仍然留下一个问题。自定义脚本可以包含多种花费方式,但在花费时,用户仍然必须揭示整个脚本,包括验证实际花费币的条件时不需要的脚本分支。这在空间上非常低效,并给花费用户带来了比必要更高的成本。

MAST 背后的思想是将多分支脚本中的每个单独花费条件分离出来,构建每个单独花费路径的默克尔树。然后每个路径被哈希,该默克尔树的根就是用户的地址。在花费时,用户只需提供他们正在使用的花费路径以及证明它是树中叶子的默克尔证明,以及满足该脚本所需的数据。

这种默克尔树结构解决了与 P2SH 相同的所有问题,并优化了 MAST 用户的花费成本(同时也改善了他们的隐私!)。

Taproot 采用了这一概念,并通过利用 Schnorr 签名的线性特性,以一种更注重隐私的方式进行集成。大多数人们想要构建的合约都将有一个乐观的结果,即双方用户简单地同意如何分配资金。在这种情况下,他们只需签署一笔交易。Taproot 采用 MAST 根并“调整”(tweaks)一个 Schnorr 公钥,从而产生一个新的公钥。通过用相同的 MAST 根“调整”私钥,你将得到新公钥对应的私钥。

用户现在可以简单地使用该调整后的密钥花费一个输出,不留下任何 MAST 树存在的痕迹,或者揭示原始公钥和 MAST 根以及他们实际使用的花费路径。此外,如果你不想包含密钥路径,可以使用一个特殊的 NUMS (Nothing Up My Sleeve) 值(可证明无法花费),而不是普通的公钥,这样只留下 MAST 脚本作为有效的花费路径。

利用隔离见证的设计选择,Taproot 还引入了 tapscript,一个全新的脚本系统。这里的主要变化是停用 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY。它们被 OP_CHECKSIGADD 取代,后者提供了一种更高效的方式来验证多个签名。这与 Schnorr 密钥聚合相结合,实现了与传统脚本相同多重签名功能。

Tapscript 额外修改了 OP_CHECKSIG 和 OP_CHECKSIGVERIFY,使其仅适用于 Schnorr 签名,并引入了 OP_SUCCESS 作为 OP_NOP(传统脚本中的未定义操作码)的替代。OP_SUCCESS 旨在实现比 OP_NOP 更清晰、更安全的操作码升级。

Witness 限制

迄今为止,有两个方面尚未讨论。隔离见证中引入的区块权重限制,以及 Taproot 中 witness 大小限制的增加。

这两个决定在生态系统中少数非常活跃的权力用户中引起了争议。我不会讨论作为引入区块权重限制一部分的区块大小增加,这在当时是与那些推动硬分叉区块大小增加的异议用户之间的妥协,并被当时的网络参与者认为是安全的;但 witness 折扣本身的动态很重要。

比特币交易费用是基于交易中的数据量。这与正在转移的价值量无关。它仅仅是输入和输出(以及 witness)的数量以及它们的数据字节数。回想一下,我前面提到,在隔离见证之前,ScriptSig,即签名和其他数据,是包含在交易输入中的。这是包含在输入中但未包含在输出中的大量数据。

这意味着交易中的输入比输出更昂贵,而且幅度很大。这为用户创造了一个长期激励,使他们倾向于花费大额输出并创建新的找零输出,而不是收集和花费大量小额输出。这是一种长期的经济激励,鼓励用户永久性地增长 UTXO 集,这对于所有完全验证节点都是必需的。

witness 折扣旨在纠正这一价格差距,使其变得微乎其微,而不是巨大。这对于经济上激励负责任的 UTXO 管理至关重要,至少对于仅进行交易的经济理性用户而言是如此。

Taproot 移除了交易 witness 字段上现有的尺寸限制。在隔离见证中,该限制为 10,000 字节。之所以这样做,是因为 Taproot 的设计减轻了可能构建昂贵验证交易的问题,并且试图在 tapscript 中引入此类限制会在 Miniscript 中引入很大的复杂性。这类限制旨在防止的问题并未影响 Taproot,反而为一款旨在使自定义脚本对开发者和用户都更安全、更易用的工具带来了复杂性。

全景

比特币的这两项更改都消除了扩展它的巨大障碍,从而让更多人可以以自我保管的方式使用它,但它们也使得协议的核心部分进行了同样大规模的更改。

我希望现在,以前不熟悉所有这些设计选择及其背后原理的读者,能够欣赏到它们设计时的细致周到和前瞻性思考。比特币是一项了不起的创新,它确实如此,但它无法将其优势提供给任何接近相当大比例人口的群体。

隔离见证和 Taproot 为基础奠定了两块基石,它们对于试图解决比特币的可扩展性缺陷绝对是必要的。如果没有这两项提案,或者一些解决相同问题的替代协议更改,我们今天拥有的所有这些不断增长的可扩展层和系统都不会存在。

闪电网络、Ark、Spark、BitVM、DLCs——它们都将无法构建。

这就是全景。今天的比特币并不完美,但它确实很有可能扩展到足够有意义的人群,从而对世界产生真正的影响,为那些寻求退出传统系统的人提供真正的替代方案。这正是因为这两项协议升级,以及它们所消除的非常根本的障碍。

  • 原文链接: bitcoinmagazine.com/prin...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

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