To measure the competitive advantage of a public blockchain project, the first and foremost thing to consider is whether it is capable of providing developer-friendly infrastructure. Given that smart contracts and blockchain are usually bundled together, the capability of providing a sound running environment for smart contracts is a touchstone for projects wishing to enter the industry. Virtual machines (VM), where smart contracts operate, are the key to that entrance.

It is known to all that NEO is largely driven by the community. It has attracted developers who believe that an ease-of-use and stable VM is one of the most important blockchain infrastructures. NEO was the second earliest public chain project to have released its own VM — NeoVM — which has seen continuous improvement since its release and is now able to provide a near flawless experience.

Early in 2018, NEO founder Erik Zhang presented the NeoVM at the first NEO DevCon in January 2018. Milestone upgrades from version 2.2.1 to 2.3.0 followed in June 2018. Since then, stack isolation has become a realized feature. Version 2.3.3 was released in November 2018, which allows the NeoVM to be deployed elsewhere outside the NEO network.

Stack isolation may be a challenging technical term for non-developers. To put it in plain English, it can be compared to the system upgrade from DOS to Windows. In the DOS system, the memory is shared by all programs, which means if one program encounters an error, other programs may also be affected and freeze. Windows solves this problem by running all the programs in individual instances so that one program crashing won’t affect the others. The upgrade of NeoVM solved a similar problem. By adding stack isolation, each contract can only access its own stack area, thus making the execution of smart contracts more secure and stable.

If you are interested, the history of NeoVM development is presented below for your reference.

In NeoVM 2.2.1 (as shown in Figure 1), all running contexts share a calculation stack (EvaluationStack) and a temporary stack (AltStack), and the dynamically invoked smart contract may affect the caller’s stack at runtime.

This may result in unexpected failures and security issues where a smart contract did not perform as expected.

In response to this situation, we upgraded the NEO virtual machine in v2.3.0 (as shown in Figure 2).

Figure 1: NeoVM structure prior to version 2.2

Figure 2: NeoVM 2.3 with stack isolation

It can be seen that all running contexts of the 2.2 virtual machine share a computing stack and a temporary stack, while the 2.3 version allocates a separate computing stack and temporary stack for each running context. At the same time, the operation result of version 2.2 is stored in the calculation stack. Version 2.3 adds a result stack (ResultStack) for storing the final running result of the virtual machine.

After adding stack isolation, each contract can only access its own stack area, thus preventing the destruction of the caller stack and making the execution of smart contracts more secure and stable.

New operation instructions

After adding stack isolation, we needed a new set of operation instructions to automatically copy the parameters to the new stack during the dynamic invocation. At the same time, after the run is complete, the return value is automatically copied to the caller’s stack.

The five new stack isolation related instructions are: CALL_I, CALL_E, CALL_ED, CALL_ET, CALL_EDT. Detailed documents will be released at NEO DevCon 2019.

Summary

In August 2018, NeoVM was upgraded from v2.3.0 to v.2.3.1 with bug fixes and new instruction documents as referential materials for interested developers.

In September, 2018, NeoVM was upgraded from v2.3.1 to 2.3.1.1 with a change to the Struct clone method, from recursive copy to repeat copy, which fixed the infinite recursion bug.

In November, 2018, NeoVM was upgraded from v2.3.1.1 to v2.3.3 with a minor fix on encoding and a hash dictionary added for interop services. The interop service was then changed from class to portal InteropService, which decoupled NeoVM thoroughly, making it much easier for NeoVM to be deployed outside of the NEO network.

In December, 2018, NeoVM maintenance and all-around improvements continued to make the execution more secure and reliable.

NeoVM is developer-friendly and has never stopped its pace of evolution. We believe that over the next year, NeoVM will be further improved as NEO continues to drive forward.

Author: Keypair