Cell contention is an often discussed issue with UTXO-based blockchains and prevents certain classes of applications from being practically implemented.
Cell contention: competing transactions race to consume the same cell, most fail, and the network fills with noise.
How I got here
The idea of “how can we bring shared state to CKB” has been discussed for some time now, credit to @xxuejie for really raising this and considering possible solutions and to @nirenzang for considering it as well.
Ren shared an idea with me about the possibility of an operator fairly issuing “tickets” to update a set of cells, thus effectively accomplishing the “anyone can update” property of shared state without requiring consensus changes.
What is being proposed
Bitcoin showed us that proof of work is a general solution to create a “leaderless” paradigm and decentralizes the notion of an operator.
With this in mind, we can construct systems on top of CKB which are updated once a specific “miner” presents a valid state transition to the system, along with a “proof of work” that meets the difficulty target.
Contract logic is enforced by the chain, while access to update cell(s) is controlled by proof of work.
An idea for implementation
Lockscript: pow check, difficulty adjustment at every state transition
Typescript: application logic
My preference is for SHA256 because we can re-use Bitcoin hardware and use the Bitcoin header format for state transitions. The system mimics a blockchain in that each state transition commits to the hash chain of state transitions before it (maybe this is needed, maybe not, but seems like a nice property to have).
Nuances
-
Many of these systems can run concurrently (maybe it’s even possible to interact across them if we can sort out the data structures).
-
Someone can grief the system by solving the pow puzzle faster than anyone else, but they will eventually be burning their own money if they are “mining” purely to grief the system. The time dimension here may have impacts on defi, but it’s possible that economic incentives can find equilibrium.
-
Difficulty adjustment can be accomplished through
header_deps+ inclusion proofs of the previous 2 state transitions on the system (difference between the timestamps in those 2 block headers) -
Light clients should be able to subscribe to these systems independently, I don’t see anything preventing this.
credit to @TabulaRasa for this summation: “Nakamoto consensus solved L1 money consensus this solves L2 tx ordering execution consensus”
AI Explanation
Introduction
On CKB, application state lives in cells — discrete UTXO-like containers that can only be consumed and recreated by one transaction at a time.
When multiple parties need to update the same cell (a DEX order book, a liquidity pool, a shared registry), you get cell contention: competing transactions race to consume the same cell, most fail, and the network fills with noise.
Solutions
We could have a centralized operator who issues “tickets” granting sequential write access to shared state cells — which works, but reintroduces a single point of control. Matt’s insight is that this is exactly the problem Nakamoto consensus already solved: decentralizing leader selection.
Instead of an operator issuing tickets, the lock script on the shared state cell performs a PoW verification check. Anyone who finds a valid nonce (against a difficulty target embedded in the cell) earns the right to update that cell.
Implementation
The type script then validates the actual state transition logic — so authorization (lock = “who can update”) is cleanly separated from validation (type = “what the update does”). Difficulty adjusts dynamically based on update frequency, and griefing is self-punishing since attackers burn real hash power for no economic gain.
The DeFi implications are significant. Today’s MEV problem is fundamentally a race condition — whoever gets their transaction ordered first extracts value. PoW-gated cells replace speed-of-access races with cost-of-work equilibrium: you can only profitably update shared state if the value of doing so exceeds your PoW cost, which creates a natural price floor on extraction.
The implementation reuses the Bitcoin block header format for proof structure, making it essentially SPV verification — the cell contains the full “block” (state transition + proof) and the lock script verifies the header meets the difficulty target.
Each shared state cell becomes its own mini-blockchain, with independent difficulty adjustment and ordering guarantees, all settled on CKB L1. Multiple such systems can run concurrently — appearing chaotic but internally ordered — because each cell’s PoW chain is independently verifiable.
It’s the type/lock paradigm doing exactly what it was designed for but has been underexplored: lock handles consensus mechanics, type handles application logic.