-
Couldn't load subscription status.
- Fork 21.5k
core/txpool/blobpool: allow gaps in blobpool #32717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
cskiraly
wants to merge
14
commits into
ethereum:master
Choose a base branch
from
cskiraly:blobpool-gapped-queue
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
29dd549
core/txpool/blobpool: add queue to blobpool
cskiraly f9aa51e
core/txpool/blobpool: fix removal from gapped queue
cskiraly d11de18
core/txpool/blobpool: accept tx if stored in gapped queue
cskiraly c860b83
core/txpool/blobpool: move tx notification event inside add
cskiraly 337af57
fix comments
cskiraly 4c9b5a1
core/txpool/blobpool: limit gapped allowance based on sender
cskiraly 33493ac
core/txpool/blobpool: limit reorder buffer size for DoS protection
cskiraly 0dfc464
core/txpoo/blobpool: expose gapped txs in Has and Status
cskiraly a0b7fad
core/txpool/blobpool: limit tx lifetime in gapped reorg buffer
cskiraly 3c0649d
core/txpool/blobpool: evict stale transactions from reorg buffer
cskiraly 4a1f509
core/txpool/blobpool: fix reorder buffer logic
cskiraly d3a6bb7
fix lint
cskiraly 7da8e27
core/txpool/blobpool: fix blob tx replacement
cskiraly bfd7edf
core/txpool/blobpool: test gapped blob tx acceptance
cskiraly File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been thinking about what form the gapped blobpool should take in the evolution of the blobpool. In my view, we have two possible options. The first is to store a transaction in the gapped set only when “nonce too high” is the sole rejection reason. The second is to store a transaction in the gapped set when “nonce too high” is one of the rejection reasons (so there can other reasons) This PR seems to be implementing the second option, and given the current state of the blobpool, I think this is reasonable.
If cells are delivered separately from transactions in the future, first option can be beneficial in some cases, in terms of bandwidth. If a transaction in the buffer cannot be included even after the gap is resolved, then by the time the client discover it needs to be discarded (when all cells are collected and revalidation occurs through the add routine below), it will already have consumed bandwidth to fetch its cells. The first design would help reduce this overhead.
However, I am not certain this first option is necessary when we have this gapped buffer, since bandwidth can easily be wasted if someone submits gapped transactions that pass other validations and never fill the gap. I am also not sure about how often this can happen and why the submitter would do such thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/ethereum/go-ethereum/compare/master...healthykim:go-ethereum:bs/cell-blobpool/sparse?expand=1
In my prototype, the buffer currently stores transactions that pass all validation checks but are simply missing their cells. Still need to do some debugging, but overall structure will remain like this
It also handles two replacement case, one for the replacement of buffered tx and the other for the replacement of pooled tx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've selected option 2 (there can be other reasons) here, since that's the option that is a pure reorder buffer, acting before any real blobpool logic. So, at least in theory, that's the least invasive version.
However, I can imagine moving to a more complex evaluation before storing the gapped transaction. The
queuein the legacypool does a more complex evaluation. I think we should check that as well before deciding on future evolution.