A Trusted Audit Architecture Using CP-ABE and Lightweight Blockchain for Industry 4.0

Abstract

The deep integration of Cyber–Physical Systems (CPSs) and embedded devices within Industry 4.0 has intensified security risks, particularly concerning data integrity and access control in resource-constrained environments. While blockchain offers decentralized trust for industrial infrastructures, its computational intensity poses significant challenges to the performance and security of embedded platforms. To address these issues, this paper proposes a lightweight, blockchain-based security architecture tailored for Industry 4.0 architectures. By integrating Ciphertext Policy Attribute-Based Encryption (CP-ABE) with a resource-efficient consensus mechanism, the proposed architecture establishes a multi-level root of trust to ensure secure data distribution and fine-grained access control across the system lifecycle. Under the evaluated simulation settings, the proposed lightweight consensus reduces the modeled hash-operation count by approximately 85% compared with Proof of Work (PoW) and improves the stability measure by 11.6% relative to PoW and 4.3% relative to Proof of Authority (PoA), while showing stronger alignment between node resource capability and election outcomes. These results provide proof-of-concept support for the proposed lightweight consensus mechanism in resource-constrained industrial audit environments.

1. Introduction

With the progress of Industry 4.0, a number of Cyber–Physical Systems (CPSs) and embedded devices in the manufacturing process have become connected and are now smart factories. Auditing serves as a foundation for maintaining data openness and stability in the system; at present, its primary functions are to ensure system reliability and promote continuous operation of the industrial ecosystem. However, distributed industrial environments have numerous deficiencies: Traditional auditing is conducted by central third-party organizations and manual verification, leading to extended cycles, high costs, and a lack of data source breadth in the audited entity; thus, risks of data alteration and reduced reliability have increased [1]. At the same time, the development of large volumes of diverse industrial data has raised demand for comprehensive traceability throughout the life cycle of the data. However, a lack of process transparency and delayed response may fail to detect an abnormality in time and thus cause irreparable operational losses and resource waste. Blockchain, with its decentralization, immutability, and transparency, provides a potential technical basis for improving audit traceability and trust. However, a significant obstacle to applying blockchain in Industry 4.0 scenarios is the high computational and energy costs of its consensus mechanism; therefore, it does not meet the resource-constrained environment and green industry sustainability requirements for large-scale deployment in Industrial Internet of Things (IIoT) devices. Existing Industry 4.0 and IIoT blockchain solutions mainly focus on data integrity, traceability, distributed storage, interoperability, intrusion detection, latency, and energy efficiency [2,3,4,5,6,7,8,9,10,11,12,13,14]. In parallel, studies on blockchain-enabled auditing emphasize audit transparency, process redesign, information sharing, consent/access management, and auditable evidence [15,16,17,18,19]. These two research streams address different layers of the problem: the former is primarily infrastructure- and device-oriented, whereas the latter is audit-process-oriented. However, the studies reviewed in Section 2 do not yet explicitly coordinate audit-lifecycle authorization, tamper-evident provenance verification, and resource-aware consensus within a unified industrial audit workflow. Accordingly, three interdependent gaps remain in blockchain-enabled industrial auditing: lifecycle-wide integrity verification, dynamic fine-grained authorization, and resource-aware low-overhead consensus. First, a unified framework to ensure the integrity of data at all times throughout its lifecycle has not been established, and standardized audit rules for closed-loop management at the stages of data generation, transmission, storage and destruction are missing. Second, multi-party audit environments still require dynamic and fine-grained authorization that can bind auditor attributes and task-specific access policies to protected audit data, while avoiding the coarse granularity and centralized trust of conventional access-control and key-management schemes. Third, resource-constrained and heterogeneous industrial devices require a lightweight consensus mechanism that can screen nodes according to both storage and computing capabilities, rather than relying on a single resource metric, while limiting consensus overhead. Based on the above gaps, this study addresses the following research questions:

RQ1: How can an industrial audit architecture provide fine-grained and lifecycle-aware access control over encrypted audit data?

RQ2: How can tampering with audit data be detected and traced against a trusted baseline throughout the audit lifecycle?

RQ3: How can resource-constrained and heterogeneous IIoT nodes be screened according to their storage and computing capabilities so that bookkeeping rights can be assigned with low consensus overhead?

RQ1 is addressed by the fine-grained access-control mechanism in Section 4.3, RQ2 is addressed through the threat/trust model and trusted-root mechanism in Section 4.1 and Section 4.2, and RQ3 is addressed by the lightweight consensus mechanism in Section 4.4 and quantitatively evaluated in Section 5.

Consequently, this paper proposes a trusted audit architecture based on Ciphertext Policy Attribute-Based Encryption (CP-ABE) and lightweight blockchain, aiming to address the current limitations in research on the integration of blockchain and auditing and providing a theoretical foundation and practical path for data integrity auditing in Industry 4.0 environments. The novelty of the proposed architecture does not lie in using CP-ABE, trusted roots, or blockchain consensus independently, but in coupling these mechanisms within the same audit lifecycle. CP-ABE binds auditor attributes and task-specific access policies to the release of audit-data decryption keys; the two-level trusted-root chain composed of the First-Level Trusted Root (FLTR) and Second-Level Trusted Root (SLTR) binds protected audit data to a verifiable preprocessing baseline for subsequent integrity verification; and the lightweight consensus mechanism screens bookkeeping candidates according to both storage availability and computational capability. In this coordinated design, CP-ABE determines who is authorized to access audit data, trusted-root verification determines whether the accessed data remain consistent with the original audit baseline, and resource-aware consensus determines which capable nodes maintain the immutable audit evidence ledger. Thus, the three mechanisms form a closed-loop relationship among access authorization, integrity verification, and low-overhead ledger maintenance, rather than operating as three parallel security components. The three main contributions of this paper are:

• We establish a trust-root-based consortium blockchain audit model that links FLTR/SLTR anchoring with lifecycle audit events to support full-lifecycle data provenance and integrity verification.
• We propose a CP-ABE-integrated identity and access management mechanism that binds auditor attributes and task-specific access policies to encrypted key distribution, enabling fine-grained and dynamic access control over audit data.
• We present a resource-aware lightweight consensus mechanism that filters bookkeeping candidates according to their storage and computing capabilities, thereby reducing election overhead while maintaining transaction stability.

The paper is structured as follows. Section 1 analyzes the research background, value and limitations of blockchain-audit integration and summarizes the key contributions of this paper. Section 2 reviews specific research efforts over the past five years in blockchain-audit integration and blockchain-attributed encryption. Section 3 discusses blockchain types suitable for audit scenarios, optimized audit business processes, identity/access management needs, and lightweight blockchain requirements. Section 4 details the paper’s core contributions in audit process redesign, identity management, and lightweight optimization. Section 5 includes scenario-based experiments and evaluation of the proposed model. Section 6 summarizes the contributions and research content, followed by future research directions.

2. Background and Recent Work

Existing studies relevant to blockchain-based industrial auditing can be grouped according to the three main requirements addressed in this work: trusted data integrity and auditability, fine-grained access control, and lightweight blockchain operation in resource-constrained environments. This section reviews these three research directions and identifies the remaining gap between them.

2.1. Blockchain-Based Audit Integrity and Trusted Architectures

Blockchain has been widely applied to improve data integrity, traceability, and trust in Industry 4.0. Juma et al. [2] proposed a trusted consortium blockchain framework for securing big-data integrity in IIoT environments, while Koustas et al. [3] employed a private Ethereum blockchain and NFT-based mechanisms to achieve lifecycle traceability of industrial components. Wang et al. [4] proposed Partitioned Vector Commitments to improve secure IIoT data storage. Other studies have extended blockchain-based trust to healthcare data sharing [5], food supply chains [6], Industrial CPSs [7], jewelry supply chains [8], and trusted interoperability in Industry 4.0 [9]. These works demonstrate the effectiveness of blockchain for immutable recording, provenance, and distributed trust.

More recent studies combine blockchain with complementary technologies to enhance industrial security and reliability. Gutiérrez et al. [10] integrated IoT architecture and blockchain-based security mechanisms; Song et al. [11] combined blockchain with machine-learning-based intrusion detection; Hameed et al. [12] investigated blockchain-supported distributed storage; Wakili et al. [13] combined digital twins, Hyperledger Fabric, and predictive analysis; Othman et al. [14] considered low-latency and energy-efficient Industry 4.0 networking.

In the auditing domain, Wang [15], Sheela et al. [16], Alkhwaldi et al. [17], Arianpoor et al. [18], and Jena [19] investigated blockchain from the perspectives of audit quality, financial reporting, professional adoption, regulatory interaction, and Industry 4.0 adoption. These studies demonstrate the potential of blockchain to improve audit transparency and efficiency, but mainly focus on adoption or process-level impacts rather than integrated technical architectures. More closely related to this work, Stodt et al. [20] proposed a privacy-preserving blockchain architecture for shop-floor auditing, while Román-Martínez et al. [21] integrated blockchain with consent management, access control, and auditing. Nevertheless, existing architectures mainly emphasize immutable records, traceability, privacy, or audit-process support, without simultaneously establishing lifecycle-oriented trusted data verification, fine-grained cryptographic authorization, and lightweight blockchain operation.

2.2. Fine-Grained Access Control and Privacy Protection

Distributed auditing involves multiple organizations and auditors with different responsibilities, making fine-grained authorization essential. Existing blockchain systems provide different forms of privacy and access protection. For example, secure data-sharing and storage mechanisms have been incorporated into federated learning [5], IoT security [10], and digital-twin environments [13]. However, these approaches mainly protect communication, storage, or system-level interactions.

Audit-oriented architectures provide more explicit access-control functions. Stodt et al. [20] address privacy-preserving auditing in IIoT environments, while Román-Martínez et al. [21] integrate consent management, access control, and blockchain-supported auditing. These studies show that access decisions can be incorporated into auditable blockchain workflows. However, policy- or system-level authorization does not necessarily bind access permissions directly to encrypted audit data.

For industrial auditing, access permissions should depend on multiple attributes, such as auditor role, department, task, and time period. Therefore, the remaining issue is how to combine fine-grained authorization with encryption so that only auditors whose attributes satisfy the corresponding audit policy can obtain the protected data. This motivates the CP-ABE-based mechanism introduced in this paper, while the detailed Attribute-Based Encryption (ABE) requirements and cryptographic design are further discussed in Section 3.2.

2.3. Lightweight Blockchain for Resource-Constrained IIoT

The computational and storage requirements of blockchain remain an important obstacle to its deployment in Industry 4.0. Existing research has addressed this problem from different directions. Hameed et al. [12] optimize distributed storage, and Othman et al. [14] focus on reducing latency and energy consumption in industrial networks.

Other studies reduce system overhead through intelligent optimization or heterogeneous node organization. Song et al. [11] integrate blockchain with intelligent or distributed computing technologies, while Stodt et al. [20] consider heterogeneous industrial participants within a blockchain-based auditing architecture. These approaches demonstrate that blockchain overhead can be reduced through permissioned architectures, optimized storage, edge-assisted processing, or differentiated node functions.

However, existing approaches generally optimize blockchain operation at the architecture or data-management level. They do not explicitly select bookkeeping nodes according to the joint storage and computing capabilities of heterogeneous audit participants. This distinction is important in industrial auditing, where resource-constrained devices should not bear the same blockchain responsibilities as more capable nodes. To clarify these differences, Table 1 compares representative studies.

Table 1. Comparison of representative related approaches.

Approach	Trust/Integrity	Fine-Grained Access Control	Encryption-Based Authorization	Resource/Consensus Optimization	Audit Lifecycle Support	Experimental Validation
Juma et al. [2]	✓	△	–	△	△	✓
Wang et al. [4]	✓	–	–	✓ Storage optimization	–	✓
Othman et al. [14]	✓	△	–	✓ Latency/energy optimization	–	✓
Stodt et al. [20]	✓	△	–	△ Hierarchical nodes/PBFT	△	✓
Román-Martínez et al. [21]	✓	✓	–	△	△	✓

✓: explicitly supported; △: partially or indirectly addressed; –: not a primary design objective.

As summarized in Table 1, existing studies provide complementary solutions but do not simultaneously satisfy the three requirements considered in this work. Juma et al. [2] and Wang et al. [4] primarily strengthen data integrity and blockchain data management; Othman et al. [14] emphasizes resource-efficient industrial operation; Stodt et al. [20] is closely related to industrial auditing but does not integrate CP-ABE-based audit-data authorization with resource-aware consensus; and Román-Martínez et al. [21] provides fine-grained access control and blockchain-supported auditing but does not cryptographically bind audit permissions to encrypted data or address resource-constrained consensus. Therefore, the remaining research gap is not the absence of these mechanisms individually, but the lack of a unified industrial audit architecture that combines trusted lifecycle data verification, cryptographically enforced fine-grained access control, and resource-aware lightweight consensus.

3. Problem and Requirement Analysis

3.1. Optimization of Audit Business Processes with Blockchain

The five links of the traditional audit process are preparation, execution, reporting, follow-up audits and storage [22]. As shown in Figure 1, the three stages of the audit lifecycle are Pre-Audit, Audit Execution and Post-Audit.

Figure 1. Traditional audit process.

• Pre-Audit: Data Preparation
  The audited entity provides the data required for subsequent auditing, which may be modified or selectively submitted before the audit begins. Blockchain immutability applies only after data have been committed and therefore cannot establish the correctness of source data. In the proposed architecture, source-data correctness relies on the underlying industrial data-acquisition layer. Once data enter trusted preprocessing, their hashes are bound to the trusted-root baseline so that subsequent modification can be detected.
• Audit Execution: Interaction and Activity Implementation
  Traditional audits often involve repeated cross-department communication and approval procedures, which may increase delay and information asymmetry. A permissioned blockchain can provide a shared and time-stamped record of audit-task updates and evidence exchanges, reducing redundant reconciliation while preserving accountability.
• Post-Audit: Traceability and Accountability
  Traditional archives may not preserve complete execution trails, making it difficult to identify when an operation occurred or which participant performed it. When audit operations, access events, and corresponding hash records are recorded on-chain, they provide tamper-evident evidence for subsequent traceability and accountability.

3.2. Fine-Grained Data Permission Management Requirements

Permissioned blockchains such as Hyperledger Fabric provide channel-based data isolation [23], while ABE enables policy-driven access to encrypted data. However, standalone ABE may face centralized trust, computational overhead, and dynamic user-management challenges [24], whereas blockchain-assisted ABE demonstrates that distributed trust can complement attribute-based authorization [25]. Industrial auditing involves auditees, auditors, and supervisory authorities with different responsibilities. Therefore, access decisions should consider multiple dimensions such as organization, role, audit task, security level, and time period; conventional role-based access control alone may not provide sufficient granularity.

ABE provides cryptographic access control based on user attributes [26], with CP-ABE and Key-Policy Attribute-Based Encryption (KP-ABE) being two representative forms. For example, an audit access policy can be expressed as:

$$\mathrm{Policy}=(\mathrm{Department}:\mathrm{Finance}\mathrm{AND}\mathrm{SecurityLevel}\ge 3)\mathrm{OR}(\mathrm{Role}:\mathrm{LeadAuditor}\mathrm{AND}\mathrm{TimeWindow}:2023\mathrm{Q}4)$$

This example illustrates that access conditions can combine multiple attributes such as department, security level, role, and time period. In the proposed architecture, such conditions are represented by the access structure tree T, and the auditor can recover the protected data key only when the attribute set A satisfies T.

Accordingly, the access-control mechanism should satisfy two requirements: audit data must remain confidential to unauthorized participants, and authorization must support fine-grained, task-dependent attribute policies.

3.3. Lightweight Blockchain Optimization

Blockchain consensus introduces computational and storage overhead, which becomes particularly significant when audit participants include resource-constrained industrial devices [27,28]. Conventional Proof of Work (PoW) requires repeated competitive hash computation and is therefore unsuitable for such environments. Audit participants are heterogeneous in computing capability, storage capacity, and network resources. Requiring every participant, particularly embedded devices, to operate as a full blockchain node may therefore limit practical deployment.

Therefore, a lightweight audit blockchain should reduce consensus computation and on-chain storage overhead, select bookkeeping nodes according to available resources, and maintain transaction continuity during node switching.

These limitations indicate that blockchain auditing requires not only reduced computational and storage burdens, but also stable operation under heterogeneous node capabilities. Together with the integrity and access-control requirements discussed above, these considerations are formalized in Section 3.4.

3.4. Formalized System Requirements

Based on the preceding analysis, the requirements of a trusted blockchain-based audit system can be summarized into six aspects:

R1: Data Integrity. Audit data should remain consistent after entering the trusted audit workflow, and any subsequent modification should be detectable.

R2: Data Confidentiality. Sensitive audit data should not be disclosed to unauthorized participants, and only authorized entities should be able to obtain the corresponding plaintext information.

R3: Authorization Granularity. Access control should support multiple audit-related attributes, such as department, role, security level, task, and time period, rather than relying only on coarse-grained roles.

R4: Computational Overhead. Blockchain-related computation should remain sufficiently low for heterogeneous and resource-constrained industrial or IIoT devices.

R5: Storage Overhead. The amount of blockchain-related data that individual participants must store should be limited to avoid excessive storage burden and improve scalability.

R6: System Availability. The audit system should maintain continuous and stable transaction processing when participating nodes change state or bookkeeping responsibilities are transferred.

Together, R1–R3 define the main security and access-control requirements, whereas R4–R6 define the resource-efficiency and operational requirements of blockchain-based auditing in Industry 4.0 environments.

4. Architecture Design

Based on the preceding analysis of the limitations of traditional audit processes and existing blockchain audit architectures, this section presents three main contributions: first, a consortium blockchain audit model based on a trusted root, designed to meet the requirements of audit scenarios; second, a data access control mechanism integrating CP-ABE, specifically designed to meet the needs of fine-grained data privacy protection and dynamic access control in auditing; third, we propose a lightweight blockchain consensus mechanism to resolve the incompatibility between existing blockchain technology and the audit scenario’s requirements for minimal burden and high efficiency.

4.1. Threat and Trust Model

The proposed architecture assumes a permissioned audit environment. The Supervision Department (SD) and Trusted Authentication Center (TAC) are treated as trusted authorities for policy definition and key management, while the Auditee Department (AED) and Auditor Department (AOD) may behave maliciously. The Global Data Center (GDC) is assumed to be honest-but-curious. For blockchain participation, the current prototype adopts a majority-honest operational assumption, under which more than half of the registered voting nodes are expected to follow the prescribed protocol. This assumption defines the trust boundary of the present design and should not be interpreted as a formally proven Byzantine fault-tolerance threshold. Standard cryptographic assumptions are also adopted, including collision-resistant hash functions and unforgeable digital signatures.

The architecture mainly addresses post-commitment manipulation. Audit data are committed to a trusted baseline before the corresponding audit task and auditor assignment are disclosed; therefore, later auditor–auditee collusion cannot selectively modify previously committed data without causing inconsistency during trusted-root verification. Fabricated source data submitted before baseline establishment and deliberate misreporting by an authorized auditor are outside this protection boundary. A malicious blockchain leader may delay transactions but cannot independently satisfy the majority-vote requirement, while compromise of the GDC may affect data availability although stored ciphertext remains encrypted. Because the TAC acts as the single CP-ABE key authority, compromise of its master key $MK$ may enable unauthorized attribute-key generation and invalidate CP-ABE confidentiality. Recovery requires revoking the affected key epoch, generating a new $(PK,MK)$ pair, and reissuing keys to valid auditors. A distributed or multi-authority extension is considered for future work.

4.2. Consortium Blockchain Audit Model Based on Trusted Roots

To further enhance the reliability of audit data—particularly during the early stages of the audit—this subsection proposes a trust-root-based consortium blockchain audit model. This framework consists of six core modules: SD, AOD, AED, Audit Consortium Blockchain (ACB), TAC, and GDC, each of which performs distinct functions. By clarifying the responsibilities and interaction logic of each module, this subsection explains how they work together to support trusted and traceable audit operations throughout the audit process, thereby providing an architectural basis for efficient audit management. As shown in Figure 2, a detailed analysis of each module is provided below:

Figure 2. Consortium blockchain audit model.

• SD
  SD dynamically constructs audit models according to business requirements, defines attribute sets for auditors (e.g., role permissions and professional domains), and applies fine-grained permission control through an access policy tree. SD is responsible for the distribution of encryption parameters and policies; it delivers the FLTR and encryption parameters to the TAC, and at the same time, pushes audit task metadata to the audit department via the blockchain for policy distribution verification. Finally, to store essential data such as the record of creation and modification logs for audit purposes in accordance with the audit task and policy, this department will build a tamper-evident audit trail for archiving and tracing audit evidence on the blockchain.
• AOD
  In the proposed architecture, the AOD is designed to operate within a Trusted Execution Environment (TEE) to protect sensitive data. Its main functions are as follows:
  • Secure Data Decryption: Receive encrypted data from the GDC, then use decryption parameters provided by the TAC and a policy tree issued by the SD to decrypt the data inside the TEE without leaking keys.
  • Audit Task Execution and Feedback: AOD verifies the accuracy and compliance of audit data with smart contracts, performs audit tasks according to audit models, and saves the results in the chain in real time.
  • Audit Execution Record Archiving: AOD’s operating records, data access logs and other vital indicators have been immutably recorded on the blockchain to construct an all-encompassing audit evidence chain for subsequent traceability and cross-validation.
• AED
  The AED, as the data source provider, focuses on trusted data preprocessing, with core responsibilities including:
  • Data Collection and Encryption: The AED integrates multi-source heterogeneous data through the Department Digital Data Center, encrypts the audit data using the symmetric data key $K_{data}$ to generate ciphertext $ED$, and generates the SLTR based on the FLTR to support subsequent integrity verification.
  • Trusted Data Transmission: AED synchronously transmits encrypted data and the Second Level Trusted Root to the GDC while recording trusted preprocessing actions on-chain. Storing the corresponding hash values on-chain enables subsequent detection of unauthorized modification during transmission.
• ACB
  The ACB, serving as the system’s distributed infrastructure, employs a multi-tiered archiving mechanism. While it does not store audit data, it ensures trusted on-chain storage of critical elements, such as trusted roots, audit task metadata, audit behavior trails, and audit results. Its responsibilities encompass:
  • Multi-Level Trusted Root Storage: ACB guarantees that both the FLTR (generated by the SD) and the SLTR (generated by the AED) are stored on-chain, establishing a cross-hierarchical data integrity verification network.
  • Audit Metadata Management: ACB archives audit task attributes, access policy trees, and smart contract code, enabling dynamic on-chain policy updates and version control.
  • Immutable Execution Trails: ACB uses its chain-based structure to record end-to-end lifecycle events for audit tasks from creation to completion, ensuring that every operation leaves a verifiable hash fingerprint.
• TAC
  TAC is responsible for identity authentication and certificate governance. It issues digital certificates to auditors based on a Public Key Infrastructure (PKI) and synchronizes certificate revocation lists via blockchain to enable real-time updates to identity status. It also generates trusted root certificates and cryptographic parameters—specifically, FLTR certificates—and uses the CP-ABE algorithm to derive master keys, public parameters, and user private keys, thereby enabling granular data access control and lightweight key management.
• GDC
  The GDC serves as the system-wide data storage and distribution layer and provides the following functions: First, distribute the ciphertext among multiple nodes and use InterPlanetary File System (IPFS) to improve storage efficiency and disaster recovery ability. Second, only a subset of the data can be accessed by auditors via a standardized API and is subject to authorization.

Interactions among the modules can be divided into the following three parts: First is a trusted data preprocessing workflow that encrypts the data, sends the ciphertext and the secondary trusted root to the GDC, and simultaneously initiates blockchain archiving. Second, the creation and execution of closed-loop audit tasks: the supervisory department sets audit policies and records them on-chain to automatically trigger task distribution by smart contracts. Third, the trusted verification mechanism requires that all data access or policy modifications be authorized by multi-signature approval; FLTR needs the joint signature of the SD and TAC, and SLTR requires the joint authentication of the AED and blockchain nodes to establish a dual-trust anchor. Detailed Module interaction and audit workflow steps will be introduced in the next section.

4.3. Fine-Grained Data Permission Management Mechanism Based on the Audit Lifecycle

The granular data permission management mechanism divides the audit process into four primary phases: trusted audit preprocessing, audit project and task creation, audit data permission acquisition, trusted audit verification and execution.

The trust and adversarial assumptions of this mechanism follow the Threat and Trust Model in Section 4.1. The TAC acts as the single key authority responsible for validating auditor attributes and generating CP-ABE keys; auditors cannot assign attributes to themselves. This work does not propose a new CP-ABE cryptographic construction. Instead, the access-control mechanism adopts the existing Bethencourt Sahai Waters CP-ABE (BSW07) scheme [26], instantiated using the Charm-Crypto CPabe_BSW07 [29] implementation. The pairing group is configured as BN254, and auditor attributes are represented as strings, including Role, Department, SecurityLevel, TaskID, and TimeWindow/Epoch.

For each audit task, the TAC executes $Setup$ to obtain the public parameter $PK$ and master key $MK$ and generates an attribute secret key $S{K}_A$ for the verified attribute set A. The AED protects the 256-bit data key $K_{data}$ under access policy T, producing $EK=Encrypt(PK,K_{data},T)$. An auditor can recover $K_{data}$ only when $A\vDash T$. BSW07 provides resistance to cryptographic collusion among independently issued user keys; organizational collusion between auditors and auditees follows the security boundary defined in Section 4.1.

Attribute revocation and key renewal are managed using task- and epoch-bound attributes. Each task key includes a TaskID and a valid TimeWindow/Epoch. When an auditor is revoked or an audit period expires, the TAC updates the certificate revocation status and does not issue the secret key for the next epoch to that auditor. Subsequent protected data use an updated policy and a fresh $K_{data}$. Thus, revoked users cannot access newly protected audit data. Revocation is therefore prospective: it prevents access to data protected in subsequent epochs but does not affect plaintext obtained during a previously valid epoch.

4.3.1. Trusted Audit Preprocessing Phase

As illustrated in Figure 3, the trusted audit preprocessing phase involves the following interactions:

Figure 3. Trusted audit preprocessing phase.

• Trusted root construction and data preprocessing (Steps 1–6)
  During initialization, the TAC generates the FLTR ($T{R}_1$) by hashing a randomly generated value $T{R}_1=Hash\left(n\right)$, establishing the foundational trust anchor for subsequent data processing and verification. $T{R}_1$ is transmitted to the AED via an encrypted channel, then the AED computes the hash of raw data $H_1=Hash\left(DATA\right)$ and synthesizes $T{R}_1$ with $H_1$ to generate the SLTR ($T{R}_2=Hash(T{R}_1+H_1)$). This dual-trust-root design employs a chained hash structure to ensure data provenance traceability—$T{R}_1$ serves as a randomized seed providing the initial trust anchor, while $T{R}_2$ binds to specific data characteristics, forming a tamper-evident audit baseline. Both trust roots are synchronously stored on the ACB and TAC, laying the decentralized trust foundation for subsequent audits.
• Data encryption and persistent storage with trusted archiving (Steps 7–10)
  The AED encrypts audit data using a symmetric key $K_{data}$ to generate ciphertext $ED$, rendering the data available but invisible. After storing $ED$ in the GDC, its hash value $H_1$ and trusted preprocessing logs are recorded on the ACB via distributed ledger technology, solidifying the data processing trail, which ensures full lifecycle verifiability of preprocessing operations while preserving data privacy. The GDC provides persistent storage for $ED$, while the ACB immutably archives trusted preprocessing activities on-chain, establishing a dual-loop framework integrating data flow and trust flow.

The trusted audit preprocessing phase adheres to a preventive risk management approach by embedding validation factors during the data collection stage—a stark contrast to traditional post-audit models—thereby reducing the cost of error correction and providing a reliable data foundation for subsequent audit execution.

4.3.2. Audit Project and Task Creation Phase

As depicted in Figure 4, the audit project and task creation phase involves the following interactions:

Figure 4. Audit project and task creation phase.

• Audit project modeling and task definition (Steps 1–4)
  The SD creates audit projects based on audit requirements and specifies audit tasks within this process, which includes defining task specifics, the access structure tree T, and auditor attribute sets. Precise task delineation ensures audit objective accuracy and execution traceability. The T employs logical expressions (e.g., “(Position = Senior Auditor) AND (Department = Compliance)”) to define data access hierarchies and permissions, enforcing the principle of least privilege. Upon task creation, the SD transmits the audit task and the corresponding access policy T to the AED. Simultaneously, the SD defines the auditor attribute requirements associated with the task for subsequent authorization. The TAC then verifies the auditor’s registered attribute set and generates the corresponding CP-ABE attribute secret key $S{K}_A$, ensuring that only auditors satisfying the task-specific requirements can obtain the required decryption key. Blockchain records audit project creation via smart contracts, utilizing Merkle trees to store task metadata for transparent and tamper-resistant task definition.
• Certificate verification and encrypted data acquisition (Steps 5–9)
  The AOD uses the identity certificate $CA$ issued by the TAC and associated with its registered attribute set A. The certificate status is checked against the revocation information before the audit task proceeds; the AOD cannot self-assign attributes. The AOD then requests the corresponding ciphertext $ED$ from the GDC according to the assigned audit task, while the associated access events are recorded on the ACB.

4.3.3. Audit Data Permission Acquisition Phase

As shown in Figure 5, the audit data permission acquisition phase involves the following interactions:

Figure 5. Audit data permission acquisition phase.

• Key encryption and transmission (Steps 1–6)
  The AED obtains the public parameters $PK$ for the audit task from the TAC. It then encrypts the symmetric data key $K_{data}$ under the task-specific access policy T using CP-ABE, producing $EK=Encrypt(PK,K_{data},T)$. The encrypted data key $EK$ is transmitted to the AOD, while $K_{data}$ itself is not directly disclosed. The corresponding key-access events are recorded on the ACB for subsequent traceability.
• Key decryption and audit data decryption phase (Steps 7–10)
  The AOD submits its verified attribute set A and task information to the TAC. After validating the auditor’s identity, attribute status, and authorization period, the TAC generates the corresponding CP-ABE attribute secret key $S{K}_A=KeyGen(PK,MK,A)$, where $MK$ is the master key maintained by the TAC. The AOD can recover $K_{data}$ from $EK$ only when its attribute set satisfies the access policy, i.e., $A\vDash T$. The recovered $K_{data}$ is then used to decrypt the audit ciphertext $ED$ and obtain the audit data $DATA$. The resulting data are subsequently used for the audit task and trusted-root verification described in Section 4.3.4.

4.3.4. Trusted Audit Verification and Execution Phase

In Figure 6, the trusted audit verification and execution phase involves the following interactions:

Figure 6. Trusted audit verification and execution phase.

• Audit data trusted root verification (Steps 1–3)
  The AOD requests the FLTR ($T{R}_1$) and SLTR ($T{R}_2$) for the audit task based on project requirements, which serve as the core verification basis for ensuring data provenance trustworthiness and subsequent audit activities. The request process is conducted via the ACB to guarantee task transparency and traceability. Upon receiving the request, the ACB returns the corresponding $T{R}_1$ and $T{R}_2$ stored on-chain, then the AOD computes a new SLTR (${T{R}_2}^{\prime }$) based on ${H_1}^{\prime }$ (the hash value of audit data) and $T{R}_1$. Upon completion, the AOD verifies whether the newly generated ${T{R}_2}^{\prime }$ matches the returned $T{R}_2$. If the two values match, the retrieved data are confirmed to be consistent with the previously committed baseline.
• Audit task execution (Steps 4–8)
  After verifying the audit data trusted roots, the AOD requests the audit computational model from the SD. This model serves as the core tool for performing specific audit calculations and analyses, defining rules and workflows to ensure efficient task execution. The SD returns the audit model to the AOD based on task requirements, which encompasses essential computational methods, algorithms, and data processing rules, forming the foundation for auditors’ data validation and calculations. Upon receiving the model, the AOD executes audit computations on the data within a TEE. Once completed, all trusted audit computation actions are recorded on the ACB. Blockchain recording provides tamper-evident and traceable records of these computation events.

Trusted-root verification allows the AOD to determine whether the retrieved audit data remain consistent with the previously committed baseline. The audit model provides predefined rules and workflows for subsequent audit computations, while the corresponding computation events and audit results are recorded on the ACB. These on-chain records provide tamper-evident and traceable evidence for subsequent verification and accountability.

4.4. Lightweight Blockchain Consensus Mechanism for Low Computational Load

The high operational burden of blockchain on devices primarily stems from the allocation of bookkeeping rights within the network, where PoW evaluates a node’s computational capacity while Proof of Stake (PoS) employs asset holdings as the criterion for bookkeeping right election. Solely considering a single capability metric imposes undue pressure on participants in audit scenarios and may not align with practical demands; thus, this section proposes a lightweight blockchain consensus mechanism that holistically integrates nodes’ computational throughput and storage scalability, enabling efficient allocation of network bookkeeping rights with low overhead costs.

• Block data structure
  The block header records basic network status information, allowing nodes to monitor network conditions by detecting changes in these records. Key fields include the Timestamp, BlockNumber, BlockHash, PreBlockHash, and MerkleRoot, alongside governance-specific parameters: Term, LeaderNode, DeputyLeaderNode, Proof-of-Storage Answer Set (PoStAnswerSet) for elections, and the Vote/Signature Information Collection used to reach consensus.
• Blockchain accounting rights election
  The election for the blockchain accounting right will determine the Leader Node and Deputy Leader Node. The first round of execution will produce the network’s first Leader Node, and the following rounds will select Deputy Leader Nodes. All the elections after the first are organized simultaneously with the block generation. The algorithm favors high-storage-capacity nodes; therefore, they will store a larger number of blocks and thus be excluded from the filter. When storage capacity is the same, the one with higher computational power will be selected; that is to say, it can perform hash operations more rapidly to speed up the broadcast of verified data. The three stages of the protocol are Election Pre-Preparation, Election Proof and Election Verification, and their specific contents are as follows.

4.4.1. Election Pre-Preparation Phase

As described in Figure 7, during the Election Pre-Preparation Phase, a data file is partitioned into n DataBlocks. Each network node stores q blocks ($q\le n$) based on its storage capacity. The algorithm then randomly selects k blocks ($k<n$) from the n blocks to form a DataBlock set $AnswerSe{t}_k$:

$${AnswerSet}_k=\{{DataBlock}_5,{DataBlock}_8,\dots ,{DataBlock}_{n-2}\},k<n$$

Figure 7. Election pre-preparation phase.

Subsequently, using a Verifiable Random Function (VRF) [30] $VRFGen$ with inputs of the node’s private key $Sk$ and a random $seed$, a random number Q and the randomness proof $VRFProof$ are generated. Based on Q, a random number set $RandomNumberSe{t}_k$ is created:

$$\begin{array}{c}\hfill \{Q,VRFProof\}=VRFGen(Sk,seed)\end{array}$$

$$\begin{array}{c}\hfill {RandomNumberSet}_k=\{Q,Q+1,Q+2,\dots ,Q+k-1\},k<n\end{array}$$

The node initiating the VRF function—randomly selected by the algorithm—serves as the challenger node for the storage proof. Here, $Pk$ and $Sk$ denote its public–private key pair. Next, the binary strings of the k numbers in $RandomNumberSe{t}_k$ are concatenated with the content of the pre-selected k data blocks, yielding a new DataBlock set $NewDataBlock{s}_k$:

$$\begin{array}{c}\hfill NewDataBlock{s}_k=\left[\begin{array}{c}NewDataBloc{k}_1\\ NewDataBloc{k}_2\\ ⋮\\ NewDataBloc{k}_k\end{array}\right]=\left[\begin{array}{c}DataBloc{k}_5\\ DataBloc{k}_8\\ ⋮\\ DataBloc{k}_{n-2}\end{array}\right]+\left[\begin{array}{c}Q\\ Q+1\\ ⋮\\ Q+k-1\end{array}\right]\end{array}$$

The concatenated blocks are then hashed sequentially to produce a storage proof answer set $PoStAnswerSe{t}_k=\left\{Has{h}_1,Has{h}_2,Has{h}_3,\dots ,Has{h}_k\right\}, k<n$:

$$\begin{array}{c}\hfill PoStAnswerSe{t}_k=\left[\begin{array}{c}Has{h}_1\\ Has{h}_2\\ ·\\ ·\\ Has{h}_k\end{array}\right]=Hash·\left[\begin{array}{c}NewDataBloc{k}_1\\ NewDataBloc{k}_2\\ ·\\ ·\\ NewDataBloc{k}_k\end{array}\right]\end{array}$$

$PoStAnswerSe{t}_k$ is stored locally by the challenger node. Finally, the block index set $AnswerNumSet$, random number Q, randomness proof $VRFProof$, the challenger’s public key $Pk$ and $Signature$ are packaged into a proof challenge packet:

$$PoStChallenge=\{AnswerNumSet,Q,VRFProof,Pk,Signature,seed\}$$

and broadcast to the blockchain network.

4.4.2. Election Proof Phase

As illustrated in Figure 8, during the Election Proof Phase, participating nodes receive the $PoStChallenge$ packet from the blockchain network. Upon unpacking the packet to obtain $AnswerNumSet$, Q, $VRFProof$, $Pk$, $Signature$ and $seed$, nodes first verify the $Signature$ for authenticity. Subsequently, they validate the legitimacy of random number Q using the VRF verification function $VRFVer$:

$$\begin{array}{c}\hfill \begin{array}{c}True/False=SignatureVer(Signature,Pk)\\ True/False=VRFVer(Q,VRFProof,Pk,seed)\end{array}\end{array}$$

Figure 8. Election proof phase.

If both signature and VRF verification pass, the node retrieves data blocks corresponding to $AnswerNumSet$ from its local database. Due to heterogeneous storage capacities, nodes store varying quantities of data blocks, let m denote the number of qualifying blocks a node locates $(k/2\le m\le k)$. For instance, a node concatenates these m blocks $\left\{DataBloc{k}_8,DataBloc{k}_{19},\dots ,DataBloc{k}_{k-2}\right\}$ with their corresponding random numbers $\left\{Q+1,Q+2,\dots ,Q+x\right\}$ and computes the storage proof answer set $PoStAnswerSe{t}_m$:

$$\begin{array}{c}\hfill PoStAnswerSe{t}_m=\left[\begin{array}{c}Has{h}_1\\ Has{h}_2\\ ·\\ ·\\ Has{h}_m\end{array}\right]=Hash·\left(\left[\begin{array}{c}DataBloc{k}_8\\ DataBloc{k}_{19}\\ ·\\ ·\\ DataBloc{k}_{k-22}\end{array}\right]+\left[\begin{array}{c}Q+1\\ Q+2\\ ·\\ ·\\ Q+x\end{array}\right]\right)\end{array}$$

When a node retrieves a number of qualifying data blocks $m<k/2$, it becomes ineligible for the current election round, while the qualified nodes package Q, $VRFProof$, $PoStAnswerSe{t}_m$, their public key $Pk$, and a $Signature$ into a storage proof packet $PoStProof$ defined as:

• PoStProof
  A PoStProof packet is a signed data packet broadcast to the blockchain network after a node computes the required $PoStAnswerSe{t}_m$ for the election. Upon broadcasting this packet, the node collects votes from other nodes and the vote information is defined as:
• Vote Information
  Upon receiving a PoStProof packet from a candidate node, other nodes verify the message’s authenticity. If valid, they sign the message to generate Vote Information and reply to the candidate node. Each node may cast only one vote per election round, When a candidate node collects votes exceeding $50\%$ of the total network nodes, it is elected as the Leader Node, initiates its term and generates the GenesisBlock.

4.4.3. Election Verification Phase

As shown in Figure 9, the final phase—Election Verification Phase—requires all nodes to check PoStProof in the blockchain network. Upon receiving a PoStProof packet, a node unpacks it to verify the signature and legitimacy of random number Q using the same procedure as the Election Proof Phase.

Figure 9. Election verification phase.

If valid, the node retrieves data blocks corresponding to the indices in $PoStAnswerSe{t}_m$ from local storage, forming $LocalDataBlocks=\left\{LocalDataBloc{k}_{19},\dots ,LocalDataBloc{k}_{k-22}\right\}$ (in this case, the node does not store $DataBloc{k}_8$). It then computes $LocalHashSet$ for comparison verification with $PoStAnswerSe{t}_m$:

$$\begin{array}{c}\hfill Hash·\left(\left[\begin{array}{c}LocalDataBloc{k}_{19}\\ ·\\ ·\\ LocalDataBloc{k}_{k-22}\end{array}\right]+\left[\begin{array}{c}Q+2\\ ·\\ ·\\ Q+x\end{array}\right]\right)=LocalHashSet\stackrel{?}{=}PoStAnswerSe{t}_m\end{array}$$

If all $LocalHas{h}_i$ in $LocalHashSet$ values identically match every $Has{h}_i$ in $PoStAnswerSe{t}_m$, the node votes for the packet sender; if any hash mismatch is detected, no vote is cast; also if the received $PoStAnswerSe{t}_m$ contains fewer elements than the node’s locally generated set, no vote is cast. When multiple validated packets exist, the node votes for the candidate with the largest $PoStAnswerSe{t}_m$, and each node votes only once per election round. The Vote packet contains voting information, voter public key $Pk$, and its $Signature$.

4.5. Implementation Scope and Prototype Status

The current prototype implements the proposed lightweight consensus mechanism and functionally instantiates the CP-ABE access-control process described in Section 4.3. The multi-level trusted-root mechanism is specified at the protocol/workflow level, while IPFS, TEE, PKI, multi-signature authorization, and smart contracts are treated as supporting architectural components. The quantitative experiments in Section 5 primarily focus on the proposed lightweight consensus mechanism, supplemented by a small performance benchmark of the functionally implemented CP-ABE component.

5. Experiments and Discussion

5.1. Experimental Setup and Lightweight Consensus Evaluation

Following the implementation scope defined in Section 4.5, the quantitative evaluation focuses on the proposed lightweight consensus mechanism. Three experiments examine resource-aware leader election, calculation count, and transaction-processing stability. PoW is used as a comparison baseline, while a simplified permissioned Proof-of-Authority (PoA) [31] mechanism is additionally included in the stability evaluation.

The experimental network consists of 30 logical nodes. Node storage capability is represented by different numbers of locally stored data blocks, while relative computing capability is represented by a configurable processing delay $d_i$, with $C_i\propto 1/d_i$. The experiments were conducted on a workstation equipped with an Intel Core i7-12700 processor and 16 GB RAM under Ubuntu 22.04. The consensus prototype was implemented in Python 3.10 as a custom simulation of the proposed election protocol and the PoW baseline. For the stability evaluation, each run contains 30 election cycles and each consensus configuration is independently repeated 30 times. The PoA baseline uses pre-authorized validators, with validator revalidation performed every 10 election cycles. All mechanisms are evaluated under the same node and workload settings. The results are reported using the mean, standard deviation (SD), and 95% confidence interval (CI).The degree of internal dispersion within a dataset is typically quantified by the Coefficient of Variation ($CV$), defined by the following formula:

$$\begin{array}{c}\hfill \mathrm{CV}={\displaystyle \frac{\sigma }{\mu }}={\displaystyle \frac{n\sqrt{\frac{\sum {(x_i-\mu )}^2}{n}}}{\sum x_i}}\end{array}$$

Therefore, we employed the $CV$ to assess the average distribution of computing and storage capacity across all nodes, as well as the disparity in election outcomes (for instance, determining whether the elected leader nodes are consistently confined to a small, fixed set). The $CV$ for node data block storage is denoted as $CV$ of node Computing and Storage capability ($CVCS$), while the $CV$ for election results is denoted as $CV$ of Election Results ($CVER$). In this study, election accuracy refers to the alignment between relative node resource capability and the observed leader-election outcome.

