Cube 简介

介绍 Cube

Cube 是一个虚拟机，旨在比特币上原生实现无需信任的智能合约执行。它提供了完全无需信任的执行环境，支持单方面退出，确保用户对其资金拥有完全控制权。通过将 BitVM 与超时树相结合，并利用比特币的数据可用性（DA），Cube 将 BTC 直接整合到一个具有全局状态的虚拟机中。这种方法将比特币的基础设计与图灵完备的智能合约执行模型结合起来，同时不引入交易对手风险，为扩展比特币功能提供了一种新颖的框架。

圣杯

比特币是最安全且经过实战考验的加密货币，但其脚本限制和可扩展性挑战限制了它在点对点支付之外支持复杂金融交易的能力。这些并非缺陷，而是有意为之的约束，旨在保持使比特币有价值的特性：抗审查、自我托管和对抗鲁棒性。然而，其结果是比特币无法原生支持全球货币层所需的可编程性、吞吐量或金融复杂性。智能合约、去中心化金融和高频结算需要一个执行环境，而比特币在其基础层从未被设计来提供这些。

解决方案不是改变比特币，而是在其之上构建。有效的 Layer 2 必须在不损害其核心属性的情况下扩展比特币的能力。它必须支持可编程的智能合约，同时保留自我托管的保证，即没有任何中介机构可以扣押或冻结用户的资金。而且，它必须在不要求改变比特币协议、不引入可窃取资金的可信中介、也不强迫用户信任他们从未见过的仪式、委员会或桥接操作者的情况下实现这一点。

许多提出的扩容方案以牺牲信任模型为代价来扩展比特币的功能。许多设计依赖于 1-of-n 的信任假设，即系统安全取决于至少一个诚实方。这种设计损害了比特币去中心化和无需信任的核心精神；它不会是比特币的长期扩容解决方案。

CUBE

Cube 引入了一种根本独特的方法来实现比特币的可编程性：一种原生 Layer 2，旨在将完全无需信任的智能合约执行直接带到比特币上，无需桥接、联邦、外部共识系统或比特币协议修改。Cube 不是将比特币移入另一个信任域以换取可编程性，而是将比特币原生的自我托管和结算模型扩展到可编程执行环境中，同时保持从根本上锚定在比特币本身。

Cube 的核心目标是实现历史上在比特币系统中被认为是矛盾的东西：无需信任的托管与通用可编程性。传统的智能合约环境通过将比特币的所有权和结算模型抽象到外部验证器、桥接、多签或联邦托管假设之后来实现可编程性。相反，Cube 直接在执行层下方保留比特币原生的所有权，允许可编程智能合约在不牺牲单方面退出、自我托管或比特币强制赎回保证的情况下运行。

Cube 利用比特币本身作为执行环境之下的底层结算、争议解决和最终所有权层。智能合约执行在链下乐观地进行，而结算保证、单方面退出和挑战-响应强制执行最终通过原生比特币原语回退到比特币上。

Cube 架构的核心是引擎（Engine），它是一个协调层，负责接收参与者的交易条目，将其排序成批次（Batch），并生成锚定在比特币上的结算交易。在正常操作下，引擎乐观地推进状态转换，协调执行而无需立即进行链上结算。至关重要的是，引擎纯粹充当协调者，绝不充当托管者。

Cube 的主要设计目标是无需信任的可编程性，而不牺牲比特币原生的自我托管。每个参与者通过由比特币脚本直接强制执行的 MuSig2 契约模拟，始终对其资金保持单方面控制。资金持续锁定在参与者和引擎之间的协作性 2-of-2 结构中，构成管理 Cube 执行环境的基础所有权原语。

由于 Cube 从未直接拥有参与者资金，因此引擎无法独立移动资产、扣押余额或阻止最终提款。参与者保留通过超时树结算路径和挑战-响应升级机制在比特币上单方面强制执行其退出条件的能力。

因此，Cube 在托管层保持完全无需信任，同时直接在比特币之上启用通用智能合约可编程性。参与者不依赖操作者、委员会、联邦或外部验证器来诚实保护资金。相反，所有权保证由比特币脚本、单方面退出路径和加密挑战-响应结构本身强制执行。引擎无法窃取，因为协议结构本身阻止了它，而参与者通过直接密钥所有权和比特币强制赎回保证对资金保持持续主权。

虚拟化计算所有权

Cube 的执行架构由两个比特币原生原语组成：(1) 类似 Ark 的超时树所有权虚拟化，以及 (2) 类似 BitVM 的可反驳计算。

