Today we continue to talk about a project that has exploded recently, which is Nervos Network (CKB). It has increased five times from the lowest point in one month. It can also be regarded as a hierarchical public chain. Its current market value has reached 490 million US dollars, and its ranking has entered It has reached 119th place, so let’s take a look at the potential of this project today.
Introduction
Nervos is a layered cryptoeconomic network. Nervos divides the infrastructure of the crypto-economy into two layers: a verification layer (layer 1) that serves as a root of trust and smart custodian, and a generation layer (layer 2) for high-performance transactions and privacy protection.
CKB generates trust and extends this trust to upper layers, making Nervos a trust network. It also serves as the store of value for the Nervos network, providing public, secure, and censorship-resistant escrow for assets, identities, and other public knowledge created in the network.
1. CKB
Nervos CKB (Common Knowledge Base) is a first-layer blockchain, a decentralized and secure layer that provides the network with hosting of common knowledge. Common knowledge refers to a state verified by global consensus.
In Nervos, CKB and all second-layer protocols work together to provide services for the crypto-economy. The CKB (or first layer) is where state is stored and defined, while the second layer is the generation layer (or computation layer, the two terms are interchangeable), which is responsible for processing most transactions and generating new state. Second-tier participants ultimately submit the newly generated state to CKB when they deem necessary. If these states pass the corresponding verifications performed by nodes in the global network, CKB securely stores them in peer-to-peer nodes.
The layered architecture separates state and computation, providing each layer with greater flexibility and scalability. For example, blockchains located in the generation layer (layer 2) can use different consensus algorithms. CKB is the lowest layer, has the broadest consensus, and provides the most secure consensus in the Nervos network. However, different applications may prefer different consensus scopes, and forcing all applications to use CKB's consensus would be inefficient. Applications can choose the appropriate generation method based on their specific needs. The only time these applications need to submit state to CKB for broader protocol agreement is when they need to make these states, validated by the CKB global consensus, common knowledge.
Possible state generation methods include (but are not limited to) the following:
1. Local generator on the client: The generator runs directly on the client device. Developers can implement generators using any programming language.
2. Web services: Users can use traditional Web services to generate new states. All current web services can work with CKB in this way to gain more trust and liquidity in the generated state. For example, a game company can define in-game items as assets in CKB, and the game itself acts as a Web service to generate game data, which is then verified and stored in CKB.
3. State channel: Two or more users can use point-to-point communication to generate new states.
4. Generation Chain: The generation chain is a blockchain that generates new states and stores them in CKB. The resulting chain can be a permissionless blockchain or a permissioned blockchain. In each generated chain, nodes reach consensus on a smaller scale, providing better privacy and performance.
CKB includes a proof-of-work based consensus, a virtual machine based on the RISC-V instruction set, a cell-based state model, a state-based economic model, and a peer-to-peer network. Proof-of-work based consensus makes CKB a public and censorship-resistant service. The combination of the CKB virtual machine and the cell model creates a stateful, Turing-complete programming model for developers, making state generation (or second layer) practical on top of CKB. CKB’s economic model is designed to achieve custody and long-term sustainability of common knowledge. CKB's peer-to-peer network provides secure and optimized communication for different types of nodes.
2. Consensus
The CKB consensus is an improved Nakamoto consensus based on proof of work, aiming to achieve openness, correctness and high performance in a distributed environment with network delays and Byzantine node failures.
CKB consensus is a variant of Nakamoto consensus, which means it allows nodes to join and exit the network freely. Each node can participate in the consensus process by mining (running a specific algorithm to find proof of work) to generate new blocks, or verify that new blocks are valid. CKB uses an ASIC-neutral proof-of-work function designed to distribute tokens as evenly as possible and make the network as secure as possible.
3. Compile model
The CKB programming model consists of three parts:
1. State generation (off-chain): In this model, the decentralized application logic is divided into two parts (generation and verification), which run in different places. State generation logic runs off-chain on the client side; new states are packaged into transactions and broadcast to the entire network.
2. State Verification (CKB VM): CKB transactions have an input/output-based structure similar to Bitcoin. Transaction inputs are references to previous outputs, and proofs of unlocking them. The client includes the generated new state as transaction output, which are called Cells in CKB. Cells are the main state storage units in CKB and are assets owned by users that must follow the associated application logic specified by scripts. The CKB VM executes these scripts and verifies the attestations contained in the input to ensure that the user is allowed to use the referenced Cells and that state transitions are valid within the specified application logic. In this way, all nodes in the network verify that the new state is valid and keep these states safe.
3. State storage (cell model): The state in CKB is the most important component. The state is included in transactions and blocks and is directly synchronized between nodes. Although the programming model is stateful, scripts running in the CKB VM are pure functions with no internal state, which makes CKB scripts deterministic, conducive to parallel execution, and easy to compose.
4. Status generation and verification
Decentralized applications on Nervos separate the generation and verification of state. Although these processes occur in different places, CKB provides additional flexibility to leverage different algorithms for state generation and verification.
Using the same algorithm on both the generation and validation sides is a straightforward choice and suitable for general problems. In this model, there are two implementations of the same algorithm, one running offline in any execution environment of the application target and the other running online in the CKB VM. New states are generated offline by this algorithm (based on previous states and user input), packaged into transactions, and then broadcast to the network. CKB nodes run the same algorithm on-chain, providing the same previous state and user input, and then verify that the results match the output specified by the transaction.
This separation of state generation and validation has several advantages:
1. Deterministic transactions: The certainty of transaction execution is one of the core pursuits of decentralized applications. If a transaction only includes user input and the new state is the result of a calculation on the node (as seen in Ethereum), the transaction creator cannot determine the context of the on-chain calculation, which can lead to unexpected results. In CKB, users generate new state on the client side. They can confirm the new state before broadcasting the state transition to the network. The transaction result is certain: either the transaction passes on-chain verification and the new state is accepted, or the transaction is considered invalid and no state change occurs in CKB.
2. Parallelism: If transactions only include user input, and new states are generated by nodes, then nodes will not know what states will be accessed by the verification process, nor can they determine the dependencies between transactions. In CKB, because transactions explicitly contain the previous state and the new state, nodes can see the dependencies between transactions before validating them and can process transactions in parallel.
3. Higher resource utilization: Because application logic is split and run in different places, the network can more evenly distribute computing workloads to nodes and clients, and therefore utilize system resources more efficiently.
4. Flexible state generation: Even using the same algorithm, developers can implement generation and verification in different ways. On the client side, there is flexibility in choosing a programming language that provides better performance and rapid development.
5. Cell
Cell is the main state unit in the Nervos blockchain, in which users can include arbitrary states. A Cell has the following fields:
1. Capacity - Cell size limit. The size of a Cell is the total size of all fields contained in it.
2. Data - state data stored in Cell. It can be empty, but the total number of bytes used by the Cell (including data) must always be less than or equal to its capacity.
3. Type - Status Verification Script.
4. Lock - a script that represents Cell ownership. The owner of a Cell can transfer the Cell to another person.
Cell is an immutable object and cannot be modified after creation. Each Cell can only be used once and cannot be used as an input for two different transactions. Cell "update" marks previous Cells as history and creates new Cells with the same capacity to replace them. By constructing and sending a transaction, the user provides a new Cell with a new state and atomically invalidates the previous Cell that stored the old state. The set of all current (or active) Cells represents the latest version of all public knowledge in the Nervos blockchain, while the set of historical (or deleted) Cells represents all historical versions of public knowledge.
CKB allows users to transfer the entire capacity of a Cell at once, or only a part of the Cell capacity, which will result in the creation of more Cells (for example, a Cell with a capacity of 10 bytes can become two Cells with a capacity of 5 bytes) .
Two types of scripts (types and locks) are executed in the Nervos VM. When a Cell is created in a transaction output, the CKB VM executes type scripts to ensure that the state in the Cell is valid under specific rules. When a Cell is referenced by a transaction input, the CKB VM executes the lock script, passing the certificate as a parameter to ensure that the user has the appropriate permissions to update or transfer the Cell. If the execution of the lock script returns true, the user is allowed to transfer the Cell or update its data according to the validation rules specified by the type script.
This type and lock script combination allows a variety of possibilities, such as:
1. Scalable cryptography - Anyone can deploy useful cryptography libraries written in C or C++ and use them in type and lock scripts. In CKB VM, there are no hard-coded cryptographic primitives and users are free to choose any cryptographic signature scheme to sign transactions.
2. Multi-signature - Users can easily create M-of-N multi-signature or more complex lock scripts.
3. Lending - Cell owners can lend the Cell to others while still retaining ownership of the Cell.
Compared with the UTXO model or the account model, the Cell model is a more general state model. Both the UTXO model and the account model can express the relationship between assets and owners. The UTXO model defines the ownership of assets through lock scripts, while the account model defines ownership of assets through account balances. The UTXO model makes ledger history clearer, but its lack of universal state storage makes it harder to use scripts that are already less expressive. The account model is easy to understand and supports authorization and identity well, but has challenges in processing transactions in parallel. The Cell model with locks and type scripts combines the advantages of these two models to provide a more general state model.
6. Virtual machine
Virtual Machine (VM)
CKB VM is a virtual machine based on the RISC-V instruction set for executing type and lock scripts. It uses only standard RISC-V instructions to maintain a standards-compliant RISC-V software implementation with the broadest industrial support. CKB implements cryptographic primitives as plain assembly running on its virtual machine, rather than custom instructions. It supports system calls (syscalls) through which scripts can read metadata from CKB such as current transactions and general information about the blockchain. The CKB VM defines cycles for each instruction and provides the total cycles executed during transaction verification to help miners determine transaction fees.
CKB VM is a password-agnostic virtual machine. There are no special encryption instructions hardcoded in the CKB VM. New cryptographic primitives can always be deployed and used by scripts like normal libraries. Being a RISC-V compliant implementation means that existing cryptographic libraries written in C or other languages can be easily ported to the CKB VM and used by cell scripts. CKB even implements default hash functions and public key cryptography used in transaction verification in this way. Cryptographic independence allows decentralized application developers on Nervos to use any new cryptography they like (such as Schnorr signatures, BLS signatures, and zkSNARKs/zkSTARKs) without affecting other users, and enables CKB users to operate in the post-quantum era Maintain the security of its assets.
seven. network
We can divide CKB nodes into three types:
1. Mining node: a node that participates in the CKB consensus process. Mining nodes collect new transactions, package them into blocks, and generate new blocks when proof of work is found. Mining nodes do not have to store the entire transaction history, only the current set of cells.
2. Full nodes: validate new blocks and transactions, relay blocks and transactions, and choose the branch on the chain they agree on. Full nodes are the validators of the network.
3. Light nodes: Trust full nodes and only subscribe to and store the subset of cells they care about. They use minimal resources. As users increasingly rely on mobile devices and mobile applications to access the Internet, light nodes are designed to run on mobile devices.
Currently, unified blockchain networks, where each node has the same role and performs the same functions, face serious challenges. Full nodes verify all blocks and transaction data, requiring minimal external trust, but resulting in higher costs and operational inconvenience. Light clients provide a better user experience by trading minimal trust for significantly lower costs in transaction verification. In a mature cryptoeconomic network, the largest node group will be light nodes, followed by full nodes and mining nodes. Since light nodes rely on full nodes for status and state verification, a large number of light nodes will require a large number of full nodes to provide services for them. With CKB's economic model, the computing and storage resources required for full nodes can be kept at a reasonable level, and the threshold for running full nodes is low, resulting in a large number of service providers providing services for light nodes and a highly decentralized network.
8. Team and development history
The biggest innovation of Nervos lies in the hierarchical design of Layer1 and Layer2. The first-layer network is the basic network, and a POW mechanism similar to Bitcoin is used to encourage miners to mine and maintain the network. At the same time, the second-layer network constructed has launched a complete DAPP development package and component tools , in the economic model, CKB is both the storage resource of the first-tier network and the pledge token of the second-tier application. In addition, the Nervos team has a luxurious background. The architect Xie Hanjian is the co-founder and CEO of Miyuan Technology and a former member of the Ethereum core research team. The team members also include former imToken co-founder and CTO Lu Guoning, cryptographer Zhang Ren, Spark mining pool members, etc. In July 2018, it received US$28 million in investment led by Sequoia Wanxiang, raised US$67.2 million from the public in October 2019, and launched its mainnet in November 2019.
9. Ecology
Currently, the official website shows that there are 139 ecological items, including DID, inscription, wallet, DAO, DEFI, second layer, NFT, infrastructure, trading market, etc.
10. Token economy
The current total number of tokens is 44,247,326,785, and 43,553,719,619 have been circulated. It can be considered that it has basically been circulated. However, it has inflation. The current currency price is around 0.01, with the peak at 0.04 (21 years), 1.344 billion CKB/year, and the token distribution is created. 25% will be destroyed, 20% will be sold to the public, 18.5% for ecological funds, 15% for the team, 14% for private placement, 5% for strategic cooperation, and 2% for the foundation.
Finally, let’s summarize this project. This project is also a relatively early project. Although there are certain innovations in technology, it is not very big. It is also layered on the basis of Bitcoin, and is similar to the current mainstream layer2 and For modular public chains, the narrative power is slightly insufficient, and the ecology has not emerged with very good projects. Judging from the last bull market, there has not been a big increase, and this increase is still due to the low value. Because we see that its public offering price is only 0.01, and the current currency price has increased five times to only 0.01, so it was a relatively underestimated range before. It is not because the project is very good. As for the token strategy, we are still on the planet. Description. #内容挖矿