RGB++ Protocol - Bitcoin Layer 2 Protocol

SPV Service Overview

Within the programmable layer of RGB++, a Bitcoin SPV light client maintains a synchronized record of Bitcoin block headers, enabling smart contracts to access and verify Bitcoin blockchain data, including historical transaction records, block difficulty, network hash rate, current block height, timestamps, and detailed transaction information, thereby providing a secure and efficient bridge between Bitcoin and CKB networks.

Core Functions

Prove if a header belongs to the Bitcoin chain

Prove if a transaction is in a Bitcoin block

Implementation

Synchronizes Bitcoin headers to SPV clients on CKB

Generate proofs for Bitcoin transactions verification

Technical Architecture

Given on-chain verification comes with resource constraints, such as the inability to afford 100 MiB of storage or 30 seconds of computation on CKB, the MMR is introduced to address this issue by only saving the MMR root of Bitcoin headers on CKB.

MMR (Merkle Mountain Range)

MMR provides a compact representation of the entire header chain with efficient verification capabilities, making it ideal for resource-constrained environments.

✓ Efficient storage
✓ Fast verification
✓ Resource optimized

Merkle Proof

Merkle proof is used to verify that a transaction - or specifically, its hash - was included in a given block.

✓ Transaction inclusion proof
✓ Cryptographic security
✓ Minimal data requirements

SPV Type Script

Architecture Overview

A Bitcoin SPV on CKB consists of cells that are managed by the CKB Bitcoin SPV Type Script and identified by the script arguments. A Bitcoin SPV instance is a collection of cells containing two types of cells: SPV info cell and SPV client cell.

SPV Client Cell

A cell is identified as an SPV client cell if its type script matches the SPV type script. SPV client cells store the Bitcoin state. Each Bitcoin SPV instance includes a minimum of three SPV client cells.

Cell Structure

Client Cell:  
    Type Script:
        code hash: "..."
        hash type: "type"
        args: "typeid + clients count + flags"
    Data:
        - id
        - btc tip block hash
        - btc headers mmr root
        - target adjust info

Key Features

• Stores Bitcoin blockchain state
• Minimum of 3 cells per SPV instance
• Contains MMR roots for verification
• Manages target adjustment information

SPV Info Cell

The SPV info cell stores the basic information of the current Bitcoin SPV instance, such as tip_client_id. Each Bitcoin SPV instance contains only one SPV info cell.

Cell Structure

Info Cell:
    Type Script:
        code hash: "..."
        hash type: "type"
        args: "typeid + clients count + flags"
    Data: 
        - tip client cell id

Characteristics

• One per SPV instance
• Contains tip client cell ID
• Manages current state pointer
• Coordinates client cell updates

Ring Structure & Updates

The SPV cells are initialized in a single transaction, resulting in one SPV info cell and a minimum of three SPV client cells. The cells must be arranged consecutively, with the SPV info cell positioned first, followed by the SPV client cells in ascending order of their IDs.

Ring Structure Operation

Initialization

Upon initialization, all client cells must contain identical data. The SPV info cell points to the current tip client.

Update Process

The SPV client cell with an ID matching the tip_client_id contains the most recent data, while the next cell in sequence holds the oldest data. This arrangement forms a ring structure where the sequence wraps around from the last cell back to the first cell.

Data Rotation

During updates, new data is written to the cell currently holding the oldest data, and the tip_client_id in the SPV info cell is updated to point to this newly updated cell, effectively marking it as the new "latest data" holder.

Technical Resources

Design Documentation

Implementation

Continue Learning

Now that you understand SPV Service, explore other core components and learn how to implement RGB++ in practice.