For a zkRollup, if you started building a lookup table as you see txs in the mempool you would decrease block prover latency and memory usage significantly.

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

/opacity

and

/eulerlagrange

For a zkEVM most of the time spent ends up being keccaking and rlp encoding and other state dependent operations.

I don't know if you're going to massively increase the proving time by optimistically proving until you're sequenced.

Builder of things. Dir of Product Research @ Polygon; x: Flow, Augur;

Yes, I can actually write code.

You may be able to get some speedups from non contending operations, but the results for PoS at least showed that parallel EVMs don't really speed up individual block execution dramatically on average.

Thoughts?

The thing is you don’t need to run multiple zkEVMs in parallel. By lookup table I mean you frontrun specific operations (Keccak, RLP). Which is like a zk microservice.

Then when you prove block validity, you can make assumptions based on the table.

See https://github.com/Hmac512/noir-merkle-root-POC-lookup/blob/main/verify-table/src/main.nr

I got a 5x speed up by offloading Poseidon hashes to another prover. The table would be verified by infra and the main circuit by browser/mobile.

I admit, this is just an educated guess.

Only way to know is to POC it.

Polygon game for a grant? Or maybe @atheartengineer? 😎

My point is you can start zk proving parts of the computation as you see txs in mempool, vs doing all in a zkEVM prover. This frontrunning should decrease prover latency.

Also, im pretty confident splitting up the zkEVM prover into zkMicroservices would open up new ways of optimizing.