詳盡解釋隔離見證

比特幣的可擴展性問題是其面臨的主要問題之一，也是許多人努力的方向。比如說，有個設想是 “閃電網絡”；但是，要在比特幣網絡中實現閃電網絡，條件似乎還不具備，因為比特幣自身的一些缺陷。另一個解決方案 “隔離見證（Segregated Witness）” 也致力於提高可擴展性，但它同時也解決了許多問題，包括閃電網絡實現所需修補的一些缺陷。本文中我們會講解隔離見證的優勢及其工作原理。

隔離見證（SegWit）是一個由多個 BIP（141、142、143、144 和 145）描述的軟分叉，其主要用意是優化比特幣交易和區塊的結構，將交易的籤名（也叫 “腳本籤名（scriptSig）”、“witness” 或 “解鎖腳本”）從交易中移到一個獨立的結構中。它不僅允許降低比特幣交易的數據量大小（因此能讓一個區塊塞下更多的交易），也能解決 “交易熔融性（transaction malleability）” 問題（也就是我們开頭提到阻礙閃電網絡實現的缺陷），對支付通道和閃電網絡這樣基於比特幣交易結構的技術來說極為關鍵。

隔離見證如何工作

在开始之前

我們先要簡單回顧一下比特幣的支付系統。它並不像銀行那樣，是一套账戶和余額的列表。相反，每個比特幣地址的余額都是由一系列發送給這個地址的交易來表示的；交易這一數據結構的主要部分就是輸入和輸出。輸入是我們想要花費的前序交易（准確來說，輸入不會是完整的一筆交易，而是某筆的輸出，因為我們可能會在一筆交易中將資金轉往多個地址），而交易的輸出就是我們的資金發送的目的地址。下圖展示了比特幣交易的結構：

輸出中的 PubKey Script 字段（下文簡稱為 “scriptPubKey”）就是我們所說的 “鎖定腳本”。它用來保證只有接受地址的所有者才能使用這個支出。Signature Script 字段（下文簡稱為 “scriptSig”）也就是所謂的 “解鎖腳本”，因為它是用來打开鎖定腳本的鑰匙，是用來證明地址所有權的。

（編者注：這裏有一個 gif 動圖，展示了比特幣的堆棧是怎么執行的，但微信公衆號推文中無法顯示。強烈建議到網站上觀看。）

有關比特幣交易和鎖定腳本、解鎖腳本功能的更多細節，可看此處。

後向兼容性

實際上，隔離見證不僅改變了交易的結構，也改變了交易的輸出。不過，這不是說傳統類型的 UTXO（未花費的交易輸出）和 SegWit 類型的 UTXO 無法在同一筆交易中花費：這種情況下，傳統類型的 UTXO 將在輸入（腳本籤名字段）內加載所有權證明，而隔離見證類型的 UTXO 將在交易輸入以外的結構中加載證明。

不管怎么說，隔離見證的定位是一個軟分叉，這個升級應該是可以忽略，無需強制的，而且，這也意味着，未升級的節點應該可以處理隔離見證類型的輸出。實際上，舊的節點和錢包將以為任何人都能花費這些 UTXO，也即這些 UTXO 是空籤名也可花費的，因此即使在交易中沒有看到籤名，交易也仍然是有效的。而升級後的節點和錢包將在交易輸入以外的地方，一個專門的 “witness” 字段尋找籤名。

案例

Pay-to-Witness-Public-Key-Hash

我們用例子來說明一下隔離見證會如何改變交易的數據結構。從標准的 Pay-to-Public-Key-Hash (P2PKH) 交易類型开始。

我們感興趣的部分是輸出，尤其是其 “scriptPubKey” 字段（鎖定腳本字段）。我們先考慮一種標准的鎖定腳本：

而隔離見證之後的鎖定腳本如下所示：