超时树提供了可扩展的虚拟化所有权和单方面赎回保证，允许参与者在链下虚拟输出上进行交易，同时保留独立退出到比特币的能力。BitVM 通过将虚拟化所有权扩展到虚拟化计算来补充这一点，使得断言的状态转换可以通过比特币原生的交互式反驳变得可挑战和可强制执行。

Cube 将这两个基础原语组合成一个统一的执行原语，称为零知识时间锁定合约（ZKTLC）。

从概念上讲，(1) 超时树解决了所有权虚拟化问题，而 (2) BitVM 解决了计算强制执行问题。Cube 将两者结合在一起，使得可编程状态转换可以在链下乐观地进行，同时通过比特币本身保持可赎回和可挑战性。

核心上，一个 ZKTLC 是一个超时树虚拟输出，携带一个可通过 BitVM 反驳强制执行的零知识计算断言。

ZKTLC

ZKTLC 扩展了 Ark 式超时树系统中使用的 VTXO 模型，增加了可编程计算和挑战-响应语义。传统的 VTXO 主要代表对价值的单方面赎回声明，而 ZKTLC 还代表用户和引擎之间可挑战的计算断言。因此，虚拟输出不仅成为对价值的声明，也成为对引擎断言的状态转换正确性的声明。

在高层次上，这种关系类似于现有的双方比特币结构。在 Lightning 中，通道通常是用户和 Lightning 服务提供商之间的 2-of-2 关系。在 Ark 式系统中，虚拟输出作为用户和 Ark 服务提供商之间的 2-of-2 关系运作。在 Cube 中，ZKTLC 作为用户和引擎之间的 2-of-2 BitVM 挑战-响应关系运作。

Cube 的执行环境遵循 BitVM3 式执行模型，其中断言的 Groth16 验证器计算被转换为乱码电路验证器环境，可通过比特币原生的挑战-响应反驳强制执行。断言的计算对应于引擎承诺的状态转换的有效性。更具体地说，引擎证明提议的转换根据 (1) 比特币和 (2) CubeVM 共识规则正确执行，并且相对于先前承诺的状态没有发生无效的状态转换。

Cube 不是直接在比特币上执行任意计算，而是执行紧凑的验证器断言，其正确性稍后可通过 BitVM3 反驳环境进行挑战。因此，底层验证器电路代表了 CubeVM 状态转换系统本身的有效性规则，包括执行语义、合约约束、余额不变量、状态转换有效性条件以及管理结算正确性的相关比特币共识规则。

断言的计算通过承诺的乱码表、导线标签承诺、挑战转录和对应于验证器电路的揭示秘密结构来表示。在协作执行下，争议环境保持休眠，而引擎乐观地推进状态转换。在对抗条件下，参与者可以通过断言见证本身强制披露可评估的验证器输入，在本地重建承诺的乱码 Groth16 验证器，并独立评估断言转换。如果评估产生无效结果，乱码验证器会推导出对应于失败输出导线标签的反驳秘密，允许参与者通过承诺的比特币哈希锁条件触发相关的惩罚性结算路径。

因此，参与者控制着包含单方面赎回权利和针对引擎断言执行状态的加密可强制执行反驳权利的虚拟化所有权对象。

与依赖生态系统范围可信仪式或 MPC 委员会的传统零知识系统不同，Cube 为每个参与者独立限定证明环境。在账户初始化期间，每个参与者直接与引擎一起执行个人设置仪式，生成参与者限定的证明参数，参与有毒废物生成，并控制自己的有毒废料销毁。

因此，从参与者的角度来看，设置本身变得无需信任。信任并非继承自外部 MPC 委员会、可信协调器或共享证明环境，而是加密地局部化到参与者自己的 ZKTLC 环境中。

超时树

Cube 利用超时树作为执行环境之下的底层所有权和单方面退出架构。

超时树是一种预签名的事务树结构，允许大量虚拟化所有权对象共享一个共同的结算结构，同时为单个参与者保留单方面赎回保证。不需要每一笔中间所有权转换立即在比特币上结算，参与者可以在嵌入共享事务树内的虚拟化输出上进行乐观交易。

在协作执行下，超时树保持休眠，而所有权转换在链下发生。如果协调失败或引擎变得不诚实，参与者可以在相关超时条件成熟后，直接在比特币上独立物化并赎回相应的超时树分支。

Cube 采用超时树作为 ZKTLC 执行之下的基础结算和所有权原语。系统内每个参与者的余额最终都解析回一个可通过比特币脚本直接强制执行的超时树赎回路径。

