Understand and Build on BigchainDB (Series — Part 1)

The concept of blockchain has been made popular by the large scale adoption of peer to peer digital currencies, popularly called cryptocurrencies, with Bitcoin being the flag bearer of the crypto revolution. Association of economic interests with these decentralized payment systems has created much hype among general populace around the crypto. Amidst all the hype, the engineering community is working continuously towards developing techniques and software that can generalize the blockchain principles to handle use cases other than payment systems.

BigchainDB is one such blockchain based technology, that attempts to combine blockchain and traditional database concepts, to provide a solution that utilizes best of both worlds. At Quillhash technologies, we have utilized the BigchainDB into developing projects where we had to handle large amount of immutable data to be stored on the blockchain.

In these series of articles, we attempt to explain BigchainDB, first by explaining the technology and it’s specifics, performing installation and setting up of a development node, and finally moving on to developing a sample application showcasing BigchainDB in action. In this article we will cover the first part, and by the end of it we would have understood this technology and it’s essential concepts. So let’s get started!

What exactly is BigchainDB ?

Most blockchain solutions look for improving the speed and efficiency of transactions, as well as providing better support for representing digital assets and control over them. BigchainDB takes a different route and does not attempt to improve the blockchain protocol. Instead it utilizes existing blockchain consensus engine (Tendermint) to handle the P2P communication and immutability, and stores data in MongoDB, which makes it possible to apply powerful queries on the data. BigchainDB also provides native support for representing digital assets and specifying multiple ownership over them.

Tendermint is a consensus engine which utilises proof-of-stake consensus algorithm. It provides an infrastructure to conduct P2P communication and ensures immutability of data by using blockchain. It supports to add any application logic on top of it in a plug and play fashion. It is Byzantine Fault Tolerant, and can handle failure of 1/3rd of the total nodes. These properties apply to BigchainDB as well, since it is built on top of Tendermint. More information about Tendermint can be found on the official website.

Transaction structure and support for assets .

As mentioned previously, BigchainDB provides native support for representing assets and metadata about those assets. The representation of assets is evident by the transaction structure of the BigchainDB.

A basic structure of BigchainDB transaction is shown below:

“id”: id,
“version”: version,
“inputs”: inputs,
“outputs”: outputs,
“operation”: operation,
“asset”: asset,
“metadata”: metadata

Let’s break this down to understand various components of the BigchainDB transactions.

  1. Id: It is the unique ID that uniquely identifies the BigchainDB transaction.
  2. Version: It specifies the transaction validation rules that need to be applied to this transaction.
  3. Inputs: Transaction Inputs is an array of public keys that previously owned the asset before this transaction taking place.
  4. Outputs: Transaction outputs specify the public keys of the new owners of the asset managed by this transaction.
  5. Operation: BigchainDB supports only creation and transfer of the assets. Thus we have two kinds of transaction, ‘CREATE’ and ‘TRANSFER’. This field specifies the nature of this transaction.
  6. Asset: It can be any JSON object that is used to model digital assets. It represents the data that needs to be stored on the blockchain. Since it can be any JSON object, it offers great flexibility in implementing various use cases.
  7. Metadata: Metadata represents the mutable data about the assets. For example, if we were to model an automobile as an asset, the mutable details like the total distance run, colour, etc can be specified in metadata. As we will see further, we can creatively use metadata to perform complex and flexible queries on the data stored on BigchainDB.
Now that we have a basic understanding of the transaction structure, we can proceed to understand the usage of this via an example. Let’s consider a use case where we need to track an automobile using blockchain and see how we can represent this scenario on BigchainDB.

Let us assume that a car manufacturer want to add the information about cars produced on the BigchainDB network. The JSON representation for each car would look like follows:

“id”: “CAR_1”,
“model”: “Swift”,
“company”: “Maruti”,
“engine”: “1197cc”,
“colour”: “white”

The properties of a car that can change in future can be included inside the metadata. Metadata can help us to specify the state of the asset as well as for querying the data flexibly.

Let’s define metadata for the car asset:

“km_run”: 0,
“services_done”: 0,
“mileage”: “20kmpl”

To create this asset on the BigchainDB network, we need to issue a CREATE transaction.

Since the asset is being created, the transaction Inputs and Outputs will contain only the public keys of the manufacturer. Entities owing the asset are represented by a pair of ED25519 keys.

The public key is used for identifying the entity publically, while private key is used to sign transactions. Thus, the following transaction will represent the creation of car asset.

“condition”: {
“details”: {
{ “fulfillment”:”pGSAIJ35YuIoPvt6VEyJ3a3om2F6sUXF3uNzdKRI3FOwxDFngUB7_blDpPaTyZ9FP9oXzeoIoFlaSmWZe7K2hpoucSa2x8OVjbPm0PwstF450mQ9Mn5qGNMFNzgjmHdZ6NED3LoK”,

Although it might appear overwhelming at first, upon close inspection we can see how it confirms to the transaction format discussed earlier. Inputs and outputs are an array of conditions that uses ed25519-sha algorithm to enforce the ownership of the asset. Here the public key is same in both inputs and outputs, as this is a CREATE transaction which means that the creator will be the owner of this asset after this transaction.

Making these transactions programmatically is not a trivial process. For this BigchainDB SDK provides a driver for creating these transaction easily in various programming languages.

Now in an event, where a buyer buys the car from the manufacturer, we can issue a TRANSFER transaction to the car buyer that will represent the change of the ownership of this asset. The transaction outputs will now consist of the public key of the buyer and operation field will change to TRANSFER.

The assets created so far can not be changed, BigchainDB itself does not expose any functionality that may alter the asset. However we can alter the metadata if we need to represent some state change of the asset. In above example, we can alter the km_run and services_done if the buyer further sells this asset.

“km_run”: 1000,
“services_done”: 4,
“mileage”: “20kmpl”

In this article we discussed about what BigchainDB is, and how does it attempts to address the issues relating to the blockchain space. Instead of providing a brand new blockchain platform, it leverages existing solutions and build on top of it. We also discussed the transaction format and asset representation in BigchainDB. In subsequent articles, we will perform a local installation of BigchainDB node, and develop a small application that shows BigchainDB in action!

Thanks for reading. Hopefully this guide has been useful to you and will help you to understand the basics of BigchainDB and Also do check out our earlier blog posts.

You can find more information about QuillHash on our Website.

To be up to date with our work, Join Our Community :-

Telegram | Twitter | Facebook | LinkedIn