RGB++ Protocol Light Paper (Translation)

English CKB Development & Technical Discussion
6

Not sure if you can call it a security assumption because you are not trusting anyone but yourself with the off-chain data, same as you are trusting yourself with the private key.

The difference to CKB is obvious, whereas in RGB you only trust yourself with the off-chain data, in CKB you need to trust CKB blockchain to store and verify the data for you.

Maybe it’s better to say that there are no additional trust assumptions in RGB, but there is an additional trust assumption in CKB blockchain for RGB++.

7

I don’t understand this point. Transactions in RGB++ are exportable and support client-side validation in a purely off-chain manner. On-chain validation in CKB is merely a convenience for users. Users can verify data themselves and reject assets they do not recognize.

If I’m only receiving $20 in assets to buy a pizza, I might not bother with client-side validation. But if someone sends me $1 million, I would certainly prudently request transaction history for client-side validation.

1 Like
8

RGB++ is not a protocol dependent on chain validation.

Okay, that’s pretty interesting, that was not immediately clear from the writeup. So RGB++ can be used both ways, with off-chain & on-chain data stored on CKB.

In this case I think it would make a lot of sense to not re-invent the wheel and just use RGB and leave CKB acting as an optional indexer and DA layer. The reason for that is that there are already products being built on RGB, such as Bitmask, Bitlight, Kaleidoscope DEX, Iris wallet, and CKB can directly tap into that ecosystem, not fragment it even further (like what TapAss does). It also saves you a lot of development time (I would expect implementing RGB validation, even AluVM on CKB is much easier then re-building the whole RGB). Therefore, if CKB wants to be an indexer and DA layer for RGB, it can just use RGB and don’t re-invent a completely new standard which is incompatible with RGB.

How much value I personally see in that is debatable, it would certainly make sense for contracts with global state, but I am wondering if for that there isn’t some better approach (e.g. bitcoin inscriptions) without having to rely on external blockchains, such as CKB. But I guess we can let the market decide about that!

DA Issues: In some scenarios, DA issues do exist.

Yes, global state is tricky, there I see the value of using CKB as a public DA layer, however as stated in a prior paragraph, maybe there could be a better approach to that.

P2P Network Issues

Current status quo in RGB is to use proxy servers, where you upload encrypted off-chain data and the recipient downloads it from that very same server. The UX for that is great, because users don’t even know about it happening in the background (this is done by e.g. Iris wallet). There are of course also other ways one can send the data to the recipient, e.g. tor hidden service or wireguard with direct tunnels.

All those ways scale strictly better than having to put all of those data to a single CKB blockchain, so RGB++ doesn’t solve the P2P network issue, it just makes it even worse, whereas in RGB you can just send data to recipient, in RGB++ you need to send it to the whole P2P network. Again, this does makes sense for contracts with global state.

I would also argue that the UX of RGB++ also has its drawbacks, mainly the fact that you need to hold both BTC (to pay tx fee on bitcoin) and CKB (to pay tx fee on CKB).

Virtual Machine and Contract Languages

Okay, this is also interesting. No objection to that

Ownerless Contract Issues

Indeed, this makes sense, in that case data needs to be public, if people want to use CKB for DA so be it.

Many of the above issues are present to some extent; otherwise, the Prime scheme would be unnecessary

Prime solves none of the points you mentioned above:
DA Issues - there cannot be any DA on Prime, it’s purely just a single-use-seal layer (holds no data itself, only commitment to data).
P2P Network Issues - uses the same principle as RGB does, the off-chain data is passed from the sender to the recipient, transfer medium is out of scope for the Prime spec.
Virtual Machine and Contract Languages - Prime is also intended to use AluVM, but is also easily estensible to other VMs (without any softfork needed)
Ownerless Contract Issues - this isn’t solved in Prime at all, again Prime itself holds no data, only commitment to data compressed to a single merkle root per block.

2 Likes
9

Yes, it is possible to compile a BTC light node on the RISC-V virtual machine, while also compiling and deploying the VM used by RGB, thereby becoming an optional indexer and DA layer. However, firstly, this requires a significant amount of engineering effort, and secondly, the latest version of the RGB protocol has not been finalized, so I don’t know when RGB++ will complete this feature.

10

I don’t understand this point. Transactions in RGB++ are exportable and support client-side validation in a purely off-chain manner.

Yes now I get it, sorry, didn’t read your message first.

If I’m only receiving $20 in assets to buy a pizza, I might not bother with client-side validation. But if someone sends me $1 million, I would certainly prudently request transaction history for client-side validation.