从概念上讲，超时树为 Cube 提供了所有权虚拟化，而 ZKTLC 则用可编程计算和挑战-响应语义扩展了这些所有权对象。从这个意义上说，Cube 的执行架构可以理解为 Ark 式虚拟化所有权与 BitVM 式可反驳计算的组合，并直接锚定在比特币结算保证上。

CubeVM

Cube 引入了一个定制的虚拟机，称为 CubeVM，实现为比特币脚本的扩展分支，专为比特币上的无需信任智能合约执行而设计。CubeVM 不是取代比特币的执行哲学，而是将比特币脚本的基于栈的执行模型扩展为针对单方面退出和可反驳计算优化的可编程全局状态环境。

CubeVM 用通用智能合约计算所需的额外操作码扩展了比特币脚本。虚拟机引入了对全局状态管理、持久合约存储、分段执行环境、高级内存管理、256 位算术、椭圆曲线操作、栈元素操作、合约调用语义以及影子操作码的原生支持，这些操作码被设计为直接与比特币作为底层资产一起工作。

与像 EVM 这样的账户原生虚拟机不同，CubeVM 是从基本原理设计的，旨在将可编程执行带入比特币原生的自我托管中。因此，智能合约状态转换始终保持与 Cube 的超时树结算架构和反驳模型的兼容性。

CubeVM 的定义性架构原语是其对**影子（Shadowing）**的原生支持，允许合约控制的逻辑余额连续投射到参与者可归属的单方面退出对象中。影子充当了可编程智能合约执行与比特币根本上以密钥为中心的所有权模型之间的语义桥梁。通过这种机制，CubeVM 使得可编程智能合约可以直接在比特币上运行，同时在合约执行期间保持完全抵押的单方面赎回保证和持续的自我托管。

影子

像以太坊这样的可编程智能合约系统运作在一种与比特币原生设计根本不同的所有权模型上。在比特币中，资金由公钥控制。所有权通过产生有效数字签名的能力来表达，Coin最终由行使自由裁量权签名权限的账户管理。另一方面，智能合约运作方式不同。智能合约在账户原生意义上并不拥有自由裁量权或意志。合约持有的资金完全根据确定性程序逻辑和状态转换来管理。在实践中，合约逻辑本身成为价值的托管者。这种区别在比特币原生所有权和可编程智能合约语义之间创造了根本性的不兼容。

BitVM 和乱码电路从根本上运作在密钥原生环境中。它们的原语围绕公钥、签名、挑战-响应协议以及与个体实体相关的可证明计算。虽然 BitVM 可以验证任意计算，但底层所有权模型保持不变：比特币仍然理解密钥，而不是逻辑。可执行逻辑本身不能直接以 UTXO 方式拥有比特币。因此，出现了两个不同的语义域。比特币使用密钥的语言，而智能合约使用逻辑的语言。这些系统本质上不可互操作，因为比特币没有用于逻辑持有价值的原生抽象。为了弥合这种不兼容性，本工作引入了一个称为影子的中间抽象。

影子充当逻辑原生托管和比特币原生占有语义之间的翻译层。影子不是试图使可执行逻辑本身成为比特币拥有实体，而是允许合约管理的余额投射到与公钥关联的一组参与者可归属余额中。影子背后的核心观察是，虽然资金可能暂时存在于合约逻辑的托管之下，但此类资金在整个合约生命周期中仍可经济地归因于各个参与者。

通常，在像以太坊这样的可编程智能合约系统中，Coin经历一个重复的托管生命周期：它们最初处于直接账户所有权之下，暂时进入合约控制的逻辑托管，最终在提款或结算时返回到直接账户所有权。参与者最初通过原生密钥控制的账户余额控制Coin。然后参与者可以将这些Coin存入智能合约——例如比特币支持的稳定币合约、AMM 流动性池或其他可编程金融原语——此时资金不再由参与者的签名权限直接拥有，而是完全由合约的执行逻辑和状态转换规则管理。最终，在抵押品赎回、流动性提款或合约结算时，Coin再次回到公钥控制下的直接参与者托管。因此，有问题的阶段是中间状态，在此期间资金不再由参与者密钥直接控制，但同时不能表示为密钥拥有的余额，因为它们存在于逻辑托管下。正是这种中间逻辑占有状态，比特币原生所有权语义和智能合约原生执行语义不再自然对齐。

