-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backwards compatibility and bug fixing #1287
Labels
discussion
Initial issue state - proposed but not yet accepted
Comments
Totally agree, as i said in #2987 but you explain it better than me :) |
Closed
Agree with all mechanisms |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: