Securing SDN-Controlled IoT Networks Through Edge Blockchain

The Internet of Things (IoT) connected by software-defined networking (SDN) promises to bring great benefits to cyber–physical systems. However, the increased attack surface offered by the growing number of connected vulnerable devices and separation of SDN control and data planes could overturn the huge benefits of such a system. This article addresses the vulnerability of the trust relationship between the control and data planes. To meet this aim, we propose an edge computing-based Blockchain as a Service (BaaS), enabled by an external BaaS provider. The proposed solution provides verification of inserted flows through an efficient, edge-distributed, blockchain solution. We study two scenarios for the blockchain reward purpose: 1) information symmetry, in which the SDN operator has direct knowledge of the real effort spent by the BaaS provider and 2) information asymmetry, in which the BaaS provider controls the exposure of information regarding spent effort. The latter yields the so-called “moral hazard,” where the BaaS may claim higher than actual effort. We develop a novel mathematical model of the edge BaaS solution and propose an innovative algorithm of a fair reward scheme based on game theory that takes into account moral hazard. We evaluate the viability of our solution through analytical simulations. The results demonstrate the ability of the proposed algorithm to maximize the joint profits of the BaaS and SDN operator, i.e., maximizing the social welfare.


I. INTRODUCTION
T HE Internet of Things (IoT) finds many applications in both industrial and domestic spheres and promises to bring great benefits through increased connectivity to cyberphysical systems. However, as IoT systems generally lack computational power, the computation tasks are moved to edge computing systems such as multiaccess edge computing (MEC). A key component of modern flexible compute systems, such as MEC, is software-defined networking (SDN), which has generally been proposed for IoT architectures to deal with highly time-varying communication demands, prolong the lifetime of energy constraint devices, provide scalability, and improve flexibility. While SDN is an essential component of many edge systems, supporting IoT through flexible networking [1], [2], it also offers benefits in improving the security of networked systems. This has been demonstrated by the SerIoT project [3], which has proposed a fully integrated system that combines edge computing and SDN to address the security of IoT. However, although SDN can benefit security [4], it has also been noted that the SDN subsystem itself can be a target of attacks [5], [6]. The security issues in SDN are complex [5] to go into great detail here. However, in brief, the issues arrive from: a centralized SDN controller that implements highly complex software actions from the contents of network flows, leading to software actions too complex to test every outcome; implicit trust between the centralized controller and the edge switches; the switches are essentially dumb and simply implement the flow rules sent to them; and a controller who often acts in a reactive mode and sends flow rules for any new network flows that arise without necessarily holding historical immutable state of the rules. Thus, this article provides a solution to facilitate SDN security, i.e., ensuring flow rules are verified, at the edge, against network policies before being inserted into SDN switches; and, maintaining an independent, immutable, history of SDN flow insertion (which may be used by anomaly detection systems). This is an important addition to systems such as that proposed by SerIoT to ensure SDN security. In particular, our solution maximizes the joint satisfaction of the different blockchain stakeholders (i.e., the SDN operator and the blockchain provider). Evaluating the security performance is out of the scope of this article as security is directly related to the choice of the implemented policies and is left for future work.
To provide the security solution above, this article proposes a novel solution that carries out a separate flow verification/validation using blockchain technology. As it is vital that the flow verification occurs close to the edge switches, to reduce the opportunity of attacks [7], it is required that the blockchain technology is also implemented at the edge through a mechanism, such as MEC, to form an edge blockchain. Blockchain technology, a subconcept of distributed ledger technology, is essentially an append-only data structure maintained by a group of not-fully trusted nodes, which nevertheless provide a trusted data structure through a suitable consensus algorithm [8]. Furthermore, blockchain technology is decentralized, immutable, transparent, and reliable, which allows it to stand independently from the SDN network and the IoT network to establish a distributed trust mechanism. This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ The distributed nature of edge blockchain is ideally suited to support the security of the edge SDN systems [9] as it allows the flow verification to take place directly next to the edge switches while ensuring there is distributed consensus over the whole network.
To provide a straightforward deployment of blockchain, we utilize Blockchain as a Service (BaaS) [10]. We introduce blockchain agents (BCAs) that are collocated with SDN switches at the edge, and also in the core. The BCAs are responsible for flow verification/validation by running smart contracts. Flow verification requires a group of edge BCAs (e.g., in MEC) to act as a verifier initiator (VeIn) and verifiers. The verifiers inspect the new flow information, e.g., addresses, ports, and any other required fields against the policy. After flow verification, the verification result is sent back to the VeIn. Then, the flow validation process will be conducted. Flow validation requires BCAs to act as peers to validate the new flow in the block and update the flow ledger. Flow verification/validation in an SDN application needs computation capability to execute the encryption algorithm, consensus mechanism, and other smart contracts. As mentioned earlier, it is essential that the verification process takes place as close as possible to the edge SDN switches to minimize opportunities for malicious interference. Thus, the proposed architecture adopts compute in the edge (e.g., MEC) that is co-located with the SDN switches to host the BCAs. With lightweight IoT hubs, the use of this edge compute may be vital as edge blockchain is likely to be beyond the computational capabilities of many IoT devices and hubs. Thus, the edge-assisted BCA can provide advantages, such as promoting the scalability of the IoT networks with the number of IoT devices and reducing the communication overhead compared with cloud computing.
In the proposed architecture, BCAs run the SDN flow verification application as an external service. Meanwhile, there could be other applications from other parties running on the BCAs. This necessitates an incentive mechanism to stimulate the BCAs to perform the SDN flow verification. When a BCA initializes the flow verification procedure (i.e., it acts as a VeIn), it hires a group of BCAs as verifiers and offers them a reward. The verifiers know their computational ability, channel condition, workload, and the size of the task. Hence, the verifiers can decide how much reward they want. In this scenario, we realize that there is an information barrier between the verification initiator and verifiers. Specifically, a verification initiator can only decide the reward by the information provided by verifiers, however, the verifiers may not always be honest. In this article, we propose two reward schemes for: 1) an information-symmetric scenario (ISS), where the verifiers report their effort honestly and 2) an informationasymmetric scenario (IAS), where the verifiers hide their effort but reveal part of their information. In IAS, the verifier may behave greedily and demand a higher price for a simple task by revealing a high performance or else they will not implement the task. This phenomenon is known as the "moral hazard" of the verifiers [11]. The underlying reason for the moral hazard is the asymmetric relationship about system information: a verifier has access to more information to make a decision than a VeIn. In this work, game theory and contract theory are used to solve this problem. To the best of our knowledge, our work is the first to propose the workflow of flow rule verification/validation in blockchain-aided SDN (BC-SDN), to do so using edge computation and also to use contract theory to study the quantified performance of blockchain in the considered use case.
The main contributions of this article are summarized as follows.
1) We propose the architecture of edge blockchain-assisted SDN (BC-SDN) for flow conformance in an IoT system. Edge-blockchain helps maintain a distributed, immutable flow ledger for SDN. 2) We design the workflow of flow verification and subsequent validation for the SDN IoT system with the assistance of edge blockchain. 3) We devise fair reward schemes based on informationsymmetric and information-asymmetric scenarios to stimulate the performance of BCAs on edge servers. Moreover, we compare the information symmetric and asymmetric cases in the proposed reward scheme using numerical simulations. Although there is a clear need for security mechanisms in SDN, as we propose, in this article, we concentrate on the edge-blockchain mechanism itself, as this is the fundamental mechanism that is required before its benefits can be deployed. Thus, now we briefly elucidate the benefits of our architecture and its intended uses. The major benefit of the mechanism described is that it provides a security framework that is completely separate from the complex SDN controller process and thus provides prevention of malicious behavior that may occur in the SDN subsystem and verifiable security auditing of SDN. By using a smart contract for flow verification, it allows verifiable, independent, code to be developed so that the safety of the flow insertion can be ensured. A smart contract also provides a development environment that allows a deployer of the technology to select a wide range of flow verification policies, for example, a simple case of checking addresses of connected devices through to complex verification of end-toend paths for specific flows. By using the immutable ledger facility of the blockchain inserted flows, it can be audited in the knowledge they cannot be changed or tested for anomalies using machine-learning approaches.
The remainder of this article is organized as follows. We first review related literature in Section II. Then, in Section III, we introduce the proposed architecture and workflow of BC-SDN. Next, we provide the considered system model in Section IV. We then formulate the problem and present our solution for both the ISS and IAS in Section V. Our solution is evaluated extensively in Section VI to get an understanding of the influence of the various system parameters. We also compare the performance of our solutions against other state-of-theart methods, and the results show the advantages of using the proposed method. Finally, we draw conclusions in Section VII.

