Use State structure for tests #85
Open
Conversation
This file contains hidden or 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
…n/minimal-rollup into ahead-of-time-prover
…n/minimal-rollup into ahead-of-time-prover
…n/minimal-rollup into ahead-of-time-prover
…l-rollup into ahead-of-time-prover
…l-rollup into ahead-of-time-prover
We had CheckpointUpdated during the constructor and TransitionProven on every update. We only need one. I think the CheckpointUpdated event is better in this case because the start checkpoint is always the previous proven checkpoint. TransitionProven was relevant when we had arbitrary transitions
We already have a finalizeClosedPeriod function that does something else. I think we should reserve "finalize" for when there is nothing left to do in the period, including processing publications and paying stake
This enforces that the deadline is never before the period end. I think it also makes the cases where provingWindow = 0 more semantically meaningful.
We no longer process the publication hash directly
This enforces the end is never in the past. I think it also makes the usage semantically clearer.
Reserve "closed period" for periods that have an end timestamp. This makes it clear that _closePeriod and finalizePastPeriod are referring to different conditions
It seems more natural distribute a fraction of the stake when finalising rather than reduce the saved stake during a proof.
This seems a lot cleaner, with one oddity: the new period only takes effect in the next block.
We create a new period in the constructor, and I originally thought that implied we do not need to prove publications in period 0. However, the _claimProvingVacancy call implies any publication created in the deployment block is assigned to period 0. Moreover, under all versions in this PR, any publication that occured before deployment is assigned to period 0. I now think we should account for this because the ProverManager might be deployed on a shared publication feed that pre-exists the CheckpointTracker. I also don't think we should rely on the CheckpointTracker being able to prove things before the prover manager is assigned, since this puts a specific constraint on the deployment mechanism.
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.
Closes #80.
I wanted to try Leo's suggestion for a state-driven approach. It seems to be much more flexible and easier to reason about. I'm in the middle of migrating the existing tests to this structure, but I ran out of time. I will continue updating it this week but I thought it would be useful to publish the current version in case you have any feedback. Note: