# CKB-side Validation on Bitcoin UTXO Commitment ## Metadata **Status**:: #x **Zettel**:: #zettel/permanent **Created**:: [[2024-02-29]] **URL**:: [Nervos Talk](https://talk.nervos.org/t/ckb-side-validation-on-bitcoin-utxo-commitment/7834) ## Synopsis 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. ![[CKB-side Validation on Bitcoin UTXO Commitment - Drawing Commitment.excalidraw.svg]] %%[[CKB-side Validation on Bitcoin UTXO Commitment - Drawing Commitment.excalidraw|🖋 Edit in Excalidraw]]%% 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. ![[CKB-side Validation on Bitcoin UTXO Commitment - Drawing DAG.excalidraw.svg]] %%[[CKB-side Validation on Bitcoin UTXO Commitment - Drawing DAG.excalidraw|🖋 Edit in Excalidraw]]%% ## DAG Validation To verify a state, we need the state itself and all its ancestors. ![[CKB-side Validation on Bitcoin UTXO Commitment - Drawing State History.excalidraw.svg]] %%[[CKB-side Validation on Bitcoin UTXO Commitment - Drawing State History.excalidraw|🖋 Edit in Excalidraw]]%% Then we validate that: 1. Root states are valid. 2. State transitions are valid 3. 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 ![[CKB-side Validation on Bitcoin UTXO Commitment - Drawing Genesis State.excalidraw.svg]] %%[[CKB-side Validation on Bitcoin UTXO Commitment - Drawing Genesis State.excalidraw|🖋 Edit in Excalidraw]]%% ## Map to CKB We can leverage CKB and its VM to validate the states. First, we define Rules to be: ```json { "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`: any - `type`: the script set as Rules in the genesis state. - `data`: Data part in the state (excluding `H(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. ![[CKB-side Validation on Bitcoin UTXO Commitment - Drawing CKB Script Groups.excalidraw.svg]] %%[[CKB-side Validation on Bitcoin UTXO Commitment - Drawing CKB Script Groups.excalidraw|🖋 Edit in Excalidraw]]%% 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++](https://talk.nervos.org/t/rgb-protocol-light-paper-translation/7790) for one of such protocols.