In this article I would like to expand on why BlockBase was designed the way it is, and why it’s important to know about it. The BlockBase concept started with security first. We wanted to develop something that enabled the storage of databases on blockchain, and that also followed the best security practices available.
Security is a hard problem to solve, and it isn’t restricted to one area only, but instead traverses many different areas like infrastructure security, data security, software security, identity control and access, network and communications and organizational security. Nonetheless, most of it is related to the secure storage of data and its secure transmission.
At the heart of all of this, lies the triad of computer security: Confidentiality, Integrity, and Availability. You want your data private, you want to make sure it wasn’t covertly changed, and you want to have it available. Traditional systems fail horribly at all three, and that’s why we have so many security hacks. The reason they fail is because traditional systems are insecure at their core, and that’s why they have so many layers of security stacked on top of each other. Each one of those is trying to patch a leaky infrastructure. Unfortunately, it has been proven time and time again that it doesn’t work.
Traditional systems usually store data in an unencrypted fashion and have centralized mechanisms to manage encryption and access. They also fail with integrity, also due to its centralization. Records may be changed or deleted, and the same goes for backups and logs. And they fail at being available too, centralized systems may be brought down by the same people that put them up in the first place.
BlockBase was designed from the ground up to comply with the security triad. It’s a distributed and scalable system, that provides integrity to the data it stores with blockchain and has all its data fully encrypted by default.
So what is BlockBase? BlockBase is a distributed network of nodes for securely storing databases on blockchain. Anyone can download the BlockBase node code from the github repo here and run a node.
How does one use BlockBase? A BlockBase node can be run to provide the on blockchain database storage services, or to request/use those services, or to do both simultaneously. This means that anyone can participate in the provisioning of the system. You can think of it as a distributed cloud service for database storage services. Also, anyone can use those services too. Interacting with a BlockBase node as a service requester, is very similar to administering a cloud database service. You can request the size of the database, the security, and the performance too. That will have a price attached to it, that you’ll have to pay in BBT to the service providers.
How does BlockBase solve the security triad?
Confidentiality
All data stored on BlockBase may be completely encrypted by default. Since we’re talking about databases, all operations related to database administration and database data management may be encrypted. Technically speaking, this means that database names, table names, column names, and record data may all be completely encrypted.
Encrypting data is important by itself for security, but it’s even more important when storing data on a blockchain. The reason for that is that since the data will be stored by multiple providers from around the world, you probably want that data encrypted in the first place.
What also should be considered here is that even though encryption may be opted out, it’s on by default. This is very different from traditional database systems. On those, encrypted may be opted out, which is a bad practice at least in my point of view. Furthermore, data is encrypted before it even enters the system, while with traditional databases the data is encrypted after it entered the database. That means it had to traverse through other systems in a fully unencrypted format before reaching the database, and who knows what may lie inside those.
To make security flexible, BlockBase has tree like structure for key management. There’s a master key at the database level from which you can derive each table key, and where from those you can derive each column key. This means that only the key to one column may be made accessible to someone if only that column was important for them to have access to.
Integrity
BlockBase uses the blockchain mechanism to provide integrity to the data that gets stored there. Like any other blockchain, the history of the data can’t be changed. The same happens with BlockBase. Since what you’re storing on BlockBase is all database related operations, you’re basically building a log of operations that is stored on a blockchain. With this log, you can run all operations there on a traditional database and derive the current state of the databases stored there. So, for example, if you deleted a record, that delete operation would be appended to the blockchain, like in a log. But then that delete operation, when executed on a traditional database, would in fact delete the record it was intended to delete.
Integrity is fundamental to any database. Unfortunately, traditional database systems don’t provide that. If you delete a record, that record is gone forever. You can add configuration on top of that to try to have integrity, but again, it’s just patches. You can basically log operations or backup the data, but those can both be disabled or also destroyed. The integrity provided by a blockchain is a game changer, because it’s built in. That is the main difference. You can’t change the past, it’s impossible.
We can even state that blockchain solved the integrity part of the security triad. But most blockchains don’t have any encryption mechanisms built in, and also struggle with availability because they can’t scale well. Here’s where BlockBase shines.
Availability
BlockBase was designed to be more than a blockchain. It’s multiple sidechains to the EOS main chain. This means you have horizontal scalability, unlike with one blockchain only. The BlockBase network can store multiple sidechains simultaneously. The cool part of it is that the ones requesting the sidechain can specify how many nodes they want producing the sidechain and can even reserve production seats for specific nodes. So, at any given instance, different subsets of nodes will be producing different sidechains. The more computing power a node has, the more sidechains it can provide simultaneously.
There’s another aspect to it though, that is the stake required by the requesters from the providers. Since a service requester will have his databases provided by anyone from around the world, he can request from the providers a specific minimum amount of BBT to be staked as collateral in order to produce the sidechain, that the provider will lose if he fails to provide the sidechain accordingly. Furthermore, if the number of providers exceed the number of providers requested for the sidechain, a random selection process is triggered that will benefit the providers that have the highest stake. This incentivizes providers to have skin in the game.
With this type of structure, anyone can request a sidechain that is tailored for their needs. If they want a small, mostly private, slow, and cheap sidechain, they can have it. If they want a large, public and fast sidechain they can have it too. This is the beauty of sidechains. One doesn’t need to conform to the costs and features of a main chain, you just tailor a sidechain to your needs. And that seems to be the future for blockchains.
Published by Ricardo Schiller Lead Architect of BlockBase.Network
