A blockchain architecture-based federated learning node selection method

Abstract

The application discloses a kind of federal learning node selection methods based on blockchain architecture, including the following steps: S1, through sensor network acquisition and pre-process node data, form standard data set;S2, homomorphism encryption is encrypted to data set and is packaged as the data block containing block header and block body;S3, block body data hash calculation, construct merkle tree and write in block header;S4, broadcast block through hash locking mechanism, chain and in side chain synchronous storage copy;S5, based on on-chain record, construct node historical data set, quantitatively evaluate and generate comprehensive evaluation result;S6, according to evaluation result, filter federal learning node, and execute homomorphism encryption model update and aggregation.The application realizes safe and efficient federal learning node screening and model training by sensor acquisition, homomorphism encryption blockchain storage and big data evaluation.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method for selecting federated learning nodes based on a blockchain architecture. Background Technology

[0002] Federated learning, as a distributed machine learning method, can train models using local data from participating nodes while ensuring data privacy. However, existing federated learning node selection methods generally rely on a central server for node scheduling and model parameter aggregation, which poses a single point of control risk and can easily lead to problems such as uneven utilization of node resources, low training efficiency, and delayed model updates. Furthermore, historical node behavior data is difficult to record completely and reliably, resulting in inaccurate evaluation of node contributions, further impacting the performance and training stability of the global model.

[0003] To address data privacy concerns, existing technologies typically employ data encryption or secure multi-party computation to protect data uploaded by nodes. However, these methods are still susceptible to tampering or loss during data transmission and processing, lacking verifiable integrity guarantees. Furthermore, the lack of standardized processing for node-generated local data and state information prevents consistent input during model training, impacting the convergence speed and model accuracy of federated learning.

[0004] In recent years, blockchain technology has demonstrated advantages in data sharing, trusted storage, and immutability. However, existing blockchain applications are mostly concentrated in transaction data or asset management, and an efficient data management mechanism for selecting federated learning nodes has not yet been established. In some attempts, the blockchain merely serves as a distributed ledger to store data uploaded by nodes, without combining it with the node's historical behavior and performance metrics for quantitative evaluation. This results in the node selection process still relying on experience or random strategies, failing to comprehensively measure the node's contribution and reliability. Furthermore, the on-chain storage of data blocks lacks redundant copy management and consistency guarantee mechanisms, making it susceptible to single-chain failures or data unavailability due to node offline issues.

[0005] Therefore, how to provide a method for selecting federated learning nodes based on a blockchain architecture is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose a method for selecting nodes in federated learning based on a blockchain architecture. This invention fully utilizes blockchain technology, homomorphic encryption technology, sensor network data acquisition and big data analysis methods, and describes in detail the complete process of node data acquisition, standardization processing, encrypted encapsulation, blockchain on-chain storage and multi-chain redundancy management, as well as the quantitative evaluation of node computing power, data quality and contribution based on historical behavioral data. It has the advantages of high data security, scientific and reliable node selection, high efficiency of federated learning training and strong traceability.

[0007] A method for selecting federated learning nodes based on a blockchain architecture according to an embodiment of the present invention includes the following steps: S1. Collect local data and operating status data of each node through the sensor network, perform data preprocessing, and record the processed data to form a standard data set; S2. Perform homomorphic encryption on the standard data set, and encapsulate the encrypted data into a data block containing a block header and a block body. The block header records the timestamp and the hash value of the previous block, and the block body stores the encrypted data record. S3. Perform hash calculation on the encrypted data in the block body, construct a Merkle tree structure based on the hash calculation result to generate the root node, and write the root node into the block header to complete the block encapsulation. S4. Broadcast the encapsulated data blocks to the blockchain network through a hash locking mechanism, perform consistency verification and on-chain storage on the data blocks, and synchronously store the corresponding data block copies in the sidechain to form a multi-chain structure. S5. Based on the timestamps, root nodes and encrypted data recorded in the main chain and side chains, construct a set of node historical behavior data. Use big data processing methods to quantitatively evaluate the node data quality, computing power and historical contribution, and generate a comprehensive evaluation result of the node. S6. Based on the comprehensive evaluation results of the nodes, perform federated learning node screening to determine the target node set for participating in model training, and perform model parameter updates and aggregation calculations based on homomorphic encrypted data to realize the federated learning training process under data security constraints.

[0008] Optionally, S1 specifically includes: S11. Deploy multi-source heterogeneous sensor components within each federated learning node. These components periodically acquire local node data and operational status data through a unified data acquisition interface, wherein: Local data is read into vectorized data blocks according to fixed dimensions and includes label fields; The operating status data, including processor utilization, memory usage, network bandwidth usage, and communication latency, are collected according to a preset sampling period. S12. During data acquisition, generate a unique index identifier for each original data record, which is composed of a node identifier code and a timestamp, and write it into the data buffer according to the preset cache queue. S13. Perform batch preprocessing on the data in the data buffer. During each batch processing: Call the imputation methods based on mean imputation and median imputation to perform mean imputation and median imputation operations on data fields with null values ​​according to the field type; Call the sliding window-based three-standard-deviation discrimination method to calculate the data distribution interval and remove data records that exceed the interval threshold; Normalization is performed on the retained data, mapping each dimension of the data to a uniform range according to the minimum and maximum values, and alignment is performed on the data dimensions using a fixed feature template, rearranging all data fields into a feature vector structure of uniform length. S14. After completing the data processing, each data record is packaged into a standard data entry according to the predetermined structure: node identifier code, timestamp, and feature vector, and sorted in ascending order according to the timestamp field. S15. Write the sorted standard data entries into each node of the sensor network. During the writing process, the target node is determined by the consistent hashing algorithm and a multi-replica writing strategy is executed to copy each standard data entry to at least three different nodes to form a redundant storage structure. The consistent hashing algorithm refers to a data distribution method that maps data and nodes to the same hash ring space and searches for the target node in a clockwise direction. S16. For each standard data entry, call the SHA-256 algorithm to generate a fixed-length digest value and write it into the corresponding verification field to form a standard data set.

