First, I don’t think that using a lot of calldata to then sell off operations is a serious threat.
It’s not free gas because the respective entity still pays the standard price for it. Selling EVM operations on a second market to potentially offset the floor cost might work but I don’t see something like that ever happening.
Even in the case that there are transactions (remember, it’s currently 2% of all tx that would hit the floor price with most of them being regular user posting comments of a few bytes into the calldata) that can sell of EVM operations, the goal of reducing the max block size is achieved.
So, I see your point but I don’t believe these are practical concerns. Writing the software to trustlessly outsource EVM operations or storage space in someone else’s calldata doesn’t seem very viable.
I recommend the EIP authors withdraw their EIP and describe the issue as a security consideration. The Core Developers who CFI’d this proposal need to be educated on economic marginalism so they do not approve similar changes in the future.
Have you heard of EIP 3074? It’s going to be easier than ever before.
The advantage of the SELFDESTRUCT gas refund was only half but I still made over a million dollars off of it. This is even more promising.
It will be achieved in a way that guarantees the block size is often at, or near, the maximum, so-long as anyone is willing to pay a fraction of the base fee for this calldata. It doesn’t make calldata gas more costly because, as I already mentioned, you can pay the lower rate by combining with another transaction with a lot of gasUsed.
No, the evm gasUsed is separate in the max formula. So you can arbitrage the difference in calldata gas costs by selling your extra calldata space to someone who would otherwise pay the higher rate.
Let’s say you do so. You’d end up with one single transaction spending 2x gasUsed on EVM than calldata, just enough to not hit the floor. That block wouldn’t be big.
I agree that the blocks will not be entirely made of calldata gas. I am saying you have created a market for sheltering different kinds of gas by batching different types of transactions. gasUsed and calldata gas would be priced separately. Whichever is cheaper will determine the market condition, and I have described both scenarios in this thread.
Ultimately the consequence of widespread gas sheltering would be that unsheltered users would have to pay a higher gas price (4x in one case, unbounded in the other), and block producers would be unable to safely increase the gas limit because gas no-longer measures their cost-burden.
Instead, gas should be charged according to the cost to the execution layer, and should not be complicated by arbitrary limits on specific items. I suspect a better fix to this issue would be to isolate total transaction size from the 21000 base gas; smaller transactions should pay less overall, not just on tx.calldata. The 21000 number is arbitrary, and doesn’t change if the recipient is a new account or if there is CALLVALUE, as for regular CALL. There is probably also a real need to increase these calldata gas costs for everyone in order to reduce block sizes.
I don’t see many differences compared to a “naive” cost increase.
In the current implemantion, every user must afford the higher calldata price and if you spent anough gas on the EVM, you receive a higher reward.
The case that users will try to spend gas on EVM for nothing but to not hit the floor price doesn’t make sense.
I like thinking of it as increasing the calldata cost for all but higher refunds for those that spend at least 2x gas on EVM than on calldata, which are 99% of all users.
The rest will move to blobs or has to take the price increase for calldata.
Ultimately, the max block size is significantly reduced for minimal impact on existing infra.
I will try to help you understand. Suppose there is a taco stand that sells tacos and salads. They offer a deal where for every two tacos you can add a salad for only another dollar, whereas normally a salad costs four dollars. But you only want two tacos, no salad! And the person behind you in the line just wants a salad. You can buy the salad for one dollar and sell it to them for two. They save two dollars and you earn one dollar. If enough people do this, the taco stand has to charge more for tacos to make up for the foolishness of their salad deal. It seems your argument is that I would not buy a salad that I am not going to eat. But I will buy it in order to sell it to someone who would otherwise have to pay more.
As a trader who wins or loses according to priority fee, I don’t want the winning factor to be my ability to find graffiti customers to batch with my transactions. I will be incentivized to do everything I can to maximize such graffiti. I don’t want to do that, especially since it will be so obvious and obnoxious that it will only help me for a short time until they finally fix gas sheltering.
You totally overrate how practical a market for excess calldata would be.
Rollups wouldn’t use something like that as you want to have control over where and when your data is posted and make sure everything is bundled correctly.
Also, why would such a “calldata reselling” even be bad by definition (even though I think it’s completely unrealistic)? I would allow heavy calldata consumers to cooporate with heavy evm users. In the end, including the overhead from combing setups into the calculation, both parties would be worse of. This while the max possible block size is still almost halved.
You totally overrate how practical a market for excess calldata would be.
I have already made a dapp, in 2017, that allows you to post any data to the blockchain, and shows all of the data that has been posted this way. It can render pictures and music. I can also show how much it will cost to post it for 64 gas per byte vs 16 gas per byte. I would expect that users would prefer to be patient and save ether.
Rollups wouldn’t use something like that as you want to have control over where and when your data is posted and make sure everything is bundled correctly.
They would, if it saved them up to 75% on their transaction fees.
Also, why would such a “calldata reselling” even be bad by definition
Gas should reflect the cost to the network. If gas is unfairly assessed, the block gas limit is constrained, and gas prices are higher for everyone else. To be extreme, consider if we made SSTORE_SET cost 1000 gas instead of 20000 (presumed fair in this example). The block gas limit would need to decrease by 95% to constrain state growth, and block producers would likely vote accordingly. This might not matter to users whose gas is primarily SSTORE_SET, as they might end up paying approximately the same in fees. But for users who are primarily transferring ether, fewer of their transactions can confirm and their gas price will be higher due to the congestion.
including the overhead from combing setups into the calculation, both parties would be worse of
Do you think batch overhead is greater than 21000, plus 75% of their calldata gas? It’s not. I estimate it will be less than 16000, mostly from the eth transfer to me to pay me for my service.
If you aren’t going to edit your EIP to fix this issue, then I can make a replacement.
The floor is at 16/42 gas for zero/non-zero bytes.
My mistake. My math in this thread is based on 16/64, which would be the same ratio as 4/16. So where I say 75% and 4x I should have said 62% and 2.625x (though if their data contains many zeros the 75% and 4x can be valid).
Sorry, this was my mistake. It’s 12/48 gas for zerobytes and nonzero bytes (see TOTAL_COST_FLOOR_PER_TOKEN) respectively, instead of the standard 4/16.
Apart from the figures, i understand what you mean, but i disagree and still think it’s better than a naive calldata increase.
In case you missed that, we’ve been trying to explore different mechanisms and the floor price seemed like a great choice balancing minimal impact and achieving the goal (=reduce max size blocks).:
Could the gas sheltering issue be avoided by making the calldata/compute binding a global constraint (block-level) instead of a local one? (transaction-level)
In other words, a transaction that maxes out on e.g., compute “unlocks” more calldata for someone else in the block. The block-level constraint only checks that overall, the unlocked and consumed gas tally up satisfactorily. This at least allows a separate transaction to piggyback on an gas-unlocking transaction without nesting itself within its callframe, punting the packing problem to the block producer instead of some transaction bundler/relay offering sheltering.
from me