## 2 System Model
### Blockchain Model  
As shown in Figure 2, the Delegated Byzantine Fault Tolerance algorithm (dBFT) [22] is used as the consensus mechanism in this paper, which is mainly responsible for the distributed verification of the task scheduling scheme generated by the optimization algorithm, to ensure the credibility and consistency of scheduling decisions. In the selection of consensus nodes, voting is based on shares to determine the nodes participating in the next round of consensus, which can quickly reach consensus and tolerate a certain percentage of malicious nodes. In the consensus process, the number of consensus nodes is assumed to be \(K\geq(3f+1)\) (\(f\) is the maximum number of malicious nodes that can be tolerated), the master node (moderator) is responsible for broadcasting the new block, and the deputy nodes (participants) are responsible for voting on the new block. When the number of malicious nodes is less than \(f\), the view switching mechanism can re-elect the master node even if there is a network outage to ensure that the consensus is finally reached and no error blocks are generated. However, if the number of malicious nodes exceeds \(f\), the system will trigger the dynamic member group adjustment mechanism to restore system activity and security by adding or subtracting nodes [23]. Define \(S_{k}\) as the size of a block and \(S_{p}\) as the average size of a transaction. The consensus process is divided into four phases: preparation request, preparation reply, submission, and broadcast, where each consensus phase generates energy consumption and latency [24]. (1) Preparation request:  
The moderator will pull transactions from the memory pool to build a new block and then send a ready request message to the participants, thus starting a new consensus round. In this phase, the moderator generates one signature and \(K-1\) message authentication codes (MACs). It is assumed that it takes \(\alpha\) and \(\beta\) central processing unit (CPU) cycles to generate and verify a signature and MAC, respectively. Therefore, the CPU cycles required by the moderator are denoted as:  
\[C_{n}^{pr}=(K-1)\beta+\alpha \tag{10}\]  
The energy consumption and latency generated in the preparation request phase are, respectively:  
\[E_{n}^{pr}=P_{cons}T_{n}^{pr} \tag{11}\]  
\[T_{n}^{pr}=\frac{C_{n}^{pr}}{f_{cons}} \tag{12}\]  
where \(f_{cons}\) denotes the average computational power of the node and \(P_{cons}\) denotes the average transmission power of the node. Figure 2: The consensus process. (2) Preparation reply:  
The moderator receives the ready request message and verifies it. If the verification passes, it sends the ready reply message to all the consensus nodes. In this phase, the participant needs to verify the signature and MAC in the new block and then generate one signature with \(K-1\) MACs for reply. Therefore, the CPU cycle required by the participant is denoted as:  
\[C_{n}^{ps}=\alpha+\beta+\frac{S_{k}(\alpha+\beta)}{S_{p}}+\alpha+(K-1)\beta \tag{13}\]  
The energy consumption and latency generated in the preparation reply phase are, respectively:  
\[E_{n}^{ps}=\sum_{1}^{k}P_{cons}T_{n}^{ps} \tag{14}\]  
\[T_{n}^{ps}=\frac{C_{n}^{ps}}{f_{cons}} \tag{15}\]  
(3) Submission:  
The consensus node starts verifying the legitimacy of each message if it obtains not less than \(K-f\) other nodes' ready replies and broadcasts them after passing the verification. In this phase, the consensus node has to verify \(K-f\) signatures and MACs and generate one signature with \(K-1\) MACs as a submit message. Therefore, the CPU cycle required by the consensus node is denoted as:  
\[C_{n}^{com}=(K-f)(\alpha+\beta)+\alpha+(K-1)\beta \tag{16}\]  
The energy consumption and latency generated in the submission phase are, respectively:  
\[E_{n}^{com}=\sum_{1}^{k}P_{cons}T_{n}^{com} \tag{17}\]  
\[T_{n}^{com}=\frac{C_{n}^{com}}{f_{cons}} \tag{18}\]  
(4) Broadcast:  
The consensus node broadcasts to all nodes if it obtains no less than \(K-f\) submissions and verifies them.