CKB Sidechain Framework

CKB Sidechain Framework Proposal

by LeapDAO

The LeapDAO Team

The LeapDAO team has evolved through different stages over 4 years.

  • In 2017 members of the team built and launched Acebusters, a decentralized poker platform on Ethereum featuring multi-party state channels as scaling technology.
  • In 2018 a fraction of the team took the lessons learned from scaling blockchain games and launched ParsecLabs, receiving a first grant from the EF for layer-2 scaling research, and contributing the Plasma Leap dialect to the community.
  • In late 2018 LeapDAO forked off the previous team, and secured a grantee relationship with the incubator as well as a second grant by the EF, leading to the launch of the Leap Network in early 2019.
    Further achievements of 2019 can be seen here.
  • In early 2020 the team has adjusted its focus on generalized layer-2 solutions.

Today the team is a distributed collective that uses holacratic methods to organize. The organization’s purpose guides the team in decision making, and the following core values are shared by all:

  • running code over assumptions
  • self-management over hierarchy
  • rough consensus over voting
  • purpose over market cap
  • community over structure

LeapDAO uses a bounty system and Colony reputation to reward members. The Leap Token integrates different revenue models and provides governance influence for stakeholders.


Among others, reasons for spinning up a sidechain include the need to use experimental features, which are not available on the home network, faster and more inexpensive operations, or sovereignty, the ability to decouple the transaction pool from other use-cases and shield a decentralized app or business from gas storms (sudden flooding of block space with many transactions leading to delay or higher cost for inclusion) introduced by others.
The sidechain framework that we propose is composed of a blockchain framework, a token bridge implementation and a UDT platform. While in theory a bridge framework could connect any two chains, we want to provide simplicity for developers and startups to launch chains that extend on the security of the CKB PoW consensus and peg tokens between the chains securely.

Target Audience Flow

L1 plus L2 Scaling : Dex, Games

This integration is to facilitate tradable assets with security offered by CKB chain. In this integration L1 will be treated as a bank to safeguard the assets value while L2 is to allow free movement of such assets.

Developers will always create their tokens on L1 and create wrapper tokens on L2 which can easily be traded. This allows such assets to carry security of L1 on to L2 and facilitate L2 to L1 to another L2. Opens the possibility of intergame transfers and more.

L1 to L2 Scaling : Payments, Dex, Games

This integration will be targeting assets which would be used to facilitate payments. We anticipate that developers would create their tokens on L1 (CKB chain) and only move the tokens to L2 for faster transfer and confirmation times.

Cosmos did something similar to this(hardspooning) when they created ethermint. Essentially having a new chain which offers more functionality than what is readily available on L1.

This allows transfer of the tokens in L2 at lower costs and faster speed compared to the CKB chain. A user wishing to trade in the tokens would be assured of the security of tokens through an exit from L2 to L1 which will be responsible for verification.

L2 to L1 Ecosystem : Enterprise, Privacy, Prototyping

The integration allows any other external chains whether private or enterprise to use the L1 ecosystem. This facilitates use of features such as kyc and identity verification which are public and reside on CKB chain. Other useful integration products would be third party information sharing as well as tapping into liquidity pools on CKB chain.

L2 also acts as a faster entry to adoption of blockchain technology. Anyone looking to try out what blockchain tech has to offer would start at L2. Such users would then move to L1 for more security once they have familiarized with blockchain tech.

A brief overview of supported developer profiles and different features available in the sidechain framework & UDT platform.

Web3 Scaling - Developer with working solution looking to scale

  • CLI tool for both CKB and sidechain deployment
  • WebUI for sidechain admin and block explorer

Web3 Dev - Familiar with decentralized apps

  • SDK tools to interact with sidechain
  • CLI tools for deployment to CKB or sidechain
  • WebUI to facilitate CKB to sidechain migration

Web2 Dev - Developer looking to start on blockchain

  • WebUI to define UDT or ERC20 tokens
  • WebUI to mint and transfer UDT or

Product Owner - None coder looking to prototype

  • WebUI playground to setup marketplace or supplychain on CKB or sidechain or use both

Technical Specification

