Thread
This may be an obvious point, but ZKPs open up a whole new design space in how we can scale blockchains. In the context of rollups, this means that zk rollups can scale way beyond what is possible with the alternatives.
A short 🧵
A short 🧵
ZKPs give us two superpowers: (1) we don't need to re-run a computation to verify that it was executed correctly, and (2) we don't need to see all the data that went into a computation to verify that the result is correct.
The first property is what allows zk rollups to avoid crypto-economic games when proving to L1 that a set of transactions was executed correctly. This is already hugely beneficial (i.e., no need for a week-long challenge period) - but that's just scratching the surface.
We can also use this property to shift the computation burden from the network to end users via locally-generated proofs. That is, for anything that doesn’t touch the public state, users can execute and prove transactions locally, and then send ZKPs to the network.
Thus, sequencers/operators need to execute only the transactions which touch the public state, and for everything else they can verify proofs generated by others. This approach takes concurrent transaction processing to the next level and makes the system horizontally scalable.
The second superpower gives us better data compressions. For example, we don't need to put transaction signatures on L1 - a single short ZKP can prove that we've verified signatures for thousands of transactions. But again, this is just scratching the surface.
What we actually get is a paradigm shift: blockchains no longer need to be transparent to maintain integrity. This is good for two reasons. First, again, data compression. Instead of bloating the blockspace with the contents of my account, I can store the contents locally.
What goes on chain is just a short commitment to my account state. Any time I execute a transaction against my account, I send a new commitment to the network together with a locally-generated ZKP. The last part ensures that I update my account according to the agreed-upon rules.
An account represented in such a manner will never require more than 32-bytes of blockspace - no matter how much data it stores or how many tokens it owns. Contrast this with an ERC20-like model where each token I own requires dozens of bytes of blockspace.
The second benefit of integrity without transparency is privacy. If the contents of my account are not on chain to begin with, making sure that the whole world does not know my entire transaction history becomes a much easier task.
This also means that privacy and scalability can go hand-in-hand: the less data I keep on chain and the more proofs I generate locally, the smaller the burden I impose on the network, which should translate into lower fees for me.