## 3 System Model and Problem Statements
### Problem Formulation  
In this section, we formulate the system with MDP to explain the problem, intending to reduce the system weighted cost based on the specifications of large-dimensional and high-dynamic blockchain-enabled IoT networks. The IoT object, which could be a camera or a utility object, is attached to an energy harvester module, which must handle computation-intensive tasks such as augmented reality apps. These jobs must be completed promptly to provide high customer satisfaction and direct subsequent actions locally or remotely. Additionally, our approach uses local edge nodes made up of basic computers and laptops. Besides, EH components and electricity storage elements, including RF energy harvester, are included in the IoT object. The IoT system could either perform jobs locally or offload jobs to an edge platform that could offer high computation efficiency with a virtual machine, thanks to the energy provided by the EH element. Typically, IoT objects are the slowest in terms of processing speed, and the cloud is particularly quick in terms of preparing; on average, IoT processing power < edge processing power < cloud processing power. As a result, IoT can connect to the cloud via Wide Area Network (WAN) and the edge via ZigBee and Bluetooth at varying powerful transmission rates. Thus, the edge platform and the IoT object can rapidly acquire the properties of the task. In this system, the number of edge nodes represents by \(E\) and the number of IoT objects represents by \(O\), which can quickly obtain the properties of a network task. Additionally, \(t\in T\) is the set of slots of all time. Job \(n\in~{}A\) can be measured in this system by the data size \(d_{i}\). IoT apps are made up of computational jobs, all of which can be offloaded. Additionally, each job can be broken down into multiple identical parts, and the computation depends on the number of instructions. The object state for IoT systems and tasks is specified as \(state\)\(s=(p\;,w,g)\), where \(p\) is the IoT object's attributes, \(w\) is the attributes of the task, and \(g\) contains networks status. In a nutshell, \(p=(\beta(t);\,b;\,f)\), where \(\beta\), \(b\), and \(f\) are harvested energy, battery level, and frequency of CPU clocks, respectively. Additionally, \(w=\)(\(d_{i};\,d_{j}\)), where \(d_{i}\), and \(d_{j}\) are the data size and the delay provisions of the job. The \(g=(CE,CC,\,\hat{\eta})\) contains the energy of all controllers, overhead computation, and \begin{table}
\begin{tabular}{c l} \hline \hline
**Symbol** & **Description** \\ \hline \(c_{c}\) & The controller \(x\)’s computing capability \\ \hline \(t_{cd}\) & Rate of transmission between the controllers and the local edge server \\ \hline \(t_{cb}\) & The transmission rate between the controllers and the blockchain \\ \hline \(CO_{offload}\) & The computation overhead \\ \hline \(CO_{server}\) & Computation overhead by server \\ \hline \(CO_{total}\) & Total overhead \\ \hline \(CO_{block}\) & Block overhead \\ \hline \(M\) & The number of consensus nodes \\ \hline \(cc_{1}\) & Request period’s computing cycles \\ \hline \(cc_{m}\) & The necessary computing cycles at the MC \\ \hline \(l\) & The percentage of right transactions sent by the MC \\ \hline \(tb\) & The transaction batch’s total size. \\ \hline \(ts\) & The average transaction size \\ \hline \(Cost\) & System cost \\ \hline \(j\) & The block size \\ \hline \(\partial\) & The constant-coefficient \\ \hline \(b_{t}\) & The broadcast delay among nodes \\ \hline \(ti\) & The block generation interval \\ \hline \(V_{n}(t)\) & Consensus time \\ \hline \(Ef_{t}\) & The IoT object’s efficiency \\ \hline \(C\) & The cumulative gain of the IoT antenna \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._computation resources, respectively. To simplify, we split spaces within discrete cells by grid approach and configure delay provisions in multiple domains. In this system, the IoT controller will pick one of the actions to be taken to deal with the task at each decision time.