隔離見證的成本與風險

概覽

• 簡介
  • 目的
• 序列化成本
  • 理由
  • 未來減少
• 區塊驗證成本
• 引入錯誤的風險
  • 避免
  • 減輕
• 與複雜性和技術債務相關的風險
  • 避免
  • 減輕
• 與軟分叉部署相關的風險
  • 避免
• 由於更大的區塊而產生的風險
  • 避免
  • 減輕
• 由於較低費用而產生的風險
  • 避免
  • 減輕
• 與長期擴展相關的風險
  • 避免
  • 減輕
• 替代方法
  • 硬分叉的 segwit
  • 更簡單的 segwit

簡介

本文是先前關於隔離見證好處文章的補充，概述了透過 BIP141 啟動隔離見證可能產生的技術成本和風險。

目的

在本文中，我們將使用成本來描述如果部署和啟動 segwit 一定會發生的負面結果，使用風險來描述可能不會發生的負面影響，或並非每個人都認為是負面的變更。

在分析風險時，我們考慮為避免風險而採取的步驟（即最小化其發生的機會），以及為減輕風險而採取的步驟（即如果確實發生，如何最小化負面影響）。

本文不嘗試就好處是否超過成本或是否應該部署或啟動 segwit 得出結論，而是透過提供背景資訊來協助利害關係人做出明智的決策。

序列化成本

交易和區塊資訊序列化有三個主要目的：

1. 跨點對點網路傳輸；

2. 將區塊鏈儲存在磁碟上；以及

3. 評估區塊限制。

Segwit 以兩種方式影響序列化：

• 見證承諾包含在 coinbase 交易中，新增 38 到 47 位元組，約為區塊的 0.005%。（參見 BIP 141 - 承諾結構）

• 定義了一個包含隔離見證資料的新交易序列化（參見 BIP 141 或 BIP 144）。這為每個交易新增了 2 位元組的額外負擔，以允許輕鬆區分序列化格式，並為每個輸入的見證項目計數新增了 1 位元組的額外負擔。這些結合起來約為每個交易的 1%。

segwit 交易格式（參見 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 編碼，以便不支援 segwit 的舊錢包可以發送可以使用 segwit 花費的資金，允許接收者獲得 segwit 的好處。

沒有這兩個因素，額外負擔在 P2WPKH 的 -3 位元組和 P2WSH 的 +1 位元組時可以忽略不計。

第一個因素背後的動機在透過 pay-to-script-hash (P2SH) 增加多重簽名的安全性下討論。

第二個因素是個別使用者在發布接收地址時可以做出的權衡，選擇 P2WPKH/P2SH 或 P2WSH/P2SH 的使用者將按額外負擔的比例支付更高的費用。這應該會在長期內自然限制這種額外負擔的影響。

未來減少

透過變更網路和儲存序列化格式，可以使這種額外負擔的大部分消失：完整序列化可以從指示正在使用哪種格式的簡單標誌（P2PKH、P2WPKH、P2WPKH/P2SH 等）以及實際資料（公鑰和簽名）中恢復。（例如，compacted_txn.txt）

區塊驗證成本

使用 segwit，在驗證區塊時引入了額外的處理，以檢查見證默克爾樹和處理 P2SH 編碼的見證交易。這需要每個交易大約五個額外的 SHA256 雜湊，每個 P2SH 編碼的 P2WSH 輸入一個額外的 SHA256，每個 P2SH 編碼的 P2WPKH 輸出一個額外的 HASH160。然而，這僅相當於對最多 4MB 資料進行大約六次 SHA256 執行，或總共大約 24MB 的 SHA256 資料，這在 Raspberry Pi v1 上應該轉化為每個區塊最多額外 15 秒，或在更強大的硬體上不到 1/10 秒。

引入錯誤的風險

segwit 補丁集是對 Bitcoin 的重大變更，並在 Bitcoin Core 0.13.0 中推出，儘管未在主 Bitcoin 網路上啟動。任何這樣的重大變更都會帶來各種風險，包括：

