I’m not following here. If the oracle generates a false table for their own use, then the table would never be made public. In this version the table can be a private input to the circuit.
This is a valid point for the MMR approach. It really only makes sense in the cases where:
-
ZK is used for its privacy preserving properties, so you can offload only the insensitive parts to cryptoeconomic security.
-
A fraud proof would be too resource intensive to generate for the whole computation. So it would be easier to split it out into many smaller operations, and you only need to contest the incorrect operations. Would be interesting to apply this to the OP fraud proof game.
—-
Keep in mind the MMR approach isn’t the only variation. Instead infrastructure can zk prove the table validity, and then recursively update the root proof to neutralize the table.
Faster client side proofs is the use case I was driven by, but it goes beyond that.
Take a zkrollup. Right now they are usually monolithic systems. With this technique you could split up proving into separate microservices that can each be optimized for a specific task.
For example, a service can order txs as it seems them in the mempool, and start validating lookup tables for keccak hashes the main prover would need.
It’s a new way to achieve IVC