-
Notifications
You must be signed in to change notification settings - Fork 288
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: blob fees #11029
base: master
Are you sure you want to change the base?
fix: blob fees #11029
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.
I think we still need to make a few more changes to how the price bump is computed, but this should fix the error we're seeing now in Sepolia.
Also, I'm not a fan of passing the blobs as a separate third argument in the API. I'd expect them to be part of the request
object. I know you didn't introduce it though, but I'd consider changing it eventually.
const blobBaseFeeHex = await this.publicClient.request({ method: 'eth_blobBaseFee' }); | ||
blobBaseFee = BigInt(blobBaseFeeHex); | ||
} catch { | ||
// Ignore if not supported |
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.
Let's at least log this as a warn
. I'm worried about a scenario where the blobBaseFee request fails due to a connectivity error and we end up sending the tx with zero fee.
const blobBaseFeeHex = await this.publicClient.request({ method: 'eth_blobBaseFee' }); | ||
blobBaseFee = BigInt(blobBaseFeeHex); |
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 understand we should be increasing the blob base fee to 12.5% per stall time in blocks, as we do with the base fee (see here).
const bumpPercentage = | ||
gasConfig.priorityFeeRetryBumpPercentage! > MIN_REPLACEMENT_BUMP_PERCENTAGE | ||
? gasConfig.priorityFeeRetryBumpPercentage! | ||
: MIN_REPLACEMENT_BUMP_PERCENTAGE; | ||
|
||
blobBaseFee = (previousGasPrice.maxFeePerBlobGas * (100n + bumpPercentage)) / 100n; |
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.
Why do we use the priorityFeeRetryBumpPercentage
here? I'd expect that we just need to use the MIN_REPLACEMENT_BUMP_PERCENTAGE
expected by geth (which comes from here apparently).
Also, we need to account for the current blob base fee, and do something similar to what we do for the calldata fee: use the minimum between the current chain blob base fee (bumped by 12.5% per stall time) and geth's minimum bump (10%) wrt the previous price.
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.
thanks for that 🙏
I was googling to find if there was such a percentage but couldn't find it so I used this patchy solution.
I should go directly to geth code from now on
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 should go directly to geth code from now on
Yup. I learned that the hard way. Anything related to mempool management is out of protocol, so it depends on the clients, and is awfully undocumented.
// Blob transactions should require more gas | ||
expect(blobEstimate).toBeGreaterThan(baseEstimate); |
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.
Curious: why is this? Does eth_estimateGas
return both the execution gas and the blob gas mixed up together?
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.
it seems in our estimateGas
, we have to use prepareTransactionRequest
to get a full estimation, which does increase a lot compared to estimateGas
so I assumed that includes the blob gas
d07b6ed
to
e7b3f71
Compare
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.
Good find on the blob bump being 100% instead of 10%. But note that the 100% bump is applied to all gas fields, not just maxFeePerBlobGas
according to this code. In other words, if the tx has blobs, the minimum bump is 100% for the maxFeePerBlobGas
, the maxFeePerGas
, and the maxPriorityFeePerGas
.
// calculate min blob fee based on previous attempt | ||
const minBlobFee = (previousGasPrice.maxFeePerBlobGas * (100n + bumpPercentage)) / 100n; | ||
|
||
// use max between current network values and min required values |
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.
Sorry I didn't catch this one earlier, but I believe we're missing the check to not go over gasConfig.maxGwei
with the blob fee. Given we're duplicating it on every attempt, let's make sure it's in there.
… into spy/tx-utils-blobs
Changes to public function bytecode sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
fixes: #11005