Discussion topic for EIP-7762 <link to EIP>
Update Log
2024-09-02: initial draft
External Reviews
Data Always
Robert Bayardo of Base
Outstanding Issues
None as of 2024-09-03
Discussion topic for EIP-7762 <link to EIP>
2024-09-02: initial draft
Data Always
Robert Bayardo of Base
None as of 2024-09-03
The motivation for setting the parameter considered in the EIP draft is wrong imo:
To set the parameter apropriately, one aproach is to look at the cost of simple transfers when base fees are low. The cost of a simple transfer when the base fee is 1 GWEI is ~5 cents USD at today’s prices (2,445.77$ ETH/USDC). We can try to peg the minimum price of a blob to that.
We should connect the logic to the reason we are increasing the minimum which is less arbitrary. Eg, can we simulate a pareto frontier between the following?
We should connect the logic to the reason we are increasing the minimum which is less arbitrary.
Makes sense.
If I understand correctly
Assuming the current blob base fee is 1 wei and then the sudden onset of sustained congestion
I do see the short-term advantages of 7762, though, I think there is also value in not touching the protocol for fine-tuning things.
Also, it’s debatable how much of a problem this really is.
Having the blob basefee min at the lowest possible point is more neutral than some arbitrary number that potentially needs to be adjusted in the future.
While the intentions are right, I am for leaving the mechanism as-is.
wei is used for decimal precision; the min price should never have been set at 1 wei as there is no decimal precision left (1 wei being the smallest amount)
If blob fees are meant to go up by +12.5% of 1 wei; what is that? 0 wei because it cannot be expressed; so instead the math needs to be fudged to 2 wei (+100%)
The fairest of fair launch tokens would never be launched at a 1 wei price because Uniswap and all dexes would choke on the maths.
For a low price something more in the 1 gwei or lowest of low 0.1 gwei is more sensible; because at least the price deltas are calculatable without fudges
This is not a problem because excess blob gas can grow infinitely (bc it’s cumulating). When it reaches 2,313,024 excess gas, then the base fee doubles (e.g. from 1 wei to 2 wei) such that the transition from 1 wei → 2 wei takes 6 blocks having 6 blobs.
Which demonstrates the issue; that it takes 6 over target blocks to increase the fee by 1 wei
I share this view point. Modifying the min base fee per blob gas seems short sighted and setting the floor to the minimum value rather than an arbitrary value is more credibly neutral. Additionally, this only matters when blob demand is too low for price discovery.
The argument that 1wei is too small of a unit to instantly react to blob demand may be valid. However, it only holds true when the price is less than 6 wei.
Do we need to modify the protocol for these edge cases? I think it is not worth it.
If there is strong interest in moving forward on this, it would be worthwhile to review the arguments from geth reducing their min tip requirements. miner: lower default min miner tip from 1 gwei to 0.001 gwei by karalabe · Pull Request #29895 · ethereum/go-ethereum · GitHub. Block producers should be rewarded something, but in the case of transactions (also blobs in this context) that something is much less than this EIP’s proposal.
Disclaimer: I am employed by a company that buys blob space. I do not care if blob buyers or my employer pays more for blob space. I care about a neutral protocol.
How about taking Time-Weighted Average Price (TWAP) model or some linear model as a reference instead of setting a hard threshold of +12.5% for adjusting the blob base fee is better. TWAP model would smooth out volatility and adjust quicker for gradual adjustments and avoiding sudden fee spikes.
@benaadams @Nerolation
L2 solutions like rollups heavily rely on DA, it’s crucial to keep DA costs low. It is better to propose a way so for transfer with less blobs like basic transfers or those using rollups, even with a higher base fee, we can ensure that fewer blobs are used at a lower cost for simpler transfers, maintaining affordability while scaling Ethereum efficiently.
@ryanberckmans