written by Paul Trestian (Solution Architect) and Ajay Rathore (Java Software Engineer) in the August 2022 issue of Today Software Magazine.

Read the article in Romanian here

Blockchain applications have become extremely popular in recent years, yet developing one is still a mystery for many developers. We had the same curiosities, so recently, we attempted to demystify the process of building a blockchain application. To make this exploration more adventurous, we chose the perfect opportunity, our ShipIT event hosted at our office in Cluj-Napoca. Our challenge was to build and demonstrate a Blockchain application in 24 hours. So, let's experience together the journey of these 24 hours and our main learnings.

Setting Up for Success in Building Blockchain Application

Given the short development time, it was important for us to be prepared for the event day. This meant having a good understanding of what it entails to build Blockchain technology, having the right technologies selected and clarifying the architecture of the solution.

Our focus in the preparation phase was to define and understand the subsystems and components that might be part of a blockchain application. This led to more research on currently available projects for building a Blockchain. We found two main open-source projects during our research: Hyperledger and Tendermint.

Hyperledger Iroha vs Tendermint

Hyperledger Iroha is a platform for developing Blockchain applications. It provides permissioned Blockchains. It is focused on supplying tools for fast application development. The project comes with many prebuilt commands that allow developers to model their digital assets and build a permissioned system around them with minimal risk of faults. It is like composing an application using prebuilt logic.

Tendermint is software that handles consensus mechanisms and provides an API for interacting with the consensus engine. Using this API, developers can build their own sets of deterministic rules and model digital assets. This API provides complete freedom in defining the components of the system, such as permissions, roles, actions, digital assets, and their representation.

Deciding technologies for developing Blockchain solutions

It was clear to the team that building a system from scratch in 24 hours is going to be extremely difficult. And focusing on such a challenge might imply not finishing the competition. On the other hand, using a tool like Hyperledger would imply that very few or just a single component will be built by the team. This means that we will not be aware of several functionalities implemented behind the scenes.

We might not even have control over how many resources are used for actions such as message signing or resources for different persistent layers. Hence, the team decided to use Tendermint as it supplied a good balance between prebuilt functionality and components that can be built independently.

During preparation, the team spent most of the time understanding Tendermint as it was handling complex parts of the software. The main area of focus was the interface for communicating with Tendermint, internal working of Tendermint processes, deployment requirements and scaling of network, fault tolerance and recovery mechanisms.

Together with Tendermint, the list of tools and technologies that were selected are the following:

• Tendermint, which handles Peer-to-Peer (P2P) Network, Consensus Mechanism, Persistence for Blockchain

• Java 17 for building Validators

• Xodus for the Persistence of digital assets

• Protocol Buffers (Protobuf) and open-source framework gRPC for communication between Tendermint and Validators

• Docker for the deployment of various nodes that run Tendermint and Validators in a single network over different containers

• Java and Spring Boot for building Client Backend Application

• Angular for Client Frontend Application

Communication protocols between different systems:

• RPC (Remote Procedure Call)

• REST (Representational State Transfer)

The Architecture

One of the most important parts of software development is having a clearly defined architecture. It is extremely helpful to know how we divide the problem into smaller parts before the development phase. Which components will be used to solve which sub-problems? Which components will come together in a single system, and how many logical systems will we have? How will communication be achieved between these systems?

After several discussions, the team identified key components that should be built to get a working Blockchain application. These components included the following:

• UI / UX for visualization of digital assets and related information

• Client Backend Application for communicating with the network to create digital assets, execute transactions and query information

• Peer-to-Peer Blockchain Network; this network runs multiple nodes, and a client can connect to any node

• Consensus Mechanism, part of Tendermint Core and uses Byzantine Fault Tolerance to achieve consensus

• Persistence for Blockchain. Blockchain is persisted in a LevelDB by Tendermint core.

• Transaction Validators. RPC API which does custom command serialization using query params; Java applications that manage state of assets and validate transactions that can change their state

• Persistence for the Digital Assets on Validators, which is key in validating transactions as the transactions are requested to change the state of these assets.

• Authentication, achieved via communication between Client Backend and Blockchain Network

The Hackathon in Action

The action day is here, and the team comes together for the final discussion and decisions for implementation. Given the nature of the experience present in the team people volunteered to implement distinct parts of the system. It was one of the most collaborative projects we have participated in so far.

Dividing Team Responsibilities

To get the best out of the team skillset, we divided the team into 5 major groups.

1. Java experts took upon the responsibility to implement the Backend for the end client and Validators. This group was tasked with creating a Validator that can verify transactions to create a wallet and transfer coins from one wallet to another. Validators will run in a separate thread and talk to Tendermint via gRPC (open-source project for RPC). An end client will also be built to send requests for both creating and transferring coins.

2. Members with experience in Repository Patterns and Persistence technology took on the responsibility for Persisting Digital Assets (wallets) and developing query mechanisms. Persistence was achieved by using the JetBrains Xodus project. Querying will allow end clients to list available wallets, create wallets and check balances.

3. Members with experience in DevOps and network configuration took responsibility for deploying the Tendermint Network. The network should be launched with a minimum of 4 Nodes and 4 Validators. Each Node should be paired with one Validator; paired Validator should be able to communicate over a TCP port. But no Validator should be exposed publicly. Every Node will be exposed publicly to communicate with an end client.

4. While other engineers took authentication protocols and permissions for user transactions. Authentication must be done using private and public key signatures. The end client must sign all the transactions to validate their identity. For permissions, special private keys will be given to selected end clients. An end client with a special private key for permissions and their personal private key will be able to sign special requests.

5. Angular experts worked on developing a UI to enable user account creation, transaction requests and displaying queried asset information from our Blockchain Network. The UI Container will talk to the end client running on the same machine, i.e., localhost.

To keep progress between all the groups synchronized, we had short catch-up meetings every 2 hours.

The first 8 hours

So far, everything looked good, and the team direction was clear. A strong start boosted the team's morale, and our goals were easily achievable. In the first 8 hours, Groups 1, 2 and 3 finished their tasks. Group 4 still worked on implementing the Authentication. At this point, heavy lifting for all the components is done. The team will now focus on integrating all the components and ensuring they all work together.

The pitfalls of pseudo-random methods

And as every software project goes, we discover the most dramatic bugs during the integration of components. This was the case with our solution, too; although everything functions as expected transaction from one wallet to another was still producing runtime errors.

After hours of scrolling through logs, the team realized that error came from using a pseudo-random function in Validators for generating UUID. This implied a single Wallet ID is different on every Node of the Network. A patch was added to fix the issue, implementing a custom hashing function.

At this point, we realized that the deterministic behaviour of Validators is especially important in our Blockchain. Each Node with a Validator installed must produce the same outputs for the same inputs; otherwise, the Consensus Mechanism will fail.

The last mileLast remaining 8 hours, Integration is done; the only things remaining are Group 5’s building UI and Group 4’s adding permissions to users. A technical solution working through CLI does indeed provide Proof of Concept, but a UI Demo is immensely powerful.

After a long discussion, the team decided to prioritize the UI and leave only two members to focus on Group 4’s tasks. If the task is not achieved in the next 2 hours, the team will scratch it from the list. It was a hard decision to make as members were incredibly involved in making it work. Unfortunately, two hours later, the task still needed to be completed and was then dropped so the team could focus on creating a solid demonstration for the Jury.

Since 75% of the Jury were non-technical people, preparing a good presentation and a working UI was important. Members used Microsoft 365 PowerPoint to work simultaneously on the slide to ensure the whole team could build a solid presentation. Again, it was one of the most collaborative teamwork.

Finally, everything was in place, even though we sacrificed a feature, but it was a worthy sacrifice as the team had a strong presentation and a working demo. Looking back, our demonstration to the Jury was the key part of our team winning the competition.

Explorations Into Network Solutions After Hackathon

The team was contemptuous of what was achieved during the event and decided to continue their exploration.

The next topic on the list is peer-to-peer networks. This is a key component in building a decentralized Blockchain solution. Such networks can be created using different algorithms. Some commonly used algorithms are Kademlia Distributed Hash tables and gossip protocols. Choosing one algorithm over another for a Blockchain solution can affect its scalability, resources used and network stability.

After going through this whole experience, it does feel like we’ve made a lot of progress demystifying the building of Blockchain applications. Yet we’ve just scratched the surface. Although one thing is clear to us, building a professional solution will require us to understand the functioning of several different components, including the components we built from scratch during the Hackathon, Peer-to-Peer Network, Consensus Mechanisms, etc.

Without this understanding, choosing any solution projects like Hyperledger, Tendermint or custom application might lead us into many pitfalls. Specifically, when building solutions for regulated businesses like Banking, where security, high availability and performance are essential.

Join our community of problem-solvers