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.
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
EIP-2583: Penalty for account trie misses #2583
EIP-2583: Penalty for account trie misses #2583
Changes from 1 commit
db1e389
fa1e06a
40876ed
7725776
d802b3f
c01f508
605e2ef
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Maybe it is worth considering the idea which was brought up as part of "Stateless Summit". Have a separate counter, this time for the entire transaction frame, for the penalty counting. This same counter could be used for witness size counting.
Wouldn't it eliminate this attack vector?
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.
Is this dependent on the assumption that there are no popular contracts (i.e. ones with an existing large storage trie) with a method that reads a large number of (caller-determined) storage entries? If so, it would be nice to state this assumption explicitly here. (e.g. a theoretical popular token contract with a
sumBalanceOf(address[])
method or something like that)Also if I understood you correctly, I would remove "plus gas for arguments to the CALL", since the
CALL
opcode doesn't charge gas for input data and presumably the DoS-attacker would generate the cache-miss arguments on-chain rather than passing them as tx data. The point about the minimum of 700 gas per cache-miss is still valid though.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.
Well, I guess it could be several different ways to do this. However, it's much eaiser to get a 'random' number as a single stack-op, (e.g.
gas
), than if you have to pre-fill a memory segment with 'random' data and pass it to another method. Every argument you send is another 32 byte memory expanded on the caller-side.One could experiment more in-depth about exactly what the costs would be, but I don't think it would be marginal.
You are correct that it doesn't, however, I was referring to the fact that you need to get your input first to stack, then load into memory. If you do it over and over (as opposed to a one-off multi-parameter thing), then you need to flip some bits between calls, to not hit the same thing over and over again.