RGB++ Protocol Light Paper (Translation)

English CKB Development & Technical Discussion
42

Not reNostr, it is this one: GitHub - RGB-Tools/rgb-proxy-server

You are not storing data on the proxy server (only for a very brief time). The proxy server is there just to facilitate transfer of off-chain data between the sender and recipient. Off-chain data is then stored by the recipient (in Iris Wallet this is stored locally on the device with encrypted copy saved on your google drive)

1 Like
43

You’d need to contact the LNP/BP association, here is a rust source where alternative L1s are defined: rgb-core/src/contract/xchain.rs at v0.11 · RGB-WG/rgb-core · GitHub

3 Likes
44

Hi admabor, nice post!

I’m a newbie to CKB and RGB, but I’m pretty interested in the RGB protocol.

Regarding assets moving between Bitcoin and Liquid, if I send my assets (let’s call the assets “Asset A”) from Bitcoin to other people (let’s call them “User B”) on Liquid, will User B (and their RGB client) have to continually check if the “Asset A” has not been double-spent until 6 Bitcoin blocks confirmed? Or is there some mechanism in the RGB protocol that ensures that user B doesn’t need to do this?

Thanks

46

Yes, the RGB software needs to check it a seal was closed on a chain it was defined.

So in your case user B needs to check if the state transition was committed in a bitcoin transaction, the number of confirmations he needs to wait for is purely depending on the preference of the user B, he can accept the payment after just 1 confirmation or he might wait for 6 confirmations for better security assurance.

47

Got it, thanks a lot

48

Hey, I do have 2 questions first here:

  • can you elaborate more on the 16MB memory limit of AluVM? From the docs I could find, AluVM seems to be a functional VM that do not have direct memory access. In this sense, how do we cap AluVM to this 16MB limit?
  • I do understand that in RGB’s design, a recipient only cares about transaction history from its senders. Assuming Alice receives fund from Bob, Alice only cares about the transaction history of Bob’s provided funds. However, Bob’s funds could come from Charlie and Dickens, Charlie’s fund to Bob could also comes from Eager, Fred and George. As time goes we are talking about a growing tree structure of transactions, is it the case that Bob still needs to run a non-trivial amount of transactions to secure Bob’s received funds? There is mentioning on solving the problem via SNARKs/STARKs in this thread. Though I was a little bit curious whether this is considered a concern of RGB in general.

And I do want to say a word or two regarding being turing-complete: I totally agree that with the current RGB design, a user needs to run much less transactions(tho I wasn’t sure of we can consider the number of transactions involved here to be trivial as time goes) compared to a full blockchain. However, I believe there are 2 orthogonal properties with respect to VM:

  1. How many transactions are executed in total from a user’s perspective
  2. Whether the design of a VM allows performant execution of sophisticated programs

Both factors contribute to the overall effectiveness of a system, and I personally don’t believe that either factor here eliminates the need for the other one.

So I do believe in a VM with proper abstraction as @orange-xc mentioned here: RGB++ Protocol Light Paper (Translation) - #11 by orange-xc

As an example here, CKB-VM aims to deliver enough performance, so public key authentication algorithms can be delivered as part of smart contracts, while most VMs, including AluVM, uses special opcodes to provide similar thing: rust-aluvm/src/isa/opcodes.rs at 1d24b92caebade27d2660437aebea3baa1d01384 ¡ AluVM/rust-aluvm ¡ GitHub

Again, I am merely providing my views into the problem, I believe there are more nuances hidden under the term of turning-completeness. VMs, while all being turing-complete, can still be drastically different, providing different potentials.

6 Likes
49

If you check out the registers, you can see that in total there could be at most 16MB of data in the string registers and 256kB of data in the ALU registers. GitHub - AluVM/rust-aluvm: Rust implementation of AluVM (RISC functional machine)

Yes, this is a correct understanding, it grows with every state transition / transfer, however it’s important to note that the this growth is strictly slower than the growth of a blockchain. You only verify the subset of history of a certain asset - and for that asset only, compared to blockchain where everyone verifies everything (all transfers for all the tokens).

It is considered a future concern. Was talking to guys from Bitfinex who are working towards deploying USDT on RGB, they estimated that it would take 2 years in the worst case (for high velocity asset such as USDT) before the history growth starts being a problem (it is also important to note that using RGB over Lightning doesn’t grow the history). But as already discussed here succinct proof systems (SNARKs/STARKs) are considered to be a permanent solution for this issue.

For centralized assets (like USDT) you can even use re-issuance, give the tokens to Tether, they burn them and give you fresh USDT without any history, this could even be done atomically in a single transaction (using scriptless atomic swaps: RGB scriptless atomic swaps ¡ LNP-BP ¡ Discussion #125 ¡ GitHub), such that not even Tether can steal your USDT during re-issuance.

Yes, you are right, I am not that deep in AluVM - I guess Maxim would be the right person to answer these questions. From what I know you can have extensions to AluVM adding additional opcodes, but not sure if those extensions are native or written in AluVM as well.

Also not sure if all the extensions need to be included in the RGB itself or if they can be just included in a specific RGB contract.

2 Likes
50

Thank you! Those make perfect sense to me

51

Posting this here as well… Why I think it makes sense to change the name of RGB++: Changing the name of RGB++

53

This is a very interesting proposal, interested how the space develops and whether more teams will be building ontop of this using this solution in the coming months.

3 Likes
54

Hey @orange-xc, great design!! I was wondering, how RGB++ handles Bitcoin reorgs?

Feel free to reply in this dedicated Github issue: How RGB++ handles Bitcoin reorgs? ¡ Issue #11 ¡ utxostack/RGBPlusPlus-design ¡ GitHub

TLDR Edit: even if Bitcoin reorgs, RGB++ has it covered. The Bitcoin inclusion block proof only appears in the witness of the RGB++ Nervos tx, so this particular information is not carried on in the next RGB++ tx of that particular cell.

1 Like
55

Hey @orange-xc, I have another doubt :thinking:

In RGB++ we have cell pairs of Bitcoin UTXO & CKB shadow cell, so I was wondering: would a user be able to spend the Bitcoin UTXO without spending its CKB shadow cell or is there any check on the Bitcoin-side preventing this scenario?

Love & Peace, Phroi

56

the CKB cell waits idle until it receives proof of a spend on Bitcoin

there will always be a time that the Bitcoin UTXO is spent but the CKB Cell is not yet spent, but someone just has to bring proof of the Bitcoin spend to CKB

1 Like
57

Hey @matt.bit, thank you for your reply :pray:

Almost, let me reformulate the question then. What happens if the Bitcoin UTXO is spent without following these rules? :point_down:

Let’s assume for example that no commitment is added to the output UTXO. Then, as far as we can tell, the CKB shadow cell becomes unspendable,

Love & Peace, Phroi

58

that sounds right, like sending assets to an all zero’s address

1 Like