Securing Zero-Touch Networks with Blockchain: Decentralized Identity Management and Oracle-Assisted Monitoring

Abstract

Zero-Touch Network (ZTN) represents a cornerstone approach of Next Generation Networks (NGNs), enabling fully automated and AI-driven network and service management. However, their distributed and multi-domain nature introduces critical security challenges, particularly regarding service identity and data integrity. This paper proposes a novel blockchain-based framework to enhance the security of ZTN through two complementary mechanisms: decentralized digital identity management and oracle-assisted network monitoring. First, a Decentralized Identity Management framework aligned with Zero-Trust Architecture principles is introduced to ensure tamper-proof authentication and authorization in a trustless environment among network components. By leveraging decentralized identifiers, verifiable credentials, and zero-knowledge proofs, the proposed Decentralized Authentication and Authorization component eliminates reliance on centralized authorities, while preserving privacy and interoperability across domains. Second, the paper investigates blockchain oracle mechanisms as a means to extend data integrity guarantees beyond the blockchain, enabling secure monitoring of Network Services and validation of Service-Level Agreements. We propose a four-dimensional framework for oracle design, based on qualitative comparison of oracle types—decentralized, compute-enabled, and consensus-based—to identify their suitability for NGN scenarios. This work proposes an architectural and design framework for Zero-Touch Networks, focusing on system integration and security-aware orchestration rather than large-scale experimental evaluation. The outcome of our study highlights the potential of integrating blockchain-based identity and oracle solutions to achieve resilient, transparent, and self-managed network ecosystems. This research bridges the gap between theory and implementation by offering a holistic approach that unifies identity security and data integrity in ZTNs, paving the way towards trustworthy and autonomous 6G infrastructures.

1. Introduction

Next Generation Networks (NGNs), along with Artificial Intelligence, eXtended Reality, and Blockchain, are the fundamental technologies of the Metaverse. Sixth-generation and beyond networks promise to offer high-quality network services guaranteeing ultra-low latency, ultra-high availability, and enormous data rates. Leveraging existing advancements in both hardware and software, NGNs are moving toward AI-powered automation and self-orchestration, with efforts led by bodies such as ETSI to standardize frameworks in the context of Zero-Touch Networks (ZTNs) and Zero-Service Management (ZSM) for fully autonomous network management [1].

While ZTNs offer significant advantages in enhancing the sustainability of NGNs, optimizing Network Service (NS) management, and ensuring high (and configurable/manageable) Quality of Service (QoS), several security challenges must be addressed [2,3]. The modular and extensible nature of ZTNs, with open interfaces and multi-domain services, increases the attack surface, necessitating robust security measures to ensure framework trustworthiness. Studies by ETSI have highlighted potential security threats in ZTN automation, which can be categorized into two critical areas of concern: Service Identity and Data Integrity.

• Service Identity concerns arise from the modular and extensible nature of ZTNs, which rely on open interfaces and multi-domain services. The lack of robust authentication mechanisms increases the risk of unauthorized access, compromised services, and trust issues between stakeholders with varying security policies. Without an effective identity verification framework, malicious entities can infiltrate the network, leading to service disruptions and security breaches. ETSI has identified these risks, emphasizing the need for adaptive trust management systems to ensure secure interactions between ZTN components [2,3].
• Data Integrity is another major area of concern, as ZTNs facilitate extensive data exchanges over public channels, making them vulnerable to tampering, unauthorized modifications, and privacy breaches. Compromised data may have catastrophic consequences, leading to faulty network operations and degraded service performance. Moreover, the integration of AI into ZTNs introduces unique security risks, such as data poisoning and adversarial attacks, which may manipulate decision-making processes. Ensuring the integrity and reliability of AI-driven automation is crucial to prevent malicious behaviors and maintain the robustness of ZTNs [2,3].

Blockchain technology comes to the rescue, offering a robust solution to the security limitations of ZTNs by providing data integrity, strong cryptographic mechanisms, and Decentralized Identity Management (DIM). Its decentralized nature eliminates single points of failure, making it an ideal framework for securing interactions between ZTN services and components. To address Service Identity concerns, blockchain can be leveraged to implement decentralized digital identity management for ZTN services. Unlike traditional identity systems that rely on centralized authorities, blockchain-based identity management enables tamper-proof verification through smart contracts and cryptographic signatures. This ensures that only authenticated and verified services can interact within the ZTN ecosystem, mitigating the risks of unauthorized access and compromised components. Regarding Data Integrity, blockchain facilitates secure communication and monitoring of NSs through oracle mechanisms, which enable blockchain networks to interact with external data sources, applications, and services [4]. By integrating oracles, ZTNs can ensure that exchanged data remains untampered and verifiable, reducing risks associated with data poisoning and adversarial attacks. Blockchain’s inherent cryptographic protections also prevent unauthorized modifications of network data, ensuring end-to-end transparency and traceability in network management operations.

Furthermore, blockchain can complement Zero-Trust Architecture (ZTA), a cybersecurity model that eliminates implicit trust in network components. ZTA is built on the notions of least privilege, granular access control, and dynamic and strict policy enforcement wherein no user or device is implicitly trusted–irrespective of stature or location [5]. In contrast to traditional security models that rely on static and network-based security perimeters, ZTA focuses on securing individual assets and resources (i.e., devices, applications, and data) [6]. Blockchain can enhance ZTA by decentralizing authentication and authorization, ensuring that every entity—whether a user, service, or resource—undergoes continuous verification before gaining access. This aligns with the zero-trust principle that no entity is inherently trustworthy, further strengthening ZTN security against unauthorized access.

This paper explores the integration of blockchain technology into Zero Touch Networks (ZTNs) to address critical security challenges related to Service Identity and Data Integrity. The main contributions are as follows:

• Decentralized Digital Identity Management in ZTNs: The adoption of decentralized digital identity mechanisms within the framework of ZTA is examined to enhance the security of ZTN services. By leveraging blockchain-based identity management, a trustless and tamper-proof authentication framework is presented to mitigate risks associated with unauthorized access and compromised services.
• Secure Interaction and Monitoring through Oracles: The use of oracle mechanisms is investigated to enable secure interaction between blockchain-based services and ZTN components. Additionally, oracles are explored as a means to facilitate real-time monitoring of NSs to ensure Service Level Agreement (SLA) fulfillment, enhancing network reliability and transparency. A multi-dimensional design framework and a comparative evaluation of various oracle solutions are conducted to identify the most suitable mechanism for ensuring secure and efficient communication between blockchain services and ZTN environments. This analysis provides insights into the strengths and limitations of different Oracle implementations, guiding future deployments in automated network management.

To the best of our knowledge, there is a lack of published research that explores the integration of decentralized digital identity management for ZTA in NGNs alongside oracle-based mechanisms for secure NS monitoring. This paper introduces a novel approach by combining decentralized identity management to strengthen Service Identity in ZTNs with oracle-based solutions to ensure secure interactions and SLA-compliant NS monitoring. Additionally, a comparative analysis of oracle mechanisms is performed to identify the most effective solution for integrating blockchain with ZTN environments. By bridging these emerging research areas, this work contributes to the advancement of secure and autonomous NGNs, paving the way for more resilient, transparent, and self-managed network infrastructures.

This work is positioned as an architectural and design-oriented study rather than an experimental performance evaluation. Quantitative performance values are provided as analytical feasibility estimates derived from existing implementations. The primary objective of this paper is to integrate decentralized identity management, Zero-Trust Architecture, ETSI ZSM principles, and oracle-assisted monitoring into a unified framework suitable for Zero-Touch Networks. Rather than proposing new cryptographic primitives or protocol-level optimizations, the paper focuses on system-level composition, trust boundaries, security assumptions, and prescriptive design guidelines that are currently missing from the literature. Experimental validation in large-scale or operator-grade environments is therefore not the main goal of this study; instead, the contribution lies in providing an implementation-aware architecture that can serve as a foundation for future deployments and empirical evaluations.

This paper is organized as follows: Section 2 presents the related work in this research domain, while in Section 3, the use of blockchain technology for decentralized identity management is discussed in detail with emphasis on its alignment with ZTA for ZTN services and on the qualitative assessment of the achieved security levels. Section 4 explores oracle mechanisms that could be used in this scenario, followed by a comparative analysis to provide guidelines to prospective implementers. Finally, future work is discussed in Section 5, while conclusions are drawn in Section 6.

2. State of the Art

In the last few years, there has been a strong push toward developing self-managed and self-orchestrated networks to support emerging technologies, with organizations such as ISG ZSM and ETSI promoting automated end-to-end service management through Network Function Virtualization (NFV), Software Defined Networking (SDN), and AI technologies [7]. One of the main aspects of this endeavor is ensuring security within the ZTN and ZSM architecture, particularly in terms of trust relationships and access control in multi-domain environments [2,3,8]. To address these concerns, researchers propose dynamic identity and authentication policy management, typically relying on centralized authentication and authorization systems [7]. However, while effective, this centralized approach presents challenges such as a Single Point of Failure (SPoF).

To this end, recent research papers explore decentralized approaches to increase network security through blockchain technology, leveraging cryptographic strength, data immutability, and support for secure decentralized applications via smart contracts. More specifically, in [8,9] authors have demonstrated blockchain’s potential in managing network resources and enhancing security in ZSM and NGNs, particularly in 6G [9]. Moreover, authors in [10] propose a blockchain-based system using Non-Fungible Tokens (NFTs) for secure resource management and trading in 6G network slicing, improving cost-efficiency and automation through Ethereum and IPFS. In [11], the authors focus on key security challenges in 6G networks, such as AI-driven trust, zero-touch security, quantum-safe communications, and real-time resilience, advocating for solutions like adaptive encryption and decentralized identity management (DIM). Similarly, authors in [12] emphasize blockchain’s role in strengthening authentication and authorization in 5G networks. While momentum is growing through initiatives like Robust-6G [13] and Safe6G [14], automated identity management in ZTNs remains an uncharted area for future exploration.

The intersection of DIM and NGNs is extremely small in the research community, without this meaning that this is a low-interest topic. Integrating DIM techniques and tools into ZTAs for NGNs represents a paradigm shift within the cybersecurity sector. Very few efforts have been made in order to examine in detail the benefits NGNs can harvest from utilizing DIM, especially within ZTA implementations. By decentralizing the trust and authentication processes between network services and resources, the security on identity verification can be reinforced and aligned to the NGNs with ZTA’s core principles of continuous validation, least privilege, and explicit trust.

Despite decentralized identity being a new but very promising field [15], it can support ZTA principles by enabling continuous, secure administration, authentication, and authorization methods in trustless environments, to facilitate performant interactions with integrity, as recently proven in [16]. Tools like Serto [17], Veramo [18], and Iden3 [19] implement the ongoing and continuously evolving W3C standards [20,21], offering practical APIs for decentralized authentication. The Decentralized Identity Foundation (DIF) [22] further supports this ecosystem with open, standards-based components based on the W3C efforts. However, these industry-driven advancements are notably absent from current academic research, revealing a disconnect between theoretical models and real-world implementations. The author in [23] evaluates how the security and privacy of ZTAs improve via a 6-month-long experiment, where DI was integrated and migrated in segmented networks. The findings of this work highlight the critical role of distributed identity in enhancing ZTAs while organizations enhance privacy and security and mitigate threats such as credential-based attacks.

Other research works also make clear the gap that exists over the intersection of DIM and secure NGNs, while also revealing the need for enhancing security and privacy. In [24], the authors propose an IoT authentication mechanism, aligning with the ZTA principles and showcasing its benefits by focusing on lightweight continuous authentication for resource-constrained IoT devices in NGNs. However, authentication here is physical-based, lacking the decentralization benefits offered by DIM methods and blockchain security and transparency. The authors in [25] make use of blockchain and cryptography for implementing DIM in cloud environments, by proposing a self-sovereignty identity (SSI) model. While this work perfectly showcases the benefits of ZTA by applying blockchain-based authentication and authorization, the findings of the authors regarding ZTNs and NGNs are not specified or contextualized. In [26], the authors present in their work a multi-layered architecture for service management in Industry 4.0 over NGNs using blockchain and federated learning. Authentication and trust are managed through federated trust scores and smart contracts rather than W3C-compliant DI methods, utilizing blockchain simply as a secure storage solution.

To better position the proposed framework with respect to existing approaches,

Table 1. Comparison of DIM with representative authentication frameworks.

Aspect	DIM Framework (Current Work)	Wijethilaka et al. [12]	SSI for Cloud [25]	Federated Blockchain [26]
Identity Model	Decentralized identifiers (DIDs) for services and components	Blockchain-registered network identities	User-centric SSI	Federated domain identities
Trust Assumptions	No implicit trust; continuous verification (ZTA-aligned)	Trusted blockchain operators	Trusted credential issuers	Trusted federation members
ZTA Compliance	Explicitly designed for Zero-Trust Architecture	Partial (authentication-focused)	Limited (identity-centric)	Partial (domain-level trust)
Scalability	Supports multi-domain and service-level scalability	Limited by blockchain interactions	Scales within cloud domains	Scales across federated domains
Interoperability	Cross-domain, standards-based (W3C DID/VC)	Network-specific	Cloud-provider-centric	Federation-specific
Authorization Granularity	Fine-grained, service-level authorization	Coarse-grained	User-level access control	Domain-level authorization

provides a qualitative comparison with representative solutions from the literature. In particular, we contrast our framework with Wijethilaka et al.’s blockchain-based authentication for 5G networks [12], an SSI-based approach for cloud environments [25], and a federated blockchain authentication model [26], focusing on identity models, trust assumptions, Zero-Trust Architecture (ZTA) compliance, and scalability and interoperability properties.

It is obvious from the above studies that both the research and the industry sectors are in imperative need for further research and development on integrating blockchain-based DIM within the framework of ZTA to facilitate ZTNs. Thus, creating the most advantageous and secure ZTAs for implementing NGNs is a critical factor of success for the future of the IT sector. Eliminating centralizing identity silos, creating tamper-proof audit trails, enabling platform and organizations interoperability and portability are only some of the most fruitful benefits of implementing blockchain-based DIM within the ZTA for NGNs. Unlike existing approaches that primarily address authentication in isolated domains, the proposed DAA framework emphasizes architectural integration, Zero-Trust compliance, and interoperability across heterogeneous NGN environments.

Considering that the collaboration of various NPs is necessary in modern networks, the monitoring of NS performance in cross-domain ZSM scenarios is a very tricky task. Up until now, NS performance was tracked using centralized services which capture important data such as latency, energy consumption, and others. Tools such as Prometheus [27] and Grafana [28], were developed by NPs to generate performance reports and check whether the SLAs were met. However, this centralized approach has limitations and therefore decentralized approaches were examined based on blockchain to enhance data integrity, transparency, and resilience.

Blockchain-based oracles play a pivotal role in integrating off-chain data into blockchain networks, thereby enabling more dynamic and informed decision-making processes within decentralized applications [29,30]. In the context of network service monitoring, oracles can securely and reliably feed real-time network performance metrics into blockchain systems. This integration facilitates automated responses to network anomalies and supports the enforcement of SLAs through smart contracts.

The idea of using blockchain oracles for service monitoring is presented in [31]. Authors present a blockchain-based decentralized federation model that provides quality verification for cloud providers leasing computing resources from one another. For a blockchain-based federation, it is important to monitor the quality of service, which is highly desirable considering the multi-tenancy characteristic of cloud services. Since the blockchain network is unable to access the outside world, it cannot handle, on its own, providers’ misbehavior in terms of SLA violations. Thus, the authors introduce an oracle as a verifier agent to monitor service quality and report to the smart contract agents deployed on the blockchain. Although this paper highlights the interest in using blockchain oracles for performance monitoring, the authors do not proceed with a comparison of several oracle mechanisms to identify the most suitable one for the presented use case.

In contrast to already published research works, this paper presents the adoption of a blockchain-based ZTA-aligned Decentralized Identifier (DID) management framework for ZTNs to address security challenges in Service Identity. Moreover, it examines the use of oracle mechanisms within ZTNs, and, more specifically, for NS monitoring to tackle data integrity challenges, while presenting a comparative analysis of these mechanisms, which, to the best of our knowledge, has not yet been published in this domain.

3. Decentralized Identity Management (DIM) Framework for ZTA-Aligned ZTNs

In this section, our proposal for a DIM framework for ZTN is presented, aiming to address the limitations of traditional centralized identity management approaches and propose a robust, secure, and decentralized authentication and authorization solution for ZTN entities. We propose a blockchain-powered framework for DIM, building upon the existing reference architecture published by ETSI [1], providing a novel approach to mitigate the security issues of modern ZTNs. Figure 1 depicts the ZSM Reference Architecture proposed by the ETSI and illustrates the main components and services of the ZTN ecosystem [1]. Following a bottom-up presentation of Figure 1, every stakeholder controls pools of physical and virtual resources (Physical and Virtual layer) and develops various types of network services (XaaS) across the continuum (e.g., Far edge, 5G Core, Edge, Central Cloud, etc.) through the ZTN. These resources may be part of one or more management domains of the stakeholder controlled by the Domain and End-to-End Service Management element, while multiple stakeholders may collaborate in an automated manner to facilitate end-to-end services via the Cross-Domain Integration Services component. The whole concept of ZTNs relies on the use of AI services implemented via the AI Orchestrator component. The orchestrator makes management decisions for the domain, as realized by the Management functions, which trigger the Domain Integration Services to deploy the requested action in the current domain or use the Cross Domain Integration Services in cross-domain scenarios. The management decisions made by the AI orchestrator are based on data collected from the continuum through the Data/Resource Monitoring components and consumed by the AI orchestrator via the Data services element, considering current network demands. To this end, we achieve dynamic network management and optimization by increasing, at the same time, the adaptability of the network to changes. To facilitate the smooth and secure operation of the ecosystem, we propose a blockchain-based framework for DIM to ensure service identity and an oracle-powered mechanism to guarantee data integrity. Building upon the reference architecture, the components should communicate in a secure manner (orange arrows), and the data they rely upon to perform the management functions of the network should be genuine and tamperproof (green boxes).

Regarding service identity, the DIM framework is responsible for the identification of the components and services of the ZSM and their secure interaction. The Decentralized Authentication and Authorization (DAA) component illustrated in Figure 2 implements the framework within the areas indicated by the orange arrows in Figure 1. The framework serves as the glue for security among services and components, ensuring trustworthy interaction between ZTN components and services. In order for our approach to be aligned with the ZTA approach, which means that no services are trusted, and every service should be continuously authenticated to interact with others, the proposed framework is based on the modern decentralized identity model of Self-Sovereign Identity (SSI), allowing each service to own a unique Decentralized Identifier (DID). A blockchain ledger ensures that the DID-related data are kept decentralized, eliminating the reliance on centralized security authorities.

The DAA component (see Figure 2) consists of the following elements:

• Authorization controller: It provides digitally signed Verifiable Credentials (VCs) to every service within the domain which needs to interact with other ZTN agents/components. The controller acts as an issuing authority, implemented as an SC, an immutable piece of code stored on the blockchain network. The authorization controller contains the verifier module used for the verification of VCs, while VCs can prove the roles, capabilities, and interaction permissions of the ZTN components by allowing the corresponding ZTN agents to create a Verifiable Presentation (VP) using Zero-Knowledge Proof (ZKP).
• ZKP: It consists of two main elements, the ZKP engine deployed outside of blockchain in virtual instances hosted in the domain, and the SCs, which are the actual implementation of the ZKP in the blockchain world. ZKP, along with the Authorization controller, generates the Verifiable Presentation of a service/component. When two components (e.g., services) are to interact, instead of presenting and exposing credentials or the whole VC itself, the requesting component creates a VP using ZKP. This flow allows the component to prove one or multiple specific claims, such as authorization to access a resource or perform an orchestration task, without compromising its identity or any sensitive data. On the other hand, the verifying component checks the VP, validates its issuing authority, and ensures that this specific VP has not been revoked by checking the corresponding decentralized registry, in our case, the blockchain ledger. The described flow keeps ZSM interactions secure, efficient, and fully aligned with the ZTA, even in the absence of trust between entities. Moreover, the introduction of ZKP-based proofs (referred to as VPs) makes the system both private and resilient. Components’ credentials are verified without disclosing any underlying data, while interactions are based on the concept of Zero Trust. A revocation mechanism handled by decentralized infrastructure allows any verifier to confirm that a claim from a component or agent is still valid, without knowing its contents. This combination of standards (DIDs, VCs) and ZKP tools forms a robust foundation that fully complies with the SSI principles for secure, autonomous communication between ZTN entities, reducing attack surface and supporting scalability and flexibility.
• DID manager: Every service/component in the ZTN ecosystems generates a Decentralized Identifier (DID) used for authentication purposes. The DID manager is embedded in those services and stores the DID in the Blockchain Ledger. In order to perform authentication actions, the DID manager, beyond the role of issuer, also has the role of resolver. Blockchain Ledger: SCs, VCs, and useful data are stored in the ledger of blockchain hosted in a decentralized network of nodes. Considering the presented use case, the most suitable type of blockchain is the permissioned and private ones. The Ledger has the role of a verifiable data registry that contains valid information which cannot be questioned by anyone in the network. The confidentiality, integrity, and availability of data is guaranteed by inheriting the benefits of blockchain technology.

The blending of those components results in the novel DAA component, which implements a robust and highly secure framework for DIM, addressing the Service Identity challenges.

3.1. Security and Threat Model

To substantiate the security claims of the proposed framework, this subsection defines the assumed threat model, identifies relevant attack vectors, and discusses the security properties achieved through the architectural design choices.

Regarding the adversary model, we consider a Byzantine adversary with the following capabilities:

  i.

The ability to compromise individual services, identity holders, or oracle nodes;

 ii.

The ability to submit malformed or malicious credentials and monitoring data;

iii.

Partial control over blockchain or oracle network participants, below the consensus threshold;

iv.

Passive observation of network traffic and ledger state.

The adversary is assumed not to control a majority of consensus participants in permissioned blockchain deployments, nor to compromise the cryptographic primitives underlying digital signatures, zero-knowledge proofs, or hash functions.

Focusing on the attack vectors within this threat model, the framework addresses the following representative attack vectors:

• False DID registration: malicious entities attempting to register unauthorized or spoofed service identifiers.
• Verifiable Credential compromise: misuse, replay, or theft of valid credentials.
• Oracle manipulation and collusion: attempts by compromised oracle nodes to inject false telemetry or SLA violation reports.
• Single-point-of-failure exploitation: targeting centralized identity providers, authorization servers, or monitoring components.

To this end, the proposed framework achieves the following security properties through a combination of decentralized trust, cryptographic enforcement, and architectural redundancy:

• Integrity and authenticity: DIDs and Verifiable Credentials are anchored on a blockchain-based registry, preventing unauthorized modification and enabling verifiable provenance.
• Privacy preservation: Zero-knowledge proofs allow entities to demonstrate possession of valid credentials and authorization for specific actions without revealing identifiers or credential contents.
• Byzantine fault tolerance: Permissioned blockchain consensus and decentralized oracle architectures tolerate failures or compromise of a bounded number of nodes, eliminating single points of failure in identity management and monitoring.
• Revocation resistance: On-chain revocation registries and freshness checks prevent the use of revoked or expired credentials.
• Resilience to oracle collusion: Threshold-based aggregation, redundancy across data sources, and off-chain computation reduce the impact of malicious oracle participants.

Collectively, these mechanisms ensure that authentication and authorization decisions remain tamper-resistant, auditable, and robust against partial system compromise, while maintaining compatibility with Zero-Trust Architecture principles and ETSI ZSM requirements.

3.2. Implementation Mapping and Reference Instantiations

While the proposed Decentralized Identity Management (DIM) framework is intentionally technology-agnostic, to support reproducibility and feasibility assessment, we provide a reference implementation mapping that binds each architectural component to representative technologies. These mappings presented in

Table 2. Reference implementation mapping for the DIM architectural framework.

Architectural Component	Representative Technologies	Role in the Framework
Blockchain Platform	Permissioned Ethereum, Hyperledger Besu	Shared trust anchor, smart contract execution
DID Registry	Ethereum-compatible smart contracts	Decentralized identifier anchoring
DID Methods	did:ethr, did:web	Service and component identification
Credential Format	W3C Verifiable Credentials (JSON-LD)	Machine-verifiable authorization claims
ZKP Schemes	Groth16 zk-SNARKs, Bulletproofs	Privacy-preserving authorization proofs
Authorization Controller	Solidity-based smart contract	Policy enforcement and access control
Revocation Registry	On-chain hash-based registry	Credential validity verification

are illustrative rather than prescriptive, and they do not constrain the framework to specific platforms or vendors.

The selected technologies reflect mature, widely adopted solutions that are compatible with ETSI ZSM deployment assumptions and Zero-Trust Architecture principles. Alternative implementations offering equivalent security, decentralization, and interoperability properties can be substituted without altering the architectural design or trust model of the framework.

It is emphasized that these technologies serve as reference instantiations, and the proposed framework remains fully extensible to alternative platforms providing equivalent security and interoperability guarantees.

3.3. DIM Framework in Action

In order to better understand the functionality of the DID framework and the role of the proposed DAA component, we provide an example with reference to Figure 3. Assuming a new service joins the ecosystem by initiating the onboarding process, in which the service generates a unique DID (Figure 3. Onboarding—Steps 1 and 2). The DID is stored on the blockchain while a VC is constructed by the DAA’s authorization controller, which acts as an issuing authority (Figure 3. Onboarding—Step 3). The VC describes the permissions of the service and is cryptographically signed by the DAA component (Figure 3. Onboarding—Step 4). The new service is now able to use the ZKP component and produce one VP for each of its capabilities (e.g., access to another’s service file, make a request to the orchestrator, utilize more CPU cores, etc.) (Figure 3. Access Control—Steps 1 and 2). Each VP is a cryptographic proof of a service’s claim during interactions that it has the permission to proceed with an action within ZTN. To this end, when the service is about to interact with another service or component of the ZTN ecosystem, the VP is presented as fully private proof that the service has the right to do so (Figure 3. Access Control—Step 3). Any other component can then reconstruct the VP using only the information known for this particular interaction (e.g., the DID of the requesting service, the request itself, and the signature of its VP) and validate this claim against the presented VP (Figure 3. Access Control—Step 4). After validation is successful, the component which asked for permission is granted authorization for its requested function (Figure 3. Access Control—Step 5).

Timing, Concurrency, and Error Handling Considerations

To further illustrate the feasibility of the workflow depicted in Figure 3 under NGN operational constraints, we distinguish between operations that require blockchain write access and those that rely exclusively on read operations. Specifically, DID generation and VC issuance occur during service onboarding and involve ledger write operations, whereas Verifiable Presentation (VP) validation during access control relies only on read operations and off-chain computation.

DID creation and VC issuance are non-time-critical operations that are executed infrequently, typically during service instantiation or reconfiguration. When permissioned blockchain platforms are employed (e.g., Hyperledger Besu), these write operations can be completed within tens of milliseconds and are not part of the real-time control loop. In contrast, VP generation and verification are designed to operate within NGN-relevant latency bounds. Zero-knowledge proof generation is performed off-chain and can be parallelized across services, while VP verification involves lightweight cryptographic checks and ledger reads that can be completed in under 10 ms in typical permissioned deployments.

To clarify the role of zero-knowledge proofs within the proposed Decentralized Authentication and Authorization (DAA), the ZKP circuit is designed to prove a set of authorization-related statements without revealing the underlying DID or credential contents. Specifically, the circuit proves the following:

  i.

The requesting entity possesses a valid VC issued by a trusted authority;

 ii.

The credential encodes authorization for a specific role or action required by the requested service;

iii.

The credential has not been revoked at the time of verification.

The ZKP statement is constructed over cryptographic commitments to the VC attributes and references an on-chain revocation registry. As a result, the verifier can validate authorization and credential freshness while preserving identity and attribute confidentiality.

Proof generation is performed off-chain by the requesting entity and can be parallelized across multiple services. Based on reported benchmarks for Groth16 zk-SNARKs and similar constructions, proof generation typically incurs latency in the order of 10–100 ms, depending on circuit complexity, while proof verification is significantly lighter and can be completed in under 10 ms. These values are consistent with latency requirements for NGN control-plane authentication when off-chain computation is employed.

