The other thing to say about TrueBlocks is that it’s very well specified: https://trueblocks.io/papers/2023/specification-for-the-unchained-index-v2.0.0-release.pdf.
One thing people miss about TrueBlocks is that it keeps the idea of a bloom filter, but it moves the bloom filter to the “chunk” level (chunks being collections of blocks). People interact with the chain in bursts. 10 times in a day, then not again for weeks. Or 100 times in ten minutes then not again for an hour. Whatever the case may be, their addresses appears in bursts. The indexing should reflect that.
Removing blooms from the block (and the receipt, I presume) is a good idea, but removing it entirely seems like a bad idea. Putting a bloom filter at a place that mimics the nature of the end user’s usage makes more sense. Another thing we did was make the bloom filters adaptive so they grow or shrink depending on how many items are put into them. This keeps the false-positive rate constant and makes the size-on-disc minimal.
And, as far as usefulness of the bloom fitlers, if you read deeply enough in the above spec, you’ll see that the way TrueBlocks works is that the end-user applications download only the chunk-level bloom filters (4 GB for an index of Ethereum Mainnet for every appearance of every address). In other words, they don’t need an archive node to get the benefits of a full index of the archive node.
The end-user app can consult this 4GB chunk blooms and download only the portions of the index that they’re interested in. Natural sharding.
Plus, if the end-user app “pins-by-default” on IPFS, you get naturally-grown sharing.
This may be coming across as a shill (I wrote TrueBlocks and the Unchained Index under EF grants over the years), but it actually already works and it works in exactly the way a truly decentralized application (and a truly decentralized world) would want it to work.
Have you seen this, @vitalik?