Neo has announced the release of Neo-CLI v3.3, featuring a range of new functionality including snapshot isolation and new opcodes for supporting zero-knowledge applications. Unlike most previous updates, v3.3 includes code-level price changes, requiring a coordinated hard fork.

Aspidochelone hard fork

Neo-CLI v3.3 is set to land on the T5 TestNet on June 2. In the update, price factors were altered for several system calls, including CreateMultiSigAccount, GetNotifications, and GetRandom.

Since changes to these values will affect the GAS costs of transactions that use them, it is required that the nodes on the network agree to implement the new values at the same time. If they didn’t, they would quickly become out of sync with each other, disagreeing on what the correct prices of transactions and resulting GAS balances are based on what block they made the changes on.

This is avoided through a coordinated event known as a hard fork. Though the pricing changes are implemented at the code level, they will only be activated at a predetermined block height. Nodes on the network can update to the new version at any time prior to the update to ensure they will adjust on schedule and synchronize in a correct state.

The hard fork, dubbed Aspidochelone, will come into effect at block height 210,000 on the T5 TestNet (estimated to occur on June 5). Should the usual two week testing period progress without issue, the fork will be applied on MainNet at height 1,730,000. Node runners are recommended to update at their earliest convenience to avoid issues, which will require a full resynchronization.

Zero-knowledge tools

A number of other improvements are also included in the release. Most notably, the new MODMUL and MODPOW opcodes are implemented, which act as the groundwork for more advanced on-chain cryptography, including applications based on zero-knowledge proofs.

Other changes in v3.3 include general bug fixes and the addition of candidate-related events to native contracts. Notifications have been added for vote invocations and changes in candidate state.

Snapshot isolation

Another significant update is snapshot isolation, applied as a measure to address the issue of exception passthrough in cross-contract invocations. The problem lies with the fact that exceptions thrown by one contract could be caught by another.

It might be the intention of the developer of the first contract to throw an error message and rollback any changes to the contract storage, however this exception could be caught if the call was made in another contract. This could lead to situations where the first contract does not have its state changes reverted as desired, leading to unexpected outcomes.

Transactions on blockchains are designed to be atomic, meaning that either all parts of the transaction succeed or none of them do (so any changes made along the path of execution are reverted if something goes wrong).

With snapshot isolation, any storage changes are stored independently for each separate call, as is also done in Ethereum. If one contract calls another which throws an exception, any storage changes in the second contract will be reverted, allowing the contract making the call to safely recover from exceptions.

The original announcement can be read at the following link: