Discovering GeoDB 6. Interconnection

Image for post
Image for post

“It isn’t that they can’t see the solution. It is that they can’t see the problem”
G.K. Chesterton, 1935 [1]

We’re here one more week with a new discovering GeoDB blog-post, the sixth one already. We’re reaching the final stage of this trip, and we’ve left the best for the end. Before we start talking about our interconnection model, let’s remember what we’ve talked about in our previous posts:

In our last post we talked about a hybrid approach in which we propose to store certain information using blockchain technology and other information in a public blockchain in order to minimize costs and maximize security. In our opinion, this scheme offers an optimal solution for several key aspects of our domain such as storage cost, scalability, security or immutability among many others.

We can not ignore that currently there are other proposals which, using blockchain technology, aim to reward users for providing their private information, each of them following a different architecture. Therefore, to clearly understand the motivation behind our architectural design, it’s convenient to reflect on the domain in which GeoDB is defined.

GeoDB is a proposal conceived for the commercialization of private locations under a big data paradigm. The big data market has an economic value of billions of dollars ($ in 2015 [7]), but we must understand that the big data paradigm is not related to the individualized sale of user data. Our architecture has been conceived to:

Image for post
Image for post

Due to the above, we believe that the only way to build GeoDB today is under a hybrid architecture. We must be clear that a hybrid solution is not a magic solution, since it’s well known that the interconnection of two isolated components could be even more complex than the creation of the components themselves. In addition, our scenario has an additional problem, we need to write additional information in a public blockchain and this is very expensive [8].

The question at this point is, is it possible to do this at a reasonable cost? Following a traditional approach, it’s not, but we should emphasize the word traditional. To paraphrase G.K. Chesterton [1], maybe it isn’t that we can’t see the solution, it’s that we can’t see the real problem.

Our technological stack

Image for post
Image for post

Broadly speaking, we can say that we propose a hybrid architecture based on blockchain technologies in which will use:

Why an ERC-20 token?

ERC-20 is the de-facto standard for the definition of tokens. It’s a type of token defined in Ethereum blockchain and it is just a coincidence that it is called in this way, where ERC stands for Ethereum Request for Comment, and 20 is the number that was assigned to this request [10].

Image for post
Image for post

Defining a token using this standard is a guarantee for us and for the users of GeoDB, due to the wide use of Ethereum and the existence of multiple popular services adapted to use it [11].

Nobody should be surprised by the fact that today, more than 100.000 tokens are defined as ERC-20 tokens [12].

Why open source blockchain technology?

We believe that it is unnecessary to reinvent the wheel. There are proven technological solutions with which we can provide many of the elements that are necessary for the infrastructure that we want to build.

Currently, in CoinMarketCap there are 838 coins associated with full blockchain implementations [13], and you know what? almost all of them are open source. But blockchain open source solutions do not end here. More and more companies are promoting open source projects for the development of blockchain frameworks with which it is possible to deploy adapted blockchain solutions. Have you heard about Corda [14], HyperLedger [15], BigChainDB [16], OpenChain [17] or MultiChain [18]? If you don’t know any of them, be prepared to experience the Baader-Meinhof phenomenon [19].


Deploy a smart contract to define an ERC-20 token is something extremely simple [20]. Deploy a smart contract without security problems is a bit more complicated [21]. Before using smart contracts in Ethereum it’s necessary to consider two critical points:

One of the main characteristics of ethereum smart contracts is that they do not allow the execution of non-deterministic code. Among many other things, this implies that only information that exists in ethereum can be used when they’re executed.

Taking into consideration the above and focusing on our proposal, the scenario sets as follows:

How can we combine all this? Our approach is to use a paradigm that we call request-approval-justice.


In first place, a smart contract will be deployed in ethereum to define an ERC-20 token. This contract will be designed to allow:

Another smart contract will be deployed in GeoDB big data ledger to account the tokens that can be claimed by each participant based on their participation. Under this paradigm, each address will have two token balances, i) tokens in ethereum that we can transfer and ii) claimable tokens in GeoDB big data ledger that we can not move but that we can claim to be assigned to us in ethereum.

Additionally, there will be a set of nodes that, using a PoS [23] mechanism to guarantee their correct behavior, will write the resumes of the blocks into ethereum blockchain when the blocks have reached a given depth. These resumes will be used as references for the execution of ethereum smart contracts as we will explain later.

Storing a resume in ethereum currently costs slightly less than half a dollar. Considering that 288 blocks are created daily if a block is created every five minutes, the cost of storing the resumes of all the blocks would be $144 per day or $52.260 per year. However, this would be the cost of storing all the resumes, which is not absolutely necessary nor saffer. For example, by storing a resume every hour, the daily cost would be $12 or $4.380 per year.

As we’ll see, to apply ‘justice’ the tokens are not rewarded at the moment, so the number of resumes to be saved could be only one every several days without any problem.

So far we have:

In this infrastructure, the first phase, Request, can be executed. In a request, a user claims the corresponding tokens in ethereum using the GeoDB ledger. A node that acts as a notary will verify that everything is correct and in that case, it’ll generate a signed transaction in GeoDB ledger that proves this. When the next resume of GeoDB ledger is transferred to ethereum, the node generates a new transaction in ethereum specifying:


Approval is not a phase but a state in the process. While request involves the creation of several transactions, specifically 2 in GeoDB ledger, claim and verification, and 2 in ethereum, block’s resume and reward order, an approved transaction is only a reward order made from an account with sufficient balance for the justice phase.


To apply justice we follow the presumption of innocence, i.e, everyone is innocent unless proven guilty. Under this approach, every approved order transaction is automatically considered valid once a possible crime has prescribed. The appropriate time in which a possible crime has been prescribed will be analyzed and fixed before the launch of our mainnet.

During the justice phase, anyone can check if any approved transaction is legitimate or not, for which it’s enough to check if the verification transaction, which is signed by the node that acted as notary, is correct or not. The proof of an illegitimate order transfers the notary’s deposit to the accusation and blocks the assignment of the tokens.

Image for post
Image for post

We still have to carry out several experiments to refine and optimize our paradigm, but in general terms we can see how it allows us to minimize the interconnection costs. As it was initially indicated, to find the solution sometimes it’s only necessary to rethink the problem. In our case, the problem is not how to communicate, but what is communicated and who makes the communication.

In our next post we’ll present our ERC-20 token, the GEO.


Written by

Geo Data Block - The first Peer to Peer Data Sharing Ecosystem powered by Blockchain Technologies - Check our web:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store