II. RELATED WORKS
Blockchain is a disruptive technology that has been used in many scenarios in real life, i.e., governance [12], healthcare [13], smart grid [14], and so on. In this article, we review the related works on blockchain-based SDN, edge computingassisted blockchain, and the pricing scheme of blockchain.

A. SDN Using Blockchain Technology
Blockchain technology uses a group of not-fully trusted nodes, which nevertheless provide a trusted data structure through a suitable consensus algorithm. Thus, it is commonly used as a solution for security challenges in IoT and SDN. In [15], an SDN-based decentralized security architecture using blockchain technology for the IoT ecosystem is presented. This work aims to mitigate the recent challenges and detect attacks more efficiently. It adopts the blockchain technology to dynamically update the attack detection model and reward the fog nodes according to the "Proof of Work." Boukria et al. [16] proposed a blockchain-based controller against false flow rule injection, focusing mainly on the SDN controller authentication. Yazdinejad et al. [17] introduced a novel authentication handover based on blockchain in the SDN-based 5G network with the aim to remove unnecessary reauthentication in repeated handover among heterogeneous cells in 5G. Qiu et al. [18] studied the scenario of industrial IoT with multiple SDN controllers. A blockchain-based consensus protocol is presented to collect and synchronize network-wide views among different SDN controllers. This work employs the Q-learning method to jointly optimize the view change, access selection, and computational resources.

B. Blockchain and Edge Computing
Blockchain technology is computationally intensive during the consensus mechanism and ledger updating procedure. Therefore, typically there is a need to offload these, relatively, computationally heavy tasks to edge devices [19], [20]. Task offloading is not new and has been researched since more than a decade ago [21]. Wang et al. [22] presented MEC in the form of mobile cloud and combined it with cloud radio access networks (C-RANs) with a particular focus on joint resource allocation across computation and communication domains. Hu et al. [23] further introduced wireless power transfer into MEC to battle the energy supply issue of batterypowered IoT devices. A blockchain-based distributed cloud architecture has been proposed in [24]- [26], with fog nodes at the edge providing the functionality of the SDN controller. This work introduces a hierarchy with a central blockchainbased cloud moving toward a blockchain-based edge, with the latter taking responsibility for updating the flow rules. Although these studies show how cloud/fog computing would support blockchain, the presented solution neglects the issue of flow conformance testing that we address in this article. The work in [27] proposes a Trust List that represents the distribution of trust among IoT related stakeholders and provides autonomous enforcement of IoT traffic management at the edge networks by integrating blockchains and SDN. Ethereum is used to store the information of the controller on the edge computing servers, which lead to severe delays. In [28], an optimal pricing-based edge computing resource management is presented. This solution can support blockchain applications, where the mining process can be offloaded to an edge computing server provider (ESP). The authors adopted a twostage Stackelberg game to maximize the utility of ESPs and miners.
Edge computing not only relieves the computational demand of blockchain technology but can also resolve security issues with the edge systems. First, using blockchain, it is possible to build a distributed control mechanism over all the edge systems [29]. Second, blockchain maintains data consistency in every edge node through its consensus mechanism; for example, Yang et al. [30] proposed a smart edge computing oriented data exchange prototype using Hyperledger to solve the issue of data automatically maintaining. Last but not least, blockchain enables dynamic resource allocation among edge nodes [31].

C. BaaS Reward Scheme
Due to the fact that blockchain technology is a resourceconsuming application, studies concentrate on optimization problems that consider various aspects, such as: the latency, throughput of transactions, finality, security, and decentralization [32]. A survey covering the use of contract theory in wireless networks is presented by Zhang et al. [33]. This article reviews works that focus on the design of incentive mechanisms in wireless networks to ensure participants from the third party, such as access point, small cells, and users execute tasks with a proper reward. In [34], blockchain-based block verification is used in an Internetof-Vehicles (IoV) setting. This article considered verification latency, verifiers' reputation, and network scale to construct the contract between the block manager and the verifiers. Differently, multidimensional contract theory in mobile crowdsourcing is studied in [35]. This article designed an incentive mechanism for mobile crowdsourcing by considering participants' effort, performance, and reward. The work in [36] proposed a directed acyclic graph (DAG)-based vehicle-tovehicle communication network to solve the limited scalability and improve blockchain's efficiency. This article also proposed a game-theoretic solution to optimize bandwidth allocation and information transmission. However, it did not provide any incentive to conduct the DAG service.
However, these solutions fail to exploit blockchain technology in a manner that is compatible with existing SDN architectures. Specifically, they do not consider how to verify a new flow using blockchain in a fine-grained manner; nor, how to enable blockchain technology without changing the foundation of SDN. Additionally, they do not take into account how to secure the communication between the SDN controller(s) and switches; nor do they consider how to use blockchain as a service that needs a pricing scheme for the business model used in practice. This article aims at solving these problems by introducing our novel solution of BC-SDN. We achieve this by designing a flow verification/validation workflow that uses smart contracts. We design two reward schemes for ISS and IAS scenarios, analyze these schemes mathematically, and evaluate them through simulations.

A. Architecture of BC-SDN
We consider an architecture in which blockchain capabilities can be offered as a service, termed BaaS to multiple customers. The architecture consists of a traditional SDN network, complemented by edge computing [37] to facilitate communication and provide applications in a generic IoT scenario. In this scenario, IoT devices are attached to edge computing systems and communicate with each other through an SDN-based network [3]. The edge computing provides virtual resources to a set of applications; one of which is a blockchain overlay, which provides blockchain services to customers both inside and outside the network. We assume the SDN operator to be one such customer, which purchases the service of the blockchain overlay to perform flow verification/validation between the control and forwarding counterparts. Fig. 1 shows an architectural view of the entities in our BC-SDN proposition, which includes the following.
1) IoT devices that interact with end-user environment and exchange data to influence said environment. 2) IoT hubs that connect the IoT devices to edge nodes through SDN switches. 3) SDN switches that detect new flows and execute a forwarding plan calculated by the SDN controller(s). 4) Blockchain agents are software components (i.e., servers) provided by a blockchain service provider utilizing edge computing. BCAs are in charge of flow verification and validation via smart contracts. Furthermore, BCAs also execute basic blockchain functions, such as the consensus process, sending transactions, and maintaining the flow ledger. We consider that one or more BCAs are located in the edge servers for each SDN switch to provide computation ability. For simplicity and without loss of generality, hereafter, we assume there is only one BCA associated with each SDN switch. 5) Edge nodes are a selection of edge computing nodes connected through the SDN infrastructure. They provide computation and storage capabilities to the blockchain service, among others. Similar to IoT hubs, edge nodes are connected by the SDN infrastructure. Notably, in a generic scenario, the distribution of edge nodes could be different from that of the SDN switches; however, to simplify our work, we assume that one edge node is collocated with each SDN switch. To remove the effect of network-related latency, we assume that a BCA running on an edge node serves the switch collocated with that node. 6) SDN controller has the global view of the network and is able to calculate optimized paths in the network according to predefined objectives and policies. In practice, multiple SDN controllers are likely to be used for reliability and scalability. This does not change the solution or architecture in any way as the BCA is colocated with a switch and, in the same manner as a switch, a BCA would be configured to operate with a load-balanced controller group that sees multiple controllers as a single, virtual, controller. We note that as with the existing SDN controller and switch interconnections [5], we assume that the controller-to-BCA and BCA-to-switch connections are protected using transport layer security (TLS). This provides basic support against malicious interventions in the control plane channels and is an important security step. However, it should be pointed out that TLS in the control plane does not provide the independent policy conformance testing that is provided by the solution presented in this article, which protects against much wider malicious activity against the SDN system. For example, malicious behavior through the manipulation of the controller or wider attempts at the injection of data plane traffic that goes against wider site policy necessitates a solution such as that presented here. Additionally, the immutable storage of the flow rules (and their changes) in the blockchain ledger allows security analysis of the behavior of SDN. This ledger can be accessed through a role-based approach so that, for example, users of the network can confirm that their relevant rules have been accepted, but without having wider access to sensitive information, while a network operator may have a full view of the rules for wider security analysis.
In this article, we adopt a permission-based consortium blockchain, such as Hyperledger [38], which means that only authorized BCAs can conduct blockchain functions. Furthermore, we adopt a BaaS infrastructure with a BCA collocated with an SDN switch. There are three main advantages of using the proposed mechanism for flow verification/validation. First, as BCAs are collocated with the SDN switches, providing a blockchain service to the SDN, the BCAs can assist with the secure communication between the controller and the corresponding switch. Second, BCAs are components provided by an external entity, which conducts flow verification/validation outside the SDN network to guarantee connection privacy. Finally, BaaS enables a straightforward deployment of blockchain in SDN without the SDN operator needing to create their own blockchain system.

B. Smart Contracts and Workflow of BC-SDN
In BC-SDN, the workflow includes flow verification and flow validation. We show these two parts in Figs   flow ledger updating. In Hyperledger, verification is performed by a leading verifier and the following verifiers. Validation is performed by a leading peer, namely, the orderer and the following peers. In BC-SDN, VeIn acts as the leading verifier and orderer. There is a group of BCAs that act as verifiers and peers in verification and validation, respectively. In this work, we adopt Hyperledger as edge blockchain and the Byzantine consensus mechanism [39]. First, we assume the following.
1) This blockchain application is using a unique Hyperledger channel. To allow multiple applications to use Hyperledger at the same time, each application is allocated a unique channel with an individual channel ID. In BC-SDN, it only has one SDN flow verification/validation application. 2) The IoT devices/IoT hubs that require new flow rules have been registered and enrolled with the organization's Certificate Authority and received back necessary cryptographic material, which is used to authenticate the device.
3) The BCAs have been fed with previous topology and connectivity information from the controller. Moreover, all the BCAs apply the same flow conformance policy to check the new flow rules. The conformance policy is defined as the simple policy, i.e., it verifies the source and destination IP addresses and the port numbers. 4) The controller is responsible for path calculations, which will result in a set of flow rules according to the path.

