# Securing the Future: Lightweight Blockchain Solutions for IIoT and IoT Networks

Fatemeh Stodt, Mohammed Alshawki, Christoph Reich, Peter Ligeti, Fabrice

Theoleyre

► To cite this version:

Fatemeh Stodt, Mohammed Alshawki, Christoph Reich, Peter Ligeti, Fabrice Theoleyre. Securing the Future: Lightweight Blockchain Solutions for IIoT and IoT Networks. Security and Privacy, 2025, 8 (4), 10.1002/spy2.70070. hal-05280875

HAL Id: hal-05280875

https://univoak.hal.science/hal-05280875v1

Submitted on 24 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RESEARCH ARTICLE

OPEN ACCESS

# Securing the Future: Lightweight Blockchain Solutions for IIoT and IoT Networks

Fatemeh Stodt¹,² | Mohammed Alshawki¹,³ | Christoph Reich¹ | Peter Ligeti³ | Fabrice Theoleyre²

¹Institute for Data Science, Cloud Computing and IT Security (IDACUS), University of Applied Sciences Furtwangen, Germany | ²ICube Lab, CNRS/University of Strasbourg, Strasbourg, France | ³Eotvos Lorand University, Budapest, Hungary

**Correspondence:** Fabrice Theoleyre (fabrice.theoleyre@cnrs.fr)

**Received:** 28 January 2025 | **Revised:** 17 June 2025 | **Accepted:** 1 July 2025

**Funding:** This research was funded by the Federal Ministry of Education and Research (BMBF) under reference number COSMIC-X 02J21D144, supervised by Projekträger Karlsruhe (PTKA), and by the UNKP-23-4 and Eköp-24 university excellence scholarship program of the ministry for culture and innovation from the source of the national research, development and innovation fund.

**Keywords:** attribute-based verification | BFT-DAG | blockchain | Industry 4.0 | IoT | privacy | shop floor

## ABSTRACT

This paper presents an innovative lightweight blockchain architecture tailored for Internet of Things (IoT) and Industrial Internet of Things (IIoT) applications. Building upon Byzantine Fault Tolerance (BFT) and Directed Acyclic Graph (DAG) technologies, our proposed BFT-DAG framework introduces key enhancements to optimize its performance in IIoT environments. Specifically, we redefine node roles and responsibilities to reduce computational cost, improve timing efficiency, and enhance scalability. To strengthen security, we integrate a lightweight attribute verification protocol that ensures secure authentication and mitigates risks associated with compromised or untrusted nodes. Unlike existing BFT-DAG approaches, such as Bullshark and its variants, which allow temporarily offline nodes to contribute blocks -introducing potential security vulnerabilities- our protocol verifies node integrity before participation. This ensures that only legitimate and uncompromised nodes are involved, bolstering system security without compromising performance.

## 1 | Introduction

The concept of Internet of Things (IoT) has revolutionized networking, allowing for the widespread use of sensing tools and low computation power devices. This eliminates the need for centralized operations and enables connectivity everywhere. The Industrial Internet of Things (IIoT) is expected to revolutionize traditional industrial processes, transforming them into intelligent, highly efficient, and interconnected systems [1].

The integration of IIoT in modern industrial applications has proven to be highly significant in enhancing operational

efficiency, reducing downtime, and fostering innovation [2]. The widespread adoption of IIoT brings several challenges, particularly in security, scalability, and real-time data processing [3]. There is a need for robust solutions to ensure trustworthiness, dependability, and efficient handling of extensive volumes of data produced within IIoT ecosystems.

In the face of these challenges, Blockchain technology has emerged as a highly promising solution for guaranteeing data integrity, traceability, and security in the realm of industrial manufacturing. The decentralized ledger system has the potential to bring about a significant transformation in the way data is shared

**Abbreviations:** BFT, Byzantine fault tolerance; IIoT, Blockchain-based Industrial Internet of Things; DABE, decentralized attribute-based encryption; DAG, directed acyclic graph; HSM, hardware security module; IIoT, Industrial Internet of Things; IoT, Internet of Things; PoA, Proof of Authority; PoH, Proof of History; PoS, Proof of Stake; PoW, Proof of Work; TMS, trust management system.

This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited.

© 2025 The Author(s). Security and Privacy published by John Wiley & Sons Ltd.
and verified in smart factories [4]. Blockchain technology has a wide range of practical applications that can benefit various sectors. These applications include ensuring secure and transparent tracking of supply chains, facilitating efficient cross-border financial transactions, and providing tamper-proof digital identities for secure access management [5].

Since IIoT devices are resource-constrained, lightweight solutions are required. Additionally, transaction processing latency could potentially result in production delays [6]. Furthermore, integrating blockchain into existing manufacturing systems may require substantial modifications, underscoring the need for a specialized and efficient blockchain architecture tailored to industrial manufacturing [7]. The focus should be on enhancing transaction speed, ensuring both data integrity and compatibility with existing operational technologies.

The current strategies for improving blockchain implementation in industrial settings involve the utilization of private blockchains to expedite transaction processing, the incorporation of consensus mechanisms tailored for industrial applications, such as Practical Byzantine Fault Tolerance (PBFT) [8] and Proof of Authority (PoA) [9], which achieve Byzantine Fault Tolerance (BFT), and the creation of specialized blockchain nodes equipped with hardware optimized for superior performance.

Nevertheless, private blockchains have the potential to compromise the fundamental decentralization of blockchain, which in turn can make them more susceptible to insider threats. Consensus mechanisms such as Byzantine Fault Tolerance (BFT) can be quite demanding in terms of computational power, presenting a challenge for lightweight industrial devices. In addition, custom-designed nodes can be costly and may not be compatible with existing legacy systems.

This paper proposes an innovative lightweight blockchain architecture designed explicitly for IIoT applications, emphasizing efficiency, scalability, and security. Our approach uses the BFT-DAG mechanism, combining the strengths of BFT and Directed Acyclic Graph DAG. This hybrid solution aims to reconcile the need for rapid transaction validation, achieving consensus within seconds, with the imperative for minimal overhead, thus maintaining high throughput and low latency, crucial for IIoT operations.

In addition, the system integrates a lightweight attribute verification protocol to ensure secure authentication and authorization in resource-constrained environments. This protocol verifies the attributes of participating nodes, securing and making interactions more efficient while minimizing computational overhead. By incorporating this protocol, the architecture enhances scalability and ensures robust security tailored for IIoT use cases.

Our contributions specifically address key IoT and IIoT challenges by proposing a lightweight blockchain architecture with substantial improvements, including:

* **Enhanced Scalability through Specialized Node Roles:** By redefining node roles into Regular Nodes (RNs), Edge Computing Nodes (ENs), Committee Nodes (CNs), and Transaction Verification Nodes (TVNs), computationally

intensive tasks are allocated primarily to more capable nodes (e.g., Committee Nodes), significantly reducing computational load and enhancing system scalability.

* **Lightweight Attribute Verification Protocol:** We introduce a lightweight and decentralized attribute verification protocol specifically optimized for resource-constrained IIoT devices. This protocol ensures secure and efficient transaction validation through cryptographically verifiable attribute tokens, effectively preventing compromised or untrusted nodes from participating in the blockchain network.

* **Robust Security Improvements:** The proposed architecture addresses known vulnerabilities in traditional BFT-DAG solutions, such as Bullshark, which permits temporarily offline nodes to rejoin and potentially introduce compromised blocks. Our approach strictly authenticates nodes based on verified attributes, thereby significantly mitigating this risk.

* **High Throughput and Low Latency in Real-world Environments:** Through implementation and evaluation in realistic IIoT scenarios, our architecture achieves substantial performance improvements, demonstrating throughput up to 49,039 transactions per second (TPS) and latency as low as 433 ms—significantly outperforming existing blockchain solutions.

* **Enhanced Security with Minimal Overhead:** Our solution robustly defends against traditional blockchain vulnerabilities such as replay attacks, DoS attacks, MITM, and Sybil attacks by leveraging attribute-based validation and decentralized consensus, thus effectively securing resource-constrained IoT networks without compromising performance.

The paper's organization is as follows: In Section 2, we present an overview of related research in the lightweight blockchains. Challenges in IIoT for Blockchain Implementation are mentioned in section 3. In Section 4 we explain about BFT-DAG and lightweight attribute verification protocol. Our proposed approach is detailed in Section 5, and Section 6 provides a risk analysis. Section 7 presents the results of our experiments. Finally, our conclusions are summarized in Section 8.

## 2 | Background and Related Work

In the subsequent sections, we explore the use of blockchain technology in Manufacturing and Industry 4.0, focusing on its applications in limited-resource environments.

### 2.1 | Blockchain for Manufacturing and Industry 4.0

