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 Status.im 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.
Justification
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.
Roles
3 roles are needed to operate a child chain in any phase of the development: trustees, validators and users.
Trustees
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.
Validators
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
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: https://testnet.leapdao.org/wallet
- 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: https://testnet.leapdao.org/status
- 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.
Functionalities:-
- 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
Milestones
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 
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
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:
- 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.
- 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.
- 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.
- 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.
- 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 
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:
- 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.
- 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.
- 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 
Parent Chain Bridge Cell v3: The bridge cell on the parent chain receives multiple new features in this phase:
- 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.
- The bridge is extended with a function that allows to challenge a state transition between 2 submitted anchors.
- 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.
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.