An AI large model-oriented sharded blockchain federated learning method

Abstract

The application discloses a kind of sharding blockchains federated learning methods for AI big model, belong to information security field, the application designs the scalable big model training architecture based on sharding blockchains and federated learning, with the aid of sharding blockchains technology, the scalability of federated learning system is guaranteed from architecture level.Based on the multi-piece collaborative model aggregation scheme SP of four-pipeline two-stage commitment, which includes multi-signature aggregation protocol MASign, pipeline mode intra-chip consensus protocol MulPipe-BFT based on improved BLS multi-signature, and inter-chip transaction processing protocol QuadPipe-Sharding based on four-pipeline mode multi-signature aggregation.The application designs a federated learning endogenous security enhancement technology composed of uniform noise adding technology, phased encryption technology and Bipole double filter, which resists data recovery attacks, free riding attacks and poisoning attacks and other risks faced during federated learning training process.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically relating to a sharded blockchain federated learning method for large AI models. Background Technology

[0002] Federated learning is a distributed machine learning framework with privacy protection and secure encryption technology. It adopts the idea of ​​"the model moves while the data remains still, and the data is usable but not visible" to the decentralized participants. It combines data from multiple parties to collaboratively train machine learning models without disclosing private data to other participants. This solves the contradiction between data silos and data privacy issues and the need for large-scale training data in artificial intelligence, and provides a new solution for training large AI models.

[0003] However, existing federated learning technologies still have many problems.

[0004] Firstly, existing federated learning architectures lack scalability and cannot meet the training needs of large models and large datasets. In a central server architecture or a single committee architecture, all participants send updated parameters of their local models to the central server or committee. When the number of participants is large, this leads to a large amount of communication traffic and network latency, causing communication bottlenecks and performance degradation. In a peer-to-peer network architecture, it is very difficult for participants to establish and maintain peer-to-peer network connections, and the addition of new nodes can also cause connection instability, affecting the scalability of the system.

[0005] Secondly, existing federated learning methods suffer from low parallelism and poor performance, making them unsuitable for training large models involving numerous user devices and data. Each participant needs to communicate with the server, but the number of connections the server can establish and the number of transactions it can process simultaneously is limited, restricting the server's ability to handle tasks concurrently. Since parameter transmission between participants and model aggregation on the server are performed serially, the training time and convergence time of federated learning are relatively long.

[0006] Thirdly, existing federated learning methods suffer from various security risks, including potential attacks such as information leakage attacks, free-riding attacks, and poisoning attacks. Information leakage attacks involve attackers retrieving valid information about the local data of training nodes from the gradients uploaded by those nodes. Free-riding attacks involve lazy participants slightly modifying gradients uploaded by others and uploading them as their own. Poisoning attacks involve adversaries using maliciously constructed data to train the model or maliciously modifying the directly trained local model, thereby adversely affecting the global model.

[0007] Because blockchain technology possesses decentralization, consistency, and immutability, introducing it for federated learning training can effectively address the aforementioned issues. However, traditional blockchain technology still suffers from scalability and performance problems. As the number of consensus nodes in the system increases, each node needs to broadcast messages to a larger number of nodes across the network to reach consensus, significantly degrading system performance and ultimately resulting in poor scalability. Since all nodes must store and process complete transaction data, this greatly impacts system performance for large-scale networks. Furthermore, all transactions are added to the blockchain sequentially, requiring serial processing, which limits the system's processing capacity and throughput. Summary of the Invention

[0008] In view of this, this invention provides a sharded blockchain federated learning method for large AI models, characterized by decentralization, efficiency, and security in the model training process. The main objectives of this invention are as follows: First, addressing the insufficient scalability of existing federated learning architectures, this invention designs a scalable large model training architecture based on sharded blockchain and federated learning. On-chain storage ensures permanent and immutable model storage, Byzantine fault-tolerant consensus guarantees consistency of model training results, and sharding technology ensures system scalability at the architectural level. Second, this invention innovatively designs a multi-shard collaborative model aggregation scheme SP based on a four-stage pipeline two-phase commitment, including a multi-signature aggregation protocol (MASign), a pipelined intra-shard consensus protocol based on improved BLS multi-signature (MulPipe-BFT), and a four-stage pipelined inter-shard transaction processing protocol based on multi-signature aggregation (QuadPipe-Sharding). This solution is based on the Hotstuff pipeline consensus mechanism and the traditional two-phase commitment protocol for cross-shard transactions. It combines a multi-signature aggregation algorithm with mechanisms such as signature member view fixing and transformation to reduce the complexity and data volume of inter-node communication, achieving low-overhead node communication and high-concurrency transaction commitments. Third, this invention designs an intrinsic security enhancement technology for federated learning. Addressing the three security risks inherent in existing federated learning methods—data recovery attacks, free-rider attacks, and poisoning attacks—it designs three corresponding security mechanisms: a uniform noise protection mechanism, a phased encrypted submission mechanism, and a Bipole dual filter, ensuring the security and trustworthiness of the federated learning training process.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A sharded blockchain federated learning method for large AI models includes the following steps:

[0011] S1: Construct a scalable large model training architecture based on sharded blockchain and federated learning. On-chain storage enables permanent storage and immutability of the model, Byzantine fault-tolerant consensus ensures the consistency of model training results, and sharding technology guarantees the scalability of the federated learning system from the architectural level.

[0012] S2: Construct a multi-shard collaborative model aggregation scheme SP based on a four-stage pipeline two-phase commitment, including the multi-signature aggregation protocol MASign, the pipeline mode intra-shard consensus protocol MulPipe-BFT based on improved BLS multi-signature, and the four-stage pipeline mode inter-shard transaction processing protocol QuadPipe-Sharding based on multi-signature aggregation.

[0013] S3: Construct an intrinsic security enhancement technology for federated learning, consisting of uniform noise addition, phased encryption, and Bipole dual filters, to resist the risks faced during federated learning training.

[0014] Furthermore, the specific process for federated learning training based on the scalable large model training architecture using sharded blockchain and federated learning, as described in step S1, is as follows:

[0015] S11: System Initialization: Deploy a deposit contract on each shard. Each node in the shard uploads its IP address and public key to the blockchain and pledges a certain amount of tokens to the deposit contract as chips for participating in the committee member election. After receiving the deposit, the smart contract concatenates the node IDs into an array according to the deposit amount. After initialization, the committee election function in the deposit contract is automatically triggered, executing the Deposit Array Generation algorithm and the Committee Selection algorithm to select a committee for the upcoming federated learning task. The committee needs to be reorganized for each round of training.

[0016] S12: The task publisher selects several shards according to the task requirements and publishes the federated learning task on the sharded blockchain in the form of a smart contract; the task publisher describes the task in the smart contract, specifies the initial model used for training, and gives the noise distribution function and the proportion of adversaries; the task publisher injects a certain amount of funds into the smart contract as a reward for participating in this task.

[0017] S13: When the smart contract is deployed, all nodes belonging to the shard execute consensus to decide whether to participate in the tasks stipulated by the smart contract. If they participate, each node calls the contract's node registration interface, puts its IP address and public key on the chain, and injects a certain amount of deposit into the contract as a token for participating in the committee. The training node belonging to the shard decides whether to participate in the learning task. If it participates, the training node needs to call the contract's training node registration interface to put its IP address and public key on the chain and pay a certain amount of deposit as the price for submitting malicious gradients.

[0018] S14: After registration, the training node downloads the model, initial parameters and other training information from the genesis block and uses local data to train the model. After completing one round of training, the training node randomly generates noise according to the noise distribution specified by the task publisher and adds noise to the gradient. The training node generates a random key and encrypts the noisy gradient. Only the encrypted gradient can be uploaded to the blockchain.

