# Blockchain-Based Distributed Computing Consistency Verification for IoT Mobile Applications
## 6 The Proposed BDCA
### Data Uploading  
In this phase, \(SC\) encrypts the uploaded transaction \(Tx_{1}\) with advanced gamma multi-signature scheme (AGMS) to ensure its security and privacy in the process of cross-chain interaction and any unauthorized access or tampering can be detected. The detailed process of AGMS is expounded in Algorithm 2 and the specific process of uploading data is shown as follows:  
* \(SC\) invokes Algorithm 2 to encrypt \(Tx_{1}\) and obtain the signature \((c,sig)\). Then, \(SC\) sends the signature \((c,sig)\), \(Tx_{1}\), and \(PK_{leader}\) to \(TC\). ```
1:Input: The message \(msg\) to be signed, the public key sets of the signers \(keys=\{pk_{i}\}_{i\in[1,\varnothing]}\), the threshold number \(\varnothing\) of signers, and the public key of the leader \(pk_{leader}\). Output: The multi-signature \((c,sig)\). 2:Randomly select a random value \(v_{i}\), compute \(V_{i}=g^{v_{i}}\);
3:Compute the partial aggregated public key \(PK_{signers}=\prod_{i\in[1,\varnothing]}pK_{i}\) and the partial aggregated commitment \(V_{signers}=\prod_{i\in[1,\varnothing]}V_{i}\);
4:Compute the complete aggregated public key \(PK_{leader}=PK_{signers}\cdot pk_{leader}\) and the complete aggregated commitment \(V_{leader}=V_{signer}\cdot V_{leader}\);
5:Compute the collective challenge \(c=H_{1}(g,V_{leader},PK_{leader})\);
6:Compute the hash of the signed message \(hv=H_{1}(msg)\) and the partial aggregated signature \(sig_{signer}=\sum_{i\in[1,\varnothing]}sig_{i}=\sum_{i\in[1,\varnothing]}v_{i} \cdot c-hv\cdot d_{i}\);
7:Compute the signature \(sig=sig_{leader}+sig_{signer}\);
8:Output the signature \((c,sig)\)
```  
**Algorithm 2** Advanced gamma multi-signature scheme. Upon receiving the signed transaction \(Tx_{1}\) from \(SC\), \(TC\) proceeds to invoke the designated smart contract \(S_{t}\) to conduct a rigorous verification process to ensure the authenticity and validity of \(Tx_{1}\) before it is stored on the blockchain. * \(TC\) computes \(hv=H_{1}(msg)\) and \(\widetilde{V}=(g^{sig}PK_{leader}^{hv})^{c-1}\). \begin{table}
\begin{tabular}{l c c c} \hline \hline \(\mathbf{AVI}_{i,j}\) & \(j=1\) & \(j=2\) & \(j=3\) \\ \hline \(i=1(Point_{1})\) & \(\tau_{1}\) & \(Point_{2}\) & \(Point_{3}\) \\ \(i=2(Point_{2})\) & \(\tau_{3}\) & \(NULL\) & \(NULL\) \\ \(i=3(Point_{3})\) & \(\tau_{8}\) & \(\chi_{11}\) & \(NULL\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Auxiliary verification information form (AVF). Figure 2: The process of constructing BV-MHT. * \(TC\) verifies the correctness of the signature \((c,sig)\) with Equation (2). If the equation holds, the signature is valid and \(TC\) continues to conduct the following verification; otherwise the signature is invalid, and \(TC\) rejects to store \(Tx_{1}\). \[c\stackrel{{?}}{{=}}H_{1}(g,\tilde{V},PK_{ leader}).\] (2)
* \(TC\) verifies the correctness of \(\{k,h_{root}\}\) by checking whether the hash value \(H_{1}(m_{k}^{*})\) based on the datasets \(\{m_{i}^{*}\}_{i\in[1,k]}\) is equal to \(h_{v_{k}}\) of the node \(v_{k}\). If the verification passes, \(TC\) continues to conduct the following verification; otherwise, \(Tx_{1}\) is invalid, and \(TC\) rejects to store \(Tx_{1}\). * \(TC\) invokes Algorithm 3 to verify the correctness of AVF\({}_{1\times t}(v_{k})\). If the algorithm outputs \(0\), \(TC\) rejects to storage of \(Tx_{1}\); otherwise, \(TC\) stores \(Tx_{1}\) and returns its acceptance and signature of \(DO_{T}\). It is worth noting that we assume that \(PI:=\{(\alpha_{i},\beta_{i})|\alpha_{i},\beta_{i}\in\mathcal{Z}_{N},i\in[1, \theta]\}\) is a \(\theta\) size set. For any element \(y\in\mathcal{Z}_{N}\), the set operations '\(\pm\)' of \(PI\) are described as follows: \[\{PI\pm y\}=\{(PI(\alpha)\pm y),(PI(\beta)\pm y)\},\] where \(PI(\alpha)\pm y:=\{(\alpha_{i}\pm y,\beta_{i})\}_{i\in[1,\theta]},PI(\beta)\pm y :=\{(\alpha_{i},\beta_{i}\pm y)\}_{i\in[1,\theta]}\).