Look at the governance and evolution of CKB from Git

Original title: CKB, Version Control and Blockchain Evolution

The original author: NBSP; Jan Xie, Nervos Chinese Community

I'm a fan of Linus. He has created a ubiquitous open source operating system, co-authored a book I love, and built a distributed version control system that almost every developer USES every day.

I started using Git the minute I saw it and was fascinated by its speed and elegance. Developers use version control system & NBSP; 1 & have spent To manage the source code so they can keep track of code updates, share changes with friends and colleagues, roll back to a previously bug-free version if a new error occurs, and so on. & have spentGit makes life more interesting, and I hope CKB can do the same.

CKB is Git

The process of creating CKB and Cell models was inspired by Git. Git was born out of Linus's desire for the ease of Linux kernel development, and people can use it whenever they want to organize something, from comments to blog posts to pictures. It is a knowledge base with excellent history tracking support.

A Git repository is known as a repository and internally maintains an immutable append only object database (remember?). . The basic unit of storage in Git is NBSP; Blob  (binary large object), which is an object that contains data that people store in a repository, like a Cell in CKB. Git creates a BLOB object for each version of each file. Each time a new file is created, a new BLOB is created. Whenever an existing file is modified, a BLOB with new content is created without modifying the old BLOB (sound familiar?). . Each BLOB is hashed, and the BLOB hash is used as an identifier to reference the blob. After a few hours of work, you create some new files and modify some existing files, commit all the changes to the repository, synchronize the new commit to colleagues, and call it a day.

A commit is the basic point of history in Git, and the repository history consists of a series of commits from the repository's origin to the most recent update. A commit is a repository version for a specific time, including version metadata such as author, timestamp, last commit, and reference to blob Tree. Just as the block header saves metadata for each update of the blockchain by writing down the address of the miner, the timestamp, the parent block hash, and the root of the trade Merkle Tree. You and your colleagues are paid to extend the history of the Git repository, just as miners are paid to extend the history of the block.

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 that relies on special point-to-point communications (such as SSH or E-mail) for data exchange.

The similarities between Git and blockchain also mean that we should be more careful about incorporating Git ideas into the blockchain rather than introducing conflicting design choices so that blockchain or smart contract developers can enjoy some of Git's proven benefits.That's what the CKB looks like internally: a single large Git repository with a true P2P network, global consensus, and an enhanced BLOB, updated by a bunch of anonymous people.

This is not a blockchain

Name the Cell the way you like it

At the heart of both Git and CKB are blob/cell data objects and hash references.A hash reference is an inherent name for an object, a wand you can wave to extract the value of the data. If you know the name of an object, you can gain its power by referring to it.On CKB, the code for the smart contract is separate from the user data, so a hash reference lets you directly name a piece of code or user data as a first-class object in the system. 2. This fine granularity creates a flexible and powerful programming pattern. Here are some examples.

Reuse code/data

Because the cell is a referable storage unit, it is easy to reuse code/data on the CKB. Assume that in cell 0xbeef#1 (transaction & NBSP; 0 xbeef & have spent The output & have spent 1) Some Shared code/data is stored in, and to reuse it, you first need to load CELL&Nbsp; 0 xbeef # 1 & have spent As a transaction dependency (cell_deps), then use & NBSP; Ckb_load_cell_data & have spent The system call reads data from it, as shown in the default locking script. Once the data from cell 0xBeef #1 is loaded into VM memory, it's time to consider what you need & NBSP; 3. Treat it as code or data usage. In this way, the CKB ACTS like a code and data sharing library for the smart contracts that run on it.Wouldn't it be cool if we could build a smart contract 4 by combining existing secure Lego bricks?Instead of having to copy code from somewhere on GitHub and deploy the same code over and over again, you waste time and space on the chain. An analysis of ethereum contracts [5][6] shows that 95 to 99 per cent of contracts are duplicated.

The most repeated smart contract on Ethereum

No fear of dependency deletion

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

That's certainly true on Ethereum. If you've been in the field long enough, you probably know about the $280 million accident in 2017. The whole tragedy was triggered by the accidental deletion of Ethereum's last smart contract, which was used by many other smart contracts. This deletion caused all the smart contracts that depended on it to become dysfunctional and all the assets stored in those smart contracts to be frozen.

On CKB, such an accident doesn't matter, because anyone saving a copy of the code (such as those running full nodes or complex light clients) can redeploy the same code on the chain, and the reference to the code hash is still valid. We simply use the new dependent cell to construct the transaction.No one will be harmed and everything will continue to function normally.