As shown in Figure 10, the total number of nodes is fixed at 30 and the total number of stored data blocks is fixed at 150k, while $CVCS$ varies from 0.05 to 0.7. The observed negative association between $CVCS$ and $CVER$ indicates that increasing heterogeneity in node computing and storage capabilities leads to more concentrated election outcomes. Compared with PoW, the proposed mechanism shows stronger sensitivity to the configured node capabilities.

Figure 10. Comparison of $CVER$ between the proposed lightweight consensus and PoW.

As shown in Figure 11, with 30 nodes and $CVCS$ fixed at 0.3, the total number of stored data blocks is increased from 150k to 750k. Computational overhead is measured at the algorithmic level by counting hash operations, where each hash computation increases the counter by one. Under the evaluated configurations, the calculation count of the proposed mechanism remains approximately 15% of that of PoW, corresponding to an approximately 85% reduction in modeled hash-operation count.

Figure 11. Comparison of calculation count between the proposed lightweight consensus and PoW.

In this study, the stability measure is derived from the coefficient of variation of TPS over the 30 election cycles within each independent run. A lower TPS coefficient of variation indicates smaller relative fluctuations and therefore more stable transaction processing. To express stability as a positively oriented score, the stability measure is defined as $S=1-C{V}_{\mathrm{TPS}}$, where a larger S indicates higher transaction-processing stability.

Figure 12 compares the stability measure of the proposed lightweight consensus, PoW, and PoA across 30 independent runs. The proposed mechanism achieves the highest mean stability value (0.8928), followed by PoA (0.8560) and PoW (0.8000). Compared with PoW and PoA, the proposed mechanism improves the stability measure by 11.6% and 4.3%, respectively. The corresponding 95% confidence intervals are [0.8906, 0.8950] for the proposed mechanism, [0.7967, 0.8033] for PoW, and [0.8524, 0.8596] for PoA.

Figure 12. Comparison of stability measure among the proposed lightweight consensus, PoW, and PoA across 30 independent runs.

5.2. CP-ABE Performance Benchmark

To provide a basic quantitative evaluation of the functionally implemented CP-ABE component, we conducted a small performance benchmark of the BSW07 scheme using the Charm-Crypto CPabe_BSW07 implementation with the BN254 pairing group. A 10-attribute access policy was used, with five warm-up runs followed by 30 independent measured runs. The execution times were recorded as mean ± standard deviation. As shown in Table 2, the average execution times of Setup, KeyGen, Encrypt, and Decrypt were 23.091 ± 0.506 ms, 12.390 ± 0.304 ms, 16.622 ± 0.954 ms, and 341.063 ± 6.875 ms, respectively. Among the four operations, Decrypt incurred the highest computational cost, whereas Setup, KeyGen, and Encrypt remained below 25 ms under the evaluated configuration. These results provide a small-scale characterization of the computational overhead of the CP-ABE component and are not intended as a comprehensive scalability evaluation with respect to the number of attributes.

Table 2. Performance benchmark of the BSW07 CP-ABE implementation.

Operation	Execution Time (ms, Mean ± SD)
Setup	23.091 ± 0.506
KeyGen	12.390 ± 0.304
Encrypt	16.622 ± 0.954
Decrypt	341.063 ± 6.875

5.3. Evaluation Against System Requirements

The proposed architecture was designed according to the six requirements defined in Section 3. R1 (data integrity) is addressed by the multi-level trusted-root mechanism, while R2 (data confidentiality) and R3 (authorization granularity) are supported by the CP-ABE-based access-control mechanism. These requirements are primarily supported at the architectural and functional-design level rather than quantitatively evaluated in the present experiments.

R4 (computational overhead) is directly evaluated in Figure 11, where the proposed consensus requires approximately 15% of the modeled hash-operation count of PoW. R5 (storage overhead) is addressed architecturally by storing encrypted audit data off-chain while retaining only trusted roots, metadata, and audit records on-chain, although its storage reduction is not independently measured. R6 (system availability) is partially evaluated in Figure 12 through the repeated stability comparison among the proposed consensus, PoW, and PoA. Therefore, the current quantitative evaluation directly addresses R4 and partially addresses R6, whereas R1–R3 and R5 are supported primarily at the architectural and functional-design level.

5.4. Threats to Validity

• Internal validity
  The experiments use logical nodes executed within a controlled simulation environment. Computational capability is represented by processing delay as a proxy for relative computational service rate. This abstraction isolates resource heterogeneity for algorithm evaluation but does not reproduce processor architecture, memory behavior, energy consumption, or operating-system scheduling of physical IIoT devices.
• External validity
  The 30-node network and simulated workload represent a proof-of-concept setting. Physical network topology, distributed communication latency, and broader device heterogeneity are not represented; therefore, the observed behavior may differ in large-scale or geographically distributed Industry 4.0 deployments.
• Construct validity
  The selected metrics characterize algorithm-level properties. Calculation count measures modeled hash operations rather than CPU execution time or energy consumption; the stability measure summarizes logical transaction-processing behavior under the simulated workload rather than physical-network availability; and CVER characterizes the alignment between configured node resources and election outcomes. Byte-level transaction and block sizes are not independently modeled.
• Conclusion validity
  The evaluation includes both PoW and a simplified permissioned PoA baseline, with 30 independent runs used for the stability evaluation and uncertainty quantified using 95% confidence intervals. Nevertheless, the results remain limited to the evaluated simulation settings and do not establish superiority over all lightweight or permissioned consensus mechanisms. Future work will consider larger heterogeneous physical networks and additional permissioned consensus baselines.

6. Conclusions

This paper proposes a trusted audit architecture for Industry 4.0 that integrates a multi-level trusted-root mechanism, CP-ABE-based fine-grained access control, and a resource-aware lightweight consensus mechanism. The trusted-root mechanism establishes a verifiable baseline for detecting subsequent modification of audit data, while CP-ABE binds auditor attributes and task-specific policies to encrypted key distribution. The lightweight consensus mechanism further considers both storage and computing capabilities when selecting bookkeeping nodes.

The quantitative evaluation focuses primarily on the lightweight consensus component. Under the evaluated simulation settings, the proposed mechanism reduces the modeled hash-operation count by approximately 85% compared with PoW and improves the stability measure by 11.6% relative to PoW and 4.3% relative to PoA, while exhibiting stronger alignment between node resource capability and election outcomes. These results provide proof-of-concept support for the proposed consensus design rather than an end-to-end validation of the complete architecture.

Future work will evaluate the architecture on larger heterogeneous physical IIoT networks, extend the comparison to additional permissioned consensus mechanisms, and develop a more fully integrated system prototype.