Qtum Institute: Blockchain Virtual Machine - the cornerstone of programmable business economics

Qtum Institute: Blockchain Virtual Machine - the cornerstone of programmable business economics
(Picture from internet)

In 2019, as the tenth anniversary of Bitcoin development, with the growing popularity of blockchain knowledge and technology, blockchain technology is constantly looking for more commercial exploration beyond the financial sector, where the blockchain infrastructure is programmable. The cornerstone of the business economy is advancing in constant exploration. The infrastructure of the blockchain technology domain—virtual machines—is the most critical and core technology for implementing smart contract systems. Smart contracts are not only the carrier of business logic, but also fall down to the level of technology implementation. It can be seen that the virtual machine is the cornerstone of the blockchain technology. In today's rapid development of technology and even in the future, blockchain technology will be inseparable from the important support of virtual machines. Qtum Quantum Chain recognizes the importance and future trend of blockchain virtual machines. As early as 2016, the Qtum-x86 virtualization of the next-generation mainstream language programming is fully explained in Chapter 3 of Qtum Quantum Chain Technology White Paper v0.7. Machine, as an infrastructure to support the actual commercialization of the future blockchain business.

What is a virtual machine? What is the difference between a normal virtual machine and a blockchain virtual machine? And why does a smart contract require a blockchain virtual machine? What are the unique advantages of the Qtum-x86 virtual machine?

What is a virtual machine To thoroughly understand a virtual machine, you should first understand the abstract word of "virtualization", and further understand the difference between a normal virtual machine and a blockchain virtual machine. Wikipedia defines it: "In computing, virtualization is a broad term referring to the abstraction of computer resources. Virtualization hides the physical characteristics of computing resources for its users, whether applications or end users. This includes rendering a single physical resource (such as a server, an operating system, an application, or a storage device) running as multiple virtual resources; it also includes multiple physical resources (such as storage devices or multiple servers). Expressed as a single virtual resource..."

Some refinements are:

  • Create multiple virtualized resources from one physical resource
  • Create a virtualized resource from one or more physical resources.

Everyday network, storage, and hardware will Frequently used to express certain concepts. Early results in this area were Christopher Strachey's paper "Time Division of Large High-Speed ??Computers." IBM's exploration of virtualization began with its CP-40 and M44/44X research systems. In return, this led to its commercial product CP-67/CMS. The concept of a virtual machine isolates the user and simulates a complete system for each user. A key feature of the IBM model is that programs share the same hardware by splitting computer resources and completely isolating programs. The resources of the mainframe at the time were very scarce and therefore mostly shared, so the virtual machine computing time was cut into the private computing time of many shared users.

Server virtualization

Server virtualization is known as "virtualization" for servers, represented by companies such as VMware, Microsoft, and Citrix. Using server virtualization technology, a physical machine can be divided into multiple virtual machines. Behind this virtualization technology, the core is the concept of hypervisor. The Hypervisor is a small layer that intercepts the operating system's calls to the hardware.

And with this layer of hypervisor you can:

  1. Improve hardware utilization: save hardware and save costs
  2. Security: Clean images can be used to reconstruct damaged systems, provide sandboxing and isolation to limit possible attacks.
  3. Development: Use cases for debugging and performance monitoring can be easily built in a repeatable manner.
  4. Unification: Uniformity between environments and operational data.

Why blockchains require virtual machines to understand the different scenarios of "virtualization". After the meaning, why does the blockchain still need a virtual machine, and what part of the virtualization feature does it need? This is related to the uniqueness of the blockchain. The blockchain system requires a consensus mechanism to ensure that the calculation results of each individual output are consistent. In the case of Bitcoin, A sends the BTC to B, and in order to implement the smart contract, the automatic transaction is converted into a code. The main task of the blockchain virtual machine is to run smart contracts. Essentially, a blockchain virtual machine is a coded runtime environment. Thereby ensuring the consistency of distributed nodes in the blockchain network. From the perspective of security, the more powerful the smart contract, the more logically complex it is, and the more likely it is to have a logical loophole. In the blockchain, if the virtual machine is considered from the security aspect, it is to prevent the wrong chain or the programmer from writing code errors and affect the entire main chain. More importantly, prevent the device running the smart contract from being attacked.

If you run directly on the device system, there may be security risks. Because each node has to run a smart contract for verification, but if you don't use a virtual machine, but run it directly on the machine, it is very easy when the smart contract developer is negligent or under-tested, and the code of the smart contract is vulnerable. It is exploited and attacked by hackers, which is common to the security of server virtual machines mentioned above.

In April 2018, BEC wrote a vulnerability due to integer overflow, and was hacked away by nearly 50% tokens. However, this error should be the basic common sense at the language level. Ethereum's smart contracts have repeatedly experienced loopholes. The industry generally believes that it is related to the underlying system. In this Qtum quantum chain virtual machine technology serialization (1) analysis, because its design is relatively non-mainstream, it is difficult to have mainstream programming languages. Ability to port to EVM. This design can be said to be incompatible with most programming paradigms in the last 50 years, so it is not friendly enough.

In order to push the development of blockchain to a more mainstream stage, the Qtum quantum chain uses the x86 instruction set. The x86 instruction set has been in development for more than 40 years. Today, the x86 architecture is becoming more compatible, and the ecosystem is becoming more sophisticated, with a market share of over 90%. The decoding function has been incorporated into today's x86 CPUs, which converts variable-length x86 instructions into fixed-length RISC-like instructions that are then handed over to the RISC core for processing. Decoding includes both hardware decoding and micro decoding. Simple x86 instructions use hardware decoding faster, while complex instructions require micro decoding, which is divided into several simple instructions before execution. At present, the advantage of the x86 architecture is that a single instruction is powerful, and the number of instructions is relatively fast; and because of the small number of instructions, high-frequency operation does not require a large bandwidth to transmit instructions to the CPU.

Bitcoin: Bitcoin's blockchain technology is primarily intended to provide simple technical support for digital currency transactions. Ethereum: Ethereum develops smart contracts and Turing's complete EVM as a symbol.

Qtum Quantum Chain: The construction of blockchain infrastructure represented by Qtum-x86 has gradually landed, promoting the rapid development of the blockchain commercial economy.

Why is the Qtum Quantum Chain designed for X86 virtual machines at the QTUM Technology Lab? The Qtum-x86 design time is planned to write smart contracts in multiple languages. Because EVM development needs to learn solidity, the learning cost is increased while the stability is not strong. If the blockchain virtual machine supports multiple programming languages, it can become more secure. Taking Rust as an example, Rust is a very efficient and lightweight programming language in other new languages, and most importantly, it is more secure and can reduce attacks caused by programmers' errors in programming. risks of. At present, the development cost of Ethereum is still very high, and because there is no standard library, it also makes a lot of memory. Qtum-x86 provides special internal code for these standard library functions, similar to the pre-compiled contract of Ethereum. This feature can be used without adding special support to the new pre-compiled contract, making it more efficient, convenient, and memory-saving without affecting other consensus variables.

The Qtum Quantum Chain development team was originally designed to support multiple virtual machines. The Ethereum virtual machine is the first supported virtual machine, but the current AAL functionality is greatly limited by EVM, and the Qtum-x86 virtual machine will not. Re-submitted to these restrictions. The large memory space of the Qtum-x86 virtual machine and its efficient operating code set enable complete blockchain data for intelligent contract analysis, which is not possible on Ethereum virtual machines. In the future, it is possible to support ai-based smart contracts to automatically monitor the blockchain, becoming a potential oracle, allowing smart contracts to dynamically adjust themselves to run as efficiently as possible under current network conditions. These blockchain data can include complete transaction data as well as node statistics (consensus correlation). Since these data are constants and require very little memory space, there is nothing wrong with exposing this data.

Currently, the Ethereum virtual machine forces each user to point to 32-byte data using a 32-byte key. Developer management can be quite complex, especially considering storage space fragmentation and maintenance issues. Therefore, on the Qtum-x86 virtual machine, a generic key-value store is added to the smart contract. This way, the user can use any key from 1 byte to longer and point it to a variable value of the same length. Currently, the gas model proposed by the Qtum development team first charges a fixed fee for reading/writing the database, and then charges the word based on the number of bytes actually operated. Of course, this feature will also be counted in stateRootHash so that SPV wallet can use this database to interact with smart contracts. Another design goal of the Qtum development team is to make smart contract dependencies clear and immutable. This is just an opt-in feature, so you can still allow calls to unknown contracts. Smart contracts that know exactly their dependencies can be executed in parallel under certain circumstances, helping to reduce the cost of gas, while at the same time providing other benefits. This will be a major extension of the smart contract based on the Qtum-x86 virtual machine. Looking back together, Qtum-x86 development engineer Howard live demo video. The API is invoked on the Qtum-x86 virtual machine in three major development languages: C, C++, and Rust, demonstrating examples of future developers writing smart contracts in these mainstream development languages.