You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 23, 2023. It is now read-only.
I've run into an issue where on a dev network, when the block baseFee is adequately low (say, 1 Wei), that the txpool begins rejecting transactions claiming they have an insufficient fee when their fee is in fact adequate. I traced it down to the following bit of code:
Unfortunately, there's no comment, but it looks to me like this function is probably supposed to implement some heuristic based on the pending block base fee to compute a 'protocol base fee' (maybe say, some fraction of the pending base fee?), but instead returns a constant 7.
Doing a git blame shows @AskAlexSharov as the author in 29bf077 and that the protocolBaseFee used to be an atomic that got set and retrieved. But, I wasn't able to glean much from the PR #48 it came in with.
So, can anyone explain to me why this function returns a constant 7? Is there some other behavior it should be doing that's documented? Would a patch which returns something equivalent to min(7, baseFee) be accepted as a fix for these devnet transactions being rejected when the basefee is adequately small?
I think you are right and it’s something mainnet-specific hardcode. Let’s do next way: create github issue from this comment - i will ask somebody in team to take a look. Likely we need “add support of non-mainnet chains to txpool”.
The text was updated successfully, but these errors were encountered:
I've run into an issue where on a dev network, when the block baseFee is adequately low (say, 1 Wei), that the txpool begins rejecting transactions claiming they have an insufficient fee when their fee is in fact adequate. I traced it down to the following bit of code:
erigon-lib/txpool/pool.go
Lines 178 to 180 in 2d6e293
Unfortunately, there's no comment, but it looks to me like this function is probably supposed to implement some heuristic based on the pending block base fee to compute a 'protocol base fee' (maybe say, some fraction of the pending base fee?), but instead returns a constant 7.
Doing a
git blame
shows @AskAlexSharov as the author in 29bf077 and that theprotocolBaseFee
used to be an atomic that got set and retrieved. But, I wasn't able to glean much from the PR #48 it came in with.So, can anyone explain to me why this function returns a constant 7? Is there some other behavior it should be doing that's documented? Would a patch which returns something equivalent to
min(7, baseFee)
be accepted as a fix for these devnet transactions being rejected when the basefee is adequately small?I first raised this on Discord, but @AskAlexSharov suggested I create this in an issue https://discord.com/channels/687972960811745322/687972960811745326/1149164360644706355
The text was updated successfully, but these errors were encountered: