Function Virtualization Can Play a Great Role in Blockchain Consensus

Bitcoin introduced a cryptocurrency as a form of public ledger consequently that turned into a most popular security technology, Blockchain. Its integrated mining technology lies the key security mechanism. The system allows forming a pool mining group to solve a particular job and share their revenues to their CPU usage while one of them successfully mines a block. To mine a block, a cryptographic puzzle should be solved, which requires significant compute resources that cause huge energy consumption. On the other hand, recent statistics show that low computational energy-restricted Internet of Things (IoT) devices are increasing exponentially. Although it has low energy and limited computation power, it is large in quantity when it is integrated. So we focus on a stochastic geometry theory, which resolves the issue of block mining computation via utilizing multiple mobile IoT devices, given that these IoT devices are Computation Capable Nodes (CCNs). To further normalize this issue, we propose an efficient mathematical solution that uses smart coordination of Virtual Network Functions (VNFs) for IoT devices to enable their CPU usage efficiently. At the same time, the work and credit point distribution policy is smartly handled through virtual pool mining. The proposal renders Network Function Virtualization technology to configure VNF, and Service Function Chain technology is utilized to enable the network flow of such VNFs. New algorithms are presented to solve multiple issues like node discovery, computation offloading, and work credit point distribution. Our goal is to minimize energy consumption within the given time constraint. Implementation results show that although virtual functions for block mining require extensive computations in IoT devices, dividing computation work into small fractions called tasks embedded with VNF, and offloading them to nearby CCNs, tend to minimize the cost and energy consumption of individual shared miners. The overall mining process is proved efficient and faster.

thousand cryptocurrencies [2] are present in the market after the revolution of the Bitcoin economy. Due to the public nature and scalability of public blockchain (i.e., cryptocurrency ), recent technology has gone beyond cryptocurrency, also called distributed private BC. It has various application domains, such as IoT, E-healthcare, education, banking, etc.
Although the nature of BC varies in different use cases, there remain some standard features like a consensus, distributed ledger, etc. Every BC is primarily different based upon their nature and core technical features of consensus algorithms whose ultimate goal is to improve TPS without compromising security. Figure 1 refers to comparisons of different types of BC concerning TPS. The blue, green, and yellow bar denotes the official release of TPS, tested average TPS, and tested peak TPS, respectively. This indicates a contradiction in the Quality of Service (QoS) assured for users.
In a BC network, a block is added to the ledger in every certain time interval (e.g., 10min/block in bitcoin) against valid PoW [3]. A valid PoW is an integral part of a cryptocurrency network that solves some cryptography problem (i.e., mathematical puzzle). As a result, it allows a block of pending transactions to be added to the BC (i.e., records of all transactions ever). The integral part must be trivial to verify whether data satisfies the said requirements, e.g., difficulty value must start with a certain number of zeros to make the puzzle complex and resource-intensive for miners called hashing. Every round, a new hash is generated from the incremented nonce. This process assures that the number of blocks found each day remains steady, and more computing power is needed to mine the next block. It indicates that it is practically impossible to mine anything significant without having specialized hardware. At the same time, we are surrounded by billions of mobile IoT devices that could replace the utility derived from specialized hardware. Users of Mobile IoT devices like laptops, android phones, iPhones, iPads, etc., would reach 75.44 billion users worldwide, and each person is expected to be connected to 6 such IoT devices by 2025 [4]. Owners of vast businesses tend to be users of IoT devices to make their business automated and highly dependent on it. So more business transactions are becoming associated with IoT devices. A new sensing era lies in Mobile crowdsensing (MCS), which explores the advantage of extensive use of mobile IoT devices to collect data efficiently and enable several significant applications. It uses sensing and wireless communication potentials to provide services to billions of mobile IoT devices. The use of such IoT devices can be extended for BC applications too. BC mining requires computation-intensive tasks for miners, i.e., solving the PoW puzzle, which demands high computational capability and storage facilities from miners' perspective. Instead of buying new expensive server machines, it is possible to minimize computation costs and optimize resource usage by utilizing these idle IoT devices for BC mining purposes. Since IoT devices tend to be low-power resource-constrained devices, a single IoT device cannot replace the utility of a highend server machine. One efficient technique to mitigate this issue is to divide the computation work into a fraction of small tasks and offload them to multiple available mobile IoT devices. Only specific IoT devices are preferred to be utilized for mining purposes based on their computational capability, and we call them CCNs. But finding optimal mining policy while Computation Offloading (CO) in wireless mobile BC networks is more challenging compared to BC mining in the wired network because of extensive computation mining process [5]. On the other end, function Virtualization (FV) addresses this issue by dividing the computation extensive mining process of a single miner in wireless mobile BC networks by sharing partial mining work via FV with nearby mobile users where FV exploits the virtualization paradigm.
Virtualization [6] is the logical abstraction of the underlying hardware devices within a network through software implementation. The abstraction decouples the control from hardware and makes it easier to modify, manage, and upgrade. In recent times, the abstraction has not been limited to hardware only. Still, rather software embedded into hardware has also been virtualized as independent elements, which is referred to as Function Virtualization [7], [8]. To this end, FV is implemented through VNF, which renders Network Function Virtualization (NFV) [9] technology. NFV flexibly utilizes network and computation resources [10], [11], [12]. It reduces mining expenses (e.g., capital and operational expenditures, CAPEX, OPEX [13]), computation delay. It also minimizes energy usage for any mobile operators via configuring software instances (i.e., VNFs) into assigned server/edge nodes rather than configuring Network Functions (NFs) on dedicated hardware [14]. Series of VNFs are interlinked via virtual links (VLs), forming a chain called Service Function Chain (SFC) [8]. NFV rendering SFC alleviates the overall traffic burden both in core and edge network because mobile users' CO tasks can be randomly configured into series of VNFs [9] and distributed to multiple CCNs. Each executes one fraction of the entire work in parallel, eventually saving time. CCNs have higher computation capability than resource-constrained IoT devices like headphones, smart shoes, smartwatches, etc. They can execute multiple computational tasks in parallel, eventually serving the purpose of FV for miners. Nowadays, people regularly use too many CCNs, which are multitasking capable. It is highly possible to share mining tasks through FV to those capable devices and interested in participating in the mining process. This will allow a huge number of participants to strengthen the effectiveness of the overall consensus process. This process can also cut energy consumption due to reduced computation usage in every mobile user. The entire work is now jointly solved via multiple mobile devices rather than executing it in one single node. Hence, the entire process will become faster and more efficient than the traditional process/block mining strategy because of the dedicated virtual function for each offloading task. There are no BC-based papers focusing on the virtualization technique for CO to nearby devices. So we are only able to study papers focusing on mining policy management for BC networks and CO schemes for Mobile Edge Computing (MEC). Houy et al. [15] presents a non-cooperative game among multiple miners, where each miner can choose to include the number of transactions in a block. Fisch et al. [16] focuses on the propagation of mined block using both sequential and stochastic game theory. [17] optimizes the pool mining mechanism via cooperative game-based BC mining. Luu et al. [18] presents a unique game for computational power split while BC mining, where miners can earn rewards by solving the PoW puzzle. Optimization of offloading ratio, speed of computation, and rate of transmission are jointly scrutinized in [19]. Mao et al. [20] focuses on optimizing offloading schemes, Yu et al. [21] focuses on optimal CPU time allocation, and Bi et al. [22] optimizes the trade-off between local computing and offloading. While Kang et al. [23] exploiting virtualization technique investigates a trade-off between device-to-device (D2D) reliability and computation load for every server through collaborative design of SFC and forwarding graph embedding. Kwak et al. [24] focuses on minimizing CPU and network energy of mobile devices considering a given delay threshold while mobile cloud offloading. In contrast to FV for CO while block mining, we strongly believe there is still scope to contribute to this field. The contributions of this paper summarizes in the following points.
• We have proposed a novel block mining framework for public blockchain network where lightweight IoT devices play a miner role. IoT devices utilize NFV and SFC technology to address extensive computation for PoW mining mechanisms. • It introduces joint mining computation modes to avoid the overload of a single miner. • CO schemes rendering NFV framework are jointly derived as an optimization problem. Our goal is to minimize latency, cost, bandwidth consumption while optimizing resource allocation within a given time constraint. • We propose virtual mining, which allows task sharing among registered capable miners via executing corresponding VNFs for each task. This part utilizes NFV technology to configure VNF for task execution and further link them using SFC technology to accumulate the execution result of various VNFs, eventually finding the full PoW of a given work. • Stochastic geometry theory is used theoretically to derive the related performance metrics that include energy consumption and delay. • We further explain the complexity of computation offloading using a dependency graph. • Finally, we show that FV can reduce computation cost, minimize energy consumption, maximize net revenue, and make faster mining.

II. LITERATURE REVIEW AND MOTIVATION
Because of security concerns, BC is becoming more popular day by day, and users are increasing numerously. Many industries have already started to do their business transactions via BC like systems, and many more are thinking of adopting a digital currency system for doing business transactions. The high cost of mining and scalability are significant constraints of the rapid expansion of the technology. Due to computational limitations, not all IoT devices can be considered directly as BC nodes [25]. Typical miner should have a large computation capacity and require a massive amount of energy for PoW. Both technical features are constraints for IoT being a minor. IoT devices are increasing in an unprecedented way. Although they have limited computation power, successful resource sharing of these large quantity devices can put the power in balance. This issue arises by targeting the optimum solution. Primary research already shows that orchestration of VNF can minimize power consumption [26] for CO. At the same time, the mining work is distributed within short coverage to multiple mobile devices (i.e., CCNs). This means less computation usage in a single node, as it only requires executing a fraction of the entire work. Since multiple fractions of the whole mining work can concurrently run in numerous CCNs, it would need less time to complete the entire work than a single node executing the same work alone. Hence computation is more efficiently managed by the NFV framework. Eventually, it will scale among all business BC nodes and help the BC transactions to execute efficiently without forgoing security. As more BC nodes can participate in the voting process, it can strengthen the weight of the consensus formation. Below are some of the existing solutions that pertain to BC mining and FV strategies for CO, separately.

A. BLOCKCHAIN MINING STRATEGIES
The articles [27], [28], [29], [30], [31] elaborate different aspects of BC mining where Kano et al. investigates the mining work concentration issue in [27], and proposes an incentive-based solution considers psychological factors via gamification instead of offering economic incentives. The solution also uses virtual currency service for users, which VOLUME 4, 2016 is only limited to gaming purposes. Lin et al. [28] proposes a sustainable rewarding mechanism for block mining in a BCbased transaction system. A secure transaction fee collection algorithm is proposed to enhance the reward distribution mechanism after successful mining, which can be considered as the key benefit of the solution. Simulation output shows that the proposed protocol implementation can steady block mining and reward distribution, but does not consider multipool scenario while block mining (i.e., limitation). Kiayias et al. [29] studies and formulate the stochastic game theory to decide a miner which blocks to mine and when to release blocks so that other miners cannot continue mining from it. One limitation is that it requires considerable computational power for mining rigs. Bae et al. [30] validates the security aspect of a miner while mining rigs by proposing a mathematical random mining group selection mechanism to reduce the probability of successful double-spending attacks. Abe et al. [31] describes that mining power is relavent on the network and price of tokens that can be taken securely on a BC. Users exchange tokens on the PoW, while BC should monitor mining power and allow exchange tokens cheaper than the attack cost so that profit and cost of the attacker are not in equilibrium. Many recent contributions suggested consensus mechanism avoiding the complexity of mining [32], [33]. However, these contributions focused on private Blockchain and can not be applied to public Blockchain, making this contribution different.

