RGB++ Protocol Light Paper (Translation)

[adambor]

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)

[adambor]

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

[c4605]

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

[adambor]

@c4605

Regarding assets moving between Bitcoin and Liquid

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.

[c4605]

Got it, thanks a lot

[xxuejie]

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.

[adambor]

@xxuejie

can you elaborate more on the 16MB memory limit of AluVM?

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)

@xxuejie

As time goes we are talking about a growing tree structure of transactions

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).

@xxuejie

Though I was a little bit curious whether this is considered a concern of RGB in general.

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.

@xxuejie

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

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.

[xxuejie]

Thank you! Those make perfect sense to me

[adambor]

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

[medici]

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.

[phroi]

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.

[phroi]

Hey @orange-xc, I have another doubt

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

[matt_ckb]

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

[phroi]

Hey @matt_ckb, thank you for your reply

@matt_ckb

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

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

@orange-xc

1. Off-Chain Computation

• Select the next one-time seal to be used, for example, btc_utxo#2
• Off-chain computation and generate an RGB++ transaction to be sent to CKB: CKB_TX_B
• Off-chain computation commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)

2. BTC Transaction Submission

• Generate and send a Bitcoin transaction Bitcoin_TX_A, consume btc_utxo#1 as input, and output the commitment added by OP_RETURN above.

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

[matt_ckb]

@phroi

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,

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

[Lutian_Guang]

I appreciate the detailed discussion here. I have a question regarding the execution of automated liquidations: If the private keys for Bitcoin UTXOs used as collateral on CKB are held by the staker, how can automated liquidations be reliably executed in cases where the staker is unwilling to cooperate?

[phroi]

@Lutian_Guang

If the private keys for Bitcoin UTXOs used as collateral on CKB are held by the staker, how can automated liquidations be reliably executed in cases where the staker is unwilling to cooperate?

Hey @Lutian_Guang, glad to have you here

I’m an independent developer working on Nervos L1, for references see my work on NervosDAO’s liquid staking iCKB. I’m not part of the RGB++ effort, but I got curious too, so I studied the RGB++ RFCs. Please take my replies with a grain of salt. Also @orange-xc @Hanssen feel free to correct me.

Could you provide a bit more context to your question?

For example, let’s say you are referring to Stable++ integration of RGB++ to mint a RUSD stablecoin on Bitcoin, the steps are currently the following:

1. User owns a BTC UXTO
2. User leaps from Bitcoin UTXO to Nervos L1’s ccBTC token with JoyID
3. User mints RUSD token offering as collateral his ccBTC token
4. User leaps his RUSD to back Bitcoin via JoyID (Spoiler: this is the only real RGB++ tx happening here)

Back to your question, as you can see liquidations are easy: say the Stable++ protocol needs to liquidate a RUSD position minted from BTC, it just liquidates the ccBTC collateral. For context, ccBTC is a very normal wrapped Bitcoin, very similar to wBTC. As for wBTC, ccBTC is also issued by a trusted regulated entity that safely locks the underlying BTC UTXO.

And that is that.

Digging a bit deeper, in the available docs it’s claimed that JoyID leaps are Transaction Folding.

TLDR: Transaction Folding means splitting Nervos L1 shadow-cell into two cells, one with the UTXO lock and the second cell with a normal lock with the user Nervos L1 asset. Now the user Nervos L1 asset is handled with 100% normal txs until the user leaps back to Bitcoin.

On the JoyID interface you can also leap BTC into ccBTC, but this is definitely not a Transaction Folding as you cannot mint ccBTC out of thin air. Only the ccBTC issuer is allowed to do that.

Under the hood, JoyID quietly is bridging these BTC to ccBTC for us (possibly an integration with Meson Finance?). @Cipher I’d like more details on this too

Love & Peace, Phroi