The basic idea is that you have functions with both public and private parameters. You can do two things:
1) Pass in all parameters, get back the output and a proof that the output is correct.
2) Pass in just the proof, the output, and the public parameters, and get verification that the function ran correctly; i.e. that the public parameters and some private parameters you don't know generated that output.
So on chain, you can skip storing all the private parameters, as long as you store the proof, and have a contract verify the proof before storing the public data.
The Ethereum blockchain hosts serious money. However it has poor cost and performance characteristics for many potential use cases. One approach to work around those is to move money temporarily from Ethereum to another blockchain (let's call that the secondary chain) that's cheaper/faster; shuffle it around there as much as you want; cash in the money back on Ethereum when you're done shuffling it. "Rollups" are a way to pull off that trick (there are other ways). Rollup means (to me at least) that you arrange to publish a kind of checkpoint of the secondary chain state at some point in time, to Ethereum. This checkpoint operation is relatively cheap to do because it's just a "put" of some small number of bytes. Where this comes in handy is when someone asks to withdraw their money from the secondary chain to Ethereum. If they were able to just say "give me my money", there would be the potential to steal funds. There has to be a way to know that a) they owned that money on the secondary chain and b) they didn't spend it already. This is achieved by making the withdrawal request of the form "give me my money because ... this rollup says I legit have that money". Absent the rollup, or some equivalent scheme the Ethereum contract deciding whether or not to give them their money would need to look at the entire history of the relevant transactions from the secondary chain. That's hard-to-impossible. Then, having invented the rollup concept there are two subspecies of ways to tell if the withdrawal request is valid or fake : 1) by holding off on giving the money for a while during which anyone who is interested can call foul on the validity (and get a reward for doing so) or 2) by means of ZK-proofs, which are a real thing but may be impractical to use for various reasons so it's always a good idea to ask for running code whenever anyone invokes them.
This paper has some useful background for the problem space: https://arxiv.org/pdf/1904.06441.pdf
Holding the data you need yourself might work ok for your own personal ETH balance, assuming you have some way to prove the absence of any outgoing transfers. In fact, that's how one variant of Plasma works.
But with smart contracts, it gets a lot more complicated. It's way simpler if you can just know that any data you need will be on the network.
Maybe do some background reading?
For example: https://arxiv.org/abs/1906.07221