To cater to the needs of the different audiences and deliver a sidechain framework that integrates its security into CKB the specification is broken into 4 phases. The initial specification will describe a minimal PoA sidechain and a trusted bridge that can be delivered to the market quickly. Over 3 consecutive upgrades the sidechain will be transformed into a rollup, a trustfree scaling solution that allows teams to spin up sovereign environments that are fully anchored in the security delivered by the CKB PoW miners. For the rest of the document we will talk about CKB as the parent chain and the sidechain as a child chain.


3 roles are needed to operate a child chain in any phase of the development: trustees, validators and users.


The trustee role continuously audits the child chain and the bridges for correctness during the first 3 phases of the design. The trustee has the ability to halt the chain and has the final control over the stake of the validators.
The trustee can execute the following functions:

  • Halt the chain.
  • Set upper and lower bounds to single transaction values.
  • configure event offset, number of blocks to wait for before relaying any events from networks with probabilistic finality.
  • Set daily limits for single users.
  • Set daily limits for total contract volume.
  • Contract upgrades.
  • Sweep stuck funds.
  • Slash and unstake validators.

The trustee role consists of one or multiple signers, a committee, elected by CKB. While the trustee has to take action to actively audit and respond to errors in the first 3 phases of the proposed development roadmap, in the last phase all auditing tasks are decentralized and only need to be invoked in the bridge contracts by an honest observer.


The validators operate the child chain. Starting from phase 2 of the roadmap validators also stake funds to be able to receive a validator seat.
The validators have the following accountabilities:

  • Running the child chain service with high availability (> 99.99%)
  • Keeping their wallet address funded at any time on both networks.
  • Listening to Deposit and Burn events on both bridge contracts and responding with transactions on the opposite network (phase 1 and 2).

The validators have cost in hosting, operations and transaction fees. These fees are either absorbed through an external business model, or charged on fungible tokens trying to cross over the bridge.


Users have no special privileges other than depositing funds to initiate a transfer across the bridge. User accounts across networks are identified by the address, hence use by account contracts is not supported by the bridge yet.

Phase 1 - Trusted Bridge

A child chain is started with a single validator using a blockchain built on the Tendermint framework. Tendermint allows extending its p2p engine and BFT consensus with plugins through the ABCI interface. Ethermint is a plugin which allows to run EVM transactions on top of Tendermint, and will be used to provide a known execution environment and compatibility with Ethereum dev tooling for dapp developers. A custom bridge plugin will be added, giving the validator duties to observe the parent chain and relay events as transactions.

A bridge is deployed on the CKB chain taking the validator address as a parameter. The bridge cell will emit lock events whenever a user deposits tokens into the bridge. These events will be relayed by the validator as transactions. The bridge on the child chain will verify the signatures of relay transactions with a custom pre-compile against the keyset of the validators. If a relay transaction is accepted in the child bridge, a mint operation is executed, and a ERC20 representing the parent chain token is minted and transferred to the user address. Once a user initiates a burn transaction on the child chain the event is relayed by the validator to the parent chain bridge. An audit safety margin, in which the trustee can halt the bridge operations, needs to pass before the user can unlock an amount equal to the burned child chain tokens back on the parent chain.

Reorg safety margin - this is a parameter that can be configured in the bridge module for the child chain. It determines an off-set from the chaintip of the parent chain that transactions and events need to have before they are relayed. The margin enables the tracking of probabilistic chains by fast finality chains like tendermint.

Lock relay by validator. When locks are relayed from the parent chain to the bridge contract on the child chain, an authentication function is needed to secure the supply. A custom precompile will be introduced to the child chain EVM that allows to check a list of signatures against the set of validator addresses. If at least â…” of the current validator set has provided a signature, the precompile will return success, and fail otherwise.

Audit safety margin - this is a period of time after a burn event is relayed from the child chain to the parent chain. In this time period the trustee has time to audit the balances of the bridge, and stop a potentially fraudulent unlock.

Phase 2 - Staked Child Chain

This phase extends on the previous design by managing the genesis file for the child chain in a cell on CBK. The child chain node can be started by providing an RPC endpoint and cell address on the root chain. For the genesis configuration of the child chain to be valid, at least one validator needs to have staked funds into the bridge contract on the parent chain.

