In the last blog post, we covered how Nervos Layer 1 CKB, Godwoken (Layer 2 Optimistic Rollup), and Axon (sidechain) compared concerning Security, Speed, and Decentralization.
In the third of our four-part blog series on Which Nervos Network Layer Should I Build On, I discuss these concerns: Ownership, Longevity, Flexibility, Time-To-Launch, Support, and Community.
I’ve tried to rank each attribute in order of a layer’s relative strength compared to other layers.
Sometimes, it is pretty straightforward, and most would agree with my ordering.
Other times, valid arguments could be made which might shift the rankings I’ve assigned.
Please read with this in mind.
Let’s continue with some additional developer concerns:
Give me longevity: I want this dApp to be around for a long time.
Most developers want to launch their projects as quickly as possible; you would be hard-pressed to find teams that are thinking even beyond five years into the future. But success can often come when you least expect it, especially in bull runs. Consider STEPN, a move-to-earn application that started by placing just 4th in a Solana Ignition Hackathon in 2021 and quickly rose to a $2.42 Billion market cap seven months later! These things can happen, so why not plan to build a sustainable app that can stay around long-term?
Longevity is dependent on three things:
1) Interoperability – How flexible will the layer or blockchain adapt to emerging technologies, standards, and protocols? Is interoperability a primary focus of the blockchain
2) Sustainable Ecosystem – How easy and desirable is it for the ecosystem to grow and mature organically? Think about how many projects left the Ethereum network during the 2021 bull market because the network wasn’t operating correctly. Transaction fees were insanely high, some transactions didn’t even go through, and users still paid for them. In the future, no blockchain will gain mass user adoption that exhibits these problems.
3) Decentralized/Secure over time – How will the network change in time? Is it becoming more centralized and less secure, or vice versa?
Numbers 1 and 2 are apparent hallmarks of any future protocol.
Number 3 is a little more challenging. Blockchain is still in its infancy, and it isn’t clear what level of decentralization users will demand in a mass adoption scenario. On the one hand, users don’t want to be scammed, hacked, or rug pulled; on the other hand, they don’t want someone watching their every move. One novel way that Nervos has positioned itself to ensure it always stays decentralized is by making sure miners are always incentivized to secure the network.
Nervos secures its network for the long term via State Rent.
State rent was defined in part one of this blog series. Essentially it is interest charged to users of the CKB L1 blockchain. When users store data, they must lock their tokens up in a 1 CKByte per 1 Byte of data arrangement. Users get their CKBytes back when their data is taken off the network.
While the user’s data exists on-chain, it will experience targeted inflation through a secondary issuance of CKBytes that get rewarded to the miners who host that data.
#1 CKB L1
CKB L1 is future-proof due to state rent and the Cell model, which allows for a higher degree of interoperability and a sustainable ecosystem. One weakness of state rent might be the cumbersome mechanic for users to lock up CKB to store data on the network. While inconvenient, this mechanism still puts CKB L1 at the top of the list. It is also worth mentioning that teams are currently working on user-friendly models for the future. For layer 1, whose duty is to provide security for other layers, this is a tradeoff the Nervos designers were willing to accept.
Godwoken is a layer 2 Optimistic Rollup, which means that it is directly tied to CKB L1. In the future, Godwoken will rely on Proof-Of-Stake (PoS). Critics of PoS have concerns over security and decentralization in the long term. However, Godwoken’s longevity will benefit significantly by being tied to CKB L1 since Godwoken inherits aspects of the security and decentralization of CKB L1.
Axon is highly configurable, giving the developer much power and responsibility. Some decisions might work great in the beginning but lead to headaches in the future since sustainability is a delicate balancing act. Because there can be many configuration flavors, one can think of Axon and the projects built on it almost as you would natural selection–the most sustainable versions will persist.
The design decisions, the amount of support, and even the consensus model and protocols are all critical to the longevity of a project. With Axon, these are all decided by the developers, for better or worse. Comparing Godwoken to Axon regarding long-term success potential is difficult since they are being built for different use cases. Since Godwoken is the safer option for less experienced blockchain developers, we rank them above Axon for longevity.
Give me ownership: I want my users to own and control their assets fully.
So far, we’ve covered security, speed, and decentralization. It is not easy to define one outside of the others, and hopefully, you can see the interconnectedness of these goals. Asset ownership is no different in that it also depends on security and decentralization.
But what does it mean to
own your asset truly?
For this, and very specific to the Nervos Network, we need to introduce the idea of a First-Class Asset in terms of the two main ownership models:
Account Model: Based on account ownership.
The account model in Ethereum is an example that is easy to understand and familiar. In the Ethereum network, transferring assets is done via two accounts. An asset in one account is reduced while another account is increased. Simple, just like a bank account works.
UTXO Model: Based on assets.
This model is a little more challenging to understand, but think of it like this: instead of just having one account that holds the asset, like a bank holding a bank account, the UTXO model is like owning one or more high-security tamper-proof safe deposit boxes.
These boxes cannot be opened without destroy it. This ensures nothing can be changed without detection. This also means you must transfer the contents into new boxes each time something is changed. As you’ll see, this idea of opening and closing digital asset containers provides nearly impossible benefits to achieve with account-based models.
Here is another good comparison between the UTXO and Account models if you want to read more.
At Nervos, we have created a simple model called the Cell model, which borrows and extends the UTXO model. We define a first-class asset whereby users have direct access to their assets. To understand what it means to have direct access, we refer again to the banking examples just mentioned.
In the account model, you must go to the bank, see a teller, and perform your transaction. The teller is the smart contract. In the Cell Model (or First-Class Asset/UTXO model), you walk directly into the vault of safety deposit boxes and access the contents without seeing a teller; you leave the teller out of the equation. By cutting the teller out of the loop, user authority gains precedence over teller authority. Another way of saying this is the smart contract owner can’t change things if the user doesn’t authorize it. In the Account model, it is the contract that has control of the account state. In the Cell model, it is the owner who has control.
What does this mean for the developer who just wants to provide a better dApp for their users? From the user’s perspective, they get to…
…have more security for their digital assets.
Going one step further, because authorization logic is separated from business logic, even if a hacker finds an exploit in the business logic, they may remain locked out of the asset. This is because the asset is owned by the user, not the smart contact. Even the author of the smart contract that defines the asset is denied permission to the user’s cell and the contents within unless the user explicitly grants them permission.
…have predictable state transitions
With the cell model, transactions are deterministic. Transactions get validated on-chain, and the actual computation is done off-chain. This means that when transactions get sent to the chain for validation, the inputs and outputs are already known, including the transaction gas fee.
From a user’s perspective, this is awesome because (1) their transaction fee won’t change; what they see is what they get, and (2) failed transactions never are sent to the network for validation due to the deterministic nature of the UTXO design. According to the UTXO Blockchain Alliance, “on the UTXO ledger, a user can predict the cost and validity of a transaction before it is processed on the chain.” This is unlike what happens on the Ethereum network when network congestion is high, where you have non-deterministic transactions that can fail.
…upgradable smart contract lock
The Cell Model separates the authorization logic (key to unlock the cell) from the business logic (smart contract as you’d normally think of one.) This separation means that authorization can be “upgraded” in the future with the user’s consent. This means that if a popular asset was developed by one team and then they discontinued maintaining it, the authorization logic may still be able to be upgraded by a new team without needing to modify the underlying asset’s smart contract. This has benefit of giving older assets a way to upgrade so they can interact with future smart contracts that have different requirements. This also gives the ability to upgrade the security of the asset in the future as standards move forward, and better options become available.
…have greater platform sustainability
We covered state rent in the section above. With the cell model, each user has separate assets and independent asset states. State rent is addressed in the cell model by design. First-Class Assets enable true ownership of digital assets. Users are in complete control of their assets, and they are also responsible for the upkeep of the asset itself. This is akin to purchasing something from the store and taking it home. The object is in your custody and you are responsible. With other models, there are still open problems such as who will pay for rent on a shared smart contract. With the cell model, there is no mixing or sharing, and each user is responsible for their own share of usage.
Ultimately if you want to work directly with First-Class Assets and the inherent flexibility of the Cell Model, your only choice would be to develop on CKB L1.
#1 – CKB L1
Only CKB L1 possesses the attribute of allowing for a First-Class Asset.
#2 – none, First-Class assets are the domain of UTXO-based models only.
#3 – none, First-Class assets are the domain of UTXO-based models only.
Give me flexibility: I may want to change my mind about my design in the future.
Flexibility is the key to what makes Nervos work. CKB L1 was explicitly built to be flexible and includes features like the Cell Model we’ve covered briefly. Most developers understand the case for creating reusable, modular code, so I won’t go into this here. Still, we can agree that being able to pivot quickly and easily to changing requirements is essential and the goal of modern software development.
#1 CKB L1
CKB L1 uses CKB-VM based on the RISC-V instruction set. This is like building on hardware. The benefits are tremendous because anything that compiles to RISC-V can be executed on any RISC-V-compatible hardware. With the Cell Model, you also get a Proof-Of-Work, UTXO-based blockchain like Bitcoin. But, in addition to only storing and transferring Satoshis (as in Bitcoin,) you can store and transfer any kind of data you like–technically speaking, there is no restriction.
Axon is a highly configurable sidechain. This means you can use a variety of consensus mechanisms and thus change the operating characteristics of that instance. Because you can choose a consensus mechanism, you can also alter that sidechain’s security and decentralization capacity.
In some ways, Axon is more configurable than CKB L1 regarding the configuration of the blockchain itself. Still, because we’ve prioritized the programming model from a developer standpoint, we keep CKB L1 at the top of the list.
Godwoken is currently a single network instance for all projects. It is designed to be 100% compatible with the Ethereum EVM. There is less flexibility here because it’s intended to be a standardized environment with little guesswork.
Godwoken is designed to be a configurable framework similar to Axon. In the future, Godwoken may be able to provide more flexible options for developers.
Give me fast startup time: I want to launch my dApp quickly.
Time to Market (TTM) is a huge priority for a dApp developer. The time from concept to a usable product is crucial for all projects. Wait too long, and your marketing costs go up trying to compete in a saturated marketplace. Be the first to market, and avoid having a viable product with the features you need to establish your position in the market.
Being able to start quickly because you have a familiar development environment, good documentation, a supportive community, and cross-team collaboration are all items you should pay close attention to when thinking about your time to market. For instance, you might only want to work with an EVM-compatible development environment because you are familiar with Solidity. Great! That narrows your focus.
Below we’ve listed EVM-compatibility considerations and a few more things to consider when considering which layer to build on.
Godwoken is 100% EVM-compatible, making it easy to deploy new projects very quickly on Godwoken. Solidity developers will feel right at home. In addition, Godwoken has the most mature tooling support, documentation, and community ready to support new developers.
Axon is also EVM compatible and meant to be a “blockchain-in-a-box.” Your time-to-launch will depend on your understanding of how Axon should be configured, the quality of your project planning, and your design choices with Axon. Some of this has to do with understanding how these configuration choices impact your project in the short and long term and what the migration path should be if you make changes in the future. Because of the thoughtfulness required in planning, we placed Axon in the second position. It should be noted that once your design plan is finished, launching on Axon should be fast and easy.
#3 CKB L1
CKB L1 has a steeper learning curve, especially for EVM developers who are accustomed to the account model but unfamiliar with the UTXO model. The Rust programming language is used for smart contracts. Rust is highly praised and rapidly growing in popularity, but it can still be a challenge for developers coming from Solidity.
CKB L1 uses the Cell Model, inspired by the UTXO model. The Cell Model uses scripts, which is the term used to describe a small program used to achieve smart contract functionality. A script accomplishes the same thing as a smart contract, but how it achieves the desired results is sometimes very different.
For example, the Cell Model uses two scripts to control an asset. The lock script defines who can modify the asset and the type script defines how the asset can be modified. With Solidity smart contracts, no such differentiation is made.
Give me support, community, and a great development experience: I want to enjoy myself.
The last two decades have seen an explosion in meet-ups, conferences, hackathons, and other experiences which allow developers to expand their knowledge and join software development conversations in meaningful ways. And for a good reason–it is tough building alone, and let’s be honest, sometimes not very fun!
Many developers, especially those actively participating in the open-source community, enjoy robust collaboration to fix bugs, improve code quality, and generate new ideas for building really cool projects. Having a community of developers that can support you along the journey is very important to the success of your project.
We at Nervos have created an effective community we call “Build Club,” which is just the right size for getting projects off the ground and onto the mainnet. Big enough to have exposure to highly talented, responsive developers and small enough not to get lost in the crowd, as might happen in larger ecosystems.
Godwoken has the fastest-growing community, the most mature tooling, and its own Build Club to help developers get the support, community, and experience they want.
#2 CKB L1
CKB L1 will join Build Club soon! As of this writing, the CKB L1 documentation and tooling are being revamped to make way for future upgrades and improvements.
At the time of this writing, Axon is testnet-ready only but will likely be ready for mainnet deployments in early 2023.
Stay tuned as I dive deeper with use cases and show why specific projects were built on Nervos (in their words, not mine) and not other blockchains.
Did you miss the 1st two parts of this series?
We’ve Got Your Back!
We’d love to support you in any way we can.
We have grant programs available and Build Club (a super-supportive community just for developers looking to get started with Nervos.)
– Here is a link to Build Club.
– Here is a link to our Grant Program.
Don’t need any help and want to start right this second?
Check out our tutorials below:
– Start building on L1 CKB!
– Start building on Godwoken!
– Start building on Axon!
Lastly, if you want a shortcut to try and figure out what layer you should be building on, we’ve created a handy tool for you that can help!