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.
Problem
The timestamp returned by
Bank::unix_timestamp()
ends up in the clock sysvar and is used to assess time-based stake account lockouts. However it's based on a theoretical slots-per-second instead of reality, so it's quite inaccurate. This will pose a problem for lockups, since the accounts will not register as lockup-free on (or anytime near) the date the lockup is set to expire.Block times are estimated using a validator timestamp oracle; this data provides an opportunity to align the bank timestamp more closely with real-world time.
Summary of Changes
Bank::unix_timestamp_from_epoch
)last_timestamp
.Bank::update_epoch_timestamps
:Bank::new_from_parent
, check the expected timestamp sample slots, and if one has passed, populate the sample with the stake-weighted timestamp.Right now, even with the feature activated this code is a no-op for the timestamp in the clock sysvar. Because the expected samples map is never populated, the timestamp at the epoch boundary defaults to the
Bank::unix_timestamp_from_genesis()
.TODO:
Bank::update_epoch_timestamps
Fixes #9874
Toward #10093 (but requires some additional consideration of inflation timing)