Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Blockchain Database: Benefits and Details

DZone's Guide to

Blockchain Database: Benefits and Details

The method of how you establish your intelligent contracts in the blockchain database should be motivated by the approach to query your data.

· Database Zone ·
Free Resource

MariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.

A lot has been documented about blockchain database merits. In this article, we will have a closer look at the blockchain as a database: pros, cons, and some specific details you can expect if you decide to use database blockchain.

Private Blockchain

A private blockchain is comprised of an individual, practically closed network of nodes (blockchain participants). All nodes have a copy of the blockchain, which is a ledger that chronicles all the transactions that occurred within the network.

Blockchain Benefits

Blockchain’s main advantage is that it provides transaction history (AKA a transaction log), which is used by all participants through secured cryptographic layers. This data storage is immutable.

Trust Levels

Level 1: ID of Participant

A lot has been said about the lack of trust in the model enabled by the public blockchain. This is a real innovation. That said, with regard to private blockchains, those involved are all identified since they must be on board and invited into the network of private blockchains. Therefore, being mindful of who is participating provides a trust level and eliminates the mining requirement: work activity proof that makes it troublesome for shady participants to dominate and regulate the blockchain network.

Level 2: Integrity of Transactions

The integrity of blockchain transactions is accomplished by the locked-down history shown in the ledger. An individual participant can’t change or "rewrite" the history after it’s been validated and locked down in the blockchain (unless 51% of the network is regulated by them).

This additional trust level adds an extra value of the blockchain than conventional databases offer. The data is shared and encrypted, but the transaction log is secured to the point where it can’t be changed by any single participant. It can, however, be assessed by a participant at any time.

Intelligent Contracts

We’ve been testing out Ethereum. We enjoy using it because the intelligent contract capability is much richer than other blockchain implementations out there. Why is this so essential?

  1. You can establish data structures inside the intelligent contracts, practically covering the blockchain into a blockchain database.
  2. You can create a permissions capability into intelligent contracts — practically embedding your security model within the blockchain so that it can’t be changed unless approved by a consensus.
  3. You can establish a workflow for several participants.

Blockchain Database

Let’s say that the benefits outlined in this article are an ideal fit for a specific use case. We can now store our data within the blockchain database as if it were an ordinary database. This would permit us to create and incorporate applications over the blockchain database.

Vertical vs. Horizontal Blockchain Scale

Blockchains were developed to be horizontally scaled. This is done to raise a number of instances operating the blockchain. That said, all instances hold a full copy of the data, and the processing is repeated. This is ideal for security and integrity, but not great if you must process and store a substantial amount of data. You’ll require all blockchain nodes to be scaled vertically. In other words, all nodes must have the ability to store and process massive data.

Nodes for Heavy Blockchains

How is an individual node scaled? Through a pair of dimensions:

  1. Processing
  2. Storage

A blockchain database node like Ethereum operates as an individual process. There might be some internal multithreading, but it’s a single process and likely can’t do a lot in parallel because of the block and transaction management’s sequential nature. With that, let’s say that processing can’t truly be scaled.

This brings us to data storage. At the moment, to store data, blockchains use local files. They might potentially be moved to a data store that is more scalable. This isn’t specifically vertical scaling because we’re discussing an individual node and having a scaled data store installed under it.

Blockchain Data Querying

Those who have worked with blockchains will understand that inserting transactions/data into a blockchain database is not fast. You must be patient while the block confirms your transaction. On Ethereum, this takes mere seconds.

It is faster to obtain data from an intelligent contract on a blockchain. You are simply obtaining data from the blockchain’s local copy instance — no involvement or "consensus" of other blockchain nodes is necessary.

Blockchain Data Indexing

The primary concern with all databases is the performance of queries. This is solved with predefined indexes in relational databases. NoSQL database indexes are also formed. In Hadoop and similar large data analytics platforms, a large amount of unstructured/structured data are scanned in parallel. However, it is still not fast, regardless of modern incarnations like Apache Spark.

The method of how you establish your intelligent contracts in the blockchain database should be motivated by the approach to query your data.

Separate Smart Contracts

If data is being stored in smart contracts, you may have a unique instance of the intelligent contract for every data row. This method appears to be easy and clean. The downside is that each time a new smart contract instance is produced, for all data rows, you’ll obtain a key. This key lets you access that precise, intelligent contract instance (and data) down the road.

The key must be stored someplace — perhaps in another contract or an external database — and won’t lend itself to querying.

Container Contracts

A data map or array is stored in a container contract. Within a single contract, you could potentially store the equivalent of a table. The benefit of this method is that the data can be stored in a map. A key can be used to query your data down the road. You can produce multiple keys to let you query the data with unique parameters.

Index Contracts

Another method is to mix the initial pair of strategies. Store each "data entity" in separate contracts, but use another contract to reference them. This other contract can hold a map structure or array, letting the items of data be searched for, while also maintaining the keys to each data entity contract.

This third option lets all the querying and data happen inside the blockchain database while letting separate contracts hold data entities.

MariaDB AX is an open source database for modern analytics: distributed, columnar and easy to use.

Topics:
blockchain ,database ,data querying ,data security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}