Smart contracts are an integral part of the blockchain and the only way to implement business logic through blockchains. By analyzing the smart contract development language of Bitcoin, Ethereum and EOS, the potential BUG threats and creatively proposes a hierarchical design of intelligent contract language to better secure the funds and functions.
Recently, Ethereum has experienced serious BUGs frequently. Since the birth of Ethereum, the financial risks caused by smart contract BUG have been emerging, from the DAO event in 2016 to the recent integer overflow, jaeden vulnerability, etc. The BUG of the ERC20 token smart contract involves tens of millions of dollars and hundreds of millions of dollars. Similar problems have arisen in other Public Blockchain that support smart contracts, but only because of the small number of DAPPs running on them, they have not received much attention.
Smart contracts are an integral part of the blockchain and the only way to implement business logic through blockchains. The smart contract is a piece of computer program code that is run by the user through the client program and runs simultaneously on each node of the blockchain, and uses the consensus algorithm to obtain the consistent running result of the whole network.
Bitcoin implements the first and simplest smart contract operating environment, and its programming language is also a very rare stack-based scripting language. Transferring money in the Bitcoin blockchain actually implements a very simple smart contract. Bitcoin's scripting language is not Turing-complete. There are only a few instructions that are closely related to bitcoin transfers. There are no complicated mathematical functions, no jumps and loop instructions, and it is difficult to use it to write complex business logic. The payment transfer function in digital currency is sufficient. With a slight extension to the instruction set, it has become possible to develop complex payment systems like the Lightning Network. Most importantly, this simple instruction set allows smart contract programmers to simply select a template from several commonly used programming templates to implement the required functionality, making it difficult to write Defective code.
Ethereum has taken a different approach to completely transforming Bitcoin's smart contract language, implementing a Turing-complete instruction set, and inventing a JavaScript-like Solidity language for writing smart contracts. The Solidity language can be used to write smart contract code that meets most business needs, but because of its unusually rich functionality and flexibility in the Bitcoin scripting language, the code is very prone to bugs.
EOS goes a step further by using a WASM virtual machine that allows smart contracts to be written in any programming language such as C. It is well known that C is a very difficult and difficult for coding. Even experienced programmers can easily write BUG code. It is conceivable how big a smart contract written in C++ will be. risk. Since EOS has just been launched, this issue is still not being noticed at present, but considering the huge economic volume of EOS, once a problem arises, it will not be a trivial matter.
Since smart contracts are an agreement between DAPP developers and users, especially when it comes to high-value digital currency assets, developers have no right to unilaterally change the contract content, which makes it impossible for developers to discover bugs. Modifying and upgrading the code of the smart contract, the vulnerability cannot be fixed. Even if the code affected by the bug only involves the business logic and does not involve the digital currency itself, DAPP developers can't do anything about it. This makes the technical risk of DAPP developers very high. Many people have proposed to adopt formal verification and third-party code auditing to improve the security and reliability of smart contract codes, but the results are minimal.
Here, the proposes a concept of hierarchically designing a smart contract language, which can be a good trade-off between financial security and functional richness. The smart contracts in DAPP are divided into three levels, namely the digital currency layer, the digital asset layer and the business layer. Different smart contracts are written separately, and each layer of smart contracts adopts different programming languages according to their characteristics. Layers and layers are connected in a loosely coupled manner, and changes in the upper layer code do not affect the lower layer.
First, at the lowest level, the digital currency layer, reliability and security are most needed. At this level, a declarative domain-specific language (DSL) can be designed to support only the basic functions shared by digital currency names, symbols, circulation, transfers, and destruction. Because declarative language programming is weak, as long as the compiler and virtual machine design are flawless, it is almost impossible for programmers to write code with bugs. This layer of smart contracts requires simplicity and stability and will not be changed after release to ensure the validity of the value of the digital currency issued.
Second, in the middle layer, the digital asset layer. Digital assets are securities based on digital currencies that are priced in digital currencies and have specific business scenarios. They also require high stability, but they also require some flexibility. The design of this layer can be referred to the solidity language, or it can be used directly. This layer needs to be set according to the business scenario, not required.
The top layer is the business layer, which is convenient for DAPP programmers to achieve various business needs, requires high flexibility, and can be developed in any programming language. The smart contract of the business layer only involves business functions and business logic. All access to digital assets and digital currency calls the underlying smart contract. When a business layer smart contract has a vulnerability or a change in business needs, it is easy to upgrade the smart contract code without affecting the value validity of the associated digital assets and digital currency.
