How to design a blockchain application architecture?

Blockchain apps, also known as dApps, are becoming increasingly popular among businesses. However, when it comes to blockchain adoption, there is still a maturity barrier. The level of trust that people have in the Blockchain varies. We can say that the friction is caused by a lack of understanding of dApp architecture concepts and their ability to solve complex business problems.

How should a dApp be designed and curated to be truly efficient? API management, architectural capabilities, system integration, transformation and connectivity, security performance and resilience – there are far too many variables to comprehend.

Taking the lead, this insight explains the fundamentals of architecture design for blockchain applications in order to help startups and enterprises understand dApps as reliable and stable enterprise-grade solutions.

• Decentralized app Vs Centralized applications
• Types of decentralized applications
• Categorization of decentralized applications
• dApp architecture designing with a sample dApp
• Bringing up a dApp architecture together
• Factors that matter for dApp architecture designing

Decentralized apps Vs Centralized apps

Control over data

Centralized apps are more private in the sense that data stored within them can be made public or private at the discretion of the single entity that owns that specific application. To put it another way, users have little to no control over the data collected by centralized apps.

Speed

When it comes to transactions, centralized applications are faster because it requires only reaching out to one system to get that single transaction completed. Because centralized apps require fewer resources, they are less expensive.

Transparency

Decentralized applications are more transparent than centralized applications because multiple stakeholders can participate in the entire network through their nodes, and the data is available to every node or stakeholder. Whatever information stakeholders want to make public, they can do so. Decentralized apps are maintained by multiple stakeholders, each of whom has a say in the consensus of the actions facilitated by the app. As a result, actions and data within dApps are more trustworthy because it completes a transaction only when a consensus of more than 51% is achieved; in some cases, it’s 66% or higher. The percentage varies depending on the platform.

So, the fundamental difference between centralized and decentralized apps is that centralized apps are managed by a single entity, whereas decentralized apps are managed by a network of participating stakeholders, all of whom have equal access to the data. Data is verifiable and trustworthy here.

Blockchain applications are mostly decentralized. There are, however, three options:

1. On-chain applications, which may or may not be decentralized
2. Off-chain applications that are essentially centralized
3. Fully decentralized applications based solely on blockchain protocols or distributed application protocols.

Types of decentralized applications

Several layer one protocols have emerged in recent years. Not only Ethereum, but also protocols such as XDC, Solana, Cardano, and others. These protocols serve as the foundation for dApp development, and then there is the ecosystem for building apps or products on top of it. The ecosystem and its SDKs, tools, and utilities assist the developer community in building products on top of the layer-one protocol.

Swap is an on-chain application that allows the exchange of one token for another within the same network.

Bridges are on-chain applications that connect two layer-one protocols or blockchains.

Decentralized exchanges are online platforms for a cryptocurrency exchange that allow direct peer-to-peer cryptocurrency transactions without the use of an intermediary.

Analytics platforms are essentially performance dashboards built on-chain to display data from these chains, primarily network data such as network speed, active nodes, number of blocks created, speed of file retrieval, and so on.

Browser extensions: Some analytical platforms are typically off-chain in nature. Chrome extensions, for example, or browser extensions. Though they are off-chain products, they communicate with the network primarily through the web3 protocol, allowing users to read and write through extensions.

Explorer: This product allows users to explore the entire blockchain network, see what activities are taking place, and keep track of various transactions. So, an explorer is a window or interface that allows users to view a network.

Metaverse: The term “metaverse” has gained popularity, even in the field of decentralized applications. Metaverse is essentially a virtual world with digital 3D assets that users can interact with to enhance their digital experiences. Having 3D assets is one component of a metaverse project, however, there are other components. Take the example of a gaming metaverse. Along with 3D assets, another important component is the gaming engine, which serves as the foundation for the gaming or virtual environment.

In a decentralized metaverse, blockchain stores all the meta-information around assets and their transactions. It facilitates transactions and trade-offs based on various events. Decentralized Metaverses have a hybrid environment; for example, metaverse marketplaces for NFTs are hybrid, despite the fact that the majority of the work is done on-chain. Also, there is data that is stored in multiple locations, on-chain as well as off-chain.

Categorization of decentralized applications

As we discussed some examples of enterprise and consumer-focused DApps in the above section, we can divide dApps into four categories:

Record keeping dApps

These are used to keep health records, supply chain records, land records, and so on. Blockchain is increasingly being used by businesses to create these record-keeping or data-keeping applications.

Asset digitization dApps

Many businesses are exploring the idea of digitizing their assets for a variety of reasons. Some want to develop their intellectual property, while others require it for loan staking and other purposes. As a result, enterprises are developing blockchain applications to achieve asset digitization, which is occurring not only in the enterprise but also in the consumer space.

Decentralized workflow dApps

