#BinanceVietnamSquare
#CKB
This article will be for those of you in Vietnam. Automatic translation on BinanceSquare may not be accurate. I learned RGB++ myself, so this will be a high-level explanation to help you understand the keywords in RGB++. Leave your comments below ^!-
********************************************
agenda: *
1. RGB *
a) What is client side validation? *
b) Single-use seal - One-time use seal. *
2. RGB++ *
3. Key notes *
********************************************
1. RGB
In the RGB architecture, the asset issued on Bitcoin is simply a sha256 hash code, with a very small size of about 32 bytes that looks like this: 2e7d2c03a9507ae265ecf5b5356885a53393a2029d241394997265a1a25aefc6.
The actual content of the asset such as total supply, token name, fungibility is defined off-chain. The balance status of each party participating in the transaction is also recorded off-chain according to a common standard for all parties to follow. This entire content will then be hashed and written onto a Bitcoin UTXO unit(*).
Name, total supply, fungibility: saved to Bitcoin at asset issue (asset issuance)
Balance status: saved on Bitcoin when the parties settle the transaction. (transaction settlement)
Bitcoin itself cannot verify the state (e.g. balance) when these assets are transferred back and forth, so RGB uses a technique called Client side validation.
______________________________________
a). What is client side validation?
To verify off-chain, parties participating in the exchange of assets will have to save their own transaction history and that of those they interact with(**).
This transaction history is saved in the Merkle DAG - Directed Acyclic Graph tree format.
When a person sends an RGB asset, he creates a proof from this DAG tree and sends the transaction to the recipient.
When a person receives an RGB asset, he compares the attached proof from the sender with the Merkle DAG tree version he stores, and verifies the accompanying rules (i.e. of the smart contract).
Question: Here, people may wonder, what if a hacker sends Alice 100 RGB tokens in exchange for Alice's car, and immediately after creates an additional transaction to send himself 100 RGB tokens?
Here the hacker is double spending the 100 RGB tokens he has!
--> This is where Bitcoin enters RGB's architecture with its disposable seal. Single-use seal.
______________________________________
b). Single-use seal - Single-use seal
This disposable stamp was mentioned above. That is a UTXO unit on Bitcoin with a size of 32 bytes. This UTXO stores a summary of the parties' balance status and other information, and is attached to each transaction in RGB.
This UTXO is destroyed and recreated with new 32bytes of data per RGB transaction. This logic is programmed with the help of Bitcoin with Bitcoin script.
--> And with this help of Bitcoin, Hacker will fail in double spend transaction because the one-time stamp (UTXO) in the first transaction has been canceled and now becomes invalid.
_______________________________________
2. RGB++
a) CKB
First, we must explain what CKB is because this is the component used in RGB++ to upgrade RGB.
CKB is an upgrade from Bitcoin's UTXO ledger structure and is called cell-model (essentially a form of extended UTXO).
b) How does RGB++ upgrade RGB with isomorphic binding and CKB?
Replace DAG and manage it with cell (cell model) on CKB and CKB now becomes DA (data availability) for RGB, helping users avoid having to manage their own DAG version during transactions.
Linking single-use seal (Bitcoin UTXO) on Bitcoin side to CKB, helps verify transaction on CKB side and data settlement on Bitcoin side more conveniently.
_______________________________________
3. Key notes
Any asset on CKB can one step become a Bitcoin asset. (Early memes like Omiga on CKB are being integrated to convert into RGB++ assets).
Assets on CKB are not RGB++ assets
CKB assets will become RGB++ assets after being committed/settled to BTC
Users need Bitcoin to receive RGB++ assets. If you want to play defi this time, prepare some BTC with joyID
RGB++ team calls the step of committing/settle data to Bitcoin Leap/Jump
There is no Brige in RGB++ which means there is no risk of bridge hacking. The architecture of RGB and RGB++ allows creating Bitcoin L2 assets with a very high security level.