Liquid 上的 RGB：深入解析 KaleidoSwap 的 Simplicity 概念验证
比特币上的 RGB 协议将资产的完整历史保存在链下：链上只在一笔普通交易中携带一个很小的密码学承诺。Liquid 上的 RGB 把同样的模型应用到 Blockstream 的 Liquid 侧链上，用 Liquid 交易而不是比特币交易来锚定 RGB 资产。KaleidoSwap 测试了这套系统的可移植性，随后借助 Liquid 的智能合约语言 Simplicity，让链本身来强制执行 RGB 的承诺规则。
简要概览
- KaleidoSwap 用一个横跨七个文件、共 207 行的补丁让 Liquid 上的 RGB 得以运行，现有的比特币行为完全不变：原有的 45 项测试全部通过，四个基于 RGB 构建的库也无需任何改动。该补丁已作为 RFC 提交，一位 RGB 维护者已确认其方向。
- 之所以可行，是因为比特币和 Liquid 对 Taproot 输出的定义完全相同（BIP-341）：标准的 RGB Tapret 验证器无需修改，就能读取一笔真实的 Liquid 交易。
- 一个基于 Opret 式承诺的 Simplicity 限制条款，让 Elements 共识拒绝任何不带 RGB 承诺的 RGB 密封条花费。
- 团队在 regtest（回归测试网络）上发行了一个资产，并在比特币和 Liquid 之间完成了一次无需托管方的原子交换。
KaleidoSwap 为什么要在 Liquid 上运行 RGB？
一个 RGB 合约由两层构成。
- 第一层是客户端验证：资产的发行规则和完整的转移历史，由每一位持有者在链下自行检查，不依赖任何特定的区块链。
- 第二层是锚定：一次性密封条将每一次转移绑定到一笔真实的链上交易，因此花费密封条所对应的 UTXO，就完成了转移的结算，也杜绝了双花。
由于每个合约从 Genesis 起就绑定在单一的链上，为比特币发行的资产和为 Liquid 发行的资产是两个独立的合约，而不是同一个资产存在于两个地方。此外，由于密封条就是一个普通的 UTXO，链所支持的花费条件同样适用于资产：在比特币上是比特币脚本（Script），在 Liquid 上则可能是表达能力强得多的方案。
Liquid 自然成为下一条值得尝试的链。它拥有一分钟出块、机密交易，以及已被交易所和交易者使用的联盟锚定机制。自 2025 年 7 月起，它还拥有了 Simplicity：一种可形式化验证的智能合约语言，这是比特币基础层所不具备的。
RGB 与 Liquid 之间的差距有多大？
结果差距很小：RGB 的代码中已经为 Liquid 打下了大部分基础。在梳理代码的过程中，KaleidoSwap 发现了三点：
- RGB 的链枚举（代码所识别的区块链的固定列表）中已经存在一个
Liquid变体； LiquidMainnet和LiquidTestnet已经被列为网络；- 合约的 Genesis 已经记录了合约所属的链。
但这些部分都没有接入真正负责检查交易的代码。
同样，密码学部分也无需重新设计。RGB 将承诺隐藏在一个看起来很普通的 Taproot 输出中，而比特币和 Liquid 依据 BIP-341 对这种输出格式的定义完全相同。KaleidoSwap 确认了这一点：标准的、未经修改的 RGB 验证器认定一笔已确认的真实 Liquid 交易中的某个输出携带了有效的 RGB 承诺。
这个 207 行的补丁改变了什么？
RGB 通过读取锚定某次转移的链上交易来检查这次转移。
原来的代码依赖一种只为比特币设计的交易格式，因此无法读取结构不同的 Liquid 交易（Liquid 交易包含机密金额、每个输出都有显式的资产标识，还有一个显式的手续费输出）。不过，这三处代码其实只需要几项基本信息：交易的输入，用来确认密封条已被花费；以及交易的输出脚本，用来找到承诺。
KaleidoSwap 的补丁让代码不再依赖只适用于比特币的交易格式，而是通过一个小型的通用“适配器”，只获取验证转移所需的信息（输入和输出脚本），任何类型的交易都可以提供这个适配器。对现有的比特币用户来说，一切都没有变化，而 Liquid 交易现在也可以走与比特币相同的验证路径。
改动很小：七个文件，共 207 行。用于检查 RGB 行为是否正确的全部 45 项现有测试，依然全部通过。另外四个基于 RGB 代码构建的库（rgb-ops、rgb-schemas、rgb-invoicing 和 rgb-aluvm）也都能在自身不做任何修改的情况下基于它编译通过，这是该补丁没有破坏其他任何部分的最有力证明。
这个适配器并不专属于 Liquid，任何以 UTXO 形式记录资金的区块链都可以使用它。KaleidoSwap 将其视为迈向跨比特币各层可移植的客户端资产的一步，而不仅仅是针对 Liquid 的修补。
为了演示，团队用 RGB 工具在 Liquid 上发行了一个真实的资产，并在两位持有者之间完成了转移。这次转移包含一个找零输出（退回给发送方的剩余金额），被记录在一笔 Liquid 交易中，并从头到尾通过了验证。该补丁现已作为 RFC（一种正式提案，需经维护者审查后才可能被采纳）提交给 RGB 维护者，编号为 rgb-consensus#12。一位 RGB 维护者回复称方向看起来不错，并给出了实现上的指导：新代码保留在共识库中，Liquid 支持作为一个可选功能，只面向比特币的构建保持不变。KaleidoSwap 同意了所有要点，并将在共识库即将发布的更新推出后更新补丁。
图片来源：Kaleidoswap
如何在没有托管方的情况下，在比特币和 Liquid 之间进行兑换？
资产始终留在其合约 Genesis 所在的链上，因此无法从比特币转到 Liquid 再转回来。可行的替代方案是原子交换：一种要么双方同时完成、要么完全不发生的交易，任何第三方都不会同时持有双方的资产。
为了测试兑换，KaleidoSwap 分别在比特币和 Liquid 上创建了一个真实的 RGB 代币，两者都在 regtest 上。两个代币通过同一个共享秘密，在一次关联的操作中完成交换。当一方揭示秘密来领取自己那一侧的资产时，这个秘密就变成公开的，另一方便可以用它来领取自己的资产。任何一方都无法同时拿走两份资产，也无法作弊。
团队在两条链上都使用了哈希时间锁定合约（Hash Time-Locked Contract，HTLC），让这一机制更安全，也更接近实际使用场景。在 HTLC 中，资金会一直锁定，直到接收方揭示秘密；或者在截止时间之后退回给发送方。在这里，只有领取方的密钥才能使用领取路径，而退款路径只有在截止时间之后才会开放。团队还测试了兑换在异常情况下的表现：HTLC 会拒绝错误的秘密和过早的退款，并接受截止时间之后的退款。
要让 RGB 在 Liquid 上运行，有一个前提必须成立，因为 Liquid 的机密交易会隐藏金额。RGB 将承诺放在 scriptPubKey 中（输出中定义花费条件的部分），而 Elements（Liquid 所基于的软件）从不隐藏这个字段。因此，未经修改的 RGB 验证器无需任何解盲数据就能读取承诺。KaleidoSwap 称之为“Liquid 上的 RGB 的承重假设”，也就是其他一切的基础，而测试证实了它的成立。
其结果是一种“RGB 封装的领取”：单笔交易同时花费 HTLC、携带 RGB 承诺，并将资产重新锚定到领取方自己的输出上。兑换的结算和资产的转移在一个原子步骤中完成，也就是说，要么完全发生，要么完全不发生。
Simplicity 如何让 Liquid 强制执行 RGB 规则？
一个 Simplicity 限制条款（covenant，附加在一枚币上、限制其花费方式的规则）会让 Liquid 节点拒绝任何不带 RGB 承诺的 RGB 密封条花费。
Liquid 本身已经支持限制条款：锁定一枚币的规则可以检查试图花费它的交易。Liquid 的 Taproot 升级新增了三十多个内省操作码，Blockstream 的期权合约已经在生产环境中使用它们。
Simplicity 更进一步：它可以表达包含多个条件的复杂合约和任意有限计算，不受比特币脚本（Script）在大小和操作码上的限制，而且程序的行为可以用数学方法证明。借助 SimplicityHL（一种类似 Rust、最终编译为 Simplicity 的语言），开发者可以把一个 Simplicity 程序附加到某个输出上，作为普通花费方式之外的另一种花费方式。
由于 RGB 密封条只是一个普通的 UTXO，Simplicity 程序可以限制密封条的花费，而完全不需要理解承载在其上的 RGB 合约。KaleidoSwap 用 SimplicityHL 编写了一个限制条款，让一个 RGB 密封条同时满足两个条件才能被花费：花费者必须揭示某个给定哈希背后的秘密，而且花费交易必须在第 0 个输出处带有一个形状与 RGB 承诺完全一致的输出（一个 OP_RETURN 加上一段 32 字节的数据）。
该限制条款针对的是 Opret 而不是 Tapret，因为 Tapret 承诺隐藏在输出的密钥中，使用的是一个限制条款无法预先知道的值；而 Opret 承诺位于一个普通的数据字段中，其形状很容易验证。
在关键测试中，团队构造了一笔满足该程序的交易，然后移除承诺输出并重新广播。Elements 共识拒绝了这笔交易。“花费 RGB 密封条必须携带 RGB 承诺”这一规则由此在共识层面得到强制执行，而不是留给钱包软件事后检查。转移本身是否有效，仍然在客户端检查。目前这一切只在 regtest 上运行。
图片来源：Kaleidoswap。原文发布后，有抵押支持的铸造也已有了 regtest 原型。
可编程密封条能带来什么？
将 Simplicity 限制条款与 RGB 密封条结合，带来的可能性远远超出兑换本身。在下面这些设想中，第一项已经得到演示，有抵押支持的铸造在代码库中已有 regtest 原型，其余仍然是提案：
- 由链强制执行的兑换：已经演示，如上文所述。
- 以 RGB 资产为抵押的借贷：Blockstream 已经在 Simplicity 上构建一个以比特币为抵押的借贷应用。同样的结构可以把 RGB 资产的密封条锁定在一个借贷限制条款之下：借款人还款后资产回到借款人手中，违约时资产归出借人所有，整个过程既不需要清算人，也没有任何托管方持有抵押品。
- 可验证的有抵押美元发行：Liquid 上已经原生发行了 Tether 的 USD₮，因此发行一种新的 RGB 美元资产时，可以要求在同一笔交易中把原生 USD₮ 锁定到一个限制条款保险库中，让抵押情况在链上公开可审计。代码库中已经包含一个有抵押铸造限制条款的 regtest 原型，允许任何人在锁定保险库资产的前提下无需许可地进行铸造。KaleidoSwap 坦承，赎回仍然是一个悬而未决的问题：链本身无法验证 RGB 状态，因此退出仍然需要由运营方验证后放行，或者与做市方的流动性进行一次原子交换。
- RGB 资产的保险库托管：一个递归限制条款（会把自身应用到下一个输出上的限制条款）可以迫使每一次花费都经过一个延迟的中转步骤，这个步骤可以用恢复密钥取消。如果有人盗取了密钥，真正的所有者有时间介入并阻止盗窃。
- 受保护的做市方库存：交易平台的热钱包可以把自己的密封条置于一个只允许兑换形式花费的限制条款之下，这样仅凭一把被盗的热钱包密钥，也无法把库存转移到攻击者的地址。这一设想与像 KaleidoSwap 自身做市模式这样的 RFQ（询价）平台直接相关，在这类平台上，做市方按请求报价。
- 兼顾隐私的可编程性：普通的 Liquid 限制条款如果需要检查金额，通常要求对该金额进行解盲（公开），从而迫使人们在可编程性和机密性之间做出取舍。RGB 绕开了这种取舍，因为资产金额从不上链：限制条款只约束一个普通的 Liquid 输出，而真正的资产账本仍然保留在链下，保持私密。
这一结果在两层之间划出了一条清晰的界线。在 RGB 中，私有合约的逻辑运行在 RGB 虚拟机 AluVM 上，并在客户端完成验证。在这次集成中，Simplicity 运作在界线的另一侧：位于 RGB 之下，在链上守护密封条，而 AluVM 继续在链下管理私有合约的逻辑。
Liquid 上的 RGB 正式上线之前还需要什么？
KaleidoSwap 的浏览器扩展已经支持 Liquid，也分别支持比特币主网上的 RGB，目前处于封闭测试阶段。把两者结合起来的 Liquid 上的 RGB，是 KaleidoSwap 下一步集成的一个选项。不过就目前而言，本文描述的一切都只是一个工程概念验证，只在比特币和 Liquid 的 regtest 上测试过，尚未投入生产环境。
要让它可以用于钱包，还需要完成一些常规的工程工作：
- 这个 207 行的补丁需要按照维护者的指导和即将到来的共识更新进行更新，然后合并；要在 Liquid 上实现完整验证，还需要第二步：让负责查找交易的代码也能处理 Liquid 交易。
- 钱包需要一种在验证过程中获取 Liquid 交易的方式。
- RGB 钱包库需要为已经面向比特币提供的发行、发送和接收功能，开发一个 Liquid 版本。
- 兑换需要一个协调方，负责处理超时、退款以及寄售包（承载资产历史的数据包）的交换。
- 限制条款还需要两项补充才能投入生产：领取方的签名和一条退款路径。