[0019] S15: After the gradient upload phase ends, each training node uploads the symmetric key used to encrypt the gradient within a specified time. Only training nodes that upload both the gradient and the key can receive a reward. Once the key is uploaded, the training node's task in this round of training is completed. Before receiving the updated global model, these training nodes use their idle computing resources to participate in other federated learning tasks.

[0020] S16: After the key upload phase, the committee nodes download the encryption gradients and keys from the blocks of the shard, decrypt them to obtain all the gradients uploaded by the training nodes to which this shard belongs; the committee nodes filter the gradients and select the best part of the gradients for shard-level aggregation; each node in the committee first performs the gradient verification and aggregation process locally, then executes the consensus protocol to reach an agreement on the aggregation result, and appends an aggregation signature to the result for others to verify.

[0021] S17: After the aggregation at the shard level is completed, the leaders of each committee send the aggregated gradient with their signatures to other shards; the committee nodes of each shard verify the signatures of each aggregated gradient, and then perform a second aggregation on each aggregated gradient, using the obtained global gradient to update the model and generate a global model; after the global model is agreed upon within each shard committee, the shard's group signature is attached and sent by the leader to the leaders of other shards; the leaders of each shard finally execute a consensus round, and the global model that has passed the consensus is uploaded by each leader to their respective shard;

[0022] S18: At this point, one round of training for federated learning is complete, and the latest block on the blockchain records the updated global model. Training nodes download the latest model from their respective shards to begin a new round of iteration. After reaching the maximum number of training rounds, the entire federated learning task ends, and the last block on the blockchain retains the results of this training, which is the model required by the task issuer.

[0023] Furthermore, the deposit array generation algorithm described in step S11 includes the following steps:

[0024] Step 1: Input the mapping relationship map between consensus node peer_ID and deposit peer_deposit, and initialize the integer array Deposit used for committee election as [0,0,...,0];

[0025] Step 2: Initialize the total deposit amount (sum) received from the smart contract to 0;

[0026] Step 3: Perform the following traversal processing on the map that maps consensus node peer_IDs to deposit peer_deposits:

[0027] ① Calculate sum = sum + peer_deposit;

[0028] ② Let i range from index to index + peer_deposit - 1, and assign deposit[i] = peer_ID;

[0029] ③ Calculate index = index + peer_deposit;

[0030] Step 4: Output Deposit and sum.

[0031] Furthermore, the Committee Selection algorithm described in step S11 includes the following steps:

[0032] Step 1: Enter Deposit, sum r And s, using the r-th integer sum from the random array defined by the task publisher. r Seed as a hash algorithm;

[0033] Step 2: Take the hash value generated by the hash algorithm modulo the total deposit amount (sum) received by the smart contract to obtain the target value (c);

[0034] Step 3: The peer_ID corresponding to index c in the deposit array Deposit is the committee member selected this time;

[0035] Step 4: Hash the seed again to get a new seed. The subsequent process remains the same until s committee members are selected.

[0036] Step 5: The first c%s peer_IDs in the Committee array Committee constitute the leader node.

[0037] Furthermore, the multi-signature aggregation protocol MASign described in step S2 is designed based on the cryptographic and mathematical properties of hash functions and bilinear mappings. On the basis of BLS multi-signature, it designs multi-signature aggregation and provides interfaces for key generation, signature share generation and verification, multi-signature generation and verification, and aggregated multi-signature generation and verification.

[0038] In the initial stage of the multi-signature aggregation protocol MASign, the system calls the parameter generation interface ParaInit(λ) to generate public parameters and broadcast them. Each participating node calls the key generation interface KeyGen(par) to generate public and private keys representing the legitimate identity of the node. The Certificate Authority (CA) completes the node identity authentication, adds the legitimate node to the shard public key list PKlist, and broadcasts it. The key aggregation interface AggreKey(par,PKlist,T) is designed. Each node combines the shard public key list PKlist to calculate the current signature member view aggregation public key agpk for subsequent verification.

[0039] During the transaction processing phase, each honest node calls the interface ShareSig(par, sk) to verify the valid proposal message m. i The signature share (m) is generated and sent to the leader. The leader verifies the validity of the signature share based on the message hash value H0(m). MAsign sets a threshold value of t, which is the number of signing members in a sharded blockchain transaction processing scheme. After receiving valid signature shares from all t members in the current signing member view, the interface AggreSig(par,PKlist,m,{s) is executed. i ,pk i} |t| ,T) and MulAggreSig(par,PKlist,{σ i ,agpk i ,m i} |s| This provides a multi-signature and aggregated multi-signature generation algorithm for the shard leader, which acts as the aggregator, and is verified by the interfaces AggreVer(par,PKlist,σ,agpki,m) and MulAggreVer(par,{Pklist}). |s| ,∑,{agpk i ,m i} |s| Perform multi-signature validity verification.

[0040] Furthermore, the pipelined on-chip consensus protocol MulPipe-BFT based on improved BLS multi-signature described in step S2 includes a proposal message m. p Node voting message m v Leader view conversion request message m rc Leader view transition message m lc and signature member view conversion message m sc There are 5 message types in total;

[0041] During normal operation, the leader receives a request message (req) and periodically generates new proposals (p). l The sub-protocol JudgeValid is invoked based on the request type, passing in the request parameters, and setting a flag for request availability in the new proposal; the chip operates in a pipelined mode, with the leader proposal message m p Includes multi-signature proofs of the proposals made in the previous round by committee members (PCC) l-1 Upon receiving the proposal, the committee members first verify the validity of the multi-signature proof, then perform a state transition on the proposal that has undergone two rounds of voting, transferring the valid proposal p to the state that has already been voted on. l-2 PCC and its multi-signature proof l-2 Output; subsequently, the JudgeValid protocol is called to determine the validity of the new proposal. For valid new proposals, the signature share generation interface is called to vote, and the voting message m is sent. v Send to the leader;

[0042] MulPipe-BFT designs a signature member view fixing and transformation mechanism, using fixed member signatures as proof of a valid proposal within the TimeofView period; the leader sets a timer Timeout after broadcasting a new proposal. l If valid votes from all members in the current signing member view are received before the timer expires, the multi-signature generation interface is called to aggregate signatures and initiate a new round of proposals; otherwise, the signing member view transition phase begins, where new view members are determined based on node behavior and the signing member view transition message m is sent. sc Broadcast the new view; while retaining the leader view transition mechanism, nodes within each shard committee also set a timeout after sending a voting message. n If no new proposal is received from the leader before the timer expires, the leader is considered unavailable, and a leader view transition request message m is sent. rc Upon entering the leader view transition phase, the new leader constructs the leader view transition message m. lc Announcing the transition to the new leader view.

[0043] Furthermore, the request type invocation sub-protocol JudgeValid is used to determine the type of the request input; if the input is an intra-chip transaction, the local UTXO is directly checked. c The state incurs costs for legitimate transactions; if the input is a cross-shard transaction, it combines the received aggregated multi-signature ∑ and the proposal set. Determine the validity of the transaction; if the input is a cross-shard transaction input, check that the input has not been used to consume the transaction output pool UTXO locally. c The available status in the data allows locking of available transaction inputs to prevent double-spending.

[0044] Furthermore, the QuadPipe-Sharding inter-shard transaction processing protocol based on multi-signature aggregation described in step S2 is used to continuously process inter-shard transactions and to change the signature member view when the current view expires.

[0045] If the received transaction is an intra-slice transaction, the MulPipe-BFT sub-protocol is directly invoked to reach consensus on the transaction and complete the transaction processing; if the user uploads a cross-slice transaction (tx), the transaction is processed directly. j Each shard processes transactions related to itself from the system, using the output shard as a coordinator. Cross-shard transactions are categorized based on the input and output shards, and then sorted and packaged in order. In the j-th round, the transaction batch CTX... j The input slice receives ordered batches of transactions from the output slice and selects the transaction input CTX.Input managed by this slice; all input slices call MulPipe-BFT(CTX). j-2 CTX j .Input), submit each CTX j The availability of input, and the submission of CTX that enters the preparation phase in round j-2. j-2 The validity of the input fragment; when the input fragment receives submissions from other input fragments in MulPipe-BFT (p j ,CC j When this occurs, this segment will submit proof (σ). j B j ,H1(p j Send to other input and output fragments; committee members of the input fragments will have access to the tx. j .input locking, i.e., setting UTXO in [tx j .input].state = locked; This is for invalid transactions tx' where some input is unavailable. j-2 The unavailable tx′ j-2 .input is unlocked and made available;

[0046] According to the multi-signature aggregation protocol MAsign, the output fragment calls MulAggreSig({σ j} k Generate an aggregated multi-signature ∑ j This completes the multi-signature aggregation for cross-shard transaction processing and constructs a unique transaction input availability proof (AC). j After the output shard completes aggregation, this shard will combine the aggregated proofs with the sorted batches of pending transactions (CTX). j+2 Sending the input fragments together will generate input fragments; subsequently, the output fragments will call MulPipe-BFT(CTX). j Submit to CTX j and its corresponding AC j The input fragment continues to call MulPipe-BFT(CTX). j CTX j+2 .Input), submit to CTX j The effectiveness and CTX j+2 The availability of each input; when the output shard receives the committed (p, CC), this shard records the transaction in the log;

[0047] If in partition S c There is a signed member view change message m sc Leader node L c All nodes will be notified, and each node will update the SPKlist of signing members and recalculate the aggregate public key agpk locally. If the current shard initiates a signing member view transition, the leader will receive the new signing member view number v from MulPipe-BFT. s 'and signature member bitmap Signature member view conversion message m sc If the message is received, it is broadcast to all other shard leaders; upon receiving it, other shard leaders broadcast it to their respective shards, and all nodes update their local storage of the shard signature member view information according to the bitmap. Re-determine the fragment signing public key list SPKlist and the aggregate public key agpk.

[0048] Furthermore, the inherent security enhancement technology for federated learning described in step S3 resists the risks encountered during federated learning training, including the following steps:

[0049] S31: Use uniform noise reduction technique to protect gradients and resist data recovery attacks; the task publisher specifies a uniform distribution function while providing the model structure and parameters; before uploading local gradients, each training node generates random noise according to the specified distribution function to mask the gradients; during model aggregation, noise from the same distribution with an expected value of 0 theoretically cancels each other out, and the sum of noise approaches 0.

[0050] S32: A phased encryption technique is used to prevent lazy training nodes from directly obtaining noisy gradients uploaded by other training nodes, thus resisting free-rider attacks. Training nodes generate random keys and use the SM4 algorithm to encrypt the noisy gradients again before they can be uploaded to the blockchain. After the gradient submission phase ends, each training node uploads the symmetric key used for encryption, ensuring that lazy training nodes cannot steal gradients from others during the gradient submission phase.

[0051] S33: Design a Bipole dual filter to resist poisoning attacks. Use cosine similarity as an evaluation metric for gradient similarity to verify gradients, select a subset of gradients for average aggregation to obtain the aggregated gradient at the fragment level; define the proportion f of sporadic adversaries. solo The proportion of colluding with the enemy f team The actual proportion of malicious gradients in each round and estimated value In each round, the sharding committee members assign each gradient w to... i Calculate the cosine similarity between the gradient and the residual gradient, and take the maximum value, denoted as cs. i Assuming the total number of gradients is n, and considering cs i Lowest rating The gradients were uploaded by a few competitors, with the highest score being the highest. The gradients are provided by colluding attackers and then filtered out; a feedback adjustment strategy is used to gradually adjust the gradients. to approximate the value of p solo The strategy of targeted search is constantly increasing To find the value of f team .

[0052] Furthermore, in step S31, the gradient filtering and aggregation algorithm select_and_aggregate is used to perform shard-level gradient filtering and aggregation based on the proportion of malicious gradients uploaded by sporadic adversaries and colluding adversaries. Specifically, this includes:

[0053] S311: Input Δω, p solo p team For each training node i, calculate the cosine similarity cs between the gradients uploaded by each of the other training nodes j and i. ij Take CSij The maximum value is denoted as d. i ;

[0054] S312: For all d i Sort the array 'distance' in ascending order;

[0055] S313: Effective cosine similarity array distance valid =distance[p solo *cnt,…,(1-p team )*cnt];

[0056] S314: For distance valid For each cosine similarity d in the graph, let its corresponding training node number be index, and calculate the sum of effective gradients valid_updates=valid_updates+Δω[index];

[0057] S315: Calculate the aggregation gradient at the piecewise level

[0058] Furthermore, in step S33, the dual-filter algorithm Bipole adjusts the filtering ratio in each round of training. and Search and Filter out the effective gradients and aggregate them to obtain Specifically, the following steps are included:

[0059] S331: Input ω r-1 ,Δω, R solo The step size τ is set at 5%, and the initial reward value is...

[0060] S332: Usage Ratio and Run the select_and_aggregate algorithm to perform gradient filtering and aggregation;

[0061] S333: Update the model The accuracy of the updated model is evaluated, denoted as .

[0062] S334: Will Increase the value of τ and rerun the select_and_aggregate algorithm;

[0063] S335: Obtain the model The accuracy of the test model is denoted as judge:

[0064] like Filtration ratio Reward value in the next round The next round will continue to increase. Explore the value;

[0065] like Filtration ratio Reward Value Next round of reduction Find the value of p in the opposite direction. solo ;

[0066] S336: hour Convergence, output of this round

[0067] S337: In the next round, the reward for the input is evaluated. If... Then output directly

[0068] S338: When At that time, the current filtration ratio

[0069] S339: When At that time, filtration ratio

[0070] S3310: Filtration ratio for the next round from and Selected from;

[0071] S3311: Output R solo .

[0072] The beneficial effects of this invention are as follows:

[0073] 1) The large-scale model training architecture based on sharded blockchain and federated learning uses sharded blockchain to replace the central server, achieving collaborative on-chain and off-chain storage of the model. This ensures the permanent recording and immutability of the model, as well as the consistency and liveness of model training. In this invention, as the number of nodes increases, the ability to process training tasks is continuously improved by increasing the number of shards, achieving the scalability of the federated learning system and adapting to federated learning scenarios for large AI models of different scales.

[0074] 2) The multi-shard collaborative model aggregation scheme based on a four-stage pipeline two-phase commitment completes one transaction processing session per vote on average, increasing the system's parallelism from 1 to 4 and significantly improving the throughput of the federated learning system. This invention designs a multi-signature aggregation scheme and a signature member view fixing and transformation mechanism to further reduce the amount of intra-shard and inter-shard communication data and the complexity of signature verification, which helps improve the training efficiency of large AI models.

[0075] 3) The inherent security enhancement technology of federated learning protects against common data recovery attacks, free-rider attacks, and poisoning attacks during the federated learning process, providing high security. Before uploading local gradients to the sharded blockchain for aggregation, training nodes mask the gradients to prevent adversaries from deducing training data from intercepted gradients. Symmetric encryption is used to encrypt the noisy gradients to prevent training nodes from stealing data uploaded by other training nodes. Before the consensus node aggregates gradients, a scoring mechanism is established using cosine similarity as an evaluation metric to filter malicious gradients uploaded by attackers.

[0076] Other advantages, objectives, and features of the invention will be set forth in the following description and will be apparent to those skilled in the art in some respects, or may be learned by practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0077] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the following figures are provided for illustration:

[0078] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0079] Figure 2 This is a schematic diagram of the QuadPipe-Sharding protocol;

[0080] Figure 3 This is a timing diagram for the QuadPipe-Sharding protocol. Detailed Implementation

[0081] like Figure 1As shown, this invention proposes a sharded blockchain federated learning method for large AI models. First, addressing the insufficient scalability of existing federated learning architectures, this invention designs a scalable large model training architecture based on sharded blockchains and federated learning. On-chain storage ensures permanent and immutable model storage, Byzantine fault-tolerant consensus guarantees consistency of training results, and sharding technology ensures system scalability at the architectural level. Second, this invention innovatively designs a multi-shard collaborative model aggregation scheme (SP) based on a four-stage pipeline two-phase commitment, including a multi-signature aggregation protocol (MASign), a pipelined intra-shard consensus protocol based on improved BLS multi-signature (MulPipe-BFT), and a four-stage pipelined inter-shard transaction processing protocol based on multi-signature aggregation (QuadPipe-Sharding). This scheme, based on the Hotstuff pipelined consensus mechanism and the traditional cross-shard transaction two-phase commitment protocol, combined with multi-signature aggregation algorithms and mechanisms such as signature member view fixing and transformation, reduces the complexity and data volume of inter-node communication, achieving low-overhead node communication and high-concurrency transaction commitments. Third, this invention designs an intrinsic security enhancement technology for federated learning. In response to the three security risks of data recovery attacks, free-rider attacks and poisoning attacks in existing federated learning methods, three corresponding security mechanisms are designed: uniform noise protection mechanism, phased encryption submission mechanism and Bipole dual filter, to ensure the security and trustworthiness of the federated learning training process.

[0082] The system assumptions of this invention are as follows:

[0083] For task publishers, publishing a task requires injecting funds into the smart contract. If the expected model is not obtained, the task publisher will not receive any benefits, thus ruling out the possibility of them acting maliciously.

[0084] Training nodes need to use local data for model training and upload the resulting gradients to receive rewards. However, training consumes computational and storage resources, making them more prone to stealing gradients from others. Furthermore, some training nodes may attempt to corrupt the model for various purposes, uploading incorrect gradients to interfere with training.

[0085] For consensus nodes, some nodes may attempt to extract information about a user's local data from the gradients uploaded by the user, thus posing a potential threat. The number of adversaries in the system is defined as follows: assuming each shard has n consensus nodes, the number of corrupt consensus nodes f... p It needs to satisfy n≥3f p +1.

[0086] The system architecture of this invention is as follows:

[0087] The system comprises three roles: Task Publisher (TP), Training Node (Client, C), and Consensus Node (Peer, P). The network is divided into subnets, each containing a separate blockchain record called a shard (S). Consensus nodes and training nodes belonging to each shard form a small P2P network. Training nodes can communicate with the consensus nodes of each shard, but during each task, a training node only needs to communicate with the consensus node of its current shard; communication between training nodes is unnecessary.

[0088] The sharded blockchain federated learning method designed in this invention does not require the participation of a trusted third party, relying instead on the automatic triggering characteristic of smart contracts when predetermined rules are met. The smart contracts mainly implement the following functions: 1) The task publisher publishes the task in the form of a smart contract on some shards, completing data interaction through the blockchain and data holders (training nodes). 2) Participants interested in the task call the smart contract's interface to upload necessary identity information to the blockchain, completing registration. This design utilizes the advantage of the blockchain as a public ledger, eliminating the process of broadcasting public keys within shards and reducing communication burden. 3) The smart contract can act as a trusted arbitrator to reward or punish parties within the system. When publishing a smart contract, the task publisher needs to inject funds into the contract. Honest participants receive a portion of these funds as a reward upon completion of each training round. When registering as a participant in a federated learning task, training nodes need to inject a deposit into the contract. If a training node uploads malicious gradients attempting to corrupt the model, the smart contract will transfer their deposit to the contract owner's account.

[0089] The intra-shard consensus protocol is developed by the intra-shard committee node CP. i Operating Protocol Π MulPipe-BFT Drive, Π MulPipe-BFT It is a pipelined consensus protocol that can complete the preparation of the current round of proposals and the commitment process of the previous round of proposals in parallel. Compared with the two rounds of voting in traditional Byzantine fault-tolerant protocols, it reduces the average number of voting rounds for proposal commitments to one round, significantly improving commitment efficiency. MulPipe-BFT It includes the transaction validity judgment sub-protocol JudgeValid, which is used to verify local unspent transaction output information and multiple signatures, and to determine the validity of protocol input requests.

[0090] Inter-film transaction processing is handled by Π QuadPipe-Sharding Processing, Π QuadPipe-ShardingBased on the traditional two-phase commit protocol, the first round of BFT consensus voting within the chip during the preparation phase, the second round of BFT consensus voting within the chip during the preparation phase, the first round of BFT consensus voting within the chip during the commitment phase, and the second round of BFT consensus voting within the chip during the commitment phase are processed in parallel, increasing the parallelism of cross-chip transaction processing from 1 to 4. Simultaneously, a multi-signature aggregation protocol Π is utilized. MAsign Reduce the complexity of intra-shard communication and cross-shard communication.

[0091] The complete protocol of this invention uses Π SP =(Π) MAsign ,Π MulPipe-BFT ,Π QuadPipe-Sharding ) indicates that Π MAsign Used for multi-signature aggregation between fragments, Π MulPipe-BFT This includes the consensus transaction processing of committee nodes within the slice and the view transformation process of signer members within the slice. QuadPipe-Sharding This is used for efficient processing of cross-shard transactions between shards. The following sections will elaborate on the sharded blockchain federated learning architecture designed by the method, the multi-shard collaborative model aggregation scheme constructed in this invention, and the inherent security enhancement technology of federated learning.

[0092] 1. Large-scale model training architecture based on sharded blockchain and federated learning

[0093] This invention designs a large-scale model training architecture based on sharded blockchain and federated learning. The specific process of federated learning training under this architecture is as follows:

[0094] 0) System Initialization. A deposit contract is deployed on each shard. Each node within a shard uploads its IP address and public key to the blockchain and pledges a certain amount of tokens to the deposit contract as leverage for participating in the committee member election. The committee election algorithm of this invention ensures that the probability of each member being selected is proportional to the amount of their pledge. After receiving the pledge, the smart contract concatenates the node IDs into an array according to the pledge amount. After initialization, the committee election function in the deposit contract is automatically triggered, executing the Deposit Array Generation algorithm (sub-algorithm 1) and the Committee Selection algorithm (sub-algorithm 2) to select a committee for the upcoming federated learning task. To prevent adversaries from corrupting committee members, the committee needs to be reorganized after each round of training.

[0095]

[0096] 1) Task Issuance. The task issuer selects several shards based on the task requirements and publishes the federated learning task on the sharded blockchain in the form of a smart contract. The task issuer needs to describe the task in the smart contract, specify the initial model used for training, and provide the noise distribution function and adversary ratio. To attract shards and training nodes to participate in the training task, the task issuer needs to inject a certain amount of funds into the smart contract as a reward for participation in this task.