影子通过不表示合约本身的托管，而是表示合约对参与者的义务来解决这种不兼容性。合约持有的余额被连续投射到一组余额中，这些余额对应于在任何给定合约状态下经济上欠参与者密钥的确切数量。这种投射表示——影子状态——变得可以通过比特币原生结构来表达，尽管底层托管仍然完全由可执行逻辑管理。通过这种机制，合约管理的Coin可以连续映射到与参与者公钥关联的单方面退出超时树上。因此，虽然底层比特币仍处于逻辑托管下，但参与者保留对应于每个状态转换时欠他们的确切数量的连续可赎回声明。在这个意义上，影子充当了 BitVM 的密钥原生挑战框架和智能合约式逻辑托管之间的语义桥梁。可执行逻辑管理资金，而这些资金的影子则通过比特币原生公钥结构保持连续可赎回。

影子空间

在实现方面，影子抽象具体化为一个专用的合约管理分配空间，称为影子空间。部署在 Cube 上的每个智能合约都被分配了自己的影子空间，它充当负责管理参与者可归属影子余额的会计层。从概念上讲，影子空间作为一个合约本地分配数据库，由以下映射组成：

$account_key \rightarrow shadow_balance$

其中每个条目代表在底层Coin处于合约托管下时，经济上可归属于或“欠”给给定参与者账户的比特币数量。因此，影子空间并不代表 UTXO 术语中的直接Coin所有权。相反，它代表合约持有流动性的投射赎回状态，形式与 BitVM 的密钥原生挑战和单方面退出框架兼容。影子分配通过一组专用的影子操作码创建和管理，允许合约随着合约状态的发展，随时间初始化、增加、减少或按比例重新平衡参与者可归属余额。

对于任何参与者账户，以下之和：

1. 账户的原生余额，
2. 该账户在所有合约中所有影子分配的总和，

定义了参与者在任何给定状态转换下跨超时树的有效单方面退出可赎回余额。

重要的是，合约的总影子分配严格受限于合约本身持有的实际余额。合约影子空间内所有影子余额之和不得超出该合约当前控制的比特币数量：$Contract\ Balance \ge \sum Shadow\ Allocations$

任何导致影子分配超出合约实际比特币余额的操作都被视为无效，并在 VM 级别被拒绝。这个约束保证所有投射的影子余额始终由合约持有的流动性全额抵押，确保始终有足够的单方面退出流动性用于所有参与者可归属余额。

影子操作码

CubeVM 引入了一组专用的操作码来管理合约的影子空间：

影子操作码

这些操作码提供了在合约执行期间维护参与者可归属影子余额所需的基础状态转换操作。OP_SHADOW_ALLOC 在合约的影子空间内为参与者账户初始化一个新的影子分配条目，初始余额为零。一旦分配，可以使用 OP_SHADOW_UP 和 OP_SHADOW_DOWN 来增加或减少与该参与者关联的影子分配。

例如，考虑一个比特币抵押的稳定币合约。当参与者将比特币作为抵押品存入合约时，存入的Coin由合约的内部执行逻辑管理，而非参与者的签名权限。此时，合约调用 OP_SHADOW_UP 将参与者的影子分配增加相应的抵押金额。虽然存入的比特币现在在技术上处于合约本身的逻辑托管之下，但等价的参与者可归属余额通过影子空间投射到单方面退出超时树上。这保证了尽管底层Coin实际上锁定在合约内，但足够的单方面退出流动性仍可由参与者连续赎回。这是影子如何桥接 BitVM 的密钥原生赎回模型与智能合约式逻辑托管的核心机制。

除了每个账户的分配操作外，CubeVM 还通过 OP_SHADOW_UP_ALL 和 OP_SHADOW_DOWN_ALL 引入了按比例重新平衡操作。与对单个参与者余额操作的 OP_SHADOW_UP 和 OP_SHADOW_DOWN 不同，_ALL 变体根据当前相对权重，按比例增加或减少整个影子空间中所有参与者的分配。这些操作对于像 AMM 这样的池化流动性系统特别有用。当池化比特币流动性因交换、费用或流动性事件而增加或减少时，合约可以在单个操作码执行中按比例重新平衡所有流动性提供者的影子分配，而不是在合约逻辑中逐个遍历参与者。这显著简化了池化金融原语的实现复杂性，同时为所有参与者保留完全抵押的单方面退出保证。

投影器

Cube 利用一种修改后的 MuSig2 聚合结构，作为在比特币缺乏原生契约操作码情况下的轻量级契约模拟机制。Cube 不依赖协议级别的契约原语，而是通过称为投影器（Projector）的、与价值绑定的聚合签名结构来模拟契约行为。

与传统的 MuSig2 聚合不同，投影器不仅将聚合契约密钥绑定到签名者身份，还绑定到明确的价值承诺。这使得契约脚本公钥能够密码学地绑定到其意图的价值状态。