• 徹底的錯誤：設計或實作中可能犯錯誤，產生意外或有害的結果。例如 PR#8525。

• 使用者錯誤：對系統的變更可能導致使用者混淆，導致系統的不正確使用，這反過來可能導致有害的結果。

• 生態系統互動：Bitcoin 生態系統的不同部分可能有硬編碼的假設，這些假設將隨著更新而被違反。例如，解析 bitcoind 的區塊儲存的應用程式將需要更新以理解新的序列化。

避免

為了減少 segwit 啟動時這些風險發生的機會，已採取以下步驟：

• 同儕審查：segwit 中的所有變更，包括設計和實作，都已公開展示並由多位獨立專家審查；通常會導致建議的改進被採納。

  公開展示包括：

  • Elements Project
  • Scaling Bitcoin 香港
  • SF Bitcoin Devs
  • Scaling Bitcoin 米蘭
  • BIP141、 BIP142、 BIP143、 BIP144 和 BIP145

  技術審查包括：

  • PR#7910
  • PR#8149
  • 開發分支拉取請求
  • Bitcoin Core 蘇黎世會議
  • Peter Todd 的審查

• 測試案例：如下一步文章中所述，「對共識規則和 P2P 網路程式碼的組合變更包含 1,486 行新增或修改的程式碼。segwit 補丁還包括單元和整合測試中的額外 3,338 行新增或修改的程式碼，這些測試有助於確保 segwit 在 Bitcoin Core 程式的每次完整建置時都能按預期運作。」

• 測試網路：在開發期間，隔離見證已部署在多個測試網路上，允許程式碼被審查，並且來自更廣泛生態系統的開發者（例如區塊瀏覽器和錢包）確保他們的軟體與隔離見證正確互操作。這些測試網路包括：
  • Elements Project – 測試了作為硬分叉實作的隔離見證概念，以及許多其他變更
  • segnet1 到 segnet4 – 在 2016 年 1 月至 5 月期間測試了 segwit 作為軟分叉的實作
  • testnet3 – segwit 於 2016 年 5 月在標準測試網上啟動
• 替代實作：segwit BIP 已在 btcd（Go）和 Bcoin（Javascript）中重新實作，以及在各種錢包和程式庫中。獨立重新實作有助於消除設計中未明確的假設和模糊性，並避免可能由此產生的錯誤。

減輕

減輕任何錯誤影響的一個主要因素是 segwit 作為軟分叉實作。這意味著：

• Bitcoin 的使用者可以簡單地避免使用新引入的功能，直到他們個人確信它們被正確實作，而不會失去任何功能。

• 所有有效的 segwit 區塊對於 pre-segwit 軟體也是有效的區塊，因此可以使用不包含 segwit 變更的早期版本 Bitcoin（因此不包含這些變更中引入的任何錯誤）來驗證區塊，以提供針對共識回歸可能性的第二級保證。

此外，「腳本」語言版本控制的可能性引入了修復 Bitcoin 腳本語言中錯誤的可能性，包括預先存在的錯誤以及 segwit 可能引入的任何潛在新錯誤。

與複雜性和技術債務相關的風險

技術債務的概念是，現在的簡單修復可能會在長期內造成足夠的困難和問題，以至於現在花更多的時間和精力將證明更經濟。

在 Bitcoin 的背景下，有兩種類型的技術債務：

• 醜陋或複雜的程式碼，可以在不影響使用者或共識的情況下重構；以及
• 不良的設計決策，其中許多必須無限期保留，否則 Bitcoin 使用者將失去對其現有代幣的存取權。

避免

如上所述，segwit 程式碼已經過大量審查，這有助於抵制在程式碼和設計層面引入技術債務。

同樣如上所述，segwit 有多個獨立的重新實作，這有助於在仍可避免的時候發現任何不必要的複雜性和技術債務。

