Neo3 Preview4 has officially been released, bringing with it numerous pieces of new functionality including initial oracle support, the new NEP-17 token standard, and the updated economic model.

A new test network running Preview4 has subsequently been launched, allowing the latest upgrades and new features to be more easily explored by developers. The new release can be downloaded here.

Economic model updates

The new update builds on from the Preview3 release in July, which laid down the foundations for the new governance model and its 21-node committee. Implementation of the new governance mechanism and related economic model changes were completed and included in Preview4. This allows for the testing of the voting system and GAS reward distribution across NEO holders, voters, and committee members.

The new model sets the GAS per block rate on Neo3 to 5, which can be modified in the future via governance proposals. Of the 5 GAS generated each block:

  • 10% is distributed proportionally amongst NEO holders
  • 10% is distributed proportionally to committee/consensus nodes
  • 80% is distributed proportionally to voters for elected nodes

To round out the model and provide a balancing mechanism, system fees on transactions are automatically burned.

Oracles and NEP-17

Another notable inclusion in Preview4 is its initial oracle support, allowing smart contracts to request and interact with data from off-chain sources. The asynchronous oracle solution replaces the former synchronous design, removing unwanted complexity in regards to oracle transaction handling in the mempool.

Neo’s new token standard, NEP-17, also makes its first appearance in Preview4. Designed to replace NEP-5, the new standard introduces a powerful piece of functionality—the onPayment call. This new method replaces Neo2’s payable check and allows a contract to execute in reaction to receiving a transfer.

This removes the need for the two-step allow and transferFrom flow that is commonly found in EVM-based dApps, used to enable contracts to transfer tokens on a user’s behalf. With onPayment, a user can simply transfer tokens to the contract and trigger the appropriate response.

In addition to the general usability improvement for smart contracts, this functionality is also used to reject unexpected token transfers. If a contract does not expect to receive certain transfers or tokens, the onPayment method is used to cause the transfer to fail, preventing the user from ever irretrievably spending tokens into the target contract.

Other changes

Additionally, various under the hood changes included in Preview4 sought to improve the Neo developer experience. Developers coming from Neo2 that are testing out the new release may encounter a number of differences, including the newly revised and adjustable opcode pricing model.

The changes redefine opcode prices as coefficients of a base fee, which is calculated using the most basic VM instruction, NOP. This base fee can then be modified by the committee via the native policy contract, providing a mechanism for VM execution fees to be normalized if the market price of GAS fluctuates.

Other quality of life improvements for developers include changes to contract hash derivation and general upgradability. Rather than being derived from the script, the hash is also calculated using the sender, causing unique hashes to be generated when different users deploy the same code.

Furthermore, the original hash is kept when a contract is updated, intended to prevent dApps, tools, and other related services from needing reconfiguration after each contract upgrade. An update counter field has been implemented, ensuring updates are easily detected.

Tags: