[core] fix: Use time-based ordering to avoid spam #4118
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.
Closes #4113 by sorting transactions by time received
instead of using a hashmap based transaction ordering. This sorting is
on top of the gas price and nonce sorting already implemented.
Effectively, this allows the production of almost a deterministic order
of transaction ordering, as opposed to a heap-based hash map ordering
which is affected by Golang's internal operations. Consequently,
arbitrageurs, who spam the network with a view to exist around
arbitrag-able transactions, will have to focus on latency instead of
network spamming.
See also bnb-chain/bsc#269 and ethereum/go-ethereum#21358 for related
issues in other chains.
Issue
#4113
Test
Unit Test Coverage
Before:
After:
Test/Run Logs
Ran the following contract + brownie script to observe that time based ordering is dependent on latency and that all transactions go through as expected.
Operational Checklist
Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)
No.
Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.
Describe how the plan was tested.
How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?
What are the planned flag epoch numbers and their ETAs on Pangaea?
What are the planned flag epoch numbers and their ETAs on mainnet?
Note that this must be enough to cover baking period on Pangaea.
What should node operators know about this planned change?
Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)
No.
Does the existing
node.sh
continue to work with this change?What should node operators know about this change?
Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?
No.