A glimpse of Block.one 's ambition: EOS-VM preempts the Virtual Machine track

The EOSIO1.8.0 version shows Block.one 's determination on EOS.IO, and EOS-VM gives us a glimpse of Block.one 's ambitions in the blockchain industry. Guya believes that EOS-VM is an important cornerstone of EOS.IO to become a general block chain protocol, surpasses EOS.IO itself, and will become the technical standard of block chain virtual machine. What is VM in detail in this article? What is EOS-VM? What is the improvement of EOS-VM and its impact on the ecology of EOS.IO? Block.one may have fired the first shot in the fight over blockchain standards, and the open source and technical standards monopoly of the encryption community may enter the public eye.

Original title: "Block chain Industry will usher in the first Technical Standard Competition: EOS-VM preempting Virtual Machine track" by Guya, founder of EOS Force

Original title: "Block chain Industry will usher in the first Technical Standard Competition: EOS-VM preempting Virtual Machine track" by Guya, founder of EOS Force

EOS-VM is an important cornerstone of EOS.IO to become a general block chain protocol, at the same time, beyond EOS.IO itself, it will become the de facto technical standard of block chain virtual machine, and even stifle the development of virtual machine in the initial stage of Ethernet and Boca in its infancy.

0 preface

Block.One, the EOS.IO development team, released the new EOS-VM on June 1, 2019.

After large-scale testing, the EOS Force team believes that EOS-VM will become the most used VM, in the blockchain industry and will be the first to become the de facto standard of VM in the blockchain industry.

As we said in our article "EOS.IO is about to usher in the most complex hard bifurcation upgrade in history," a number of important branches are under active development, and EOS-VM is no less important than 1.8.0. it is a branch that is no less important than 1.8.0. as we said in our article, "the most complex hard bifurcation upgrade in history," a number of important branches are being actively developed. The branch began in July 2018, and according to the submission record, the early EOS-VM did not have a particularly tight development plan. However, since 2019, after a series of intensive development, we have initially completed the EOS-VM project we see today.

If the EOSIO1.8.0 version shows us Block.one 's determination on EOS.IO, EOS-VM gives us a glimpse of Block.one 's ambitions in the blockchain industry.

1 what is VM

The full name of VM is Virtual Machine, which can be understood as the running environment of intelligent contract in blockchain context.

We can compare the intelligent contract to the HTML, blockchain system in the Internet can be regarded as the operating system, then the VM is the browser, all kinds of DAPP based on the intelligent contract are all kinds of websites in the Internet.

Ethernet Square completed the intelligent contract support of the first system in the blockchain system, and its EVM virtual machine is also the mainstream development environment for early intelligent contract developers. At the same time, many projects have borrowed from the VM, of Ethernet Square, such as the TVM of TRX.

However, EVM has its limitations, virtual machine efficiency is relatively mature virtual machine system is extremely low, it is difficult to support more complex applications and environments.

A mature virtual machine system is a system composed of a series of huge projects. In fact, in the current environment, it is very difficult and unnecessary to implement a complete and mature virtual machine system from scratch. Because for such a huge engineering project, starting from scratch means that developers and the community have to bear a lot of compatibility and learning costs. The best way is to develop a virtual machine implementation that is suitable for blockchain projects based on existing mature virtual machine standards.

Therefore, most blockchain projects choose to use the existing mature virtual machine implementation, it can be said that the most suitable virtual machine is WebAssembly virtual machine. In addition to EOS.IO, polkadot also chooses to be based on WebAssembly, and Ethernet Fang is also developing WebAssembly-based ewasm projects.

WebAssembly has become a very important part of the blockchain domain, whether it is "The Lesser Evil" or not.

As a high-performance decentralized intelligent contract platform, the virtual machine implementation used in EOSIO is a very important part of the whole project. When reading the early EOSIO implementation code, we will find that when calling the virtual machine, few of the EOSIO implementation code has done a very strict encapsulation, in order to hide the details of the virtual machine implementation. It can be seen that the EOSIO project will continue to make significant improvements in the virtual machine.

From the earliest wavm virtual machines to the wabt virtual machines supported later, the Block.one team has been improving the support of virtual machines and preparing for multi-virtual machine compatibility. Finally, EOSIO launched a higher challenge and developed a new virtual machine implementation used by EOS-VM, as the most EOSIO virtual machine.

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 first take a look at what EOS-VM is. EOS-VM is a wasm runtime dedicated to blockchain systems.

In blockchain systems, contract code is compiled into bytecode form, which cannot be run directly on the operating system and requires an actuator to execute these contracts. In software architecture, these actuators can be regarded as an abstract "machine". EOS-VM is such an actuator.

EOS-VM does four main things:

First, EOS-VM is responsible for loading and parsing the compiled smart contract bytecode, that is, wasm;

Second, EOS-VM is responsible for allocating resources to bytecode while it is running, and of course, for smart contracts, the available resources are memory;

Thirdly, EOS-VM is responsible for providing the API calling function outside the virtual machine to the bytecode of the intelligent contract.

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

In EOS-VM, the eosio::vm::backend class is the entry point for the entire virtual machine system call. In the tools directory, there are two testing tools that use EOS-VM virtual machines. Readers who want to learn more about the EOS-VM implementation can use these as portals to read the code of EOS-VM.

The main work of EOS-VM is mentioned here, but if it is just these, it is no different from wavm and wabt. In addition to completing the basic necessary work, EOS-VM has made some important improvements and optimizations for blockchain application scenarios. Let's combine the introduction documentation and code implementation of EOS-VM to see what important improvements EOS-VM has.

3 what are the important improvements to EOS-VM

EOS-VM has made a number of improvements to the blockchain application scenario, which are the best gifts for smart contract developers.

Let's take a look at the improvements in conjunction with the EOS-VM README documentation, and then take a look at how EOS-VM works with the existing EOS-VM code.

In the early README of EOS-VM, 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 is 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 analyze them one by one:

    First of all, Block.one positioned EOS-VM as "A VM for Blockchain," which means that EOS-VM adds a lot of specific features required by the block chain on top of WebAssembly.

    At present, there are mainly three aspects:

    The first is the support of floating point numbers. For floating-point numbers, many developers tend to think that their operations are imprecise and can not be used in blockchain systems. In fact, this is not the case, but for some different hardware, because of a variety of historical reasons, there are some differences in the solidified floating-point operation in the hardware. The best way to solve this problem is to use the softfloat library, not to use the floating-point number provided by the machine hardware, so that the results of floating-point operation are the same on different hardware machines. Of course, Block.one also mentioned here that if you don't care to keep floating-point operations deterministic on all platforms, you can use hardware-based floating-point operations, which is much faster than using softfloat, which is typically used by node hardware machines in a unified state.

    The softfloat library is also integrated in EOSIO, but the previous implementation is embedded in the chain, which is not supported in the native virtual machine itself, and can now be incorporated into the virtual machine implementation to reduce the development cost of other blockchains using EOS-VM.

    Second, EOS-VM adds a watchdog mechanism to ensure the run-time limit for running bytecode, a watchdog-like mechanism that limits the use of resources on contracts with fine granularity.

    This is so important that later introductions are described in a separate section.

    If you look at the current code of EOS, you will find that there are a lot of messy code dealing with the problem of contract execution timeout. For a Turing complete intelligent contract, the biggest difficulty is that if we do not execute its contract once, we will not be able to know its execution consumption. therefore, in EOS, we need to determine the consumption time while executing the intelligent contract. For the environment of the EOS chain, VM is a black box. So it will be very difficult to determine the execution time of the contract outside of VM, and EOS-VM provides built-in support in this respect, the relevant implementation will be very simple, and will avoid problems in this area.

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

    Blockchain systems that support smart contracts can be treated as a public computer, which means that users must be restricted. If users can run their own code without restrictions, it can cause a lot of security problems, which is unacceptable for public chains.

    The security issues here are mainly two aspects: the security of code behavior and the boundedness of code consumption.

    First, EOS-VM ensures the security of the type through the built-in type, and uses the mechanism provided by the system through an optional allocator to ensure sandbox.

    In addition, the watchdog mechanism mentioned above ensures the run time limit for running bytecode. For the public chain, if there is no effective mechanism, this will often lead to the security of the public chain. EOSIO has had the problem of blocking attacks based on delayed transactions before, which is essentially a problem that does not effectively and carefully define the use of resources. The corresponding etheric square also appears the similar problem many times, the etheric square early several times hard bifurcation is to solve this kind of problem.

    Finally, EOS-VM does not trigger unlimited recursion or loop at any time, strictly restricting certain situations where WASM intentionally or unintentionally causes crashes or unlimited machine suspensions.

    These built-in security support will greatly improve the security of the chain, but also provide a controllable security guarantee.

    In many cases, specialization is the best optimization.

    In fact, there is not much room for EOS-VM optimization if it is fully compatible with WebAssembly,. However, for the requirements scenario of block chain, many WebAssembly designs are not needed. EOS-VM has done a lot of specialization based on this, at the same time, it means that the performance of EOS-VM has also been greatly optimized.

    EOS-VM performance is mainly due to the optimization of its built-in types. EOS-VM has built-in most of the data types required by the contract, for which EOS-VM can optimize them one by one, especially since the type variant, is not really a native feature. If you use something like union directly, it can cause a lot of type safety problems, although the use of variant, is well guaranteed in terms of safety and ease of use. However, if it is not integrated into the virtual machine layer, then its complex implementation will bring a lot of performance loss.

    Similarly, if vector, reads the current EOS system contract, it will be found that heavy use of vector, is very convenient for contract design, but many developers who are particularly sensitive to performance may feel very "upset" about this. VM direct integration with vector, can now be expected to follow these developers to be "more enjoyable" to use vector.

    Today's EOS contract development needs to rely on a basic library that is not small, which means that every contract that uses these basic functions has to integrate existing code, bringing a large amount of basic library code into the wasm layer. Now EOS-VM embeds these basic types in the implementation layer of the virtual machine, and the performance optimization space is naturally greatly improved.

    EOS-VM is a pure header file, which means that EOS-VM can be embedded in almost any C + project.

    At the same time, EOS-VM has done special treatment in the design, so that EOS-VM can adapt to the multi-thread environment well. C + multi-thread programming was once a "deep pit". Building a library that can run safely in a concurrent environment often needs to avoid a lot of problems. EOS-VM has made a lot of preparations on this issue, which can avoid repeating the "mistakes" of std::string in the multi-thread environment.

    There are many advantages of pure header files, in this respect EOS-VM has been widely used in many ways like LUA, the latter is also known for its lightweight runtime, and it can be predicted that more non-EOS or even non-blockchain projects will use EOS-VM in the future.

    EOS-VM has a finely designed structure, and in some ways EOS-VM is much better than EOSIO's code structure.

    The extensibility of EOS-VM is fully taken into account in its design, and there is little room for expansion and modification of its backbone structure for a VM, because its functionality is just the four things mentioned above.

    However, for different application scenarios, its bytecode format and function must be extended and modified. EOS-VM has been designed in response, in which the visitor pattern is deeply applied, so that it is easy to add functionality to the whole VM without changing the class architecture.

    In the eyes of many people, a good architecture doesn't seem to work. After all, you can't think of "well-structured" as a "unprecedented" new feature, but for project development, a good architecture determines the subsequent potential of the entire project.

    In general, read the current EOS-VM project, there will be a similar feeling of lua or redis project, the whole project is small, compact, the code is very clean.

    Although the heavy use of the C + feature will confuse some beginners, it will not affect the understanding of functionality, and we believe that EOS-VM will play a greater role in a wider range of areas in the future.

    (4) the effect of EOS-VM on the ecology of EOSIO

    EOSIO as an open source software, the community based on EOSIO launched different functions and governance concepts of the EOS network, EOS, EOS Force, ENU, Telos, worbli,BOS and other networks have been developed with the technical support of Block.one, and this reform of VM will benefit all public chains based on EOSIO.

    From the point of view of the existing implementation, EOS-VM will try to be compatible with the current EOSIO virtual machine implementation, where there is incompatibility, or it can be distinguished based on the version in abi. In the future, even if there are a large number of blockchains that have made as many improvements to the underlying EOSIO code as the EOS Force, they can be easily compatible.

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

    The introduction of EOS-VM can bring a lot of benefits and effects to the chain.

    As mentioned above, using EOS-VM can improve the performance of the chain, and users can save a lot of resources on the chain by using smart contracts based on EOS-VM.

    In the common chain based on EOSIO, there are often three kinds of resources: CPU, NET and RAM,CPU are mainly settled by the actual time consumed by the contract operation. NET is mainly related to the size of the transaction, while RAM is mainly based on the amount of memory used in the state transition brought about by the contract.

    Among them, at the present stage, EOS-VM will mainly save users CPU resources, which is also the main resource limitation of EOSIO network. For EOSIO network, NET resource consumption is often fixed, and RAM can encourage nodes to upgrade through continuous issuance, so that the supply of RAM can be increased on the network.

    From a hardware point of view, the RAM upgrade space supported by the current server performance is still very abundant, but the current restrictions on CPU, are very large, just like the "complaints" made by BM in the telegram group. Intel did not create a 100THz CPU, for EOS. Of course, this is just a joke, but it is true that the current server CPU performance limit is still relatively large, for the server. In recent years, it is mainly the improvement of parallel computing power, although the performance of single core has also been improved to a certain extent, but it is still insufficient.

    Adding parallel computing support to EOSIO is a long process. Even if EOSIO can support parallel computing, it will be limited by the performance of single-core computing, because for contracts, the computing process is still single-threaded, improves the efficiency of virtual machines, and is very useful for EOSIO-based chains.

    Both the code and architecture of EOS-VM are very simple and clear, in order to keep it simple and pure head file, Block.one did not even introduce its "ancestral" fc library, most developers just have a brief understanding of the definition document of wasm bytecode, they can read and understand the design and code of EOS-VM without obstacles.

    In this way, developers can easily carry out secondary development on the basis of EOS-VM, especially for some EOSIO technology-based chains, developers can simply add new types to meet the special needs of specific chains.

    EOS-VM is a pure header file, which means that EOS-VM can be embedded in almost all C + projects, and with simple processing, EOS-VM can be developed based on other languages.

    For example, interp, in tools in EOS-VM takes less than 100 lines of code to build a run-time environment for EOS-VM, which is useful for developing tools for developing EOSIO contracts.

    Many beginners of EOS contract development will want to debug contract code, which was almost impossible in the past, although the new version of cdt also provides a native lib, but this is not the perfect simulation contract running environment.

    Although "good code is not pulled out," the lack of a debugging environment can also cause some trouble. On the other hand, we also need to consider the integration of contract runtime with existing development tools, and EOS-VM can well meet this.

    Through EOS-VM, the development ecology of EOSIO will be more perfect in the future, and the development efficiency will be greatly improved.

    5 EOSIO is evolving to a true protocol

    Unwittingly, EOSIO's official website, slogan, has changed from "the most powerful decentralized application platform" to "build on chang,build on EOSIO." Also in the design of EOS-VM, developers have been unable to clearly feel the existence of EOSIO and DPOS consensus mechanism, the design of EOS-VM is very independent.

    If you have been paying attention to the development of EOSIO, you will find that the contract layer of EOSIO is gradually de-EOSIO, from the renaming of eosio_assert to check to the refactoring of removing capi calls completely in cdt. In the current EOS contract development, developers will encounter less and less "EOS".

    A typical example is the contract migration between different EOSIO sister chains. Now the difference between different projects based on cdt contracts has become less and less. The early community used to be very troubled by the incompatibility caused by a large number of unnecessary renaming such as enu, but now if you use the cdt tool, developers can hardly feel the incompatibility caused by enu renaming.

    All of this means that EOSIO is evolving to a real protocol.

    In the early days, the Block.one team was not eager to build abstract protocols and formal yellow books as other projects, but carried out the development of EOS in a very pragmatic manner, which in some ways made EOSIO, the main network of the public chain, start much earlier than other "third-generation" blockchain projects.

    We believe that the Block.one team will not be "buried in the car" all the time, but will continue to develop the EOSIO ecology from the bottom up, make it evolve to a real agreement, and eventually become a very competitive de facto standard of blockchain agreement.

    6 Block.one fired the first shot in the battle for blockchain standards

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

    In the field of blockchain VM, the performance of old virtual machines such as EVM is poor, and virtual machines with single function cannot carry complex intelligent contracts. Virtual machines based on general design will become the necessity of mainstream blockchain projects in the future. At present, the only option for such blockchain projects is that EOS-VM,EOS-VM will lead the industry for more than a year, which will become the standard of the best intelligent contract running environment. Its industry status will be similar to that of ARM in the mobile chip industry, and even the smart contract of ETH 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, but will even be used in traditional software development areas such as game engines, databases, and Web frameworks because of its excellent design and implementation.

    7 Open Source and Technical Standard Monopoly in encryption Community

    As we all know, Block.one has always stressed that it is an open source organization when raising money from the community, and the money raised has to be used to develop open source EOSIO software to give back to the community, and has also made a great contribution to the encryption economy community.

    But unlike any previous open source project at Block.one, Block.one rarely reserves its rights to the EOS-VM project, which means that the project will not be just an open source library like other open source libraries. The act of reserving rights deviates from the positioning of the purely open source organization at the time of fund-raising, and may even limit its usage scenarios through commercial licensing.

    Different from the traditional Internet industry, most of the technologies of the encryption economy are open source, whether the dispute over expansion or the concept of governance does not involve the level of technical standards. What kind of impact will be brought about by the emergence of a monopoly VM in the open source encryption economy market, we will wait and see.

    Chain News only provides relevant project information and does not constitute any investment advice.

    Does not constitute any investment advice.

    Firmly put an end to all kinds of token issuance and hype, if you find that the article contains sensitive information, please click "report", we will deal with it in a timely manner.