Thread by @epolynya

Some thoughts:

1) Optimistic rollups can have stateless clients. With designs like danksharding + relevant access opcodes, high-frequency state expiry becomes trivial because state is easily reconstructed from L1. High throughput optimistic rollups are not impossible.

https://twitter.com/DangerWillRobin/status/1492507834722000899

2) ZK rollups can have validity proven nodes ala Mina. I believe StarkNet is working on this?

In both of the above cases - statelessness and validity proofs - you can have high throughput, but a low cost to verify rollup nodes directly.

3) Cost of block production will still be high. But as Vitalik's Endgame article argues, this is pragmatic as long users can verify easily, and we have censorship resistant techniques like crLists that force block producers to include transactions.

vitalik.ca/general/2021/1…

Further, rollups have a much weaker trust assumption: 1-of-N, so one can argue that higher system requirements for rollup BPs are much safer than equivalent monolithic chains.

4) Finally, you can just run an L1 node. Today, the trade-off is latency, but as rollups mature and...

...build activity, and with danksharding type designs, you can totally have rollups where rollup finality = L1 finality. Interestingly, you can also have rollup finality shorter than L1 finality with recursive validity proofs, but that's for another time.

5) Rollups have a wide-open design space. While some rollups may choose to not implement statelessness or validity proofs, and keep running a rollup node very easy, other rollups won't. For example, dYdX regularly has more computation than Ethereum already.

6) Of course, even with mature ecosystems, there'll still be limits to how far a single rollup's throughput goes. You need to ensure infrastructure is feasible too. My contention, though, is this ceiling can be very high - and much higher than is safe with monolithic chains.

7) Cross-rollup interoperability is much better & safer than cross-L1. With danksharding, two-slot communication between ZK rollups should be fine, and even single-slot transactions might be possible with crLists (TBD on this one). Liquidity sharing is also possible (dAMM).

8) We definitely want the settlement layer to be stateless or ideally validity proven. Ethereum is working on both statelessness and zkEVM - but these will take time. The endgame is one validity proof to rule them all - verifying all rollups.

The main challenge, as I see it, is actually coordinating all of this data and having robust systems that make it easy for stateless and validity proven clients to access all easily. This is a 1-of-N assumption, so I'm not concerned, but it'd be great to have multiple solutions.

Of course, I get that John is working on solving the above problems with Fuel V2 - that's great. But I wanted to question if other rollups are a dead end and are forever limited by state bloat. It just doesn't align with everything I have seen, but hey, I'm just a minor hobbyist!

9) Finally, and perhaps most interestingly: using Durin (which has just been finalized as EIP-3668!) or similar protocols you can have Ethereum light clients be light clients for rollups.

Side-note: I definitely see application-specific rollups making sense for certain applications, particularly as recursive rollups / L3s.

Eventually, I can see composability being solved across all rollups in the same network.

medium.com/starkware/frac…