relax validation requirements on subjective data returned by get_wall_time #10
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
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.
I am concerned about validation requirements on the subjective data returned by
get_wall_time; I consider one of the requirements overly restrictive. The proposal currently requires that the wall clock time returned by the intrinsic increases monotonically across all transactions in the block. This assumes that transactions have linear ordering. That is currently true, but we may wish to explore enhancements to the EOSIO protocol in the future that requires transactions to be serializable but no longer requires linearizability (for example enabling concurrent transaction execution).So in this PR I propose relaxing the validation rules to ensure the wall clock time monotonically increases only within the transaction (not block), so that we avoid constraining certain optimization/parallelization options for the future.