Versioning of protocol contracts #1135
Comments
|
Individual protocol contract versioning is highly desirable from the side of downstream tools and interfaces, which are developed against a specific ABI of a protocol contract. If the contract ABI changes for a protocol contract, or the even if the behaviour changes without a change to the ABI, it can break downstream tools and interfaces that provide strong compatibility guarantees for their users. Examples of downstream tools and interfaces would be Autonity CLI and Autonity Python SDK. In addition to individual protocol contract versions, it would be desirable to be able to check compatibility against the entire protocol in a single check, rather than have to enumerate all contracts, and then check their version one by one. Conceptually, if a single protocol contract changes, it changes the Autonity Protocol as a whole. So would it make sense for the "version" of the Autonity Protocol as a whole should increase at the same time as the upgraded protocol contract? In this way, if we are connecting to an RPC node, we can check if the version of all protocol contracts on the chain is what we expect, and if not, then we can raise an error that the chain has an unexpected/unsupported Autonity Protocol version. |
|
Note that autonity.py is checking that the value of |
Agree. |
|
Yes, that makes sense. Ideally, the upgrade manager contract would handle versioning and expose a global protocol contracts version. However, I’d argue that some upgrades are entirely transparent to users and are implemented solely for internal improvements. Would it make sense to adopt a simple double-digit versioning scheme like "X.Y," where X represents a compatibility-breaking change and Y signifies a minor update? To support this, we could update the upgrade method in the upgrade manager contract to include an additional flag indicating whether the update is minor. |
It would make sense to use a versioning scheme that distinguishes between a breaking upgrade and a fully backward-compatible upgrade. However I am wondering, instead of a custom versioning scheme, if it's better to just adopt the well-known three-digit semantic versioning scheme, as it's only one more digit, instead of a custom version scheme. |
|
Without changing the upgrade manager, we can just manage a const version field out from the state of the contract, thus that the version is compiled into the binary, once the contract is upgraded, the version will be accessible by calling a pure function. In this way, we just need to upgrade the contract that we officially released, there is no state management are required since the version is in the bytes code. |
Each protocol contract should have a version, so that we can track upgrades at chain runtime.
The tricky thing is how to manage the increment of the version number on upgrade. Some possibilities are:
UpgradeManagercontract manages all versioning by itselfincrementVersionfunction on the upgraded contractThe text was updated successfully, but these errors were encountered: