The Blockchain Industry Will Have the First Technical Standard Debate: EOS-VM Take the Lead in Virtual Machine Race

Author: Cyborg of EOSForce

EOS-VM is an important cornerstone for EOS.IO to become a common blockchain protocol. At the same time, it surpasses EOSIO and will become the de facto blockchain virtual machine technology standard, and even stifles the virtual machine development of Ethereum and Polkadot in the cradle.

0 Preface

EOS.IO development team Block.One released the new EOS-VM on June 1, 2019. After large-scale testing, EOSForce team believes that EOS-VM will become the most commonly used VM and the de facto standard of VM in blockchain industry. As we mentioned in the article “EOS.IO will implement the most complicated hard fork upgrade in history”, several branches are under active development, and EOS-VM is just as important as the version 1.8.0. The branch began in July 2018. From the submission record, the early EOS-VM had no particularly compact development plan. However, since 2019, after a series of intensive developments, the EOS-VM project as we see it today was initially completed.

If EOSIO version 1.8.0 makes Block.One’s determination clear on EOSIO, EOS-VM gives us a glimpse of Block.One’s ambitions in the blockchain industry.

1 What is a VM?

VM is called virtual machine, which can be understood as the running environment of smart contract in the context of blockchain. We can take smart contract as an analogy to HTML in the Internet, blockchain system as an operating system, VM as a browser, and various dapps based on smart contract as various websites in the Internet.

Ethereum has completed the first smart contract function in blockchain system, and its EVM virtual machine is also the mainstream development environment for early smart contract developers. Meanwhile, many projects have borrowed Ethereum’s VM, such as TRX’s TVM.

However, EVM has its limitations. The efficiency of virtual machine is extremely low compared with mature virtual machine systems, and it is difficult to support more complex applications and environments.

Mature virtual machine system consists of a series of large projects, in current environment, it’s hard to achieve a complete mature virtual machine system from scratch and is also not necessary. Because for such a huge engineering project, starting from scratch means that developers and communities have to bear a lot of compatibility and learning costs. The best way is to develop virtual machine implementations for blockchain projects based on existing mature virtual machine standards.

Therefore, most of the blockchain projects choose to use an existing mature virtual machine implementation, it can be said that WebAssembly is the most suitable virtual machine. In addition to EOSIO, Polkadot also chooses WebAssembly, and Ethereum is also developing webassembly-based ewasm project.

WebAssembly has become a very important part of the blockchain world, whether it’s “The Lesser Evil” or not.

As a high-performance decentralized smart contract platform, the virtual machine implementation used in EOSIO is a very important part of the entire project. When reading the early EOSIO implementation code, it will be found that when the virtual machine is revoked, the EOSIO implementation code did a very strict encapsulation to hide the details of the virtual machine implementation. It can be seen that the EOSIO project will make significant continuous improvements in the virtual machine.

//A rare interface wrapper in EOSIO chain implementation

Class Wasm_interface {

Public :

Enum Class Vm_type {

Wavm ,

Wabt

};

…

Private :

Unique_ptr < struct Wasm_interface_impl > My ;

…

};

From the earliest use of ‘wavm’ virtual machine to the later support of ‘wabt’ virtual machine, Block.One has been improving the support of virtual machine and preparing for multi-virtual machine compatibility.

Eventually, EOSIO took on a higher challenge and developed a new EOS-VM, to be used as EOSIO’s virtual machine implementation. If EVM is a blockchain virtual machine, EOS-VM will be the first virtual machine to be commercially available on a large scale.

2 What is EOS-VM ?

Let’s take a look at what EOS-VM is. EOS-VM is a wasm runtime dedicated to blockchain systems.

In a blockchain system, contract code is compiled into bytecode, which cannot be run directly on the operating system. Instead, an executor is needed to execute these contracts. In a software system, the executor can be regarded as an abstract “machine”, and EOS-VM is such an executor.

EOS-VM mainly does four things :

First, EOS-VM is responsible for loading and parsing the compiled smart contract bytecode, known as wasm.

Second, EOS-VM is responsible for allocating resources to the bytecode as it runs. Of course, for smart contracts, the available resources are memory.

Third, EOS-VM is responsible for providing out-of-vm API calls to the bytecode of smart contracts.

Finally, the EOS-VM is responsible for executing bytecode to compute the results of smart contract runs.

As for EOS-VM, eosio:: VM ::backend class is the gateway for entire virtual machine system calls. In the tools directory, there are two testing tools that use the EOS-VM virtual machine. Those who want to understand the EOS-VM implementation in detail can read the EOS-VM code.

Int Main ( int Argc , char** Argv ) {

…

/ / Set the watchdog , limit the running time to seconds

Watchdog < std::chrono::nanoseconds > Wd ;

. wd set_duration (std :: chrono :: seconds (3));

Try {

…

/ / Load wasm bytecode

Auto Code = Backend_t::read_wasm ( argv [ 1 ] );

/ / Create an execution environment

Backend_t Bkend ( code );

Wd . set_callback ([ & ](){

. bkend get_context () exit () .;

});

…

// Execute

Bkend . execute_all ( & wd );

} catch ( … ) {

}

Return 0 ;

}

Here is the main job of EOS-VM, but if that’s all, there is no difference from wavm and wabt. In addition to doing the basic necessary work, EOS-VM makes some important improvements and optimizations for the blockchain application scenario. Let’s take a look at some of the important improvements to EOS-VM in combination with the documentation and code implementation.

3 Important improvements to EOS-VM

EOS-VM has made a number of improvements according to the blockchain application scenario and it’s a great gift to smart contract developers.

Let’s look at some of the improvements in the EOS-VM README documentation, and then look at how EOS-VM does it in the context of the existing EOS-VM code.

In early EOS-VM README document, Block.One listed the following improvements:

1) Satisfying the needs of a blockchain.

2) Security built into the framework.

3) Performance centric design.

4) Light weight and easy to integrate solution.

5) Effortless extendability.

The current README has been changed to a more understandable description for non-developers:

● Extremely Fast Execution (6x faster than WABT)

● Extremely Fast Parsing/Loading (20x faster than WABT)

● Efficient Time Bound Execution

● Deterministic Execution (Soft Float & Hardware Floating Point options)

● Standards Compliant

● Designed for Parallel Execution

● C++ / Header Only

● Simple API for integrating Native Calls

Let’s break it down one by one.

3.1 Meet the needs of the blockchain scenario

Firstly, Block.One’s positioning of EOS-VM is “A VM for Blockchain”.

It means that EOS-VM adds a lot of the specific functionality needed for the blockchain to WebAssembly. At present, there are mainly three aspects:

First is the support of floating point numbers. Many developers are often one-sided that floating point arithmetic is inaccurate, and cannot be used for blockchain system. In fact, it is not the case. Just for some different hardware, because of some historical reasons, the floating-point arithmetic of the hardware has some difference. The best way to solve it is to use softfloat library and do not use the machine hardware floating-point numbers. So floating-point computation results of different hardware machine are the same. Of course Block.One also mentioned that if you don’t care about all platforms keep floating-point arithmetic, you can use hardware-based floating point arithmetic, which is much more efficient than using softfloat. And it is typically used when the hardware of node machines remains unified.

Softfloat library is also integrated in EOSIO, but the previous implementation is embedded in the chain, native virtual machine itself does not support it. Now it is incorporated into the virtual machine implementation and can reduce the development cost of other blockchain using EOS-VM.

The second is that EOS-VM adds a watchdog mechanism to ensure run time limits on bytecode. A watchdog mechanism that imposes resource usage restrictions on contracts at a fine-grained level.

It is so important that a later section of the introduction document is needed to describe it.

There are a lot of messy code in EOS in dealing with the problem of contract execution timeout. For a Turing Complete smart contract, the biggest difficulty is that if we don’t perform the contract again, we will not be able to know its execution cost. Therefore, in EOS, it is necessary to determine the consumption time while executing smart contract. VM is a black box in the environment of EOS blockchain, so it will be very difficult to determine the contract execution time outside of VM. If EOS-VM provides built-in support, the implementation is simple and avoids problems in this area.

Finally, there are some virtual machine execution boundary restrictions. These boundary restrictions may appear to be some functional limitations at first glance, but in the blockchain application scenario, these restrictions do not bring the actual functional limitations, but based on these assertions, EOS-VM can be greatly optimized.

3.2 Built-in security support

A blockchain system that supports smart contracts can be seen as a common computer, and common means that users must be restricted, which would pose a big security problem if users could run their own code without restriction. For the public chain, it is not acceptable.

The security issue here is twofold: the security of code behavior and the boundedness of code consumption.

First, EOS-VM guarantees type security through built-in types, and uses the system-provided mechanism for sandboxing through an optional allocator.

In addition, the mechanism of watchdog mentioned above ensures the running time limit of running bytecode. For the public chain, if there is no effective mechanism, it will often cause some security problems. EOSIO has previously had the problem of blocking attacks based on delayed transactions, which is essentially the problem of not effectively and carefully defining the use of resources. Ethereum’s early hard fork was aimed at solving similar problems.

Finally, EOS-VM does not trigger unlimited recursion or circulation at any time, strictly limiting the number of crashes or unlimited hang-ups that WASM can cause intentionally or unintentionally.

The built-in security will greatly improve chain’s security while also providing a controllable security guarantee.

