Cube 簡介

作者：Buark

來源：https://medium.com/cube-bitcoin/introducing-cube-8b3702e470a5

“Cube”是一種專門為以原生於比特幣的方式啟用免信任的智能合約執行而設計的虛擬機。它能提供帶有單方面退出能力的免信任的執行環境，從而保證用戶對自己的資金保持完整的控制權。通過結合 BitVM 與 “超時樹”，並利用比特幣區塊鏈作為 “數據可得性（DA）” 層，Cube 將 BTC 直接置入一個帶有 “全局狀態（global-state）” 的虛擬機。這種方法結合了比特幣的基礎設計以及一種圖靈完備的智能合約執行模式，並且無需引入對手方風險，從而為拓展比特幣的功能提供了一種全新的框架。

聖盃

比特幣是最安全、最久經考驗的密碼貨幣，但它在腳本編程上的侷限性、以及在可擴展性上的難題，限制了它支持除了點對點支付以外的複雜金融交易的能力。這並非缺陷。它們是為了保護讓比特幣有價值的屬性 —— 抗審查性、自主保管、抗壓能力 —— 而有意設計的約束。不過，結果是比特幣無法原生支持一個全球貨幣層所需要的可編程性、吞吐量和金融複雜性。智能合約、去中心化的金融，以及高頻結算，都要求一個執行環境，比特幣從未被有意設計成在其基礎層提供這樣的環境。

解決方案並不是改變比特幣，而是以它為基礎。有意義的二層網絡（layer 2）必須拓展比特幣的能耐，且不犧牲它的核心屬性。它必須帶來可編程的智能合約，同時保持自主保管屬性：沒有中間人能凍結火罰沒用戶的資金。它必須能實現這一切而不要求比特幣協議變更、不引入可以盜竊的受信任的中間人，並且不強迫用戶信任啟動儀式、委員會以及他們不知底細的橋接合約（bridge）運營者。

許多人提議的擴容方案雖然拓展了比特幣的功能，但犧牲了免信任的模式。許多設計依賴於 1-of-n 可信任假設，也就是安全性依賴於至少有 1 個運營者是誠實的。這些設計犧牲了比特幣的核心倫理：去中心化和免信任性；它們不會是比特幣的長期擴容方案。

CUBE

Cube 為比特幣的可編程性帶來了一種完全不同的方法：專門為直接在比特幣上執行完全免信任的智能合約而設計的原生 layer 2，無需橋接合約、運營者聯盟、外部共識系統乃至修改比特幣協議。Cube 不是將比特幣轉移到一個另類的信任域中、換來可編程性，而是將比特幣原生的自主保管和結算模式延展為一種可編程的執行環境，同時保持對比特幣網絡的錨定。

Cube 所要實現的核心目標，曾被認為在比特幣系統中是矛盾的：免信任的保管與通用的可編程性。傳統的智能合約環境通過抽象掉比特幣的所有權和結算模式、代之以外部驗證器、橋接合約、多簽名或者說聯盟託管假設，來實現可編程性。Cube 不這樣做。Cube 的執行層之下直接就是比特原生的所有權模式，這讓可編程的智能合約可以運行而無需犧牲單方面退出能力（自主保管特性，或者說比特幣強制執行的贖回保證）。

Cube 利用了比特幣自身作為執行環境之下的結算、糾紛解決以及最終所有權層。智能合約環境在鏈外以樂觀模式運作，而結算保證、單方面退出以及 挑戰-應答 機制的強制執行，都通過原生於比特幣的原語迴歸到比特幣自身。

Cube 的架構圍繞著 “Engine”，這是一個協調層，負責接收來自參與者的交易條目、排序成批次、併產生錨定到比特幣網絡的結算交易。在常規運營中，Engine 樂觀地推進狀態轉換、協調執行，不要求立即在鏈內結算。關鍵是，Engine 純粹是一個協調員，絕不是託管商。

Cube 的首要設計目標是免信任的可編程性，不犧牲比特幣原生地自主保管特性。每一個參與者在所有時段都保留資金的單方面控制權，靠的是直接由比特幣腳本強制執行的由 MuSig2 多簽名模擬的限制條款。資金一直鎖定在合作的 2-of-2 多簽名構造中（參與者與 Engine 一對一），這就形成了管轄 Cube 執行環境的所有權原語基礎。

因為 Cube 從不直接處理參與者的資金，Engine 無法獨自移動資產、罰沒餘額和阻止單方面取款。參與者保留在比特幣網絡上通過 “超時樹” 結算路徑和 挑戰-應答 機制直接執行單方面退出條款的能力。

結果是，在保管層面，Cube 保留了完全的免信任性，同時，直接在比特幣上帶來了通用的智能合約可編程性。參與者們不依賴於運營者、委員會、聯盟和外部驗證器的品格來保管資金。所有權保證一直是由比特幣腳本、單方面退出路徑和密碼學 挑戰-應答 構造直接強制執行的。Engine 無法盜竊，因為協議結構自身就不允許；憑藉密鑰和比特幣強制執行的贖回保證，參與者對自己資金的掌控不會中斷。

虛擬化的計算所有權

Cube 的執行架構是兩種原生於比特幣的原語的結合：（1）Ark 式的超時樹所有權虛擬化；以及（2） BitVM 式的可證否計算（disprovable computation）。

超時樹提供了可擴容的虛擬化所有權和單方面贖回保證，讓參與者可以在鏈外交換虛擬輸出，同時保持獨立退出到比特幣鏈內的能力。BitVM 補充了這種模式：它將虛擬化的所有權延展為虛擬化的計算，讓比特幣原生的可證否計算來挑戰、強制執行得到斷言的狀態轉換。

Cube 將這兩種基礎性原語組合成一種統一的執行原語，稱為 “零知識時間鎖合約（ZKLTC）”。

從概念上來說，（1）超時樹解決了所有權虛擬化問題；而（2） BitVM 解決了計算的強制執行問題。Cube 將兩者結合在一起，所以可編程的狀態轉換可以在鏈外樂觀地發生，同時始終保持通過比特幣自身來贖回和挑戰的能力。

（譯者注：“樂觀” 在這裡意味著默認提議的狀態變更是有效的，除非其他人提出反對。）

一言以蔽之，ZKTLC 是一個超時樹虛擬輸出、攜帶著一個可以通過 BitVM 挑戰機制來強制執行的零知識的計算斷言。

ZKTLCs

ZKTLCs 延申了在 Ark 式超時樹系統中使用的 VTXO 模型，使之帶有可編程的計算和 挑戰-應答 語義。傳統的 VTXO 主要代表的是對價值的單方面贖回請求權，ZKTLC 則額外代表了用戶和 Engine 之間的一個可以挑戰的計算斷言。因此，這個輸出不僅是一個對價值的請求權（claim），還是對 Engine 所斷言的狀態轉換的正確性的聲明（claim）。

抽象地說，其中的關係可以類比為已有的比特幣兩方合約。在閃電網絡中，一條通道在絕大部分時候是一個用戶和一個閃電網絡服務商（LSP）的一對一關係。在 Ark 式系統中，虛擬輸出表達的是一個用戶和該系統的 Ark 服務商的一對一關係。而在 Cube 中，一個 ZKTLC 表達的是用戶和 Engine 之間的一對一 BitVM 挑戰-應答 關係。

Cube 的執行環境遵循 BitVM3 範式的執行模型：在其中，得到斷言的 Groth16 驗證器運算，會被轉化為可以通過比特幣原生的 挑戰-應答 機制來執行的混淆電路（garbled-circuit）驗證器環境。這些被斷言的計算對應著 Engine 所承諾的狀態轉換。更具體地說，Engine 要證明的是所提議的狀態轉換，根據（1）比特幣和（2）CubeVM 的共識規則，得到了正確的執行，並且相對於以往承諾的狀態，沒有發生無效的狀態轉換。

Cube 的做法不是直接在比特幣商執行任意計算，而是執行緊湊的驗證器斷言，斷言的正確性可以在稍後通過 BitVM3 證否環境來挑戰。因此，底層的驗證器電路代表了 CubeVM 狀態轉換系統自身的有效性規則，包括執行語義、合約約束、餘額不變量、狀態轉換有效性條件，以及管轄結算正確性的相關比特幣共識規則。

被斷言的計算是通過被承諾的混淆表（garbled tables）、線路標籤承諾（wire-label commitments）、挑戰記錄，以及對應於驗證器電路的秘密值揭曉結構，來表示的。在合作式執行時，裁決環境保持休眠，Engine 樂觀地推進狀態轉換。而在對抗條件下，參與者可以強迫披露可以求值的驗證器輸入（通過斷言見證本身）、在本地重新構造出得到承諾的混淆 Groth16 驗證器，然後自己求值得到斷言的狀態轉換。如果求值產生了一個無效的結果，那麼混淆驗證器會產生對應於出錯的輸出線路標籤的證否秘密值，它允許參與者觸發在已經承諾的比特幣哈希鎖條件中相關的懲罰性結算路徑。

因此，參與者控制著虛擬化的所有權對象，這樣的對象既包含著單方面的贖回權利，又包含可以強制執行的、密碼學證否 Engine 所斷言的執行狀態的權利。

傳統的零知識證明系統依賴於整個生態參與的受信任啟動儀式（或者說多方安全計算委員會），Cube 與此不同，它將證明環境限制為每個參與者有一個獨立的環境。在賬戶初始化期間，每個參與者都直接跟 Engine 一起執行一個單獨的啟動儀式、生成專屬的證明參數、參與有毒廢料（toxic-waste）的生成，並控制自己的有毒廢料的銷燬。（譯者注：此處的 “有毒廢料” 指的是會洩露啟動儀式相關信息的數據。）

結果是，啟動裝置自身，對參與者來說就編程了免信任的。信任不是投放給外部的 MPC 委員會、協調員或者共享的證明環境，而是侷限在這個參與者專有的 ZKTLC 環境中。

超時樹

Cube 利用超時樹作為底層的所有權和單方面退出架構， 比執行環境更為底層。

超時樹就是一棵由預先簽名的交易組成的樹，它允許大量的虛擬化所有權對象共享一個共同的結算結構，同時保護每一個參與者的單方面贖回保證。參與者們在嵌進一棵共享交易樹的虛擬化輸出上樂觀地交易，而不是讓所有權的每一次中間轉換都立即在比特幣鏈內結算。

在合作式執行時，超時樹保持休眠，所有權轉換髮生在鏈外。如果協調失敗，或者 Engine 變得不誠實，參與者們可以在相關的超時條件成熟後，在比特幣鏈內獨立地實體化並贖回對應的超時樹分支。

