RGB++ Scripts
Understanding the core contracts and implementation details of RGB++ Protocol including RGBPP_lock, BTC_TIME_lock, and configuration mechanisms.
As described in the Typical Transaction Flow section, isomorphic binding requires that RGB++ transactions must be submitted on the Bitcoin chain, and that users utilize single-use seals on Bitcoin to describe operations on RGB++ cells.
Transaction Process
User constructs the CKB raw transaction and the RGB++ commitment
Submits Bitcoin transaction that contains the commitment
Submits the final CKB transaction
The ownership of Bitcoin UTXOs is encoded in the lock script of RGB++ Cells, specified by the combination of the Bitcoin transaction ID and output index. Regarding the commitment calculation, it encompasses the first N consecutive inputs and outputs, where N must include all inputs and outputs with non-null Type scripts.
Core Contracts
A specialized contract that manages the unlocking mechanism for RGB++ Cells, ensuring secure and controlled access to the assets.
Contract Structure
RGBPP_lock:
code_hash:
RGBPP_lock
args:
out_index | %bitcoin_tx%The combination of out_index and bitcoin_tx uniquely identifies the Bitcoin UTXO that owns this Cell.
Key Features
- • Manages unlocking mechanism for RGB++ Cells
- • Ensures secure and controlled asset access
- • Links Bitcoin UTXOs to CKB Cells
- • Validates commitment and transaction integrity
A time-based locking contract that enforces a predetermined block confirmation period when assets are transferred from Bitcoin Layer 1 to Layer 2, providing additional security for cross-layer transactions.
Contract Structure
BTC_TIME_lock:
args: lock_script | after | %new_bitcoin_tx%• lock_script is the owner of the cell once the time lock is unlocked
• after enforces a minimum block confirmation threshold
Security Features
- • Time-based locking mechanism
- • Block confirmation requirements
- • Cross-layer transaction security
- • Straightforward unlocking process
Both the RGBPP_lock and BTC_TIME_lock contracts require access to Bitcoin light client data, which is identified by the associated contract's type_hash. To eliminate hardcoded dependencies and enhance configurability, the protocol introduces the concept of Config Cell.
RGBPPConfig Structure
struct RGBPPConfig {
version: Uint16,
// Type hash of bitcoin light client
bitcoin_lc_type_hash: Byte32,
// Type hash of bitcoin time lock contract
bitcoin_time_lock_type_hash: Byte32,
}Deployment Process
# BTC_TIME_lock inputs: any cells outputs: BTC_TIME_lock code cell time_lock_config cell # RGBPP_lock inputs: any cells outputs: RGBPP_lock code cell rgb_lock_config cell
Configuration Loading
load_script finds current contract's type_hash
Locates cell dep with matching type_hash
Loads cell dep data to obtain global configuration
During the RGBPP_Lock unlocking process, the SPV cells are consulted to verify the existence of the corresponding Bitcoin transaction, while the commitment is recalculated and validated against the commitment stored in the Bitcoin transaction's OP_RETURN field, along with additional security checks.
Verification Steps
SPV Verification
Consult SPV cells to verify Bitcoin transaction existence
Commitment Validation
Recalculate and validate commitment against OP_RETURN field
Security Checks
Perform additional security validations and integrity checks
Process Diagram
The following figure demonstrates the unlocking process with detailed verification steps and security checks.
[Unlocking Process Diagram - See RGB++ Design Documentation]
Design Documentation
Implementation
Additional Information
For a comprehensive understanding of the protocol design, please refer to the RGB++ Script Standard documentation. The complete implementation can be found in the RGB++ Script repository with detailed code examples and deployment instructions.
Continue Learning
Now that you understand RGB++ Scripts, explore other core components and learn how to implement RGB++ in practice.