偉大的腳本恢復：比特幣的前進之路

首頁
資訊
偉大的腳本恢復：比特幣的前進之路

偉大的腳本恢復：比特幣的前進之路

發表於 2024-05-20 11:00 作者：區塊鏈情報速遞pro

撰文：SHINOBI

編譯：Block unicorn

盡管提案範圍相當廣泛，但 Rusty Russell 的「偉大的腳本恢復」可能是比特幣發展的前進之路的原因是什么？

Block unicorn 注釋：Rusty Russell 是比特幣社區的活躍开發者，在社區中非常受人尊敬。他曾在 Linux 內核开發方面有過卓越的工作，也參與了許多比特幣核心开發項目。

比特幣最初設計時擁有一個完整的腳本語言，旨在涵蓋和支持用戶未來可能提出的任何潛在安全用例。正如中本聰在消失之前所說的那樣：

「比特幣的本質是，一旦版本 0.1 發布，核心設計就被確定爲其余生命周期。因此，我希望設計它來支持我所能想到的每一種可能的交易類型。問題在於，每件事都需要特殊的支持代碼和數據字段，無論是否被使用，這會導致出現過多特殊情況。解決方案是腳本，它將問題概括化，這樣，交易雙方可以用特定條件來描述他們的交易，節點網絡會根據這些條件進行評估或是驗證。」- 中本聰，2010 年 6 月 17 日

他的整個目的是給用戶一個通用到足以讓他們按照自己的意愿組織自己的交易類型的語言。即，給用戶設計和實驗如何編寫他們自己的貨幣的空間。

在他消失之前，中本聰刪除了其中的 15 個操作碼，完全禁用了它們，並且在腳本引擎堆棧上添加了一個硬限制，限制了可以操作的數據塊大小（520 字節）。這是因爲他實際上搞砸了，留下了大量使得復雜腳本可能被用來對整個網絡進行 DOS 攻擊（發送大量垃圾請求，導致網絡癱瘓）的方式，創建了巨大且成本高昂的交易，會導致節點崩潰。

這些操作碼並不是因爲中本聰認爲這些功能是危險的，或者人們不應該利用它們構建能夠實現的東西而被移除的，而僅僅（至少表面上是如此）是因爲它們在沒有資源限制的情況下對整個網絡構成的風險，這樣它們可能在不受限制的情況下對網絡施加的最壞的驗證成本。

從那時起，比特幣的每次升級最終都是對剩余功能的功能優化，糾正中本聰留給我們的其他不那么嚴重的缺陷，並擴展我們剩下的腳本子集的功能。

偉大的腳本恢復

在五月初的奧斯汀比特幣 ++ 大會上，核心閃電網絡开發者拉斯蒂·拉塞爾在會議的第一場演講中提出了一個非常激進的提案，他基本上提出了重新啓用中本聰在 2010 年消失之前禁用的大多數操作碼的想法。

自 2021 年 Taproot（Taproot 是比特幣的一個重要升級，旨在提高隱私性、安全性和可擴展性）激活以來的幾年裏，开發領域實際上有點毫無目標。我們都知道，比特幣並不具備足夠的可擴展性，無法真正爲世界上任何可觀規模的人口提供自我主權的服務，甚至可能無法以最小化信任或托管的方式爲能夠超越非常大的托管機構和服務提供商、無法真正擺脫政府長臂約束的服務提供商提供擴展性。

這篇文章指出了比特幣技術層面上的認識，這不是一個需要爭論的問題。值得爭論的問題是如何解決這個缺陷，這是一個非常有爭議的話題。自從 Taproot 提出以來，每個人都在提出非常狹窄的提案，旨在解決只有特定使用案例才能實現的問題。

例如，ANYPREVOUT（APO）是一個提案，允許籤名在不同的交易中重復使用，只要輸入的腳本和金額相同，這個提案是專門爲了優化閃電網絡和其多方版本而設計的。CHECKTEMPLATEVERIFY（CTV）是一個提案，要求硬幣只能由與預定義交易完全匹配的交易來支出，這個提案是爲了通過使它們完全無信任來擴展預籤名交易鏈的功能而設計的。OP_VAULT 是專門設計用來爲冷存儲方案設置「超時期」，這樣用戶就可以通過將其發送到更冷的多籤設置來「取消」從冷存儲中提取，以防止其密鑰被泄露。

還有很多其他提案，但我想你已經明白了要點。過去幾年來，每個提案都是爲了要么稍微增加可擴展性，要么改進單一的小功能，因爲這被認爲是可取的。這是爲什么這些討論沒有取得進展的根源。沒有人對其他提案感到滿意，因爲它們沒有滿足他們想要看到的使用案例。

除了提案發起者之外，沒有人認爲任何提案是足夠全面的，可以被視爲合理的下一步行動。

這就是「偉大的腳本恢復」背後的邏輯。通過推動並分析對腳本的全面恢復，就像中本聰最初設計的那樣，我們實際上可以嘗試探索我們需要的整個功能空間，而不是爭論和內訌關於現在哪種小型功能擴展足夠好的問題。

OPCODES（操作碼）

