CKB governance and evolution from Git

Original title: "CKB, version control and blockchain evolution"

Original author: Jan Xie, Nervos Chinese Community

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

I started using Git the moment I saw it and was attracted by its speed and elegance. Developers use version control systems 1 to manage source code so that they can keep track of code updates, share modifications with friends and colleagues, roll back to a previous bug-free version when new errors appear, etc. Git makes life more interesting, and I hope CKB can do the same.

CKB is Git

We were inspired by Git in the process of creating CKB and Cell models. Git emerged out of Linus's desire to facilitate 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 called a "repository" and maintains an immutable, append-only database of objects internally (remember it?). The basic storage unit in Git is a Blob, 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 an existing file is modified, a blob with the 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 refer to 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, sync the new commits to your colleagues, and call it a day.

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 version of the repository at a specific time, including version metadata such as the author, timestamp, previous commit, and reference to the blob tree. Just like the block 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 like 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 the "correct" one is decided by the repository maintainer, not by consensus. Git is a distributed system without consensus, relying on ad hoc peer-to-peer communication (like ssh or email) for data exchange.

The similarities between Git and blockchain also mean that we should be more cautious in incorporating Git ideas into blockchains, rather than introducing conflicting design choices into blockchains, 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 repository with a true p2p network, global consensus, and enhanced blobs, which is constantly updated by a group of anonymous people.

This is not a blockchain

Name the Cell as you like

At their core, both Git and CKB are data objects (blobs/cells) and hash references. A hash reference is an intrinsic name for an object, a magic wand you can wave to extract the value of the data. If you know the name of an object, you can reference it, thereby gaining its power. On CKB, smart contract code and user data are separated, so hash references allow you to directly name a piece of code or user data, making them first-class objects in the system 2. This fine granularity creates a flexible and powerful programming model. Here are some examples.

Reuse code/data

Because cells are referenceable storage units, it is easy to reuse code/data on CKB. Assuming there is some shared code/data stored in cell 0xbeef#1 (output 1 of transaction 0xbeef), to reuse it, you first need to load cell 0xbeef#1 as a transaction dependency (cell_deps) and then read the data from it using the ckb_load_cell_data system call, as shown in the default lock script. Once the data in cell 0xbeef#1 is loaded into the VM memory, it can be used as code or data depending on your needs 3. In this way, CKB is like a code and data sharing library for smart contracts running on it. Wouldn’t it be cool if we could build a smart contract 4 by combining existing secure Lego blocks? Without copying the code from somewhere on GitHub and deploying the same code again and again, which is a waste of time and space on the chain. An analysis of Ethereum contracts[5][6] showed that 95%~99% of contracts are duplicated.

The most duplicated 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 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 deletes it from CKB? Would that make my smart contract unusable?

This is certainly the case with Ethereum. If you’ve been in the space long enough, you’ll probably know about the $280 million accident in 2017[7]. The whole tragedy was triggered by the accidental deletion of a smart contract on Ethereum that 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 were frozen.

On CKB, such an accident will not cause any impact, because anyone who keeps a copy of the code (such as those running a full node or a complex light client) can deploy the same code again on the chain, and the reference to the code hash will still be valid. We just need to construct the transaction with the new dependency cell. No one will lose money, and everything will still work normally.

Recovering from Dependency Removal

In fact, we can even intentionally use this to implement " use before deployment " of code. Suppose you want to use a new custom locking 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 locking script (code implementation) into the cell lock (code use), and then these 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 to unlock the cells as usual. After the cell is unlocked, you can delete the deployed code and claim back the occupied CKBytes to reduce unnecessary storage costs. The additional benefit of using it first and deploying it later is better privacy: no one knows what the logic of this new lock is until you unlock it.

Evolved CKB

After understanding the similarities and advantages between CKB and Git, let's explore a more interesting question: If CKB is a git repository, can we use CKB to manage CKB's code?

Yes! This is why some CKB core functions, such as transaction signature verification [8] and Nervos DAO [9], are implemented as smart contracts. Take transaction signature verification as an example - this is a core function of almost all blockchains and is hard-coded in the native language (for example, C in Bitcoin and Go in go-ethereum).

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

We can do better. On CKB, every user owns their own data, so a contract is more like a two-party agreement between the user and CKB, and individuals can make independent choices. If you use a contract by code hash[11], it means " I agree to this specific version of the contract ." You don't have to worry about the developer upgrading the contract code one day, because the code hash of the new contract will be different, and your lock/type will still reference the old contract instead of the new one. After the new version is deployed, it will coexist with the old version in the system. If you use a system contract by its code hash, the new version will not affect you, and you can decide whether to upgrade. If the answer is yes, then you can update all cells to use the new version. If it is no, then you don't need to do anything and continue to use the old version.

This is a friendly guarantee for holders who may not be online often, because they can be sure 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 specified when they locked it. This is the ultimate guarantee for SoV users and what makes CKB assets different from assets on other blockchains. This is the same as Bitcoin's "only follow soft forks" approach to provide holders with guarantees. The only downside is that you run the risk of being "too late" when it comes to security upgrades. Therefore, for the sake of convenience, some people may still like to always use the latest version because they trust the development team and don't need to worry about reviewing the contract and manually upgrading. In this case, they will use type id[12] to reference the contract. Roughly speaking, type id is similar to HEAD in Git, an updateable reference that always points to the current version. By providing these two options (referenced by code hash and referenced by type id) we give the right to choose the appropriate upgrade strategy back to users. It is always good to have choices. 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 on-chain smart contracts. In its complete form, we should be able to upgrade CKB without soft/hard forks. The missing link is how do we, the community, decide whether to upgrade the system contract or not, or what is the governance model of CKB? More precisely, how do 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 forks. In order for people using its type id references to enable a 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 unlockable lock (https://explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga, check its code hash) . Not using a multi-signature lock controlled by the core team is an intentional choice, as upgrades to system scripts should follow governance decisions made by the community.

As we said in our positioning whitepaper, while there are many interesting proposals, we have not yet seen a practical governance model. Once we find the right governance model, we can replace the unlockable lock with a "governance lock" to allow the system smart contract to be upgraded with community consent, such as the result of a vote. Until then, we will temporarily stick to the imperfect off-chain governance model, but the backbone of CKB governance and evolution is already there.

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

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