You have no authority to say that Ethereum wasn’t designed for permanent data storage. How can you know what all designers of Ethereum were thinking? That invariant has existed for 10 years and app developers have taken advantage. I don’t know why you even bring up Filecoin, it clearly isn’t useful at all. Should rollups also have used Filecoin over Ethereum calldata? Strange argument
Ethereum was not designed for permanent data storage, from the early days of the World Computer (Ethereum, Swarm, Whisper) it was clear that Ethereum blockchain was not supposed to store such data.
Blobs do not provide true on-chain storage compared to calldata, as blob data is only available for 18 days. This necessitates external archiving solutions to preserve blob data. Those solutions require permissionless upload and download, information neutrality, and plausible deniability. There is only a handful of storage solutions who provide those.
Filecoin falls short in addressing plausible deniability challenges, as its nodes are fully aware of the data they store, making it easier to target and track operators. Additionally, the network’s high hardware requirements limit node distribution, hindering its ability to scale in a truly decentralized manner.
It’s still relevant despite its flaws, I wonder what would they say about these
IMHO best way of solving this is accepting that standard should say MAY NOT store.
getLogs interface has nothing wrong with it from client (dApp dev) perspective.
In fact, as dApp developer, I would prefer just having an RPC endpoint that I can arrange with that it will return low-latency event data for pre-arranged contracts/events trough getLogs instead of having to manage separate indexer.