Through some public content, I guess that the interaction mode between RGB and Liquid is like this, that is, the UTXO bound in the commitment has chain information and is bound to a specific UTXO chain.
When a user transfers the binding of RGB assets from BTC to a UTXO on the liquid chain, the flow of RGB assets is automatically transferred to the liquid blockchain for commitment, and the user will turn to focus utxo on liquid blockchain.
I don’t know if my analysis is correct. I hope you can clarify the errors in my description.
Since the cell model is also a UTXO model, this form of transfer is also feasible for CKB, as long as RGB can assign a chainId to CKB.
How to solve the synchronization problem, because the block confirmation time of the Bitcoin main network and Liquid are different, what if a revert occurs on one side?
Well there is no synchronization problem. The transaction is always only committed/anchored on the source chain when you move between chains.
So when you have a state assigned to a UTXO on Bitcoin, you create a state transation sending that state to a UTXO on Liquid - the state transition is then anchored in a Bitcoin transaction and state is transfered. After that you transact on Liquid, so then the state transitions are anchored inside Liquid transactions.
It really is no different to sending state only on bitcoin, only the seal definition is not anymore just (txId):(output) but is extended to (chain):(txId):(output)
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)
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?
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.
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:
How many transactions are executed in total from a user’s perspective
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.
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.
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.
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.