Lessons Learned from Bitcoin’s and Ethereum’s Programming Models
and a Simple Explanation of How Cell Model Combines the Advantages of the Two
Authored by zhangyaning
With a layered architecture, an affordable and universal infrastructure can be created and in my opinion, this is the only viable future for a blockchain-powered world.
Through my work, I have realized how difficult it is for people to wrap their heads around the idea of Cell Model. This article is an attempt to explain Cell model in a simplified way so that it is accessible by most people.
First, it is important to work forwards from history, starting with Bitcoin. Bitcoin is known as a peer-to-peer electronic payment system that uses a programming model called UTXO.
The easiest way to think of UTXO is as a box. (That’s right, not a ledger, a box.) The box contains a number representing some monetary value and has a lock. Only the person with the corresponding key can open the box. When making a transfer, the owner/person with the key uses the key to unlock the lock, finds another empty box, put the new denomination in the new box, and attach a new owner’s lock.
The entire transaction can be summarized as opening the box, taking out the money inside, destroying the original box, and putting it in another box.
To sum up, box represents the UTXO model where data is stored and the lock represents ownership. Cryptography is a great invention that maps the concept of a lock in the physical world to the virtual world.
Aside from the UTXO model, there is also account model. The most famous example of this model is Ethereum. In addition to data, there is also computational logic in the Ethereum account model. You can think of the ERC20 contract as a box not with money but a complex set of logic and numbers.
Unlike UTXO, the account model’s box is always reused and cannot be opened for the duration for its life. A set of rules would have been written into the box as they get produced and some buttons are put into place so that people could interact with the box. For example, the rules may say something like this: if a party wants to transfer money, then she or he or it needs to show one form of proof of identity and enter a pin. Once the previous steps are completed, the following information is needed, transfer amount, the recipient, and other information. Once those are enter, she or he or it needs to hit transfer button to complete the transfer. After the box receives the information, it deducts your from amount and makes the change to the other party’s account and then updates all internal data. Those familiar with programming will quickly see that the account model is similar to object-oriented programming in the real world and the idea of buttons is similar to API.(My wife said account model sounds like an ATM machine. She is right.)
In the account model, the box saves the logic and data. The logic can never be changed after it is written to the box at the factory setting. You can only use the external button when you need to modify the data. Everyone’s money is recorded in the box. To make a transaction one only needs to enter transaction information. The box is processed requests and update data according to the rules.
In the Cell Model, we can also think of the Cell as a box, as it is very similar to the UTXO model. One can perform some magic on the box and write a set of rules to specify what the box can store. This way the data inside the Cell can be made to represent money and/or assets like CryptoKitties. Moreover, the locks in UTXO are of the same kind. Yet in Cell model, users will have the freedom to change and use customized locks. (You could think of simple padlocks vs fingerprint locks or digital locks)
Overall, Cell model is a generalized UTXO model in the following two senses: first, locks are customizable; second, box can store user defined data. Nervos’s CKB has a programming model that combines advantages of Bitcoin’s programming model and that of Ethereum’s.
Some might be curious in what sense Cell Model is an advanced and how its programming model can be used.
It is important that we first understand the evolution of blockchain systems. Bitcoin was the birth of a peer-to-peer payment system, and later came Ethereum, a more generalized decentralized application platform. Further developments in blockchain have led to a wide variety of new and increasingly diverse projects.
Because transactions and storage that require network-wide consensus are expensive, it is inevitable that blockchains will adopt an architecture that allows for flexibility in the scope of consensus, allowing them to deliver low-cost transactions on a massive scale.
Two Major Roadblocks
One roadblock that continues to impede blockchain development is the issue of scalability. If we cannot mitigate this issue, blockchain capabilities will be limited and we will not see the development of robust higher-level applications that can unlock the true potential of the decentralized economy.
Scalability is one part of the ‘blockchain trilemma,’ which also includes security and decentralization and states that a blockchain system can have at most have 2 of 3 qualities of the trilemma.
A second roadblock is the issue of transaction costs. A reduction in a society’s overall transaction costs is one of the strongest indicators of a technology’s viability at scale. Because transactions and storage that require network-wide consensus are expensive, it is inevitable that blockchains will adopt an architecture that allows for flexibility in the scope of consensus, allowing them to deliver low-cost transactions on a massive scale.
The Solution: A Layered Architecture
Computer enthusiasts know their devices contain an intricate layered architecture, incorporating memory, hard disk, a multi-level cache, and various registers. This architecture allows for low-cost use by the general public, as well as scalable capabilities that can meet ever-growing computing challenges.
We can apply the same design principles to a blockchain. With a layered architecture, an affordable and universal infrastructure can be created and in my opinion, this is the only viable future for a blockchain-powered world. With the rise of Lightning, Plasma and state/payment channels, we can already see this type of architecture emerging and the use cases it facilitates.
In approaching this layered blockchain architecture, it is important to examine the relationship between three different data models that underlie blockchain systems: Bitcoin’s UTXO model, the account model, and our contribution- the cell model.
Verification vs. Computational Model
The cell model is derived from the UTXO model and is thus a verification model. The account model, in contrast, is a computational model.
Current Layer 2 solutions such as the Lightning Network, utilize a proof submission and verification mechanism when assets return to Layer 1 from Layer 2. With Layer 1 playing a verification role, rather than a computation role, we can see that a UTXO or cell model is the proper approach for these kind of constructions.
Addressing State Explosion
Currently, Ethereum and ‘next-generation’ blockchains face the difficult challenge of ever-growing state size. While mass adoption is still ahead of us, data storage costs for full nodes are already high, and include a variety of zombie accounts to make matters worse.
With an account model, assets of all users are stored in a single contract. Without a direct way to split out state for each user, it is very difficult to charge each user for the capacity and duration they are occupying state.
This poses a challenge to the implementation of state fees, and currently in Ethereum, transaction fees are a one-time payment that grants permanent state storage. This model is unsustainable, given a blockchain is public infrastructure. We can see that continuous payment for rental of storage space is a much more reasonable approach.
In the cell model, each user’s digital assets are stored separately in their respective cell(s). If a user does not want to continue to hold assets, the data in the cell can be released and the storage capacity can be sold or lent to another user. This design ensures that Layer 1 will not indefinitely store abandoned assets and also opens up new possibilities for state storage.
Overall, it is clear that when storage and verification requirements are taken into account, the cell model is best suited to the needs of a layered blockchain architecture.
The next article will demonstrate how to program with the Cell model and introduce some advantages, as well as some limitations of the programming model.