Decentralized Security From a Centralized Database

Blockchain technology is great don't get me wrong but does traditional peer-to-peer blockchain fit most business cases? Most businesses would not benefit from publicly distributed data and private blockchain services are very expensive.

This begs the question... How can I get similar security features from my centralized database?

Blockpoint is able to prove the authenticity of records by exporting cryptographic digests: a unique, mathematical representation of the data, which allows external sources to validate data without having access to it. In this article we will examine the lifecycle of this validation technique.

Exporting Digests

The EXPORT DIGEST command reads data digests from the specified database object.

Syntax

READ DIGEST { <datbase_object> }

database_object ::=  
{   
   database_name.blockchain_name   
   | datbase_name    
}  

Arguments

database_name
The target database to read the digests.

blockchain_name
The target blockchain to read the digests from.

Remarks

• The READ DIGEST command reads page hashes, timestamps, and previous hashes and outputs the data in query format. The command returns a response with the following
  columns:

  • blockchain_id: The internal id of the blockchain.
  • page_id: The page id of the blockchain.
  • timestamp: The time that the page was sealed at.
  • current_hash: The hash of that page as a UINT64.
  • previous_hash: The hash of the previous page; stored as 0 for the first page in the blockchain.

• Only blockchain pages in the archive are read. Blockchain pages are pushed to the archive when the page is full and no currently open transaction have written to that page. This ensures a ROLLBACK can't change archived data, resealing the page, and changing the hash.

• Running a CHECK VALIDITY command before reading a digest ensures that digest is valid within the database and values haven't been illicitly changed.

A. Reading the digest from a blockchain

The following example reads the digest from the pricing blockchain.

READ DIGEST financial.pricing;

Output

The output returned reads the two archived pages in pricing, if there were no archived pages, no records would be returned. Notice that the previous hash of the first page is 0, because there is no previous page.

BLOCKCHAIN_ID [UINT16]  PAGE_ID [UINT64]    TIMESTAMP [TIMESTAMP]   CURRENT_HASH [UINT64]   PREVIOUS_HASH [UINT64]
19                      0              2021-05-24 16:46:05.991142800    6006725463818420546  0
19                      1              2021-05-24 16:46:05.992201900    3175351712536806224  6006725463818420546

Distributing a Digest

Distributing a digest is really up to an organizations digression. It safer to distribute digest files over multiple technologies. This can be through email and other messaging or file sharing services.

Validating a Digest

VALIDATE DIGEST checks the current digest against the provided.

Syntax

VALIDTATE DIGEST { <datbase_object> } PATH "file_path";

database_object ::=  
{   
   database_name.blockchain_name   
   | datbase_name    
}  

Arguments

database_name
The target database to be checked against the provided digest.

blockchain_name
The target blockchain to be checked against the provided digest.

PATH "file_path
The filepath to the provided digests. The provided digests must be in CSV format and follow the column order produced by
the READ DIGEST command.

Remarks

• Only blockchain pages in the archive are validated. Blockchain pages are pushed to the archive when the page is full and no currently open transaction have written to that page.

• If data was added to the blockchain archive after the digest was exported. New data won't be validated.

• Running a CHECK VALIDITY command before validating a digest ensures that digest is valid within the database and values haven't been illicitly changed.

• A database or blockchain digest can be used to validate a blockchain.

• Only a database digest can be used to validate a database.

• DISCONNECTED blockchains are still validated as they can be reconnected to the database.

A. Validating a blockchain digest

The following example validates the digest of the pricing blockchain. The provided digest can be a blockchain or database digest.

VALIDATE DIGEST financial.pricing PATH "digests/may_5_digest.csv";

Output

If valid, the output provides the time at which the digest is valid given the last archived page's sealed time of the uploaded digest.

Database object financial_1.pricing is valid against the stored digests for archived pages before 2021-05-24 16:46:05.992201900

B. Validating a database digest

The following example reads all blockchain digests in the entire database.

VALIDATE DIGEST financial PATH "digests/may_5_digest.csv";

C. Invalid digest

The following example illustrates an invalid digest being compared to a valid database.

VALIDATE DIGEST financial PATH "digests/may_5_bad_digest.csv";

Output

An invalid digest returns specifics on the failed data. In this case, the timestamp on the first page of the system blockchain syscolumns has been modified in either the database or the imported digest.

Blockchain syscolumns: timestamp mismatch when verifying digest page 0, digest timestamp 2021-05-21 19:14:14.9512269 +0000 UTC not equal to system timestamp 2021-05-24 16:46:05.9175726 +0000 UTC

Conclusion

The digest lifecycle described above allows outside sources to validate that data within a centralized database hasn't been illicitly changed. Nifty!