There are multiple businesses flows in the business world, and the workflow of each department overlaps with the other department at various touchpoints. Then there are multiple stakeholders at various levels. A decentralized workflow application is more of a business flow management application that attempts to bring together different stakeholders at various stages so that they can coordinate with each other in a transparent, trustless manner. They can, for example, sign documents and store them on the Blockchain.

The insurance industry processes insurance claims using blockchain decentralized workflow apps, as blockchain improves data trust. There are numerous decentralized workflow use cases in insurance and claim management, among other areas.

Consumer-focused dApps

There are a variety of consumer-focused decentralized finance applications available, including peer-to-peer lending platforms, crypto loan platforms, exchanges, and staking platforms. Other consumer-focused blockchain applications include voting apps and loyalty programs.

dApp architecture designing with a sample dApp

Consider the following scenario: you are attempting to create a Blockchain-based aircraft maintenance record-keeping application. The application’s concept is that when a user searches for a flight, say from New York to San Francisco today, the app begins to show how much carbon emissions the flight will produce by retrieving the aircraft maintenance record. Perhaps the app could simply display red, yellow, and green lights to indicate the aircraft maintenance status of each flight, assisting users in deciding which flight to take.

Data Gathering

The first step for the application is to collect all data, beginning with the manufacturer data. Manufacturers of aircraft can send all data related to that aircraft via a smart contract. The aircraft manufacturing data can be structured within a blockchain and used by the airline company. Similarly, procurement data will be stored on the Blockchain. Using procurement and manufacturing data, the airline company can easily create electronic flight logs or any other information logs required for any other system. In parallel, the flight logs and manufacturing and procurement data can be utilized through the smart contracts by MRO service providers to generate maintenance data.

So at the first layer of the dApp architecture development, all types of maintenance data and support data are captured and gathered in the Blockchain.

Data Processing

The next step is to process the data after it has been captured and structured. Now that the data is in the Blockchain, the next architectural requirement is interfaced through which auditors, customers, or resale agencies can interact with the app and trust the data.

Designing and developing of dApp interfaces is a multi-dimensional process. A lot of factors and attributes need to be factored in to design the interfaces of a dApp. The following section explains how the dApp interfaces are conceptualized and built, what factors are to be considered and how to bring up everything together. For easy understanding, we will continue referring to the sample dApp- the aircraft maintenance record keeping application.

Bringing up a dApp architecture together

As previously stated, the first layer of dApp architecture development is data capturing on the Blockchain. For this, the developers or architecture team must first decide on the best blockchain platform based on the application’s use case. Referring back to the sample dApp discussed here, it can be developed in a couple of blockchain platforms. One possibility is a permissioned Blockchain, in which only the permissioned stakeholders capture and gather data.

Then there will be a public blockchain platform, such as XDC or Ethereum, where all public information will be stored in complete transparency for end-users to see. Then, for data transfer, bridges could be built between the permissioned and public Blockchains.

Factors that matter for dApp architecture designing

1. Blockchain Protocol

Now, the immediate question is which blockchain protocol to pick. It can be decided based on 8 factors, viz:

The type: Whether you are building a private network or bringing your data to a public network

Speed: Do you want a real-time recording of transactions or scheduled recording, like once in a day, week, or month, as required.

Bridging capacity: Do you want your network to talk to other protocols? Do you want a hybrid environment?

Ecosystem tools: What kind of ecosystem tools are you looking for?

Energy efficiency: How energy efficient is the network?

Cost: Another important factor is certainly the cost, and it includes storage cost on the network, execution cost, development cost, and all.

Once the application’s blockchain protocol(s) is determined, the next level is to pick the factors that need consideration while moving data between on-chin and off-chain. Once the Blockchain platform/platform is chosen, multiple other factors come into the picture. Some of the major factors are:

2. User identity

Regarding user identity, the first step is to determine whether to keep the identity centralized or decentralized. The identity of the user is an important factor in defining the user flow or interface. The following key points about user identity must be clearly defined: whether the user identity will be stored as a decentralized or centralized entity, where it will be saved, and what information it will contain.

In web 2, people sign up to log into systems and view data by using their Google, Facebook, or Twitter accounts, as well as their email addresses and phone numbers. In web3, this logging happens through wallets. The user identity is hidden behind the wallet in this case, and the identity is not even on the network.

So, whereas web 2 applications include identity as part of the data, the architecture for blockchain applications separates identity from data. In most cases, identity is not linked to data at all in a pure on-chain application. As a result, blockchain applications are ideal for developing applications in which data use does not need to be linked to users’ identities.

Returning to the aircraft maintenance application. Users will almost certainly want to know who performed the aircraft’s maintenance. So, in this case, identity must be made public in order for it to be transparent. However, revealing the identity of a user who is searching for a flight from New York to San Francisco is meaningless. But again, when someone tries to buy a ticket, revealing the identity gets imperative.

3. Authorization and roles

Here, key considerations include where to save authorization and roles, regulating user movements, and ensuring that roles are properly managed.

Users have control over their data in blockchain applications.Now, let’s take the example of an enterprise application to understand the context of authorization and roles. Assume an employee is in possession of an enterprise data record. In that case, the application’s architecture must take into account the fact that when that employee leaves the organization, no data breaching or theft occurs.

As a result, the application architecture design must consider what data is going on and off-chain. Certain blockchain platforms, such as Hyperledger, include authorizations and roles as part of their platform.

4. Notifications

Notifications are mostly off-chain and send alerts about the actions happening on-chain and off-chain.

5. Business Logic

There are various business logic layers in our sample application – flight maintenance record keeping. There is business logic for data acquisition to find data from various sources such as auditors, maintenance agencies MROs, etc. Here the complex part of the decision tree is to decide whether to keep the business logic in the interfaces or into the smart contract.

Business logic is made for the public, and they are trustful. The critical point is to figure out how to showcase the business logic data, whether it will be showcased as off-chain or on-chain data. Certain types of data need to be made transparent to the public, like the airplane maintenance records or who have audited airline maintenance records. Such information can go on-chain through smart contracts.

Then there could be very specific business logic, such as the flight schedule, and such a logic can be off-chain. So the developer of the application needs to consider every business logic of the application and then draw the line whether that logic is toe kept on-chain or off-chain.

There are many web 2 based applications that people are already using, so how the architecture of such an application can incorporate Blockchain? It necessarily doesn’t require starting from scratch but just utilizing the application ecosystem and trying to take out some of the information, especially the information that multiple stakeholders and end-users access, and put it on Blockchain. Then keep improving on top of it.

So basically, any existing application is converted to a Blockchain-based application by extracting data, moving it to Blockchain, and making it transparent. Moving business logic that is important for the end-user on the Blockchain helps.

6. Storage:

Another complex attribute of a decentralized application is storage. An application could have various storage requirements, such as storing the metadata and storing large files. While defining the architecture of a decentralized application, storage is very critical to define. For example, if you are building a flight maintenance record-keeping application, data in file storage could be of any logs, images, videos, maintenance records, people identities.

Doing file storage in a decentralized app is more like doing it in a hybrid place. There are two choices, either data can be saved to the cloud, like Amazon s3 with its CDNs or data can be stored on the Blockchain itself, and these data could be large files or small files.

There is a separate architecture for pure blockchain applications where data is stored only on-chain. In such an application, the data for storage is encrypted, and then the encrypted file is split into pieces, and then these pieces get saved on the blockchain network, distributed among different nodes.

When data is to be retrieved, a trigger to call for a particular file fetch the data/information from various nodes. Data fetched from multiple nodes is compiled, decrypted and then delivered. Encryption, splitting, and distributed storing render high security to data.

Pure decentralized Blockchain-based storage solutions are expensive compared to AWS3 CDNS. Thus, storing data on a decentralized network like IPFS requires architectural decisions like what to pin at the gateway, what data needs cache, and which data is genuinely required to be stored on-chain.

A hybrid storage solution works the best for decentralized applications balances cost and security. In a hyrid storage solution, the files are encrypted, and instead of storing the files on the Blockchain platform, these files are uploaded on s3. To ensure that there is no loosing of files, these files are not stored at one single cloud storage but multiple cloud storage. Rather than storing the files on the blockchain platforms since it’s more costly, only the hashes for those files are stored on the Blockchain.

So the file-hashes are there on the Blockchain, and files are stored on multiple clouds in encrypted forms. To retrieve the files, one needs to verify the file or document by uploading tha specific file back to the system, then create the same kind of encryption for the file, which will create the same hash and then compare those hashes with the hash available on the Blockchain.

7. Smart Contracts

Smart contracts have two major operations, one is to be read, and the second is to write. There is a cost associated with triggering a blockchain smart contract when you’re writing. There is a lot of complexity in determining how to trigger a smart contract, what information goes into a smart contract and when to make a call to a smart contract.

Smart contracts are made to communicate with of-chain/ external data sources or APIs via Oracles. A smart requesting contract calls the oracles and can import off-chain data to on-chain by converting it to codes that Blockchain can read. Similarly, using smart contracts, on-chain data is delivered to off-chain databases.

Putting Together

To put all the pieces together discussed so far, let’s understand that architecture designing of a decentralized application starts with deciding whether it is a public or private permissioned or hybrid application.

Then, the next important piece is Interfaces, to create event-driven triggers for smart contracts. These interfaces deliver the data from the chain to the users right on their devices. Then the next important aspect is designing a storage mechanism for the secured storing and distribution of data.