This is an image about the release of the sanbox

Sandbox Release Information

Ricardo Pinto - February 21, 2020

The BlockBase team has recently released an online sandbox where anyone can test BlockBase’s main database querying functionalities without the need to run a full node. This release takes BlockBase one step closer to main net as a beta version, and showcases BlockBase’s functionalities to anyone who’s interested in using the platform.

In an interview with Matt Haynes on his Youtube channel Costa Crypto, we demonstrated the power of BlockBase tech using the sandbox. And the best part is that you can try it yourself too. So what we did was to show how a BlockBase database service can be easily used, and how similar it is to using traditional SQL. The example we used was to create a database that would store information related to the Corona virus patients, where some information would be encrypted and the rest would be publically available. This is an interesting scenario because it shows you how you can query encrypted and non-encrypted data with relative ease.

Building a secure and audit-able Coronavirus database using BlockBase on EOSIO

The best part is that all encrypted data on a BlockBase node has arrived there encrypted in the first place, and that all queries that retrieve that encrypted data don’t reveal information to the BlockBase node. You can try it for yourself here.

How does it work

There are two main types of users of the BlockBase platform, the service requesters and the service providers. This sandbox is mainly targeted to the former, the ones who will use BlockBase secure database services to store their data.

On this sandbox, anyone can test the BlockBase querying language, and experiment with managing BlockBase databases and data. This language was designed to be very similar to traditional SQL, to make it easy for users to switch from a traditional database to a BlockBase service without friction.

Behind the scenes, we’ve got a BlockBase node running a sidechain to EOS Jungle Test Net. So when a query is executed on the sandbox it is stored sequentially on the latest block of the sidechain, and is then executed on a traditional Postgres database. The BlockBase node also publishes the block header to our smart contract running on EOS Jungle Net to assure historic proof of operations. The sidechain thus constitutes proof of all operations executed and is backed up by a EOSIO chain, in this case the Jungle Test Net chain.

Whereas traditional databases usually have a log of operations that have been executed on the database, BlockBase has a log of operations to be executed on the database. Each sidechain stores that log, which is backed up by an EOSIO main chain. This assures historic proof of all operations, and anyone with the sidechain can execute all operations by their right order on a traditional database and end up with the up-to-date state of the database.

BlockBase SQL

The BlockBase SQL has a very interesting feature that took us months to research and to develop. It was also the main subject matter of a master thesis in computer science from one of our coworkers.

Since BlockBase is a distributed system for the storage of database operations that in many cases may have highly confidential data, we designed our SQL language to support client-side encryption and server-side querying without revealing confidential data. This means that any query sent to a BlockBase node, may have its sensitive data pre-encrypted before being sent to the node, so as to ensure nothing of importance is revealed to the node itself. Also, any query for data retrieval may be encrypted in such a way that the node will return the right data without knowing what was queried and what was retrieved.

This encryption method differs widely from what is done in traditional databases. In traditional databases, all data that arrives at the database server is unencrypted, and usually is also stored in an unencrypted fashion inside the database. Encryption may be activated on the database, but that is only applied to stored data. All data entering the database and leaving the database is still unencrypted. Furthermore, even if the database has encryption activated, it is still a centralized system where one person with enough authority has the keys to decrypt all data.

Published by Ricardo Schiller

Lead Architect