Series on Bitcoin Commitment
This post is my thoughts on implementing a minimal product to validate the states bound to Bitcoin UTXO via commitments.
Bitcoin Commitment
- Bind states to Bitcoin UTXOs.
- States constitute DAGs.
The example above uses the first output OP_RETURN to tag a merkle root hash. The leaves of the mekle tree are hashes of states bound to the remaining outputs.
The DAG between states is derived from the bitcoin tx graph. Protocol like RGB does not use tx graph to avoid tx tracing, but it is not a concern to understand the core principle of UXO commitments.
DAG Validation
To verify a state, we need the state itself and all its ancestors.
Then we validate that:
- Root states are valid.
- State transitions are valid
- State bindings and the DAG structure matches the Bitcoin chain.
We don’t know the rules to validate root states and state transitions yet. Let’s add a genesis state. Here I add the hash of the genesis state to all the state nodes
Map to CKB
We can leverage CKB and its VM to validate the states.
First, we define Rules to be:
{
"code_hash": Hash(RISC-V Elf Binary),
"type": "data2",
"args": "0x..."
}
Yes, I use a CKB script structure. This script will be used as the type script.
Each state is mapped to a CKB cell, where
lock: anytype: the script set as Rules in the genesis state.data: Data part in the state (excludingH(G)).capacity: any
For Root states. We create a type script group that has no inputs, and has the state mapped CKB cell as the only output.
For non-root states, we create one script group for each transaction. The outputs are CKB cells for states that having sibling relationship in the DAG, and the inputs are their parents.
Users can run these script groups locally to validate, or complete these script groups into full CKB txs and commit them to the CKB chain. A CKB cell can be used as a proof of a state, if its type script and the data match the state, and it is created in a script group matching the state transitions. If the cell is in the CKB chain, users do not need to verify the history when they trust the CKB chain. Also notice that, anyone can commit the txs to CKB as a shortcut poof, and one state in Bitcoin may have many matched CKB cells. Strict 1 to 1 mapping requires careful protocol design, refer to RGB++ for one of such protocols.