[0009] Optionally, S13 specifically includes: S131. Each batch of data is loaded into memory according to a fixed batch size, and the data type of each column is determined. For missing value fields, imputation methods of mean imputation and median imputation are applied sequentially, where: Numeric fields are filled by calculating the mean of the non-null values ​​in the current batch; The categorical field is populated by calculating the median category of the field's non-null values; S132. After filling, perform outlier detection on each field, use a sliding window to calculate the mean and standard deviation of multiple consecutive data, and remove outliers that exceed the range of mean plus or minus three times the standard deviation. S133. Maintain the index mapping table during the outlier removal process to ensure the correspondence between the data record order and the original timestamp. The index mapping table refers to the key-value correspondence between the unique index identifier of each standard data entry and the corresponding node address and storage location within the node. The mapping table is formed by the transaction manager automatically recording the index identifier, node identifier code and physical storage offset when data is written to the node. S134. After anomaly removal, perform linear normalization on the values ​​of each dimension to map them to the interval between 0 and 1, and call the fixed feature template to rearrange the fields according to the feature order to form a feature vector structure of uniform length. The fixed feature template refers to a standardized feature vector structure formed by mapping each field in each data record in a uniform arrangement according to a predefined field order and feature dimension.

[0010] Optionally, S15 specifically includes: S151. Perform hash calculation on the unique index identifier of each standard data entry to obtain a hash value, and map the hash value to the consistent hash ring space. Search for the closest node in the clockwise direction as the primary storage node. S152. Select the next two nodes in a clockwise direction as replica storage nodes to implement a three-replica write strategy; S153. During the write process, the transaction manager ensures the atomicity of the write operation and updates the index mapping table on each node. After the write is completed, a write completion notification is sent to the distributed coordination service to ensure that the data is synchronously stored on at least three different nodes, forming a redundant storage structure, including: The transaction manager creates a transaction context for each standard data entry and records the target node identifier, data entry hash value, timestamp, and node index mapping information in the transaction context; The write operation sequentially writes standard data entries into the data buffers of the primary storage node and the two replica nodes. At the same time, each node calls the logger to write the start, success and commit status of the write operation to the log file. The transaction manager initiates a two-phase commit protocol on both the primary storage node and the replica nodes, including: Phase 1: Perform the preparation and commit operation, and return a readiness confirmation at each node; Phase 2: After receiving confirmation from all nodes, execute the commit operation; The data in the data buffer is written to local storage, and the index mapping table is updated to synchronize the correspondence between standard data entries and node locations. After the commit is completed, the transaction manager sends a write completion notification message to the distributed coordination service and broadcasts the completion status to all relevant nodes.

[0011] Optionally, S2 specifically includes: S21. Perform homomorphic encryption on each standard data entry in the standard data set; S22. Serialize the data into a binary data stream according to a fixed field order and feature vector length, and input the serialized binary data into the homomorphic encryption engine; S23. The homomorphic encryption engine uses the Paillier homomorphic encryption algorithm to generate a public key and a private key pair. The public key is used for encryption operations, and the private key is stored in the security key management module. S24. During the encryption process, the encryption function is called to generate ciphertext for each dimension value, and the generated ciphertext and the metadata corresponding to the original field are encapsulated into an encrypted data unit. The metadata includes node identifier, timestamp, and feature vector length; S25. Divide the encrypted data units into batches according to the block size threshold and write them into the block body in sequence. Each record in the block body includes the encrypted value and the corresponding metadata, keeping the order consistent with the original data. S26. Write the timestamp of the current block generation into the block header, and call the SHA-256 algorithm to perform hash calculation on the block body content of the previous block. Fill the hash value obtained into the hash field of the previous block in the block header. At the same time, set the root node placeholder information and the block version number in the block header. S27. Perform batch hash operation again on all encrypted data units in the block body, and fill the result into the digest field in the block header; S28. Mark the homomorphic encryption algorithm type, key version number, and encryption parameters, including public key length and random number generator seed, in the block header to ensure that each encrypted data unit is fully bound to the block header, and complete the encapsulation of encrypted data entries and the generation of data blocks.

[0012] Optionally, S3 specifically includes: S31. Serialize each encrypted data record in the block body into a binary data stream of uniform length according to a fixed field order. Generate a hash value for each binary data stream using the SHA-256 algorithm. Store the hash values ​​into the leaf node array in the original order in the block body and assign a unique index identifier and a parent node placeholder field to each leaf node. S32. Starting from the leaf node array, pair up the parent node hash values ​​in pairs and calculate the hash values ​​of the parent nodes. Concatenate the hash values ​​of two adjacent leaf nodes in order to form a new byte array. Call the SHA-256 algorithm again to generate the parent node hash value. If the total number of leaf nodes is odd, copy the hash value of the last node and concatenate it to calculate, ensuring that the number of parent nodes is an integer. S33. For each layer of parent nodes generated, record the parent node index, left child node index, right child node index and hash value, and use the hash value array of the current layer nodes as the input for the next round of parent node calculation, iterating upwards in sequence until a unique root node hash value is generated; S34. After the root node is generated, write the root node hash value into the corresponding field in the block header. At the same time, record the total number of Merkle tree levels, the number of leaf nodes, the root node calculation timestamp, and the offset address of the data index mapping table used for verification in the block header. S35. Throughout the process, each node calculation uses a contiguous array in memory to store hash values, and releases the temporary buffer after the calculation is completed, while maintaining the node's index mapping table.

[0013] Optionally, S4 specifically includes: S41. Generate a lock hash value for each data block. Perform a double SHA-256 hash calculation using the root node hash value in the block header and the randomly generated lock key to generate a unique lock identifier, and append the lock identifier to the block metadata. The locking identifier is used to uniquely constrain and bind the state of the data block during the broadcasting and writing process. By locking the hash value, the block content, time order and write permission are associated, so that the block is in an immutable confirmed state before completing the consistency verification and on-chain writing, and serves as the basis for state confirmation and synchronization triggering during the main chain and side chain writing process. S42. Through the network communication module, the data block and the lock identifier are packaged into a transmission unit and broadcast requests are sent to each node according to the blockchain network node list. After receiving the data block, each receiving node first checks whether the lock hash value is consistent with the local calculation result. After the verification is passed, the block consistency check is performed, including checking the hash value of the previous block, the timestamp order and the integrity of the Merkle tree root node. S43. After the verification is passed, the node calls the on-chain write function to write the data block to the main chain. At the same time, it calls the replica write interface on the side chain to generate the corresponding data block replica. The data block replica contains the original block body, block header digest and lock identifier. After the write is completed, each replica node updates the index mapping table on the chain and broadcasts the write status to other side chain nodes through consensus message. The on-chain write function refers to the operation interface on the blockchain node that writes verified data blocks into the blockchain ledger and updates the on-chain index mapping. S44. After the main chain and side chain are written, the network node will return a confirmation message to the broadcast initiating node. The broadcast initiating node will determine whether the on-chain process was successful, thus forming a multi-chain structure in the blockchain network in which the main chain and side chain are synchronized.

[0014] Optionally, S5 specifically includes: S51. Read the block header information and encrypted data record of each block sequentially from the main chain and side chain, extract the timestamp, Merkle tree root node and encrypted data entry, and group them according to the node identifier code to form the historical block sequence of each node. S52. Input each encrypted data entry into the homomorphic encryption engine, count the data submission frequency, data validity hash verification pass rate and data integrity index of the node in each block, and call the performance monitoring interface to read the processor utilization, memory usage, network bandwidth usage and average latency of the node in the block generation, verification and transmission process, and generate a multi-dimensional feature vector after standardizing all the indicators. S53. Import the multi-dimensional feature vectors of each node into the big data analysis platform. Using a combination of batch processing and streaming processing, calculate the node data quality score, computing power score, and historical contribution score sequentially, where: Data quality scoring is based on encrypted data integrity and verification pass rate; The computing power score is based on a weighted average of processor, memory, and network utilization. Historical contribution scores are based on the number of blocks a node has committed and the number of times it has participated in verification. S54. By weighting and summarizing the three types of scores, a comprehensive evaluation result for each node is generated.

[0015] The beneficial effects of this invention are: First, by deploying multi-source heterogeneous sensor components within federated learning nodes and standardizing and homomorphically encrypting the collected local data and operational status data, this invention achieves secure, complete, and unified management of node data, effectively ensuring data privacy and the immutability of on-chain data.

[0016] Secondly, by encapsulating encrypted data into blocks and utilizing hash locking mechanisms, Merkle tree root nodes, and multi-chain redundant storage of the main chain and side chains, this invention achieves consistency verification, verifiable on-chain recording, and redundant backup of data in the blockchain network. It solves the problems of data loss, tampering, or unavailability that may occur during the transmission and storage of node data, and improves the efficiency of blockchain storage and access.

[0017] Finally, by combining big data analysis methods to quantitatively evaluate the historical behavior data of nodes, this invention can scientifically measure the data quality, computing power, and historical contributions of nodes, thereby generating reliable comprehensive evaluation results. This provides a trustworthy decision-making basis for node selection in federated learning and improves the efficiency, stability, and accuracy of global model training. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a federated learning node selection method based on a blockchain architecture proposed in this invention; Figure 2 This is a flowchart illustrating the data acquisition and preprocessing process of a blockchain-based federated learning node selection method proposed in this invention. Figure 3 This is a flowchart of block encapsulation and hash processing for a federated learning node selection method based on a blockchain architecture proposed in this invention. Figure 4 This is a flowchart illustrating the block broadcasting and node evaluation process of a blockchain-based federated learning node selection method proposed in this invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0020] refer to Figures 1-4 A method for selecting federated learning nodes based on a blockchain architecture includes the following steps: S1. Collect local data and operating status data of each node through the sensor network, perform data preprocessing, and record the processed data to form a standard data set; S2. Perform homomorphic encryption on the standard data set, and encapsulate the encrypted data into a data block containing a block header and a block body. The block header records the timestamp and the hash value of the previous block, and the block body stores the encrypted data record. S3. Perform hash calculation on the encrypted data in the block body, construct a Merkle tree structure based on the hash calculation result to generate the root node, and write the root node into the block header to complete the block encapsulation. S4. Broadcast the encapsulated data blocks to the blockchain network through a hash locking mechanism, perform consistency verification and on-chain storage on the data blocks, and synchronously store the corresponding data block copies in the sidechain to form a multi-chain structure. S5. Based on the timestamps, root nodes and encrypted data recorded in the main chain and side chains, construct a set of node historical behavior data. Use big data processing methods to quantitatively evaluate the node data quality, computing power and historical contribution, and generate a comprehensive evaluation result of the node. S6. Based on the comprehensive evaluation results of the nodes, perform federated learning node screening to determine the target node set for participating in model training, and perform model parameter updates and aggregation calculations based on homomorphic encrypted data to realize the federated learning training process under data security constraints.

[0021] In this embodiment, S1 specifically includes: S11. Deploy multi-source heterogeneous sensor components within each federated learning node. These components periodically acquire local node data and operational status data through a unified data acquisition interface, including: Local data is read into vectorized data blocks according to fixed dimensions and includes label fields; The operating status data, including processor utilization, memory usage, network bandwidth usage, and communication latency, are collected according to a preset sampling period. S12. During data acquisition, generate a unique index identifier for each original data record, which is composed of a node identifier code and a timestamp, and write it into the data buffer according to the preset cache queue. S13. Perform batch preprocessing on the data in the data buffer. During each batch processing: Call the imputation methods based on mean imputation and median imputation to perform mean imputation and median imputation operations on data fields with null values ​​according to the field type; Call the sliding window-based three-standard-deviation discrimination method to calculate the data distribution interval and remove data records that exceed the interval threshold; Normalization is performed on the retained data, mapping each dimension of the data to a uniform range according to the minimum and maximum values, and alignment is performed on the data dimensions using a fixed feature template, rearranging all data fields into a feature vector structure of uniform length. S14. After completing the data processing, each data record is packaged into a standard data entry according to the predetermined structure: node identifier code, timestamp, and feature vector, and sorted in ascending order according to the timestamp field. S15. Write the sorted standard data entries into each node of the sensor network. During the writing process, the target node is determined by the consistent hashing algorithm and a multi-replica writing strategy is executed to copy each standard data entry to at least three different nodes to form a redundant storage structure. Consistent hashing refers to a data distribution method that maps data and nodes to the same hash ring space and searches for the target node in a clockwise direction. S16. For each standard data entry, call the SHA-256 algorithm to generate a fixed-length digest value and write it into the corresponding verification field to form a standard data set.

[0022] In this embodiment, S13 specifically includes: S131. Each batch of data is loaded into memory according to a fixed batch size, and the data type of each column is determined. For missing value fields, imputation methods of mean imputation and median imputation are applied sequentially, where: Numeric fields are filled by calculating the mean of the non-null values ​​in the current batch; The categorical field is populated by calculating the median category of the field's non-null values; S132. After filling, perform outlier detection on each field, use a sliding window to calculate the mean and standard deviation of multiple consecutive data, and remove outliers that exceed the range of mean plus or minus three times the standard deviation. S133. Maintain the index mapping table during the outlier removal process to ensure the correspondence between the data record order and the original timestamp. An index mapping table is a key-value pair that establishes a key-value relationship between the unique index identifier of each standard data entry and the corresponding node address and storage location within the node. This mapping table is formed by the transaction manager automatically recording the index identifier, node identifier code, and physical storage offset when data is written to the node. S134. After anomaly removal, perform linear normalization on the values ​​of each dimension to map them to the interval between 0 and 1, and call the fixed feature template to rearrange the fields according to the feature order to form a feature vector structure of uniform length. Fixed feature templates refer to standardized feature vector structures formed by mapping the fields in each data record in a uniform arrangement according to a predefined field order and feature dimensions.

[0023] In this embodiment, S15 specifically includes: S151. Perform hash calculation on the unique index identifier of each standard data entry to obtain a hash value, and map the hash value to the consistent hash ring space. Search for the closest node in the clockwise direction as the primary storage node. S152. Select the next two nodes in a clockwise direction as replica storage nodes to implement a three-replica write strategy; S153. During the write process, the transaction manager ensures the atomicity of the write operation and updates the index mapping table on each node. After the write is completed, a write completion notification is sent to the distributed coordination service to ensure that the data is synchronously stored on at least three different nodes, forming a redundant storage structure, including: The transaction manager creates a transaction context for each standard data entry and records the target node identifier, data entry hash value, timestamp, and node index mapping information in the transaction context; The write operation sequentially writes standard data entries into the data buffers of the primary storage node and the two replica nodes. At the same time, each node calls the logger to write the start, success and commit status of the write operation to the log file. The transaction manager initiates a two-phase commit protocol on both the primary storage node and the replica nodes, including: Phase 1: Perform the preparation and commit operation, and return a readiness confirmation at each node; Phase 2: After receiving confirmation from all nodes, execute the commit operation; The data in the data buffer is written to local storage, and the index mapping table is updated to synchronize the correspondence between standard data entries and node locations. After the commit is completed, the transaction manager sends a write completion notification message to the distributed coordination service and broadcasts the completion status to all relevant nodes.

[0024] In this embodiment, S2 specifically includes: S21. Perform homomorphic encryption on each standard data entry in the standard data set; S22. Serialize the data into a binary data stream according to a fixed field order and feature vector length, and input the serialized binary data into the homomorphic encryption engine; S23. The homomorphic encryption engine uses the Paillier homomorphic encryption algorithm to generate a public key and a private key pair. The public key is used for encryption operations, and the private key is stored in the security key management module. S24. During the encryption process, the encryption function is called to generate ciphertext for each dimension value, and the generated ciphertext and the metadata corresponding to the original field are encapsulated into an encrypted data unit. Metadata includes node identifier, timestamp, and feature vector length; S25. Divide the encrypted data units into batches according to the block size threshold and write them into the block body in sequence. Each record in the block body includes the encrypted value and the corresponding metadata, keeping the order consistent with the original data. S26. Write the timestamp of the current block generation into the block header, and call the SHA-256 algorithm to perform hash calculation on the block body content of the previous block. Fill the hash value obtained into the hash field of the previous block in the block header. At the same time, set the root node placeholder information and the block version number in the block header. S27. Perform batch hash operation again on all encrypted data units in the block body, and fill the result into the digest field in the block header; S28. Mark the homomorphic encryption algorithm type, key version number, and encryption parameters, including public key length and random number generator seed, in the block header to ensure that each encrypted data unit is fully bound to the block header, and complete the encapsulation of encrypted data entries and the generation of data blocks.

[0025] In this embodiment, S3 specifically includes: S31. Serialize each encrypted data record in the block body into a binary data stream of uniform length according to a fixed field order. Generate a hash value for each binary data stream using the SHA-256 algorithm. Store the hash values ​​into the leaf node array in the original order in the block body and assign a unique index identifier and a parent node placeholder field to each leaf node. S32. Starting from the leaf node array, pair up the leaf nodes and calculate the hash value of each pair. Concatenate the hash values ​​of adjacent leaf nodes in order to form a new byte array. Call the SHA-256 algorithm again to generate the hash value of the parent node. If the total number of leaf nodes is odd, copy the hash value of the last node and concatenate it for calculation. Ensure that the number of parent nodes is an integer, including: Allocate a contiguous array of hash values ​​in memory for the parent node layer, and initialize an index mapping table to record the correspondence between parent nodes and child nodes; Following the order of the leaf node array, every two adjacent hash values ​​are extracted and concatenated into a fixed-length byte array. The SHA-256 algorithm is then used to generate the parent node hash value. At the same time, the index of the parent node, the index of the left child node, and the index of the right child node are recorded in the index mapping table. For an odd number of leaf nodes, copy the hash value of the last node, concatenate it with the hash value of the current node to generate the hash value of the parent node. S33. For each layer of parent nodes generated, record the parent node index, left child node index, right child node index and hash value, and use the hash value array of the current layer nodes as the input for the next round of parent node calculation, iterating upwards in sequence until a unique root node hash value is generated; S34. After the root node is generated, write the root node hash value into the corresponding field in the block header. At the same time, record the total number of Merkle tree levels, the number of leaf nodes, the root node calculation timestamp, and the offset address of the data index mapping table used for verification in the block header. S35. Throughout the process, each node calculation uses a contiguous array in memory to store hash values, and releases the temporary buffer after the calculation is completed, while maintaining the node's index mapping table.

[0026] In this embodiment, S4 specifically includes: S41. Generate a lock hash value for each data block. Perform a double SHA-256 hash calculation using the root node hash value in the block header and the randomly generated lock key to generate a unique lock identifier, and append the lock identifier to the block metadata. The locking identifier is used to uniquely constrain and bind the state of data blocks during the broadcasting and writing process. By locking the hash value, the block content, time order and write permission are associated, so that the block is in an immutable confirmed state before the consistency verification and on-chain writing are completed, and it serves as the basis for state confirmation and synchronization triggering during the main chain and side chain writing process. S42. Through the network communication module, the data block and the lock identifier are packaged into a transmission unit and broadcast requests are sent to each node according to the blockchain network node list. After receiving the data block, each receiving node first checks whether the lock hash value is consistent with the local calculation result. After the verification is passed, the block consistency check is performed, including checking the hash value of the previous block, the timestamp order and the integrity of the Merkle tree root node. S43. After successful verification, the node calls the on-chain write function to write the data block to the main chain. Simultaneously, it calls the replica write interface on the sidechain to generate a corresponding data block replica. The data block replica contains the original block body, block header digest, and lock flag. Each replica node updates the on-chain index mapping table after writing and broadcasts the write status to other sidechain nodes via consensus messages, including: The block body content and block header digest are written to the blockchain ledger field by field through the on-chain write function, and the correspondence between the block hash value and the storage location is registered in the index mapping table. At the same time, a two-phase commit protocol is started to ensure the atomicity of the write operation. On-chain write functions refer to the operation interface on a blockchain node that writes verified data blocks into the blockchain ledger and updates the on-chain index mapping. After writing to the main chain, the sidechain write interface receives the original block body, block header digest, and lock flag. It allocates node storage space for the replica block according to the sidechain storage rules, copies the field order and hash relationship of the main chain block, updates the index mapping table of the sidechain, and records the storage location and timestamp of the replica block in the sidechain node. After the main chain and side chain writes are completed, the node encapsulates the write state into a consensus message and broadcasts it to other side chain nodes through the peer-to-peer network; S44. After the main chain and side chain are written, the network node will return a confirmation message to the broadcast initiating node. The broadcast initiating node will determine whether the on-chain process was successful, thus forming a multi-chain structure in the blockchain network in which the main chain and side chain are synchronized.

[0027] In this embodiment, S5 specifically includes: S51. Read the block header information and encrypted data record of each block sequentially from the main chain and side chain, extract the timestamp, Merkle tree root node and encrypted data entry, and group them according to the node identifier code to form the historical block sequence of each node. S52. Input each encrypted data entry into the homomorphic encryption engine, count the data submission frequency, data validity hash verification pass rate and data integrity index of the node in each block, and call the performance monitoring interface to read the processor utilization, memory usage, network bandwidth usage and average latency of the node in the block generation, verification and transmission process, and generate a multi-dimensional feature vector after standardizing all the indicators. S53. Import the multi-dimensional feature vectors of each node into the big data analysis platform. Using a combination of batch processing and streaming processing, calculate the node data quality score, computing power score, and historical contribution score sequentially, where: Data quality scoring is based on encrypted data integrity and verification pass rate, and is calculated as follows: ; in, Indicates the first Data quality score for each node Indicates the first The node at the th Data integrity metrics in each block Indicates the first The node at the th The pass rate of verification in each block This indicates the number of blocks within the statistical period. and The data quality weight coefficient is and satisfies ; The computing power score is based on a weighted average of processor, memory, and network utilization, calculated as follows: ; in, Indicates the first Individual node computing power score , , They represent the first Normalized averages of node processor utilization, memory utilization, and network bandwidth utilization. This represents the normalized value of the average communication delay. , , , The corresponding weight coefficients and satisfying ; Historical contribution scores are based on the number of blocks a node has committed and the number of times it has participated in verification. The calculation method is as follows: ; in, Indicates the first Each node's historical contribution score This indicates the number of block commits that the node participated in. Indicates the number of times the block verification has been participated in. `max(V)` and `max(V)` represent the maximum number of submissions and the maximum number of validations within the statistical period, respectively. and The weighting coefficients are satisfied. ; S54, Weighted aggregation , and Three types of scoring are used to generate a comprehensive evaluation result for each node.

