Understanding the Tradeoffs of Designing Programming Models for Blockchains
If you want a closer look at the cell model itself, there is a two part series that goes over the cell model and how it compares to UTXOs.
Authored by Jan Xie and Translated by Harika Kalidhindi
Today’s popular blockchains more or less face at least one of these three problems that hinders scalability:
- Tragedy of the (Storage) Commons caused by State Explosion (and the resulting loss of decentralization);
- The loss of flexibility and scalability caused by computation and verification being coupled;
- The contradictions that exist between the demands for transaction throughput and value storage. Layer 2 and cross-chain implementations will aggravate these contradictions and thus have negative economic impacts on Layer 1.
These problems are rooted in the underlying blockchain architecture and protocol, making them difficult to solve with patches. To truly address the root of the problems, the underlying data structure itself must be more appropriate. This article details the benefits that the CKB gains by using the cell model, a generalization of UTXO model.
If you are unfamiliar with the CKB’s cell model or Bitcoin’s UTXO model, there is a two part series that goes over the cell model and how it compares to UTXOs.
Here is a quick recap on the cell model:
In the CKB’s cell model, there are cells instead of UTXOs. While UTXOs can only hold a number representing the amount of coin held, cells can hold data of any type. The value of a cell is determined by the amount of bits it can use to store its data. That storage size gives you the value of the cell in the CKB network, because the CKB’s first class citizen is storage space (and the ability to hold information that everyone has reached consensus on).
The user assigns a type to their cell. When users define a type, they also define a type script with the rules that govern cells of that type. The type script ensure transactions that attempt to change the data in your cell, still result in a valid data for the given type. The rules could be define any kind of model; for example the UTXO model can be implemented using cells.
Unlike with Bitcoin, the CKB allows you to define your own rules for what kind of transactions are allowed (by writing a type script that decides if a transaction is valid). Unlike with Ethereum, the amount of storage space that a user can take up is capped, because you can only make two cells with data taking up 8 bytes if you already owned a cell with more than 16 bytes of storage space.
Let’s go over the transaction processes for Ethereum and Bitcoin, and then compare them to that of the CKB.
General Verification Network
Bitcoin is a Verification Network.
When making a transaction, a user needs to input to the wallet or local client the amount of coins to be transferred and the recipient. After receiving this information, the wallet will do calculation and search for this amount of coins (UTXOs) owned by the sender (locally) and create new coins, part of which will be transferred to the recipient and part of which will be returned to the sender as change. The wallet will then package the spent and new UTXOs into a transaction and broadcast it to the network. Once the transaction is verified by the network, it will be packaged into a block and completed.
In the process, the nodes of the network are not concerned with how the previous state (the destroyed coins) has been found or how the new state (new coins) is generated. The nodes are only concerned with any change in the total value of these coins after the transaction is completed. When a user makes a transfer, the calculation is done on their (client) side. Hence the user can be sure of the result (the new state) when sending the transaction.
Now that the Bitcoin network has already been established, however, it is difficult to make changes to how this state is checked.
Ethereum is a General Computation Network.
When using a DApp, the user needs to tell the wallet or local client what he wants to do. The wallet will package the user’s request into a transaction and broadcast it to the network. When the transaction is accepted by the nodes of the network, the new state will be computed according to the current state and the request included in the transaction. In the process, the computation is completed by the nodes. The result (the new state) can only be confirmed after the transaction has been added into a block. Unlike on the Bitcoin platform, the user is uncertain about the result when sending the transaction.
The top shows the transaction process on Ethereum, with transaction being a request or Event; below is the transaction process on Bitcoin/CKB with the transaction with the new state generated off-chain.
CKB is a General Verification Network.
When using a DApp, the user needs to tell the wallet or local client what he wants to do. The wallet will compute the new state according to the current state and the user’s request. In the process, computation is completed on the user’s side, and its result (the new state) is confirmed before the transaction is sent.
Like in the Ethereum model, a user can define their own logic to use with assets they define on the CKB. This means they both share the generality that makes for a powerful development platform.
Unlike Ethereum (and like Bitcoin), the CKB is still a verification (not computation) model: computation is still done locally before the transaction is made and broadcasted. In other words, a transaction is created after the computation is done in the Bitcoin or CKB model, but before the computation is done in the model of Ethereum.
The separation of computation and validation also separates Layer 1 and Layer 2. Layer 1 is concerned with new states rather than the steps by which they are generated. In essence, all the Layer 2 solutions including state channels and Plasma make calculations off-chain and commit the finalized state to Layer 1 for validation at a specific time.
Why is CKB better?
We now have a basic data structure that is quite different from others and have designed a unique economic model on it. Is this really better? Maybe we can obtain some inspiration from the three questions raised at the very beginning of this article.
State Explosion has brought about the Tragedy of the (Storage) Commons and loss of decentralization in networks like Ethereum (that are general enough for developers to want to allocate new data to suit their use case).
Capacity is a finite asset native to CKB with its supply restricted by the predefined rules. It is also a unit of measurement for state. The amount of capacity determines how much data can be stored on CKB, i.e., the maximum state space of CKB. This means that the state stored on CKB is limited by the total amount of capacity. Hence, CKB cannot to suffer from state explosion. As long as capacity is issued appropriately, the network can maintain its decentralized properties indefinitely. Every Cell is independent and has a specific owner. This privatizes the state space that has served as a kind of public resource, ensuring that precious consensus space can be utilized more effectively.
The coupling of computation and validation restricts flexibility and scalability, like on the Ethereum network.
As a General Verification Network, CKB separates computation and verification, making each more flexible and scalable. More computation is executed on the user side, closer to their data, as well as application usage. Data can be processed more flexibly and with more diverse tools. With CKB’s architecture, wallets can have more power and capabilities. At the verification stage, it is easier to analyze the dependencies of transactions and execute transactions in parallel given that the results of computation have already been finalized.
While neither of these problems exist in Bitcoin, the Bitcoin platform is specialized and can never be used to run anything other than bitcoin transactions.
The contradictions that exist between the demands for transaction throughput and value storage.
Layer 2 and cross-chain implementations will aggravate these contradictions and thus have negative economic impacts on Layer 1.
In a Cell-based economic model, the cost of storage is proportional to the amount of consensus space and the length of time required. Miners can earn revenue by providing consensus space and the utility of CKB is derived from its entitlement to safe consensus space. The CKB is valuable for its security and accessibility, rather than TPS. A state-only Layer 1 like the CKB naturally supplements a transaction-oriented Layer 2, making CKB better at value capture in a layered network and interchain network.
CKB inherits the ideas of Bitcoin’s architecture and creates the Cell model from generalizing the UTXO model, retaining the consistency and simplicity of Bitcoin. In the CKB model, all the states are stored in Cells, all computation is done off-chain, and all the verification work is handled by nodes.
CKB is NOT …
IPFS
It may be confusing to define CKB as storage. You may ask, “isn’t this the same as IPFS, Filecoin or any other distributed storage models?”
CKB differs from distributed storage in that the latter only stores data without verification and thus can’t reach a consensus on the data stored in it. The capacity of distributed storage can grow in proportion to the development of storage technology. The capacity of CKB however, is limited by the efficiency of reaching a global consensus.
There is no need to worry about the capacity of CKB. As Layer 2 and other layering technologies mature, a single merkle root may be all that is required on Layer 1 in the most extreme cases of Layer 1 efficiency demands. The state required by Layer 1 for validation can also be committed through a transaction, requiring nodes to check merkle proofs to ensure the validity of state and state transfer. There has been some research on this.
Reference：
