Discovering GeoDB 4. Modular Blockchain Architectures

“Everything should be made as simple as possible, but no simpler”
Attributed to Albert Einstein, 1933 [1]

September fourth and Discovering GeoDB fourth post. Let’s recap what we’ve discussed so far.

In [2], The power of place, we’ve analyzed the great value of private location data.
In [3], Game theory, we’ve reviewed how in a free and competitive market, the price will be dictated by both sellers and buyers.
In [4], Blockchain 101, we’ve summarized the pillars of blockchain technology and we’ve indicated how we aspire to use it to work with private location data.

When a few weeks ago we created our blog to share our idea with the world, we asked ourselves, what is the best way to present GeoDB to a person who has absolutely no idea about the project? Do we write an extensive publication to explain absolutely everything that nobody is going to read more than the first couple of paragraphs of it? Do we write a brief summary with an amalgam of ideas in which we explain everything but in which nothing is clear? Do we make a logical division of our proposal and explain each concept independently?

It’s said that sometimes, to find a satisfactory solution to a dilemma, it’s best to reformulate the main question. In our case, what do we want? We want to explain our proposal to make it as clear as possible so it’s not necessary to indicate what our decision was. By dividing a proposal into its different logical parts, we can explain each of them in a simple way, being able to delve into all the convenient details at the same time.

GeoDB architecture has been proposed following a very similar approach. Our infrastructure is based on what we have termed as a Modular Blockchain Architecture, or MBA, which focuses on the interconnection and interoperability between different blockchain networks. Maybe you can think that it’s a convoluted solution, but believe us, it’s the best solution and at the same time, the simplest. Let us explain it to you.

Interconnection is the key

The term blockchain isn’t the most appropriate to describe the technology to which it refers, being Distributed Ledger Technology, or DLT, a more precise definition [5]. However, the irruption of blockchain as the first DLT led us to use the term blockchain to name somethings that really aren’t blockchains.

Something similar occurs with respect to the mother of all the blockchains, Bitcoin. Due to its advent as the first blockchain, the Bitcoin network has a much greater diffusion than the rest of blockchain networks, and its cryptoactive, the bitcoin, a much higher value than other cryptoactives.

The spectacular rise in the price of bitcoin as well as the rest of cryptoactives has led to meaningless discussions about which blockchain network will prevail over the rest, something reflected in the used of the term altcoin.

These are sterile discussions because they assume the hypothesis that there will be a blockchain network that will triumph over the rest. This conjecture only reflects ignorance about blockchain technology.

As soon as we analyze how blockchain technology works and what it allows to do, we’ll realize that it’s a nonsense to propose a unique blockchain network to cover the needs of all types of users and entities. Are the needs of a bank identical to those of an insurance company or those of the social security of a country? Should the data be stored in the same way and be accessible under the same scheme in all cases?

Obviously the answer to the previous two questions is a resounding no in both cases, and this is the cause of the use of an increasingly rich vocabulary to talk about types of blockchains networks.

In the future, there will be multiple blockchains networks, and each of them will cover the needs of a specific sector and therefore they will be designed with unique characteristics that will allow them to provide very specific features. Without going any further, today we already have a great heterogeneity. We have blockchains networks in which all information is public and others in which the information is encrypted. Blockchains in which anyone can participate publicly and others in which the access is restricted. Blockchains that use smart contracts as opposed to others in which it’s only necessary to store data. With consensus algorithms based on PoW or PoS. And so on.

We could extend the previous list extensively, but our goal here is not to establish a taxonomy but to illustrate the absurdity of thinking that a single blockchain network is the solution to all existing problems. As in so many other cases, there are no silver bullets here.

We must be aware that this heterogeneity is not a problem, but the opposite, since we can use customized blockchains networks to cover our needs in an optimal way. This scenario of multiple blockchains has led to the creation of gateway services, which allow us to interact in several blockchains networks simultaneously.

We are convinced that this interconnection will prevail in the coming years as it fosters the emergence of high-value synergies: i) blockchains with health data accessed partially by the blockchains of insurance companies, ii) blockchains with sports results accessed by the blockchains of sports betting companies and these blockchains accessed by the blockchain of the tax agency of a country, iii) blockchain of geo-positioning data accessed by the blockchain of a research institute and this blockchain accessed by the blockchain of a verification agency, and we could continue with a long etcetera.

When we proposed GeoDB, we asked ourselves the question: what is the most appropriate blockchain architecture for our proposal? We want to store data under a big data paradigm, facilitate the sale to users and the purchase to customers. But we also want to facilitate the development of novel applications on our infrastructure.

Our solution has been the proposal of a modular blockchain architecture, which we have conceived as an architecture with modular nodes that can interact at the same time in multiple blockchains under different roles.

Our architecture offers great advantages, among which we highlight:

Our infrastructure is scalable and adaptable to multiple types of needs.
The modification of the infrastructure is simple and can be optimized in each case.
The participation of a node can be evaluated according to different parameters, so it can obtain greater rewards.

Our concept of modularity

Perhaps, after reading the previous section, you’ve clear what kind of architecture we want to propose, but we know that the term modularity used in a technological context can be ambiguous. When we talk about modularity, our thoughts can go in several directions [6]:

From a design perspective, we can see it as a software technique to separate the functionality of a programme into independent parts that each contains everything necessary to execute only one aspect of the desired functionality [7].
From a development perspective, we can see it as an approach that subdivides a system into smaller parts that can be independently created and then used in different systems [8].
From an infrastructure perspective, we can see it as an expandable architecture in which the systems are expandable through modules that provide them with a specific role with which they can participate in our system or in other systems.

The latter is the one we refer to. If you do not end up understanding it, the following diagrams will clarify your doubts. Let’s suppose that this is a blockchain.

Multiple nodes can participate in a blockchain network, each with a local copy, complete or not, of the blockchain.

The nodes are connected, usually under a P2P network topology, forming a blockchain network.

The nodes that participate in the blockchain network follow a consensus algorithm that allows them to agree on how to add blocks to the blockchain and what is the correct blockchain version.

There are different blockchains networks, with more or less similarities between them.

Each of these networks has a purpose, so they use different consensus algorithms, different types of blocks and different access policies.

In many occasions, the data of a blockchain network can be useful in another network. In these cases, gateways capable of interacting in both networks can be implemented.

The implementation of a gateway varies in each case and is far from being a trivial process.

Given that the previous situation is not exceptional but recurrent, we propose an expandable blockchain architecture in which the nodes are expandable through modules that provide them with a specific role with which they can participate in one or more blockchain networks.

And that’s all for now folks.

In our next post we’ll perform an analysis on the size of our big data pool of private locations and on the economic cost of storing that volume of information using some of the current public blockchains versus the cost using GeoDB.

Interconnection is the key

Our concept of modularity

References

Share this:

Like this:

Related