-
Notifications
You must be signed in to change notification settings - Fork 25
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
fix(l1): add temporary fix to transaction filtering & handle tx filtering unwrap edge case #1018
Conversation
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.
LGTM (small np comment that could be ignored)
effective_gas_tip
computation
crates/blockchain/mempool.rs
Outdated
// This is a temporary fix to avoid invalid transactions to be included. | ||
// This should be removed once https://github.com/lambdaclass/ethereum_rust/issues/680 | ||
// is addressed. | ||
if tx.effective_gas_tip(filter.base_fee).is_none() { | ||
return false; | ||
} |
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.
We could add this check on the else
block of the min_tip check, that way we can leave the check even when the issue is fixed
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.
But, this should be an else if
right? We still need to know if effective_gas_tip
returned None
, or am I missing 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.
As I understood it, yes, we still need to check for the None
of effective_gas_tip
even in the else of let Some(min_tip) = filter.min_tip
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.
What I mean is that with this change we have:
check effective fee != None
if min_tip:
check effective fee != None && > min_tip
When we could have:
if min_tip:
check effective fee != None && > min_tip
else:
check effective fee != None
That way we only compute the effective fee once in any case
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.
Gotcha
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.
Done 62e4d9c
Co-authored-by: fmoletta <[email protected]>
crates/blockchain/error.rs
Outdated
#[error( | ||
"Attempted to add an invalid transaction to the block. The transaction filter must have failed." | ||
)] | ||
AttemptedToAddInvalidTransaction, |
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.
the error is a bit long. Why not just InvalidTransaction
?
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.
Not a problem, renaming it asap.
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.
Done 6f3a2fb
Generalize the error to InvalidTransaction which can be raised with additional context.
**Motivation** Have the tx spammer running instead of immediatly shutting down when we are the first node in the devnet setup. **Description** This PR tackled a couple of issues until we were able to process an initial transaction, (they are small changes): - We were returning an error on `eth_getTransactionCount` when we either didn't have a `latest` block before genesis or at any point when we don't have `pending` blocks. The solution in this case was returning `0x0` in those cases. - When requesting `eth_getTransactionCount` on `pending` after some transaction went through we were defaulting to `0x0`, it appears that the idea is to default to the `latest` in those case which make sense. - There were a missing filter that made the node panic when building payloads for transactions with fees lower than the base_fee_per_gas, this generated that those kind of transactions stopped the node's ability to build blocks when they were in the mempool, we made a quick workaround in this PR, but will remove it in favor of #1018 Closes #1026
…ring unwrap edge case (lambdaclass#1018) **Motivation** <!-- Why does this pull request exist? What are its goals? --> To avoid panicking when the transaction filter fails to filter a transaction because we do not yet filter transactions with invalid tip. **Description** - Filter transactions whose effective gas tip calculation underflowed. - Handle the unwrap of the `effective_gas_tip` calculation. Even though this is an edge case that shouldn't happen, it is better to have a descriptive error if it happens someday than to panic. --------- Co-authored-by: fmoletta <[email protected]>
**Motivation** Have the tx spammer running instead of immediatly shutting down when we are the first node in the devnet setup. **Description** This PR tackled a couple of issues until we were able to process an initial transaction, (they are small changes): - We were returning an error on `eth_getTransactionCount` when we either didn't have a `latest` block before genesis or at any point when we don't have `pending` blocks. The solution in this case was returning `0x0` in those cases. - When requesting `eth_getTransactionCount` on `pending` after some transaction went through we were defaulting to `0x0`, it appears that the idea is to default to the `latest` in those case which make sense. - There were a missing filter that made the node panic when building payloads for transactions with fees lower than the base_fee_per_gas, this generated that those kind of transactions stopped the node's ability to build blocks when they were in the mempool, we made a quick workaround in this PR, but will remove it in favor of lambdaclass#1018 Closes lambdaclass#1026
Motivation
To avoid panicking when the transaction filter fails to filter a transaction because we do not yet filter transactions with invalid tip.
Description
effective_gas_tip
calculation. Even though this is an edge case that shouldn't happen, it is better to have a descriptive error if it happens someday than to panic.