Optimizing Smart-Home Energy Systems Through Energy-Efficient Off-Chain Blockchain-Based Attribute-Based Access Control (ABAC): A Hybrid LightGBM Approach

Abstract

The widespread deployment of Internet of Things (IoT) technologies in smart-home energy systems has increased the demand for secure, context-aware, and energy-efficient access control (AC) mechanisms. Although blockchain-based AC provides immutability, auditability, and fine-grained policy enforcement, its dependence on on-chain decision-making introduces significant computational latency and energy overhead, limiting its suitability for resource-constrained IoT environments. This paper proposes Optimized Dynamic-Attribute-Based Access Control-IoT (ODABAC-IoT), a hybrid off-chain and decentralized ABAC framework that combines off-chain LightGBM inference with selective on-chain verification to reduce blockchain workload while preserving trust and transparency. This work focuses on improving the computational efficiency, latency, and energy consumption of blockchain-enabled AC within smart-home energy systems, rather than directly optimizing physical energy consumption. In the proposed framework, high-confidence access requests are evaluated off-chain, whereas uncertain requests are forwarded to smart contracts for final validation. This hybrid decision-making strategy reduces unnecessary blockchain transactions, lowers latency, and improves computational efficiency without compromising security. Experimental results demonstrate up to 65% reduction in blockchain transaction volume, 64% improvement in latency, and 65% reduction compared to on-chain ABAC and 50% compared to hybrid blockchain approaches. These gains correspond to a reduction in daily blockchain energy consumption from 10 kWh to 3.5 kWh in a representative household scenario. The results indicate that ODABAC-IoT improves scalability, energy efficiency of the digital control layer, and responsiveness in IoT-enabled smart home energy systems, offering an effective pathway toward energy-aware and secure AC in the digital infrastructure of smart home energy systems.

1. Introduction

The increasing demand of the world towards more energy-efficient and sustainable technologies has enhanced the necessity of more complex control of electricity use and efficient management in interconnected surroundings. In smart-home and smart-grid scenarios, there is a wide range of IoT devices constantly communicating to balance loads, distributed generation, and overall energy efficiency. However, despite providing a high level of security and transparency, blockchain-based AC often results in both computational and energy overhead, which can undermine the efficiency benefits themselves. As a result, an increasing demand is building around lightweight and intelligent frameworks to ensure controlled and energy-aware operation of IoT-enabled energy systems.

IoT is becoming an increasing mainstay in industries such as healthcare, smart cities, and industrial automation. Nevertheless, as IoT Networks grow, concerns about AC, security, and scalability have also increased. Hasan et al. in [1] proposed a smart-contract-based AC framework addressing these challenges by utilizing blockchain for decentralized and secure policy enforcement. Waheed et al. [2] proposes a dynamic ABAC framework that integrated off-chain machine learning (ML) to reduce computational costs and improved system responsiveness by pre-evaluating access requests before they were processed on the blockchain, addressing the limitations of traditional Role-Based Access Control (RBAC), which is inflexible for fast-paced IoT environments with devices frequently joining and leaving networks. As a more context-sensitive solution, ABAC has potential but is not practically implemented due to complexity and insufficient decentralization [3].

Blockchain technology provides a decentralized way of AC, increasing the integrity and transparency of data sharing in IoT systems [4]. The use of smart contracts generated on a blockchain platform is beneficial as it provides automated and tamper-proof access decisions. However, using blockchain in the IoT presents issues in terms of performance and latency, notably with the availability of resources for low-powered devices [5].

In order to circumvent these issues, researchers have proposed hybrid models that pair blockchain with off-chain ML components. In a hybrid architecture, ML models can be employed to preprocess incoming access requests to filter out low-risk or high-confidence decisions and only submit ambiguous decisions to the blockchain, which reduces overhead [6]. LightGBM and Random Forest classifiers, for example, have shown good performance in improving the accuracy of access decisions and responsiveness of the system in a hybrid model architecture [7].

Recent studies have shown that ML can improve authentication and AC in resource-constrained IoT settings with good accuracy and lightweight performance [8]. Also, the use of distributed blockchain frameworks using ABAC can reduce single points of failure and improve scalability [9].

While these approaches improve AC efficiency, their impact on the energy consumption of the underlying blockchain infrastructure in smart-home energy systems remains insufficiently explored.

This paper proposes ODABAC-IoT, an off-chain and decentralized ABAC framework for IoT. ODABAC-IoT employs a preprocessing layer using LightGBM to assess access requests off-chain. Only those requests that are uncertain are forwarded to on-chain smart contracts for final validation. This represents a meaningful decrease in both the volume of blockchain transactions and latency, while retaining the audit ability and transparency properties/benefits of the model. The proposed framework focuses on optimizing the computational and energy efficiency of the digital AC layer within smart-home energy systems, rather than directly modifying physical energy consumption patterns. This proposed framework attempts to address the performance, scalability, and security shortcomings of existing IoT AC solutions [10].

The contributions of this work are threefold:

• Optimization of a hybrid blockchain architecture decision-making pipeline with integration of off-chain ML implication with on-chain verification.
• Optimization of cost and performance through selective on-chain execution and periodic audit mechanisms.
• Optimization of system efficiency through comprehensive evaluation demonstrating reductions in on-chain transaction volume, latency, and blockchain-related energy consumption with negligible loss in decision accuracy.

This paper is structured into the following: Section 2 carries out a detailed literature review of the related approaches, outlining current methodologies and highlighting the existing limitations thereof. Section 3 elaborates the presented ODABAC-IoT framework, including its architectural elements and design principles. Section 4 shows how the framework can be applied to the example of a smart-home energy-management process. Section 5 describes the experimental results and provides a detailed discussion, including transaction-volume reduction, latency reduction, storage optimization, blockchain-related energy savings, compliance with energy standards, and a general evaluation of the framework performance.

2. Related Work

2.1. Blockchain-Based Access Control in the IoT

The rapid growth of the Internet of Things (IoT) means AC now faces considerable challenges related to device diversity, dynamic network topologies, and the need for more secure and real-time decision making [11]. Traditional AC models such as RBAC and ABAC have made their way into IoT ecosystems. RBAC enforces AC through roles, meaning IP devices are assigned roles, and permissions are based upon these roles [12]. However, ABAC policies are enforced using various attributes, including user, device, and environmental attributes, which allow for a more dynamic approach, and to varying degrees, support finer-grain and context-aware AC decisions [13]. Because it is less prescriptive in such respects, it is seen as a suitable model in a number of IoT applications compared to RBAC [14].

IoT devices are often lightweight and work under stringent constraints in terms of resources and power, which usually lack enough computational or storage capabilities to perform complicated tasks related to AC on their own. As a result of this, conventional AC models and their cryptographic analog called ABE are often built on the use of centralized management systems that allow for the central evaluation of policies, and for the central encryption and decryption of data, as well as allowing for central decision-making about who can access which data [15]. This reliance on and management by a central system creates a number of serious problems including single-point failures and greater exposure to manipulation, and limits the ability to grow in size or scale [16]. Although ABE is able to give assurance to a data owner that only those individuals with credentials that meet or exceed the qualifications specified in the owner’s policy for that data are able to decrypt it, the cost of executing ABE algorithms on an IoT device is extremely high [17]. In addition, although ABE is specifically designed to protect the confidentiality of stored data, it is not designed to provide real-time AC or dynamic service authorizations in the face of changing circumstances [18].

To address these constraints, newer frameworks propose combining lightweight intrusion detection, edge computing, and blockchain to decentralize and optimize AC for real-time, scalable, and secure IoT deployment [19].

Blockchain technology has been seen as a solution to data AC issues in the IoT because of its decentralization, immutability, and consensus mechanisms for verification [20]. In RBAC, blockchain can provide secure storage of roles and permissions in the distributed ledger, while smart contracts manage automated role assignment, verification, and tracking of misbehavior [21]. With ABAC, the inherent intelligence of smart contracts can provide real-time evaluation of policies and matching dynamic sets of attributes, allowing for real-time and adaptive policy enforcement in a dynamic context and permitting differentiated access to public and private data of IoT devices [22]. Dynamic ABAC implementations can also utilize immutable logs of all entries (unique identification) into distributed services controlled by the entity, decentralized attribute control, and dynamic or context-aware attribute verification and updates from whichever trusted or untrusted third parties (cross-organizational) are required or authorized by the entity [23]. These characteristics enable scalable, interoperable, and fully accountable permissions, rights management, and transparent AC in the IoT across once untrusted third parties or across organizations [24].

2.2. Dynamic ABAC Models and Computational Challenges

Blockchain-enabled ABAC has been greatly studied for secure and decentralized policy implementation in IoT systems; however, it has many limitations in practical implementations because of high computational overheads in resource-pairing-constrained environments.

As described by the recent literature, the most significant challenges of blockchain-enabled ABAC models are the costly rate of computation arising from multiple evaluations of attributes [25], the high cost of smart-contract execution within blockchain platforms [26], and consensus mechanisms that contribute to high latency [27]. In the case of ABE (such as bilinear-pairing-based ABE), the rate of computation also imposes heavy processing loads on small and lightweight IoT devices [28]. Additionally, recording all access data in granular, on-chain logs increases ledger size and creates inefficiencies in operational data storage, scaling, and transaction costs [29].

