In the past year, together with the NEO community, we accomplished the development of NEO 2.x. NEO 2.x provided essential infrastructure mechanics of the NEO Smart Economy. Now, it's time to look ahead. What's next? The short answer is NEO 3.0, of which development started in the last quarter (Q2 2018).

What is NEO 3.0? What are the key features of NEO 3.0? Today, NEO co-founder and core developer Erik Zhang shares with us the latest features and improvements of NEO 3.0. 

Erik Zhang: 

NEO 3.0 will be an entirely new version of the NEO platform, built for large scale enterprise use cases. It will provide higher TPS and stability, expanded APIs for smart contracts, optimized economic and pricing models, and much more. Most importantly, we will entirely redesign NEO's core modules.

1. Various Improvements

1.1. Increasing TPS

Increasing the TPS is important if we want to run large-scale distributed applications on NEO. In NEO 3.0, we will increase the TPS in the following ways:

• Refactor the code and core modules
• Optimize the network protocol
• Implement the feature manifest and permission system for NeoContract
• Prepare for dynamic sharding
• Detach state persistence and block persistence

1.2. Bug fixes

In NEO 3.0, we will fix some known bugs and significantly improve system stability.

2. Protocol

2.1. Adjusting the economic model

We designed a dual-token economic model for NEO, which has proven to be a very successful model. However, there were also problems: NEO was indivisible, and GAS could not be divided when paying for system fees (sys_fee). These issues were roadblocks for the utility of NEO and GAS tokens. To solve this problem, some adjustments to the economic model need to be applied. Some of the possible adjustments are:

• A small increase in the supply of gas every year
• Reward consensus nodes
• Make NEO divisible
• Allow gas to use the decimal part when being used for system fees

(This is suggestion only. This issue is being discussed at: https://github.com/neo-project/neo/issues/285)

2.2. Adjusting the system pricing model

For developers, expensive system fees have become a primary concern. In NEO 3.0 we will make adjustments to the pricing model so that the cost of running and deploying smart contracts will be significantly cheaper.

3. Smart Contract

3.1. Cross-platform smart contracts

Smart contracts should be able to be executed on different blockchain platforms, if they're made compatible with NEO 3.0. To achieve this, we need not only NeoVM support, but also unified smart contract APIs. In addition, we also provide an API for platform detection.

• System.Runtime.Platform

This allows the smart contract to detect the current platform at runtime.

3.2. Feature manifest and permission system

When a smart contract is deployed, it must explicitly declare the features and permissions it will use. When it is running, it will be limited by its declared list of features and permissions, and cannot make any behavior beyond the scope of the list.

3.3. Native contracts

Native contracts are smart contracts that are not run in a virtual machine. Instead, it's built directly into the blockchain code. Native contracts can still expose their script hashes to other contracts, so that other contracts can invoke them.

Native contracts can allow for the interaction with NEO and GAS (and all global assets) as NEP-5 tokens. This introduces a unified approach for sending and receiving assets in smart contracts.

3.4. Callback APIs

Create callback functions for smart contracts or SYSCALL, and allow other contracts to perform tasks through callback functions, which can work with iterators.

3.5. Other new APIs

We will add some new APIs to NEO 3.0. Some APIs that may be added:

• System.Account.IsStandard
• System.Runtime.GetEntryContract
• System.Runtime.GetCallingContract
• System.Runtime.GetExecutingContract
• System.Runtime.GetInvocationCounter
• System.Runtime.GetNotifications

4. NeoVM

4.1. Fully decoupled

Currently, contract invocations are made with the APPCALL instruction (and the corresponding stack isolation instruction), and NeoVM will directly look for the target contract. This is unreasonable because the list of smart contracts on the blockchain should not be directly visible to NeoVM.

We need to create a new API to invoke contracts with SYSCALL, and discard the original APPCALL instructions. This would introduce two additional benefits:

• We do not need to do extra work to implement stack isolation, because invoking a new contract in SYSCALL will start a new virtual machine.
• We can easily implement native contracts.

4.2. Support for global variables

Currently, NeoVM does not support global variables. The code with global variables will fail to compile. This is because NeoVM is a stack based virtual machine, with no storage methods for global variables. This makes it difficult to compile smart contracts written in high-level languages. To solve this problem, we need to add a global array for the virtual machine to store all the global variables. We also need to add a new opcode (“GLOBAL”) which pushes the global array to the evaluation stack. Then we can use PICKITEM and SETITEM to access global variables.

5. Conclusion

NEO will be reborn in 3.0 and will better serve the Smart Economy. In the future I will present more features of NEO 3.0, and publish a series of articles detailing technical points more in-depth.

You can see all the current improvement proposals for NEO 3.0 on the GitHub. (Github link: https://github.com/neo-project/neo/milestone/1) And we warmly welcome discussions and suggestions from the community on these proposals.