1) Smart Contracts in Edge Blockchain:
We define a group of smart contracts to conduct flow verification/validation on edge blockchain. First, we have verification initiation contract and validation initiation contract to start the preparation of new flow verification/validation by obtaining the key information of the flow, essential encrypted materiel, and so on. Then, edge blockchain deploys verification contract to inspect the signature of the verifiers, conduct flow conformance policy, and construct response messages to peer verifiers. Last but not least, we have the Byzantine consensus mechanism deployed as consensus contract when the response is checked among all the peers in the verification/validation phase.
2) Flow Verification: In the traditional SDN architecture, when IoT devices initiate a new communication request, the corresponding access switch sends the new packet with source/destination IP, source/destination port ID, and protocol to the controller. It requires the controller with the global view of the network to calculate the path. In BC-SDN, the flow verification process initiates after the SDN controller sends the flow rule back with verification initiation contract. Instead of sending the flow rule back to the switch, the SDN controller sends it to the corresponding BCA of the switch. Then, the BCA VeIn will start flow verification by running a verification initiation contract. This contract requires preparing the proposal and sending it to the other BCAs, namely, verifiers. Here, the VeIn adopts a preset endorsement policy to employ the verifier. The endorsement policy [38] requires that the VeIn must obtain the inspection feedback of the new flow rule from a certain number of verifiers, otherwise, the endorsement is considered as failed. The endorsement policy is crucial to justify if the Byzantine consensus mechanism is reached. The actions of establishing and verifying/validating a new flow rule are embedded in consensus contract within the blockchain. Below, we explain these actions in more depth.
1) An IoT device causes an SDN switch to initiate a new flow establishment request when it sends a packet with source IP/port information, destination IP/port information, and flow conformance policy. The message is formed as packet = <souIP, desIP, souPort, desPort, Policy> without an existing flow rule, and this is sent to the controller over a secure communication channel. 2) When all the BCAs receive the proposal, the leader selection procedure is triggered. We assume that VeIn is the leader of the flow ledger updating. VeIn sends a message deliver(seqno, prevhash, endorsement), where seqno is the sequence number and prevhash is the hash of the most recently delivered endorsement. VeIn orders all the flow rules chronologically and creates blocks of flow rules.
3) The blocks of flow rules are delivered to all BCAs. The consensus contract is executed by all the BCAs as it is in the verification consensus mechanism. a) The BCAs verify the ID of consensus contract, endorsement policy, and consistency of the status database to avoid violations. They wait until all the peer BCAs' feedback to reach consensus. b) If the checks pass, the flow rule is deemed valid or committed. In this case, the BCAs set the bitmask of the flow Ledger. c) If the checks fail, the new flow establishment is considered invalid and the BCA unsets the bitmask of the flow Ledger. This invalid flow rule is still stored until it is deleted by a periodic blockchain function. Up to this point, flow verification/validation is completed.

IV. SYSTEM MODEL
We use BaaS in BC-SDN, as described in Section III, the BaaS is running over virtual resources rented from the edge computing provider, independently from the SDN network. The BaaS provides services to multiple organizations, one of which is the SDN network. This means that the VeIn may lack knowledge of the edge servers' performance (and other abilities). Thus, there is an information barrier between VeIn and BaaS. In this article, we assume two scenarios, namely, an ISS and an IAS. IAS leads to what is known as a moral hazard [40]. The moral hazard is commonly solved by contract theory in the field of economics. Motivated by the above, in this article, we design two reward schemes for BaaS, which can relieve the difficulty of the information barrier between VeIn and the third-party BCAs.
In BC-SDN, flow verification/validation is provided by BCAs and a contract is designed based on the outcome of the verifiers. We consider N verifiers. Each verifier offers n different execution latencies according to the reward, workload, CPU capability, and so on. The set of possible latency values for flow verification and validation is denoted as L = {l 1 , . . . , l n }, l i ∈ L and the set of blocksizes as S = {s 1 , . . . , s n }, s i ∈ S with elements in S and L having one to one correspondence. When a flow verification process is initiated, the VeIn presents a contract for the verifiers offering a reward. Then, the verifiers have the option to either accept the reward or reject it. According to the reward, the verifiers exert the flow verification/validation latency. During this procedure, the verifier has to report its latency of execution to the VeIn. We represent the honesty factor of a verifier by h i ∈ H, where H = {h 1 , . . . , h n } is the set of honesty factors. The honesty factor indicates the level of honesty of a verifier when it reports its performance to the VeIn. In this work, we propose two reward mechanisms for the two scenarios studied here, ISS and IAS. Let t be the reward mechanism indicator, where t ∈ {t 1 , t 2 }. When t = t 1 , we consider ISS, and vice versa. In ISS, VeIn can observe the effort, namely, the blocksize s i , to make a decision regarding the reward. Thus, we consider the reward mechanism as contract C t 1 (r i , s i ), where r i is the reward of the ith verifier. In IAS, BCAs hide their true effort blocksize s i , so VeIn can only make a decision of the reward by the latency l i of BCAs. Thus, the contract is defined as C t 2 (r i , s i ), with t = t 2 indicating IAS contract.
In this section, we first introduce the system model by analyzing the cost and income of the VeIn and verifiers. Then, we define the employed utility functions of both the VeIn and verifiers. Finally, we propose our solution based on contract theory. Note we list the notations and descriptions in Table I.

A. Execution Cost of the Verifier
Consider verifiers who participate in BC-SDN and make a choice of flow verification/validation latency. However, the latency may not just be the consequence of the block it actually processes but may also be influenced by other tasks that the verifiers choose to carry out. However, generally, we can say that the execution cost of the verifier is related to the blocksize. Similar to [19], the execution cost of a verifier is defined in a quadratic form, which is thus convex and provides a straightforward evaluation of the derivative. When verifiers create a blocksize s i , the execution cost of the verifier is where α > 0 is the cost factor for the verifiers. The cost function shows that there exists an optimal blocksize, which could lead to the optimal cost.

B. Reward Plan for Verifier
We consider the set of rewards R = {r 1 , . . . , r n }, r i ∈ R. We assume that verifiers with the same honesty factor have the same reward. Thus, we define the reward to verifiers with honesty factor h i as where χ i (·) is a function of verifiers with honesty factor h i 's performance. The reward plan for verifiers in both scenarios should respect the following: the bigger the honesty factor is, the bigger the reward is. Moreover, for ISS, the bigger the blocksize is, the bigger the reward is. On the contrary, for IAS, the bigger the latency is, the smaller the reward is. Therefore, the following conditions should hold when designing the reward function:

C. Income of VeIn
The income of VeIn depends on the contribution of the verifiers, i.e., the blocksize s i and the honesty factor h i for ISS and the latency l i of flow verification/validation and the honesty factor h i of the verifier for IAS. The income function of VeIn I i in terms of verifiers with honesty factor h i , blocksize s i , and latency l i is given by where τ 1 > 0 and τ 2 > 0 are the weighting of honesty and the weighting of latency, respectively. The parameter l max is the maximum latency.
We should have (∂f (h i )/∂h i ) > 0, (∂g(l i , l max )/∂l i ) > 0, (∂I i /∂h i ) > 0, and (∂I i /∂l i ) < 0. This means that the bigger is the honesty factor, the higher is the income. It also means that larger latency leads to lower income. To simplify the problem, we define the income function as (3)

V. PROBLEM FORMULATION
In this section, we analyze the ISS and IAS scenarios in detail. In ISS, the VeIn is informed by the verifiers about their efforts of executing a verification/validation task with respect to their honesty factor. Therefore, in ISS, the VeIn can optimize the reward according to the efforts of verifiers.
We also investigate IAS, which suffers a moral hazard. Since in IAS, the VeIn does not have full knowledge of the verifiers, it can only be informed from their performance, i.e., the execution latency of the verifiers. Thus, the IAS scenario leads to a more complex problem to solve than the ISS scenario. The rest of this section studies ISS and IAS scenarios in Sections V-A and V-B, respectively.

A. Information Symmetric Scenario
In ISS, we assume that verifier i will report the actual effort, i.e., the blocksize s i considering a honesty factor h i . The honesty of the verifier affects the income of the VeIn. We define the utility function of the verifier as the income of the verifier i minus the execution cost (1). Hence, it is where the income of the verifier i is proportional to the blocksize s i . We also formulate the utility function of VeIn as where β > 0 is the VeIn's income factor. We can then propose a two stage optimization method. In the first stage, the verifier considers the reward r i from VeIn as known and computes the optimal blocksize s i . In the second stage, the verification initiator uses the optimal blocksize s i * and solves a second optimization problem to compute the optimal reward r i * . This formulation falls to the category of Stackelberg games, which also means that Stackelberg game is information symmetric between the VeIn and the verifiers.
Definition 1 (Stackelberg Equilibrium): The system reaches the Stackelberg equilibrium, if and only if the verifiers and the verification initiator reach the relationship described by the following equations: Following the Stackelberg equilibrium, we use the backward induction algorithm [41] to determine the equilibria of the subgames (6) first. The maximization problem for verifier i is defined as where s max stands for the maximum blocksize. To calculate the optimal blocksize, we set the first derivative of the maximization problem in (8a) to zero. Hence, we obtain By solving this equation, we can determine the optimal blocksize s i * = (r i /α). We then substitute s i * in the utility function of the VeIn and solve the second stage of the optimization problem so that it respects (7) max Following the same method with the first stage, we can obtain the optimal reward by finding the derivative of the objective function with respect to the reward and setting it equal to zero Therefore, we can calculate the optimal reward and the blocksize by the following equations: We can observe from (10) and (11) that the honesty factor h i is proportional to both the reward and the blocksize.

B. Information Asymmetric Scenario
In this scenario, the VeIn considers the honesty and latency of the verifiers provide. Therefore, according to the income of VeIn in (3), we define the utility function of VeIn as the gross income minus the reward plan w to the verifier. Due to the uncertainty of the verifiers' behavior, we define that verifiers with honesty factor h i choose latency l i with probability p i . We denote the discrete set of probabilities P = {p 1 , . . . , p n }, with n i=1 p i = 1, where p i ∈ P is the probability the verifier to choose a blocksize s i ∈ S that results to a latency l i . Similar to the ISS case, the utility of the verifier is defined as the reward plan minus the execution cost. Meanwhile, we assume that verifiers who choose the same latency l i have the same honesty factor. Thus, the verifier's utility is defined as Let us assume that the total number of verifiers is N. The VeIn's utility function is given by recall β is the income factor of the VeIn. For IAS, the optimization problem is defined as where σ is reservation utility, which is the minimum profit that must be guaranteed by the contract to make it acceptable to the verifiers. Note that without loss of generality, we set σ = 0 to simplify the problem. Equation (14b) is the individual compatibility (IC) for verifiers, which means that by exerting the optimal blocksize, it can obtain the optimal reward. Equation (14c) is the individual rational (IR) that requires the utility of the verifier is positive. For the sake of simplicity of representation, we omit the arguments of χ(·) function when they do not affect the calculations. Lemma 1 (Monotonicity): If we have for the income function χ i ≥ χ j , ∀i, j ∈ {1, . . . , n}, the reward satisfies r i ≥ r j .

Definition 2 (Local Upward and Downward Constraints):
If verifiers with χ i prefer contract (r i , l i ) to (r i+1 , l i+1 ), then the local upward constraint for χ i is satisfied, as shown in (22). Similarly, if verifiers with χ i prefer contract (r i , l i ) to (r i−1 , l i−1 ), then the local downward constraint for χ i is satisfied, as shown in (21).
Lemma 3: Local downward compatibility is reached as follows: Proof: We assume that χ i−1 < χ i < χ i+1 , then according to the IC constraint, we have According to Lemma 1, we have By combining (25) and (26), we get Then, by combining (24) and (27), we find that Finally, by expanding (28), we get which completes the proof.
Lemma 4: Upward local incentive is satisfied in the proposed problem as follows: Proof: We can prove Lemma 4 in the same way as Lemma 3.
In the optimization problem (14), constraint (14b) includes n(n − 1)/2 upward local incentive and n(n − 1)/2 downward local incentive conditions. Additionally, constraint (14c) consists n IR constraints. By applying the lemmas we proved previously, we can reduce the constraints as follows.
We know that in order to maximize the utility of VeIn, we need to provide the minimum reward to verifiers, which leads to the minimum utility of the verifier in (14c) as r 1 χ 1 − (1/2)αs 2 1 = 0. Therefore, (14c) can be reduced. Moreover, for (14b), if rewards r i and r i−1 lower the utility value by the same amount and the downward local incentive still holds, then eventually it can reach r i Since monotonicity holds, when χ i ≥ χ i−1 , it is also r i ≥ r i−1 , so we have By adding (31) and (32), we derive By observing (33), we note that it is the same as Lemma 4. Thus, constraint in (14b) can be reduced as (31). Therefore, we can propose the new optimization problem as follows: By solving (34c), we can obtain Then, by solving recursively (34b), we can find As blocksize and latency have a linear relation, we can substitute blocksize with latency without losing optimality Let us define Then, we can substitute r i in (34a) and the objective function becomes We can calculate the derivatives of the utility function in (37) with respect to l i as follows: From (38), we can see that (∂U t 2 v 2 /∂l i 2 ) < 0, thus the objective function/ utility function of VeIn is concave. Furthermore, as the constraints are all affine, the optimal value of latency l i and reward r i can be computed using an optimization solver such as CVX [42]. We would like to note that by using the proposed scheme, the verifiers can be stimulated by the reward and conduct the flow verification/validation.

VI. EXPERIMENTAL EVALUATION
In this section, we numerically evaluate the performance of the proposed reward schemes in BC-SDN. We consider that BCAs work as both verifiers and validators in the proposed architecture. In the following, we first introduce the benchmark solutions. Then, we evaluate the performance of the proposed reward schemes with respect to the cost factor of verifiers α, the income factor of VeIn β, the number of verifiers N, and the probability p of blocklength selection which is proportional to latency. In the simulation set up, we consider a group of verifiers and different numbers of χ values, in which χ i stands for the combination of latency l i and honesty factor h i . The key parameters used in the evaluation are listed in Table II. In the simulations, we consider these values unless otherwise stated.
To evaluate the performance of the proposed reward scheme, we introduce the concept of "social welfare" ω of the BaaS service and defined as the profit of the verifiers and VeIn. Thus, the social welfare is Social welfare is a rational way to analyze if the contract can maximize the total utilities, where the utility indicates the preference of VeIn and the verifiers choosing and consuming the contracts and resources, respectively, which leaves utility without unit. Social welfare also indicates the BCAs' resource utilization of the edge. For the sake of comparison, we compare the proposed reward scheme with a solution based on the Stackelberg game. We examine the ISS scenario described in Section V-A, where VeIn knows the true effort s i of the verifiers. We also investigate the IAS scenario, as discussed in Section V-B, where the VeIn is only aware of the performance, namely, latency l i , of the verifier. Our evaluations attempt to capture the impact of honesty on the derived solutions. Specifically, the ISS scenario can be seen as a special subcase of the IAS scenario, whereas in ISS, VeIn and the verifiers share the same information while deciding the optimal blocksize, for example. Finally, we also compare our scheme against the fixed reward scheme proposed in [43].

1) Utility of VeIn With Respect to the Honesty Factor:
We evaluate the utility of VeIn with respect to the honesty factor h i . We assume ten verifiers (i.e., N = 10) with four values of honesty factors, i.e., h 1 , h 3 , h 4 , h 6 ∈ H as defined in Table II. From Fig. 4, we can note that the utility of VeIn reaches its maximum when the corresponding contract is obtained, i.e., when h 4 with contract C t 2 (r 4 , l 4 ) can allow the utility to be the maximum. Note that, in practice, we actually consider χ i , which is a combination of both latency l i and honesty h i , for convenience here we have considered the case where h 1 < h 3 < h 4 < h 6 . This result verifies IC in (14b), i.e., for verifiers with χ i , there is one, and only one, optimum contract item.
2) IAS's Social Welfare With Respect to β: We examine the social welfare of IAS with respect to the VeIn's income factor β. In Fig. 5, we consider different numbers of latency and honesty factors' combinations. From this evaluation, we can observe that with increasing income factor β, social welfare also increases. Second, we note that when the number n of combinations increases, the social welfare decreases. This is due to the fact that increasing the number of combinations, n, adds uncertainty to the system, which leads to a higher cost of VeIn, and causes social welfare degradation.
3) Impact of α to the Social Welfare: In Fig. 6, we compare the social welfare of the proposed IAS, ISS, and fixed salary scheme with respect to the cost factor α. We simulate IAS with two kinds of combination χ and four kinds of combination χ . Note that parameter n means that the verifiers have n different probabilities to choose from these combinations. From the simulation results, we can see that as α increases, the social welfare decreases. The reason for this behavior is that the larger the cost factor is, the larger the cost of the verifier is, which means that it is going to cost more to maintain the same blocksize. However, the IAS achieves higher social welfare when α is about 1.3. This is due to the fact that in IAS, the verifiers can choose a smaller blocksize to compensate the execution cost in order to maintain social welfare.