為了支援現有的透過重構和改進 Bitcoin 程式碼庫來償還技術債務的努力，segwit 作為僅程式碼更新合併，作為0.13.0 版本工作的一部分。

減輕

Bitcoin 已經遭受了一些重大的設計債務，segwit 專門設計用於減少這些債務的影響（特別是交易可塑性、簽名雜湊的二次方擴展和未簽名的輸入值）。

segwit 提供的腳本版本控制方法提供了一種優雅的方式，允許未來的軟分叉更新進一步減少設計債務，包括透過修復現有操作碼中的錯誤（例如 CHECKMULTISIG）、重新啟用停用的操作碼（例如 CAT），或切換到優越的驗證方法（例如 Schnorr 簽名或聚合簽名）。

一般來說，Bitcoin 腳本中的設計債務無法完全償還，因為總是有可能存在一些未花費的交易支付到利用「醜陋」功能的 P2SH 地址。停用這些功能將使這些交易無法花費，實際上從使用者那裡竊取資金。腳本版本控制允許減少這種設計債務的「成本」，透過將這種「醜陋」功能劃分為僅適用於「舊」腳本版本，從而允許新的開發工作在很大程度上忽略舊程式碼。

與軟分叉部署相關的風險

軟分叉是對 Bitcoin 共識規則的任何變更，使先前有效的某些交易集無效。處理不當的軟分叉可能在 Bitcoin 生態系統中造成許多問題，並且，因為 segwit 使額外的見證資料對於建立 Bitcoin 的分散式共識至關重要，處理不當的升級可能導致系統以額外的方式失敗。主要的潛在失敗模式包括：

1. 使某些 Bitcoin 持有者無法花費他們的錢
2. 導致舊節點和升級節點對哪些未確認交易有效且可能被挖掘有不同的看法
3. 礦工錯誤地挖掘在新規則下無效的區塊
4. 被啟動，有一些實際使用，然後被撤回
5. 由於 p2p 網路實際上被斷開連接，導致大型區塊鏈分叉，因為透過無法轉發見證資料的舊節點的連接

避免

Bitcoin 中已經啟動了許多軟分叉（包括 BIP 16、34、65、66、68、112 和 113），這種經驗已被編纂在啟動軟分叉的 BIP9 流程中。BIP9 流程用於部署 CSV 軟分叉（BIP 68、112 和 113），並導致該變更的共識規則快速且無問題的升級。

segwit 設計和 BIP9 部署透過以下方式避免了上述問題：

1. segwit 施加的新限制僅影響目前沒有人會使用的交易，因為：

   • 受影響的交易將是非標準的，因此不會被絕大多數節點中繼或被大多數礦工挖掘。

   • 任何受影響的交易目前都會被視為明顯的「任何人都可以花費」付款，並且可以立即被任何監控區塊鏈的人領取，因此應該預期會「丟失」。

2. 舊節點將認為花費 segwit 輸出的交易是非標準的，因為明顯違反了 BIP62 CLEANSTACK 規則，因此不會被包含在舊節點的 mempool 中。同樣，具有 P2WPKH 或 P2WSH 輸出（但不是透過 P2SH 編碼的 P2WPKH/P2WSH）的交易也將被視為非標準，因為它是新的輸出類型。

   這使得透過舊節點中繼一個交易並透過 segwit 節點中繼不同的交易來實現 segwit 輸出的雙花變得不可能。

   然而，這些差異仍然可能被用於嘗試雙花，例如透過在單個交易中組合非 segwit 輸出和 segwit 輸出（該交易將僅透過升級的 segwit 節點中繼），然後嘗試透過僅使用非 segwit 輸出的更高費用交易進行雙花，該交易可能透過舊節點成功中繼。

   這些擔憂僅影響 mempool 中的未確認交易；一旦交易被確認並挖掘到區塊中，雙花仍然不可能。現有的監控雙花的方法應該保持同樣有效，前提是監控工具能夠完全追蹤 segwit 花費。

