浅析比特币的可扩展性方案：隔离见证

比特币的可扩展性是它面临的主要问题之一，也是许多人努力的方向。例如，一个想法是“闪电网络”；然而，由于比特币本身的一些缺陷，在比特币网络中实现雷电网络的条件似乎不可用。另一个解决方案“聚合见证”（aggregated witness）也致力于提高可伸缩性，但它也解决了许多问题，包括在实施lightning network时需要修复的一些缺陷。在这篇文章中，我们将解释独立证人的优势以及它是如何工作的。

Segwit是由多个BIP（141、142、143、144和145）描述的软分支。其主要目的是优化比特币事务和块的结构，并将事务签名（也称为“scriptsig”、“见证”或“解锁脚本”）从事务移动到独立的结构。它不仅可以减少比特币事务的数据量（因此可以在一个块中插入更多事务），而且还可以解决“事务延展性”问题（即阻碍lightning network实施的缺陷）。它是基于比特币交易结构的支付渠道、闪电网络等技术的关键。

隔离证人如何工作

在开始之前

让我们首先简要回顾一下比特币的支付系统。它不像银行那样是账户和余额的列表。相反，每个比特币地址的余额由发送到此地址的一系列事务表示；事务数据结构的主要部分是输入和输出。输入是我们想要花费的预订单交易（确切地说，输入不是一个完整的交易，而是某个交易的输出，因为我们可以在一个交易中将资金转移到多个地址），而交易的输出是我们资金的目的地地址。下图显示了比特币事务的结构：

输出中的pubkey脚本字段（以下称为“scriptpubkey”）就是我们所称的“锁定脚本”。它用于确保只有收到地址的所有者才能使用此费用。签名脚本字段（以下称为“scriptsig”）是所谓的“解锁脚本”，因为它用于打开密钥以锁定脚本并证明地址的所有权。

编者按：这是一个GIF图，显示了比特币的堆栈是如何执行的，但微信官方账号不能显示在推文中。强烈建议在网站上观看。）

有关比特币事务、锁定脚本和解锁脚本函数的更多详细信息，请参见此处。

向后兼容

事实上，隔离见证不仅改变了事务的结构，还改变了事务的输出。但是，这并不意味着传统类utxo（事务输出未花费）和segwit类utxo不能在同一事务中花费：在这种情况下，传统类utxo将在输入（脚本签名字段）中加载所有权证书，而隔离见证类utxo将在事务输入以外的结构中加载证书。

在任何情况下，隔离见证的位置都是软分叉。此升级应该可以忽略不计，并且不是强制性的。此外，这还意味着未升级的节点应该能够处理隔离见证类的输出。事实上，旧的节点和钱包会认为任何人都可以使用这些UTXO，也就是说，这些UTXO即使是空签名也可以使用。因此，即使在事务中看不到签名，该事务仍然有效。升级后的节点和钱包将在交易输入之外的特殊“见证”字段中查找签名。

案例

Pay-to-Witness-Public-Key-Hash

让我们使用一个示例来说明隔离见证将如何更改事务的数据结构。从标准的支付到公钥散列（P2P KH）事务类开始。

我们感兴趣的是输出，特别是它的“scriptpubkey”字段（lockscript字段）。让我们先考虑一个标准的锁定脚本：

隔离见证后的锁定脚本如下：

如您所见，隔离见证的输出比传统类的输出简单得多：只有两个值将被推入脚本执行堆栈。正如我们前面所说，旧的比特币客户机会认为输出是掉在地上的钱——它可以在不提供签名的情况下使用输出。但是，新客户端将第一个数字解释为版本号，第二个对应于锁定脚本（见证程序）。实际上，这里只能使用压缩公钥的哈希值。我们稍后再谈。

让我们看看这个输出被消耗的情况。使用时，传统事务输出的数据结构如下所示：

但是，当使用独立见证输出时，事务的scriptsig将为空，并且所有签名将放置在一个特殊的位置：

警告

尽管传统客户可以处理独立的见证交易（同样，他们会将这些输出视为每个人都可以消费的钱），但他们自己却不能消费这些钱：然而，旧钱包可能会尝试使用带有空签名的独立见证输出，此事务实际上无效（更新的节点将不允许链接此类事务）。这意味着发件人必须知道收件人的钱包不支持隔离见证，以便为其创建适当类的输出。

根据BiP 143的定义，隔离见证的输出应为；压缩公钥；创建的哈希值。如果使用传统类的地址或未压缩公钥的哈希值，此输出将不可用（您的硬币将锁定）。

Pay-to-Witness-Script-Hash

另一个关键事务类是p2sh。它允许将事务发送到脚本的哈希值（而不是公钥的哈希值，即比特币地址）。要使用p2sh事务的输出，消费者需要提供一个脚本（称为“赎回脚本”），其哈希值应与utxo中的脚本哈希值匹配，并基于该脚本提供签名/密码/其他内容。这种用法可以保护解锁脚本，使发件人无法知道地址的内容，还可以节省空间：例如，多重签名钱包的锁定脚本可能很长，因此我们必须保存整个锁；使用p2sh，您只能保存一个哈希值。

假设有一个多重签名钱包，需要提供5个私钥中2个的签名才能使用。如果使用传统事务，p2sh事务输出的锁定脚本如下：

要使用它，付款人（也是上一笔交易的接收人）需要提供一个赎回脚本，该脚本定义了使用条件（多个签名，2-5）和两个签名。所有这些都应放在事务的输入中：

在使用隔离见证后，让我们看看发送方和接收方。输出锁定脚本如下所示：

与P2P KH事务一样，输出脚本变得更简单。第一个值表示版本号，第二个值是对应于赎回脚本（见证程序）的sha256哈希值（32位）。在某种意义上，此函数用于根据长度（32字节sha256哈希值与ripemd160（sha256（脚本））区分p2wpkh的见证程序与p2wsh的见证程序。

使用此输出的事务如下所示：

在 P2SH 中嵌入隔离见证

我们已经看到，使用隔离证人是有益的。然而，上述示例仅适用于发送方和接收方都升级了软件的情况。但情况并非总是如此。考虑一下这种情况：

爱丽丝想把一些BTC转给鲍勃。鲍勃有一个钱包软件支持隔离证人，但她没有。显然，他们只能以标准形式进行交易，但Bob希望使用segwit来降低手续费。

此时，Bob可以创建一个包含segwit脚本的p2sh地址。Alice会将此地址视为普通p2sh地址，因此她可以毫无问题地直接将资金转移到此地址。但是，Bob可以使用segwit交易来使用此输出并获得手续费折扣（我们将在下面解释segwit交易手续费的新定价方法）。

这就是如何在p2sh中实现两种类的segwit事务p2wsh和p2wpkh。

P2SH(P2WPKH)

要在p2sh事务中实现p2wpkh事务，Bob需要使用其公钥创建见证程序。然后散列并将结果转换为地址：

第一个值是版本号，第二个值是20字节的公钥散列值。该脚本首先执行sha256哈希操作，然后执行ripemd160操作以获得20字节的哈希值。

Hash160 p2wpkh见证程序的结果：

转换为一个地址：

发送到此地址的输出锁定脚本与普通p2sh地址的脚本看起来没有什么不同：

当Bob花费输出时，事务结构如下：

开始时，我们创建的赎回脚本（即见证程序）将进行散列计算。如果结果与锁定脚本中的哈希值匹配，则将执行该脚本，并且程序将验证放置在见证字段中的签名。

P2SH(P2WSH)

P2wsh脚本也可以用p2sh实现。让我们考虑上面提到的2-5多重签名钱包的例子。所有步骤与p2sh（p2wpkh）相同：

首先，创建一个见证程序：

第一个值是版本号，第二个值是32位sha256哈希值，它对应于我们的签名脚本。然后，我们将见证程序的hash160哈希值转换为普通的p2sh地址。要使用发送到此地址的输出，我们需要在scriptsig字段中发布见证，并在见证字段中提供完整的多重签名脚本。

隔离见证的好处

通过对技术部分的梳理，我们可以了解隔离见证的主要优势。

交易熔融性漏洞

segwit解决的一个关键问题是比特币事务的“融化”，即比特币事务的ID是散列值这一事实所导致的问题。让我们详细谈谈。

在以前的比特币交易中，签名放置在交易的输入部分，第三方可以更改签名而不会使交易无效。这允许第三方更改事务的ID（即事务的哈希值），而无需更改事务的“键”字段（例如输入、输出和传输的数量）。这样，事务仍然有效，并且具有相同的含义，但如果使用另一个ID，它可以用于执行另一种攻击，例如DoS攻击（拒绝服务攻击）。

Segwit解决了这个问题，因为所有签名都放在事务之外。因此，签名的更改不会更改事务的哈希值，也不会影响事务的ID。隔离见证还引入了一个名为“wtxid”的特殊标识符：它是事务和整个见证部分的哈希值。因此，如果在没有任何见证数据的情况下传播事务，则事务ID（txid）等于wtxid。

此解决方案使我们能够创建一系列连续的未确认交易，而不必担心任何风险，这对于lightning network等协议来说非常重要（译者注：这可能意味着如果交易融化问题没有解决，支付渠道的参与者将无法快速检索交易对手是否链接了过时的渠道交易，因为具有相同内容的交易可能以完全不同的ID显示）。

网络和存储扩展

见证数据通常是事务数据的**部分。在使用多重签名脚本的事务中，见证可能占事务数据的75%。多亏了segwit，签名传输成为一种选择：节点只有在想要验证事务时才需要请求此数据。不支持segwit的SPV（简单支付验证）客户端和节点不需要下载额外的数据，这可以节省硬盘空间。

扩展了可用的区块空间，降低了交易费用

Segwit类的事务比以前的事务类便宜，因为它减少了存储见证数据的需要。确切地说，“大小”的概念在segwit类的事务中略有不同。它引入了“虚拟大小”的概念：放置在见证部分的所有数据都将乘以0.25来计算数据大小，以便将更多事务填充到一个块中。让我们举个例子。

假设我们有一个数据大小为200字节的传统事务。然后，可以在1MB块中放置5000个这样的事务。等效的sigwit事务在见证区域中有120个字节，因此其虚拟大小为80+0.25*120=110字节，因此9090个此类事务可以放置在块中。如果上行链路的服务费为每字节40聪，交易费将从8000聪降至4400聪，几乎是一半的折扣（注：“聪”是比特币的数量单位，是BTC的十亿分之一。）

脚本版本

您可能已经注意到，每个锁脚本都有一个字节来表示脚本的版本。使用不同的版本号可以以软分叉的形式添加或更改函数（语法更改、新运算符等）。

签名验证的效率优化

隔离见证还优化了签名算法（如checksig、checkmultisig等）的效率。在segwit之前，哈希计算的数量与签名数量的平方成正比，但在隔离见证下，算法的计算复杂度降低到o（n）（与签名数量成正比）。

其他的问题？

如果百里没有伤害，怎么会有人认为有问题呢？比特币社区中的许多人反对此升级，因为即使升级时间很长，它也有一些缺点。让我们来看看对方提出的一些观点。

• 由于segwit是一个软分支，许多客户端可能无法升级，因此网络中将同时存在两种类的utxo；对于非segwit输出，消除事务ID的融化和哈希计算次数的线性增加等重大更改无效，因此网络仍将面临事务ID融化和哈希时间平方上升的风险。
• Segwit将降低网络的安全性，执行完全验证的节点数量将大大减少，因为只有那些适应Segwit的节点才能验证事务的见证部分。
• 塞格威特不能被废除。如果它被废除，所有的改变都被撤销，那么所有赛格维特的产出都将成为人们在街上捡到的钱。
• Segwit希望一次解决所有问题，这将导致大量代码更改。这将增加未来的工作量，并提高无法消除的软件缺陷的可能性。

结论

虽然SW解决的问题可能会有更优雅的解决方案，但我们仍然相信，目前，这是提高网络可扩展性和启用lightning network等技术的**方式。下一篇文章将提供更详细的分析。