GeoDB. Technical discussion I

Hi everyone!

We hope you’re having a fabulous vacation time!

For us, the last months have been amazing. Four new guys have joined our technical team, we’ve defined our roadmap for the following months and we’re currently working hard in several areas of our ecosystem.

So it’s a great moment to share some new stuff with you.

Today, we’re going to start a new blog series with which we intend to clarify the reasons for some of our decisions. Specifically, today we’re here to clarify the reason why we’ve opted for Ethereum as platform for the emission of the GEO token.

To explain this, we’ll conduct a brief technological analysis with which we’ll try to answer the following question: what is the most appropriate DLT infrastructure to issue the GEO Token?

Approach

Before making any technological decision it’s convenient to carry out a state of the art review, in our case, in the DLT area.

DLTs can be categorized according to different aspects such as ledger topology, visibility, permissions, consensus algorithm used or supported functionalities among others.

In our case, we’ll initially focus on the DLT generations, perhaps a less objective factor than others, but a quite useful one for an initial approach:

• DLT 1.0: In 2009, Bitcoin emerged, and with it, the starting signal for DLT was given. All those DLTs based on a chain of blocks or blockchains which are focused on the transmission of an asset can be considered as DLT of the first generation.
• DLT 2.0: Just over four years ago another small revolution happened. Vitalik Buterin brought to the table a new concept, the smart contract, with which anyone can deploy, in a DLT created to support it, a decentralized application or dApp. With the emergence of smart contracts, the concept of DLT as a service began to spread and the new generation of DLTs or DLT 2.0 started, headed from its inception by Ethereum.
• DLT 3.0: Vitalik Buterin, which is one of the most recognized faces in this field, and for us, one of the most lucid minds too, raised few years ago the famous scalability trilemma which refers to the tradeoffs that crypto projects must make when deciding how to optimize the underlying architecture of their own blockchain [https://medium.com/@aakash_13214/the-scalability-trilemma-in-blockchain-75fb57f646df]. The third generation of DLTs is made up with proposals which are using new approaches to face this reality. We set aside blockchains, consensus algorithms based on proof of work and other things and we begin to explore new ways to create DLTs. Within this generation, the DLTs which are using directed acyclic graphs or DAGs stand out from the rest, being IOTA the most recognized project.

In GeoDB we propose a hybrid solution in which alternatives of the second and third generation will be used, for the deployment of our fungible token as well as for the efficient validation of the information provided. Therefore, the selection of the most appropriate platform for the token deployment is a critical step and, given the high number of existing alternatives, it’s necessary to filter those to consider using objective parameters. In our case, the following:

1. Permission. We want to deploy our token in a public permissionless DLT. This moves away solutions created to provide privacy in transactions such as Monero or Zcash as well as permissioned DLT frameworks such as HyperLedger or Corda.
2. Community support. The infrastructure must have great support in the community, as we believe this is a guarantee of a higher level of infrastructure refinement, rapid error detection and greater resilience to external attacks. Based on the above, the level of community support has been analyzed based on: i) market capitalization, ii) volume of transactions over a period of time and iii) activity in public repositories. To analyze the above, the values shown by CoinMarketCap, StateOfTheDapps, Blocktivity and Coinchekup have been taken as a reference.
3. Smart contracts support. It’s necessary that the infrastructure allows us to deploy a fungible asset with the characteristics we need. This rules out solutions such as Bitcoin or IOTA among others.

Using the above filters our analysis is limited to (i) Ethereum, (ii) EOS, (iii) Stellar, (iv) NEO, (v) Waves.

Study of alternatives

Using raw data to reach a decision can be a major mistake. Nothing offers more objectivity than numbers, this’s a great truth, but as British Prime Minister Benjamin Disraeli said, “There are three kinds of lies: lies, damned lies, and statistics”.

In practice we can justify the use of any DLT by strategically selecting a handful of values. And most of the projects have already done this work for us. On their websites or in their papers they offer tables with which they can prove with irrefutable data that their alternatives are the best.

And we don’t want to fool you with data. As we indicated at the beginning, we’ve decided to use Ethereum, probably the project with the most fervent community. Justifying the choice of Ethereum over others with numbers is extremely simple because Internet is full of resources to do this.

We believe that it’s more suitable to explain, not that Ethereum is the best solution in all aspects (which it’s not), but, that for us, it’s definitely the most appropriate alternative.

Ethereum

Ethereum is a second generation DLT and it uses a blockchain. It’s the most famous, known and used of all the alternatives considered.

As “first mover” of the second generation, it has a much larger community than the rest and offers more refined technical solutions at all levels, leading innovation in the area. Its decentralization gives it an incomparable degree of stability, especially in terms of resilience to vulnerabilities, denial of service and censorship. Politically, Ethereum is very stable and there are very few conflicts of interest between the different areas that make up the project. On the near horizon of the network is the Casper update, which will completely change the way in which the network operates moving into a Proof of Stake model.

As a counterpart, the decentralization and stability of Ethereum must be paid. The costs are higher and transaction times greater. In addition, being the most veteran project, the introduction of innovations and new paradigms to its technological base is more complex.

Pros:

• The best known platform by our team.
• High adoption.
• It provides the necessary features for our token and our needs.
• There are multiple standards developed and audited for cryptoactives deployment.

Cons:

• Worst operating performance among all the alternatives considered.

EOS

The EOSIO platform, sometimes called simply as EOS (although it’s not exactly the same), tries to solve scalability problems with which other networks such as Bitcoin or Ethereum are dealing right now by using an alternative consensus algorithm, the Delegated Proof of Stake (DPoS).

EOS provides an execution environment similar to the one provided by Ethereum regarding Turing-Completeness. In EOS, the logic implemented by a smart contracts is completely free. However, there is a big difference.

In EOS, the assurement of a contract execution by the entities that carry out the consensus, does not exist. If the contract performs a non-convenient operation or the operation is considered “against the rules of use”, the operation will not run. Therefore, EOS ecosystem is not as resilient as Ethereum.

EOSIO is currently governed by a single entity that accumulates most of decision and operating power, so, today, it could be considered as a centralised platform. However, and because of this, EOS enables users to communicate efficiently with the blockchain, minimizing transaction fees and with very low latency.

Pros:

• Very fast.
• Turing complete.

Cons:

• New paradigm without validation in the medium term.
• Complex computing cost mechanism.
• Centralized. A single organization decides who can participate in the consensus. A legal agreement, called Constitution, is also signed to be a masternode.
• It isn’t immutable. The masternodes may be forced to reverse transactions and the history of the ledger for legal imperative (Constitution).

Stellar

Stellar is a DLT with support smart contracts but with a limited functionality.

The fundamental difference of Stellar regarding other solutions is the way in which the consensus is achieved. Most of DLTs opt for mechanisms that guarantee the dedication of individual resources to ensure the right network performance (usually with computational resources). Instead of this, Stellar employs a consensus algorithm based on trust between entities. This algorithm allows any node registered in network to vote its most representative node and only the most representative nodes can update the status of the ledger. This is also called “Federated vote” and due to this mechanism, the latency is lower than in other DLTs.

As mentioned, Stellar smart contracts have limited their functionality and it is limited to a minimum set of operators running under different conditions, so it is considered non turing complete. This limitation is not bad by itself, because this reduced functionality can be a plus in case you want to deploy a very simple smart contract, but not if it has some complexity.

Pros:

• It’s faster than Ethereum.
• Good reputation.

Cons:

• Smaller adoption than Ethereum.
• More limited smart contracts than Ethereum.

NEO

NEO is also a blockchain DLT on which smart contracts can be executed.

It improves aspects such as scalability, being able to support up to 10,000 transactions per second (theoretically). To achieve the above, NEO uses a consensus algorithm that emerged as an evolution of PoS and which is called Delegated Byzantine Fault Tolerance (dBFT), which reduces resource consumption.

One of its peculiarities is its platform, which uses two layers and two different cryptocurrencies (one per layer). In the first one, the applications are executed using GAS, the currency of this layer. In the second one the native currency of the platform, the NEO, is used.

Its virtual machine, NeoVM, is turing complete, being possible to develop smart contracts in general purpose languages such as C #, Java and Go.

Pros:

• Turing complete.
• Smart contracts development in general purpose languages.
• Its consensus algorithm minimizes the computational resources to be used.
• High transaction speed.

Cons:

• Lower adoption.
• Reduced technical knowledge of the proposal as a whole by our team.
• There are rumors that it’s supported by the Chinese government, which makes the community suspicious of its future evolution.

Waves

Waves Platform is known as the “Russian Ethereum” given the great similarities between both projects.

Waves uses PoS as consensus protocol which improves the scalability of the platform, and with the release of Waves-NG and its enhanced transaction serialization protocol, it offers an approximate transaction validation time of 3 seconds.

Waves makes use of what are called “liquid blocks”, a kind of block which is continuously increasing by a node, which is continuously validating transactions. In this process, the creation of a block is divided into two parts, i) the communication of a KeyBlock to the network and ii) the creation and continuous spreading of microblocks associated with it.

Waves also allows the creation of smart contracts and dApps with its own programming language, RIDE. However, these smart contracts are not turing complete, although if we stick to its roadmap they will be turing complete within this year.

Pros:

• Fixed transaction cost.
• Quite fast.

Cons:

• Their smart contracts are not turing complete.
• Very oriented to ICOs and token exchange through its decentralized exchange.
• Low diffusion.
• Strong community, but very small compared to other alternatives.

Why Ethereum?

For us, after considering all this information, the right decision is to use Ethereum.

This infrastructure offers a worse quantitative performance than others, but this is because of the solution’s approach.

That operating costs are high is a directc consequence of several facts: i) there is a large community interested in using the platform and that ii) a purely decentralized scheme is used.

As a long-term approach, a factor such as community support is a crucial element, and in that, Ethereum’s leadership is indisputable. We must not forget that we move in a totally new land, in which Ethereum, being one of the most veteran projects, has just turned four years old.

A serious architectural error is less likely in Ethereum, given the large number of developers who maintain and update their code base and the large number of solution creators who test the infrastructure on a daily basis.

Thus, Ethereum is the slowest and most expensive solution to those considered, but in return, it’s the safest against attacks and failures and the one that offers the greatest guarantees in the medium and long term.

But let’s not forget that these technologies are not yet mature enough. Maybe in a few years Ethereum is surpassed by one of the previous projects or even perhaps GeoDB will deploy its own public DLT to support the operations of our token and thus minimize costs. Who knows!

See you all soon! Enjoy the summer! ;)