feat: validate_timestamp
implementation
#26
Merged
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.
validate_timestamp
function. #21This PR implements
validate_timestamp
functions, which checks that the proposed timestamp for the new block is strictly greater than the median of the previous 11 timestamps.My implementation is simplified compared to ZeroSync
ZeroSync uses cairo zero hints to retrieve the last 11 timestamps by reading 11 contiguous memory cells in the VM, and then sorts the new array of 11 elements in order to find the median. I think this step can be skipped, it doesn't seem necessary to sort anything in our implementation as
prev_timestamps
inChainState
is necessary already sorted right?also, what happens if
prev_timestamps
contains only a few values or even none (for example when syncing the very first blocks)? I'm assuming there are at least 6 values (11 - 5 = 6 to get the mean) , implementation will break if its not the case. But i guess for ZeroSync its the same? Trying to read 11 consecutives values in vm memory if there are less than 11 will fail withreading unknow value
error