Cube 採用超時樹，作為 ZKTLC 執行機制之下的基礎性結算和所有權原語。系統中的每個參與者的餘額，最終都可以解析為可以通過比特幣腳本強制執行的一條超時樹贖回路徑。

從概念上來說，超時樹結構給 Cube 提供了所有權虛擬化能力，而 ZKTLCs 用可編程的計算和 挑戰-應答 語義豐富了這些所有權對象。在這個意義上，Cube 的執行架構可以理解為結合了 Ark 的虛擬所有權和 BitVM 的可證否計算，都直接錨定比特幣的結算保證。

CubeVM

Cube 引入了一種定製化的虛擬機，叫做 “CubeVM”， 實現為 Bitcoin Script（編程語言）的一種延申覆刻，是專門為在比特幣上執行免信任的智能合約而設計的。CubeVM 不會替換比特幣的腳本執行理念，而是將 Bitcoin Script 的基於堆棧的執行環境延展成一種專門為單方面退出和可證否計算優化的可編程全局狀態環境。

CubeVM 用泛化的智能合約計算所需的額外操作碼延展了 Bitcoin Script 。這個虛擬機原生支持全局狀態管理、持久化合約存儲、隔離的執行環境、增強的內存管理、 256 比特算術、橢圓曲線運算、堆棧元素操作、合約調用語義，以及直接操作底層資產比特幣的投影操作碼。

與賬戶原生的虛擬機（比如 “以太坊虛擬機（EVM）”）不同，CubeVM 是從第一性原理（將可編程的執行帶給比特幣原生的自主保管裝置）設計的。因此，智能合約的狀態轉換永遠跟 Cube 的超時樹結算結構和證否模式保持兼容。

CubeVM 的定義性架構原語，是它原生支持 “投影”，允許將合約控制的邏輯餘額不斷投射成歸屬於參與者的單方面退出對象。投影操作是介於可編程的智能合約執行與比特幣的基於密鑰的所有權模型之間的語義橋。通過這一機制，CubeVM 讓可編程的智能合約可以直接在比特幣上操作，並且保持完全擔保的單方面贖回保證，並且在合約執行期間，保持自主保管特性。

投影

可編程的智能合約系統，比如以太坊，運行在與比特幣的原生設計截然不同的所有權模式上。在比特幣中，資金是由公鑰來控制的。所有權表示為製作有效電子簽名的能力，自由行使簽名權的賬戶最終管轄的是錢幣（coins）。智能合約則完全不同。一個智能合約並不具有賬戶原生的那種自由裁量權或者說自由意志。由一個合約只有的資金，完全是管局確定性的程序邏輯和狀態轉換來管轄的。尤其是，合約邏輯自身會成為價值的託管商。這種區別，讓比特幣原生的所有權和可編程的智能合約語義在根本上無法兼容。

BitVM 和混淆電路，基本上還是在密鑰原生的環境中操作。它們的原語圍繞著公鑰、簽名、挑戰-應答 協議，以及跟單個實體關聯的可證明計算。雖然 BitVM 可以驗證任意計算，其底層的所有權模式沒有改變：比特幣理解的依然是密鑰，而非邏輯。可執行的邏輯自身無法直接以 UTXO 的形式持有比特幣。結果是，產生了兩種不同的語義域。比特幣說的是公鑰語言，而智能合約說的是邏輯語言。這些系統並不天然可以互操作，因為比特幣沒有讓邏輯持有價值的原生抽象。為了彌合這種不兼容性，我們的工作引入了一種中間抽象，就是 “投影”。

投影是一個翻譯層，介於邏輯原生的保管模式與比特幣原生的持有語義之間。它不是讓可執行的邏輯自身成為一個持有比特幣的實體，而是讓一個由合約控制的餘額可以投射為一組歸屬於各個參與者的、與公鑰關聯的餘額。投影背後的核心觀察是，雖然資金可能暫時存在於合約邏輯的託管之下，但這些資金，在這個合約的整個生命週期中，從經濟上來說依然歸屬於各個參與者。

通常來說，在可編程的智能合約系統比如以太坊上，錢幣會通過一種重複的託管週期來轉移：最初是在賬戶的直接所有權之下，然後是臨時進入合約控制的邏輯託管，最終，因為取款或者結算，回到直接賬戶所有權。一個參與者可能最初是通過原生的密鑰控制的賬戶餘額來控制錢幣。然後，這個參與者可能會將這些錢幣存入一個智能合約 —— 比如用比特幣擔保的穩定幣合約、一個自動做市商（AMM）流動性池，或是另一種可編程的金融原語 —— 這時候，資金就不再是由這個參與者的簽名權限直接持有的了，而是完全由合約的執行邏輯和狀態轉換規則來管轄。最終，到贖回擔保品、流動性撤出或者合約結算的時候，錢幣會再次回到參與者的公鑰控制保管之下。因此，這個過程有問題的地方在於，在中間狀態中，資金不再直接由參與者的公鑰控制，同時也就無法表示為由公鑰持有的餘額，因為它們處於邏輯託管之下。這種中間狀態，由邏輯持有的狀態，正是比特幣原生的所有權語義和智能合約原生的執行語義無法天然對齊的地方。

（譯者注：實際上，在以太坊這樣的協議上，能夠使用公鑰直接持有的錢幣只有以太坊原生貨幣 ETH 本身；其它錢幣都是在其發行合約的執行邏輯定義下可以由公鑰操作，也即邏輯託管是第一位的。）

