RGB++ Protocol Light Paper

Special thanks to Ajian, cyberorange, Jan, Shawn, and DaPangDun for feedback and discussion.

简介

RGB++ 是一个基于 RGB 的扩展协议,利用一次性密封条和客户端验证技术来管理状态变更和交易验证。它通过同构绑定将比特币 UTXO 映射到 Nervos CKB 的 Cell 上,并利用 CKB 链和 Bitcoin 链上的脚本约束来验证状态计算的正确性和变更所有权的有效性。RGB++ 解决了原 RGB 协议在实际落地中的技术问题,并提供了更多的可能性,如区块链增强的客户端验证、交易折叠、共享状态与无主合约、非交互式转账等。它比特币带来了无须跨链、不损失安全性的图灵完备合约扩展和性能扩展。

一次性密封

一次性密密封的概念最早由 Peter Todd 在 2016 年提出,它允许你对一条消息锁上一个电子密封条,确保这条消息只能被使用一次。具体来说,我们可以使用比特币的未花费的交易输出(UTXO)作为消息的密封条,比特币系统的共识机制可以确保这些 UTXO 仅能被消费一次,也即这些密封条仅能被打开一次。

RGB 协议利用这种基于比特币 UTXO 的一次性密封条,将 RGB 状态变更与比特币 UTXO 的所有权对应。因此比特币系统确保了 RGB 的状态所有权,以及可以通过 UTXO 历史来追溯所有的状态变更。一次性密封为 RGB 协议提供了由 Bitcoin 共识保障的防双花安全和交易分支追溯功能。

客户端验证

RGB 协议包含的用户状态无法由比特币共识直接验证,用户必须通过链外计算确保 RGB 的状态变更符合预期。客户端验证技术允许用户只需要验证与自己有关的 UTXO 分支历史,而无需关心与自己无关的交易历史。RGB 的状态安全性通过客户端验证方式保障,不依赖任何中心化第三方。

RGB 协议的问题

尽管 RGB 协议有非常多的优势,尤其它可以为 Bitcoin 提供几乎不妥协的合约扩展,但在实际应用中依然存在多个技术和产品问题。

DA 问题

普通用户如何生成或获取交易历史的证明。普通用户使用简单的客户端产品时,并没有能力或资源保存所有的历史交易,也因此难以向交易对手方提供交易证明。

P2P 网络问题

RGB 交易作为 Bitcoin 的扩展交易,需要依赖一个 P2P 网络进行传播。用户之间在进行转账交易时,也需要进行交互式操作,接收方需要提供收条。这些都依赖一个独立于 Bitcoin 网络的 P2P 网络。

虚拟机与合约语言

RGB 协议的虚拟机目前主要是采用了 AluVM,作为新的虚拟机,目前缺乏完善的开发工具和实践代码。

无主合约问题

RGB 协议目前尚无完善的无主合约(公共合约)的交互方案。这导致多方交互难以实现。

RGB++ 同构绑定

RGB++ 通过同构绑定技术解决了 RGB 协议遇到的问题,并赋予了 RGB 更多的可能性。在 RGB 协议中,最重要的两个组件是用来做所有权认定的 UTXO 和用来做状态管理与一次性密封的 commitment。RGB++ 的同构绑定将其中的 Bitcoin UTXO 一一映射到 CKB 的 Cell 上、使用 bitcoin utxo lock 来实现所有权同步,并使用 cell 的 data 和 type 来实现状态的维护。

区块链增强客户端验证

所有的 RGB++ 交易都会在 BTC 和 CKB 链上同步各出现一笔交易。前者与 RGB 协议的交易兼容,后者则取代了客户端验证的流程,用户只需要检查 CKB 上的相关交易即可验证这笔 RGB++ 交易的状态计算是否正确。但用户也可以不使用 CKB 链上的交易作为验证依据,利用 UTXO 的局部历史交易信息,用户可以脱离 CKB 链独立地对 RGB++ 交易进行验证(交易折叠等部分功能仍然需要依赖 CKB 的块头哈希做防双花验证)。

RGB++ 交易流程

链外计算

  • 选中下一次要使用的一次性密封条,例如 btc_utxo#2

  • 链外计算并生成一笔将要发送到 CKB 上的 RGB++ 交易: CKB_TX_B

  • 链外计算 commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)

BTC 交易提交

  • 生成并发送一笔比特币交易 Bitcoin_TX_A, 输入消耗 btc_utxo#1,输出通过 OP_RETURN 加入上面的 commitment

CKB 交易提交

  • 发送上述 CKB 交易 CKB_TX_B

  • 用户的最新状态由 CKB_TX_B.output.data 维护

  • 下一次变更状态需要使用 btc_utxo#2CKB_TX_B.output

链上验证

  • Bitcoin 验证相关的 utxo 只能被指定用户花费一次

  • CKB 上存在 Bitcoin 的轻客户端,它可以验证 Bitcoin 上的相关交易存在 Bitcoin 链上

  • Bitcoin 的相关交易作为 ckb 交易的 witness 被提交上来,协助验证

  • CKB 进一步验证该 btc 交易花费了正确的 utxo

  • CKB 进一步验证该 btc 交易承诺了正确的 commitment

  • CKB 验证 CKB 上的状态转移符合预订的合约规则

RGB++ 客户端

不同于 RGB 协议,RGB++ 的所有交易都在 CKB 上并由 CKB 脚本约束验证,因此 RGB++ 无须独立客户端,用户只需要访问 Bitcoin 和 CKB 轻客户端即可验证所有交易。其中 CKB 轻客户端同样使用 PoW 算法可以实现最近的若干个块头即可验证所有历史交易和状态,进而利用同构绑定验证 RGB++ 的所有交易。

交易折叠

RGB++ 协议将 Bitcoin UTXO 与 CKB Cell 进行同构绑定,实现了 CKB Cell 验证支持的图灵完备 Bitcoin UTXO 交易。如果我们进一步利用 CKB Cell 的可编程能力,那么我们可以将多笔 CKB 交易与一笔 Bitcoin RGB++ 交易对应,这样就可以将低速低吞吐量的 Bitcoin 链使用高性能的 CKB 链进行扩容。

共享状态与无主合约

共享状态的平庸实现

共享状态一直是 UTXO 系统的难题,这里先讨论一种不考虑多人同时更新共享状态的平庸实现,再进一步讨论实际会采用的允许多人同时操作共享状态的解决方案。

考虑 CKB 上存在一个全局状态的 Cell,用来管理多用户共享的状态。典型地,它可以是一个算法稳定币的质押合约,用户将波动资产存入,并获得一个存款证明。全局状态由无主合约管理,所谓无主合约指的是任何人在满足合约的约束前提下都可以对状态进行变更,而不要求指定的数字签名提供方进行变更。无主合约的实现对协议的去中心化和抗审查有决定性的作用。

这里的平庸实现指的是 Global-state cell 有被其他用户占用的风险,这样 CKB TX 就会因为指定的 Global state utxo 不存在而无法成立。而 Bitcoin TX 需要先于 CKB TX 发送出来、并将其计算到 commitment 中,因此也无法进行后续的验证。

共享状态的状态争抢问题与解决方案

为了解决上述问题,我们引入了 Intent Cell 作为中介。用户将自己希望执行的动作确定性地写入 Intent Cell,后者则可以通过第三方聚合器的协作与全局状态 Cell 交互,批量将多方的 intent 进行计算,并将交互结果合并到标准的 shadow cell 上。

非交互式转账

原始 RGB 协议的一个问题是收款方需要提供一个自己的 live utxo 作为 invoice 才能实施转账,这种方式要求收款方必须在线才能完成一笔普通的交易,增加了用户理解难度和产品复杂度。RGB++ 可以利用图灵完备环境的优势,将交互行为放置在 ckb 环境里面,采用发送-领取两步操作来实现非交互式转账逻辑。

发送

用户 A 向用户 B 发送资产时,只需要获知 B 的地址,并在 RGB++ 交易中向该地址转账,而不需要收款人提供 utxo 或 invoice。

领取

CKB 的 lock 合约有能力验证 btc 地址对应的数字签名,因此接收方可以在 CKB 上构造 Tx C 来解锁对应的 CKB Cell,并将资产转移到自己的 utxo#2 上。从而完成了非交互式收款。

Coins

RGB++ 上的 fungible 资产发行需要对应的数据结构标准和一致性验证标准。我们可以使用 ckb 的 xudt 标准作为它的同构绑定协议。

发行

RGB++ coins 的发行有很多种方式,包括并不限于中心化分发、空投、认购等方式。代币的总量也可以选择不设上限和预设上限两种。对于预设上限的代币,可以使用状态共享方案在每次发行时验证已发行总量小于等于预设上限。

转移

RGB++ coins 的转移非常简单,只需要将收款方和找零 utxo 分别对应到 ckb 的 shadow cell 即可。coins 的转移也可以通过交易折叠的方式只发生在 CKB 上,多笔交易后再将最后结果 commit 到 BTC 上。

隐私

xudt 是一个透明的代币协议,我们也可以采用支持金额隐私和流向隐私的代币协议来强化 RGB++ coins 的隐私保护特性。例如,我们可以使用 bulletproof 算法,将 data 中的内容变成盲化金额,并在每次转让的交易中提供金额一致且非负的零知识证明。这样,只有交易当事人知道当前交易的具体金额信息,第三方观察者无法获知金额数据。

