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.