Fine-grained ABAC policies on blockchain yield better decision performance, but they incur high fees and longer response times in public blockchain scenarios [30]. In addition, ref. [31] reckons that ABAC’s cryptographic requirements impose substantial issues in low-power IoT devices and do not yield sufficient and timely AC. To overcome these challenges, there has been a wave of new research into hybrid and off-chain computing architectures, which can reduce on-chain workloads while still being transparent and auditable [32,33]. However, the general research issue is to introduce low-latency, energy-efficient, and scaling of blockchain-based access management systems using ABAC in the IoT setting [34].

2.3. AI Driven Blockchain Optimization

Recent research has looked into the ways in which Artificial Intelligence (AI) can be integrated with a blockchain to improve scalability, security, and operational efficiencies [35]. The authors of [36,37] thoroughly reviewed AI-based blockchain approaches, providing coverage of AI’s usefulness in optimizing consensus mechanisms, identifying vulnerabilities in smart contracts, and enabling privacy-preserving computations. The survey authors reported that ML and DL, AI approaches, were beneficial to improve consensus latency, predict malicious behavior, and facilitate improved contract execution [38]. However, other thematically similar AI-enabled AC mechanisms geared toward IoT (Internet of Things) systems have not been explored in detail, despite researchers mainly focusing on improving only the foundational operational efficiencies of blockchain [39].

Building on these innovations, Anand et al.in [40] proposed an AI and blockchain-based AC model that included biometric authentication, anomaly detection, and contextual analysis to facilitate dynamic management of ABAC policies. In that model, blockchain was utilized to conduct trustworthy, decentralized storage of control policies. Using AI, the model could process user and device behavior to continually update access rules for each user and their associated devices. This yielded an overall enhancement with the ML aspect for the overall identity management in characteristics such as consent, also supporting the development of privacy-preserving federated learning and enhanced security by increased resilience against evolving attacks [41,42]. Similarly, the works of [43] and others demonstrate how AI-based inference methods can reduce oversight over manual policies and speed incident response, adapt AC decisions substantially quicker, more smoothly, and efficiently respond to changing security contexts.

While these advantages exist, substantial computational challenges still exist. The joint load of AI inference and smart-contract execution may be excessive in resource-limited IoT devices and limit the service latency and transaction costs in the case of a public blockchain. The two studies above emphasized that future research should focus on balancing lightweight AI models, off-chain processing, and edge computing based on the security strength and performance efficiency of AI blockchain-enabled IoT AC systems.

2.4. Lightweight Blockchain Frameworks with Off-Chain Intelligence

Off-chain computation has emerged as an effective strategy for addressing the scalability and performance limitations of blockchain-based systems, particularly in latency-sensitive and data-intensive IoT applications. By executing computational tasks outside the blockchain and only committing essential proofs or outcomes on-chain, this approach preserves decentralization and verifiability while significantly reducing storage, transaction costs, and consensus latency [44].

Yang et al. [45] identified off-chain technologies as comprising privacy mechanisms, intelligent networking, edge computing, and transaction scheduling, which extend to adopting advanced AI approaches, such as federated learning and deep reinforcement learning, to optimize routing and resource assignment and to assess trust without adding overhead to the blockchain layer. The AI models can be trained and executed in an off-chain manner, but the correctness, integrity, accountability, and auditability are taken care of on-chain, along with the secure enforcement of policy implications.

In a hierarchy of blockchain presented by [46] for smart cities, the presented system solution consists of the management of resource and location of diverse IoT nodes using both public and private chains, leveraging lightweight cryptographic methods and utilizing ML-based inconsistency detection. The main limitation of the proposed system is the lack of an execution environment for off-chain real-time detection, and it misses the opportunity to better incorporate the descriptive and prescriptive power of AI [47,48].

Similarly, Hakilo Sabit in [49] proposed a smart-home application leveraging off-chain ML inference to only trigger aspects of actions captured on the blockchain in the interest of minimizing the frequency of on-chain transaction processing and thus reducing transaction costs. They also solely considered the actions as events to be automated, refraining from studying the impact on dynamic AC or a more modular and unique AC based on policies. Emerging directions include integrating federated learning with off-chain storage (e.g., IPFS) for privacy-preserving model training in distributed IoT systems [50,51], and reinforcement learning–based routing in Payment Channel Networks, which improves throughput and privacy [52]. In IoT AC, such off-chain intelligence can support real-time anomaly detection and policy evaluation at the edge, with only final authorization results recorded on-chain for immutability and audit.

Despite these benefits, off-chain AI systems still face challenges, such as high computational demands, trust gaps between off-chain and on-chain components, and ensuring transparent, verifiable decision-making. Future research is expected to focus on hybrid designs combining lightweight edge AI, cryptographic proofs of computation, and selective on-chain validation to balance security, scalability, and performance in blockchain-enabled IoT AC. As shown in Table 1, the various AC techniques in IoT systems are summarized, highlighting their key features, limitations, and applications.

Table 1. Summary of access control techniques in IoT studies.

Reference	Study Focus	Access Control Approach	Key Features	Limitations
[12]	RBAC-based secure data processing in IoT	RBAC	Secure and efficient framework for IoT data processing	Limited adaptability for dynamic environments
[14]	Context-aware access via fog computing	Context-aware AC	Fog-enabled dynamic access policy adaptation	Complexity in context integration
[16]	Zero-trust access for 6G IoT environments	Zero trust + blockchain + inner product encryption	Designed for 6G-enabled IoT networks	High computation overhead and encryption complexity
[17]	Healthcare access with ABE	Attribute-Based Encryption (ABE)	Secure-cloud-based system with fine-grained control	Tailored for healthcare, limited generalizability
[18]	Leakage-resilient control for IoT outsourcing	Leakage-resilient AC	Resists data leakage during outsourced storage	Focuses more on leakage than real-time access
[19]	AI-driven adaptive threat detection in IoT	AI-integrated AC	Real-time adaptive security under constraints	Lacks blockchain integration
[20]	Decentralized authentication in IoT access	Hybrid access control with decentralized auth	Emphasizes authentication and layered access	Review-based, lacks implementation insights
[21]	Policy-based control for health data	Policy-based AC with blockchain	Unauthorized access prevention in EHR systems	Application-specific (healthcare), scalability untested
[22]	Boundary-access enforcement in IoT	Fine-grained trusted control	Enhanced boundary control, fine-grained policies	Boundary specific, not generalized
[23]	DID-based identity for IoT devices	Decentralized Identity Management (DID)	Blockchain-based identity for IoT devices	Relies on IOTA, may limit interoperability
[24]	Blockchain-enabled IoT data marketplaces	Use-case-oriented blockchain integration	Market-driven IoT data control	Use-case-centric, lacks generalizable access model
[25]	Scalability in blockchain IoT access	Performance-oriented blockchain access	Analyzes performance in varied IoT settings	Focuses on performance, not access policy design
[26]	Policy-controlled smart contracts in IoT	Policy-based smart contracts	IoT privacy via policy managed smart contracts	Privacy heavy, lacks performance benchmarking
[27]	Smart-city access control using 6G + blockchain	Blockchain IoT in smart cities	6G integration, secure urban IoT	Generalized, not focused on specific control mechanisms
[28]	Ethereum smart contracts for IoT access	Ethereum-based ABAC	RBAC and Ethereum smart contracts’ integration	Requires Ethereum network, high cost
[29]	Hybrid storage in blockchain traceability	On-chain + off-chain access strategy	Enhanced scalability with hybrid storage	Focused on traceability, not full access control
[30]	ABAC for blockchain donation systems	ABAC	Donor centric access transparency	Niche application, limited IoT focus
[31]	Fine-grained control in blockchain IoT	Blockchain-based fine-grained access	Secure storage and access granularity	General IoT focus, lacks trust management
[32]	Distributed access in Industrial IoT	Distributed-blockchain AC	Access for IIoT through blockchain enforcement	Tailored to industrial settings
[33]	Supply-chain access visibility using blockchain	Blockchain-enabled supply-chain control	Track and access visibility	Limited to logistics-based IoT
[35]	Convergence of blockchain IoT AI for access	Converged-access frameworks	Multitech synergy for access and control	Early stage, lacks prototype
[37]	Smart-contract administration in virtual settings	Blockchain-based contract management	Optimized contract handling	Focused more on admin than access policies
[38]	Digital-twin security with IoT blockchain	Blockchain-based digital-twin security	Secure twin representation and monitoring	Conceptual, lacks deployment examples
[39]	Governance framework for blockchain IoT AI	Conceptual governance framework	Access governance across AI, IoT, blockchain	Conceptual, not technical
[40]	Blockchain with TL for secure dissemination	Blockchain-based dissemination control	Transfer learning + blockchain for data spread	Dissemination focused, less on access policy

The evolution of access-control mechanisms in IoT systems has progressed from centralized RBAC models to decentralized ABAC frameworks and more recently, to hybrid blockchain–ML architectures that aim to balance security and efficiency.

Compared to existing hybrid blockchain-based access control frameworks, ODABAC-IoT introduces a more efficient decision-making pipeline by integrating lightweight LightGBM inference with selective on-chain verification. While prior works such as [1,2] focus on fully on-chain or partially optimized blockchain execution, they still incur significant computational overhead due to frequent smart-contract evaluations. In contrast, the proposed framework reduces unnecessary on-chain interactions by filtering high-confidence decisions off-chain, thereby achieving lower latency and energy consumption. Furthermore, unlike conventional approaches, ODABAC-IoT incorporates periodic auditing and trust recalibration mechanisms to maintain security guarantees while improving efficiency. These features collectively position the proposed framework as a scalable and energy-aware alternative to existing state-of-the-art solutions.

3. Methodology

The proposed ODABAC-IoT framework is an optimized hybrid blockchain-enabled AC mechanism for smart-home energy systems. The methodology is built directly on a hybrid blockchain-based dynamic ABAC framework for smart energy environments. It combines Hyperledger Fabric and Hyperledger Besu to achieve decentralized, tamper-proof, and context-sensitive AC while ensuring strong security and operational efficiency and to overcome the computational overhead and scalability challenges arising from the high frequency of on-chain access evaluations. This model also introduces an off-chain Light Gradient-Boosted Machine (LightGBM)-driven pre-evaluation layer. LightGBM is a gradient-boosting decision tree framework specifically optimized for high-speed inference on tabular data, which aligns with the structured and context-rich nature of IoT AC attributes. Its ability to handle categorical, numerical, and temporal features efficiently makes it well suited for processing heterogeneous IoT request data in real time. The methodology focuses on optimizing the computational efficiency, latency, and blockchain-related energy consumption of the digital access control layer, rather than directly modifying physical energy consumption in the smart home. In the proposed framework, high-confidence decisions are executed off-chain using the lightweight LightGBM classifier, while low-confidence requests are enforced for full blockchain-based ABAC implementation. The low latency implication of LightGBM, along with a small memory footprint, makes it a suitable choice for deployment on edge devices and ensures scalability in resource-constrained IoT environments.

Trust is preserved using cryptographic signing, and audit logs ensure integrity and traceability, enabling the system to attain substantial cost and latency reductions without compromising immutability or transparency. Unless otherwise stated, all performance and energy-related results refer to the computational and blockchain infrastructure layer.

The architecture of the proposed ODABAC-IoT framework is shown in Figure 1 and consists of three layers: the IoT Device Layer, the Off-Channel ML Processing Layer, and the On-Channel Blockchain Layer. The first layer comprises smart meters, appliances, and energy management controllers that generate access requests along with contextual attributes. The Off-chain ML Processing Layer, which serves as the second layer, includes LightGBM as a prediction engine, hosted on edge nodes, to enable high-speed evaluation of access requests. Finally, the third on-chain blockchain layer utilizes the Hyperledger Fabric network to host smart contracts for policy enforcement, secure logging, and continuous trust recalibration. The solid line represents a compulsory interaction, whereas the dotted line represents a conditional interaction between the components. The white lines represent the optimization in the framework proposed in [2] study, whereas the black lines represent the adoption of the framework described by Waheed et al. in [2].

Figure 1. ODABAC-IoT hybrid architecture with off-chain ML and on-chain verification.

In the proposed architecture, in keeping with the zero-trust model, there is no trust implicit at any point in the system; every request for access is verified contextually via LightGBM inference and then validated again by blockchain-enabled ABAC policies.

This makes it possible to continuously adjust trust according to user behavior, thus applying the principle of least privilege. The use of off-chain ML improves decision-making speed without compromising on validation, whereas on-chain auditing ensures nothing escapes cryptographic scrutiny. Latency refers to the period of time taken between the creation of an access request and the ultimate decision made to grant permission.

3.1. IoT Device Layer

This includes smart-home devices and energy management components that continuously interact with the Home Energy Management System (HEMS) and external utility services and serve as the data generation and request initiation point inside the ODABAC-IoT framework. To be specific, this layer comprises smart meters for household consumption and tariff status reporting, HVAC systems (air conditioners and water heaters) for controllable load management, renewable energy units (solar inverters), and energy storage systems that manage charging and discharging cycles. Also, EV chargers, demand response controllers, and environmental sensors for monitoring temperature, occupancy, voltage, and frequency. Over time, these devices, generate requests for access like “turn on the EV charger for 2 h,” “switch air conditioner on at 5 p.m.,” etc., so they are categorized into static (device ID, owner ID, manufacturer), dynamic (energy usage, device state, battery SOC, current tariff), and contextual (location, time of request, occupancy, peak/off peak periods) classes.

The AC pipeline’s initial stage is formed by this layer, which guarantees that every single piece of operational and contextual data is collected. This in turn allows for aware and fine-grained context both for LightGBM off-chain inference and ABAC policy execution. The collected attributes are assumed to represent typical smart-home operational conditions and are used as inputs for both off-chain ML inference and on-chain policy evaluation.

3.2. Off-Chain Processing

All access requests are preevaluated off-chain before they experience blockchain processing costs. The off-chain processing pipeline in Figure 2 serves as the first level of intelligence in the ODABAC-IoT architecture, transforming raw IoT attributes into clean, standardized, and contextually enriched feature vectors, and leveraging LightGBM to make fast access predictions with high confidence. It balances efficiency and trust, and the model is trained against audited ABAC decisions, i.e., reducing blockchain execution overheads while still maintaining security and flexibility as indicated by conditional interaction represented by dotted line with in the framework. Thus, it reduces blockchain execution costs and preserves security and adaptability. This tiered architecture ensures on-chain reliable AC outcomes optimizing both system performance and policy robustness in dynamic IoT environments. The concept of an off-chain processing phase assumes that an access request’s attributes and distribution will match standard models that are used in typical smart-home application systems; therefore, obtaining a generalized solution to this problem becomes feasible. The training set includes simulated access requests based on ABAC on a blockchain and IOT access request simulations based on normal and abnormal access patterns.

Figure 2. Computation flow of off-chain processing in ODABAC-IoT framework.

3.2.1. Attribute Acquisition and Preprocessing

Each AC decision in IoT environments can be represented as a collection of attributes from four domains:

• User attributes: identity, role, authentication level, past behavior history.
• Device attributes: type of device (e.g., air conditioner, EV charger), power rating, criticality level.
• Request attributes: action requested (turn on/off, limit usage), requested duration, resource demand.
• Contextual attributes: time of day, tariff period (peak/off-peak), household occupancy, grid load state, renewable availability.

It is assumed that all attributes are time-synchronized at the moment of request generation and that missing values occur randomly rather than systematically. The data from the IoT devices are collected through secure channels and passed to the preprocessing module, as shown in Figure 3. These collected data are first processed for missing values by median imputation to ensure data completeness while maintaining distributional integrity. Next, robust anomaly scoring using the robust z score is applied to identify and mitigate outliers arising from sensor noise or malicious injections. The cleaned data then undergo standardization of numerical attributes, transforming them to zero mean and unit variance for stable learning.

Figure 3. Attribute preprocessing module for IoT access requests.

For energy-related readings, device-aware normalization is employed to scale features relative to each device’s operational range. Discrete variables are handled through categorical encoding, converting symbolic attributes into machine-readable form. Temporal and contextual variables are processed with cyclical encoding, preserving natural periodicity such as daily or weekly cycles. Finally, all transformed features are combined through feature assembly, producing a unified vector ($x_i$) suitable for input to the ML prediction engine. The raw attribute vector for a request at time $t_i$ can be expressed using Equation (1), where $u_i,v_i,r_i,$ and $c_i$ denote user, device, request and contextual attributes respectively.

$$x_i=[u_i,v_i,r_i,c_i]\in {\mathbb{R}}^d$$

(1)

• Missing-Value Masking and Median Imputation 

For each feature j, a binary mask $m_i\in {[0,1]}^d$ indicates whether the value is observed ($m_{ij}=1$) or missing ($m_{ij}=0$). Missing values are replaced using median-based imputation. For each feature i, let $me{d}_j$ be the median computed on the training set as presented in Equation (2).

$${\tilde{x}}_{ij}=m_{i,j}·x_{i,j}+(1-m_{ij})·{med}_j$$

(2)

This assumes that missing values do not carry semantic meaning and can be approximated using median-based imputation without introducing significant bias.

• Robust Anomaly Scoring (Robust z-Score) 

The robust z-score is used to flag anomalous values, where the median $me{d}_j$ provides a robust estimate of central tendency, and the median absolute deviation $MA{D}_j$ captures the spread of each attribute as shown in Equation (3).

$$MA{D}_j=media{n}_k\left(\right|x_{kj}-me{d}_j\left|\right)$$

(3)

The robust z-score ensures that occasional noisy readings (e.g., sudden spikes in smart-meter values or abnormal temperature readings from sensors) do not distort the preprocessing pipeline. This allows the system to reliably detect and handle anomalous attribute values before they are passed to the LightGBM classifier or the blockchain-based ABAC engine, thereby reducing false denials and improving model robustness in dynamic IoT environments. Therefore, the normalized distance of a data point $x_{i,j}$ from the median of that attribute, scaled by the typical spread ($MAD$) is shown in Equation (4). Thus, $r_{ij}$ is basically an anomaly score per attribute per request.

$$a={\displaystyle \frac{{\tilde{x}}_{ij}-me{d}_j}{1.4826·MA{D}_j}}$$

(4)

where

• $x_{ij}$ = value of attribute j for data instance i
• $me{d}_j$ = median of attribute j
• $MA{D}_j$ = median absolute deviation, a robust measure of spread.
• The constant 1.4826 ensures consistency with standard deviation under normal distribution assumptions.

• Standardization of Numerical Attributes 

Numerical attributes excluding power/energy features that will undergo device-aware scaling are standardized to ensure comparability across devices with different measurement scales. Standardization transforms each attribute $x_{ij}$ into $z_{i,j}$ as shown in Equation (5)

$$z_{i,j}={\displaystyle \frac{x_{i,j}·{\mu }_j}{{\sigma }_j}}$$

(5)

