Option 1: A Based ZK Rollup on CKB
When discussing an EVM environment on CKB, the conversation usually begins with execution: Solidity compatibility, Ethereum RPCs and the migration of existing DeFi protocols.
Yet execution may no longer be the defining question. Mature EVM implementations already exist. The harder questions concern who orders the next batch, what CKB itself ought to verify, and how users retain control over their assets when execution takes place elsewhere.
I have been exploring whether Myelin could provide the off-chain foundation for a based EVM architecture whose canonical ordering and settlement are governed by CKB itself.
I see three possible architectures worth exploring:
-
Option 1 — Based ZK Rollup: CKB provides canonical sequencing, L1 data availability and validity-proof settlement.
-
Option 2 — Based ZK Validium: The same sequencing and validity-proof model, but with external data availability to support higher throughput.
-
Option 3 — Based Optimistic Rollup: CKB provides canonical sequencing and data availability, while disputed EVM execution is adjudicated through a CKB-VM-compatible court rather than continuous ZK proving.
These options explore two distinct design choices: where transaction data resides, and how execution correctness is established. All three retain CKB as the canonical sequencing and settlement authority, while Myelin provides the off-chain execution and evidence infrastructure.
Option 3 is particularly interesting in relation to Myelin’s original CKB-isomorphic execution model, although extending its existing court machinery to EVM semantics would require substantial additional work.
This first post focuses on Option 1, with the other two explored separately in the thread.
The idea follows my earlier discussion, Introducing Myelin: a CKB-aligned off-chain Cell session runtime.
Myelin began as an experiment in preserving CKB transaction semantics across off-chain sessions: deterministic execution, dependency scheduling, persistent state, evidence commitments and a path towards L1 adjudication. It was deliberately not presented as a new permissionless chain.
An EVM Rollup would require a separate execution backend, but much of Myelin’s surrounding runtime machinery could be useful. More importantly, it raises an architectural possibility worth examining: using CKB’s own consensus and Cell model to establish the canonical history of an EVM ledger, without appointing a permanent L2 sequencer.
This is a design proposal, not an announcement of an implemented Rollup.
What makes a Rollup based?
The term comes from Justin Drake’s original proposal.
In a conventional Rollup, an L2 sequencer typically collects transactions, chooses their order and submits batches to L1. Even where users have a forced-inclusion mechanism, the sequencer retains considerable influence over transaction ordering and short-term censorship.
A based Rollup takes a different approach. The underlying L1 determines the canonical sequence of L2 blocks. The right to propose the next Rollup block is permissionless, rather than reserved for an appointed L2 operator.
The important distinction is not whether an L2 block eventually appears on L1. Almost every Rollup does that. It is whether a privileged actor controls which L2 blocks may advance the chain.
For CKB, this would mean allowing competing builders to assemble EVM batches, while CKB miners determine their canonical inclusion through ordinary PoW consensus.
There would be no separate L2 committee whose signatures establish the authoritative batch sequence.
This does not eliminate MEV or guarantee immediate confirmations. Builders still influence transaction ordering within their batches, and ordering competition moves towards the L1 block-building and fee market. CKB also has its own transaction proposal window, so the latency and preconfirmation model would differ from Ethereum-based designs.
Nevertheless, the attraction is considerable: the Rollup need not maintain a second political or economic authority over its canonical history.
Why the Cell model is particularly interesting
CKB has a useful property which is easy to overlook in discussions dominated by account-based contracts.
A Cell can only be consumed once in the canonical chain.
Suppose a Rollup maintains a SequencingTip Cell representing its current ordered batch frontier. A valid proposal consumes that Cell and creates a successor with the next batch commitment.
Two competing proposals cannot both become successors of the same Cell in the same canonical history.
This gives us a native, L1-enforced linearisation point.
flowchart TB
A["Permissionless EVM batch builders"] --> B1["Candidate batch A"]
A --> B2["Candidate batch B"]
S["Current SequencingTip Cell"]
S --> B1
S --> B2
B1 --> C{"CKB canonical inclusion"}
B2 --> C
C --> D["One accepted successor"]
C -.-> R["Conflicting spend cannot survive"]
D --> E["Next SequencingTip Cell"]
E --> F["Canonical EVM batch stream"]
classDef builder fill:#edf3ff,stroke:#6487ca,color:#1f3c75
classDef canonical fill:#daf3e7,stroke:#38936d,color:#14573e
classDef reject fill:#fff0eb,stroke:#cb806e,color:#8b4031
class A,B1,B2 builder
class S,C,D,E,F canonical
class R reject
The Type Script would enforce the transition rules: the previous tip must be consumed, the successor must preserve the Rollup identity, and the new batch commitment must be correctly formed and linked to the old one. Crucially, advancing this Cell would not require a designated sequencer’s signature.
This is not a free scaling solution. A singleton sequencing Cell creates contention, and CKB’s proposal/commit mechanism complicates successive batch production.
My preferred starting point is to separate parallel transaction intake from L1 canonicalisation. Myelin could execute bounded microbatches off-chain, which are then assembled into ordered epoch manifests, with one CKB sequencing transition per epoch.
This amortises contention rather than eliminating it. The sustainable checkpoint rate would still need to be measured under realistic CKB transaction-dependency conditions.
There is another important requirement: users must be able to submit transactions without depending on a particular builder.
I would distinguish ordinary batch-data publication from a separate, authenticated priority inbox on CKB.
The first provides the transaction data needed for independent reconstruction. The second provides a potential route for forced inclusion when ordinary builders refuse to process a user’s transaction.
The priority inbox would need explicit admission rules, resource limits, deterministic rejection semantics and verifiable processing obligations. Simply recording requests on L1 would not, by itself, guarantee their execution.
Its ordering and completeness must also be authenticated without trusting an off-chain indexer’s interpretation of CKB history.
These are protocol responsibilities, rather than details that can safely be delegated to the mempool.
Myelin as an execution and evidence substrate
I would separate the system into three responsibilities:
- CKB determines the canonical order of accepted batches, authenticates the sequencing history and enforces verified settlement.
- Myelin reconstructs that history, executes the corresponding state transitions and provides the infrastructure for independent state reconstruction.
- Independent provers demonstrate that the EVM state transitions conform to the committed execution rules.
The proposed architecture would look roughly as follows:
flowchart TB
subgraph USER["Ethereum application surface"]
U["Wallets and Solidity applications"]
B["Permissionless batch builders"]
U --> B
end
subgraph CKB["CKB Layer 1 · PoW authority"]
D["L1 batch-data publication"]
I["Authenticated priority inbox"]
O["SequencingTip Cell<br/>Canonical ordering frontier"]
S["SettlementTip Cell<br/>Verified EVM state"]
V["Asset vaults and withdrawal claims"]
D --> O
I -.-> O
S --> V
end
subgraph MYELIN["Myelin · Off-chain runtime"]
F["Canonical CKB follower"]
E["EVM execution and state reconstruction"]
P["Independent validity prover"]
F --> E --> P
end
B --> D
U -. "Forced inclusion" .-> I
O --> F
D -. "Published execution data" .-> F
O -. "Authenticated history" .-> S
P --> S
V -. "Deposits and exits" .-> E
style USER fill:#f4f0ff,stroke:#9b87c6,stroke-width:2px
style CKB fill:#eaf3ff,stroke:#6b91c9,stroke-width:2px
style MYELIN fill:#e9f6f0,stroke:#6fae91,stroke-width:2px
The proposed EVM execution profile would use an established Ethereum execution engine, such as revm, with canonical Ethereum account and storage semantics.
This deserves a distinction from Myelin’s original design.
The existing Cell execution model is CKB-isomorphic: its transactions and scripts are deliberately shaped to remain compatible with CKB-VM. EVM execution cannot simply inherit that claim. Ethereum has a different state model, execution semantics and gas accounting.
I would therefore retain native Cell sessions as one Myelin execution profile and introduce EVM execution as another.
They could share infrastructure for deterministic batch processing, recovery, durable state lineage and evidence generation, without pretending their virtual machines are equivalent.
For the EVM profile, correctness would be established through validity proofs rather than direct CKB-VM replay of every EVM instruction.
CKB would verify the proof, not emulate Ethereum.
There is also an unresolved data-publication question within the Rollup design itself.
CKB transaction witnesses, Cell data and other CKB-committed data structures have different storage, retrieval and economic properties. The precise data carrier must ensure that independent participants can retrieve the ordered transaction inputs needed for state reconstruction.
Merely committing to a data hash is not sufficient for Rollup-grade data availability.
Two frontiers instead of a second consensus network
The part of this design I find most promising is to separate the ordering frontier from the proven-state frontier.
The first advances when CKB accepts the next canonical batch. The second advances when a validity proof establishes the resulting EVM state transition.
They need not advance at the same pace.
flowchart TB
subgraph ORDER["CKB ordering frontier"]
direction LR
O0["Order 0"] -->|"Batch A"| O1["Order 1"]
O1 -->|"Batch B"| O2["Order 2"]
O2 -->|"Batch C"| O3["Order 3"]
end
subgraph PROOF["Verified settlement frontier"]
direction LR
P0["State 0"] -->|"Proof A"| P1["State 1"]
P1 -->|"Aggregated proof B + C"| P3["State 3"]
end
O1 -. "Verified ordered prefix" .-> P1
O3 -. "Verified ordered prefix" .-> P3
classDef ordered fill:#dfeaff,stroke:#668bd1,color:#203e77
classDef proven fill:#ddf3e5,stroke:#55a37b,color:#195c3d
class O0,O1,O2,O3 ordered
class P0,P1,P3 proven
style ORDER fill:#f5f8ff,stroke:#a6bce5
style PROOF fill:#f1fbf5,stroke:#9ed0b3
The ordering commitment would bind each new batch to the previous commitment. Separately, the settlement Cell would hold the latest verified Ethereum state root and the highest proven batch index.
A proof authorising settlement must establish that it has executed the next contiguous range of the canonical CKB-ordered batch history, starting from the previously verified state.
The verifier’s public inputs would bind the Rollup identity, protocol version, execution rules, authenticated batch range, previous state root, new state root and withdrawal commitment.
One detail that deserves particular attention is how the settlement verifier authenticates that historical batch range.
A simple hash chain establishes succession, but does not necessarily provide efficient proofs that an older range belongs to the accepted history.
An append-only authenticated accumulator, CKB-authorised batch receipts, or an equivalent mechanism supporting verifiable prefix extensions may therefore be needed.
The settlement script must verify the relationship against authenticated CKB sequencing state, rather than accepting a prover-supplied account of canonical history. The precise commitment structure and its CKB-VM verification cost remain to be specified.
This separation would let different parties participate without granting any of them permanent authority over the ledger.
A miner or builder could propose a batch without producing its validity proof. A prover could settle a range of batches without deciding their order. A full node could independently reconstruct the EVM state from published transaction data.
There is, however, an important liveness problem.
An unproven batch must not become an irreversible obstruction merely because its builder supplied malformed data or an impossible execution workload.
The batch format, admission rules, resource bounds and treatment of rejected transactions must make every admissible ordered entry deterministically processable.
Otherwise, separating ordering from proving would introduce a denial-of-service mechanism.
The settlement logic must also account for prover disappearance. Permissionless proof generation removes dependence on a particular prover in principle; practical recovery additionally requires public data, reproducible proving inputs and a workable exit path.
These are the areas where I would concentrate much of the protocol design.
How this differs from Godwoken
It would be misleading to discuss an EVM Rollup on CKB without acknowledging Godwoken.
Godwoken and Polyjuice established that an EVM-compatible execution environment could be built above CKB.
The original Godwoken framework was intended to support permissionless Rollup configurations, while its early deployments used an optimistic-Rollup design and PoA-controlled L2 block issuance.
That work addressed a genuine limitation in the ecosystem: Ethereum developers could not otherwise bring their existing contracts and tooling into a scalable CKB-connected environment so readily.
I regard the proposed based design as a continuation of that research direction, with a different emphasis.
| Dimension | Early Godwoken architecture | Proposed Myelin-based ZK Rollup |
|---|---|---|
| Execution | Polyjuice EVM | Ethereum-equivalent execution backend |
| Block ordering | PoA-controlled L2 production in early deployments | Permissionless batch proposals, canonical sequence determined by CKB |
| State verification | Optimistic/challenge-oriented design | Validity-proof-oriented settlement |
| L1 responsibility | Rollup commitments, contracts and settlement | Canonical ordering, L1 data publication, proof verification and settlement |
| Off-chain infrastructure | Godwoken-specific Rollup node | Myelin runtime extended with an EVM profile |
These are comparisons of architectural models, not a claim that Godwoken never contemplated other consensus mechanisms or ZK configurations.
The distinction I care about is where authority resides.
Godwoken’s early architecture provided an Ethereum-like execution environment whose blocks were produced by an L2 authority set and committed to CKB.
In a genuinely based design, L1 consensus determines which permissionlessly proposed Rollup batches become canonical. The proof system determines whether the resulting state can be settled.
This is not the same as guaranteeing transaction-level fairness.
Builders would still choose the order of ordinary transactions within their batches, subject to whatever inclusion and ordering constraints the protocol enforces.
Meaningful censorship resistance would therefore require an authenticated forced-inclusion path, rather than relying on permissionless batch publication alone.
There is a difference between using CKB as a place to publish Rollup commitments and allowing its consensus to govern the canonical extension of the Rollup’s execution history.
That latter possibility seems underexplored.
What kind of ecosystem could emerge?
The immediate attraction is familiar: Solidity contracts, Ethereum wallets, automated market makers, lending protocols, stablecoins and the wider body of EVM tooling.
But simply creating another EVM environment with a bridge to CKB would offer a rather limited proposition.
The more interesting opportunity is to combine Ethereum’s composable execution environment with CKB-native ownership and settlement semantics.
Consider CKB-native assets such as xUDT tokens. Their custody and issuance constraints could remain enforced through CKB Cells, while representations of those assets circulate in an EVM environment offering AMMs, lending markets and other financial primitives.
An asset might originate under a CellScript-defined issuance or redemption policy on L1 and gain access to EVM liquidity through a proof-secured vault.
Returns to L1 would be authorised against verified withdrawal commitments rather than an operator’s discretionary approval.
The two environments would retain different strengths. EVM provides a familiar programmable financial environment; CKB retains the underlying asset custody rules.
Cross-layer interactions would still be asynchronous, and their bridge contracts would form a significant security boundary. This proposal should not be mistaken for atomic EVM–CKB composability.
The availability of liquid stablecoins would be particularly important.
Deep markets cannot be obtained from execution compatibility alone. A technically correct AMM without useful collateral, stablecoin liquidity or reliable price discovery is not much of a financial system.
Another possibility concerns Fiber.
A mature Fiber ecosystem could provide payment and liquidity-routing services around the Rollup, whilst the EVM environment handles more complex programmable positions and CKB provides asset settlement.
The integration would need explicit message and trust boundaries, but the complementary roles are worth exploring.
There may also be room for RFQ markets, tokenised real-world asset workflows and agent-operated financial applications, especially where the origin of an asset, the rules governing its custody and its trading environment ought to remain separately verifiable.
I find the economic implications interesting as well.
If applications depend on CKB for canonical ordering, batch publication and proof-backed settlement, their activity creates demand for CKB block space.
That is a different relationship from an L2 which merely posts an occasional state commitment whilst most of its economic activity remains within a proprietary ordering system.
It would connect a portion of Rollup activity to the existing L1 fee market.
Of course, the economic significance would depend on actual usage, fee levels and the resulting demand for block space. More L2 transactions do not automatically translate into proportionally greater L1 revenue.
There is also a hard capacity constraint.
CKB’s block space is finite, and publishing complete Rollup transaction data is more expensive than publishing a commitment alone.
A validity proof solves execution verification; it does not solve data availability.
For a trust-minimised Rollup, independent parties must be able to reconstruct the state from available batch data.
Using external DA instead would create a different security model, closer to a Validium. That is the motivation for the second architectural option discussed separately in this thread.
Any claim of economically viable throughput needs to be tested against CKB’s actual data capacity, transaction costs, canonicalisation rate and proof-verification budget.
Why I think this is worth exploring
The idea appeals to me partly because it does not require CKB to imitate Ethereum.
CKB would continue to do what its architecture is particularly well suited to: enforce precise state-transition constraints, establish ownership through live Cells, provide a common consensus history and verify programmes or proofs under CKB-VM.
The EVM can remain the EVM, with its own account state, execution rules and developer ecosystem.
Myelin would provide the off-chain machinery connecting those worlds, with strict boundaries between CKB-native execution, EVM execution and the evidence accepted at settlement.
There are plenty of unresolved questions.
A contested singleton sequencing Cell may be a poor throughput primitive under realistic CKB transaction-proposal conditions. An authenticated forced-inclusion queue is considerably harder to design than an ordinary off-chain mempool.
Efficient verification of historical batch prefixes also needs careful work. Proof verification costs, L1 data economics, bridge safety, prover liveness and emergency exits all deserve serious scrutiny.
I would be interested in challenges to these assumptions, especially from people familiar with CKB consensus, transaction dependencies and script verification.
The ambition is not to recreate Godwoken under a different name.
It is to investigate whether CKB’s PoW consensus and Cell model can provide canonical ordering for permissionlessly proposed EVM batches, without introducing a privileged L2 sequencing authority.
Transaction ordering within those batches would still require explicit rules, particularly around forced inclusion and censorship resistance.
The underlying research question is whether CKB can enforce a uniquely ordered, permissionlessly extensible and efficiently verifiable execution history, while allowing settlement to advance independently of sequencing.
If that can be established, the next question is how best to secure execution and data availability: through validity proofs or optimistic adjudication, with data published on CKB or an external network. The three options discussed here explore different trade-offs within that design space.
That seems a worthwhile direction for Myelin to explore.