the entire state of the database gets captured by a hash value. By having light-weight clients (or auditors) keeping track of it is how tampering is detected in despite of where the database server is running
Keeping track of the "HEAD" hash on the clients is what consensus protocols achieve. You can also achieve it with trusted counters like the one SGX provides (depends on Intel ME so not exactly recommended, also most probably switched off in cloud environments). Alternative is an implementation of something like https://dl.acm.org/doi/10.5555/3241189.3241289.
You can of course say that it's the clients' responsibility to do this, but in practice they won't and they'll implicitly trust the server state.
Having said this, the project does look promising, we may end up using it in a confidential compute setting where clients can verify the server code running, and we'll add rollback protection on top
This is an impossible guarantee. Suppose the state that is sent to you from the server needs some time to get to you. meanwhile the state on the server could have changed. You don't even need a remote server to have this issue. Your thread (where you see the latest state) is put to sleep for a while (sheduler, os, ...) It wakes up. Is the state it observes still the latest? That's impossible to know. The only thing you can do is to refuse future updates if the state they were built upon is not the current state of the database.
With crypto protocols in general "guarantees" are always prefixed with "if the protocol completed successfully, then ...". For example authenticated DH + e2e encryption guarantees that you will send data to the intended participant only. But an attacker can still disrupt the network packets, so the true guarantee is "if the protocol completed successfully, then you have sent the data to the intended participant only".
Same thing here, you cannot of course guarantee the "latest state", if we want to go into the extreme, one could even argue that actually time doesn't work like that because of relativity/speed of light limitations:D. What you can guarantee is that if your commit protocol succeeded, then it updated the latest state at the time of consensus/monotonic counter update.
> That's what I meant.
> time doesn't work like that because of relativity/speed of light.
I would say that in practice what differentiates a blockchain from other applications of hash trees is a mechanism for consensus, not whether the blocks being formed into a trees conceptually represent time or not.
In a block chain it is easy to find history because the link to the history is included. Merkle trees require n-1 additional hashes.
A blockchain is a growing list of records,
called blocks, that are linked together using
cryptography. Each block contains a cryptographic
hash of the previous block, a timestamp, and
transaction data (generally represented as a
Merkle tree).
Merkle trees are used in various ways within cryptography in general and cryptocurrencies specifically, but blockchains and Merkle trees are distinct data structures with different uses. The colloquial use of "blockchain" has perhaps made the word somewhat ambiguous in some contexts but not in the context of cryptographic data structures, and Merkle trees are in fact formally defined.
Cool, so let's say we're using this to track financial transactions.
Server A has an Immudb at some state x and server B has an Immudb at some state y. Which one is correct, how do I decide?