where ${\mu }_j$ and ${\sigma }_j$ denote the mean and standard deviation of the attribute. This yields zero mean, unit variance features so attributes with larger raw ranges (e.g., latency vs. temperature) do not dominate the model.

• Device-Aware Normalization for Power/Energy Features 

For power and energy consumption, device-aware normalization is applied. Each device’s readings are scaled relative to its own operating range or rated capacity, so that both low-power devices (e.g., bulbs) and high-power devices (e.g., EV chargers) contribute comparably to the classifier. For instance, the min and max consumption of device d is known then the normalized power/energy value of feature j for request i from device d can be expressed as shown in Equation (6).

$$p_{i,j}^{\left(d\right)}={\displaystyle \frac{x_{ij}-mi{n}_d}{ma{x}_d-mi{n}_d}}$$

(6)

Similarly, if the rated capacity of device d is known, then normalized power/energy value of feature j for request i from device d can be expressed as shown in Equation (7).

$$p_{i,j}^{\left(d\right)}={\displaystyle \frac{x_{ij}}{rated·d_d}}$$

(7)

This assumes that device operational ranges and rated capacities are known and remain stable over time.

• Categorical Encoding 

Categorical attributes are transformed via one-hot encoding. Formally, if feature j takes value $x_{ij}=k_k$ (the $K^{th}$ category), the encoding function maps it to the one-hot vector as shown in Equation (8)

$${\varphi }_j\left(x_{ij}\right)={\mathbf{e}}_k,x_{ij}={\kappa }_k.$$

(8)

where $e_k$ is a K-dimensional unit vector with 1 at the $k^{th}$ position and 0 elsewhere.

• Cyclical Encoding for Temporal/Contextual Variables 

Temporal/contextual variables such as time of day and day of week are encoded as cyclical features as expressed in Equation (9)

$$t_i^{sin}=sin\left({\displaystyle \frac{2\pi ·h_i}{24}}\right),t_i^{cos}=cos\left({\displaystyle \frac{2\pi ·h_i}{24}}\right).$$

(9)

where $t_i$ indicates time of day or day of week.

This unified feature representation ensures that heterogeneous IoT attributes are transformed into a consistent numerical space suitable for ML inference.

• Feature Assembly 

The complete preprocessing pipeline yields a model-ready feature vector as represented in Equation (10)

$${\varphi }_i=\left[{\mathbf{z}}_i\parallel {\mathbf{p}}_i^{\left(d\right)}\parallel {\mathbf{o}}_i\parallel {\mathbf{t}}_i\parallel {\mathbf{a}}_i\right]\in {\mathbb{R}}^{d^{\prime }}.$$

(10)

where

• $Z_i$ is a standardized numeric;
• $p_i^{\left(d\right)}$ is the device-aware power/energy;
• $o_i$ represents the one-hot encoding;
• $t_i$ is the cyclical time/context;
• $a_i$ are anomaly flags.

This formalized preprocessing ensures that attributes collected from IoT devices are clean, normalized, and contextually enriched before being passed to the off-chain inference engine and ABAC policy evaluator.

3.2.2. Machine Learning Prediction Engine

The ML Prediction Engine is an off-chain module responsible for making fast and reliable AC predictions. Algorithm 1 and Figure 4 illustrates the off-chain ML Prediction Engine workflow within the ODABAC-IoT framework with conditional interaction in the form of dotted line, feature importance and explainable AI. Attribute data from IoT devices, contextual features, and trust recalibration history are preprocessed into feature vectors ${\varphi }_i$. These vectors are passed to the LightGBM model, which iteratively combines shallow decision trees to produce a predicted access decision with calibrated confidence $p_i\in [0,1]$ as shown in Equation (11).

$$y_i\in \{\mathrm{Allow},\mathrm{Deny}\}$$

(11)

Figure 4. Machine learning prediction engine pipeline in ODABAC-IoT.

The prediction model is implemented using Gradient-Boosted Decision Trees (GBDTs), an ensemble learning approach that builds a strong classifier by combining the outputs of many weak learners, typically shallow decision trees. Unlike a single decision tree, which often suffers from overfitting or limited generalization, GBDTs improve performance by training trees sequentially, where each new tree is optimized to correct the residual errors of the previous ensemble. The training dataset was extracted from CouchDB off-chain storage, which contains historical attribute decision pairs along with trust recalibration history. This ensured that the model was trained on realistic access patterns and could generalize well to future requests. Formally, let the cleaned training dataset be as shown in Equation (12):

$$\mathcal{D}={\left\{({\varphi }_i,y_i)\right\}}_{i=1}^N$$

(12)

where ${\varphi }_i$ are the feature vector and $y_i\in [0,1]$ are the binary labels.

The off-chain database (CouchDB) that provides the training dataset for the LightGBM model was based on historical access-control logs, containing attribute–decision pairs produced as a result of previous ABAC checks. To preserve privacy, user identifications were not utilized in any way; only anonymous attributes were considered as contextual and behavioral features. Additionally, using off-chain technology for training purposes helped protect personal information by keeping the raw sensitive data away from the blockchain.

An 80:20 split was used to create both an 80% (training subset) and a 20% (validation subset) subset of the total dataset in order to allow for an assessment of the generalizability of the final classification performance. The model built using LightGBM on the training subset and its performance were assessed using a validation (testing) subset. The classification performance of each method was evaluated using standard classification metrics of accuracy, precision, recall, and F1-score across each model and subset, and the models’ robustness (i.e., their ability to prevent overfitting) were further evaluated through the use of k-fold cross-validation (where k = 5) to test the model with 5 different (random) partitions of the data.

The model aims to minimize a differentiable loss function. The classifier is trained by minimizing a loss function as shown in Equation (13), where y denotes the ground-truth access decision obtained from blockchain ABAC enforcement, $\varphi$ represents the preprocessed attribute vector, and $f\left(\varphi \right)$ is the predicted decision score from the LightGBM model.

$$L(y,f(\varphi \left)\right)$$

(13)

The LightGBM training process begins with an initial constant prediction equal to the log odds of the positive class, i.e., the ratio of Allow vs. Deny outcomes in the blockchain-verified dataset as shown in Equation (14), where p is the proportion of “Allow” decisions in the training data.

$$F_0=log\left({\displaystyle \frac{p}{1p}}\right),$$

(14)

Training proceeds iteratively, where in each round residuals are computed as the difference between ground-truth blockchain decisions and the model’s predictions. For instance, at each round m it measures the difference between the blockchain’s decision $u_i$ and the model’s current prediction $f_{m1}\left({\varphi }_i\right)$ as presented in Equation (15)

$$r_{im}=u_i{f}_{m1}\left({\varphi }_i\right)$$

(15)

A shallow regression tree is trained on the pairs $({\varphi }_i,r_{im})$ to predict these residuals. This tree learns where the current model is making errors. The outputs of the new tree $h_m\left(\varphi \right)$ are added to the model, scaled by a learning rate $\eta$ as shown in Equation (16). This ensures gradual corrections and prevents overfitting.

$$f_m\left(\varphi \right)=f_{m1}\left(\varphi \right)+\eta ·h_m\left(\varphi \right)$$

(16)

After M boosting rounds, the final LightGBM model is expressed in Equation (17)

$$f_M\left(\varphi \right)=F_0+{\displaystyle \sum _{m=1}^M}\eta ·h_m\left(\varphi \right)$$

(17)

where $f_M\left(\varphi \right)$ outputs a logit score. A sigmoid transformation converts it into the probability of an Allow decision as represented in Equation (18)

$$P(\mathrm{Allow}\mid \varphi )=\sigma \left(f_M\left(\varphi \right)\right)={\displaystyle \frac{1}{1+e^{f_M\left(\varphi \right)}}}$$

(18)

The predicted probabilities are assumed to be well-calibrated outputs of the LightGBM model; however, no explicit calibration method is applied, which may introduce uncertainty in confidence estimation.

If the confidence score exceeds a predefined threshold $\tau$, the decision is directly accepted and logged on-chain to minimize energy consumption. Otherwise, low-confidence cases are deferred to a full on-chain ABAC evaluation for stricter verification as shown in Equation (19).