4) Impact of the Number of Verifiers to the Social Welfare:
We also analyze the social welfare of ISS, and IAS with respect to the number of verifiers N. The results are illustrated in Fig. 7. We consider verifiers have honesty factor h 6 and latency l 6 , and have different numbers of verifiers for ISS and IAS. We apply the setting of three different combinations of χ , i.e., χ 5 , χ 6 , and χ 7 . As we can observe from the figure, the social welfare increases when the number of verifiers increases. Note that the least social welfare is observed for IAS. This is attributed to the fact that VeIn has no knowledge of the verifiers' real effort in executing the application. From this, we can conclude that the IAS costs more than the ISS to the VeIn. 5) Impact of the Probability Distributions of Latency to the Utility of VeIn: In Fig. 8, we investigate the impact   Fig. 8, the Gaussian distribution achieves the maximum utility for χ 5 setting. In addition, we evaluate (Fig. 9) the utility of VeIn with respect to the number of verifiers for the considered probability distributions. We consider a range of verifiers [10,14], corresponding to the deployment in a regional edge network. As we can observe from Fig. 9, the utility of VeIn increases for all distributions when the number of verifiers increases. This comparison also shows that the proposed reward scheme can cope with different scenarios in a real-world situation. In this setting, the discrete Gaussian distribution achieves the highest utility among three distributions, followed by the uniform distribution and the affine distribution. The reason for this is that the utility of VeIn increases  when the combination χ 's index i increases, which is also the case of monotonicity in Lemma 1.

6) Edge-Blockchain Performance in Terms of Blocksize:
We analyze the edge-blockchain performance by considering the blocksize in the ISS and IAS scenarios in Fig. 10 with a fixed reward budget. Blocksize can represent the flow conformance task volume on the edge servers. For ISS, from (11), we know that in ISS, the optimal blocksize only relates to the reward. When more verifiers join the verification, the reward to each individual decreases, which leads to a decrease of blocksize. For IAS, we assume five combinations of χ with a limited reward budget. We observe that when the number of verifiers increases, the average blocksize in both scenarios decreases due to fixed reward. Limited reward budget leads to verifiers choosing different contracts. We also add a range indicator to the IAS case to show the biggest and largest blocksizes (the blocksize does not change in the ISS case). The smallest IAS blocksize is always the same as there are only five contracts  Evolution of reward scheme with respect to number of χ 's combinations.
to choose from. When there are 14 verifiers, they can only choose between two contracts due to the limited reward budget. We also observe that the ISS often has larger blocksizes than the IAS, particularly as the number of verifiers increases (with a constrained budget). 7) Impact of the Number of Combinations χ in Terms of Latency: Finally, we investigate the complexity of the proposed IAS with respect to the number of the combinations of latency l i and honesty h i factor values, i.e., χ i . We should emphasize that here we are interested in the relationship of the computational complexity to the size of the problem rather than the absolute runtimes. We leave the design of a fast heuristic to future work. To investigate this relationship, we use CVX [42] to solve the proposed optimization problem shown in (14b). The results are depicted in Fig. 11. From this comparison, we can see that the proposed reward scheme is bounded by the number of χ i 's combinations and that the execution latency grows only linearly with the number of χ combinations. Furthermore, this comparison makes clear that the computational complexity of the solution will not be high.

VII. CONCLUSION
In this article, we have investigated a novel security solution for SDN supported by edge blockchain, which interconnects IoT networks. We proposed an architecture for blockchainbased software-defined networks. Then, we suggested the workflow of the flow verification and validation according to the architecture of BC-SDN. To support blockchain technology, we deployed BCAs with edge computing servers to reduce the computational burden on the IoT systems. Owing to the fact that we use BaaS, we have designed two reward schemes for ISS and IAS to tackle the potential moral hazard caused by BCAs hosted by a third-party edge computing provider. By using the proposed reward scheme based on contract theory, we can determine the optimal blocksize and latency of the blockchain and the corresponding reward value. Finally, we evaluated our system to demonstrate the impact of different parameters using two different incentive mechanisms. The results showed that the proposed reward scheme can achieve good social welfare. For our future work, we will consider how different flow conformance policies can be implemented within a smart contract.