Recover from dependency deletion

In fact, we can even take advantage of this on purpose to implement the code's"Use first, deploy later". Suppose you want to protect your cell with a new custom locking script (smart contract). Instead of the usual deploy-before-use process, you can use it without deploying. Simply hash the code for the new lock script (code implementation) into the cell lock (code usage), and the cells are 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 the cells, you first 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 remove the deployed code and call back the occupied CKByte to reduce unnecessary storage costs.The added benefit of using it first and deploying it later is greater privacy: No one knows the logic of the new lock until you unlock it.

The evolution of CKB

With an understanding of the similarities and benefits between CKB and Git, let's explore a more interesting question:If CKB is a Git repository, can we use CKB to manage CKB code?

Yes! This is why some CKB core functions such asTransaction signature verification[8] and & have spentNervos DAO& have spent [9] Are all realized in the form of intelligent contract. Take transaction signature verification -- a core function of almost all blockchains and hard-coded in native languages (like Bitcoin in C or Go-ethereum in GO).

To upgrade the blockchain, one must distribute and deploy new software versions (soft/hard forks) on most nodes, which requires a lot of coordination.For CKB, transaction signature verification can be updated just like any other smart contract by deploying the new version along the chain. This gives CKB the long-term upgradability proposed by Tezos [10].

We can do better. On the CKB,Each user owns their own data, so a contract is more like a two-party agreement between the user and the CKB, where the individual can make an independent choice.If you use a contract by hashing the code, it means"I 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 hash of the new contract is different and your lock/ Type will still refer to the old contract instead of the new one. When the new version is deployed, it coexists 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, then you can update all cells to use the new version. If it is no, nothing needs to be done and the old version continues to be used.

This is a friendly guarantee for holders who may not be online often, as they can guarantee that the contract attached to their cell at creation time will not be changed.People's assets will always be locked in the way they were locked in. This is the ultimate guarantee for SoV users and why CKB assets are different from other assets on the blockchain.This is the same way that Bitcoin protects its holders by "following only a soft fork". The only downside is that when you do a security upgrade, you risk being "too late." Therefore, for convenience, some people may prefer to use the latest version all the time because they trust the development team not to worry about reviewing the contract and upgrading manually, in which case they will refer to the contract using the Type ID [12]. In general, the Type ID is similar to the HEAD in Git, where an updatable reference always points to the current version.By providing both options (through code hash references and Type ID references) we give the user back the right to choose the appropriate upgrade policy.It's always good to have a choice. We can have different choices and no one will be forced to upgrade.

System script upgrade

In the long run, CKB will become more abstract and modular, and more core functions will be extracted and implemented in smart contracts along the chain. In its full form, we should be able to upgrade the CKB without a soft/hard fork. The missing link is, how do we, the community, decide whether or not to upgrade the system contract, or what is the governance model for the CKB? More precisely, how we decide to upgrade the Type ID of a system contract.

Today, CKB USES the same down-chain governance model as Bitcoin, and we still rely on a soft/hard fork. In order for someone using their Type ID reference to enable the new version of the system script, a hard fork is required to update the Type ID reference to point to the latest version, because the code cell is locked by an unlocked lock(https://explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga, check it hash code). Not using multi-signed signature locks controlled by the core team is a conscious choice, as system script upgrades should follow governance decisions made by the community.

As we see in NBSP; Positioning the white paper & NBSP; ", we do not yet see a workable governance model, although there are many interesting proposals.Once we find the appropriate governance model, we can replace ununlocked locks with "governance locks" and let the system smart contract be upgraded with community consent, such as the result of a vote. Until then, we will stick to the imperfect chain governance model for the time being, but the backbone of CKB governance and evolution already exists.

Ref:

[1] : https://en.wikipedia.org/wiki/Version_control

[2] : https://talk.nervos.org/t/first-class-asset/405

[3] : https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_helper.h#L40-L66

[4] : https://talk.nervos.org/t/rfc-swappable-signature-verification-protocol-spec/4802

[5] : https://www.researchgate.net/publication/332799463_Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem

[6] : https://security.cse.iitk.ac.in/sites/default/files/17111011.pdf

[7] : https://medium.com/hackernoon/what-caused-the-latest-100-million-ethereum-bug-and-a-detection-tool-for-similar-bugs-7b80f8ab7279
[8] : https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_blake160_sighash_all.c
[9] : https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/dao.c
[10] : https://tezos.com/
[11] : https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#upgradable-script
[12] : https://docs.ckb.dev/blog/ckbscript-06

Text link:https://mp.weixin.qq.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia