applied

sciences
Article
Architectural Patterns for Blockchain Systems and
Application Design
Fouzia Alzhrani 1, * , Kawther Saeedi 1 and Liping Zhao 2

1 Information Systems Department, King Abdulaziz University, Jeddah 21589, Saudi Arabia;
[email protected]
2 Computer Science Department, The University of Manchester, Manchester M13 9PL, UK;
[email protected]
* Correspondence: [email protected]

Abstract: Blockchain technology has gained popularity in various applications, including finance
transactions and beyond. However, developing blockchain application systems is challenging due to
stringent quality requirements, such as performance, scalability, and security. Software architecture
plays a critical role in realizing key quality requirements. Nonetheless, little work has been performed
on software architectures for blockchain applications since blockchain application development is still
a new field. This paper proposes twelve architectural patterns for blockchain application software
architectures based on 400 cross-industry real-world applications available on the Internet. We
determine the key components of each application guided by a blockchain application taxonomy we
developed. We then identify typical architectural patterns from the interactions of these components
guided by well-known software patterns, such as peer-to-peer, layered, pipe-filter, and access control.
Based on the roles of these patterns, we organize them into four architectural views comprising
four structural, two interactional, four transactional, and two security patterns. We describe each
pattern in detail using a standard form and demonstrate the patterns through a real-world blockchain
application. The use of patterns can be valuable in addressing blockchain’s unique challenges, but
creativity remains essential in crafting innovative solutions. Mixing architectural patterns according
to varying requirements can help developers communicate effectively.

Keywords: blockchain; smart contracts; distributed applications (dApps); interoperability; software

development process; software architecture
Citation: Alzhrani, F.; Saeedi, K.;
Zhao, L. Architectural Patterns for
Blockchain Systems and Application
Design. Appl. Sci. 2023, 13, 11533.
https://doi.org/10.3390/ 1. Introduction
app132011533 A blockchain is a distributed ledger with lists of records (blocks) that are securely
Academic Editor: Tomasz Górski
linked together via cryptographic hash functions [1]. Originally developed to record
cryptocurrency transactions [2], blockchains are considered highly secure due to their
Received: 27 September 2023 anonymity, auditability, persistency, and decentralization. Blockchain technology provides
Revised: 14 October 2023 a tamper-proof record of transactions, which ensures the integrity of data and eliminates
Accepted: 18 October 2023 the possibility of fraud. Additionally, blockchain transactions are transparent, allowing for
Published: 21 October 2023
greater accountability and accuracy [3].
Since its inception in 2008, blockchain technology has steadily gained popularity, with
new applications emerging from domains extending beyond the original cryptocurrency
Copyright: © 2023 by the authors.
transaction domain [4–7]. These emerging applications include voting, healthcare, sup-
Licensee MDPI, Basel, Switzerland. ply chain management, and the Internet of Things (IoT) [8]. The necessity of combining
This article is an open access article blockchain systems for real-world applications is driven by the need for a secure, trans-
distributed under the terms and parent, and decentralized system. By incorporating this technology into such domains,
conditions of the Creative Commons organizations can improve efficiency, enhance trust, and ensure data privacy for their
Attribution (CC BY) license (https:// users [5].
creativecommons.org/licenses/by/ Real-world projects have already harnessed the power of blockchain technology to
4.0/). transform their respective industries. For instance, the IBM Food Trust (https://www.

Appl. Sci. 2023, 13, 11533. https://doi.org/10.3390/app132011533 https://www.mdpi.com/journal/applsci

Appl. Sci. 2023, 13, 11533 2 of 22

ibm.com/products/supply-chain-intelligence-suite/food-trust (accessed on 22 September

2023)) uses the blockchain to enhance the transparency of the food system, Everledger (https:
//everledger.io/ (accessed on 22 September 2023)) uses it to create permanent records of
valuable items, and Filecoin (https://filecoin.io/ (accessed on 22 September 2023)) uses the
blockchain for creating a more secure cloud storage platform. These applications increase
transparency, security, and efficiency in their respective areas, optimizing existing systems.
However, the development of blockchain systems is challenging [8] due to their
high-quality requirements (QRs), such as performance, scalability, reliability, portability,
interoperability, privacy, and security [9]. As QRs are system-level requirements, they need
to be designed at the infrastructure and architectural level; furthermore, QRs are often
interconnected and their realization in a system requires the collective and coordinated
behavior of the system components and a system-level design strategy [10].
Software architecture has long been recognized as a critical area in software devel-
opment, as it plays a key role as a bridge between system requirements and implementa-
tion [11]. Software architecture focuses on the architectural level of system design—“the
gross structure of a system as a composition of interacting parts” [11]. Architectural designs
address “such key issues as scaling and portability, the assignment of functionality to de-
sign elements, interaction protocols between elements, and global system properties such
as processing rates, end-to-end capacities, and overall performance” [12]. Architectural
patterns or architectural styles have been used to document architectural design deci-
sions [12,13]. Such patterns offer structured descriptions of some well-established solutions
to recurring architectural design problems, facilitate communication between stakeholders
through a common vocabulary, and support architectural design reuse through reusable
solutions [14,15].
As blockchain systems are relatively new, work on software architecture and archi-
tectural patterns for these systems is still limited. To date, most work has primarily been
focused on the networks of blockchain hardware systems, e.g., Peer-to-Peer (P2P) net-
works [9,16]. The need for the adaptation of architectural patterns stems from the fact that
blockchain technology is still in its early stages; thus, the patterns need to be adapted to
remain effective and relevant in solving the problems that arise from changes in technology.
To address this limitation, we have developed:
• A collection of 12 software architectural patterns to support the design of blockchain
system architectures. These patterns are discovered from our study of 400 real-world
blockchain applications from different open-source blockchain platforms [17]. These
patterns are interconnected, as each describes one aspect of a blockchain architectural
design. Collectively, these patterns describe a blockchain architecture from different
architectural views: structural, interactional, transactional, and security.
The rest of this paper is organized as follows. Section 2 reviews the related work on
blockchain application architectures. Section 3 explains the identification of the proposed
patterns. Section 4 describes these patterns. Section 5 illustrates these patterns by using
them to describe the architecture of a real-world blockchain application. Section 6 discusses
the strengths and limitations of this study. Finally, Section 7 concludes this paper.

2. Related Work
There have been several attempts at developing architectural patterns for blockchain
systems. This section provides an overview of these attempts. The International Organiza-
tion for Standardization (ISO) has published a standard for Distributed Ledger Technology
(DLT) systems, where a blockchain system is a type of such a system [18,19]. The archi-
tecture has six layers: the non-DLT systems, user, Application Programming Interface
(API), platform, infrastructure, and cross-layer functions. It provides a framework for
the adoption of DLT solutions while ensuring their compliance with global standards for
security, privacy, and interoperability.
Xiwei et al. [20] proposed a taxonomy of architectural design decisions to classify and
compare blockchain systems. The taxonomy captures the impact of principal design deci-
Appl. Sci. 2023, 13, 11533 3 of 22

sions about quality attributes on the architectural characteristics of blockchain systems. The
decisions are related to decentralization, storage and computation, infrastructural configu-
ration, and other issues. In the context of blockchain-based IoT systems, Yánez et al. [21]
proposed a catalog of architectural tactics and design primitives for specific quality at-
tributes. The catalog consists of 12 design decisions that are systematically derived from
the literature for security, scalability, performance, and interoperability.
A study by Wöhrer et al. [22] discussed blockchain integration. The study elaborated
a number of architectural design options related to operational and integration design
aspects of public permissionless blockchain applications. Liu et al. [23] proposed a refer-
ence architecture for the governance of blockchain systems, focusing on how governance
fits within the development and use of the blockchain. The proposed reference architec-
ture consists of four layers: infrastructure, platform, API, and user layers. Within each
layer, the study suggested a set of design patterns to address governance-related issues in
blockchain systems.
Another four-layered architecture was proposed by Zhang et al. [24] to analyze data
privacy threats and protection methods for blockchain applications. The layers are transac-
tion, consensus, network, and application. The architecture was derived from the layered
architecture mode of Open Systems Interconnection [25]. Weber et al. [26] proposed a
multi-tenant blockchain platform architecture to ensure the data integrity of permissioned
blockchains while maintaining privacy and performance isolation. This was achieved
via anchoring the consensus state of each permissioned blockchain periodically to a pub-
lic blockchain.
Aiming at identifying a common vocabulary for the blockchain domain, Wan et al. [27]
proposed a layered architecture of blockchain platforms derived from four platforms: Bit-
coin, Ethereum, Corda, and Hyperledger Fabric. The architecture consists of five layers:
a P2P network, consensus, virtual machine (VM), API-VM programming language, and
application layers. This reference architecture was used to capture and categorize the
discussions among programmers about blockchain technologies. For Healthcare 5.0 ap-
plications, Gupta et al. [28] proposed a drone delivery scheme based on the blockchain to
facilitate the delivery of medical supplies. The architecture consists of three layers: data
dissemination, data communication, and consumer. It integrates the blockchain and drones
through the 5G-enabled tactile Internet to allow the monitoring and tracking of the delivery
among stakeholders.
On the other hand, few attempts have explicitly focused on analyzing industry-
developed blockchain applications. Min et al. [29] analyzed blockchain game trends
in Ethereum and EOS applications. The study provided a block diagram architecture
that provides a high-level view of the interactions between game players and blockchain
networks through smart contracts. Qasse et al. [30] examined the consistency of five
blockchain application repositories in terms of schema and content. A basic three-layered
architecture was proposed consisting of application, contract, and service layers. It is a
refinement of the two-layer architecture presented in [31].
Wu et al. [32] investigated the popularity of Ethereum applications, the openness of
their source codes, and the costs of deploying and executing smart contracts. The study
proposed an architecture to describe high-level interactions between clients and the smart
contracts of Ethereum applications. The architecture comprises five layers: the dApp client,
smart contract, dApp service, dApp server, and Ethereum blockchain.
Overall, the proposed architectures and strategies demonstrate the ongoing efforts
to enhance the scalability, privacy, and performance of blockchain systems, which are, in
most cases, for public blockchains or a specific application domain. This study adds to this
ongoing work by providing a collection of interconnected architectural patterns. In contrast,
our proposed patterns are cross-domain, blockchain-agnostic, and industry-derived from
400 blockchain applications. Although the dataset in this study contains a smaller number
of applications than those in [30,32], it contains a range of cross-industry applications on
nine different public and private platforms.
Appl. Sci. 2023, 13, 11533 4 of 22

Moreover, our proposed patterns are consistent with the ISO standard for DLT sys-
tems [18] and elaborate on aspects such as interoperability, data flow, security, and ledger
architecture. Where the standard provides a comprehensive and detailed framework for
blockchain and DLT systems, our study proposes high-level architectural patterns for the
design of blockchain systems and applications.

3. Pattern Identification
This section describes how we identified the 12 proposed architectural patterns.

3.1. Blockchain Application Selection

The first step in our pattern identification involved selecting a large number of existing
blockchain applications. To ensure recency, we restricted our selection to applications
published between September 2019 and February 2020, focusing particularly on nine open-
source platforms: Ethereum, Steem, EOS, Blockstack, Klaytn, POA, Hive, Corda, and
Hyperledger Fabric. We only included Blockchain 2.0 and 3.0 applications, which have
smart contract functionality. Our selection also ensured the diversity of the applications,
as we aimed to identify different types of blockchains (public, private, and consortium
blockchains) and different domain applications (such as asset management, exchange,
energy, finance, games, health services, insurance, IoT, and real estate). After reviewing
each application carefully to ensure that we could extract meaningful information from it,
we selected 400 applications [17].

3.2. Application Analysis

We analyzed these 400 applications one by one, to identify key components from each
application. Guided by a taxonomy for blockchain application development [3] and our
knowledge of blockchain technology, we found 13 core functional components from these
applications. These components are briefly outlined as follows:
1. Smart contract. These are programmable commands that can transfer digital assets
between parties in a predictable and transparent way [33]. A smart contract is written
in a platform-specific language, such as Solidity for Ethereum. Some platforms
allow only users to command pre-built smart contract modules, such as Hyperledger
Iroha, whereas others, such as EOS, allow for both pre-built and programmed smart
contracts [3].
2. Token. Tokens are cryptographic assets that may represent cryptocurrencies or real-
world objects [34,35]. Tokens are primarily native—protocol—or application tokens.
A native token is part of a blockchain platform’s protocol, such as Ether in Ethereum.
Application tokens are second-layer tokens that are programmed through smart
contracts for specific use cases [3].
3. Digital wallet. A digital wallet stores and manages digital keys and cryptocurren-
cies and can be implemented in various forms, such as hardware, paper, desktop,
mobile, web, browser-based, smart contract wallets, etc. A digital wallet can be em-
bedded within a blockchain application as a primary service or can be a stand-alone
application [3].
4. Permission management. This component is responsible for authorizing access to other
blockchain components, such as joining the network, invoking smart contracts, and
reading from or writing to ledgers. A permission component is essential in consortium
and private networks to encapsulate transactions and data within the consortia and
to maintain data privacy between consortia members themselves, as each member
should have access to specific data only [3,34,35].
5. Incentive mechanism. Primarily, this mechanism applies to public blockchains where
peer nodes are incentivized to contribute to the blockchain network, such as mining
blocks [34]. The incentive mechanism consists of the system fee and reward compo-
nents. The system fee is payable by the users of a blockchain application to the system,
whereas the reward is payable by the system to the miners [3].
Appl. Sci. 2023, 13, 11533 5 of 22

6. Ledger. The distributed ledgers serve as record keepers for all transactions that occur
in the network. They are synchronized between the involved peers [34–37]. There are
mainly two architectures of distributed ledgers: single- and multi-ledger. Moreover,
distributed ledgers could be a chain of blocks, a chain of transactions, a Direct Acyclic
Graph (DAG) of blocks, or a DAG of transactions [3,38].
7. Consensus. Consensus mechanisms are used to agree on the validity of transactions be-
tween trustless entities in a blockchain network. Different consensus mechanisms have
been applied in public and private network settings [39], including computation-based
protocols, such as PoW, and voting-based protocols, such as PBFT. Other algorithms,
such as PoS and DPoS, attempt to overcome the power-intensiveness limitation of
computation-based algorithms in public networks [3]. Consensus mechanisms have a
significant impact on the performance of a blockchain network [40].
8. Peer-to-Peer (P2P) network. A blockchain network is a communication medium that
allows participants to communicate in a P2P manner [16,34,35]. There are three main
types of blockchain networks: public, private, and consortium. Public blockchains
are permissionless networks that offer equal rights to all peers to read from and
write to the distributed ledger. Private blockchains encapsulate transactions and
data within a single organization. Read and write privileges are managed using
a permission management component. An extension of this private setting allows
multiple organizations to participate as a consortium [3].
9. Node. Nodes are the hardware and software representations of users participating in
a blockchain network and can be any electronic device with the required technical
specifications. Three main types of nodes perform ledger-oriented operations: full,
pruned, and lightweight nodes. Full and pruned nodes participate in transaction vali-
dation and block generation, while lightweight nodes store only transaction headers
and do not participate in consensus and block generation processes. Service nodes
may also be used to coordinate the general workflow between other nodes [3].
10. End user interface. Through this, users can initiate transactions and see the query
results of blockchain data. The end user interface can be a graphical user interface
(GUI) or a command-line interface (CLI).
11. Database. These data stores are used to store off-chain data and can be centralized or de-
centralized. They provide a solution for data privacy and blockchain scalability [34].
12. Server. Typically, servers are used to host UIs. The hosts can be centralized servers or
decentralized hosting services.
13. API. This component is responsible for passing messages between the client applica-
tion on one side and the blockchain network endpoints on the other side. For example,
the JavaScript Object Notation encoded messages protocol (JSON-RPC) is used by the
Ethereum, POA, Klaytn, EOS, Steem, and Hive platforms.

3.3. Mapping Components and Characteristics to Software Patterns

The identified 13 components and their architectural characteristics were mapped to
well-known software patterns [15,41], as shown in Table 1. The rationale for this mapping
is as follows:
• The N-Tier pattern divides an application into multiple layers or tiers. Each tier has a
particular responsibility, and communication happens between them through well-
defined interfaces. In the context of blockchain systems, the components are mainly
on two tiers: on-chain and off-chain. Each tier has its variations of architectures.
• The Peer-to-Peer (P2P) architecture relies on a distributed network of nodes that com-
municate directly with each other to exchange data [15]. The network component of
the blockchain is responsible for facilitating communication and transactions between
participants in a decentralized manner. All communication happens through the
network, eliminating the need for a centralized server or authority.
• In the Layer architectural pattern, an application is divided into multiple layers, each
with a specific function [15]. In the context of blockchain systems, the pattern provides
Appl. Sci. 2023, 13, 11533 6 of 22

a framework to ensure the separation of concerns, promote reusability, and facilitate

testing and debugging.
• The Shared Repository pattern is responsible for storing data and ensuring data
consistency across a network [15]. In blockchain systems, the ledger is a distributed
database that maintains a record of all transactions across the network. It is not only
shared, but is also immutable and replicated across the network. Each validation node
has an identical copy of the ledger. The pattern provides a standardized method for
maintaining a reliable and secure distributed ledger.
• The Broker pattern uses decentralized mechanisms for secure communication between
nodes and actors in a system. It involves components acting as message producers,
brokers, and clients [15]. In the context of blockchain systems, every node within the
network has the capability to act as a producer or a consumer of messages, determined
by whether, for example, it submits transactions or receives blocks from the network.
• The Pipe-Filter pattern represents a processing pipeline in which data flow through a
series of filters, with each filter transforming the data in some way [15]. In blockchain
systems, it ensures the authenticity of transactions and identifies potential threats. The
ledger, consensus, and smart contract stream transactions through a series of filters to
extract data and detect suspicious activity.
• The Access Control patterns involve methods such as authentication and authorization
to ensure that only authorized individuals have access to the system’s resources [42].
The digital wallet, incentive mechanism, and permission management aim to protect
blockchain systems from various types of threats. They provide an extra protection
layer by offering authentication, encryption, and authorization for users.

Table 1. The mapping of fundamental blockchain (BC) components to generic software architectural
(SW Arch.) patterns.

BC Components SW Arch. Patterns BC Arch. Patterns

- On-Chain-Off-Chain
All components N-Tier - Distributed Off-Chain
- Centralized Off-Chain
Network, nodes, permission
Peer-to-Peer (P2P) - P2P On-Chain
management
- Replicated Repository
Ledger, consensus Shared Repository - Chain-of-Blocks
- Chain Fork
Node, API, smart contract,
Broker - Blockchain Broker
digital wallet
Ledger, consensus, token,
smart contract, incentive - On-Chain Pipe-Filter
Pipe-Filter
mechanism, permission - Incentivized Contribution
management
All components Layer - Layered Application
Permission management,
Access Control - Crypto Shield
digital wallet

3.4. Pattern Organization

Based on the role of each pattern in our selected applications, we classified the pro-
posed patterns into four architectural views, composed of four structural, two interactional,
four transactional, and two security patterns, as Table 2 shows. Each architectural view
represents a blockchain application from the perspective of several concerns and comprises
a set of blockchain application components and their relationships. In the following, we
summarize these patterns based on these architectural views:
Appl. Sci. 2023, 13, 11533 7 of 22

1. Structural view: This view abstracts the logical and physical dissemination of the
blockchain application components.
2. Interactional view: This view abstracts how the individual components of a blockchain
application can exchange messages while retaining their autonomy.
3. Transactional view: This view abstracts how blockchain application components suc-
cessively process transactions as persistent, immutable, shared data.
4. Security view: This view abstracts how blockchain systems implement security and
privacy mechanisms to protect user data, prevent unauthorized access, and maintain
privacy.

Table 2. The proposed architectural patterns and their categories.

Architectural View Proposed Patterns

- On-Chain-Off-Chain
- Distributed Off-Chain
Structural
- Centralized Off-Chain
- P2P On-Chain
- Blockchain Broker
ine Interactional
- Layered Application
- On-Chain Pipe-Filter
- Replicated Repository
ine Transactional
- Chain-of-Blocks
- Chain Fork
- Incentivized Contribution
ine Security
- Crypto Shield

4. Pattern Description
In what follows, we describe each pattern in detail under its category.

4.1. Structural View Patterns

From this perspective, a blockchain application is viewed as a number of distributed
components among multiple tiers in a networked ecosystem. It addresses the ways in
which the components of a blockchain application are decoupled from and interact with
each other, with a focus on their physical arrangement.

4.1.1. On-Chain-Off-Chain Pattern

Summary: This pattern addresses the physical organization of blockchain system compo-
nents as a multi-tier system.
Context: A software system utilizes blockchain technology.
Solution: This architecture provides a global view of blockchain applications. A blockchain
application is separated into five logical and physical tiers, as shown in Figure 1. First,
the presentation tier hosts the application front-end and handles the static and dynamic
presentation of the user interface. It can be a remote web server or a local device, such as
a smartphone or wearable. Second, the off-chain logical tier coordinates the interaction
between the off-chain data and presentation tiers. It performs off-chain computation and
business logic on data collected from the presentation tier, and passes data from and to the
off-chain data tier. Source code files can be written in conventional server-side languages
and run in dedicated frameworks. Third, the off-chain data tier is where off-chain data are
stored and retrieved from to the off-chain logic tier and, eventually, to the presentation tier.
It can be a database or a file system. Fourth, smart contracts perform on-chain computations
and business logic through the on-chain logical tier. Finally, the on-chain data tier stores
on-chain data in distributed ledgers. This architectural pattern is sophisticated in that each
tier has several variant architectures.
The blockchain application components can be deployed in a plug-and-play manner.
There are three main deployment approaches for the different tiers: pure local, pure remote,
Appl. Sci. 2023, 13, 11533 8 of 22

and a combination of both. In pure local deployment, all tiers are deployed to a local
machine and connected to the test network of the blockchain platform. This approach
is suitable for pre-production and testing environments to evaluate application features
and assess smart contract execution. In pure remote deployment, all tiers are deployed on
remote machines and are accessed through RPCs. For example, the off-chain tier is deployed
on a remote web server, and the on-chain tier is deployed to a remote blockchain node as a
service, such as DappNode. Usually, this approach is used in a production environment in
which the application is deployed on the production network of the blockchain platform.
Hybrid deployment can occur in several ways.
For example, a remote off-chain local on-chain deployment occurs when a blockchain
node hosts the on-chain tier on a local computer machine connected to the blockchain
network, and the off-chain tier is hosted on remote servers. In contrast, when the off-chain
tier is a mobile app installed on users’ phone devices connected to the blockchain network,
the on-chain tier is deployed to remote nodes as a local off-chain remote on-chain approach.
The hybrid deployment is a customized approach that allows the articulation of different
deployment styles for each tier.

Figure 1. The on-chain-off-chain pattern for blockchain applications.

Known uses: Dtube is a video-sharing application. It consists of presentation and off-chain

logic tiers as a web application hosted on a centralized server, an off-chain data tier that
adopts centralized and distributed third-party data stores, and on-chain logic and data tiers
hosted on the Steem and Hive blockchains. PUML is a health and fitness loyalty program.
It consists of presentation and off-chain logic tiers combined in a mobile application hosted
on users’ mobile devices, as well as an off-chain data tier that adopts third-party data
stores. PUML’s on-chain logic and data tiers are hosted on the EOS blockchain and PUML’s
private side chain. CryptoFlip Cars is a card-trading game application. It consists of
presentation, off-chain data, and off-chain logic tiers combined as a web application hosted
on a centralized server. The application’s on-chain logic and data tiers are hosted on the
Ethereum blockchain.
Related patterns: Communication between the off-chain and on-chain components is
achieved through the blockchain broker pattern. The on-chain tier is depicted in the P2P
on-chain pattern, whereas the off-chain tier is illustrated by the distributed off-chain and
centralized off-chain patterns.

4.1.2. P2P On-Chain Pattern

Summary: This pattern addresses concerns regarding the decentralized communication of
back-end components within the internal environment of the blockchain.
Context: A software system utilizes blockchain technology.
Solution: This is the typical architecture of blockchain systems, as shown in Figure 2. A
blockchain network consists of multiple decentralized peer nodes, in which each node
has the same capabilities and responsibilities. For example, blockchain participants have
Appl. Sci. 2023, 13, 11533 9 of 22

equal reading and writing rights to the blockchain distributed ledger. However, permission
components can manage these rights in certain cases. The propagation of blocks and
transactions typically follows a gossip strategy. There are different protocols adopted by
blockchain networks to manage the propagation of data between peers. For example,
Ethereum Mainnet nodes run different protocols, such as the Light Ethereum Subprotocol
(LES) used by lightweight clients and the Ethereum Wire Protocol (ETH) used by full nodes.
Hyperledger Fabric implements a data dissemination protocol based on gRPC and protocol
buffers.

Figure 2. The P2P on-chain pattern for blockchain applications.

Known uses: Dtube is a video-sharing application. Its on-chain back-end is the Steem
blockchain, which is a P2P network. PUML is a health and fitness loyalty program. Its
on-chain back-end comprises the EOS blockchain and PUML sidechain, which are P2P
networks. CryptoFlip Cars is a card-trading game application. Its on-chain back-end is the
Ethereum blockchain, which is a P2P network.
Related patterns: This pattern complements the on-chain-off-chain, distributed off-chain,
and centralized off-chain patterns.

4.1.3. Distributed Off-Chain Pattern

Summary: This pattern addresses concerns regarding the decentralized communication of
back-end components within the external environment of the blockchain.
Context: A blockchain application utilizes off-chain services as a distributed system.
Solution: Off-chain back-end servers provide their services through distributed servers
to distribute access to web apps and off-chain data, as shown in Figure 3. For example, a
blockchain application may use an off-chain P2P file system, such as the BitTorrent File
System (BTFS) and Interplanetary File System (IPFS), for web hosting and data storage.
Instead, the application may utilize a P2P file-sharing system for either web hosting or data
storage and use a centralized server for the other as a three-tier client–server architecture.
Known uses: Aragon is an Ethereum-based service for the creation of Decentralized
Autonomous Organizations (DAOs) that uses IPFS for their data. Augur is an Ethereum-
based marketplace that uses IPFS for client application hosting and distribution. Dtube is a
Steem-based video-sharing platform that uses IPFS and BTFS for users’ video hosting.
Related patterns: This pattern complements the P2P on-chain and on-chain-off-chain
patterns.

4.1.4. Centralized Off-Chain Pattern

Summary: This pattern addresses concerns regarding the centralized communication of
back-end components within the external environment of the blockchain.
Context: A blockchain application utilizes off-chain services as a centralized system.
Appl. Sci. 2023, 13, 11533 10 of 22

Solution: Off-chain back-end servers provide their services through centralized server
machines, as shown in Figure 4. For example, a blockchain application may use a single
server for the off-chain application front-end and data or can use separate servers for each
as a three-tier client–server architecture.

Figure 3. The distributed off-chain pattern for blockchain applications.

Figure 4. The centralized off-chain pattern for blockchain applications.

Known uses: CryptoFlip Cars is an Ethereum-based game that uses centralized servers for
web hosting and data storage. Dtube uses centralized servers for web hosting and data
storage. Geon is a POA-based mobile game hosted locally by mobile device users.
Related patterns: This pattern complements the P2P on-chain and on-chain-off-chain
patterns.

4.2. Interactional View Patterns

From this perspective, a blockchain application is viewed as a set of independent
components that interact with each other within an application context. It addresses how
the components of a blockchain application are decoupled from and interact with each
other, with a focus on the logical arrangement.

4.2.1. Blockchain Broker Pattern

Summary: This pattern addresses concerns about communicating the decoupled compo-
nents of a blockchain application as a distributed system.
Context: A blockchain application consists of decoupled off-chain and on-chain compo-
nents.
Solution: The blockchain broker enables communication between the decoupled compo-
nents in distributed systems. Each node in the network can act as a message producer
Appl. Sci. 2023, 13, 11533 11 of 22

or consumer, depending on whether it submits transactions or receives blocks from the

network. For example, smart contracts can act as message brokers by enabling commu-
nication and coordination between different nodes. Digital wallets and APIs can act as
message clients that consume messages from the network and perform various actions
based on them, such as updating balances, providing market data, and providing services
to third-party applications or users. As shown in Figure 5, there are two types of blockchain
brokers:
1. Side-chain broker: By design, blockchains are heterogeneous and not able to commu-
nicate with each other since each blockchain has its own set of rules and tools that
make communication difficult. A side-chain broker allows blockchain interoperability
through cross-chain bridges. It enables the transfer of assets between one blockchain
(on-chain) and another (side-chain). Typically, a side-chain broker involves locking
or burning tokens through a smart contract on the source chain and unlocking or
minting equivalent tokens on the destination chain through another smart contract.
2. Off-chain broker: This type of service communicates among blockchain and client
applications. A client API handles the input from the client UI and passes it to a
dedicated blockchain endpoint. The blockchain endpoint node passes the input data
to the blockchain and returns output data to the client API, which, in turn, passes
the data to the UI. The client API and blockchain endpoint API are service broker
components that connect off-chain and on-chain components.

Figure 5. The blockchain broker pattern for blockchain applications.

Known uses: Dtube is a Steem-based video-sharing application. It uses the JSON-RPC

web service and the RPC endpoint of Steem’s public service node to communicate the
off-chain components with the Steem blockchain. CryptoFlip Cars is an Ethereum-based
game application. It uses the JSON-RPC web service and the RPC endpoint of Ethereum
public nodes to communicate the off-chain components with the Ethereum blockchain.
PUML is a health and fitness loyalty program. It uses the JSON-RPC web service and the
RPC endpoint of EOS public nodes to communicate the off-chain components with the EOS
blockchain and the PUML side chain.
Related patterns: This pattern shows how the different tiers in the on-chain-off-chain
pattern are connected.

4.2.2. Layered Application Pattern

Summary: This pattern addresses the decomposition of blockchain application components
into interacting parts as complex, heterogeneous entities.
Context: A software application utilizes blockchain technology.
Solution: A blockchain application can be represented in a generic layered architecture, as
shown in Figure 6. A typical blockchain application architecture consists of the following
layers:
• Application layer: This layer represents the use cases of blockchain applications, such
as intelligent transportation, supply chain traceability, artificial intelligence, robotics,
Appl. Sci. 2023, 13, 11533 12 of 22

unmanned aerial vehicles, intelligent manufacturing, business process management,

enterprise transformation, insurance processing, risk management, cryptocurrency
exchange, games, gambling, social networking, community reputation systems, rights
management, and data ownership.
• Presentation layer: This layer is related to front-end components that can interact with
the blockchain layer via client APIs. This layer consists of a typical UI and digital
wallet. It serves the purpose of providing an intuitive way for end-users to use
blockchain applications. A digital wallet stores and manages digital keys and crypto
assets in a blockchain system [3].
• Business logic layer: This layer handles the on-chain computations of the system. An
essential component is a smart contract. The other components within this layer
are smart contract wallets and application tokens. It also consists of web services to
connect the presentation layer with the blockchain layer.
• Blockchain layer: The blockchain layer includes the actual blockchain network itself,
which is composed of nodes, consensus algorithms, and the blockchain ledger. This
layer is responsible for maintaining the integrity and security of the blockchain net-
work and handles data storage, transaction validation, and other core blockchain
functions.
• Support layer: This layer provides supportive services for other layers. Hosting services
and external storage services are required for hosting and operating client applications.
This layer also provides IoT-related services, such as processing and analyzing sensor
data and transferring them to other layers.
• Security and privacy layer: This layer provides security services to the applications
and users. It provides user authentication, membership management, access control,
and permission management components. These components are responsible for
authorizing access to other blockchain components, such as joining the network,
invoking smart contracts, and reading from or writing to ledgers.
Known uses: Dtub is a Steem-based video-sharing application that rewards users for
sharing their content and commenting on and upvoting others’ content. KYC-Chain is an
Ethereum-based customer onboarding application for verifying customers’ identities and
managing the customer lifecycle. Hawk E-Scooter is a Klaytn-based decentralized, shared
scooter travel platform.
Related patterns: This pattern shows how the different layers in the on-chain-off-chain
pattern are connected.

Figure 6. The layered application pattern for blockchain applications.

4.3. Transactional View Patterns

In this view, a blockchain application is viewed as a number of subsequent transfers of
the input transaction data. It addresses how transactions on a blockchain are committed and
ordered. It also addresses how distributed ledgers are accessed, updated, and distributed.
Appl. Sci. 2023, 13, 11533 13 of 22

4.3.1. On-Chain Pipe-Filter Pattern

Summary: This pattern addresses concerns regarding how data are transferred from a
client to a shared ledger while retaining data integrity and confidentiality.
Context: A software application utilizes blockchain services as a distributed ledger.
Solution: Data in the blockchain are processed in the form of transactions. A transaction is
a single instruction constructed and cryptographically signed by a client external to the
scope of the blockchain. The process of adding new transactions to the ledger is a Pipe-Filter
architecture, as shown in Figure 7. A transaction passes several filters (validators/miners)
from the client (source) to the ledger (sink). The number and types of filters differ among
blockchain systems. Initially, a transaction must be cryptographically signed at the client
application using the user’s private key. The signed transactions then enter a pending
pool. They are then filtered by validators/miners. Subsequently, a certain number of valid
transactions are bundled into a block. The block size determines the number of transactions
included within a block. The block size also differs between the blockchain systems. Finally,
a valid block is added to the ledger and synchronized with all participants.

Figure 7. The on-chain pipe-filter pattern for blockchain applications.

Known uses: Transactions of Ethereum-based applications are submitted to Ethereum’s

pending transaction pool and then validated by miners, who are rewarded for generating
new blocks. Transactions of Hyperledger Fabric-based applications are validated by en-
dorsing, ordering, and committing peers. Transactions of Steem-based applications are
submitted to Steem’s pending transaction pool and then validated by witnesses, who are
rewarded for producing new blocks.
Related patterns: The generated blocks can be linked as in the chain-of-blocks pattern.

4.3.2. Replicated Repository Pattern

Summary: This pattern addresses concerns regarding distributing on-chain data as a
replicated ledger.
Context: A software application utilizes blockchain services as a distributed ledger.
Solution: A blockchain is a digital archive of transactions that are replicated and broadcast
across the blockchain network nodes. Every time a new block is committed, a copy of this
block is added to the ledgers of the other participants, as shown in Figure 8. Because each
participant, with the exception of light clients, has its copy, ledgers on the blockchain are
replicated rather than shared. Although nominated public nodes share their replications
with other nodes and clients in permissionless networks, any newly added block is repli-
cated and broadcast among all network participants. Reading from and writing to these
replications is permitted equally among all the nodes in the network. In permissioned
networks, broadcasting is performed for a subset of the network participants based on their
granted permissions. This permission-based replication allows complex ledger structures
in enterprise applications. In such cases, each member in a consortium has a digital ledger,
and any subset of members of the consortium can have a mutual replication. Finally, there
is a master replication among all the consortium members. The replicated records are also
at varying transparencies to ensure data confidentiality in the private environment.
Appl. Sci. 2023, 13, 11533 14 of 22

Figure 8. The replicated repository pattern for blockchain applications.

Known uses: The Ethereum network is permissionless, and its digital ledger is replicated
among all Ethereum nodes as a single-ledger-based architecture. The Hyperledger Fabric
network is permissioned, and its digital ledger is replicated per channel, allowing for a
multi-ledger-based architecture. The Corda network is permissioned and allows for shared
ledger structures.
Related patterns: The data in a replicated ledger can be linked, as in the chain-of-blocks
pattern.

4.3.3. Chain-of-Blocks Pattern

Summary: This pattern addresses concerns regarding structuring on-chain data.
Context: A software application utilizes blockchain services as a distributed ledger.
Solution: Confirmed transactions in the blockchain are grouped into blocks. Each block
has a unique number, known as the block height. A block typically consists of two parts
common to all blockchains: a block header and block data. The block header contains,
among other information, a link to its preceding block, which allows the blocks to be
chained in a strict order. Such a link is typically a hash of the preceding block. A block
hash is cryptographically derived from the block’s data. The block data contain a list of
confirmed transactions. Thus, a block can be searched for by its block number or hash.
Additional parts are customized per blockchain platform for the block structure. Usually,
these data are not included in the block hash calculation. The time interval, or block interval,
is the time allowed to add a new block to the chain. This time differs between blockchain
systems based on the blockchain protocol specifications. For example, Steem produces
blocks every three seconds. Figure 9 illustrates this pattern.

Figure 9. The chain-of-blocks pattern for blockchain applications.

Known uses: Ethereum is chain-based, and its block structure consists of a block header,
block data, and a list of ommers. The blocks are connected to a single chain. Hyperledger
Fabric is chain-based, and its block structure consists of a block header, data, and metadata.
The blocks are connected to a restricted shared chain. Klaytn is chain-based, and its block
Appl. Sci. 2023, 13, 11533 15 of 22

structure consists of a block header, block data, and a list of uncles. The blocks are connected
to a single chain.
Related patterns: The chain of blocks in the blockchain is synchronized between the
network participants as a replicated repository pattern. When more than one block has
the same block height, i.e., they are mined at nearly the same time, there could be a chain
fork pattern.

4.3.4. Chain Fork Pattern

Summary: This pattern addresses concerns regarding structuring on-chain data in conflict.
Context: A software application utilizes blockchain services as a distributed ledger.
Solution: To create a blockchain, the chain of blocks receives information from the blocks
that preceded them. The block relationship can be viewed as a parent–child relationship,
where each parent block has one child. The hash of the parent block is included in the
header of the child block. Blockchain participants must follow common rules to maintain
the history of the blockchain. When the participants are not in agreement or the rules are
changed, alternative chains may emerge as chain forks. A chain fork occurs by splitting a
chain of blocks into two paths. There are two main methods for such a split, as shown in
Figure 10.
The first occurs unintentionally at the consensus level when different blockchain
participants disagree on the block validity. For example, when two blocks are mined
simultaneously, they include the hash of their parent block and produce two different
hashes for their blocks’ data. This affects the validity of the chain. Therefore, only one block
must be integrated into the chain. To decide which child block to include, the participants
are allowed a temporary split with both conflicting child blocks. The miners then continue
producing blocks based on each conflicting block. The conflicting block with the longest
chain is then accepted. The other conflicting block becomes a stale/ommer block, and all its
dependent blocks are discarded and returned to the pending transaction pool for validation
to be included in the chain. The effect of a consensus-level chain fork on a blockchain
application is that it affects referential integrity with transaction finality.
The second occurs intentionally at the protocol level when the blockchain is upgraded
or changes its rules. This change causes a permanent split in the chain. When a blockchain
changes its rules, the existing chain is considered invalid in the new network. Thus, an
alternative chain should be created according to the new rules. Therefore, the validator
nodes must be upgraded to the new network. If some validator nodes insist on following
the old rules, a permanent divergence version of the chain is created. One path follows the
new version of the blockchain, and the other follows the old one. The effect of a protocol-
level chain fork on a blockchain application is that the application may remain on the old
chain or move completely to the forked chain, or it can be available on both chains.

Figure 10. The chain fork pattern for blockchain applications.

Known uses: Ethereum was forked into Ethereum Classic (old) and Ethereum (new) as
a protocol-level split. Hive is forked from Steem as a protocol-level split. Dtube is a
Appl. Sci. 2023, 13, 11533 16 of 22

Steem-based video-sharing application that runs on both blockchains: Steem and its forked
chain, Hive.
Related patterns: The forked chain is a chain of blocks synchronized between the network
participants as a replicated repository pattern.

4.4. Security View Patterns

4.4.1. Incentivized Contribution
Summary: This pattern addresses concerns regarding enhancing the security and increasing
the overall health of the blockchain network by motivating users.
Context: A blockchain system that requires from users significant resources or poses risks,
such as energy consumption or hardware maintenance.
Solution: Incentivizing users can increase the likelihood of active participation and im-
prove the performance and security of the blockchain system. As shown in Figure 11,
developers can design a reward mechanism that distributes tokens, privileges, or rep-
utational benefits to users who actively contribute to the system. By rewarding honest
behavior, incentive mechanisms encourage network participants to act honestly and dis-
courage malicious actions. By providing rewards for nodes that validate transactions,
participants are incentivized to agree on a single version of the distributed ledger, increas-
ing the security of the network. Moreover, incentive mechanisms can prevent Sybil attacks
by requiring network participants to stake or lock up a certain amount of cryptocurrency as
collateral, making it expensive and difficult for attackers to create multiple fake identities to
manipulate the network. These mechanisms can encourage network growth, which helps
to maintain the security of the network by ensuring that there are sufficient resources to de-
fend against cyber-attacks and by making it more challenging for attackers to compromise
the system.

Figure 11. The incentivized participation pattern for blockchain applications.

Known uses: The Ethereum blockchain rewards miners with ether tokens for processing
and validating smart contracts and transaction blocks. The amount of reward depends
on the level of computing power provided by the miner, as well as the gas fees paid by
the users. Steemit is a social media platform that incentivizes users to create and curate
content by rewarding them with STEEM tokens based on the popularity and quality of
their contributions. The STEEM tokens can be exchanged for other cryptocurrencies or
fiat currencies or can be used to vote on proposals and decisions related to the Steemit
ecosystem. Such participation contributes to the security of the Steem blockchain. Augur is
a prediction market that incentivizes users to report on the outcomes of events and bets
made on the platform. Users who report correctly on the outcomes can earn reputation
tokens, which can be used to participate in the governance and dispute resolution processes
of the platform. Such participation contributes to the security of the Ethereum blockchain.

4.4.2. Crypto Shield

Summary: This pattern addresses concerns regarding the security and privacy of blockchain
network applications through authentication, authorization, and encryption.
Context: A software application utilizes blockchain technology.
Appl. Sci. 2023, 13, 11533 17 of 22

Solution: Digital wallets play an essential role in safeguarding blockchain applications

by offering a permission mechanism for authentication, encryption, and authorization for
users, as shown in Figure 12. This function reduces the chances of fraud and protects against
cyber-threats. They authenticate users’ identities by utilizing digital signatures, while
encryption secures the transaction data and digital assets transmitted to and from the wallet.
Additionally, digital wallets only allow authorized personnel to access and manage digital
assets, ensuring that they remain secure. Furthermore, they restrict unauthorized access to
blockchain applications by only permitting authorized users to initiate transactions. Digital
wallets also ensure privacy by offering pseudonymous identities for the blockchain users.

Figure 12. The crypto shield pattern for blockchain applications.

Known uses: Dtube uses the Steemit wallet to secure access to the Steem network. Meta-
Mask is a browser extension wallet that provides authentication and encryption for users
utilizing the Ethereum blockchain. MyEtherWallet is a software wallet that utilizes encryp-
tion, authentication, and authorization for users utilizing the Ethereum blockchain.

5. Pattern Demonstration
In this section, we demonstrate the 12 patterns by using them to describe the architec-
tures of a popular real-world blockchain system. CryptoKitties is a popular marketplace
game for the buying, selling, and breeding of virtual cats called CryptoKitties. The architec-
ture of CryptoKitties can be described using the proposed architectural pattern language
for blockchain applications as follows.

5.1. Component Structure Design

At a high level of abstraction, CryptoKitties is a two-tier application built as a combi-
nation of the P2P on-chain and centralized off-chain patterns. CryptoKitties’s P2P on-chain
back-end is the Ethereum Mainnet. The application’s centralized off-chain is realized by
hosting the CryptoKitties front-end web application on a centralized hosting service and
storing the off-chain data in a relational database server.
CryptoKitties’s presentation tier compromises a web application hosted on Cloud
Flare servers. The game logic is distributed between the off-chain and on-chain logic tiers.
The off-chain data correspond to the off-chain logic and the client application. These data
are stored in PostgreSQL. The on-chain data correspond to the on-chain logic and are
stored in the Ethereum distributed ledger. CryptoKitties can be deployed using various
approaches. The off-chain tier is deployed remotely from a game player’s perspective. It
comprises the presentation, off-chain logic, and off-chain data tiers. The on-chain logic tier
is deployed on the EVM.
The deployment of the on-chain data tier depends on the player’s choice. If the player
wants to interact with CryptoKitties as a lightweight client, they are not required to deploy
their own Ethereum node. However, if the player is an Ethereum miner, they must have
their own Ethereum node. However, it is possible to deploy a full node as a remote Node-
as-a-Service, instead of being deployed locally. The former is a pure remote deployment,
and the latter is a hybrid approach in the form of remote off-chain local on-chain.
Appl. Sci. 2023, 13, 11533 18 of 22

5.2. Component Interaction Design

The off-chain and on-chain tiers communicate via RPCs initiated from the CryptoKit-
ties client application to the Ethereum Mainnet public node endpoints using JSON-RPC
web services. This communication realizes the blockchain broker pattern. Figure 13 il-
lustrates the mapping of the CryptoKitties architecture to the architecture of the layered
application pattern.

Figure 13. The mapping of the CryptoKitties architecture to the layered application pattern.

5.3. Transactional Design

Game transactions are initiated by players on the CryptoKitties web front. These
transactions involve buying, selling, transferring, or generating CK tokens. The client
first signs the transaction by using the player’s digital key via their digital wallet. The
signed transaction is then broadcasted to the Ethereum Mempool, a pool for pending
transactions, and is made available for miners to validate. Miners are not necessarily
players in CryptoKitties. Usually, they are application-independent and contribute to the
Ethereum network through block validation. The miner then selects the transactions for
validation. Usually, those with higher gas fees are selected because they are converted
into higher mining rewards. Subsequently, a set of validated transactions is bundled to
generate a block. Once this block is validated, it is added to the miner’s ledger. The miner
is then rewarded with the deserved amount of Ether for the validated blocks. There are no
separate transaction pipes for the different applications in Ethereum.
Ethereum has a single ledger for all transactions that occur on its Mainnet, and miners
select the set of transactions to validate; thus, CryptoKitties transactions may be bundled
with transactions from other applications within a single block. Every time a new block
is generated, it is attached to its preceding blocks in the Ethereum Mainnet in the form of
the chain-of-blocks pattern. It is then broadcast to all Ethereum participants, even if these
nodes are not CryptoKitties players, as in the replicated repository pattern.

5.4. Security Design

The incentive mechanism has two components: fees and rewards. The system fee
is payable by the users of CryptoKitties to Ethereum, whereas the reward fee is payable
by the system to miners. The platform incentivizes users to participate and contribute
by rewarding them with ether tokens, which they can use to purchase, breed, or trade
Appl. Sci. 2023, 13, 11533 19 of 22

cats. The more rare and valuable the cat, the higher the reward for breeding or selling it.
CryptoKitties also offers limited-edition cats and special events, which can increase the
demand and value of certain cats and encourage users to participate in the game. By using
various reward mechanisms and benefits, the application encourages users to participate,
contribute, and add value to the Ethereum ecosystem.
CryptoKitties uses digital wallets to ensure security in a few different ways. It uses
digital wallets to ensure security through ownership, secure transfers, breeding, and
a trustless system. Storing CryptoKitties in a digital wallet provides full control and
ownership, and secure transfers use a decentralized and traceable blockchain transaction.
The breeding mechanism produces unique cryptographic identifiers for each offspring,
and a trustless system eliminates the need for a centralized authority. By using blockchain
technology, CryptoKitties provides a secure and trustworthy platform for the buying,
selling, and breeding of virtual cats.

6. Discussion
Software patterns exist at different levels of abstraction, such as design patterns,
architectural patterns, and architectural styles. They capture complementary design aspects
that, to some extent, overlap. However, each pattern type offers a set of models and
mechanisms to address these aspects [12,43]. As already stated, architectural patterns
describe the high-level structures of software systems in terms of their major components
and the interactions between these components. Such patterns provide major system
structures in which multiple design decisions about functional requirements, non-functional
requirements, and physical constraints are realized [12,43]. Architectural tactics are design
decisions that affect how individual quality attribute requirements are controlled [43].
The emergence of blockchain technology has led to significant advancements in vari-
ous industries. However, the development of blockchain applications is a complex process
that requires a deep understanding of the technology and its underlying architecture [8].
This study has identified and categorized patterns that are essential to blockchain systems’
structural, interactional, transactional, and security aspects. Each pattern category repre-
sents a specific architectural view that helps blockchain application developers focus on
one design aspect. All these patterns contribute toward a framework for the development
of robust, scalable, secure, and efficient blockchain systems.
One of the main findings from this contribution is that blockchain platforms are
evolving mostly to overcome protocol-related issues such as scalability and performance.
For example, POA is a public side chain that enables a cross-chain-bridging architecture
within the Ethereum ecosystem. Moreover, Hive was forked from the Steem blockchain to
offer more decentralization and uncontrolled token ownership. Furthermore, the identified
patterns also provide industry policymakers and regulators with a framework for engaging
with blockchain-based systems.
In another respect, considering reusable architectural patterns can reduce the number
of concerns that blockchain application architects and developers need to address. The
patterns provide blueprints to help with design decision-making and fulfill application-
specific NFRs and quality requirements. For example, the interoperability and scalability
of blockchain applications can be fulfilled with the blockchain broker pattern, and the
reliability can be accomplished with the distributed off-chain pattern, coupled with the
P2P on-chain pattern. Certainly, there should be a trade-off between the different quality
requirements when designing an application according to the use case needs.
The originality of the proposed patterns lies in their suitability for blockchain systems
and their ability to provide a standardized approach to developing blockchain applications,
addressing the need for a clear architecture in the complex field of blockchain, which
can reduce the development time and improve the quality of the final product. As these
patterns are industry-derived, they are proven to be useful to describe the architectures of
existing applications and can be customized to suit the specific requirements of different
new applications.
Appl. Sci. 2023, 13, 11533 20 of 22

However, this proposal has some limitations. The proposed patterns are not exhaustive.
They are a good starting point for the development of blockchain applications, but they
do not cover all aspects of blockchain architecture. This is a work in progress; therefore,
there may be specific requirements of a blockchain application that are not adequately
addressed by the proposed patterns and may require additional architectural patterns or
modifications to the existing ones.
As blockchain technology evolves, there may be a need to introduce additional patterns
or fine-tune the existing ones to suit emerging technological trends. Additionally, this study
does not consider the commercial viability of blockchain systems, and the patterns may not
be suitable for certain use cases with specific business requirements. Another limitation
is concerned with the evaluation of the proposed patterns, as we have only selected a
sample application to demonstrate their applicability; we have not involved industries in
this evaluation.

7. Conclusions
This paper proposes 12 architectural patterns for the design of blockchain application
architectures. Derived from 400 industrial blockchain applications, these patterns describe
the architecture of a blockchain application from four important architectural design aspects.
The proposed patterns are intended to be general and applicable to a broad range of
blockchain applications. The usefulness of the patterns was demonstrated through a case
study by illustrating how they can be used to describe the architectures of real-world
blockchain applications.
Many software patterns can be applied to blockchain applications, but they need to be
adapted to the unique features of the blockchain, such as decentralization, immutability,
and replicated chains. Architectural patterns can be a valuable tool for collaboration
and communication among developers working on a blockchain project, as the patterns
provide a shared language and understanding of design decisions. Developers should
consider using a combination of patterns depending on the specific requirements of the
blockchain application under development, taking into account the trade-offs between the
requirements.
The blockchain ecosystem is evolving rapidly, and new patterns are emerging as the
technology matures. The available software patterns are not a complete solution to all
the challenges in blockchain software design, and the patterns in this study are an initial
proposal with limited validation. Developers must exercise creativity and adaptability to
craft innovative solutions that address the unique challenges in blockchain applications
while keeping in mind the specific requirements of each application.
Future work involves conducting empirical studies to evaluate the proposed patterns
in terms of effectiveness, efficiency, and usability by collecting feedback from developers
and end-users to measure the performance and quality attributes of the blockchain systems.
Additionally, developing practical guidelines and best practices for implementing and
deploying blockchain systems using the proposed patterns could facilitate their replication
and reuse by documenting key design decisions, implementation details, and deployment
strategies.

Author Contributions: The Conceptualization, F.A., K.S. and L.Z.; Methodology, F.A., K.S. and L.Z.;
Data curation, F.A., K.S. and L.Z.; Writing—original draft, F.A., K.S. and L.Z.; Writing—review and
editing, F.A., K.S. and L.Z. Funding acquestion, F.A. and K.S. All authors have read and agreed to the
published version of this manuscript.
Funding: This research work was funded by the Institutional Fund Project under grant no. (IFPRC-
079-612-2020); therefore, the authors gratefully acknowledge the technical and financial support from
the Ministry of Education and King Abdulaziz University, Jeddah, Saudi Arabia.
Data Availability Statement: The data presented in this study are openly available in Zenodo at
10.5281/zenodo.4268953, reference number [17].
Appl. Sci. 2023, 13, 11533 21 of 22

Conflicts of Interest: The authors declare that they have no known competing financial interest or
personal relationships that could have appeared to influence the work reported in this paper.

References
1. Narayanan, A.; Bonneau, J.; Felten, E.; Miller, A.; Goldfeder, S. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction;
Princeton University Press: Princeton, NJ, USA, 2016.
2. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized Bus. Rev. 2008. Available online: https://assets.
pubpub.org/d8wct41f/31611263538139.pdf (accessed on 22 September 2023).
3. Alzhrani, F.E.; Saeedi, K.A.; Zhao, L. A Taxonomy for Characterizing Blockchain Systems. IEEE Access 2022, 10, 110568–110589.
[CrossRef]
4. Casino, F.; Dasaklis, T.K.; Patsakis, C. A systematic literature review of blockchain-based applications: Current status, classification
and open issues. Telemat. Inform. 2019, 36, 55–81. [CrossRef]
5. Bodkhe, U.; Tanwar, S.; Parekh, K.; Khanpara, P.; Tyagi, S.; Kumar, N.; Alazab, M. Blockchain for Industry 4.0: A Comprehensive
Review. IEEE Access 2020, 8, 79764–79800. [CrossRef]
6. Sharma, P.K.; Park, J.H. Blockchain based hybrid network architecture for the smart city. Future Gener. Comput. Syst. 2018,
86, 650–655. [CrossRef]
7. Cai, W.; Wang, Z.; Ernst, J.B.; Hong, Z.; Feng, C.; Leung, V.C.M. Decentralized Applications: The Blockchain-Empowered
Software System. IEEE Access 2018, 6, 53019–53033. [CrossRef]
8. Zheng, Z.; Xie, S.; Dai, H.N.; Chen, X.; Wang, H. Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. 2018,
14, 352–375. [CrossRef]
9. Monrat, A.A.; Schelén, O.; Andersson, K. A Survey of Blockchain From the Perspectives of Applications, Challenges, and
Opportunities. IEEE Access 2019, 7, 117134–117151. [CrossRef]
10. Yang, X.; Zhao, L.; Wang, X.; Wang, Y.; Sun, J.; Cristoforo, A.J. Satisfying quality requirements in the design of a partition-based,
distributed stock trading system. Softw. Pract. Exp. 2012, 42, 131–157. [CrossRef]
11. Garlan, D. Software Architecture: A Travelogue. In Proceedings of the Future of Software Engineering Proceedings, FOSE 2014;
Association for Computing Machinery: New York, NY, USA, 2014; pp. 29–39. [CrossRef]
12. Monroe, R.T.; Kompanek, A.; Melton, R.; Garlan, D. Architectural styles, design patterns, and objects. IEEE Softw. 1997, 14, 43–52.
[CrossRef]
13. Zdun, U.; Avgeriou, P. Modeling architectural patterns using architectural primitives. ACM SIGPLAN Not. 2005, 40, 133–146.
[CrossRef]
14. Garlan, D. Software architecture: A roadmap. In Proceedings of the ICSE ’00: Conference on the Future of Software Engineering,
Limerick, Ireland, 4–11 June 2000; pp. 91–101. [CrossRef]
15. Avgeriou, P.; Zdun, U. Architectural patterns revisited—A pattern language. In Proceedings of the Tenth European Conference
on Pattern Languages of Programs (EuroPLoP 2005), Irsee, Germany, 6–10 July 2005; pp. 431–470.
16. Syed, T.A.; Alzahrani, A.; Jan, S.; Siddiqui, M.S.; Nadeem, A.; Alghamdi, T. A comparative analysis of blockchain architecture
and its applications: Problems and recommendations. IEEE Access 2019, 7, 176838–176869. [CrossRef]
17. Alzhrani, F. A Collection of Industry-Developed Blockchain-Based Applications. Zenodo CERN 2020. [CrossRef]
18. ISO 23257:2022(E); Blockchain and Distributed Ledger Technologies—Reference Architecture. ISO: Geneva, Switzerland, 2022.
19. Deng, X.; Huang, W.; Tang, X.; Basic Technology. Blockchain Application Guide: Methodology and Practice; Springer Nature Singapore:
Singapore, 2022; pp. 3–17. [CrossRef]
20. Xu, X.; Weber, I.; Staples, M.; Zhu, L.; Bosch, J.; Bass, L.; Pautasso, C.; Rimba, P. A Taxonomy of Blockchain-Based Systems for
Architecture Design. In Proceedings of the 2017 IEEE International Conference on Software Architecture (ICSA), Gothenburg,
Sweden, 3–7 April 2017; pp. 243–252. [CrossRef]
21. Yánez, W.; Bahsoon, R.; Zhang, Y.; Kazman, R. Architecting Internet of Things Systems with Blockchain: A Catalog of Tactics.
ACM Trans. Softw. Eng. Methodol. 2021, 30, 1–46. [CrossRef]
22. Wöhrer, M.; Zdun, U. Architectural Design Decisions for Blockchain-Based Applications. In Proceedings of the 2021 IEEE
International Conference on Blockchain and Cryptocurrency (ICBC), Dubai, United Arab Emirates, 3–6 May 2021; pp. 1–5.
[CrossRef]
23. Liu, Y.; Lu, Q.; Yu, G.; Paik, H.Y.; Zhu, L. A Pattern-Oriented Reference Architecture for Governance-Driven Blockchain Systems.
In Proceedings of the 2023 IEEE 20th International Conference on Software Architecture (ICSA), L’Aquila, Italy, 13–17 March 2023;
pp. 23–34. [CrossRef]
24. Zhang, Q.; Lv, H.; Ma, J.; Li, J.; Zhang, J. Overview of Blockchain Data Privacy Protection. In Proceedings of the BIOTC’21:
2021 3rd Blockchain and Internet of Things Conference, BIOTC’21, Ho Chi Minh City, Vietnam, 8–10 July 2021; Association for
Computing Machinery: New York, NY, USA, 2021; pp. 53–58. [CrossRef]
25. Zimmermann, H. OSI Reference Model—The ISO Model of Architecture for Open Systems Interconnection. IEEE Trans. Commun.
1980, 28, 425–432. [CrossRef]
26. Weber, I.; Lu, Q.; Tran, A.B.; Deshmukh, A.; Gorski, M.; Strazds, M. A Platform Architecture for Multi-Tenant Blockchain-Based
Systems. In Proceedings of the 2019 IEEE International Conference on Software Architecture (ICSA), Hamburg, Germany, 25–29
March 2019; pp. 101–110. [CrossRef]
Appl. Sci. 2023, 13, 11533 22 of 22

27. Wan, Z.; Xia, X.; Hassan, A.E. What Do Programmers Discuss About Blockchain? A Case Study on the Use of Balanced LDA
and the Reference Architecture of a Domain to Capture Online Discussions about Blockchain Platforms across Stack Exchange
Communities. IEEE Trans. Softw. Eng. 2021, 47, 1331–1349. [CrossRef]
28. Gupta, R.; Bhattacharya, P.; Tanwar, S.; Kumar, N.; Zeadally, S. GaRuDa: A Blockchain-Based Delivery Scheme Using Drones for
Healthcare 5.0 Applications. IEEE Internet Things Mag. 2021, 4, 60–66. [CrossRef]
29. Min, T.; Wang, H.; Guo, Y.; Cai, W. Blockchain Games: A Survey. In Proceedings of the 2019 IEEE Conference on Games (CoG),
London, UK, 20–23 August 2019; pp. 1–8. [CrossRef]
30. Qasse, I.A.; Spillner, J.; Abu Talib, M.; Nasir, Q. A Study on ÐApps Characteristics. In Proceedings of the 2020 IEEE International
Conference on Decentralized Applications and Infrastructures (DAPPS), Oxford, UK, 3–6 August 2020; pp. 88–93. [CrossRef]
31. Zeng, Y.; Zhang, Y. Review of research on blockchain application development method. J. Phys. Conf. Ser. 2019, 1187, 052005.
[CrossRef]
32. Wu, K.; Ma, Y.; Huang, G.; Liu, X. A first look at blockchain-based decentralized applications. Softw. Pract. Exp. 2021,
51, 2033–2050. [CrossRef]
33. Zheng, Z.; Xie, S.; Dai, H.N.; Chen, W.; Chen, X.; Weng, J.; Imran, M. An overview on smart contracts: Challenges, advances and
platforms. Future Gener. Comput. Syst. 2020, 105, 475–491. [CrossRef]
34. Xu, X.; Weber, I.; Staples, M. Architecture for Blockchain Applications; Springer: Berlin/Heidelberg, Germany, 2019; p. 307.
[CrossRef]
35. Dinh, T.T.A.; Liu, R.; Zhang, M.; Chen, G.; Ooi, B.C.; Wang, J. Untangling Blockchain: A Data Processing View of Blockchain
Systems. IEEE Trans. Knowl. Data Eng. 2018, 30, 1366–1385. [CrossRef]
36. Pervez, H.; Muneeb, M.; Irfan, M.U.; Haq, I.U. A Comparative Analysis of DAG-Based Blockchain Architectures. In Proceedings
of the 2018 12th International Conference on Open Source Systems and Technologies (ICOSST), Lahore, Pakistan, 19–21 December
2018; pp. 27–34. [CrossRef]
37. Paik, H.Y.; Xu, X.; Bandara, H.M.N.D.; Lee, S.U.; Lo, S.K. Analysis of Data Management in Blockchain-Based Systems: From
Architecture to Governance. IEEE Access 2019, 7, 186091–186107. [CrossRef]
38. Kannengießer, N.; Lins, S.; Dehling, T.; Sunyaev, A. Trade-Offs between Distributed Ledger Technology Characteristics. ACM
Comput. Surv. 2020, 53, 1–37. [CrossRef]
39. Jennath, H.S.; Asharaf, S. Survey on Blockchain Consensus Strategies. In Proceedings of the ICDSMLA 2019: 1st International
Conference on Data Science, Machine Learning and Applications; Springer: Singapore, 2019; pp. 637–654. [CrossRef]
40. Ismail, L.; Materwala, H. A Review of Blockchain Architecture and Consensus Protocols: Use Cases, Challenges, and Solutions.
Symmetry 2019, 11, 1198. [CrossRef]
41. Jaiswal, M. Software architecture and software design. Int. Res. J. Eng. Technol. (IRJET) e-ISSN 2019, 6, 2452–2454. [CrossRef]
42. Hafiz, M.; Adamczyk, P.; Johnson, R.E. Organizing Security Patterns. IEEE Softw. 2007, 24, 52–60. [CrossRef]
43. Harrison, N.B.; Avgeriou, P. How do architecture patterns and tactics interact? A model and annotation. J. Syst. Softw. 2010,
83, 1735–1758. [CrossRef]

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.