Design notes: verifying CKB state inside other chains (EVM-first, built on RFC 44/45)

English CKB Development & Technical Discussion
1

Gm everyone!

I want to share a design I’ve been working on and have it picked apart before any code gets written. The cheapest time to be wrong is now.

NOTE: This is design-stage. Nothing is built. Full design doc with threat model, cost estimates and a phased plan is here: REPO LINK. This post covers the shape and the specific places where I want pushback.

Where this starts

A few weeks ago I posted about Cellora, an indexing and query service I’m building for CKB. The most valuable feedback on that thread was about trust: an indexer sitting between signers and consensus is a trusted oracle whether we name it or not, and the path out is Merkle inclusion proofs up to headers, anchored by the chain root MMR and Flyclient.

That sent me down a rabbit hole, and at the bottom of it was a bigger question. The CKB light client protocol (RFC 44 and RFC 45) already gives us trustless verification on devices. Phones. Browsers through WASM. But nothing runs that verification inside another chain’s execution environment. Which means:

a phone           can verify CKB trustlessly
a browser tab     can verify CKB trustlessly
an EVM contract   cannot. it trusts a bridge committee instead

Every path from CKB state to a contract on Ethereum, Solana or a Move chain runs through a multisig, an MPC set, or an oracle. RGB++ gives trustless BTC↔CKB binding for issued assets, but the moment those assets head toward other ecosystems, the trustless property is severed at the bridge. The CKB↔everything-else leg is the gap.

The shape

One-directional: CKB state verified on destination chains. EVM first, because that’s where RGB++ asset liquidity would actually get used.

The design rests on one cost asymmetry, splitting the work into two operations with very different profiles:

tip updates        expensive, rare
                   verify Eaglesong PoW + FlyClient sampling
                   runs inside a zkVM, contract checks one SNARK
                   periodic, not per-message

inclusion proofs   cheap, frequent
                   CBMT branch + MMR branch, pure hashing
                   ~60-100k gas natively on EVM
                   no ZK in the hot path

Eaglesong has no EVM precompile, so verifying headers natively on Ethereum is economically impossible. That’s why tip updates go through a zkVM (SP1 first): the guest program verifies a batch of sampled headers, the MMR root transition and cumulative difficulty, and the contract verifies a single proof for around 320k gas. But once a tip is verified, proving a transaction or cell against it is just hashing, and that’s affordable directly.

The protocol-design crux is making RFC 45’s sampling non-interactive. An on-chain verifier can’t pick random heights the way an interactive client does, so sample heights are derived Fiat–Shamir style from the tip hash itself. The prover can’t choose which heights to prove, and grinding for favorable samples costs a full valid PoW per attempt. The analysis is in the doc.

One more decision worth stating plainly: the consensus-critical logic lives in a single shared no_std Rust crate, consumed by the zkVM guest, by native verifiers on Solana and CosmWasm later, and by the relayer. Written once, audited once. The relayer itself is deliberately not consensus-critical. Relayer bugs are liveness bugs, never safety bugs, and anyone can run one.

What this is not

  • Not a messaging protocol and not an asset bridge product. It’s the verification layer. Bridges and asset integrations are downstream consumers.
  • Not the reverse direction (verifying foreign state on CKB).
  • Not a fix for custody trust. This deserves a precise statement, credit to Neon for forcing it: a custodially wrapped asset stays custodially trusted no matter how good the verification layer is. What becomes trustless is the CKB-side state verification. An asset issued on CKB or bound via RGB++ gets a trustless end-to-end story; a custodial wrapper does not, and the SDK must never imply otherwise. The doc has a full asset trust taxonomy making this concrete.

Relationship to work happening right now

This space is suddenly active, which I take as a good sign.

Chiral. @matt_ckb pointed me at the Chiral light paper, which independently arrives at the same core conclusion: succinct on-chain light client verification is the right primitive for committee-free CKB interop. The shapes differ. Chiral is symmetric (each chain verifies the other) and Cardano-targeted; this design is one-directional and EVM-first. But the primitives overlap, especially Eaglesong proving. To the Chiral author if you’re reading: I’d genuinely rather compare notes than duplicate circuit work. Shared Eaglesong proving infrastructure with different protocols on top seems like the right ecosystem outcome. And I’d especially like to understand the soundness gap you’ve flagged on your CKB→Cardano leg, since my design may face the same class of problem.

ZK verification on CKB. @Mulandi_Cecilia’s research notes and groth16-ckb work run in the opposite direction to mine: she’s verifying proofs on CKB (~102M cycles per Groth16 verification, about 2.9% of a block, which is genuinely usable), while this design proves CKB to other chains. The two directions are complementary. If both mature, CKB verifies the world and the world verifies CKB, with no committee in either direction.

ckb-light-client. The existing implementation is the verification logic this design ports. The intent is to adapt its crates inside the zkVM guest rather than reimplement, so the consensus logic stays as close to the reference as possible.

Where I’d value input

  1. Sampling parameterization. The FlyClient sample count and difficulty-weighted distribution, adapted non-interactively, is the one place where a subtle error is catastrophic and silent. If you’ve worked on RFC 45 or the light client implementation, this is the section that most needs adversarial eyes.

  2. Cell liveness. Inclusion proves a cell was created, not that it’s still unspent. Proving liveness needs a non-inclusion proof that the CBMT/MMR stack doesn’t natively give. The doc lays out options (covenant patterns, a live-cell-set commitment, optimistic claims), but I’d like to hear from builders: is “this cell existed at height N with k confirmations” enough for your use case, or do you need “this cell is live now”? The answer shapes the SDK’s scope more than any other question.

  3. The extension-field off-by-one. The chain root committed in a header’s extension covers headers up to the parent. If you’ve implemented against this, war stories welcome. It’s a classic consensus-bug shape.

  4. Eaglesong proving. If you’ve put Eaglesong inside any proving system, your cycle counts and pain points would compress my de-risking phase significantly. This is the first spike in my build plan and the biggest open unknown.

  5. Demand reality-check. For teams shipping RGB++ or xUDT assets: would trustless verification of your asset’s CKB state on an EVM chain change what you can build? Honest “no, because…” answers are as valuable as yes.

The full doc covers the threat model, per-chain implementation plans, relayer economics, cost estimates and a phased build plan with written kill criteria: REPO LINK

Direct and critical feedback welcome.

References:

— Antismart

2 Likes