jeroiraz

5 ms·

1.
by jeroiraz 5y ago
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
2.
by 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
3.
by jeroiraz 5y ago
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
4.
by jeroiraz 5y ago
sure, schema changes are already in the roadmap
5.
by jeroiraz 5y ago
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
6.
by 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 datab
7.
by jeroiraz 5y ago
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). Truncati
8.
by jeroiraz 5y ago
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 exp
9.
by jeroiraz 5y ago
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
10.
by jeroiraz 5y ago
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
11.
by jeroiraz 5y ago
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.
12.
by jeroiraz 5y ago
logical deletion is in place, physical deletion is already on the roadmap
13.
by jeroiraz 5y ago
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 b
14.
by jeroiraz 5y ago
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 histo
15.
by jeroiraz 5y ago
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
16.
by jeroiraz 5y ago
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 d
17.
by jeroiraz 5y ago
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 tamperi
18.
by jeroiraz 5y ago
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-lik
19.
by jeroiraz 5y ago
the order of changes is not subject to consensus, but clients have the tools to ensure no history rewrite happened
20.
by jeroiraz 5y ago
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
21.
by jeroiraz 5y ago
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