Bit of a riff on my previous post: https://polynya.medium.com/blockchain-full-nodes-decentralization-and-scalability-an-impossible-challenge-d77df0944bbf
It’s abundantly clear that single-ledger monolithic blockchains have hard limits to scalability. Projects may recklessly sweep this under the rug, but state bloat will catch up to them eventually. It’s simply not sustainable.
Some will argue that rollups are bound by the same constraints, but this is not true. So, how can rollups achieve high scalability while still remaining sustainable?
First of all, rollups don’t require consensus mechanisms for security. The concept of 51% attacks do not exist, removing the need to have a culture of users verifying. All transaction data, state diffs and proofs are available on Ethereum L1 — so users can simply verify there, and Ethereum does abide by the philosophy of having a culture of users verifying, so it’ll always be usable on consumer machines. Further, we’ll have techniques like this that’ll make this process easier for the long term: Future-proof Shard and History Access Precompiles — Eth1.x Research — Ethereum Research (ethresear.ch).
Indeed, a rollup only needs to have one sequencer live at one time. With optimistic rollups, you do need to have at least one honest full node to report fraud, so there’s some pressure to keep a full node accessible. However, with such a weak assumption, rollups can actually run with high-spec server-grade machines.
Furthermore, zkRollups — which is where we’re headed in the medium to long term — you don’t even need fraud provers to constantly watch full nodes. Instead of consensus mechanisms, rollups can have co-ordination mechanisms with rotation schedules, where you don’t strictly need BFT — or at least no more so than a minimal amount. Sequencers can be rotated accordingly. So, you can have very high-spec machines but they only need to be online for a certain amount of time.
Given the entire state of a rollup can be reconstructed from L1, rollups can be very aggressive and innovative with state size management techniques like state expiry / regenesis. Rollups can safely have short expiry periods, as the historical data is always available and accessible from L1.
[Side-note: with initiatives like checkpointing, we can have shorter duration validity proofs which can be used to verify full nodes before batch is posted on L1.]
My only concern for rollup full nodes are not sequencers or users, but rather infrastructure providers, developers, etc. It’s totally fine for users to rely on Infura or Alchemy (unlike on L1) but I’d like to see developers being able to run their own nodes, at least. Fortunately, stateless clients can help with this. Eventually, I’d like to see zkR clients derive directly from L1, but I don’t know how far off that is.
And if a rollup does reach its limits, you can always deploy another rollup. Sure, it won’t be composable, but there are multiple projects working hard to solve this.
In short, to repeat myself once again, rollups + data shards on a secure and robust L1 network is the only way the blockchain industry scales to mass adoption.
