Architectural Patterns for Blockchain Systems and Application Design

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.

1. Introduction

A blockchain is a distributed ledger with lists of records (blocks) that are securely linked together via cryptographic hash functions [1]. Originally developed to record cryptocurrency transactions [2], blockchains are considered highly secure due to their anonymity, auditability, persistency, and decentralization. Blockchain technology provides a tamper-proof record of transactions, which ensures the integrity of data and eliminates the possibility of fraud. Additionally, blockchain transactions are transparent, allowing for 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 transaction domain [4,5,6,7]. These emerging applications include voting, healthcare, supply chain management, and the Internet of Things (IoT) [8]. The necessity of combining blockchain systems for real-world applications is driven by the need for a secure, transparent, and decentralized system. By incorporating this technology into such domains, organizations can improve efficiency, enhance trust, and ensure data privacy for their users [5].

Real-world projects have already harnessed the power of blockchain technology to transform their respective industries. For instance, the IBM Food Trust (https://www.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 development, as it plays a key role as a bridge between system requirements and implementation [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 design 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 decisions [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 architectural 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) networks [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 Organization 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 architecture 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 decisions about quality attributes on the architectural characteristics of blockchain systems. The decisions are related to decentralization, storage and computation, infrastructural configuration, 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 attributes. 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 reference architecture for the governance of blockchain systems, focusing on how governance fits within the development and use of the blockchain. The proposed reference architecture 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 transaction, 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 public 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: Bitcoin, 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 applications, 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.

Moreover, our proposed patterns are consistent with the ISO standard for DLT systems [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 cryptocurrencies 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 embedded 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 components. 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].

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,35,36,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 between 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 validation 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 decentralized. 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 application 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 mapping of fundamental blockchain (BC) components to generic software architectural (SW Arch.) patterns.

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

. 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 communicate 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 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.

3.4. Pattern Organization

Based on the role of each pattern in our selected applications, we classified the proposed patterns into four architectural views, composed of four structural, two interactional, four transactional, and two security patterns, as

Table 2. The proposed architectural patterns and their categories.

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

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:

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 successively 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.

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 components 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, 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.

• 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 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.
• 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.
• 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.
• 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 components of a blockchain application as a distributed system.
• Context: A blockchain application consists of decoupled off-chain and on-chain components.
• Solution: The blockchain broker enables communication between the decoupled components in distributed systems. Each node in the network can act as a message producer 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 communication 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 communicate 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.

• 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, 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 network 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.

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.

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.
• 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 endorsing, 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 replicated 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.
• 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.
• 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 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.

• 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 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 improve the performance and security of the blockchain system. As shown in Figure 11, developers can design a reward mechanism that distributes tokens, privileges, or reputational benefits to users who actively contribute to the system. By rewarding honest behavior, incentive mechanisms encourage network participants to act honestly and discourage malicious actions. By providing rewards for nodes that validate transactions, participants are incentivized to agree on a single version of the distributed ledger, increasing 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 defend against cyber-attacks and by making it more challenging for attackers to compromise the system.
• 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.
• 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.
• Known uses: Dtube uses the Steemit wallet to secure access to the Steem network. MetaMask is a browser extension wallet that provides authentication and encryption for users utilizing the Ethereum blockchain. MyEtherWallet is a software wallet that utilizes encryption, 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 architectures 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 architecture 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 combination 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.

5.2. Component Interaction Design

The off-chain and on-chain tiers communicate via RPCs initiated from the CryptoKitties client application to the Ethereum Mainnet public node endpoints using JSON-RPC web services. This communication realizes the blockchain broker pattern. Figure 13 illustrates the mapping of the CryptoKitties architecture to the architecture of 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 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 various 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 represents 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.

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.