BigchainDB – The lightweight blockchain framework [blockcentric #5]

With BigchainDB we see one of the first complete but simple blockchain frameworks. The project strives to make blockchain usable for a large number of developers and use cases without requiring special knowledge in cryptography and distributed systems.

According to benchmarks (whose scripts are also included in the repository), a simple BigchainDB network is able to accept and validate 800 transactions per second (cf. 3-10 tx/s at Bitcoin ). This high data throughput is due to the selected Big Data technologies for data persistence. Database systems from this environment use proven mechanisms based on Paxos algorithms to reach a consensus on the status of the data.
MongoDB or RethinkDB can be selected as the underlying database for a BigchainDB. Both options are document-oriented NoSQL databases, which can be scaled horizontally by replication and shaping. They are also schema-free, so that data can be stored in them without the need to globally define a uniform schema.
The throughput of both systems alone can generally be named with more than 80,000 write operations per second.

Transactions in BigchainDB

The framework makes uses of the consensus of the used database cluster. In order to validate transactions, it is also possible to implement your own validation mechanisms.
Two types of transactions are available in BigchainDB. CREATE transactions create an asset, i. e. a collection of data, and link it to at least one owner (its public key). In addition, all assets are “divisible” and can therefore be broken down into different proportions for different owners.
With TRANSFER transactions, complex instructions can be created that link existing assets (and their shares) to conditions of further transactions. In this way, assets and parts of the network can be easily moved between subscribers in the network.
As usual in a blockchain, there is no way to delete an asset or modify its properties.

For a transaction to be validly processed in the network, several conditions must be met .
Once the transaction has been received, the nodes check it for the correct structure. For example, CREATE transactions must contain their asset data while TRANSFER transactions reference the ID of an asset created. Both types also differ in the way they have to deal with inputs and outputs. Of course, each transaction must be signed and hashed before it is transmitted to the network.
If the structure of a transaction is valid, the validity of the contained data is checked. In short, the so-called “double spending” is prevented in this step. This prevents the transaction from repeatedly transferring the same asset or issuing assets that have already issued other transactions.
In addition, you can implement your own validation mechanisms that could check asset generation and transfers for correct functionality, for example. For example, whether realistic dimensions have been assigned for a car part or whether the color code of an automotive paint job exists.

For a deeper understanding of the idea as well as the technical and architectural details of the project, it is recommended to read the BigchainDB Whitepaper , which was maintained until June 2016.

Scenarios and operation of a blockchain

Since the consensus in a BigchainDB is not implemented via public mechanisms such as Proof of Work, Proof of Stake or similar , the technology is more suitable for private blockchains. This means that some parties will form a consortium in order to jointly execute their transactions among themselves without the need for an intermediary. To this end, each participant of this association adds some infrastructure on which at least one node of the blockchain solution is operated. Therefore, each transaction that occurs in the network must be validated and confirmed by a technical and organizational party of the consortium. This approach is very lightweight and does not require participants to be rewarded for their validations. The reward for the participants is, after all, to build up a trusting network without questionable and costly middlemen.

Due to these circumstances, the operation of a private blockchain based on BigchainDB is relatively easy. Each member of the consortium must take care of setting up and maintaining a database and BigchainDB cluster distributed in its infrastructure. In addition, there is of course the holding of a private key to sign his messages to the network. Each organization participating in the network can be identified and verified by in-built certificate management and registry.

One example would be a merger of a number of banks operating payment transactions and information exchange among themselves. Usually, these participants do not fully trust each other and must involve third parties to verify the transactions. However, if this network of banks were to form a consortium that would automate and cryptographically secure each transaction, a third instance would be superfluous and could therefore be excluded.
With a BigchainDB solution in place, each bank would operate its own cluster in its infrastructure that is linked to the network.

BigchainDB is therefore particularly suitable for private blockchain networks with high activity and data volume. This stack is also suitable for archiving solutions in which many data records have to be stored in a trustworthy way for many years. This can be used, for example, to make instances obsolete that call up high service, hardware and license fees for legally compliant data archiving.
Tracking steps in a supply chain can also cover the Bigchain transaction model excellently.

Getting started on the local machine or in IPDB

As a Managed BigchainDB Blockchain network, the Interplanetary Database (IPDB) is now also offered, with which one can interact as a registered organization.

Locally, Bigchain can either be installed directly on the host or operated with a docker. The docker variant is well suited for starting and testing.

In order to develop client applications against the started network, some official and community-maintained drivers are available. From the wide range of Python, JavaScript, Java, Ruby, Haskell and Go, every developer will probably find the right library.

We wish you a lot of fun trying it out.

Our article series “blockcentric” discusses Blockchain-related technology, projects, organization and business concerns. It contains knowledge and findings from our 20% time work, but also news from the area.

We are looking forward to your feedback on the column and exciting discussions about your use cases.

Previously published blockcentric-Posts