B. FV STRATEGIES FOR OFFLOADING
Virtualization techniques regarding CO has been discussed in [9], [34], [36] where they focus on decoupling the control from the hardware to edge server by offloading network functions into software.  [36], [37] proposed a solution on green computing in a small cell, and another on efficient power allocation that renders virtualization technology and distributed CO strategy, respectively. The solution adopts probabilistic Service Function Chain (SFC) and NFV for providing virtualization service and interlinks between them via virtual links and Management and Network Orchestration (MANO). To minimize the cost of CO in heterogeneous RAN, the solution also adopts integer linear programming to reduce the latency constraint, enhance resource allocation, and allow flexible use of applications for mobile users. The use case differs from our proposal because we consider CO for BC mining while they consider CO for gaming purposes only. They do not consider the BC network Performance evaluation, shows cost minimization between memory and computation usage and mobile users using the application. This solution provides optimal output with low complexity and a suitable environment for a large-scale network, which can be considered key benefits. Deployment of the proposed framework in heterogeneous RAN is challenging, and policy implementation to manage interference in such network considering end-to-end small BS communication is not considered and can be regarded as future work.
In light of the literature review in this section, we believe there are still gaps in optimizing the use of physical storage resources reducing latency and cost for resource-constrained mobile IoT devices. So BC mining becomes challenging for such IoT devices. Motivated from these issues, we propose smart coordination of VNF for CO, while computation work and reward distribution policy are smartly handled through virtual pool mining. The effort is included in Section III. Figure 2. The variables used to formulate mathematical equations are given in Table 1.

NFV based system model for block mining is illustrated in
This section have been categorized into six subsections where system model presents how a lot of CCN devices can be a part of BC mining network; device-2-device communication (D2D) describes how devices interact with each other in a heterogeneous environment, system components illustrates the features of various components of system model, virtual functionalities describes how MANO orchestrates VNF, computation offloading describes the offloading decisions, preliminary metrics formulates the elementary metrics of CO, and problem formulation with constraints elaborates the optimization objectives of CO scheduling. f mx , f m l sum computational capability of miner m j , m l in a pool, respectively The pathloss exponent µ Mean value of rayleigh fading

A. SYSTEM MODEL
The system model supports BC technology based upon AP network with multiple mobile nodes within its network coverage. A peer node, in our context, is a device capable of performing computation required for mining, also referred to as CCN. Every node in the BC network carries a unique identity id and can perform an individual task. A node performs a task for a specific period, and the node that performs such a task is a miner. Successful task execution is followed by both Partial Proof-of-Work (p P oW ) and Full Proof-of-Work (f P oW ). f P oW occurs when a single miner successfully solves the mathematical puzzle of the entire work. At the same time, p P oW occurs when a single miner divides complete work into a series of tasks to be solved by other individual registered miners concurrently. Every task contains a mathematical puzzle that a selected CCN must solve. Collective aggregation of p P oW from such miners comprises of f P oW signifies that a block is added to the BC network successfully, and reward is obtained. We presume that all CCNs can execute certain tasks assigned to them, as their computational capability is already weighted. At the same time, they agree to join the BC network. We presume that the list of available miners is obtained through the neighbor discovery process elaborated VOLUME 4, 2016 in section III-E, and such that the mining power of a single miner can be split and transmitted to multiple CCNs without computational constraints. Lets take there are A access points (APs), and n miners participating in a pool following two independent homogeneous Poisson point processes φ a = {AP 1 , . . . , AP A } and φ u = {m 1 , . . . , m n } with density ϑ a and ϑ u , respectively, shown in Figure 2. We denote that one participant is considered an edge AP having enough capabilities to orchestrate MANO. Multiple pools may exist within a small network, but we consider only one pool in this network.
So associated miners with the nearest edge AP AP m is denoted as .., m n }. A work, initially, is evoked by a mining leader m l , consist of a set of T tasks, where T = t i |{i = 0, 1, . . . , n}, which it tries to compute by itself. Every associated miner is taking part in the shared mining process which needs to input data with data size D n (regarded in bits), have completion deadline time τ n (regarded in second), and need computation capability G n (regarded in CPU cycles per second). The decision to or not to offload computation is based upon the computation capability of m l miner. We run a unique algorithm to compare the computation capability of the miner and the computation required to complete the work. While the algorithm determines m l 's computation capability is not enough to complete the work alone, we presume it is able to compute certain amount ofT tasks asT = {t 0 , t 2 }, T ⊂ T , and the rest is offloaded to associated miners participating in the computation process. t 0 must reside on m l locally validating the f P oW found in M , and t 2 is an extra task that it may also compute locally without computational constraints. We denote the computation capability of m l and AP m as f m l and f APm . In case of CO, we presume m l offloads T tasks to M such that T = {t 1 , t 3 , . . . , t x }, M = {m 1 , m 3 , . . . , m x }, and T ⊂ T , M ⊂ M . The offloading is efficiently managed by configuring VNF for every offloading tasks, such that V = v i |{i = 0, 1, 3, . . . , n, n + 1} represents a set of VNFs corresponding to T , except 0 and n+1 denotes the first and last VNF residing on m l validating the p P oW found in M . E.g. m l offloads t 1 task to m 1 miner and assigns v 1 VNF that should be downloaded from AP m in order to compute t 1 task locally by m 1 miner, and the same process applies for the rest of the miners taking part in the shared task computation process, shown in Figure 2. Else, we consider no function virtualization while the solo miner m l solely hashes the H(T ) full work while associated miners (i.e m i ) only vote to form a consensus.

B. DEVICE-2-DEVICE COMMUNICATION
CO for block mining consists of various VNFs, and a user (i.e., m l ) of the BC network requests a set of VNFs to the orchestrator via application proxy, based on the amount of mining work. The network flow of VNFs is formed as SFC. SFC renders SDN and NFV capabilities to create a service chain of connected network services among firewalls, network address translation (NAT), intrusion protection, etc., eventually creating a virtual chain. SFC can configure many VNFs connected in an NFV environment, while its programmable interface allows customizing policy implementation via softwarization. Softwarization allows flexible software instances in virtual circuits that can easily set connections up or torn down as needed with the service chain provisioning through the NFV orchestration layer.
From the perspective of heterogeneous BC network for resource constrained IoT devices, distributed miners (i.e. M ) are located within the coverage area of m l . m j is denoted as each CCN selected for CO, a set of m j and an m l together provide computation and storage facilities, i.e., m j ∈ M are providing resources for virtual mining, and VNF components are deployed in the virtualization layer. Wireless virtual links are deployed between m l and individual m j of set M for communication. m l provisions application proxy to process service requested from M , a set of distributed miners. The application proxy is responsible for generating SFC by analyzing the information request of m l for CO. The orchestrator, located in the edge network, is called Access Point (AP). It is responsible for deciding the optimal placement of VNFs forming SFC. The decision is updated to the proxy, and the orchestrator requests to initiate VNFs to each m j . m j provides computation resources for processing VNFs and communicates through wireless links during block mining. The wireless connections among associated miners of M , and between M & m l are mapped as virtual links (VLs) on the virtualization layer.

C. SYSTEM COMPONENTS
There are four different kinds of nodes in the system scenario serving other purposes in forming a BC network. They are leader miner (m l ), distributed miner (m j ), access point (AP m ), and cloud server.

1) Leader Miner
All miners in the BC network may form a network of m n , where individual m i miners compete to hash T work successfully and try to find f P oW . The first m i to solve the f P oW is referred to as m l while others vote to form consensus, eventually m l adds the new block in the ledger and earns the reward. It is called solo execution. It occurs only when m l is capable of processing the full work based on its computational capability, and else it decides to offload task computation. Since it cannot hash T work by itself, it may decide to computeT tasks locally, as it is capable of, and distribute the rest of the T tasks to nearby miners forming a virtual pool, where it remains the mining leader. The CO task distribution process renders SFC & NFV technologies efficient resource optimization service to mobile users (i.e., CCNs). With the help of the MANO component, which orchestrates VNFs, m l transmits a series of offloading tasks to nearby CCN miners (i.e., M ) in the pool along with state information of VNFs via VLs. Every offloading task has a corresponding VNF, which should be processed by individual m j locally.
Every m j miner in M is referred as a distributed miner. But it competes to solve a single off loadable task transmitted by m l , and else solo execution occurs, which only requires voting from a set of m i miners to form consensus, followed by successful hashing of T full work. Whether m j miner may agree upon processing task computation, its work interest depends on its computing capabilities. And hence successful hashing of each task represents f P oW for m j miner, but for the same corresponding task, m l receives a p P oW , considered as part of the full work processed.

3) Access Point (AP)
At the edge of the BC network, AP is considered when solo mining takes place, but it also participates in the mining process where needed. The only fact that differentiates AP from other miners is that it is the only node capable of orchestrating VNFs via MANO component, exploiting SFC with NFV principles. SFC provides services to store a series of VNFs and interconnects them. This allows an easy way of aggregating the result of multiple p P oW found in M , eventually enabling an m l to find f P oW . Both m l & m j nodes render MANO's functionalities to obtain VNFs, while m i doesn't.

4) Cloud Server
A cloud server may provide backup storage services. Nodes in M are following common consensus as they compete to find f P oW , while nodes in M are following precise consensus with extended virtual functionalities, as they compete to find p P oW . The replicated ledgers are stored in the cloud server once a block is successfully formed, as it is also part of the same BC network.

D. VIRTUAL FUNCTIONALITIES
CO and successful block mining is aided via SFC, as presented in Figure 3. The detailed process is divided into two parts: VNF placement section and mining related CO section.
In the VNF placement section, communication occurs between m l & m j , m j ∈ M . Let's presume G SF C is the directed graph of SFC, which has a vertex set V . Loading all these VNFs consume energy & cost. We derive VNF load CPU usage in Section IV-B2. Initially, the proxy located in m l receives service requests to generate an SFC for BCbased CO as per information provided by m l . Given that m l already has the list of available registered neighboring CCNs elaborated in Section III-E, where φ u ∼ = p m l τ . This process defines the strategy of node discovery of nearby CCNs. Then the proxy generates the requested G SF C and forwards it to the orchestrator (i.e., AP m ) to generate VNFs. The respective CCN downloads the associated VNF as per its computation capability. VNF placement algorithm is proposed in Algorithm 3. The VNF placement is based upon the objectives of CO and its resource information of M . With the produced result, the orchestrator forwards the decisions to m j to initiate VNF downloaded from AP m . Individual   m j executes one corresponding VNF, assigned for hashing one single task, and the orchestrator updates the decision placement to the proxy, shown in the VNF placement section of Figure 3. Then the proxy updates the decision response to m l , the VNFs are initiated as per the service requested.
In the second section of Figure 3, it is noticed that m l initially generates v 0 to provision the call sequence of the rest of the VNFs (i.e. v 1 , v 3 . . . , v n , v n+1 ), then starts forwarding it to AP m . The call sequence V SF C is presumed to have VNFs ranging from v 0 , . . . , v n+1 . m 1 downloads associated v 1 VNF with its input argument, executes v 1 locally, then returns the state information to m l . This process is carried on until v n is completed, where n is the n (th) term of the VNF to be processed in M . Finally, m l aggregates all the p P oW via v n+1 , corresponding to the state information of each VNF from v 1 , v 3 , . . . , v n which were executed in M . While m l eventually finds the f P oW , shown in the above figure, corresponding to v n+1 state information, such that the objectives of the input/output arguments of v 0 matches with v n+1 (i.e. v 0 ∼ = v n+1 ). Given that v 0 & v n+1 is the first and last term VNFs generated, to manage the placement of v 1 , v 3 , . . . , v n residing on m 1 , m 3 , . . . , m x , respectively, and that the outcome of each VNF successfully hashes every individual task from t 1 , t 3 to t n with one task executing in every individual m j miner. It is presumed that all m j s have equal computation capability, and can compute minimum one task assigned at a time. It is noticed that placement of VNFs are based on the application mining decisions, and the modeling of mining decisions are presented in Section IV-A.

E. NODE DISCOVERY AND REGISTRATION
This section introduces a Neighbour Discovery process of CCNs in a large-scale network. Communication may be well distributed when multiple nodes try to connect simultaneously, and transmission may fail due to interference. So we adopt a simple protocol model (derived from [21], [22]) to elaborate the process. We initially presume a node m l can receive m i 's message signal successfully only if m i is one of the transmitters within the m l 's single-hop communication range. As the CCNs are energy-and computation-constrained nodes, they can turn on or off their radio signals when needed to save energy [17] [24]. Recalling from System Model (i.e., III-A), a set of nearby nodes are denoted as M = {m 1 , . . . , m n }, where there exists a set consisting of n number of nearby nodes at the edge network distributed in a large area community via a fixed wireless channel. We presume a node's radio signal range has 10 meters ≤ ∆ ≤ 100 meters. As the task is distributed sequentially, we consider the transmission of one task at a time. Lets presume there are two neighboring m l , m i nodes lying within a suitable distance d(m l , m i ) ≤ ∆. Node m l is well aware of its position (x l , y l ) and computing local density using decision vectors: where ϑ(x l , y l ) ∈ ϑ u , D refers to network coverage area when m l 's distance from m i is denoted as: given that ∆ 2 must remain within the network coverage of m l . m l 's expected number of nearby neighbors are derived as:n m l = m x π∆ 2 ϑ(x l , y l ) Node m l can discover its neighbor node m i within τ N time slot, and m x is the number of CCNs available for task computation, as already mentioned in system model, and that m i being one of the selected neighbor of m l to transmit, given that m l is listening in the slot. A pre-defined sequence S m l = s m l (τ ), 0 ≤ τ ≤ N of period N is scheduled for node m l , in which: sleep m l in time τ slot radio signal turned of f transmit m l in time τ slot transmitting listen m l in time τ slot listening (2) Duty cycle (θ) is the fraction of time that a node keep its radio signal turned on, formulated as: for any m l and m i nodes, because we presume they have the same duty cycle at all times (i.e. θ m l = θ mi = 1). So they are referred as symmetric node. Hence, for any two nodes like m l and m i following uniform distribution, we can say the transmitting or listening state probability of a miner p m l τ = p mi τ = p τ = 1 N +1 , where expected number of nearby CCNsN m l =N mi =N , since the task of each miner is uniformly distributed. These preliminaries are used to derive the optimal transmitting or listening state probability of m l while discovering nearby nodes, which is precisely generated in Algorithm 1, Line 1. N is referred as the time threshold/latency bound, stated in Line 2. Line 3 models the decision vector whether to transmit or listen. In line 4, when ε < p τ , the node discovery application decides to transmit message including m l 's information & id through the communication channel. Else, in line 7, ε ≮ p τ , the node discovery application decides to listen through the communication channel, decode the message, and save id. Line 9 updates timetreshold or latency, every time a new m i is enlisted for task offloading. Proof: See [43]. We presume τ : = τ + 1 10 end that the number of available miners is enough to share task computation. The mining power can be split based upon the nearby miner's computation capability for a given computation task. Since traditional pool mining requires miners to register into the pool (network), miners need to meet a certain standard set by the pool. In our case, we compare the computational capability of a miner and the computation energy required to execute a certain task for that miner to meet the standard. This is further presented in Algorithm 2 and elaborated in Section IV-D.

IV. COMPUTATIONAL COMPLEXITY
Overall computation complexity depends on amount of task (T ) required to be computation. Complexity is proportional to the amount of task. In this experiment, if T is larger than the computational capacity of leader miners, then the t i ∈ T |i = 1, 2, 3, . . . n where n number of virtual miners joined the computation. In case of virtual mining, complex-ity is calculated in terms of communication, computation, offloading (ol), miner selection, etc.
t mining i following sections presents details of complexity dependencies and calculations.

A. COMPUTATION OFFLOADING
Although mining work varies from application to application, mining involves the execution of numerous tasks that is common, which certainly cannot be completed by any single CCN device. CO plays a significant role in completing the entire work. Thus, the decision to or not to offload computation may result in solo execution or offloading, expressed as σ(m l ) = {0, 1}.

1) Solo execution (Mode 0)
As shown in Figure 2, the entire computation of a given T work is done locally at m l , given that m l node became the first one to successfully solve the mathematical puzzle, and publish f P oW in the pool, while other m i miners in M join to form a voting consensus. We denote σ(m l ) = {0} when m l decides to execute solo execution process. The offloading to M is not performed either due to unavailability of CCNs or the offloading tasks can be simply handled by themselves. In this case, FV is not required too.

2) FV for Computation Offloading (Mode 1)
CO is a very complex process of pool mining-affected by various factors, such as mobile users' preferences and capabilities, AP availability, connection quality to transmit VNF, and cloud capabilities. We denote offloading mode, which represents σ(m l ) = {1}, when m l decides to offload T tasks to M . CO is required when the fraction of theT tasks are computed locally by m l , derived from the solo execution part. The rest is offloaded to AP m for individual m j miners to download associated VNF recommended by m l and to compute locally, given that m j ∈ M .

B. PRELIMINARY METRICS
This section will formulate the elementary metrics, including processing delay time, VNF loading cost, and energy consumption in mode 0 and mode 1.

1) Solo computation
We only formulate the delay time and energy consumption (CPU used) in this section. Since there is no FV in solo execution, VNF loading cost will not be considered here.
• Processing Delay: It is the sum of time (τ ) needed to execute(e) and queue(q) while processing t i task by m l , as τ D = τ (m l ,e) +τ (m l ,q) , and execution delay in eq 4, and queuing delay in eq 5 are derived separately as follows: where Q n , is the number of CPU cycles to be executed in the task buffer at m l such that q = {1, . . . , n}. • Energy Consumption: Although m l tries to complete full work here, it may be available to complete partial work only. In this case, the rest of the work will be offloaded in mode 1. Total energy consumption to process T full work and CPU usage: where κ m l is the computational energy coefficient of the processor's chip of miner m l [44], [22], and P s is the static circuit power.

2) Remote Computation
It includes task CO to a group of D2D miners at mode 1. Since offloading requires data transmission to configure VNF, total cost is formulated by energy consumption (CPU usage), VNF loading cost, and the processing delay.
• Processing Delay: It is different from self computation at mode 0, where every tasks are implemented with corresponding VNF and transmitted among individual pool miners (i.e. m j ) for mining. Every pool miner is competing to complete individual task. But this sometimes cause to delay the aggregated time to complete the offloading tasks. Considering the full work T divided into t n tasks, of which T tasks are offloaded to multiple m j miners, until completed at mode 1. Since offloading is done simultaneously, the total delay to process T parts are: trans denotes delay to transmit V SF C to M , while l D1 V N F denotes delay (i.e. queue) in task buffer of AP m , and V N F D1 exec denotes delay to execute V SF C in M , all in respect to process T parts implemented with V SF C VNFs for all miner. • Transmission delay: It is the time taken by m l to transmit the data packets to AP m .
Data size transmission rate VOLUME 4, 2016 • VNF load delay: It is the waiting time of the task buffer in the processor chip of AP m while uploading VNFs.
where Q n is the number of CPU cycles to be executed in the task buffer at AP m to transmit v 1 , v 3 , . . . , v n into M . • VNF Execution time: The execution (e) time for M to compute v 1 , v 3 , . . . , v n VNFs corresponding to T tasks until completed in mode 1: where G T denotes the computational capability to execute T task. • Energy Consumption: Sum of the energy consumption of remote processing (i.e. E mx ) required to hash T tasks (i.e. t 1 , t 3 , . . . , t x ) are as follows: where κ mx is the aggregated computational energy coefficient of the processor's chips of a set of miners M [44], [22]. P u and P AP is the transmit power of m l & AP m , respectively.

C. PROBLEM FORMULATION WITH CONSTRAINTS
This section studies the optimization of CO scheduling in order to maximize the total net revenue via FV.

1) Total Cost Optimization
This section elaborates the optimization objectives of CO scheduling: • Offloading decision: Lets presume the net revenue for mining offloadable and non-offloadable tasks be Ψ (m x ) and Λ(m l ), respectively. Recalling again that offloadable and non-offloadable parts need to hash T andT tasks, respectively.
• Total Net Revenue: The total net revenue for mining the entire work T is:

2) Problem Formulation
Considering the offloading scheduling with decision vectors σ, we in this subsection draw formula for the total optimization problem: There are constraints formulated from C1-C6. C1 validates the non-offloading and offloading decision. C2 ensure that the sum data rate of all the miners associated with AP m doesn't exceed its backhaul capacity Ω AP . C3 confirms that the sum computational capability of all the miners associated with M does not exceed the sum computational capacity required to execute T parts. C4 ensures that the task delay does not cross the limit of task deadline τ n . C5 means that the data size of each offloaded part via D2D link does not cross the limit of the link capacity L V N F . Also, we formulated constraint C6 to ensure that the total size of the data processed in m l does not exceed its storage capability C store . And X n refers to the size of the cryptographic hashes of blocks w.r.t. t n parts, are set at 1 for convenience.

D. TASK OFFLOADING SOLUTION
Overall task offloading processes are executed in two steps, such as 1) Solo mining (Mode 0) and 2) Virtual mining (Mode 1). Virtual mining process is executed only when solo miner / leader is incapable to execute the etire task.

1) Execution in Leader Miner (Mode 0):
First function of Algorithm 2 implements solo mining defined as doM ining function. While, m l also an m i , compares it's own computation capability f m l (stored in I) with the computation energy required G T (stored in J), in order to complete full work H(T ). If its capacity matches then proceed task execution else decide to offload tasks. To implement task execution, the system initially takes input of target value H(T ) derived from T , and verifies through while loop in doM ining function, whether evoked T is already added to BC or not. If not, m l randomly takes a corresponding input of T value, and keeps in num, stated in line 6. In line 8, it adds combination of nonce constantly until rehashing matches the target value H(T ), and stores inH T . Line , as nowH T and input target value H(T ) already matched, the if condition further calculates credit point (CP) of m l , and returns f P oW stated in line 10. Else, the loop is repeated in case of not fulfilling the requirements, stated in line 13. Figure 4 (a) reflects the solo execution showing full work H(T ) consists of series of tasks, say, t 1 , . . . , t 5 which are locally executed because m l is available and capable. There is no need to offload computation, and share reward. Entire reward is taken by itself only. M ode 1 signifies the CO decision. An important aspect in the CO and reward (or credit point) calculation depends in application model/type, since it determines which fraction of the full work to be processed locally and which are to be processed remotely, what could be offloaded, and how. With the help of MESC/MANO m 1 , m 3 , m 4 process offloadable tasks t 1 , t 3 , t 4 with corresponding v 1 , v 3 , v 4 , respectively, and m l processes non-offloadable t 0 , t 2 tasks locally, as shown in Figure 4(b). The application criteria of CO is summarized below.

3) Tendency of application Offloadability
Offloading is based upon its enabling code, representing how much task is locally processed and how much is off loadable, given that offloading task must be processed in parallel to form a consensus. Selected M miners are only allowed to process H(T ) tasks offloadable by m l . Initially, Algorithm 2, line 17-21 explains the function T enderP rocess. This function selects the computation offloadable tasks & miners from the interested enlisted miners from Algorithm 1. Algorithm 2, line 23 determines the portion of reward achieved by m l while task sharing with f mx . Line 19 searches for valid miners by verifying their computational capability. Lines 20 parses tasks to a set of selected m x min-VOLUME 4, 2016 ers and embeds tasks to respective miners in line 21. Reward of individual m j is calculated using RewardCalculator function, line 24-28. We denote m j as a virtual miner, shown in Algorithm 2, line 25, as they are now part of the virtual pool. Against every p P oW , there is a constant k value determined, retrieved from Algorithm 3. k represents the workload done by individual m j through computing its embedded task. Line 30 returns the individual reward of m j by multiplying k with the credit point (CP ). Virtual execution of VNF in m j miner is shown in Algorithm 3. Initially, it is presumed that the work done by m j is zero. The V irtualM ining function takes T tasks as input, then compares the processing capacity of m j miner. The while loop verifies if the evoked T tasks are already solved or not. If not, m j randomly takes a corresponding input of T value, and keeps in num, referred in line 6. Then it adds combination of nonce constantly until rehashing matches the target value H(T ), and store inH T against a constant k value, stated in line 7. This hashing process should be completed within a given time threshold τ n , else repeat line 8. Whilst the target value matching occurs, Reward of m j in the RewardCalculator function in Algorithm 2 is updated.

V. RESULTS ANALYSIS
This section presents the critical analysis & performance evaluation of the proposed research. The objective is to enable BC technology for IoT objects allowing secure, efficient CO through FV. There are multiple existing efforts considering CO for IoT objects. Still, the proposed research adds more contribution by utilizing BC to ensure transaction security and enables virtualization to ensure the efficiency of IoT objects. The simulation considers Python language for emulating performance evaluation. PoW is considered for transaction verification. The m l randomly takes value against task computation (T ) targeting to reach H(T ) and then sorts equal offloading tasks to nearby CCN devices and m l itself. In the simulation, the random value against task computation (i.e. H(T )) is taken from 100-200, where each fraction of T task (i.e. t i ) process 30MB of data. Delay threshold and bandwidth are taken 15 seconds and 15 Mbps, respectively. Transmit power (P u ), and static circuit power (P S ) of individual CCN are taken 0.1 W and 0.05 W, respectively. Algorithm 2 refers to task selection (i.e. doM ining function) and reward distribution process (i.e. RewardCalculator function), and the nearby CCN devices are selected through Algorithm 1. The algorithm is implemented through Python language, presuming that all nearby CCN devices have equal computation capability and the reward is evenly distributed. The set of nearby CCN device selection is limited between 5-10 nodes at a time randomly. The best combination of node selection is based on the collaborative approach of maximum reward output. e.g., four nodes can compute 100 tasks with a total reward of 10 points, or three nodes can compute 100 tasks with a total reward of 8 points, or two nodes can compute 100 tasks with a total reward of 2 points on. The set of 4 CCNs computing 100 tasks with the reward of 10 points is selected. In this case, leader miner (m l ), as one of the CCN among four nodes, also receives the same reward as other m j miners, as it computes an equal amount of tasks as others. In this case, m l computes onefourth of the computation, such as generating v 0 , v (n+1) , computing v 2 , and matching v 0 ∼ = v (n+1) , while individual m 1 , m 3 , m 4 computes v 1 , v 3 , v 4 VNFs respectively. It is presumed generating v 0 , v (n+1) and matching v 0 ∼ = v (n+1) requires negligible amount of computation, and so reward for this work is ignored. Parameters and symbols used to implement proposed algorithms are stated in Table 2.

A. EVALUATION AND DISCUSSION
Function virtualization impact on mining has been evaluated with state-of-art in Figure 5. Figure 5a shows comparison between traditional centralized approach and decentralized BC approach with or without FV for task computation. It presents the execution time (milliseconds) of compute tasks. IoT nodes are resource constrained devices that are not capable of computing heavy tasks. In Figure 5a, the blue line refers to a server node computing task via a centralized approach that considers no FV or BC technology, the red line refers to computing tasks by a CCN using BC platform, the purple line refers to CO to nearby CCNs by a m l via FV using BC platform.
The time threshold (τ n ) is set as 15 seconds. For example, to compute ten tasks, a server node consumes 1800 ms in a centralized approach, a CCN consumes 1870 ms to compute the same task in M ode 0, and an m l in M ode 1 consumes 2992 ms to share task computation with the selected nearby CCN miners to complete the same tasks. It is noticeable that the centralized approach consumes the least amount of time, and M ode 1 takes the maximum amount of time to execute a certain amount of tasks. M ode 0 is moderately taking less time than M ode 1 because the computation capability (i.e., f m l =18000 CPU cycles/sec ) of m l is just enough to compute the given task by itself. As the task increases, the execution time increases steadily in a centralized approach, while the decentralized approach consumes more time in M ode 0 and M ode 1. Successful block creation consumes more time because the difficulty for block transaction verifi-   cation increases proportionately as more CCNs participate in the mining process. Figure 5b presents a computation time with the participation of miner devices for mining a specific task through FV. It is observed that time is disproportionate to the number of active participants. While the number of FV participants is increased, computation time is decreased. It is assumed that every device has a 1k to 50k T computation capacity. The task is split randomly among devices. It can vary based on the devices' capacity.
This ensures the security of IoT nodes. Even though transmission delay of CO is minimized through FV, internet bandwidth (B), presumed as 15 Mbps, remains a crucial factor in minimizing computation execution time. It is noticeable that there is a trade-off between time and energy consumption while incorporating a decentralized approach. The centralized approach consumes less time but is limited to provisioning security. In comparison, the decentralized BC approach with FV collaboratively consumes a little more time but provides more security and resource optimization by employing underutilized nearby CCNs. But individual CCN takes only a couple of 100ms to execute each virtual functions, which is a lot less than the centralized approach. The proposed research considers FV to offload computation tasks to nearby CCNs while m l is not computed for all tasks by itself due to its limited computation capability. The transaction security of CCNs are preserved by BC and FV ensures efficient CO to nearby devices. Figure 6 shows computation usage of participating miners via FV using the BC platform. It presents the number of tasks to be computed by nearby participated CCNs and their average computation (CPU cycles/sec). The blue bars refer to the number of CCNs participating in computation mining. The orange bar refers to the average computation of each set of CCN miners, e.g., four CCNs participates in computing 100 tasks with an average computation of 6.89 CPU cycles/sec, or 3 CCNs participates to compute 110 tasks with an average computation of 6.62 CPU cycles/sec, and so on. It is noticeable that the number of participating CCN miners  varies, affecting average computation to compute every set of tasks. As the difficulty of block mining is connected to the number of participating miners, some tasks require more energy and time to compute. In comparison, others require less energy and time to compute. Transmission delay of virtual functions also affects CO, as tasks remain in the queue to be offloaded to the nearby CCNs. Figure 7 shows the average reward distribution for the participating miners for task computation. The x-axis refers to the number of tasks, and the y-axis refers to the average reward points (CP) for each set of participating CCN miners for a set of given tasks. For example, four CCNs participate in computing 100 tasks to earn an average reward point of 10, or 2 CCNs participate in computing 130 tasks to earn an average reward point of 8, and so on. It is noticeable that the obtained CP is influenced by the number of miners participating in the computation mining and the related number of tasks that need to be computed by each set of participating miners. Among other factors, bandwidth tends to be very crucial. Figure 8 shows individual reward (CP) and computation usage of participating miners via FV using the BC platform. The x-axis refers to the number of tasks to be computed by  nearby CCNs, and the y-axis refers to individual rewards (CP) of CCN participating in computation mining. The right of the y-axis refers to the individual computation (CPU cycles/sec) of the involved CCN for executing the single task. The blue bars refer to individual rewards (CP), and the orange bar refers to the individual computation of executing a single task of participating miners. e.g., four CCNs participate in computing 100 tasks to earn an individual reward point of 2.5, or three CCNs participate in computing 110 tasks to earn an individual reward point of 4, and so on. It is presumed participating CCN miners have equal computation capabilities where f mj =100-1000 CPU cycles/sec. So the shared task computation is evenly distributed as it would take the same time to execute a task embedded with a virtual function. As a result, the rewards are also evenly distributed. Internet bandwidth (B) remains 15 Mbps. And the time taken by individual m j to execute each VF (v i ) is also equal. It is worth mentioning that FV enables efficient processing of CO. Reward distribution for block mining is validated by cryptographic hashing functions, where the difficulty starts with '0000'. It also creates a chain of linked blocks which ensures data integrity and the immutability of the ledger.
• Insights: From the above discussion, it is predictable  that FV enables optimal resource usage and allows heavy computation mining for resource-constrained IoT devices utilizing the virtual task mining process. As the underutilized IoT devices are used to compute mining tasks, the cost of installing expensive server stations is no longer required. The net revenue of individual CCN is optimized as it can earn more CPs rather than being underutilized. It is also noticed that hashing also leverages the PoW to validate transactions encouraging incentive miners to agree upon computation mining.

