大約兩周后，比特幣將迎來它最重要的技術升級之一：Taproot。
什麼是Taproot？維基百科上給出的普通定義是：
“主根（taproot）是一個大的、中心的、佔優勢的根，而其它的根會從其側面發芽。通常，主根有些直，然後形狀逐漸變細，並直接向下生長。在例如胡蘿蔔這樣的植物中，主根是一種非常發達的貯藏器官，其已被作為蔬菜栽培。"
那比特幣即將採用的Taproot技術方案到底是什麼？它的名字是如何來的？
比特幣Taproot名字的由來
“我一直認為這個名字的由來是‘利用Merkle根‘，但我實際上並不知道Gregory Maxwell的想法是什麼。’ —— Pieter Wuille（來源）
“我最初不得不查這個詞，但我把它理解成了關鍵路徑，因為它是你製作美味的胡蘿蔔湯的核心，而默克爾化的腳本將是你希望忽略的其他較小的根。” —— Anthony Towns （來源）
而Taproot方案提出者Gregory Maxwell給出的答案則是：
“這個詞起源於一棵樹的形象化，這顆樹的中央有一個像蒲公英主根一樣粗壯的中心（這項技術非常有用，因為假設有一條高概率路徑，其餘的路徑就模糊化了）。我認為這是一個很好的方法，因為它通過利用根中隱藏的commitment來驗證腳本路徑的花費。
……唉，將具有已排序內部節點的哈希樹稱為“桃金娘樹”（Myrtle tree）並沒有流行起來。 （Myrtle tree是包括Melaleuca樹、茶樹（tea-tree）在內的樹家族，這聽起來像'merkle'。:p)”
因此，當談論比特幣taproot時，我們腦海中浮現出來的圖像應該是下面這個樣子的：
來源：SHUTTERSTOCK
Taproot升級對比特幣的影響是什麼？
早在18年初，在Gregory Maxwell提出Taproot方案之後，國內比特幣社區便對該方案進行了早期的報道，當時社區的關注點在於：
“實施taproot升級后，閃電網絡將變得更加私密，這使得LN交易與所有比特幣交易無法區分開來，因此人們將無法區分比特幣的鏈上交易和閃電網絡的鏈下交易”。
而要應用Taproot的前提，是需要先讓Schnorr簽名方案落地。
到了2019年，除了提高比特幣的隱私性之外，Taproot方案又被社區賦予了新的使命 —— 擴展比特幣智能合約的靈活性。也因此，Taproot升級以及Schnorr簽名被提升為“比特幣在下一階段的重要技術”。
2020年1月份，Bitcoin core代碼庫維護者之一Pieter Wuille 正式發布了包含Taproot/Schnorr 軟分叉升級的BIP 340、BIP 341以及BIP 342，由此，這兩個升級提案開始逐漸進入比特幣用戶們的視野。
今年6月份，比特幣全網支持Taproot升級的算力超過了90%，達到了鎖定升級的最低要求，這也意味着 Taproot將在比特幣區塊高度達到709,632（預計將在北京時間11月13日前後）時正式與大家見面。
關於Taproot和Schnorr簽名的一些趣事
1、比特幣最初使用的是ECDSA簽名方案，但實際上Schnorr簽名要比ECDSA簽名更早誕生，我們說Schnorr 簽名是對比特幣原始 ECDSA 簽名的升級，是因為其可以更容易地實現各種密碼學技巧。在時間順序上，Schnorr簽名算法的誕生，要早於ECDSA 所基於的 DSA 算法。而中本聰使用DSA的部分目的是為了規避 Claus Peter Schnorr 的 Schnorr簽名專利，而他的專利在 2011 年到期了。
2、雖然沒有成功，但在比特幣採用Schnorr簽名的早期發展中，有人建議不應將Claus-Peter Schnorr的名字與比特幣關聯起來，因為他的專利導致這種有價值的密碼學技術在20多年的時間裡沒有被廣泛使用。Pieter Wuille曾表示：
“我們確實考慮過用DLS（離散對數簽名）來稱呼BIP340，但我們最終沒有這樣做，因為Schnorr的名字已經被談論得太多了。”
3、Pay to contract：Ilja Gerhardt 和 Timo Hanke 創建了一個名為Pay to contract的協議，該協議由Hanke 在 2013 年的聖何塞比特幣會議上提出，其允許一筆支付承諾其合約的哈希值。任何擁有該合約副本和用於避免某些攻擊的nonce的人，都可以驗證這個承諾（commitment），但對其他人來說，這種付款看起來與其他的比特幣付款類似。
2014 年關於側鏈的論文中包含了對這種pay-to-contract (P2C)協議的輕微改進，其中承諾還包括原始的支付公鑰，而Taproot 使用了相同的結構。
Taproot落地之後，未來可能的比特幣共識改變
那在激活Taproot之後，開發者們會在它的基礎之上對比特幣進行哪些共識層的改進呢？
1、交叉輸入（Cross-input）簽名聚合：Schnorr簽名使幾個不同的公鑰和私鑰對的所有者可輕鬆地創建單個簽名，以證明所有密鑰所有者在創建簽名時都進行了協作。隨着未來共識的變化，這可能允許交易包含單個簽名，該簽名可用於證明在該交易中使用的所有UTXO的所有者已授權使用。在第一次輸入后，這將為每個密鑰路徑（keypath） 花費節省大約 16 虛擬字節（vbytes），從而為整合以及coinjoin節省開銷。它甚至可使基於coinjoin的支出比常規的支出更便宜，從而提供一種溫和的激勵，以鼓勵人們更多地去使用隱私交易。
2、SIGHASH_ANYPREVOUT：每一筆正常的比特幣交易都包含一個或多個輸入，並且這些輸入中的每一個都使用其 txid 引用前一筆交易的輸出。這告訴了全驗證節點（例如Bitcoin Core）這筆交易可以花費多少錢，以及需要滿足哪些條件才能證明支出是經過授權的。為比特幣交易生成簽名的所有方式，無論有沒有taproot，要麼提交到prevout中的txid，要麼根本不牽扯到prevout。對於不想使用精確的預先安排的一系列交易的多用戶協議來說，這是一個問題。如果任何用戶可以跳過特定交易，或更改除witness驗證數據之外的任何交易的任何細節，這將更改任何後續交易的 txid。而更改 txid 會使之前為以後交易創建的任何簽名無效。這迫使鏈下協議實施機制來懲罰任何提交舊交易的用戶（例如 LN 的懲罰機制）。
而SIGHASH_ANYPREVOUT可通過允許簽名跳過提交到prevout txid 來消除這個問題。這使得為閃電網絡（LN） 實施 eltoo 層以及對vault金庫和其他合約協議的改進成為可能。
3、委託（Delegation）和歸納：在你創建一個腳本（taproot或其它）之後，除了將私鑰授予其他人（非常危險），你幾乎無法授權他人使用該腳本。此外，對於想要使用密鑰路徑（keypath）花費加上少量基於腳本條件的用戶來說，可以使taproot變得更經濟。開發者們已經提出了幾種通過歸納和提供簽名者委託來增強 taproot的方法：
（1）Graftroot：在taproot的想法誕生后不久，Graftroot就被提出了，該方案將為任何能夠製作taproot路徑的人提供一項額外的功能。密鑰路徑（keypath）簽名者可以簽署一個腳本，描述資金可使用的新條件，將支出權限委託給任何能夠滿足該腳本要求的人，而不是直接支出資金。簽名、腳本以及滿足腳本所需的任何數據，都將在支出交易中提供。 密鑰路徑（keypath）簽名者可通過這種方式委託給無限數量的腳本，而無需創建任何鏈上數據，直到發生實際支出。
（2）廣義taproot (g’root): 幾個月後，Anthony Towns提出了一種使用公鑰點（public key points）來承諾多種不同支出條件的方法，而不必使用類似 MAST 的結構。這種廣義taproot (g’root)構造“在taproot假設不成立的情況下可能更有效”，此外，它還提供了一種構建軟分叉安全交叉輸入聚合系統的簡單方法。
（3）Entroot：Graftroot和g'root的最新合成方案，它簡化了許多情況，使它們更具帶寬效率。
4、新的和舊的操作碼（opcode）：taproot 軟分叉包含了對tapscript 的支持，它提供了一種向比特幣添加新操作碼的改進方法，即 OP_SUCCESSx 操作碼。一些擬議的新操作碼包括：
（1）恢復舊操作碼：由於擔心安全漏洞，2010 年開發者禁用了一些數學和字符串操作的操作碼。許多開發人員希望在安全審查后重新啟用這些操作碼，並且（在某些情況下）可能會擴展操作碼以處理更大的數字。
（2）OP_CAT：值得特別提及的一個先前禁用的操作碼是OP_CAT，研究人員發現它可單獨在比特幣上實現各種有趣的行為，或者它還能以有趣的方式與其他新操作碼進行組合。
（3）OP_TAPLEAF_UPDATE_VERIFY：當與taproot的密鑰路徑和腳本路徑功能一起使用時，OP_TLUV操作碼能以一種特別高效和強大的方式啟用契約（covenants）。這可用於實現JoinPool、Vault以及其他安全和隱私改進。它還可以與OP_CHECKTEMPLATEVERIFY很好地結合。
注意，以上所有的想法仍然只是提議，沒有人能保證它們會成功應用，這需要研究人員和開發人員完成每一項提案，然後由用戶決定這些功能是否值得去改變比特幣的共識規則。
相關資料：
1、https://bitcoinops.org/en/newsletters/2021/10/27/
2、https://bitcoinops.org/en/newsletters/2021/10/20/
3、https://www.8btc.com/article/223681
4、https://www.8btc.com/article/351969
本文鏈接：https://www.8btc.com/article/6702629
轉載請註明文章出處