Comment by timdaub | Hacker News Reader

Comment by timdaub | Hacker News Reader

I went on their website and tried to understand how immutability is enforced but I couldn't find anything.

I'm sceptical, but particularly because they make a deliberate comparison to blockchain that I doubt they'll be able to deliver.

The PoW immutability of e.g. BTC and ETH is strong as it yields the following guarantees for stored data:

- Immutability of the BTC blockchain is protected through all cummulative work that has happened on a specific branch of the chain. Even if someone replayed BTC, it'd take millenias to recompute the work on an average machine

- The immutability isn't enforced on a file level, as I suspect it is with immudb. Immutability is enforced through the network that has additionally shown to have conservative political views too. You can go, sync a BTC node and change the underlying level db. Still that won't change the network state. Immutability on a single system is physically impossible if e.g you consider deleting the file as mutation.

- immudb says "it's immutable like a blockchain but less complicated", but Bitcoin isn't more complicated than some sophisticated enterprise db solution.

- I think immudb should be maximally upfront what they mean by immutability: It seems they want to communicate that they're doing event sourcing - that's different from immutability

Finally there's a rather esotheric argument. If you run an immutable database as an organizatiom where one individual node cannot alter the network state but you have (in)direct control over all nodes: Isn't it always mutable as you could e.g. choose to swap out consensus?

So from a philosophical perspective, then immutability can truly only occur if mutability is out of an individual's control.

Why do I have the authority to say this? Because I too have once worked for a database with blockchain characteristics called https://www.bigchaindb.com

Edit: The best solution that also has a theoretically unlimited throughput is this toy project: https://github.com/hoytech/quadrable

Conceptually, it computes a merkle tree over all data and regularly commits to Ethereum. Through this commitment the data may still change locally: But then at least would be provably tampered. So I guess for databases, the artibute we can really implement is "tamper-proof".

I’d say the attribute is "tamper-proof history", not "tamper-proof data (current content)".

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

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

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.

The big question is if someone gets on your DB server and wants to change a record how does the software prevent them from altering a record and then recomputing the remainder of the chain?

That’s presumably out of scope. The scope of the guarantees is restricted to the operations made available by the database API. Just like the ACID guarantees of regular relational databases are.

Which makes any blockchain comparison extremely stupid since it doesn't even attempt to solve the same threat model..

> but Bitcoin isn't more complicated than some sophisticated enterprise db solution.

It is, however, hundreds of thousands times slower as a database.

At least for money transmission use cases that's a rather weak argument considering that my local bank calls me in person to confirm transactions above 2k EUR.

Reply on news.ycombinator.com