A few decades ago, people due to need better tools to organize data, so the SQL database (en.wikipedia.org/wiki/SQL) arises at the historic moment. ACID properties (en.wikipedia.org/wiki/ACID) is designed to make data can create a few years later, in the original still can safely be written and read. In those days, a database served only a limited number of people, and a single machine (a mainframe or, later, a powerful microcomputer) was enough to support a database.
Gradually, computers began to spread, a process accelerated by the explosion of the Internet. Soon, a single machine could no longer support the database, and distributed databases began to emerge. However, the discovery of the CAP theorem that you can only choose two of the three features of consistency, availability, and partition fault tolerance presents a huge challenge for software engineers. In the end, they were forced to choose between CP and AP databases. For easy reference, we use a simple (albeit one-sided) method to distinguish between CP and AP databases:
- CP database ensures the global consistency view of the whole distributed system.
- An AP database may provide different views for different logical parts or partitions.
From Amazon’s DynamoDB to the boom of MongoDB, there was a time when AP databases got a lot of attention. Everywhere people shout, “NoSQL is the future! SQL is an outdated thing.” Many people did choose NoSQL solutions to build their applications. At the time, it did seem that the future solution for databases was indeed partitioned.
But the story is not over. A few years later, a flaw in the AP database began to emerge: different views from different partitions did influence people’s decisions when designing system architectures.
For example, if you are a developer building on a traditional SQL database, you only need to care about logical tables and the connections between them. Occasionally more performance queries may be required, but your data is always in order. In an AP database, however, you only have a key-value (KV) store or a document store. We have to design the schema first, but on top of that, you have to deal with inconsistent writes that occur between different partitions of the database. This greatly increases the workload for application developers and, in many cases, leads to messy data storage.
Even with the launch of CP database solution DynamoDB and the use of AWS today, traditional SQL databases are still widely used. Only in exceptional cases, such as shopping cart logic with special merge capabilities, will DynamoDB be widely used. AP databases are hardly a good choice for the vast majority of applications that everyday developers are building.
Now let’s look at the hot topic of today’s discussion: NewSQL, which retains the ACID properties of the original SQL model and has gained popularity as an alternative to NoSQL in most use cases. Due to design requirements, most or all of NewSQL’s solutions are based on the CP model:
- Google Spanner is Google’s future-oriented, global-scale database. It follows a CP design designed to provide a better alternative to AP-based BigTable;
- CockroachDB and TiDB are modern open source distributed SQL databases based on the CP model;
- CitusDB, a typical postgresQl-based extensible database, is also based on the CP model.
Many more examples could be given, but the trend is clear: developers are eager to use CP systems to increase productivity. History briefly tilted toward AP, but people eventually went back to CP because of its developer-friendly nature.
From this story, we can see that developers will ultimately choose the tools that make them more productive.
Now you might be thinking: That’s a long story, but what does that have to do with blockchain?
At Nervos, we believe in layered solutions. This has always been the result of careful consideration and is based on our extensive experience in the software industry. Layering gives us a way to set boundaries, encapsulate complexity, and provide assumptions.
A lot of things in our industry are built on layered architectures: network stacks, compiler infrastructure, CPU architectures, the list goes on and on. In this industry, as in many others created by humans, we can see layers that are built to hide details while providing support for the upper layers.
Even for those who see blockchain as a brand new technology, the use of layers presents a clear difference:
- In a layered network, the core blockchain ensures the global consistency of its transactions;
- Sharded blockchain is designed to provide different shards, each of which can work independently.
Do you have a familiar feeling when you see here? When you think about it, blockchain is very similar to a distributed database! While there are big differences, in our view, the discussion about layering and sharding is similar to the discussion we have had with CP and AP databases for the past 10 years: In a layered blockchain, you group the upper layer of the blockchain according to its logical function, minimizing the need for cross-chain communication; However, in sharded blockchain, cross-chain communication is the basis of expanding requirements, which cannot be avoided.
Over time, we believe that layering will bring more tangible benefits to all dApp developers, much like the rise of NewSQL databases.
A lot of people have been wondering what a Layer 2 solution would look like on CKB, so today we’re here to introduce two complementary projects:
-
Initial version of Godwoken: github.com/nervosnetwo…
-
Full update for Polyjuice: github.com/nervosnetwo…
Godwoken: Permissionless Rollup framework
There are many scaling schemes in the blockchain world today. There are payment channels, Rollup, status channels, Plasma and so on.
On Nervos, we can support all of these solutions, but really, we have to start with one solution. Of the existing solutions, Rollup is the best and least flawed. As a result,We started our journey on Rollup. As we’ll see later, due to CKB’s unique design, Rollup makes more sense than just boosting TPS on steroids. Based on nearly a year of research, design, and implementation, we have released the initial version of Godwoken, our permission-free Rollup framework.
Godwoken works by collecting specially designed Layer 2 transactions through a set of Aggregator nodes, then packaging them as CKB transactions and submitting them to the Layer 1 CKB for reception. In this sense, Godwoken does work in a Layer 2 way:
- In addition to CKB nodes, special Godwoken aggregator nodes are run
- Adopt a specially designed Layer 2 transaction format to replace CKB transaction format
- A special CKB transaction is submitted by the Godwoken node, which can also be considered a Layer 2 block
Despite being a Layer 2 solution, one of the key design concepts behind Godwoken is that we are building a Layer 2 solution that does not require permission.
- As provided by the Layer 1 blockchain, Layer 2 transactions incentize the aggregator nodes with transaction fees;
- Multiple separate Godwoken deployments are available on the Nervos CKB. Each deployment is free to make its own choices. If one deployment does not meet your requirements, you are free to switch to another deployment or even start your own;
While some deployments may create additional limitations, the core design of Godwoken is to enable everyone to submit blocks to the Layer 2 blockchain, making it scalable like a true permissionless Layer 1 blockchain.
(To show more inside information about Godwoken, we will soon be Posting an article called “Life of A Godwoken Transaction” in which we will go into more detail about the design and implementation of Godwoken.)
It’s worth noting that we’ve only released the first version of Godwoken so far, which is limited to the following design choices:
- Design based on Optimistic Rollup will be used;
- Proof-of-authority controls the issuance of Layer 2 blocks.
We will continue to add more features to Godwoken, including:
- A truly proof-of-stake based block publishing coordination mechanism
- Settings based on ZK Rollup
- And more!
Recently, we’ve been pleasantly surprised by how quickly Rollup is catching on in the blockchain world (ethereum-magicians.org/t/a-rollup-… . We are honored to stand on the shoulders of giants, and we are eager to do better work in this field and to stand on the shoulders of others to innovate.
However, using the Rollup framework is only half the answer. A solution that sends only native token transfers won’t solve all problems. In the highly competitive and growing blockchain space, a smart contract solution is often needed to unleash more potential. To address this other half of the problem, we also created Polyjuice, which will work in conjunction with Godwoken.
Polyjuice: A 100% EVM-compatible Ethereum solution for CKB
Polyjuice is an Ethereum solution on CKB, which means that people can migrate their existing Dapps running on Ethereum to CKB with minimal modification. Polyjuice is designed to be 100% or even 120% compatible with EVM, which means:
- Any Solidity based smart contract that runs on Ethereum can run on Polyjuice;
- Polyjuice offers even more features that are not available on Ethereum today. If you need an EIP right now, Polyjuice will implement it to aid your dApp.
Note that compatibility design only works with EVM, Ethereum also has RPC support, and applications can communicate with the chain through RPC. Unfortunately, due to the design differences between Polyjuice and Ethereum, we can’t guarantee full RPC compatibility. This means that taking your existing Ethereum dApp and deploying it to Polyjuice requires some work.
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.
These differences will be clearly documented. In this way, the number of transplants will be reduced as much as possible. We’ll also build integration with the Portal Wallet so the end user can have a seamless experience.
We launched Polyjuice in July 2020, and I mention it again because we did a thorough review and overhaul of Polyjuice and fixed its biggest problem: dealing with shared status.
To demonstrate the shared state, let’s assume that the developer has deployed a Ethereum smart contract to Polyjuice. In our previous model, people would create a Cell like this:
This causes multiple transactions to consume the same contract status cell, and the miner has to select one transaction, which invalidates all other transactions. This is a result of CKB’s choice to be based on the cell model, but it’s not necessarily a disadvantage:
- SUDT is an example of a number of situations where you don’t need a single shared state. For these cases, the cell-based model provides improvements, such as increased scalability and determinism;
- Even in cases where shared state is inevitable (such as voting applications, or AMM), there are solutions:
In many cases, simple retry logic can be used: you can create a rule that says “AS long as the transaction contains input 1 and output 1&2, I don’t care what the 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 apps, this is enough.
If there are cases where there are additional requirements, such as higher TPS requirements, then retry logic is not feasible. Rollup offers a different solution here. By building Polyjuice on top of Godwoken, each individual Polyjuice trade can be just a Layer 2 Godwoken trade. This avoids shared state issues, as only a packaged Godwoken CKB transaction consumes the contract state cell and recreates an updated state cell.
Here, Godwoken and Polyjuice are complementary: Polyjuice offers a Rollup solution that injects custom logic into Godwoken, Godwoken solves Polyjuice’s shared status problem while also offering higher TPS potential. We hope that the combination of Godwoken and Polyjuice will inspire layered dApp design in Nervos CKB Wonderland.
It’s worth pointing out that Polyjuice isn’t Godwoken’s only virtual machine solution. We can also integrate other virtual machines with Godwoken to provide different ways to build dApps. For example, a pure JavaScript virtual machine (github.com/xxuejie/ckb…) Is completely achievable, so we just need to write it in JavaScript directly within the blockchain. Or more ambitious goals, with the help of Godwoken, Diem(www.diem.com/en-us/) on CKB can be fully realized.
(To further explain the inner workings of Polyjuice, we’ll be publishing another article in the near future titled “Life of A Polyjuice Transaction.”)
Looking to the future
At Nervos, we want to cater to two different groups of developers:
- For busy application developers, we want to provide a one-stop solution that allows them to publish whatever they want directly with the Layer 2 EVM-powered blockchain. For example, what if we told you that Uniswap (uniswap.org/) could be deployed on CKB with minimal adjustments?
- For the more adventurous, CKB offers the perfect Lego-style parts that you can disassemble and reassemble yourself.
- Don’t like writing smart contracts with Solidity? Why not build your own virtual machine at Godwoken to implement a different Rollup chain?
- Optimistic Rollup Sounds boring? Feel free to pull it out and replace it with something more challenging, such as the ZK Rollup.
- Is the PoA mechanic like a ticking time bomb to you? Then delete it and use your own PoS or even PoW scheme.
All in all, we’re hoping that the new Layer 2 Godwoken/Polyjuice will be deployed on CKB in a way that’s similar to what you might be used to: you can either buy it from a dealership and drive it away, or you can turn it on and add a turbocharger for more power. We’re ready for you to finally be surprised by all the modifications to your new “car”.
Fan Welfare Activities
-
Activity Rules:
-
Pay attention to Nervos official number — “NervosNetwork”;
-
Leave a comment about this article in the comments section;
-
-
Activity Rewards:
- We’ll select one to five outstanding comments from the comments section and each person will receive a COFFEE Token that can be exchanged for a Starbucks COFFEE (details can be found here).
-
Notes:
-
The same address, can only get a reward;
-
If cheating is found in the activity, the participant will be disqualified.
-
-
Activity Time:
2021/1/21 12:30-2021/1/23 18:00
// If you like Nervos and like development
// You can leave a comment and follow me in the comments
if (you like Nervos && you like dev) {
println("you can leave a message in the comments area and follow me~");
}
Copy the code