Anchors - an additional module has been created for the child chain which regularly anchors the child chain blocks in the parent chain. The module collects block data and in regular intervals submits the blocks as a single transaction into the parent chain bridge. The bridge parses the blocks, verifies the block-votes of the child chain validators, and stores the event root as well as the new state root in the bridge cell.

Burn transaction proof - once anchors of the child chain are present in the root chain bridge contract, proofs about events can be presented to the bridge, triggering events in a secure way. A proof of a burn event on the child chain can trigger an unlock of funds from the bridge. Anchors and proofs can be submitted without authentication, also by parties other than the validators. For example, if a validator would censor a burn event, the user itself could relay the anchor, and following that the burn proof referencing the anchor, by that unlocking its funds without the validator’s aid.

Slashing - being limited to halting the chain in the previous design, the trustee has now the option to penalize the validator for violations of the protocol, like double-signing blocks at the same height, invalid state transitions, or censorship of data.

Unstaking - once the chain is halted, either by violation or on protocol, the validator can unstake his funds.

Phase 3 - SPV Bridge

In this phase the child chain is extended with light client capabilities towards its parent chain. Together with the genesis data, the block headers of the parent chain initialize the bridge contract on the child chain.

Once the child chain starts operation, additional block headers are relayed to the child chain and the included proof of work verified. Given all block headers are relayed the child chain can now independently verify the valid tip of the parent chain. Together with the block header the transaction root is stored in the child chain bridge for each root chain block.

Reorg safety margin. Not all valid and relayed block headers are on the canonical parent chain. The probabilistic nature of PoW requires that the child chain bridge prunes forks of the parent chain, and only accepts a block header finalized once enough PoW has been piled onto it. Once the safety margin is cleared block headers can be used for proof verification.

Lock transaction proofs - can be used in reference to parent chain headers to prove locked funds and initiate token minting. Proof submission is open to any-one and users can relay block headers and and lock proofs independently, if they feel censored by the validators of the network.

Stake / unstake transactions - transactions that affect the validator set on the parent network can also be relayed to the child chain as proofs referencing the block header of their inclusion. Additional pre-compiles will be introduced so that the child chain bridge can modify the validator set.

Phase 4 - Rollup Chain

The rollup phase expands on the use of anchor data. The audit safety margin is replaced by a challenge duration during which functions on the bridge contract can be used to challenge state transitions that have occurred on the child chain. The bridge cell will need to support the verification of EVM transitions on-chain. Storage proofs of all touched fields will need to be provided with the challenge function call.

Halt. The child chain runs BFT consensus, yet transactions that have been accepted as valid on the child chain can be deemed invalid by the challenge functions on CKB. A conflict arises between the two chains that can not be resolved programmatically, as Tendermint’s BFT consensus offers no way to reverse finalized blocks. Hence, in a situation of successful state transition challenges the child chain will be stopped, and the stakes handed over to the trustees of the network to further investigate the incident.

With the introduction of the transition challenge functions the trustees are unburdened from continuously auditing the chain. A single honest observer assumption can be applied to the correctness of the network, hence the child chain is tightly integrated into the security and censorship resistance provided by the PoW miners of CKB.

Components and Modes of Integration

In addition to the Bridge Smart Contracts and the Bridge module the system is comprised of the following parts:

  • Bridge UI: a web application allowing users to transfer tokens between networks. An example implementation by the LeapDAO team can be found here:
  • Audit Module: a script for checking balances and comparing accounting across the networks. If balances run out of sync invalid state transitions and unprocessed events can be identified or bugs/attacks revealed. An example implementation by the LeapDAO team can be found here:
  • Documentation: a playbook on how to spin up a new child chain and connect tokens and contracts to the parent chain.

The first version of the sidechain will be EVM based and support both ERC20 and ERC721 tokens and later build on to have a sidechain that supports UDT. Depending on the chosen mode of interconnection a bridge can deliver the following integration:

  • CKB to Token: the native asset of the home network is linked to a defined token on the foreign network. When a transfer is initiated from the home network, the native asset is locked in the bridge and a token is minted on the foreign network. The reverse operation burns tokens and unlocks CKB. This is a common mode to equip a new sidechain with an asset that has already market value and can be used for payment or staking.
  • Token to Token: here a token used on the home network to be deposited into the bridge, which causes a linked token on the foreign network to be minted. The reverse operation is analog to the previous mode. This setup can be used for projects that want to launch a token on the home network before the sidechain is operational. This mode could also extend stablecoins to side chains that focus on payment networks.

