RETRACTED: MCS-VD: Alliance Chain-Driven Multi-Cloud Storage and Verifiable Deletion Scheme for Smart Grid Data

Abstract

The entire system collapses due to the issues of inadequate centralized storage capacity, poor scalability, low storage efficiency, and susceptibility to single point of failure brought on by huge power consumption data in the smart grid; thus, an alliance chain-driven multi-cloud storage and verifiable deletion method for smart grid data is proposed. By leveraging the synergy between alliance blockchain and multi-cloud architecture, the encrypted power data originating from edge nodes is dispersed across a decentralized multi-cloud infrastructure, which effectively mitigates the danger of data loss resulting from single-point failures or malicious intrusions. The removal of expired and user-defined data is guaranteed through a transaction deletion algorithm integrated into the indexed storage deletion chain and strengthens the flexibility and security of the storage architecture. Based on the Practical Byzantine Fault-Tolerant Consensus Protocol with Ultra-Low Storage Overhead (ULS-PBFT), by the hierarchical grouping of nodes, the system communication overhead and storage overhead are reduced. Security analysis proves that the scheme can resist tampering attacks, impersonation attacks, collusion attacks, double spend attacks, and replay attacks. Performance evaluation shows that the scheme improves compared to similar methods.

1. Introduction

The smart grid is a key area for the deep integration of energy revolution and digital revolution. Its massive power consumption data is the core cornerstone of smart grid scheduling, energy efficiency optimization, and accurate user services [1]. The stable operation of the power grid, the preservation of user privacy, and the sound growth of the energy market are all directly impacted by the safe storage and effective administration of these data. It is a crucial issue that needs to be resolved in order to establish a smart grid.

The current research in the field of smart grid data storage has obvious deficiencies and challenges [2]. Massive data growth makes it challenging for centralized storage architecture to handle issues like inadequate storage capacity, poor scalability, and a high risk of single-point failure, which could bring down the entire system and result in incalculable losses in the event of a failure [3]; existing storage solutions lack flexible and effective data deletion mechanisms, making it difficult to safely and reliably handle expired data and user-specified data that needs to be deleted. This not only wastes storage resources but also poses risks of privacy breaches, thereby reducing the security and flexibility of the storage model [4]; while the adoption of blockchain for energy data management can enhance security [5], mainstream consensus protocols suffer from excessive communication and storage overhead, resulting in transaction throughput that fails to meet the actual needs of smart grids [6]. Additionally, there is room for improvement in resisting various types of attacks [7].

To address the challenges cited above, this paper, which is an extension of our preliminary work [8], proposes a smart grid framework integrating multi-cloud storage and verifiable deletion, underpinned by the Practical Byzantine Fault-Tolerant Consensus Protocol with Ultra-Low Storage Overhead (ULS-PBFT) [9]. The key contributions are outlined as follows:

(1) An integrated model of multi-cloud storage and alliance chain. A data storage architecture integrating alliance chain and multi-cloud storage is constructed. Within this framework, encrypted power usage records originating from edge nodes are dispersed throughout a multi-cloud server infrastructure, thereby mitigating the risk of data loss resulting from single-point failures or malicious attacks.

(2) Dual guarantee of transaction deletion mechanism and ciphertext index. The ciphertext index is stored to the indexed storage deletion chain, which ensures that the electricity consumption data can be verified. The transaction deletion algorithm is suggested to be implemented on the indexed storage deletion chain, which ensures that expired data and user-specified data can be deleted, reinforcing the safety and flexibility of the storage model.

(3) ULS-PBFT consensus protocol optimization. In addition to reducing system storage and communication costs, ULS-PBFT increases the alliance chain transaction throughput capacity through hierarchical node grouping.

The remainder is organized as follows: Section 2 displays the relevant work. Section 3 outlines the system model, notation and assumptions, threat model, design goals, and mapping between technical steps and security objectives. Section 4 provides a detailed description of the scheme. Section 5 presents the security analysis. Section 6 assesses the performance of the proposed scheme. Ultimately, Section 7 summarizes the paper.

2. Related Works

In recent years, there has been an increase in research on using blockchain technology in connection with data storage [10,11,12]. Vatankhah [13] suggested a system for secure and trusted data access in cyber–physical power systems using blockchain technology, but the storage overhead for the consensus process of traditional blockchain technology is too high in the power system. Wu [14] developed a decentralized energy exchange model leveraging blockchain technology and evaluated its robustness against cyber threats. Nevertheless, the solution lacks a mechanism to ensure the integrity of the data. Gai [15] put forward a smart grid edge model that employs a permissioned blockchain to protect the confidentiality and safety of the power source management system, but the study overlooked the system’s operational flexibility in real-world scenarios.

Chenthara [16] introduced a decentralized framework for storing healthcare data to improve privacy protection, in which the framework utilizes a permissioned blockchain, resulting in decreased flexibility for the system in practical applications. Ma [17] introduced a decentralized database maintenance scheme utilizing alliance chain technology; nevertheless, this approach incurs significant storage expenses. R.V. [18] proposed a trusted data collection method for cyber–physical power systems based on blockchain technology, which utilizes a decentralized private data collection blockchain for trusted data and regional autonomy, but the private chain is restricted by licensing rights and is only suitable for internal use within a specific organization. Ghosh [19] presented a data storage architecture utilizing blockchain technology to enhance personal data protection in IoT environments. The scheme uses certificate-less cryptography, which reduces the processing time and communication overhead, but public key encryption is computationally expensive for resource-constrained devices.

KMM [20] proposed a secure e-FIR management system that incorporates blockchain technology and IPFS, utilizing IPFS for data storage on the blockchain. M. Naz [21] introduced a storage framework leveraging IPFS and blockchain, where encrypted files are managed via the shamir secret-sharing scheme. Despite offering robust privacy protection, the method suffers from scalability issues regarding large-scale datasets. Kaur [22] proposed an IPFS-based data storage and sharing framework. Due to the lack of defined access policies, malicious nodes can still access and control the data. In conclusion, there is huge potential in utilizing blockchain technology for IoT data storage. However, the consensus process in blockchain technology needs nodes to work together across the network, leading to significant energy consumption. Thus, the aforementioned solution is not suitable for the storage of data from smart grid sensors.

Compared with traditional centralized storage, cloud storage has higher performance, better scalability and lower cost. Cao [23] introduced a blockchain-based cloud architecture to ensure the immutability of electronic health records (EHR), but the inherent capacity constraints of the blockchain result in excessive storage overhead for transactions. P. [24] suggested a novel online data cloud storage model that preserves privacy by employing strong diffusion and obfuscation techniques. The model designs an efficient batch online query processing system which improves storage efficiency and security but also requires additional computational overhead. P. [25] proposed an innovative cloud security framework that leverages encryption and obfuscation to safeguard information, but the method suffers from significant computational overhead.

Sharma [26] designed a framework employing CP-ABE to handle access rights and revocation within distributed cloud systems. However, a major limitation of this approach is its high resource consumption regarding storage. Zhao [27] suggested a provable multi-copy data ownership program for cloud-based EMR systems; however, the scheme does not consider the huge computational and communication overhead. Rahman [28] put forward the Block-Sdot cloud composition to enhance the safety of cloud storage network, but the composition lacks sufficient flexibility. Huang [29] suggested a blockchain structure for co-auditing cloud data storage, but the framework is not very scalable. Seth [30] employed encryption mechanisms to ensure data security within the cloud environment; however, this strategy results in higher network bandwidth consumption. Pise [31] used decentralized blockchain to enhance data security with the disadvantage that it is not resistant to replay attacks.

Lu [32] proposed a secure storage and sharing framework for industrial IoT sensors utilizing blockchain-based cloud infrastructure. However, due to the limited computational capacity of the blockchain, the system suffers from data congestion. Gousteris [33] suggested a secure distributed cloud storage architecture incorporating blockchain. However, the RSA algorithm used in this scheme is inefficient in encryption and decryption and is not relevant for large-scale scenarios. Alsulbi [34] proposed a secure blockchain-cloud storage framework tailored for big data applications. The study established a dual-layer private blockchain system; however, the reliance on an Ethernet platform results in limited system throughput. Qamar [35] suggested a secure cloud storage framework utilizing blockchain technology, which named the “CHARON”, capable of securely and efficiently storing and sharing data; however, the incorporation of byzantine elastic cloud storage in this system implies increased latency. In summary, blockchain-based cloud storage solutions not only provide strong scalability but also ensure data security; however, with the escalating demand for data volume and reliability, single-cloud storage architectures are inadequate to completely meet the requirements of high usability and strong safety.

It is vital to improve the availability and flexibility associated with storage framework. Mishra [36] proposed a scheme integrating redactable blockchain and IPFS and realizes verifiable deletion by leveraging the editability of blockchain, but the scheme relies on Proof of Work (PoW) consensus for redaction validation, leading to high on-chain computational overhead and latency. Hua [37] proposed a blockchain-assisted secure deduplication scheme for large-scale cloud storage; nevertheless, its key servers (KS) group management and key migration introduce additional computational overhead. Hou [38] proposed a controlled readable blockchain, which supports common transaction coding and supports the mandatory removal of harmful data within the blockchain, but its data security is not guaranteed. Mehrotra [39] proposed a delegate data deletion scheme, but when additional verifiers try to confirm the deletion results, it risks disclosing the patterns used to conceal the physical media. Pyoung [40] proposed Litchain, a lightweight and extensible framework capable of pruning expired blocks from the chain. Nevertheless, the system neglects to preserve the hashes of deleted transactions or blocks, which poses a risk to the blockchain’s traceability and data integrity. Jin [41] proposed a blockchain-based auditable deduplication scheme for multi-cloud storage, yet its secret sharing and batch auditing mechanisms bring extra computational overhead. In summary, the security and efficiency of existing data deletion schemes need to be improved. A summary of related works is provided in Table 1.

Table 1. Summary of relevant work.

Scheme	Scheme Description	Insufficient
Blockchain-based electricity trading model [13,14,15]	A proposed model for trusted access to data in cyber–physical power systems using blockchain technology.	Higher storage overhead
Data storage mechanism based on IPFS [20,21,22]	A data storage mechanism based on IPFS is proposed, and data confidentiality is well-protected.	Not applicable to larger data sets
Data cloud storage model based on obfuscation techniques [24,25]	An obfuscation technology-based cloud data storage model is introduced to improve data security.	Additional computational overhead is required
Blockchain-based data cloud storage scheme [26,29,34]	A cloud model leveraging blockchain technology is proposed to safeguard data within cloud environments.	High storage overheads for transactions and no consideration of outsourced cloud security
Blockchain-assisted cloud storage data deletion strategy [36,37,41]	By editable blockchain, key servers, and threshold secret sharing, respectively, to realize verifiable deletion in cloud scenarios.	High computational overhead
Edit-based data deletion scheme [38,39,40]	The volume of blockchain data is minimized by purging or modifying ledger entries within the mining operation.	Often at the expense of security or diversification

3. Overview of MCS-VD

3.1. System Model

Research on a multi-cloud storage architecture and provable deletion protocol for smart grid data, based on the alliance chain, comprises five distinct entities: smart grid nodes, edge nodes, blockchain, multi-cloud storage with CM, and a data management center. Figure 1 illustrates the system model.

Figure 1. System model.

(1) Smart grid node (SN): The smart meter in the node collects the power consumption data of the region, completes the primary encryption, uploads the ciphertext of the power consumption data to the superior node, and responds to the verification inquiry from the higher layer.

(2) Edge node (EN): Upon processing the power data ciphertext received from the SN, the node’s edge server transfers the data to the multi-cloud infrastructure for retention.

(3) Alliance blockchain (CB): The proposed framework incorporates two alliance chains. (1) $SDchain$: It is utilized for holding the ciphertext index of data on electricity use and offering the ability to remove certain keywords or on-chain transactions that have expired. The storage, querying, and deletion are all realized by the deployment of smart contracts. (2) Smart grid alliance chain: With the exception of the CSP, all entities within the model participate in the alliance chain to ensure efficient data handling and safeguard data privacy.

(4) Control center (CC): Charged with the initialization of the system infrastructure and validates any entity requesting membership in the smart grid alliance chain. Upon validation, it generates IDs and public–private key pairs for qualified members.

(5) Multi-cloud storage (CS): The data management center and lower entities can access storage and processing resources thanks to multi-cloud storage. The ciphertext index is returned and kept on the $SDchain$ after the ENs’ uploaded ciphertext data is validated and saved in the multi-cloud server cluster. For effective data storage, transport, and retrieval, multi-cloud storage also incorporates a sub-entity known as Cloud Management (CM).

3.2. Notation and Assumptions

3.2.1. Notation Description

Table 2 outlines the definitions and explanations for the notation presented in the article.

Table 2. Notation table.

Notation	Description
$\lambda$	security parameters
$q$	prime number, order of cyclic groups $G_1$ and $G_2$
$G_1$$, G_2$	multiplicative cyclic group of order $q$
$g_1$$, g_2$	generator of $G_1$ and $G_2$
$e$	bilinear pairing
$H_1,H_2,H_3,H_4$	full-domain cryptographic hash functions
$a_j,b_i,r$	random numbers
$A_j,B_i$	public values corresponding to $a_j,b_i$
$S{K}_{SN}$, $P{K}_{SN}$	the private key, the public key of $SN$
$S{K}_{EN}$, $P{K}_{EN}$	the private key, the public key of $EN$
$P{K}_{sys}$	public key of the alliance chain system
$T$, $\tau$, $k$	timestamp, transmission authentication tag, random factor
$M$	plaintext of smart grid power consumption data
$Index$	ciphertext index
$Add{r}_C$	distributed storage address of $C$
$R$	remarks other than power usage data
$K_{i,j}$	shared key
$h_M$, $C$	ciphertext hash, ciphertext number
$\sigma$	BLS signature of $M$
$N$	the total number of alliance chain nodes
$m$	number of SCG
$y$	size of SCG, $y\approx N/m$
$T_{valid}$	validity period of $C$

3.2.2. Trust Assumptions

(1) Assumption: CC is fully trusted. CC as a fully trusted authority, assumes the core responsibilities of system initialization, entity authentication, and key pair generation. The rationality of this assumption is supported as follows:

① CC is operated by the grid operator and strictly adheres to critical infrastructure security standards, safeguarding non-malicious behavior and data integrity through stringent access control and auditing mechanisms.

② CC is deployed in a physically isolated air-gap environment and employs multi-factor authentication to effectively reduce the risk of unauthorized access and provide solid support for fully trusted attributes.

③ This assumption avoids the excessive complexity of key management in the initial deployment phase, and the CC’s responsibilities are limited to authentication and key generation, further reducing the risk of trust abuse.

(2) Assumption: CM is semi-trusted. CM, as a sub-entity of the CS responsible for data storage, transmission and retrieval, is assumed to be semi-trusted. The rationality of this assumption is supported as follows:

① CM is managed by CSPs with authoritative certifications, and has the technical capability to withstand external attacks, while the semi-trusted definition takes into account the risk of disclosure due to unanticipated vulnerabilities.

② CSPs sign SLA with grid operators and face severe penalties for actively tampering with or leaking data, with reputational and financial losses posing a strong incentive, a logic that has been validated by real-world deployment cases.

(3) Assumption: the majority of alliance chain nodes are honest. Alliance chain nodes cover grid companies, regulators, and edge operators, assuming that most of them are honest and trustworthy, and that malicious nodes account for no more than 1/3 of them. The rationality of this assumption is supported as follows:

① Nodes have high credibility and are bound to the long-term interests of smart grid stability. Malicious behavior will face legal recourse and reputational damage, significantly reducing the risk of collusion and tampering.

② This assumption is the core premise of the BFT consensus, which provides theoretical support for dealing with potential attacks in subsequent threat models and guarantees the robustness of the system.

3.2.3. Trust Boundaries and Out-of-Scope Threats

(1) Trust boundaries. CC’s authentication process, key generation and distribution mechanisms are fully trusted domains. CM’s data storage/transfer/deletion execution and multi-cloud computing resource scheduling are semi-confidence domains. The consensus behavior of the coalition chain nodes belongs to the conditional trust domain. Public communication channels and unauthorized external entities are untrustworthy domains.

(2) Out-of-scope threats. The current solution does not provide protection against the following scenarios, which need to be supplemented by additional security measures. Malicious collusion of more than ${\displaystyle \frac{1}{3}}$ alliance chain nodes and complete compromise of CC. Active collusion between CM and more than ${\displaystyle \frac{1}{3}}$ alliance chain nodes. Underlying hardware-level attacks and quantum computing attacks.

3.3. Threat Model

3.3.1. Adversarial Model

The security of MCS-VD is defined in the context of a Probabilistic Polynomial-Time (PPT) adversary $\mathcal{A}$. Considering the practical deployment environment of the smart grid, the capabilities of $\mathcal{A}$ are modeled as follows.

(1) Network capabilities: Public communication channels are assumed to be controlled by $\mathcal{A}$ under the Dolev–Yao model. Consequently, $\mathcal{A}$ can eavesdrop, intercept, reorder, or inject messages transmitted between SNs, ENs, and the CS.

(2) Adversarial roles and intent.

① External adversary: An entity without legitimate cryptographic credentials. The goal of $\mathcal{A}$ is to compromise data integrity by replaying expired ciphertext indices or forging data tags.

② Internal adversary: An entity with partial legitimate privileges. $\mathcal{A}$ may attempt to recover SM9-encrypted user data without the private key or collude to forge deletion proofs in multi-cloud storage.

③ Oracle access: To formalize adaptive chosen-message attacks (EUF-CMA), $\mathcal{A}$ obtains permission to utilize the listed oracles.

Signing oracle ${\mathcal{O}}_{sign}$: On input of a message $m$, the oracle returns a valid BLS signature from a target node.

Hash oracle ${\mathcal{O}}_{hash}$: The full-domain hash functions $H_1~H_4$ are modeled as random oracles.

3.3.2. Cryptographic Security Assumptions

The security proofs of the presented mechanism rely on the hardness of the following computational problems defined over the cyclic groups $G_1,G_2$ and the bilinear pairing $e$ (Section 4.1 details the parameter construction).

(1) Computational Diffie–Hellman (CDH) assumption: Given $(g_1,g_1^a,g_1^b)\in G_1^3$, computing $g_1^{ab}$ is computationally infeasible for any PPT adversary. This assumption underpins the unforgeability of BLS signatures in Theorem 3.

(2) Bilinear Diffie–Hellman (BDH) assumption: Given $(g_1,g_1^a,g_1^b,g_1^c)$, distinguishing the pairing value $e{(g_1,g_2)}^{abc}\in G_T$ from a random element is computationally hard. This assumption guarantees the semantic security (IND-ID-CPA) of the SM9 algorithm, which forms the basis for the verifiable deletion security in Theorem 4.

(3) Collision-Resistant Hashing (CRH) assumption: For hash functions $H_1~H_4$, the probability of identifying two different $x\ne x^{\prime }$ such that $H(x)=H(x^{\prime })$ is negligible. This ensures the tamper-resistance property in Theorem 2.

3.4. Design Goals

(1) Secure storage: The fusion of alliance blockchain and multi-cloud storage ensures that encrypted electricity data from edge devices is preserved on distributed servers. This approach significantly lowers the chance of data corruption due to centralized failures or attacks.

(2) Encryption of sensitive information: Ensure that users’ sensitive data is stored in encrypted format, preventing exposure to CSPs and other shared users.

(3) Data Integrity: Leveraging blockchain technology to register important information during the multi-cloud data transfer process helps maintain data integrity after it has been migrated and replicated.

(4) Low storage overhead: The ULS-PBFT protocol is utilized, organizing nodes in a hierarchical manner to minimize storage overhead within each group.

3.5. Mapping Between Technical Steps and Security Objectives

To clarify the link between the technical steps and the security objectives, a detailed mapping table is listed in Table 3.

Table 3. Detailed mapping table.

Technical Step	Targeted Security Property
bilinear pairing initialization	confidentiality, integrity
BLS signature	authenticity, integrity, non-repudiation
SN/EN key exchange	confidentiality, authenticity
ULS-PBFT hierarchical consensus	consistency, fault tolerance, integrity
ciphertext index storage on $SDchain$	integrity, verifiability

4. Scheme Design

The section provides a comprehensive description of the system initialization, secure data storage, and deletion mechanism. And the ULS-PBFT consensus mechanism adopted in this scheme is elaborated. Figure 2 illustrates the detailed workflow.

Figure 2. The MCS-VD workflow.

4.1. System Initialization

4.1.1. Cyclic Groups and Bilinear Pairing Constructions

Based on the given security parameter $\lambda =128$ (corresponding to 128-bit equivalent security strength), the system executes a parameter generator to complete the following constructions:

(1) Select a prime number $q=2^{256}-2^{224}+2^{192}+2^{96}-1$, which complies with the order of the 256-bit BN curve specified in the SM9 national standard (GB/T 35275-2023) to ensure resistance against discrete logarithm attacks and quantum computing threats.

(2) Construct two multiplicative cyclic groups $G_1$ and $G_2$ of order $q$, where $g_1$ is the generator of $G_1$ and $g_2$ is the generator of $G_2$ (satisfying $g_1\ne 1_{G_1}$ and $g_2\ne 1_{G_2}$, with $1_{G_1}$ and $1_{G_2}$ being the identity elements of the two groups, respectively).

(3) Establish a bilinear pairing $e:G_1\times G_1\to G_2$, which strictly satisfies three core properties to support the correctness and security of BLS signatures:

① Bilinearity: For any $a,b\in Z_q^{\ast }$ ($Z_q^{\ast }$ denotes the multiplicative group of integers modulo $q$) and $P,Q\in G_1$, $e(aP,bQ)=e{(P,Q)}^{ab}$ holds.

② Non-degeneracy: $e(g_1,g_1)\ne 1_{G_2}$, ensuring the mapping result is not constantly the identity element and avoiding signature verification failure.

③ Computability: For any $P,Q\in G_1$, $e\left(P, Q\right)$ can be efficiently computed in polynomial time via the Tate pairing algorithm, balancing security and execution efficiency.

4.1.2. Definition and Role Derivation of Hash Functions

To meet the security requirements of different scenarios, four full-domain cryptographic hash functions are defined. Their role derivation is as follows.

$H_1:{\{0,1\}}^{\ast }\to G_1$: BLS signatures require mapping arbitrary-length power consumption data to $G_1$ for group operations. The full-domain property of $H_1$ ensures no missing data mapping, and its collision resistance prevents different data from mapping to the same group element, avoiding signature forgery. This directly supports the non-forgeability and integrity of BLS signatures.

$H_2:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$: Used to generate data transmission authentication tags $(\tau =H_2(K\parallel M\parallel T))$ and ciphertext hash values. The 256-bit output length ensures the uniqueness of hash results, avoiding undetected data tampering due to hash collisions, and supporting data integrity verification.

$H_3:{\{0,1\}}^{\ast }\to Z_q^{\ast }$: Applied in ULS-PBFT node grouping. By mapping node IDs to $Z_q^{\ast }$ and performing modulo $F$ operations, SN1s are evenly distributed into $F$ second-tier consensus groups (SCGs). The uniform distribution characteristic avoids load imbalance or single-point failure caused by biased grouping, enhancing system availability and load balancing.

$H_4:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$: Responsible for block hash calculation $H_4(Previous Hash\parallel Merkle Root\parallel Timestamp)$. If the block content is modified, the output of $H_4$ changes significantly, enabling nodes to quickly verify block integrity and ensuring tamper-proofing and traceability.

4.1.3. Key Generation and System Public Key Deployment

(1) Entity account registration and key pair generation. CC, as a fully trusted authority, completes account registration and key pair generation for all alliance chain entities:

① All entities submit registration requests to the alliance chain. Following the validation of the entity’s legitimacy, the CC assigns a unique ID to each entity.

② Each entity randomly selects a private key $SK\in Z_q^{\ast }$.

③ Based on the multiplicative property of $G_1$, the public key is computed as $PK={g_1}^{SK}$. For EN and SN, the key pairs $(S{K}_{EN},P{K}_{EN})$ and $(S{K}_{SN},P{K}_{SN})$ are fully compatible with subsequent BLS signature operations.

④ Private keys are stored in the local secure storage module of entities, while public keys are uploaded to the alliance chain for public inspection and verification.

(2) Generation and deployment of system public key:

① The CC randomly selects a global random number $r\in Z_q^{\ast }$.

② The alliance chain system public key is computed as $P{K}_{\mathrm{sys}}=g_1^r$, leveraging the multiplicative property of $G_1$; $P{K}_{\mathrm{sys}}$ serves as a global verification public key for verifying the legitimacy of BLS signatures and data transmission authentication tags, ensuring secure interaction between entities.

③ The CC sends $P{K}_{\mathrm{sys}}$ to all alliance chain nodes via an encrypted channel. Nodes verify the validity of $P{K}_{\mathrm{sys}}$ by verifying the signature of CC and store it in the local parameter library.

Generate the complete set of system public parameters $params=(G_1,G_2,e,g_1,g_2,q,H_1,H_2,H_3,H_4,P{K}_{sys})$, and all nodes synchronously store this parameter set; simultaneously, clear residual blockchain data (if any) ensure the system starts from an initial secure state, avoiding privacy leakage or security vulnerabilities caused by residual data. The initialization process is outlined in Algorithm 1.

Algorithm 1: Initialization
1	Input: Security parameter $\lambda =128$
2	Output: System public parameters $params$
3	Select prime $q=2^{256}-2^{224}+2^{192}+2^{96}-1$;
4	System creates additive cyclic group $G_1$ of order $q$ and selects generator $g_1$; creates multiplicative cyclic group $G_2$ of order $q$ and selects generator $g_2$;
5	Set bilinear pairing map $e:G_1\times G_1\to G_2$ and verify its bilinearity, non-degeneracy, and computability; // support BLS signature and SM9 encryption
6	Set full-domain cryptographic hash functions: $H_1:{\{0,1\}}^{\ast }\to G_1$, $H_2:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$, $H_3:{\{0,1\}}^{\ast }\to Z_q^{\ast }$, $H_4:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$;
7	For each entity: select $SK\in Z_q^{\ast }$, compute $PK={g_1}^{SK}$; store $SK$ locally and upload $PK$ to the alliance chain; // identity authentication and secure key distribution
8	CC selects $r\in Z_q^{\ast }$, computes $P{K}_{\mathrm{sys}}=g_1^r$ and deploys it to all nodes; // global verification public key distribution
9	Generate system public parameters $params=(G_1,G_2,e,g_1,g_2,q,H_1,H_2,H_3,H_4,P{K}_{sys})$;
10	Clear blockchain raw data and return $params$.

4.2. Secure Storage

4.2.1. $SN$/$EN$ Key Exchange

(1) $SN$ initiates key exchange request. When a $S{N}_j$ collects regional power consumption data $M$, it first completes local primary encryption to prevent plaintext leakage, then randomly selects a private value $a_j\in Z_q^{\ast }$, computes the corresponding public value $A_j={g_1}^{aj}$, generates a timestamp $T_{SN}$ (accurate to the second) to resist replay attacks with the validity condition $\mid current\_time-T_{SN}\mid <30s$, attaches its unique identity $I{D}_{S{N}_j}$, $A_j$ and $T_{SN}$, packages them into $(A_j,T_{SN},I{D}_{S{N}_j})$, and transmits the package to the $E{N}_i$ through an encrypted pathway.

(2) $EN$ verifies request validity. Upon receiving the package from $S{N}_j$, $E{N}_i$ first verifies the legitimacy of the request to avoid responding to malicious attacks: it queries the alliance chain ledger to confirm whether $I{D}_{S{N}_j}$ is a registered legitimate node, relying on the non-tamperability of the alliance chain to guarantee the authenticity of the sender’s identity; it checks if $T_{SN}$ is within the valid time window, rejecting expired requests where $\mid current\_time-T_{SN}\mid \ge 30s$ to resist replay attacks, and confirms that the package structure $(A_j,T_{SN},I{D}_{S{N}_j})$ is complete and compliant with the predefined protocol to avoid format tampering.

(3) $EN$ negotiates and derives shared key. After all verifications pass, $E{N}_i$ randomly selects a private value $b_i\in Z_q^{\ast }$, computes the corresponding public value $B_i=g_1^{b_i}$ based on the multiplicative property of $G_1$, and leverages the bilinearity of the pairing $e:G_1\times G_1\to G_2$ to derive the shared key $K_{i,j}=e{(A_j,B_i)}^{S{K}_{E{N}_i}}=e{(g_1^{a_j},g_1^{b_i})}^{S{K}_{E{N}_i}}=e{(g_1,g_1)}^{a_j\cdot b_i\cdot S{K}_{E{N}_i}}$, with the shared key integrating the random values of both parties $(a_j, b_i)$ and the private key of $E{N}_i$ to ensure only $S{N}_j$ and $E{N}_i$ can compute it, grounded in the intractability of the Discrete Logarithm Problem (DLP) within $G_1$.

(4) $EN$ generates transmission authentication tag. To safeguard data $M$ integrity in transit, $E{N}_i$ uses the full-domain cryptographic hash function $H_2:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$ to compute the ciphertext hash $h_M=H_2(M)$, generates the current timestamp $T_{EN}$ to ensure the uniqueness of each transmission tag, and computes the authentication tag via concatenation hash $\tau =H_2(K_{i,j}\parallel h_M\parallel T_{EN})$, with any tampering with $M$, $K_{i,j}$ or $T_{EN}$, resulting in a different $\tau$ to enable the multi-cloud storage to quickly verify data integrity before formal storage.

4.2.2. Encryption and BLS Signature

(1) SM9 encryption for confidentiality protection. To prevent CSPs from accessing sensitive power consumption data plaintext $M$, $E{N}_i$ adopts the SM9 identity-based encryption algorithm recommended by the national standard (GB/T 35275-2023) to encrypt the collected data $M$: this algorithm does not require certificate management for public keys, which is highly compatible with the distributed multi-cloud storage scenario and reduces the overhead of key management in cross-cloud environments; during encryption, $E{N}_i$ uses $K_{i,j}$ as the core derivation basis for the encryption key, ensuring the consistency of the key system, and encrypts $M$ to obtain the ciphertext $C$; the decryption key is stored on the alliance chain in ciphertext form and associated with the identity of authorized entities, ensuring that only legitimate nodes can decrypt $C$ to obtain the plaintext $M$, while CSPs can only store the ciphertext without accessing the actual data content, thus protecting user privacy and data confidentiality.

(2) BLS signature construction for non-forgeability. To prove that the data $C$ is indeed generated by a legitimate $E{N}_i$ and has not been tampered with or forged, $E{N}_i$ reuses the key pair generated during system initialization: the private key $S{K}_{E{N}_i}\in Z_q^{\ast }$ is utilized to compute the signature, and the public key $P{K}_{E{N}_i}=g_1^{S{K}_{E{N}_i}}$ is provided for public verification; during signature construction, $E{N}_i$ first uses $H_1$ to map the plaintext $M$ to $h=H_1(M)$, which adapts the arbitrary-length data to $G_1$ for subsequent group operations, and the collision resistance of $H_1$ prevents different data from mapping to the same group element to avoid signature forgery; then, $E{N}_i$ randomly selects $k\in Z_q^{\ast }$ to introduce a random factor, ensuring that the same data generates different signatures in different transmission sessions to resist replay attacks, and computes $g_1^k$ and $h^k$; finally, based on the associative property of $G_1$ multiplication, the signature $\sigma ={(h^k)}^{S{K}_{E{N}_i}}=h^{k\cdot S{K}_{E{N}_i}}$ is derived, which integrates $S{K}_{E{N}_i}$ and $k$, and due to the hardness of the DLP in $G_1$, attackers without $S{K}_{E{N}_i}$ cannot forge a valid signature.

(3) BLS signature verification for validity confirmation. When CS receives the data package containing $C$ and $\sigma$, it verifies the signature’s validity to confirm that $C$ is derived from $M$ and the sender is authorized: CS first obtains $K_{i,j}$ from the alliance chain, decrypts $C$ to retrieve $M$, then uses $H_1$ to map $M$ to $h^{\prime } = H_1\left(M\right)$; subsequently, CS retrieves $P{K}_{E{N}_i}$ of $E{N}_i$ from the alliance chain and verifies the bilinearity-based equation $e(\sigma ,g_1)=e(h^{\prime },P{K}_{E{N}_i})$; the derivation logic of the verification equation is as follows: substituting $\sigma ={h^{\prime }}^{k\cdot S{K}_{E{N}_i}}$ and $P{K}_{E{N}_i}=g_1^{S{K}_{E{N}_i}}$ into the equation, the left-hand side $e({h^{\prime }}^{k\cdot S{K}_{E{N}_i}},g_1)=e{(h^{\prime },g_1)}^{k\cdot S{K}_{E{N}_i}}$, and the right-hand side $e(h^{\prime },g_1^{S{K}_{E{N}_i}})=e{(h^{\prime },g_1)}^{S{K}_{E{N}_i}}$; since $k\in Z_q^{\ast }$ and $e(h^{\prime },g_1)\ne 1_{G_2}$, the equation holds if and only if $\sigma$ is a valid signature generated by $S{K}_{E{N}_i}$ for $M$, thus confirming that $C$ is not forged, $M$ is intact, and the sender is legitimate.

4.2.3. Data Upload, Verification, and Standardized Storage

(1) Standardized data packaging and upload. After completing SM9 encryption and BLS signature, $E{N}_i$ integrates all security-related components into a standardized data package to ensure that CS can complete full verification without additional data requests: the package includes $C$, $\sigma$, $\tau$, $T_{SN}/T_{EN}$, and $I{D}_{S{N}_j}/I{D}_{E{N}_i}$; $E{N}_i$ then determines the target storage region based on the load balancing status of multi-cloud nodes and sends the standardized package to CS via a secure transmission channel, with the entire packaging and upload process complying with the predefined alliance chain communication protocol to ensure compatibility and security.

(2) CS multi-dimensional verification. Upon receiving the data package, CS retrieves $K_{i,j}$ from the alliance chain associated with $I{D}_{S{N}_j}$ and $I{D}_{E{N}_i}$, decrypts $C$ to obtain $M$, computes the hash value $h_M=H_2(M)$ using $H_2$, extracts $T_{EN}$ from the package, and verifies whether $H_2\left(K_{i,j}\parallel h_M\parallel T_{EN}\right)=\tau$, this step has low computational overhead and can quickly filter out data with tampered content or tags, avoiding unnecessary subsequent verification costs; then, CS retrieves $P{K}_{E{N}_i}$ from the alliance chain, maps $M$ to $h^{\prime } = H_1\left(M\right)$ via $H_1$, and verifies the legitimacy of the BLS signature $\sigma$ by determining if $e(\sigma ,g_1)=e(h^{\prime },P{K}_{E{N}_i})$; this step strictly confirms that the data is generated by a legitimate $E{N}_i$ and has not been forged, rejecting maliciously tampered or forged data to ensure the authenticity of stored data.

(3) Distributed secure storage. If both verification steps pass, CS executes standardized storage operations to ensure data availability and confidentiality: CS selects a distributed storage address $Add{r}_C$ across multiple cloud nodes, avoiding single-point failure caused by centralized storage, ensuring data can still be accessed when individual cloud nodes fail, stores $C$ in the distributed storage space, and encrypts $K_{i,j}$ with $P{K}_{sys}$ before storage; this prevents $K_{i,j}$ from being leaked even if the cloud storage is compromised; during storage, CS also records the storage time and validity period $T_{valid}$ of $C$ to support automatic deletion of expired data, with the entire storage process compliant with multi-cloud access control policies to guarantee that resources are accessible exclusively to authenticated entities.

(4) Ciphertext index generation and management. To support efficient query and verifiable deletion of stored data, CS generates and manages a unique ciphertext index: using $H_4:{\{0,1\}}^{\ast }\to {\{0,1\}}^{256}$, CS computes the unique ciphertext index $Index=H_4(C\parallel h_C\parallel Add{r}_C\parallel T_{valid})$; the index integrates core information of the stored data, ensuring one-to-one correspondence with $C$ and avoiding index duplication; CS then returns $Index$ to $E{N}_i$ for local backup and stores $Index$ on the $SDchain$ to ensure the index is tamper-proof and traceable; simultaneously, CS creates a Red-Black Tree (RBT) record table to maintain the mapping relationship between $Index$ and $Add{r}_C$; the RBT structure enables efficient retrieval of $Add{r}_C$ via $Index$ during data deletion, significantly reducing query latency and improving the efficiency of verifiable deletion operations. The ciphertext index computation process is outlined in Algorithm 2.

Algorithm 2: Ciphertext index computation
1	Input: $C$$, Add{r}_C$$, T_{valid}$
2	Output: $Inde{x}_C$
3	Compute ciphertext hash via $H_2:h_C=H_2(C)$; // prevent ciphertext tampering
4	Concatenate core parameters: $Data=C\parallel h_C\parallel Add{r}_C\parallel T_{valid}$; // ensure index uniqueness
5	Compute unique ciphertext index: $Inde{x}_C=H_4(Data)$; // generate tamper-proof index
6	Return $Inde{x}_C$.

4.3. Data Deletion

The scheme adopts a two-stage deletion verification strategy of on-chain index validation and ULS-PBFT consensus confirmation. It first verifies the legitimacy and permission of deletion requests via ciphertext indexes, then confirms deletion operations through alliance chain node consensus to ensure traceable behaviors and consistent results across the network.

① Active deletion by authorized entities. When $S{N}_j$ or $E{N}_i$ no longer needs the stored $C$, $E{N}_i$ initiates an active deletion request. ② Automatic deletion of expired ciphertext. During daily maintenance, CM checks $T_{valid}$ of each stored $C$. When $current\_time>T_{valid}$, CM triggers automatic deletion. The following describes the detailed steps:

(1) Initiate deletion request with standardized parameters. For active deletion, $E{N}_i$ retrieves the locally backed-up ciphertext index $Index$ corresponding to $C$, computes the request authentication tag ${\tau }_{del}=H_2\left(K_{i,j}\parallel Index\parallel T_{del}\right)$, and packages $\left(I{D}_{E{N}_i},Index,{\tau }_{del},T_{del}\right)$ into a standardized deletion request, sending it to CM via a secure channel that complies with the alliance chain communication protocol.

For automatic deletion, CM directly retrieves the expired $Index$ and corresponding $Add{r}_C$ from the RBT record table based on the $T_{valid}$ check, skipping the request packaging process but retaining the same verification logic as active deletion to ensure security and consistency.

(2) CM verifies request legitimacy. CM executes multi-dimensional verification to avoid malicious deletion: it first queries the alliance chain ledger to confirm whether $I{D}_{E{N}_i}$ (for active deletion) is a legitimate authorized entity associated with $Index$, verifying the consistency of $I{D}_{E{N}_i}$ with the storage-stage $I{D}_{E{N}_i}$ by relying on the non-tamperability of the alliance chain; it retrieves $K_{i,j}$ encrypted and stored with $P{K}_{sys}$ during storage from the alliance chain, computes $h_{Index}=H_2(Index)$, and verifies whether $H_2(K_{i,j}\parallel h_{Index}\parallel T_{del})={\tau }_{del}$ to ensure the request is not tampered with; it also checks whether $Index$ exists in the $SDchain$ and RBT record table to avoid repeated deletion, and for active deletion, confirms $T_{del}$ is within the valid time window ($\mid current\_time-T_{del}\mid <30s$) to resist replay attacks, with any verification failure resulting in an immediate request rejection and feedback to the initiator.

(3) Delete ciphertext from distributed storage. After passing all verifications, CM executes ciphertext deletion based on the storage address $Add{r}_C$ associated with $Index$: it retrieves $Add{r}_C$ corresponding to $Index$ from the RBT record table, deletes the ciphertext $C$ from all cloud nodes in the distributed storage cluster to eliminate data residues, and erases the encrypted $K_{i,j}$ associated with $C$ to prevent the unauthorized decryption of potential residual data; it then marks the $Index$ entry in the RBT record table as “deleted” and synchronizes the updated status to all CS nodes in the distributed cluster, ensuring consistent deletion results across the multi-cloud storage system.

(4) Update $SDchain$ and blocks. To ensure the traceability and tamper-proofing of deletion operations, CM updates the index and blockchain based on ULS-PBFT: it first queries the $SDchain$ for the transaction corresponding to $Index$, deletes the transaction if it exists, and generates a deletion record transaction $T{r}_{del}$ with the value set to $H_4(Index\parallel “deleted”\parallel current\_time)$; subsequently, it derives the Merkle root $M{R}_{new}$ for the block housing of the removed transaction, and determines the hash of the most recent block on the alliance blockchain, denoted as $Has{h}_{prev}=H_4(Bloc{k}_{latest}\parallel current\_time)$; next, it submits $T{r}_{del}$, $M{R}_{new}$, and $Has{h}_{prev}$ to ULS-PBFT, verifying the legality of the deletion transaction through the two-tier consensus of SCG and FCG; if consensus is reached, it generates a new block $Bloc{k}_{new}$ at the latest blockchain height, which includes $T{r}_{del}$, $M{R}_{new}$, $Has{h}_{prev}$, and the signature of the consensus nodes, then broadcasts $Bloc{k}_{new}$ to all alliance chain nodes for synchronous storage to ensure the deletion operation is tamper-proof and traceable. The merkle root update after data deletion process is outlined in Algorithm 3.

Algorithm 3: Merkle root update after data deletion
1	Input: $MT$$, T{r}_{del}$$, T{r}_{remain}$
2	Output: $M{R}_{new}$
3	Compute leaf node of deleted transaction via $H_4:Lea{f}_{del}=H_4(T{r}_{del})$;
4	Traverse the path from $Lea{f}_{del}$ to original root $M{R}_{old}$, record parent nodes $P_1,P_2,\dots ,P_k$; //locate modification path
5	Recompute hashes for affected parent nodes: for each $P_i$, replace $Lea{f}_{del}$ with hashes of adjacent valid leaves $Lea{f}_{\mathrm{valid}}=H_4(T{r}_{\mathrm{valid}})$ (where $T{r}_{\mathrm{valid}}\in T{r}_{\mathrm{remain}}$), then compute ${P_i}^{\prime }=H_4({P_i}^{left}\parallel {P_i}^{right})$; //ensure merkle tree consistency
6	Update root node: $M{R}_{new}={P_i}^{\prime }$; //solidify post-deletion block state
7	Return $M{R}_{new}$.

(5) Return deletion confirmation. After completing ciphertext deletion, index update, and block consensus, CM generates a deletion confirmation message $Confir{m}_{del}=H_2(Index\parallel “success”\parallel Bloc{k}_{new}.Hash)$; the message integrates core parameters to ensure non-tamperability, and sends it to $E{N}_i$ (for active deletion) or records it in the immutable audit log (for automatic deletion); for active deletion, $E{N}_i$ verifies the confirmation message by comparing it with the locally stored $Index$ and the broadcast $Bloc{k}_{new}.Hash$, confirming that the deletion is successful only when the verification passes, and updates the local $Index$ status to “deleted” to avoid repeated requests. Figure 3 illustrates an instance of the freshly created transaction ${Tr}^{\prime }$.

Figure 3. The most recent block height and ${Tr}^{\prime }$.

Algorithm 4 is the algorithmic code for deleting $SDchain$ on block $Tr$ under the ULS-PBFT consensus mechanism.

Algorithm 4: Deletion ( )
1	Input: $Index$$, I{D}_{E{N}_i}$$, H$$, P{K}_{sys}$$, K_{i,j}$$, T_{valid}$
2	Output: $Confir{m}_{del}$$, Bloc{k}_{new}$$, H_{new}$, Deletion status (Success/Failure)
3	If (Active deletion: $I{D}_{E{N}_i}$ is legitimate $\wedge$ ${\tau }_{del}$ is valid) $\vee$ (Automatic deletion: $current\_time>T_{valid}$), retrieve $Add{r}_C$ via $Index$ from RBT; // prevent malicious deletion
4	Delete $C$ from $Add{r}_C$ and erase encrypted $K_{i,j}$; mark RBT entry as “deleted”;
5	Generate deletion transaction $T{r}_{del}=H_4(Index\parallel “deleted”\parallel current\_time)$; compute $M{R}_{new}$ and $Has{h}_{prev}$;
6	Submit $T{r}_{del}$, $M{R}_{new}$, $Has{h}_{prev}$ to ULS-PBFT consensus for verification; // ensure deletion consistency
7	If consensus is reached: $Bloc{k}_{new}=\{Has{h}_{prev},M{R}_{new},T{r}_{del},Signatur{e}_{FNs}\}$. $H_{new}=H+1$. Broadcast $Bloc{k}_{new}$ to all nodes $Confir{m}_{del}=H_2(Index\parallel “success”\parallel Bloc{k}_{new}.Hash)$. Print: “Data deletion successful”; //solidify deletion result
8	Else, print: “Data deletion failed” Return deletion status: Failure.

4.4. Consensus Mechanism

The section elaborates on the ULS-PBFT protocol, focusing on its architectural framework and the specific stages of its consensus execution.

Figure 4 presents the makeup of the ULS-PBFT two-tier consensus, which integrates second-tier nodes (SN1), first-tier nodes (FN), and the associated consensus groups designated as SCG and FCG.

Figure 4. Framework of ULS-PBFT.

SN1: SN1 first executes the consensus of multiple SCGs in parallel. Regarding data storage, SN1 solely retains data from its respective SCG, excluding data from nodes located outside this group.

FN: FN not only participates in the FCG consensus but also takes on the role of SCG leader within this consensus framework. The consensus process initiated by the FCG can only commence once the SCG consensus has been finalized. This is due to the fact that each FN assumes the responsibility of storing the corresponding SCG data, which necessitates the retention of the entire blockchain system’s data.

Derivation of FN quantity: To resist $f$ malicious nodes, the BFT principle requires $N\ge 3f+1$. To balance fault tolerance and efficiency, the number of FNs is derived as $F=N/3$, where $f=F/2$ (maximum tolerable malicious nodes).

SCG: Each SCG includes some nodes from the secondary layer and one node from the initial layer; it allows the FCG to promptly ascertain the consensus results derived from the SCG.

SCG Grouping formula: SN1s are evenly divided into $F$ SCG via hash function $H_3$:

$$SC{G}_m=\{SN{1}_j\mid H_3({SN{1}_j}^{\prime }s ID)modF=m\} m\in \{0,1,\dots ,F-1\}$$

(1)

Each SCG contains approximately $\mid SN1\mid /F$ nodes and is managed by one FN as the group leader to coordinate intra-group consensus.

FCG: FCG is responsible for reaching the ultimate consensus finality within the ULS-PBFT.

ULS-PBFT consensus framework is categorized into three distinct entities: Clients, SN1s, and FNs. Specifically, FN is denoted as Replica i.0 embedded within the i-th SCG. In a similar vein, SN1 is identified as Replica i.j, representing the j-th SN1 located in the same group. Figure 5 delineates the execution flow of the mechanism.

Figure 5. Consensus workflow.

Request phase: Client issues a consensus request to every FNs Replica i. 0.

Pre-prepare phase: The pre-prepare message is dispatched by each FN to the SN1s located in the same SCG.

Prepare phase: Within each SCG, every SN broadcasts its preparation status to all nodes.

Commit phase: Within each SCG, nodes interchange consensus data with one another.

Reply phase: Each node submits its respective SCG consensus outcomes to the Client.

Request1 phase: During the secondary stage of ULS-PBFT, a master node is chosen from the set of all FNs, and Client subsequently transmits a consensus request to the designated master node. In this instance, Replica 1.0 acts as the master node.

Pre-prepare1 phase: Replica1.0 sends pre-prepared messages to Replica2.0, Replica3.0 and Replica4.0.

Prepare1 phase: Each Replica i.0 communicates its readiness to the other Replicas, with the exception of Replica 1.0.

Commit1 phase: All Replica i.0s interchange consensus data with one another.

Reply1 phase: Each Replica i.0 submits its respective consensus outcome to the Client, and the Client stores or deletes the data operation is completed.

The consensus message propagation between SCG and FCG layers process is outlined in Algorithm 5.

Algorithm 5: Consensus message propagation between SCG and FCG layers
1	Input: SCG consensus result ${Res}_{SCG}$, subgroup signature set $Si{g}_{SCG}$, $I{D}_{FN}$, FCG node set $N_{FCG}$, SCG node list $L_{SCG}$
2	Output: Propagation status (Success/Failure)
3	FN verifies $Si{g}_{SCG}$: count valid signatures $Si{g}_{valid}$, ensure $Si{g}_{\mathrm{valid}}\ge {\displaystyle \frac{2}{3}}|L_{\mathrm{SCG}}|$ (BFT threshold); //verify consensus legitimacy
4	If verification fails, return “Failure”;
5	Package propagation message $Msg=\{Re{s}_{SCG},Si{g}_{valid},I{D}_{FN},L_{SCG}\}$; //message standardization to prevent tampering
6	FN sends $Msg$ to all nodes in $N_{FCG}$ via encrypted channel; //prevent message eavesdropping
7	Each FCG node verifies $Msg$: validate $I{D}_{FN}$ via alliance chain ledger, verify consistency of $Si{g}_{valid}$ with $L_{SCG}$; //dual verification to prevent forgery
8	If all FCG nodes pass verification, return “Success”; else, return “Failure”.

5. Security Analysis

Theorem 1 (Correctness).

MCS-VD scheme satisfies functional correctness if all entities execute the protocol honestly.

Proof. 

Decryption correctness: Follows from the consistency of the SM9 algorithm. For any ciphertext $C_{data}$ encrypted under identity $ID$, the legitimate entity holding $S{K}_{ID}$ can correctly recover the plaintext $m$. □

Verification correctness: Follows from the bilinearity of the pairing $e$. For a valid signature $\sigma =S{K}_{EN}\cdot H_1(m)$ and public key $P{K}_{EN}=S{K}_{EN}\cdot P$, the equation $e(\sigma ,P)=e(H_1(m),P{K}_{EN})$ holds strictly.

Deletion Correctness: The deterministic index generation via $H_2$ and the immutable blockchain ledger ensure that any valid deletion request correctly locates the target ciphertext for removal.

Since all core components are individually correct and interactions are well-defined, the overall MCS-VD scheme is correct.

Data origin authentication (Unforgeability). To guarantee that data originates from legitimate entities, the existential unforgeability property is modeled through the following game and its security is proven.

Game definition: Game-EUF

Interaction: The Challenger $\mathcal{C}$ initializes the system and gives public keys to the Adversary $\mathcal{A}$. $\mathcal{A}$ can adaptively query the signing oracle ${\mathcal{O}}_{sign}$ for messages $m_i$ to obtain valid signatures ${\sigma }_i$.

Winning condition: $\mathcal{A}$ wins if a valid message–signature pair $(m^{\ast },{\sigma }^{\ast })$ is output such that $\mathrm{Verify}(m^{\ast },{\sigma }^{\ast })=1$ was never queried to ${\mathcal{O}}_{sign}$.

Theorem 2 (Unforgeability).

Under the Computational Diffie–Hellman (CDH) assumption in $G_1$, the BLS signature scheme in MCS-VD is existentially unforgeable against chosen-message attacks.

Proof. 

A reduction is constructed where a simulator $\mathcal{S}$ utilizes an adversary $\mathcal{A}$ (who wins Game-EUF with non-negligible advantage $ϵ$) to solve a CDH instance $(P,aP,bP)\in G_1^3$. The goal of $\mathcal{S}$ is to compute $abP$. □

Setup: $\mathcal{S}$ sets the target public key $P{K}_{EN}=aP$ (implicitly setting the secret key $x=a$) and transmits system parameters to $\mathcal{A}$.

Oracle simulation: $H_1$ is modeled as a random oracle. When $\mathcal{A}$ queries signatures for message $m_i$, $\mathcal{S}$ responds by programming the random oracle and utilizing the properties of discrete logarithms (without knowledge of $a$).

Extraction: If $\mathcal{A}$ outputs a valid forgery $(m^{\ast },{\sigma }^{\ast })$ such that $e({\sigma }^{\ast },P)=e(H_1(m^{\ast }),P{K}_{EN})$, then by the Forking Lemma, the signature component corresponding to the challenge, can be extracted. Since $H_1(m^{\ast })$ effectively embeds the component $bP$, the valid signature ${\sigma }^{\ast }$ allows $\mathcal{S}$ to compute $abP$.

Conclusion: If $\mathcal{A}$ succeeds with probability $ϵ$, then $\mathcal{S}$ solves the CDH problem with probability ${ϵ}^{\prime }\approx ϵ$. Since the CDH assumption states that $Ad{v}_{\mathcal{S}}^{CDH}(\lambda )$ is negligible, $ϵ$ must also be negligible.

$$Ad{v}_{\mathcal{A}}^{EUF}(\lambda )\le \mathrm{poly}(\lambda )\cdot Ad{v}_{\mathcal{S}}^{CDH}(\lambda )$$

(2)

Data integrity (Tamper-resistance). To ensure data is not modified during transmission or storage, the tamper-resistance property is analyzed.

Game definition: Game-Integrity

Interaction: $\mathcal{A}$ controls the communication channel. $\mathcal{A}$ observes valid storage requests and is permitted to query the storage oracle.

Winning condition: $\mathcal{A}$ wins if a modified tuple $({C^{\prime }}_{data},Ta{g}^{\prime },{\sigma }^{\prime })$ (where ${C^{\prime }}_{data}\ne C_{data}$) is submitted that successfully passes the CS verification logic.

Theorem 3 (Tamper-resistance).

Assuming the Collision-Resistant Hashing (CRH) and the unforgeability of signatures, the scheme is tamper-resistant.

Proof. 

In Game-Integrity, $\mathcal{A}$ wins if a modified tuple ${\tau }^{\prime }=({C^{\prime }}_{data},Ta{g}^{\prime },{\sigma }^{\prime })$ that passes verification is output. Let $E_{coll}$ be the event that $\mathcal{A}$ finds a hash collision for $H_2$, and $E_{forge}$ be event that $\mathcal{A}$ forges a signature. The advantage of $\mathcal{A}$ is bounded by

$$Ad{v}_{\mathcal{A}}^{Int}(\lambda )\le \mathrm{Pr}[E_{coll}]+\mathrm{Pr}[E_{forge}]$$

(3)

□

Hash collision: If $C_{data}^{\prime }\ne C_{data}$ but $H_2(C_{data}^{\prime })=H_2(C_{data})$, the CRH property is broken. Thus, $\mathrm{Pr}[E_{coll}]\le Ad{v}_{\mathcal{A}}^{CRH}(\lambda )$.

Signature forgery: If no collision occurs, then the signed message digest must be different. For ${\sigma }^{\prime }$ to be valid, a signature must have been forged on the new digest. Thus, $\mathrm{Pr}[E_{forge}]\le Ad{v}_{\mathcal{A}}^{EUF}(\lambda )$. Combining these, since both terms on the right are negligible (based on the CRH assumption and Theorem 2), the total advantage $Ad{v}_{\mathcal{A}}^{Int}(\lambda )$ is negligible.

Verifiable deletion soundness. To ensure deleted data cannot be recovered, the Soundness of Verifiable Deletion is modeled.

Game definition: Game-Del

Interaction: After a target message $m^{\ast }$ is encrypted and stored, the deletion protocol is executed by the Challenger $\mathcal{C}$. $\mathcal{A}$ is given the deleted view, which includes the updated blockchain transaction logs, public parameters, and the state of the cloud storage, where the ciphertext has been removed.

Winning condition: $\mathcal{A}$ wins if $m^{\ast }$ can be correctly output based solely on the deleted view.

Theorem 4 (Deletion soundness).

The scheme achieves sound verifiable deletion assuming the SM9 encryption is IND-ID-CPA secure (based on the BDH assumption) and the ULS-PBFT consensus is secure.

Proof. 

Let $Ad{v}_{\mathcal{A}}^{Del}(\lambda )$ be the probability that $\mathcal{A}$ distinguishes the deleted message $m^{\ast }$ from random in Game-Del. □

Reduction to encryption: Assume the deletion protocol is executed honestly by the majority nodes. The ciphertext $C_{data}$ is removed. The only advantage for $\mathcal{A}$ comes from any prior intercepted ciphertext $C_{intercept}$. Distinguishing $m^{\ast }$ from $C_{intercept}$ without the private key constitutes breaking the IND-ID-CPA security of SM9.

Reduction to consensus: Alternatively, $\mathcal{A}$ attempts to compromise the integrity of the deletion log to retain data. This requires controlling more than ${\displaystyle \frac{N}{3}}$ nodes to fork the blockchain or revert the state, violating the BFT assumption. Thus, the advantage is bounded by

$$Ad{v}_{\mathcal{A}}^{Del}(\lambda )\le Ad{v}_{\mathcal{A}}^{SM9}(\lambda )+Ad{v}_{\mathcal{A}}^{BFT}(\lambda )$$

(4)

Under the BDH assumption (which implies SM9 security) and the honest majority assumption, both terms are negligible.

Collusion attack: The security of this scheme rests on the discrete logarithm problem, ensuring that signer anonymity and key confidentiality are preserved even in the event of internal key exposure. Additionally, by employing a reliable third-party administrator, the system precludes malicious key disclosure. Therefore, collusive attacks are effectively mitigated by this architecture under the pair of conditions described.

Double spend attack: When a double spend attack is attempted by a malicious node, two possible scenarios may occur. In the first scenario, consensus confirmation is achieved for only one of the blocks from at least 2/3 of the total nodes, while the other block receives confirmation from fewer than 2/3 of the nodes. In the second scenario, neither block secures consensus confirmation from the required number of nodes. Consequently, this system is effectively protected against double-flower attacks. In the course of the consensus execution, adversaries are precluded from attaining the necessary consensus confirmations for both blocks, thereby enhancing the system’s overall integrity and robustness.

Replay attack: By embedding timestamps within the messages exchanged between successive nodes (from $SN$ to $EN$, $EN$ to $ES$, $ES$ to $RC$), the system verifies integrity via the sender’s digital signature. This verification process precludes the possibility of a receiver being deceived by maliciously replayed data, thereby safeguarding the scheme against replay attacks.

The security comparison with other schemes is shown in Table 4. The comparison shows that the scheme outperforms existing methods in various attack defense capabilities and better meets the high demand of the smart grid for secure storage of electricity data.

Table 4. Security comparison.

Comparison Dimension	MCS-VD	Mishra [36]	Hua [37]	Jin [41]
Correctness	Strong	Relatively Strong	Relatively Strong	Relatively Strong
Anti-tampering attack	Strong	Weak	Relatively Strong	Medium
Anti-forgeability attack	Strong	Weak	Medium	Weak
Verifiable deletion soundness	Strong	Weak	Medium	Weak
Anti-collusion attack	Strong	None	Medium	None
Anti-double spend attack	Strong	None	Relatively Strong	None
Anti-replay attack	Strong	Weak	Medium	Medium

6. Performance Analysis

To evaluate the scheme’s performance comprehensively, a sequence of experiments was undertaken. (1) Dataset size: to accurately simulate smart grid scenarios and achieve repeatable experiments, a synthetic time-series electricity consumption record dataset is used to simulate the output of real smart meters. The dataset contains 300,000 records, and the total amount of data is about 3.6 GB, 4 KB per transaction, and 220 test blocks. (2) Simulation conditions: based on Ubuntu 17.04 LTS with the Hyperledger Fabric 2.5 framework, the hardware includes Intel Core i5 1.8 GHz, Intel i7-1260P 2.1 GHz mainframe and 32 GB RAM, the environment configuration is shown in Table 5. (3) Network topology: distributed multi-cloud topology with six parallel CSPs, cross-regional communication support. (4) Number of nodes: 50~1600. (5) Bandwidth assumption: 10 Gbps Ethernet, complying with smart grid industrial standards. (6) Antagonistic behavior: 33% of byzantine nodes that commit malicious attacks.

Table 5. Hardware and software environment attributes.

Software/Hardware	Argument
Operating system	Ubuntu Linux 17.04LTS
CPU	IntelCore i5 1.8 GHz, Inteli7-1260P 2.1 GHz
Writing language	Go
Internal memory	32 GB
Development environment	Hyperledger Fabric

6.1. Consensus Mechanism Performance Analysis

6.1.1. Theoretical Analysis

The various performances of PBFT [42], RAFT [43], PRAFT [44], RPBFT [44], and ULS-PBFT consensus are summarized in Table 6. According to the results tabulated above, the storage overhead and communication overhead of PBFT are high compared to ULS-PBFT; although the communication overhead of RAFT is low, its byzantine fault tolerance and storage overhead are not advantageous compared to ULS-PBFT. From the table, it can be seen that the ULS-PBFT used in the paper has benefits in byzantine fault tolerance, storage overhead, and communication overhead.

Table 6. Theoretical analysis.

Consensus Algorithm	Byzantine Fault Tolerance	Storage Overhead	Communication Overhead
PBFT [42]	Yes	N2 s	N2
RAFT [43]	No	N2 s	N
PRAFT [44]	Yes	(N + 4)2 s/4	2 N
RPBFT [44]	Yes	(N2 + 16 N) s/5	3.4 N
ULS-PBFT	Yes	N1.5 s	0.5 N

6.1.2. Consensus Latency

Consensus latency is the total time between transaction submission and final confirmation of uploading, which includes request propagation delay, consensus processing delay, and uploading verification delay. To quantitatively compare the consensus latency of the proposed ULS-PBFT with PBFT [42], RAFT [43], PRAFT [44], and RPBFT [44], comparative experiments were conducted at different node sizes from 200 to 1600, as evidenced by the results in Figure 6.

Figure 6. Evaluation of consensus latency.

As shown in Figure 6, the consensus latency of all evaluated protocols grows in correlation with the node count, but the growth characteristics vary significantly. At 200 nodes, the latency of PBFT, RAFT, PRAFT, RPBFT, and ULS-PBFT are about 2000 ms, 1500 ms, 1000 ms, 800 ms, and 200 ms, respectively. At 800 nodes, the latency of PBFT goes up to about 3000 ms, RAFT to about 2500 ms, PRAFT to about 2000 ms, RPBFT to about 1800 ms, and ULS-PBFT to only about 700 ms. At 1600 nodes, the latency of PBFT is close to 5000 ms, while ULS-PBFT is only about 700 ms. RPBFT rises to about 1800 ms, while ULS-PBFT only rises to about 700 ms. At 1600 nodes, the delay of PBFT is close to 5000 ms, while that of ULS-PBFT is only 37% of that of RAFT, 44% of that of PRAFT, and 50% of that of RPBFT, which demonstrates the robustness of the ULS-PBFT multi-tier design when scaling to massive network sizes.

6.1.3. Consensus Communication Overhead

The entire quantity of data produced by nodes exchanging messages during the consensus process is known as the consensus communication overhead, including the number of messages transmitted at each stage of the consensus process. To quantitatively compare the consensus communication overhead of the proposed ULS-PBFT with PBFT [42], RAFT [43], PRAFT [44] and RPBFT [44], comparative experiments at a scale of 200 to 1600 nodes and the findings are visualized in Figure 7.

Figure 7. Evaluation of consensus communication overhead.

As shown in Figure 7, as the network scales from 200 up to 1600 nodes, and the communication overhead of PBFT increases dramatically from about 10⁴ KB to 10⁶ KB, which is an increase of nearly two orders of magnitude; the overhead of RAFT and PRAFT increases from about 10² KB to 10³ KB, which is an increase of about one order of magnitude, respectively; while the overhead of ULS-PBFT increases only from about 10¹ KB to 10² KB. At 1600 nodes, the communication cost of ULS-PBFT is roughly 1/10,000 of that of PBFT, while it is about 1/10 of that of RAFT. This result shows that ULS-PBFT keeps the communication overhead at a low level compared to the other four consensus mechanisms while maintaining byzantine fault tolerance.

6.2. Scheme Comparison

To comprehensively evaluate the performance of the presented MCS-VD, three advanced data storage and deletion schemes are selected as baselines. Ref. [36] proposes a scheme integrating redactable blockchain with IPFS to realize data storage and deletion. Ref. [37] represents the mainstream approach of blockchain-assisted secure deduplication for cloud storage. Ref. [41] presents a typical scheme combining auditing and deduplication for multi-cloud storage. All three schemes address secure storage and data deletion issues within cloud storage and blockchain scenarios, aligning highly with the research objectives of MCS-VD and facilitating a focused comparison of core performance differences.

To further highlight the core functional differences between MCS-VD and the baseline schemes, a comparison is conducted across the eight dimensions of confidentiality, integrity, flexibility, scalability, availability, verifiable deletion, trust assumptions, and system scope, as detailed in Table 7. The results demonstrate that the proposed method possesses significant advantages over the existing solutions.

Table 7. Comparison of schemes.

Scheme	Mishra [36]	Hua [37]	Jin [41]	MCS-VD
Confidentially	×	√	√	√
Integrity	×	√	×	√
Flexibility	√	×	√	√
Scalability	√	×	√	√
Availability	×	√	√	√
Verifiable deletion	√	×	√	√
Trust assumptions	Semi-trusted	Semi-trusted	Trusted	Semi-trusted
System scope	Decentralized cloud storage	Large scale general cloud	General multi-cloud storage	Smart grid edge–cloud

6.3. Storage Costs

To benchmark the storage efficiency of MCS-VD, we monitored the space consumption of nodes during the generation of 200 blocks. While maintaining uniform external conditions, the number of blocks was treated as the independent variable to verify the storage requirements of the four investigated models, with the outcomes illustrated in Figure 8.

Figure 8. Comparison of storage overhead with Mishra et al. [36], Hua et al. [37], and Jin et al. [41].

As shown in Figure 8, single-block storage space rises with the number of blocks for all schemes, but MCS-VD has the significantly slowest growth rate. At 50 blocks, the single-block storage of all schemes is maintained within 50 KB, and the difference between schemes is small, because the block size has not yet amplified the redundant storage overhead that comes with each scheme’s mechanism. As the block count scales to 200, the single-block storage space of MCS-VD is only about 180 KB, while Ref. [36] exceeds 500 KB, Ref. [37] approaches 300 KB, and reaches about 350 KB. The storage strategy of MCS-VD accurately breaks through the storage pain points of full volume data uploading and the redundant metadata accumulation of traditional solutions and has a greater advantage over the other three schemes.

6.4. Throughput

Throughput, which is precisely defined as the number of transactions the system can execute in a given amount of time, is a crucial metric for assessing a blockchain system’s execution efficiency. The experiment tests the throughput changes under various blockchain node sizes of 50–200, sets the block size to include 1200 transactions, fixes other parameters, and conducts comparative trials. The findings are displayed in Figure 9.