3. 確保礦工挖掘有效區塊顯然是每個人的高度優先事項，並且已經投入了大量工作來保證 segwit 的情況如此。這包括 BIP145 下的直接工作，以及間接工作，例如緊湊區塊（BIP152）。

4. 如果 segwit 軟分叉在啟動後被撤回，這可能允許任何進行 segwit 交易的人損失資金 – 例如，惡意礦工可以在沒有啟用 segwit 的鏈上重播交易，此時它將是任何人都可以花費的，然後礦工可以透過將其花費給自己來竊取資金。segwit 軟分叉在啟動後可以透過兩種方式撤回，同時允許竊取啟用 segwit 的交易：

   • 礦工可以放棄啟用 segwit 的鏈，並從 segwit 啟動之前開始挖掘。基於 BIP9 啟動規則，這將需要放棄超過 2016 個區塊（LOCKED IN 期間，加上足夠的區塊以確保未達到 95% 的閾值）。這將要求礦工放棄超過 25,200 BTC 的區塊獎勵，按當前價格計算超過 15,000,000 美元。

   • 礦工可以簡單地使用不識別 segwit 規則的軟體（例如 Bitcoin Core 的早期版本）在啟動了 segwit 的鏈頂部挖掘區塊。就 segwit 感知軟體而言，這將是硬分叉，因此使用 segwit 感知驗證節點的 Bitcoin 使用者將忽略這些區塊。如果有足夠多的使用者使用 segwit 節點，這樣的硬分叉將不會比引入新的 alt coin 更有效。

   因此，這兩種方法似乎都不太可能。

5. 已經投入了大量工作以確保啟用 segwit 的對等方將形成 Bitcoin P2P 網路的強連接子圖。這包括為啟用見證的節點提供專用的服務位元，並優先連接到這些節點。

由於更大的區塊而產生的風險

Segwit 將 1MB 區塊大小限制更新為 4M 單位區塊權重限制，將序列化的見證資料計為一個單位，將核心區塊資料計為四個單位。隨著使用 segwit 功能的交易開始被使用，此變更將允許每個區塊包含更多資料（如果 100% 的交易使用 segwit 功能，預計每個區塊約 2MB 資料，但在最壞的情況下可能高達每個區塊 4MB 資料）。就其允許更大的交易量而言，可以預期它將更快地增加 UTXO 資料庫（如果 100% 的交易使用 segwit 功能，增長率可能預期大約翻倍；但是因為 segwit 是軟分叉，最壞情況的 UTXO 增長是不變的）。

這些結果可能有積極的屬性（例如更多的交易量允許更多的使用者採用），但也有可能顯著的負面影響：

• 更大的區塊可能導致更慢的區塊傳輸，導致礦工的孤塊率更高 – 這反過來可能導致更低的安全性（控制網路所需的雜湊算力更少），或更高的中心化（較大的礦工更能夠降低其孤塊率）。

• 更大的區塊將導致完整節點的資源需求更高，可能導致使用者關閉他們的節點，這將導致更高的中心化。

• 更大的 UTXO 集將導致礦工的資源需求更高，可能導致礦工共享驗證資源，這將導致更高的中心化。

避免

更大區塊的負面影響以多種方式受到限制：

• 由於部署 libsecp256k1，區塊的驗證時間已顯著減少。

• 透過 BIP152 部署緊湊區塊有助於限制更大區塊對區塊傳輸的影響，因此對孤塊率的影響，也減少了完整節點的頻寬使用。

• 剪除支援允許使用者執行完整節點而無需儲存整個區塊鏈歷史，這允許資源受限儲存的使用者繼續執行完整節點，即使區塊大小更大。

• segwit 簽名使用的簽名雜湊演算法的變更以避免二次方擴展，為某些大型交易提供了成本的顯著降低。

增加的 UTXO 增長的負面影響受到以下限制：

• 將 segwit 部署為軟分叉，以確保最壞情況的 UTXO 增長不會變得更糟。