UDT Token Development

Tokens used to capture value can be categorized as fungible or non-fungible. We will be seeking to ease the generation of such tokens through assistive tools.

Languages to be supported are Javascript, C and minimal assembly language.

Initial code scripts will be modelled after the Simple UDT, ERC20 and ERC721 to provide developers with various functions that can be incorporated in their UDT.


  • Access control off the UDT to be able to define ownership and conditions to carry out token functionalities. Through roles different functionalities such as minter, burner and admin can be made possible and allow different users to safeguard a UDT
  • Token transfer functionality. Owners of token can easily specify recipients of minted tokens and allow recipients of such tokens to transfer to other users.
  • Interface Script to allow users to explicitly give an identifier to their token for easier recognition in the ecosystem of usage and interactions. An upgrade path for backward compatible interface scripts

Tools to be provided are:-

  • No code, step by step web app that allows capture of token specific details. Initial version will allow developers to choose from a list of provided code scripts. Eventually allow them to upload their own scripts for evaluation. The web app will act as an abstraction to users who are not familiar with C code and want a quick easy way to test
  • CLI tool, tailored for developers who would like to extend provided scripts and customize further. Developers will have options to work with both C and Javascript versions of the code scripts.
  • UDT examples will include escrow contracts and rental property tokens.
  • Deployment to CKB main chain and support to known side chains will also be supported


We plan to deliver the grant in multiple milestones so that we can enable first teams to use a trusted bridge solution within a few months, then upgrade the codebase step-by-step into a trust free setup using CKB as the parent chain.

MVP Scope - Trusted Bridge :star2:

Sidechain Module: Review the Ethermint module available for tendermint. Enable full EVM support to run on top of tendermint consensus. Verify Web3 compatibility: In order enable developers to move applications over to the child chain existing tooling (i.e. web3 compatible clients) need to be able to interact with it.

Bridge Contracts: Write bridge contracts for CKB and child networks that enable the locking, minting, burning and unlocking of fungible tokens. Events need to be emitted. Permissions to halt the bridge for trustees need to be available on the parent chain.

Bridge Module: A custom bridge plugin will be added, giving the validator duties to observe the parent chain and relay events as transactions. The module needs to offer a reorg safety margin, a parameter that determines the off-set from the chaintip of the parent chain that transactions and events need to have before they are relayed.

Validator Pre-Compile: When the bridge contract on the child chain receives a relaid transaction, it needs to check the signatures to conform with the validator set. Ethereum does not offer the ability to query the validator set from the execution context of smart contracts. Hence a new pre-compile needs to be added that can verify a list of signatures against the current validator set.

Audit Module: In this phase of the project the parent chain does not monitor the child chain for correct execution yet. Hence the trustees will be required to run a script that constantly monitors the balances of bridges connected to CKB and halt withdrawals from the parent chain bridge automatically if any anomaly is detected.

Documentation: A documentation will be provided for users to launch a new network from a config file, deploy the bridges manually, and deposit first tokens into the child chain.

UDT Tools: Simple interfaces for fungible and non-fungible tokens on the CKB chain. Available repos for the standard interfaces available.

Milestone 2 - Staked Child Chain :star2:

Bridge Module v2: The functionality to relay burn events from the child chain to the parent chain is removed from the module. It will now be covered by the anchor module and the burn proof functionality without the need to trust validators.

Anchor Module: The anchor module can be used by validators or read-only nodes of the child chain. The module collects transactions from multiple blocks, together with the voting transactions by the validators and submits the data regularly as transactions to the bridge cell of the parent network.

Parent Chain Bridge Cell v2: The bridge cell on the parent chain receives multiple new features in this phase:

  1. The bridge cell on the parent contract is extended with the capability to collect stakes from potential validators. When a validator puts down a stake it is registered into the genesis config with a proportional voting weight.
  2. The bridge cell is also extended with a function to receive anchors of the child chain. The anchors are verified by height and validator vote signatures for correctness, then the event roots and state roots are stored in the bridge cell.
  3. The ability to relay burn transactions by validators is removed, and burn transaction proofs are introduced instead. Burn transaction proofs reference anchors that have passed the audit safety margin through merkle proofs. Hence, they can be relaid by any-one, also users exiting their own funds, and censorship by validators is circumvented.
  4. A slashing function is added to the bridge. On the sole discretion of the trustee committee the stake of validators can be slashed. Proofs for slashing should be documented in the history of anchors relayed into the bridge cell.
  5. An unstaking function allows validators to withdraw their funds. In this phase the function only becomes available after the chain is halted.

