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
Extracted Gas Limit Multiplier from gas estimators to WrappedEvmEstimator #12534
Extracted Gas Limit Multiplier from gas estimators to WrappedEvmEstimator #12534
Changes from 4 commits
49a0a1c
9d0da6f
d65615f
f3415c1
cf9002e
933524f
58f0336
87cf9e9
843766f
c39b995
a91e13f
33447f6
4971c26
4a0d405
d37b71f
da7d128
c0964fd
0c2a4bb
ffc2cf2
ef5e761
ed5a50f
773d9b0
ebf465a
d84c214
da360f7
b9a0cce
3d5a0cb
ea6e6a4
4ad0d7e
2a62ed1
f313676
1d20f79
6362c28
1c7b57c
ca8e467
b6dfef6
c25b2ca
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.
These are unused changes
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.
Just cleaned this up, additionally, I removed any reference to
LimitMultiplier()
where they already existed in the block history estimator and fixed price estimator since those aren't being used anymore, theLimitMultiplier()
only needs to be in the gas estimator config stored by theWrappedEvmEstimator
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.
Calling out that there is a weird interaction going on here that seems to take place in the BHE as well. If we apply the multiplier during each bumping it means that successive bumping requests will result in multiple gas limit bumps, which is usually not the desired behaviour. We haven't encountered this issue yet because
LimitMultiplier
was set to 1 so far.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, since the multiplier should already be included in the
originalFee
when bumping the gas, it probably doesn't make sense to include the multiplier again in the gas bumping. Am I understanding this correctly @dimriou?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.
If we can ensure gas bumping will reuse the already multiplied gas limit value from the previous attempt, same as it does for the BHE, then yes.
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 that familiar with the codebase atp, but isn't the only way to calculate that original fee used in
BumpLegacyGas
to usegetLegacyGas
which accounts for the multiplier? From my understanding,BumpLegacyGas
implies there was a previous attempt where the limit multiplier was applied.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 feeLimit param sent to BumpFee() and thus to BumpLegacyGas() and BumpDynamicFee(), is actually the original feeLimit sent by the user.
It is sent from here:
chainlink/core/chains/evm/txmgr/attempts.go
Line 74 in 2869a7b
I would think the easiest and best approach to apply the limitMultiplier would actually be in this above file(attempts.go) which controls all Fee calculations.
Everywhere that it sends etx.FeeLimit, we should already apply the multiplier. Then the various gas estimators don't need to separately account for it. It will be cleaner like this.
I see 2 functions in this file where we send the limit. NewTxAttemptWithType() and NewBumpTxAttempt().
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.
@prashantkumar1982 I don't think we can remove this responsibility from gas estimator. Like for Arbitrum, the
tx.FeeLimit
might just be a piece of a calculated gas limit that needs to be multiplied in the end. I agree that making sure individual estimators are applying this multiplier probably isn't the best though. What if we store a copy of the gas estimator config in theWrappedEvmEstimator
and apply this multiplier in the GetFee and BumpFee methods? Then estimators that don't require calculations can just pass the gas limit through likechainSpecificGasLimit = GasLimit
.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.
@amit-momin Agreed, this seems like the cleanest solution.
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.
If we pass the original etx fee limit why isn't the original solution sufficient?
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.
By the original solution do you mean, applying the multiplier in the individual estimators? If so, that would work too but applying the multiplier in a centralized place in WrappedEvmEstimator seems like the better place for it. It would help us avoid the reason we needed this PR where the multiplier was only applied in some estimator even though the expectation is should always be applied.
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.
Alright, makes sense.