Backwards compatibility and bug fixing

[realloc]

This proposal is closely related to #1284.

Blockchain Settings Smart Contract

With strict State verification there is a need to be able to change Blockchain constants with its lifetime. We propose to define a Settings Smart Contract Address in Genesis Block. It may be implemented as Native Contract.

This Smart Contract's storage would contain parameters and settings for Blockchain, like different types of fees, addresses of service Smart Contracts like NeoFS, lists of blocked keys and other settings that may change in the future. Neo node will track those changes and use correct values for the corresponding height. This will solve the problem of past transactions verification, as they will be executed in a deterministic way with the correct set of parameters for the particular height.

Settings Smart contract would contain methods for changing or adding parameters upon specific auditable conditions, like voting or some network parameters or events.

Block Version field

To roll out changes in behaviour that can't be expressed by the Settings Smart Contract parameters, we propose to utilize block version header. Depending on block's version, different versions of functions implementing a particular behaviour would be called.

It means for the older block version older version of VM or older behaviour implementation must be used.

New Neo releases may re-run the whole blockchain from genesis block to current height as part of release process to verify state at each step and make sure nothing is broken.

Corrective transactions

In case there is a significant bug that results in wrong data going to the State, after fixing the bug and changing the behavior for future transactions, we may need to "fix" the current state. This may be done by CN's issuing a Corrective Transaction, that would change the state values.

Such transactions must require some complex ceremony not to be abused (maybe similar to the current CN voting process) and it meets the requirement for auditable changes and verifiable solid state, while, together with block version dependent behavior, allowing to fix bugs and address unpredictable issues.

Native Smart Contracts specification

Because both Native and Regular Smart Contracts must have the same verification mechanism, Native contracts must follow the same rules of working with State as the Regular ones. It means they must never change Node's databases directly, but use common API that would trace State changes in a controllable way. Native Contracts must not have any side-effects that can't be traced via standard State change mechanism.

[shargon]

Totally agree, as i said in #2987 but you explain it better than me :)

[vncoelho]

Agree with all mechanisms