比特币的可扩展性问题是需要面对的主要问题之一,也是许多人努力的方向。比如说,有个设想是「闪电网路」;但是,要在比特币网路中实现闪电网路,因为比特币自身的一些缺陷,目前条件仍不具备。本文源自于
Magomed Aliev 的《Segregated Witness for dummies》,由动区专栏作者以太坊爱好者整理、翻译与撰稿。
(前情提要: 【三分钟内就看懂】什么是Segwit隔离见证?)
(背景补充:干货|简单理解 Taproot 软分叉:为何是比特币睽违 4 年最重要升级?)
比特币可扩展性问题是其面临的主要问题之一,也是许多人正在努力的方向。举闪电网路为例,要在比特币网路中实现,碍于比特币本身的一些缺陷,仍不具备该条件。
另一个解决方案,隔离见证(SegregatedWitness)也致力于提高可扩展性,但它同时也解决了许多问题,包括闪电网路实现所需修补的一些缺陷。我们也将在本文中讲解隔离见证的优势及其工作原理。
隔离见证(SegWit)是一个由多个 BIP(141、142、143、144 和 145)描述的软分叉,主要用意是优化比特币交易和区块的结构,将交易的签名(也叫 「脚本签名(scriptSig)」、「witness」 或 「解锁脚本」)从交易中移到一个独立的结构中。
它不仅能降低比特币交易的资料量大小(因此能让一个区块塞下更多的交易),也能解决 「交易熔融性(transaction malleability)」 问题(也就是我们开头提到阻碍闪电网路实现的缺陷),对支付通道和闪电网路来说,这种比特币交易结构的技术来说极为关键。
在开始之前,我们先要简单回顾一下比特币的支付系统。它并不像银行那样,是一套帐户和余额的列表。
相反,每个比特币地址的余额都是由一系列发送给这个地址的交易来表示的;交易这一资料结构的主要部分就是输入和输出。
输入是我们想要花费的交易(准确来说,输入不会是完整的一笔交易,而是某笔的输出,因为我们可能会在一笔交易中将资金转往多个地址),而交易的输出就是我们的资金发送的目的地址。下图展示了比特币交易的结构:
输出中的 PubKey Script 栏位(下文简称为 「scriptPubKey」)就是我们所说的 「锁定脚本」。它用来保证只有接受地址的所有者才能使用这个支出。Signature Script 栏位(下文简称为 「scriptSig」)也就是所谓的 「解锁脚本」,因为它是用来打开锁定脚本的钥匙,是用来证明地址所有权的。
有关比特币交易和锁定脚本、解锁脚本功能的更多细节,可看此处。
实际上,隔离见证不仅改变了交易的结构,也改变了交易的输出。不过,这不是说传统类型的 UTXO(未花费的交易输出)和 SegWit 类型的 UTXO无法在同一笔交易中花费:这种情况下,传统类型的 UTXO 将在输入(脚本签名栏位)内载入所有权证明,而隔离见证类型的 UTXO将在交易输入以外的结构中载入证明。
不管怎么说,隔离见证的定位是一个软分叉,这个升级应该是可以忽略,无需强制的,而且,这也意味着,未升级的节点应该可以处理隔离见证类型的输出。
实际上,旧的节点和钱包将以为任何人都能花费这些 UTXO,也即这些 UTXO是空签名也可花费的,因此即使在交易中没有看到签名,交易也仍然是有效的。而升级后的节点和钱包将在交易输入以外的地方,一个专门的 「witness」 栏位寻找签名。
我们用例子来说明一下隔离见证会如何改变交易的资料结构。从标准的 Pay-to-Public-Key-Hash (P2PKH) 交易类型开始。
我们感兴趣的部分是输出,尤其是其 「scriptPubKey」 栏位(锁定脚本栏位)。我们先考虑一种标准的锁定脚本:
1 OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
而隔离见证之后的锁定脚本如下所示:
1 0
如你所见,隔离见证的输出比传统类型的输出要简单很多:只有两个值会被推入脚本执行栈中。
如我们上面说得,旧版本的比特币客户端会以为这个输出是掉在地上的钱—— 无需提供签名就能花费这个输出。不过,新的客户端会将第一个数字解释为版本号,而第二个则对应着一个锁定脚本(witness 程序)。
在现实中,只有压缩公钥(compressed public key)的杂凑值可以用在这里。这一点我们后面再说。
再来看看这个输出被花费时的情形。传统交易的输出在花费时的数据结构如下:
1 ...2 "Vin" : 3 {4 "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",5 "vout": 0,6 "scriptSig": ""7 }89 ...
但是,在花费一个隔离见证输出的时候,交易的 scriptSig 将为空,而所有的签名都会放到一个专门的地方:
1 ...2 "Vin" : 3 {4 "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",5 "vout": 0,6 "scriptSig": ""7 }89 ...10 "witness": ""11 ...
虽然传统的客户端可以处理隔离见证的交易(再次提醒,他们会把这些输出当成人人都可以花的钱),但他们自己没法花这些钱:旧型的钱包可能会尝试用空签名来花用一个隔离见证的输出,但这笔交易在现实中是无效的(更新之后的节点不会允许这样的交易上链)。
这就意味着,发送者必须知道接受方的钱包支不支持隔离见证,这样才能为之创建合适类型的输出。
由 BIP-143定义,隔离见证的输出应该用压缩公钥的杂凑值来创建。如果你用的是传统类型的地址或者非压缩公钥的杂凑值,这个输出将变得不可用(你的币就会锁死)。
另一个关键的交易类型是 P2SH。它让交易可以发送给脚本的杂凑值(而非公钥的杂凑值,也即比特币地址)。要花费 P2SH交易的输出,花费者需要提供一个脚本(叫做「赎回脚本」),其杂凑值应该与 UTXO 中的脚本杂凑值匹配,并基于这个脚本提供签名/口令/别的东西。
这个用法可以把解锁脚本保护起来,让发送者无从知晓一个地址的内容,并且也能节约空间:举个例子,一个多签名钱包的锁定脚本可能非常长,这样我们就必须把整个锁保存起来;有了 P2SH 可以只保存一个杂凑值。
假设现在有一个需要提供 5 个私钥中的 2 个签名才能使用的多签名钱包。如果你使用传统的交易,P2SH 交易输出的锁定脚本将如下:
1 HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL
要花费的时候,花费的人(也是上一笔交易的接收方)需要提供一个赎回脚本,这个脚本定义了花费条件(多签名,2-5),还有两个签名。所有这些都要放在交易的输入中:
1 ...2 "Vin" : 3 "txid": "abcdef12345...",4 "vout": 0,5 "scriptSig": " <2PubA PubB PubC PubD PubE 5 CHECKMULTISIG>",6
再来看看使用隔离见证后的发送者和接收者。输出的锁定脚本如下:
1 0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73
就像 P2PKH 交易一样,这个输出的脚本也变得更简单。第一个数值表示版本号,第二个是对应于赎回脚本(witness 程式)的 SHA256杂凑值(32位)。
使用这个函数某种意义上是为了用长度来区分 P2WPKH 的见证程式以及 P2WSH 的见证程式(32 位元组的 SHA256 杂凑值 vs. RIPEMD160(SHA256(script)))。
使用这一输出的交易如下所示:
1 ...2 "Vin" : 3 "txid": "abcdef12345...",4 "vout": 0,5 "scriptSig": "",6 7 ...8 "witness": " <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>"9 ...
我们已经看到,使用隔离见证是有好处的。不过,上面的例子只对发送者和接收者都有升级软体的情形才适用。但现实并不总是如此。考虑这样一种情形:
Alice 希望给 Bob 转帐一些 BTC,Bob 有支持隔离见证的钱包软体而她没有。他们显然只能用标准形式的交易,但 Bob 希望使用 SegWit来减少手续费。
这时候,Bob 可以创建一个包含了 SegWit 脚本的 P2SH 地址、Alice 会把这个地址当成一个普通的 P2SH地址,因此可以直接向这个地址转帐而没有任何问题。但 Bob 可以使用 SegWit 交易来使用这个输出,并获得手续费折扣(下文我们会解释 SegWit交易的手续费的新的定价方式)。
这就是 SegWit 交易的两种类型 P2WSH 和 P2WPKH 在 P2SH 内实现的方式。
想在 P2SH 交易中实现一笔 P2WPKH 交易,Bob 需要使用其公钥创建一个见证程序。然后把结果杂凑、转码成一个地址:
1 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7
第一个数值是版本号,而第二个数值是 20 位元组的公开金钥杂凑值。这个脚本先做 SHA256 杂凑运算,再做 RIPEMD160 运算,就可得到一个 20位元组的杂凑值。
这是 P2WPKH 见证程式的H ASH160 结果:
1 3e0547268b3b19288b3adef9719ec8659f4b2b0b
转化成一个地址:
1 37Lx99uaGn5avKBxiW26HjedQE3LrDCZru
发送这个地址的输出的锁定脚本,看起来跟一个普通的 P2SH 地址的脚本一模一样:
1 HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL
那么 Bob 花费输出的时候,交易的结构会像这样:
1 ...2 "Vin" : 3 {4 "txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",5 "vout": 0,6 "scriptSig": "0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7"7 }89...10 "witness": ""11 ...
在一开始,我们创建的赎回脚本(也就是那个见证程式)会经过一次杂凑计算,如果结果符合锁定脚本中的杂凑值,这个脚本就会得到执行,程式会验证放在 witness栏位的签名。
P2WSH 脚本也可以用 P2SH 来实现。我们考虑上面所说的 2-5 多签名钱包的例子。所有的步骤都跟 P2SH (P2WPKH) 没什么区别:
首先,创建一个见证程序:
1 0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73
第一个数值是版本号,第二个数值是 32 位的 SHA256 杂凑值,对应于我们的签名脚本。然后我们拿这个见证程式的 HASH160 杂凑值转成一个普通的 P2SH 地址。要使用发送这个地址输出时,我们需在 scriptSig 栏位公布这个见证程式,在 witeness 栏位提供完整的多签名脚本。
梳理清楚技术的部分之后,我们就可以理解隔离见证的主要优点了。
SegWit 解决的一个关键问题就是比特币交易的「熔融性」,也即比特币交易的 ID 是杂凑值这一点所带来的问题。我们详细说一下。
在以往的比特币交易中,签名是放在交易的输入部分的,协力厂商可以更改签名且不会让交易失效。这使得协力厂商可以在完全不更改交易的「关键」 栏位(比如输入、输出、转帐的数量)的前提下更改交易的 ID(也就是交易的杂凑值)。
这样一来,交易还是有效的,含义也还是一样的,但是有了另一个 ID,这可以用来执行另一种攻击,比如 DoS 攻击(拒绝服务式攻击)。
SegWit 解决了这个问题,因为所有的签名都是放在交易外面的,因此签名的变动不会导致交易的杂凑值变动,也就不会影响交易的 ID。隔离见证还引入了一个专门的标识符,叫做「wtxid」:它是交易和整个 witness 部分的杂凑值,所以如果一笔交易在传播时没有附带任何 witness 数据,交易 ID(txid)就等于 wtxid。
这个解决方案使得我们可以创建一系列前后相继的未确认交易,而无需担心任何风险,这对闪电网路这样的协议来说是非常重要的。(译者注:这里的意思可能是,如果不解决交易熔融性问题,支付通道的参与者就无法快速检索对手有没有把一笔过时的通道交易上链,因为同样内容的交易可能会以完全不同的 ID 出现)。
Witness 数据往往是交易数据中占比最大的一部分。在使用多签名脚本的交易中,witness 最多可能占据交易数据量的 75%。感谢 SegWit,签名的传输变成了一个可选项:只有节点想要验证交易时,才需要请求这些数据。
而没有支援 SegWit 的 SPV(简易支付验证)客户端和节点也无需下载额外的数据,可以节省硬碟空间。
SegWit 类型的交易比以往的交易类型更便宜,因为它减少了需要储存的 witness 数据。准确来说,「Size」(数据量大小)的概念在 SegWit类型的交易上略有不同。
它引入了一个「虚拟大小(virtual size)」 的概念:所有放在 witness 部分的数据都会乘以 0.25来计算数据量大小,从而一个区块中可以塞进更多的交易。来看一个例子。
假设我们有一笔传统类型的交易,数据量大小为 200 位元组。那么 1MB 的区块里面可以放进 5,000 笔这样的交易。而一笔等效的 SigWit 交易有 120 位元组是放在 witness 区域的,因此其虚拟大小为 80 + 0.25 * 120 = 110 位元组,所以区块可以放入 9,090笔这样的交易。如果上链的手续费是每位元组 40 聪,则交易费会从 8,000 聪减低到 4,400 聪,几乎打了对折。(译者注:「聪」 为比特币的数量单位,是 BTC 的亿分之一。)
你可能已经注意到了,每个锁定脚本都会有 1 个位元组来表示脚本的版本。使用不同的版本号就能以软分叉的形式增加或变更功能(语法改变、新的操作符,等等)。
隔离见证也优化了签名演算法的效率(如 CHECKSIG、CHECKMULTISIG,等等)。在 SegWit之前,杂凑计算的次数与签名数量的平方成正比,但有了隔离见证后,演算法的计算复杂度就减低到了 O(n) (与签名的数量成正比)。
如果百利而无一害,怎么还有人会觉得有问题呢?比特币社群有许多人反对这一升级,因为,即使它有这么多长处,它也有一些缺点。我们来看看反对方提出的一些意见。
因为 SegWit 是一个软分叉,许多客户端可能不会升级,因此两种类型的 UTXO 会在网路中同时存在;诸如消除交易 ID熔融性以及杂凑计算次数线性上升这样的重大变更对非 SegWit 输出无效,因此网路仍会暴露在交易 ID 熔融性和杂凑时间平方级上升的风险中。
SegWit 会降低网路的安全性,执行完全验证的节点会大幅减少,因为只有那些适配了 SegWit 的节点才有能力验证交易的 witness 部分。
SegWit 不能被废除。如果废除了它,所有变更都撤销,那么所有的 SegWit 输出就会变成大街上任人捡拾的钱。
SegWit 希望一次解决所有问题,也正因此,它导致了大量的原始码改动。它会让未来的工作负荷更重,而且提高了出现驱之不去的软体 bug 的机会。
虽然由 SW 解决的问题很有可能有更优雅的解决方案,我们仍然相信,在当前,这是提高网路的可扩展性并开启闪电网路等技术实现的最佳办法。
LINE 与 Messenger 不定期为大家服务
Leave a Reply