Based on a protocol that employs a single-use seal and client-side validation, when making a transfer, legitimacy is verified by one party providing the entire transaction sequence to another. This raises a question: how is the first transaction in every transaction sequence generated?
Since RGB++ is a protocol that utilizes CKB, the initial thought is to use CKB’s scripts for constraints.
Assuming the asset standards used are xUDT and Spore, we can propose two types of Genesis constraints as follows:
- Bound to a specific Cell:
- The individual issuing the asset creates a cell and binds this cell to a btc utxo, which constitutes the Genesis of an asset.
- The owners of xUDT and Spore are set as the type_script of this Cell.
- This cell represents the right to mint coins. Thus, the minting right itself can circulate on the BTC chain and be controlled by a specific scriptPubkey. If destroyed, it implies that the asset can never be minted again.
- If only the BTC lock is used for control, then the type can simply use type_id.
- If a more complex minting determination is needed, developers can implement their own Type while utilizing the corresponding cell data to store some state for use.
- Bound to a specific lock:
- If the lock alone represents the right to mint, then every minting act is a Genesis operation.
If the lock represents the minting right and its verification is simply signature verification, then this is actually independent of CKB, as the minting right is constrained by the signature. But since CKB’s lock needs to sign the full transaction, this will bring a lot of inconvenience, so I don’t think this is a recommended method. Unless we build an asset type whose ownership is a BTC scriptPubkey.
However, further consideration of another approach reveals that the generation of type_id is guaranteed by CKB’s consensus, meaning that when users trace back to verify the legitimacy of the type_id’s generation, they rely on CKB’s consensus.
To address this issue, a new btc_type_id can be proposed, where the calculation of this btc_type_id is the hash value of the first input of the btc_tx + the index of the output cell in outputs as the type_id.
When creating the corresponding cell on the CKB chain, it is necessary to provide the existence proof of the corresponding BTC transaction in an spv cell, while verifying the commitment, and the correctness of the btc_type_id calculation.
During client-side verification, clients need to independently check whether the corresponding output’s btc_type_id was generated correctly according to the rules.
In this way, both types of Genesis transactions are protected against double-spending by BTC consensus.