Recently, the team behind Modex BCDB (Blockchain Database) held an open discussion session centered around this innovative product. The speakers and architects of Modex BCDB – Head of Modex Alin Iftemi, CTO Dragos Rautu and Software Lead Dan Popescu – teamed up to answer the audience’s questions and offer a glimpse on how this solution functions and how it can be used by companies to enhance security and performance.

Modex BCDB general overview

Modex Blockchain Database (BCDB) was designed to help people without a background in tech, access the benefits of blockchain technology and remove the dangers posed by the loss of sensitive data.

Modex BCDB is a new take on blockchain technology which removes the need to invest resources in blockchain training and facilitates fast adoption of the technology in businesses. The solution proposed by Modex is a middleware that fuses a blockchain with a database to create a structure that is easy to use and understand by developers with no prior knowledge in blockchain development. As a result, any developer who knows to work with a database system can operate with our solution, without needing to change their programming style or learn blockchain. 

In a traditional flow scheme, the front-end application sends a request to an application server, which in turn sends requests to the database to access or modify the information stored. Modex BCDB challenges this established paradigm by positioning itself between the application server and the database. This way, clients get to tap into the benefits of blockchain technology without needing to invest time and resources in developing their own blockchain. 

Open discussion session

Q: What kind of consensus protocol does Modex BCDB use?

A:  Modex BCDB utilizes Proof of Authority, the default consensus protocol of Tendermint. As a general rule, we do not intend to modify the consensus protocol or the blockchain in general. Because Modex BCDB is designed as a middleware solution, we focus mainly on integrating with a blockchain network that best suits our customer’s needs. We do however alter the authentication layer to comply with our node licensing mechanism which will enable the network beneficiary to grant licenses to a third party. Node licensing gives the network beneficiary complete control over third party nodes, which means that if contractual obligations are not respected by an external party, the network owner can revoke their license and remove the node from the network. At the moment, Modex BCDB is defaulted with the Tendermint blockchain, so we also use Tendermint’s consensus protocol.

Q: How does Modex BCDB stand in terms of speed? If I write a new record in a node, how much time would it take for the information to replicate across the entire node network?

A: Maximum one second. It depends a lot on the network latency between the respective nodes.  I’m afraid this is an issue that no blockchain can solve. The overhead we are dealing with depends a lot on how you want to add an insertion through our system. If you want the system to perform an integrity check or other data manipulation, it will take a bit longer, but still under a second, a few milliseconds for a single insertion. But if you make a direct insertion and go through all our layers and only ensure the insertion in the database and blockchain the time drops significantly. Overall we try to keep it at a minimum when it comes to the internal flow of our system. Reading operations take a bit longer as they, require a full integrity check, and depending also on the latency of the blockchain used, the process may be slower. In the case of Tendermint, because it is a fast blockchain, operations are much smoother. But if we use a slower blockchain, the integrity check will be slower. 

We have decided to use Tendermint because it is a light and fast blockchain framework. Their benchmark tests show an average speed of 1000 transactions per second. We haven’t reached those numbers yet and it’s very likely that we will never come close to that speed because of the agnostic character of Modex BCDB. We are trying to balance performance with utility, so it’s only natural to make some sacrifices. In the research stage of BCDB, we concluded that businesses extract more value from the fact that they can choose what blockchain framework is more suited for their needs.

Q: Why did you decide to make Modex BCDB agnostic from a blockchain and database perspective, and how does the system overcome the scalability trilemma?

A: The scalability trilemma isn’t directly related to the Modex BCDB layer. It is an issue directly concerned with how you implement blockchain technology. As an agnostic solution, we provide clients the freedom to choose the best blockchain framework for their needs. So, a client can opt for a more scalable, secure, or decentralized blockchain, it doesn’t matter for us. If a blockchain that overcomes the scalability trilemma appears in the near future, we will integrate with it and allow our customers to reap the benefits.

This is one of the reasons why we decided to develop an agnostic solution. As a technology, blockchain hasn’t reached full maturity yet, there are many options in the market at the moment, each with its advantages and disadvantages, and considering the rate in which this technology evolves, we thought it foolhardy to focus only on one implementation of the technology. We didn’t initially start with Tendermint. Our primary focus was Sawtooth, but during our pen and paper stage, we saw that Tendermint made huge leaps in this area and that it was more suitable for our use case. Maybe in two years, there will appear a faster, more powerful and stable blockchain iteration which solves the scalability trilemma. Because we chose to be agnostic we will be able to introduce it in our expanding list of blockchain frameworks.

We strongly believe that the agnostic characteristic of Modex BCDB opens new windows of opportunity, as compatibility related issues become a thing of the past. Regardless of the type of database a company is employing, or the type of blockchain it wishes to connect to, our solution ensures a seamless connection between the two technologies. For example, one node can hold a MongoDB database, while another node from the same network can host a SQL database. This layer of flexibility can prove to be invaluable to a consortium network, where multiple companies can synchronize their databases, without requiring to change their database providers. As a result, the system becomes database agnostic, which implies that Oracle, IBM, Mongo DB, Microsoft SQL databases can synchronize with each other. Modex BCDB positions itself between the client’s application and database without altering data entries to facilitate communication with different types of databases.

Q: In most blockchain networks, if a user loses their private key, their data is lost forever. Does Modex BCDB have a key recovery mechanism?

A: When designing Modex BCDB, security ranked among our top priorities. As such, we decided to create a separate blockchain network, namely the Authorization and Licensing Network, which contains the private and public keys. Of course, depending from use case to use case, network beneficiaries have the option to configure the network to hold or distribute the private keys among network participants as they see fit. Furthermore, clients can choose to transform the private key into a token hardware that they can store however they want. The Authorization and Licensing Network is a private blockchain, purposely designed for the enterprise sector. As such, a consortium of companies can distribute authorization nodes between each member and ensure that everyone stands on equal footing. 

Indeed. One of the biggest issues concerning the use of blockchain for business is the risk of losing the private key, and subsequently all the data. To circumvent this issue we have designed a functionality called the master key, through which a user can recover their lost private key. The solution is quite straight forward. The master key is split in multiple shards and each trusted network administrator receives a shard. Let’s say we have a network where there are seven administrators. To recover a lost private key, a majority of the administrators, in this example, at least four of them, must give their consent and use their shards to form the master key used for recovery.

As a quick side note, the authorization network can be thought of as a key management system that the network owner can entrust to a third party. The advantage is that instead of relying on a centralized server that is vulnerable to attacks, the data is stored across a distributed network of nodes.

Q: Let’s assume I am a client, a distribution company at a national level, and I want to use Modex BCDB to secure my data. What does this entail? What do I need to do to move my product stocks safely on the blockchain? I assume it’s more difficult to log in to a blockchain than a CRM for example?

A: The first thing you need to do is to study and make sure that blockchain is the right answer for your business. If you conclude that blockchain is suitable for your needs, you can start the data migration process. One of the advantages of Modex BCDB over other blockchain solutions present on the market is that it is much easier to integrate directly with a CRM because you aren’t required to write your own smart contracts, simply put, you don’t need to familiarize yourself with the logic behind blockchain. Our solution comes with a predefined blockchain configuration, and the integration is done through the adapter. As a beneficiary, you are no longer required to write directly in your database. You can write in our API, which is similar to writing in your database, but our solution simultaneously converts the data into a hash (a string of characters which is used to verify the integrity of the data) and stores it into the blockchain.

Modex BCDB functions by employing a minimally invasive approach. Small changes to your existing software, if you are a distribution company, I assume you have a registry software which needs to connect in certain key point to our solution. After this process is completed, we will begin the integration and data migration process. Data migration is a process mandatory for every system which already has data entries. What does it entail? The scanning of blocks of data which are transformed in metadata that will be introduced into the blockchain to ensure integrity and immutability.

Q: It is a well-known fact that it is nearly impossible to delete data from the blockchain. Taking this into consideration, how does Modex BCDB ensure GDPR compliance? Can you remove a user’s personal data?

A: GDPR refers to the protection of a user’s personal information as well as the right to be forgotten, namely the right of a user to request the deletion of any personal data. When a company fully integrates with Modex BCDB, every piece of data is stored directly, or if the use case demands it, encrypted in the database. From a GDPR standpoint, encrypted data is still considered personal data. This is because encryption is a two-way function. As such, what is encrypted can also be decrypted with the proper key. But Modex BCDB does not store raw, or encrypted data into the blockchain. Instead, it calculates the hash of the information which is later stored and distributed across the blockchain. Hashing is a one-way function that scrambles plain text to produce a unique message digest, a string of unintelligible text, from which it is impossible to determine the initial input. As such, when a user requests the deletion of their personal information, we simply delete it from the database which leaves the hash in the blockchain. Keep in mind that each entry in the database has a corresponding hash in the blockchain which references the data. When information is removed from the database the hash remains, but it will no longer be linked with any data. It will become a redundant string of characters in the blockchain, impossible to determine its meaning. 

This is one approach to handling GDPR compliance, which briefly explains how the mechanism works. Modex BCDB also has a more elegant approach to the issue. Before information is introduced in the system, users can tick a checkbox named GDPR compliance. If the checkbox isn’t ticked, it means that a particular piece of information isn’t GDPR compliant, so it will not be hashed and distributed on the blockchain. It will be stored only at the database level.

Q: What is Modex BCDB’s approach to data ownership?

A: Our solution has a new approach to data ownership, in the sense that each record has its owner. A record is owned by the individual/company who introduces it into the network. This means that in order to access a record introduced by somebody else, you need to forward a request and receive their approval to be able to interact with it. At the subnetwork level, admins can impose full restrictions and completely shut down the network to users that are not in the same region. This aspect can boost security, as it mitigates the risk of mismanagement and erroneous permission. Access can be granted to individuals outside the subnetwork, only after special configurations have been set in place and if data sharing legislation from that region is followed. The Modex solution was designed to give users the possibility to create and develop software applications that fall within the legal limits of the country in question, regardless of its blockchain nature.

An ecosystem where each record has a unique owner can have a disruptive impact across every major industry, especially in healthcare. Managing patient health records in legacy systems has proved time and time again that inefficiencies and data losses are commonplace, and that band-aid solutions only temporarily remedy these issues. A blockchain-powered backend application can empower both clinics and patients, by enabling them to interact in a consensus-driven environment, where data ownership is law. Modex BCDB offers a full suite of functionalities and features that enables developers to create a healthcare application that respects the principle of data ownership and pseudonymity. Our solution allows healthcare clinics to store and access data only from their patients, for a period of time determined by the patient. Accessing health records from patients outside the clinic requires special permissions from the record owners. The process is straightforward. A request is made from an API, and the record owner receives a notification informing him that a company wants to access their data, which he can simply approve or dismiss. Access permission is not limited only to read, external parties can request record write access. An application designed in this fashion disrupts the patient-physician interaction, concerning personal data management. Patients grant doctors write access, enabling them to write records such as medical investigations, drug prescriptions, surgical investigations, and so on, on behalf of the patient. Write access can be granted for a limited period, or for an unspecified amount of time, depending on the situation and the desire of the record owner.  Another major benefit of this system is that once running, only the end-users, in this case, the patient and physician are directly involved in the process.

Healthcare research institutes are among the prime beneficiaries of a permission-based app. When performing a trial, institutes require a large sample of patients to gather relevant data. Let’s assume that a pharmaceutical research company wants to perform a trial and needs a large sample of people with diabetes. An app built on this type of permission principle can streamline the whole process as it gives clinics access to a large sample. It is a win-win situation because both interests are served, companies get their data (only if consent is received), and patients can be incentivized for participating in the trial. But the most important aspect is the fact that the app will be GDPR compliant.  Clinics will never receive patient personal data, their dashboard will display the number of patients, the type of diabetes, prescribed treatment, reaction to medication and so on, data that cannot be used to single out an individual.

Double data ownership is another feature that supports healthcare institutions. Patient data introduced in the system by a physician has double ownership, in the sense that the hospital can see that a patient x had y intervention at a specified date, but personal data which belongs to the patient can’t be accessed, unless a request is formulated through an API, and the patient gives their consent.

Q: Does Modex BCDB have any unique features and functionalities?

A: Currently there is no hybrid blockchain database system that has an agnostic approach to the blockchain framework. There are a couple of similar products on the market, but they come with a great inconvenient. They force the beneficiary to use only one blockchain framework, regardless of the fact that it is not the best blockchain for them. The same applies to database frameworks. So versatility is one of our strongest points. We can switch both blockchain and database in order to devise custom solutions tailored to the client’s specifications and requirements.

Our approach to data synchronization policies offers a greater degree of flexibility. Existing blockchain networks synchronize the data equally across the whole network, but with Modex BCDB you can choose to synchronize only with specific nodes from the network. Let’s take a use case, for example, a bank that wants to secure its data with blockchain. The bank in question has ten branches and a database of one hundred gigabytes. With existing blockchain solutions, the bank will have a node for each branch and due to current synchronization policies, it will replicate the one hundred gigabyte database to each node, which can be a waste of time and resources. Modex BCDB provides an alternative. The bank headquarters can, for example, hold two full nodes which contain the whole database, and give each branch a partial node which stores only the information introduced from the respective branch, because most often than not, a branch will interact with clients from their vicinity. If a client from branch A goes to branch B, for whatever reason, only his data will synchronize with the node from branch B. This approach is more storage efficient, and also resolves privacy issues, because each branch works only with its set of data.

Default encryption is another feature that gives beneficiaries access to increased security and flexibility. Users can create a table and configure specific fields to automatically encrypt data. Then, depending on a user’s access permission, they can view the data in a decrypted format, without requiring to manually decrypt it.  Encryption is a well-established concept, but default encryption has never been implemented in blockchain database mechanisms. This feature can greatly benefit software solutions that don’t have an inbuilt encryption mechanism, as they are not required to restructure their base application. And the automation layer greatly simplifies how users interact with the application.