CKB, version control and blockchain evolution


from Jan

I’m a fan of Linus. He created a ubiquitous open source operating system, CO authored a book I love very much, and built a distributed version control system that almost every developer uses every day.

I started using git the moment I saw GIT and was attracted by its speed and elegance. Developers use version control system [1] to manage source code, so that they can keep abreast of code updates, share changes with friends and colleagues, and roll back to a bug free version when new errors occur.Git makes life more interesting and I hope CKB can do the same.


CKB, version control and blockchain evolution
We were inspired by git in the process of creating CKB and cell models. Git was born out of Linus’ desire for the convenience of Linux kernel development. People can use git whenever they want to organize something, from comments to blog posts to pictures. It is a knowledge base with excellent history tracking support.

Git repository is called “repository” and maintains an immutable appendable object database internally (remember?). The basic storage unit in Git isBlob(binary large object), which is an object that contains the data that people store in the repository, just like a cell in CKB. Git creates a blob object for each version of each file. Whenever a new file is created, a new blob is created. Whenever you modify an existing file, you create a blob with new content instead of modifying the old one (does that sound familiar?). Each blob is hashed, and the blob hash is used as an identifier to reference the blob. After working for a few hours, you create some new files and modify some existing files, then commit all the changes to the repository, synchronize the new submissions to colleagues, and you’re done.

A commit is the basic historical point in git, and the repository history consists of a series of commits from the origin of the repository to the most recent update. A commit is a repository version at a specific time, including version metadata such as author, timestamp, previous commit, and reference to blob tree. Just as the chunk header saves metadata for each update of the blockchain by writing down the miner address, timestamp, parent block hash, and the root of the transaction Merkle tree. You and your colleagues get paid by extending the history of the GIT repository, just as miners get block rewards by extending the history of blocks.

Git repositories can also have forks. People work on different branches, but which branch is “right” is determined by the repository maintainer, not by consensus. Git is a distributed system without consensus, which relies on special point-to-point communication (such as SSH or email) for data exchange.

There are similarities between GIT and blockchain, which also means that we should be more careful to integrate git ideas into the blockchain, rather than introduce conflicting design choices into the blockchain, so that blockchain or smart contract developers can enjoy some of GIT’s proven advantages.This is what CKB really looks like inside: a unique large git library with a real P2P network, global consensus and enhanced blobs, constantly updated by a group of anonymous people.
CKB, version control and blockchain evolution
This is not a blockchain

Name the cell the way you like

The core of GIT and CKB are data objects (blob / cell) and hash references.Hash reference is the inherent name of an object. It is a magic wand you can wave to extract the value of data. If you know the name of an object, you can gain its power by referring to it.In CKB, the code of smart contract is separated from user data, so hash reference can let you name a piece of code or user data directly, and make them become the first level object in the system [2]. This fine granularity creates a flexible and powerful programming model. Here are some examples.

Reuse code / data

Because cells are referential storage units, it’s easy to reuse code / data on ckbs. Suppose that in cell 0xbeef ා 1 (transaction0xbeefThe output of1)Some shared code / data is stored in. To reuse it, you need to load the cell first0xbeef#1As a transaction dependency (cell_ DEPs), and then use theckb_load_cell_dataThe system call reads data from it, as shown in the default lock script. Once the data in cell 0xbeef ා 1) is loaded into VM memory, it can be treated as code or data usage according to your needs [3]. In this way, CKB is similar to a code and data sharing library for smart contracts running on it.If we can build a smart contract by combining existing security Lego blocks[4],Isn’t it cool?Instead of copying code from somewhere on GitHub and deploying the same code over and over again, it’s a waste of time and space on the chain. An analysis of Ethereum contracts [5] [6] shows that 95% – 99% of the contracts are repetitive.

CKB, version control and blockchain evolution
The most repeated smart contracts on Ethereum

Fearless dependency deletion

In the code / data reuse example above, you don’t need to worry about someone modifying the code / data stored in the dependent cell, because the cell is immutable, that is, no one has a way to modify it.But what if the owner of the dependent cell directly removes it from CKB? Will that make my smart contract unusable?

This is true on Ethereum. If you stay in this field long enough, you may know about the $280 million accident in 2017 [7]. The whole tragedy was caused by the accidental deletion of a smart contract on Ethereum, which was used by many other smart contracts. This deletion has resulted in the dysfunction of all smart contracts that rely on it, and all assets stored in these smart contracts are frozen.

On CKB, such an accident doesn’t make any difference, because anyone who keeps a copy of the code (such as those running full node or complex light clients) can deploy the same code again on the chain, and the reference to the code hash is still valid. We just need to use the new dependent cell to construct the transaction.No one is going to suffer, and everything will still work.

CKB, version control and blockchain evolution
Recover from dependency deletion

In fact, we can even use this to implement theUse before deployment」。 Suppose you want to use a new custom lock script (smart contract) to protect your cell. Unlike the usual deploy before use process, you can use it without deployment. Just put the code hash of the new lock script (code implementation) into the cell lock, and the cells will be protected by the new lock and take effect immediately.

The deployment of the actual locking script code can be delayed until you want to unlock the cells. If you want to unlock, you first need to deploy the script code on the chain, and then send another transaction as usual to unlock the cells. After the cell is unlocked, you can delete the deployed code and retrieve the occupied ckbyte to reduce unnecessary storage costs.The added benefit of use before deploy is better privacy: no one knows what the logic of the new lock is until you unlock it.

Evolutionary CKB

After understanding the similarities and advantages between CKB and git, let’s explore a more interesting problemIf CKB is a git library, can we use CKB to manage the code of CKB?

yes! That’s why some of the core functions of CKB, such asTransaction signature verification[8] AndNervos DAO[9] It’s all in the form of smart contracts. Take transaction signature verification as an example – this is the core function of almost all blockchains, and is hard coded in native languages (for example, C is written in bitcoin, and go is written in go Ethereum).

In order to upgrade the blockchain, people have to distribute and deploy new software versions (soft / hard fork) on most nodes, which requires a lot of coordination.For CKB, transaction signature verification can be upgraded by deploying a new version on the chain like other smart contracts. This gives CKB the long-term scalability proposed by tezos [10].

We can do better. On CKB, each user has his own data,So a contract is more like a two-party agreement between the user and CKB, and the individual can make an independent choice。 If you use the contract through the code hash [11], it means thatI agreed to this particular version of the contract」。 You don’t have to worry that one day developers will upgrade the contract code, because the code hash of the new contract is different, and your lock / type will still refer to the old contract instead of the new contract. After the new version is deployed, it will coexist with the old version in the system. If you use the system contract through its code hash, the new version will not affect you, and you can decide whether to upgrade or not. If the answer is yes, you can update all cells to use the new version. If it’s no, nothing needs to be done and the old version continues.

This is a friendly guarantee for holders who may not be online often because they can guarantee that the contracts attached to their cells at the time of creation will not be changed.People’s assets will always be locked in the way they specify when they lock in. This is the ultimate guarantee for SOV users and the reason why CKB assets are different from other assets on the blockchain.This is the same as bitcoin’s “soft fork only” approach to protect its holders. The only drawback is that you need to take the risk of “too late” when performing security upgrades. Therefore, for convenience, some people may prefer to use the latest version all the time, because they believe that the development team does not need to worry about reviewing the contract and upgrading manually. In this case, they will use type ID [12] to refer to the contract. In general, type ID is similar to head in GIT. An updatable reference always points to the current version.By providing these two options (by code hash reference and type ID reference), we give the user the right to choose the appropriate upgrade strategy.It’s always good to have a choice. We can have different choices and no one will be forced to upgrade.

CKB, version control and blockchain evolution
System script upgrade

In the long run, CKB will become more and more abstract and modular, and more core functions will be extracted and implemented in the smart contract on the chain. In its complete configuration, we should be able to upgrade CKB without using soft / hard fork. The missing link is how the community decides whether to upgrade the system contract or not, or what is the governance mode of CKB? More precisely, it’s how we decide to upgrade the type ID of a system contract.

Today, CKB uses the same off chain governance model as bitcoin, and we still rely on soft / hard fork. In order for the person using its type ID reference to enable the new version of the system script, a hard fork is needed to update the type ID reference to point to the latest version, because the code cell is locked by an unlocked lock(… Check its code hash). It is an intentional choice not to use multi signature locks controlled by the core team, because the upgrade of system scripts should follow the governance decisions made by the community.

As we said in the positioning white paper, although there are many interesting suggestions, we have not yet seen a practical governance model.Once we have found a suitable governance model, we can use “governance lock” to replace the non unlocking lock, so that the system smart contract can be upgraded with the consent of the community, such as voting results. Before that, we will temporarily adhere to the imperfect off chain governance model, but the backbone of CKB governance and evolution already exists.














Recommended Today

Construction and basic use of GIT server in Linux environment (CentOS 7 version)

Server side: 1. Install Git 1.1 install git from yum yum –y install git 1.2 verify that the installation is successful git –version If the current version number is displayed, the installation is successful 2. Create git’s exclusive management account and password 2.1 create git account adduser git 2.2 set the password of GIT account […]