Config Module: The config for starting child chain validators is moved into a cell on the parent chain. This module enables a simpler configuration of validators by providing only the cell address and the RPC endpoint to the node. At least one validator needs to have staked funds into the bridge contract on the parent chain for the network to start. The config module also deploys a bridge contract on the child chain automatically once it is started.

Audit Module v2: The audit module is extended with the ability to follow the anchor submission into the parent chain bridge cell and verify state transitions between the anchors.

Bridge UI: a user interface for each bridge contract deployed on the home network. The bridge-ui allows users to connect popular wallets and provides the ability to transfer funds from the parent chain to the child chain and back.

UDT Tools: Web interface for creation and and deployment of tokens and binding across the bridge. Simple reusable token scripts that can be deployed both on CKB and on the child chain. A web UI and CLI will be provided to ease developer experience.

Milestone 3 - SPV Bridge :muscle:

Bridge Module v3: The functionality to relay lock events from the parent chain to the child chain will be replaced by SPV proofs. The module is not needed any more.

Config Module v2: The config module is extended with the functionality to set the block header from the parent chain in the child chain bridge contract at the start. This header will be the genesis header for later headers that will be relayed to the child chain.

Child Chain Bridge Contract v2: The bridge contract on the child chain receives multiple new features in this phase:

  1. The ability to verify block headers including the PoW from the parent chain is added. Consequently, any-one can relay block headers, the PoW is verified, and the header is added to the storage of the child chain. The contract becomes a light client to the parent network.
  2. Lock transaction proofs can now be relaid from the parent chain into the bridge contract. They need to reference block headers with a merkle proof to trigger a minting of tokens. A verified block header is not immediately eligible for lock proofs, but the reorg safety margin needs to pass and the block needs to be on the tip with the highest PoW accumulated to be valid.
  3. Validator set modification proofs can be relayed from the bridge cell of the parent network. This will modify the validator set of the child network.

Light Client Module: This module can be used by validators or read-only nodes of the child chain. The module relays block headers of the parent chain to the bridge contract of the child chain regularly.

Validator Pre-Compile v2: while the previous pre-compiles could only read out the validator set of the child chain, now a new instruction is added that can modify the validator set. The functions include:
Add a new validator with specific weight
Reduce the weight of an existing validator or completely remove it.

Bridge UI v2: an interface to configure a child chain is provided. A bridge contract is deployed on the parent chain, or an existing bridge contract can be imported. For each bridge contract validators have the option to stake and unstake funds. Bridge parameters are displayed.

Documentation v2: a playbook on how to spin up a new foreign network and connect tokens and contracts to the home network.

UDT Tools v2: Continued support and updates to existing UDT scripts and a token curated registry for UDT interfaces and lock scripts. Support for RISC-V assembly lang

Milestone 4 - Rollup Chain :rocket:

Parent Chain Bridge Cell v3: The bridge cell on the parent chain receives multiple new features in this phase:

  1. The bridge cell will receive the ability to verify EVM state transitions. This is a significant task that requires a virtual machine implementation to be compiled in a CKB cell. The execution of any code running on the child chain needs to be fully synchronized with the implementation on the parent chain.
  2. The bridge is extended with a function that allows to challenge a state transition between 2 submitted anchors.
  3. If a challenge of a state transition is successful, the child chain is halted automatically and the validators voting on the invalid state transition slashed. The remaining stakes are transferred to the trustee committee. Since phase 4 the trustee role is reduced to decide the fate of the network in such halts.

Audit Module: The audit module is discontinued, as the correct operation of the child chain and bridge can be guaranteed through the state-transition-challenge-function in the bridge cell.

Bridge UI v3: support for transfer of non-fungible tokens and arbitrary message passing across the bridge.

Documentation v2: the playbook is extended with validator staking documentation and instructions to transfer non-fungible tokens.

Further Development and Unknown Scope

Providing option of cell model sidechain through muta framework. We would be in touch with the Muta dev team and this will mainly be an Exploration scope. It may have its own separate roadmap and not necessarily delivered within the scope of the current sidechain framework.


Does that mean that the side chain on ckb could be the same with cosmos due to the same framwork?

btw I like your swag!

Not the same as cosmos, rather built on top of cosmos sdk. We will be working with a fork of

Mwaa Joseph ( > (twitter, github)) is a blockchain developer from LeapDao team in Kenya, Africa.In this issue, he shared his experience working in a DAO (decentralized autonomous organization).

Where are you based and what’s the local crypto community look like?

Mwaa: I am based in Kenya the heart of East Africa. The crypto community is actively growing each year. There are a few established blockchain accelerators that have promoted more talks and short courses for wider community. Government is actively supporting non-crypto blockchain solutions and this year we had 2 blockchain companies accepted to the regulatory sandbox. I would say community is still pretty much developer composed, ideally 40% developers, 30% traders and rest mainly businesses.

When and how did you get into crypto?

Mwaa: My background is mainly web-development, using Laravel (Php) + Vue (Js), and I am an active contributor to the laravel community. Got introduced to bitcoin back in 2012 but only dove into crypto space in 2016 during the launch of Maid Safe. I felt that the safe network offered a platform that resonated with my projects at that time on digital identities and safe guarding them. Over the years got to explore different blockchain technologies such as EOS only to fallback to EVM because of the maturity in the ecosystem.

What’s the most interesting thing about blockchain that make you wanted to work in the sector? Anything you dislike?

Mwaa: I got interested in blockchain because of data immutability. Simply the ability to get rid of man in the middle processes is attractive in that it saves on costs and time. Like a service provider getting full payment amount for their services without extra bank fees.

I dislike that tokens and token economics have come to overshadow much of the functionality that blockchain space can offer. Not to mention a few bad projects that create scam tokens.

What blockchain use scenario are you especially looking forward to see?

Mwaa: Super interested in end-to-end supply chains. Not the huge volumes that some projects will boast about. Rather tracing the full path of item from factory to consumer. Like members of a grassroots community choosing to save costs pay a factory directly for goods. Storage and transport become add-on services for those interested.

The DAO Life

LeapDAO is an open community operating on Holacracy. How do you guys work together and what are the advantages and disadvantages of this mode compare to the traditional corporate system?

Mwaa: LeapDAO has been a wonderful discovery for me this year: it is very different from other teams in so many ways. Its openness in information sharing and operations drew me in to be part of the DAO. In its simplest form, Holacracy means there is no one boss or hierarchical structure of managers . Each member is driven to take up roles that benefit the DAO as a whole and are answerable to themselves. This promotes a sense of passion in the team and you get to shape direction of your interests based on the roles you hold. Its always exciting to listen in on calls from the more experienced members and get to hear about different passions.

The DAO is open to anyone who shares a common interest in scaling technologies and the work we do. Team is pretty much self-driven and you get to interact with different people who champion different technologies every day.

So, everything is based on bounties?

Mwaa: Yes bounties are the norm when it comes to assigning rewards. The bounties are open to everyone and once in a while you would see external developers who contributed to such bounties become members of the DAO. There is more teamwork in the bounty system than you would think. Each bounty requires 3 roles.

Bounties of LeapDAO

  • Gardener — does research and is responsible of ensuring the bounty contains all the necessary details before its available to be worked on
  • Worker — responsible for implementation
  • Reviewer — reviews the submission of the worker to be in line with task details

All great projects start with a passionate member who makes a pitch about the project to DAO for resource allocation. Once approved project gets a roadmap and any member of the DAO can take on the role of gardener to propose bounties that fall in-line with the projects road map. Bounties are subjected to approval process where members can object to them if tasks don’t align with project requirements. This ensures proper utilization of resources as expected from any team

LeapDAO has around 120 people with active daily members at 24 and 19 are programmers.

Can you give us an example of how to start a project in LeapDao?