Blockchain technology has been extensively explored for enhancing security, scalability, and data management in industrial systems. Barenji et al. [10] proposed a blockchain-enabled, multi-agent architecture for smart factories, enabling autonomous collaboration among devices while ensuring secure data exchange and efficient resource sharing. Similarly, Li et al. [11] introduced a blockchain-based cloud manufacturing
system that improves scalability and security by leveraging decentralized resource sharing, encryption, and smart contracts to maintain data integrity. In another study, Li et al. [12] focused on secure knowledge sharing for mold redesign, leveraging blockchain's immutable ledger for secure data exchange across enterprises. However, these approaches often rely on static frameworks and do not fully address the dynamic and resource-constrained nature of IIoT environments.

Kobzan et al. [13] investigated blockchain's application through network simulation to improve performance in industrial networks, highlighting its ability to address heterogeneity and scalability challenges by evaluating transaction throughput, bandwidth utilization, and deterministic timing. While their simulation-based approach demonstrates blockchain's adaptability, it lacks focus on real-world implementation and lightweight scalability.

Zhang et al. [14] explored blockchain's role in secure data collection, adaptive decision-making, and real-time communication within smart factories, emphasizing its potential for production scheduling and supply chain coordination. Angrish et al. [15] introduced FabRec, a blockchain-based peer-to-peer network for manufacturing nodes, designed to enhance data transparency and optimize resource sharing through smart contracts. However, these studies primarily focus on general manufacturing scenarios and lack dedicated mechanisms to address the unique scalability and security challenges of IIoT applications.

Liu et al. [16] proposed a blockchain-based solution for bandwidth and latency issues in digital twin manufacturing systems, using a peer-to-peer data exchange mechanism to reduce reliance on centralized cloud services while ensuring data security. Schmid et al. [17] developed a blockchain framework to enhance data synchronization and security in digital twin systems, employing manufacturing edge pools for efficient data exchange. Despite their contributions to reducing latency and improving efficiency, these approaches do not adequately address robust node authentication or lightweight mechanisms for scalability in IIoT environments.

## 2.2 | Lightweight Blockchain

Efficiency within resource-constrained environments has become increasingly critical in the rapidly evolving landscape of blockchain technology [18]. A clear framework has emerged to demonstrate lightweight characteristics [19]. This model's design is defined by five key attributes that set it apart from conventional blockchain models. These attributes include (i) **low computational burden**, (ii) **minimal network overhead**, (iii) **reduced storage requirements**, (iv) **enhanced throughput**, and (v) **superior energy efficiency**. In this section, we discuss the constraints to consider. Then, we explore potential solutions to overcome these limitations.

### 2.2.1 | Limitations in Lightweight Blockchain

Conventional blockchain systems typically require substantial computational power for cryptographic hashing and consensus algorithms, posing challenges in resource-constrained environments.

Addressing this issue necessitates the development of computationally efficient solutions [33]. Additionally, blockchain systems often generate high volumes of network traffic, as each node must download and verify all transactions. This can lead to network congestion and inefficiencies, particularly in IoT ecosystems [26]. Moreover, blockchains present storage challenges for devices with limited capacity, as nodes are required to maintain a complete copy of the ledger, which can expand significantly over time [27].

Transaction throughput is crucial for real-time applications. Unfortunately, traditional blockchains often experience low throughput because of the time required for consensus and transaction validation [23]. It is worth noting that the energy consumption of blockchain operations, particularly those utilizing Proof of Work (PoW), is significant and not ideal for low-power devices. This highlights the importance of finding more energy-efficient solutions.

### 2.2.2 | Addressing Constraints With Effective Solutions

Research on reducing the computational demands of blockchain systems has been limited, but several innovative approaches have emerged. Kempa et al. [33] suggest using compressed data structures to enhance efficiency in data processing tasks. Chaudhry et al. [34] focus on developing more efficient consensus algorithms that lower computational requirements, laying a foundation for advanced computational solutions.

Bandara et al. [24] introduced Tikiri, a blockchain platform for IoT devices that utilizes Apache Kafka for consensus and integrates functional programming with actor-based smart contracts. However, the integration of Apache Kafka may present scalability challenges. GradedDAG [29] extends BFT-DAG systems' efficiency through Reliable Broadcast (RBC) and Consistent Broadcast (CBC) mechanisms. However, its complexity may limit applicability in resource-constrained environments.

AEchain [23] employs a proof-of-authority (PoA) consensus algorithm and lightweight authenticated encryption to reduce computational load, making it suitable for resource-constrained IoT devices, albeit with a complex deployment process. LightDAG [30] minimizes network overhead through a streamlined consensus mechanism using Plain Broadcast and Consistent Broadcast, though this simplification may compromise network robustness under malicious conditions.

Shoal++ [31] balances high throughput with reduced storage requirements through staggered DAG instantiation and dynamic anchor scheduling, though its dynamic architecture may challenge consistency across diverse networks. Spiegelman et al. [32] propose BullShark, which optimizes performance in BFT-DAG systems but raises safety and security concerns due to its reliance on the integrity of the DAG structure.

Alkhazaali et al. [26] integrate blockchain with a lightweight fog computing solution to enhance communication between IoT devices and fog nodes, improving efficiency but facing scalability challenges. Wang et al. [27] address storage reduction through
<table><caption>TABLE 1 | Comparison of papers on lightweight blockchain characteristics.</caption><thead><tr><th>Paper</th><th>Low computational burden</th><th>Minimal network overhead</th><th>Reduced storage requirements</th><th>High throughput</th><th>Superior energy efficiency</th><th>Security and privacy preserving</th></tr></thead><tbody><tr><td>Kably et al. [20]</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>✓</td><td>✓</td></tr><tr><td>Ekanayake et al. [21]</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td></tr><tr><td>LightChain (Liu et al.) [22]</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✗</td></tr><tr><td>Khan et al. (AEchain) [23]</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>✓</td></tr><tr><td>Bandara et al. (Tikiri) [24]</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✓</td><td>✓</td></tr><tr><td>Yasmin et al. (SFC) [25]</td><td>✓</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td></tr><tr><td>Alkhazaali et al. [26]</td><td>✗</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td></tr><tr><td>Wang et al. [27]</td><td>✗</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td></tr><tr><td>Na et al. [28]</td><td>✓</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td></tr><tr><td>Dai et al. (GradedDAG) [29]</td><td>✗</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>✓</td></tr><tr><td>Dai et al. (LightDAG) [30]</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>✗</td></tr><tr><td>Arun et al. (Shoal++) [31]</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✗</td></tr><tr><td>Spiegelman et al. (BullShark) [32]</td><td>✓</td><td>✓</td><td>✗</td><td>✓</td><td>✓</td><td>✗</td></tr><tr><td>Our approach</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td></tr></tbody></table>

proxy re-encryption, allowing secure data storage in the cloud while presenting challenges in key management and server availability.

The Smart Food Chain (SFC) [25] and LightChain [22] propose models to reduce storage requirements, with SFC enhancing the food supply chain's efficiency through a sub-blockchain approach, though its specificity limits broader applicability. AEchain and Tikiri improve throughput with AEchain's PoA consensus and Tikiri's innovative architecture, though integration complexities remain. The authors of [28] present a blockchain architecture leveraging the Fabrik SDK and Schnorr signatures to enhance IoT security, albeit with deployment complexities.

Lastly, Kably et al. [20] propose a cloud-based framework to enhance energy efficiency by offloading computational tasks to the cloud. Ekanayake et al. [21] introduce the Proof of Equivalent Work (PeW) consensus mechanism as a more energy-efficient alternative to proof-of-work (PoW), promoting sustainability in industrial applications.

## 2.3 | Summary

Table 1 reports systematically the different solutions and how they comply with the corresponding constraints. This comparison highlights the need for a specific solution tailored for the IIoT. We need a Blockchain-based solution providing high-throughput, energy-efficiency, with a minimal set of constraints so that it can be executed on low-power nodes.

## 3 | Challenges in IIoT for Blockchain Implementation

The incorporation of blockchain technology into the IIoT landscape poses significant challenges that require a thorough

understanding and creative solutions. The following challenges emerge as pivotal:

* **Scalability and Throughput:** The distributed nature of blockchain necessitates substantial computational resources, bandwidth, and storage, which can be difficult to manage in IIoT settings where devices generate large data volumes [35]. It is essential to enhance the scalability and throughput of blockchain systems to efficiently process transactions without bottlenecks, ensuring system performance under high data loads [36].

* **Security Vulnerabilities:** IIoT devices, often resource-constrained, are susceptible to various cyber threats that can jeopardize data integrity and system functionality [37]. To counter these vulnerabilities, robust security protocols, including encryption, authentication, and access controls, must be implemented to maintain transaction integrity and trustworthiness [36]. Notably, vulnerabilities extend beyond specific operational stages; for example, Denial of Service (DoS) attacks can affect not only transaction verification but also critical phases like the voting phase, necessitating comprehensive security strategies across all blockchain implementation stages in IIoT networks.

* **Privacy and Confidentiality:** The challenge of reconciling blockchain's transparency with the need for data privacy and confidentiality in IIoT contexts is complex [35]. To protect sensitive information from unauthorized access, innovative cryptographic techniques such as zero-knowledge proofs and homomorphic encryption are suggested [36].

* **Interoperability and Integration:** The heterogeneous nature of IIoT ecosystems, characterized by disparate devices, protocols, and platforms, engenders interoperability challenges [38]. Seamless integration of blockchain with
existing IT and operational technologies demands stan-
dardized protocols and interfaces to facilitate cohesive data
exchange and interoperable communication [39].

The integration of blockchain technology into industrial pro-
cesses can significantly enhance transparency, security, and effi-
ciency, thus paving the way for Industry 4.0, despite facing
numerous challenges.

4 | Fundamentals

In the following subsections, we first describe the mechanisms of BFT-DAG [8], a foundational framework for achieving dependable and secure consensus in distributed systems, and then elaborate on our contributions, including the implementation of a lightweight attribute verification protocol and optimizations for IIoT-specific requirements.

The BFT-DAG architecture is a foundational framework for
achieving dependable and secure consensus in distributed sys-
tems, particularly in the context of IIoT. This framework
addresses specific challenges in IIoT environments, such as scal-
ability, low latency, and resource-constrained settings. To achieve
these goals, the authors have made several enhancements to
the BFT-DAG framework, including the implementation of a
lightweight attribute verification protocol and optimizations for
IIoT-specific requirements.

The lightweight attribute verification protocol integrates a dis-
tributed and privacy-preserving attribute verification protocol
into the BFT-DAG architecture, ensuring secure authentica-
tion of nodes based on verified attributes rather than identities.
This minimizes overhead and enhances privacy and scalabil-
ity. The original BFT-DAG consensus mechanism is adapted to
reduce latency and improve throughput for high-frequency IIoT
data streams, ensuring real-time processing without sacrificing
security.

The lightweight attribute verification protocol seamlessly inte-
grates a distributed, privacy-preserving attribute verification
mechanism into the BFT-DAG architecture. This enables secure
node authentication based on verified attributes rather than iden-
tities, reducing overhead while enhancing privacy and scalabil-
ity. Additionally, the original BFT-DAG consensus mechanism is
optimized to minimize latency and boost throughput, ensuring
real-time processing of high-frequency IIoT data streams without
compromising security.

The improved consensus mechanism ensures that the network
agrees on transaction validity and order even in the presence of
malicious or faulty nodes. This design achieves high through-
put and scalability to handle the massive data generated in IIoT
environments.

## 4.1 | Lightweight Attribute Verification Protocol

Authentication is a core security property in many IIoT systems.
Traditional authentication protocols often rely on revealing

exact identities and providing sensitive credentials, which can
compromise privacy. While some privacy-preserving models
exist [40–42], they still depend on identity disclosure dur-
ing authentication. In contrast, the attribute verification proto-
col (AVP) ensures secure, privacy-preserving authentication by
validating attributes rather than identities, making it particu-
larly suitable for resource-constrained and privacy-sensitive IIoT
environments.

Major authentication protocols in IIoT rely on centralized [43]
or edge servers [44], which introduce single points of failure
and increase communication overhead. The AVP addresses these
challenges by decentralizing the authentication process and ver-
ifying attributes instead of full identities.

The attribute verification protocol provides a decentralized and
privacy-preserving method for authenticating participants based
on verified attributes. As detailed in [45], the AVP involves three
main entities: the issuer, the prover, and the verifier (Figure 1).

* **Issuer:** Acts as the trusted authority responsible for managing attributes. It generates attribute tokens to attest to an entity's possession of specific attributes. The verifier receives the issuer's public keys for validation.

* **Prover:** The entity seeking authentication. The prover uses its attribute tokens to prove possession of the required attributes. Authentication succeeds when the prover provides valid proof based on its tokens.

* **Verifier:** Authenticated the prover by validating its attribute tokens. The verifier issues a challenge, and the prover responds with proof of its attributes.

This protocol employs cryptographically verifiable attribute
tokens, allowing only authenticated and authorized nodes to
participate, thus effectively preventing compromised or malic-
cious nodes from impacting the network. The lightweight
decentralized attribute-based encryption ensures secure trans-
action validation without excessive computational overhead,
making it particularly suitable for resource-constrained IIoT
devices. Moreover, the strict verification of node attributes
ensures secure node identity and prevents temporarily dis-
connected nodes—potentially compromised during their
offline period—from injecting unauthorized or false data upon

<figure><img src="image_2.png" /><figcaption>FIGURE 1 | Attribute verification protocol.</figcaption></figure>
<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /><figcaption>**FIGURE 2** | IOTA's tangle as a directed acyclic graph (DAG).</figcaption></figure>

reconnection. Consequently, our approach significantly mitigates vulnerabilities inherent in traditional BFT-DAG frameworks.

## 4.2 | Conceptual Overview of DAG-Based Validation

DAG-based validation mechanisms, as exemplified by protocols such as IOTA, represent a departure from traditional linear blockchain architectures. Figure 2 Illustration of IOTA's Tangle as a Directed Acyclic Graph (DAG). In contrast to the sequential nature of conventional blockchains, Directed Acyclic Graphs (DAGs) permit each transaction to directly confirm one or more preceding transactions. This structure facilitates parallel validation, thereby increasing system throughput and reducing latency. Rather than discarding or overlooking isolated transactions, the DAG model assimilates them into the broader network, enhancing overall efficiency. This parallelism reduces latency and improves throughput, an important requirement in IIoT networks with frequent, small-scale transactions. Nonetheless, this paradigm shift introduces significant challenges, particularly concerning the immutability and the global consistency of the distributed ledger.

In practice, each new transaction introduces a vertex into the DAG. It references and attempts to validate a set of previously unconfirmed transactions already embedded in the graph – commonly referred to as the Tangle in the context of IOTA. These transactions are cryptographically linked via directed edges, thereby extending the structure of the DAG. With each new validation, the likelihood of a transaction being legitimate increases. Once a transaction has been referenced more than a predefined threshold c times, it is deemed trustworthy and subsequently considered immutable. The integrity of the ledger is maintained, as the removal of a single transaction would necessitate the computationally prohibitive task of reconstructing all its dependent successors within the DAG.

# 5 | Proposed Lightweight Blockchain Architecture

The proposed BFT-DAG architecture addresses the limitations of current blockchain solutions in IIoT settings, such as inability to scale, high latency, and inefficiency in processing large amounts of data generated by industrial devices. By pairing BFT and DAG, the proposed architecture provides weak anonymity and secrecy

by design. Transaction Verification Nodes (TVN) perform the verification process without any knowledge about the generated data or the ID of the node, except when the ID is sent as part of the verification process.

## 5.1 | Network Architecture and Node Roles

Figure 3 illustrates our BFT-DAG architecture using attribute-based verification. The BFT-DAG architecture comprises a network of nodes categorized into four types: Regular Nodes (RN), Edge Computing Nodes (EN), Committee Nodes (CN), and Transaction Verification Nodes (TVN). Regular Nodes are IIoT nodes that support the network by creating data validated by edge computing nodes. Edge Computing Nodes handle tasks like data aggregation, filtration, and preliminary analysis, reducing data volume for transmission across the network for validation and inclusion in the DAG. Committee Nodes have a high processing capacity and dependability, responsible for maintaining the ledger, verifying transactions, and carrying out the consensus mechanism. They guarantee that transactions within the DAG are logically and securely linked, automatically sorting transactions without requiring explicit commit steps.

It is worth noting that Figure 3 includes a single instance of each entity for simplicity. However, in practice, our architecture supports multiple replicated instances of each node type (Regular Nodes, Edge Computing Nodes, Committee Nodes, and Transaction Verification Nodes), thereby eliminating any single point of failure. Redundancy is implemented through the parallel deployment of node instances within each subnetwork, allowing for failover in case of node unavailability.

Specifically, Committee Nodes (CNs) operate using a BFT-based consensus protocol that remains functional as long as a quorum (e.g., 2f + 1 out of 3f + 1 nodes) is preserved. This ensures that even if some Committee Nodes fail or act maliciously, the system continues operating securely. Similarly, multiple Edge Nodes (ENs) in each subnetwork can mirror data pre-processing tasks, ensuring that if one EN becomes unresponsive, another can seamlessly take over its role without interrupting data flow.

Redundancy is also supported in the TVN layer, where multiple verification nodes share responsibility for validating transactions in parallel. Load-balancing strategies can be employed to distribute verification tasks dynamically, enabling both fault tolerance and scalability.

This multi-instance deployment strategy not only ensures high availability and system resilience, but also supports horizontal scaling, allowing the network to grow by adding new node instances without disrupting existing services.

During transaction validation, Committee Nodes play the role of computational nodes to perform powerful computations that may not be executable on regular nodes. Transaction Verification Nodes (TVN) in the BFT-DAG system ensure that only valid nodes with valid tokens create the transactions, maintaining the network's security and integrity.
<figure><img src="image_5.png" /><figcaption>**FIGURE 3** | Relationship between main players in the proposed architecture.</figcaption></figure>

The network may consist of multiple subnetworks, ranging from 2 to *n*. Each subnetwork can include 1 to *n* regular nodes, 1 to *n* − 1 edge computing nodes, at least 1 transaction verification node, and 0 to *n* committee nodes. However, the entire network must have a minimum of 3 committee nodes to ensure reliable consensus.

This specialized assignment of node responsibilities significantly enhances scalability and reduces computational overhead. Regular Nodes delegate intensive computational tasks, such as cryptographic computations and complex transaction validations, to Edge Nodes, preserving their limited computational resources and preventing device overload. This approach not only protects lightweight nodes but also mitigates single points of failure by distributing essential computations across multiple Edge Nodes. Additionally, Committee Nodes employ local DAG structures, allowing transactions to be validated faster and more efficiently, further boosting overall system throughput and reducing latency. This approach protects lightweight nodes and enhances system resilience by replicating critical tasks across multiple Edge Nodes, ensuring continuity despite individual node failures.

## 5.2 | Initialization Process

The initialization process is crucial for setting up the system, ensuring that nodes are authenticated, and establishing the primary node for the committee. Below, we briefly outline the steps involved in the initialization process, followed by a detailed algorithm and its explanation.

1. Primary Node Selection: A primary node is randomly selected from the pool of CNs and verified by other Committee Nodes to ensure it meets security and performance criteria.

2. Node Authentication: Committee Nodes authenticate RNs and ENs within their subnetwork, verifying their attributes to confirm validity and authorization. Mutual authentication between ENs and RNs is also conducted to establish secure communication channels.

3. Network Initialization: Once the primary node is verified and all nodes are authenticated, the network initialization is completed, allowing the system to start normal transaction processing and consensus.

Algorithm 1 begins by selecting and verifying the primary node. A node is randomly chosen from the CNs and verified to meet security and performance criteria. If the selected node is valid, it is set as the primary CN. Otherwise, the selection process repeats until a valid primary node is found.

Next, the algorithm authenticates nodes within each subnetwork. For each CN in the network, every RN within its subnetwork is verified and authenticated if valid. Similarly, each EN is verified and authenticated. Furthermore, mutual authentication is conducted between ENs and RNs within their subnetwork to establish secure communication channels.

Finally, the algorithm completes the initialization process. Once all nodes are authenticated, the network is fully initialized and ready for normal transaction processing.
**Require:** List of CNs, RNs, ENs

**Ensure:** Initialized blockchain network

1: // Step 1: Select and verify the primary node

2: primary_node ← Randomly select a node from CN

3: **if** Verify(primary_node) = TRUE **then**

4: Set primary_node as the primary committee node

5: **else**

6: Repeat Step 4 until a valid primary_node is found

7: **end if**

8: // Step 2: Authenticate nodes within each subnetwork

9: **for** each CN in the network **do**

10: **for** each RN in CN.subnetwork **do**

11: **if** Verify(RN) = TRUE **then**

12: Authenticate RN

13: **end if**

14: **end for**

15: **for** each EN in CN.subnetwork **do**

16: **if** Verify(EN) = TRUE **then**

17: Authenticate EN

18: **end if**

19: // Mutual authentication between EN and RNs

20: **for** each RN in EN.subnetwork **do**

21: **if** Mutual_Authenticate(EN, RN) = TRUE **then**

22: Establish secure channel between EN and RN

23: **end if**

24: **end for**

25: **end for**

26: **end for**

27: // Step 3: Finalize initialization

28: **if** All nodes authenticated successfully **then**

29: Initialize network

30: Start normal transaction processing

31: **end if**

## 5.3 | Transaction Creation and Validation Process

Once the network is initialized and nodes are authenticated, the system proceeds with the transaction creation and validation process. We describe here briefly the different steps of our algorithm. Algorithm 2 proceeds as following:

1. Transaction Generation (lines 2-7): RNs generate data and create initial transactions. More precisely, each RN collects data from sensors or actuators, formats this data into a transaction including a timestamp and a unique identifier, and signs the transaction with its private key to ensure authenticity and integrity. The signed transaction is then sent to an EN.

2. Data Pre-Processing (lines 8-15): ENs aggregate, filter, and perform preliminary analysis on the data. Each EN receives transactions from RNs. The EN aggregates multiple transactions, filters out redundant or irrelevant data, and performs a preliminary analysis. The processed transactions are then added to the mempool, awaiting validation.

**Require:** Data from RN, EN, TVN

**Ensure:** Validated transactions ready for inclusion in the DAG

1: // Step 1: Transaction Generation

2: **for** each RN **do**

3: data ← Collect data from sensors/actuators

4: transaction ← Create transaction with data, timestamp, and unique identifier

5: signed_transaction ← Sign transaction with RN private key

6: Send signed_transaction to EN

7: **end for**

8: // Step 2: Data Pre-Processing

9: **for** each EN **do**

10: transactions ← Receive transactions from RNs

11: aggregated_data ← Aggregate transactions

12: filtered_data ← Filter redundant/irrelevant data from aggregated_data

13: pre_prepared_transactions ← Perform preliminary analysis on filtered_data

14: Add pre_prepared_transactions to mempool

15: **end for**

16: // Step 3: Transaction Validation

17: **for** each TVN **do**

18: transactions ← Retrieve transactions from mempool

19: **for** each transaction in transactions **do**

20: **if** Validate(transaction) = TRUE **then**

21: **if** Verify_Attribute_Tokens(transaction) = TRUE **then**

22: validated_transaction ← transaction

23: Send validated_transaction to CN

24: **end if**

25: **end if**

26: **end for**

27: **end for**

3. Transaction Validation (lines 16-27): TVNs re-validate the transactions, ensuring they originate from valid nodes with proper attribute tokens. Each TVN retrieves transactions from the mempool. Each transaction undergoes re-validation using attribute tokens to verify data integrity and authenticate the sender. Once validated, the transactions are forwarded to CN for inclusion in the DAG. This ensures that only legitimate transactions are added to the blockchain, maintaining the network's integrity and security.

## 5.4 | Consensus and Inclusion in DAG

In the proposed lightweight blockchain architecture, the consensus mechanism is a critical component that ensures the integrity, security, and consistency of the distributed ledger. The process involves CN executing a BFT protocol to validate and order transactions. This section provides a detailed explanation of how the consensus mechanism works and how transactions are included in the DAG.

1. Transaction Propagation: Once a transaction is generated and pre-processed, it is propagated to the mempool, where it awaits validation. The TVN first validate these transactions
for authenticity and attribute validity before they are picked
up by the Committee Nodes.

2. Proposal Phase: A CN, selected as the proposer (often the primary node), collects a batch of transactions from the mempool. The proposer creates a proposal block, which includes these transactions and references to previous DAG vertices.

3. Voting Phase: The proposal block is broadcasted to all other CN. Each CN independently verifies the transactions in the proposal block against the current state of the DAG. Verification includes checking transaction validity, ensuring there are no double-spending issues, and confirming that the proposer followed the protocol rules.

4. Pre-Commit Phase: Upon successful verification, each CN sends a pre-commit vote to other CNs. Pre-commit votes are aggregated to determine if a quorum (typically 2/3 majority) agrees on the proposal block.

5. Commit Phase: If the proposal block receives enough pre-commit votes, the CNs proceed to the commit phase. Each CN sends a commit vote, and once again, these votes are aggregated to ensure a consensus. If a quorum is reached, the block is considered committed.

6. Finalization: The committed block is added to the DAG, ensuring it is logically linked to previous vertices. The new state of the DAG is broadcasted to all nodes in the network, updating their local ledgers.

Algorithm 3 begins with the proposal phase, where a proposer node is selected from the CNs to create a block with transactions from the mempool. This proposal block also includes references to previous DAG vertices and is broadcasted to all CNs. In the voting phase, each Committee Node verifies the transactions in the proposal block against the current state of the DAG. Verification ensures transaction validity, absence of double-spending, and adherence to protocol rules. Verified transactions receive pre-commit votes from the nodes, which are then aggregated. If a quorum is reached, indicating that a majority of nodes agree on the proposal block, the process moves to the pre-commit phase.

During the pre-commit phase, each CN sends a commit vote. These votes are also aggregated, and if a quorum is reached again, the proposal block is considered committed. Finally, in the commit phase, the committed block is added to the DAG, ensuring it is logically linked to previous vertices. The updated state of the DAG is broadcasted to all nodes in the network, which then update their local ledgers.

## 5.5 | Inclusion in DAG

1. Vertex Creation: Each committed block becomes a new vertex in the DAG. The vertex includes references to one or more previous vertices, creating a directed path that ensures the chronological order of transactions.

2. Linking Vertices: Transactions in the new vertex are linked to transactions in previous vertices through

ALGORITHM 3 | BFT-DAG consensus mechanism.

Require: Transactions from mempool

Ensure: Updated DAG with committed transactions

1: // Step 1: Proposal Phase

2: proposer ← Select a Committee Node to propose a block

3: proposal_block ← Create block with transactions from mempool

4: proposal_block references ← References to previous DAG vertices

5: Broadcast proposal_block to all Committee Nodes

6: // Step 2: Voting Phase

7: **for** each CN in Committee Nodes **do**

8: **if** Verify(proposal_block) = TRUE **then**

9: pre_commit vote ← Generate pre-commit vote

10: Broadcast pre_commit vote to all Committee Nodes

11: **end if**

12: **end for**

13: // Step 3: Pre-Commit Phase

14: pre_commit votes ← Collect pre-commit votes

15: **if** Quorum(pre_commit votes) = TRUE **then**

16: **for** each CN in Committee Nodes **do**

17: commit vote ← Generate commit vote

18: Broadcast commit vote to all Committee Nodes

19: **end for**

20: **end if**

21: // Step 4: Commit Phase

22: commit votes ← Collect commit votes

23: **if** Quorum.commit votes) = TRUE **then**

24: Add proposal_block to DAG

25: Broadcast updated DAG to all nodes

26: **end if**

cryptographic hashes. This linking mechanism ensures that any tampering with a transaction would break the cryptographic chain, making it immediately detectable.

3. Updating the Ledger: Once a new vertex is added to the DAG, all nodes update their local copies of the ledger. This update includes the latest state of the DAG, ensuring consistency across the network.

Figure 4 illustrates the consensus method with the interconnected roles of the different node types and their collaboration. This visualization highlights the operational flow from transaction generation to validation, the consensus mechanism, and the network's hierarchical structure.

# 6 | Security Analysis

The BFT-DAG architecture prioritizes security to address vulnerabilities that could compromise integrity, availability, and confidentiality in Industrial Internet of Things (IIoT) systems. While this section emphasizes Replay, Denial of Service (DoS), and Man-in-the-Middle (MITM) attacks due to their relevance, we also extend security considerations to broader vulnerabilities present in traditional BFT-DAG approaches.
<figure><img src="image_6.png" /><figcaption>**FIGURE 4** | Data flow and consensus process among different nodes within a BFT-DAG system.</figcaption></figure>

For instance, unlike traditional BFT-DAG approaches such as Bullshark, which allow temporarily offline nodes to add potentially compromised blocks upon rejoining the network, our lightweight attribute verification protocol ensures strict node authentication based on attribute tokens. This mechanism effectively mitigates the security risk of nodes that, while temporarily offline, could become compromised and inject malicious data or transactions upon their return.

# 6.1 | Addressed Threats

## 6.1.1 | Replay Attack

During the verification process, the Transaction Verification Node (TVN) generates a challenge as follows:

$$ challenge_{TVN} = Enc(r||ts||PK_{TVN}) \quad (1) $$

where r is a random parameter, ts is the timestamp, and PK_{TVN} is the public key of the corresponding transaction verification node. By including both a nonce value r and the current timestamp ts, and assuming a cryptographically secure random number generator and synchronized system time, replayed verification packets are directly detected.

## 6.1.2 | Denial of Service (DoS) Attack

The system's decentralized design ensures that no single managing entity exists. During the transaction verification process, no external third-party nodes, including issuing committee nodes, are involved. As a result, DoS attacks targeting transaction verification are ineffective, as there is no centralized point of failure.

## 6.1.3 | Man-in-the-Middle (MITM) Attack

Committee nodes generate tokens for each Regular Node (RN) based on their attributes:

$$ token_{(RN, attribute)} = PK_1 \cdot I^{PK_2} \quad (2) $$

where PK_1 and PK_2 are the public keys of the issuing committee nodes, and I is the identifier of the RN. By encrypting traffic during transaction creation and verification, unauthorized interception or manipulation is effectively prevented.

# 6.2 | Additional Vulnerabilities

## 6.2.1 | Data Forgery

Data forgery involves creating or modifying transactions with malicious intent. The proposed architecture mitigates this risk through:

* Cryptographic signatures to ensure data authenticity.

* Attribute-based verification to restrict data creation to authorized nodes.

## 6.2.2 | Distributed Denial of Service (DDoS) Attack

DDoS attacks aim to overwhelm network resources. Mitigation strategies include:

* Decentralized processing and consensus mechanisms effectively eliminate single points of failure.

* Resource-intensive tasks are confined to Committee Nodes, which are specifically designed to handle high workloads efficiently.

## 6.2.3 | Sybil Attacks

Malicious entities may create multiple fake identities to disrupt consensus mechanisms. The architecture mitigates this by:

* Using attribute-based verification to authenticate nodes before participation.

* Incorporating a reputation system to penalize nodes exhibiting malicious behavior.

## 6.2.4 | Side-Channel Attacks

Side-channel attacks exploit unintended information leakage, such as timing or power consumption. Countermeasures include:

* Randomizing computational processes to obscure timing patterns.

* Utilizing secure hardware to minimize information leakage.
<table><caption>**TABLE 2** | Comparison of mitigation strategies against common attacks.</caption><thead><tr><td>Attack type</td><td>Impact</td><td>Mitigation</td><td>Evaluation</td></tr></thead><tbody><tr><td>Replay</td><td>Data integrity</td><td>Nonce, timestamp validation</td><td>Mitigated</td></tr><tr><td>DoS</td><td>Network availability</td><td>Decentralized design</td><td>Mitigated</td></tr><tr><td>MITM</td><td>Data confidentiality</td><td>Encrypted communication</td><td>Mitigated</td></tr><tr><td>Data forgery</td><td>Data authenticity</td><td>Cryptographic signatures</td><td>Mitigated</td></tr><tr><td>DDoS</td><td>Network availability</td><td>Distributed processing</td><td>Partially mitigated</td></tr><tr><td>Sybil</td><td>Consensus reliability</td><td>Attribute verification</td><td>Partially mitigated</td></tr><tr><td>Side-Channel</td><td>Confidentiality</td><td>Secure hardware, randomization</td><td>Partially mitigated</td></tr></tbody></table>

## 6.3 | Comparative Analysis

Table 2 summarizes the architecture's resilience against various attacks.

## 6.4 | Discussion

Our architecture carefully balances decentralization, security, and efficiency, acknowledging the inherent trade-offs between these aspects. While higher efficiency is achieved through specialized roles and centralized computational tasks at Committee Nodes, this slightly reduces decentralization. However, this approach significantly enhances security by ensuring rigorous attribute-based node authentication and improving overall system performance, making it well-suited for IIoT environments.

Beyond performance and security optimizations, the architecture demonstrates resilience against various attacks commonly encountered in IIoT environments. Nevertheless, challenges remain, particularly in enhancing protections against physical tampering, addressing resource constraints for side-channel mitigation, and incorporating adaptive scaling mechanisms for DDoS resistance. Future work will focus on integrating advanced cryptographic techniques, adaptive scaling strategies, and real-world deployment to further strengthen the system's security and adaptability.

# 7 | Implementation and Evaluation

This section delineates the methodology employed for implementing the proposed architecture, utilizing a combination of hardware as well as simulated network conditions to replicate an industrial IoT environment.

## 7.1 | Implementation Methodology

To effectively evaluate the proposed BFT-DAG architecture, we conducted a comprehensive implementation using real hardware, enabling us to explore the system's response to different network scenarios. Our hardware setup is illustrated in Figure 5.

Three laptops function as the primary nodes or committee members of the BFT-DAG network. These committee members are responsible for proposing, validating, and committing

<figure><img src="image_7.png" /><figcaption>**FIGURE 5** | Hardware network demonstration for test architecture.</figcaption></figure>

transactions within the network. One of these laptops was additionally designated as an EN, tasked with aggregating data and performing computational processing close to the data sources. This dual role helps in reducing latency and offloading processing tasks from the central network. The laptops communicate through a local network setup with WLAN-Standard IEEE 802.11n (WiFi 4), effectively simulating the network interactions typical in IIoT deployments.

The Raspberry Pi acts as a gateway, enabling seamless communication between environmental sensors and the edge computing node. The digital temperature sensor (TMP102) is connected to the Pico Brik via the I2C protocol, while the analog light sensor interfaces with the MCP3008 ADC through the SPI protocol. Both interfaces are managed by the Raspberry Pi for efficient data acquisition and processing, ensuring real-time sensor data is pre-processed and transmitted for further action.

Table 3 regroups the specification of our hardware platform.

## 7.2 | Results of the Evaluation

To thoroughly validate our architecture's performance improvements, we evaluate key metrics critical for IoT and IIoT scenarios, including throughput (TPS), latency (milliseconds), and energy efficiency (Joules per transaction). Specifically, the performance evaluation of the BFT-DAG architecture focuses on throughput, measured in transactions per second (TPS), and latency, defined as the time required to validate and finalize transactions. Experimental results demonstrate substantial improvements, achieving approximately 49,039 TPS with a latency as
<table><caption>TABLE 3 Hardware information for testing the BFT-DAG architecture.</caption><thead><tr><td>Device model</td><td>Network role</td><td>Specifications</td></tr></thead><tbody><tr><td>Lenovo IdeaPad 520</td><td>CN</td><td>Intel i7 8550U, 16GB RAM</td></tr><tr><td>Lenovo ThinkPad x230</td><td>CN</td><td>Intel i3 3110M, 8GB RAM</td></tr><tr><td>Lenovo IdeaPad Flex 15</td><td>CN/EN</td><td>Intel i3 4010U, 4GB RAM</td></tr><tr><td>RP2040</td><td>Gateway</td><td>dual-core ARM Cortex M0+ processor running up to 133 MHz, 264KB of SRAM and 2MB of on-board flash memory</td></tr><tr><td>Light sensor GL5528</td><td>Data collector</td><td>Light intensity measurement</td></tr><tr><td>Temperature sensor DHT22</td><td>Data collector</td><td>Temperature and humidity measurement</td></tr></tbody></table>

<table><caption>TABLE 4 Verification time across different devices.</caption><thead><tr><td>Component</td><td>Time (ms)</td></tr></thead><tbody><tr><td>Prover for response creation task (RN)</td><td>13.013</td></tr><tr><td>Verifier for verification task (CN)</td><td>10.74</td></tr><tr><td>Verifier for lightweight protocol task (CN)</td><td>3.142</td></tr></tbody></table>

low as 433 ms—significantly surpassing existing blockchain solutions. These results confirm the suitability and effectiveness of our approach for high-throughput and low-latency IIoT environments while ensuring improved energy efficiency.

We focus on the following metrics:

**Verification Time:** duration required to verify the authenticity and integrity of a transaction, including signature validation and data consistency checks against the current ledger state.

**Throughput:** number of transactions processed per second (TPS) by the blockchain network, indicating its capacity to handle a high volume of transactions.

**Latency:** time elapsed from the initiation of a transaction to its final confirmation and inclusion in the blockchain ledger, reflecting the speed and efficiency of the network.

### 7.2.1 | Verification Time

Verification time was assessed across three devices (Laptop 1, Laptop 2/Raspberry Pi, and Laptop 3). Two main components were measured: the time taken by the prover to generate a response and the verification time required by the verifier. Table 4 summarizes these results.

The verification time was assessed across three devices, focusing on the time taken by the prover and verifier in different tasks. The prover, typically a RN, takes the longest at 13.013 ms due to the complexity of generating cryptographic proofs. The verifier, a CN, takes 10.74 ms for standard verification, which involves validating signatures and ensuring data meets consensus rules. The lightweight protocol verification is the quickest at 3.142 ms, indicating its efficiency with fewer cryptographic checks or simpler algorithms. These results highlight the need to optimize the prover's response creation time and leverage the lightweight protocol for faster transaction processing and lower network latency.

### 7.2.2 | Energy Consumption Evaluation

Energy consumption is a critical metric for lightweight blockchain systems, particularly in resource-constrained Industrial Internet of Things (IIoT) environments. This section evaluates the energy efficiency of the proposed BFT-DAG architecture using the hardware specifications and throughput results from our experiments.

Energy consumption is calculated based on the power consumption of each node type and the system's transaction throughput (TPS). Using the formula:

$$ \text{Energy per transaction (J)} = \frac{\text{Power (W)}}{\text{TPS}} $$

we estimated the energy usage for Regular Nodes (RNs), Edge Nodes (ENs), and Committee Nodes (CNs). The total energy per transaction includes contributions from all active nodes, including the overhead from authentication.

Table 5 summarizes the energy consumption for each node type, including the authentication overhead, and calculates the total energy per transaction.

For a transaction throughput of 49,039 TPS, the system's total energy consumption per second is approximately 55.05 Joules, including the authentication overhead. This demonstrates the architecture's suitability for energy-efficient, high-throughput environments.

### 7.2.3 | Benchmarking Results

The metrics are regrouped in Table 6. Our benchmark evaluates the consensus throughput (Transactions Per Second or TPS) and latency across various transactions and batch sizes. The consensus throughput achieves 49K transactions per second (TPS) and 25 Mbps, with a latency of 433 ms. These figures indicate a high efficiency in processing transactions within the consensus mechanism.

The end-to-end system, which includes all stages from transaction initiation to finalization, exhibits almost the same throughput with a decrease smaller than 1%. The latency increases slightly to 577 ms. The additional latency and slightly lower throughput in the end-to-end measurements can be attributed to the cumulative processing and network delays beyond the
<table><caption>**TABLE 5** | Energy consumption per transaction and total energy per second.</caption><thead><tr><th>Node type</th><th>Power (W)</th><th>Base energy/ transaction (J)</th><th>Authentication overhead (J)</th><th>Total energy/ transaction (J)</th></tr></thead><tbody><tr><td>Regular node (RN)</td><td>2.5</td><td>0.000051</td><td>0.00000255</td><td>0.00005355</td></tr><tr><td>Edge node (EN)</td><td>20</td><td>0.000408</td><td>0.0000204</td><td>0.0004284</td></tr><tr><td>Committee node (CN)</td><td>30</td><td>0.000612</td><td>0.0000306</td><td>0.0006426</td></tr><tr><td><strong>Total</strong></td><td><strong>52.5 W</strong></td><td><strong>0.00107 J</strong></td><td><strong>0.00005355 J</strong></td><td><strong>0.00112355 J</strong></td></tr></tbody></table>

<table><caption>**TABLE 6** | Benchmarking results for consensus throughput and latency.</caption><thead><tr><th>Metric</th><th>Result</th></tr></thead><tbody><tr><td>Consensus TPS (transactions per second)</td><td>49,439 tx/s</td></tr><tr><td>Consensus BPS (bytes per second)</td><td>25,312,723 B/s</td></tr><tr><td>Consensus Latency</td><td>433 ms</td></tr><tr><td>End-to-End TPS</td><td>49,039 tx/s</td></tr><tr><td>End-to-End BPS</td><td>25,107,962 B/s</td></tr><tr><td>End-to-End Latency</td><td>577 ms</td></tr></tbody></table>

consensus layer. These results highlight the system's overall capability to handle a high volume of transactions efficiently, while also indicating areas where latency can be further optimized for improved performance.

### 7.2.4 | Comparison With Related Works

The performance evaluation of the proposed architecture centers around three core comparisons: **average transactions per second (TPS)**, **consensus latency**, and the **balance between TPS and latency**. These metrics offer valuable insights into the system's ability to deliver rapid data processing while ensuring accurate consensus.

The results from both verification and benchmarking tests confirm the system's high throughput and efficient consensus capabilities, showing that the architecture is suitable for distributed environments requiring reliable and low-latency consensus.

Figure 6 compares average TPS across several blockchain systems, revealing the efficiency of the proposed architecture in high-throughput scenarios. Bitcoin, known for its PoW mechanism, has high energy consumption and slow transaction processing, resulting in limited throughput. Ethereum, currently transitioning from PoW to Proof of Stake (PoS) with Ethereum 2.0, offers moderate throughput. Solana combines Proof of History (PoH) with PoS, providing higher throughput and lower latency compared to PoW systems. GradedDAG and Shoal++ excel in processing high volumes of transactions with reduced latency, enhancing throughput significantly over traditional blockchain systems.

IOTA's Tangle uses a DAG instead of a traditional blockchain, making it better suited for IoT applications with lower

<figure><img src="image_8.png" /><figcaption>**FIGURE 6** | Average TPS comparison across blockchain systems.</figcaption></figure>

transaction fees and improved scalability. IoT-Chain, designed specifically for IoT environments, focuses on low latency and efficient consensus. Our architecture after Shoal achieves significantly higher TPS compared to its competitors.

While throughput is crucial, achieving consensus promptly is equally important. Figure 7 compares consensus latency across blockchain systems. The proposed architecture's latency of 433 ms is markedly lower than that of systems like Bitcoin, which suffer from long delays due to their PoW protocols. Bitcoin's approximately 10-m latency range highlight the inefficiencies of this systems for applications requiring prompt decision-making. Ethereum's latency is 12 to 15 s, Solana, GradedDAG, Shoal++, and IOTA's Tangle show better latency but are still not as efficient as our system. IoT-Chain achieves lower latency due to its design for IoT environments, but our architecture strikes a better balance between high throughput and low latency, making it ideal for real-time applications.

Figure 8 illustrates the relationship between TPS and consensus latency. Our system demonstrates a compelling balance, maintaining high throughput while ensuring relatively low latency. Bitcoin achieve lower TPS with high latency due to it's PoW mechanisms. Ethereum, Solana, GradedDAG and IOTA's Tangle improve on this but still face trade-offs. Our architecture, optimized for both metrics, offers a significant advantage for applications demanding rapid data processing and reliable, low-latency consensus. This balance is essential for IoT applications, where quick data processing and immediate consensus are critical for performance and reliability.
<figure><img src="image_9.png" /><figcaption>**FIGURE 7** | Consensus latency comparison across blockchain systems.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>**FIGURE 8** | TPS versus latency comparison across blockchain systems.</figcaption></figure>

To provide context, we compare the estimated energy consumption of our system with other blockchain systems, including Solana, Bitcoin, Ethereum, and IOTA (Table 7).

Our system demonstrates superior energy efficiency compared to traditional blockchain systems like Bitcoin and Ethereum (PoW). Although platforms like Solana and IOTA also exhibit low energy consumption, the proposed BFT-DAG balances energy efficiency, high throughput, and robust security, making it particularly suitable for IIoT environments.

## 7.3 | Discussion and Future Direction

The results presented previously highlight the notable advantages of the proposed architecture compared to other blockchain systems. The following discussion delves deeper into these findings, examining their implications and the potential use cases and

<table><caption>**TABLE 7** | Comparison of energy consumption across blockchain systems.</caption><thead><tr><td>System</td><td>Energy/ transaction (J)</td><td>Energy/ second (J)</td></tr></thead><tbody><tr><td>Proposed BFT-DAG</td><td>0.00112355</td><td>55.05</td></tr><tr><td>Solana</td><td>0.014832</td><td>740.82</td></tr><tr><td>Bitcoin</td><td>2,545,200</td><td>N/A</td></tr><tr><td>Ethereum (PoW)</td><td>225,000</td><td>N/A</td></tr><tr><td>Ethereum (PoS)</td><td>0.0108</td><td>N/A</td></tr><tr><td>IOTA</td><td>0.000001</td><td>N/A</td></tr></tbody></table>

challenges of implementing this architecture in real-world applications.

* **Throughput Advantage:** The exceptional TPS achieved by our system demonstrates its scalability and suitability for high-throughput environments. This is particularly significant for industrial IoT applications where massive data is generated at high frequencies and needs immediate processing. The throughput results indicate that our approach could handle peak traffic without compromising efficiency, making it ideal for large-scale data aggregation and analysis.

* **Reduced Latency:** The low consensus latency achieved by our architecture further strengthens its value proposition for applications requiring real-time or near-real-time decision-making. The architecture's ability to reach consensus swiftly ensures that data collected from edge devices or sensors can be verified, processed, and acted upon in a timely manner, reducing delays and improving operational efficiency.

* **Throughput and Latency:** The scatter plot comparing TPS against latency reveals that the proposed architecture strikes a balanced approach. It maintains high throughput while achieving consensus rapidly, unlike many conventional blockchain systems that often sacrifice one metric for the other. This balanced performance enables a wide range of applications that require both high-speed data processing and reliable consensus.

* **Use Cases and Limitations:** The high throughput and low latency characteristics of our system are especially beneficial for applications like supply chain monitoring, smart cities, and predictive maintenance in industrial settings. However, challenges remain in fine-tuning the architecture to handle varying network conditions and potential adversarial behavior. The participation of resource-constrained devices in the consensus protocol is also challenging.

* **Future Work:** Future research directions will focus on the following practical operational aspects:

- **Energy Consumption Optimization:** We plan to investigate adaptive workload allocation mechanisms such as scheduling tasks based on device battery level and communication costs, using lightweight optimization heuristics. Future work will also explore the use of hardware accelerators (e.g., ARM TrustZone or FPGA-based
hashing units) for cryptographic operations, particularly
in edge nodes.

- **Scalability Improvements:** To support elastic network growth, we will explore decentralized membership management protocols that allow dynamic node onboarding and removal without centralized control. For example, gossip-based discovery and adaptive sharding mechanisms can be evaluated to maintain ledger performance as the network scales.

- **Security Enhancements:** Future work will focus on extending the current token- and attribute-based access mechanisms with adaptive, learning-based security strategies. For example, lightweight classifiers such as decision trees or online k-means clustering can be deployed at the edge to detect anomalous behavior in transaction patterns or node interactions.

- **Protocol Interoperability:** To facilitate real-world deployment, future work will address the integration of the proposed blockchain architecture with mainstream IIoT communication protocols such as MQTT, CoAP, and OPC UA. This involves defining protocol adapters or gateways that allow secure token-based or attribute-based authentication to be layered on top of existing transport mechanisms. For example, lightweight wrappers could embed blockchain-issued transaction tokens within MQTT messages or use metadata fields in OPC UA for policy enforcement. Such integration will ensure that the system can interoperate with existing industrial platforms without requiring full replacement of communication infrastructure.

In conclusion, the proposed architecture has strong potential for adoption in data-intensive environments, provided the challenges are adequately addressed through continued optimization and refinement.

8 | Conclusion

The proposed BFT-DAG architecture builds upon existing concepts to address the unique challenges of IIoT networks by combining the scalability of DAG, the security of BFT, and the decentralization of a lightweight attribute verification protocol. These enhancements result in high throughput and low latency, making the architecture particularly suitable for data-intensive and time-sensitive applications. Our evaluation demonstrates the system's strong performance in processing and validating transactions. While the system achieves the second-highest average TPS after Shoal, it outperforms Shoal in latency and ranks second only to IoT-Chain in this metric.

Future research directions include optimizing the architecture for diverse network scenarios and further improving its fault tolerance and decentralized decision-making capabilities. This involves implementing adaptive scaling and load balancing to handle dynamic workloads efficiently, developing advanced fault tolerance strategies, and incorporating machine learning techniques into the attribute verification protocol for real-time optimization. Additionally, reducing energy consumption through the design of optimized consensus algorithms

and exploring energy-efficient protocols will be essential for resource-constrained environments. Enhancing security through advanced cryptographic techniques, establishing interoperability standards, and conducting real-world field tests will further validate and solidify the architecture's practicality.

Improving user accessibility with user-friendly interfaces and comprehensive documentation will also support broader adoption. By addressing these areas, the BFT-DAG architecture can continue to evolve as a leading solution for IIoT networks, meeting the demands of modern, data-intensive, and time-sensitive applications with greater efficiency, security, and scalability.

Acknowledgments

This research was funded by the Federal Ministry of Education and Research (BMBF) under reference number COSMIC-X 02J21D144, supervised by Projektträger Karlsruhe (PTKA), partially supported by ERC Advanced Grant “ERMiD” and supported by the UNKP-23-4 and Eköp-24 university excellence scholarship program of the ministry for culture and innovation from the source of the national research, development and innovation fund.

Data Availability Statement

Data sharing is not applicable to this article as no new data were created or analyzed in this study.

References

1. A. Sari, A. Lekidis, and I. Butun, "Industrial Networks and IIoT: Now and Future Trends," In, *Industrial IoT: Challenges, Design Principles, Applications, and Security*, edited by I. Butun, (Springer, 2020), 3–55.

2. H. Boyes, B. Hallaq, J. Cunningham, and T. Watson, "The Industrial Internet of Things (Iiot): An Analysis Framework," *Computers in Industry* 101 (2018): 1–12.

3. J. Stodt, D. Schönle, C. Reich, F. Ghovanlooy Ghajar, D. Welte, and A. Sikora, "Security Audit of a Blockchain-Based Industrial Application Platform," *Algorithms* 14, no. 4 (2021): 121.

4. O. Peter, A. Pradhan, and C. Mbohwa, "Industrial Internet of Things (Iiot): Opportunities, Challenges, and Requirements in Manufacturing Businesses in Emerging Economies," *Procedia Computer Science* 217 (2023): 856–865.

5. A. K. Tyagi, "Decentralized Everything: Practical Use of Blockchain Technology in Future Applications," in *Distributed Computing to Blockchain* (Elsevier, 2023), 19–38.

6. C. H. Le, D. T. Le, D. Arey, et al., "Challenges and Conceptual Framework to Develop Heavy-Load Manipulators for Smart Factories," *International Journal of Mechatronics and Applied Mechanics* 8, no. 2 (2020): 209–216.

7. F. Stodt, M. B. Alshawki, C. Reich, F. Theoleyre, and P. Ligeti, "Blockchain-Based Privacy-Preserving Shop Floor Auditing Architecture," *IEEE Access* 12 (2024): 26747–26758.

8. M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," *OsDI* 99, no. 1999 (1999): 173–186.

9. S. De Angelis, L. Aniello, R. Baldoni, et al., "Pbft vs Proof-Of-Authority: Applying the Cap Theorem to Permissioned Blockchain," in *CEUR Workshop Proceedings*, vol. 2058 (CEUR-WS, 2018).

