Converting RDBMS Into Blockchain

Converting RDBMS Into Blockchain

So you might have already known at least a little bit about blockchain. It is a distributed database where nodes can synchronise all the data easily. The information is grouped into numbered blocks according to a consistent timestamping system. I have seen the beauty of this synchronisation capability and wondering if we can port this into any RDBMS. I have several experiences of transferring data between databases and in fact, I was unsure about the integrity of the information. Since it relies on services in which there might not be any tools for the system to check for its consistency, then maybe we can add something to these regular databases to be synchronised easily.

I got this idea last night when thinking whether we can add something into an RDBMS database to resemble a blockchain system. Since they both are forms of database, then I don’t think it is an impossible task to do.

The first thing to do is to map a database structure into blockchain. I believe we can map a table into a blockchain. So, in a database, we have several blockchains. We might need a master header to tangle all these blockchains altogether, but I don’t think it is necessary (or at least I have found any useful functions). We now have our blockchain. The next thing is the primary key. I think we can map each primary key into an account or similar to address. Well, we do not really need to sign the transactions at the moment. But if we do really need to do this, we can use the deterministic function of an elliptic curve cryptography. So, we only need to pick a pair of parent keys consisting of a public key and a private key, and the child keys can be derived by using the parent keys and the indexes (which are the primary keys of the table).

Since we know that in a blockchain everything is recorded and never be deleted, we assume that the delete and update functions in CRUD functions (create, retrieve, update, delete) of the database should be disabled. Instead, we will utilise the create function and use versioning of each data. We assume that each time the data cannot be updated concurrently, and therefore in a given time, we can always see which one is the latest version of the data.

Constructing transaction data from the table is pretty straightforward. We can utilise a JSON format to ease the transaction data creation. We then hash this data format and put it into Merkle Tree structure. Then we can hash the previous block header hash and Merkle root hash into a current block hash. We simply create a new table to put our blockchain data. This blockchain table can be utilised to store all blockchains within a database.

One of the concerning matter is how to determine the block creation. We should really investigate the nature of the database usage; whether it is a busy database or just a rarely used database. The epoch can be picked by time or by the number of records. If the epoch cannot be satisfied in a given time, we can use an approach from Bitcoin-NG by creating microblocks which are temporary blocks before the real blocks are created.

Since this kind of database will be a trusted one (we only focus on how to synchronise this database within different nodes), we will not be taking care of the consensus in a specific way. We might also want to add the Hashcash feature into our database to avoid our database to be flooded by transactions. But again, this is not really necessary.

The next step to do is, of course, to construct an application layer for the nodes to communicate in order to synchronise data between them. RPC is a common way to do that, but any kind of communication should be sufficient as long as we can ensure the data integrity.

This approach is really useful since we do not need to migrate our existing database into a blockchain product, because such action might be costly, in particular, if we have a massive amount of data to be migrated. I have not yet read any article discussing this idea, which is pretty interesting to bring this into my next supervision meeting. Who knows we can publish an academic paper or even write a tool to convert any database into blockchain. It should be awesome!

What do you think? Write your comments.

Leave a Reply

Your email address will not be published. Required fields are marked *