Simplify data flow for epoch queues #2548
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Some renames to make it easier to read. - Mutate the state of the queue in place relying on EVM reverts to restore the state of the contract when the transactions revert. Would have to still update abstract contract and tests, so mainly pushing this for discussion. We would also have a new function for clients to determine available epochs, if that's actually required. I think for clients it might be fine if we just return the max of the registrationEpoch variable in the contract and currentEpoch() + 1. If the registration epoch gets bumped by one by the time their transaction is included that's just a race condition we can't avoid anyway. They can set a reasonable `validUntilEpoch` to avoid having to wait too long.
sveitser
force-pushed
the
ma/2316-stake-table-epochs-refactor
branch
from
85ca13a to
229b454
Compare
sveitser
commented
Feb 6, 2025
| if (exitEpoch < currentEpoch() + 1) { | ||
| // The exit epoch is outdated. | ||
| exitEpoch = currentEpoch() + 1; | ||
| numPendingExitsInEpoch = 0; |
There was a problem hiding this comment.
Probably better to call this queueIndex to make it clearer that it goes from 0 to N - 1.
contracts/src/StakeTable.sol
Outdated
| } else if (numPending >= maxChurnRate) { | ||
| epoch = firstAvailableEpoch + 1; | ||
| queueSize = 0; | ||
| function pushToRegistrationQueue() internal override returns (uint64, uint64) { |
There was a problem hiding this comment.
previously i merged these into one function nextAvailableEpoch(...) since the logic being performed was the same - just different queues (register and exit). pros of that are: smaller contract size, reusability and consistency, cons: reduced readability which can lead to errors if the function usage isn't clear.
Which do you think is best?
There was a problem hiding this comment.
In order for them to be general to work for both queues we can't directly operate on the state I think, so I prefer to have them separate.
…ridden again if need be, update parent contract
- Fix solhint. - Add a test for an epoch lenght greater than one. - Remove unnecessary return values from functions that push to queue.
sveitser
requested review from
philippecamacho,
ImJeremyHe,
jbearer,
tbro and
imabdulbasit
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note this PR is from reviewing #2316 and into that branch.
Would have to still update abstract contract and tests, so mainly pushing this for discussion. We would also have a new function for clients to determine available epochs, if that's actually required.
I think for clients it might be fine if we just return the max of the registrationEpoch variable in the contract and currentEpoch() + 1. If the registration epoch gets bumped by one by the time their transaction is included that's just a race condition we can't avoid anyway. They can set a reasonable
validUntilEpochto avoid having to wait too long.