Skip to content
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

Merged
merged 15 commits into from
Oct 29, 2024

Conversation

jordanschalm
Copy link
Member

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

/// 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) {
Copy link
Member

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?

Copy link
Member Author

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.

@jordanschalm jordanschalm merged commit 807cf69 into feature/efm-recovery Oct 29, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants