- This lite paper is based on the Introduction of CKB Virtual Machine, click for more details about the Nervos CKB Virtual Machine.
Introduction
We considered the features required by the Nervos CKB VM during virtual machine (VM) design for the CKB blockchain. To be suitable for use on a blockchain, a VM must deliver certainty (a given program and input must always compute the same result) and security (the VM must not affect the operation of the host computer).
After considering the design of a VM that will best serve the CKB’s objectives, we have identified a few key features the VM must deliver and determined the best technology to be utilized to deliver these qualities.
Key Requirement #1: Flexibility
Our goal is to design a VM flexible enough to run for decades, allowing the CKB to evolve along with the field of cryptography. As time goes on, older cryptographic techniques may no longer be used and valuable new cryptographic innovations will continue to emerge. With the design of the CKB, we would like to make these innovations available to future users and allow unused functionality to be disregarded.
All blockchains we researched require a hard fork to upgrade their underlying cryptography. With the design of the CKB, we would like to provide freedom of innovation and allow the CKB to utilize new cryptographic primitives such as Schnorr signatures or bulletproofs.
Key Requirement #2: Resource Visibility
After conducting research on existing blockchain virtual machines, we have observed a problem. Programs running on the VM cannot obtain information about the current resource utilization of the VM, restricting use of the full capabilities of the VM.
We have considered providing programs running on the VM the ability to query resource usage, which would allow programs running on the VM to utilize different algorithms based on resource availability. With this design we can ensure the VM can be utilized to its full potential.
We see more VM flexibility enabled in the following scenarios:
- When storing data, contracts can select different policies based on their needs and resources available. When there is ample storage capacity, a program can directly store data on the CKB. When storage capacity is limited, the contract can compress data, utilizing more computation but less storage.
- Different approaches can be selected for utilizing VM memory based on the amount of cell data and size of remaining memory. When there is a substantial remaining memory, all cell data can be read to memory and then the smart contract will be executed. When there is little remaining memory, data can be read to memory as needed and removed as the smart contract executes its instructions.
- For common contracts, such as hash algorithms, a smart contract can utilize different algorithms based on the number of CPU cycles the user has provided in the transaction. For example, SHA3–256 will be less resource intensive and “cheaper” than SHA3–512 and the contract can change at runtime which algorithm is used.
Key Requirement #3: Resource Utilization Calculation
The gas mechanism in the Ethereum virtual machine (EVM) is a brilliant design. With this mechanism, Ethereum is capable of flexible computation on a fully decentralized virtual machine. We have however observed that it is difficult to design a proper gas determination method for different EVM opcodes.
We have found that the gas computation mechanism has been adjusted in almost every version update. We wonder, can we create a straightforward, accurate calculation of computational requirements through VM design?
We have considered the design of a VM that can deliver all of these requirements and have found that there is not an existing solution that can achieve our vision of the CKB.
The CKB VM Architecture
Given the architecture requirements for a VM running on a blockchain, we have chosen to use a real CPU instruction set for the CKB VM. We have identified the following benefits:
Flexibility : Developers can implement data structures and algorithms that best suit their applications on top of the CKB. Native CKB data structures and algorithms are kept to a minimum, maximizing compatibility over time.
Stability : CPU instruction sets designed for hardware are hard to modify once finalized and used in chips, which makes for a very stable base for a blockchain VM. A stable instruction set means less hard forks without sacrificing flexibility.
Resource visibility : The operation of a VM with a real instruction set provides a program executing on the VM the ability to query resource (disk, memory, processor) usage in real-time, maximizing utilization of the VM.
Resource Utilization Calculation : For a VM with real CPU instruction set, resource requirements are easily calculated. Based on the number of cycles required for running each instruction on a real CPU, we can accurately reflect the resource requirements of new algorithms when they are implemented.
Performance Considerations
Utilization of a real CPU instruction set has one key disadvantage compared to VMs that implement cryptographic algorithms through opcodes or native VM instruction sets: performance. However, according to our research and test results, we can optimize the cryptographic algorithms running on the VM.
RISC-V
After the decision was made to go with a real CPU instruction set, the next step was to choose which set to use. Through our research, we have found the RISC-V (https://riscv.org/) instruction set to be the best choice for the CKB VM.
RISC-V is an open-source RISC instruction set architecture (ISA) designed by professors of the University of California, Berkeley beginning in 2010. The aim of RISC-V is to provide a common computer instruction set that will enable the next generation of system architecture development.
RISC-V is suitable for a variety of applications, from low power embedded circuits to data center servers. Compared with other CPU instruction sets, such as the common x86, the RISC-V instruction set has the following advantages:
Openness: Both the core design and implementation of RISC-V are provided under a BSD license, a permissive free software license. All companies and agencies can use the RISC-V instruction set to create new hardware and software without restriction.
Simplicity: As a RISC instruction set, RISC-V has only about 50 instructions compared to thousands of instructions other instruction sets may have. This allows for the same functionality to be implemented with RISC-V easily, with fewer bugs while providing the same functionality.
Modular mechanism: RISC-V is modular, allowing for extended instruction sets to be implemented. For example, the CKB might choose to implement the extensions for vector computing or large integers, providing the possibility of high-performance cryptographic algorithms.
Wide support: The RISC-V instruction set is supported by a number of compilers and has a variety of supported programming languages. The VM implementation of CKB will use the widely implemented ELF format, CKB VM contracts can be developed using any language that can be compiled to RISC-V instructions.
Maturity: The RISC-V core instruction set has been finalized and frozen; all RISC-V implementations in the future are required to be backward compatible. This removes the possibility of a hard fork when upgrading the VM. Additionally, the RISC-V instruction set has hardware implementations and has been verified in real world application scenarios.
Though other instruction sets may have some of the qualities listed above, the RISC-V instruction set is the only one that delivers all of them according to our evaluation. Based on this, we have chosen to implement CKB VM with the RISC-V instruction set and utilize the ELF format for smart contracts to ensure wide language support.
Incentives
We encourage the community to provide more optimized cryptographic algorithm implementations to reduce computational requirements on the CKB. The topic of developer incentives to improve functions of the CKB is interesting and has been frequently discussed among the CKB team. It is our hope that the CKB VM will develop and improve with the evolution of cryptography and community, without the need for hard forks to upgrade the protocol.
Smart Contract Development
Any language that can be compiled to the RISC-V instruction set can be used for CKB contract development. Examples of languages that can be used on the CKB: Ruby, Python, Javascript, EVM bytecode, Bitcoin script.
The following (simplified) figure shows the CKB contract verification model based on a preceding system library:
Input & Output cell capacity
Each input to the transaction references an existing cell. A transaction can overwrite, destroy or generate a cell. The capacity of all output cells in the transaction cannot exceed the capacity of all input cells.
Validation Scripts
Each cell may also contain a validation script to check whether the cell data meets specified conditions. For example, a cell to save tokens would ensure that no additional tokens have been created in a transaction. The validation script will verify the number of tokens in the input cells of the transaction is greater than or equal to the number of tokens in the output cell. For added security, CKB contract developers can also leverage special contracts to ensure the validation scripts of cells can never be modified after cell creation.
Unlock Scripts
The CKB VM utilizes an unlock script to verify that the cell owner has signed the transaction, authorizing the input cell use. If verification of the unlock script is successful, the transaction originator can use the cell referenced by the input and the contract is executed successfully. Otherwise, contract execution and transaction verification fail.
WebAssembly
Some may ask: why does the CKB not use WebAssembly, given the interest it has attracted in the blockchain community?
WebAssembly is a great project and we hope it will be successful. Though WebAssembly has the potential to implement most of the features we have discussed, it does not deliver all of the benefits RISC-V can bring to the CKB VM. RISC-V design began in 2010, the first version was released in 2011, and hardware began to emerge in 2012. However, WebAssembly emerged much later in 2015, with an MVP released in 2017.
While we acknowledge WebAssembly has the potential to become a good VM, RISC-V currently has the advantage over WebAssembly in a blockchain context. We do not completely discard the use of WebAssembly in the CKB VM. We believe we can provide a translator from WebAssembly to RISC-V, ensuring that WebAssembly-based blockchain innovation can be leveraged by the CKB.
Summary
With the design of CKB VM, we aim to build a community around CKB that grows and adapts to new technology advancements freely and where manual intervention (such as hard forks) can be minimized. We believe CKB VM can achieve this vision.
Originally published at medium.com on December 12, 2018 by Matt Quinn, Co-founder of Starfish Mission, a blockchain community hub in San Francisco. Matt is also the founder of SF Ethereum meetup.