此外,我们还可以使用环签名实现转账流向的盲化。用户的 coin 在 CKB 上转账给环签名混淆器,然后再回流到由 bitcoin utxo 管理的地址上。通过这种方式切断资金流的历史轨迹,从而完成地址的隐私保护。

NFTs

发行

RGB++ 的 NFT 资产发行也可以利用到 ckb 上现有的 NFT 协议,包括不限于 Spore、mNFT 和 CoTA 协议。以 Spore 为例,它将所有的元数据均保留的链上,实现了数据可用性的 100% 安全。而 CoTA 协议则是利用状态压缩技术,将 NFT 信息和持有数据压缩在 32 字节的的 SMT 中,提供了极致的成本优势。

转移

RGB++ 中 NFT 的转让也非常简单,类似无须找零的 coins 转账。

闪电网络联通

RGB 作为客户端验证协议天然支持状态通道和闪电网络,但受限于 Bitcoin 的脚本计算能力,在 Bitcoin 上实现非 btc 的闪电网络非常困难。通过 RGB++ 协议的包裹,我们可以基于 CKB 的图灵完备脚本系统实现 RGB++ 资产的状态通道以及闪电网络。这项技术有着巨大的商业前景,例如基于闪电网络的稳定币支付系统可以提供低于中心化系统的成本和性能优势,同时保障了去中心化和抗审查特性。

应用举例

Airdrop

给定一个地址列表和金额列表,我们可以使用 RGB++ 实现完整的 airdrop 应用。我们假设待领空投数据和已领地址列表均以 SMT 的信息保存在 cell data 中。用户即可通过自己的地址领取空投。

DEX & AMM

RGB++ 利用 UTXO 结构可以直接支持基于 UTXO 的资产交换协议,无须引入中介方。同时利用网格订单簿设计可以实现自动化做市商模式,有别于 Uniswap 的价格曲线做市商模式,网格做市商模式可定制化更强,更适合 UTXO 结构的资产交易。

上面的例子是卖家挂单 RGB++ xudt,买家使用 Bitcoin 购买。交易结构为买家提供包含了足够数量 Bitcoin 的 buyer’s utxo 并提供 PBST 签名,买家则构造 CKB 上的交易来符合卖家的要求,最终买家将构造好的 CKB 交易发送给卖家,卖家将 BTC 交易和 CKB 交易先后上链完成交易。

总结

RGB++ 继承了 RGB 协议的核心思想,采用了不同的虚拟机和验证方案,用户无须独立的 RGB++ 客户端,只需要访问 Bitcoin 和 CKB 轻节点即可独立完成所有的验证。RGB++ 为 Bitcoin 带来了图灵完备合约扩展和数十倍的性能扩展。它没有使用任何跨链桥,而是使用了原生的客户端验证方案,确保了安全性和抗审查性。

27 Likes

不明觉厉:+1::+1:,期待CKB生态越来越强大!!

3 Likes

English translation, hope it’s accurate, let me know if anything needs fixing.

Introduction

RGB++ is an extended RGB-based protocol that utilizes one-time seals and client-side validation techniques to manage state changes and transaction validation. It maps the Bitcoin UTXO to the Cell of the Nervos CKB via isomorphic bindings, and utilizes scripting constraints on the CKB chain and the Bitcoin chain to validate the correctness of the state computation and the validity of the change ownership.

RGB++ solves the technical problems that the original RGB protocol had in practice, and provides more possibilities, such as blockchain-enhanced client-side validation, transaction folding, shared state and masterless contracts, non-interactive transfers, and more. It brings Turing-complete contract scaling and performance scaling to Bitcoin without the need to cross-chain and without loss of security.

One-Time Seals

The concept of one-time hermetic seals, first introduced by Peter Todd in 2016, allows you to lock an electronic seal on a message, ensuring that the message can only be used once. Specifically, we can use Bitcoin’s Unspent Transaction Outputs (UTXOs) as seals for messages, and the Bitcoin system’s consensus mechanism ensures that these UTXOs can only be consumed once, meaning that these seals can only be opened once.

The RGB protocol utilizes this one-time seal based on Bitcoin UTXOs to map RGB state changes to ownership of Bitcoin UTXOs. The Bitcoin system thus ensures ownership of the state of RGB, as well as the ability to trace all state changes through the UTXO history. The one-time seal provides the RGB protocol with double-spend-proof security and transaction branch traceability guaranteed by the Bitcoin consensus.

Client-side Authentication

The RGB protocol contains user state that cannot be verified directly by the Bitcoin consensus, and users must use off-chain calculations to ensure that RGB’s state changes are as expected. Client-side validation technology allows users to validate only the UTXO branching history that is relevant to them and not the transaction history that is not relevant to them. RGB’s state security is ensured through client-side validation and does not rely on any centralized third party.

Problems with the RGB Protocol

Despite the many advantages of the RGB protocol, especially its ability to provide Bitcoin with virtually uncompromising contract extensions, there are still several technical and product issues in practice.

DA Issues

How the average user can generate or obtain proof of transaction history. The average user with a simple client-side product does not have the ability or resources to save all historical transactions, and therefore has difficulty providing proof of transactions to counterparties.

P2P Network Issues

RGB transactions, as an extension of Bitcoin, rely on a P2P network for propagation. Users also need to interact with each other when transferring money, and recipients need to provide receipts. These rely on a P2P network that is independent of the Bitcoin network.

Virtual Machines and Contract Languages

The virtual machine for the RGB protocol is currently dominated by AluVM, which, as a new virtual machine, currently lacks well-developed development tools and practice code.

Problems of Masterless Contracts

The RGB protocol does not have a perfect solution for the interaction of no master contract (public contract). This makes multi-party interactions difficult to realize.

RGB++ isomorphic bindings

RGB++ solves the problems encountered by RGB protocol and gives more possibilities to RGB through isomorphic binding technology. In the RGB protocol, the two most important components are the UTXO for ownership determination and the commitment for state management and one-time sealing, RGB++'s isomorphic binding maps the Bitcoin UTXOs to the cell of the CKB, uses the bitcoin utxo lock for ownership synchronization, and uses the cell’s data and type for state maintenance.

Blockchain Enhanced Client-side Authentication

All RGB++ transactions are synchronized with one transaction each on the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter replaces the client-side validation process, so that the user only needs to check the relevant transaction on the CKB to verify that the state of the RGB++ transaction is calculated correctly.

However, users can also not use the transactions on the CKB chain as the basis for verification, and by utilizing the local historical transaction information of UTXO, users can independently verify the RGB++ transaction from the CKB chain (some functions such as transaction folding still need to rely on the block header hash of CKB to do the anti-double spend verification).

RGB++ Transaction Process

Out-of-chain calculations

Select the next one-time seal to be used, e.g. btc_utxo#2

Calculate off-chain and generate an RGB++ transaction to be sent to CKB: CKB_TX_B

Calculate off-chain commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)

BTC Transaction Submission

Generate and send a Bitcoin transaction Bitcoin_TX_A, input consumed btc_utxo#1, output added to above commitment via OP_RETURN

CKB Transaction Submission

Send the above CKB transaction CKB_TX_B

User’s latest state is maintained by CKB_TX_B.output.data

The next change of status requires the use of btc_utxo#2, CKB_TX_B.output.

On-chain validation

Bitcoin validation related utxo can only be spent once by a given user.

There is a light client for Bitcoin on CKB, which can verify that the relevant transactions on Bitcoin exist on the Bitcoin chain.

The relevant transaction on Bitcoin is submitted as a witness to the CKB transaction to assist in the verification

CKB further verifies that the correct utxo was spent on the BTC transaction.

CKB further verifies that the BTC transaction is committed with the correct commitment

CKB verifies that the state transfer on the CKB conforms to the predefined contract rules.

RGB++ Client

Unlike the RGB protocol, all transactions in RGB++ are on CKB and are validated by CKB script constraints, so there is no need for a standalone client for RGB++. Users only need to access Bitcoin and the CKB light client to validate all transactions. The CKB light client also uses the PoW algorithm to validate all historical transactions and state from the nearest block header, which in turn validates all transactions in RGB++ using isomorphic bindings.

Transaction Folding

The RGB++ protocol isomorphically binds the Bitcoin UTXO to the CKB Cell, enabling Turing-complete Bitcoin UTXO transactions supported by CKB Cell validation. If we further utilize the programmability of the CKB Cell, then we can map multiple CKB transactions to a single Bitcoin RGB++ transaction, which allows a low-speed, low-throughput Bitcoin chain to be scaled with a high-performance CKB chain.

rgb3

Shared States and Masterless Contracts

A mediocre implementation of shared state.

Shared state has always been a challenge for UTXO systems, so here we discuss a mediocre implementation that does not take into account multiple people updating the shared state at the same time, and then move on to a solution that allows multiple people to manipulate the shared state at the same time, as would be the case in practice.

Consider the existence of a global state cell on the CKB that manages the state shared by multiple users. Typically, it could be a pledge contract for an algorithmic stablecoin, where users deposit volatile assets and receive a certificate of deposit. The global state is managed by a masterless contract, by which we mean that anyone can make changes to the state, subject to the constraints of the contract, without requiring the designated digital signature provider to do so. The implementation of a masterless contract is decisive for the decentralization and censorship resistance of the protocol.

A mediocre implementation in this context means that there is a risk that the Global-state cell is occupied by another user, so that CKB TX will not hold because the specified Global state utxo does not exist. The Bitcoin TX needs to be sent out and computed into the commitment before the CKB TX, and thus no subsequent validation is possible.

State Contention in Shared State and Solution

To solve the above problem, we introduce the Intent Cell as an intermediary. Users write deterministically the actions they wish to perform to the Intent Cell, which can interact with the global state cell through the collaboration of a third-party aggregator, batch-computing multiple parties’ intent and merging the results of the interaction into a standard shadow cell.

Non-Interactive Transfers

One of the problems with the original RGB protocol is that the payee needs to provide a live utxo as an invoice in order to perform the transfer, which requires the payee to be online in order to complete an ordinary transaction, increasing the difficulty of user understanding and product complexity. RGB++ can take advantage of the Turing-complete environment by placing the interaction behavior in a CKB environment, and adopting a two-step operation of send-receive to implement non-interactive transfer. Receive two-step operation to realize the non-interactive transfer logic.

Send

When user A sends an asset to user B, it only needs to know B’s address and transfer money to that address in the RGB++ transaction, without requiring the recipient to provide a utxo or invoice.

rgb4

Recieve

The CKB lock contract has the ability to verify the digital signature of the BTC address, so the receiver can construct a Tx C on the CKB to unlock the corresponding CKB Cell and transfer the assets to their utxo#2. This completes the non-interactive collection.

Coins

The issuance of fungible assets on RGB++ requires corresponding data structure standards and consistency verification standards. We can use CKB’s xudt standard as its isomorphic binding protocol.

Issuance

RGB++ coins can be issued in a variety of ways, including but not limited to centralized distribution, airdrops, and subscriptions. The total number of tokens can be either uncapped or pre-capped. For tokens with a preset cap, a state sharing scheme can be used to verify that the total amount of issued tokens is less than or equal to the preset cap at each issuance.

Transfers

The transfer of RGB++ coins is very simple, you only need to assign the payee and the change utxo to the shadow cell of CKB, and the transfer of coins can also be done by collapsing the transactions to CKB only, and then committing the final result to BTC after multiple transactions.

Privacy

xudt is a transparent token protocol, and we can also enhance the privacy-preserving properties of RGB++ coins by employing token protocols that support amount privacy and flow privacy. For example, we can use the bulletproof algorithm to turn the contents of the data into a blinded amount and provide a zero-knowledge proof that the amount is the same and non-negative in each transfer transaction. In this way, only the parties to the transaction know the specific amount information of the current transaction, and a third-party observer cannot obtain the amount data.

In addition, we can use ring signatures to realize the blinding of the transfer flow. The user’s coin is transferred to the ring signature obfuscator on the CKB, and then back to an address managed by bitcoin utxo. In this way, the history of the money flow is cut off, thus accomplishing address privacy.

NFTs

Distribution

RGB++'s NFT asset distribution can also utilize existing NFT protocols on CKB, including but not limited to Spore, mNFT, and CoTA. Spore, for example, keeps all metadata on-chain and achieves 100% security of data availability. The CoTA protocol, on the other hand, utilizes state compression to compress NFT information and holding data in a 32-byte SMT, providing the ultimate cost advantage.

Transfers

The transfer of NFTs in RGB++ is also very simple, similar to a coins transfer with no change.

Lightning Network Connectivity

RGB, as a client-side authentication protocol, naturally supports stateful channels and lightning networks, but it is very difficult to implement non-btc lightning networks on Bitcoin due to its scripting capabilities. By wrapping the RGB++ protocol, we can implement state channels and lightning networks for RGB++ assets based on CKB’s Turing-complete scripting system. This technology has great commercial promise, e.g., a stablecoin payment system based on the Lightning Network can provide cost and performance advantages over centralized systems, while guaranteeing decentralization and censorship resistance.

Application Examples

Airdrop

Given a list of addresses and a list of amounts, we can implement a complete airdrop application using RGB++. Let’s assume that both the pending airdrop data and the list of claimed addresses are stored in cell data as SMT. Users can then collect airdrops from their own addresses.

DEX & AMM

RGB++ utilizes the UTXO structure to directly support UTXO-based asset exchange protocols without the need to introduce intermediaries. The grid order book design also enables an automated market maker model, which is more customizable and suitable for trading UTXO structured assets than Uniswap’s price curve market maker model.