[0028] In this embodiment, S6 specifically includes: S61. Based on the comprehensive evaluation results of the nodes, perform federated learning node screening to determine the target node set for participating in model training; S62. The Paillier homomorphic encryption algorithm is used to encrypt the local model parameters of each node, and a weighted summation operation is performed on the encrypted parameters in conjunction with a secure aggregation protocol based on secure multi-party computation, wherein: After each node completes model training locally, it encrypts and uploads the parameters. The aggregation node completes the homomorphic accumulation calculation of global model parameters without decryption; After the threshold condition is met, the global model update result is obtained by decryption using the private key; S63. Complete the security parameter update and aggregation calculation during the federated learning training process.

[0029] Example 1: To verify the feasibility of this invention in practice, it is applied to a vehicle-to-everything (V2X) edge collaborative computing scenario. In this scenario, multiple vehicle-mounted terminals and roadside edge nodes jointly participate in a federated learning task to jointly model vehicle operating status, road congestion risk, and driving behavior. Each vehicle-mounted node is equipped with a multi-source sensor module to collect vehicle operating data in real time, including vehicle speed, acceleration, engine speed, braking frequency, throttle opening, and network latency and packet loss rate generated by the vehicle communication module. Simultaneously, the edge nodes continuously record their own computing resource usage, such as CPU utilization, memory utilization, and task scheduling latency. In actual operation, due to the large number of V2X nodes and the continuous high-frequency generation of data, traditional centralized training methods are prone to data leakage risks. Furthermore, the inconsistent quality of nodes leads to unstable model training. Therefore, a processing method is needed that can achieve trusted node selection and stable model updates while ensuring data privacy.

[0030] In this scenario, each vehicle, acting as a federated learning node, first collects raw operational data through the onboard sensor network. For example, a vehicle's speed sequence within a 10-second sampling window might be [32, 35, 38, 36, 40] km / h, its acceleration sequence might be [-0.2, 0.1, 0.3, 0.0, -0.1] m / s², and its engine speed range might be [1200, 1800] rpm. Network latency fluctuates between 28ms and 45ms. After this raw data enters the local preprocessing module, it undergoes null value imputation and outlier removal. For instance, if a speed sensor is lost at a certain moment, the system uses the average of the nearest time window (35.2 km / h) to fill in the missing data, and uses a three-standard-deviation method to remove abnormal rapid acceleration data points. The processed data is then uniformly mapped to standard feature vectors. For example, each time slice is ultimately encoded into a fixed-dimensional vector, generating data records with timestamps and vehicle IDs.

[0031] This standard data is then input into a homomorphic encryption module for encryption processing. For example, the Paillier homomorphic encryption algorithm is used to encrypt the feature vectors, ensuring that the encrypted data can still be added and aggregated but cannot be directly deconstructed, thus guaranteeing that in-vehicle privacy data will not be leaked during transmission. The encrypted data is then encapsulated into a block structure, where the block header records a timestamp, the hash of the previous block, and a Merkle root node, and the block body stores the encrypted vehicle data records. In this process, each block contains, for example, approximately 5,000 vehicle data records, and the length of a single encrypted record is expanded from approximately 40 bytes to approximately 256 bytes.

[0032] After a block is generated, the system hashes the block data and constructs a Merkle tree structure. For example, it hashes 5000 records layer by layer, pairwise, to generate a tree structure, ultimately obtaining a unique root node hash value. This value is written into the block header to ensure data integrity. The block is then broadcast to the vehicle-to-everything (V2X) edge blockchain network via a hash locking mechanism. This network includes roadside unit nodes and edge computing nodes. Each node, upon receiving the block, first verifies the consistency of the locked hash value, then checks if the timestamp order matches the hash of the previous block, thus completing the consistency check. Once the check passes, the block is written to the main chain, and a replica is simultaneously generated and stored in the side chain. For example, the main chain records the complete block digest, while the side chain stores an encrypted data mirror for subsequent model training.

[0033] During continuous operation, the system constructs vehicle node behavior data based on historical records in the main chain and side chains. For example, it records that a vehicle submitted data 96 times and participated in valid verification 88 times within 100 block cycles. It also records its average communication latency of 38ms, average CPU utilization of 62%, and average memory utilization of 58%. This data is input into the big data analysis module for unified modeling. After normalization, node feature vectors are generated, and a comprehensive node score is further calculated to select reliable training nodes.

[0034] In a real-world testing environment, compared to traditional random node selection methods, the method of this invention demonstrates significant optimization under the same data scale (approximately 200 vehicles, 50,000 data points per training round). As shown in Table 1, regarding model convergence, the traditional method requires approximately 42 training rounds to reach stability, while this method only requires 28 rounds; regarding model accuracy, the traditional method achieves a final accuracy of 89.3%, while this method reaches 94.8%; regarding communication overhead, due to the adoption of sidechain replicas and hash locking mechanisms, duplicate data requests are reduced by approximately 37%; and regarding the impact of abnormal nodes, the model fluctuation caused by malicious nodes participating in training is reduced from ±6.2% to ±2.1%.

[0035] Table 1. Statistics on the Operation and Model Performance of Federated Learning Nodes in the Internet of Vehicles The actual results show that by performing data preprocessing, homomorphic encryption encapsulation, blockchain storage, and big data scoring and screening based on historical behavior on vehicle network nodes, the stability and convergence efficiency of federated learning training can be effectively improved. At the same time, the interference of low-quality nodes on the global model can be reduced, making the overall training process more reliable and controllable.

