|
|
|
|
|
by inkyoto
1299 days ago
|
|
Publishing a commit ID in a printed newspaper does not prevent the data loss nor the tampering with the data. Destructive operations in a ledger database are simply not available at the API/interface contract level. A delete operation in a ledger database is non-destructive and does not delete the data but rather creates a new «deleted» revision in the history table. The deleted revision is always available, and it can be «undeleted» as there is nothing special about the deleted revision: it is merely another document revision with the N+1 revision number. The document can be deleted (revision N+1), undeleted (revision N+2), updated multiple times (revision N + M1, N + M2 …), deleted again (revision N + M1 + M2 + P), yet the entire history of all past and current revision(s) is always available, and it can be retrieved/inspected; even after the table is dropped, it can still be undropped without incurring a data loss – all of that is the append-only ledger guarantee. The only destructive operation that is practically possible is tearing down the entire ledger at the infrastructure level, which is irreversible and will result in a full data loss. However it can be mitigated (to a very large extent) through segregating and locking down access to the infrastructure. git does not provide the immutability guarantee as it allows destructive operations, therefore it does not qualify for a ledger proper. A commit history can be rewritten or deleted resulting in a data loss. Published commit ID's are of no use if the data has been tampered with later and valuable revisions have been deleted in perpetuity. |
|