A blockchain architecture that can be developed at a high speed for another ten years-the Wormhole Protocol deploys an infinitely scalable smart contract layer on the Bitcoin Cash network

A blockchain architecture that can be developed at a high speed for another ten years-the Wormhole Protocol deploys an infinitely scalable smart contract layer on the Bitcoin Cash network

Author Lightning HSL Chapter 0 Introduction The success of Ethereum has inspired countless developers to devote themselves to the development of a "blockchain operating system." This is an architecture that takes the "blockchain operation chain" as the bottom structure, and then builds various dApps on it to implement various businesses. I think this is an architecture that is difficult to scale.

Bitcoin Cash has recently reproduced and extended the Bitcoin Omni protocol, and the Wormhole protocol proposed is a more scalable architecture.

The blockchain architecture that can be developed at a high speed for another ten years-the Wormhole Protocol is deployed in the Bitcoin Cash network with unlimited scalability...

Chapter 1 What is scalability? The scalability of a blockchain has two main meanings. The first meaning is that the transaction volume can be expanded, that is, the network can accept more and more transactions. For example, BTC is about 3~7tps and ETH is about 20~30tps, but these two are already close to the limit. The theoretical value of BCH can reach 100tps, but no one uses it. The actual usage is only 0.5~1tps, the theoretical value of bts At 3300tps, the theoretical value of EOS is higher, and the actual usage is less. Scalability is to allow this tps to continue to grow in actual use value.

The second meaning of scalability is the sustainable growth of the number of nodes. The main constraint on the continuous growth of the number of nodes is the performance limitation of the network hardware facilities and the cost limitation. If the cost of node operation is higher, and the performance of the actual network hardware facilities is worse, then the number of nodes running will not grow sustainably.

At present, the operating cost of Ethereum nodes is very high. Under the premise of maintaining a certain degree of decentralization, the performance limit of network hardware facilities has been reached. Ordinary users will hardly run a node, and users can only run one. Light wallet. The operating costs of Bitcoin and Bitcoin Cash are still very low. The design goal of the DPOS consensus mechanism of BTS and EOS does not include node scalability.

The operating cost of a node can be calculated by dividing it into CPU calculation cost, hard disk and memory storage cost, and network transmission bandwidth cost.

The main purpose of achieving node scalability is to achieve decentralization. If decentralization is not considered, the scalability of the transaction volume using the centralized design is very easy to achieve.

The design of the Internet has very successful scalability, and most of us are less than a networked device. The Internet never has to worry about too many devices connected to the Internet, nor does it worry about overloading the information sent.

However, it is not easy for a blockchain product with decentralization as the design goal to successfully achieve scalability.

Chapter 2 Ethereum and similar blockchain operating systems limit scalability. We look at blockchain operating systems from the user's point of view. Ethereum has two types of accounts, external accounts and contract accounts. The external account is composed of a public key and a private key. The Ethereum wallets produced by most of our users belong to this type of account, and the private key can determine the coins in this account, including Ethereum and ERC20 coins.

The contract account is composed of an address and some codes corresponding to the storage. To issue ERC20 tokens on Ethereum is to create a contract account. The code stored in the contract determines how the coins in this address are handled. The contract account does not have a private key.

Users use wallets to send and receive Ethereum, which is generally the behavior of external accounts. We send a sum of Ethereum, essentially calling a "system contract tranfer" of Ethereum to modify the balance of the account. The Ethereum node needs to execute this "tranfer function". Any user sending a transaction, such as sending ERC20 tokens, will trigger the execution of the code in a contract account, and the Ethereum node needs to execute the code in the contract account. All nodes must execute these codes.

Any user deploying code on Ethereum, as long as a user triggers the code by sending a transaction, the node must execute and verify it, and the user pays for gas to trigger the code execution.

Ethereum designs external accounts and contract accounts on the same layer at the same time, requiring all nodes to jointly maintain external accounts and contract accounts, which leads to very poor scalability. This architecture causes the node's operating cost to grow rapidly with the growth of transaction volume. Ethereum has only been in operation for three years. The block data that nodes need to store has reached more than 600G, and a large number of codes hosted in the block require the node to run. These complex codes consume a lot of computational costs, and ether The block interval time of Fangfang is as fast as 15s, which requires very high bandwidth, and the slower bandwidth cannot keep up. At present, in order to maintain decentralization, Ethereum can no longer increase the transaction carrying capacity of the network.

Chapter 3 Bitcoin's pure transaction accounting layer is scalable. Bitcoin (including BTC and BCH) has only "accounts" controlled by private keys and addresses, and no "contract accounts" that can host code. Users using the Bitcoin network can only send transactions and cannot execute "deployment of code for nodes to execute" in the Bitcoin block like Ethereum. The node only needs to execute and verify the transaction.

If we compare the verification of Bitcoin transactions to an unlocking function (unlocking script), then the Bitcoin node only needs to execute one function and does not need to execute user-defined code.

An architecture such as Bitcoin can achieve higher scalability, but because of the development concept of BTC, the use of 1M transaction data block + 3M signature data block limits the scalability of transaction volume. At present, the actual usage of the BTC network has reached its peak, but the entire BTC community refuses to expand. The node scalability of BTC is no problem at the current level.

On the other hand, BCH does not have the problem of expansion. Both transactions and nodes have very good scalability, but the BCH ecosystem has not yet risen, resulting in few people using it.

The problem with Bitcoin is that compared with blockchain operating systems like Ethereum, its functions are too narrow. The blockchain operating system allows users to customize functions and host them in the block, allowing nodes to ensure operation, which can achieve very complex functions, not just limited to sending transactions and transfers. For example, Ethereum can engage in complicated FO3D fund-based games, and ethereum cat games. Bitcoin can only be used for transfers.

Bitcoin also has the meta-coin protocol, which is a secondary extension protocol to achieve more complex functions, and the side chain protocol can also extend functions indefinitely, but Bitcoin has been developed for ten years and has not been popularized.

Bitcoin Cash has recently reproduced and expanded the Bitcoin Omni protocol, and the Wormhole protocol proposed is an attempt to expand a two-layer network based on the BCH main chain to achieve more complex functions. Chapter 4 The contract account layer of Bitcoin Cash can be expanded indefinitely As mentioned above, the transaction accounting layer of Bitcoin Cash has very good scalability because the functions performed by this layer are very simple. But now the development of blockchain proves, especially the development of Ethereum proves that more complex functions besides transactions are necessary. The Wormhole Protocol launched by Bitcoin Cash attempts to supplement these complex functions.

The complete agreement using the Wormhole Protocol to implement smart contracts has not been released, but the part of the agreement to issue tokens has been implemented. The simple understanding is this, the wormhole protocol is to implement the function of Ethereum's contract account on BCH. Like Ethereum, the user deploys the contract code by sending a transaction. The user constructs a BCH transaction, and the contract code is saved in OP_Return (or P2SH lock scripts and other methods can also save the code). However, the BCH main chain does not execute the contract code. The BCH nodes do not care about the OP_Return data, let alone execute it. The BCH main chain just treats this deployment transaction as an ordinary transaction.

The wormhole protocol execution contract is executed by the node running the wormhole protocol. What is a wormhole node?

The wormhole node is a computer running the wormhole protocol set. The wormhole protocol can be regarded as a plug-in of the BCH node. This plug-in program is specifically used to analyze and run the user's deployment on the BCH main chain using the wormhole protocol Code.

The external part of the wormhole node is an isolated node, but the BCH node part is a P2P network connected to each other. Isolation means that the execution of the contract is independent of each other. Ethereum's contract account is that all nodes need to execute all contracts. Wormhole agreement contract account is that you care about this contract before you execute it. It does not force all nodes to execute these codes. How safe is that?

If a project party deploys a contract A, and only the project party runs a wormhole node and executes contract A, does that mean that the project party can fake it? The answer is no, because the operation result of the smart contract must be deterministic. As long as your code has been deployed to the BCH network, it means that the result of the operation must be deterministic, which means that if anyone can verify the contract A.

In addition, the operation of smart contracts is mainly dependent on the project party, rather than relying on a decentralized network.

BCH's smart contract design idea is completely a two-layer network design, which does not harm the scalability of the BCH main chain. And because the contracts are independent, or "parallel", this means that contracts can be deployed without restrictions, that is, the smart contract layer of BCH is infinitely scalable. This is the contract sharding that Ethereum dreams of, and the smart contract layer of BCH is naturally sharded.

Chapter 5 Layering is the scalable architecture. Different functions are deployed to different layers. This design is more scalable. Ethereum deploys external accounts purely for transaction transfers and external accounts that deploy contract code to the same layer of the "blockchain operating system" architecture. After three years of operation, it has faced great scalability challenges.

On the other hand, BCH designs the transaction transfer as the main chain, and the code of the contract account is hosted on the main chain, but the main chain does not execute the code, but is stored on the chain and executed on the second layer. This not only guarantees the security of the contract, but also hinders the scalability of the main chain. This layered design is more scalable.

Chapter 6 Concluding Remarks If you want to bet on which chain can continue to maintain the scalability in actual operation in the next ten years, I will stand on Bitcoin Cash BCH.