Nervos plans to carry out the first hard fork of CKB this year, release a basic light client, and develop a Layer 2 Rollup framework based on CKB.
Original title: “Nervos 2021 Technology Roadmap”
Written by: Xie Hanjian (Jan Xie), Chief Architect of Nervos, CEO of Secret Ape Technology, former member of the Ethereum core R&D team
Sometimes people wonder, why can’t find milestones with gorgeous names on the Nervos website, but only a “roadmap for 2020” ? So I wonder if Nervos really has a long-term plan, and even wonder if the team will “return the project to the community” after 2020? The fact is just the opposite. We believe that the Nervos mainnet launch in 2019 is just the beginning of a long journey, and we are well prepared.
It’s easy to come up with some cool milestone names, but if these milestones are still meaningful in a few years, it will be difficult to keep up with them. Planning everything in advance and working towards a fixed goal (the so-called waterfall model in software engineering) will not work in a constantly changing environment. In the field of encryption, this is 200% of the truth. Every day we can see the emergence of new ideas, the launch of new projects, every day we will learn from each other, any plan will be out of date in 3 months (maybe I exaggerated a bit, maybe 6 months). So, what is the purpose of setting a milestone for 2077 today? Someone once said: “Vague correctness is better than precise error.”
So we used another method, which we call the Nervos Way . Nervos is a network running on many protocols, it is not a single blockchain. We have a general idea of ​​the world after using blockchain technology, and we want to ensure that the Nervos protocol stack can support this vision. We keep the most important things in Layer 1 to make it the minimum basis for stability and security, and leave other things to Layer 2 or higher. This layering brings great flexibility to Nervos, because it is easier to try various ideas and explore different directions on Layer 2. This means that as we learn more about the future, Nervos can develop with the entire industry.
Our general long-term goal is to be able to complete the entire design and implementation of the Nervos protocol stack by 2024. According to our estimation, the design space of Layer 1 and Layer 2 is likely to be stabilized before 2024, and we can be confident that we will not miss anything in the Nervos agreement; 2024 is also the first four-year halving of CKB In the first year, it feels good to match it. Although the goal of 2024 is ambitious, it can be achieved if we are bold enough to enjoy the “four-year sprint .” Before 2024, while we are focusing on short-term tasks, we will constantly look at other people’s practices, learn from new things, and adjust our plans accordingly. At the beginning of each year, we will plan the next year’s plan based on last year’s experience and move forward to the 2024 goal. In this way, we can keep ourselves and Nervos flexible and adapt to the ever-changing future.
Next, it’s time to plan the technology roadmap for Nervos 2021 .
Layer 1: CKB
The first hard fork
Evolution means change, and sometimes even radical change. The hard fork is a direct way to bring breakthrough changes to Layer 1. We plan to carry out the first hard fork of CKB in 2021, including the upgrade proposed by the Nervos RFC . These suggestions allow us to improve CKB in many different ways:
The official RISC-V B extension will be introduced into CKB VM, so it can provide more efficient encryption algorithm implementation.
Flyclient support . Flyclient is a fast verification method for PoW blockchain. After enabling Flyclient, the light client can synchronize to the correct tip block within a few seconds. Flyclient needs to modify the block header structure, and the same modification is also conducive to the cross-chain verification of CKB transactions on other blockchains.
CKB VM will introduce a new concept, macro-op fusion . Looking at macro-op fusion from a higher perspective, when people use certain RISC-V instructions together, the CPU can execute them together in a more efficient way. Therefore, CKB VM will reduce the cycle of forming the macro-op fusion instruction mode. Please note that modern compilers have made extensive use of macro-op fusion, so the only result you may notice is that the CKB VM charges fewer cycles for smart contracts than before the hard fork. For a more detailed introduction of macro-op fusion in RISC-V, please refer to here .
Re- fix the bugs in CKB VM in a cleaner way. These bugs have been fixed on the main network with temporary solutions.
Adjust the block/transaction version and CKB VM rules to make future soft forks easier.
Multiple dep matching can be performed in the transaction. CKB Cell uses data hash or type script hash to indirectly match script binary. Cells that store binary files must be added through Cell dep. Currently, it is not possible to perform multiple matches in CKB Cell dep to avoid ambiguity. However, if the same Cell appears multiple times in Cell deps, this error can usually be safely bypassed through the dep group.
Simplify the since rules for transaction input.
One of the main reasons behind the CKB VM changes (except for bug fixes) is to reduce overhead . CKB VM is already a thin abstraction layer on the local CPU. With a hard fork, we really want to make the abstraction layer thinner: the RISC-V B extension allows us to directly map RISC-V instructions to the native instructions provided by x86-64 cpu, while macro-op fusion is even more In-depth utilization of the modern micro-architecture in our CPU. All these efforts are to make the encryption algorithm run more efficiently on the CKB VM, thereby unlocking more potential use cases for Nervos CKB.
Coordinating a hard fork has never been an easy task. We will do our best to communicate fully with the community to ensure a stable and elegant upgrade.
Light client
Although we have spent a lot of effort to lower the threshold for full node operation, the time, network bandwidth, and disk storage required to synchronize the entire chain will increase linearly with the length of the chain. Full nodes provide us with a trustless option, but this level of security may be too high for some users. It would be great if there was a more balanced choice for daily use. The light client is created for such a demand. The light client allows users to interact with CKB with the least bandwidth and storage, and it can also help Nervos dApp run on more platforms, such as mobile devices.
We have tested a basic light client protocol design last year. In 2021, we will complete this work and release a version. We will build tools and integrate with Neuron. The basic light protocol will still download all block headers. If we successfully add Flyclient to the hard fork and switch to a more advanced light protocol, this may greatly reduce synchronization time, network bandwidth and disk storage.
Layer 2
Godwoken & Polyjuice
Godwoken is a Layer 2 Rollup framework based on Nervos CKB. It provides CKB with scalability and an account-based programming model.
With Godwoken, Polyjuice provides an Ethereum compatibility layer on Nervos CKB. It uses the account model and scalability provided by Godwoken, and then integrates evmone as the EVM engine for running Ethereum smart contracts. Polyjuice’s goal is to be 100% EVM compatible, which means that we plan to support all smart contracts supported by the latest hard fork version of Ethereum.
Both Godwoken and Polyjuice have been deployed to the Nervos CKB testnet environment. In 2021, after Godwoken/Polyjuice passes the audit, we will deploy them to the Nervos CKB mainnet. In addition, we will also introduce more enhancements to Godwoken:
Godwoken currently uses Proof-of-Authority to simplify the design, but it is not limited to this. In 2021, we will study a more decentralized Proof-of-Stake model and Zero-Knowledge Rollup.
Extended functions, such as BLS signature integration, will be introduced to achieve higher throughput.
Polyjuice provides the first but not the last programming model. We are looking for the next programming model supported in Godwoken, such as Diem . If it is found in 2021, we will integrate it with Godwoken. The more programming models supported, the more dApps and developers can migrate between Nervos and other blockchains, which is one of the pillars of Interoperability 2.0.
Axon
Axon is a Layer 2 protocol based on chain. It is not Rollup because it does not use CKB as a data availability layer. Data may not be available in Axon. We hope to solve this problem with different assumptions and designs. We have done several rounds of Axon protocol design before, but it was not until last year that we had satisfactory results. After 2019 and 2020, we have learned more real needs and pain points from our partners. We believe that these experiences will help us make the right choices and bring a better security model, governance model and better security model to Axon. Token economics. Currently, we are still studying the agreement. Hope we can complete the design and translate it into code in 2021.
Payment channel network
The channel network is the other side of Layer 2’s native tokens (compared to chain-based protocols). In 2020, we started researching from the general payment channel (GPC) and discussed topics such as HTLC channel synchronization , UDT support , watch towers, payment routing issues, and split payments. We built a prototype to test these ideas and conducted multiple design iterations last year. Prototypes and discussions show that the payment channel network on CKB is not only possible, but also more powerful than the payment channel network on Bitcoin and Ethereum. The composability of universal payment channels means that UDT can be “channelized” effortlessly on CKB! UDT is not only an asset on Layer 1 as a “first-class citizen”, but also a “first-class citizen” asset on Layer 2, because they can flow in and out of layers without any modification. This brings maximum liquidity to the payment channel network, because all assets of Layer 1 can be added to the fund pool of Layer 2 without friction.
I believe that a payment channel network that supports UDT will create unprecedented new application cases. Accompanying its huge potential is the high complexity of the channel network. We hope that we can complete the preliminary design in 2021 and establish a small but usable payment channel network on the mainnet.
xUDT
If sUDT is the “ERC 20 token on Nervos”, then xUDT will be something without similar competitors because of its strong scalability. xUDT (Extensible UDT) extends sUDT to provide room for additional behaviors that UDT may require, such as compliance requirements and governance. xUDT is more like an extensible framework, just like Chrome browser, we can create various extensions for it. xUDT itself does not specify or implement any specific UDT behavior. When you want to create a new UDT, these extensions can be combined and used in a flexible way. Like sUDT, we will provide an xUDT RFC, which will be deployed on the main network and test network by default after approval.
tool
CKB is fundamentally different from the existing smart contract blockchain, so it encounters a common problem that every new platform will encounter: lack of tools. This is why we are committed to developing tools at the beginning of 2020 and working around the clock. With the release of a series of tools such as CKB SDK, ckb-indexer, ckb-x64-simulator, lumos, Capsule, animagus, mandrake, etc., the threshold for developing applications has been lowered a lot. We can see that many developers have begun to use These tools have been built on Nervos. In 2021, we will continue to improve existing tools and bring you some new tools.
Tippy
Tippy is a complete dApp development kit on Nervos CKB. It aims to provide all the tools that can come in handy in CKB dApp development. The feature list of Tippy includes:
Start a new CKB blockchain with one click. You can also adjust the blockchain parameters, and even fork the current mainnet/testnet blockchain into a local blockchain.
You can adjust the mining speed of the block. You can mine 3 blocks, roll back 2 blocks, and then mine 1 block. You can also tell Tippy to mine 10 blocks after using a 3 second interval. You can even control the transactions in each block. For example, you can ask Tippy to submit a transaction to CKB, but never go on the chain.
Built-in mini CKB browser to improve the developer experience. It will provide developers with more convenient functions, including transaction visualization, lookup scripts/data hashes, instant cell capacity usage, signature message calculations, etc.
Built-in transaction debugger, all failed transactions will be collected. You can start the debugger for any transaction at any time, and all the binary files of the debugged transaction can be converted into files that conform to the debugging information.
An API layer that can start all the above functions programmatically, which means that Tippy is not only a good friend for debugging, but also a friend for building integration tests.
The first stable version of Tippy is scheduled to be released at the end of the first quarter of 2021. In 2021, we will continue to improve Tippy to provide developers with a better experience.
aML
aML is a new programming language used to write smart contracts for Nervos CKB. The name aML is a recursive abbreviation of “aML is a ML”. Although aML provides a modern programming language with many convenient functions (static typing, pattern matching, garbage collector to simplify memory management), one of the functions is particularly useful in the programming of smart contracts- formal verification: not only this The language is designed with first-class, most advanced, source-level formal verification built in, and the entire compiler from aML to the RISC-V assembly used in CKB VM is also formal-verified. This unique design makes aML stand out from most other programming languages ​​we use today, including C, Rust, JavaScript, etc. We hope that this fully formal-verified language, including a formal-verified compiler, can help and ensure the maximum security of CKB smart contracts.
We plan to release the initial version of aML in 2021 for everyone to use.
Cryptographic primitives
CKB VM is unique from other blockchain virtual machines in that it can provide flexible cryptographic primitive support. As of January 2021, we have not seen a second blockchain virtual machine that supports flexible cryptographic primitives in the form of smart contracts. In 2021, we will continue to work hard in this regard, hoping to bring more cryptographic primitives into the world of CKB:
Effectively realize the elliptic curve alt_bn128. With this, Polyjuice will be fully compatible with Ethereum. Other applications that use this curve can also benefit from it.
Implement BLS signature. Not only Godwoken can use BLS signatures to speed up, but other applications that require aggregation signatures can also benefit from this implementation.
Other cryptographic primitives are also considered here. For example, we will study the possibility of introducing a complete zero-knowledge proof algorithm into CKB VM to achieve more use cases. Once a more detailed plan is formed, we will share it with others.
Interoperability 2.0
Force Bridge
Force bridge is a universal cross-chain framework that promotes asset transfer between blockchains. The first bridge built on this framework is the CKB-ETH bridge, which supports the transfer of CKByte, ETH, sUDT and ERC-20 assets between CKB and Ethereum. The latest version was deployed on the Aggron and Rinkby testnets, and a GliaDEX demo was provided, demonstrating the capabilities of Interoperability 2.0.
In 2021, we will review and deploy the CKB-ETH bridge on the mainnet . There are two directions to go after:
We will choose the second direction first, because the semi-trustless bridge is safe enough for most current use cases, and the new bridge will bring more assets to Nervos dApps and users. We also hope to maintain the first direction after the hard fork, so that if the block header structure changes, we will not waste energy. The initial plan was to build a new bridge between Bitcoin, EOS, TRON and Polkadot.
Gliaswap
In 2021, with the maturity of Force Bridge, Godwoken/Polyjuice and pw-lock, the dream of interoperability 2.0 will be closer than ever.
We have already demonstrated GliaDEX, a demo of the order book mode, on the testnet. The next Gliaswap, it is not just a demo. Gliaswap is an open source DEX template using AMM on Nervos. It is also a complete and ready DEX implementation, including on-chain smart contracts and off-chain components. It provides an easy-to-deploy vanilla AMM by default, which can be used as the basis for more complex DEX. It has the same interoperability as you see in the GliaDEX demo, and it provides better liquidity because any user can contribute liquidity to its liquidity pool. Anyone who has reached the basic technical level can deploy his/her own AMM on Nervos, and any team with qualified programming skills can fork and build their own version of AMM.
As a template project, we hope that Gliaswap will not only show how to build DEX on Nervos, but also inspire developers how to build an interoperability 2.0 dApp, or Uniapp, on Nervos. **Currently the development of Gliaswap is progressing smoothly and is expected to be completed within a few months.
Looking to the future
Hope you enjoy Nervos’s 2021 technology roadmap! The crypto world is changing rapidly. In such a changing environment, it is often difficult to find the right path. I am glad that we have found one, and time is proving the value of this path:
When everyone was talking about PoS, we embraced PoW;
When everyone is pursuing sharding technology, we chose the second layer network;
When you can only find the account model, we explored and expanded the UTXO model.
We make RISC-V a strong competitor of EVM and WebAssembly in the field of blockchain virtual machines. These choices have brought us Interoperability 2.0, and there will be more exciting things to happen. The path that no one walks in the garden, although full of thorns, is also full of magical scenery. We are full of confidence. Let us run wild along our own path, cool like the wind, wild like a dog.
Finally, I would like to thank Ian (CKB), Xuejie (CKB VM, tools) and Wenchao (Force Bridge) for their contributions in relevant chapters.