OP_CAT：從堆棧中獲取兩個數據，並將它們相加形成一個數據。
OP_SUBSTR：接受一個長度參數（以字節爲單位），從堆棧中獲取一段數據，將該長度的字節移除並放回堆棧。
OP_LEFT 和 OP_RIGHT：接受一個長度參數，從堆棧中獲取一段數據，並從其一側或另一側移除指定長度的字節。
OP_INVERT、OP_AND、OP_OR、OP_XOR、OP_UPSHIFT 和 OP_DOWNSHIFT：接受一個數據元素，對其執行相應的位運算。
OP_2MUL、OP_2DIV、OP_MUL、OP_DIV 和 OP_MOD：數學操作符，用於乘法、除法和取模運算（返回除法的余數）。

除了上面列出的要恢復的操作碼之外，Rusty Russell 還提出了另外三個操作碼，旨在簡化不同操作碼的組合：

OP_CTV（或 TXHASH/ 等效操作碼）：允許對交易的某些部分進行精細化的強制執行，要求這些部分必須與預定義的內容完全一致。

CSFS：允許對籤名進行驗證，不僅限於整個交易，這樣可以要求腳本的某些部分或使用的數據必須進行籤名才能執行。

OP_TWEAKVERIFY：驗證基於 Schnorr 的操作，涉及公鑰，例如從聚合公鑰中添加或減去單個公鑰。這可以用來確保在某個參與方單方面離开共享的未使用交易輸出（UTXO）時，其他所有參與方的資金都被發送到一個不需要離开的參與方籤名就能進行合作支出的聚合公鑰。

我們爲什么要這樣做

第二層網絡本質上是比特幣基礎層的延伸，它們在功能上受到基礎層功能的約束。閃電網絡在實際實現之前需要三個單獨的軟分叉：CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY (CSV) 和隔離見證（Segregated Witness）。

如果沒有更靈活的基礎層，就無法構建更靈活的第二層網絡。唯一的捷徑就是信任第三方，這是非常簡單明了的，我希望我們都渴望盡可能從與比特幣規模化交互的每個方面中移除信任第三方。

我們需要能夠做一些目前無法做到的事情，以便安全地將兩個以上的人合並到一個單一的未使用交易輸出（UTXO）中，並能夠在基礎層上無需信任地執行。比特幣腳本目前的靈活性還不足夠。在最基本的層面上，我們需要契約，我們需要腳本能夠實際強制執行關於執行交易的更精細細節，以確保像一個用戶安全地退出其自己的 UTXO 不會將其他用戶的資金置於風險之中。

在更高的視角上，這就是我們需要的功能：

自身審查（Introspection）：我們需要能夠實際檢查堆棧上有關支出交易本身的特定細節，比如「這筆錢的這部分金額會流向某個輸出的這個公鑰」。這使得我可以使用我自己的特定 Taproot 分支自行提取我的資金，同時確保我無法取走其他任何人的資金。執行的腳本將確保其他所有者的資金，被發送回其他用戶的公鑰組成的地址，以防其他參與者造成資金損失。

前向數據傳遞（Forward Data Carrying）：假設我們進一步發展了比如一個具有大量人的單個 UTXO 的概念，任何人都可以隨意進出。在這種情況下，我們需要一種方式來追蹤誰有多少錢，通常會使用默克爾樹及其根。這意味着當有人離开時，我們必須確保「記錄」誰有權獲得什么作爲其他所有人資金的找零 UTXO 的一部分。這基本上是內省的一個特定用途。

公鑰修改：我們需要確保可以在堆棧上驗證對聚合公鑰的修改。在未使用交易輸出（UTXO）共享方案中，我們的目標是通過一個包含所有參與者的聚合公鑰來促進資金的合作和高效流動。當有人單方面離开共享的 UTXO 時，我們需要從聚合公鑰中刪除他們的個人公鑰。如果事先沒有計算所有可能的組合，那么唯一的選擇就是驗證從聚合公鑰中減去一個公鑰是否會生成由其余個人公鑰組成的有效公鑰。

如何確保安全：VAROPS 正如我上面所說的，禁用所有這些操作碼的原因是爲了解決 DOS 攻擊（通過發送大量垃圾請求，導致網絡崩潰），這種攻擊可以導致組成網絡的節點崩潰。有一種方法可以解決這個問題，就是限制任何這些操作碼可以使用的資源量。

當涉及到籤名驗證時，比特幣腳本中最昂貴的部分，我們已經有了這樣的解決方案，它被稱爲籤名操作（sigops）預算。每次使用籤名檢查操作碼都會消耗一定的「預算」，即每個區塊允許的籤名操作次數，這對於交易可以對用戶產生的驗證一個區塊所需的成本設定了一個硬限制。

Taproot 改變了這種工作方式，它不再使用單一的全局區塊限制，而是每個交易都有自己的 sigops（籤名操作）限制，與交易的大小成比例。這基本上等於相同的全局限制，但更容易理解每個交易有多少 sigops 可用。

Taproot 在處理每個交易的 sigops（籤名操作）限制方面的變化，爲一種泛化方法提供了可能性，這也是 Rusty Russell 在 varops 限制方面提出的建議。這個想法是爲每個重新激活的操作碼分配一個成本，以考慮到每個操作碼可能創建的最壞情況，即驗證時產生的最昂貴的計算成本。這樣，每個操作碼都會有自的「sigops」限制，限制它在驗證過程中可以消耗的資源量。這也將基於使用這些操作碼的任何交易的大小，因此可以方便進行推理，同時仍然累積到每個區塊的隱式全局限制。

這將解決 DOS 攻擊（通過發送大量垃圾請求，導致網絡崩潰），因爲這些垃圾交易，也是導致中本聰最初禁用所有這些操作碼的原因。