> Zkps are just hashes that can hash the execution of code rather than hashing static data ("dynamic hashes"?)

That's actually a great intuitive explanation. I'm stealing that.

> Do you think cryptographic hash functions are a means to compression?

No. I think I am missing some core idea here.

All I can come up with is a backing store of files (or blocks of files) indexed by hash. Then you can store the hash (or chain of hashes if working with blocks) to represent the file. I wouldn't call that compression though, because you still need the underlying backing store. It could lead to something like compression if you have lots of duplicate blocks. Something like tarsnap uses for efficiently keeping incremental backups. But, compression wise, just handling repeating blocks is rather rudimentary.

I guess the above idea isn't what you had in mind though.

Not all zero knowledge proofs offer compression, or small proof sizes. You can have linear sized proofs with useful properties, eg, zero knowledge. Indeed, the first ZKPs weren't concerned with succinctness at all.

> hashes that can hash the execution of code rather than hashing static data

That’s an interesting way to put it!

How can you prove something about what happens in the real world with some computer program? Okay we run some hash once and then I go chuck the hard drive in a smelter.

> that obviously takes less space

Not necessarily =)

That's not compression if you can't use the dataset. All you compressed is the proof.