Title: EIP_7623__Increase_Calldata_Cost
Category: EIPs

Author: Nerolation
Date: 2024-02-14T07:44:09.512Z

By increasing the calldata cost for users that do not spend more than a certain threshold on EVM computation we can achieve the following:

Reduce maximum possible blocksize from ~1.7 MB to 0.55 MB without effects on current throughput.
Reduce block size variance
Reduce inefficienty from big gap between avg. block size and max. possible block size.
Make room for raising gas limit and/or blob count
Differentiate between users that need calldata inside the EMV vs pure DA.

This is achieved by increasing cost for DA users (who can move towards using blobs).
PR:
https://github.com/ethereum/EIPs/pull/8218
More info:


Ethereum Research – 5 Feb 24




On Increasing the Block Gas Limit




Economics






data-availability





On Increasing the Block Gas Limit by Toni and Vitalik.  special thanks to the Starkware team for feedback and data!  The TL;DR  By increasing the block gas limit and the price for nonzero calldata bytes, a smaller and less variable block size can...

Reading time: 8 mins 🕑
Likes: 48 ❤









Ethereum Research – 24 Jan 24




On Block Sizes, Gas Limits and Scalability




Economics






eip-1559
scaling
resource-pricing
fee-market





On Block Sizes, Gas Limits and Scalability  Thanks to Alex Stokes, Matt (lightclients) and Matt Solomon for feedback and review!   There has been much discussion about raising Ethereum’s block gas limit recently.  Some argue for bigger blocks...

Reading time: 8 mins 🕑
Likes: 48 ❤

Author: storm
Date: 2024-02-19T18:54:12.131Z

TOTAL_COST_FLOOR_PER_TOKEN seems like a good heuristic for penalizing call data heavy txs and nudging them toward blobs
to red-team this a bit, are there any circumstances where allowing larger amounts of call data is important or necessary for security? examples:

large number of users might need to submit fraud proofs for optimistic rollup(s) over a short period of time. what might that realistically look like in terms of total EL call data requirements? and is there any other situation where users might need to replicate lots of blob data into regular execution call data?
what are the other unlabeled points in the lower half of the transaction_dist.png in On Increasing the Block Gas Limit? are any of those use cases both 1) important and 2) difficult to convert to blobs?
has any bridge dev team encountered difficulty in converting their architecture over to blobs? what is a reasonable timeline to expect most/all of them to blobify?

Author: MariusVanDerWijden
Date: 2024-02-20T22:48:06.931Z

Draft implementation in geth: [wip] core: implement eip-7623: increase calldata cost by MariusVanDerWijden · Pull Request #29040 · ethereum/go-ethereum · GitHub
One issue I came across is that the EIP is kinda underspecified wrt. the gas costs for contract creation vs normal transactions. A normal transaction costs 21000 + Tokencost * Tokens + evm_gas, a contract creation costs 53000 + Tokencost * Tokens + 2 * Initcode_Wordsize + evm_gas.
I’ve interpreted the EIP as follows:
tx.gasUsed = {
    21000 + 32000 * isContractCreation // 21000 or 53000
    + 
    max (
        STANDARD_TOKEN_COST * tokens_in_calldata + IsContractCreation * (InitCodeWordGas *  words(len(calldata))) + evm_gas_used,
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )
)

Where IsContractCreation is 1 if the transaction is a contract creation and 0 otherwise.

Author: Nerolation
Date: 2024-02-21T07:35:58.224Z

storm:

large number of users might need to submit fraud proofs for optimistic rollup(s) over a short period of time. what might that realistically look like in terms of total EL call data requirements? and is there any other situation where users might need to replicate lots of blob data into regular execution call data?


The formula is applied for each transaction, so it doesn’t matter if multiple use have to execute transations with much calldata at the same time. They are only limited by the block gas limit. I don’t see scenarios where many regular users suddenly need to post 1MB calldata transactions.
Regarding 2, I’ll do further analysis on those outliers but I expect that 99.9% of all transactions using enough evm resources to “qualify” for the 16 gas calldata cost. Then this EIP would basically reduce the max possible block size without impacting regular users at all. Only DA via calldata should become more expensive, preventing the EVM having to deal with Inscriptions, or rollup data.
Regarding 3. I think some of the rollups will start using blobs from day one while the majority plans to shift in the following days/weeks. I’ve only seen a few announcing that they will not yet move to blobs. In the end, rollups know that this is coming and all of them are prepared.

Author: Nerolation
Date: 2024-02-21T08:11:10.249Z

Yeah, you’re right.
The initcode cost of currently 2 gas per word might be negligiable low compared to the calldata costs but it makes full sense to put them into the formula, treating it similar as the base cost.
One could even go one step further and adjust the formula to distinguish between CREATE and CREATE2 deployments:
tx.gasUsed = {
    21000 \ 
        + (32000 + InitCodeWordGas *  words(calldata)) * isContractCreation  \
        + isCreate2Creation * Keccak256WordGas *  words(calldata)
    + 
    max (
        STANDARD_TOKEN_COST * tokens_in_calldata + evm_gas_used,
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )
)

I’d still keep the gas involved with contract creations outside the conditional part of the formula.

Author: vbuterin
Date: 2024-02-28T08:06:57.276Z

I would actually go for Marius’s interpretation!
My reasoning is that Keccak256WordGas and InitCodeWordGas are “actually” not data-related costs, but rather execution-related costs. Those costs were introduced because of issues that have to do with the expense of processing the CREATE and CREATE2 opcodes, and were added to transaction-level creates for symmetry. So they should be put in the same bucket as evm_gas_used.
I would even go so far as to put 32000 * isContractCreation into the same bucket as execution-related costs (since a contract creation by itself isn’t any heavier on calldata than a regular transaction), but I’m happy to go either way on that.

Author: Nerolation
Date: 2024-02-28T15:21:16.335Z

I see! Based on that the formula would look like this:
tx.gasUsed = {
    21000 \ 
    + 
    max (
        STANDARD_TOKEN_COST * tokens_in_calldata \
           + evm_gas_used , \
           + isContractCreation * (32000 + InitCodeWordGas *  words(calldata)),
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )

Ive skipped the CREATE2 part, so the difference to @MariusVanDerWijden approach is the 32k base cost inside the max().
I agree that the 32k contract creation could be put into the evm_gas_used side of the max() , contributing towards the standard token cost. Also, the CREATE opcode is different from the 21k base cost and one can argue that it must therefore be treated differently in the gasUsed formula.

Author: chfast
Date: 2024-03-15T10:53:34.704Z

How about we remove the special zero-byte cost from the formula as it make no sense?

Author: qizhou
Date: 2024-03-27T21:46:27.437Z

Would the gas cost for EIP-2930 also need to be adjusted since the storage data cost under EIP-7623 is 32 * 68 = 2176, which exceeds 1900 in EIP-2930.

Author: Nerolation
Date: 2024-04-02T15:56:03.533Z

With respect to snappy compression rates it does make sense, as many consecutive zeros can be compressed very well. The formula assumes that zero bytes are less expensive than non-zero bytes.
There’s more info on that here:
https://eips.ethereum.org/EIPS/eip-2028

Author: Nerolation
Date: 2024-04-02T16:01:45.898Z

Could you elaborate on that?
The access list gas in charged in addition to the base tx cost, why would it be affected?
Or are you comparing them as a DA layer now?
Edit: We were thinking about 48 (instead of 68) as a better price anyway (because of merkle proof, post quantum crypto, etc.) and 48 happens to not be vulnerable to the scenario you describe.
It’s fixed in the current version of the EIP. Thanks!

Author: wjmelements
Date: 2024-04-04T21:28:36.310Z

kladkogex:

If someone wants to publish data just for availability, they will switch to logs.


How will they publish to the logs without calldata?

Author: qizhou
Date: 2024-04-05T06:09:28.237Z

Nerolation:

The access list gas in charged in addition to the base tx cost, why would it be affected?
Or are you comparing them as a DA layer now?


My point is that the tx access list in 2930 is charged independently compared to calldata cost (see go-ethereum/core/state_transition.go at 35fcf9c52b806d2a7eba0da4f65c97975200a2b2 · ethereum/go-ethereum · GitHub), but it takes the same block space as calldata.  That means that if the tx access list is under-charged vs calldata cost, an attack will use the tx access list to create a larger block that circumvents the limit of EIP-7623.
For example, a storage key in the tx access list takes at least 32 bytes (let’s ignore the overhead of RLP encoding); thus, the gas cost per byte of the storage key is 1900 / 32 = 59.37. That said, if the calldata per gas cost is 68, then an attacker can still create a larger block size post-EIP-7623 by filling a large number of storage keys in the tx.
Reducing the gas cost of calldata per byte to 48 should alleviate the issue as using access list to create a large block is less cost-efficient than using calldata.

Author: dror
Date: 2024-04-09T17:42:48.722Z

The motivation for this EIP looks great.
A side-effect is that it clears out the cost of a transaction.
It could be written just as “never charge less than 48*tokens_in_calldata”, but instead, it tries also to spell out the existing gas cost
What I miss in the document are some examples of the impact on TXs that use cpu-gas: That is, what kind of non-L2 transaction might get hurt by this change.

Author: Nerolation
Date: 2024-04-09T20:55:33.242Z

Thanks for pointing that out. I could have linked to some more analysis here but didn’t (yet).
There’s this “post-4844” analysis that highlights the impact of the EIP on post-4844 Ethereum:


Ethereum Research – 3 Apr 24




EIP-7623 - Post-4844 Analysis




Execution Layer Research






fee-market





EIP-7623 - Post-4844 Analysis EIP-7623 proposes to increase the calldata cost for transactions that use Ethereum mainly for DA.  This is done by setting a floor price for non-zero bytes at 48 gas and zero-bytes at 12 gas.  The goal is to reduce...

Reading time: 1 mins 🕑
Likes: 6 ❤






It also includes a site where the most commonly used functions are listed together with stats on gas usage and indicating if they’d be affected by this EIP.
Find it here:
EIP-7623 - Impact
In summary, there aren’t many non-DA use cases for big-calldata transactions. One of them are big zk-proofs like STARKs, as well as very large merkle proofs.
As visible in the above table, the number of transactions affected is very small and those non-DA that are affected are not impacted drastically (e.g. certain STARK transcation increase by ~30%).
The largest part of affected users are those attaching additional data to their transaction (messages). For them, the increase in gas cost is negligible as those messages are usually very small (and, to be fair, there are better ways to do messaging than using Ethereum L1 anyways).

Author: Nerolation
Date: 2024-04-11T13:51:54.007Z

Quick summary/faq on EIP-7623
What?

EIP-7623 proposes to introduce a floor cost for calldata.
Transactions that use Ethereum mainly for DA will pay 12 (zero bytes) and 48 (non-zero bytes) gas per byte.

Why?

The main goal is to reduce the maximum possible block size form 3.5 MiB to 1.9 MiB (incl blobs).
Reduce history growth (theoretically as avg. block size might remain the same).

How?
The new formula to calculate the gas used per tx would be:
tx.gasUsed = {
    21000 \ 
    + 
    max (
        STANDARD_TOKEN_COST * tokens_in_calldata \
           + evm_gas_used \
           + isContractCreation * (32000 + InitCodeWordGas * words(calldata)),
        TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
    )

with STANDARD_TOKEN_COST = 4,
and TOTAL_COST_FLOOR_PER_TOKEN = 12,
and tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4 (in order to one-dimensionalize calldata).
Who would be affected?


Largest part: users putting messages into their transactions (negligible).


DA users (negligible because they have blobs).


Certain use cases such as STARK proofs, or very large merkle proofs that are heavy in calldata but don’t require much computation.


Simply speaking, every transaction that pays 2x on EVM computation than what it spends on calldata will be unaffected. Around 3% of transaction would be affected. Regular users who are sending ETH, tokens, swapping, etc. are unaffected.


Why floor ar 12?

This makes sure that access lists don’t become cheaper than calldata (otherwise one could again produce “big block” by filling access lists. (h/t @qizhou)

When?

proposed for inclusion in the Pectra hardfork

Useful links

Implementation EL specs
Implementation Geth
Post 4844 Analysis

Author: wjmelements
Date: 2024-04-26T18:26:21.624Z

There is a problem with this floor gas pattern: the marginal cost of additional execution can be zero. This means it is free for a transaction with lots of calldata to package additional operations. This allows such transactions to sell this free gas on the market, which could cause all sorts of havoc. Gas should therefore never be structured this way.

Author: shemnon
Date: 2024-04-26T19:00:27.998Z

Can you provide a worked example of how this might be done?  I don’t think we need EVM code but a description of what the contracts would do should suffice.

Author: wjmelements
Date: 2024-04-26T19:54:01.708Z

Suppose there is a protocol whose recurring transactions require lots of calldata but do little execution. Several L2s are in this category, but there could also be graffiti apps. Many of their transactions will have gasUsed based entirely on their calldata due to the max calculation. They can auction out additional CALLs or even AUTHCALLs to their periodic transaction, specifying a total gas limit according to their CALLDATASIZE. The marginal cost of these auctioned calls to the operator is only their additional calldata, which can even be zero if the auctioning mechanism is implemented on-chain.
So, a calldata operator has been forced to buy extra gas by this EIP, but they can sell it, and this can offset their gas costs.
The maximum price a reasonable buyer would pay for the auctioned gas is the base fee, but the operator should be willing to sell their gas for much less than the base fee to offset their costs, according to demand. They will sell it at any price because from their perspective, it is free gas.

Author: wjmelements
Date: 2024-04-26T20:20:28.904Z

There is a parallel problem: a transaction with a lot of gasUsed but not much calldata could sell extra calldata. This additional calldata costs the gasUsed operator according to the STANDARD_TOKEN_COST schedule, so they could sell it to someone who would otherwise pay TOTAL_COST_FLOOR_PER_TOKEN.
So in summary this EIP creates a gas loophole that incentivizes heavy gasUsed operators who don’t use much calldata to pair up with heavy calldata operators who don’t have much gasUsed, combining into one transaction. It creates separate markets for both kinds of gas.

Author: Nerolation
Date: 2024-04-26T20:35:40.380Z

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.

Author: wjmelements
Date: 2024-04-26T20:47:04.245Z

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.



 Nerolation:

Writing the software to trustlessly outsource EVM operations or storage space in someone else’s calldata doesn’t seem very viable.


Have you heard of EIP 3074? It’s going to be easier than ever before.

Author: wjmelements
Date: 2024-04-26T20:52:35.408Z

Nerolation:

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.


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.



 Nerolation:

the goal of reducing the max block size is achieved.


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.

Author: Nerolation
Date: 2024-04-26T20:54:15.099Z

wjmelements:

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.


This is not the case. As soon as you are forced to have a certain amount of gas to be spent on EVM, you cannot make big blocks anymore.

Author: wjmelements
Date: 2024-04-26T20:55:59.398Z

Nerolation:

As soon as you are forced to have a certain amount of gas to be spent on EVM, you cannot make big blocks anymore.


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.

Author: Nerolation
Date: 2024-04-26T20:58:12.471Z

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.

Author: wjmelements
Date: 2024-04-26T21:04:42.484Z

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.

Author: wjmelements
Date: 2024-04-26T21:22:30.873Z

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.

Author: holiman
Date: 2024-04-30T12:23:50.227Z

This is trying to outsmart the economics

Quote from @fjl about this eip, I think it captures it pretty well. It’s adding a reverse sale: buy more units get a price increase per unit.
This isn’t going to work.  from me
Better suggestion, IMO, is to just increase the calldata cost equally and fairly

Author: Nerolation
Date: 2024-04-30T18:11:15.291Z

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.

Author: wjmelements
Date: 2024-04-30T19:48:36.684Z

Nerolation:

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 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.

Author: Nerolation
Date: 2024-04-30T20:02:05.882Z

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.

Author: wjmelements
Date: 2024-04-30T20:29:21.103Z

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.

Author: Nerolation
Date: 2024-04-30T20:33:29.366Z

wjmelements:

64 gas per byte


The floor is at 16/42 gas for zero/non-zero bytes.

Author: wjmelements
Date: 2024-04-30T20:36:54.200Z

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).

Author: Nerolation
Date: 2024-04-30T20:48:44.050Z

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).:


Ethereum Research – 5 Feb 24




On Increasing the Block Gas Limit




Economics






data-availability





On Increasing the Block Gas Limit by Toni and Vitalik.  special thanks to the Starkware team for feedback and data!  The TL;DR  By increasing the block gas limit and the price for nonzero calldata bytes, a smaller and less variable block size can...

Reading time: 8 mins 🕑
Likes: 48 ❤

Author: wjmelements
Date: 2024-04-30T21:28:29.720Z

I hope my presentation to ACD next week dissuades future gas floor designs.

Author: wjmelements
Date: 2024-05-08T01:56:46.362Z

wjmelements:

If you aren’t going to edit your EIP to fix this issue, then I can make a replacement.


https://github.com/ethereum/EIPs/pull/8529

Author: wjmelements
Date: 2024-05-08T02:13:05.593Z

https://github.com/ethereum/EIPs/pull/8530

Author: barnabe
Date: 2024-05-17T20:57:25.060Z

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.

Author: wjmelements
Date: 2024-05-17T21:31:35.362Z

barnabe:

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)


Yes, though a simpler solution could be to have a variable block size limit. Block builders are capable of adding complexity to their algorithms.
The problem with block constraints is that it results in discrimination, one of the problems this change is trying to address. Gas and gas price (now priority fee) are supposed to be fair ways to evaluate whether a transaction can or should go into the block. Discrimination here means that a transaction might pay a fair priority fee but not be accepted due to outsized calldata. This isn’t fair because the transaction is being treated as if it uses more gas than it does, diluting its priority fee. If blocksizeGas is a constrained resource, there should be a market for it, similar to blobgas.

Author: gurukamath
Date: 2024-08-29T16:22:57.883Z

A question that I have here is how much gas is made available for the actual execution of the opcodes.
Currently, that amount is pre_7623 = tx.gas - 21000 - data_cost - create_cost - access_list_cost. If data_floor_cost is the new floor cost of call data (as per this EIP), do we now make post_7623 = tx.gas - 21000 - data_floor_cost - create_cost - access_list_cost available for execution?
If yes, would we be under-funding some transaction executions?
I imagine a scenario where we passed post_7623 gas for opcode execution but during the course of execution, the execution gas used built up enough to cross the threshold. This means that we should really have passed pre_7623 gas for opcode execution. Since post_7623 < pre_7623 we have essentially underfunded the execution in a way. This could be the difference between success vs OutOfGas in some cases.

Author: wjmelements
Date: 2024-08-30T15:37:18.743Z

The computation uses gas_used which is only known after execution. So this EIP can cause out-of-gas after execution would have otherwise succeeded, by retroactively increasing the calldata cost. While the available gas could be computed ahead of time, the spec does not currently do this.

Author: Nerolation
Date: 2024-08-31T07:58:09.652Z

The internal gas of the transaction is computed by taking the higher gas cost, such that 99% of transactions (those don’t reach the floor) get more refund.
We must make sure that we don’t run out of gas after execution, otherwise clear DoS.

Author: gurukamath
Date: 2024-08-31T10:13:29.911Z

So there’s a possibility that a transaction that ran out of gas, gets a gas refund. And that it wouldn’t have run out, if the refunded gas was available for execution.

Author: Nerolation
Date: 2024-09-03T07:32:27.207Z

you’re right, yes!
Though, this should be a rare exception.
This is the latest el specs implementation of the eip, would be great to have your feedback:

github.com/ethereum/execution-specs








Fix refund logic: eip-7623



        committed 07:12AM - 03 Sep 24 UTC




          nerolation
        



+20
-11

Author: eawosika
Date: 2024-12-04T07:31:44.946Z

research.2077.xyz



EIP-7623: Repricing Ethereum Calldata
Learn EIP-7623, a proposal aiming to increase calldata costs in Ethereum transactions.





A high-level overview of EIP-7623 for those interested in understanding what’s involved with this proposal.

Author: TimDaub
Date: 2024-12-17T06:29:44.261Z

Nerolation:

Who would be affected?

Largest part: users putting messages into their transactions (negligible).



Ethereum dapp builder here, I think we shouldn’t make calldata more expensive, here is why:

Many L2 app builders such as us have started building on L2s like Optimism when they still sent all L2 data into Ethereum’s calldata
We have protested against it, but Optimism and others have then started to post data into blob storage making the data we post on L2 “data available” but not “retrievable into perpetuity.”
In essence chains like Optimism have pulled the rug under our application as they have gotten rid of a guarantee they priorly passed on to L2 dapp devs.
This is somewhat understandable as they’re NOT putting user funds at risk, since these can be settled to L1 using Ethereum’s blob storage.

But here is why a calldata cost increase is a problem for non-ERC20 type of applications on Ethereum:
Our application asks users to store delegations from a user’s regular Ethereum wallet to a delegated in-app wallet on Optimism. If you’ve ever used Farcaster, you might be aware that any interaction on there is essentially a signed Ethereum EIP-712 message. This is enabled because Farcaster delegates a signer on Optimism allowing that signer to represent your identity on the app. So Farcaster, but us as well, we falsely have relied on the L2 data to be available in perpetuity (and because L1 calldata was just too expensive)
Now, core devs and ETH researchers don’t seem to be aware of this type of application being built on Ethereum and so in the recent past a few updates have been made that end up hurting these types of non-financial apps.
Generally speaking, any app that must store any kind of data which is not directly related to settling ERC20 tokens on L1 from L2 is affected. These apps need to be able to post cheaply into L1 calldata (or another solution like it must be found). That is because when posting into L1’s calldata, this creates a timestamp whose creation isn’t controllable by users. Consumer protocol like Farcaster and Kiwi News rely on this timestamp and the data to be retrievable into perpetuity to come to our own consensus between nodes.
I want to make everyone aware that:

L2 data is fundamentally not exitable from L2s as blobs become non-retrievable for a regular person
Since we’re building a protocol on top of Ethereum/Optimism, we were relying on this timestamped and into perpetuity retrievabe data to be accessible from a regular Ethereum node.
Since OP’s move to EIP-4844, we’re basically reliant on the good will of the Optimism sequencer operator to allow us access to this data as we’re still allowing users to delegate their keys on L2.

Why do I think this matters for objecting increasing the calldata on L1?
Many application builders have had wrong ideas about what problems L2s are solving for them. The simple fact of the matter is that any type of data where the app builder relies on the data to be retrievable from an Ethereum node in perpetuity MUST BE L1 calldata. L1 hasn’t been a priority so for these types of app developers L1 calldata is, most likely, already considered too expensive. But making it more expensive basically kills their use cases as then building a protocol on top of Ethereum becomes much harder.
Why calldata and not blobs?
Blobs’s retrievability on nodes is only possible in the short term. I’m not aware of a workflow that would make it possible for a Farcaster or Kiwi News node operator to download all blobs ever stored on Ethereum and if I read the docs correct, then blobs will be pruned from nodes after some time. That said, I think it is also unproductive to suggest that these apps “can just load blobs from an archival service.” I’m aware that centralized blob archival services for blobs exist. But we ourselves are building a protocol, and so to make it reliant on the good will of a blob archival provider isn’t any better than being reliant on the good will of the Optimism sequencer operator. We want to base our protocol on Ethereum. Otherwise, if we base it on a centralized operator (be that the Optimism sequencer or a blob archival provider) our guarantees to users will be much worse.
The usefulness of calldata is that the data is timestamped (without the submitter being able to control the timestamp) and retrievable in perpetuity from a regular Ethereum node with a pretty good guarantee that any standard interface provider like Infura and Alchemy also provide access to the data and that we don’t have to rely on any single entity.
I think it should be prioritized creating a space where L2 users can cheaply post small amounts of metadata that can be timestamped and stored into perpetuity. We must mitigate the damage that is currently done on L2s by unaware application builders (who store data on L2s thinking it is permissionlessly retrievable in perpetuity) and we must broadly teach that L2 data isn’t as exitable from L2s as are ERC20 tokens.
I hope you can consider this feedback to make a decision. I’m happy to provide more detailed information. A disclaimer: I’ve said that Farcaster is also reliant on using this “ideal timestamped calldata, retrievable into perpetuity,” it still is.
However, from what I know, they’re now actively working on Snapchain, which is most likely going to solve this problem for them. I’d prefer to keep building Kiwi News on Ethereum, and so I think it’s important that this information gets circulated and understood to make wise decisions at the level of the core devs. Thank you.

Author: Nerolation
Date: 2024-12-19T07:01:25.867Z

Thank you for the feedback!
To clarify, applications that still want to post data on-chain via calldata can continue to do so—it just might become more expensive. This cost adjustment is primarily aimed at reducing worst-case limits without impacting the majority of users. It’s a trade-off between “making a small nr of tx more expensive” vs “DoS resistance”.
When data is posted as calldata, it becomes part of the history, which places a burden on every node. In contrast, blobs are pruned after approximately two weeks, offering a more scalable solution.
While pure data transactions via calldata may become costlier, there are proposals, such as EIP-7639, that could eventually enable pruning of calldata as well. Ethereum has always prioritized horizontal scaling and reducing hardware requirements, so this direction should come as no surprise.
The “timestamp” argument applies equally to blobs. Your application could choose to store data in blobs, retain all blobs locally without pruning (which I do personally, and I assume most companies can do as well), and still make the data—including timestamps—available for verification.

Author: TimDaub
Date: 2024-12-19T12:47:33.557Z

Nerolation:

To clarify, applications that still want to post data on-chain via calldata can continue to do so—it just might become more expensive.


Yes, I understand that.

For our dapp, to delegate keys pre EIP-4844 a user would roughly pay 0.1 USD to delegate their key. Most users accepted this.
Post EIP-4844 with OP posting into blobs this cost as gone to 0.01 USD. However, I have described above why that is non-sustainable for us and what the security implications of OP posting into blobs storage are.

Now let me simulate what it’d cost on today’s mainnet (napkin math ahead):

We need to post 3x 32bytes into calldata. We also have to pay the transaction envelope cost of 21k gas
We’ve maximally optimized gas costs of our key delegation contract down to 37k gas when posting on OP. We don’t push the key into readable storage for other contracts or users, it’s plainly calldata and emitting an event (details). All this to say, there’s very little optimization potential for us to bring costs down.

Farcaster has a more complex identity model where they also store the delegated key in storage (so for them it’ll be much more expensive)
- At today’s 10gwei gas rate (the post EIP-4844 average gas cost was 10gwei), putting 3x 32bytes into calldata on L1 is $1.44. That’s unacceptably expensive as a cost to just get a consumer logged into a dapp!



Screenshot 2024-12-19 at 12.54.35840×1732 88.1 KB
Why is it unacceptably expensive already?
Farcaster has already implemented a model where the user has to pay up to 1 USD when they want to login to another app using their Warpcast-internal delegation.

Many users on Warpcast have specifically complained about this being too costly for the use case. There are ways to look up the complaints using Warpcast’s search or even asking someone from the Merkle Manufactory team. I’m sure they’ll confirm that this is an issue, if they haven’t yet said publicly anyways.
Farcaster developers are moving away from Ethereum Optimism through the Snapchain proposal. Since in the Snapchain message timestamping is also harder to user-control this will allow them to put the delegations on the Snapchain, leaving Ethereum.
With Kiwi News, we also don’t know were to go frankly. But Ethereum or the L2s don’t seem to serve our use case at all. I however have the impression that we’re very Ethereum aligned. Why is Ethereum not serving us? We (consumer apps like FC and us) have a lot of growth potential through onboarding consumers. And our architectures are very aligned with Ethereum’s vision of decentralization. Putting on my Ethereum investor hat, it’s suboptimal that we seem to want to just ignore this use case

I want to stress here that I think Ethereum’s treatment of users who need to store small amounts of metadata into calldata is what’s most likely leading them to implement alternatives, not the other way around. Mind you, the 1.44 USD that is shown on the Metamask screenshot is the cost today, at LOW gas fees. Your proposal wants to increase this.



 Nerolation:

When data is posted as calldata, it becomes part of the history, which places a burden on every node. In contrast, blobs are pruned after approximately two weeks, offering a more scalable solution.


I’m aware that it puts a burden on everyone. But there’s also a benefit to it. E.g. we and Farcaster are creating a new online space for people to curate and publish content. Do you want to continue to post on X? I don’t.
If you read my original response you’ll find that blobs are not a functionally perfect substitute of calldata for us. Blobs are only a perfect functional substitute for rollups who can settle their balance before blobs are pruned on the nodes. Obviously the Ethereum community has set a blobs pruning target that fits rollups. Blob space was custom made for rollups. Also, us and comparable projects have never been contacted about a prune duration we would prefer.
That said, our and Farcaster’s delegation keys live on people’s apps, so alternatives to the Warpcast and the Kiwi News client. Those keys have a long lifetime: Basically they keys that have been delegated for Kiwi News to upvote a story 1.5 years ago today still have to be retrievable through Ethereum calldata. That’s why I’ve been saying “in perpetuity.”
But I want to stress this again, our keys in our users’ app live way beyond the duration that blobs are stored on Ethereum nodes. Hence we cannot use blobs. I’ve also argued extensively for other reasons why blobs cannot be used, e.g. that they’re not easily permissionlessly retrievable after pruning.



 Nerolation:

While pure data transactions via calldata may become costlier, there are proposals, such as EIP-7639, that could eventually enable pruning of calldata as well. Ethereum has always prioritized horizontal scaling and reducing hardware requirements, so this direction should come as no surprise.


The practical requirements of application builders suggest we may need to reconsider this approach.
I have been using Ethereum since 2018-2019 as an application builder and up until very recently the invariant that all data will stick around and be retrievable with an archive node has been solid (maybe not in ETH researcher circles, that may be).
I’ve never been a fan of EIP-4444 and state expiry proposals etc. When I talk to other builders I often get approval with that opinion. Dapp builders have informed opinions as we have to work with the actual system in the trenches and make it work for users!



 Nerolation:

The “timestamp” argument applies equally to blobs. Your application could choose to store data in blobs, retain all blobs locally without pruning (which I do personally, and I assume most companies can do as well), and still make the data—including timestamps—available for verification.


If we were building an application, maybe. But we’re not building an application, we’ve built a protocol using set reconciliation over a patricia merkle tree. So has Farcaster. If we want our nodes to come to a deterministic eventual consistency over who has posted what then they’ll have to have all the same source of truth of which key is allowed to post on behalf of which root key and during what time intervals (again: Happy to provide even more details here). That’s why us and Farcaster have been leveraging Ethereum to store key delegations. The key delegations must be stored in perpetuity retrievable for all Farcaster and Kiwi News nodes and they must be timestamped such that the user cannot back date their delegations. If this isn’t the case then all sorts of bad things happen in our protocol. E.g. someone could claim to have casted a message in 2021 etc.
Again, you cannot suggest to use blobs here:
We’re actually talking about the proper functioning of the p2p set reconciliation algorithm that reconciles messages on Farcaster and Kiwi News nodes.

E.g. my Kiwi News node has been running since 1.5 years.
A new Kiwi News node might come online today. It’ll want to download all messages from the last 1.5 years from my node.
If we were to look up key delegations in blobs, then my node would have received all blob related key delegations and could have retained them after they were pruned. No problem so far.
However, that new Kiwi News node which just came online CANNOT trust my node to understand who has delegated their keys. They can also not look up long gone key delegations in a permissionlessly decentralized way because blobs archives are only provisioned by centralized actors. And additionally, you have to consider that today all a new node operator has to do is enter a Alchemy or Infura RPC URL to the .env file. If you actually want people to download blobs from centralized actors this comes with all sorts of problems for us.

If you look at Farcaster’s Snapchain proposal over their original architecture, you’ll find that the Snapchain which moves away from eventual consistency is much more complex than their earlier version.
The first time I saw FC’s architecture I was amazed by it as I had looked for a scalable dapp architecture that would also allow to scale the metadata that usually accumulates in dapps. I truly think that a generalization of the FC set reconciliation (including a few tweaks here and there) can get us really far towards the goal of a scalable dapp infrastructure for data.
Think about it. We’ve created the equivalent to rollups for data. All we have to store are key delegations. It’s highly efficient for how much data you can store on these networks. And rollups cannot be used for data as I’ve already mentioned (because rollups cannot exit data). So why would you hinder this use case by increasing calldata costs? This type of architecture should be promoted and Ethereum should serve it, as it has served rollups! We should not let Farcaster escape into building their own thing! We should serve them

Author: TimDaub
Date: 2024-12-20T08:38:08.578Z

Nerolation:

When data is posted as calldata, it becomes part of the history, which places a burden on every node.


If you combine this sentiment with a proposal to increase costs, then this is Bitcoiner-style zero sum thinking.
When I worked at ascribe.io in 2015, the Bitcoiners also wanted to shut us down for storing art on the blockchain. Exactly the same argument. “It burdens everyone.” This was right before the blocksize wars.

In either case, Bitcoin was ill-equipped to handle Ascribe, and it was sometimes met with outright hostility in the crypto community. On a technical level, Ascribe capitalized on a standardized function called OP_RETURN, which enables a user-defined sequence of up to 40 bytes to be written onto the blockchain. This allowed for things like links – pointing to images and longer texts living off-chain – to be stored in Bitcoin transactions. Daubenschütz wrote about the project in a recent newsletter for NFT curation protocol JPG.space: “Ascribe was built on Bitcoin … by signing up via email and password, a hierarchical deterministic wallet was derived from the federation wallet; all ownership transactions were stored in an inventive protocol called SPOOL, the “Secure Public Online Ownership Ledger”(12). Similar to the well-known ERC721 NFT standard, the SPOOL encodes ownership information on-chain(13); but it was a hell of a mess as Bitcoin really wasn’t meant for any of this.(14)” Indeed, issues occasionally arose with Bitcoin validator nodes rejecting the transactions for containing too much data; some hardcore Bitcoin purists even called OP_RETURN transactions “spammy” or blamed them for bloating the network (15). As their anxieties attest, Ascribe was a critical intervention for attempting to broaden the blockchain’s functionality beyond straight-up financial exchange.




jpg100.substack.com



On Building - our essay from the NFT Taschen Book
TLDR: a good summary of infrastructure and the history of NFTs towards ERC-721 as told by its protagonists





I’m excited about Ethereum’s potential to scale beyond rollups! We already went from zero to one
What Ethereum’s implementation of the rollup roadmap has shown is that if we can identify a use case that clogs up L1 mainnet, and we design a better, cheaper, alternative solution, we scale Ethereum, bring down costs to many users and developers, allow more people to use the technology, and we broaden its appeal. That’s amazing! Meanwhile we have managed to leave Ethereum L1 largely unaffected. AND we have scaled DeFi and tokens and while we have preserved all L1 guarantees (as of now).
I’d hence propose that if we want to scale L1 throughput, instead of curbing economic activity with restrictive policy proposals, we should come up with solutions that make it economically unviable to still use the L1 resource because there’s a better alternative. A great example of this is rollups using blobs, which have produced a 91% cost benefit over storing their data in perpetuity in calldata (https://dune.com/0xRob/blobs).
Screenshot 2024-12-20 at 09.32.531076×814 35.5 KB
So to unclog L1, I generally propose the following method to develop Ethereum:

Analyze what causes L1 clogging
Design an economically more viable solution and adjust it until developers use it
When developers move, L1 un-clogging happens
repeat

I think scaling this type of thinking in the culture of Ethereum developers could also lead to a broad enthusiasm about its culture. Maybe you know: https://www.solanaroadmap.com/
I’d be excited if we could do this our own way too! Investors would love it too probably
And just to make sure: blobs != calldata for all use cases of calldata, so please don’t suggest again to use blobs, thank you.

Author: Nerolation
Date: 2025-01-04T11:05:10.588Z

The rationale behind this EIP goes beyond simply saying, “it’s a burden for everyone, so we’re making it more expensive.” Large blocks pose a significant DoS risk, and ensuring the network’s security is of utmost importance. It’s a delicate balance between allowing larger blocks to enable certain types of applications and safeguarding the network, and this decision is far from black and white. For instance, storing HD videos directly on-chain is already impractical. While making calldata extremely cheap could make it feasible, doing so would drastically increase hardware requirements for nodes or require longer block times. In most cases, it’s more sensible for blockchains to host large datasets externally (e.g., via IPFS) and only store timestamped proofs on-chain.
With the gradual increase in gas limits, we’ve seen how vulnerable the network can be to large blocks, and EIP-7623 addresses this by mitigating that risk. The vast majority of users won’t notice any difference. Among those affected, most are only writing small amounts of data into calldata, so they’ll see only a slight increase in costs (=negligible since 100 more gas is nothing in perspective of paying 21000 gas already).
Here are two recent instances where large blocks caused issues:



Ethereum Foundation Blog



Sepolia Incident | Ethereum Foundation Blog








Ethereum Research – 9 Dec 24




On Increasing the Block Gas Limit: Technical Considerations & Path Forward




Execution Layer Research




On Increasing the Block Gas Limit: Technical Considerations & Path Forward Authored by: Toni, Marek, Pari, Jacek, Paul, Tim and Alex.  Authors’ Note:  The core development community is committed to continuous improvement of the network’s...

Reading time: 4 mins 🕑
Likes: 50 ❤

Author: poojaranjan
Date: 2025-02-18T04:16:55.008Z

PEEPanEIP #140: EIP-7623: Increase calldata with @Nerolation

Author: sbacha
Date: 2025-03-07T13:33:12.316Z

The comparison to “storing HD Video” is a strawman argument, no one is proposing to do that.
Blobs are for ensuring the availability w.r.t. the fraud proof window, they are not for legit calldata use cases.
Additionally, this requires changes to the gas pricing API’s, of which I do not know one provider who is even working on this (I would assume there are some at least). With EIP1559 there was a readiness checklist for downstream services signalling readiness for the new changes (e.g. Wallet providers supporting the usage). Do you have such a check list? I maintain a Gas Reporting Registry, GitHub - sambacha/gas-reporting: Reference documentation on every gas price API and all the different formats so this would be helpful to know and to provide additional information regarding the changes!
Thanks @Nerolation for responding to all these questions, I can appreciate both sides of the argument.

Author: TimDaub
Date: 2025-03-08T13:07:25.479Z

sbacha:

The comparison to “storing HD Video” is a strawman argument, no one is proposing to do that.


I agree, this is crazy. We just want our 3x 32 byte calldata to be preserved to do onchain delegations of Ethereum addresses, and at the same time we need to make this transaction consumer friendly. I have been pretty clear about this in earlier posts already. Not HD videos. Blobs are fundamentally not a consumer grade transaction anyways.

Blobs are for ensuring the availability w.r.t. the fraud proof window, they are not for legit calldata use cases.

Sorry for the accusation but it is my assessment that ETH researchers are pretty clueless or willfully against other use cases but token trading. I‘ve brought this issue up many times already. There are many use cases of Ethereum beside cheap token swaps, but nobody seems to care. At the end of the day this is probably a failure from us who rely on long-term retrievability of data etc. The DeFi lobby on Ethereum is very strong, for good reasons

Author: Nerolation
Date: 2025-03-08T15:12:54.640Z

sbacha:

The comparison to “storing HD Video” is a strawman argument, no one is proposing to do that.


You’re right—storing HD videos was a poor example, as it pushes the argument to the extreme.
Ultimately, though, it’s a trade-off between allowing larger blocks and enabling messaging through calldata.



 TimDaub:

my assessment that ETH researchers are pretty clueless or willfully against other use cases but token trading.


This is just gaslighting, and it doesn’t help in being taken seriously—which, to be clear, I have and still do. We both know that large blocks pose a significant DoS risk. On top of that, until we implement regular history pruning, every full node has to store it on disk, further driving up hardware requirements.

Author: TimDaub
Date: 2025-03-08T16:20:54.950Z

Nobody wants regular history pruning but token swap applications

This is just gaslighting, and it doesn’t help in being taken seriously

You didn‘t give a shit about my concerns and the proposal has been moved further in the Pectra approval process. I have been pretty respectful so far. Also in person at Devconflict where my concerns were cast aside too. Why should I now care about an etiquette that you impose? Maybe take people‘s concerns seriously next time before they start to violate your etiquette

Author: Nerolation
Date: 2025-03-08T17:46:00.706Z

I take others’ concerns seriously, but there’s another perspective in this discussion: some advocate for making calldata more expensive to mitigate the growing DoS risk that comes with increasing gas limits.
History expiry shouldn’t come as a surprise—it has been under consideration for years. For instance, Vitalik’s well-known roadmap diagram highlighted it years ago.
There will never be complete consensus on any topic. At some point, after weighing the pros and cons and going through the ACD process, a decision has to be made.

Author: TimDaub
Date: 2025-03-08T19:17:39.350Z

Nerolation:

History expiry shouldn’t come as a surprise—it has been under consideration for years. For instance, Vitalik’s well-known roadmap diagram highlighted it years ago.


I‘m not surprised by state expiry. I‘ve always been against it. As you can read from my above remarks, I have already built applications with data retrievability in perpetuity in mind since 2015, so I‘m quite aware that there are plans for history expiry, and I‘m still against it today. Vitalik is just one person. He‘s our leader but I don‘t agree with everything he proposes.

There will never be complete consensus on any topic. At some point, after weighing the pros and cons and going through the ACD process, a decision has to be made.

You should consider projecting the minority by eliciting their use cases. Many people will just stop building on Ethereum without a complaint beforehand. L2s are already useless to my application so I have moved off of Ethereum. Everyone sleepwalked into this. DeFi has a much stronger lobby. But people who want to etch stuff in the chain arguably don‘t have a strong lobby or billion dollar companies who can commission research and influence.

Author: CPerezz
Date: 2025-03-10T11:36:30.596Z

I’m wondering how will that play in the mid-term with STARK/PQ-secure proofs verification.
All of the proving systems known atm that are PQ-secure depend on having large proofs.
See for example this post on WHIR Solidity verifier or this post on lattice-based signature solidity verifiers.
If we blow-up CALLDATA cost, how do we anticipate verifying these proofs when we don’t need any sort of DA solution (we just need to verify the proof to trigger certain SC function). So basically, no blob-related stuff to solve this.
It will become unreasonable to have apps as we have today that rely on G16 verification being “decently cheap”.

Author: TimDaub
Date: 2025-03-20T09:33:10.774Z

Nerolation:

History expiry shouldn’t come as a surprise—it has been under consideration for years.


EIP-4444 was written at a time (2021) when historical block state growth was still an issue. Today, the L1 isn’t even being used anymore! We’re sub 1 gwei gas!! We’re seeing a much slower growth of the total size of the sync because of less activity on L1 and blobs. The motivation for EIP-4444 is outdated! This is what EIP-4444 says in its Motivation

Historical blocks and receipts currently occupy more than 400GB of disk space (and growing!). Therefore, to validate the chain, users must typically have a 1TB disk.

This is arguably less of a concern in 2025. As you can see below, the full chain sync data size is growing at a much slower rate than what it was when EIP-4444 was written. Please update your priors.
Screenshot 2025-03-20 at 10.10.342480×886 137 KB
Also, if you haven’t already, I invite you to read the comments for EIP-4444. The community hates this proposal and there are many people who have come out against it. Their arguments in summary:

Storage costs have decreased significantly - 4TB SSDs now cost ~$280, making historical storage more affordable
Storage capacity grows faster than blockchain size - The relative burden is smaller over time
Post-Dencun architecture has reduced data growth - Block sizes and daily history growth have decreased
Breaks Ethereum’s promise of data persistence - Undermines the “unstoppable apps” value proposition
Canonical transaction history is a core value - Critical to Ethereum’s fundamental utility
External solutions have proven unreliable - TheGraph has demonstrated censorship issues
Creates new centralization risks - Forces reliance on potentially centralized data providers
Degrades developer and user experience - Breaks uniform access interfaces for historical data
Damages DeFi ecosystem - Could reduce DeFi to permissioned fintech services
Alternative economic models exist - Storage could be incentivized through fees or staking
Historical data has inherent market value - Reduced supply may create natural incentives
Breaks existing applications - Many dApps depend on historical data access

Do you suggest to argue away the community’s concerns? Do you think they are all wrong? I don’t.



 Nerolation:

There will never be complete consensus on any topic. At some point, after weighing the pros and cons and going through the ACD process, a decision has to be made.


I completely agree that there will never be complete consensus. But have you read the EIP-4444 comments? The roughly consensus is that nobody wants it and the EIP has since then been stagnant.
To me “going through the ACD process” is not creating legitimacy around the issue. Nobody but people who are paid to work on this software can afford to go to all of these calls to argue against certain roadmap items. Again I’m an app developer, not a core dev. If you also know anything about my app’s funding model you will know that my money is anyways earned by delivering a good app to consumers, not to play the politics in ACD calls. Clearly then the concerns in the Ethereum Magicians forum have to be heard and taken seriously.



 Nerolation:

Vitalik’s well-known roadmap diagram  highlighted it years ago.


This tweet was posted on 5 Nov 2022. IMO it is not relevant anymore either. Look at the financial fundamentals of Ethereum:
Screenshot 2025-03-20 at 10.15.223118×1002 324 KB
The fact is that due to the L2 roadmap now fee accrual has come down significantly in 2025. We’re on track to only make $300M, down from $2.4B and even 4 and 9 billion! That’s an order of magnitude LESS in 2025! Maybe you make good money in the Protocol Guild aside from your EF salary, I’m locked into only ETH prices rising!
It is pretty clear that we can’t just blindly continue to execute Vitalik’s roadmap diagram anymore as we have to cater to the issues that we’re having today, which are that fee accrual is basically now broken for Ethereum. So that has to be fixed first before there is any further legitimacy in following the technical vision of the founder. If that roadmap is followed there’ll just be further deterioration in price because fee accrual won’t fix itself.
Even Vitalik has since then admitted that L2s aren’t super useful for everything we want to do with Ethereum: Reasons to have higher L1 gas limits even in an L2-heavy Ethereum
Fundamentally L2s are really just a temporary transactional layer that you should exit after you’ve done your business. They are really useful for trading memecoins. And his post also admits that it’s effortful, at best, to bolt-on more use cases to the existing rollup design or to make it safer e.g. for L2 issuance.
I think if we want to grow fee accrual again we have to develop calldata beyond just increasing its cost. Calldata is what got rollups started. And as I’ve said, blobs and L2s are a narrow solution to transacting scalar values cheaper. But they don’t solve other use cases the L1 services. Please do acknowledge this.
I’m obviously not surprised by the state expiry roadmap. I’m against The Purge part of that roadmap and I have been for a while.
There are many applications which have been building for years on Ethereum and which are not served well with e.g. the dumb formulations in EIP-4444

Historical data can be packaged and shared via torrent magnet links or over networks like IPFS. Furthermore, systems like the Portal Network or The Graph can be used to acquire historical data.

Why are Ethereum core devs shilling me The Graph or IPFS? Or Torrents? This level of not-giving-a-fuck really makes me mad. The Graph, IPFS, Torrents, they all suck!
There is a very good reason I do not use these systems today in my dapps. Torrents and IPFS have literally existed for the entirety of time while Ethereum has existed. If they are so great, naturally dapp developers would have adopted them in the meantime, don’t you think?

Author: Nerolation
Date: 2025-03-21T13:29:24.117Z

First, it’s good to have different perspectives, and I appreciate that you’re voicing yours.
We clearly see this issue differently, and that’s okay. The community saw big blocks and growing history as a problem, and people reacted to that. There was no skipped governance; discussions happened, and decisions evolved over time.
History isn’t being erased, just handled differently. Not every node will store everything, but the data will still be accessible.
I get that this is fair to push back. But let us keep things professional—no need for personal attacks.

Author: TimDaub
Date: 2025-03-21T13:39:03.148Z

Nerolation:

The community saw big blocks


Blocks aren’t big anymore. EIP-4444 was written on a premise that is false today. Growing history isn’t a problem as of now. 4TB SSD are 280 USD today. Update your priors.



 Nerolation:

and decisions evolved over time.


Decisions have to evolve again, I have presented a lot of arguments for re-assessing the situation.

Author: TimDaub
Date: 2025-03-24T15:24:02.428Z

Nerolation:

Your application could choose to store data in blobs, retain all blobs locally without pruning (which I do personally, and I assume most companies can do as well), and still make the data—including timestamps—available for verification.


I don’t think this is a practical suggestion.
As I have described, my users rely on submitting their delegation transactions themselves. These delegations are 3x bytes32. It’s important that their message sender is the user’s who’s delegating to a temporary application key.

Isn’t the minimum blob size 128kb? Why suggest using blobs when we just wanna store 3x bytes32?
Which of the most popular wallets are supporting signing and sending blobs today? My initial research of a few hours today is suggesting me that no one is actually supporting this as of now.

I think if blobs were broadly supported to allow users to anchor data on Ethereum then yes, our p2p network could take care of keeping those blobs retrievable, but as of now it looks like as if:

wallets do not support this
the minimum size of blobs is waaaaay too big for what we’re trying to do.

My understanding is that one of the reasons for making call data more expensive is to not make it a substitute for rollups when blobs get a minimum fee. OK, I get that. But the damage that you’re doing to all other app devs on Ethereum is significant. Vitalik has always said that Ethereum is a generalized computation platform and not serving one specific use case. And here we’re definitely making decisions that exclusively serving rollups.
My proposal here would be this:

Find a size of calldata for which it is still OK to use the old calldata cost, this will make sure that small application devs can still take advantage of cheap calldata
For your rollup customers, make sure that they’re paying the more expensive calldata prices so that they use blobs over calldata

Just an example of what an implementation could look like
if (tokens_in_calldata < 256 bytes && execution_gas_used < small_threshold) {
  // old call data cost calculation if the user just wants to store a little bit of data in calldata
  tx.gasUsed = nonzero_bytes_in_calldata * 16 + zero_bytes_in_calldata * 4
} else 
  tx.gasUsed = (
      21000
      +
      max(
          STANDARD_TOKEN_COST * tokens_in_calldata
          + execution_gas_used
          + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata)),
          TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
      )
  )
}

Not really saying we should limit it to exactly 256 bytes or whatever, but just for you to understand what I’m thinking about. E.g. if we constraint it to a small size then it wouldn’t make sense for rollups to use this, right? Plus, this would probably still allow you to keep blocks small. It wouldn’t allow anyone to store HD videos in calldata

Author: TimDaub
Date: 2025-03-24T17:42:15.808Z

After some more discussions in DMs my concerns might be addressed by running an OP sequencer copy ourselves and sending calldata to OP mainnet. I had previously assumed we have to store our delegations into L1 calldata after L2s replaced storing in calldata to blobs

Author: OlivierBBB
Date: 2025-03-25T10:40:14.350Z

Hi there @gurukamath, I’m wondering the same thing. Has anyone provided you with an answer ?

Author: Nerolation
Date: 2025-03-25T14:14:14.377Z

Check this line in the specs:

github.com


ethereum/execution-specs/blob/a25a8ab3a2989b15baac19eb327325e442342a60/src/ethereum/prague/transactions.py#L215

      
                  based on the calldata size.
          
              Raises
              ------
              InvalidBlock :
                  If the transaction is not valid.
              """
              from .vm.interpreter import MAX_CODE_SIZE
          
              intrinsic_gas, calldata_floor_gas_cost = calculate_intrinsic_cost(tx)
              if max(intrinsic_gas, calldata_floor_gas_cost) > tx.gas:
                  raise InvalidBlock
              if U256(tx.nonce) >= U256(U64.MAX_VALUE):
                  raise InvalidBlock
              if tx.to == Bytes0(b"") and len(tx.data) > 2 * MAX_CODE_SIZE:
                  raise InvalidBlock
          
              return intrinsic_gas, calldata_floor_gas_cost
          
          
          def calculate_intrinsic_cost(tx: Transaction) -> Tuple[Uint, Uint]:

Author: gurukamath
Date: 2025-03-25T17:13:09.994Z

Yes. As pointed out in the EELS implementation, you just check to make sure that the user has enough funds to pay for either the intrinsic_gas  or the calldata_floor_gas_cost  as the case may be.
Once you have executed the transaction, if the execution cost is less than the calldata_floor_gas_cost , you just charge the diff.

Author: 0x000hx
Date: 2025-05-07T18:19:39.294Z

Is there any way to reconsider the implementation of this? Its going to make my app 2.5x more expensive. My bad that i learned about it so late.

Author: wjmelements
Date: 2025-05-07T18:57:39.017Z

Too late now. You can propose another way to do it for a future upgrade.
What is your app? I might be able to provide you with gas sheltering.

Author: 0x000hx
Date: 2025-05-07T21:31:40.624Z

Its an onchain storage with post-quantum encryption (kyber) and/or ecc. Mainly for gov and medical institutions, patients history preservation etc. It also allows to send files between users onchain by using asymetric cryptography properties (sends to the receiver, reconstructs his pub key from signed txes, receiver decrypts with secret key). Name is Aetrna, its in stealth as of now.
I already used agressive optimizations so theres not much to do with it, the calldata costs are actually going to make it way more expensive. I can use L2s however they are short-term businesses that gonna cut the operations and erase their datacenters once it becomes unprofitable to run. So storing something really valuable there isnt an option.

Author: wjmelements
Date: 2025-05-07T22:05:07.012Z

Ethereum is also going to prune blocks and transactions in the future so calldata is not great for long-term storage. Only archive nodes will have that information and it won’t be cheap to retrieve from them due to the cost of operation. I recommend you run your own archive nodes if you want to pursue this path, or use a chain less-likely to upgrade in the future (such as Ethereum Classic or Bitcoin).

Author: 0x000hx
Date: 2025-05-07T22:17:28.998Z

Thanks, will consider.
Also @abcoathup could you please remove the double post, thanks