Blockchain-Based Distributed Computing Consistency Verification for IoT Mobile Applications

Abstract

The maturation of wireless connectivity, blockchain (distributed ledger technologies), and intelligent systems has fostered a comprehensive ecosystem for the Internet of Things (IoT). However, the growing volume of data generated by IoT devices creates substantial pressure on blockchain storage and computation capabilities, impeding the further development of the IoT ecosystem. Decentralizing data storage across multiple chains and utilizing cross-chain technology for data exchange eliminates the need for expensive centralized infrastructure, lowers data transfer costs, and improves accessibility. Hence, the issue of computational and storage pressure in blockchain can be improved. Nonetheless, the data of IoT devices are constantly updating, and ensuring consistency for dynamic data across heterogeneous chains remains a significant challenge. To address the aforementioned challenge, we propose a blockchain-based distributed and lightweight data consistency verification model (BDCA), which leverages a batch verification dynamic Merkle hash tree (BV-MHT) and an advanced gamma multi-signature scheme (AGMS) to enable consistent verification of dynamic data while ensuring secure and private data transmission. The AGMS scheme is reliable and robust based on security analysis while the dependability and consistency of BDCA are verified through inductive reasoning. Experimental results indicate that BDCA outperforms CPVPA and Fortress in communication and computation overhead for data preprocessing and auditing in a similar condition, and the AGMS scheme exhibits superior performance when compared to other widely adopted multi-signature schemes such as Cosi, BLS, and RSA. Furthermore, BDCA provides up to 99% data consistency guarantees, demonstrating its practicality.

1. Introduction

As a state-of-the-art technology, the Internet of Things (IoT) has garnered extensive application in various facets of modern life, ranging from smart cities [1] and connected vehicles [2] to intelligent healthcare [3,4,5]. The proliferation of IoT devices has resulted in the generation of voluminous and dynamic data [6], which often contains sensitive user information, including personal identification, health, physiological data, and transaction records [7]. The exponential growth of data has placed significant pressure on the storage and computing capabilities of IoT devices. Moreover, due to the problem of data silos [8], secure and reliable data interaction among IoT devices remains a challenging issue, thereby impeding the further development of IoT.

Currently, the prevalent approach to address the storage and computation pressure in the IoT domain is to store data in cloud servers [9,10,11,12,13], which possess robust computational and storage capabilities. Notwithstanding the potential benefits of cloud-based solutions for IoT data storage, the adoption of this approach also introduces new challenges. Firstly, the process of uploading data to cloud servers may result in delays or service disruptions for IoT devices, particularly in the presence of external attacks that specifically target cloud servers. Secondly, uploading data to cloud servers relinquishes the control of data owner over their data, leading to potential data inconsistency and security breaches. As a result, data may be subjected to various issues, such as theft, tampering, or forgery, thereby compromising its integrity and confidentiality. Despite the best efforts of cloud service providers to maintain data consistency, data loss events still occur frequently. For instance, in 2015, a Google Cloud server data centre was attacked, resulting in the permanent loss of a significant amount of user data. Similarly, in 2016, Uber experienced an external attack that resulted in the leakage of around 57 million user records. These events underscore the fact that data loss or leakage due to cloud service providers is a common occurrence [14]. Thus, ensuring secure and reliable data storage remains a critical research challenge.

The emergence of blockchain technology provides a promising alternative for addressing these challenges [15,16]. Blockchain possesses several essential characteristics, including transparency, tampering, and decentralization, which enable distributed data storage and consistency verification and ensure the security and privacy of data. Additionally, cross-chain technologies can facilitate data exchange and interaction among different IoT devices [17,18,19], thereby mitigating the problem of data silos and promoting further development in the IoT domain. However, ensuring secure and reliable data storage as well as achieving traceability and consistency verification of data interactions remain critical research challenges. Currently, the focus of research on addressing data consistency auditing primarily centres on traditional cloud storage. Provable data possession (PDP) [20] is a key technique for verifying data consistency, which utilizes a third-party auditor to conduct audits on the data. However, the reliability of third-party auditors cannot be guaranteed, and this approach undermines the decentralized feature of blockchain technology.

To address the above-mentioned problems, in this paper, we propose a novel blockchain-based distributed and lightweight data consistency verification model (BDCA), which ensures the consistency of data transmission during cross-chain interactions. The BDCA model comprises four entities: IoT device ($DO$), source chain ($SC$), target chain ($TC$), and audit chain ($AC$). $AC$ is a distinct chain that audits data consistency during cross-chain interactions between $SC$ and $TC$. The audit information is recorded in $AC$, which is transparent, tamper-proof, and preserves the decentralized feature of blockchain technology. To account for the possibility of data modification in the blockchain, we design a batch verification dynamic Merkle hash tree (BV-MHT), which stores the position information of the data to facilitate data location. Additionally, we utilize the auxiliary verification information form (AVF) to implement data updating and auditing with minimal overhead. Furthermore, in order to ensure the security and privacy of the transferred data, we introduce an advanced gamma multi-signature scheme (AGMS) to encrypt the exchange data between $SC$ and $TC$. The main contributions of this paper are as follows:

• We propose a novel blockchain-based distributed and lightweight data consistency verification model (BDCA), which provides robust data security and privacy guarantees. Furthermore, we demonstrate that BDCA can effectively achieve cross-chain data interaction consistency verification with minimal overhead through experimental evaluations.
• We design a batch verification dynamic Merkle hash tree (BV-MHT), which supports batch verification and dynamic data updates. Furthermore, we introduce the concept of the auxiliary verification information form (AVF) to locate the position of the stored data and improve batch validation efficiency.
• We construct random challenges and store the audit logs in the audit chain ($AC$) for future checking, enabling efficient and reliable cross-chain data consistency verification while preserving the transparency and tamper-proof feature of the blockchain.

The remainder of the paper is organized as follows. First, we summarize the related work in Section 2 and introduce preliminaries of BDCA in Section 3. Second, we format BDCA in Section 4 and Section 6. Third, we provide the security analysis and theoretically and experimentally analysis of BDCA in Section 7 and Section 8, respectively. Lastly, we summarize the paper in Section 9.

2. Related Work

2.1. Cross-Chain Technologies and Applications

With the development of cutting-edge information technology, ensuring the secure and private flow and storage of data has become an increasingly important concern. In this context, the emergence of cross-chain technology has offered a promising alternative for resolving these challenges. Currently, the mainstream cross-chain technologies include notary mechanisms [17], side/relay chain technology [18], and hash locking [19]. Cross-chain technologies have been utilized in many fields, which facilitates the further development of blockchain.

In 2019, Jiang et al. [21] proposed a cross-chain framework, which integrated multi-chains to implement efficient and secure IoT data management. In 2021, Tian et al. [22] proposed a distributed cryptocurrency trading scheme, which can implement secure and fair trading between different types of cryptocurrencies. In 2022, Xiong et al. [23] proposed a notary group-based cross-chain interaction model, which can achieve efficient interoperability between different blockchains. In 2022, Herlihy et al. [24] proposed a novel concept “cross-chain deal”, a new approach to managing the complex distributed computations and assets flow in an adversarial setting. In 2022, Li et al. [25] proposed a privacy-preserving cross-chain solution based on sidechain, which can guarantee transaction unlinkability, exchange fairness, and value confidentiality. Nevertheless, these studies mainly focused on static data flow or asset transfer while dynamic data flow and data consistency verification lack sufficient research.

2.2. Dynamic Data Integrity Auditing Scheme

Currently, dynamic data integrity auditing schemes are primarily focused on cloud scenarios. In 2007, Ateniese et al. [20] firstly proposed a provable data possession (PDP) scheme, which can implement the integrity auditing of data with high probability. In 2008, Ateniese et al. [26] improved the traditional PDP scheme and proposed a partially dynamic PDP scheme, which can implement the insertion, deletion, and modification of file blocks with a restricted limit. From then on, many kinds of research implementing dynamic data integrity auditing as well as supporting various properties in different fields have been proposed. In 2015, Tian et al. [27] proposed a privacy preservation data integrity auditing scheme, which enables efficient data updating. In 2017, Rao et al. [28] proposed a data integrity auditing scheme, which supports fully dynamic data updating and can detect malicious data owners or dishonest behaviours. In 2017, Shen et al. [29] proposed an efficient public auditing protocol, which can implement global and sampling blockless verification as well as batch auditing, utilizing a doubly linked info table and a location array. However, these studies introduce a third-party auditor (TPA), which may disrupt the decentralized feature of the blockchain and the reliability of the TPA is also not assured.

2.3. Gamma Signature Scheme

Gamma signature, originally proposed by Yao et al. [30] in 2013 as a modification of Schnorr signature [31], is characterized by a two-phase implementation: an offline phase that pre-computes partial values without any knowledge of the message to be signed and an online phase that generates the aggregated signature upon receiving the message. Compared to Schnorr signature, Gamma signature offers several advantages, including superior online performance, greater flexibility in interactive protocols, and enhanced unforgeability against concurrent interactive attacks. The advanced gamma multi-signature scheme (AGMS) is a novel multi-signature scheme based on Gamma signature, improving the efficiency and security of Gamma signature and making its application in blockchain feasible.

2.4. Merkle Hash Tree

Merkle hash tree (MHT), introduced by Merkle [32] in 1989, is a popular technique for verification and integrity checking in various applications, such as Git and Bitcoin, where it serves as an authentication scheme [33]. MHT is a binary tree composed of hash values, with leaf nodes being arbitrary hash values or those generated from pseudorandom numbers, and intermediate nodes being the hashes of their immediate children. The root of the MHT is a unique value due to the collision resistance property of the hash function, which ensures that no two hash values differing by at least one bit should be the same. To adapt MHT to the IoT environment, traditional designs have been modified. BV-MHT is a variation of the traditional MHT, where the data stored in each node is adjusted to enable efficient data updates as well as batch verification.

3. Preliminaries

3.1. Advanced Gamma Multi-Signature Scheme

The advanced gamma multi-signature scheme (AGMS) is a novel variant of the gamma signature scheme, which leverages the discrete logarithmic puzzle [34] and the efficient Schnorr signature scheme [35] to enable multiple entities to collaboratively generate an aggregated signature based on an aggregated public key. The concrete procedures of the scheme entail a rigorous and well-defined process, which are shown as follows:

• Setup$\left(1^n\right)$: take a security parameter n as the input, output a public parameter $pp=(q,\mathcal{G},g)$, where $\mathcal{G}$ is a group of prime order q and g is a generator of $\mathbb{G}$.
• KenGen$(pp)$: take a public parameter $pp$ as the input, randomly choose ${\left\{s{k}_{ij}\right\}}_{i\in [1,n],j\in U_i}$$\in {\mathcal{Z}}_N$, compute ${\{p{k}_{ij}=g^{s{k}_{ij}}\}}_{i\in [1,n],j\in U_i}$, and output ${\left\{(p{k}_{ij},s{k}_{ij})\right\}}_{i\in [1,n],j\in U_i}.$
• KeyAgg$({\left\{p{k}_{ij}\right\}}_{i\in [1,n],j\in U_i})$: take the public key $\left({\left\{p{k}_{ij}\right\}}_{i\in [1,n],j\in U_i}\right)$ as the input, compute the aggregated public key $PK=\mathsf{\prod }_{i\in [1,k]}(\mathsf{\prod }_{j\in U_i}p{k}_{ij})$, and output $PK$.
• Sign$(msg,V^{\ast },PK)$: take the message m, an aggregation commitment $V^{\ast }$, and an aggregation public key $PK$ as the input, and output a signature $(c,Sig)$.
• Verify$(pp,V^{\ast },V^{{\ast }^{\prime }})$: take the message m, aggregated commitment $V^{\ast }$, and $V^{{\ast }^{\prime }}$ as the input, and output $0/1$ to indicate whether the message $msg$ is invalid or valid.

3.2. Bilinear Map

Let ${\mathcal{G}}_1$, ${\mathcal{G}}_2$, and ${\mathcal{G}}_T$ be a multiplicative cyclic additive group with the same order q. The map $e:{\mathcal{G}}_1\times {\mathcal{G}}_2\to {\mathcal{G}}_T$ is a bilinear pairing only if the following properties are satisfied:

• Bilinearity: For any $a,b\in Z_q^{\ast }$, $x\in {\mathcal{G}}_1$, and $y\in {\mathcal{G}}_2$, $e(x^a,y^b)=e{(x,y)}^{ab}$.
• Non-degeneracy: For any $x\in {\mathcal{G}}_1$ and $y\in {\mathcal{G}}_2$, if $e(x,y)=1$ only if $x=1$ or $y=1$.
• Computability: There exists an efficiently computable homomorphism between ${\mathcal{G}}_1$ and ${\mathcal{G}}_2$.

3.3. Mathematical Assumptions

Let $\mathcal{G}$ be an additive cyclic group of prime order q and $a,b$ be random elements of ${\mathcal{Z}}_N$.

• Discrete logarithm (DL) assumption. Given $g,g^a\in \mathcal{G}$ as the input, it is computationally infeasible to compute a. That is, for any PPT adversary $\mathcal{A}$, the probability of solving the DL problem is negligible in $\mathcal{G}$.
• Computational Diffie–Hellman (CDH) assumption. Given $g,g^a,g^b\in \mathcal{G}$ as the input, it is computationally infeasible to compute $g^{ab}$. That is, for any PPT adversary $\mathcal{A}$, the probability of solving the CDH problem is negligible in $\mathcal{G}$.

4. Models

In this section, we describe the architecture of BDCA in Section 5.1 and then lay out its threat model in Section 5.2. Finally, we introduce the design goals of BDCA in Section 5.3. Furthermore, some additional notations and descriptions are defined in

Table 1. Notations and descriptions.

Notations	Descriptions
M	The original data
$M^{\ast }$	The blinded data
$M^{{\ast }^{\prime }}$	The updated data
d	A public key of $D{O}_i$
$\{e,u\}$	A private key of $D{O}_i$
n	System security parameter
$T{x}_1$	Data uploading transaction
$T{x}_2$	Data updating request transaction
$D{O}_{s_0}$	The leader of all the signers in blockchain
$D{O}_S$	The IoT device of $SC$
$D{O}_T$	The IoT device of $TC$
$\varpi$	The threshold number of signers

.

5. The Proposed BDCA

5.1. System Model

The architectural diagram depicted in Figure 1 illustrates the configuration of BDCA, comprising three distinct consortium blockchains based on Hyperledger Fabric technology: the source chain ($SC$), the target chain ($TC$), and the audit chain ($AC$). The innovative model BDCA enables the secure and seamless exchange of data between the two different chains while ensuring data integrity through the implementation of an audit chain ($AC$) for data consistency verification as well as maintaining the decentralized feature of BDCA [36]. To further enhance the reliability and functionality of BDCA, three smart contracts are deployed within the system, each specifically allocated to $SC$, $TC$, and $AC$, respectively. The four principal entities comprising BDCA are IoT devices ($DO$), source chain ($SC$), target chain ($TC$), and audit chain ($AC$) with each entity bearing unique responsibilities and obligations as follows:

• IoT device ($DO$): $DO$ is an entity that is responsible for processing and storing the original data M, and initiating data update requests to the source chain ($SC$). To ensure the security and privacy of the data, $DO$ preprocesses M into blinded data $M^{\ast }$ before generating authentication tags for $M^{\ast }$. Once $DO$ has generated the authentication tags for $M^{\ast }$, it transfers the blinded data and corresponding tags to the audit chain ($AC$) for secure storage. Within the BDCA model, there are two distinct $DO$ entities, namely $D{O}_S$ and $D{O}_T$, which are deployed within the source chain ($SC$) and target chain ($TC$), respectively.
• Source chain ($SC$): $SC$ is an entity that serves as the primary repository for data received from $DO$ and facilitates the exchange of data with the target chain ($TC$). Upon receiving data update requests from $D{O}_S$, $SC$ is responsible for updating the data accordingly and synchronizing the data updates with $TC$ to ensure consistency across the two chains. In addition, $SC$ is programmed to respond to audit challenges issued by the audit chain ($AC$) by generating an audit proof that verifies the consistency and accuracy of the data stored within the system. Once the audit proof is generated, $SC$ sends it to $AC$ for data consistency verification, ensuring that the data remains secure and reliable.
• Target chain ($TC$): $TC$ is an entity that is responsible for receiving data from the source chain ($SC$) and facilitates data exchange between the two chains. Upon receiving data update requests from $SC$, $TC$ updates the data as required, ensuring that the data remains consistent across both chains. Like $SC$, $TC$ also responds to audit challenges from the audit chain ($AC$) by generating storage proofs that verify the integrity and accuracy of the data stored within the system. Once the storage proof is generated, $TC$ sends it to $AC$ for data consistency verification, ensuring that the data remains secure and reliable.
• Audit chain ($AC$): $AC$ is an entity that is established and overseen by national regulatory authorities. $AC$ is responsible for conducting data consistency verification between the source chain ($SC$) and the target chain ($TC$) based on the audit proof and storage proof received from $SC$ and $TC$, respectively. Through its advanced data consistency verification protocols, $AC$ ensures that the data exchanged between $SC$ and $TC$ remains accurate and consistent, preventing any unauthorized modifications or tampering.

5.2. Threat Model

In BDCA, the auditing mechanism is facilitated by $AC$ and its associated smart contract, which are deployed by national regulatory authorities. The audit process is transparent and tamper-proof, thereby instilling trust in the reliability of $AC$. Furthermore, it is worth noting that the introduction of the auditing mechanism facilitated by $AC$ does not compromise the decentralized feature of the blockchain owing to the openness and transparency of the audit process, ensuring that the regulatory oversight is conducted in a fair and impartial manner. The introduction of $AC$ can be viewed as a complementary measure that enhances the security and reliability of cross-chain transactions. Furthermore, $DO$ is entrusted with the responsibility of processing the original data and transmitting it to $SC$ for storage. However, $SC$ is considered semi-honest, which implies that it may have a vested interest in the content of the received data. Similarly, $TC$ is also semi-honest and may resort to forging storage proof to bypass the consistency verification process of $AC$. In conclusion, there are mainly the following types of cross-chain attacks:

• Tampering attacks: The transferred data $F^{{}^{\prime }}$, corresponding tags, and data update requests may be tampered with or forged by an adversary in the process of cross-chain interaction.
• Privacy leakage attacks: The content of the transferred data $F^{{}^{\prime }}$, corresponding tags, and data update requests may be leaked and expose the private information of $DO$ in the process of cross-chain interaction.
• Audit inconsistency attacks: The $TC$ may pretend to forge a storage proof to pass the data consistency verification of $AC$ to conceal its incomplete data storage or updates.

5.3. Design Goals

Based on the above analysis of BDCA, in order to ensure the security and privacy of the transferred data and guarantee the consistency of data interactions between $SC$ and $TC$, we propose the following design goals:

• Consistency: BDCA can ensure the consistency of the data interaction between $SC$ and $TC$ and when $TC$ modifies or does not update the data as requested, it cannot pass the consistency verification by $AC$.
• Privacy: BDCA can ensure the privacy of the transferred data. $SC$ and $TC$ cannot gain any private information of $DO$ in the process of cross-chain data interaction.
• Dynamic operations: BDCA can allow $DO$ to perform data update operations at will with low overhead, including insertions, deletions, and modifications.
• Security: BDCA can ensure that the data updates operations, including insertions, deletions, and modifications, are conducted only by the owner of the data.

6. The Proposed BDCA

In this section, we present a detailed description of the proposed BDCA, highlighting how dynamic data consistency audits can be implemented in the process of cross-chain interaction. In general, BDCA comprises five essential procedures, which include: system initialization, data processing, data uploading, data updating, and data auditing.

6.1. System Initialization

In this phase, $DO$ in BDCA generates its public and private key pair and outputs the public parameters of BDCA as follows:

• Upon receiving a security parameter $1^n$, each $DO$ in BDCA selects four random large prime p, q, $p^{{}^{\prime }}$, and $q^{{}^{\prime }}$. Meanwhile, $DO$ computes RSA modulus $N=pq$ and selects a generator g of ${\mathcal{QR}}_N$, where $p=2p^{{}^{\prime }}+1$, $q=2q^{{}^{\prime }}+1$, and ${\mathcal{QR}}_N$ is a multiplicative cyclic group of quadratic residues modulo N.
• BDCA then selects a hash function $H_1:{\{0,1\}}^{\ast }\to {\mathcal{Z}}_N$, a pseudo-random permutation $\mathcal{F}:{\{0,1\}}^{k_1}\times {\{0,1\}}^{lo{g}_2^n}\to {\{0,1\}}^{lo{g}_2^n}$, and a pseudo-random function (PRF) $\mathcal{A}:{\{0,1\}}^{k_2}\times {\{0,1\}}^{lo{g}_2^n}\to {\mathcal{Z}}_N$.
• BDCA then selects a security random large prime e as the public key and computes the private key d, where $e·d\equiv 1\left(mod\left(p^{{}^{\prime }}{q}^{{}^{\prime }}\right)\right)$, u is a security random large prime, and $u\ne d$.
• BDCA then generates a public key and private key pair $\{pk=e, sk=(d, u\left)\right\}$ and outputs the public parameters $par=\{g, e, N, H_1, \mathcal{F}, \mathcal{A}, {\mathcal{QR}}_N\}$.

6.2. Data Processing

In this phase, $D{O}_S$ first preprocesses the original data M and constructs the BV-MHT and auxiliary verification information form (AVF). Then, $D{O}_S$ uploads the processed datasets to $SC$ for storage, the specific steps are shown as follows:

• Given a original data file $M\in {\{0,1\}}^{\ast }$, $D{O}_S$ splits M into k blocks, represented as ${m_i}_{i\in [1,k]}$. Note that if the last block is not the same size as the other blocks, $D{O}_S$ pads 0 at the end of the last block. In order to protect the security and privacy of M, $D{O}_S$ applies a blind signature technique by creating a blinded version of M, denoted as $M^{\ast }$, with ${\left\{m_i^{\ast }\right\}}_{i\in [1,k]}={\left\{m_i\right\}}_{i\in [1,k]}+H_1(md\left|\right|a_d)$, where $md\in {\{0,1\}}^{\ast }$ is the unique identification of M, $a_d\in {\mathcal{Z}}_N$ is a random number, and $H_1$ is a one-way hash function. Additionally, $D{O}_S$ calculates a verification value $A_d=g^{a_d}$, where g is a generator of a cyclic group $\mathcal{G}$, and N is the order of $\mathcal{G}$.
• $D{O}_S$ constructs the batch verification Merkle hash tree (BV-MHT) based on the processed data to facilitate efficient and secure data auditing. In BV-MHT, each node $\nu$ stores a tuple ($l_{\nu },r_{\nu },h_{\nu }$), which represents the position information of the node $\nu$ in BV-MHT. Specifically, if the node $\nu$ is the i-th leaf node ${\tau }_i$, $r_{\nu }$ is set to 1 and $h_{\nu }=H_1\left(m_i^{\ast }\right)$. If the node $\nu$ is a non-leaf node $\chi$, $r_{\nu }$ stores the number of the leaf nodes that $\chi$ can reach from the left to right and $h_{\nu }=H_1(r_{\nu }\left|\right|h_{lef{t}_{\chi }}\left|\right|h_{righ{t}_{\chi }})$, where $h_{lef{t}_{\chi }}$ and $h_{righ{t}_{\chi }}$ denote the left and right child nodes of $\chi$ [37]. If the node $\nu$ is the left child node of its parent node, $l_{\nu }$ is set to 0; the node $\nu$ is the right child node of its parent node, $l_{\nu }$ is set to 1; the node $\nu$ is the root of the BV-MHT, $l_{\nu }$ is set to 2. The process of constructing BV-MHT is shown in Figure 2 and the nodes $\{{\tau }_2,{\tau }_4,{\tau }_7\}$ are verified simultaneously.
• $D{O}_S$ constructs the auxiliary verification information form (AVF) to implement the batch verification and accelerate the process of batch verification. In traditional MHT, the i-th leaf node can only be verified one by one with its siblings on the path from the i-th leaf node to the root. For instance, if the nodes $\{{\tau }_2,{\tau }_4,{\tau }_7\}$ want to be verified simultaneously, they need to generate the auxiliary verification information ${\omega }_{{\tau }_2}=\{{\tau }_1,{\chi }_{10},{\chi }_{14}\}$, ${\omega }_{{\tau }_4}=\{{\tau }_3,{\chi }_9,{\chi }_{14}\}$, and ${\omega }_{{\tau }_7}=\{{\tau }_8,{\chi }_{11},{\chi }_{13}\}$, respectively. The node ${\chi }_{14}$ will be retrieved twice, which will cause more overhead. Furthermore, as the number of verified nodes simultaneously increases, the number of duplicate retrieval nodes increase. From the perspective of saving verification overhead, we introduce a concept auxiliary verification information form (AVF) in BV-MHT, as an example is shown in

  Table 2. Auxiliary verification information form (AVF).

  AVI${}_{\mathit{i},\mathit{j}}$	$\mathit{j}=1$	$\mathit{j}=2$	$\mathit{j}=3$
  $i=1\left(Poin{t}_1\right)$	${\tau }_1$	$Poin{t}_2$	$Poin{t}_3$
  $i=2\left(Poin{t}_2\right)$	${\tau }_3$	$NULL$	$NULL$
  $i=3\left(Poin{t}_3\right)$	${\tau }_8$	${\chi }_{11}$	$NULL$

  , the nodes $\{{\tau }_2,{\tau }_4,{\tau }_7\}$ can be verified simultaneously by retrieving the AVF${}_{r\times t}$, where r is the number of the nodes verified simultaneously, t is the max layer of the leaf nodes in BV-MHT, and $Point$ is a point that points to the different line in AVF${}_{r\times t}$. The specific procedures of constructing AVF${}_{r\times t}$ are shown in Algorithm 1. Finally, $D{O}_S$ invokes Algorithm 1 to generate an AVF${}_{1\times t}\left({\nu }_k\right)$ for the last leaf node ${\nu }_k$.
• $D{O}_S$ generates the authenticated tags of the transferred data ${\left\{m_i^{\ast }\right\}}_{i\in [1,k]}$ with Equation (1) and uploads the datasets $D{S}_1={\left\{(m_i^{\ast },{\zeta }_i)\right\}}_{i\in [1,k]},\{k,h_{root}\},\{v_k$, AVF${}_{1\times t}\left({\nu }_k\right)\left\}\right\}$ to $SC$ for storage.

  $$\zeta ={(g^{h_{{\nu }_i}}·g^{m_i^{\ast }})}_{i\in [1,k]}^d.$$

  (1)
• After receiving the datasets $D{S}_1$ from $D{O}_S$, $SC$ generates a data-uploading transaction $T{x}_1$ and sends $T{x}_1$ to $TC$:

  $$T{x}_1=[“Upload”,p{k}_{D{O}_S},D{S}_1].$$

Algorithm 1 Constructing the auxiliary verification information form (AVF${}_{r\times t}$).

Input: BV-MHT, index sets $\{d_1,d_2\dots d_r\}(d_1<d_2<\dots <d_r)$ of the verified leaf nodes. Output: AVF${}_{r\times t}$. 1: i = 1; 2: while i <= r do 3:     LN[i] = ${\nu }_{d_i}$; 4:     i = i + 1; 5: end while 6: j = 1, Q = t; 7: while Q > 0 do 8:     for i = 1, 2, …, r do 9:         $\varrho$ = LN[i]; 10:         if $\varrho$≠ NULL then 11:            if the layer number of $\varrho$ == Q then 12:                if $\varrho$ exists sibling node $\kappa$ in current LN[] then 13:                    AVF[i][j] = “$Poin{t}_{\iota }$” ($\iota \in (1,r]$); 14:                    LN[$\iota$] = NULL; 15:                else $\varrho$ does not exist sibling node $\kappa$ in current LN[] 16:                    AVF[i][j] = $\kappa$; 17:                end if 18:                LN[i] = the parent node of $\varrho$; 19:            else the layer number of $\varrho$≠ Q 20:                AVF[i][j] = NULL; 21:            end if 22:         else $\varrho$ == NULL 23:            AVF[i][j] = NULL; 24:         end if 25:     end for 26:     j = j + 1, Q = Q − 1; 27: end while 28: return AVF${}_{r\times t}$;

6.3. Data Uploading

In this phase, $SC$ encrypts the uploaded transaction $T{x}_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 $T{x}_1$ and obtain the signature ($c,sig$). Then, $SC$ sends the signature ($c,sig$), $T{x}_1$, and $P{K}_{leader}$ to $TC$.

Algorithm 2 Advanced gamma multi-signature scheme.

Input: The message $msg$ to be signed, the public key sets of the signers $keys={\left\{p{k}_i\right\}}_{i\in [1,\varpi ]}$, the threshold number $\varpi$ of signers, and the public key of the leader $p{k}_{leader}$. Output: The multi-signature ($c,sig$). 1: Randomly select a random value $v_i$, compute $V_i=g^{v_i}$; 2: Compute the partial aggregated public key $P{K}_{signers}={\mathsf{\prod }}_{i\in [1,\varpi ]}p{k}_i$ and the partial aggregated commitment $V_{signers}={\mathsf{\prod }}_{i\in [1,\varpi ]}{V}_i$; 3: Compute the complete aggregated public key $P{K}_{leader}=P{K}_{signers}·p{k}_{leader}$ and the complete aggregated commitment $V_{leader}=V_{signer}·V_{leader}$; 4: Compute the collective challenge $c=H_1(g,V_{leader},P{K}_{leader})$; 5: Compute the hash of the signed message $hv=H_1\left(msg\right)$ and the partial aggregated signature $si{g}_{signer}={\sum }_{i\in [1,\varpi ]}si{g}_i={\sum }_{i\in [1,\varpi ]}{v}_i·c-hv·d_i$; 6: Compute the signature $sig=si{g}_{leader}+si{g}_{signer}$; 7: Output the signature ($c,sig$)

Upon receiving the signed transaction $T{x}_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 $T{x}_1$ before it is stored on the blockchain.

• $TC$ computes $hv=H_1\left(msg\right)$ and $\tilde{V}={\left(g^{sig}P{K}_{leader}^{hv}\right)}^{c^{-1}}$.
• $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 $T{x}_1$.

  $$c\stackrel{?}{=}{H}_1(g,\tilde{V},P{K}_{leader}).$$

  (2)
• $TC$ verifies the correctness of $\{k,h_{root}\}$ by checking whether the hash value $H_1\left(m_k^{\ast }\right)$ based on the datasets ${\left\{m_i^{\ast }\right\}}_{i\in [1,k]}$ is equal to $h_{{\nu }_k}$ of the node ${\nu }_k$. If the verification passes, $TC$ continues to conduct the following verification; otherwise, $T{x}_1$ is invalid, and $TC$ rejects to store $T{x}_1$.
• $TC$ invokes Algorithm 3 to verify the correctness of AVF${}_{1\times t}\left(v_k\right)$. If the algorithm outputs 0, $TC$ rejects to storage of $T{x}_1$; otherwise, $TC$ stores $T{x}_1$ and returns its acceptance and signature of $D{O}_T$. It is worth noting that we assume that $PI :=\left\{({\alpha }_i,{\beta }_i)\right|{\alpha }_i,{\beta }_i\in {\mathcal{Z}}_N,i\in [1,\vartheta ]\}$ is a $\vartheta$ size set. For any element $y\in {\mathcal{Z}}_N$, the set operations ’±’ of $PI$ are described as follows:

  $$\begin{array}{c}\hfill \{PI\pm y\}=\left\{\right(PI\left(\alpha \right)\pm y),(PI\left(\beta \right)\pm y\left)\right\},\end{array}$$

  where $PI\left(\alpha \right)\pm y :=\left\{({\alpha }_i\pm y,{\beta }_i)\right){\}}_{i\in [1,\vartheta ]},PI\left(\beta \right)\pm y :={\left\{({\alpha }_i,{\beta }_i\pm y)\right\}}_{i\in [1,\vartheta ]}.$ Furthermore, the operation $Union(P{I}_i,P{I}_j)$ is described as follows:

  $$Union(P{I}_i,P{I}_j)={\{({\alpha }_i,{\beta }_i),({\alpha }_j^{{}^{\prime }},{\beta }_j^{{}^{\prime }})\}}_{i\in [1,{\vartheta }_1],j\in [1,{\vartheta }_2]},$$

  where $P{I}_i={\left\{({\alpha }_i,{\beta }_i)\right\}}_{i\in [1,{\vartheta }_1]}$ and $P{I}_j={\left\{({\alpha }_j,{\beta }_j)\right\}}_{j\in [1,{\vartheta }_2]}$.

6.4. Data Updating

In this phase, when $D{O}_S$ wants to update the data stored in $SC$ at will, $D{O}_S$ generates a data updating request $req$ and sends it to $SC$. $SC$ updates the data as the request $req$ and sends a data update request transaction $T{x}_2$ to $TC$. $TC$ updates the data as the transaction $T{x}_2$. In general, data update operations include $Insertion\left(I\right)$, $Modification\left(M\right)$, and $Deletion\left(D\right)$. It is imperative to highlight that the process of updating data in this paper is instigated by the user node that initially generated the data. Each data update request is accompanied by a public key signature from the data update user node and the execution of the data update operation is contingent upon its successful verification by a majority of nodes in the blockchain. Specifically, the data update operation must be approved by more than 50% of the user nodes in blockchain. The robust approach of this paper provides a high level of security against potential security threats, such as the malicious random or chosen node or link to a blockchain node deletion and the integrity and security of the blockchain are safeguarded. The specific process is shown as follows:

Modification: Assume that $D{O}_S$ wants to modify the i-th leaf node into $m_i^{{\ast }^{\prime }}$ at $t{s}_2$ (e.g., modify $m_4^{\ast }$ into $m_4^{{\ast }^{\prime }}$ in Figure 3b).

• $D{O}_S$ calculates $H_1\left(m_i^{{\ast }^{\prime }}\right)=h_i^{\ast }$ and ${\zeta }_i^{\ast }={(g^{h_i^{\ast }}·g^{m_i^{{\ast }^{\prime }}})}^d$.
• $D{O}_S$ invokes Algorithm 1 to generate an auxiliary verification information form AVF${}_{1\times t}$.
• $D{O}_S$ modifies the original node into ${\nu }_i^{\ast }=\{l_{{\nu }_i^{\ast }},r_{{\nu }_i^{\ast }},h_i^{\ast }\}$ and updates the BV-MHT by recalculating all the nodes on the path from the node ${\nu }_i^{\ast }$ to the root, generating a new hash root $h_{root}^{\ast }$.
• $D{O}_S$ generates a data update request $req=\{t{s}_2,Modify,i,h_i^{\ast },AV{F}_{1\times t},h_{root}^{\ast },m_i^{\ast },$$p{k}_{D{O}_S}\}$ and sends it to $SC$.
• $SC$ verifies the request $req$ with Algorithm 3 and updates the data as the request $req$, generating a new transaction linked to the original blockchain network. Then, $SC$ generates a data update transaction $T{x}_2$ and encrypts $T{x}_2$ with AGMS in a similar process in Section 6.3 and uploads $T{x}_2$ to $TC$.

  $$T{x}_2=[“Update”,req]$$
• After receiving the transaction $T{x}_2$, $TC$ first verifies the correctness and validity of the received transaction in a similar way in Section 6.3. If the verification is valid, $TC$ updates the BV-MHT as requested; otherwise, $TC$ rejects to update the transaction.

Algorithm 3 Batch verification.

Input: Index sets $\{d_1, d_2, \dots , d_r\}(d_1<d_2<\dots <d_r)$ of the verified leaf nodes, the number of all blocks k, the corresponding hash root of BV-MHT based on the batch verified nodes $h_{root}$, and AVF${}_{r\times t}$. Output: 0/1. 1: i = 1; 2: while i <= r do 3:     $P{I}_i$= $\left\{(k,{\gamma }_{\nu d_i}-1)\right\}$; 4:     ${\mathsf{\Gamma }}_i={\gamma }_{\nu d_i}$; 5:     ${\mathsf{{\rm Y}}}_i=h_{\nu d_i}$; 6:     i = i + 1; 7: end while 8: $Point\_Sets=\{1,2, \dots ,r\}$; 9: for i = 1, 2, …, t do 10:     for j = 1, 2, …, r do 11:         if AVF[i][j] == NULL then 12:            continue; 13:         else if AVF[i][j] is a leaf or non-leaf node ${\nu }_x$ then 14:            ${\mathsf{\Gamma }}_i={\mathsf{\Gamma }}_i+r_{{\nu }_x}$; 15:            if $l_{{\nu }_x}==1$ then 16:                ${\mathsf{{\rm Y}}}_i=H_1({\mathsf{\Gamma }}_i\left|\right|{\mathsf{{\rm Y}}}_i\left|\right|h_{{\nu }_x})$; 17:                $P{I}_i=P{I}_i\left(\alpha \right)-r_{{\nu }_x}$; 18:            else if $l_{{\nu }_x}==0$ then 19:                ${\mathsf{{\rm Y}}}_i=H_1({\mathsf{\Gamma }}_i\left|\right|h_{{\nu }_x}\left|\right|{\mathsf{{\rm Y}}}_i)$; 20:                $P{I}_i=P{I}_i\left(\beta \right)+r_{{\nu }_x}$; 21:            else $l_{{\nu }_x}==2$ 22:                return 0; 23:            end if 24:         else AVF[i][j] is a point $Poin{t}_{\delta }$, $\delta \in (1,r]$ 25:            $P{I}_{\delta }=P{I}_{\delta }\left(\beta \right)+{\mathsf{\Gamma }}_i$; 26:            ${\mathsf{\Gamma }}_i={\mathsf{\Gamma }}_i+{\mathsf{\Gamma }}_{\delta }$; 27:            ${\mathsf{{\rm Y}}}_i=H_1({\mathsf{\Gamma }}_i\left|\right|{\mathsf{{\rm Y}}}_i\left|\right|{\mathsf{{\rm Y}}}_{\delta })$; 28:            $P{I}_i=P{I}_i\left(\alpha \right)-{\mathsf{\Gamma }}_{\delta }$; 29:            $P{I}_i=Union(P{I}_i,P{I}_{\delta })$; 30:            remove $\delta$ from $Point\_Sets$; 31:         end if 32:     end for 33: end for 34: if  $P{I}_1\ne \{(d_1,d_1-1),(d_2,d_2-1), \dots ,(d_r,d_r-1)\}$  then 35:     return 0; 36: else if ${\mathsf{\Gamma }}_1\ne k$ or ${\mathsf{{\rm Y}}}_1\ne h_{root}$ then 37:     return 0; 38: else 39:     return 0; 40: end if

Deletion: Assume that $D{O}_S$ wants to delete the i-th leaf node at $t{s}_2$ (e.g., delete $m_4^{\ast }$ in Figure 3c).

• $D{O}_S$ generates the data updates request $req=\{t{s}_2,delete,i,AF{V}_{1\times t},h_{root}^{\ast },p{k}_{D{O}_S}\}$ and updates the BV-MHT on the path from the node ${\nu }_i$ to the root. Then, $D{O}_S$ sends it to $SC$.
• $SC$ verifies and updates the BV-MHT in a similar way as above, and generates a data update transaction $T{x}_2$ encrypted with AGMS. Then, $T{x}_2$ is sent to $TC$ for data updating.

  $$T{x}_2=[“Update”,req]$$
• $TC$ updates the data in a similar way as above.

Insertion: Assume that $D{O}_S$ wants to insert a new node after the i-th leaf node at $t{s}_2$ (e.g., insert $m_4^{{}^{\prime }}$ after $m_4$ in Figure 3d).

• $D{O}_S$ generates the data updates request $req=\{t{s}_2,insert,i,h_i^{{}^{\prime }},m_i^{{}^{\prime }},AF{V}_{1\times t},h_{root}^{\ast },p{k}_{D{O}_S}\}$ and updates the BV-MHT on the path from the node ${\nu }_i$ to the root, where ${\nu }_i^{{}^{\prime }}=\{l_i,r_i+1,H_1(r_i+1\left|\right|h_i\left|\right|h_i^{{}^{\prime }}\left)\right\}$. Then, $D{O}_S$ sends it to $SC$.
• $SC$ verifies and updates the BV-MHT in a similar way as above, and generates a data update transaction $T{x}_2$ encrypted with AGMS. Then, $T{x}_2$ is sent to $TC$ for data updating.

  $$T{x}_2=[“Update”,req]$$
• $TC$ updates the data in a similar way as above.

6.5. Data Auditing

In this phase, $AC$ periodically constructs a random challenge to verify the consistency between $SC$ and $TC$ in order to ensure the integrity and reliability of BDCA. It is important to note that all entities involved, including $SC$, $TC$, and $AC$, should utilize a uniform time standard and the time interval for the audit should be fixed. The detailed process is shown as follows:

• $AC$ constructs a random challenge:

  $$cha{l}^{\left(t{s}_1\right)}={\{t{s}_1,{\lambda }_{\phi }^{\left(t{s}_1\right)},{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}\}}_{\phi \in [1,c]},{\lambda }_{\phi }^{\left(t{s}_1\right)}\in [1,k],{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}\in {\mathcal{Z}}_N$$

  (3)

  where ${\{{\mathcal{F}}_{k_1^{\left(t{s}_1\right)}}\left(\phi \right)={\lambda }_{\phi }^{\left(t{s}_1\right)}\}}_{\phi \in [1,c]}$ represents the index set of the c challenged block, ${\{{\mathcal{A}}_{k_2^{\left(t{s}_1\right)}}\left(\phi \right)={\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}\}}_{\phi \in [1,c]}$ denotes the corresponding coefficient set of the challenged block, $k_1^{\left(t{s}_1\right)}=H_2(t{s}_1\left|\right|va{l}^{\left(t{s}_1\right)})$, $k_2^{\left(t{s}_1\right)}=H_3(t{s}_1\left|\right|no{n}^{\left(t{s}_1\right)})$, $H_2$ is a hash function that transforms the set ${\{0,1\}}^{\ast }$ to the space of $\mathcal{F}$, $H_3$ is a hash function that transforms the set ${\{0,1\}}^{\ast }$ to the space of $\mathcal{A}$ [38], $va{l}^{\left(t{s}_1\right)}$ is the number of blocks in $TC$ and $no{n}^{\left(t{s}_1\right)}$ is the random value closest to the nearest the timestamp $t{s}_1$. Due to the unpredictability and non-repudiation of $va{l}^{\left(t{s}_1\right)}$ and $no{n}^{\left(t{s}_1\right)}$, the challenge $cha{l}^{\left(t{s}_1\right)}$, which is undeniable, can be constructed by $AC$.
• $AC$ sends the challenge $cha{l}^{\left(t{s}_1\right)}$ to $SC$ and $TC$.
• Upon receiving the challenge $chal$ from $AC$, $TC$ selects a secret random value $r^{\left(t{s}_1\right)}\in {\mathcal{Z}}_N$ and generates a storage proof:

  $$proo{f}_{TC}=\{{\zeta }^{\left(t{s}_1\right)},{\mu }^{\left(t{s}_1\right)},g^{\left(t{s}_1\right)},u^{\left(t{s}_1\right)}\},$$

  where ${\zeta }^{\left(t{s}_1\right)}={\mathsf{\prod }}_{\phi \in [1,c]}{\zeta }_{{\lambda }_{\phi }^{\left(t{s}_1\right)}}^{{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}}\left(modN\right)$, ${\mu }^{\left(t{s}_1\right)}=r^{\left(t{s}_1\right)}+{\sum }_{\phi \in [1,c]}{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}·m_{{\lambda }_{\phi }^{\left(t{s}_1\right)}}$, $g^{\left(t{s}_1\right)}=g^{r^{\left(t{s}_1\right)}}$, $u^{\left(t{s}_1\right)}=g_u{\sum }_{\phi \in [1,c]}{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}·m_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}modN$, and $g_u=g^u$.
• $TC$ sends the proof $proo{f}_{TC}$ and its signature $p{k}_{D{O}_T}$ used to provide non-repudiation to $AC$ for consistency verification.
• $SC$ generates an audit proof and sends the proof $proo{f}_{SC}$ with its signature $p{k}_{DOS}$ to $AC$ for consistency verification.

  $$proo{f}_{SC}=\{AV{F}_{c\times t},h_{\mathrm{root}}^{\left(t{s}_1\right)},{\left\{h_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}\right\}}_{\phi \in [1,c]}\}$$
• Upon receiving the proof from $SC$ and $TC$. $AC$ calculates the verification information ${\mathsf{\Omega }}^{\left(t{s}_1\right)}$ based on the $proo{f}_{SC}$:

  $${\mathsf{\Omega }}^{\left(t{s}_1\right)}=\mathsf{\prod }_{\phi \in [1,c]}{g}^{{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}·h_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}}modN.$$
• AC checks the signature of $p{k}_{D{O}_S}$ and $p{k}_{D{O}_T}$, then verifies the correctness of $proo{f}_{TC}$ with Equation (4). If the equation verification fails, $TC$ may not store the data as required and $AC$ notifies $SC$ about the exceptional situation; otherwise, $AC$ generates an audit log $ro{d}^{\left(t{s}_1\right)}=\left\{\mathrm{chal}{}^{\left(t{s}_1\right)},{\mathsf{\Omega }}^{\left(t{s}_1\right)},{proof}_{TC},{proof}_{AC},p_{D{O}_S},p{k}_{D{O}_T}\right\}$ and stores $ro{d}^{\left(t{s}_1\right)}$ on the blockchain for further checking logs.

  $${\left({\zeta }^{\left(t{s}_1\right)}\right)}^e·g^{\left(t{s}_1\right)}(mod N)\stackrel{?}{=}{\mathsf{\Omega }}^{\left(t{s}_1\right)}·g^{{\mu }^{\left(t{s}_1\right)}}(mod N).$$

  (4)

7. Security Analysis

In this section, we conduct a series of theoretical analyses to prove the security of BDCA. We first provide a security proof of the advanced gamma multi-signature scheme (AGMS) and then prove that BDCA can achieve the design goals defined in Section 5.3. The detailed security proofs are shown as follows:

Theorem 1.

The security of AGMS can be assured under the assumption that the computation of discrete logarithms is a computationally infeasible problem.

Proof. 

The idea behind the proof lies in the notion that if it were computationally feasible to fabricate the signature of AGMS, it would imply that adversary $\mathcal{A}$ has the ability to circumvent the discrete logarithm (DL) assumption [39]. Otherwise, if the DL assumption holds, then the security of AGMS can be ensured, thereby preventing potential cross-chain tampering attacks and privacy leakage attacks. We assume that adversary $\mathcal{A}$ has the ability to resolve the DL assumption in $\mathcal{G}$, which can forge a signature $\left(c^{\ast },{sig}^{\ast },h{v}^{\ast }\right)$ to pass the verification. Thus, we can deduce Equation (5):

$$\begin{array}{cc}\hfill g^{sig}& =V_{\mathrm{leader}}^c·P{K}_{\mathrm{leader}}^{-hv}=V_{\mathrm{leader}}^c\mathsf{\prod }_{i\in [1,\omega ]}p{k}_i^{-hv}\hfill \\ \hfill g^{\mathrm{sig}}& =V_{\mathrm{leader}}^{c^{\ast }}·P{K}_{\mathrm{leader}}^{-h{v}^{\ast }}=V_{\mathrm{leader}}^{c^{\ast }}\mathsf{\prod }_{i\in [1,\omega ]}p{k}_i^{\ast -h{v}^{\ast }},\hfill \end{array}$$

(5)

where ${\left\{p{k}_i\right\}}_{i\in [1,\omega ]}$ and ${\left\{p{k}_i^{\ast }\right\}}_{i\in [1,\omega ]}$ are two public key sets aiming to forge the signature. We can conclude that the signature can be forged successfully only if $V_{\mathrm{leader}}^c=V_{\mathrm{leader}}^{c^{\ast }},c^{-1}hv=$$c^{\ast -1}h{v}^{\ast }$, and ${\left\{p{k}_i^{-hv}\right\}}_{i\in [1,\omega ]}={\left\{p{k}_i^{\ast -h{v}^{\ast }}\right\}}_{i\in [1,\omega ]}$. Hence, we can deduce Equation (6).

$$\begin{array}{c}{V}_{\mathrm{leader}}=g^{\mathrm{sigc}}{}^{-1}\mathsf{\prod }_{i\in [1,\omega ]}p{k}_i^{c^{-1}}hvs.\hfill \\ V_{\mathrm{leader}}=g^{{\mathrm{sig}}^{\ast }{c}^{\ast -1}}\mathsf{\prod }_{i\in [1,\omega ]}p{k}_i^{c^{\ast -1}h{v}^{\ast }}\hfill \end{array}$$

(6)

Based on Equation (6), we can obtain Equation (7) and it can be asserted that $\mathcal{A}$ has the capability to generate all possible private keys with the exception of its own if $c^{\ast }=c$ and $e^{\ast }=e$ from Equation (7). According to [40], it can be concluded that the likelihood of the adversary $\mathcal{A}$ succeeding in generating two distinct outputs that satisfy the verification criteria is exceedingly small. As a consequence, the robustness of the AGMS scheme can effectively mitigate the potential risks of cross-chain tampering attacks and privacy leakage attacks.

$$g^{{\mathrm{sigc}}^{-1}-si{g}^{\ast }{c}^{\ast -1}}=\mathsf{\prod }_{i\in [1,\omega ]}p{k}_i^{c^{\ast -1}h{v}^{\ast }-c^{-1}hv}$$

(7)

□

Theorem 2.

If all entities of the BDCA have duly complied with the prescribed procedures, it can be asserted that the consistency of dynamic cross-chain data can be reliably ensured.

Proof. 

The idea behind the proof lies in the notion that if all entities involved in the BDCA abide by the prescribed procedures in an honest and diligent manner, certain associated parameters can be computed with integrity and accuracy. Under such circumstances, $AC$ is able to ensure the auditing consistency between the source chain ($SC$) and target chain ($TC$), thereby promoting the reliability and trustworthiness of cross-chain transactions. In the process of data auditing, $AC$ generates verification information ${\mathsf{\Omega }}^{\left(t{s}_1\right)}$ based on the $proo{f}_{SC}$ and checks the validity of $proo{f}_{TC}$ based on Equation (4). The correctness and soundness of Equation (4) can be deduced as follows:

$$\begin{array}{cc}\hfill LHS& ={\left({\mathsf{\Omega }}^{\left(t{s}_1\right)}\right)}^e·g^{\left(t{s}_1\right)}\left(modN\right)\hfill \\ & =(\mathsf{\prod }_{\phi \in [1,c]}(((g^{h_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}}·g^{m_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}}{)}^d{)}^{{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}}{)}^e)·g^{r^{\left(t{s}_1\right)}}\left(modN\right)\hfill \\ & =(\mathsf{\prod }_{\phi \in [1,c]}{(}^{g^{h_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}·{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}}·g^{m_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}·{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}}))}·g^{r^{\left(t{s}_1\right)}}\left(modN\right)\hfill \\ & =(\mathsf{\prod }_{\phi \in [1,c]}(g^{h_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}·{\mathsf{\Lambda }}_{\phi }^{(t{s}_1)}}))·(g^{{\sum }_{\phi \in [1,c]}{m}_{{\lambda }_{\phi }}^{\left(t{s}_1\right)}·{\mathsf{\Lambda }}_{\phi }^{\left(t{s}_1\right)}}·g^{r^{\left(t{s}_1\right)}})\left(modN\right)\hfill \\ & ={\mathsf{\Omega }}^{\left(t{s}_1\right)}·g^{{\mu }^{\left(t{s}_1\right)}}\left(modN\right)\hfill \\ & =RHS\hfill \end{array}$$

(8)

It can be ascertained that the correctness of Equation (4) can be demonstrated with Equation (8) and the assurance of dynamic cross-chain data consistency primarily hinges on establishing the accuracy of Equation (4). Hence, the consistency of dynamic cross-chain data auditing can be guaranteed. □

8. Performance Analysis

We have developed a prototype of the BDCA, utilizing Hyperledger Fabric v1.4 on Ubuntu18.04 with a system memory of 32GB. The implementation leverages the PBC library [41] and simulates the entire experimental procedure by executing three distinct smart contracts, namely $S_a,S_s$ and $S_t$, which have been developed using the Go programming language [42]. Firstly, we evaluate the efficiency of AGMS, compared with commonly used multi-signature algorithms in the blockchain. Then, we evaluate the computation time and communication overhead of BDCA.

8.1. AGMS Execution Overhead Evaluation

Currently, mainstream multi-signature schemes [43] applied to the blockchain can be divided into RSA-based multi-signature schemes [44], Schnorr-based multi-signature schemes (e.g., Cosi [45], and AGMS), and BLS-based multi-signature schemes [46]. The results are illustrated in Figure 4. The BLS-based multi-signature scheme exhibits significantly longer processing times for both signing and verification operations compared to the other two categories of signature schemes, attributed to the highly time-consuming bilinear pairing operation involved in the BLS-based multi-signature. Despite the fact that the RSA-based multi-signature scheme exhibits the lowest execution time during the verification process, its total time overhead is comparable to that of Cosi and AGMS. The signature length of the RSA-based multi-signature scheme is 2048 bit, while the signature length of the Schnorr-based multi-signature is only 448 bit, also indicating the advantage of the Schnorr-based multi-signature scheme. Moreover, we have taken into account the variation of execution time with the number of signers, as illustrated in Figure 5, while the AGMS signature scheme incurs a higher cost than Cosi, it offers a higher level of security than Cosi, particularly in terms of mitigating the risks of rogue-key attacks and k-sum problem attacks [47], making it a justifiable choice in BDCA where security is of utmost importance.

8.2. Computation Overhead Evaluation

We conduct experiments to evaluate the computation overhead of BDCA with a similar scenario as in previous studies using Fortress [48] and CPVPA [38]. As shown in Figure 6, our experimental results indicate that the computation overhead of the BDCA in preprocessing data is lower compared to the Fortress and CPVPA schemes. This is attributed to the fact that the Fortress scheme requires the utilization of zero-knowledge proofs (ZKPs) in preprocessing data while the CPVPA scheme involves multiple costly exponentiation and multiplication operations, resulting in a significantly larger computation overhead. Figure 7 reveals that when the number of challenged blocks is fixed at 300 blocks, irrespective of block size, the computation cost of BDCA in auditing data is marginally superior to that of Fortress. This is due to the fact that the Fortress scheme requires doubling the computations for combined blocks with two different authentication tags, whereas BDCA exhibits a more efficient performance in this regard. Moreover, the computational efficiency of BDCA is significantly higher than that of the CPVPA scheme, which involves multiple computations for combined blocks with different authentication tags. In general, BDCA is efficient in computation.

8.3. Communication Overhead Evaluation

We conduct similar experiments to evaluate the communication overhead of BDCA with Fortress and CPVPA. Figure 8 demonstrates that the communication overhead of the BDCA in preprocessing data is lower compared to the Fortress scheme. This is attributed to the fact that the Fortress scheme requires the generation of various commitments of zero-knowledge proofs (ZKPs), which results in a significant communication burden. In contrast, BDCA only requires transferring the BV-MHT, which incurs a considerably lower communication overhead. Additionally, the communication overhead of the CPVPA scheme grows linearly with the number of blocks, resulting in a higher communication overhead compared to BDCA. Figure 9 highlights that both the Fortress and CPVPA schemes require transferring more combined blocks against each challenge in auditing data, resulting in a higher communication overhead compared to BDCA. This is due to the fact that BDCA employs a more efficient method for generating and transmitting combined blocks. Specifically, BDCA generates and transmits only the necessary combined blocks for each challenge, resulting in a significantly lower communication overhead. In general, BDCA is efficient in communication.

8.4. The Probability of Data Consistency Guarantees

In Figure 10, our evaluation of the proof generation time under different standards (from the number of challenged blocks equals 240 to 460) of tampered data detection reveals that the number of challenged blocks is the primary determinant of the time required for proof generation. Specifically, increasing the confidence level (from 90 to 99%) [20] of data consistency guarantees leads to a substantial increase in the proof generation time for a fixed data tampering rate of 1%, emphasizing the importance of optimizing consistency guarantees to balance performance and security considerations.

9. Conclusions

In this paper, we present a novel blockchain-based distributed model BDCA, that leverages the BV-MHT and AGMS to implement a lightweight and secure data consistency verification process. By incorporating the auditing capabilities of $AC$ and the privacy-preserving features of AGMS, BDCA provides a robust and efficient means of ensuring the integrity and confidentiality of cross-chain transactions. Additionally, we introduce BV-MHT and AFV to enable data updates and batch verification with minimal overheads. We also conduct a comprehensive security analysis to demonstrate the security and reliability of BDCA in practice. Experimental results reveal that the average execution time of AGMS scheme is 5.3 ms, which exceeds that of RSA and BLS, and rivals that of Cosi, while the security of AGMS outperforms that of Cosi. Furthermore, BDCA is practical and highly efficient for data preprocessing and auditing in terms of computation and communication, outpacing both CPVPA and Fortress. BDCA can also provide data consistency guarantees of up to 99%. Our future work involves deploying BDCA on a public blockchain platform, e.g., Ethereum, to evaluate its scalability and efficiency in real-world applications. The potential decline in interoperability, scalability, and security of BDCA with the increasing user nodes underscores the need for ongoing research and optimization of BDCA. Some new approaches to improve these metrics will be explored in order to ensure that BDCA can scale effectively and maintain high levels of security and performance.