[0097] 2) Registration. When the smart contract is deployed, all nodes belonging to that shard execute consensus to decide whether to participate in the tasks stipulated by the smart contract. If they participate, each node calls the contract's node registration interface, uploads its IP address and public key to the blockchain, and injects a certain amount of deposit into the contract as a token for selecting committee members. On the other hand, the training nodes belonging to the shard decide whether to participate in the learning task. If they participate, the training nodes need to call the contract's training node registration interface, upload their IP address and public key to the blockchain, and pay a certain amount of deposit as the price for submitting malicious gradients.

[0098] 3) Gradient Upload. After registration, the training node downloads the model, initial parameters, and other training information from the genesis block and trains the model using local data. After one round of training, to prevent data recovery attacks, the training node randomly generates noise according to the noise distribution specified by the task publisher and adds noise to the gradient. To prevent free-rider attacks, the training node also needs to generate a random key and encrypt the noisy gradient using the SM4 algorithm. Only the encrypted gradient can be uploaded to the blockchain.

[0099] 4) Key Upload. After the gradient upload phase ends, each training node needs to upload the symmetric key used to encrypt the gradient. The upload operation must be completed within the specified time. Only training nodes that upload both the gradient and the key are eligible for a reward. Once the key upload is complete, the training node's task for this round of training is finished. Before receiving the updated global model, these training nodes can utilize their idle computing resources to participate in other federated learning tasks.

[0100] 5) Gradient Validation and Local Aggregation. After the key upload phase, committee nodes download encrypted gradients and keys from the shard blocks, decrypt them to obtain all gradients uploaded by the training nodes belonging to their shard. To reduce the adverse effects of malicious gradients on the model, committee nodes filter the gradients, selecting the optimal subset for shard-level aggregation. Each node in the committee first performs gradient validation and aggregation locally, then executes the consensus protocol to reach agreement on the aggregation result, and appends an aggregation signature to the result for verification by others.

[0101] 6) Global Aggregation. After shard-level aggregation is completed, the leaders of each committee send the aggregated gradients with their signatures to other shards. Each shard's committee nodes verify the signatures of each aggregated gradient, then perform a second aggregation, using the resulting global gradient to update the model and generate the global model. Once each shard committee reaches a consensus on the global model, it attaches the shard's group signature and sends it to the leaders of other shards. Finally, each shard leader executes a final round of consensus, and the globally agreed-upon model is uploaded to its respective shard by each leader.

[0102] 7) Model Update. At this point, one round of training for federated learning is complete, and the latest block on the blockchain records the updated global model. Training nodes download the latest model from their respective shards to begin a new round of iteration. After reaching the maximum number of training rounds, the entire federated learning task ends, and the last block on the blockchain retains the results of this training, which is the model required by the task issuer.

[0103] The complete description of a secure federated learning scheme based on sharded blockchain is as follows:

[0104]

[0105]

[0106]

[0107] 2. A multi-shard collaborative transaction processing scheme (SP) based on pipeline mechanism and multi-signature aggregation.

[0108] Multi-chip collaborative transaction processing solution Π SP It consists of three sub-protocols: MAsign, MulPipe-BFT, and QuadPipe-Sharding.

[0109] The sub-protocol MAsign is designed based on the cryptographic and mathematical properties of hash functions and bilinear mappings. Building upon BLS multi-signature, it designs multi-signature aggregation and provides multiple interfaces, including key generation, signature share generation and verification, multi-signature generation and verification, and aggregated multi-signature generation and verification.

[0110] In the initial stage of protocol operation, the system can call the parameter generation interface ParaInit(λ) to generate public parameters and broadcast them. Each participating node calls the key generation interface KeyGen(par) to generate public and private keys representing the node's legitimate identity. The Certificate Authority (CA) completes the node identity authentication, adds the legitimate node to the shard's public key list PKlist, and broadcasts it. Since the leader will determine the signing member view T for a certain period of time based on the performance of the nodes in the shard committee in the subsequent intra-shard consensus protocol and broadcast it to the entire network, the key aggregation interface AggreKey(par,PKlist,T) is designed. Each node can combine the shard's public key list PKlist to calculate the aggregated public key agpk of the current signing member view of the shard for subsequent verification.

[0111] During the transaction processing phase, each honest node can call the interface ShareSig(par, sk) to verify a valid proposal message m. i The signature share (m) is generated and sent to the leader. The leader verifies the validity of the signature share based on the message hash value H0(m). MAsign sets a threshold value of t, which is the number of signing members in a sharded blockchain transaction processing scheme. After receiving valid signature shares from all t members in the current signing member view, the interface AggreSig(par,PKlist,m,{s) is executed. i ,pk i} |t| ,T) and MulAggreSig(par,PKlist,{σ i ,agpk i ,m i} |s| This provides multi-signature and aggregated multi-signature generation algorithms for the shard leader acting as an aggregator, and is supported by the verification interfaces AggreVer(par,PKlist,σ,agpk,m) and MulAggreVer(par,{Pklist}). |s| ,∑,{agpk i ,m i} |s| Perform multi-signature validity verification.

[0112] The multi-signature aggregation protocol MAsign reduces the communication complexity of the on-chip consensus process proposal broadcast phase from O(u) to O(u). 2 The communication complexity of the availability proof forwarding phase in cross-shard transaction processing is reduced from O(k) to O(u). 2The computational complexity is reduced to O(k), where k is the number of transaction input shards and u is the number of nodes within each shard (assuming the number of nodes within each shard is the same). Since this protocol only adds a multi-signature aggregation step and a legitimacy verification step to the traditional BLS signature, it still satisfies integrity, non-forgeability, and robustness. Compared to threshold signature technology commonly used in blockchain systems, the multi-signature aggregation protocol does not require distributed key generation. Nodes can calculate their public and private keys themselves based on system parameters, and the Certificate Authority (CA) completes identity authentication and public key broadcasting. This makes it easier for the network to dynamically adjust node composition and change node public keys, providing greater flexibility.

[0113]

[0114]

[0115] The sub-protocol MulPipe-BFT describes an intra-fragment pipelined Byzantine fault-tolerant protocol. The protocol contains a proposal message m. p Node voting message m v Leader view conversion request message m rc Leader view transition message m lc and signature member view conversion message m sc There are 5 message types in total.

[0116] During normal operation, the leader receives a request message (req) and periodically generates new proposals (p). l Based on the request type, the `JudgeValid` subprotocol is invoked, passing in the request parameters, and a flag for request availability is set in the new proposal. The chip operates in a pipelined mode, with the leader proposal message m... p Includes multi-signature proofs of the proposals made in the previous round by committee members (PCC) l-1 Upon receiving the proposal, the committee members first verify the validity of the multi-signature proof, then perform a state transition on the proposal that has undergone two rounds of voting, transferring the valid proposal p to the state that has already been voted on. l-2 PCC and its multi-signature proof l-2 Output. Afterwards, the JudgeValid protocol is called to determine the validity of the new proposal. For valid new proposals, the signature share generation interface is called to vote, and the voting message m is sent. v Send to the leader.

[0117] MulPipe-BFT designs a signature member view fixing and transformation mechanism, using fixed member signatures as proof of a valid proposal within the TimeofView period. The leader sets a timer (Timeout) after broadcasting a new proposal. lIf valid votes from all members in the current signing member view are received before the timer expires, the multi-signature generation interface is called to aggregate signatures and initiate a new round of proposals; otherwise, the signing member view transition phase begins, where new view members are determined based on node behavior and the signing member view transition message m is sent. sc Broadcast the new view. Simultaneously, retain the leader view transition mechanism, and each node in the shard committee also sets a timeout after sending a voting message. n If no new proposal is received from the leader before the timer expires, the leader is considered unavailable, and a leader view transition request message m is sent. rc Upon entering the leader view transition phase, the new leader constructs the leader view transition message m. lc Announcing the transition to the new leader view.

[0118] The complete protocol description is as follows:

[0119]

[0120]

[0121] The JudgeValid protocol, a sub-protocol of the MulPipe-BFT on-chip consensus protocol, determines the type of the request input. If the input is an on-chip transaction, it directly checks the local UTXO. c The state incurs costs for legitimate transactions; if the input is a cross-shard transaction, it combines the received aggregated multi-signature ∑ and the proposal set. Determine the validity of the transaction; if the input is a cross-shard transaction input, check that the input has not been used to consume the transaction output pool UTXO locally. c The available status in the data allows locking of available transaction inputs to prevent double-spending.

[0122]

[0123] like Figure 2-3 As shown, Sub-protocol 4, QuadPipe-Sharding, is primarily used for continuous and uninterrupted processing of inter-shard transactions and for making signature member view changes when the current view expires.

[0124] If the received transaction is an intra-slice transaction, the MulPipe-BFT sub-protocol is invoked directly to reach consensus on the transaction and complete the transaction processing. If the user uploads a cross-slice transaction (tx),... j Each shard processes transactions related to itself from the system. To achieve batch processing of transactions and ensure view consistency, an output shard is used as a coordinator. Cross-shard transactions are classified according to the transaction input and output shards, and then sorted and packaged in order. In the j-th round, the transaction batch CTX...j The input slice receives ordered batches of transactions from the output slice and selects the transaction input CTX.Input managed by this slice. All input slices call MulPipe-BFT(CTX). j-2 CTX j .Input), submit each CTX j The availability of input, and the submission of CTX that enters the preparation phase in round j-2. j-2 The validity of the input fragment. When the input fragment receives a (p) submitted by another input fragment from MulPipe-BFT. j CC j When this occurs, this segment will submit proof (σ). j B j ,H1(p j Send it to other input and output fragments. Since p has already been submitted... j =V j-2 ||B j Represents CTX j Input availability and CTX j-2 The validity of the transaction, the input shard, will be available to committee members. j .input locking, i.e., setting UTXO in [tx j .input].state = locked. Furthermore, for invalid transactions tx' where some input is unavailable... j-2 The unavailable tx′ j-2 The .input field is unlocked and made available.

[0125] According to the multi-signature aggregation protocol MAsign, the output fragment calls MulAggreSig({σ j} k Generate an aggregated multi-signature ∑ j This completes the multi-signature aggregation for cross-shard transaction processing and constructs a unique transaction input availability proof (AC). j Once the output shard has completed aggregation, this shard will combine the aggregated proof with the sorted batch of pending transactions (CTX). j+2 Sending the input fragments together will generate input fragments. Then, the output fragments will be processed using MulPipe-BFT(CTX). j Submit to CTX j and its corresponding AC j The input fragment continues to call MulPipe-BFT(CTX). j CTX j+2 .Input), submit to CTX j The effectiveness and CTX j+2The availability of each input. When the output shard receives a committed (p, CC), this shard records the transaction in the log.

[0126] If in partition S c There is a signed member view change message m sc Leader node L c All nodes will be notified, and each node will update the SPKlist of signing members and recalculate the aggregate public key agpk locally. If the current shard initiates a signing member view transition, the leader will receive a view number v containing the new signing member view number for that shard from MulPipe-BFT. s' and signature member bitmap Signature member view conversion message m sc If the message is received, it is broadcast to all other shard leaders. Upon receiving the message, other shard leaders broadcast it within their respective shards, and all nodes update their locally stored shard signature member view information based on the bitmap. Re-determine the fragment signing public key list SPKlist and the aggregate public key agpk.

[0127] The protocol flow is described as follows:

[0128]

[0129]

[0130] 3. Federated Learning Intrinsic Security Enhancement Technology Based on Staged Encryption and Dual Filtering

[0131] This invention designs an intrinsic security enhancement technique for federated learning based on staged encryption and dual filters to resist attacks that may occur during federated learning training. The detailed process is as follows:

[0132] (1) To resist data recovery attacks, uniform noise is used to protect the gradient. The task publisher specifies a uniform distribution function along with the given model structure and parameters, which is generally a normal distribution with an expected value of 0. Before uploading the local gradient, each training node needs to generate random noise according to the specified distribution function to mask the gradient. During model aggregation, noise from the same distribution with an expected value of 0 will theoretically cancel each other out, and the sum of the noise will approach 0, so its impact on the global model can be ignored.

[0133] (2) To resist free-rider attacks, a phased encryption technique is used to prevent lazy training nodes from directly obtaining noisy gradients uploaded by other training nodes. Training nodes generate random keys and use the SM4 algorithm to encrypt the noisy gradients again before uploading them to the blockchain. After the gradient submission phase ends, each training node uploads the symmetric key used for encryption, thus ensuring that lazy training nodes cannot steal gradients from others during the gradient submission phase.

[0134] (3) To resist poisoning attacks, a Bipole dual filter is designed, using cosine similarity as the evaluation index of gradient similarity to verify the gradients. A subset of gradients is selected and averaged to obtain the aggregated gradient at the fragment level. The proportion f of sporadic adversaries is defined. solo The proportion of colluding with the enemy f team The actual proportion of malicious gradients in each round and estimated value In each round, the sharding committee members assign each gradient w to... i Calculate the cosine similarity between the gradient and the residual gradient, and take the maximum value, denoted as cs. i Assuming the ladder cs i The total number of degrees is n, and cs is considered to be i Lowest rating The gradient was uploaded by a few rivals, and the highest-rated one... The gradients, provided by colluding attackers, are filtered out. A feedback-based adjustment strategy is used for gradual adjustment. to approximate the value of p solo The strategy of targeted search is constantly increasing To find the value of f team .

[0135] The gradient filtering and aggregation algorithm select_and_aggregate (sub-algorithm 3) performs gradient filtering and aggregation at the shard level based on the proportion of malicious gradients uploaded by sporadic adversaries and colluding adversaries.

[0136]

[0137] The Bipole dual-filter algorithm adjusts the filtering ratio in each round of training. and Search and Filter out the effective gradients and aggregate them to obtain Its function in the system is shown in sub-algorithm 4.

[0138]

[0139] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made to it in form and detail without departing from the scope defined by the claims of the present invention.

Claims

1. A sharded blockchain federated learning method for large AI models, characterized in that: Includes the following steps: S1: Construct a scalable large-scale model training architecture based on sharded blockchain and federated learning. On-chain storage ensures permanent and immutable model storage, Byzantine fault-tolerant consensus guarantees consistency of training results, and sharding technology ensures the scalability of the federated learning system at the architectural level. The specific process for federated learning training using the scalable large-scale model training architecture based on sharded blockchain and federated learning described in step S1 is as follows: S11: Deploy deposit contracts on each shard. Each node in the shard uploads its IP address and public key to the blockchain and injects its voting tokens into the committee. The deposit contract concatenates node IDs into an array according to the amount of deposit. The deposit contract selects a committee for the upcoming federated learning task. The committee needs to be reorganized for each round of training. S12: The task publisher publishes the federated learning task on the sharded blockchain according to the demand, sets the parameters and injects reward funds through smart contracts; S13: When deploying a smart contract, all nodes in the shard reach a consensus to decide whether to participate in the task. If they do, they register as nodes and inject voting tokens into the committee. The training nodes to which the shard belongs decide whether to participate in the learning task. If they do, they register as training nodes and pay a deposit. S14: The training node uses local data to train the model. After completing one round of training, the training node adds noise and encrypts the gradient to obtain the encrypted gradient, and uploads it to the blockchain. S15: Each training node uploads the symmetric key used for encryption gradients to the blockchain within the specified time. S16: Committee nodes download encrypted gradients and keys from the blocks of the shard, decrypt them to obtain all gradients uploaded by the training nodes to which the shard belongs; committee nodes select the best part from the gradients and perform shard-level aggregation; each node in the committee performs gradient verification and aggregation locally, and attaches an aggregation signature after reaching a consensus on the aggregation result. S17: The shard sends the aggregated gradient with the signature to other shards; the committee nodes of each shard verify the aggregated gradient and perform secondary aggregation, using the obtained global gradient to update the model and generate the global model; after the committee of each shard reaches a consensus on the global model, it attaches the shard group signature and sends it to other shard leaders; each shard leader executes the consensus and uploads the global model that has passed the consensus to its shard. S18: The latest block on the blockchain records the updated global model; training nodes download the latest model and begin a new round of iteration; after reaching the maximum number of training rounds, the last block on the blockchain retains the model required by the task publisher; S2: Construct a multi-shard collaborative model aggregation scheme SP based on a four-stage pipeline two-phase commitment, including the multi-signature aggregation protocol MASign, the pipeline mode intra-shard consensus protocol MulPipe-BFT based on improved BLS multi-signature, and the four-stage pipeline mode inter-shard transaction processing protocol QuadPipe-Sharding based on multi-signature aggregation. S3: Construct an intrinsic security enhancement technology for federated learning, consisting of uniform noise addition, phased encryption, and Bipole dual filters, to resist the risks faced during federated learning training.

2. The sharded blockchain federated learning method for large AI models according to claim 1, characterized in that: The specific process for federated learning training based on the scalable large model training architecture using sharded blockchain and federated learning, as described in step S1, is as follows: S11: System Initialization: Deploy a deposit contract on each shard. Each node within a shard uploads its IP address and public key to the blockchain and pledges tokens to the deposit contract as collateral for election as a committee member. Upon receiving the deposits, the smart contract concatenates the node IDs into an array based on the deposit amount. After initialization, the committee election function in the deposit contract is automatically triggered, executing the deposit array generation algorithm. And committee election algorithm Select a committee for the upcoming federal learning mission; the committee will need to be reorganized for each round of training. S12: The task publisher selects several shards according to the task requirements and publishes the federated learning task on the sharded blockchain in the form of a smart contract; the task publisher describes the task in the smart contract, specifies the initial model used for training, and gives the noise distribution function and the proportion of adversaries; the task publisher injects funds into the smart contract as a reward for participating in this task. S13: When the smart contract is deployed, all nodes to which the shard belongs execute consensus to decide whether to participate in the tasks stipulated by the smart contract; if they participate, each node calls the contract's node registration interface, puts its own IP address and public key on the chain, and injects a deposit into the contract as a token for the election of committee members. The training node to which the shard belongs decides whether to participate in the learning task. If it does participate, the training node needs to call the training node registration interface of the contract to put its IP address and public key on the chain and pay a deposit as the price for submitting malicious gradients. S14: After registration is complete, the training node downloads the information required for training from the genesis block, including the model and initial parameters, and trains the model using local data; after completing one round of training, the training node randomly generates noise according to the noise distribution specified by the task publisher and adds noise to the gradient. The training node generates a random key to encrypt the noisy gradient, so that the encrypted gradient can be uploaded to the blockchain. S15: After the gradient upload phase ends, each training node uploads the symmetric key used to encrypt the gradient within a specified time. Only training nodes that upload both the gradient and the key can receive the reward. Once the key is uploaded, the training node's task in this round of training is completed. Before receiving the updated global model, these training nodes use their idle computing resources to participate in other federated learning tasks. S16: After the key upload phase, the committee nodes download the encryption gradients and keys from the blocks of the shard, decrypt them to obtain all the gradients uploaded by the training nodes to which this shard belongs; the committee nodes filter the gradients and select the best part of the gradients for shard-level aggregation; each node in the committee first performs the gradient verification and aggregation process locally, then executes the consensus protocol to reach an agreement on the aggregation result, and appends an aggregation signature to the result for others to verify. S17: After the aggregation at the shard level is completed, the leaders of each committee send the aggregated gradient with their signatures to other shards; the committee nodes of each shard verify the signatures of each aggregated gradient, and then perform a second aggregation on each aggregated gradient, using the obtained global gradient to update the model and generate a global model; after the global model is agreed upon within each shard committee, the shard's group signature is attached and sent by the leader to the leaders of other shards; the leaders of each shard finally execute a consensus round, and the global model that has passed the consensus is uploaded by each leader to their respective shard; S18: At this point, one round of training for federated learning is complete, and the latest block on the blockchain records the updated global model. Training nodes download the latest model from their respective shards to begin a new round of iteration. After reaching the maximum number of training rounds, the entire federated learning task ends, and the last block on the blockchain retains the results of this training, which is the model required by the task issuer.

3. The sharded blockchain federated learning method for large AI models according to claim 2, characterized in that: The deposit array generation algorithm described in step S11 Includes the following steps: Step 1: Input consensus node With deposit mapping relationship The integer array to be used for committee elections Initially ; Step 2: Total amount of deposit received from the smart contract Initially ; Step 3: For consensus nodes With deposit mapping relationship Perform the following traversal processing: ①Calculation ; ② Order from arrive Assignment ; ③Calculation ; Step 4: Output and .

4. The sharded blockchain federated learning method for large AI models according to claim 3, characterized in that: The committee election algorithm described in step S11 Includes the following steps: Step 1: Input , and Using the random array defined by the task publisher, the first... integers As a hash algorithm Step 2: The hash value generated by the hash algorithm is compared with the total amount of deposits received by the smart contract. Take the modulo to obtain the target value. ; Step 3: Deposit Array Subscript corresponding These are the committee members selected this time; Step 4: Perform another hash to get a new one. The subsequent process remains unchanged until a candidate is selected. ; Step 5: Committee Array Center front indivual Leader node .

5. The sharded blockchain federated learning method for large AI models according to claim 1, characterized in that: The multi-signature aggregation protocol MASign described in step S2 is designed based on the cryptographic and mathematical properties of hash functions and bilinear mappings. On the basis of BLS multi-signature, it designs multi-signature aggregation and provides interfaces for key generation, signature share generation and verification, multi-signature generation and verification, and aggregated multi-signature generation and verification. In the initial stage of the MASign multi-signature aggregation protocol, the system calls the parameter generation interface. Generate public parameters and broadcast them; each participating node then calls the key generation interface. Generate public and private keys representing the legitimate identity of the node. The Certificate Authority (CA) then authenticates the node's identity and adds the legitimate node to the public key list of its respective shard. And broadcast; design a key aggregation interface. Each node combines its own shard public key list Calculate the aggregated public key of the current signature member view of the corresponding shard. For subsequent verification; During the transaction processing phase, each honest node verifies the validity of the proposal message. Calling the interface Generate a signature share and send it to the leader, who then uses the message hash value. Verify the validity of the signature share; MAsign sets the threshold value to [value missing]. In a sharded blockchain transaction processing scheme, this refers to the number of signing members. When all members in the current signing member view are received... After each member's valid signature share, the interface... and Provides multi-signature and aggregated multi-signature generation algorithms for the shard leader acting as an aggregator, and is verified by the interface. and Perform multi-signature validity verification.

6. The sharded blockchain federated learning method for large AI models according to claim 1, characterized in that: Step S2 describes the MulPipe-BFT pipelined on-chip consensus protocol, which includes a proposal message. Node voting messages Leader view conversion request message Leader view switching message and signature member view conversion message There are 5 message types in total; During normal operation, the leader receives the request message. And generate new proposals regularly. The `JudgeValid` subprotocol is invoked based on the request type, passing in the request parameters, and setting a flag for request availability in the new proposal; the chip operates in a pipelined mode, with the leader proposing the message. Includes multi-signature proof of the proposal from the previous round by committee members. ; Upon receiving the proposal, the committee members first verify the validity of the multi-signature proof, then perform a state transition on the proposal that has already undergone two rounds of voting, thus converting the valid proposal into a valid one. and its multi-signature proof Output; Subsequently, the JudgeValid protocol is invoked to determine the validity of the new proposal. For valid new proposals, the signature share generation interface is invoked to vote, and the voting message is sent. Send to the leader; MulPipe-BFT design signature member view fixing and transformation mechanism, Within a specified time, signatures from fixed members are used as proof of a valid proposal; the leader sets a timer after broadcasting a new proposal. If valid votes are received from all members in the current signing member view before the timer expires, the multi-signature generation interface is called to aggregate signatures and initiate a new round of proposals; otherwise, the signing member view transition phase begins, where new view members are determined based on node behavior and the signing member view transition message is sent. Broadcast the new view; at the same time, retain the leader view transition mechanism, and each node in the shard committee also sets a timer after sending a voting message. If no new proposal is received from the leader before the timer expires, the leader is considered unavailable, and a leader view transition request message is sent. Upon entering the leader view transition phase, the new leader constructs a leader view transition message. Announcing the transition to the new leader view.

7. The sharded blockchain federated learning method for large AI models according to claim 6, characterized in that: The request type invocation subprotocol JudgeValid is used for... The input type is used for judgment; if the input is an intra-chip transaction, the local machine is checked directly. The status incurs costs for legitimate transactions; if the input is a cross-shard transaction, it is combined with the received aggregated multi-signature. and proposal set Determine the validity of the transaction; if the input is a cross-shard transaction input, check if the input has been used up in the local transaction output pool. The available status in the data allows locking of available transaction inputs to prevent double-spending.

8. The sharded blockchain federated learning method for large AI models according to claim 1, characterized in that: The QuadPipe-Sharding inter-shard transaction processing protocol based on multi-signature aggregation described in step S2 is used to continuously process inter-shard transactions and change the signature member view when the current view expires. If the received transaction is an intra-slice transaction, the sub-protocol MulPipe-BFT is invoked directly to reach a consensus on the transaction and complete the transaction processing. If a user uploads a cross-slice transaction Each shard processes transactions related to itself from the system, using the output shard as a coordinator. Cross-shard transactions are categorized based on the input and output shards, and then sorted and packaged in order. In the cycle, transaction batches The input fragment receives ordered batches of transactions from the output fragment and selects the transaction input managed by this fragment. ; All input slices call MulPipe-BFT( Submit each Availability, while submitting in the first The wheel enters the preparation stage The validity of the input fragment; when the input fragment receives submissions from other input fragments in MulPipe-BFT. At that time, this segment will submit proof. Send to other input and output fragments; committee members of the input fragments will be available. Lock, i.e., set For invalid transactions where some input is unavailable It will be unavailable Unlocked to be usable; According to the multi-signature aggregation protocol MAsign, the output fragment calls MulAggreSig( Generate an aggregated multi-signature. This completes the multi-signature aggregation for cross-shard transaction processing and constructs a unique proof of transaction input availability. ; Once the output shard has completed aggregation, this shard will combine the aggregated proofs with the sorted batches of pending transactions. Sending the input fragments together will generate input fragments; then, the output fragments will call MulPipe-BFT (...). ),submit and its corresponding ; Input fragments continue to call MulPipe-BFT( ),submit effectiveness and Availability of each input; When the output fragment receives the submitted... Then, this shard will record the transaction. middle; If in fragmentation There is a signature member view change message. Leader node It will notify all nodes, and each node will update the signature members. And recalculate the aggregated public key locally. ; If the current shard initiates a signature member view transition, the leader receives the new signature member view number for that shard from MulPipe-BFT. and signature member bitmap Signature member view conversion message If the message is received, it is broadcast to all other shard leaders; upon receiving it, other shard leaders broadcast it to their respective shards, and all nodes update their locally stored shard signature member view information according to the bitmap. Re-determine the list of public keys for the fragment signing and aggregated public keys .

9. The sharded blockchain federated learning method for large AI models according to claim 1, characterized in that: The inherent security enhancement technology for federated learning described in step S3, which resists the risks encountered during federated learning training, includes the following steps: S31: Use uniform noise reduction technique to protect gradients and resist data recovery attacks; the task publisher specifies a uniform distribution function while providing the model structure and parameters; before uploading local gradients, each training node generates random noise according to the specified distribution function to mask the gradients; during model aggregation, noise from the same distribution with an expected value of 0 theoretically cancels each other out, and the sum of noise approaches 0. S32: A phased encryption technique is used to prevent lazy training nodes from directly obtaining noisy gradients uploaded by other training nodes, thus resisting free-rider attacks. Training nodes generate random keys and use the SM4 algorithm to encrypt the noisy gradients again before they can be uploaded to the blockchain. After the gradient submission phase ends, each training node uploads the symmetric key used for encryption, ensuring that lazy training nodes cannot steal gradients from others during the gradient submission phase. S33: Design a Bipole dual filter to resist poisoning attacks. Use cosine similarity as an evaluation metric for gradient similarity to verify gradients, select a subset of gradients for average aggregation to obtain the aggregated gradient at the fragment level; define the proportion of sporadic adversaries. The proportion of those who conspire with the enemy The actual proportion of malicious gradients in each round , and estimated value , In each round, the sharding committee members assign responsibilities to each gradient. Calculate the cosine similarity between the gradient and the residual gradient, and take the maximum value, denoted as . Assume the total number of gradients is ,think Lowest rating The gradients were uploaded by a few competitors, with the highest score being the highest. The gradients are provided by colluding attackers and then filtered out; a feedback adjustment strategy is used to gradually adjust the gradients. to approximate the value The strategy of targeted search is constantly increasing To find the value .

10. The sharded blockchain federated learning method for large AI models according to claim 9, characterized in that: In step S31, the gradient filtering and aggregation algorithm is used. Based on the proportion of malicious gradients uploaded by sporadic adversaries and colluding adversaries, gradient filtering and aggregation are performed at the shard level, specifically including: S311: Input , , For each training node Calculate the remaining training nodes and Cosine similarity of the uploaded gradient ,Pick The maximum value is denoted as ; S312: For all Sort the array from smallest to largest ; S313: Effective cosine similarity array ; S314: For Each cosine similarity in Let its corresponding training node number be . Calculate the sum of effective gradients ; S315: Calculate the aggregation gradient at the piecewise level ; In step S33, the dual-filter algorithm Bipole adjusts the filtering ratio in each round of training. and Search and Filter out the effective gradients and aggregate them to obtain Specifically, it includes the following steps: S331: Input , , , , Specified step size for Initial reward value S332: Usage Ratio and Running Algorithm Perform gradient filtering and aggregation; S333: Update the model The accuracy of the updated model is evaluated, denoted as . ; S334: Will The value increases Rerun the algorithm ; S335: Obtain the model The accuracy of the test model is denoted as... ,judge: like Filtration ratio The reward value in the next round The next round will continue to increase. Explore the value; like Filtration ratio Reward value The next round of reduction The value is searched in the opposite direction. ; S336: hour Convergence, Output , ; S337: In the next round, the reward for the input is evaluated. If... Then output directly. , ; S338: When At that time, the current filtration ratio ; S339: When At that time, filtration ratio ; S3310: Filtration ratio for the next round from and Selected from; S3311: Output , , , .

Images