BIGCHAINDB

BigchainDB is a versatile blockchain database. It’s intended to blend the best of two universes: the traditional distributed database world and the conventional blockchain world [8].

BigchainDB begins with a conventional distributed database (at first RethinkDB), which has the qualities of:

• • scale (throughput, capacity, low latency)
• • queryability

From that, we engineered in blockchain characteristics:

• • decentralized (no single entity owns or controls it)
• • immutable (tamper-resistance)
• • assets (owns the asset if they owns the private key, i.e., blockchain-style permissioning)

KEY CONCEPTS OF BIGCHAINDB

• • Transaction model
• • Visualization of transaction model
• • Asset
• • Input
• • Output
• • Metadata
• • Transaction ID

Transaction Model

The main thing to comprehend about BigchainDB is the way we structure our information. Traditional SQL databases structure data in tables. NoSQL databases use other formats to structure data such as JSON and key-values, as well as tables. At BigchainDB, we structure data as assets. We believe anything can be represented as an asset. An asset can characterize any physical or digital object that you can think of like a car, a data set or an intellectual property right [9].

These advantages can be enlisted on BigchainDB in two different ways. (1) By users in CREATE transactions. (2) Updated (or refreshed) to different clients in TRANSFER exchanges. Traditionally, people design applications focusing on business processes (e.g., apps for booking and processing client orders, apps for tracking deliver)' of products, etc.). At BigchainDB, we don’t concentrate on procedures rather on resources (e.g., a customer request can be a benefit that is then followed over its whole lifecycle). This switch in perspective from a process-centric towards an asset-centric view influences much of how we build applications.

Visualization of Transaction Model

This infographic will help to understand what CREATE and TRANSFER exchanges are and what the individual segments of a transaction insists (inputs, yields, resources, metadata and so forth). Let’s see a basic genuine model, for example, Martina carefully enrolls her bike on BigchainDB in a CREATE exchange. After some time, she moves this bike to Stefan in a transaction (Figure 3.5) [9].

Asset

An asset constitutes any physical or computerized object. It can be a physical object like a car or a house. Or it can be a digital object like a customer order or an air mile. An asset can have one or multiple owners, but it can also be its own owner. Think of an autonomous car or an Internet of Things (IoT) sensor that does transactions

FIGURE 3.5 Shows the virtualization of the transaction model.

automatically [10]. More data about the asset information model can be found in our asset model. An asset always contains data that is immutable. In our example, the color and the registration number of a bicycle is immutable data. Depending on the context, an asset can represent many different things.

An asset as a claim: An asset can represent an ownership claim for a particular object, for example, it represents a claim that User ABC owns the bicycle with the number XYZ. This can be valid for any type of ownership.

An asset as a token: An asset can also represent a token. BigchainDB supports divisible assets. This means, multiple assets can be issued and attributed to one overarching asset. This can for example be intriguing for token dispatches.

An asset as a versioned document: An asset can likewise be a formed record with the adaptation expressed in the metadata field. The adaptation of this report can be refreshed on a nonstop premise. Each time there is another adaptation of the archive, it could be reflected in the metadata.

An asset as a period arrangement: An asset can likewise speak to a period arrangement of information. For example, an IoT sensor records its own information. The IoT sensor is the asset and each accommodation of its information (e.g., temperature) is spoken to as an update in the metadata with the most recent temperature that the IoT sensor estimated.

An asset as a state machine: An asset can also be a state machine where the state transition is represented in the metadata. Each time the machine changes its state, a transaction is triggered to update the metadata to the new state (possibility to listen to it with the WebSocket).

An asset as a permission: Assets could also be roles (role-based access control or RBAC), users, and messages (and anything which can have multiple instances in a scenario—vehicles, reports, and so on). As you can see, there are almost no limits with respect to what an asset can represent.