客户端验证协议(Client-side Validation Protocol)
客户端验证协议 (opens in a new tab),是 Bitcoin 生态的开发者提出的概念,它允许比特币交易提交一些数据,这些数据的有效性是独立于比特币共识规则之外确定的。这种协议下产生的资产,只利用 Bitcoin 来保证资产的所有权以及避免双花,而资产的有效性在链下验证。后文中我们把客户端验证简称为“CSV”。
而在 Bitcoin 提交数据的方式不同的协议有不同的方案。比如 RGB (opens in a new tab) 只给链上提交承诺,Taproot assets (opens in a new tab) 会提交状态树的根,而 Ordinals (opens in a new tab) 协议则直接提交数据,相当于把 Bitcoin 同时作为数据可用层。
我们认为 Ordinals 这样的依赖链下索引器的协议,也属于 CSV 协议的范畴。链下索引器其实相当于一种胖客户端。而未来 RGB 协议发展起来,也会有类似的方案来代用户验证资产,降低用户的使用成本。
为什么需要 CSV
- Bitcoin 上的扩展性受限,如果要在 Bitcoin 上定义资产协议,唯一的途径是通过 CSV 模式。
- CSV 是一种新的扩展模式,它可以让资产的验证在不同的层次上进行。
- CSV 是数据资产化的正确途径,可以保证数据的所有权在产生之初就属于用户。
CSV 资产协议的分层
CSV 资产协议,就是通过 CSV 方式定义的资产协议,可以抽象为以下几个层:
资产仓库层(Asset Repository Layer)
我们把给资产提供存储的平台统一抽象为"资产仓库",它可以是一条链,比如 Bitcoin,或者非链的基础设施,但有个要求是资产仓库层需要保证可验证性,让资产验证器可以验证和追踪资产。
Bitcoin 既是资产类型的定义平台,也是一个资产仓库。不同的资产仓库提供的安全性和功能不一样,用户将资产在不同的仓库间迁移,在应用场景和和安全性之间寻求平衡。
资产容器层(Asset Container Layer)
资产容器是资产的载体,它用来表达资产的所有权,但它不关心资产的有效性。比如 Inscription 就是一种典型的资产容器。由于 CSV 类的资产是用户直接生成的,有可能生成无效的资产,所以需要有一种容器先来承载资产,表达所有权。
资产验证器层(Asset Validator Layer)
资产验证器是协议的逻辑实现,它可以运行在终端用户的钱包,也可以运行在链下的索引器。如果资产验证器可以对外公开访问,我们可以称之为“公共资产验证器”。
Rooch 会提供一种资产验证器的扩展机制,开发者可以通过 Move 合约来自定义 Bitcoin 上的资产协议,以适配自己的应用场景。
资产协议层(Asset Protocol Layer)
资产协议层提供了资产的命名空间,以及定义基础的资产格式以及验证规则。
资产层(Asset Layer)
资产层是具体的资产,它是资产协议的实例化。每种资产会有一个唯一的标识,该标志在资产协议内是唯一的。
下图以 Ordinals 协议为例,展示了 CSV 资产协议的分层:
Bitcoin 提供了存储功能,以及 UTXO 的所有权,是资产仓库层。
Ordinals 协议定义了 ID,以及追踪资产的所有权,留了 Metadata 以及 Content 用于扩展。我们把它称为资产容器层。
而上层的协议,BRC20/BRC1024 等,通过在 Content 中写 JSON 或者扩展 Metadata 的方式,定义资产协议,可以称为资产协议层。
再上面就是基于协议发行的具体的资产,不同的资产有不同的验证规则,可以叫做资产层。而这些规则当前是通过资产协议在部署参数中提供的机制实现的,硬编码在索引器中,现在需要一种更灵活的扩展方式,并且直接融合到应用中去,这是当前 Bitcoin 的智能合约层需要解决的问题。
这种资产协议的优势是,资产有效性校验逻辑是从底层往上一层一层增加规则,符合下层数据格式的规则不一定符合上层规则。这样就实现了扩展性,底层协议不用关心上层协议数据的有效性。
数据,资源与资产
从数据资产化的角度来看,数据、资源和资产是三个不同的概念。
- “数据”在计算机系统中就是一组二进制,它是程序操作的对象,可以有任意副本,不存在稀缺性。
- “资源”则已经蕴含了稀缺性的概念,不能随意复制,一般通过给它赋予唯一的 ID 来表达。
- “资产”则蕴含了所有权以及可交换或者获取收益的含义,被市场共识,并绑定了权益。
所以数据和资产在格式上并没有本质的区别。数据上链的途径应该是用户先自己将数据提交到链上,保存到资产容器中,取得所有权,然后再通过资产验证器验证数据符合资产协议的规则,实现数据的资产化。
资产跃迁协议(Asset Leap Protocol)
跃迁(Leap):资产迁移的过程,我们称之为“跃迁”,用户将资产从一个资产仓库跃迁到另一个资产仓库。跃迁的过程是一个销毁和重新铸造的过程。注:Leap 这个词最初来源于 RGB++ 协议,我们认为这个词很贴切,所以沿用了这个词。
当前区块链的资产跨链协议,都是基于一边锁定,一边映射的模式,而这种模式并不能降低链的状态存储的压力,也无法支持资产先在链下发行,从而很难支持大规模数据的资产化。而 CSV 资产可以真正实现资产在不同资产仓库之间的迁移,只要保证资产验证器可以验证两边的资产,就可以实现资产的迁移。
而这种资产迁移模式比当前的桥模式有几个优点:
- 不会聚集大量的资产在桥中,避免了集中性风险,资产迁移模式的风险是分散的。资产迁出,以及迁入,都是用户触发的,客户端追踪的是所有权,只要验证迁出的时候的销毁操作和迁入的时候的重新发行操作是匹配的,资产就是安全的。
- 资产可以像“现金”一样在各种网络之间迁移。将资产的存储和资产的应用场景分开,既能解决状态爆炸问题,也能解决新型资产的大规模发行问题。
- 这种模式要求钱包扮演重要的角色,而不仅仅是当前这种只信任 RPC 的“笨”钱包,需要更“智能”一些。
关于资产迁移协议的具体方案,不同的 CSV 资产协议会有不同的实现。我们以 Inscription 为例,说明资产如何实现从 Bitcoin 到 Rooch 的迁移,以及迁移回 Bitcoin 的过程。这里 Bitcoin 是资产仓库,而 Rooch 既是资产仓库,也是资产验证器。
- Alice 在 Bitcoin 上铸造了一个 Inscription A。
- 这个交易会在 Rooch bitcoin 模块内再次执行,会生成一个影子资产 A'。
- Rooch 内的资产验证器会验证 A' 的有效性,并在其内部打上有效性标记。
- 此时,资产 A 完成了铸造和验证。应用可以通过 Rooch 查询资产 A 的状态:所有权以及有效性。但此时,资产 A 的资产仓库依然是 Bitcoin,它可以在 Rooch 上被使用,但不能直接交易。
- 如果 Alice 想要将资产 A 迁移到 Rooch 上,则需要在 Bitcoin 上发起交易,销毁资产 A,并标记
leap_to rooch
。 - Rooch bitcoin 模块执行该交易后,也会销毁影子资产 A',并在 Rooch 内重新自动铸造一个新的资产 A。
- 此时,资产 A 的资产仓库已经变成了 Rooch,它可以在 Rooch 上被使用,也可以直接交易。
- 如果 Alice 想要将资产 A 迁回 Bitcoin 上,则需要在 Rooch 上发起交易,调用合约
leap_to bitcoin
,该合约会销毁资产 A。然后再在 Bitcoin 上重新铸造一个资产 A,标记为leap_from rooch
。 - Rooch bitcoin 模块执行该交易后,资产验证器会通过前面的销毁状态验证,生成一个影子资产 A',并标记有效性。这样,资产 A 的资产仓库又变成了 Bitcoin。
注意:
- 这个流程是一个简化的流程,没有考虑用户交易未能上链,需要恢复资产的情况。
- 资产跃迁时,资产容器会被销毁,所以不能保证容器的 ID 一致,所以资产内部需要有业务 ID 来标识资产。
Reference
- Client-side validation protocols (opens in a new tab) from bitcoinops.org
- Client side validation (opens in a new tab) from rgb.info
- Ordinals (opens in a new tab) from ordinals.com
- Taproot assets (opens in a new tab) from lightning.engineering