-
Notifications
You must be signed in to change notification settings - Fork 20.5k
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
core/txpool/legacypool: add support for SetCode transactions #31073
Merged
+368
−17
Merged
Changes from 13 commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
487fcd8
core/txpool: add support for setcode tx
lightclient e01a042
core/txpool: allow same delegation in multiple txs
lightclient e3223c8
core/txpool: simplify known conflicts
lightclient 418e96b
core/txpool: add setcode tx to filter list of accepted txs
lightclient b74866b
blobpool wip add
lightclient 84593a1
core/txpool/blobpool: add difficulty to test header
lightclient 85dceef
txpool: move authorizations to lookup obj (#69)
MariusVanDerWijden 0c0d6b3
core/txpool/legacypool: track auths with associated tx hash
lightclient 2dc72d5
core/txpool: check authoirization nonce is not stale
lightclient 37d91cd
core/txpool/legacypool: check code hash to determine delegation status
lightclient 8c98433
core/types: fix typo
lightclient ffa02b8
core/types: authorities to setcodeauthorities
lightclient a15c297
core/txpool: all one tx from accounts with in-flight delegation
lightclient 37247f9
core/txpool/legacypool: add note about pool behavior w.r.t. authoriza…
lightclient 56422c8
core/txpool/legacypool: update comment
fjl 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 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 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 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.
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.
Do you think
len(pool.all.auths[addr]) != 0
could become an attack vector? Consider the following scenario: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.
In this case, the
len(pool.all.auths[addr]) != 0
is used to limit the number of txs an account can queue when they have the ability to sweep their balance from underneath the txpool w/o originating a tx to do so. Without this check, what is possible:A submits a tx which sets code in B. During the tx, B sweeps its balance. Immediately after A submits tx1, B submits 16 txs to the pool. When A is mined first, it invalidates all txs from B. You can expand the A's tx to include many accounts, now A can invalidate many txs from many accounts.
By only allowing a single tx from accounts who have code / will potentially have code soon, we can reduce the potency of this attack.
Originally I blocked this attack, by not allowing a tx from an account with a pending delegation, but this leads to the attack Gary described. Now that we allow 1 tx from the account with a pending delegation, we can avoid that account getting deadlocked.
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.
In this example, X and Y are from different senders, say A an B respectively. Even if X is from A and includes the delegation for A, when B copies the auth and puts it in Y, the node will still accept X because although it has a pending delegation, it will still have 1 free slot for the account A. This does mean B can limit the number of txs A can queue.
The only scenario the tx will be rejected is as follows: suppose A submits an auth to bundler B. Say B submits the auth in tx Y. If A is able to queue a tx X before nodes start recieving Y then Y will be rejected.
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.
Will this have a serious impact? I think we have the similar issues nowadays in the legacy pool. Let's say account a has 16 transactions with continuous nonces. If the first transaction drains the balance of A and the following 15 transactions will be invalidated later.
In the scenario you mentioned, tx can set code for a list of accounts [B, C, D, ..., Z] and meantime these accounts can submit a tons of pending transactions. However, these accounts must sign an auth in which the balance will be drained by the code. Although the scale of this invalidation seems to be magnified, but it should be feasible to submit legacy pending transactions from multiple accounts and invalidate the remaining by using balance in the first tx?
Maybe I miss something
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'm not sure if I understand this. The quote you have here was me explaining an attack that we avoid by limiting the account to 1 pending tx? I don't think you can easily replace all the txs pending for an account because we check the total value of the stack?
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.
Yeah right. There is no way to drain the balance of an EOA without the deployed code!