NEO Global Development (NGD) has announced the release of the NEO3 Preview1 build, accompanied by the launch of the first NEO3 TestNet. The preview release is intended to help introduce community developers to major updates to be expected in NEO3.

NEO3 Preview1

Although many further changes and feature implementations are expected to be added before the official release of NEO3, the Preview1 build provides insight into some key architectural changes.

The most notable change is the move away from UTXO-based assets in favour of the account-based model currently used by NEP-5 tokens. On NEO3, all assets (including the native NEO and GAS tokens) will be created using smart contracts. This also allows all transaction types to be simplified to a single one, which is used to invoke contracts.

The use of an auto compression mechanism on P2P messages has also been implemented, which is designed to save on space, bandwidth, and increase TPS.

Contract Manifests and Pricing Model

Project developers may be interested to explore the new manifest files, which are required when deploying contracts on NEO3. These files declare important information such as any groups that the contract belongs to, its features, permissions, and other assorted information.

The manifest files are intended to make contracts more explicit about their functions whilst also enabling secure dynamic invocation through the declaration of trusted contracts or safe methods. More information on contract manifests may be found here.

To accompany these improvements to contracts, the Preview1 build includes a pricing model adjustment that dramatically reduces system fees such as contract deployment costs. The free 10 GAS system has been removed alongside the free 20 transactions per block.

Although the current release does not include a mechanism for free transactions to be provided, potential solutions and mechanisms to provide free transactions in some form are being explored. One such example would be to allow contracts to pay fees on behalf of their users.

Connecting to the NEO3 TestNet

Developers looking to run a NEO3 client will first need to download the latest build found here. In order to connect to the TestNet, the protocol.json and config.json files must first be overwritten with the contents of the protocol.testnet.json and config.testnet.json files respectively. After this has been done, neo-cli.exe may be opened.

Alternatively, users may also use an experimental NEO3 Preview1 docker build released by core developer Ricardo Prado. With docker installed, it takes three commands in the terminal to get up and running with a NEO3 TestNet node:

  • docker pull simpli/n3preview1
  • docker run -it –volume wallets:/neo-cli/wallets -p20332-20336:20332-20336 simpli/n3preview1:latest
  • dotnet neo-cli.dll

Running these three commands will first install and then run the NEO3 Preview1 experimental build. Once inside the neo-cli client, users of this version may use the command show tutorial to activate a brief walkthrough.

When creating wallets with the docker-based version, the wallets folder should be used to ensure that the files persist after docker is closed, which would otherwise result in TestNet funds being lost. For example, this can be done by using create wallet wallets/walletname.json within the CLI.

Feedback on the NEO3 Preview1 build can be submitted at the form here.

Users may request TestNet NEO and GAS using the following form, though a faucet is intended for implementation in the near future.

Launching a NEO3 PrivateNet

Developers wishing to experiment with NEO3 without needing to wait for TestNet GAS may find it more appropriate to deploy their own private networks. Splyse founder Joe Stewart lent his assistance, providing a tutorial on how the Preview1 build can be used to run a NEO3 private network using single-node consensus.

After installing the .NET SDK from Microsoft and downloading the latest NEO3 build, developers are required to update three JSON files before running the neo-cli client. Stewart also lends further instruction, explaining how to add a second non-consensus node in order to interact with the private network. This would allow developers to test invoke their own contracts.

Tags: