Should I develop for blockchain?

and what options we have

Sava Gerov
Coinmonks
Published in
4 min readMay 17, 2018

--

EOS? Ethereum? Ripple? Waldo?

After a bitcoin paper walkthrough I still don’t know if I should keep digging into blockchain. As a developer I’m interested in practical knowledge and a certain output. So go build a DApp — it’s easy!

But should I use Ethereum at all? Are there better options? Options for what? Do we need decentralization? Isn’t a regular DB enough? Most of the work is done at the protocol level at this moment, why daring to work on a higher level?

Simplification

How can we simplify what a blockchain can/might provide without understanding deeply the different consensus mechanisms, coins, marketing, interests or technical limitations?

Blockchains share some properties with databases but what are they better at?

Decentralization & Robustness to failure: they can provide distributed storage which no one can change and failing nodes are not a problem. All that “for free” (you don’t need a service provider nor maintaining it) based on incentives.

A proven application is storage of digital assets (bitcoin). Also ethereum makes us dream of a decentralized computer. Both have scalability (Ethereum supports ~15 transactions per second) and energy-consumption problems.

Different consensus mechanisms solve above issues in different ways, but there is always a tradeoff

Pick your tool

When considering blockchain applications from a developer perspective, we have to take into account several things.

Category

This article splits blockchains within three categories:

  • Permissionless: Any node can freely join the network, there is no central authority that can decide who is a legit user. (Bitcoin / Ethereum)
  • Permissioned: A central entity attributes rights to nodes that want to join the network. It can be public or private depending on who can see (and verify correctness) of the stored data. (Ripple / R3 Corda)
  • Central database: What we know pretty well. (REST API / GraphQL)

The point of the article is that we need a permissionless blockchain only when we can’t trust a third party. We are told distrust makes a good use case for financial services, but does it? Wouldn’t we end up with third party services which help us during disputes such as Paypal/banks and return to a trust-oriented model? Maybe, but the cognitive effort to find arguments against is easier than to find suitable use cases as the technology is far from production-ready and a sequence of innovations is what leads to practicality.

Zimbabwe Hyperinflation

For example, central banks can devaluate a currency by issuing new bills or just the fact that anyone can create a digital currency has created use cases by its own (ICOs or generating a coin for specific purposes).

There is a lot of criticism on how slow blockchain evolves by nature, but most of criticism is on the application level. The protocol can evolve slowly which doesn’t mean applications built on top of it will follow the same pace.

What about permissioned blockchains? Well, if you know who will be writing to the chain you can use it as a distributed ledger to add information from several sources. Sounds more enterprise-ish.

Consensus mechanism

Every blockchain has to reach consensus in a way and its’ characteristics are defined by the chosen mechanism (i.e. Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Capacity (PoC), Practical Byzantine Fault Tolerance (PBFT), Distributed Acyclic Graph (Tangle), Proof of Authority (PoA), Proof of Space and Time (PoCT), etc).

Such diversity just makes the choice more difficult, but that’s what I referred to as the protocol level development before. You might get a higher or lower transactions output, a higher or lower degree of decentralization, but think of what you want to build in an ideal scenario to push the boundaries of the chain you have chosen to hack with. You can’t seek the ultimate app while the technology is so immature.

So what?

Ok, decentralized storage could benefit many use cases but what can we do as devs nowadays?

  • Create a smart (or not so much) contract: they have turing or almost-turing complete languages which allow to define complex business logic. The main pain point is UX which is blockchain users-oriented and the lack of scalability. Check a list of platforms here.
  • Create a (sub)currency: you can clone any existing coin and start mining it. Of course there should be some added value, otherwise pure replication won’t get any adoption. Check a map of coins.
  • Help develop a chain: if you believe in the philosophy and people behind some implementation, many of them are open to contributors.
  • Work on tooling: the development process is very painful in most cases so tons of tools are missing to bring developer happiness.
  • Create your own chain: requires deep knowledge on current implementations to be able to innovate.

Conclusion

The point I’m trying to make here is that no individual contribution will make practical blockchain use cases for today. Just experimenting and hacking around compounds with other peoples’ developments.

Good thing is, smart people are involved in this area, don’t get stressed if you don’t see (like me) an immediate application of the knowledge you will acquire. Just have fun if it excites you and rewards will come. Eventually — just as blockchain consistency (couldn’t avoid it, sorry ✌️).

Get in touch with me on twitter @sgerov!

--

--