• 見證資料的權重降低以重新平衡 UTXO 的生命週期成本，降低引入花費 segwit 輸出的額外輸入的成本，因此（相對地）增加引入建立新 UTXO 的額外輸出的成本，將建立/花費成本比率從約 1:4.5 變更為約 1:2。這應該透過阻止 UTXO 建立和鼓勵 UTXO 花費來適度減少增加 UTXO 集的激勵。

減輕

• 由於每個區塊的最大資料量上限為不超過當前速率的四倍，因此解決大型區塊引起的問題的減輕工作應該在相對直接的工程工作範圍內。此外，由於預期每個區塊的資料量僅約為當前速率的兩倍，這意味著任何必要的減輕努力應該進一步簡化。

• 正在進行的工作是改進交易和區塊的磁碟和網路序列化，進一步減少執行完整節點的儲存和頻寬需求。

由於較低費用而產生的風險

Bitcoin 區塊鏈的安全性由雜湊算力提供，該算力由固定的區塊獎勵和來自個別交易的費用獎勵。因此，費用收入的減少有可能減少用於挖掘 Bitcoin 的雜湊算力，這反過來可能降低 Bitcoin 區塊鏈的安全性。

就個別交易費用由市場力量和供需決定而言，segwit 引入的變更可能透過增加供應（假設需求不會也上升，無論是因為還是至少與 segwit 部署同時）來降低價格的風險，較低的個別價格可能導致較低的整體挖礦收入（如果需求的價格彈性在非彈性範圍內）。

此外，segwit 中所做的變更可能使「第二層」解決方案（例如閃電網路）更具吸引力。如果這導致使用者將第二層解決方案視為鏈上交易的替代品，這可能會顯著降低對鏈上交易的需求，這將對交易費用水平施加額外的下行壓力。

避免

費用目前約為每個區塊 0.5 BTC，而區塊補貼為每個區塊 12.5 BTC，約為礦工收入的 4%，因此對礦工收入的潛在影響以及網路安全性在短期內可能很小。

此外，在過去十二個月中，費用在 BTC 計價值（從一年前的每個區塊不到 0.2 BTC）和實際價值（從一年前的每 BTC 不到 300 美元到今天的每 BTC 超過 600 美元）方面都在上漲，因此費用水平的適度下降只會相當於回到最多十二個月前的費用收入，這應該不會是重大影響。

減輕

礦工能夠個別和集體限制供應，無論是透過個別設定他們生產的區塊的最大權重的軟限制（「blockmaxweight」設定，預設為 3M），還是透過集體使用軟分叉透過孤立超過特定權重的區塊來有效降低共識限制。這種方法有可能防止由於供應增加而導致的任何費用減少（或者確實透過減少供應來增加個別費用，儘管這可能不會增加整體收入），但無法防止由於替代效應（例如採用第二層網路）而導致的費用收入減少。

雖然第二層網路可能充當鏈上交易的替代品，但它們無法完全避免鏈上交易，在某些情況下，即使來自第二層網路的這些相對較少的鏈上交易也可以輕易地在啟用 segwit 的情況下飽和鏈上容量。即使只有這些網路價值的非常小的一部分透過鏈上交易費用捕獲，這也可能大大高於當前的費用價值。

與長期擴展相關的風險

如上所述，所有交易完全採用 segwit 預計將容量大約翻倍。這在短期或中期提供了顯著的一次性容量增加，取決於採用速度。此外，透過新增功能以啟用第二層網路，可能實現一些額外的中期和長期擴展。透過修復二次方 sighash 擴展錯誤，segwit 還減少了由於未來容量增加而產生負面影響的風險。

然而，segwit 並沒有提供任何直接機制來進一步擴展鏈上交易量，除了那一次性的翻倍。

這存在長期擴展方法可能被阻止或延遲的風險：利害關係人可能認為 segwit 是「足夠的」擴展並拒絕進行或支援進一步的擴展努力。

避免

避免這種風險的努力包括：

• 在 2015-12-07 容量增加路線圖中納入「適度區塊大小增加提案」
• 在同一路線圖中納入「彈性上限或激勵一致的動態區塊大小控制」。
• 在 segwit 中包含功能以使後期擴展風險更低，特別是簽章操作的線性擴展和邁向單一組合區塊限制。
• 研究更有效地使用區塊空間的技術，例如使用 Schnorr 簽名和簽名聚合
• 研究區塊鏈的替代模型，維持去中心化和安全性，但具有更好的可擴展性屬性，例如 Mimblewimble、Braiding 和 Jute Braiding。

此外，使 segwit 允許的規模增加可實現的工作（例如 libsecp256k1 和緊湊區塊）顯然也使進一步的潛在規模增加更可實現。

減輕

Segwit 在任何技術層面上都沒有使進一步的擴展更加困難 – 這裡的風險完全是社會性的。因此，最有效的減輕努力也可能是社會性質的：例如透過讓支援長期擴展的公司投入開發資源來實現這一點。

segwit 使交易量增加到大約當前水平的兩倍也提供了展示擴展的實際影響的機會，例如對節點效能、去中心化和交易需求的影響，以及生態系統升級可以進行的速度。這些資料可以合理地收集並用於支援未來的擴展努力，無論是透過顯示某些擔心的結果不太可能發生，還是透過確認有效的擔憂並允許工作集中於解決這些擔憂。

替代方法

本節提供與實現 segwit 的部分或全部好處的一些替代方法的簡要比較，以及這些不同方法如何可能改變所涉及的成本和風險。

硬分叉的 segwit

任何 segwit 的硬分叉實作都會增加顯著的新成本和風險，因為需要所有節點在啟動之前升級以理解新規則，並有可能分叉成「舊 Bitcoin」和「新 Bitcoin」，從而導致混淆和價值損失。由於 Bitcoin 社群對硬分叉的經驗相對缺乏，可能還會出現意外的風險和成本，儘管這顯然很難分析。

segwit 的硬分叉實作實際上可以以兩種方式進行：

1. SPV 不可見：如果見證承諾從 coinbase 移至區塊交易默克爾樹，大多數非驗證客戶端和錢包將繼續工作而無需升級。這將節省 coinbase 交易中的 38-47 位元組，但不提供任何其他優勢。

2. SPV 可見：如果變更交易雜湊的計算以排除 scriptSig，這可能允許更簡單的實作，並減少每個交易的額外負擔；然而，它將使所有現有的 Bitcoin 軟體在更新之前無法處理這些交易。此外，需要保留管理舊式交易的單獨程式碼路徑，增加程式碼複雜性和錯誤的可能性。BIP 134，彈性交易 提出了一種替代方法，透過 SPV 可見的硬分叉獲得 segwit 的一些好處。

任何一種硬分叉方法都可能同時大幅改變區塊的共識限制。

更簡單的 segwit

segwit 的許多好處在邏輯上可以分為獨立的變更，並單獨評估和部署。然而，各種功能的實作需求密切相關：

• 簽章操作的線性擴展：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。
• 輸入值的簽名：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。
• 透過 P2SH 增加多重簽名的安全性：P2SH 支付格式需要替換。
• 腳本版本控制：P2SH 支付格式需要替換。

獨立進行這些修復將增加 Bitcoin 程式碼庫的複雜性，因為需要處理在區塊鏈上的不同時間啟動不同功能；而同時部署它們則消除了這種複雜性。

因為由於現有 CHECKSIG 和 CHECKMULTISIG 操作碼的簽章操作的二次方擴展，增加容量是危險的，因此需要對這些操作施加一些限制。由於 segwit 僅允許透過更新的操作碼增加簽名操作，舊操作碼自然保持受限。相反，如果獨立應用容量增加，則需要實作額外的限制以確保增加是安全的，可能會增加挖礦和費用計算的複雜性。