fix: DelayedPublicMutable not relying on the guarantee of increasing timestamps#20244
Merged
charlielye merged 1 commit intonextfrom Feb 17, 2026
Merged
fix: DelayedPublicMutable not relying on the guarantee of increasing timestamps#20244charlielye merged 1 commit intonextfrom
DelayedPublicMutable not relying on the guarantee of increasing timestamps#20244charlielye merged 1 commit intonextfrom
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Block timestamps are no longer guaranteed to be increasing and instead now are just guaranteed to be non-decreasing (monotonically increasing). This is because blocks in the same checkpoint can have the same timestamp. With this change it was necessary to update
DelayedPublicMutableas there the timestamps-are-always-increasing assumption was used to compute the effective minimum delay.Closes https://linear.app/aztec-labs/issue/F-307/fix-bug-in-delayed-public-mutable
Tagging @iAmMichaelConnor to make him aware that this is getting tackled.
Unrelated changes I sneaked in
I renamed the historical timestamp everywhere as anchor block timestamp. The motivation for this was that the old naming made this PR even more convoluted. We also in some places used "anchor timestamp". I renamed that as well to anchor block timestamp to maintain consistency.
Note on docs
This all was too hard to understand. Feels like re-writing the docs here would be a good idea.