A Deep Dive into NEO3 Preview1 Features

Published in

The Neo Pulse

7 min readSep 16, 2019

The first preview version of NEO3 has been optimized and improved in many aspects, including architecture, stability, and performance. It also features a redesigned pricing model that significantly reduces development costs. All of these changes are intended to support large-scale commercial applications on NEO3.

The below summarizes some of the features found in NEO3 Preview1. There will be more new features included in the follow-up releases, so please stay tuned.

Architecture Optimization

Account model

In NEO2.x, there are two ways to create assets on NEO. The first is to create a global asset with RegisterTransaction, and the second is to create a contract asset by writing a smart contract. In practice, global assets are rarely used, and most applications create contract assets due to their flexibility and functionality. Since global assets are not integrated with smart contracts, managing global assets in smart contracts is very difficult.

Therefore, in NEO3, all the UTXO-based global assets have been removed and replaced in favor of the contract-based account model. NEO and GAS are implemented as native contracts and follow the NEP-5, NEP-10 standards so that the operation of digital assets follow a unified standard.

Smart contracts

Native Contract

Native contracts are written in native language rather than NeoVM opcode script, and are embodied as interoperable services executed in NeoVM. The native contract exposes its service name to other contracts for invocation. Currently, there are three types of native contracts: NeoToken, GasToken, and PolicyContract.

NeoToken referred to as NEO, acts as the governance token which is used to enforce the management of the NEO network and conforms to the NEP-5 standard.

GasToken referred to as GAS, is a fuel token which is used to pay the handling fees on the NEO network, in line with NEP-5 standards.

PolicyContract is the contract for configuring the consensus strategy and saves relevant parameters in the consensus process, including maximum transactions per block, maximum low-priority transactions per block, maximum low-priority-transaction size, the fee per byte, etc.

Application Manifest and ScriptHeader

Now each contract is required to provide a manifest file to describe its properties, including Groups, Features, ABI, Permissions, Trusts, SafeMethods, as shown below:

Groups: Declare the groups to which the contract belongs. Each group is identified by a public key and a signature.

Features: Declare the features of the smart contract. Where the attribute value storage indicates that the contract can access the storage area, and the payable indicates the contract can accept the transfer of assets.

ABI: Declare the interface information about the smart contract, you can refer to NEP-3 for the details. The basic properties of the interface include:

Hash: the script hash of the contract. It is encoded as a hexadecimal string in big-endian;
EntryPoint: a Method object which describes the details of the entry point of the contract, including name, parameters, and the value returned;
Methods: an array of Method objects which describe the details of each method in the contract;
Events: an array of Event objects which describe the details of each event in the contract.

Based on the ABI information, mutual invocation between contracts can be realized.

Permissions: Declare which contracts may be invoked and which methods can be called. If a contract invokes a contract or method that is not declared in the manifest at runtime, the invocation will fail.

Trusts: Declare which contracts or groups can call the contract safely.

SafeMethods: Declare an array containing a set of method names. SafeMethods usually won’t modify the storage area, only involved in reading the blockchain data. If a method is marked as safe, the user interface will not give any warnings when it is called by any other contract.

New smart contract APIs

Added System.Runtime.Notify to allow messages to be passed between contracts. For example, consider a contract built to run a decentralized exchange. When a user needs to deposit, he will first transfer some NEP-5 tokens to this contract and then call its deposit method. In the deposit method, the contract can confirm that the user actually transferred the tokens by calling System.Runtime.Notify .

In addition, Neo.Json.Serialize, Neo.Json.Deserialize have been added to enable the contract to support the processing of JSON data and simplify contract development.

Transaction

Single transaction type for all blockchain interactions

In NEO 2.x, there are 9 different transaction types: MinerTransaction, IssueTransaction, ClaimTransaction, EnrollmentTransaction, RegisterTransaction, ContractTransaction, StateTransaction, PublishTransaction, and InvocationTransaction. These transaction types are either related to a particular application scenario or provide more niche functionality. But in NEO3, there will only be one transaction type, the format is as follows:

Scoped witness for signature usage

Currently the witness is valid in the global scope. In order to enable users to control the scope of signatures more finely, NEO3 has changed the cosigners field in the transaction structure to realize the function that witnesses are limited to verifying specified contracts. The structure of Cosigner as following:

The Scopes field defines the scope of witness, including the following four types:

The result of transaction execution is now being stored

At present, the success or failure of the transaction execution is also stored. The transaction information can be queried to confirm whether the transaction was successfully executed by NeoVM, such as confirmation of a cross-chain transaction.

Block

Currently, we add MaxSize for block and block witness (to better prevent spam attacks), and changed the time unit of the block timestamp to milliseconds for IoT use cases.

NeoVM

NeoVM is a lightweight virtual machine for executing smart contracts. It features fast startup, low resource consumption, and supports multiple high-level programming languages to allow developers to build contracts with familiar tools.

In NEO 3.0, NeoVM has been completely decoupled from the blockchain and become a pure virtual machine by moving opcode fee to ApplicationEngine and simplifying the instructions. The following opcodes have been discarded: APPCALL, TAILCALL, SHA1, SHA256, HASH160, HASH256, CHECKSIG, VERIFY, CHECKMULTISIG, CALL_I, CALL_E, CALL_ED,CALLET, `CALLEDT`, etc.

There are several advantages:

Easy implementation of native contracts.
Application scenarios of NeoVM outside the blockchain.
Smooth Integration of NeoVM into any IDE and easy debugging of smart contracts without loading blockchain data.

Stability enhancement

Delegated Byzantine Fault Tolerance (dBFT) is a consensus mechanism designed specifically for blockchains. A set of consensus nodes are selected through a voting process, and these consensus nodes jointly generate and validate blocks. As consensus nodes are required to come to an agreement on a new block before it is committed to the blockchain, dBFT provides single block finality, meaning the NEO blockchain cannot be forked and transactions are irreversible. Once a transaction is confirmed on the blockchain, it cannot be reversed or cancelled. For financial applications, the finality of a transaction is a necessity.

In dBFT 2.0, we added a recovery mechanism that greatly improves the stability of the consensus algorithm. In the rare occurrence of a network failure or a node failure, a quick recovery is expected.

Performance enhancement

NEO3 added auto compression mechanism on P2P messages, which provides great savings on space and bandwidth, and also increases TPS.

Some compression samples are as follows:

Pricing model

System fee

The system fee is calculated by opcodes to be executed by the NEO virtual machine, please refer to the opcode fee section in the NEO3 Development Guide on GitHub for specific fees on each opcode. The 10 GAS free system fee has been removed in NEO3. The total fee is subject to the quantity and type of instructions in the contract script. The calculation formula is as follows:

Network fee

The network fee is the fee paid by users when they submit transactions to the NEO network and it will be distributed to the validator for producing new blocks. For each transaction, there is a base minimum network fee which is calculated as the following formula. Transactions will be executed only when the network fee paid by the user is equal to or higher than the base network fee. Otherwise, the transaction will be determined to be invalid.

Where VerificationCost is the costs for transaction signature verification in NeoVM, tx.size is the byte length of transaction data, FeePerByte is the fee per byte, which is 0.00001GAS as defined in the PolicyContract.