I may be missing something but I don't think this prevents rollbacks. Can a client prove that the server rolled back / lost data?

In the merkle tree committment example, I don't think it allows identifiying e.g. a fraudulent rollback just from looking at the hash.

If you wanted to identify a fraudulent rollback, I think you had to constantly replicate all transitions and recompute the on-chain merkle hash. If you found discrepancies in the on-chain hash and yours, it'd mean that either node ran out of synch for some unknown reason.

Then, if e.g. other nodes too replicated your state, you may be able to conclude that the wrong-hash node had a (byzantine) fault etc.

But I think that at least in the case of the Ethereum Plasma architecture, just committing a state aggregate in form of a hash wasn't enough because of some block withholding attack. From my understanding, hoytech's quadrable is just a chain committment. Similar to Plasma.

Modern rollup architectures end up storing all transition state in Ethereum calldata state. This way proving fraudulent validation is possible and things become conceptually simpler as you can rely on the strong guarantees of e.g. data availability of the PoW chain.

Only by storing (a hash of the) previous state client-side and comparing with the audit log for the current state, i believe.

Is that enough to prove a rollback happened? How do you validate that hash without the data?

You can think of it like a Git hash. If there was a rollback, the hash won’t be in the audit log (commit history in Git terms).

the hash is cryptographically signed by the server. So whatever state the database is, there must be a proof from the signed state up to the current one. Otherwise, the client application should handle this situation with care, as the database may be compromised.

Those signatures don’t prevent or expose or otherwise impede server-side rollbacks. They are thus immaterial to the question raised.

is out of the scope of immudb to prevent rollbacks if someone gain access to the filesystem. But even if that happen, immudb sdks will detect such situation when requesting a proof