The example above is a seller placing an order for RGB++ xudt and a buyer buying it with Bitcoin. The structure of the transaction is that the buyer provides the buyer’s utxo with sufficient amount of Bitcoin and PBST signature, and the buyer constructs the transaction on the CKB to meet the seller’s requirements, and finally the buyer sends the constructed CKB transaction to the seller, who then uploads the BTC transaction and the CKB transaction one after the other to complete the transaction.

Summary

RGB++ inherits the core idea of the RGB protocol and adopts a different virtual machine and validation scheme. Users don’t need a separate RGB++ client, but only need to access the Bitcoin and CKB light nodes to complete all the validation independently. RGB++ brings Turing-complete contract scaling and dozens of times of performance scaling to Bitcoin. It does not use any cross-chain bridges, but rather a native client-side validation scheme that ensures security and censorship resistance.

8 Likes

链外计算

  • 选中下一次要使用的一次性密封条,例如 btc_utxo#2

这里好像是选中 btc_utxo#1 ?

虽然看不懂,但大受震撼,牛逼完事了

1 Like

需要一段时间研究

Thanks for taking the time to do this :smiling_face::wave:

1 Like

个人研究RGB也有一段时间了,觉得RGB最大的优势是打破了区块链的枷锁,可以做到更好的隐私(数据主权)和无限扩展(百万级tps),对RGB++白皮书中的RGB痛点也深有体会,也期待RGB做得更好。现有两个问题:

1、RGB++中原始交易数据保存在Nervos网络还是其他地方?如果在Nervos网络是不是所有人可见?如果在其他地方,如何访问?

2、RGB的客户端验证在钱包就能很好的完成,不需要依赖节点,RGB++是否也能不依赖Nervos节点,只在钱包做到验证,如何做的?

你好,很高兴和您讨论 RGB/RGB++ 协议的细节

这些数据会被默认保存在 Nervos 网络,所有人都可见。这样解决了原始 RGB 协议的可组合性问题。但事实上,你也可以选择仅仅利用 Nervos CKB 的交易规则构造这些交易,而并不去提交/保存在 Nervos,这样就退化成了原 RGB 协议的方案——用户自己保存这些历史,仅在向收款人证明时提供这些“链外”数据。

我猜测你这里讲的“不需要依赖节点”应该是“不需要依赖【全节点】”的含义吧?RGB 的客户端验证需要 Bitcoin 块头哈希来验证 utxo 的存在性。RGB++ 协议是一样的,它的基础功能部分仅仅需要 BTC 的块头哈希证明,不需要依赖 CKB 的节点。关于这部分,做个简单的类比可以更好地说:假设我们可以构造一个 AluVM based UTXO chain,每一笔 RGB off-chain 交易都可提交到这个公链并被很好地验证,但你完全不需要依赖这个公链,因为只要你有足够的信息,用户可以自行验证 utxo 分支历史而不需要另一个链的共识机制帮你验证——尽管后者可以让应用开发、用户体验更加实用

但这里还有另外一个细节,就是 RGB++ 提出的交易折叠、非交互转账、共享状态等功能。如果说,RGB 协议的收款对象是 bitcoin utxo,那么 RGB++ 协议的收款对象既可以是 bitcoin utxo,也可以是 nervos address。在一个 RGB++ utxo 历史链条中,当收款对象在 btc utxo 和 ckb address 之间来回变化时,用户需要一个 ckb 轻节点来验证 ckb 的 PoW 块头以防止 ckb 上的 utxo 双花问题——这一点和我们需要 btc PoW 块头以防止 btc 上的 utxo 双花问题一样。那么安全性是否被妥协了呢?并没有,同样源自客户端验证的哲学理念,你认为 BTC 的 PoW 不够安全(唯一的攻击是 reorg 带来的双花攻击)你就在确认交易的时候多等几个确认;那么在使用 RGB++ 的交易折叠等功能时,如果你认为 CKB 的 PoW 不够安全(唯一的攻击同样是 reorg 带来的双花攻击),那么你只需要同样在确认交易的时候多等几个 bitcoin 确认 & ckb 确认。安全的级别是用户自选的,你不需要信任任何人。

3 Likes

感谢回复!
一个项目或产品,都是各方面的权衡和取舍。

关于非交互转账,我想是可以通过一个agent(智能合约)来自动进行,这个agent可以既是智能合约也是RGB钱包,以及其他更丰富的功能。

1 Like