To mitigate gas costs associated with on-chain verification, the proposed framework favors off-chain ZKP verification combined with on-chain anchoring of verification results or commitments. When on-chain verification is required, existing zk-SNARK verifier contracts incur gas costs proportional to the number of pairing operations, which can be further reduced through batching, rollup-based execution, or Layer-2 verification mechanisms. As such, the architecture avoids placing privacy-preserving authentication on the critical on-chain execution path, preserving both scalability and cost efficiency.

The workflow inherently supports concurrent authentication requests, as VP verification is stateless and does not require global synchronization. Multiple services can independently generate and verify VPs without contention on shared resources. Error handling is addressed through explicit verification failures: invalid, revoked, or malformed credentials result in immediate authorization denial without affecting other concurrent interactions.

Based on analytical estimates derived from reported benchmarks and performance analyses of existing implementations, the critical authentication path—comprising VP generation, verification, and ledger read operations—can be completed well within the <100 ms latency requirements of NGN control-plane operations. Off-chain zero-knowledge proof generation and verification have been shown to incur millisecond-scale latency depending on circuit complexity, while permissioned blockchain platforms report read and write latencies in the order of tens of milliseconds [32,33,34,35,36,37,38,39].

Table 3. Analytical timing breakdown of the framework.

Workflow Step	Operation Type	Analytical Latency Range	Critical Path
DID Generation	Blockchain write	10–100 ms	No (onboarding only)
VC Issuance	Blockchain write	10–100 ms	No (onboarding only)
VP Generation	Off-chain ZKP computation	10–100 ms	Yes
VP Verification	Off-chain verification + ledger read	<10 ms	Yes

illustrates an analytical timing breakdown based on our main findings.

Every service in the ecosystem is identified by a unique DID, while every action of the service must be justified by a VP, implementing a decentralized, highly secure authentication and authorization framework. Therefore, the service identity is guaranteed, excluding malicious services which aim to take advantage of the open nature of modern networks. The described process should be implemented in a holistic manner, which means that every domain of the ecosystem, regardless of the NP owners or infrastructure used, should be able to use this framework.

To facilitate interoperability of the framework, a common permissioned blockchain network should be used by the providers. Even in cross-domain scenarios in which an NP of a specific domain needs to interact with services in another domain, the various components and services will interact through the DAA component. For instance, NP1 should launch an NS that requires the use of several VNFs which belong to different domains, then the management function component (see Figure 1) will communicate with the cross-domain integration services to facilitate the necessary conditions for the NS. To accomplish this, the framework and the DAA component will be used for the authentication and authorization of the various components and services that need to interact in this scenario.

3.4. Minimal Proof-of-Concept Design and Feasibility Analysis

To demonstrate the practical feasibility of the proposed architecture without assuming a full-scale Zero-Touch Network (ZTN) deployment, this subsection presents a minimal proof-of-concept (PoC) design. The purpose of the PoC is to validate architectural coherence, component interoperability, and order-of-magnitude feasibility with respect to NGN requirements, rather than to provide operator-grade performance benchmarking. The PoC focuses on service-level authentication and monitoring workflows within the management and orchestration planes, in alignment with the ETSI ZSM architecture. User-plane traffic processing and real-time packet forwarding are explicitly out of scope.

The DAA PoC targets service onboarding and access control among ZTN services operating across one or more administrative domains. It assumes a permissioned or consortium blockchain shared among trusted operators, and off-chain execution for computationally intensive tasks such as zero-knowledge proof generation. The architectural components introduced in Section 3 are instantiated using mature, widely adopted technologies, following the reference implementation mapping summarized in

Table 4. Minimal DAA proof-of-concept component mapping.

DAA Component	PoC Instantiation
DID Registry	Permissioned Ethereum-compatible ledger (e.g., Hyperledger Besu)
DID Method	did:ethr or did:web
Credential Issuer	Veramo-based SSI agent
Credential Format	W3C Verifiable Credentials (JSON-LD)
ZKP Engine	zk-SNARKs (Groth16) or Bulletproofs
Authorization Controller	Smart contract enforcing role- and policy-based access
Revocation Registry	On-chain hash-based revocation registry

.

This mapping demonstrates that the proposed DAA framework can be instantiated using existing tooling without introducing custom cryptographic primitives or proprietary components.

A typical PoC authentication and authorization flow proceeds as follows:

• Service onboarding: Each network service generates a DID and registers the hash of its DID document on the blockchain.
• Credential issuance: An authorized domain entity issues a VC attesting to the service’s role, domain affiliation, and permissions.
• Access request: When requesting access to a protected service or resource, the service generates a VP containing a zero-knowledge proof demonstrating possession of a valid, non-revoked credential that satisfies the access policy.
• Verification: The verifier validates the proof and checks credential revocation status via the ledger, without learning the service’s full identity or credential contents.

This workflow enables zero-trust, privacy-preserving authentication without reliance on centralized identity providers.

While the DID framework solves service identity security issues in modern networks, it does not tackle data integrity, which is vital for the proper operation of the ZTNs ecosystem. The following section aims to solve this issue by introducing the use of oracles to guarantee data integrity and prevent data poisoning attacks, which may lead to hazardous situations.

4. Oracle Mechanisms for Network Service Monitoring in NGNs

This section addresses the critical data integrity challenges in blockchain ecosystems that were discussed previously by presenting oracle-based solutions that extend blockchain’s inherent security properties to external data sources. While blockchain technology excels at ensuring integrity, transparency, and immutability for on-chain data, it faces fundamental limitations when interacting with external information systems—a challenge known as the “oracle problem” [40].

In modern blockchain applications, smart contracts must frequently interact with external data sources and systems to execute real-world functions. This interaction creates a critical vulnerability: blockchain networks cannot independently verify the authenticity or accuracy of off-chain data. To this end, oracles are software mechanisms that serve as trusted intermediaries, bridging the gap and enabling secure bidirectional communication between blockchain networks and external data resources while extending blockchain’s security guarantees to the entire system architecture (as illustrated in Figure 1).

4.1. Oracle Types Taxonomy

To systematically understand the oracle ecosystem, a comprehensive taxonomy of oracle types based on their operational characteristics, architectural patterns, and functional capabilities, as they appear in [30,41], is provided.

Table 5. Blockchain oracle types.

