jeroiraz

every change is made by appending a new transaction. immutability is intrinsic to transaction processing, it can not be disabled. Once a transaction (it may include several entries) is committed, the database state change accordingly and no change into already committed transaction may be done without clients being able to notice it. Note for this to be ensured, clients of immudb should keep track of the latest verified state. official sdks handle this for end-applications

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

each transaction may have several entries, in order to gain more performance, it's better to include several entries per transaction. But all the entries in the same transaction are atomically stored.

submitting several transactions at the same time is also possible and convenient, processing is concurrently done until the last step which requires a strict serialization.

benchmarking is a huge topic and we'd love to have contributions on this. It may refer to using embedded immudb, as a stand-alone server, kv, sql, etc....

sure, schema changes are already in the roadmap

first of all, thanks for your feedback and discussion :)

if entering an email for downloading the paper is a concern, we'll consider it.

immudb should be used as a traditional database (log, key-value or even a relational store - with limitations of course), so it's up to your deployment to whom you give user credentials with read/write permissions. The key difference is the state being captured by a single hash value.

Given the hash value denoting the entire state can be signed and exported. It's out of control of the server how many copies or when a validation is going to be made. Currently, official SDKs are storing the latest validated hash in a local file, but it's perfectly possible to store the hash in a remote storage, other database, etc. This will ensure data is only added but never changed once written, please note with never changed I mean it's subject to detection when a proof is requested.

immudb does not pretend to provide a complete security solution, but a key component when you deal with sensitive data.

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.

the hash tree, transactions headers, payloads and index are all independently stored. So it will be possible to physically delete payloads and still be able to build all the proofs (but not being able to provide the actual values).

Truncating transaction headers should be possible, but each physical deletion will be associated to a real lost of data, so proof generation may be affected on deleted data.

I'll find detailed information in the research paper: https://immudb.io/

Basically a hash value denotes the entire state of the database (including the entire history). This hash may be cryptographically signed and exported from the server. immudb SDKs keeps track of the last verified state, each time a new one is received, it's cryptographically validated.

Whenever a particular entry or transaction is verified, the latest validated hash also used. If the entry was tampered in, hashes won't match.

This is a very interesting point. Rollbacks are protected by consistency proofs and with inclusion proofs it's possible to detect such situation but it may require scanning over the transactions. immudb does not only provide access by key or key prefixes but it's also possible to fetch a particular tx by its unique identifier or scan over them.

For sure it's not the optimal solution, some ideas to cover this scenario were discussed but not yet fully defined.

several solutions may be possible. Simplest would be to delete payloads associated to entries. While the actual data won't be there, it will still be possible to build cryptographic proofs. Then it's possible to prune by physical deleting entire transaction data, which may or not affect proof generation. However, tampering will still be subject to detection.

currently it's logical deletion and time-based expiration. Actual values associated to expired entries are not fetched. Physical deletion is already in the roadmap.

logical deletion is in place, physical deletion is already on the roadmap

The difference is that client applications does not need to trust proper "append-only" permissions were enforced on server side but they will be have the chance to detect any tampering while in the former approach, it won't be noticeable

temporal features provided in immudb allows query (and subquery) resolution based on older states of the database. So for instance, it can be thought as retrieving the documents on its current state in a given time range. Querying the history of changes of a given key or document is slightly different and it's also covered with history operation in immudb.

immudb can hold the actual data. An equivalent approach using an existent database without this features will involve creating a cryptographic data structure which captures not only individual content but the entire history of changes. Also having the functionality to construct and verify the cryptographic proofs to validate read data

immudb already included history support for key-value entries in previous releases. But since v1.0.0, immudb provides query resolution at a given point, using the current data on that specific moment but also being able to combine data at different points in time on the same query. Is not clear to me if it's something that can be achieved with “SELECT * FROM history”, it requires up most one result per different entry (the most recent one)

immudb is not meant for public decentralized networks, although it might be possible to use embedded immudb to build a public blockchain... but that's a different story. immudb server is tailored to provide a database where any tampering will be subject to detection by any single client application consuming its data.

there are many differences (as immudb contributor): - immudb can be used embedded or client-server database while qldb is a aws service - immudb behaves as a key-value store but also provides SQL support while qldb provides a document-like data model with PartiQL language - immudb provides time travel features - immudb it's faster, built-in with a mode of operation designed for fast writes which works with eventual indexing.

Finally but super important, immudb can be deployed anywhere and it's open source!

the order of changes is not subject to consensus, but clients have the tools to ensure no history rewrite happened

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

In some way, it’s basically that but on steroids… Note that if the signature includes the previous one then you are protecting the history of changes. However, this simple approach may not scale when dealing with considerable amount of data, proving some older entry was not tampered may require to validate all signatures from that point up to the latest one. immudb employs hash trees to optimise these proofs.