你好,我看完了你的文章了,感觉非常有启发。不过由于此前我对 CKB 基本没有什么了解,是刚刚看完了官方的文档,所以我也遇到了一些疑问:

  • CKB 本身也是基于 UTXO 模型的,而且还支持智能合约(这个让我觉得非常惊喜,我一直想多了解一些基于 UTXO 模型且支持智能合约的区块链)。如果我真的要使用 CKB 的话,那我为什么还要使用 RGB 呢?如果我使用 RGB 是为了能够享受到 Bitcoin 的安全性的话,那么一旦我大规模地使用 RGB++ ,我必然需要依赖 CKB 的安全性(比如用到 Intent Cell 的场景或者非交互式转账的场景),如此一来整个系统的安全性就依赖于 CKB 了,我使用 RGB 的意义好像就变弱了

  • CKB 是怎么解决和 Bitcoin 的同步问题的呢?考虑到 CKB 是一个 L1 ,并不是类似于 Stacks 的基于 Bticoin 的 L2 (一旦 Bitcoin 出现 reorg ,Stacks 已经上已经被确认的交易也会尝试重新 settlement)。一旦 Bitcoin 出现 reorg ,再加上比特币链上可能出现的对交易的 RBF ,可能会导致比特币链的部分交易被修改,比如原本存在于某个 TX 的某个 OP_RETURN 因为 RBF 而消失了,而这个时候 CKB 没有相应的发生回滚,于是出现了 RGB++ 交易的 BTC TX 消失,而 CKB TX 依旧存在的情况。这个时候出现的混乱要怎么解决呢?(可能还有相反的情况,就是 BTC TX 还在,但是 CKB TX 没了,但是我没那么确定 CKB 会不会发生这种情况)

我想了想,好像我上面提到的两个问题其实归结起来就还是安全问题。是不是这就是你在 RGB++ Protocol Light Paper - #9 by Cipher 里说的 “那么你只需要同样在确认交易的时候多等几个 bitcoin 确认 & ckb 确认” ?

也就是说,如果我使用 RGB++ ,我有两种选择:

  1. 我可以同时发布 BTC TX 和 CKB TX ,这样出问题的概率是不是从 P(btc) 变成了 P(btc) + P(ckb)
  2. 如果我希望先确保 CKB TX 不会发生 reorg 然后再广播 BTC TX 并确保 BTC TX 也不会发生 reorg,那么我需要等待的时间就变成了 (ckb block time) * (ckb wait block) + (btc block time) * (btc wait block) ,这样会不会太久了?

期待你的回复,谢谢

1 Like

专业的问题,都是大牛!

很好的问题,我刚好打算写一篇安全方面的思考,这两天贴出来。不过我可以先对你的问题里面一个重要的细节讨论一下。

关于 reorg 的安全问题:注意 UTXO 链语境下,reorg 不等于交易失败或双花。如果没有交易发起人的恶意行为(对同一个 UTXO 签署两笔交易),那么区块 reorg 不会对确定性的交易有影响。所以在考虑安全问题时,这个点需要注意。剩下的我会在安全方面的文章里面详细讨论。

1 Like

感谢回复

关于 reorg 的安全问题:注意 UTXO 链语境下,reorg 不等于交易失败或双花。如果没有交易发起人的恶意行为(对同一个 UTXO 签署两笔交易),那么区块 reorg 不会对确定性的交易有影响。所以在考虑安全问题时,这个点需要注意。剩下的我会在安全方面的文章里面详细讨论。

对我明白,我指的就是存在恶意行为的场景,比如这种:

在一个非交互式转账的场景里,我先把一些 token 转到一个中间地址,我需要发起两个交易:BTC TX 和 CKB TX,在 CKB TX 和 BTC TX 确认后,我利用 BTC 的 reorg 的机会,发起一个 BTC TX 的 RBF ,修改掉这个交易。

此刻 CKB 链上的交易状态是我已经给中间地址转账了,在 BTC 链上是我没有给中间地址转账,如果我此刻运行的是一个基于 CKB 链上数据的客户端的话,我就会认为我基本上已经得到这个钱了,但其实在 BTC 链上我是没有得到这笔钱的

期待你的新文章

啊,关于我的第一个问题:

CKB 本身也是基于 UTXO 模型的,而且还支持智能合约(这个让我觉得非常惊喜,我一直想多了解一些基于 UTXO 模型且支持智能合约的区块链)。如果我真的要使用 CKB 的话,那我为什么还要使用 RGB 呢?如果我使用 RGB 是为了能够享受到 Bitcoin 的安全性的话,那么一旦我大规模地使用 RGB++ ,我必然需要依赖 CKB 的安全性(比如用到 Intent Cell 的场景或者非交互式转账的场景),如此一来整个系统的安全性就依赖于 CKB 了,我使用 RGB 的意义好像就变弱了

请问你的看法是什么呢?

如果我的整套系统的安全性是完全依赖 CKB 的话,那为什么我不直接使用 CKB 而是去使用 RGB++ 呢?

RGB++ 协议下折叠交易和 L1 交易的安全性可以做到等价,这块不用担心。如果用户不放心交易折叠,他们总是可以只使用 RGB++ L1 交易,而不使用交易折叠。此外,RGB++ 协议的资产主要是在 BTC 上发行。这就像 ETH L2 ,你不能说既然未来大规模采用必然发生在 L2 上,那大家就没必要用 L1 了。