Oracle Type	Description	Key Advantages	Limitations	Use Cases
Pull-Based Oracles	Retrieve data from external sources on demand when requested by smart contracts	Real-time data access Efficient resource utilization Widely adopted in DeFi protocols	Dependency on external source availability Potential centralization risks	Price feeds, market data, API integrations
Push-Based Oracles	Proactively send data or commands from smart contracts to external systems	Enables blockchain-to-world automation Supports complex workflow orchestration	External system dependency Potential execution failures	Payment processing, IoT device control, automated notifications
Cross-Chain Oracles	Facilitate interoperability by enabling data and asset transfer between different blockchain networks	Multi-chain ecosystem support Enhanced liquidity and functionality	Complex security coordination Increased attack surface	Cross-chain DeFi, multi-blockchain applications, asset bridging
Compute-Enabled Oracles	Execute complex off-chain computations and deliver verified results to smart contracts	Scalability enhancement Privacy-preserving computations Advanced cryptographic operations	Trust assumptions in computation Potential latency issues	Zero-knowledge proofs, verifiable random functions, and machine learning inference
Software Oracles	Automated systems that aggregate data from digital sources (APIs, websites, databases)	High-speed data processing Multi-source aggregation capabilities Cost-effective operation	Centralization vulnerabilities Internet connectivity dependency	Weather data, financial markets, news feeds, social media sentiment
Hardware Oracles	Physical devices (sensors, RFID, IoT devices) that capture real-world data for blockchain integration	Direct real-world data capture Tamper-evident capabilities Supply chain transparency	Physical tampering risks Limited deployment scalability	Supply chain tracking, environmental monitoring, and asset authentication
Inbound Oracles	Specialized systems for importing external data into blockchain environments	Real-world event integration Trigger-based smart contract execution	Source reliability dependency Data validation challenges	Insurance claims, prediction markets, event-driven contracts
Outbound Oracles	Enable smart contracts to trigger actions in external systems	Real-world impact capability Automated external system control	Single point of failure risks External system reliability dependency	Banking integrations, logistics automation, and regulatory reporting
Centralized Oracles	Single entity-controlled data providers offering streamlined data delivery	Simple implementation Low latency Cost-effective for specific use cases	Single point of failure Manipulation and censorship risks	Internal enterprise systems, trusted data providers
Decentralized Oracles	Multi-node networks using consensus mechanisms to validate and deliver data	Enhanced security and reliability Manipulation resistance High availability	Increased operational complexity Higher costs Consensus latency	Critical financial data, high-value transactions, public goods
Human Oracles	Human experts providing subjective analysis and complex data interpretation	Subjective judgment capability Complex scenario handling Quality assurance for nuanced data	Scalability limitations Potential bias and errors High operational costs	Legal disputes, subjective assessments, and quality verification
Contract-Specific Oracles	Purpose-built oracles designed for individual smart contract requirements	Optimized performance Minimal attack surface Tailored security measures	Limited reusability Higher development costs per application	High-security applications, specialized use cases, one-time events
Consensus-Based Oracles	Networks that aggregate multiple data sources using consensus algorithms for accuracy	Enhanced data reliability Reduced manipulation risks Fault tolerance	Coordination complexity Increased latency Higher operational costs	Critical infrastructure, financial settlements, and governance systems
AI-Based Oracles	Machine learning systems that provide predictive analytics and intelligent data processing	Predictive capabilities Adaptive learning Complex pattern recognition	Model transparency challenges Training bias risks Continuous maintenance requirements	Prediction markets, risk assessment, automated decision-making

provides a detailed analysis of fourteen distinct oracle categories, each addressing specific use cases and technical requirements.

Each oracle category in Table 5 is systematically mapped onto the four dimensions introduced in Section 4.2, enabling structured comparison and informed selection for NGN deployments.

Clarification on overlapping oracle categories:

Some oracle categories in Table 5 may appear overlapping at first glance, particularly Software Oracles and Inbound Oracles. This overlap is intentional and reflects the fact that oracle types can be described along different orthogonal design dimensions.

Specifically, Software Oracles characterize the nature of the data source (i.e., digital, API-based information), whereas Inbound Oracles describe the directionality of data flow, namely the import of external data into the blockchain. As a result, a Software Oracle may operate as an inbound, outbound, or bidirectional oracle depending on the interaction pattern.

To avoid ambiguity and support design-time reasoning, these categories are explicitly positioned within the four-dimensional oracle framework introduced in Section 4.2, where directionality, architecture, functionality, and application-specific optimization are treated as independent dimensions.

4.2. A Four-Dimensional Framework for Oracle Integration in NGN

While researchers have proposed multi-dimensional frameworks for oracle classification, existing approaches often focus on specific aspects rather than comprehensive taxonomies [42,43,44]. Building upon these foundational works, we propose a novel four-dimensional classification framework that synthesizes and extends existing approaches while aligning closely with the needs of NGNs. The oracle taxonomy presented in Section 4.1 serves as the input space for this framework, with individual oracle types positioned along each dimension to support design-time trade-off analysis.

The first dimension, Directionality, describes the flow of information between off-chain systems and the blockchain. This dimension comprises three primary modes: inbound, wherein external data is transmitted onto the blockchain; outbound, in which blockchain data is sent to external entities; and bidirectional, which supports two-way data interactions. The bidirectional mode ensures seamless interoperability between on-chain and off-chain environments, facilitating integrated and dynamic data exchanges essential for NGNs.

The Architectural dimension addresses the structural organization of blockchain systems that interface with oracles. Centralized architectures offer streamlined management under a single authority but may compromise trust and fault tolerance. In contrast, decentralized architectures distribute control across multiple nodes, leveraging consensus algorithms to enhance security, transparency, and resilience. Hybrid architectures aim to balance these traits by integrating centralized coordination with decentralized validation, optimizing both efficiency and trustworthiness.

From a Functional perspective, oracles are classified according to their mechanisms for data acquisition and computation. Pull-based models rely on on-demand data retrieval initiated by blockchain requests, whereas push-based models proactively deliver data or trigger computations as required. Compute-enabled architectures extend these capabilities by supporting off-chain computations whose results are verified on-chain, thereby enhancing scalability and flexibility. The Functional dimension also applies cross-chain capabilities, enabling communication and data transfer across heterogeneous blockchain networks and promoting broader ecosystem interoperability.

Finally, the Application-Specific dimension captures optimization goals tailored to particular use cases. Computation-focused systems prioritize intensive data processing and complex algorithmic execution. Prediction-oriented designs emphasize analytics and forecasting capabilities, supporting forward-looking insights critical to various domains. Privacy-preserving implementations integrate advanced cryptographic techniques to ensure data confidentiality and user privacy, while real-time systems are engineered for low latency, addressing the stringent timing requirements of mission-critical applications—an increasingly vital feature in NGNs.

Together, these four dimensions illustrated in Figure 4, form a comprehensive framework for analyzing and designing oracle-enabled blockchain systems. This taxonomy accommodates the diverse technical requirements and operational challenges intrinsic to next-generation decentralized networks, supporting more robust, adaptable, and secure oracle deployments.

4.2.1. Prescriptive Design Guidelines for Oracle Selection in NGNs

While the four-dimensional framework provides a structured classification of oracle mechanisms, NGN deployments require prescriptive guidance to translate design requirements into concrete oracle configurations. Based on the identified dimensions, we derive the following design guidelines that map common NGN constraints to recommended oracle architectures and functional models.

For ultra-low latency control-plane operations (e.g., closed-loop orchestration with end-to-end latency on the order of 10 ms), compute-enabled inbound oracles with off-chain aggregation are recommended. In this case, off-chain computation minimizes blockchain interaction overhead, while inbound directionality ensures timely delivery of telemetry data to on-chain decision logic. Privacy-sensitive data should be processed off-chain, with only verified summaries or cryptographic commitments submitted on-chain to reduce exposure and latency.

For latency-sensitive monitoring involving sensitive or proprietary telemetry, a compute-enabled architecture combined with privacy-preserving functional models (e.g., zero-knowledge proof–assisted computation) is preferred. This configuration allows services to prove compliance with monitoring or SLA constraints without revealing raw metrics, aligning with Zero-Trust principles while maintaining sub-control-plane latency requirements.

For cross-domain SLA enforcement and multi-operator environments, decentralized inbound or bidirectional oracles are the most suitable choice. Decentralized architectures mitigate single points of failure and reduce trust assumptions across administrative domains, while consensus-based aggregation enhances data integrity and auditability. This configuration is particularly appropriate when SLA violations trigger contractual or automated remediation actions.

For mission-critical decision-making where correctness and tamper resistance outweigh latency constraints, consensus-based decentralized oracles are recommended. Although consensus introduces additional delay, the resulting Byzantine fault tolerance and resistance to oracle manipulation are essential for high-impact decisions such as service suspension, penalty enforcement, or regulatory reporting.

For automation and actuation scenarios where blockchain logic must trigger actions in external systems (e.g., resource scaling, service reconfiguration, or policy enforcement), bidirectional or outbound oracles should be employed. These configurations enable blockchain-to-network interaction while maintaining traceability and control over externally executed actions.

Finally, centralized oracle architectures may be acceptable only in tightly controlled, single-domain environments where trust assumptions are explicit and aligned with operator policies. However, such configurations are generally discouraged in Zero-Touch and Zero-Trust NGN scenarios due to their inherent single-point-of-failure characteristics.

These guidelines operationalize the four-dimensional framework by explicitly linking NGN requirements to oracle design choices, enabling practitioners to move from abstract classification to concrete deployment decisions.

4.3. Qualitative Analysis of Oracle Mechanisms in NGNs

Considering the high expectations of NGNs, presented also in [45], we proceed in performing qualitative analysis to identify the characteristics of the most suitable oracle mechanisms that can be adopted. Focusing on the case of network service (NS) monitoring in ZTNs, an oracle is expected to collect real-time performance metrics and deliver this information to ZTN components, such as the AI orchestrator (see Figure 1), enabling the execution of necessary management actions. This integration allows for automated, tamper-proof data management, which can be used for real-time control on whether the conditions of an active SLA are met or not. Then, with the aid of a smart contract, decisions for the network’s operation can take place.

Based on these requirements, the selection of appropriate oracle types for this task depends on several critical factors. Reliability and availability are essential, as the monitoring service must achieve high availability (greater than 99%) and robust fault tolerance to ensure continuous operation despite potential component failures. Data integrity and accuracy are equally important; the applied oracle mechanism should employ cryptographic techniques and consensus mechanisms to guarantee the authenticity and precision of collected and transmitted data. In terms of scalability, performance, and trust, the selected oracle must support both horizontal scaling—by adding nodes to the oracle network—and vertical scaling—by adjusting available resources according to demand—so that high performance and system trust can be maintained. Finally, security and cost considerations dictate that the oracle network incorporate authentication and authorization mechanisms for registered users while ensuring redundancy in monitored data sources to mitigate single points of failure. Consensus algorithms should be employed to coordinate processes efficiently and minimize operational costs when reaching decisions.

An initial selection of the types of oracles that could look more promising to be applied for NGNs, followed by reasoning on that decision, is presented in

Table 6. Suitable oracle types for NS monitoring.

Oracle Type	Reasoning	Features Covered	Examples
Decentralized Oracles	Ensures high availability and trust by aggregating data from multiple independent sources. Crucial for preventing single points of failure and mitigating manipulation in multi-domain ZTNs.	Availability, Scalability, Performance, and Trust, Security and Cost, Data Integrity	Chainlink, Witnet, API3, Band Protocol
Compute-Oriented Oracles	Ideal for processing off-chain network telemetry data (e.g., bandwidth trends, anomaly detection) and sending verified results on-chain. Can also support privacy-preserving proofs via ZKPs.	Reliability and Availability, Data Integrity and Accuracy, Scalability, Performance, and Trust, Security and Cost	Chainlink Functions/Chainlink Off-chain Reporting (OCR)
Consensus-Based Oracles	Potentially useful for predictive analytics or identifying SLA violations in complex, dynamic NGN environments—though risks of model manipulation and opacity need to be managed.	Reliability and Availability, Scalability, Performance, and Trust, Data Integrity, Security and Cost	Augur, Tellor

.

To accurately assess the effectiveness of different oracle mechanisms in NGN environments, it is essential to define appropriate evaluation criteria. We propose the following NGN-specific performance metrics, which reflect the operational, reliability, and security requirements of next-generation decentralized networks. These metrics include the following:

-

Latency (Performance): Time from telemetry event to submission to blockchain network;

-

SLA Breach Detection rate (Accuracy): Correctly flagged vs. Missed violations of SLA;

-

Tamper Resistance (Data Integrity): Resistance to manipulation of data by simulated attacks;

-

Fault Tolerance (Security): Performance under node failures or delayed transactions;

-

Gas Usage (Cost): On-chain interaction costs for the oracle mechanism;

-

Throughput (Scalability): Number of events (i.e., telemetry) handled per second.

Table 7. Qualitative comparison of oracle types in the NGN context.

Type	Security	Latency	Scalability	Tamper Resistance	Complexity
Decentralized Oracle	High	Medium	Medium	High	High
Consensus-Based Oracle	High	Low	Medium	High	High
Compute-Enabled Oracle	High	Medium	High	Medium	High

summarizes the main results of the qualitative analysis that took place.

One more important topic that is often under-discussed is the underlying trust model governing the oracle infrastructure. Depending on the oracle type, the applied governance might introduce significant security risks.

Table 8. Trust models and oracles in the NGN use case.

Type	Trust Model	Security Risk	NGN Suitability
Centralized Oracle	Single-Entity Trust	High—single point of failure, data tampering	Low—violates ZTA principles
Decentralized Oracle	Distributed Trust	Medium—depends on node diversity and sync	Good—needs coordination
Consensus-Based Oracle	Economic/Stake-Based Trust	Low—slashing and disputes prevent misbehavior	Strong—ideal for SLA decisions
Compute-Enabled Oracle	Hybrid + Computation Trust	Medium—depends on computation accuracy and off-chain logic	Suitable—needs a monitoring layer

highlights the expected performance of each of the oracle types included in Table 5 and Table 6, with the extra addition of the centralized type, which is added for comparison reasons.

Based on the qualitative assessment across the defined NGN-specific metrics, decentralized and compute-enabled oracles emerge as the most balanced solutions for ZTN environments. They achieve high tamper resistance and scalability while preserving low-latency performance essential for SLA validation and real-time decision-making. Compared to centralized and static oracle schemes, they better align with the Zero-Trust and Zero Touch principles by distributing verification responsibilities and eliminating single points of failure. Moreover, their modular design allows incremental integration into existing service orchestration layers without disrupting current NGN control logic. This qualitative validation confirms that the proposed four-dimensional framework and performance metrics can effectively guide oracle selection and deployment strategies in real-world NGN scenarios.

4.4. Decision-Oriented Oracle Selection Guide for NGNs

While Section 4.2.1 provides narrative prescriptive guidelines derived from the four-dimensional framework, this section summarizes those guidelines in a compact, decision-oriented form for quick reference. To support practical design-time selection, we derive a decision-oriented guide presented in

Table 9. Decision-oriented oracle selection guide for NGN scenarios.