3.3 Design for high performance

In many cases, specialization is the best optimization. In fact, if WebAssembly is fully compatible, there is not much space for EOS-VM optimization. But for scenarios of blockchain requirements, many WebAssembly designs are not required. EOS-VM does a lot of specialization based on this, which means that the performance of EOS-VM is also greatly optimized.

The performance of EOS-VM mainly benefits from the optimization of its built-in types. EOS-VM has built-in data types required by most contracts, which can be optimized by EOS-VM.

In particular, ‘variant’ is not a native function. It may cause serious type securty problems if you directly use ‘union’.

Although ‘variant’ can guarantee security and ease of use in the implementation, if it is not integrated into the virtual machine layer, its complex implementation will bring a lot of performance losses.

‘vector’ is similar. If you read the current EOS system contract, you will find that vector is widely used. It is indeed very convenient to use vector for contract design.

But many performance-sensitive developers may feel “uneasy” about this, and now the VM is directly integrated with vector, you can expect them to be “more comfortable” to use it.

Today’s EOS contract development relies on a fairly small base library, which means that every contract using these base functions integrates their implementation code, bringing a lot of base library code into the wasm layer.

With EOS-VM now embedding these base types in the implementation layer of virtual machines, the performance optimization space is naturally greatly improved.

3.4 Lightweight and easily integrated architecture

EOS-VM is in the form of pure header files, which means that EOS-VM can be embedded in almost any C++ project.

At the same time, the design of EOS-VM makes it can be well adapted to multi-threaded environment. C++ multi-threaded programming was difficult and it was often necessary to avoid many problems to build a library that could run securely in the concurrent environment.

EOS-VM does a lot of work on this issue to avoid repeating the “mistake” of STD ::string in a multi-threaded environment.

There are more advantages of pure header files and EOS-VM has become much like the widely used LUA, which is also known for its lightweight runtime. It is foreseeable that more non-eos and even non-blockchain projects will use EOS-VM in the future.

3.5 Highly scalable

EOS-VM has a well-designed structure that is better than EOSIO’s code structure in some ways.

The EOS-VM was designed with extensibility in mind, and there is little to expand or modify the backbone of a VM because its functions are just the four things mentioned above. However, for different application scenarios, its bytecode format and functions must be expanded and modified. EOS-VM has been designed in response. The visitor pattern is heavily applied, making it easy to add functionality to the entire VM without changing the class architecture.

Many people think that there is no advantage for good architecture. After all, you can’t think of “well-architecting” as an “unprecedented” new feature.

However, in the case of project development, a good architecture will determine the subsequent potential of the whole project.

In general, reading current EOS-VM projects gives you a sense of ‘lua’ or ‘redis’ projects, which are small, compact, and clean. Although the heavy use of C++ features will confuse some beginners, it will not affect their understanding of functionality, and we believe that EOS-VM will play a bigger role in a wider range of areas in the future.

4 The impact of EOS-VM on the EOSIO ecosystem

EOSIO is an open source software. There are several blockchain networks launched by community with different functions and governance concepts based on EOSIO, such as EOS, EOS force, ENU, Telos, worbli, BOS and other networks, which have been developed with the technical support of Block.One. The innovation of EOS-VM will benefit all public chains based on EOSIO.

From the perspective of existing implementation, EOS-VM will try to maintain compatibility with the current EOSIO virtual machine implementation, and if there are incompatibilities, it can also be differentiated based on version in abi. In the future, even if there are a lot of blockchains that have made a lot of improvement on the underlying EOSIO code like EOSForce, it can be easily compatible.

In the future, developers of EOSIO-based public chains will be able to integrate EOS-VM into the chain, while maintaining the existing support for wasm.

EOS-VM can bring many benefits and impacts to the chain:

4.1 Saving user resource consumption

As mentioned above, using EOS-VM can improve chain’s performance, and users can save a lot of resource consumption on chain by using smart contracts running on EOS-VM.

In EOSIO-based public chain, there are usually three main resources: CPU, NET and RAM. CPU is mainly settled by the actual time consumed by contract operation. NET is mainly related to the size of transaction, while RAM is mainly determined by the memory size used by the state transformation brought by the contract.

At this stage, EOS-VM will mainly save user CPU resources, which is now the main resource limitation of EOSIO network. For EOSIO network, NET resource consumption is often fixed, while RAM can stimulate node to upgrade through continuous additional issuance, so that the supply of RAM can be increased on the network. From the perspective of hardware, the RAM upgrade space supported by current server performance is enough.

But for the CPU, the current limit is significant. As BM said in telegram, Intel hasn’t made 100 terahertz CPU. It is just a joke, but the current server’s CPU performance limit is relatively large. For server, it is mainly parallel computing ability enhancement in recent years. The performance of single core has been improved but is still insufficient.

Adding parallel computing support for EOSIO is a relatively long process, even if EOSIO can support parallel computing, it will be limited by single-core computing performance. Because for the contract, its computing process is still a single-thread. Improving the efficiency of virtual machine is very useful for the chain based on EOSIO.

4.2 Make the chain more extensible

Both the code and the architecture of EOS-VM are fairly straightforward, and in order to keep it simple in the form of pure header files, Block.One did not even introduce its fc library.

Most developers can easily read and understand the design and code of EOS-VM by simply understanding the definition documentation of wasm bytecode.

In this way, developers can easily reuse EOS-VM, especially for chains based on EOSIO technology.

Developers can simply add new types to meet the specific needs of a particular chain.

4.3 Simpler development tools

EOS-VM is in the form of pure header files, which means that EOS-VM can be embedded in any C++ project, and with simple processing, EOS-VM can also be used in projects based on other languages.

For example, interp in EOS-VM’s tools requires less than 100 lines of code to build the runtime environment of EOS-VM, which is useful for the tools for developing EOSIO contract.

Many beginners of EOS contract development want to debug contract code, which is almost impossible in the past. Although a native lib is provided in the new CDT, it cannot perfectly simulate the running environment of the contract. While “Good code doesn’t come out by debugging”, the lack of a debugging environment can be inconvenient.

On the other hand, we also have to consider the integration of contract runtimes with existing development tools, and EOS-VM is a good fit for this.

Through EOS-VM, EOSIO development ecosystem and development efficiency will be greatly improved in the future.

5 EOSIO is evolving towards a true protocol

Unconsciously, EOSIO’s official slogan has changed from “the most powerful decentralized application platform” to “ Build on Change. Build on EOSIO”.

Similarly, in the design of EOS-VM, the developers have no obvious sense of the existence of EOSIO and DPOS consensus mechanism. The design of EOS-VM is quite independent.

If you have been looking at EOSIO development, you will find that the EOSIO contract layer is gradually de-eosio. From renditions such as’ eosio_assert ‘to’ check ‘to refactorings such as the complete removal of c API calls from CDT, developers will encounter fewer and fewer “EOS” in the current EOS contract development.

A typical example is the contract migration between different EOSIO sister chains. The CDT based contracts have fewer differences between different projects now

While the early community was bothered by incompatibilities such as enu caused by a large number of unnecessary name changes, now developers can hardly feel the incompatibilities caused by enu name changes when using CDT tools.

All this means that EOSIO is evolving towards a practical protocol.

In the early days, the Block.One team was not eager to build abstract protocols and formalized yellow books like other projects, but carried out EOS development with a very pragmatic attitude, which also made EOSIO, the mainnet of the public chain, launch much earlier than other “third-generation” blockchain projects.

We believe that the block. one team will not always “build cars with full head”, but adopt a bottom-up approach to continuously develop the EOSIO ecosystem. It will evolve into a true protocol, and eventually become a highly competitive DE facto standard of blockchain protocol.

6 Block.One hits the first shot in the battle over the blockchain standard

One is the first shot in the battle over the blockchain standard.

For a long time, any software subdivision has been seeking for the integration and unification of technical standards, which is not enforced by centralized organizations, but gradually recognized by the mainstream market through the software itself, and finally becomes the DE facto technical standard.

And in the field of blockchain VM, the performance of old virtual machine such as EVM is poor and the single function of virtual machine cannot take complex smart contract. The virtual machines based on general design will become the essentials of future mainstream blockchain projects. Currently, the only option for such blockchain project is EOS-VM, which leads the industry for more than a year and will become the standard of the best smart contract operating environment. Its industry status will be similar to ARM’s in the mobile chip industry, and even ETH’s smart contract is expected to run on EOS-VM in the future.

Even we can boldly assume that EOS-VM will not be limited to the blockchain industry, and will be used in traditional software development fields like game engines, databases, and web frameworks due to its excellent design and implementation.

7 Encryption community’s open source policy and technical standards monopoly

As we know, Block.One always emphasizes that it is an open source organization when raising funds from the community, and all the money raised will be used to develop open source EOSIO software to feedback to the community, which also brings a lot of contributions to the cryptographic economy community.

But EOS-VM is unlike any previous open source project of Block.One, which has made a rare reservation to the EOS-VM project. It means that the project is not just an open source library. Reserving rights deviates from the pure open source organization positioning at the time of funding and may even limit its usage scenarios through commercial licensing.

Different from the traditional Internet industry, most of the encryption economy technology is open source, regardless of the expansion of the debate and governance philosophy are not involved in the level of technical standards. We will wait and see the impact of VM’s aiming at monopoly in open source encryption economy market.