$$y_i=\left\{\begin{array}{cc}\mathrm{Allow},\hfill & \mathrm{if}{p}_i\ge \tau ,\hfill \\ \mathrm{Deny},\hfill & \mathrm{if}{p}_i<\tau .\hfill \end{array}\right.$$

(19)

The confidence threshold $\tau$ is analytically set (e.g., $\tau$ = 0.9) and controls the trade-off between off-chain efficiency and on-chain security verification.

Algorithm 1 Training and inference of ODABAC-IoT classifier

Input:  • Training dataset $\mathcal{D}={\left\{({\varphi }_i,u_i)\right\}}_{i=1}^N$, where ${\varphi }_i$ are preprocessed attribute vectors and $u_i$ are blockchain ABAC labels;  • Learning rate $\eta$; number of boosting rounds M. Output:  • Trained LightGBM classifier $f_M\left(\varphi \right)$. Training Phase   1: Initialization: Compute initial model score (logit baseline): $$F_0=log\left({\displaystyle \frac{p}{1p}}\right),p={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}{u}_i$$   Set $f_0\left(\varphi \right)=F_0$.   2: Boosting Rounds (for $m=1$ to M):  (a) Pseudo residuals for each sample: $$r_{im}=u_i\sigma \left(f_{m1}\left({\varphi }_i\right)\right)$$  (b) Fit a regression tree $h_m\left(\varphi \right)$ to map ${\varphi }_i\mapsto r_{im}$.  (c) Update the model: $$f_m\left(\varphi \right)=f_{m1}\left(\varphi \right)+\eta ·h_m\left(\varphi \right)$$   3: Return final model: $$f_M\left(\varphi \right)=F_0+{\displaystyle \sum _{m=1}^M}\eta ·h_m\left(\varphi \right)$$ Inference Phase (Access Request Evaluation)   1: For an incoming IoT request with raw attributes $\mathbf{z}$, preprocess: $$\varphi =\Phi \left(\mathbf{z}\right)$$   2: Compute logit score: $$\widehat{y}=f_M\left(\varphi \right)$$   3: Convert to probability: $$P(\mathrm{Allow}\mid \varphi )=\sigma \left(\widehat{y}\right)={\displaystyle \frac{1}{1+e^{\widehat{y}}}}$$   4: Apply confidence threshold $\tau$:  If $P\ge \tau$: decision = Allow, cryptographically signed, logged on-chain.  If $P<\tau$: escalate to full blockchain ABAC evaluation.

3.2.3. Cryptographic Result Signing

Adversarial attack resilience is a key element in the design of the suggested architecture. Being based on off-chain contextual information, the LightGBM-based ML algorithm can suffer from adversarial attacks, since the context itself might be manipulated by malicious actors. ODABAC-IoT addresses these challenges using multiple protective measures. First, all ML results with a high degree of confidence are signed cryptographically and checked via on-chain validation to make sure that no altered predictions could pass unnoticed. Second, any predictions with a low-confidence level are automatically forwarded for full-scale ABAC on-chain processing. Finally, on-chain model retraining on regular basis would allow spotting adversarial patterns. The combination of these techniques increases the resistance of the proposed architecture to adversarial attacks.

FFDI (false-data injection) attacks are a possible risk in which bad people can affect how ML is able to infer results by inserting their own data into the input attributes and then using these new “faked” attributes to change how ML infers results based on those altered attribute values. The proposed architecture provides multiple security measures to mitigate FDI attacks through each layer of the architecture. For example, there are several robust preprocessing methods, such as anomaly detection (for example, using the robust z-score mechanism), to identify abnormal or invalid values in the input attributes prior to performing inference. In addition, all low-confidence or suspicious predictions are redirected automatically to a complete on-chain ABAC evaluation to ensure that bad data do not get past the enforced policies. Periodic auditing and trust recalibration further enhance the system’s ability to detect and respond to inconsistencies caused by malicious data injection.

To preserve integrity and authenticity, every high-confidence prediction generated by the off-chain ML Prediction Engine is digitally signed before being forwarded on-chain as illustrated in Figure 5. It produces a decision tuple as shown in Equation (20)

$$m_i=({\widehat{y}}_i,p_i,t_i)$$

(20)

where $y^i$ is the predicted decision, $p_i$ is the confidence score, and $t_i$ is the timestamp. The ML node uses its private key $s{k}_{ML}$ to generate a digital signature as shown in Equation (21)

$${\sigma }_i={Sign}_{s{k}_{\mathrm{ML}}}\left(H\left(m_i\right)\right)$$

(21)

where $H(·)$ is a cryptographic hash function, and ${\sigma }_i$ is the digital signature bound to the result tuple. On-chain, the blockchain nodes verify the signature using the ML node’s public key $p{k}_{M}L$ as shown in Equation (22)

$${Verify}_{p{k}_{\mathrm{ML}}}\left(H\left(m_i\right),{\sigma }_i\right)\stackrel{?}{=}\mathrm{True}$$

(22)

Figure 5. Cryptographic result signing in ODABAC-IoT framework.

If verification succeeds, the decision is accepted and logged without re-executing the full smart contract. If the validation is not successful, the decision is rejected and upgraded to an on-chain ABAC assessment. Such a handoff of data ensures that adversaries are unable to spoof ML predictions or tamper with them; hence, meritorious trust in off-chain inference outcomes is established.

3.2.4. Periodic Model Verification and Retraining

To avoid concept drift and guarantee long-term dependability, the system incorporates periodic model verification and retraining mechanisms. A small fraction $\alpha \%$ of high-confidence decisions are arbitrarily selected and checked on-chain by re-executing the full ABAC policy evaluation as shown in Equation (23)

$$\mathit{AuditSet}=\{m_i\mid Random\left(i\right)<\alpha \}$$

(23)

This ensures that even predictions accepted off-chain are occasionally double-checked for correctness. If the ML prediction outcome $y^i$ do not match the ABAC ground-truth decision $y_i^{\mathrm{ABAC}}$, the inconsistency is logged as shown in Equation (24)

$${\Delta }_i=⊮\left({\widehat{y}}_i\ne y_i^{\mathrm{ABAC}}\right)$$

(24)

where

• ${\Delta }_i=1$: misclassification detected.
• ${\Delta }_i=0$: prediction validated.

If the inconsistency exceeds a threshold $\beta$, the ML model is flagged for retraining. Equation (25) is used to check the inconsistency range.

$${\displaystyle \frac{{\sum }_i{\Delta }_i}{\left|\mathit{AuditSet}\right|}}\ge \beta$$

(25)

This ensures adaptation to evolving user/device behaviors and changing grid conditions. The ML model is retrained using both historical CouchDB records and newly audited ABAC data.

Figure 6 shows the process where a fraction of off-chain decisions is recomputed (shown using dotted line) using the ABAC engine. Inconsistency discovery guarantees mismatches are logged, while exceptionally, the inconsistency threshold triggers retraining. The updated dataset is then used to redeploy the ML model.

Figure 6. On-chain auditing and model retraining workflow.

3.3. On-Chain Processing

In [2] the on-chain processing was distributed across Hyperledger Fabric and Hyperledger Besu. It utilized four contracts on fabric for user (UAC), device (DAC), resource (RAC) and certificate management contracts (CMC) which were responsible for maintaining attribute registries and cryptographic trust, whereas Besu maintained access policy (APC) and access decision (ADC) contracts. This design ensured immutability, auditability, and zero-trust enforcement, but the continuous on-chain assessment of attributes for every request gave rise to computational overhead and scalability challenges. Before contributing to the framework, a blockchain-based registration process is necessary for every type of entity, as shown in Figure 7 and Figure 8. For instance, devices such as smart meters, HVAC systems, etc., are onboarded through the DAC. Each device is bound to a certificate issued by the CMC, guaranteeing authenticity. Likewise, users are registered through the UAC and validated by CMC-issued certificates. Together, these registries guarantee that only authenticated users and certified devices can issue access requests, while failed authorization requires repeating the process.

Figure 7. Device registration via the DAC with certificate validation through the CMC.

Figure 8. User registration via the UAC with certificate validation through the CMC.

As illustrated in Figure 9, the RAC complements the UAC and DAC by maintaining dynamic, resource-specific attributes such as tariff schedules, demand response signals, and grid thresholds. These three attribute stores collectively serve as the Policy Information Point (PIP). Policies themselves are authored in the APC and deployed on Hyperledger Besu, where they define contextual rules such as time-of-day restrictions, energy-trading limits, or device-specific authorizations.

Figure 9. Attribute store schematic (PIP on Fabric).

In ODABAC-IoT, the architecture preserves this contract structure but optimizes it by introducing a LightGBM-assisted off-chain inference stage. The ADC is the primary point of modification, extended with two distinct entry paths:

• submitPrediction() which accepts high-confidence LightGBM predictions signed by the off-chain inference node and verifies their cryptographic integrity before committing a minimal decision record on-chain.
• fullEvaluateRequest() which executes the complete ABAC workflow across the UAC, RAC, DAC, and APC for low-confidence or anomalous requests.

Figure 10 shows the hybrid blockchain framework integration for on-chain processing. This double pathway lessens redundant on-chain assessments while guaranteeing that ambiguous access still experiences full blockchain endorsement.

Figure 10. On-chain processing in the proposed ODABAC-IoT framework.

The selective on-chain verification mechanism in ODABAC-IoT operates as a confidence-driven event-triggered process. Specifically, access requests are only escalated to the blockchain when the prediction confidence falls below a predefined threshold or when periodic auditing conditions are met. This behavior is conceptually similar to event-triggered control mechanisms, where system updates are executed only when certain conditions are violated. By avoiding continuous on-chain evaluation, the framework reduces communication and computational overhead while maintaining security through conditional verification.

The two new entry points added to the smart contract distinguishing between high-confidence and low-confidence requests are:

• submitPrediction()

• Accepts a decision tuple $mi=(y^i,p_i,t_i,{\sigma }_i)$ from the ML engine.
• Verifies the cryptographic signature ${\sigma }_i$ using the ML node’s public key.
• Validates confidence metadata $(p_i\ge \tau )$.
• Logs the result to the ledger without executing the full ABAC policy.

Formally:

$$\mathrm{if}{Verify}_{p{k}_{\mathrm{ML}}}\left(H\left(m_i\right),{\sigma }_i\right)=\mathrm{True}\mathrm{and}{p}_i\ge \tau \Rightarrow Ledger.Log\left(H\left(m_i\right)\right)$$

• fullEvaluateRequest()

• Invokes the traditional ABAC evaluation engine.
• Used for:

  (a)

  Low-confidence predictions $(p_i<\tau )$;

  (b)

  Randomly sampled audit requests.

This guarantees that the blockchain continuously has a dependable contingency to have firm on-chain policy checks.

To reduce the quantity of data on the blockchain ledger, the RAC and ADC were also streamlined to store records of decision outcome, cryptographic hashes, and minimal contextual metadata:

• Decision hash $H\left(m_i\right)$ instead of the full feature vector.
• Minimal attribute metadata (e.g., device ID, request type).

Formally:

$$\mathit{LedgerEntry}=\left(H\left(m_i\right),\mathrm{DeviceID},\mathrm{Action},\mathrm{Timestamp}\right)$$

This improves the query efficiency while maintaining immutability and transparency with a minimized ledger.

Lastly, the trust recalibration mechanism was optimized within the ADC and CMC. Any off-chain prediction deviating from the verified outcomes of ABAC triggers modification to the device’s or inference node’s trust score, guaranteeing continuous zero-trust arrangement. Whenever the off-chain prediction $y^i$ conflicts with ABAC decision $y_i^{\mathrm{ABAC}}$, the trust score is updated:

$${\mathit{Trust}}_{\mathrm{new}}={\mathit{Trust}}_{\mathrm{old}}\delta ·{\Delta }_i$$

where ${\Delta }_i=1$ if a discrepancy is detected, and $\delta$ is the penalty factor.

This guarantees that ML-based optimizations do not weaken security guarantees but are instead incorporated into the dynamic trust cycle.

The on-chain processing layer as shown in Figure 11 complements the off-chain prediction engine by ensuring verifiability, immutability, and trust. Through selective logging, cryptographic validation, and trust score updates, it provides a secure fallback that balances efficiency with accountability. This hybrid design not only reduces blockchain computation costs but also strengthens resilience, making the ODABAC-IoT framework scalable, auditable, and adaptable in dynamic IoT environments.

Figure 11. On-chain processing layer of ODABAC-IoT framework.

Scalability of the proposed ODABAC-IoT framework is achieved through its hybrid architecture, which minimizes reliance on computationally expensive on-chain operations. As the number of IoT devices and access requests increases, the majority of high-confidence decisions are processed off-chain using the LightGBM inference engine, thereby preventing congestion in the blockchain layer. Only a subset of uncertain or anomalous requests are escalated to on-chain evaluation, ensuring that blockchain workload grows sub-linearly with system scale. Furthermore, the use of distributed edge nodes for off-chain processing enables parallel evaluation of access requests, improving throughput in large-scale deployments such as smart communities or grid-level systems.

The proposed ODABAC-IoT framework is designed to align with key regulatory requirements related to data governance. Blockchain-based logging ensures immutable and auditable records of all access decisions, supporting transparency and accountability. Data retention is handled through selective on-chain storage, where only essential metadata and cryptographic hashes are recorded, minimizing exposure of sensitive information. User consent and privacy are preserved by restricting access to contextual attributes and enforcing policy-based authorization through ABAC rules. Furthermore, the use of off-chain processing reduces the quantity of personal or sensitive data stored on-chain, which is beneficial for compliance with modern data protection principles. The hybrid on-chain enforcement process for handling high-confidence and low-confidence access requests is formally described in Algorithm 2.

Algorithm 2 Smart-contract logic for hybrid ABAC enforcement

Input:  • Decision tuple from ML engine: $$m_i=⟨{\widehat{y}}_i,p_i,t_i,{\sigma }_i⟩$$   where ${\widehat{y}}_i$ = ML decision, $p_i$ = confidence, $t_i$ = timestamp, ${\sigma }_i$ = signature.  • Confidence threshold $\tau$.  • Audit rate $\alpha \in [0,1]$.  • ABAC policy engine (on-chain). Output:  • Final access decision logged on the blockchain ledger. Procedure   1. Function  submitPrediction($m_i$) 1.1. Verify ${\sigma }_i$ using ML node’s public key. 1.2. If signature invalid ⇒ reject request. 1.3. If $p_i\ge \tau$: 1.3.a. Append $H\left(m_i\right)$ to ledger. 1.3.b. Return decision $={\widehat{y}}_i$. 1.4. Else: Call fullEvaluateRequest(${\varphi }_i$).   2. Function  fullEvaluateRequest(${\varphi }_i$) 2.1. Execute ABAC policy engine on attribute vector ${\varphi }_i$. 2.2. Obtain ground truth decision $u_i$. 2.3. Log $(u_i,{\varphi }_i,t_i)$ to the ledger. 2.4. If $u_i\ne {\widehat{y}}_i$: 2.4.a. Trigger trust recalibration event. 2.4.b. Mark $({\varphi }_i,u_i)$ for retraining dataset. 2.5. Return decision $=u_i$.   3. Audit Sampling 3.1. For each high confidence request ($p_i\ge \tau$): 3.1.a. Draw $q\sim U(0,1)$. 3.1.b. If $q<\alpha$, override and call fullEvaluateRequest(${\varphi }_i$) (audit).

4. Scenario: Smart-Home Energy Access Request

To demonstrate the functioning of the proposed framework, consider a scenario in which many devices, such as a smart meter, HVAC system, solar inverter, and battery, communicate with the HEMS and other utility networks. The devices often make requests for actions such as fetching information on usage, load control, and energy trading.

In [2] devices were placed into three categories of High Security (smart grid controller), Moderate Security (thermostat), and Low Security (light bulb); these were all identified as an equivalent level of security. ODABAC-IoT extends this classification to realistic smart-home energy devices, as summarized in Table 2. These devices are associated with AC attributes, enriched with temporal and contextual features assembled off-chain for ML processing, and assigned a criticality level consistent with zero-trust enforcement.

Table 2. IoT device attributes and contextual features in ODABAC-IoT scenario.

Device	Primary Operations	Access Control Attributes [2]	Temporal/Contextual Variables (ODABAC-IoT)	Device Criticality (Security Class)	Measuring Unit/Normalization
Smart Meter	Report consumption data; request billing info	Device ID, User ID, Role, Location, Certificate validity	Time of request, reporting interval, tariff period (peak/off peak)	High Security—mandatory for billing and grid balancing	Energy (kWh), normalized by daily average load
HVAC System	Adjust temperature; demand scheduling	Device ID, User role, Authorized function (cooling/heating)	Time of day, indoor temperature, occupancy status, external weather	Moderate Security—comfort-oriented, not grid-critical	Power (kW), normalized by rated capacity
Solar Inverter	Inject PV power; request synchronization	Device ID, Location, Policy ID, Certificate validation	Solar irradiance, time of day, seasonal variation, grid demand	High Security—impacts grid injection stability	Power (kW), normalized by installed PV capacity
Energy Storage Unit	Charge/discharge scheduling; backup provisioning	Device ID, State of Charge (SoC), Resource policy	Time of request, SoC threshold, demand response signal, grid status	Critical/High Security—reliability and grid balancing	Energy (kWh), normalized by maximum capacity
HEMS Controller	Orchestrates device actions; interacts with utility	Controller ID, User role, Policy ID, Certificate status	Energy price signals, demand response events, household load forecast	Very High Security—central trust anchor	Aggregated load (kWh), normalized vs. baseline household demand

The experiments were conducted on an Intel Core i7 workstation with 16 GB RAM and 256 GB SSD running Ubuntu 22.04 LTS (Dell Inc., Round Rock, TX, USA).

Upon creation of a new request (such as a smart meter sending data on usage), the IoT Device Layer gathers context-based attributes, including attributes related to device identification, location, timing of request, usage pattern, and user preference. The feature vector created from these attributes undergoes processing in the Off-chain ML Processing Layer using the LightGBM classifier, which generates a probability for that request being aligned with acceptable behavior.

• High-Confidence Case: If the probability surpasses a predefined threshold (e.g., ≥95%), the decision is cryptographically signed and submitted to the ADC through the submitPrediction() function. The ADC confirms the signature, records the decision hash, and grants access without invoking full on-chain evaluation, as shown in Figure 12.
• Low-Confidence Case: If the confidence score is below the threshold, or if anomalies are noticed, the request is diverted to the fullEvaluateRequest() function. A complete ABAC process runs on-chain via the UAC, DAC, RAC, and APC, ensuring rigorous verification and preserving zero trust enforcement, as shown in Figure 13.

Figure 12. High-confidence fast path.

Figure 13. Low-confidence ABAC path.

Example: A smart meter performing a standard request at its regular reporting interval is quickly confirmed through off-chain LightGBM inference with negligible blockchain costs. On the contrary, if the same smart meter tries to access the system at an odd hour or reports strange consumption, the low-confidence classification sets off complete on-chain ABAC validation.

Workflow Summary

• Request Generation:
  IoT device sends an access request with contextual attributes.
• Off-Chain Preprocessing:
  Attributes are normalized, validated, and passed to the ML prediction engine.
• Prediction and Thresholding:
  • High confidence → submitPrediction() on-chain.
  • Low confidence → fullEvaluateRequest() on-chain.
• On-chain Enforcement:
  Blockchain either logs the prediction result (high confidence) or executes the full ABAC evaluation (low confidence).
• Periodic Verification:
  Random samples of high-confidence cases are verified on-chain to ensure ML model reliability.
• Retraining: ML model retrains periodically with updated labeled data from blockchain verified requests.

5. Results and Discussion

5.1. Experimental Setup

The implementation and evaluation of the proposed ODABAC-IoT framework were simulated and evaluated on a Ubuntu 22.04 LTS operating system with 16 GB of RAM, an Intel Core i7 processor, and 256 GB of SSD storage, ensuring efficient execution and scalability.

The dataset used in this study was generated based on simulated IoT access scenarios and augmented using realistic attribute distributions derived from typical smart-home environments.

The hybrid blockchain infrastructure was emulated on a private network with the help of Hyperledger Fabric (v2.5) to manage the registries of users, devices, and resources, and Hyperledger Besu (v23.4.1) to enforce access control rules and run smart contracts. The testbed for smart-home energy management comprised a typical collection of IoT devices like smart meters, HVAC controllers, solar inverters, and energy storage units generating synthetic access requests under dynamically varied contextual conditions (e.g., peak/off peak hours, occupancy status, renewable energy availability).

In order to facilitate predictive processing off-chain, the ML inference engine based on LightGBM was developed in Python (v3.10) and utilized Docker (v20.10) for deployment on edge nodes within the simulated environment. The engine was linked with Apache CouchDB (v3.2) for keeping historical requests and managing training datasets generated through simulation. This setup offered a realistic environment for testing system latency, transaction volume, energy consumption, and storage overhead. A detailed description can be found in Table 3, which includes the hardware specifications, software tools, and IoT device testbeds that are necessary for assessing the performance and scalability of the proposed system.

Table 3. Components description.

Component	Description & Purpose
Ubuntu 22.04 LTS + Hardware Specs	Provides stable computing environment; sufficient memory/processing capacity ensures realistic performance metrics.
Hyperledger Fabric	Manages dynamic attribute storage and updates, critical for context-aware ABAC policy enforcement.
Hyperledger Besu	Hosts smart contracts and enforces ABAC logic; supports private chain execution contexts for smart homes.
IoT Device Testbed	Simulates real-world energy IoT devices; generates diverse contextual access requests covering energy-relevant scenarios.
Python + LightGBM (Docker)	Mimics edge-level ML deployment; containerization highlights system deployability and reproducibility.
CouchDB Storage	Enables offline training data retention and history logging, essential for ML model performance and auditability.

5.2. Transaction Volume Reduction

One of the main aims of the ODABAC-IoT framework is to cut down the transactions run on the blockchain to a minimum, thus lessening the computational overhead, storage growth, and the energy costs linked with them. In the typical on-chain ABAC system, the full policy evaluation via smart contracts is mandatory for every access request, thereby leading to one transaction per request. Thus, for 10,000 requests that were simulated, the on-chain system marked almost 10,000 transactions, which mirrors the linear growth problem that has been a part of the traditional blockchain-based ABAC models. In contrast, the former suggested hybrid blockchain framework [2] gave rise to partial optimizations by distinguishing between static and dynamic attributes thus limiting the total transactions to nearly 7000, a 30% reduction. However, this degree of optimization turns out to be inadequate in the long run when the numbers of IoT devices and requests for access keep growing. By contrast, ODABAC-IoT introduces an off-chain LightGBM pre-evaluation layer that filters out high-confidence decisions, submitting only essential verification records to the blockchain. Table 4 summarizes the transaction volume across different request loads for the baseline ABAC model, hybrid Fabric–Besu model, and the proposed ODABAC-IoT framework. As a result, for the same 10,000 requests, the number of on-chain transactions was reduced to nearly 3500, yielding a 65% reduction compared to on-chain ABAC and 50% compared to hybrid blockchain approaches. This significant reduction, as shown in Figure 14, demonstrates the effectiveness of integrating lightweight ML inference in alleviating the transaction burden on the blockchain, directly contributing to enhanced scalability, reduced ledger growth, and improved responsiveness in smart HEMSs.

Table 4. Transactions across request loads for baseline ABAC [1], hybrid Fabric–Besu [2] and ODABAC-IoT (Proposed).

Number of Requests	Baseline ABAC [1]	Hybrid Fabric Besu [2]	ODABAC-IoT (Proposed)
100	105	95	70
500	540	460	280
1000	1120	920	580
5000	5600	4550	2500

Figure 14. Transaction volume reduction across baseline ABAC ([1]), hybrid Fabric–Besu ([2]), and ODABAC-IoT.

The baseline ABAC model shows near linear growth as every request triggers full on-chain evaluation. The hybrid Fabric–Besu model reduces transactions moderately by distributing processing across chains. The proposed ODABAC-IoT achieves the most significant reduction by resolving high-confidence requests off-chain, cutting transaction volume by over 50% under high request loads.

5.3. Latency Improvement

In IoT-based energy management systems, latency is essential to performance; access requests must typically be verified almost instantly in order to facilitate dynamic operations, such as demand response (load shifting), renewable energy scheduling, etc. The baseline on-chain ABAC system takes each request and performs a full policy evaluation across all smart contracts plus consensus validation, which results in an average decision latency of approximately 245 milliseconds per request. Because of this relatively high latency, decision latency is a critical issue in scenarios requiring a timely response, such as turning on a storage unit in response to fluctuations in grid frequency or controlling HVAC loads based upon real-time tariff changes.

The previously proposed hybrid blockchain framework in [2] helped to alleviate this burden to a certain extent by optimizing attribute management. This resulted in a reduction in average latency to 165 ms per request, which translates to a 32.6% improvement over the pure on-chain model. However, the responsiveness was still not sufficient for latency-constrained smart-grid applications. The proposed ODABAC-IoT framework improves responsiveness significantly, as depicted in Figure 15. This is because high-confidence access requests are offloaded to the off-chain LightGBM inference engine.

Figure 15. Latency reduction across baseline ABAC ([1]), hybrid Fabric–Besu ([2]), and ODABAC-IoT.

This selective approach reduced average latency to 88 ms per request, achieving a 64.1% reduction compared to the baseline on-chain ABAC and a 46.7% improvement over the earlier hybrid framework. The results highlight the importance of integrating lightweight off-chain ML processing, which enables ODABAC-IoT to meet the stringent real-time requirements of smart energy systems while maintaining zero-trust security guarantees. Table 5 shows the latency reduction and comparison across the baseline ABAC model, hybrid Fabric–Besu model, and the proposed ODABAC-IoT framework under varying request loads.

Table 5. Average latency per request and percentage reduction relative to baseline ABAC.

Method	Latency (ms/request)	Reduction vs. Baseline
Hassan 2023 [1]	245	N/A
Waheed 2025 [2]	165	32.6%
ODABAC-IoT (Proposed)	88	64.1%

The average latency values represent overall system performance under comparable experimental conditions and are used to summarize the latency improvements across different frameworks.

Figure 16 describes latency improvement with rising request loads for baseline ABAC, hybrid Fabric–Besu, and ODABAC-IoT. In the baseline system, there is a sharp increase in latency with each rising request, since each request is subjected to full on-chain evaluation. In the hybrid system, the rate of increase in latency is reduced with the help of distributed processing. In ODABAC-IoT, the maximum improvement in latency is achieved with the help of off-chain filtering of high-confidence requests, with an improvement of over 70% in latency with rising request levels. Table 6 describes the values of latency for the baseline ABAC, hybrid Fabric–Besu, and ODABAC-IoT systems with varying levels of requests.

Figure 16. Latency variation with increasing request loads for Baseline ABAC ([1]), Hybrid Fabric–Besu ([2]), and ODABAC-IoT.

Table 6. Latency across baseline ABAC ([1]), hybrid Fabric–Besu ([2]), and ODABAC-IoT.

Number of Requests	Baseline ABAC [1] (ms)	Hybrid Fabric-Besu [2] (ms)	ODABAC-IoT (Proposed) (ms)
100	220	280	95
500	780	600	280
1000	1450	1100	520
5000	7200	5000	1900

Latency values represent the average time required to process access requests under identical workload conditions, measured as the time elapsed between request generation and final authorization decision.

5.4. Energy-Efficiency Outcomes

The design of ODABAC-IoT is motivated not just by the desire to improve computational efficiency but also by the need for energy sustainability; both of these are of utmost importance when deploying technologies in smart homes and smart grids. One of the main drawbacks of implementing blockchain-based systems as AC mechanisms is the additional computational and storage overhead they create for all of the nodes that must continue to provide maintenance to the network, resulting in additional energy consumption. Following the methodology outlined by Waheed et al. [2], the average computational energy cost of a blockchain transaction in a lightweight, permissioned environment can be conservatively estimated at $E_{t}x=0.01$ kWh, considering both consensus operations and smart contract execution. Figure 17 is a rough approximation based on previous work and was considered in order to conduct comparisons since there can be differences in actual consumption due to the underlying hardware and consensus algorithms employed in various networks.

Figure 17. Energy consumption comparison for Baseline ABAC ([1]), Hybrid Fabric–Besu ([2]), and ODABAC-IoT.

In order to perform a sensitivity analysis and examine the validity of the energy consumption model, the energy per transaction ($E_{t}x$) factor was varied within ±20% from its default value. The result showed that while the absolute value of energy consumed changed proportionally with $E_{t}x$, the relative efficiency gains of ODABAC-IoT were still maintained. Hence, it can be concluded that the observed benefits are not dependent on the value of $E_{t}x$.

In the baseline on-chain ABAC model, every access request is fully evaluated on-chain, leading to the highest energy demand. For 100,000 simulated requests, this translated to approximately $Y_1=1000$ kWh. The previously proposed hybrid blockchain framework [2], which streamlined attribute handling, reduced the number of on-chain executions by about 30%, lowering total energy usage to around $Y_2=700$ kWh. By contrast, the proposed ODABAC-IoT framework achieved a far greater reduction by selectively delegating high-confidence access decisions to the off-chain LightGBM inference engine, while cryptographically verifying the results on-chain. This selective strategy reduced the number of blockchain transactions by nearly 65%, resulting in an energy consumption of only $Y_3=350$ kWh per 100,000 requests, a 65% reduction compared to on-chain ABAC and 50% compared to hybrid blockchain approaches. Assuming linear scaling, the energy consumption per request would be approximately 0.01 kWh/request, and total energy would scale proportionally with the number of access requests.

When scaled to a realistic household deployment with ∼20 devices generating approximately 1000 access requests per day, ODABAC-IoT reduces daily blockchain energy use from 10 kWh/day in the on-chain baseline to 3.5 kWh/day, yielding a daily saving of $Z\approx 6.5$ kWh.

These savings represent the equivalent of continuously running an efficient 65 W LED lighting system for 100 h. This represents small savings for an individual home; however, when scaled to a large number of households (e.g., 1000 homes in a smart-grid-based community setting), the savings can represent significant contributions to sustainability. Assuming an average grid emission factor, the reduction in energy consumption also implies a proportional decrease in carbon dioxide emissions; however, a detailed emission model is beyond the scope of this study. Table 7 provides a comparison of the energy usage of the baseline on-chain ABAC protocol, hybrid blockchain protocol, and the proposed ODABAC-IoT protocol per 100,000 requests. This table highlights the significant savings achieved by the ODABAC-IoT protocol.

Table 7. Comparative energy consumption of access control frameworks (per 100,000 requests).

Framework	Energy Consumption (kWh)
On-chain ABAC [1]	1000
Hybrid Blockchain [2]	700
ODABAC-IoT (Proposed)	350

Figure 17 demonstrates how these frameworks use energy to process 100,000 requests, with an assumption of linear relationship between the number of transactions processed and the energy required to process transactions, with a fixed energy model per transaction ($E_{t}x$) being used when calculating the energy consumption per transaction. The on-chain ABAC model experiences the highest level of growth in demand for energy, while the hybrid blockchain model experiences partial reductions versus the ABAC model. The ODABAC-IoT model continues to have a low level of usage and has a much flatter slope versus the ABAC model. The results demonstrate that ODABAC-IoT enhances operational efficiencies and supports the environmental sustainability of energy-efficient IoT systems in their contributions toward achieving smart-energy-system sustainability goals.

The ODABAC–IoT framework enhances the performance of transactions by performing off-chain inference using LightGBM. This method employs an efficient leaf–wise gradient-boost algorithm and histogram-based decision trees which allow for faster training and lower memory requirements when compared to traditional ensemble algorithms.

These algorithmic benefits are reflected in the reduced number of CPU cycles per access request evaluation, particularly when implemented on small edge nodes. Consequently, edge devices experience a power consumption decrease of approximately 20% (based on comparative computational profiling) during inference relative to baseline off-chain models. This two-layer minimization, both at the blockchain level and at the edge-processing level, shows that ODABAC-IoT can achieve end-to-end AC pipeline energy savings, which justifies its use as a sustainable and green computing architecture in smart-home energy systems. Figure 18 indicates that LightGBM inference requires less computational resources than other ensemble models, reducing edge-node power consumption by as much as 22% and supplementing the energy savings of the blockchain side. The results shown here were obtained through analytical modeling and simulation-based evaluation. The comparison of the different algorithms in this study was based on the same set of workloads and compared based on the computational efficiency of each algorithm, considering its model complexity and inference cost. Figure 18 shows the results of this empirical evaluation.

Figure 18. Comparative edge-node power consumption (per 1,000 inference requests.

5.5. Security, Trust, and Standards Compliance

Beyond performance and efficiency gains, the ODABAC-IoT framework is explicitly designed to preserve zero-trust principles and ensure compliance with established and emerging standards in the energy domain. A core element of this design is the cryptographic signing of all high-confidence off-chain ML predictions, which guarantees their authenticity before submission to the blockchain. The system requires random auditing of its predictions because this process protects the off-chain ML inference engine from unauthorized operation. The combination of cryptographic integrity together with randomized auditing creates a reliable trust system that protects against adversarial attacks while allowing operational efficiency. ODABAC-IoT meets multiple international standards through its compliance with various regulatory frameworks.

• NISTIR 7628 [53]
  ODABAC-IoT fulfills the NIST requirement for continuous monitoring, integrity validation, and accountability by ensuring that each AC decision is verified through immutable logs.
• IEC 62351 [54]
  ODABAC-IoT implements the communication and system security standard for power systems, IEC 62351, using cryptographic guarantees of integrity, authenticity and confidentiality to protect data exchange within energy management systems as part of an overall focus on securing IoT-enabled devices through ODABAC-IoT’s decision-making process.
• IEEE 2030.5 [55]
  The context-aware decision-making and secure logging elements of IEEE 2030.5 (SEP2.0) inherently support the interoperability/security requirements for distributed energy resources as specified within this smart energy profile standard.

Moreover, the auditable and tamper-proof decision logs that can be maintained through ODABAC-IoT can help in establishing a robust compliance strategy with FERC/NERC Critical Infrastructure Protection (CIP) requirements, which emphasize the need for transparent, traceable, and verifiable AC mechanisms for critical infrastructures in the energy domain. Thus, by establishing itself as a compliance-ready framework, ODABAC-IoT is capable of supporting a wide range of secure smart homes, microgrid systems, and grid-integrated IoT environments.

Table 8 maps the relevant international standards to the specific contributions of ODABAC-IoT, highlighting how each security, trust, and compliance requirement is addressed by the framework.

Table 8. Standards mapping and ODABAC-IoT contributions.

Standard/Regulation	Key Requirement	Contribution of ODABAC-IoT
NISTIR 7628 [53]	Continuous monitoring, integrity validation, and auditability of smart-grid systems	Cryptographic signing of ML decisions and periodic on-chain auditing ensure continuous verification and tamper proof logging of AC events.
IEC 62351 [54]	Confidentiality, integrity, and authentication of communication in energy management systems	All access requests and ML predictions are cryptographically verified before execution, preserving data integrity and authentication.
IEEE 2030.5 [55]	Secure, interoperable communication and control of distributed energy resources (DERs)	Context-aware, zero-trust ABAC policies with secure decision logs enable interoperability and trustworthy DER integration.
FERC/NERC CIP [56]	Transparent, traceable, and auditable AC mechanisms for critical energy infrastructures	Immutable, auditable blockchain logs of AC decisions support regulatory compliance for grid-level security.

5.6. Sustainability Impact

The ODABAC-IoT framework aligns with UN SDG 7 (Affordable and Clean Energy) by lowering blockchain-related electricity demand by ≈65%. At the community scale (e.g., 1000 homes), this equates to ≈6.5 MWh in annual savings. The reduced on-chain workload also extends node hardware life, indirectly cutting embodied carbon. Hence, ODABAC-IoT contributes to energy-aware and carbon-efficient smart-grid ecosystems.

6. Discussion

The findings from this study demonstrate that the proposed ODABAC-IoT framework achieves a well-calibrated balance between efficiency, accountability, and compliance readiness. From a performance point of view, the use of off-chain LightGBM inference has a significant impact, reducing decision latency and transaction volume on the blockchain, which has a direct impact on reducing the overhead of the system. At the same time, the auditability of the system has not been compromised, as all high-confidence off-chain predictions are cryptographically signed and periodically verified on-chain, ensuring the integrity of the system is not compromised. From an energy system point of view, the contribution of the proposed system, ODABAC-IoT, towards the green computing movement is direct. The framework achieves energy savings for both homes and communities through its computational optimization, which results in a 65% reduction in expensive on-chain executions. The smart-grid system shows minimal energy savings for individual homes, but the total energy savings become essential when all homes join the smart-grid system. ODABAC-IoT functions as an effective technical solution that improves energy systems through its focus on sustainability. The framework complies with international standards like NISTIR 7628, IEC 62351 and IEEE 2030.5 while it helps organizations meet FERC/NERC CIP compliance obligations. Thus, by incorporating auditable, tamper-proof, and standards-aligned decision logging into its design, ODABAC-IoT is able to assert itself as a compliance-ready framework, one that is appropriate for use in energy-sensitive and critical infrastructures domains, where compliance is a de facto requirement for adoption. In summary, the hybrid design of ODABAC-IoT moves well beyond technical optimization concerns to deliver a holistic solution that improves scalability, energy efficiency, and compliance, making it a progressive architecture for smart homes and grid-integrated energy systems that is secure and sustainable in nature.

7. Conclusions

This paper proposed ODABAC-IoT, a novel hybrid framework using dynamic ABAC to provide secure AC in IoT environments with a focus on being able to handle large numbers of users and devices without sacrificing performance or scalability by using ML to make efficient use of off-chain resources. High-confidence decisions are made by the LightGBM model based on learned decision patterns, using results it produces, therefore keeping the integrity of the data, while using the blockchain for low-confidence/ambiguous results by doing full on-chain ABAC evaluations. As a result, there are no blockchain transaction overheads when completing a high-confidence ABAC evaluation; however, there is absolutely no loss of verifiability or security. Furthermore, the models are verified and retrained periodically, which allows for long-term sustainability and adaptability as the environment changes. Experimental results demonstrated that the proposed framework achieved up to 65% reduction in blockchain transaction volume, approximately 64% improvement in latency, and 65% reduction in energy consumption compared to conventional on-chain ABAC mechanisms, while maintaining reliable and auditable access control decisions. Moving forward, ODABAC-IoT presents a scalable, cost-effective, and intelligent solution for secure AC in smart-home energy systems, with potential applicability across other critical IoT domains. Future work will focus on improving robustness against adversarial inputs and validating the framework in real-world deployments.