NGN Requirement	Key Design Constraints	Recommended Oracle Characteristics	Indicative Oracle Types
Ultra-low latency control loops	Sub-100 ms reaction, minimal on-chain interaction	Off-chain aggregation, pull-based, lightweight verification	Compute-enabled, Software (Inbound)
Cross-domain SLA enforcement	Multi-stakeholder trust, auditability	Multi-source validation, decentralized consensus	Decentralized, Consensus-based
Privacy-sensitive telemetry	Confidential metrics, limited data disclosure	Off-chain computation, ZKP-assisted proofs	Compute-enabled with ZKP
Mission-critical automation	High fault tolerance, tamper resistance	Redundant sources, Byzantine-resilient aggregation	Decentralized + Consensus-based
Blockchain-to-network actuation	External system triggering, bidirectional flow	Outbound or bidirectional communication	Outbound, Bidirectional Oracles

that maps common NGN requirements to suitable oracle characteristics and representative oracle types.

This guide operationalizes the oracle taxonomy of Section 4.1 within the four-dimensional framework of Section 4.2, transforming descriptive classification into actionable design guidance for NGN deployments.

4.5. Discussion and Assessment

The four-dimensional oracle framework was assessed qualitatively against the identified NGN-specific performance metrics to evaluate its applicability within Zero-Touch Networks. The evaluation highlights that decentralized and compute-enabled oracles, when analyzed under the proposed taxonomy, offer optimal trade-offs between trust distribution, data integrity, and operational latency. The framework enables systematic comparison across oracle architectures and facilitates alignment with ZTA principles. Although the evaluation is theoretical, it provides an evidence-based rationale for selecting oracle mechanisms capable of secure, low-latency, and privacy-preserving telemetry monitoring in NGNs. Future work will extend this assessment through emulated testbeds to quantify performance under real traffic and multi-domain orchestration conditions.

4.6. Oracle-Assisted Monitoring PoC

For oracle-assisted monitoring, the PoC adopts a decentralized, compute-enabled inbound oracle architecture, consistent with the prescriptive guidance derived from the four-dimensional oracle framework. Network telemetry (e.g., latency, packet loss, resource utilization) is collected from multiple monitoring agents and aggregated off-chain by oracle nodes.

Aggregated results are then committed on-chain as signed data, enabling tamper-resistant SLA verification and automated policy enforcement via smart contracts. This approach minimizes on-chain load while preserving auditability and integrity.

To complement the architectural design,

Table 10. Analytical feasibility summary for the minimal PoC.

Metric	Analytical Range	Notes
ZKP Generation	10–100 ms	Off-chain, asynchronous
ZKP Verification	<10 ms	Off-chain or Layer-2
Ledger Read/Write	10–100 ms	Permissioned blockchain configuration
Oracle Aggregation	Few ms	Off-chain computation
On-chain Oracle Commit	Tens of ms	Depends on update frequency

summarizes analytical performance envelopes derived from existing implementations and reported benchmarks. Oracle aggregation and on-chain commitment operations introduce limited overhead when off-chain reporting mechanisms are employed [46,47,48]. These values provide order-of-magnitude feasibility indications rather than precise performance measurements.

Because authentication and monitoring occur at the service interaction level rather than per packet, the resulting overhead remains compatible with NGN control-plane operational constraints.

The minimal PoC design demonstrates that the proposed DAA and oracle-assisted monitoring frameworks can be instantiated using current technologies while respecting NGN architectural assumptions. It validates architectural consistency, security assumptions, and deployment feasibility without requiring a full ZTN testbed or operator-scale infrastructure. Comprehensive experimental evaluation in multi-domain and large-scale environments is therefore identified as ongoing and future work.

5. Future Work

Although this study presents a comprehensive framework for integrating decentralized identity management and oracle mechanisms within Next Generation Networks (NGNs), several aspects require further research and practical validation.

For the Decentralized Identity Management (DIM) component, future work should focus on the practical implementation and testing of the proposed Decentralized Authentication and Authorization (DAA) mechanism in cross-domain environments. This includes investigating interoperability between heterogeneous blockchain platforms and evaluating the scalability and privacy implications of applying Zero-Knowledge Proof (ZKP) techniques in real-world Zero-Touch Network (ZTN) deployments. Moreover, extending the framework with threshold cryptography and multi-signature schemes could further enhance resilience against key compromise and improve fault tolerance in distributed identity ecosystems.

Regarding oracle integration, future research should aim to develop standardized interfaces and benchmarking methodologies for evaluating oracle mechanisms in NGNs. Despite the clear advantages of decentralized and compute-enabled oracles, their effective deployment is currently hindered by the absence of standardized APIs and robust pre-verification methods to ensure data integrity and interoperability before information reaches on-chain logic. Additionally, the lack of specialized benchmarking tools represents a major obstacle to their empirical evaluation. Existing tools, such as Hyperledger Caliper, provide limited support—mainly for EVM-compatible networks—and do not fully capture the performance and reliability dimensions critical to oracle-assisted monitoring in NGNs. Therefore, designing new, domain-specific testing frameworks capable of simulating multi-domain ZTN environments would be a significant step forward in this research area.

Finally, future work should also explore the integration of the proposed identity and oracle frameworks into AI-driven network orchestration workflows. By linking blockchain-based trust mechanisms with predictive analytics and autonomous decision-making modules, NGNs could achieve a higher degree of resilience, transparency, and self-management, ultimately advancing the realization of trustworthy and fully automated 6G infrastructures.

6. Conclusions

This paper presented an architectural and design framework for integrating decentralized authentication, Zero-Trust principles, ETSI ZSM, and oracle-assisted monitoring in Zero-Touch Networks. The focus of the contribution is not on protocol-level innovation or large-scale experimental validation, but on system integration, architectural consistency, and security-aware design across heterogeneous and multi-domain NGN environments. By explicitly addressing trust relationships, identity management, and automated monitoring within a unified architectural model, the proposed framework fills an important gap between theoretical security mechanisms and practical Zero-Touch network management.

More specifically, this paper examined the integration of blockchain technology into Next Generation Networks (NGNs) to address two fundamental security challenges: Service Identity and Data Integrity. First, we introduced a blockchain-based Decentralized Identity Management (DIM) framework aligned with Zero-Trust Architecture (ZTA) principles. Its core component, the Decentralized Authentication and Authorization (DAA) module, establishes a trustless authentication and authorization process among network services, enabling verifiable, privacy-preserving, and tamper-resistant interactions across domains.

To ensure data integrity and reliability, we investigated the role of blockchain oracles as a secure bridge between on-chain logic and real-world data. Building on a comparative analysis, we proposed a four-dimensional design framework—encompassing directionality, architecture, functionality, and application-specific optimization—to classify and evaluate oracle mechanisms in the context of NGNs. Complementing this framework, a set of NGN-specific performance metrics was introduced to assess oracle suitability based on latency, scalability, tamper resistance, fault tolerance, and operational cost. These metrics provide a foundation for more systematic benchmarking and performance evaluation in future deployments.

Overall, the proposed dual-framework approach demonstrates how blockchain-based identity management and oracle-assisted monitoring can collectively enhance the trustworthiness, autonomy, and resilience of Zero-Touch Networks, paving the way toward self-managed, transparent, and secure 6G infrastructures.