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