投影器的主要目标是实现轻量级契约执行环境，能够安全地参与契约签名会话，而无需完全理解合约执行状态或交易意图的语义。投影器参与者不是推理任意契约逻辑，而是可以使用最小的确定性验证规则安全地操作，同时抵抗重放、重新绑定或恶意双重签名尝试。

在高层次上，投影器将契约签名转化为一个受约束的投影问题：可执行合约状态被投射到与值绑定的公钥结构中，与 BitVM 原生的以密钥为导向的挑战模型兼容。

投影器通过一个预处理投影阶段扩展了原始的 MuSig2 聚合过程，该阶段在 BIP-327 中定义的标准 $KeyAgg(pk_1 \dots pk_u)$ 步骤之前执行。

投影器不直接将参与者公钥提供给 $KeyAgg$，而是引入了一个与值绑定的确定性投影函数：

$KeyProjectorAgg(pk_1, \dots, pk_u, val_1, \dots, val_u)$

其中：

• $pk_i$ 代表参与者公钥，
• $val_i$ 代表与每个参与者关联的以聪计的价值承诺。

对于每个参与者索引 $i$，投影调整量计算为：

$t_i = H_{CubeProjector}(val_i \parallel i)$

其中 $H_{CubeProjector}$ 表示使用标签“CubeProjector”的标记哈希。然后每个公钥被投影为：

$pk_i' = pk_i + t_i \cdot G$

得到的投影密钥集：

