3 ms·

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

layer8 5y ago
Only by storing (a hash of the) previous state client-side and comparing with the audit log for the current state, i believe.
- thebean11 5y ago
  Is that enough to prove a rollback happened? How do you validate that hash without the data?
  - jeroiraz 5y ago
    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.
    - layer8 5y ago
      Those signatures don’t prevent or expose or otherwise impede server-side rollbacks. They are thus immaterial to the question raised.
      - jeroiraz 5y ago
        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
  - layer8 5y ago
    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).
timdaub 5y ago
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.

layer8 5y ago

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

thebean11 5y ago
Is that enough to prove a rollback happened? How do you validate that hash without the data?
- jeroiraz 5y ago
  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.
  - layer8 5y ago
    Those signatures don’t prevent or expose or otherwise impede server-side rollbacks. They are thus immaterial to the question raised.
    - jeroiraz 5y ago
      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
- layer8 5y ago
  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).

timdaub 5y ago

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.