Mwaa: Recently we received a grant from Nervos Foundation for building a layer 2 framework. Johann is the co-author of the grant proposal. He introduced the team to Nervos at the beginning of the year and built the general interest around the Nervos Positioning Paper.

Nervos UTXO model shares a lot of similarity with LeapDAO’s implementation of Plasma. This created interest in evaluation of what could have been done better on the plasma network and what Nervos had to offer. This comparison solidified the interest within the team where Nervos’ type script = bytecode in the first input of a spending condition for the plasma network.

The integration of the NervosDAO directly into the Nervos Network was interesting. If DeFI solutions such as using secondary issuance of CKB tokens from NervosDAO as one of the incentives for validators of the sidechain, this could be integrated directly into the network then the possibilities for Nervos Network must be vast.

I remember we did several call discussions before choosing Off-chain Scaling through Layer 2 as the what we wanted to focus on.

Plasma Group just stop studying and developing on Plasma earlier this year. Do you still focus on Plasma and what do you think of Plasma and why it seems to be failed?

Mwaa: Plasma has design weaknesses, either it has a mass-exit vulnerability, or the tokens are not fungible. Both can not be overcome at the same time.

Still plasma scales much better than any other technique (state channels, rollups). It is the right technology for a niche market where a lot of scalability is needed, and fungibility or passive security can be sacrificed. Plasma is not dead, but it is only suited for few specialized use cases.

We are adopting agile practice of ensuring each phase still delivers a functional side-chain on CKB:

  • Phase 1 fully functional side-chain but trustee controlled.
  • Phase 2 introduces validator staking.
  • Phase 3 transaction proofs relay between main and side-chain.
  • Phase 4 full synchronization of transactions between side-chain and main chain.

Each phase improves on the functionality into making side-chain more decentralized friendly from the control of trustee in phase 1 to none in phase 4.

In the last phase, it would evolved to a Rollup Chain, as far as I know Rollup mainly have two direction, ZK Rollup and Optimistic Rollup, which one do you choice?

Mwaa: Optimistic Rollup. The good thing about the space is that technologies always improve and there is no one way of doing things.

Is the sidechain framework based on UTXO model or account model? So at first those tokens created on child chain were still based on ERC20 and ERC721, why would you choice this way? Is there any benefits?

Mwaa: Account Model. UTXO model can and will be an improvement later on. Give the more options once the ecosystem grows a bit around Nervos. At present its to ensure compatibility with EVM. Maintain entry criteria to be same as EVM.

LeapDAO will also develop an assistive tools to deal with all tokens? The mix of ERC tokens and UDT token would bring some trouble to you or it would bring something new? Like those DApps or DeFis on Ethereum would be more easily to transfer to CKB or its UDTs?

Mwaa: I’m excited about this section especially the structure of UDT token. We will be exploring functionalities such as an interface of ERC20 token been stored on the UDT token. UDT coming with in-built support side chain token ensuring minted tokens on sidechain framework is always compatible to UDT.

What’s the difference between Nervos’ Layer2 and Ethereum’s Layer2, especially on the sidechain part?

Mwaa: Nervos Layer2 borrows a lot of security of layer1 by having more integration points into layer1 with out creating more transaction overhead as would occur on Ethereum.

What do you think is the biggest challenge to develop on CKB right now? and what is the biggest challenge for LeapDAO to build sidechain on CKB?

Mwaa: Biggest challenge I would say is the learning curve for the technology stack used in CKB. Learning content is still minimal and little reference material. This been a challenge, I love how the core dev team is actively looking to provide tools and support for language familiarity to wider dev community.

For LeapDAO challenge is unlearning Ethereum and adopting a new way of think for CKB related work. CKB is more like bitcoin and has many differences with Ethereum.

:t_rex: :panda_face: :t_rex: :panda_face: :t_rex: :panda_face:
Interview conducted by @stwith and was published on Syncing Nodes.


Does this sidechain framework aim at providing more heterogeneous chains, or only for speeding up txs? Nervos itself is already working on PCN–are sidechains really necessary?

We’re working with the community on channel networks, commit chains, rollups and sidechains at the same time :slight_smile: Unlike layer 1, layer 2 will be a heterogeneous network, a mixture of different protocols and sub-networks. Channels and chains will play distinct roles on layer 2 as they have different properties.


I see. Thanks for the explanation.