What makes development on blockchain different?

Published 19.2.2024

Building on blockchain involves a paradigm shift from traditional programming and requires a thorough understanding of the blockchain’s decentralized model. Smart Contract developers have a specific set of functions at their disposal for developing decentralized applications (DApps). They have to build a secure DApp on the first try. In this article, we will explain the differences between developing regular applications and blockchain applications. We will look at a script written in Aiken and SC written in Solidity.

How Is Building On The Blockchain Different?

The major difference between common programming languages and blockchain languages is their use cases and design principles. Common programming languages are general-purpose and can be used to develop a wide range of applications. On the other hand, blockchain languages are often designed with specific features to support the development of decentralized applications (DApps) and Smart Contracts (SCs).

Developers using traditional programming languages have a huge number of libraries at their disposal that allow them to write almost anything. These libraries, developed over many years by the global developer community, provide pre-written code for a wide range of functionalities from handling file I/O to complex machine learning algorithms. This vast ecosystem of libraries enables developers to build applications quickly and efficiently, without needing to reinvent the wheel.

However, when it comes to blockchain development, the landscape is quite different. Blockchain programming languages such as Solidity for Ethereum or Plutus for Cardano, while powerful, do not have the same breadth and depth of libraries available. This is partly due to the relative newness of blockchain technology and the specific requirements of writing smart contracts.

Blockchain programming languages are designed with a specific focus on cryptography and fund manipulation. Furthermore, it can be the creation of a new type of token, defining control over tokens, transfer conditions, etc.

Developers who write SCs do have control over the logic and rules encoded in those contracts. However, they do not have control over certain aspects of the blockchain network itself.

For instance, developers cannot control the network throughput, which is the rate at which transactions are processed and added to the blockchain. This is determined by various factors such as the network's protocol, the number of nodes, and the consensus algorithm used.

Similarly, developers cannot control or prevent the potential manipulation of blocks by block producers. The integrity of block production is maintained by the blockchain's underlying consensus algorithm and network rules.

While developers can dictate the behavior of their SCs, their execution is dependent on (and may be limited by) the blockchain network.

This separation of concerns is a fundamental aspect of the decentralized nature of blockchain technology. It ensures that no single party has complete control over all aspects of a blockchain network, thereby enhancing its security and trustworthiness. Although this is a desired feature of blockchain, some developers may feel somewhat limited or dependent on external factors.

In blockchain development, code is executed on a decentralized network and must adhere to the constraints of the blockchain’s protocol. For instance, every operation in an SC costs a certain amount of ‘gas’, and developers must write their contracts to be as gas-efficient as possible. This often means that smart contracts are more low-level and explicit in their coding style.

Furthermore, once a smart contract is deployed on the blockchain, it cannot be changed. This immutability is a fundamental feature of blockchain technology, but it also means that developers must get their code right the first time.

There is no room for errors or security vulnerabilities, as they cannot be patched later. Therefore, the development process for smart contracts often involves rigorous testing and auditing. This makes the development of DApps longer and more expensive.

Although it is a challenge for new developers to understand all the pitfalls of programming on the blockchain, the decentralized model can present another pitfall.

Developing regular applications often involves creating a centralized system where a single entity has control over the data and functionality. This is in stark contrast to blockchain applications, which operate on a decentralized model. In this model, no single entity has control over the entire network. Instead, control is distributed among a network of nodes.

SCs are a fundamental part of blockchain applications. They are self-executing contracts with the terms of the agreement directly written into code. They automatically execute transactions following predetermined rules, without the need for a middleman. This automation reduces the risk of human error and fraud.

Since there is no room for error, the SC must do exactly what is expected of it under the given conditions. No third party must be able to influence the execution of the SC or stop it. The code is the law. If the SC execution fails and an unexpected error occurs, there is usually no way to save the lost funds.

Another specific feature of DApp development is that if a developer knows one environment well, such as Ethereum, he may not be ready to develop on Cardano at all. SC platforms can be fundamentally different from each other.

It Is Difficult For Developers To Migrate To A New Platform

Developers must be aware of the significant differences between SC platforms, as these differences can greatly impact the design, functionality, and security of their applications. Let's see, for example, the differences between state and concurrency.

Two prominent SC platforms, Ethereum and Cardano, provide excellent examples of how these differences can manifest, particularly in terms of state manipulation and concurrency.

Ethereum operates on an account-based model. In this model, the entire network shares a global state, which is updated with every block that is produced. This global state includes account balances and smart contract states.

Ethereum's model allows multiple users to interact with a single smart contract within a single block. However, this shared mutable state can lead to complexities and potential vulnerabilities, especially when it comes to concurrency. Concurrency in this context refers to the ability of multiple transactions to be executed simultaneously. If not handled correctly, this can lead to race conditions and other security vulnerabilities.

On the other hand, Cardano uses the Extended Unspent Transaction Output (EUTxO) model. In this model, the sending and receiving of funds are not stored as a balance but as unspent transaction amounts (UTxOs) that are associated with a wallet's addresses. These UTxOs can each only be spent once.

This model inherently handles concurrency, as each transaction output can only be spent once, and once it's spent, it cannot be used by another transaction. However, this also means that developers need to think differently about how they design their smart contracts and handle state.

Understanding these differences is crucial for developers to avoid bugs and vulnerabilities in their smart contracts. For instance, reentrancy is a common vulnerability in Ethereum SCs, where an attacker can repeatedly call a function before the first function call is finished. This is less of a concern in Cardano due to its EUTxO model.

While Ethereum and Cardano both offer powerful platforms for developing decentralized applications, they each have their unique approaches to handling state and concurrency. Developers must understand these differences and the implications they have for smart contract development to effectively build secure and efficient applications on these platforms.

Developers who understand Solidity well cannot switch to Cardano easily. In addition to having to learn a new programming language (Plutus, Aiken, etc.), they also have to deal with the specific characteristics of the given blockchain. The same applies when migrating to Solana, for example.

Transitioning from one blockchain platform to another involves more than just learning a new programming language. Each platform has its own unique architecture, consensus mechanism, transaction model, account model, and smart contract functionality.

For example, the transition from Java to C# can be easier for developers if they already have experience with concepts such as working with the Internet, databases, cloud services, file systems, etc.


Aiken is a functional programming language used for writing scripts (smart contracts) for Cardano.

In the picture, you can see a very simple validator script. The script checks if the conditions for spending are met.

The spender must provide a signature and the string 'Hello, World!'. If so, the return value of the script is True. This will allow funds to be spent.

Check out the functions available to developers. Among other things, developers can use byte arrays and compare them with each other, use several hash functions (blake2b_256, sha2_256, and sha3_256), work with a time interval, perform basic arithmetic functions, work with strings, etc.

As for functions that are more related to the blockchain, developers can work with addresses, certificates, and transactions. Furthermore, they can work with the values of ADA coins and tokens, etc.

A DApp for Cardano requires building an on-chain and off-chain part. Aiken is intended for the on-chain part only. Developers can use any suitable programming language to build the off-chain part.

In Cardano, smart contracts written in Aiken or Plutus are often smaller because they are essentially validation scripts that determine whether a transaction is valid. They operate on the UTXO model, where each transaction output carries a small piece of logic (the contract) to validate any transaction that tries to spend it.

On the other hand, Ethereum's smart contracts, written in Solidity, are stateful applications that live on the blockchain and usually have a higher level of complexity. They operate on an account-based model, where contracts have a persistent state stored in the blockchain and functions that can alter this state.

In the picture below you can see an example of the contract that manages the ownership of the digital tokens, and makes it possible to transfer those tokens between the token holders.

The first 4 lines of the contract represent the state that is stored in the blockchain.

A small enterprise application written in a traditional object-oriented programming language can have thousands of lines of code, while an enterprise application can easily have tens to hundreds of thousands of lines of source code. For example, a Boeing 787 has 6.5 million lines behind its avionics and online support systems.

In terms of lines of code, DApps are small compared to regular apps. A simple DApp might include a few smart contracts, each consisting of a few dozen to a few hundred lines of code. More complex DApps, such as decentralized exchanges or lending platforms, might consist of multiple smart contracts with thousands of lines of code.


Building DApps is a new lucrative field that attracts more and more developers every year. They can deliver increasingly efficient and user-friendly DApps despite having to overcome all the pitfalls of decentralization and the specifics of development on blockchain. The development of games and applications for mobile phones, for example, is highly competitive and saturated. In the blockchain industry, it can be much easier for a team to establish itself and become a dominant player in the field. It is tempting.


Related articles

Did you enjoy this article? Other great articles by the same author