SFedChain: blockchain-based federated learning scheme for secure data sharing in distributed energy storage networks

SFedChain scheme

Before we introduce SFedChain, we will outline the relevant concepts and keyword definitions in SFedChain.

MasterChain: MasterChain is used to register new sites and new users, records the main configuration information of the site, manage user data access control, and store the joint modeling model. We use MasterChain to publish the requested task.

RetrievalChain: RetrievalChain is used to record the summary of site document information and the Unified Retrieval Graph that is regularly established, and it is mainly responsible for the retrieval of task-related parties.

ArgChain: The upload of local model parameters by each party and the update of the aggregated model are recorded in ArgChain in the form of transactions.

DataHolder: DataHolder is a energy storage device registered with MasterChain. It has private local data and can rely on its own local dataset to train to participate in the joint modeling.

TaskRequester: TaskRequester is the user who publishes the requested task. It needs to pay the corresponding coin for the requested task to start the joint modeling.

Worker: In SFedChain, Worker is the task-related DataHolder obtained from RetrievalChain according to the requested task. It is similar to the role of participant in traditional distributed deep learning, but it can’t train alone to obtain a joint modeling model, and can only use its limited dataset for local training to participate in joint modeling tasks.

Committee Members: In each round of local model parameter aggregation, Z Workers with higher CreditCoin are selected from the Y Workers participating in the joint modeling to form Committee Members. The Worker with the highest CreditCoin is selected as the Leader of the committee.

CreditCoin: At the beginning of the joint modeling process, SFedChain allocates the same amount of CreditCoin to the Workers participating in the joint modeling process to represent the initial credit of each Worker in the joint modeling process.

In the scenario of distributed energy storage networks, we designed the system model of SFedChain. We combined blockchain technology with traditional federated learning technology to achieve secure and efficient distributed data sharing. MasterChain was mainly responsible for issuing requested tasks and recording joint modeling models, which can improve the efficiency of the system in processing tasks. RetrievalChain was used to record the Unified Retrieval Graph that as generated regularly, and realized the quick retrieval of Workers. Workers uses its dataset to train local models, we combined the federated learning technology and use the parameter entry method to ensure the safety of parameter sharing in the joint modeling process. Committee Members and Leader in the committee were selected for aggregation of local model parameters through SFedChain’s novel aggregation strategy. Therefore, the system does not require a reliable third party for parameter aggregation, which further ensures the security of the joint modeling process. At the same time, the system introduces an incentive mechanism to encourage the active participation of DataHolder by rewarding honest participants. Eventually, TaskRequester will obtain the result of the request through MasterChain.

Threat model

We paid attention to the secure data sharing between distributed multiple parties, and selected Y Workers related to the requested task among the X data providers to complete a joint modeling task. In a real-world industrial environment, task requesters and co-modeling participants are usually considered dishonest. They do not want to pay for the requested task or deliberately sabotage the joint modeling process and steal confidential information from other participants. From the above analysis, we can see that the proposed system model may face the following three threats:

1. Quality of the locally trained model: Workers may provide poorly trained model parameters due to local data set quality problems, or malicious Workers want to get rewards but do not participate in training, so they directly provide incorrect local models.

2. Instability of the parameter aggregation service: A dishonest parameter aggregation server may provide incorrect aggregation models, which will result in a serious degradation of the quality of the joint modeling model, or the parameter aggregation service may suffer malicious attacks and cause the joint modeling process to be interrupted.

3. Privacy protection in the data sharing: Workers and DataHolders participating in the joint modeling process want to obtain the parameter information of other participants through inference attacks or other methods, thereby causing user privacy leakage.

Architecture design

The SFedChain architecture we proposed consists of three parts: MasterChain module, RetrievalChain module, and ArgChain module based on federated learning. MasterChain module establishes a secure connection between all participants, and records the joint modeling model of each requested task to achieve a rapid response to the same requested task of other users. RetrievalChain module uses the regularly generated Unified Retrieval Graph to achieve efficient retrieval of the relevant DataHolders of the requested task, and uses the retrieved Workers to implement joint modeling. ArgChain module combines with traditional federated learning to realize the secure sharing of local model parameters, and uses novel smart contract and consensus mechanism to improve the quality and efficiency of the joint modeling model. We use the “three-chain-in-one” architecture to achieve secure joint modeling without the original data coming out of the local situation, and maintain the system’s lasting operation through all DataHolders.

Before a new user initiates a requested task or a new DataHolder participates in joint modeling, both should first register through MasterChain. TaskRequester publishes the requested task to MasterChain through its nearby DataHolder_Req site server, Fig. 2 shows the working mechanism of our proposed architecture, DataHolder_Req first searches MasterChain whether the joint modeling model of the same requested task has been recorded. If found, the system will download the joint modeling model GM_i recorded in MasterChain, and then return the result of the requested task Req(GM_i) to the TaskRequester. Otherwise, for a new task, the task-related information is sent to RetrievalChain to retrieve the task-related DataHolders, and then, the system will use the retrieved Workers to perform the joint modeling process through ArgChain. In each iteration, the new CreditCoin owned by each Worker is calculated based on the CreditCoin owned by each task-related parties and the local model accuracy, and then new Leader in committee and Committee Members are elected to aggregate and agree on the joint model. Finally, the result Req(GM_Req) of the requested task is returned to the TaskRequester in the form of a transaction through MasterChain. The coin paid by TaskRequester are distributed in the same proportion according to the proportion of CreditCoin ultimately owned by Workers participating in the joint modeling, in this way, more data holders will be attracted to join the system.

Unified retrieval graph

As a classic image data information extraction technology, CNN has been applied in many fields such as image segmentation, video classification, and target recognition (Liu, Liu & Zhang, 2022). For traditional CNN technology, an input image is processed by a convolutional layer, a pooling layer, and a linear layer to obtain the final result. But for text data, Chen (2015) proposed that the CNN model can also learn the content of text information. The output of the operating data of each device in the energy storage networks is mostly recorded in text format. How to use text data to measure the similarity of data sets between DataHolders and to achieve retrieval of task-related parties, inspired by Liu, Guo & Chen (2021), we proposed the following method. The process is shown in Fig. 3.

For the processing of text data, the use of pre-trained language models (Yamada & Shindo, 2019; Yamada et al., 2020) for text characterization is considered a reliable method. We first used the selected pre-trained language model to process the text data of each DataHolder, then use the convolutional layer and the ReLU activation function to process to obtain the feature map representation of data information of each DataHolder. Finally, the sparse representation in each channel was obtained through multi-channel convolution kernel processing, $Sparsity=\frac{Numberofnon-zerovaluesinvector}{Totalnumberofvectorelements}$, the data information owned by each DataHolder is abstracted into a matrix represented by sparsity. Since we use the sparsity expression of text statistics to retrieve Workers, it is difficult to steal the original information.

In order to continue to simplify the calculation of data similarity between DataHolders, we further processed the sparsity expression of data of each DataHolder. For the i − th DataHolder, we used $DAT{A}_i=\left[\left[d_{11}^i,d_{12}^i,\dots ,d_{1n}^i\right],\dots ,\left[d_{m1}^i,d_{m1}^i,\dots ,d_{mn}^i\right]\right]$ represents the data it holds, where m represents the number of texts of the filtered DataHolder. Since the Jaccard distance formula has the advantage of being independent of position and order, this article used it to calculate data similarity. Communication efficiency will also affect the creation of the Unified Retrieval Graph, the actual physical distance between DataHolders will become a factor that must be considered. Therefore, we proposed an improved Jaccard distance formula suitable for our proposed system (1)${\displaystyle Similarity\left({NODE}_i,{NODE}_j\right)=\frac{|{NODE}_i\cap {NODE}_j|}{|{NODE}_i\cup {NODE}_j|+\alpha \ast distance\left({NODE}_i{,NODE}_j\right)}}$

where NODE is the sparse representation matrix of DataHolder, distance represents the actual physical distance between DataHolder_i and DataHolder_j and α is a hyperparameter, which is used to adjust the holding ratio of the actual physical distance.

In order to improve the efficiency of calculation and processing, we used graphs to express the relationship between DataHolders, as shown in the following definition 1:

$Definition1\left(UnifiedRetrievalGraph\right)$: A Unified Retrieval Graph G = {V, E} consists of a series of nodes and edges. Each vertex V_i represents a DataHolder, and its weight represents the identity information of DataHolder, such as ID, data type, data size, etc. Each edge E_ij connects vertices V_i and V_j, and its weight W_Eij represents the ratio of the similarity between the two vertices to the maximum vertex similarity value ($\widehat{W_{E_{ij}}}=\frac{W_{E_{ij}}}{Max\left(W_{E_{ij}}\right)}$).

Finally, with the assistance of Unified Retrieval Graph, when users submit tasks, we can find the parties involved in the task very accurately and efficiently. In order to ensure the timeliness of the unified search graph search, it is updated after performing a certain number of search operations or adding a new data holder.

Task-related parties retrieval

The sharing of raw data will not only bring security threats, but also a series of privacy leaks. Therefore, we do not share the original data of DataHolder, and use the Unified Retrieval Graph to retrieve the task-related parties. When a TaskRequester publishes a requested task, the relevant information of the task will be recorded in the MasterChain in the form of a transaction. The MasterChain will send the processed task information to RetrievalChain to retrieve the task-related parties. The retrieval process in RetrievalChain is shown in Fig. 4.

RetrievalChain obtains ID_DH (the ID of the DataHolder) information of nearby nodes through ID_TR (the ID of the TaskRequester). According to the coin paid by TaskRequester, the ratio of retrieving the number of DataHolders is $rati{o}_{retrieval}=\frac{coin}{CONS{T}_{coin}}$. We first traverse the Unified Retrieval Graph, and then query the vertices V_DH representing ID_DH, retrieve its adjacent edges. If the weight W_Ei,j of the adjacent edge E_i,j is less than ratio_retrieval, the vertex V_i connected by the adjacent edge E_i,j will be included in the task-related parties set $SE{T}_{DH}\left(V_j\in SE{T}_{DH}\right)$. After the traversal is over, the nodes contained in the set SET_DH are the Workers participating in the joint modeling. At the same time, the equal number of CreditCoins are equally divided among Workers to identify the initial credit of each participant.

Data sharing process

In distributed energy storage networks, the first energy storage device to join the system is responsible for the deployment of the blockchain network. Subsequent devices need to register their own nodes through MasterChain, and then use their site servers to jointly maintain the operation of the blockchain network. Before publishing the requested task, the new TaskRequester should first register as a user through the nearby device DataHolder_req, and then initialize the requested task $Req\left(r1,r2,\dots ,rn\right)$ and pay a certain amount of coins, and then DataHolder_req submits the requested task to MasterChain in the form of a transaction. MasterChain queries its recorded historical joint model, if there is a joint model GM_i for the same request task and the coin paid by TaskRequester is less than or equal to the coin spent on establishment of GM_i, DataHolder_req will download the model GM_i and return the result Req(GM) to TaskRequester. Finally, the coin paid by the TaskRequester are distributed according to the proportion of CreditCoin owned by each Worker after GM_i is jointly modeled. On the contrary, If the joint modeling model GM that matches the requested task is not found, or the GM is hit but the coin paid by the TaskRequester is more than the coin paid by the user when the GM_i is established, the system will retrain the model for the requested task. During joint modeling, the system first uses the Unified Retrieval Graph to perform task-related parties retrieval through RetrievalChain, and then performs joint modeling using the retrieved Workers. After multiple iterations of training through ArgChain, the system finally obtains the joint modeling model GM_Req that satisfies the requested task, and then uploads GM_Req to MasterChain in the form of a transaction, and returns the result Req(GM_Req) to TaskRequester, finally the system performs the remuneration distribution of coin paid by TaskRequester.

The detailed steps of our data sharing scheme are as follows, Fig. 5 shows the process of data sharing.

1. System deployment: The first DataHolder to join the system is responsible for the deployment of the system. First, it will create MasterChain, RetrievalChain and ArgChain, and then register its node information in MasterChain. There are two main types of transactions in MasterChain: registration records of new users and new nodes, and release records of joint models.The main transaction forms in RetrievalChain include: update records of Unified Retrieval Graph and retrieval records of task-related parties. The transaction forms in ArgChain mainly include: the upload record of local training models and aggregate model.

2. System Initialization: When a new DataHolder applies to join the system, the system distributes ID_DH through MasterChain (ID_DH consists of device code, module code and sensor code), and then it will work with other DataHolder to maintain the operation of the system. Similarly, a new user should first register with the nearby DataHolder before posting the requested task to obtain its unique ID_user.

3. Task Request: Task Requester submits the requested task $Req\left(r1,r2,\dots ,rn\right)$ through its nearby DataHolder _Req, and pays the corresponding coin according to the expected model effect. MasterChain checks whether the TaskRequester has been registered. If the check passes, the nearby energy storage deivce DataHolder _Req uploads the task to MasterChain as a transaction.Otherwise, the system performs a new user registration operation.

4. Historical joint model query: Once the task submitted by TaskRequester is accepted by MasterChain, the system will query the historical union model. If there is a joint model GM_i of the same requested task, the coin paid by TaskRequester is less than or equal to the coin _i spent on establishment of GM_i, and greater than the minimum payment fee αcoin _i. Then, the result Req_GMi is returned to TaskRequester, and the coins paid by it are distributed according to the proportion of CreditCoin owned by each worker after GM_i joint modeling. On the contrary, if the joint model GM that matches the task is not found, or GM_i is queried but TaskRequester paid more coins than GM_i was created, retrain the joint model.

5. Retrieval task-related parties: MasterChain obtains the relevant information of the nearby energy storage device DataHolder_Req through the requested task, and then sends the obtained ID_DH to RetrievalChain for task related party retrieval and make the distribution of CreditCoin. Finally, RetriavalChain sends the retrieved Workers to ArgChain for joint modeling.

6. Model training: ArgChain obtains Y Workers participating in joint modeling from RetrievalChain. Each Worker uses its local dataset and initial model GM_Req for local model training. After the local model training is over, ArgChain’s smart contract algorithm will verify the local model parameters, and then upload the W(W ≤ Y) local model parameters that have passed the verification to the ArgChain. At the same time, the CreditCoin owned by each worker will also be adjusted according to the training quality of its local model.

7. Consensus process: We select Z(Z = μY) Workers with the highest accuracy from W honest workers to form Committee Members. At the same time, we select the Worker with the highest accuracy as the Leader of the committee for local model parameter aggregation, and send the aggregation results to the committee members for consensus. If the consensus is passed, the Leader of the committee will release the aggregation model GM_Req and upload it to AgrChain, which can facilitate the Workers participating in the joint modeling process to download and update their local models.

8. Complete the requested task:After several iterations of training, the joint modeling model ${\mathrm{GM}}_{Req}^{final}$ is finally established. According to the proportion of CreditCoin held by each Worker, the system distributes the coin paid by TaskRequester as reward to Workers participating in joint modeling, which can encourage DataHolder to actively participate in joint modeling of requested task next time. Finally, the system will upload and store the joint modeling model ${\mathrm{GM}}_{Req}^{final}$ to MasterChain, and return the result $Req\left(GM\right)$ to the TaskRequester.

SFecChain aggregation strategy

For a DataHolder, it is difficult to guarantee the training quality of the local model due to its limited resources, and to effectively protect the privacy of users by sharing the original data information of all parties for centralized training. As a result, the aggregation strategy of SFecChain not only expands the amount of data required but also protects data privacy of users by integrating multiparty DataHolders’ local model parameters for joint model training without the original data being local.

In the local model parameter aggregation stage, dishonest Workers may upload incorrect local model parameters, and it is difficult to guarantee the reliability of the Leader in committee responsible for local model parameter aggregation. Therefore, it is difficult to establish an accurate and efficient joint model. Existing consensus protocols, such as PoW, etc. miner requires huge computational overhead to solve cumbersome data problems, and its long consensus process seriously affects the efficiency of system modeling, so it is not suitable for scenarios with frequent transactions. To solve these problems, inspired by Tang, Zhang & Hu (2020), we proposed a credit-based dynamic weight consensus protocol combined with deep learning. The system can effectively identify dishonest Workers participating in each round of joint modeling, and can also use the historical credit of the Workers participating in joint modeling and the accuracy of each round of local model training, and combine with the way of dynamically selecting committees for consensus. Eventually a high-quality joint model will be obtained.

Dynamic weight consensus protocol based on credit

After the local model parameters of Y Workers participating in the joint modeling are verified by the smart contract of ArgChain. Package the verified local model parameters $\hat{Y}\left(\hat{Y}\le Y\right)$, and then upload them to ArgChain in the form of transactions. The process for training work based consensus is illustrated in Fig. 6. The local model parameters in Y in each round will be aggregated by the miners. A conventional idea is that the Worker with the highest accuracy of local model training in each round has high credibility and can be used to aggregate local model parameters. This is considered a greedy strategy. The training accuracy of local model is not necessarily related to whether it is honest or not, and the reliability of the aggregation process cannot be guaranteed. In order to ensure the accuracy of local model parameter aggregation, we propose a credit-based dynamic weight consensus protocol.

We comprehensively consider the historical credit of the Y Workers participating in the joint modeling and the training accuracy of each round of local model, and then we calculate the new credit value of the Y Workers in the new round. The Leader in committee and Z Committee Members are elected through the new credit value for the aggregation of local model parameters and the consensus of the aggregation results. Algorithm 2 illustrates the overall process of credit-based dynamic weight parameter aggregation.

Evaluation setup

We used 20 Newsgroups and AG News to simulate the adaptability and high efficiency of SFedChain, which are international standard datasets that are often used to evaluate text-related machine learning algorithms. The 20 newsgroup dataset is a collection newsgroup documents. This dataset collected about 20,000 newsgroup documents, which were evenly divided into 20 newsgroup collections with different topics. It has become a popular data set for experiments in text applications of machine learning techniques. The AG news is a collection of more than one million news articles. News articles were gathered from more than 2,000 news sources by ComeToMyHead in more than one year of activity. The dataset includes 120,000 training samples and 7,600 test samples. Each sample was a short text with four types of labels. We used these two datasets to simulate the text data generated by the equipment operation and monitoring of each device.

We simulated different numbers of energy storage devices, which have their own local dataset and can be independently modeled. We used the selected dataset to split the data entries, and regroup according to the number of groups set in each experiment, to simulate DataHolders in SFedChain. We used text topic classification analysis to simulate the requested task of the TaskRequester, and implemented our improved attention mechanism on text data to perform the joint modeling process of the SFedChain scheme in the process of distributed multi-party data sharing.

We perform a lot of simulations on Linux ubuntu 4.15.0-45-generic, and the hardware conguration is as follows: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30 GHz, 251G, 10TB hard drive, interpreter Python 3.8.10, and pytorch 1.7.0, We analyzed and evaluated the performance of the SFedChain scheme, and gave the following experimental results.

Numerical results

We use 20 Newsgroup and AG News benchmark datasets to evaluate the accuracy of our proposed model. In order to ensure the accuracy of the experimental results, we conducted 10 experiments and took the average of the results. The performance comparison between our proposed model and the benchmark method text graph convolutional networks (Yao, Mao & Luo, 2019) on various datasets is shown in Fig. 7. From Fig. 7A, we can see that compared to the benchmark method, most of our test groups have obtained a higher accuracy, which shows that our proposed SFedChain has a high diagnostic ability. At the same time, we can see that the more data that each DataHolder has, the higher the accuracy of the joint model built together. This is because that the accuracy of the model has a certain relationship with the number of datasets and computing resources owned by the DataHolder in the actual environment. Figure 7B shows the accuracy results with various number of data providers. As data providers increase, the accuracy curve of the model first grows and eventually stabilizes. This means that the lack of data volume affects the accuracy of the model to a certain extent. Eventually, as the data volume saturates, the model reaches the limit of its diagnostic ability. Therefore, we determine the number of Workers according to the minimum and maximum payment amount of the request task to adapt to the model’s diagnostic ability.

However, the time to build a model is also a key factor to measure the performance of the model. Therefore, we evaluated the time for each DataHolder to build the local model and the joint model, and compared it with the benchmark method text graph convolutional networks model. Figure 8A shows that the running time of our proposed mechanism in different subdatasets. The results show that compared with the benchmark method, the time spent on establishing the joint model of our proposed scheme is significantly reduced, and it can well meet the waiting time of the TaskRequester. From Fig. 8B, we can see that as the DataHolder increases, its running time can still remain stable. The processing time spent to establish the joint model will not change significantly due to the continuous addition of DataHolder, which shows that the model we proposed has good compatibility. Due to the existence of malicious workers, the performance of the joint model is affected to different degrees. Therefore, we simulate the anti-interference of our model by simulating different proportions of malicious attackers to conduct simulation experiments. We use the AG News dataset as the experimental dataset to simulate a scenario of joint modeling of 50 energy storage nodes, and simulate malicious nodes by modifying the dataset in the nodes to be mismatched label pairs. We set different proportions of malicious attackers: attack strength 10%, attack strength 20%, attack strength 30%, attack strength 40%, attack strength 50%. From Fig. 9, we can see that the presence of a small number of dishonest nodes does not affect the accuracy of our proposed model for joint modeling. The system can dynamically distinguish malicious nodes through the dynamic weight consensus protocol and smart contract mechanism to ensure the quality of the training data set, thereby effectively improving the performance of the system.

Through the above evaluation, we can observe that with the addition of the new data holder, the accuracy of the joint modeling model can be continuously improved without significantly increasing the time spent in the joint modeling process. So our scheme can attract more data holders to join to improve the joint modeling effect of the request task. As the number of data holders participating in joint modeling increases, the system needs to perform more local model aggregation and updates, which causes a slight increase in system overhead. However, with the addition of more data holders, the data scale of joint modeling is further improved, and SFedChain’s secure data sharing mechanism brings a significant increase in the performance of joint modeling models, which effectively improves the quality of service in distributed energy storage networks.