"The next exciting change-the database for Blockchain"
Key concepts of BigchainDB
Note: A blockchain is a type of database, but not all databases are blockchains. Blockchains can store transactional data in a digital ledger. Only read and create operations are permitted. Databases can store different types of data and support update and delete transactions. Every block in a blockchain needs to be signed and verified, which makes it slower than database types.
Which database does Bitcoin use?
Different blockchain implementations can use various database engines to store the blockchain itself. Bitcoin uses a mix of LevelDB and BerkerlyDB. High-performance blockchain databases such as BigchainDB and ProvenDB are using MongoDB. MongoDB is a great choice to store blockchain data because of its flexible data schema and rich query language.
Why did BigchainDB team chose MongoDB?
BigchainDB is one of the first blockchain databases developed for general purposes. It offers powerful query functionalities and high performance, along with all the benefits of a classic blockchain to create decentralized and immutable data storage.
The decision to choose MongoDB was based on many factors as follows:
1. Popularity: MongoDB is the most popular document database and has been on developer’s top wanted database for years.
2. Flexibility: The data is stored in Binary JSON (BSON) format, allowing for structured or unstructured data. Unlike relational databases, MongoDB offers developers a flexible schema model.
3. Performance: MongoDB is ready for vast quantities of data and was built with scalability in mind.
4. Ease of deployment: MongoDB can be easily deployed locally on each node in a system or directly in the cloud with MongoDB Atlas.
While traditional SQL database structure data in tables, NoSQL databases use other formats to structure data such as JSON and key-values, as well as tables. With BigchainDB, data are structured as assets. BigchainDB represent anything 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.
The assets can be registered on BigchainDB in two ways viz., a) By users in CREATE transaction; and b) Transferred (or updated) to other users in TRANSFER transactions. While traditional way design applications focusing on business processes (such as apps for booking & processing client orders, apps for tracking delivery of products etc), BigchainDB does not focus on processes but rather on assets (such as a client order can be an asset that is then tracked across its entire lifecyle). Thus, BigchainDB is a switch from a process-centric to an asset-centric view, and is how applications in BigchainDB are built.
Let’s understand the transaction model of BigchainDB using the following analogy.
Let’s use a real-life example: Martina digitally registers a car on BigchainDB in a CREATE transaction. After some time, she transfers this bicycle to Stefan in a TRANSFER transaction.
The concept of inputs, outputs, etc. are discussed more in the following snapshot.
ASSET
An asset can represent any physical or digital object. It can be a physical object like a car or a house. Or it can be 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. In the example above, the color and the registration number of a bicycle is immutable. Thus, asset contains data that is immutable.
Depending on
the context, an asset can represent many different things.
a. An asset as a claim-An asset can represent an ownership claim for a particular object, e.g., it represents a claim that User ABC owns the bicycle with the number XYZ.
b. 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.
c. An asset as a versioned document-An asset can also be a versioned document with the version stated in the metadata field. The version of this document can be updated on a continuous basis. Every time there is a new version of the document, it could be reflected in the metadata.
d. An asset as a time series-An asset can also represent a time series of data. For instance, an IoT sensor records its own data (i.e., the sensor is the asset and every submission of its data (e.g., temperature) is represented as an update in the metadata with the latest temperature that the sensor measures.
e. An asset as a state machine-An asset can also be a state machine where the state transition is represent3ed in the metadata. Each time the machine changes its state, a transaction is triggered to update the metadata to the new state.
f. An asset as a permission (RBAC)-Assets could also be roles, users, messages, (and anything which can have multiple instances in a scenario-vehicles, reports, and so on).
INPUT
The input of our CREATE transaction contains the information that Martina (represented by his public key) is registering the bicycle. It contains a digital signature generated with Martina’s private key to proof that it’s really him creating the transaction and not someone else.
Conceptually, an input is a pointer to an output of a previous transaction. It specifies to whom an asset belonged before and it provides a proof that the conditions required to transfer the ownership of that asset are fulfilled. For example, Martina is only authorized to transfer the bicycle to Stefan as the ‘input’ contains a proof that Martina is authorized to ‘spend’ (transfer or update) this particular output.
OUTPUT
A transaction output specifies the conditions that need to be fulfilled to change the ownership of a specific asset. For example, to transfer a bicycle, a person needs to sign the transaction with his or her private key. This also implicitly contains the information that the public key associated with that private key is the current owner of the asset.
METADATA
The metadata field allows users to add additional data to a transaction such as the age of the bicycle or the kilometers driven. Metadata can be updated with every transaction. In contrast to the data in the asset field, the metadata field allows to add new information to every transaction.
TRANSACTION ID
The ID Of a transaction is a unique hash that identifies a transaction. It contains all the information about the transaction in a hashed way.
Some of the use case of BigchainDB
1. Res()nate-IP Music Rights (A streaming service owned by all)
2. Ascribe-IP Digital Art (Enables creators of digital art to get compensated via claiming attribution and licensing)
3. Authenteq-Identity (low-friction assurance, sovereign personal data)
4. BenBen-Government Land Rigistry (low-cost registry, less risk of corruption)
5. Recruit-Education Credentials (reduce fraudulent degrees, lower HR friction)
6. RWE-Energy (manage $ flow in energy deregulation)
7. Tangent90-Supply chain/health (government mandated transparent $ flow)
8. IPDB-Decentralized Atlas, BigchainDB MongoDB (Anyone can write, anyone can read, permissions as assets)Sweet spots: ID, IP.
Will review your comment and get back!