Right, this makes sense. However what is already being explored in RGB is history compression (through SNARKs or STARKs), in that case the asset history will always be small enough to be verifiable by anyone (~500kB with STARKs).

11

Using zero-knowledge proofs in RGB, especially recursive zero-knowledge proofs, is a very promising direction. I notice you’re working hard to achieve this, which is great, as it will significantly reduce the cost for users to perform client-side validation

However, I have a slight concern regarding this. If the RGB protocol isn’t designed with enough abstraction and the VM used isn’t high-performance enough, will many new features require incompatible upgrades?

I believe a protocol should be designed with sufficient abstraction, for example, using RISC-V or WASM. This way, even if more powerful zero-knowledge proof solutions emerge in the future, they can be compiled and deployed as a contract within the protocol without requiring a hard fork. If you’re interested, you can take a look at this Blockchain Abstraction and Interoperability 2.0.

12

What mechanism does Prime use to resist double spending? Up until these seals are protected by Bitcoin.

13

That is a good objection to bring up to the LNP/BP association about RGB, however as AluVM is turing complete you can implement anything on top of it.

14

Prime is a chain of blockheaders (really small ones ~1kB), where the blockheader only contains merkle root of all the seals that were closed in that blockheader. Users are then required to store the proofs of either inclusion/non-inclusion of their seal inside the blockheaders (seal has a deterministic position inside the merkle tree, so proof of inclusion/non-inclusion is a single merkle path per blockheader). You can then reveal the proofs of non-inclusion for all blockheaders between the time the seal was defined and now, this proves that you haven’t closed your seal yet and the counterparty can accept your RGB state/assets. To commit a state transition you close the seal by including it in the blockheader’s merkle tree, get a proof of inclusion, and this way the RGB state transition is finalized. It is a super scalable singe-use-seal layer, with blocks (or as I call them, blockheaders) having constant size regardless of how many transaction are processed inside the block.

Prime is also designed to inherit full security of bitcoin through Bitcoin PoW anchoring.

1 Like
15

evm is aslo a Turing-complete vm, however, due to performance issues, it is very difficult to implement other cryptographic algorithms on it, such as BLS12-381, which must be added to the precompiled contract through a hard fork.

16

Prime sounds very interesting. It is also a compression scheme that can expand RGB. So do users need to transfer RGB assets to the UTXO hosted by Prime first? Without transferring authority to the UTXOs hosted by Prime, how can the commitment submitted by Prime represent the transfer of these assets? Are there security issues if permissions are transferred to Prime-hosted contracts? I may need to read further into the documentation to sort these out.

17

The performance of EVM is limited exactly due to the fact that it is a blockchain using it, so one computation in EVM needs to be re-run by all the 10k nodes in the ethereum network. This is not the case for AluVM, which only needs to be ran by the recipient, to my knowledge it has 16MB of available memory space, and the computation complexity is only bounded by the recipient executing it. So if you have more complex smart contract, you just need to tell the recipient to leave it running for longer - no hard fork required.

18

In RGB you can transfer assets between blockchains (this is already something up and coming in RGB v0.11 allowing users to freely transfer assets between Bitcoin & Liquid), the very same way you would be able to transfer and RGB assets between Prime & Bitcoin.

EDIT: As it is a client-side-validated protocol, you can freely transfer the assets between different single-use-seal layers. You can send an asset from a UTXO on Bitcoin to a UTXO on Liquid, or from a UTXO on Bitcoin to a seal on Prime.

19

Is there any relevant documentation on this? It sounds very interesting. As a UTXO chain, CKB can also be connected to the original RGB using this mechanism.

20

I think this needs to be tested. You can have confidence, but it depends on the actual situation.

21

That was also actually part of my critique. If you want to use RGB, better use is as is (with data off-chain) and use CKB as a single-use-seal commitment layer (same as Liquid or Prime), that would make more sense to me.

22

We have not seen any public introduction or demonstration that 0.11 can freely transfer assets on the Bitcoin main network and Liquid network, and the official association has not released relevant news.

From what I can find, it says it will be supported.

23

I just confirmed with the team over Telegram, it WILL be part of the 0.11 release. It even is already implemented.

24

Well, if it is turing complete than it can compute anything. Of course we can go into depths saying nothing is really turing complete because you have bounded memory and execution, but that’s a different discussion, as I mentioned earlier AluVM in RGB has 16MB of memory and the execution time is bounded by the client validating the state transition.

25

thank you for the infomation

1 Like