Content
@
0 reply
0 recast
0 reaction
EulerLagrangodamus
@eulerlagrange
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.
2 replies
3 recasts
23 reactions
pgpg
@pgpg.eth
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.
1 reply
0 recast
1 reaction
pgpg
@pgpg.eth
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?
1 reply
0 recast
1 reaction
EulerLagrangodamus
@eulerlagrange
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.
1 reply
0 recast
0 reaction
EulerLagrangodamus
@eulerlagrange
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.
1 reply
0 recast
0 reaction
EulerLagrangodamus
@eulerlagrange
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.
1 reply
0 recast
0 reaction
