比特币上的 RGB 协议建立在三个
密码学基石之上。
每个原语解决一个特定的问题。三者共同作用，使得在比特币上拥有和转移数字资产成为可能，且没有任何合约数据接触区块链。
客户端验证
每一方只验证属于自己的那部分合约历史。设计上即具备隐私性，可扩展性没有上限。
一次性密封条
每一次状态转换都绑定到一个比特币 UTXO。花费它就会关闭密封条——从而防止双花。
模式系统
声明式的合约模板定义了状态结构和转换规则——无需任何可在链上执行的代码。
顺序很重要：模式定义了合约 是什么，客户端验证确保 只有相关方才能看到数据，而一次性密封条确保 每一次转换都是最终且唯一的。比特币则提供时间戳和防双花保护。
在标准区块链中，每个节点都要存储并重新执行每一个合约。这带来了一个根本性的可扩展性与隐私上限——所有数据公开可见，所有节点都要承担全部计算负载。
RGB 颠覆了这一点。正如 docs.rgb.info 所述， “验证的逻辑可以被颠倒过来”：每个参与者只验证属于自己的那部分合约历史——即连接 Genesis 与其当前归属状态的有向无环图（DAG）。这部分私有的历史切片被称为 分片（shard）。
可扩展性优势立竿见影：由于所有人只需要存储那个微小的密码学承诺（大小仅为几十字节，在 Tapret 方案下甚至不占用额外字节）， 成千上万笔来自不同合约的 RGB 状态转换可以被打包进同一笔比特币交易 ，链上占用可以忽略不计。
定义 — docs.rgb.info
“一次性密封条（Single-Use-Seal）是一种正式承诺：承诺在未来某个时刻提交一条尚未知晓的消息，且只能提交一次，以使承诺的事实对特定受众的所有成员显而易见。”
— docs.rgb.info/distributed-computing-concepts/single-use-seals
一次性密封条由 Peter Todd 于 2016 年提出，是比特币上的 RGB 协议的防双花机制。它分为三个步骤：
Alice 定义密封
Alice 向 Bob 承诺，会在约定的时间点、通过双方商定的发布媒介发布一条特定消息——在 RGB 中，这个媒介就是一个比特币 UTXO。
seal ← Define()
Alice 关闭密封
Alice 通过花费该 UTXO 来发布这条消息（一个 RGB 状态转换承诺）。这会产生一个见证（witness）——证明密封已被关闭的证据。该密封无法被再次关闭。
witness ← Close(seal, message)
Bob 独立验证
Bob 接收到密封、见证和消息，并在本地验证密封是否被正确关闭。整个过程无需信任 Alice——比特币区块链提供了证明。
bool ← Verify(seal, witness, message)
在 RGB 中， 密封定义就是比特币 UTXO。承诺是嵌入在一笔比特币交易中的哈希值。密封的关闭就是花费该 UTXO。一连串相互连接的交易花费构成了发布证明（Proof-of-Publication）——即某次转换确实发生过的不可篡改记录。
这正是 RGB 资产所有权在安全性上与比特币本身完全等同的原因：控制一个 UTXO，就意味着控制通过一次性密封条分配给它的所有 RGB 资产。
以声明式方式定义的合约，
而非可执行代码。
RGB 模式是一个声明式模板，定义了合约的结构。正如 docs.rgb.info 中所述， 一个 模式 相当于面向对象编程中的类 ——它规定了合约是什么，而不是如何在链上执行它。
这在架构上与以太坊截然不同：在以太坊中，合约代码由区块链上的每个节点存储并执行。在 RGB 中，模式定义的验证规则由 AluVM 在客户端验证过程中于本地执行——从不上链。一个模式需要回答以下问题：
存在哪些 Owned State 和 Assignment？
合约拥有哪些 Global state？
Genesis 的结构是怎样的？
可能发生哪些状态转换？
状态数据在转换中可以如何变化？
编译完成后，模式会被编码为一个 .rgb 二进制文件，供钱包软件导入。目前官方支持五种标准模式——NIA、UDA、CFA、IFA、PFA——此外也可以针对任何使用场景构建自定义模式。
从 Genesis 到
当前状态。
正如 docs.rgb.info 中所述， “状态可以被定义为一种独特的信息或数据配置，代表合约在某一特定时间点的状况。” 每一个 RGB 合约都会通过一连串的状态转换，从最初的定义（Genesis）演变到其当前的活跃状态。
来自 docs.rgb.info 的关键洞察： “一条给定的 RGB 转换链，并不一定对应着一条比特币交易链” ——Anchor 交易在链上的顺序，并不能用来推断 DAG 节点的顺序。DAG 的顺序是由各个操作对其输入的承诺来维护的，而这些操作会被锚定到比特币上以获得时间戳。
以
闪电般的速度流转的资产。
上述这些原语不仅仅作用于比特币的基础层——它们还与闪电网络原生集成。RGB 状态转换直接嵌入闪电承诺交易内部，这意味着资产能够以任何闪电支付相同的速度和成本，流经类型化的通道。
与那些通过封装或跨链桥来与闪电网络交互的方案不同，RGB 在协议层面直接运作。每个通道都携带着自己的类型化资产状态——由各方私下验证，并在比特币上结算，除了通道本身之外不引入任何额外的信任假设。
运作方式如同
无记名工具的合约。
正如 docs.rgb.info 中所述，RGB 架构背后的理念有着深厚的历史渊源： “不久之前，证券等合约还是无记名工具。合约的无记名属性，实际上是一项延续了数百年的传统。”
RGB 以数字形式复兴了这一模式。各方的无记名权利作为数据被包含在合约之中——私下持有，可在各方之间直接转让，并通过密码学方式强制执行，无需托管方或登记机构。
资产存放于托管登记系统中
– 银行或经纪商持有所有权记录
– 转让需要中介方批准
– 每一层都存在交易对手风险
– 隐私取决于机构的政策
– 登记机构层面存在审查的可能
权利本身包含在合约之中
– 所有权通过控制该 UTXO 来证明
– 转让直接进行——从发送方到接收方
– 无中介，无托管方
– 设计上即具备隐私性——数据只在相关方之间流动
– 具备比特币级别的抗审查性
顺序很重要：模式定义了合约 是什么，客户端验证确保 只有相关方才能看到数据，而一次性密封条确保 每一次转换都是最终且唯一的。比特币则提供时间戳和防双花保护。
接下来该读
什么。
准备好
在比特币上的 RGB 协议上构建了吗？
这些原语已经讲清楚了——现在开始付诸实践吧。