Neo Releases Neo3 Preview4 With Updated Business Model, NEP-17, Initial Oracle Support, And More


Neo3 Preview4 has been officially released, bringing with it many new features including initial Oracle support, the new NEP-17 token standard, and the updated business model.

A new test network running Preview4 was then launched, making it easier for developers to explore the latest upgrades and new features. The new version can be downloaded here.

Updates to the business model

The new update builds on July’s Preview3 release, which laid the groundwork for the new governance model and its 21-node committee. The implementation of the new governance mechanism and associated business model changes have been completed and included in Preview4. This allows testing of the voting system and distribution of GAS rewards among NEO holders, voters and committee members.

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

  • 10% is distributed proportionately among the NEO holders
  • 10% is distributed proportionally to committees / consensus nodes
  • 80% is distributed in proportion to the voters for the elected nodes

To complete 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 old synchronous design, removing unwanted complexity in handling Oracle transactions 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 feature: the onPayment call. This new method replaces the payable check from Neo2 and allows the execution of a contract in reaction to the reception of a transfer.

This eliminates the need for the two-step procedure To allow and transfer from A stream commonly found in EVM-based dApps, used to allow contracts to transfer tokens on behalf of a user. With onPayment, a user can simply transfer tokens to the contract and trigger the appropriate response.

In addition to the general improvement in the usability of smart contracts, this feature 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 fail the transfer, preventing the user from irretrievably spending tokens in the target contract.

Other changes

Additionally, various under-the-hood changes included in Preview4 were aimed at improving the experience for Neo developers. Developers coming from Neo2 testing the new version may experience a number of differences, including the newly revised and adjustable opcode pricing model.

The changes redefine the prices of the opcodes as coefficients of a base royalty, which is calculated using the most basic VM instruction, NO. These base fees can then be changed by the committee through the native policing contract, providing a mechanism for standardizing VM execution fees if the market price of GAS fluctuates.

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

Additionally, the original hash is preserved when updating a contract, to prevent dApps, tools, and other related services from needing to be reconfigured after each contract upgrade. An update counter field has been implemented, ensuring that updates are easily detected.

Source link


Leave A Reply