EIP-7623: Increase Calldata Cost

EIPs EIPs core
62

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

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.

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

63

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.

64

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.

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

1 Like
65

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

66

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

67

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

68

Check this line in the specs:

1 Like
69

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.

1 Like
70

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.

71

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.

73

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.

74

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

75

Thanks, will consider.

Also @abcoathup could you please remove the double post, thanks