Verification, Computation and the Internet of Value

Toya B
Nervos Network
Published in
5 min readJun 19, 2019

by Jan Xie

Photo by Freddie Collins on Unsplash

Understanding Tradeoffs in Designing a Blockchain

Bitcoin’s UTXO model

Bitcoin saves the ledger in parts, using UTXOs to store the knowledge of who owns a certain chunk of bitcoin.

A UTXO, short for Unspent Transaction Output, is actually the output included in a transaction(CTxOut). A CTxOut is quite simple in structure, which includes only two fields:

class CTxOut
{
public:
CAmount nValue;
CScript scriptPubKey;

}

Every CTxOut represents a coin worth nValue. scriptPubKey is a script which indicates the owner of the coin (and usually includes the public key of the owner). Only the person who provides the right parameters that make the script run successfully can “transfer” the coin to another person.

Destroy and create UTXOs in transaction processing

Note the quoted “transfer” above mentioned. When a coin is transferred, it does not simply alter or replace the scriptPubKey in it, but rather destroys it and creates a new one. Every Bitcoin transaction will destroy some coins and create new ones, whose value and owner will change. The total value of the newly-made output coins must be less than or equal to the value of the destroyed input coins, to ensure people aren’t spending bitcoin they don’t have.

A UTXO model has the following features:

1. Coin (Asset) is the most essential element in the system;

2. Owner is an attribute of coin, so each coin has only one owner;

3. Coins are constantly being destroyed and created;

So how does this translate from the UTXO model to the cell model?

The main role of Layer 1 is to provide global consensus on state, so the design of CKB Layer 1 also lays emphasis on state.

In the Bitcoin protocol, the output of a transaction and the new state are the same object because the Bitcoin architecture is centered on states.

With Ethereum, transaction history and state history are two different dimensions. Blocks and transactions represent the events that trigger state transfer, instead of the states themselves.

The Cell Model

A state verified and held by CKB is not simply a number (nValue), but any data that is considered as valuable and recognized by all the actors. As long as nValue is modified to be a space that can store not just integers, but also any other data, we have a more generalized ‘nValue’, called a ‘Cell’. The native asset of the CKB network is consensus state, storage space for data to be validated by global consensus.

pub struct CellOutput{
pubcapacity: Capacity,
pubdata: Vec<u8,
publock: Script,
pubtype_: Option<Script,
}

In a Cell, nValue is replaced by ‘capacity’ and ‘data’. Together these two fields represent a storage space. ‘Capacity’ is an integer that holds the size of the storage space (in bytes), while ‘data’ holds the bytes that represent the state.

The Cell model also introduces the concept of lock script, which is similar to scriptPubKey, to refer to the owner of the Cell. Only the person who can produce the parameters (such as a signature) required by the lock script can “update” the state of the Cell. Just like with ‘data’, the bytes occupied by CellOutput must not be more than the Cell’s ‘capacity’ value.

In Bitcoin, the set of all unspent UTXOs forms the current state of the Bitcoin network. CKB contains a large number of Cells: the set of all of these Cells forms the current state of CKB, which stores not just a ledger for digital currency, but more diverse common knowledge.

The state of CKB is a Set of Cells

Like in Bitcoin, a CKB transaction itself is the change/transfer of a state. The change of state, or “update” of Cell content, is done through Cell destruction and Cell creation, which means the content of the original Cell is not directly changed. Every transaction actually destroys some Cells and creates new ones, the newly-created Cells will have new owners and store new data.

Bitcoin protocol checks the ‘nValue’ of inputs and outputs to make sure bitcoin is not being created by a transaction. The CKB ensures that no one can generate additional storage space in the same way, by requiring that the destroyed ‘capacity’ is larger than or equal to the newly-created ‘capacity’.

As the native asset of the CKB network, ‘capacity’ represents space for consensus state, which a transaction can transfer but never generate. When a Cell is destroyed, it is simply marked as “destroyed” in the same way a UTXO is marked as “spent”, instead of being removed from the blockchain. Every Cell can only be destroyed once, just as every UTXO can only be spent once.

Consensus state refers to bytes that the CKB network validates and reaches consensus on.

A Cell model has the following features and is essentially a generalized version of the UTXO model.

1. State is the most essential element in the system;

2. Owner is an attribute of state, so each state has only one owner;

3. States are constantly being destroyed and created;

The Cell model Verify

Only having space to store any state is not enough. The reason why Bitcoin is valuable is that every transaction needs to be validated by each of the full nodes in the network, so that all users can ensure the rules written in the Bitcoin protocol are being followed (and users know that others believe that the rules are being enforced). The concept of common knowledge is also derived from this. If anyone ensures that what he or she knows is also recognized by others, the information they agree on is called common knowledge.

In the blockchain system, it is known that the data can be verified independently and recognized by any actor. This is the reason why common knowledge can be generated by a blockchain. A consensus is reached through validation and confirmation among all the actors. This is also how common knowledge is created. (It should be noted that the knowledge is validated according to predefined rules. However, the validated knowledge is not always truth.)

How can we verify the data stored in a Cell?

This depends on another field in the Cell — the type script. This script defines the rules of state transfer and thus imposes constraints on state. When a consensus is being reached in the CKB network, the CKB-VM will execute the type script and verify that the state saved in the newly-generated Cell conforms to the rules predefined by the type script. All of the Cells that are restricted by the same kind of type script store the same type of data.

Join our community of miners, developers and crypto enthusiasts — connect with us on Nervos Talk, Github, Twitter, and Reddit, and sign up to receive community updates.

For discussions or questions join one of our community Telegram channels: English, Korean, Russian, Japanese, Spanish, Vietnamese and Chinese. We also have dedicated Mining and Dev channels.

--

--