我个人理解,虽然CKB已然非常灵活和强大且去中心化,这是从技术层面看,但BTC目前从共识上看仍然是大家最信赖的存在,也是共识度最高和共识最去中心化的,那么两者结合起来,在这个时间CKB经过四年的不间断的开发和完善,正好具备了承载BTC L2的基本条件(而不是像有些提出概念和想法,实现的时候还需要有链下或中心化服务端等的存在等),在当前环境下,回归BTC或者重新发掘UTXO和POW优势的呼声中,其实是更多的人想把ETH过于偏颇的方向在不同的方向能有不同的尝试,这是历史的潮流,那么正正好CKB和BTC的结合就是当下最好的叙事也是最好的尝试!未来CKB肯定不止是BTC的L2!

1 Like

如果BTC是区块链世界的原点和根,那么各种蓬勃发展的区块链项目就是这颗大树上的枝和枝丫,如果ETH是一个长的比较早且大的枝叉,那么CKB就是另外一个枝叉,他们生长的方向不一样,但是当这些枝叉变得大且繁茂的时候,还有很多藤蔓交织和贯通在一起,每个枝叉足够大的时候说不定自身又延伸弯曲并扎根于土壤变成了根,这是一个生机勃勃的新世界和生态。

1 Like

谢谢回复

在我看来 RGB++ 之于 RGB 不能以 L2 之于 L1 来类比

L2 是会有独属于自己的交易,只不过会在经过某些检查点时,把区块的验证信息 settle 到 L1 上(这更像是 RGB++ 的交易折叠)。而如果是 L2 上存在可能会影响 L1 的交易,比如从 L1 上转账到 L2 ,那么一旦 L1 发生 reorg ,L2 上的已经被确认的交易会被需要重新确认

我的感觉是 RGB++ 除了交易折叠的用例以外,其他情况下 CKB 链上的交易历史更像是 BTC 链上的交易记录的影子,我们需要始终保证 CKB 上的 RGB 交易和 BTC 上的 RGB 交易一一对应。我担心的情况就是在于,CKB 本身是一条 L1 ,它和 BTC 本身不存在什么关联,因此也没办法在 BTC 发生 reorg 的时候(并可能被人恶意利用或者破坏的时候)重新验证交易。


我们来想象一个例子:

  1. A 给 B 进行了一次转账 100z 消费掉了 UTXO#0 & Cell#0,大家等 BTC 和 CKB 上交易都确认了,此刻 B 有 UTXO#1 & Cell#1 。
  2. BTC 上发生了 reorg ,A 发现了这个情况,于是双花了 UTXO#0 ,把这 100z 发给了 C ,并且没有在 CKB 上发布任何交易(这是允许的对吧?我就进行一次 RGB 交易嘛)
  3. 于是我们现在的情况是 B 有 Cell#1 ,C 有 UTXO#2 ,这就变得很奇怪
  4. 我们再想象一下,假如 B 在收到 A 的转账后(A 还没进行双花),在一个交易折叠里进行了 20 多次转账,涉及到了 20 多个用户,这些交易里可能还添加了这些用户的其他 UTXO 作为输入,最后这些交易折叠到了一个 BTC 链上交易里。然后 A 实施了双花,于是这 20 多个用户的余额都出现了问题,对于 CKB 而言,那些 UTXO 应该已经被花掉了,但是整个交易链条又是有缺陷的(因为有一个 UTXO 已经不存在了),由于 CKB 上的交易不会因为 BTC 的 reorg 而触发重新确认,于是 CKB 上就出现了大规模的和 BTC 不一致的情况,而且状态没办法回滚到一开始的样子

RGB++ 想要实现的“共享状态”和“非交互式转账”好像也会遇到类似的情况,而为了避免这种情况:

  • 共享状态用例里的第三方聚合器就会需要多等几个 BTC block 才能进行聚合;
  • 非交互式转账的接收方会需要多等几个 BTC block 才能放心地把实体商品交给发送方

否则就有可能被发送方利用 reorg 破坏掉两条链上的交易记录的对应关系,实现恶意行为。尤其是对于共享状态用例,一旦对应关系被破坏,我感觉恢复起来可能也会比较麻烦

这是我比较担心的事情

谢谢回复,我也觉得 RGB++ 的想法挺好的,非常有意思,很期待它能真的生根发芽。

CKB 也非常有意思,我之前一直很期待想看看有没有一个 UTXO 模型的支持智能合约的区块链,不过之前一直不知道有 CKB ,这次看到以后就觉得很开心

2 Likes