SIMD-0297: Relax Invalid Nonced Transactions Constraint #297
Conversation
tao-stones
changed the title
tao-stones
changed the title
|
Doesn't this introduce a new DoS vector from a malicious leader? |
| non-state-modifying, non-fee-charging failures, as follows: | ||
|
|
||
| - The transaction is not executed. | ||
| - The transaction is metered by CU limits. |
There was a problem hiding this comment.
What specifically does this mean?
There was a problem hiding this comment.
This means the CU cost of such a transaction still counts toward the block’s CU limit, even if it isn’t executed or charged a fee. I'll update it
|
|
||
| ### Proposed Change | ||
|
|
||
| Update the replay logic to treat invalid nonce transactions as |
There was a problem hiding this comment.
Could we make it clear that an "invalid nonce transaction" is a transaction that doesn't pass the checks listed above?
Thanks for feedback, updates in 57b1fb2 |
tao-stones
force-pushed
the
relax-invalid-nonce
branch
from
57b1fb2 to
f6d0d6b
Compare
| - No account state is modified, including the nonce account (i.e., nonce is | ||
| not advanced). | ||
| - The block is not rejected as long as all other transactions replay | ||
| successfully. |
There was a problem hiding this comment.
not included in status cache as well?
There was a problem hiding this comment.
My initial thought was to exclude these transactions from the status cache, since that aligns better with their non-state-modifying nature. The downside, however, is that invalid transactions might be re-executed multiple times, and their status may not be immediately available via RPC.
There was a problem hiding this comment.
Good catch. This definitely needs to be mentioned in the SIMD.
There was a problem hiding this comment.
If no objection of excluding such transactions from status cache, I'll add it to spec.
No description provided.