I think of quadratic sharding as a “uniform” scaling solution which addresses all computational bottlenecks (storage, I/O, computation, bandwidth) simultaneously, and in a similar amount. If we have, say, 100 shards then we get a roughly 100x increase in scalability (ignoring overheads such as cross shard communication). In practice I expect the “main shard” to handle a fixed number of “children shards”, so in practice we may only scale by a multiplicative constant. (I’m hoping this constant is >100, but Vitalik probably has better intuition on this.)
I’ve been exploring scaling approaches that are fundamentally “non-uniform”. The idea is to look at the individual bottlenecks separately, and shoot for exponential scaling (vs multiplicative scaling).
- Storage and I/O: At this point I’m very bullish on stateless clients. Great progress has been made, including miner-updated witnesses, Merkle Mountain Ranges, witnesses in miner data, partial statelessness, accumulator sharding, fancy accumulator schemes, witness provision markets, and storage rent.
- Computation: Two approaches I can see working here are SNARKs/STARKs and interactive verification (TrueBit). Theoretically SNARKs/STARKs are the ultimate solution but we may be years away (maybe 3-10 years) from practicality for scalability purposes. Interactive verification is the low tech solution, but relies on data availability for a large class of applications.
- Bandwidth: This is possibly the hardest one theoretically, and boils down to the data availability problem. I think I have made some good theoretical progress on this front which I will publish on ethresear.ch shortly. My gut feel is that SNARKs/STARKs will play a key role in the solution, making data availability hard both theoretically and practically.
In short, I think the low-hanging fruit is stateless clients. This is especially good news because Ethereum’s current bottlenecks are largely related to I/O for transaction processing (and storage to a smaller extent for the initial sync time). In addition, stateless clients are somewhat of a prerequisite for sharding because they allow for frequent validator shuffling. Given this, I think there is an argument to be made to augment the sharding roadmap with “Phase 0” that implements the stateless client on a single shard (i.e. minimal sharding).