DEV Community

Cover image for Building your next application using blockchain: Why and how
Adrián Lorenzo for The Agile Monkeys

Posted on • Edited on

Building your next application using blockchain: Why and how

Why build an application using blockchain?

The first question someone could have when considering building applications using blockchain is why doing it. It is a very important question that we believe should be asked no matter the technology or the solution that you are trying to create, since usually our objective is to solve a problem, not to use a specific technology.

Nowadays, the Web3 ecosystem is very focused on very specific use cases, but that doesn’t mean that those specific use cases are the only ones that blockchain can provide value to. I believe that the value that blockchain can provide is beyond digital assets and decentralized finance. I believe that trust is the most important value that blockchain can provide.

Trust as the value

Any individual or entity that wants to make use of a solution needs a certain amount of trust to make sure that it is going to work as expected. Sometimes this is easy to provide, but sometimes there are many environmental factors that can reduce the amount of trust that someone can have in your application. If your user has too much to lose by using your application, then they may not want to use it.

If you think that your solution is missing mechanisms to provide users with trust, it is possible that blockchain can provide those mechanisms, since it enhances trust by offering security, continuity, and transparency.

Be safe, then I can trust

Security is one of the main concerns that people currently have when it comes to building software. Without security, you can’t obtain trust, and therefore, many of the solutions that you could think of don’t make sense for the user, since they don’t really solve the problem. When we create an application that provides value to the user, you don’t want the rules of the games to be violated by an external party (hacker) or an internal party (team insiders, other users, etc.), because it means that the value that you offer to the user could be lost forever.

And when we talk about value, we need to talk about data. The internet and all the applications that we use nowadays are driven by data, and it even serves as the main way of generating revenue for some companies. That is why protecting the data that drives your application is essential.

Current blockchains have been designed with security as their main objective. If you don't trust any of the individual actors within a platform, it doesn't mean that you can't trust the system as a whole. The system has been designed to give more power to those actors who have a lot more to lose by being dishonest.

Expect continuity, then I can trust

If the data that is hosted in your application is not guaranteed to be preserved through time, many parties involved in the application have to accept the risk of potentially losing valuable data, which could decrease user trust.

Blockchain transaction records immutability allows users to keep track of every data entry, forever. You can expect your data to always be stored in the system, or for it to be stored as long as predicted.

Be transparent, then I can trust

In terms of the business logic rules of the game, when many parties are involved, it is essential for cooperative solutions to keep data transparent, so people can trust each other and therefore, be confident when making use of the cooperation tools provided.

If the application you are using is also being used by many different parties that you don’t trust, you can verify if dishonest participants are using the application maliciously. This would therefore affect the value that the application is providing to you.

Blockchains allow users to have a full history of the actions that are committed to the system, without the possibility of modifying previous records.

Smart contracts

Smart contracts are a solution provided by general-purpose blockchains (also known as layer-1 solutions) to program limited applications that run and store their data inside the network nodes. They are usually executed in a virtual machine. Currently, the Ethereum Virtual Machine is the most popular one.

You can use programming languages like Solidity or Vyper to program smart contracts that run in the Ethereum Virtual Machine.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

// Example contract in Solidity
contract Storage {
    uint256 value;

    function store(uint256 _value) public {
        value = _value;
    }

    function get() public view returns (uint256) {
        return value;
    }
}
Enter fullscreen mode Exit fullscreen mode

This solution is the response of these general-purpose blockchains to those use cases that would benefit from the network effect of the blockchain. The advantages of this mechanism are pretty clear:

  • The application takes full advantage of the network effect.
  • You can interact with other smart contracts in the ecosystem.
  • The application is hosted in the same ecosystem as any other app, reducing the entry barriers for users to use it.

Smart contracts are great, but not always enough

However, smart contracts have some critical disadvantages that can cause huge drawbacks for many solutions:

It is not scalable

Being in the same environment as everyone is a great advantage in a small number of use cases. For example, solutions that are interconnected with many other “public-good” applications and have complex interactions (more than just querying) between them. Also, the security advantages are important for certain use cases.

However, most applications do not take advantage of this, since the dynamics of an application are usually limited to a small set of interactions, or don’t need such an amount of security granularity.

The thing is that usually, the most used general-purpose blockchains, those that have the best network effect, are VERY secure. So secure, and so decentralized that they are often very slow and not scalable. This problem is generally called The Blockchain Trilemma.

Many different smart contracts are being executed, and therefore, requesting the same amount of security and decentralization as any other, even if their use case is not taking advantage of that level of security. The consequence of everyone taking advantage of the maximum network effect is a saturated network that is not able to scale when the amount of users running transactions is unsustainable.

Your application could be undestroyable and super-interconnected, but if one million requests per minute make your application unusable for those users, maybe you are not as interested in that amount of security and interconnection as you thought.

It is not private

Taking full advantage of a public network has the disadvantage of also submitting your data to the public domain.

To have a decentralized application doesn’t necessarily mean that you want to let everyone know about your data and let them participate in your network. In many organizations or cooperatives, individuals could have common objectives but also common secrets that they don’t wish to share with anyone other than the participants of the organization. Ideally, everyone should be able to be a participant in the system they trust.

It is limited

Smart contracts offer a very limited set of instructions that can be run. It is much more limited than programming your own traditional application, for example, in the Java Virtual Machine (JVM).

This limitation means fewer attack vectors, but also means less configuration and more work in many cases.

Application-specific blockchains

Instead of making use of a general-purpose blockchain to build your application on top of it using smart contracts, a great alternative could be to build your own blockchain, as your application.

An application-specific blockchain is just a blockchain that understands and provides operations and queries for your business logic. It uses the necessary resources that your application needs to run, and is configured to match the requirements that your application has.

Since your blockchain is being used for just one purpose, it means that your resources are being used for just that purpose, and therefore it is maximizing performance. Also, the system can be customized as you want to enable the best security, decentralization, and scalability configuration for your use case.

In addition, since you are building everything “from scratch” and your business logic is not running in a limited set of instructions, you are free to make use of any of your programming language tools.

Independent networks: to be isolated or not to be?

Having a custom network that runs independently from other networks has many advantages, but it also has disadvantages that we can’t ignore.

If your application is hosted as an independent network blockchain, it means that it is not going to take advantage of the network effects that a major network is going to provide, like security and decentralization.

Also, if your system wants to communicate with other networks, those networks should understand the same language as your own, and therefore, have a standard communication interface to make use of.

Permissioned blockchains

In some cases, this isolation is something that your requirements may take advantage of. If you don’t want everyone to be a participant of the network, a permissioned blockchain can match the requirements of your network.

Taking advantage of network effects with interoperability solutions

Now, imagine that you could have an independent network that could make use of some of the advantages of a major network without losing its independence. To allow that, there should be a mechanism that enables interconnection between those independent networks so they can fulfill their wishes.

Blockchain interoperability solutions allow independent networks to take advantage of at least part of the network effect of the major network without compromising scalability or configuration.

There isn’t one single way of enabling blockchain interoperability, and the way the mechanism is architected offers different capabilities to the solution you want to create.

Sidechains

A sidechain is a blockchain network that is interconnected to a bigger network, usually called the “mainchain”, following a chief/worker pattern.

The sidechains and the mainchain communicate with each other with a specific protocol. The sidechains have to validate their state with the mainchain periodically to remain part of the network, by submitting proofs. This allows the sidechain to have an extra layer of security by obtaining direct validation from a bigger network and therefore, taking advantage of its network effect.

Some key characteristics of sidechains are:

  • The main network is never affected by the problems that sidechains could face.
  • The sidechain doesn’t need to be public or have the same implementation as the mainchain.
  • Since you don’t have to validate each sidechain’s transaction with the mainchain, the mainchain is able to scale more effectively.
  • The mainchain can act as a bridge between sidechains to communicate if necessary.

Inter-communication protocols

Another solution for better scalability through interoperability is the implementation of inter-communication protocols. One of the most popular inter-communication protocols is the Inter-Blockchain Communication Protocol (IBC).

This protocol allows chains with similar core configurations to interact with each other.

Sharding

Sharding is the database architecture concept of dividing a database horizontally into independent databases, called shards. Each shard has different data and it is usually located in a different server, to allow better scalability.

The sharding concept is being introduced in blockchain networks too: the idea is to create different shards (subnetworks of nodes) that store a part of the blockchain. Each shard is going to be able to communicate with other shards and participate in the network as one.

Since no one should store the whole state and receive transactions to obtain transaction finality, the network is going to be able to scale more effectively.

Bridges

A bridge is a mechanism to interconnect blockchains through an “information exchange” using an intermediary. There are two types of bridges:

  • Trusted bridges: based on trust assumption, and handled by a centralized entity.
  • Trustless bridges: based on an algorithm, usually written in a smart contract.

A bridge is made specifically for interconnection between a set of specific blockchains with specific configurations. It doesn’t act as a protocol.

Does this mean that I should discard smart contracts?

Smart contracts are VERY useful for many use cases. There are a lot of applications like Uniswap, Filecoin or Developer DAO that make an excellent use of smart contracts to implement their applications.

In this article I have analyzed some of the current advantages and disadvantages of building smart contracts and application-specific blockchains. Depending on your use case, you may find one of the solutions more suitable than the other.

Wait, should I implement application-specific blockchains from scratch?! 😦

You could actually implement any of these mechanisms and blockchain specifications from scratch, but you probably don’t have the time and the resources to even consider it.

However, we are in luck. There are a lot of useful open-source tools that allow developers to build application-specific blockchains without having to worry about low-level implementations and cryptographic details. This is done by making use of industry-standard specifications and protocols backed up by the community.

In my next article, I’m going to review some of the most relevant solutions that you can find in the market right now.

Stay tuned!


This article represents a very small piece of what we are building at The Agile Monkeys. If you like what we do, you may want to join us in our journey!


Photo by Shubham Dhage on Unsplash

Top comments (0)