Understanding Nervos’s Multi-Chain Solutions

NervosGuides & Tutorials, Learning Resources

As we’re actively ramping up the development of our multi-chain solutions this Autumn, through a $200,000 prize-pool Bounties and Hackathon with Gitcoin, beta testing of a new Dex called Yokai, and launching some of our multi-chain solutions, it is probably a good time to explain these solutions further. 

At the heart of Nervos is a group of tools, or multi-chain solutions, aimed at creating Universal Applications which are apps that transcend individual blockchains to work seamlessly across every blockchain in the ecosystem.

Polyjuice, an Ethereum Virtual Machine (EVM) compatible layer running on top of CKB that enables the deployment of any Ethereum dApp on the network. 

Godwoken, a framework to build rollups, which are scaling solutions that perform transactions outside a layer 1 blockchain such as Ethereum or Nervos, and trustlessly verify their executions on the base layer protocols. 

As well as our Layer 1 cross-chain bridge.

Force Bridge, a cross-chain bridge that connects Nervos to other chains, making it easier for Ethereum developers to expand their dApps and user base to the Nervos ecosystem. 

In this article we will take a deeper, more technical look at how these tools work, and what we are trying to achieve with them towards a multi-chain environment powered by Universal Apps.

Godwoken: a Permissionless Rollup Framework

Many scaling solutions exist now in the blockchain world. There are payment channels, rollups, state channels, and plasma, just to name a few.

At Nervos we have the ambition to support all of them, but practically, we have to start with one. Amongst existing solutions, rollup stands out as the most promising, with the least amount of quirks. As a result, we have begun our journey from rollup. Later we shall also see, due to CKB’s unique design, rollup plays an even bigger role than just putting TPS on steroids. Based on almost a year’s research, design and implementation, we have now released the initial public version of Godwoken, our permissionless rollup framework.

Initial public version of Godwoken

Godwoken works by having a set of aggregator nodes collect specially designed layer 2 transactions, then pack them into a CKB transaction, which they submit to layer 1 CKB for acceptance. In this sense, Godwoken truly works in a layer 2 fashion:

Special Godwoken aggregator nodes are running in addition to CKB nodes

  • A specially designed layer 2 transaction format is used instead of CKB’s transaction format
  • A special CKB transaction is submitted by Godwoken nodes, which can also be viewed as layer 2 blocks

Despite being a layer 2 solution, one important design rationale behind Godwoken is that we are building a permissionless layer 2 solution:

  • Layer 2 transactions incentivize aggregator nodes with transaction fees, much like what the layer 1 blockchain provides.
  • Multiple individual Godwoken deployments are possible on Nervos CKB. Each deployment is free to make their own choices. If one deployment does not satisfy you, you are free to switch to a different one, or even start your own one.
  • Though some deployments might create additional restrictions, the core of Godwoken is designed so that everyone is able to submit a block to the layer 2 blockchain, making it scale like a real permissionless layer 1 blockchains.

To show more about the internals of Godwoken, we will publish a different article titled Life Of A Godwoken Transaction soon, where we will cover more details of Godwoken’s design and implementation.

It is worth mentioning here that we are only releasing the first version of Godwoken, which is limited to the following design choices:

  1. An Optimistic Rollup based design will be used
  2. A Proof-of-Authority mechanism controls layer 2 block issuance

We will continue enhancing Godwoken with more features, which will include:

  1. A true Proof-of-Stake based mechanism for block issuance coordination
  2. A ZK Rollup based setup
  3. and more!

Lately, we have been surprised and happy to find out that rollup is also quickly gaining popularity in the blockchain world. We are humbled to be standing upon the shoulders of giants and are inspired to deliver more diligent work here, hoping to innovate on others’ as well.

Having a rollup framework, however, only solves half of the problem. A solution that can only send naive token transfers won’t be very helpful. In a competitive and ever-growing blockchain space, a smart contract solution is often needed to unlock more potential. To address this other half of the problem, we also built Polyjuice, which will harmoniously accompany Godwoken.

Polyjuice: a 100% EVM-compatible Ethereum on CKB Solution

Polyjuice is an Ethereum on CKB solution, which means one should be able to port their existing dApps running on Ethereum to CKB with minimal effort. One design goal of Polyjuice is being 100%, or even 120% compatible with EVM, which means:

  • Any Solidity based smart contract running on Ethereum today should be able to run on Polyjuice
  • Polyjuice can even ship more features that might not be implemented in Ethereum today. If there is an EIP you desperately need today, maybe Polyjuice can implement it to aid your dApps.

