How to solve problems in Bitcoin and Ethereum programming models

“With a layered architecture, you can create an affordable and versatile infrastructure that, in my opinion, is the only viable future for the blockchain to drive the world.”

 

Three programming models

 

—— UTXO model

• "618" shopping festival e-commerce giants trick play blockchain experts said that relying on "chain" to solve commodity security "a little difficult"
• 5G+ blockchain, is it a gimmick, or is it possible in the future?
• Media: Is Bitcoin "wake up"?

First, start with Bitcoin.

Bitcoin, also known as a peer-to-peer electronic payment system, uses a programming model called UTXO ( a collection of bitcoin amounts associated with bitcoin addresses, a data structure containing data and executable code ).

The easiest way is to think of UTXO as a box. The box contains a number that represents the value of the currency and a lock. Only the person holding the corresponding key can open the box. When making a transfer, the owner or individual holding the key unlocks with the key, finds another empty box, puts the new denomination in the new box, and attaches 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 then placing it in another box.

In summary, the box represents the UTXO model that stores the data, and the lock represents ownership.

—— Account model

In addition to the UTXO model, there is an Account model . The most famous example of this model is Ethereum.

In addition to the data, there is computational logic in the Ethereum Account model. You can think of the ERC20 contract as a box with no money but a complex set of logic and numbers.

Unlike UTXO, the Account model's box is always reusable and cannot be opened during its lifetime.

When the account of the Account model is created, a set of rules is written into the box, and some buttons are placed in the box so that people can interact with the box. For example, a rule might say that if a party wants to transfer money, she or he or it needs to present a form of identification and enter the password. Once you have completed the previous steps, you will need the following information: transfer amount, recipient, and other information. Once inside, she or he or it needs to press the transfer button to complete the transfer. Once the message is received, it will deduct from your amount and change it to the other party's account, then update all internal data.

Those familiar with programming will soon find that the Account model is similar to OOP in the real world ( object-oriented programming , a computer programming architecture ) , and the concept of buttons is similar to API ( Application Programming Interface ) .

If we extend the box metaphor, Ethereum functions more like an ATM machine.

In the Account model, the box holds the logic and data. Once the logic is written to the factory-set box, it can never be changed. You can only use external buttons when you need to modify the data. Everyone's money is recorded in the box. To do the transaction, you only need to enter the transaction information, and the box will update the data according to the request processed by the rule.

—— Cell model

In the Cell model, we can also think of Cell as a box because it is very similar to the UTXO model and can contain any object that is locked at will.

You can execute on the box and write a set of rules to specify what the box can store. In this way, the data in the unit can represent assets such as goods or encrypted cats. In addition, the locks in UTXO are the same. But in the cell model, users are free to change and use custom locks. (You can compare a normal padlock with a fingerprint lock or a digital lock)

In general, the Cell model is a generalized UTXO model with two meanings: first , the lock is customizable; second , the box can store user-defined data.

In CKB, the core project of Nervos (a distributed application network with a layered architecture), a programming model combines the advantages of the Bitcoin programming model with the Ethereum programming model.

Some people may be curious about how the Cell model uses its programming model.

It is important to understand the evolution of the blockchain system first. Bitcoin is a derivative of the p2p (peer-to-peer) payment system, and later a broader decentralized application platform, Ethereum. The further development of the blockchain has brought about a variety of new projects and is increasingly diverse.

Due to the high transaction and storage costs that require a network-wide consensus, blockchains inevitably adopt an architecture. This architecture allows flexibility to be achieved within agreed scope, allowing them to deliver low-cost transactions on a large scale.

Two major obstacles

 

– scalability issues

One obstacle that continues to hinder the development of blockchain is the issue of scalability. If we can't alleviate this problem, blockchain capabilities will be limited, and we won't be able to see the development of powerful advanced applications, and then unlock the true potential of a decentralized economy.

Scalability is part of the “blockchain trilemma”, which also includes security and decentralization. A blockchain system can have up to two of the three difficult dilemmas.

– transaction cost issues