$(pk_1', pk_2', \dots, pk_u')$

随后被提供给原始的 MuSig2 聚合过程：

$KeyAgg(pk_1', \dots, pk_u')$

而不修改其余的 MuSig2 签名流程。为了签名正确性，每个参与者相应地使用相同的调整量投影其私钥：

$sk_i' = sk_i + t_i$

投影后的私钥随后用于其余的 MuSig2 随机数生成和部分签名程序，完全按照原始协议中的定义进行。因此，得到的聚合密钥——称为投影器密钥——在密码学上既绑定到签名者身份，也绑定到明确的价值承诺。

这种价值绑定属性对于轻量级契约模拟至关重要。在标准的 MuSig2 结构中，聚合只承诺签名者公钥。因此，如果轻量级签名者不完全理解其签署的内容，恶意协调器可能尝试获取跨替代契约状态的多个有效签名。

在投影器下，这类攻击受到极大限制，因为聚合契约密钥本身在承诺的价值配置发生变化时也会改变。由于契约脚本公钥派生自投影后的聚合密钥，签名权限本质上绑定到特定的价值状态。因此，轻量级签名环境可以安全地参与契约执行，同时只执行最小的确定性验证逻辑。

托管盒投影

托管盒投影（Hosted Box Projection）指的是在有限的上下文感知范围内运作、了解更广泛的契约执行图的轻量级契约签名环境。托管盒本质上是一个轻量级的、始终在线的契约模拟服务，运行在用户控制的设备上，类似于路由器、中继或节点软件在后台持续运行的方式。该设备可以由参与者自行托管，或部署在外部托管基础设施内，但其角色有意保持狭窄：在引擎请求时参与投影器签名会话。

托管盒不是作为完整的智能合约执行环境运行，而是作为一个受约束的契约模拟节点，仅负责参与价值绑定的投影器签名流程。托管盒不需要完全理解合约语义、交易流程或执行意图。相反，它通过仅验证最小的确定性属性来安全地参与投影器签名会话，例如：

• 它自己的公钥是否参与聚合集合，以及
• 请求的价值绑定投影参数是否有效。

一旦这些检查通过，托管盒就可以安全地参与剩余的 MuSig2 签名流程，并为投影后的聚合密钥生成部分签名。

该模型的安全性源于价值绑定聚合本身。由于契约脚本公钥在密码学上绑定到明确的价值承诺，恶意的跨替代契约状态重用签名权限的尝试会导致完全不同的聚合密钥，因此也导致完全不同的契约脚本公钥。因此，托管盒可以安全地作为轻量级契约模拟引擎运行，而不需要完全的契约执行意识，使其适用于持久的低资源部署环境。

黑盒投影

投影器还启用了一个更广泛的未来研究方向，称为黑盒投影（Black Box Projection）。在该模型中，契约签名环境表现为受约束的输入/输出系统，暴露最少的内部状态、签名逻辑或执行语义，同时仍然安全地参与价值绑定的契约执行。

由于投影承诺在契约级别本身是价值绑定的，黑盒投影潜在地实现了非交互式契约参与，其中签名环境不再需要完全解释或验证周围的执行上下文，仅需进行最小的结构检查。这显著简化了契约模拟流程，降低了交互复杂性，并为高度可扩展的轻量级契约签名环境开辟了可能性，这些环境作为受约束的密码学投影设备而非完全有状态执行参与者来运作。

虚拟黑盒

一个可能的方向涉及隔离的虚拟契约签名环境，作为 IO 黑盒运作。此类系统可以安全地参与投影器签名会话，同时仅执行最小的确定性验证逻辑，例如验证签名者包含性和验证预期的价值绑定投影参数。由于投影器契约密钥是价值绑定的，跨替代契约状态的重放或恶意双重签名尝试受到极大限制。这使得高度简化的签名环境能够安全地参与契约执行，而不需要完整的智能合约执行意识。

物理黑盒

一个更具推测性的方向涉及物理黑盒契约设备。此类系统理想地允许签名设备物理交付给交易对手，同时在检查或篡改下基本无法暴露其内部秘密材料。

一个假设的架构可能涉及将签名秘密存储在不断维持的电磁或真空隔离容纳环境中。在这种模型下，任何物理探测、打开或干扰设备的尝试都会导致容纳环境崩溃，并不可逆地销毁受保护的秘密材料。虽然高度理论化，但此类系统说明了契约签名基础设施中可能的长期方向：物理受限的签名环境能够安全地参与投影器契约执行，同时保持强大的密码学隔离保证。

提升（Lifting）

提升是将原生链上比特币 UTXO 原子性转换为 Cube 原生虚拟输出的过程。从概念上讲，提升将比特币从直接链上所有权“移动”到 Cube 的虚拟化执行环境中，资金随后可以参与普通转账和智能合约调用。

比特币必须先被提升，才能在 Cube 系统内流通。因此，提升作为规范的上线机制，外部链上流动性通过它进入 Cube 执行环境，同时每一步都保留托管权。

提升

提升输出

Lift 是一种专门的上线交易输出，用于将裸链上比特币转换为 Cube 原生虚拟输出。当 Lift 输出被注资时，参与者和引擎通过提升过程协作性地将 Lift 输出交换为相应的 1:1 VTXO。实际上，Lift 输出被提升为虚拟化的超时树所有权对象。Lift 输出携带以下花费条件 (Self + Engine) or (Self after 3 months)：

• 提升路径： 参与者和引擎通过 User + Engine 花费路径协作签名。作为交换，参与者收到 Cube 系统内相应的 1:1 VTXO 表示。
• 退出路径： 如果引擎变得不协作或拒绝处理提升操作，参与者可以在指定超时期限后通过超时恢复路径收回底层比特币。

退出阶梯与分叉证明

单方面退出路径

在不协作的情况下，即引擎拒绝协作处理参与者提款或合约退出，Cube 通过一种携带元数据的交易类型提供单方面退出机制，称为 tx::exit-ladder。

参与者可以为以下两者调用单方面退出路径：

1. 直接余额提款，例如未解决的 Swapout 条目，
2. 通过 Call -> Swapout 执行路线退出的合约控制影子余额。

在正常操作下，这些退出由引擎在批次内协作处理。如果引擎拒绝包含或执行请求的退出，参与者可以改为通过广播 tx::exit-ladder 交易在链上强制执行。

tx::exit-ladder 交易包含编码待处理退出操作的元数据，这些操作是引擎拒绝协作处理的。具体来说，该交易携带与意图执行的批次操作对应的 APE 编码条目类型。因此，单方面退出充当了本应是虚拟化链下状态转换的链上升级路径。

除了退出元数据本身，tx::exit-ladder 交易还携带一个用于分叉证明的连接器输出点（Connector outpoint）。

该连接器存在是为了解决许多基于 BitVM 的桥接和争议架构中存在的一个基本分叉选择问题：即挑战者或证明者无法可靠地证明存在争议的状态转换实际发生的规范链。

没有这样的证明，恶意操作者可能尝试挖掘或中继一个替代的非诚实分叉，其中单方面退出交易不存在，从而试图避免挑战激活或 ZKTLC 惩罚流程。

Cube 通过显式输出点证明来防止这类攻击。

来自 tx::exit-ladder 交易的连接器输出点成为相应 tx::fork-attest 交易的必需输入材料。由于连接器必须来自单方面退出交易本身，引擎无法在缺少退出阶梯交易的有冲突链上构建有效的分叉证明路径。

因此，单方面退出交易的存在在密码学上耦合到可挑战的争议环境本身。因此，引擎无法通过选择性承认缺少单方面退出请求的替代分叉来逃避挑战激活。

tx::fork-attest 交易通过 2-of-2 结构使用 SIGHASH_ALL | ANYONECANPAY 预签名，同时嵌入一个 SIGHASH_ALL CHECKSIG 验证路径，强制执行包含源自 tx::exit-ladder 交易的连接器输出点。

因此，单方面退出路径通过显式输出点链接变得可链证明。这使得挑战者和参与者能够可靠地证明发生单方面退出升级的规范争议链，防止针对 ZKTLC 挑战-响应机制的分叉选择模糊攻击。

数据可用性编码

编码比较

Cube 使用一种称为Airly 负载编码 (APE) 的自定义交易编码方案，专门针对 Cube 的数据可用性效率进行了优化。

APE 的主要目标是通过最小化每笔交易的编码开销，最大化比特币区块空间内的交易密度。通过激进的负载压缩、紧凑索引和面向聚合的编码策略，Cube 能够将比传统 EVM 或 zkEVM 架构多得多的状态转换打包到比特币区块中。

与像 RLP 这样优先考虑灵活性和递归结构表示的通用编码方案不同，APE 是为确定性 Rollup 执行和紧凑状态转换编码而专门构建的。该编码模型假设一个受约束的执行环境，具有预定义的类型系统、确定性的 Calldata 布局和协议级索引保证，允许 Cube 消除传统上在 EVM 兼容系统中所需的大量的元数据开销。

Airly 负载编码由几种互补的压缩和编码技术组成。

1. 位级编码

Cube 对交易字段和值类型使用位级编码，而不是 EVM 和 zkEVM 系统使用的传统面向字节的编码方案。

像 RLP 这样的传统编码以字节粒度操作，意味着即使值的实际熵需要更少的位数，它们也会被扩展为字节对齐表示。在大型交易负载中，这引入了大量的累积开销。

APE 移除了这种字节对齐假设，而是根据值的有效熵（而不是名义类型宽度）直接在位级编码值。

例如，传统系统序列化：

• u32 值使用 4 字节，
• u64 值使用 8 字节，

无论实际表示范围如何。然而在实践中，许多交易字段——例如索引、标志、选择器、计数器和紧凑值类型——很少需要其完整的可表示宽度。

因此，APE 动态地将这些字段压缩为更小的位表示，通常节省：

• u32 大约 1-3 字节，
• u64 大约 1-7 字节，

同时仅引入一或两位的开销。

这种方法尤其有效，因为 Cube 在确定性的协议约束执行环境中运行，其中 Calldata 布局和类型结构已经预先知道。因此，Cube 可以激进地最小化序列化开销，而不需要像 RLP 这样的递归自描述元数据结构。

参见 Valtypes。

2. 基于排名的索引

Cube 根据交易频率而非注册顺序对账户和合约进行索引。

每次账户发起交易或合约被调用时，其排名分数增加 1。因此，频繁访问的账户和合约会随时间迁移到更小的索引表示。

这允许使用频繁的系统原语——例如 AMM 池、稳定币合约或主要流动性中心——最终压缩成极小的索引表示，通常接近单字节寻址。

排名和索引解析系统在内存和执行层维护，允许 Cube 避免重复传输大的静态标识符，例如 20 字节的 EVM 地址或固定宽度的合约标识符。

参见 注册管理器。

3. 无前缀 Calldata

Cube 将 Calldata 元素直接映射到具有确定性长度的预定义类型布局。

因此，Calldata 项不需要像 RLP 中使用的显式递归长度前缀编码。因为解码器已经知道 Calldata 布局的预期结构和字段宽度，额外的前缀元数据变得不必要。

这消除了传统上与 EVM Calldata 序列化相关的前缀开销，同时简化了确定性负载解析。

参见 Calldata 元素。

4. 常见值查找

Cube 对经常出现的交易值使用基于查找的编码机制。

经常使用的值——例如常见的转账金额、流动性数量或合约交互面额——通过紧凑的查找索引表示，而不是反复以完整宽度形式序列化。

这种优化对于金融原语特别有效，其中重复的面额模式在大交易集中频繁出现。通过紧凑的查找引用编码重复的值模式，Cube 在大规模下显著减少了重复的负载开销。

参见 CommonVal。

5. 紧凑调用方法

Cube 通过一个称为 AtomicVal 的紧凑可变位大小原语来编码合约调用方法。

Cube 不使用 EVM 中的 4 字节函数选择器，而是动态分配表示合约内可调用方法所需的最小位数。

例如，一个暴露四个可调用方法的合约只需要 2 位用于方法选择。

这显著减少了聚合负载量中每次调用的开销，并且在高交易吞吐量下变得越来越有益。

参见 AtomicVal。

6. 签名聚合

Cube 将账户 Schnorr 密钥映射到 BLS 兼容聚合空间，并跨交易执行非交互式签名聚合。

因此，多个交易签名可以压缩为单个恒定大小的聚合签名，而不是需要每个交易单独的签名或大型零知识有效性证明。

这显著减少了与签名相关的数据可用性开销，同时保持紧凑的区块级验证语义。

参见 BLS。

7. 最小目标编码

Cube 用一个称为 Target 的紧凑重放保护字段取代了传统的基于 nonce 的排序。

Target 机制不是携带单调递增的账户 nonce，每个条目携带一个最小编码的目标，指示条目预期执行的批次高度。目标机制支持当前批次以及一个可扩展到最多五个批次深度的有限回滚窗口。

这可以防止延迟广播重放行为，即恶意引擎试图扣留并在未来状态转换时重新广播先前已签名的条目。条目仅在其预定的执行窗口内有效，使得后来的重放尝试无效。

由于绝大多数条目针对当前批次高度，编码开销在实践中变得极小。单个位足以指示当前高度执行，而额外的回滚深度仅需要两个额外位。

因此，Cube 用通常仅消耗少量位的重放保护机制取代了传统的固定宽度 nonce 字段（在传统系统中通常为 8 字节）。

参见 条目。

参见 Target。

8. 最小操作数字段

Cube 用称为 Ops Price 和 Ops Budget 的紧凑面向操作的执行字段取代了传统的 Gas 核算字段。

与为每个条目重复编码大的固定宽度 Gas 参数不同，Cube 假设协议定义的默认值，并且仅编码与这些默认值的偏差。

Ops Price 字段指示该条目是使用协议基本执行价格还是指定额外的执行溢价。在常见情况下，单个位足以指示使用默认基本价格。如果请求额外溢价，则仅紧凑编码超出基准的过剩差额。

类似地，Ops Budget 字段指示该条目是否指定了自定义执行预算。单个位确定是否存在显式预算。如果存在，额外位仅编码请求的预算金额。

由于大多数条目在默认执行假设下运行，两个字段在实践中通常仅消耗最小位开销，同时在必要时仍然支持可变执行定价和有界执行控制。

参见 Ops Price 和 Ops Budget。

9. 断言

Cube 在断言的执行模型下运行，其中只有有效交易才被允许进入最终确定的批次。

失败的状态转换被排除在最终确定的负载之外，因此永远不会消耗永久的数据可用性空间。相比之下，EVM 和 zkEVM 系统允许失败的交易尽管产生无效或回滚的执行结果，但仍被永久记录在链上。

通过消除永久记录的执行失败尝试，Cube 实现了额外的历史区块空间效率，同时保持更清晰的执行状态模型。

TPS 预估

以下预估使用 Airly 负载编码 (APE) 估算了 Cube 在典型交易模式下的理论交易吞吐量。这些预估主要关注原始数据可用性效率，并将 Cube 与 zkEVM 式 Rollup 和传统 EVM 交易格式进行了比较。

由于 Cube 通过位级编码、紧凑索引、无 nonce 目标、最小操作数字段、紧凑 Calldata 布局和轻量级调用方法编码激进地最小化序列化开销，平均交易负载大小变得比传统智能合约系统小得多。

AMM 交换

AMM 交换 — TPS 预估比较

以平均 AMM 交换为例，Cube 每次交易消耗约 ~10.7 字节（~2.67 vBytes）的区块空间。

相比之下：

• 一个等效的 zkEVM 交易消耗约 33 字节，
• 而一个传统的 EVM 交易消耗约 110 字节。

因此，Cube 预计支持：

• 在比特币上比 zkEVM 等效系统多约 3.1× 的 AMM 交换，
• 比标准 EVM 环境多约 10.5× 的 AMM 交换。

代币转账

代币转账 — TPS 预估比较

以标准代币转账为例，Cube 每次交易消耗约 ~9.7 字节（~2.42 vBytes）的区块空间。

相比之下：

• 一个等效的 zkEVM 交易消耗约 33 字节，
• 而一个传统的 EVM 交易消耗约 126 字节。

因此，Cube 预计支持：

• 在比特币上比 zkEVM 等效系统多约 3.5× 的代币转账，
• 比标准 EVM 环境多约 13.2× 的代币转账。

有疑问？加入 CUBE 电报社区频道

• 原文链接： medium.com/cube-bitcoin/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～