Note the compatibility design only applies to the EVM, Ethereum also has supporting RPCs, with which an application communicates with the chain. Unfortunately, we cannot promise full compatibility with respect to RPCs, due to different designs between Polyjuice and Ethereum. This means your existing Ethereum dApps will need some work before they can be deployed to Polyjuice.

We will however make sure a) smart contracts need no changes; b) the 2 sets of RPCs resemble each other. We will also work to clearly document the differences. This way, porting effort shall be reduced to as minimal as possible. Integrations with pw-wallet will also be built, so a seamless experience can be expected from the end-user side.

You might have noticed that we already launched Polyjuice in July. The reason we are mentioning it again is that we have completely reviewed and overhauled Polyjuice to fix its biggest problem: handling shared state.

To demonstrate shared state, assume one has deployed an Ethereum smart contract to Polyjuice. In our previous model, one will create such a cell:

A deployed Ethereum smart contract to Polyjuice

To call this smart contract, one would necessarily create a CKB transaction that consumes this contract cell and create a new contract cell.

Transaction 1 and Transaction 2 in Ethereum smart contract to Polyjuice

This is where the problem arises: when multiple users call the same smart contract, they will all need to consume and re-create the contract cell. Effectively they are competing for the shared contract state cell. In most cases, users would not know the transactions being created by others; each of them would create a transaction using the most recent live contract state cell on chain.

This will result in multiple transactions consuming the same contract state cell, a miner will then have to pick one transaction, which will render all the other transactions invalid. This is a consequence of the cell-based model selected for CKB, but it is not necessarily a disadvantage:

  • There are many more cases where a single shared state is not necessary. sUDT is one such example. For these cases, the cell-based model provides improvements such as increased scalability, and determinism.
  • Even in cases where a shared state is inevitable (such as voting apps, or AMM), solutions exist to solve the problem:

For many cases, simple retry logic can be leveraged: one can create a rule saying “as long as the transaction contains input 1 and output 1 & 2, I don’t care what input 0 is, just sign and send the transaction”. A timeout such as a 10 minute window can also be attached to the rule. For relatively lower volume dApps, such as a voting app, this would be good enough.

Some cases have other requirements, such as higher TPS requirements, which would make retry logic infeasible. Rollup provides a different answer here. By architecting Polyjuice on top of Godwoken, each individual Polyjuice transaction can just be a layer 2 Godwoken transaction. The shared state problem is thus avoided, since only the packed Godwoken CKB transaction will then consume the contract state cell, and re-create an updated one.

Here Godwoken and Polyjuice complement each other: Polyjuice provides a way to inject custom logic into Godwoken’s rollup solution, Godwoken solves Polyjuice’s shared state problem, while also providing higher TPS potential. We hope that the combination of Godwoken and Polyjuice can help shed some light on layered dApp designs in the Nervos CKB wonderland.

It is worth pointing out that Polyjuice is not the only VM solution for Godwoken. One can also integrate other VMs with Godwoken, providing different ways of building dApps. For example, a pure JavaScript VM is totally possible, so one can just write plain JavaScript in a blockchain, or as a more ambitious goal, Libra on CKB is also totally achievable with the help of Godwoken.

Force Bridge (ETH)

Force bridge is a bridge which connects CKB with other blockchain systems( aka cross-chain protocol).

Force-Bridge-ETH is the Ethereum component. Messages consist of transactions, events and states on Ethereum can be transferred to CKB. In reverse, messages about transactions on CKB can be transferred to Ethereum.

In other words, dapps on two sides can interoperate with each other based on force-bridge-eth.

In the remaining part of this document, we will refer to force-bridge-eth as force bridge for simplification.

Design

Cross-chain refers to the credible communication between blockchains. Generally, cross-chain protocols need solve two problems:

The credibility of cross-chain messages, that is, the authenticity of the message can be verified.

The comprehensibility of cross-chain messages, that is, messages can be decoded by another party.

For the first problem, force bridge maintains light clients in smart contracts on both chains and uses light clients to verify that transactions or events did happen on the counter party chain. The concept of an on-chain light client is similar to a lightweight node on BTC. And we use a mechanism called SPV ( Simplified Payment Verification) to accomplish the verification.

At the first stage, force bridge will maintain the light client in a multi-signature notary scheme. A committee consists of Nervos Foundation and the community members will submit headers to the light client, along with their signature.

At the second stage, the Force will replace the multi-sig-light-client with consensus-based-light-client. It will be a fully decentralized way. Everyone can submit headers. The contract will verify the header with the consensus algorithm of the chain.

For the second problem, CKB uses molecule for serialization and blake2b for hashing, corresponding to rlp and keccak256 on Ethereum. So we developed molecule and blake2b library on Ethereum to decode messages from CKB, rlp and keccak256 library on CKB to decode messages from Ethereum.

Thereafter, we can transfer messages between CKB and Ethereum.

Ethereum to CKB

The Ethereum header contains state/transaction/receipt root, so messages of these three kinds can be transferred and verified.

Take assets transfer as an example:

  1. We can lock ETH/ERC20 token in an asset bridge contract with events emitted on Ethereum.
  2. Then transfer the receipt message to CKB, that is to say, construct a CKB transaction with receipt and merkle proof as witness.
  3. The constructed CKB transaction will mint a mirror asset after verifying the message by the Ethereum client.

CKB to Ethereum

The CKB header contains transaction merkle root, so messages of CKB transactions can be transferred and verified.

Take assets transfer as an example:

  1. We can burn SUDT ( Simple User Defined Token ) on CKB.
  2. Then transfer the transaction message to Ethereum, that is to say, call unlock method of the asset bridge contract with transaction data and merkle proof.
  3. The asset bridge contract will unlock the correct asset after verifying the message by CKB client.

Architecture

architecture

Force-bridge-eth will support assets transfer natively, the system consists of on-chain contracts and off-chain components.

On-chain:

  • Ethereum contracts ( solidity )
    • CKB light client
    • cross-chain contract
      • asset-bridge: supports lock/unlock asset features
  • ckb contracts ( rust )
    • Ethereum light client
    • cross-chain contract
      • asset-bridge: supports mint/burn asset features
        • bridge-lockscript: supports mint asset feature
        • recipient-typescript, supports burn asset feature

Off-chain:

  • bridge lib ( rust )
    • construct force-bridge-eth related transactions to ckb and ethereum
    • construct cross-chain message proof
    • common structures and functions
  • bridge cli ( rust )
    • depends on bridge lib
    • used by developers to do [deploy, test, bridge actions]
  • bridge web ( frontend: js, backend: rust )
    • depends on bridge lib
    • used by users to do asset bridge actions
  • multi-sig-server ( rust )
    • depends on bridge lib
    • used by signers to maintain ckb/ethereum clients

Features

Security. The version 2.0 of force bridge will be a fully decentralized, permissionless bridge between CKB and Ethereum. Force bridge is secure as long as the majority (1/2) of Ethereum mining power and majority (1/2) of CKB mining power is honest. There are no additional security requirements. The whole cross chain process can be performed by anyone.

Extendability. Due to the low level abstraction of CKB script programming and flexible architecture of force bridge, it will be easy to extend its ability.

  • The asset bridge we already implemented will support ETH and all ERC20 tokens natively. In most solutions, you have to deploy a new asset on the target chain, register the address on Ethereum, and specify the relationship between them before you can move your asset. In force bridge, you can move your asset right after you deployed the ERC20 contract. You will get the associated mirror token automatically.
  • Move your asset to a user or to a dapp is the same thing for force bridge. As we will show in the DEX demo, users can place an order with ETH to buy CKB in a single step, instead of locking the asset on ETH and then placing order on CKB. As long as the dapp follows some specific pattern, the dapp and bridge can be integrated without any changes of bridge.
  • In the future version of force bridge, we may reuse the existing components to support new cross chain situation, e.g. ERC721. The eth light client on CKB can verify that a transaction or event did happened on Ethereum. Developers can write handler dapps on CKB to extend the ability as they want.

User experience and broader interoperability. For a typical cross chain process, users have to maintain at least one account on each chain with associated wallet. In force bridge, users can reuse existing tools and participate in the CKB ecosystem without learning new concepts. You can use an Ethereum wallet (e.g. Metamask) to do the cross chain, manage your assets and interact with DeFi on CKB. In the future, we will support connecting to other blockchain systems. Users from different chains may use their own wallet to trade in the same liquid pool on CKB.


To stay updated on all things Nervos:

Join our community: Discord — Github — Nervos Talk Forum — Twitter

For discussions or questions join the conversation on Discord or check out one of our community Telegram channels: EnglishKoreanRussianJapaneseSpanishVietnamese and Chinese