[0036] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for selecting federated learning nodes based on a blockchain architecture, characterized in that, Includes the following steps: S1. Collect local data and operating status data of each node through the sensor network, perform data preprocessing, and record the processed data to form a standard data set; S2. Perform homomorphic encryption on the standard data set, and encapsulate the encrypted data into a data block containing a block header and a block body. The block header records the timestamp and the hash value of the previous block, and the block body stores the encrypted data record. S3. Perform hash calculation on the encrypted data in the block body, construct a Merkle tree structure based on the hash calculation result to generate the root node, and write the root node into the block header to complete the block encapsulation. S4. Broadcast the encapsulated data blocks to the blockchain network through a hash locking mechanism, perform consistency verification and on-chain storage on the data blocks, and synchronously store the corresponding data block copies in the sidechain to form a multi-chain structure. S5. Based on the timestamps, root nodes and encrypted data recorded in the main chain and side chains, construct a set of node historical behavior data. Use big data processing methods to quantitatively evaluate the node data quality, computing power and historical contribution, and generate a comprehensive evaluation result of the node. S6. Based on the comprehensive evaluation results of the nodes, perform federated learning node screening to determine the target node set for participating in model training, and perform model parameter updates and aggregation calculations based on homomorphic encrypted data to realize the federated learning training process under data security constraints.

2. The method for selecting federated learning nodes based on a blockchain architecture according to claim 1, characterized in that, S1 specifically includes: S11. Deploy multi-source heterogeneous sensor components within each federated learning node. These components periodically acquire local node data and operational status data through a unified data acquisition interface, wherein: Local data is read into vectorized data blocks according to fixed dimensions and includes label fields; The operating status data, including processor utilization, memory usage, network bandwidth usage, and communication latency, are collected according to a preset sampling period. S12. During data acquisition, generate a unique index identifier for each original data record, which is composed of a node identifier code and a timestamp, and write it into the data buffer according to the preset cache queue. S13. Perform batch preprocessing on the data in the data buffer. During each batch processing: Call the imputation methods based on mean imputation and median imputation to perform mean imputation and median imputation operations on data fields with null values ​​according to the field type; Call the sliding window-based three-standard-deviation discrimination method to calculate the data distribution interval and remove data records that exceed the interval threshold; Normalization is performed on the retained data, mapping each dimension of the data to a unified range according to the minimum and maximum values, and alignment is performed on the data dimensions using a fixed feature template, rearranging all data fields into a feature vector structure of uniform length. S14. After completing the data processing, each data record is packaged into a standard data entry according to the predetermined structure: node identifier code, timestamp, and feature vector, and sorted in ascending order according to the timestamp field. S15. Write the sorted standard data entries into each node of the sensor network. During the writing process, the target node is determined by the consistent hashing algorithm and a multi-replica writing strategy is executed to copy each standard data entry to at least three different nodes to form a redundant storage structure. The consistent hashing algorithm refers to a data distribution method that maps data and nodes to the same hash ring space and searches for the target node in a clockwise direction. S16. For each standard data entry, call the SHA-256 algorithm to generate a fixed-length digest value and write it into the corresponding verification field to form a standard data set.

3. The method for selecting federated learning nodes based on a blockchain architecture according to claim 2, characterized in that, S13 specifically includes: S131. Each batch of data is loaded into memory according to a fixed batch size, and the data type of each column is determined. For missing value fields, imputation methods of mean imputation and median imputation are applied sequentially, where: Numeric fields are filled by calculating the mean of the non-null values ​​in the current batch; The categorical field is populated by calculating the median category of the field's non-null values; S132. After filling, perform outlier detection on each field, use a sliding window to calculate the mean and standard deviation of multiple consecutive data, and remove outliers that exceed the range of mean plus or minus three times the standard deviation. S133. Maintain the index mapping table during the outlier removal process to ensure the correspondence between the data record order and the original timestamp. The index mapping table refers to the key-value correspondence between the unique index identifier of each standard data entry and the corresponding node address and storage location within the node. The mapping table is formed by the transaction manager automatically recording the index identifier, node identifier code and physical storage offset when data is written to the node. S134. After anomaly removal, perform linear normalization on the values ​​of each dimension to map them to the interval between 0 and 1, and call the fixed feature template to rearrange the fields according to the feature order to form a feature vector structure of uniform length. The fixed feature template refers to a standardized feature vector structure formed by mapping each field in each data record in a uniform arrangement according to a predefined field order and feature dimension.

4. The method for selecting federated learning nodes based on a blockchain architecture according to claim 2, characterized in that, S15 specifically includes: S151. Perform hash calculation on the unique index identifier of each standard data entry to obtain a hash value, and map the hash value to the consistent hash ring space. Search for the closest node in the clockwise direction as the primary storage node. S152. Select the next two nodes in a clockwise direction as replica storage nodes to implement a three-replica write strategy; S153. During the write process, the transaction manager ensures the atomicity of the write operation and updates the index mapping table on each node. After the write is completed, a write completion notification is sent to the distributed coordination service to ensure that the data is synchronously stored on at least three different nodes, forming a redundant storage structure, including: The transaction manager creates a transaction context for each standard data entry and records the target node identifier, data entry hash value, timestamp, and node index mapping information in the transaction context; The write operation sequentially writes standard data entries into the data buffers of the primary storage node and the two replica nodes. At the same time, each node calls the logger to write the start, success and commit status of the write operation to the log file. The transaction manager initiates a two-phase commit protocol on both the primary storage node and the replica nodes, including: Phase 1: Perform the preparation and commit operation, and return a readiness confirmation at each node; Phase 2: After receiving confirmation from all nodes, execute the commit operation; The data in the data buffer is written to local storage, and the index mapping table is updated to synchronize the correspondence between standard data entries and node locations. After the commit is completed, the transaction manager sends a write completion notification message to the distributed coordination service and broadcasts the completion status to all relevant nodes.

5. The method for selecting federated learning nodes based on a blockchain architecture according to claim 1, characterized in that, S2 specifically includes: S21. Perform homomorphic encryption on each standard data entry in the standard data set; S22. Serialize the data into a binary data stream according to a fixed field order and feature vector length, and input the serialized binary data into the homomorphic encryption engine; S23. The homomorphic encryption engine uses the Paillier homomorphic encryption algorithm to generate a public key and a private key pair. The public key is used for encryption operations, and the private key is stored in the security key management module. S24. During the encryption process, the encryption function is called to generate ciphertext for each dimension value, and the generated ciphertext and the metadata corresponding to the original field are encapsulated into an encrypted data unit. The metadata includes node identifier, timestamp, and feature vector length; S25. Divide the encrypted data units into batches according to the block size threshold and write them into the block body in sequence. Each record in the block body includes the encrypted value and the corresponding metadata, keeping the order consistent with the original data. S26. Write the timestamp of the current block generation into the block header, and call the SHA-256 algorithm to perform hash calculation on the block body content of the previous block. Fill the hash value obtained into the hash field of the previous block in the block header. At the same time, set the root node placeholder information and the block version number in the block header. S27. Perform batch hash operation again on all encrypted data units in the block body, and fill the result into the digest field in the block header; S28. Mark the homomorphic encryption algorithm type, key version number, and encryption parameters, including public key length and random number generator seed, in the block header to ensure that each encrypted data unit is fully bound to the block header, and complete the encapsulation of encrypted data entries and the generation of data blocks.

6. The method for selecting federated learning nodes based on a blockchain architecture according to claim 1, characterized in that, S3 specifically includes: S31. Serialize each encrypted data record in the block body into a binary data stream of uniform length according to a fixed field order. Generate a hash value for each binary data stream using the SHA-256 algorithm. Store the hash values ​​into the leaf node array in the original order in the block body and assign a unique index identifier and a parent node placeholder field to each leaf node. S32. Starting from the leaf node array, pair up the parent node hash values ​​in pairs and calculate the hash values ​​of the parent nodes. Concatenate the hash values ​​of two adjacent leaf nodes in order to form a new byte array. Call the SHA-256 algorithm again to generate the parent node hash value. If the total number of leaf nodes is odd, copy the hash value of the last node and concatenate it to calculate, ensuring that the number of parent nodes is an integer. S33. For each layer of parent nodes generated, record the parent node index, left child node index, right child node index and hash value, and use the hash value array of the current layer nodes as the input for the next round of parent node calculation, iterating upwards in sequence until a unique root node hash value is generated; S34. After the root node is generated, write the root node hash value into the corresponding field in the block header. At the same time, record the total number of Merkle tree levels, the number of leaf nodes, the root node calculation timestamp, and the offset address of the data index mapping table used for verification in the block header. S35. Throughout the process, each node calculation uses a contiguous array in memory to store hash values, and releases the temporary buffer after the calculation is completed, while maintaining the node's index mapping table.

7. The method for selecting federated learning nodes based on a blockchain architecture according to claim 1, characterized in that, S4 specifically includes: S41. Generate a lock hash value for each data block. Perform a double SHA-256 hash calculation using the root node hash value in the block header and the randomly generated lock key to generate a unique lock identifier, and append the lock identifier to the block metadata. S42. Through the network communication module, the data block and the lock identifier are packaged into a transmission unit and broadcast requests are sent to each node according to the blockchain network node list. After receiving the data block, each receiving node first checks whether the lock hash value is consistent with the local calculation result. After the verification is passed, the block consistency check is performed, including checking the hash value of the previous block, the timestamp order and the integrity of the Merkle tree root node. S43. After the verification is passed, the node calls the on-chain write function to write the data block to the main chain. At the same time, it calls the replica write interface on the side chain to generate the corresponding data block replica. The data block replica contains the original block body, block header digest and lock identifier. After the write is completed, each replica node updates the index mapping table on the chain and broadcasts the write status to other side chain nodes through consensus message. The on-chain write function refers to the operation interface on the blockchain node that writes verified data blocks into the blockchain ledger and updates the on-chain index mapping. S44. After the main chain and side chain are written, the network node will return a confirmation message to the broadcast initiating node. The broadcast initiating node will determine whether the on-chain process was successful, thus forming a multi-chain structure in the blockchain network in which the main chain and side chain are synchronized.

8. The method for selecting federated learning nodes based on a blockchain architecture according to claim 1, characterized in that, S5 specifically includes: S51. Read the block header information and encrypted data record of each block sequentially from the main chain and side chain, extract the timestamp, Merkle tree root node and encrypted data entry, and group them according to the node identifier code to form the historical block sequence of each node. S52. Input each encrypted data entry into the homomorphic encryption engine, count the data submission frequency, data validity hash verification pass rate and data integrity index of the node in each block, and call the performance monitoring interface to read the processor utilization, memory usage, network bandwidth usage and average latency of the node in the block generation, verification and transmission process, and generate a multi-dimensional feature vector after standardizing all the indicators. S53. Import the multi-dimensional feature vectors of each node into the big data analysis platform. Using a combination of batch processing and streaming processing, calculate the node data quality score, computing power score, and historical contribution score sequentially, where: Data quality scoring is based on encrypted data integrity and verification pass rate; The computing power score is based on a weighted average of processor, memory, and network utilization. Historical contribution scores are based on the number of blocks a node has committed and the number of times it has participated in verification. S54. By weighting and summarizing the three types of scores, a comprehensive evaluation result for each node is generated.

Images