作者：ademan
來源：https://delvingbitcoin.org/t/ctv-only-vault-concept-v0-1-0-release/2539
我很高興能夠宣佈，MCCV —— 我的 “更復雜的 CTV保險櫃” 概念 —— 的第一個版本發佈；它是使用 BIP-119 OP_CHECKTEMPLATEVERIFY（OP_CTV）開發出來的。MCCV 證明了，一個功能非常全面的保險櫃合約可以僅使用 OP_CHECKTEMPLATEVERIFY 就構造出來，無需依賴於更有表達能力的限制條款（covenant）操作碼。雖然最終的設計有很大的計算負擔，也不是很便利，但它成功提供了存入、延遲取款、復原、 取款速度控制以及重複的保險櫃操作這些特性。
概要地說，資金從一個普通錢包以預先定義的增量存入保險櫃；取款也是按預先定義的增量來取款，並且其所面臨的時間鎖會隨著取款數量的增加而延長。這種相對時間鎖提供了一種挑戰窗口，在此期間，待完成的取款操作和保險櫃中剩餘的資金可以被清掃到一個復原密鑰；復原密鑰可以使用更安全的保管裝置。
因為時間鎖會隨著取款數量的增加而線性延長，這種保險櫃合約提供了由共識機制來強制執行的取款速度限制，可以減少潛在損失。
概述
注：這是實驗性的概念驗證軟件，只應用在 signet（或 regtest）等測試網上。
當前的實現是一款可用的命令行界面軟件，屬於概念驗證，是用 Rust 語言編寫的，依賴於 BDK 和 rust-bitcoin。它使用 Bitcoin Inquisition v29 運行在 regtest 和 signet 上；Bitcoin Inquisition 提供了對 OP_CHECKTEMPLATEVERIFY、TRUC（確認前拓撲受限的交易）和 “臨時錨點” 的支持。
本實現支持：
- 生成保險櫃
- 使用一個熱錢包來收款和花費
- 存入固定規模的增量資金到保險櫃
- 以固定規模的增量初始化延遲取款
- 將成熟的取款轉移到熱錢包
- 將整個保險櫃復原到一個冷存儲的復原密鑰
- Github 倉庫地址：GitHub - LNHANCE-Expedition/mccv: More Complicated CTV Vault · GitHub
- 用戶指南：mccv/docs/user-guide.md at master · LNHANCE-Expedition/mccv · GitHub
- 協議詳述（WIP）：mccv/docs/protocol.md at master · LNHANCE-Expedition/mccv · GitHub
特性
防止未經許可的取款
與所有的保險櫃構造一樣，從這種保險櫃取出的款項會進入一段挑戰窗口：在這段時間內，用戶可以將取出的款項和保險櫃中剩餘的資金都清掃給一個復原密鑰。
取款速度控制
這種保險櫃不僅提供了在遭遇未經許可的訪問時追回資金的辦法，還添加了由共識機制來強制執行的取款速度限制。
多次操作
本協議支持在同一個保險櫃上執行數量可觀但有限的存款和取款次數。這使得這種保險櫃設計比一次性的保險櫃設計靈活得多。
備份
這種保險櫃可以備份成一個一段非常小的、恆定大小的數據。
重大缺點
複雜性
這套協議可能生成多達幾百萬筆交易；它需要通過嚴格的代碼質量檢驗和審計，才能達到基本的可信任度。而且，複雜性自身就是一種風險，讓協議對它的目標使用場景 —— 大額資金 —— 變得不那麼吸引。不過，只要有 冷存儲密鑰/復原密鑰 逃生艙，就可以在一定程度上緩解這個最令人擔心的風險。
計算繁重
計算負擔會隨著存款增量的粒度、允許同一時間 取款/存入 的增量的數量以及保險櫃支持的操作總次數而增加。所有會改善用戶體驗的做法都會導致計算負擔以及鏈內交易費用增加。
信任保險櫃的生成程序
本方案的計算複雜性導致了需要建立信任的問題。生成保險櫃的設備必須足夠強大，能夠枚舉用戶想要的操作，同時還得是能夠信任得。當前，以實用的參數生成保險櫃實例，需要與最新的商品個人電腦或移動設備性能相當的硬件，但這些系統都是難以信任的。離線的個人電腦最符合這個要求，但是離線的電腦自身已經能夠在相當程度上滿足用戶的安全性要求，無需加入任何複雜的保險櫃。STARKs 也許能夠在硬件簽名器內實用地驗證保險櫃，這我認為是未來工作的一個重要方向。
取款需要兩步
因為每一個保險櫃都是預先計算出來的，資金無法直接取出給收款方。相反，成熟的取款可以被熱錢包花費，熱錢包可以轉發給收款方。這意味著，如果熱錢包被攻陷了，那麼成熟的取款也可能被盜走。這也意味著，授權一次取款時複雜的，因為資金的最終目的地並不包含在取款交易中。OP_VAULT 和 OP_CCV 都解決了這個問題（事實上，也會完全淘汰本設計。）
隱私性
嚴格的取款速度控制要求資金彙集到一個 UTXO 中。這是鏈上隱私性的重大犧牲。
手續費
這個缺點並不是這個協議內生的，而來自這個概念驗證實現的設計：熱密鑰與熱錢包密鑰是相關的。因此，攻擊者可以先吸乾你的熱錢包、阻止你為確認 追索/復原 交易而支付手續費。
這個問題可以通過確保瞭望塔使用另一個密鑰、安排了專項資金為復原交易支付手續費來緩解，不論這個瞭望塔服務是由用戶自己運行，還是由第三方運行。
協議概述
協議的詳細說明還在編寫中。
一個保險櫃就是一個規模很大的 DAG（有向無環圖），由預先計算的交易組成；這些交易之間的轉換則用 OP_CHECKTEMPLATEVERIFY 來強制執行。保險櫃被配置成具有下列參數：
scale：基本的取款和取款增量。對保險櫃的每一次操作都是這個數量的聰的倍數。delay：每多取出一份增量，需要額外等待的區塊數量max-withdrawal：可以一次性取出的最大數量max-deposit：可以一次性存入的最大數量max-depth：保險櫃可以支持的操作數量（DAG 的深度）
這些參數控制著安全性、便利性和預計算成本之間的取捨。
歷史
本保險櫃項目始於一項實驗：僅使用 CTV，有多大可能做出便於使用的保險櫃。人們普遍認為，單靠 CTV 不足以構造出理想的響應式保險櫃（reactive valut），但 CTV 確實能夠開發出預先計算的狀態機。這些構造可以帶來多種多樣的鏈內合約，唯一的限制因素在於預先計算。在純粹理論意義上，CTV 加上 taproot 可以表達極端複雜但最終可以枚舉的交易轉換圖，但只有通過窮舉每一種可能的狀態和狀態轉換才能實現。而在現實中，只要參數集合超過嚴格約束的大小，這在計算上就變得不可行。
我的發現是，這種方案對於不多的參數，是實用的，只是預先計算的速度會隨著參數集的擴大而迅速破壞用戶體驗。緩存可以實現，為了緩解對後續運行的延遲也應該實現，但即便如此，保險櫃的初始化計算也可能要耗費相當長時間。因此，“實質上無限制” 的保險櫃，其參數遠遠高於任何實際可預測的用法，希望似乎破滅了。不過，接受一些實用性上的限制（可以明確告知用戶），MCCV 提供了有用的功能。
比較
本方案不是第一種保險櫃設計，也不是第一種利用了 OP_CHECKTEMPLATEVERIFY 的保險櫃設計。不過，就我所知，這是第一種以這種方式結合 OP_CHECKTEMPLATEVERIFY 和 taproot 的公開的保險櫃設計。
simple-ctv-vault
顧名思義，“簡單 CTV 保險櫃（simple-ctv-vault）“ 希望儘可能簡單。它啟發了我開發 MCCV，我希望知道更復雜的構造有多實用。簡單 CTV 保險櫃讓一個 UTXO 可以要麼取款到一個熱地址（帶有時延），要麼清掃到一個冷地址。這依然是 MCCV 的基本原理，只不過簡單 CTV 保險櫃只支持一次性的存入和取款。
Bryan Bishop 的 “Bitcoin Vaults”
我真希望自己早一點知道 Bryan Bishop 的 “Bitcoin Vaults”。這種設計在概念上和方向上都類似於 MCCV 。與 MCCV 一樣，它也將保險櫃按價值切分成幾份，叫做 “shard”。它支持受到約束的保險櫃操作，要麼用毀掉了私鑰的預簽名交易來強制執行，要麼通過 OP_CHECKTEMPLATEVERIFY 來執行，只不過它是在 taproot 激活之前設計出來的。沒有 taproot，增加花費路徑的數量就需要（為花費交易）使用提及更大的 witnessScript（見證腳本）。Bryan 謹慎地挑選了花費路徑，使得保險櫃可以：將資金推送到冷存儲；將保險櫃分割成許多份；剝離其中一份，剩餘的則仍留在保險櫃中。這最後一項跟 MCCV 的特性尤其相似。我現在的直覺是，taproot 高效表示替代性花費條件的能力，有力的削弱了將保險櫃分割成許多份的需要。使用 MCCV，用戶可以取出足夠多的增量來滿足自己的需要，而留存的保險櫃會保護剩下的餘額。Taproot 的效率也讓 MCCV 可以讓存款進入已有的保險櫃，這在 Bryan 的協議中是做不到的，雖然這是以預先計算許多狀態為代價的。雖然 MCCV 協議設計是在我知曉 Bryan 的工作之前確定的，一些相似的設計元素，比如將保險櫃分割成許多份，以及在取款過程中剝離數量，使我感覺如遇知音。
OP_VAULT 和 OP_CHECKCONTRACTVERIFY 設計
希望不要引起任何跟限制條款操作碼有關的爭議，我只是想指出，這些操作碼很大程度上會取代我的設計。使用這些操作碼，就可以避免所有讓本保險櫃設計顯得可怕的預先計算。而且，它們還允許單步取款，也就是收款方可以在取款交易中指定，這可以協助由瞭望塔執行的透徹授權，並且讓收款方可以直接領取自己的資金（雖然收款方將需要額外的信息來清掃這些輸出）。話說回來，我認為 OP_VAULT 和 OP_CHECKCONTRACTVERIFY 激活的可能性遠遠低於 OP_CHECKTEMPLATEVERIFY，因此值得探索一種僅使用 CTV 的設計。
請求反饋
如能提供對以下事項的反饋，我會非常感激：
- 整體的協議設計
- 這種設計與更簡單的設計的取捨
- 關於保險櫃的整體思考
- 用戶體驗：這 只是 一個概念驗證項目，有一些已知的使用體驗缺陷，但用戶操作可能性皆已準備好測試。請參與用戶指南。
- 性能和預計算成本
結論
本方案有大量缺點，但依然在管理資金的安全性上提供了有趣的提升。它提供了可以等量齊觀的用戶體驗，而無需依賴於 OP_VAULT 和 OP_CCV，尤其是如果我們能在下述方向上做出改進的話。
未來的工作
許多其他工作同樣吸引我的注意力，所以這不是在承諾近期內就會投身於這些方面。不過，其中有一些，我認為是非常有趣的，值得儘快開始探索。
潛在的未來工作包括：
- 瞭望塔軟件：瞭望塔所需的所有特性在本命令行界面工具中皆已齊備，但尚未集成為一個有用的自動化特性。
- 委託復原：通過僅委託發起復原操作的能力，允許 準-受信任的 瞭望塔保險櫃。
- 緩存保險櫃計算：在保險櫃初始化生產後，顯著提升軟件的響應性。
- CPU 優化：多種多樣的優化，其中許多是容易摘到的果實。
- 通用化：適配軟件堆棧以支持其它 CTV 狀態機協議。
- GPU 加速：這種保險櫃的並行友好設計也讓它適合使用 GPU 來加速。
- 有望為硬件簽名器實現基於 STARK 的驗證
STARK 驗證的想法是非常有趣的。它將允許強大的消費者硬件來生成保險櫃及其形式正確性的證據，而更安全的硬件簽名器將使用緊湊的證據來驗證形式正確性。
（完）
