7 paradigm shifts I experienced becoming a developer in a blockchain based project

When I embarked in my first blockchain project as a developer, I had zero knowledge about the technology, and was soon to find out that I was starting from the least favorable position: a software engineer who’s been working for more than 13 years exclusively with high level programming languages and Microsoft technologies. But since both computers and developers need a good old-fashioned restart sometimes, I considered the change a welcomed one.

Where do you start?

I didn’t have any in-depth knowledge about blockchain or cryptography when I started out, so I just begun by covering the basics. What is blockchain? What is a distributed system? What is immutability? And so on.

Even if you have the knowledge of the concepts, it’s best to ensure that how they are applied corresponds to your understanding of them. Just because you are familiar with them and how they are applied in some domains that you are familiar with, doesn’t always translate the same in other areas or technologies.

From this first reading I extracted a first pile of unknown concepts that led me to the second layer of learning. It was quite the journey down the rabbit whole, and not because of the big learning load. But because I soon realized that I had to change the way I saw and did things for so many years. This, I think, is the hardest part: to know what you don’t know.

paradigm conflict

Here are some of the key perspective turns that I had to take in order to be able to complete my first task in a blockchain based project.

No. 1: Blockchain architecture is different

When you contribute to develop an application on blockchain and you consult an architecture document, you should know that this is not the standard client – server database architecture that many of us are used to.

client-server vs. blockchain architecture

Client-server vs. blockchain architecture

As opposed to a centralized client/server architecture used in traditional databases, blockchain nodes are organized in a peer-to-peer network where each computer runs blockchain software and maintains an updated version of the whole blockchain data structure.

This is the biggest difference that leads to other particularities of the blockchain systems.

No. 2: There’s no such thing as central validation

As blockchain is supposed to be an alternative solution to regular central authority-based systems, there can be no central validation either.

One of the key features of the blockchain is that it is a decentralized system, where the same data structure is distributed throughout every node of the blockchain network.

The system is based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.

Throughout different blockchain networks, the way to obtain proof is different, but always depends, in one way or another, on the consensus of the majority of the nodes in the network.

No. 3: You can never delete any data


Data immutability

In a client-server database for example, you can delete and change data at any time, without any restrictions, considering that you have the necessary permissions.

In a blockchain-based system, this thing is not possible.

Well, in theory, it is possible to delete data from a record of transactions that are part of a blockchain, if two conditions can be simultaneously met:

  1. More than half of the network nodes agree with the deletion
  2. All the hashes of the transactions registered after the one that is deleted must be recomputed

To achieve this, an immense CPU power would be needed which renders the attempt impossible.

Therefore, you cannot say that you can delete data from a blockchain. You can only add to the existing chain, for example you can update the state of a piece of information you initially stored. Depending on the type of blockchain, of architecture, of what the application is doing, you may need to support or make implementations at the smart contracts level.

No. 4: You must think about the resources you use

Speaking of smart contracts, you may be interested to know that they are also software components, but they are written in languages that are specific to the blockchain distribution you are using.

To create or modify a smart contract you need to learn this specific language, to acknowledge its limitations and what you can do with it. If you are just starting out you need to do a lot of research, as these languages are very low level.

What does low level mean? It means that sometimes you may need to consider the amount of memory that is needed for the operations you are making. How expensive they are in terms of resources, processor, and time. These are usually non-issues when programming in a high-level language.

In C# for example, when you want to perform operations with strings or other data types, you don’t need to care about that, as there are many ways to perform them. But in blockchain, all these aspects become important, and in some contexts, exceedingly difficult to execute.

No.5: The compatibility issue

Another issue that arises with blockchain-based application development is the compatibility with what you want to integrate.

When you implement a solution in C# for example, you only need to know this one programming language.

But suppose you are implementing a smart contract that performs some operations on the blockchain side, such as some validations and then stores some data in a specific way, and you also need to be able retrieve the data at wish. For this you have to learn the languages that allow you to implement these functionalities.

In my case, for example, in the timeframe I’ve been working on PharmaLedger, I had to implement APIs or software components in Node.JS, GO, and Solidity. So, you can end up navigating through many programming languages that don’t resemble one another.

This requires a greater flexibility on your side as a programmer or system architect.

No. 6: There’s no such thing as support

The blockchain distributions like Bitcoin, Ethereum, Quorum, or Hyperledger Fabric are all open source.

If you’ve been working for example with Microsoft distributions for most part of your software development activity, when you make the transition to blockchain distributions you’ll have to adapt to the fact that there’s no central entity to offer support or fix some issues. The community will offer help, or, if something doesn’t work, can offer insight on why and what would be the correct approach.

However, the bigger the community that is involved with the distribution, the bigger the chance that documentation is up to date, that coherent examples are available, and that you can find the tools to help you optimize or deploy components.

No. 7 Deployment is a whole different experience

Finally, a big mind shift for me was with the deployment for blockchain. In a cluster, when you raise a container, that container is based on the image of a machine you are building. On that machine you specify the operating system, the software products you install, the source code, dependencies, and the program you need to execute. It’s like raising a virtual machine. These are built in an optimized mode, with the minimum necessary so that your software component works.

It’s not like a Windows machine where you load all possible applications, no matter if you use them or not. It’s bare-bone, there’s no UI, no mouse. This machine emits only logs. And you have only a command prompt to interact with it. You will not be comfortable to make a deployment to Kubernetes for example, if you are very used to rely on operating with a mouse. You have to adapt to using the keyboard exclusively, to learn how to navigate between folders, to read and search log files without the support of various APIs. The workflow is a lot different from what you previously knew and it takes some getting used to.

To the blockchain beginner

If you want to become a developer in a blockchain based project, it may be easier if you have strong Node.JS knowledge and you are familiar operating on Linux. There’s even an open position in the project I am currently working, that you can check out.

But in the end, the technology is less important if your mind is set on it. What I can say now, after going through this process myself, is that, if this transition process does something, is to test your tolerance to change and your capability to adapt to new ways of doing things.

Illustrations by Iulia Weingold