Blockchain LEGO of CKB style: Polyjuice on godwood


​​Blockchain LEGO of CKB style: Polyjuice on godwood
Before studying godtoken, Polyjuice or other blockchain related things, let’s start from the pastStory of database fieldStart talking.

Decades ago, people needed better tools to organize data, so SQL database( )Came into being. Acid attribute( )Is designed so that data can be safely written and read years after its original creation. At that time, a database only served a limited number of people, and one machine (mainframe, or later powerful microcomputer) was enough to support a database.

Gradually, computers began to popularize, and the explosive development of the Internet accelerated this process. Soon, a single machine has been unable to provide due support for the database, so the distributed database began to appear. However,Cap theoremThe discovery of (only two can be selected from the three characteristics of consistency, availability and partition fault tolerance) has brought great challenges to software engineers,They are forced to choose between CP and AP databases。 For ease of reference, we use a simple (although unilateral) method to distinguish between CP database and AP database:

  • CP database ensures the global consistent view of the whole distributed system;
  • The AP database may provide different views for different logical parts or partitions.

Blockchain LEGO of CKB style: Polyjuice on godwood
AP database, source:… Database, source:

From dynamodb of Amazon to the vigorous development of mongodb, AP database has attracted extensive attention for some time. People everywhere are shouting:“NoSQL is the future! SQL is an outdated thing.”At that time, many people did choose NoSQL solution to build their own applications. At that time, it seemed that the future solution of database was indeed partitioned.

But the story is not over. A few years later, the defects of AP database began to surface:When people design system architecture, different views from different partitions do affect people’s decisions

For example, suppose you are a developer based on a traditional SQL database. You only need to care about the logical tables and the connections between them. Occasionally, you may need more performance queries, but your data is always in order. However, in the AP database, you are only equipped with key value (kV) storage or document storage. We must first design patterns, but on this basis, you must deal with inconsistent writes in different partitions of the database. This greatly increases the workload of application developers, and in many cases, it will also lead to chaotic data storage.

Even though dynamodb, the CP database solution, has been launched and used so far, the traditional SQL database is still widely used by people. Dynamodb will be widely adopted only under special circumstances, such as the special merge function in shopping cart logic. For most applications that daily developers are building, AP database is difficult to be a good choice.

Now let’s take a look at the hot topics discussed today:NewSQL, it maintains the acid attribute of the original SQL model and is popularized as a substitute for NoSQL in most use cases. Due to the design requirements, most or all of the solutions of newsql are based on the CP model:

  • Google SpannerIt is Google’s future oriented and global database. It follows the CP design and aims to provide a better alternative to AP based BigTable;
  • CockroachDBandTiDBAre modern open source distributed SQL databases built based on CP model;
  • CitusDB, a typical extensible database based on PostgreSQL is also built based on CP model.

There are still many examples, but the trend is obvious: developers are eager to improve productivity through CP system. History tilted to AP for a short time, but due to the friendliness of CP to developers, people finally returned to the path of CP.

From this story, we can see that,Developers will eventually choose tools that make them more efficient

Now you might think:This is a long story, but what does it have to do with blockchain?

In nervos, we firmly believe in layered solutions. This is always the result of our careful consideration, which is based on our rich experience in the software industry. Layering gives us a way to set boundaries, encapsulate complexity, and provide assumptions.

Many things in our industry are based on layered architecture: network stack, compiler infrastructure, CPU architecture, etc. there are countless examples. In this industry and many other industries created by human beings, we can see that some layers hide details during construction and provide support for the upper layer at the same time.

Even for those who think blockchain is a new technology, the use of layers shows obvious differences:

  • In a layered network, the core blockchain ensures the global consistency of its transactions;
  • The design of block chain provides different pieces, and each piece can work independently.

See here, do you have a familiar feeling? If you think about it carefully, is blockchain very similar to distributed database! Although there are great differences, in our opinion, the discussion on layering and slicing is similar to our discussion on CP and AP databases in the past 10 years:In the hierarchical blockchain, you group the upper blockchain according to the logical function to minimize the demand for cross chain communication; In the sub area block chain, cross chain communication is the basis of expansion requirements, which can not be avoided.

Over time, we believe that layering will bring more obvious benefits to all DAPP developers, just like the rise of newsql database.

Many people always want to know what the layer 2 solution on CKB will look like, so today, we are here to introduce you to two complementary projects:

  • Initial version of godtoken:
  • Comprehensive update of Polyjuice:

Godtoken: rollup framework without license

There are many expansion schemes in the blockchain world. There are payment channels, rollup, status channels, plasma, etc.

On nervos, we can fully support all these schemes, but in fact, we must start with one scheme. Among the existing solutions, rollup is the best and flawless. So,We started our journey from rollup。 We will see later that due to the unique design of CKB, rollup is more meaningful than the steroid like scheme of simply improving TPS. Based on nearly a year of research, design and implementation, we have released the initial version of godtoken, that is, our unlicensed rollup framework.
Blockchain LEGO of CKB style: Polyjuice on godwood

Godtoken works through a set ofaggregatorThe node collects specially designed layer 2 transactions, then packages them into CKB transactions and submits them to layer 1 CKB for reception. In this sense, godtoken does work in the way of layer 2:

  • In addition to the CKB node, a special godtoken aggregator node is running
  • The specially designed layer 2 transaction format is adopted to replace the transaction format of CKB
  • A special CKB transaction submitted by godtoken node can also be regarded as layer 2 block

Although it is a layer 2 solution, an important design concept behind godtoken is that we are building aNo license requiredLayer 2 solution.

  • As provided by layer 1 blockchain, layer 2 transactions use transaction costs to motivate aggregator nodes;
  • Multiple separate godwatches can be performed on the nervos CKBdeploy。 Each deployment is free to make its own choices. If one deployment cannot meet your requirements, you can freely switch to another deployment, or even start your own deployment;

Although some deployments may impose additional restrictions, godtoken’s core design is to enable everyone to submit blocks to the layer 2 blockchain to expand like a real layer 1 blockchain without license.

(in order to show more internal information about godtoken, we will publish an article entitled “life of a godtoken transaction” in the near future, in which we will introduce more details about the design and implementation of godtoken.)

It is worth mentioning that we have only released the first version of godtoken, which is limited to the following design options:

  • An optimal rollup based design will be used;
  • The release of layer 2 blocks is controlled through proof of authority.

We will continue to add more features to godtoken, including:

  • A real block issuance coordination mechanism based on proof of stack
  • ZK rollup based settings
  • And more!

Recently, we were pleasantly surprised to find that rollup is rapidly becoming popular in the blockchain world( )。 We are honored to stand on the shoulders of giants, and very much hope to do better work in this field. We also hope to stand on the shoulders of others and make innovations.

However, using the rollup framework can only solve half the problem.A solution that can only send native token transfers will not solve all the problems after all. In the highly competitive and growing blockchain field, a smart contract solution is often needed to release more potential. In order to solve the problem of the other half, we also built Polyjuice, which will complement godtoken.

Polyjuice: 100% EVM compatible Ethereum solution on CKB

Polyjuice is an Ethereum solution on CKB, which means that people can migrate their existing dapps running on Ethereum to CKB with minimal changes. Polyjuice is designed to be 100% or even 120% compatible with EVM, which means:

  • Any solid based smart contract running on Ethereum can run on Polyjuice;
  • Polyjuice can even provide more functions that cannot be realized on Ethereum today. For example, you urgently need an EIP, and Polyjuice can implement it to assist your DAPP;

It should be noted that the compatibility design is only applicable to EVM, Ethereum also supports RPC, and applications can communicate with the chain through RPC. Unfortunately, due to the different design between Polyjuice and Ethereum, we cannot guarantee full compatibility with RPC. This means that you need to do some work before deploying your existing Ethereum DAPP to Polyjuice.

However, we will ensure that

a) Smart contracts do not need to be changed;
b) The two sets of RPCs are similar to each other.

We will clearly record these differences. In this way, the migration work will be reduced as much as possible. We will also build integration with the portal wallet so that end users can have a seamless experience.

We launched Polyjuice in July 2020. We mentioned it again because we conducted a comprehensive review and overhaul of Polyjuice and fixed its biggest problems:Process shared state