Figure 9. Comparison of throughput with Mishra et al. [36], Hua et al. [37], and Jin et al. [41].

Figure 9 illustrates that the throughput of all evaluated protocols exhibits an upward trajectory as the network scale expands, but MCS-VD has the fastest growth rate and the highest absolute throughput. With the node count expanding from 50 to 200, the throughput of MCS-VD increases from about 1300 tps to about 4900 tps; Ref. [36] increases from about 1100 tps to about 3300 tps, Ref. [41] increases from about 800 tps to about 2900 tps, and [37] stays at a lower level. At 200 nodes, the throughput of MCS-VD is about 1.5 times that of [36], 4.9 times that of [37], and 1.7 times that of [41]. So, the proposed framework demonstrates superior operational efficiency; this advantage accurately fits the operation characteristics of the smart grid with massive nodes and high-frequency data interaction.

6.5. Storage Latency

One crucial metric that demonstrates the scheme’s capacity to store data is storage latency. The average storage latency is used as an evaluation index since the latency difference between this scheme and other storage schemes focuses on the effects of various consensus processes on the storage and uplinking of ciphertext data. Figure 10 displays the results of the experiment.

Figure 10. Comparison of average storage latency with Mishra et al. [36], Hua et al. [37], and Jin et al. [41].

As shown in Figure 10, Ref. [36] has the fastest growth rate, with the total number of blocks expanding from 20 to 220, the latency rises from approximately 1000 ms to over 6000 ms; while MCS-VD maintains the slowest growth rate, under the same block range, its latency only increases from approximately 200 ms to 1800 ms. Even at 220 blocks, the storage latency of MCS-VD is only about 30% of [36], about 45% of [37], and about 40% of [41]. This advantage stems from the design of encrypted compression storage, which may successfully satisfy the low latency requirements for the smart grid’s real-time data uplink storage.

6.6. Communication Overhead

To evaluate the communication efficiency of this scheme, the total communication overhead of MCS-VD is compared with the total communication overhead of [36,37,41] and these outcomes are detailed in Table 8. MCS-VD has a smaller communication overhead than the other three methods, as Table 8 illustrates.

Table 8. Communication overhead comparison.

Scheme	Total Communications Overhead
Mishra [36]	$n\cdot \left|G_1\right|+4\left|p\right|+{\log }_2\left(l\right)+\left|2n\right|+n\left|\left(p+5\right)\right|+3\left(n+4\right)G_1$
Hua [37]	$n\cdot \left|G_1\right|+3\left|p\right|+{\log }_2\left(l\right)+\left|2n\right|+n\left|\left(p+4\right)\right|+\left(n+2\right)G_1$
Jin [41]	$n\cdot \left|G_1\right|+2\left|p\right|+{\log }_2\left(l\right)+\left|n\right|+n\left|\left(p+2\right)\right|+\left(n+3\right)G_1$
MCS-VD	$n\cdot \left|G_1\right|+2\left|p\right|+{\log }_2\left(l\right)+\left|n\right|+n\left|p\right|+\left(n+1\right)G_1$

Symbols in the formulas are defined as follows: let $n$ denote the total count of nodes within the network; $\left|G_1\right|$ denotes the bit length of group elements in $G_1$; $\left|p\right|$ is the bit length of parameter $p$; $l$ stands for the data length.

6.7. Computation Overhead

This experiment utilizes the total computation overhead of the on-chain data deletion scheme to measure its performance, and since the number of data files affects the scheme computation time, the performance of the scheme can be evaluated by changing the number of data files and observing the change in the scheme’s elapsed time. References [36,37,41] are compared with the scheme and experimental outcomes and are illustrated in Figure 11.

Figure 11. Evaluation of computational overhead with Mishra et al. [36], Hua et al. [37], and Jin et al. [41].

As shown in Figure 11, the computational overheads of all four schemes tend to increase along with the file count; however, the proposed scheme demonstrates a better efficiency advantage. The computational overhead of MCS-VD grows at a significantly slower rate, which is about 20 ms at 60 files, which is 50% lower than that of [36], and 80% lower than that of [37,41]. At a file scale of 120, the overhead of MCS-VD is about 180 ms, which is 10% lower than that of [36] and 28% lower than that of [37,41]. Upon the file quantity attaining 120, the overhead of MCS-VD is about 180 ms, which is 10% less than that in [36] and 28% less than that in [41]. In a large-scale scenario of 200 files, the overhead of MCS-VD is maintained at about 350 ms, which is 22.2%, 30%, and 32.7% less than that in [36,37], and [41], respectively. This fully verifies the effectiveness of this scheme based on tag matching and timestamp-driven design logic in reducing the computational complexity, especially for the deletion of massive data in the smart grid, which can avoid the performance bottleneck in large-scale scenarios.

6.8. Deletion Latency

The deletion latency is the total elapsed time from the submission of a data deletion request to the return of a valid deletion completion confirmation from system, and a core real-time metric differentiated from storage latency. To quantitatively verify the real-time advantage of the deletion mechanism of the scheme, the deletion delay comparison experiments between MCS-VD and [36,37,41] are carried out, and the experimental results are illustrated in Figure 12.

Figure 12. Evaluation of deletion latency with Mishra et al. [36], Hua et al. [37], and Jin et al. [41].

As shown in Figure 12, while the deletion latency across all four schemes escalates in correlation with the expanding file count; MCS-VD demonstrates a notably more gradual growth trajectory compared to its counterparts. When the quantity of files grows from 60 to 200, the latency of MCS-VD only increases from about 70 ms to about 120 ms, which is a cumulative increase of 50 ms, while Ref. [36] increases from about 140 ms to about 270 ms, which is an increase of 130 ms; Ref. [37] increases from about 100 ms to about 210 ms, which is an increase of 110 ms, and Ref. [41] also increases from about 100 ms to about 200 ms, which is an increase of 100 ms. Even at 200 files, MCS-VD latency is still under 120 ms, 55.6% lower than [36], 42.9% lower than [37], and 40.0% lower than [41]. This advantage comes from the tag index matching and ULS-PBFT consensus design of MCS-VD, which can effectively adapt to the real-time demand of smart grid data cleaning.

7. Conclusions

The scheme adopts a blockchain-integrated multi-cloud storage architecture, and stores edge-encrypted power consumption data in a distributed manner across multi-cloud servers. It takes advantage of the non-tamperability of the alliance chain and the redundancy and fault tolerance of the multi-cloud architecture and effectively alleviates the risk of data loss. At the same time, the architecture can also prevent sensitive data from leaking to cloud service providers (CSPs) and shared users, further protecting data privacy. Key data transmission information is recorded on the blockchain to ensure transmission integrity. The transaction deletion mechanism is further designed to improve flexibility, and the ULS-PBFT consensus algorithm with hierarchical node grouping is used to reduce storage overhead and improve transaction efficiency. Security and performance analysis and verification confirm that the scheme achieves high throughput and low latency while ensuring data confidentiality, availability and integrity.

The following are the limitations and future directions:

(1) The experiments use synthetic timing power datasets to simulate smart meter outputs, which ensures the repeatability of the experiments but lacks the data complexity in real smart grid scenarios, which may lead to performance bias in real deployments. We plan to extend the experimental validation using the UK-DALE dataset and anonymized real-world smart meter data to verify the scheme’s adaptability under physical constraints. Furthermore, we will focus on lightweight algorithm optimizations and multi-scenario testing to ensure the system’s robustness for and compliance with critical smart grid infrastructure.

(2) Though MCS-VD delivers comprehensive security, it lacks both quantitative analysis of security-related overhead, whose absence hinders accurate security–efficiency trade-off assessment and practical deployment guidance despite extra computational/communication costs from core security operations, and decoupled component analysis to quantify the specific contribution of each independent module. To address these gaps, future work will supplement the required quantitative analysis and establish a trade-off model to measure how security parameter adjustments impact throughput and latency, validated via comparative experiments to provide node-specific security configuration guidance; it will also conduct a quantitative evaluation of system metrics under different configurations, including the impact of SCG hierarchical grouping versus flat consensus structures on communication complexity and latency, the contribution of FCG finalization steps to finality time and fork resistance, efficiency gains of BLS signature aggregation over traditional elliptic curve signatures in message size and verification overhead, and the performance advantages of RBT-based indexing over linear search for verifiable deletion retrieval and deletion speed.

(3) The current evaluation lacks stress tests, which cannot validate the robustness of the scheme under extreme conditions and therefore cannot determine whether the system can maintain stable throughput, low latency, and data consistency under extreme conditions. In addition, the current trust model relies on CC for centralized key generation, posing a single-point trust risk, yet this is a deliberate trade-off to simplify deployment and minimize overhead. To address these issues, future research will design stress tests for extreme conditions and optimize the ULS-PBFT consensus grouping policy and multi-cloud dynamic load balancing mechanism based on the test results, thus enhancing the fault tolerance and dynamic adjustment capability of the scheme to ensure stable operation in extreme smart grid environments. And leveraging modular compatibility, we plan to implement a threshold SM9 scheme using DKG protocols. Replacing the single KGC with a decentralized committee will minimize trust assumptions and enhance resilience for large-scale grid federations.

(4) The limitations of the deletion verification strategy lie in its reliance on the semi-trusted CM assumption, its inability to prevent passive data leakage, and the inherent BFT consensus constraints that cause delays when malicious nodes approach ${\displaystyle \frac{1}{3}}$; furthermore, it only verifies logical deletion without guaranteeing the physical absence of data residues. To address the limitations, future work will introduce a media-level erasure proof mechanism for physical data removal verification, optimize the consensus grouping strategy to enhance malicious node tolerance, and add a CM behavior-auditing module to reduce reliance on its semi-trusted assumption, thus achieving dual verification of logical deletion and physical erasure.