Before we look at Godwoken, Polyjuice, or anything related to blockchains, let’s start with a story from the past, in the field of databases.

Decades ago, the SQL database was born out of the requirement for a better tool to organize data. ACID properties were designed so data could be safely written and read years after the original creation. In this era, a database only serves a limited number of people, and a single machine (a mainframe, or a powerful micro-computer in the later years) is enough to power a single database.

Gradually, computers begin to serve more people. The explosion of the Internet accelerates the process. Soon a single machine can barely power a database, and distributed databases begin to emerge. Unfortunately, the discovery of CAP theorem (pick 2 of 3 — Consistency, Availability, Partition Tolerance) presents software engineers quite the challenge. Ultimately, they are forced to choose between CP and AP databases. For quick reference, a simple (though unilateral) way to tell a CP database from an AP database is:

• A CP database ensures a global consistent view on the whole distributed system.
• An AP database, however, might give different views for different logical parts, or partitions.

Starting with Amazon DynamoDB, and flourishing with MongoDB, there was a period of time when AP databases received a lot of buzz. Everywhere people exclaimed, “NoSQL is the future! SQL is such a dinosaur.” This was indeed a time when numerous people chose NoSQL solutions to build their apps. At this time, it did seem the future of databases was partitioned solutions.

But this is not the end of the story. Fast forward a few years, the weakness of AP databases started to surface: the different views witnessed from different partitions really get in the way when one is making decisions in architecting a system.

Take one example, you are a developer building on a traditional SQL database, you only need to care about logical tables and the connections between them. There might be a need for more performant queries now and then, but your data will always remain organized. In an AP database, however, you are only equipped with a key-value (KV) store, or a document store. You have to design your schema first, but on top of that, you have to deal with inconsistent writes happening from different partitions of the database. This significantly complicates the work required from the app developer, which, in many cases, also leads to a messy data store.

Even looking at AWS, where the CP database solution DynamoDB is live and used till today, traditional SQL databases still remain widely used. Only in special cases such as shopping cart logic, where a special merge function exists, has DynamoDB gained huge adoption. For the vast majority of the apps everyday developers are building, AP databases are hardly a good choice.

And now we arrive at the trending topic today: NewSQL, which maintains the ACID properties from the original SQL model, has gained popularity as a replacement for NoSQL in the majority of use cases. Due to the design requirements, NewSQL solutions are mostly, if not all, built upon CP models:

• Google Spanner is Google’s future-proof, global scale database. It follows a CP design, aimed at providing a better alternative than AP-based BigTable.
• CockroachDB and TiDB are both modern open source distributed SQL databases built on the CP model.
• CitusDB, a famous scalable PostgreSQL-based database, is also built on the CP model.

We could go on but the trend is already clear: developers yearn for CP systems for productivity. History took a slight detour towards AP, but corrected itself back to a CP path, due to its developer friendliness.

From this story, we can learn that ultimately, developers will pick the winner based on what makes them most productive.

Now you might wonder: this is a rather long story, what does this have to do with blockchains?

At Nervos, we strongly believe in a layered solution. This has never been a random preference, nor is our means to be kool. It is based on our extensive experience in the software industry. Layers equip us with a way to set boundaries, encapsulate complexities, and provide assumptions.

If we look around, a huge number of things in our industry are built upon layers: networking stack, compiler infrastructure, CPU architecture, the list goes on. Everywhere in this industry, as well as many other industries created by humankind, we see layers built to hide details, while providing features to the layers above.

Even for those who believe blockchains are so novel, the usage of layers also presents a clear difference:

• The core blockchain in a layered network ensures a global consistent view on its transactions.
• A sharded blockchain design, however, provides different shards that each can work independently.

Does this ring a bell to you? A blockchain, if you think about it, closely resembles a distributed database! There are certainly major differences, but the discussion contrasting layers and shards, in our opinion, is similar to what we saw between CP and AP databases over the past 10 years: in a layered blockchain, you are grouping upper layer blockchains based on their logical functionality, minimizing the need for cross-chain communication; whereas in a sharded blockchain, cross-chain communication is the basis of scaling needs, and cannot be avoided.

Given time, we believe layers will present clear benefits for all dApp developers to embrace, just like the rise of NewSQL databases.

We know many of you have been wondering what a layer 2 solution will be like on CKB, so it is our great pleasure here, to present 2 complementary projects to you: the initial release of Godwoken, and a complete overhaul of Polyjuice.

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.

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:

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

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.

To explain more about the internals of Polyjuice, we will also publish a different article titled Life Of A Polyjuice Transaction soon.

Looking Into the Future

At Nervos, we want to cater to 2 different groups of engineers:

1. For the busy app craftsmen, we want to provide a one-stop solution, so they can directly leverage the layer 2 EVM-powered blockchain to ship whatever they want. For example, what if we told you, Uniswap can be deployed to CKB with just a minimal amount of tweaking?
2. For the more adventurous minds, CKB provides the perfect Lego style pieces, which you can disassemble and reassemble together yourself. Don’t like writing smart contract via Solidity? Why not build your own VM on Godwoken for a different rollup chain? Optimistic rollup sounds boring to you? Feel free to take that out and swap in a more challenging piece, such as ZK Rollup. PoA mechanism sounds an alarm for you? Just cut that out and use your own PoS or even PoW solution.

In a nutshell, we hope this brand new layer 2 Godwoken/Polyjuice deployment on CKB, can be similar to what you may be accustomed to with cars: you can drive it off the lot (stock) after you’ve purchased it from a dealer, or you can open it up to add a turbocharger for more potential. We are prepared to be amazed at all the mods you end up having with your brand new “car”.

---

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: English, Korean, Russian, Japanese, Spanish, Vietnamese and Chinese