Thread by @matthew_d_green

Every article I read on (ZK) rollups almost gets to the real problem, and then misses it. The real problem is the need for storage. ZK proofs won’t solve this.

I keep reading these articles that talk about the problems with rollups. And they’re good articles! E.g.: medium.com/dragonfly-rese…

But they always reach a point where they realize that the problem is state storage, and then they handwave that the solution is going to be something like Mina or zkSync, which don’t fully solve the state storage problem.

The problem here is that smart contract systems have three kinds of state:

1. Public state (eg total supply of an ERC20)
2. User-owned state (eg your balance in an ERC20)
3. Useless cruft (eg a specific set of transaction structures, block headers, etc.)

ZK-style rollups can help eliminate most of the cruft (category 3).

In principle they can also push storage responsibility for some types of user-owned state onto the users themselves (with a lot of careful engineering work.)

So what’s left is “only” public contract state.

But that public contract state has to be held in a place where it is guaranteed to be available for a while, and can even be moved around if rollup servers die. I feel like all current public discussion discounts the scaling limitations this will create.

Note that I’m not saying “nobody is working on this”. Lots of people are thinking about it. I just don’t think people are publicly explaining how much of a giant PITA it will be. And how ZK solutions (even if they work) will just leave you stuck with a state storage problem.

And I’m afraid that given the incentives, there’s a very simple solution to all of this: just keep the state on a centralized server, rather than designing it to be available and move around.

But once you do that, you may as well just be Binance Smart Chain.