如你所見，隔離見證的輸出比傳統類型的輸出要簡單很多：只有兩個值會被推入腳本執行棧中。如我們上面說得，舊版本的比特幣客戶端會以為這個輸出是掉在地上的錢 —— 無需提供籤名就能花費這個輸出。不過，新的客戶端會將第一個數字解釋為版本號，而第二個則對應着一個鎖定腳本（witness 程序）。在現實中，只有壓縮公鑰（compressed public key）的哈希值可以用在這裏。這一點我們後面再說。

再來看看這個輸出被花費時的情形。傳統交易的輸出在花費時的數據結構如下：

但是，在花費一個隔離見證輸出的時候，交易的 scriptSig 將為空，而所有的籤名都會放到一個專門的地方：

雖然傳統的客戶端可以處理隔離見證的交易（再次提醒，他們會把這些輸出當成人人都可以花的錢），但他們自己沒法花這些錢：舊型的錢包可能會嘗試用空籤名來花用一個隔離見證的輸出，但這筆交易在現實中是無效的（更新之後的節點不會允許這樣的交易上鏈）。這就意味着，發送者必須知道接受方的錢包支不支持隔離見證，這樣才能為之創建合適類型的輸出。

由 BIP 143 定義，隔離見證的輸出應該用 壓縮公鑰 的哈希值來創建。如果你用的是傳統類型的地址或者非壓縮公鑰的哈希值，這個輸出將變得不可用（你的幣會鎖死）。

Pay-to-Witness-Script-Hash

另一個關鍵的交易類型是 P2SH。它讓交易可以發送給腳本的哈希值（而非公鑰的哈希值，也即比特幣地址）。要花費 P2SH 交易的輸出，花費者需要提供一個腳本（叫做 “贖回腳本”），其哈希值應該與 UTXO 中的腳本哈希值匹配，並基於這個腳本提供 籤名/口令/別的東西。這個用法可以把解鎖腳本保護起來，讓發送者無從知曉一個地址的內容，並且也能節約空間：舉個例子，一個多籤名錢包的鎖定腳本可能非常長，這樣我們就必須把整個鎖保存起來；有了 P2SH 可以只保存一個哈希值。

假設現在有一個需要提供 5 個私鑰中的 2 個的籤名才能使用的多籤名錢包。如果你使用傳統的交易，P2SH 交易輸出的鎖定腳本將如下：

要花它的時候，花費的人（也是上一筆交易的接收方）需要提供一個贖回腳本，這個腳本定義了花費條件（多籤名，2-5），還有兩個籤名。所有這些都要放在交易的輸入中：再來看看使用隔離見證後的發送者和接收者。輸出的鎖定腳本如下：

就像 P2PKH 交易一樣，這個輸出的腳本也變得更簡單。第一個數值表示版本號，第二個是對應於贖回腳本（witness 程序）的 SHA256 哈希值（32位）。使用這個函數某種意義上是為了用長度來區分 P2WPKH 的見證程序以及 P2WSH 的見證程序（32 字節的 SHA256 哈希值 vs. RIPEMD160(SHA256(script))）。

使用這一輸出的交易如下所示：

在 P2SH 中嵌入隔離見證

我們已經看到，使用隔離見證是有好處的。不過，上面的例子只對發送者和接收者都有升級軟件的情形才適用。但現實並不總是如此。考慮這樣一種情形：

Alice 希望給 Bob 轉账一些 btc，Bob 有支持隔離見證的錢包軟件而她沒有。他們顯然只能用標准形式的交易，但 Bob 希望使用 SegWit 來減少手續費。

這時候，Bob 可以創建一個包含了 SegWit 腳本的 P2SH 地址、Alice 會把這個地址當成一個普通的 P2SH 地址，因此可以直接向這個地址轉账而沒有任何問題。但 Bob 可以使用 SegWit 交易來使用這個輸出，並獲得手續費折扣（下文我們會解釋 SegWit 交易的手續費的新的定價方式）。

這就是 SegWit 交易的兩種類型 P2WSH 和 P2WPKH 在 P2SH 內實現的方式。

P2SH(P2WPKH)

