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.
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.
I just confirmed with the team over Telegram, it WILL be part of the 0.11 release. It even is already implemented.
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.
thank you for the infomation
1 Like
What I mean is that the virtual machine needs to be checked. 16M may be discussing performance issues.
Of course, I donāt doubt that it will be great in actual performance, I just state that it needs to be tested and enough development needs to be done through it to know whether everything works.
1 Like
Iām very much looking forward to its final release.
1 Like
But if I remember correctly, Liquid is not a public chain, but a federated blockchain, right? Will this bring some custody risks?
Yes, you are right, Liquid uses a federated model and is therefore less secure than bitcoin. Thatās why you as an RGB contract dev can specify which chains to allow for your RGB asset. The asset is then only as secure as the least secure chain it ever was on during its history.
1 Like
Does this mean that RGB itself can be connected to other chains, Liquid, or other utxo chains?
Of course, I donāt know what the limits of this connectivity are? For example, is it just an asset transfer?
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.
1 Like
Not limited to an asset transfer, any state can be transfered freely between chains.
Yes, your understanding is correct.
Exactly, and that would actually make way more sense than RGB++.
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)
1 Like
ok,thank you
1 Like
appreciate your patient and reply
2 Likes
Are you referring to reNostr? Who would pay for the storage costs of the proxy servers?
Quite interesting, thanks for sharing.
Is there a defined process to add chains/chainids?