-
Notifications
You must be signed in to change notification settings - Fork 50
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
Add ProtocolStateVersionUpgrade
service event
#464
Add ProtocolStateVersionUpgrade
service event
#464
Conversation
accepting broken assets.go, will regenerate after cherry-pick is complete
broken assets.go
Previously service events could only be emitted in the system chunk. With onflow/flow-go#5828, we can directly emit them in governance transactions.
/// Emits the given protocol state version upgrade event. If the version and active are | ||
/// valid, this will cause the Protocol State to upgrade its model version when the | ||
/// event is incorporated. | ||
access(all) fun emitProtocolStateVersionUpgrade(newProtocolVersion: UInt64, activeView: UInt64) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any validation we can do on these inputs? Like the view needs to be in the future, version needs to be greater than the current version, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can check that view needs to be in the future (but the actual acceptance criteria is more involved). We can't check the version is greater than current, because the current version only exists in the protocol state.
The complete validation is done in the Protocol State Machine, where the service event is processed. Even if we partially replicate the validation here, we still need to wait for the service event to be processed at the Protocol level before we know it was successful.
Since emitting these events is not state-changing from the smart contract perspective (you can emit as many as you want, it doesn't change any on-chain state), I'm inclined to keep all the validation only in the Protocol State machine. I'll add some documentation to explain this.
This PR adds a minimal version of a service event to upgrade the protocol state version (see also onflow/flow-go#5428). This PR replaces #419 and targets the EFM Recovery branch, as we intend to deploy this change alongside EFM Recovery.
There is an integration test validating the new service event is processed in onflow/flow-go#5477.
Context
The plan is to deploy this changes alongside EFM Recovery (see branch
Outstanding TODOs
TestProtocolVersionUpgrade
integration test inflow-go
before merging.