10. A. V. Barenji, Z. Li, and W. M. Wang, "Blockchain Cloud Manufacturing: Shop Floor and Machine Level," in *Smart SysTech 2018; European Conference on Smart Objects, Systems and Technologies* (VDE, 2018), 1–6.
11. Z. Li, A. V. Barenji, and G. Q. Huang, "Toward a Blockchain Cloud Manufacturing System as a Peer to Peer Distributed Network Platform," Robotics and Computer-Integrated Manufacturing 54 (2018): 133-144.

12. Z. Li, L. Liu, A. V. Barenji, and W. Wang, "Cloud-Based Manufacturing Blockchain: Secure Knowledge Sharing for Injection Mould Redesign," Procedia CIRP 72 (2018): 961-966.

13. T. Kobzan, A. Biendarra, S. Schriegel, T. Herbst, T. Müller, and J. Jasperneite, "Utilizing Blockchain Technology in Industrial Manufacturing With the Help of Network Simulation," in 2018 IEEE 16th International Conference on Industrial Informatics (INDIN) (IEEE, 2018), 152-159.

14. R. Y. Zhong, X. Xu, E. Klotz, and S. T. Newman, "Intelligent Manufacturing in the Context of Industry 4.0: A Review," Engineering 3, no. 5 (2017): 616-630.

15. A. Angrish, B. Craver, M. Hasan, and B. Starly, "A Case Study for Blockchain in Manufacturing: "Fabrec": A Prototype for Peer-To-Peer Network of Manufacturing Nodes," Procedia Manufacturing 26 (2018): 1180-1192.

16. S. Liu, Y. Lu, J. Li, X. Shen, X. Sun, and J. Bao, "A Blockchain-Based Interactive Approach Between Digital Twin-Based Manufacturing Systems," Computers & Industrial Engineering 175 (2023): 108827.

17. P. Schmid, A. Schaffhäuser, and R. Kashef, "Iotchain: Adopting Blockchain Technology to Increase Plc Resilience in an Iot Environment," Information (Basel) 14, no. 8 (2023): 437.

18. A. Jabbar and S. Dani, "Investigating the Link Between Transaction and Computational Costs in a Blockchain Environment," International Journal of Production Research 58, no. 11 (2020): 3423-3436.

19. D. Stefanescu, L. Montalvillo, P. Galán-García, J. Unzilla, and A. Urbieta, "A Systematic Literature Review of Lightweight Blockchain for Iot," IEEE Access 10 (2022).

20. S. Kably, M. Arioua, and N. Alaoui, "Lightweight Blockchain Network Architecture for Iot Devices," in 2020 International Symposium on Advanced Electrical and Communication Technologies (ISAECT) (IEEE, 2020), 1-6.

21. O. A. Ekanayake and M. N. Halgamuge, "Lightweight Blockchain Framework Using Enhanced Master-Slave Blockchain Paradigm: Fair Rewarding Mechanism Using Reward Accuracy Model," Information Processing & Management 58, no. 3 (2021): 102523.

22. Y. Liu, K. Wang, Y. Lin, and W. Xu, "Lightchain: A Lightweight Blockchain System for Industrial Internet of Things," IEEE Transactions on Industrial Informatics 15, no. 6 (2019): 3571-3581.

23. S. Khan, W.-K. Lee, and S. O. Hwang, "Aechain: A Lightweight Blockchain for Iot Applications," IEEE Consumer Electronics Magazine 11, no. 2 (2021): 64-76.

24. E. Bandara, D. Tosh, P. Foytik, S. Shetty, N. Ranasinghe, and K. De Zoysa, "Tikiri-Towards a Lightweight Blockchain for Iot," Future Generation Computer Systems 119 (2021): 154-165.

25. S. Yasmin, M. F. A. Al Sohan, M. N. B. Anwar, M. Hasan, and G. F. Hossain, "Sfc: A Lightweight Blockchain Model for Smart Food Industry," in 2021 2nd International Conference on Robotics, Electrical and Signal Processing Techniques (ICREST) (IEEE, 2021), 699-703.

26. A. H. Alkhazaali and A. Oğuz, "Lightweight Fog Based Solution for Privacy-Preserving in Iot Using Blockchain," in 2020 International Congress on Human-Computer Interaction, Optimization and Robotic Applications (HORA) (IEEE, 2020), 1-10.

27. F. Wang, J. Cui, Q. Zhang, D. He, C. Gu, and H. Zhong, "Lightweight and Secure Data Sharing Based on Proxy Re-Encryption for Blockchain-Enabled Industrial Internet of Things," IEEE Internet of Things Journal 11, no. 8 (2023): 14115-14126.

28. D. Na and S. Park, "Iot-Chain and Monitoring-Chain Using Multilevel Blockchain for Iot Security," Sensors (Basel) 22, no. 21 (2022): 8271.

29. X. Dai, Z. Zhang, J. Xiao, J. Yue, X. Xie, and H. Jin, "Gradeddag: An Asynchronous Dag-Based Bft Consensus With Lower Latency," in 2023 42nd International Symposium on Reliable Distributed Systems (SRDS) (IEEE, 2023), 107-117.

30. X. Dai, G. Wang, J. Xiao, et al., "Lightdag: A Low-Latency Dag-Based Bft Consensus Through Lightweight Broadcast," 2024 IEEE International Parallel and Distributed Processing Symposium (IPDPS) (2024), 998-1008.

31. B. Arun, Z. Li, F. Suri-Payer, S. Das, and A. Spiegelman, "Shoal++: High Throughput Dag BFT Can Be Fast!," arXiv preprint arXiv:2405.20488 (2024).

32. A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris-Kogias, "Bullshark: Dag BFT Protocols Made Practical," in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS '22) (Association for Computing Machinery, 2022), 2705-2718.

33. D. Kempa and T. Kociumaka, "Collapsing the Hierarchy of Compressed Data Structures: Suffix Arrays in Optimal Compressed Space," in 2023 IEEE 64th Annual Symposium on Foundations of Computer Science (FOCS) (IEEE, 2023), 1877-1886.

34. N. Chaudhry and M. M. Yousaf, "Consensus Algorithms in Blockchain: Comparative Analysis, Challenges and Opportunities," in 2018 12th International Conference on Open Source Systems and Technologies (ICOSST) (IEEE, 2018), 54-63.

35. A. Jahid, M. H. Alsharif, and T. J. Hall, "The Convergence of Blockchain, Iot and 6g: Potential, Opportunities, Challenges and Research Roadmap," Journal of Network and Computer Applications 217 (2023): 103677.

36. A. K. Tyagi, S. Dananjayan, D. Agarwal, and H. F. T. Ahmed, "Blockchain-Internet of Things Applications: Opportunities and Challenges for Industry 4.0 and Society 5.0," Sensors (Basel) 23, no. 2 (2023): 947.

37. A. Chaurasia, "Iiot Benefits and Challenges With Blockchain," in 2020 International Conference on Decision Aid Sciences and Application (DASA) (IEEE, 2020), 196-203.

38. R. Cerchione, P. Centobelli, and A. Angelino, "Blockchain-Based Iot Model and Experimental Platform Design in the Defence Supply Chain," IEEE Internet of Things Journal 10 (2023): 22033-22039.

39. K. Chen, D. Y. Golhar, and S. Banerjee, "Blockchain Applications and Challenges for Supply Chain and Industry 4.0: A Literature Review," International Journal of Applied Decision Sciences 16, no. 1 (2023): 1-41.

40. A. K. Das, M. Wazid, N. Kumar, A. V. Vasilakos, and J. J. Rodrigues, "Biometrics-Based Privacy-Preserving User Authentication Scheme for Cloud-Based Industrial Internet of Things Deployment," IEEE Internet of Things Journal 5, no. 6 (2018): 4900-4913.

41. X. Li, J. Niu, M. Z. A. Bhuiyan, F. Wu, M. Karuppiah, and S. Kumari, "A Robust Ecc-Based Provable Secure Authentication Protocol With Privacy Preserving for Industrial Internet of Things," IEEE Transactions on Industrial Informatics 14, no. 8 (2017): 3599-3609.

42. H. Xiong, Y. Wu, C. Jin, and S. Kumari, "Efficient and Privacy-Preserving Authentication Protocol for Heterogeneous Systems in Iiot," IEEE Internet of Things Journal 7, no. 12 (2020): 11713-11724.

43. B. Baruah and S. Dhal, "An Efficient Authentication Scheme for Secure Communication Between Industrial Iot Devices," in 2020 11th International Conference on Computing, Communication and Networking Technologies (ICCCNT) (IEEE, 2020), 1-7.

44. J. Cui, F. Wang, Q. Zhang, C. Gu, and H. Zhong, "Efficient Batch Authentication Scheme Based on Edge Computing in Iiot," IEEE Transactions on Network and Service Management 20, no. 1 (2022): 357-368.

45. M. B. Alshawki, Y. Yan, P. Ligeti, and C. Reich, "Attribute Verifier for Internet of Things," in 2022 32nd International Telecommunication Networks and Applications Conference (ITNAC) (IEEE, 2022), 1-3.