想在 P2SH 交易中實現一筆 P2WPKH 交易，Bob 需要使用其公鑰創建一個見證程序。然後把結果哈希、轉碼成一個地址：

第一個數值是版本號，而第二個數值是 20 字節的公鑰哈希值。這個腳本先做 SHA256 哈希運算，再做 RIPEMD160 運算，就可得到一個 20 字節的哈希值。

這個 P2WPKH 見證程序的 HASH160 結果：

轉化成一個地址：

發送給這個地址的輸出的鎖定腳本，看起來也就跟一個普通的 P2SH 地址的腳本沒啥區別：

那么 Bob 花費輸出的時候，交易的結構會像這樣：

在一开始，我們創建的贖回腳本（也就是那個見證程序）會經過一次哈希計算，如果結果符合鎖定腳本中的哈希值，這個腳本就會得到執行，程序會驗證放在 witness 字段的籤名。

P2SH(P2WSH)

P2WSH 腳本也可以用 P2SH 來實現。我們考慮上面所說的 2-5 多籤名錢包的例子。所有的步驟都跟 P2SH(P2WPKH) 沒什么區別：

首先，創建一個見證程序：

隔離見證的好處

梳理清楚技術的部分之後，我們就可以理解隔離見證的主要優點了。

交易熔融性漏洞

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 的區塊裏面可以放進 5000 筆這樣的交易。而一筆等效的 SigWit 交易有 120 字節是放在 witness 區域的，因此其虛擬大小為 80 + 0.25 * 120 = 110 字節，所以區塊可以放入 9090 筆這樣的交易。如果上鏈的手續費是每字節 40 聰，則交易費會從 8000 聰減低到 4400 聰，幾乎打了個對折。（譯者注：“聰” 為比特幣的數量單位，是 btc 的億分之一。）

腳本版本

你可能已經注意到了，每個鎖定腳本都會有 1 個字節來表示腳本的版本。使用不同的版本號就能以軟分叉的形式增加或變更功能（語法改變、新的操作符，等等）。

籤名驗證的效率優化

隔離見證也優化了籤名算法的效率（如 CHECKSIG、CHECKMULTISIG，等等）。在 SegWit 之前，哈希計算的次數與籤名數量的平方成正比，但有了隔離見證後，算法的計算復雜度就減低到了 O(n) （與籤名的數量成正比）。

那還有啥問題呢？

如果百利而無一害，怎么還有人會覺得有問題呢？比特幣社區有許多人反對這一升級，因為，即使它有這么多長處，它也有一些缺點。我們來看看反對方提出的一些意見。

• 因為 SegWit 是一個軟分叉，許多客戶端可能不會升級，因此兩種類型的 UTXO 會在網絡中同時存在；諸如消除交易 ID 熔融性以及哈希計算次數线性上升這樣的重大變更對非 SegWit 輸出無效，因此網絡仍會暴露在交易 ID 熔融性和哈希時間平方級上升的風險中。

• SegWit 會降低網絡的安全性，執行完全驗證的節點會大幅減少，因為只有那些適配了 SegWit 的節點才有能力驗證交易的 witness 部分。

• SegWit 不能被廢除。如果廢除了它，所有變更都撤銷，那么所有的 SegWit 輸出就會變成大街上任人撿拾的錢。

• SegWit 希望一次解決所有問題，也正因此，它導致了大量的代碼改動。它會讓未來的工作更加負載，而且提高了出現驅之不去的軟件 bug 的機會。

結論

雖然由 SW 解決的問題很有可能有更優雅的解決方案，我們仍然相信，在當前，這是提高網絡的可擴展性並开啓閃電網絡等技術實現的最佳辦法。更詳細的分析我們放在下一篇文章。

參考文獻

• Lightning network in depth, part 1: payment channels

• “Mastering bitcoin” — Andreas M. Antonopoulos

• Bitcoin Core blog

• Many segwit resources

• Good article about txn malleability

原文鏈接:

https://medium.com/softblocks/segregated-witness-for-dummies-d00606e8de63

作者: Magomed Aliev

翻譯: 阿劍

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。