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…
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
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…