To actually verify that what was posted in logs corresponds to the state update that is proved by a zkSNARK you have to include every field of the transaction as a public input to the snark verification. It is an extra one point multiplication per input parameter. If the transaction is short you can pack and reduce this number of inputs, but still, right now it’s 40000 gas per multiplication in G1 of BN256.
Right, I forgot about this. I would say make a simple hash of the inputs be a public parameter, along with the inputs, and verify the hash on chain (SHA3 is 6 gas per 32 bytes, so ~3 gas per operation). The data must be public and verified to chain to avoid data availability issues (if the data is non-public, then you’ve basically created a Plasma chain, and at that point you need some trust in the operator for liveness).
And yes, I understand that the above requires some quite heavy duty computing work on the part of the relayers. But at this point it’s widely known that optimizing SNARK/STARK provers is super-important so I’m sure there will be more and more software engineering work going into it over time.