# Addressing ZSM Security Issues with Blockchain Technology
## 4 The Architecture of the Blockchain-Enabled ZSM Approach  
The proposed blockchain approach aims at increasing the security of the ZSM framework by addressing the aforementioned security issues and at the same time maintaining the complexity level low (as will be explained) using the blockchain technology and the benefits it inherently provides. Focusing on the scenario of E2E service deployment in a multi-domain environment and having in mind the architecture described in [34], we propose the introduction of blockchain technology in the cross-domain integration fabric component as it is depicted in Figure 2.  
In the presented approach, each NP is part of the ZSM framework and hosts a blockchain node that belongs to a _private permissioned blockchain network_ as depicted in the figure above. The private and permissioned characteristic of the network increases the security of this approach as we are able to control which NPs participate in the network and at the same time minimize the possibility of a malicious participant. This is also the approach adopted in [36] for Secure Routing for Multidomain SDN-Enabled IoT Network. The NPs are registered in the blockchain and obtain a unique address (IDs) used for their identification in the network. In addition, the ledger of the blockchain includes not only the IDs of the NPs but also the addresses of the Smart Contracts (SCs) deployed in the network. Both the E2E service management domain and the management domain of the ZSM participant create and execute _management functions, which are deployed in the form of SC in the blockchain network_. According to the ZSM standard, the development and execution of management functions are implemented using closed loops. Closed loops are based on AI/ML technology which uses mathematical models trained by secure datasets of the framework. It is worth mentioning that no AI/ML code runs inside the blockchain. It is _the decisions_ generated by the closed-loop mechanisms that _are registered in the blockchain_ so as  
Figure 2: The architecture of blockchain-based ZSM. to ensure the immutability and traceability of the decisions. Additionally, every change in the ZSM network in a cross-domain scenario, which in our case can be _the consumption_ of a management function, is considered a transaction and _is stored in the ledger_. The registration of an NP, the creation of an SC that utilizes a management function and the outcome of an SC are considered blockchain transactions and are permanently written in the ledger of the blockchain. Moreover, the blockchain interacts with other ZSM components using _oracle mechanisms to ensure that valid information is exchanged from and towards the blockchain_. Oracles in our case are software mechanisms developed to provide a secure interface between the blockchain network (including the SCs deployed in it) and ZSM services. To accomplish that, oracles use cryptography or/and consensus techniques applied on-chain or off-chain, to establish a secure connection between blockchain and other services outside of it. In the current research, oracles are used by the cross-domain integration fabric component as presented in Figure 2.  
Let us examine how the multi-domain scenario described in the previous section changes with the integration of blockchain technology. Assuming that NP1 has a request to support a demanding streaming application based on predefined network services. In this scenario, NP1 cannot support the application using its own resources and uses the ZSM framework to complete the request. Using the management services, NP1 finds another management service in a different domain that can fulfill the request. NP1 decides to consume the management service of the other provider (i.e., NP2) by executing a management function in the form of SC. An example of this SC is described in an abstract manner by the following pseudocode.