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

fix(StakeManager): don't allow migration initialization while migrating #76

Merged
merged 1 commit into from
Mar 1, 2024

Conversation

0x-r4bbit
Copy link
Collaborator

This is actually a bug that the certora prover found. The rule epochStaysSameOnMigration failed because a previous StakeManager could call migrationInitialize and change currentEpoch on a next StakeManager, even though the next StakeManager might be in migration itself (which means the currentEpoch is now allowed to change).

This commit fixes this by ensure migrationInitialize() will revert if the StakeManager already has a migration on going.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

  • Added natspec comments?
  • Ran forge snapshot?
  • Ran pnpm gas-report?
  • Ran pnpm lint?
  • Ran forge test?
  • Ran pnpm verify?

@0x-r4bbit 0x-r4bbit requested a review from 3esmit March 1, 2024 10:49
@0x-r4bbit 0x-r4bbit force-pushed the fix/certora-compile branch 2 times, most recently from b81e370 to 109b684 Compare March 1, 2024 12:18
@0x-r4bbit 0x-r4bbit changed the base branch from fix/certora-compile to fix/current-contract March 1, 2024 12:22
This is actually a bug that the certora prover found.
The rule `epochStaysSameOnMigration` failed because a previous
`StakeManager` could call `migrationInitialize` and change
`currentEpoch` on a next `StakeManager`, even though the next `StakeManager`
might be in migration itself (which means the `currentEpoch` is now
allowed to change).

This commit fixes this by ensure `migrationInitialize()` will revert if
the `StakeManager` already has a `migration` on going.
@0x-r4bbit
Copy link
Collaborator Author

This commit should actually pass just fine.
Here's a certora job I ran on this commit: https://prover.certora.com/output/6199/9108462dc0734e85a63d32a303036c00?anonymousKey=ad4b679fc143ce45ebc4193e4fbd892f93eead05

For some reason, CI is taking an outdated state of the rules.

Copy link
Collaborator

@3esmit 3esmit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! Thats a nice one.
This check ensures that its impossible for the old contract to request a migration to a contract that is already in migration. Will prevent someone on making a deployment mistake or accidentally calling migrateTo with the address of an incorrect state.
There was no checks that require the new contract to behave as expected.

@3esmit 3esmit merged commit 507cbcb into fix/current-contract Mar 1, 2024
6 of 7 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.

None yet

2 participants