The second obstacle is the transaction cost issue. The reduction in the overall transaction cost of a society is one of the most powerful indicators for measuring the feasibility of a technology on a scale. Due to the high transaction and storage costs that require a network-wide consensus, blockchains inevitably adopt an architecture. This architecture allows flexibility to be achieved within agreed scope, allowing them to deliver low-cost transactions on a large scale.

Solution: Layered architecture

 

Computer enthusiasts know that their devices contain a complex layered architecture. The layered architecture includes memory, hard disks, multi-level caches, and various registers. This architecture allows the general public to use at a low cost while leveraging its scalable capabilities to meet growing computing challenges.

We can apply the same design principles to the blockchain. With a layered architecture, you can create an affordable and versatile infrastructure. In my opinion, this is the only viable future in the world driven by blockchain. With Lightning, (Lightning Network), Plasma (one of the four major expansions of Ethereum) and the rise of payment channels, we can already see the rise of this type of architecture and the use cases it promotes. When approaching this hierarchical blockchain architecture, it is important to examine the relationships between the three different data models that make up the blockchain system: the UTXO model, the Account model, and the Cell model.

– verification and calculation model

The Cell model is derived from the UTXO model and is therefore a validation model. Instead, the Account model is a computational model.

When an asset returns from Tier 2 to Tier 1, the Tier 2 solution leverages proof submission and verification mechanisms (such as Lightning Networks). And because Layer 1 plays the verification role, not the computational role, we can see that the UTXO or Cell model is the appropriate method for this structure.

——Resolve scale expansion problems

At present, Ethereum and the “next generation” blockchain are facing serious challenges of increasing scale. Although large-scale adoption has achieved breakthroughs, the cost of data storage for all nodes is increasing, including the expansion of various zombie accounts, which makes the situation worse.

When using the Account model, all user assets are stored in a contract. If there is no direct way to segment the state for each user, it is difficult to charge them based on the capacity and duration of each user's occupancy state.

At the same time, this poses a challenge to the implementation of payment channel charges. Currently in Ethereum, the transaction fee is a one-time payment, granting permanent storage. But given that the blockchain is a public infrastructure, this model is not sustainable. We can see that it is a more reasonable way to continue to pay for storage space.

In the unit model, each user's digital assets are stored in their respective units. If the user does not want to continue to hold the asset, the data in the unit can be released and the storage capacity can be sold or lent to other users. This design ensures that Tier 1 does not store obsolete assets indefinitely and opens up new possibilities for stateful storage.

 

in conclusion

In general, the unit model is best suited to the needs of a hierarchical blockchain architecture when considering storage and verification requirements.

Attachment: UTXO and ACCOUNT advantages and disadvantages contrast

UTXO model

In the UTXO model, transactions simply represent changes to the UTXO collection. The concept of accounts and balances is a higher abstraction on the UTXO collection, and the concept of accounts and balances only exists in the wallet.

advantage:

The calculation is out of the chain, and the transaction itself is both the result and the proof. The node only does the verification, there is no need to perform additional calculations on the transaction, and there is no additional state storage. The output of the transaction itself UTXO is calculated in the wallet, so the calculation burden of the transaction is completely borne by the wallet, which reduces the burden on the chain to some extent.

In addition to Coinbase transactions, the Input of a transaction is always linked behind a UTXO. The transaction cannot be replayed, and the order and dependencies of the transaction are easily verified, and it is easy to prove whether the transaction is consumed or not.

The UTXO model is stateless and easier to handle concurrently.

For P2SH type transactions, it has better privacy. Inputs in transactions are not related to each other, and technologies such as CoinJoin can be used to increase certain privacy.

Disadvantages:

Some complicated logic cannot be implemented, and the programmability is poor. For complex logic, or contracts that require state preservation, the implementation is difficult and the state space utilization is relatively low.

When there are more Inputs, the witness script will also increase. The signature itself is more CPU and storage space.

ACCOUNT model

For the Account model, the Account model preserves the state of the world, and the state of the chain is generally agreed in the block in the form of StateRoot and ReceiptRoot. The transaction is only the event itself, does not contain results, and the consensus of the transaction and the consensus of the state can be isolated in nature.

 

advantage:

The contract is saved in Account as an account, and Account has its own state. This model has better programmability, is easy for developers to understand, and has a wider range of scenarios.

The cost of bulk trading is lower. Imagine that the mine pool pays the miners a fee. In UTXO, because each Input and Out requires a separate Witness script or Locking script, the transaction itself will be very large, and signature verification and transaction storage will consume valuable resources on the chain. The Account model can greatly reduce costs through contracts.

Disadvantages:

There is no dependency between the Account model transactions and the replay problem needs to be resolved.

For lightning network/thunder network, Plasma, etc., user proof requires a more complex Proof proof mechanism, and sub-chain state transition to the main chain requires more complex protocols.

UTXO VS ACCOUNT

 

For the above advantages and disadvantages, we will do some analysis and comparison.

First, the question about computing.

The UTXO transaction itself does not have complex calculations for the blockchain, so it is not completely accurate. The main reason is that Bitcoin's own transactions are mostly P2SH, and Witness script is non-turing complete, there is no loop statement. For Account models, such as Ethereum, because the calculations are mostly in the chain, and Turing is complete, the general calculation is more complicated, and contract security is likely to become a relatively large problem. Of course, whether Turing is complete is not directly related to whether it is an account model. But after the introduction of the account model, the contract can exist as an independent entity that is not controlled by anyone, which is significant.

Second, the issue of UTXO is more concurrency.

In the UTXO model, the state of the world is a collection of UTXOs. For faster verification of transactions, nodes need to store all UTXO indexes in memory, so UTXO is very expensive. For UTXOs that do not consume for a long time, they will always occupy the memory of the node. Therefore, for this model, users should be encouraged to reduce the production of UTXO and consume UTXO. But if you want to use UTXO for parallel trading, you need more UTXO as input, and at the same time generate more UTXO to ensure concurrency, which is essentially a dust attack on the network. And because the transaction is built in the wallet, a more complex design of the wallet is needed. In contrast to the Account model, each account can be viewed as a separate state machine that does not affect each other, and accounts communicate via messages. So in theory, when a user initiates multiple transactions, when the transactions do not call the same account between each other, the transaction can be executed concurrently.

Third, the issue of transaction replay for the Account model.

Ethereum uses the way to add a nonce to the Account. Each transaction corresponds to a nonce, and the nonce increments each time. Although this approach is intended to solve the problem of replay, it also introduces a sequential problem and makes the transaction in parallel. For example, in Ethereum, the user sends multiple transactions. If the first transaction fails to be packaged, it will cause the subsequent multiple transactions to be packaged unsuccessfully. In CITA we use a random nonce scheme so that there is no sequential dependency between users' transactions, no tandem failures, and the possibility of parallel processing of transactions.

Fourth, the storage problem.

Because in the UTXO model, the state can only be saved in the transaction. The state of the Account model is saved in the node, stored in Ethereum using MPT, and only the consensus StateRoot is needed in the Block. In this way, for the data on the chain, the Account model is actually smaller, the amount of network transmission is smaller, and the state is saved locally in the MPT mode, which is more efficient in space usage. For example, A transfers to B. If there are 2 Input and 2 Outputs in UTXO, then 2 Witness scripts and 2 Locking scripts are needed. In the Account model, only one signature is needed, and the transaction content only contains the amount. After the latest quarantine witness implementation, Bitcoin's transaction data volume is also greatly reduced, but in fact for the verification node and the full node still need to transmit and verify for the Witness script.

Fifth, UTXO is more complicated for light nodes to acquire an address state.

For example, in a wallet, all UTXOs about an address need to be requested from the whole node. The whole node can send part of UTXO. The wallet has to verify whether the UTXO has been consumed, and it is difficult to prove that UTXO is a complete set. Not a partial collection. For the Account model, it is much simpler. Find the corresponding state in State according to the address. State Proof of the current state can prove the authenticity of the contract data. Of course, for UTXO, the UTXO root can also be verified in each block, which is related to the current implementation of Bitcoin and is not a feature of UTXO.

Author: Zhang Yaning

Compile: Sharing Finance Ma Ming

We will continue to update Blocking; if you have any questions or suggestions, please contact us!