To demonstrate the sharing state, we assume that the developer has deployed an Ethereum smart contract to Polyjuice. In our previous model, people created such a cell:
Blockchain LEGO of CKB style: Polyjuice on godwood
To invoke this smart contract, you must create a CKB transaction, consume the contract cell and create a new contract cell.

Blockchain LEGO of CKB style: Polyjuice on godwood
This is the problem: when multiple users call the same smart contract, they all need to consume and recreate the contract cell. In fact, they are competing for a shared contract state cell. In most cases, the user will not know the transaction being created by others; Each of them creates a transaction using the latest real-time contract status cell on the chain.

This will cause multiple transactions to consume the same contract state cell, and miners have to choose one transaction, which will invalidate all other transactions. This is the result of CKB’s selection based on the cell model, but it is not necessarily a disadvantage:

  • There are many cases where a single shared state is not required. Sudt is an example. For these cases, the cell-based model provides improvements, such as improving scalability and certainty;
  • Even when the sharing state is unavoidable (such as voting application or AMM), there are solutions:

In many cases, simple retry logic can be used: a rule can be created that “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”. You can also attach a timeout to the rule, such as a 10 minute window. For relatively small dapps, such as voting applications, this is enough.

If there are other requirements in some cases, such as higher TPS requirements, the retry logic is not feasible. Rollup provides a different solution here. By building Polyjuice on godtoken, each individual Polyjuice transaction can be just a godtoken transaction of layer 2. This avoids the sharing status problem, because only the packaged godtoken CKB transaction will consume the contract status cell and recreate an updated status cell.

Here, godtoken and Polyjuice are complementary:Polyjuice provides a rollup solution that injects custom logic into godtoken. Godtoken solves the problem of shared state of Polyjuice and provides higher TPS potential.We hope that the combination of godtoken and Polyjuice can inspire the layered DAPP design in nervos CKB Wonderland.

It is worth noting that Polyjuice is not godtoken’s only virtual machine solution. We can also integrate other virtual machines with godtoken to provide different DAPP construction methods. For example, a pure JavaScript virtual machine( )It can be completely implemented, so we just need to write it directly in JavaScript in the blockchain. Or as a more ambitious goal, with the help of godtoken, Diem on CKB( )It can also be achieved.

(to further explain the internal structure of Polyjuice, we will also publish another article entitled life of a Polyjuice transaction in the near future.)

Looking ahead

In nervos, we want to cater to two different developer groups:

  • For busy application developers, we hope to provide a one-stop solution so that they can directly use the layer 2 EVM driven blockchain to publish anything they want. For example, if we tell you, uniswap( )With only a few adjustments, you can deploy to CKB. What will happen?
  • For more adventurous people, CKB provides the perfect LEGO style parts that you can disassemble and reassemble yourself.

    • Don’t like writing smart contracts through solidity? Why not build your own virtual machine on godtoken to implement a different rollup chain?
    • Optimal rollup sounds boring? You can take it out at will and replace it with a more challenging part, such as ZK rollup.
    • The mechanism of Poa is like a time bomb to you? Then delete it and use your own POS or even POW scheme.

In short, we hope that this new layer 2 godtoken / Polyjuice will be deployed on CKB, It can be similar to the car you may be used to: you can buy it from the dealer and drive it away (original factory), or you can open it and install a turbocharger to get more power. We are ready, and you will eventually be surprised by all the modifications of your new “car”.

Fan welfare activities

  • Activity rules:

    • Pay attention to the official number of nervos – “nervosnetwork”;
    • Leave a message in the comment area of this article and write down some views on this article;

  • Activity rewards:

    • We will select 1 ~ 5 wonderful comments from the comments area, and each person will get a coffee token that can be exchanged for Starbucks coffee (exchange details can be stamped here).

  • matters needing attention:

    • You can only receive one reward at the same address;
    • If cheating is found in the activity, its participation qualification will be cancelled.
  • Activity time:

    2021/1/21 12:30 – 2021/1/23 18:00

//If you like nervos and like development
//You can pay attention to me and trust me privately~
if (you like Nervos && you like dev) {
    println("you can follow me and private letter for me~");

Blockchain LEGO of CKB style: Polyjuice on godwood