VI. COMPLEXITY OF COMPUTATION OFFLOADING
CO application may require individual miners to consider several internal components to exercise to improve real-time CO efficiency. They are (i) Program/code profiler component, (ii) System profiler component, and (iii) Decision engine component [45]. The first one is responsible for determining the offload table tasks based on application decision type and selecting which tasks need to be processed in m l and which to be processed in m j . The second is responsible for configuring available bandwidth validate miners, and CP distribution is based on energy spent locally & remotely. Finally, the last one decides to or not to offload computation. Moreover, some critical discussions about CO are stated below.
• Knowledge based data processing: m l initially compares between the amount of data that is required to process the entire work and the amount of data it can locally process, shown in Algorithm 2, line 3. This comparison already shows how much data full work consumes (stated in problem formulation C1). Based on this assumption, it is also calculated how much time the entire work requires to complete (stated in problem formulation C4). Most importantly, what fraction of the computation needs to be offloaded for continuous application processing (stated in problem formulation C2). We next explain the complexity of the inter-dependency offloading issues through Figure 9. • Inter-dependency of the offloadable tasks: The application decision regarding CO is determined by the dependency relationship of T tasks to be processed. However, offloading tasks may or may not be dependent on each other. Independent tasks may be processed locally in m l , based on application decision. In the case of dependent tasks, the continuation of application execution may require the input of one task from the output of another task (s), whom we say are mutually dependent on each other. Hence, parallel offloading may not always be possible. We further demonstrate this complexity through a Component dependency Graph (CDG) [46], [47], [48], [49] shown in Figure 9. The entire application is broken into two parts; (i) Offloadable tasks (i.e. t 1 , t 3 , and t 4 ), and (ii) Non-Offloadable tasks (i.e. t 0 , and t 2 ). Note that t 1 and t 3 are only offloadable after processing t 0 , while t 4 is only offloadable after processing t 0 , t 1 , t 2 , t 3 . This means that certain tasks are only offloadable after completion of dependent nonoffloadable tasks, which are processed locally. We intend to mitigate this issue in the future.

VII. CONCLUSION
This effort aimed to investigate existing challenges of traditional IoT ecosystems and find the optimal solutions for challenges integrating SDN and NFV with BC technology to mitigate the storage and computation issue of resourceconstrained IoT devices. We have discussed significant research that exists regarding BC and FV. The literature review separately grouped existing efforts in two parts, (i) existing BC mining strategies, (ii) FV strategies for CO. Although the review section has separately addressed many ways to mitigate resource-constrained IoT devices' storage and computation challenges, it was not possible to achieve the desired goal. As most IoT devices are limited in computational capability and storage space, a single IoT device cannot do extensive computation. We then further extended our effort to produce a contribution focusing on BC mining designed explicitly for resource-constrained IoT devices. Our goal to this end was to render underutilized resource-constrained IoT devices for task computation with minimal energy consumption within the given time constraint. We have combined BC and FV to mitigate the said issue. In light of this, we introduced a novel BC framework for such mobile IoT devices utilizing NFV and SFC technologies on top of SDN controllers. The contribution adopts a virtual mining strategy that adheres to the computation-intensive PoW puzzle performed by the individual nearby mobile nodes (or CCNs). The CO mechanism is performed by a lead miner, which coordinates a series of VNFs linking them through SFC technology. The leader miner eventually accumulated the execution result of multiple VNFs to find the full PoW. We have shown that FV can reduce computation cost, minimize energy consumption, and make block mining more efficient than a centralized approach.