比特幣最初是使用完全充實的腳本語言設計的,旨在包含和支撐用戶將來可能提出的任何潛在的安全用例。正如聰自己在失蹤前所說:
“比特幣的本質是這樣的,一旦0.1版本發佈,核心設計就會在其餘生中一成不變。正因為如此,我想把它設計成支撐我能想到的每一種可能的交易類型。問題是,無論是否使用,每件事都需要特殊的支撐代碼和數據欄位,並且一次只涵蓋一種特殊情況。這將是特殊情況的爆炸式增長。解決方案是腳本,它概括了問題,因此交易方可以將他們的交易描述為節點網路評估的謂詞。 - 聰,2010 年 6 月 17 日。
整個目的是為使用者提供一種足夠通用的語言,使他們能夠按照自己認為合適的方式編寫自己的交易類型。 即給用戶空間來設計和試驗他們如何程式設計自己的錢。
在他消失之前,聰撕掉了其中的 15 個操作碼,完全禁用了它們,並對腳本引擎堆疊上可以操作的數據大小(520 位元組)增加了硬性限制。這樣做是因為他坦率地搞砸了,並且留下了大量複雜的腳本可用於拒絕服務攻擊整個網路的方式,從而產生了巨大且昂貴的驗證交易,這些交易會使節點崩潰。
這些操作碼被刪除並不是因為聰認為該功能是危險的,或者人們不應該能夠用它們構建他們能構建的東西,而僅僅(至少顯然)是因為在沒有資源限制的情況下使用它們來限制他們可能強加給網路的最壞情況驗證成本,這對整個網路構成了風險。
從那以後,每次升級到比特幣最終都是為了簡化剩下的功能,糾正聰留給我們的其他不太嚴重的缺陷,並擴展我們留下的腳本子集的功能。
五月初在奧斯丁的比特幣++上,Core Lightning開發人員Rusty Russell在會議的第一次演講中提出了一個非常激進的建議。他基本上提出了回溯了2010年聰他消失之前禁用的大多數操作碼。
自 2021 年 Taproot 啟動以來的過去幾年裡,坦率地說,開發空間有點漫無目的。我們都知道,比特幣的可擴展性不足以真正以自我主權的方式為世界上任何相當大的人口提供服務,甚至可能無法以最小化或託管的方式擴展到無法真正逃離政府多臂的非常大的託管人和服務提供者。
任何在技術層面上瞭解比特幣的人都明白這一點,這不是一個有爭議的問題。一個有爭議的問題,一個非常有爭議的問題,是如何解決這個缺點。自Taproot年以來,每個人都提出了非常狹隘的建議,旨在僅解決可以啟用的非常特殊的用例。
ANYPREVOUT(APO),一項允許簽名在不同交易上重複使用的提案,多腳本和輸入量相同,是專門為優化閃電網路和多方版本而量身定製的。CHECKTEMPLATEVERIFY(CTV)是一項強制硬幣只能由與預定義交易完全匹配的交易花費的提案,專門設計用於通過使其完全無需信任來擴展預簽名交易鏈的功能。OP_VAULT 專門設計用於為冷存儲方案啟用“超時期限”,以便使用者在密鑰洩露時可以通過將其發送到更冷的多重簽名設置來“取消”從冷存儲中提取。
還有很多其他建議,但我想你明白了。過去幾年的每一項提案都不是試圖全面解決從根本上擴展比特幣所需的表現力和可程式設計性,而是旨在小幅增加可擴展性或改進被認為可取的單個狹窄功能。我認為這就是為什麼這些對話都沒有進行到任何地方的原因。沒有人對任何其他提案感到滿意,因為它不符合他們希望看到構建的用例。
沒有什麼是全面的,除了提案贊助者之外,任何人都認為這是明智的下一步行動。
這就是大劇本還原背後的邏輯。通過推動和分析聰最初設計的腳本的全面恢復,我們實際上可以嘗試探索我們需要的功能的整個空間,而不是為現在的功能的小擴展足夠好而爭吵和內訌。
上面的操作碼是要恢復的操作碼。除此之外,Rusty 還提出了另外三個來簡化不同操作碼的組合。
第 2 層本質上是 比特幣 基礎層基礎層的擴展,它們本質上在功能方面受到基礎層功能的約束。閃電網路需要三個獨立的軟分叉,CHECKLOCKTIMEVERIFY (CLTV),CHECKSEQUENCEVERIFY(CSV)和隔離見證才能實際實現它。
如果沒有更靈活的基礎層,就無法構建更靈活的第 2 層。唯一的捷徑是受信任的第三方,純粹而簡單。我希望我們都渴望盡可能從與比特幣互動的各個方面消除這一點。
我們需要能夠做一些事情,我們現在無法做到,單子以一種可以在基礎層上無信任地強制執行的方式安全地將兩個以上的人打包到一個未花費的交易輸出(UTXO)中,比特幣腳本不夠靈活。在最基本的層面上,我們需要契約,我們需要腳本能夠實際執行有關執行它們的交易的更精細的詳細資訊,以確保使用者自己安全退出未花費的交易輸出(UTXO)不會使其他使用者的資金面臨風險。
從高處看,這就是我們需要的功能:
內省:我們需要能夠實際檢查堆棧上有關支出交易本身的特定細節,例如“這筆錢在某個輸出中流向了這個公鑰”。這使我可以使用自己的特定Taproot分行自行提取資金,同時確保我不能拿走其他人的錢。如果我離開,執行的腳本將通過共識強制執行其他人擁有的正確數量將發送回由其他使用者的公鑰組成的位址。
轉發數據攜帶:假設我們比閃電頻道的想法更進一步,其中有兩個以上的人,我們構建了一個包含大量人員的單一未花費的交易輸出(UTXO),任何人都可以隨心所欲地進出。不知何故,幾乎總是有一棵默克爾樹和它的根,我們需要某種方法來跟蹤誰有多少錢。這意味著當有人離開時,我們必須能夠確保誰有權獲得零錢的“記錄”未花費的交易輸出(UTXO)其他人的錢。這本質上是內省的一種特定用途。
公鑰 修改:我們需要能夠確保可以在堆疊上驗證對聚合公鑰的修改。未花費的交易輸出(UTXO)共享計劃的目標是,每個參與者都有一個聚合鍵,允許合作和更有效的資金流動。每當有人單方面離開共用未花費的交易輸出(UTXO)時,我們都需要從聚合密鑰中刪除他們的個人密鑰。如果不提前預先計算所有可能的組合,唯一的選擇是能夠驗證從聚合中減去一個鍵會創建一個由其餘單個鍵組成的有效鍵。
正如我上面所說,所有這些操作碼被禁用的原因是為了消除拒絕服務攻擊的風險,這些攻擊可能會使組成網路的節點崩潰。有一種方法可以解決這個問題,限制這些操作碼中的任何一個可以使用的資源量。
在簽名驗證方面,我們已經有了這樣的解決方案,這是驗證比特幣腳本中最昂貴的部分。它被稱為sigops預算。每次使用簽名檢查操作碼都會消耗每個塊允許的簽名操作的一定“預算”。這硬性限制了交易可以強加給用戶驗證單個區塊的成本。
Taproot改變了這種工作方式,而不是使用單個全域區塊限制,每個交易都有自己的sigops限制,與交易的大小成比例。這基本上適用於相同的全域限制,但可以更輕鬆地根據單個事務有多少個可用 sigops 進行推理。
Taproot處理相對於每個事務的 sigops 限制的方式的轉變提供了一種概括這一點的方法,這就是 Rusty 提出的 varops 限制。這個想法是為每個重新啟動的操作碼分配一個成本,以考慮每個操作碼可能創建的最壞情況帳戶即驗證成本最高的計算成本。有了這個,這些操作碼中的每一個都有自己的“sigops”限制,以限制它在驗證中可以消耗多少資源。它還將基於使用它們的任何交易的大小,因此請保持推理的便利性,同時仍然為每個區塊加起來隱式全域限制。
這將解決導致聰首先禁用所有這些操作碼的拒絕服務風險。
我相信你們中的許多人都在想“這是一個太大的變化”。我可以對此表示同情,但我認為這個專案的一個重要方面是,作為一個需要理解的建議,我們不必做所有的事情。這個提案的價值並不一定實際上將所有這些作為一個整體重新打開,而是我們實際上會全面地查看大量原語,並問自己在功能方面我們真正想要什麼。
這將是過去三年來爭吵和爭論的關於只有助於某些功能的微小狹窄變化的完整面子。這是一個帳篷,可以將所有人聚集在一個屋簷下,真正全面地評估從這裡走向何方。也許我們最終會重新打開所有這些,也許我們最終只是啟動了一些東西,因為共識是,這就是我們啟用每個人都同意我們需要的功能所需要的一切。
無論最終結果如何,它都可以成為圍繞我們從這裡走向何方的整個對話中的富有成效的變化。我們實際上可以繪製出地圖並全面瞭解這片土地,而不是笨拙地爭論接下來要走哪條渾濁和半明半暗的道路。
這絕不是我們前進的道路,但我認為這是我們決定我們走哪一條的最佳機會。是時候再次開始以富有成效的方式進行實際合作了。
分享
目錄
比特幣最初是使用完全充實的腳本語言設計的,旨在包含和支撐用戶將來可能提出的任何潛在的安全用例。正如聰自己在失蹤前所說:
“比特幣的本質是這樣的,一旦0.1版本發佈,核心設計就會在其餘生中一成不變。正因為如此,我想把它設計成支撐我能想到的每一種可能的交易類型。問題是,無論是否使用,每件事都需要特殊的支撐代碼和數據欄位,並且一次只涵蓋一種特殊情況。這將是特殊情況的爆炸式增長。解決方案是腳本,它概括了問題,因此交易方可以將他們的交易描述為節點網路評估的謂詞。 - 聰,2010 年 6 月 17 日。
整個目的是為使用者提供一種足夠通用的語言,使他們能夠按照自己認為合適的方式編寫自己的交易類型。 即給用戶空間來設計和試驗他們如何程式設計自己的錢。
在他消失之前,聰撕掉了其中的 15 個操作碼,完全禁用了它們,並對腳本引擎堆疊上可以操作的數據大小(520 位元組)增加了硬性限制。這樣做是因為他坦率地搞砸了,並且留下了大量複雜的腳本可用於拒絕服務攻擊整個網路的方式,從而產生了巨大且昂貴的驗證交易,這些交易會使節點崩潰。
這些操作碼被刪除並不是因為聰認為該功能是危險的,或者人們不應該能夠用它們構建他們能構建的東西,而僅僅(至少顯然)是因為在沒有資源限制的情況下使用它們來限制他們可能強加給網路的最壞情況驗證成本,這對整個網路構成了風險。
從那以後,每次升級到比特幣最終都是為了簡化剩下的功能,糾正聰留給我們的其他不太嚴重的缺陷,並擴展我們留下的腳本子集的功能。
五月初在奧斯丁的比特幣++上,Core Lightning開發人員Rusty Russell在會議的第一次演講中提出了一個非常激進的建議。他基本上提出了回溯了2010年聰他消失之前禁用的大多數操作碼。
自 2021 年 Taproot 啟動以來的過去幾年裡,坦率地說,開發空間有點漫無目的。我們都知道,比特幣的可擴展性不足以真正以自我主權的方式為世界上任何相當大的人口提供服務,甚至可能無法以最小化或託管的方式擴展到無法真正逃離政府多臂的非常大的託管人和服務提供者。
任何在技術層面上瞭解比特幣的人都明白這一點,這不是一個有爭議的問題。一個有爭議的問題,一個非常有爭議的問題,是如何解決這個缺點。自Taproot年以來,每個人都提出了非常狹隘的建議,旨在僅解決可以啟用的非常特殊的用例。
ANYPREVOUT(APO),一項允許簽名在不同交易上重複使用的提案,多腳本和輸入量相同,是專門為優化閃電網路和多方版本而量身定製的。CHECKTEMPLATEVERIFY(CTV)是一項強制硬幣只能由與預定義交易完全匹配的交易花費的提案,專門設計用於通過使其完全無需信任來擴展預簽名交易鏈的功能。OP_VAULT 專門設計用於為冷存儲方案啟用“超時期限”,以便使用者在密鑰洩露時可以通過將其發送到更冷的多重簽名設置來“取消”從冷存儲中提取。
還有很多其他建議,但我想你明白了。過去幾年的每一項提案都不是試圖全面解決從根本上擴展比特幣所需的表現力和可程式設計性,而是旨在小幅增加可擴展性或改進被認為可取的單個狹窄功能。我認為這就是為什麼這些對話都沒有進行到任何地方的原因。沒有人對任何其他提案感到滿意,因為它不符合他們希望看到構建的用例。
沒有什麼是全面的,除了提案贊助者之外,任何人都認為這是明智的下一步行動。
這就是大劇本還原背後的邏輯。通過推動和分析聰最初設計的腳本的全面恢復,我們實際上可以嘗試探索我們需要的功能的整個空間,而不是為現在的功能的小擴展足夠好而爭吵和內訌。
上面的操作碼是要恢復的操作碼。除此之外,Rusty 還提出了另外三個來簡化不同操作碼的組合。
第 2 層本質上是 比特幣 基礎層基礎層的擴展,它們本質上在功能方面受到基礎層功能的約束。閃電網路需要三個獨立的軟分叉,CHECKLOCKTIMEVERIFY (CLTV),CHECKSEQUENCEVERIFY(CSV)和隔離見證才能實際實現它。
如果沒有更靈活的基礎層,就無法構建更靈活的第 2 層。唯一的捷徑是受信任的第三方,純粹而簡單。我希望我們都渴望盡可能從與比特幣互動的各個方面消除這一點。
我們需要能夠做一些事情,我們現在無法做到,單子以一種可以在基礎層上無信任地強制執行的方式安全地將兩個以上的人打包到一個未花費的交易輸出(UTXO)中,比特幣腳本不夠靈活。在最基本的層面上,我們需要契約,我們需要腳本能夠實際執行有關執行它們的交易的更精細的詳細資訊,以確保使用者自己安全退出未花費的交易輸出(UTXO)不會使其他使用者的資金面臨風險。
從高處看,這就是我們需要的功能:
內省:我們需要能夠實際檢查堆棧上有關支出交易本身的特定細節,例如“這筆錢在某個輸出中流向了這個公鑰”。這使我可以使用自己的特定Taproot分行自行提取資金,同時確保我不能拿走其他人的錢。如果我離開,執行的腳本將通過共識強制執行其他人擁有的正確數量將發送回由其他使用者的公鑰組成的位址。
轉發數據攜帶:假設我們比閃電頻道的想法更進一步,其中有兩個以上的人,我們構建了一個包含大量人員的單一未花費的交易輸出(UTXO),任何人都可以隨心所欲地進出。不知何故,幾乎總是有一棵默克爾樹和它的根,我們需要某種方法來跟蹤誰有多少錢。這意味著當有人離開時,我們必須能夠確保誰有權獲得零錢的“記錄”未花費的交易輸出(UTXO)其他人的錢。這本質上是內省的一種特定用途。
公鑰 修改:我們需要能夠確保可以在堆疊上驗證對聚合公鑰的修改。未花費的交易輸出(UTXO)共享計劃的目標是,每個參與者都有一個聚合鍵,允許合作和更有效的資金流動。每當有人單方面離開共用未花費的交易輸出(UTXO)時,我們都需要從聚合密鑰中刪除他們的個人密鑰。如果不提前預先計算所有可能的組合,唯一的選擇是能夠驗證從聚合中減去一個鍵會創建一個由其餘單個鍵組成的有效鍵。
正如我上面所說,所有這些操作碼被禁用的原因是為了消除拒絕服務攻擊的風險,這些攻擊可能會使組成網路的節點崩潰。有一種方法可以解決這個問題,限制這些操作碼中的任何一個可以使用的資源量。
在簽名驗證方面,我們已經有了這樣的解決方案,這是驗證比特幣腳本中最昂貴的部分。它被稱為sigops預算。每次使用簽名檢查操作碼都會消耗每個塊允許的簽名操作的一定“預算”。這硬性限制了交易可以強加給用戶驗證單個區塊的成本。
Taproot改變了這種工作方式,而不是使用單個全域區塊限制,每個交易都有自己的sigops限制,與交易的大小成比例。這基本上適用於相同的全域限制,但可以更輕鬆地根據單個事務有多少個可用 sigops 進行推理。
Taproot處理相對於每個事務的 sigops 限制的方式的轉變提供了一種概括這一點的方法,這就是 Rusty 提出的 varops 限制。這個想法是為每個重新啟動的操作碼分配一個成本,以考慮每個操作碼可能創建的最壞情況帳戶即驗證成本最高的計算成本。有了這個,這些操作碼中的每一個都有自己的“sigops”限制,以限制它在驗證中可以消耗多少資源。它還將基於使用它們的任何交易的大小,因此請保持推理的便利性,同時仍然為每個區塊加起來隱式全域限制。
這將解決導致聰首先禁用所有這些操作碼的拒絕服務風險。
我相信你們中的許多人都在想“這是一個太大的變化”。我可以對此表示同情,但我認為這個專案的一個重要方面是,作為一個需要理解的建議,我們不必做所有的事情。這個提案的價值並不一定實際上將所有這些作為一個整體重新打開,而是我們實際上會全面地查看大量原語,並問自己在功能方面我們真正想要什麼。
這將是過去三年來爭吵和爭論的關於只有助於某些功能的微小狹窄變化的完整面子。這是一個帳篷,可以將所有人聚集在一個屋簷下,真正全面地評估從這裡走向何方。也許我們最終會重新打開所有這些,也許我們最終只是啟動了一些東西,因為共識是,這就是我們啟用每個人都同意我們需要的功能所需要的一切。
無論最終結果如何,它都可以成為圍繞我們從這裡走向何方的整個對話中的富有成效的變化。我們實際上可以繪製出地圖並全面瞭解這片土地,而不是笨拙地爭論接下來要走哪條渾濁和半明半暗的道路。
這絕不是我們前進的道路,但我認為這是我們決定我們走哪一條的最佳機會。是時候再次開始以富有成效的方式進行實際合作了。