投影解決這種不兼容性的辦法是不表示合約的託管本身，而是表示合約對參與者的義務。合約持有的餘額會不間斷地投射為一組餘額，對應於參與者公鑰在任一合約狀態中（經濟意義上）持有的具體數量。這種投射出來的表示 —— 影子狀態 —— 是可以通過比特幣原生的結構來表達的，儘管其底層的託管依然是完全由可執行的邏輯來管轄的。通過這種機制，由合約管轄的錢幣可以不斷投影到與參與者公鑰關聯的可單方退出的超時樹上。結果是，雖然背後的比特幣依然是邏輯託管的，參與者們永遠保留在任一狀態中對屬於他們的具體數量的可贖回請求權。所以說，投影是 BitVM 的密鑰原生挑戰框架與智能合約式的邏輯託管之間的語義橋。可執行的邏輯管轄著資金，但這些資金的影子，永遠可以通過比特幣原生的公鑰結構贖回。

投影空間

從實現的角度看，投影抽象機制形成了一個專門由合理管理的分配空間，叫做 “投影空間”。每一個部署在 Cube 上的智能合約都被安排了自己的投影空間，這是記賬層，符合管理歸屬於參與者的影子餘額。概念上來說，投影空間是一個合約自己分配的數據庫，由 賬戶公鑰 -> 影子餘額 這樣的映射組成；其中每一個條目都表示經濟意義上歸屬於（或者說 “欠”）某個參與者賬戶的比特幣數量，雖然背後的錢幣是在合約託管之下。因此，投影空間並不以 UTXO 的形式表達錢幣的所有權，相反，它表示的是由合約持有的流動性的計劃中的贖回狀態，其形式兼容於 BitVM 的密鑰原生的框架以及單方退出框架。影子的分配由一組專門的投影操作碼來創建和管理，從而允許合約在狀態變化過程中初始化、增加減少和按比例調整歸屬於參與者的餘額。

對於任何一個參與者賬戶，以下兩項的和：

1. 賬戶的原生餘額；
2. 在所有合約中歸屬於該賬戶的影子分配（shadow allocations）；

定義了這個參與者在任一給定的狀態中，其在超時樹上的實質可贖回餘額。

重要的是，一個合約的影子分配總額，嚴格受到由該合約持有的實際餘額的約束。一個合約投影空間內所有影子餘額的總和，永遠不能超過該合約當前持有的比特幣數量：Contract Balance ≥ ∑Shadow Allocations

任何導致影子分配超過該合約的實際比特幣餘額的操作，都被認為是無效的，會在虛擬機層面被拒絕。這種約束保證了所有投射出來的影子餘額都總是由合約持有的流動性全額擔保，從而保證對於所有歸屬於參與者的餘額，總是有充足的單方退出流動性。

投影操作碼

CubeVM 加入了一族專設的操作碼來管理一個合約的投影空間：

- 投影操作碼 -

這些操作碼，提供了在合約執行期間管理歸屬於參與者的影子餘額所需的狀態轉換操作原語。OP_SHADOW_ALLOC 的作用是在一個合約的投影空間內，為一個參與者賬戶初始化一個新的影子分配條目，其初始餘額為 0 。分配之後，OP_SHADOW_UP 和 OP_SHADOW_DOWN 可以用來增加或減少跟這個參與者相關的影子分配。

比如說，設想一種以比特幣為擔保的穩定幣合約。當一個參與者存入比特幣到這個合約作為擔保品時，存入的錢幣變成由合約的內部執行邏輯來管轄，不再由參與者的簽名權限來管轄。測試後，合約會調用OP_SHADOW_UP 來增加這個參與者的影子分配，數額是對應的擔保品數量。雖然存入的比特幣現在，從技術上來說，處在合約的邏輯託管之下，但是等量的歸屬於參與者的餘額，通過投影空間被投射為可以單方退出的超時樹。這保證了充足的單方退出流動性，永遠可以由參與者贖回，哪怕背後的錢幣在合約內保持虛擬化鎖定。這就是投影溝通 BitVM 的密鑰原生贖回模型與智能合約式邏輯託管的核心機制。

除了按賬戶分配的操作碼，CubeVM 還加入了按比例調皮操作碼，包括 OP_SHADOW_UP_ALL 和 OP_SHADOW_DOWN_ALL。它們與 OP_SHADOW_UP 及 OP_SHADOW_DOWN 不同，後兩者只會改變單個參與者的餘額，而它們會按比例增加或減少一個投影空間內所有參與者的影子分配（根據他們現在的相對權重）。這些操作碼，對於池化流動性系統（比如 AMM）尤其有用。當池化的比特幣流動性因為互換、手續費或流動性事件而增加或減少時，合約需要在一個操作碼的執行中按比例調平所有流動性提供者的影子分配，而不是逐個調整各流動性提供者的影子分配。這大大簡化了池化金融原語的實現複雜性，同時為所有參與者保持了全額擔保的單方面退出保證。

投射器

Cube 使用一種修改過的 MuSig2 聚合構造，作為一種輕量化的限制條款模擬機制（因為比特幣現在沒有原生的限制條款操作碼）。不能依賴協議層的限制條款原語，Cube 就通過綁定價值的聚合簽名結構來模擬限制條款；這種聚合簽名結構就叫 “投射器（Projectors）”。

與傳統的 MuSig2 聚合簽名不同的地方是，投射器讓聚合的限制條款公鑰不僅跟簽名者的身份綁定，還跟顯式的數值承諾綁定。這讓限制條款腳本公鑰與其意圖的價值狀態形成密碼學綁定。

投射器的首要目標是啟用輕量化的限制條款執行環境，讓參與者們可以安全地參與限制條款簽名會話，並且不要求對合約執行狀態或者說交易內容的完全語義性覺察。投射器參與者們不需要分析可能性無限多的限制條款邏輯，只需使用盡可能少的確定性驗證，就能安全操作，而且依然能抵抗重放（replay）、重綁定和惡意的重複簽名嘗試。

抽象地說，投射器是將限制條款簽名轉化成一種帶有約束的投射問題：可執行的合約狀態被投射成綁定價值的公鑰結構，與 BitVM 的公鑰原生的挑戰模式兼容。

投射器通過一個預處理的規劃階段，延申了原本的 MuSig2 聚合流程：在執行標準的 KeyAgg(pk_1 … pk_u) 步驟（由 BIP-327 定義）之前，先執行這個規劃階段。

Cube 引入了一種綁定價值的確定性投射函數（而不是將參與者的公鑰直接投入 KeyAgg 函數）：

KeyProjectorAgg(pk_1...pk_u, val_1...val_u)

其中：

• pk_i 為參與者的公鑰；
• val_i 表示以 聰 為單位的價值承諾，與每一個參與者相關

對於每一個參與者（以編號 i 區分），一個投射調整項這樣計算出來：

t_i = H CubeProjector(val_i // i)

其中，H CubeProjector 表示的是一個帶標籤的哈希函數，使用的標籤為 “CubeProjector” 。

然後，每一個公鑰被投射為：

pk_i'= pk_i + t_i.G

最終的投射公鑰集合為：

(pk_1', pk_2', ... , pk_u')

然後，它們被傳入原本的 MuSig2 聚合流程中：

KeyAgg(pk_1', pk_2', ... , pk_u')

剩下的 MuSig2 簽名流程無需再修改。至於簽名的正確性，每一個參與者都可以使用一樣的調整項來投射自己的私鑰：

sk_i' = sk_i + t_i

投射出來的私鑰會用在剩餘的 MuSig2 nonce 生成和碎片簽名生成中，就跟原本的協議一樣。最終得到的聚合公鑰 —— 叫做 “投射器公鑰” —— 就同時綁定了簽名人身份和顯式的價值承諾。

這種價值綁定屬性，對於輕量化的限制條款模擬來說是極為關鍵的。在標準的 MuSig2 構造中，聚合僅僅承諾簽名者的公鑰。 結果是，惡意的協調者可以嘗試手機對多個限制條款狀態都有效的簽名，只要簽名者不完全知曉自己在簽名什麼。

在投射器中，這種攻擊收到實質性的約束，因為只要被承諾的價值改變了，聚合限制條款公鑰自身就會改變。因為限制條款腳本公鑰是從投射聚合公鑰中推導出來的，簽名權限就跟內在弟跟一個具體的價值狀態綁定。因此，不完全驗證的簽名運行環境也能安全地參與限制條款執行，只需運行最少量的確定性驗證邏輯。

主機箱子投射

“主機箱子投射（Hosted Box Projection）” 指的是輕量級的限制條款簽名運行環境，對廣闊的限制條款執行圖譜僅有少量語境感知。一個主機箱子本質上就是一個輕量級的、永遠在線的限制條款模擬服務，運行在一個用戶控制的設備上，類似於一直在後臺工作的路由器、轉發器或者節點軟件。這個設備可能是參與者自己運行的，也可能部署在外部的託管基礎設施上，但它的角色是有意限定的：在 Engine 請求時，參與投射器簽名會話。

主機箱子不是一個完整的智能合約運行環境，而是一個有限的限制條款模擬節點，僅僅負責參與綁定價值的投射器簽名流程。主機箱子不需要完全理解合約語義、交易流程乃至執行內容。它只需要安全地參與投射器簽名會話，這個過程只需要驗證很少的一些確定性屬性，例如：

• 自己的公鑰是否在聚合集合中，以及
• 所請求的價值綁定投射器參數是否有效。

一旦這些檢查通過，主機箱子就可以安全地參與剩餘的 MuSig2 簽名流程、為投射出的聚合公鑰製作一個碎片簽名。

這個模式的安全性來自綁定價值的聚合自身。因為限制條款腳本公鑰與顯式的價值承諾形成了密碼學綁定，在替代性限制條款狀態中複用簽名權限的惡意嘗試，只會得到另一個投射器聚合公鑰，以及完全不同的限制條款腳本公鑰。因此，主機箱子可以安全地作為一個輕量級的限制條款模擬引擎，無需完全知曉限制條款的執行；所以它也適合放在永續運行的低能耗設備中。

黑箱投射

投射器還帶來了一個廣闊的未來研究方向，叫做 “黑箱投射（Black Box Projection）”。在這種模式下，限制條款簽名運行環境是一個受到限制的 輸入/輸出 系統，暴露儘可能少的內部狀態、簽名邏輯和執行語義，同時依然能安全地參與綁定價值的限制條款執行。

因為投射承諾在限制條款層面綁定了價值，黑箱投射也許能帶來非交互的限制條款參與：簽名運行環境不再需要完全解讀或驗證相關的執行背景，只需要執行最簡單的結構性檢查。這將讓限制條款模擬流程流暢很多、減少交互的複雜性，並且打開極易擴容的輕量化限制條款簽名運行環境作為受約束的密碼學投射設備（而不是完全帶狀態的執行參與者）的可能性。

虛擬黑箱

一種可能的方向是隔離的虛擬限制條款簽名運行環境，作為一個 輸入/輸出 黑箱。這樣的系統可以安全地參與投射器簽名會話，只需執行儘可能少的確定性驗證邏輯，比如驗證簽名人隊伍和驗證價值綁定投射器參數符合與其。因為投射器聚合公鑰是價值綁定的，在多個限制條款狀態中重播或者惡意的雙重簽名嘗試已經受到限制。這讓高度簡化的簽名環境有能力安全地參與限制條款執行，無需對智能合約執行的完全感知。

物理黑箱

一個更加不確定的方向則是物理黑箱限制條款設備。這樣的系統，理想情況下，允許實際傳遞一個簽名設備給對手方，同時依然完全不會暴露其內部的私鑰材料，不論檢查還是篡改。

一種假想的架構可能包括在穩定可持續的電磁場中，或者在真空隔離的密閉環境中存儲簽名私鑰。在這種模式下，任何物理上的偵測、拆卸或干擾設備的行為，都會摧毀這個密閉環境，從而不可避免會摧毀其中的私鑰。雖然這有些異想天開，但這樣的系統表面了限制條款簽名基礎設施中的一個可能的長期方向：物理上受約束的簽名運行環境，有能力安全地參與投射器限制條款執行，同時保持強壯的密碼學隔離安全。

跳躍

“跳躍（Lifting）” 是鏈內的比特幣 UTXO 原子化地轉型為 Cube 原生的虛擬輸出的過程。從概念上來說，跳躍將比特幣從直接的鏈內所有權 “轉移” 到 Cube 虛擬化執行環境中，然後，資金可以在這個環境中參與普通的轉賬和智能合約調用。

比特幣必須先跳躍，然後才能在 Cube 系統中流通。因此，跳躍是正式的入門機制，經過這個機制，外部的鏈內流動性進入 Cube 執行環境，在整個過程的每一步中，都保持保管能力。

- 跳躍 -

跳躍輸出

一個 Lift 是一種專門的入門交易的輸出，用來將裸的鏈內比特幣轉化為 Cube 原生的虛擬輸出。一個 Lift 輸出得到注資後，參與者和其 Engine 在跳躍過程中將這個 Lift 輸出換成 1:1 對應的 VTXO。實際上，這個 Lift 輸出是被提升為一個超時樹虛擬所有權對象。Lift 輸出攜帶以下的花費條件：(Self + Engine) or (Self after 3 months)：

• 跳躍路徑：參與者和其 Engine 通過 Self + Engine 路徑合作式簽名。作為交換，參與者在 Cube 系統內收到一個 1:1 對應的 VTXO。
• 退出路徑：如果 Engine 不合作，或者拒絕處理跳躍操作，參與者可以在定義好的超時時段結束後，獨自通過超時復原路徑取回其中的比特幣。

階梯式退出與分叉見證

- 單方面退出路徑 -

在不合作情形中，也就是 Engine 拒絕合作式處理參與者取款或者合約退出，Cube 提供了單方面退出機制，辦法是一種攜帶元數據交易類型，叫做 tx::exit-ladder。

參與者可能會為這兩種資金形式調用單方面退出路徑：

1. 直接取出餘額，例如未解決的互換（Swapout）條目，以及
2. 退出合約控制的影子餘額，通過 Call -> Swapout 執行路徑。

在正常情況下，這些退出活動會由其 Engine 在一個 “批次（Batch）” 中合作式處理。如果 Engine 拒絕包含或者說執行參與者請求的退出活動，這個參與者可以轉而通過在鏈內廣播 tx::exit-ladder 交易強制執行。

tx::exit-ladder 交易包含了元數據，編碼了 Engine 拒絕合作式處理的待處理退出操作。具體來說，這種交易攜帶了 APE 編碼的 “條目類型（Entry Kind）”，對應著意圖執行的批次操作。因此，這種單方面退出交易是一種鏈內的上訴路徑（否則，相關狀態轉換將在鏈外保持虛擬化狀態）。

除了退出元數據本身，tx::exit-ladder 交易還攜帶了一個 “連接器（Connector）” 輸出點，用於 “分叉見證（fork attestation）”。

這個連接器存在，是為了解決存在於許多基於 BitVM 的橋接合約和爭議解決架構中的一個基本的 “分叉挑選問題（fork-selection problem）”：無論挑戰者還是證明者，都無法可靠地見證（attest）有爭議的狀態轉換實際發生的那條正統鏈。

沒有這樣的見證，惡意的運營者就可以嘗試挖出或者轉發一個替代性的、不誠實的分叉，單方面退出交易在這個分叉上並不存在，從而逃避激活挑戰機制或者 ZKTLC 的懲罰流程。

Cube 通過顯式的輸出點見證來防止這種攻擊。

來自 tx::exit-ladder 交易的連接器輸入會成為對應的 tx::fork-attest 交易的輸入。因為連接器必然來自單方面退出交易自身，Engine 就無法在一個不存在這筆 exit-ladder 交易的衝突鏈條上構造出有效的分叉見證路徑

因此，單方面退出交易的存在，就跟可挑戰的爭議環境自身形成密碼學關聯。Engine 無法通過選擇性確認另一個沒有單方面退出請求的分叉鏈來逃避激活挑戰機制。

tx::fork-attest 交易是通過一個 2-of-2 構造、使用 SIGHASH_ALL | ANYONECANPAY 標籤預先簽名的，並且額外嵌入了一個 SIGHASH_ALL CHECKSIG 驗證路徑來確保交易包含了來自 tx::exit-ladder 交易的連接器輸出點。

最終，單方面退出路徑通過顯式的輸出點關聯，見證了自身所在的鏈條。這讓挑戰者和參與者可以可靠地證明這次單方面退出的申訴所發生的爭議鏈條，防止針對 ZKTLC 挑戰-應答 機制的分叉選擇模稜兩可攻擊。

數據可得性編碼

- 編碼方法比較 -

Cube 使用了一種定製的交易編碼格式，叫做 “Airly Payload Encoding（APE）”，這是專門為優化 Cube 的數據可得性效率而設計的。

APE 的主要目標是在比特幣區塊空間中儘可能提高交易密度，辦法是儘可能較低每一筆交易的編碼開銷。通過激進的載荷壓縮、緊湊索引和基於聚合編碼策略，Cube 能夠可靠地在一個比特幣區塊內容納更多的狀態轉換（相比傳統的 EVM 或 zkEVM 架構）。

通用的編碼方法，比如 “RLP”，會將靈活性和遞歸結構表示放在首位，但 APE 是專門為確定性的 rollup 執行和緊湊的狀態轉換編碼而設計的。這種編碼方法假設了一個受約束的執行環境，它帶有預先定義的類型系統、確定性的調用數據（calldata）格式，以及協議層的所隱藏保證，所以 Cube 能夠消除 大量傳統的 EVM 兼容系統所需的元數據開銷。

APE 由以下幾種互補的壓縮和編碼技術組成。

1. 比特級編碼

Cube 為交易字段和數值類型使用了比特級編碼，而不是 EVM 和 zkEVM 系統所使用的傳統的基於字節的編碼方案。

傳統的編碼方案，比如 RLP，其操作粒度是字節，意味著數值將被擴展為字節對齊的表示形式，連數值的實際熵只需要少得多的比特（就能表示）時也不例外。在體積較大的交易載荷中，這會帶來客觀的累積開銷。

APE 取消了這個字節對齊假設，直接以比特來編碼數值，根據它們的實際熵，而不是它們名義上的類型寬度。

比如說，傳統的系統會：

• 使用 4 字節來序列化一個 u32 （無符號的 32 比特整數）數值；
• 使用 8 字節來序列化一個u64 數值；

不管實際的表示範圍。然而，實際上，許多交易字段，比如索引號、標籤、選擇符、計數器和緊湊的數值類型 ，很少用盡全部空間。

因此，APE 將這些字段動態地壓縮成更小的字節表示，通常可以：

• 為一個 u32 數值節約大約 1 ~ 3 字節
• 為一個 u64 數值節約大約 1 ~ 7 字節

同時只會帶來額外的 1 到 2 比特開銷。

因為 Cube 只在一個確定性的、協議約束的執行環境中操作，調用數據的格式和類型結構都是已知的，這種方法變得非常高效。因此，Cube 可以激進地降低序列化開銷，而不需要 RLP 這樣的遞歸的自我描述的元數據結構。

詳見：數值類型。

2. 基於排名的索引

Cube 根據交易的頻率而不是登記的順序來索引賬戶和合約。

每次一個賬戶發起一筆交易，或者一個合約被調用的時候，它的分數就會增加 1 。隨著時間推移，頻繁被訪問的賬戶和合約會獲得更小的索引表示。

這讓被重度使用的系統原語 —— 比如 AMM 池，穩定幣合約以及主要的流動性中心 —— 最終可以壓縮成非常小的索引表示，通常可以實現單字節尋址。

這個排名和索引求解系統是在內存和執行層中維護的，所以 Cube 可以避免重複地傳輸大體積的靜態標識符，比如 20 字節長的 EVM 地址或者固定長度的合約標識符。

詳見：登記管理器。

3. 無前綴的調用數據

Cube 將調用數據元素直接映射成預先定義的類型格式，都有確定性的長度。

結果是，calldata 元素不需要以數值長度為前綴的顯式遞歸編碼方法（比如 RLP 中的方法）。因為解碼器已經知道了預期的結構和 calldata 格式的字段寬度，額外的前綴元數據也就變得不必要了。

這又消除了一直跟 EVM calldata 序列化相關的前綴開銷，同時簡化了確定性的載荷解析。

詳見：Calldata 元素。

4. 常見數值查找表

Cube 為經常出現的交易數值使用了一種基於查找表（lookup）的編碼機制。

頻繁使用的數值，比如常見的轉賬數額、流動性數量，乃至合約互動面額 —— 都會通過緊湊的查找表索引來表示，而不是反覆地序列化成全寬度格式。

這種優化對於面額模式在大的交易集合中反覆出現的金融原語尤為有用。通過將反覆出現的數值模式編碼成緊湊的查找表索引，Cube 實質性減少了大量重複的載荷開銷。

詳見：常見數值。

5. 緊湊調用方法

Cube 還通過一種緊湊的變長原語來編碼合約調用方法，叫做 AtomicVal 。

EVM 使用 4 字節長的函數選擇器，Cube 則動態分配儘可能少的比特來表示一個合約內可以調用的方法。

舉個例子，一個暴露了 4 個可調用方法的合約，只需要 2 比特就可以選出方法。

這大大降低了每次調用的開銷，並且隨著交易吞吐量提高會變得更有好處。

詳見：AtomicVal 。

6. 簽名聚合

Cube 將賬戶的 Schnorr 公鑰映射到 BLS 兼容的聚合空間，並在交易間執行非交互的簽名聚合。

結果是，多筆交易的簽名可以壓縮成一個固定長度的聚合簽名，而不是每一筆交易都需要一個簽名或者大體積的零知識有效性證據。

這大大減少了跟簽名相關數據可得性開銷，同時保持了緊湊的區塊層面的驗證語義。

詳見：BLS 。

7. 最小化的 target 編碼

Cube 還將傳統的基於 nonce（流水號）的交易排序替換成一種緊湊的、抗重播的字段，叫做 Target。

在 Cube 中，各條目（Entries）不是攜帶單調遞增的賬戶 nonce，而是一個最小化編碼的 Target，表明這個條目意圖在某個批次高度執行。這種 Target 機制支持當前的批次機制，以及由受限制的回溯窗口（最多 5 個批次）。

這防止了推遲廣播的重播行（惡意的 Engine 嘗試扣住想要執行的條目，或者等到未來的狀態轉換再廣播 以往簽名的條目）。僅在其意圖的執行窗口內，條目才是有效的，所以未來的重新廣播的嘗試是無效的。

因為在實踐中，絕大多數條目都以當前的批次高度為 Target ，編碼開銷變得非常小。一個比特就足以表示在當前高度執行，額外的回溯深度也只需要多兩個比特。

結果是，Cube 將傳統的固定寬度 nonce 字段 —— 通常是 8 字節 —— 換成了一種抵抗重播的機制，通常需要幾個比特。詳見：Entry 。

詳見：Target 。

8. 最小化的經濟字段

Cube 將傳統的統計 gas 的字段換成了緊湊的、基於執行操作的字段，叫做 Ops Price 以及 Ops Budget。

Cube 不會為每一個條目重複編碼大體積的固定寬度的 gas 參數，而是假設協議定義的默認值，僅僅編碼對默認值的偏離。

Ops Price 字段指明這個條目是否要使用協議的基礎執行價格，還是指定一個額外的執行溢價。在常見情形中，一個比特就足以指明使用默認基礎價格。如果要求使用溢價，只需緊湊地編碼超過基準的差值。

類似地，Ops Budget 字段表明這個條目是否要指定一個自定義的執行預算。一個比特就足以確定是否存在一個顯式的預算。如果有，額外的比特只編碼請求預算數量。

因為在現實中，絕大部分條目都按默認的執行假設下操作，兩個字段通常都只消耗很少的比特；單依然能支持變動的執行價格和受約束的執行控制（在有必要時）。

詳見：Ops Price 以及 Ops Budget 。

9. 斷言

Cube 是在一個依靠斷言的執行模式種運行的，在其中，只有有效的交易會被允許進入有價值的批次。

失敗的狀態轉換會被排除在最終載荷之外，因此永遠不會消耗永久性的數據可得性空間。相反，EVM 和 zkEVM 系統都允許失敗的交易永遠記錄在區塊鏈上，哪怕它產生了無效（或者說逆轉）的執行結果。

通過消除永久記錄失敗執行的機制，Cube 實現了額外的歷史區塊空間效率，並且形成了一種更加清晰地執行狀態模式。

TPS 預估

下文預估了 Cube 的理論交易吞吐量，假設使用 APE 的普通交易範式。這份預估主要關注的是裸的數據可得性效率，並將 Cube 與 zkEVM 風格的 rollup 和傳統的 EVM 交易格式作對比。

因為 Cube 通過比特極編碼、緊湊索引、無 nonce 機制、最小化經濟字段、緊湊的 calldata 格式，以及情況話的調用方法編碼，激進地降低了序列化開銷交易，平均的交易載荷體積大大小於傳統的智能合約系統。

AMM Swap

- 自動做市商互換 —— TPS 預估 -

以普通的自動做市商互換操作為例，Cube 每筆交易只需消耗大約 10.7 字節（大約 2.67 vByte）的區塊空間。

相比之下：

• 同等級的 zkEVM 交易消耗大約 33 字節；
• 傳統的 EVM 交易消耗大約 110 字節。

因此，Cube 預計可以支持：

• 大約 3.1 倍數量的 AMM 互換（相比等價的 zkEVM 系統，在比特幣上）；
• 大約 10.5 倍數量的 AMM 互換（相比標準的 EVM 環境）。

Token 轉移

- Token 轉移 —— TPS 預估 -

以標準的 token 轉賬為例，Cube 每筆交易只需消耗大約 9.7 字節（大約2.42 vByte）的區塊空間。

相比之下：

• 同等級的 zkEVM 交易消耗大約 33 字節；
• 傳統的 EVM 交易消耗大約 126 字節。

因此，Cube 預計可以支持：

• 大約 3.1 倍數量的 token 轉賬（相比等價的 zkEVM 系統，在比特幣上）；
• 大約 10.5 倍數量的 token 轉賬（相比標準的 EVM 環境）。

（完）