The Process of Creating Decentralized Apps (dApps)

Nowadays we are using ordinary traditional apps as part of our daily tasks. The applications that we are using are pretty similar, even if they look different. All of them have the same architecture structure and all of them are relying on synchronizing data with centralized servers. 

On the other hand, a decentralized application has a different architectural approach and they are working on distributed ledger technology called blockchain, where there is no central point of failure nor third parties involved. This makes the technology revolutionary and attractive for new opportunities. Web3 and dApps are such new opportunities. 

This article will cover the process of creating such applications and why they are needed, as well as challenges during implementation.

Challenges of Creating Decentralized Apps

The process of creating decentralized applications is complicated, and according to me, the first challenge in order to create such an app is to understand what blockchain is, how it works, and what kind of problems it solves. This will help to understand why the application needs to be decentralized and why it might be successful or not.

Such a deep understanding will help you to understand your project and define the risks. Knowing all the key facts and major concepts of consensus algorithms, blocks, and transactions will help you to scale the application if needed. The architecture of dApp is quite different from traditional applications. Decentralized applications require a unique system design to achieve high security, reliability, privacy, and usability.

Another challenge is to define the purpose of the dApp, who will use your application, and how they will benefit from working specifically with a decentralized application. This process is described in the whitepaper of the app. An example is the Ethereum Whitepaper. It looks like the image below:

The whitepaper is the document that explains the technology and purpose of the app. It tells prospective investors how the dApp was conceived and highlights its purpose, phases of development, team involvement, how a certain problem is solved, and more. So, in addition to goals, the whitepaper can also show how the dApp will really work, for example, it may include more technical details about which Blockchain network will be used.

Then we come to the fundraising of the project. While in the past (around 2017) it was a big deal to do an ICO (initial coin offering) in order to raise the funds that you needed to develop your projects, nowadays they are not so preferred. Now we have different entities that are doing blockchain ventures in order to support and invest in different Blockchain technologies. Obtaining such venture capital mainly comes at a far later stage of the whole process of development. The ICOs are without limitations and allow companies to raise initial funding before they would otherwise be able to through venture capitalists or lenders. Venture capitalists are more likely to come up with business guidelines that need to be followed.

Why Do We Need dApps?

Before talking about why we need dApps and their advantages and disadvantages, let’s first do a deep dive into their architecture and how they are operating.

The dApps are allowing users to engage and process transactions directly against the public ledger without the layer of authority where validation of a single point is needed. Frequently, this is called a new revolutionary internet because censorship as well as owning somebody else's data is not possible. Everything is in the hands of the users and there is no central point of failure.

The decentralized apps quite often look the same to the users on the top of the browser. The only difference is that behind that look there is a Smart Contract and connection with a wallet. Behind that, the connection with the wallet opens a completely new world where this dApp is communicating directly with the blockchain, or more specifically, with Smart Contracts, which hold the business logic of the dApp or part of it, making it worth it to be deployed on the Blockchain technology.

The decentralized apps have some major differences versus the traditional apps, the first one being that behind the dApps there are the following architecture components:

• Blockchain Protocol - this is the network protocol that the app is working on
• Smart Contracts - this is the business logic defined in form of programming functions

A simple smart contract looks like this:

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


contract Deposit {
   uint public balance;


   function add(uint a, uint b) public pure returns(uint) {
       return a + b;
   }


   function getBalance() public view returns(uint) {
       return balance;
   }


   function deposit() public payable {
       balance += msg.value;
   }
}

You can see the following components:

Line 1: The license of the contract

Line 2: The solidity version of the compiler needed to compile the file

Line 4 and below: The actual representation of the business logic of the smart contract

Another difference is that dApps do not require registration with profiles. The crypto wallet is the user side part, which is used to “log in” to the dApp and start using it, so they do not require and save user sensitive information.

Now speaking about advantages and disadvantages, the first advantage of the dApp is that there is no central authority, which means there are no intermediaries and users can directly interact with each other. This on the other hand makes the process transparent and trustless, yet secure. When we talk about trustless, it refers to a quality of a decentralized blockchain, whereby in using the network there is no need to rely on trust in a third party.  Another cool feature of the dApps is security and data integrity, which makes it truly difficult to hack a chain and take over a decentralized application. Privacy is another important advantage of dApps. All transactions can be traced on the blockchain, yet they are completely anonymous and only a public address is behind them. 

The drawbacks of dApps are frequently connected with maintenance, scalability, user-friendly interface, and some challenges connected to the speed of the blockchain network. A dApp is more challenging to be managed than a regular app because the blockchain specifics need to be taken into account, for example, the immutability and the bugs that need to be solved into the smart contracts as well as the whole knowledge that needs to be gained in the process. Apart from regular software development, these bugs are sometimes expensive and impossible to be solved. For such cases, upgradeability strategies are needed, but they need to be planned on the architecture level of the design of the Smart Contracts. 

Another thing is the need for scale and that need depends on the network congestion. A good example is with CryptoKitties that brought all transactions on the Ethereum blockchain to a screeching halt when thousands of people decided to try this dApp. Such hype led to delays in some of the transactions and higher gas prices. 

Apart from the cons with the blockchain network layer, large amounts of dApps are built by developers who don’t necessarily have much UI/UX design experience and considerations and they may look hard to operate for a regular everyday person. That’s why the adoption of decentralized applications has a long way to go and my suggestion for solving this problem is to standardize the blockchain UI/UX terminology.

From Whitepaper to Mainnet

The first step of the actual creation process is to start with the architecture of the application. This architecture will include the Smart Contracts as well as any other interfaces for communication with them - SDKs or Front-end interface. Verification of the idea with a prototype is a must-have, and right after that the development process can start and all the building blocks/components can be designed and built simultaneously. An example of this is to create a minimal workable example showing only the main features of the application and to verify the idea in front of the community and the investors.

Smart Contracts and their architecture is what makes dApp possible. This is the most important part, because this part will be implemented into the blockchain. How is this architecture created? The business logic that is published into the whitepaper is transferred in the form of rules that need to be implemented in those contracts. They are separated by this business logic as well as by the Solidity programming language features and limitations. Such architecture is not easy, as you need to think about several aspects while reaching to cover the logic requirements:

• Consensus Algorithm Specifications
• Security
• Readability
• Gas Optimization
• Scalability
• Free of expensive bugs

The process can start with drawing diagrams for designing and planning the Smart Contracts Interfaces. What functions need to be implemented, what kind of input and output parameters they will have and how those contracts would be upgraded if needed. This process can take some time and depends on the complexity of the dApp. If the dApp will include tokenomics or other DeFi functionalities, it will need a system of contracts with libraries and contracts that are deploying other contracts as well as upgradeability patterns. Such processes are described in the diagrams before the actual development process.

During the deployment phase, a project is created which should consist of the following components:

• The Smart Contracts itself
• The compiled Contracts ready for deployment
• Testing scenarios (both unit and integration tests)
• Deployment scripts
• Verification Scripts
• Another helper methods needed for the development process

Once those procedures have been done, it is good practice to submit the Contracts for external audit. This can happen as soon as the Smart Contracts are tested with unit and integration tests, and we encounter 100% code coverage. Then the audit is performing a detailed evaluation of a smart contract's source code to uncover possible failure points, security flaws, and poor development practices. While code audits can be automated, here I am referring to human-aided code analysis. They are important and give the community, investors and users higher assurance of smart contract safety. Audits benefit from extensive analysis performed by cybersecurity professionals and detect potential vulnerabilities or bugs that could break the smart contract functionality.

The external audit can take up to months, and this should not affect the development process of the whole dApp. Rather, it will include FE interface or SDK, and their development process can start with the usage of still unaudited smart contracts. It’s a good practice to deploy those contracts on a local/remote test network and start to communicate with them (consume the logic) in order to create the other components of the dApp. Those iterations can also reveal vulnerabilities that exist outside the Smart Contracts, but can still affect them. For example, during the development process of the other components, we can discover vulnerabilities arising from flawed interaction with off-chain components.

The mainnet deployment of the dApp is done right after all the security issues, bugs, and vulnerabilities noted in the audit are reviewed and solved.

Testing Smart Cоntracts

Smart contract testing is a process of verifying the functionality and behavior of smart contracts, which are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. It involves writing and executing test cases that simulate various scenarios to ensure that the smart contract works as intended and is secure from vulnerabilities.

Examples of smart contract testing include:

• Unit testing: This involves testing individual functions or modules of the smart contract to ensure they behave as expected.
• Integration testing: This involves testing how different parts of the smart contract interact with each other.
• End-to-end testing: This involves testing the entire smart contract system, including its integration with other systems and its behavior in different scenarios.
• Security testing: This involves testing the smart contract for vulnerabilities such as the reentrancy attack, where an attacker can repeatedly call the contract and drain its funds.
• Performance testing: This involves testing the scalability and efficiency of the smart contract, especially in terms of gas consumption and transaction processing time.

Here's an example of unit and integration testing smart contracts in Solidity with Chai and Mocha:

pragma solidity ^0.8.0;

contract SimpleMath {
   function add(uint a, uint b) public pure returns (uint) {
       return a + b;
   }


   function sub(uint a, uint b) public pure returns (uint) {
       return a - b;
   }
}

The unit tests:

const { expect } = require("chai");

const SimpleMath = artifacts.require("SimpleMath");

contract("SimpleMath", () => {

   let simpleMath;

   beforeEach(async () => {

       simpleMath = await SimpleMath.new();

   });

   describe("add", () => {

       it("returns the correct result", async () => {

           const result = await simpleMath.add(3, 4);

           expect(result).to.be.bignumber.equal(7);

       });

   });

   describe("sub", () => {

       it("returns the correct result", async () => {

           const result = await simpleMath.sub(4, 3);

           expect(result).to.be.bignumber.equal(1);

       });

   });

});

In this example, Chai is used to write assertions and Mocha is used to structure the tests. The SimpleMath contract is deployed before each test, and the add and sub-functions are tested individually. The expect function from Chai is used to verify that the expected result is returned by each function.

Integration Tests:

const { expect } = require("chai");

const SimpleMath = artifacts.require("SimpleMath");

contract("SimpleMath", () => {

   let simpleMath;

   beforeEach(async () => {

       simpleMath = await SimpleMath.new();

   });

   describe("integration", () => {

       it("returns the correct result", async () => {

           const result1 = await simpleMath.add(3, 4);

           expect(result1).to.be.bignumber.equal(7);

           const result2 = await simpleMath.sub(result1, 3);

           expect(result2).to.be.bignumber.equal(4);

       });

   });

});

In this example, the SimpleMath contract is tested for integration between its add and sub-functions. The tests start by adding 3 and 4 and then subtracting 3 from the result, verifying that the final result is 4.

It is important to thoroughly test smart contracts before deploying them on the blockchain, as once deployed, it is extremely difficult and often impossible to modify or correct them.

Conclusion

In my opinion and based on my experience, the most important part of creating a decentralized application is testing its smart contracts. An application free of security flaws and bugs will complete the security of the contracts and thus will help the application to become popular and viral.