A blockchain-based federated learning model quality detection method

Abstract

The application discloses a kind of federal learning model quality detection methods based on blockchain, first model requester requester and model training party worker send identity identification to smart contract, requester builds Merkle Tree with test set, the root hash of Merkle Tree is sent to smart contract, worker builds Merkle Tree after training model with local data, the root hash of Merkle Tree is sent to smart contract, requester sends test set to worker, worker uses test set to test model and obtains output and corresponding proof, the root hash of Merkle Tree is sent to smart contract, output and model are sent to worker, if requester cannot provide the test result of model given by worker to smart contract after getting model does not meet requirements or evidence of proof error, smart contract will reward worker;If evidence can be provided that worker is evil, punish worker.This method can be combined with benefit distribution, and greatly save the computing resources and storage resources on the chain.

Description

Technical Field

[0001] This invention relates to the fields of federated learning, blockchain, cryptography, and incentives, and in particular to a blockchain-based method for quality detection of federated learning models. Background Technology

[0002] Currently, there are several solutions for auditing models or validating the quality of training data in federated learning, such as the Class-Sampled Validation Error Scheme (CSVES). This method is only for classification problems, where data is classified according to labels. The model trainer worker stores the local dataset's set of categories C. D The request is sent to the model requester, which retrieves the corresponding set C from the off-chain dataset. D The method involves generating a validation dataset and sending it to the worker. The worker trains the model locally, intermittently using the validation dataset and recording its errors. After training, the worker sends the model and the error sequence generated from the validation dataset to the requester. The requester can verify the quality of the worker-trained model or the worker's local data in two ways: first, by fitting the error sequence to a straight line and checking if the slope is negative; second, by checking if the last element of the error sequence is less than a certain threshold. This method has several problems: first, the worker could maliciously generate fake error sequences to deceive the requester; second, the entire method is not linked to an incentive / reward mechanism, lacking practical application value.

[0003] There are some solutions regarding fair model trading, such as having the worker send the entire trained model to the smart contract. However, this presents several problems: First, once the worker exposes the model to the requester, it becomes passive, with the requester having complete control over whether it receives payment. Second, on-chain storage and computation costs are too high, making it difficult to store the entire model on-chain in practice. Third, there is no clear method for judging the quality of the model; it is entirely up to the requester. Therefore, these problems cannot be solved by current technology. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a blockchain-based federated learning model quality detection method. This method aims to solve the problems of how the requester can detect the quality of models trained by the worker, and how to ensure fair model trading under the assumption that the requester wants to obtain models and the worker wants to receive rewards. Specifically, the worker cannot deceive the requester with inferior models to obtain rewards, and the requester cannot fail to provide rewards when it obtains high-quality models. This invention uses a smart contract on the blockchain as a decentralized, trusted third party. It divides the entire detection process into multiple stages using zero-knowledge proofs and cryptography, saving on-chain resource costs. Only O(1) data needs to be stored on the blockchain, and the computational time complexity of the smart contract is O(logn + logN), where n is the number of test points in the test set, and N is the size of the zero-knowledge proof circuit. Since our scheme uses zk-STARK for zero-knowledge proofs, verifying the correctness of a proof only requires O(logN) complexity.

[0005] The objective of this invention is achieved through the following technical solution: a blockchain-based federated learning model quality detection method, comprising the following steps:

[0006] A blockchain-based federated learning model quality detection method includes the following steps:

[0007] (1) The requester and the worker agree on the settings of the model to be trained and the optimizer;

[0008] (2) The requester and worker agree on the zero-knowledge proof circuit C. The logic of circuit C is to use the model parameters as private input, the test point data as public input, and the root of the Merkle Tree generated after encrypting the model parameters and the output of the model based on the test points as the output of circuit C.

[0009] (3) The requester and worker each generate a public-private key pair (sk r , pk r ), (sk w , pk w ), and pk the public key r , pk w Send to the smart contract;

[0010] (4) The requester and worker send their respective identity tokens to the smart contract;

[0011] (5) The requester encrypts the test set and uses the encrypted test set to build a Merkle Tree. It sends the root hash, initial settings and identity information of the Merkle Tree to the smart contract and sends the encrypted test set to the worker. The worker receives the encrypted test set and builds the corresponding Merkle Tree to verify whether the verification symbol does not conform to the Merkle Tree root hash on the chain.

[0012] (6) The worker obtains the encrypted test set and constructs the corresponding Merkle Tree verification symbol to check whether it conforms to the Merkle Tree root hash on the chain;

[0013] (7) The worker trains the model as agreed in step (1) and obtains the trained model. The trained model is encrypted and a Merkle Tree is built using the encrypted model. Each parameter in the model is used as a leaf node of the Merkle Tree. The root hash of the Merkle Tree is sent to the smart contract. (8) The worker obtains the private key of the requester, decrypts it to obtain the test set, and runs the dataset with the model trained in (5) to obtain the results and corresponding proofs. If the results do not meet the threshold specified by the requester, the protocol is terminated. Otherwise, the Merkle Tree is built using the results and proofs, and the root hash of the Merkle Tree is sent to the smart contract.

[0014] (9) The worker obtains the test set results and the encrypted model, constructs the corresponding Merkle Tree to verify whether the encrypted model conforms to the Merkle Tree root hash on the chain, and verifies the correctness of the results and whether they meet the requirements.

[0015] (10) The requester obtains the worker's private key, decrypts it to obtain the trained model in (7), and verifies the correctness of the model; the protocol ends.

[0016] The smart contract is specifically:

[0017] Initially, the smart contract's status is 0;

[0018] a. Receive and process request R(type, param), where type is the request type and param is the request parameters, specifically:

[0019] if Punish the requester and terminate the protocol;

[0020] If type ≠ status+1, penalize the requester and terminate the protocol;

[0021] Verify the validity of the parameter; if it fails, penalize the requester and terminate the protocol.

[0022] If param resolves to the instruction S for terminating the protocol, then the protocol is terminated.

[0023] If param is interpreted as a proof of dishonesty towards the other party (π) dishonest Processing π dishonest ;

[0024] Update status = status + 1;

[0025] b. Receive and process request W(type, param), specifically:

[0026] if Punish the worker and terminate the agreement;

[0027] If type ≠ status + 1, penalize the worker and terminate the agreement;

[0028] Verify the validity of the parameter; if it fails, penalize the worker and terminate the agreement.

[0029] If param resolves to S, the protocol is terminated.

[0030] If type = 5 and param is resolved to π dishonest Processing π dishonest ;

[0031] Update status = status + 1.

[0032] Furthermore, step (4) includes the following sub-steps:

[0033] (4.1) The requester sends R(1, id) to the smart contract. r ), where id r This serves as the identity identifier for the requester.

[0034] (4.2) The worker sends W(1, id) to the smart contract w ), where id w This serves as the identifier for the worker.

[0035] Furthermore, step (5) includes the following sub-steps:

[0036] (5.1) Requester calculates ET i =Enc(T i That is, for each test point T i Encrypt it into ETi ;

[0037] T i The value is encrypted.

[0038] (5.2) Using list {ET i Construct a Merkle Tree with root hash MR ET ;

[0039] (5.3) Send R(2, K, MR) to the smart contract ET K is the threshold number of test points that the worker's model needs to pass in the test set, and P is the predicate for determining whether the output of a model passes a test point.

[0040] Furthermore, step (6) includes the following sub-steps:

[0041] (6.1) The requester will {ET} i Send to worker;

[0042] (6.2) The worker uses {ET} i Construct a Merkle Tree with root hash MR′ ET ;

[0043] (6.3) If MR′ ET ≠MR ET Send W(3, S) to the smart contract if necessary, otherwise send W(3) to the smart contract.

[0044] Furthermore, step (7) includes the following sub-steps:

[0045] (7.1) The worker uses the model agreed upon in (1), or if there is no current model, it directly trains based on the local model to obtain a new model M;

[0046] (7.2) Calculate EM i =Enc(M i That is, for each model parameter M i Encrypt into EM i Finally, the ciphertext model {EM} is obtained. i};

[0047] (7.3) Using {EM i Construct a Merkle Tree with root hash MR EM ;

[0048] (7.4) The worker sends W(4, MR) to the smart contract EM ).

[0049] Furthermore, step (8) includes the following sub-steps:

[0050] (8.1) The requester will pass the private key sk r Send to the smart contract, the smart contract verifies sk r It's a PK r The private key;

[0051] (8.2) The worker receives the SK. r Decrypt {ET i}, thus obtaining {T i};

[0052] (8.3) Check {T i Is it legal?

[0053] (8.4) If invalid, send W(5, π) dishonest ) to the smart contract, where in For ET i With root MR ET Merkle proof in Merkle Tree;

[0054] (8.5) If valid, the worker runs the test set T locally, and the result is {a i}, and simultaneously generate zero-knowledge proofs {π} i Here, the zero-knowledge proof protocol zk-STARK is used;

[0055] (8.6) Calculate P i =P(s) i a i That is, using the predicate rule P in (5.3) and the true value s i Evaluate each result a i The evaluation result is P. i ,make If num < K, meaning no evaluation result has been reached and the threshold K has not been reached, send W(5, S) to the smart contract;

[0056] (8.7) Calculate P i hash h i , will {P i} converted to {h i P i};

[0057] (8.8) The worker uses {h i P iConstruct an Additional Merkle Tree with the root (AMR, num), where AMR is the root hash of the Additional Merkle Tree and num is the weight of the root.

[0058] (8.9) Worker Calculation That is, use result a i Proof of its calculation process π i By concatenating and encrypting the data, we obtain... use Construct a Merkle Tree. The root hash of the Merkle Tree is...

[0059] (8.10) worker will Send to the smart contract.

[0060] Furthermore, step (9) includes the following sub-steps:

[0061] (9.1) The worker will {h i P i}, {EM i}Send to requester;

[0062] (9.2) requester uses {h i P i Construct an Additional Merkle Tree with root (AMR′, num′);

[0063] (9.3) If AMR′≠AMR, the worker sends R(6,S) to the smart contract;

[0064] (9.4) requester Construct a Merkle Tree with the root hash as follows:

[0065] (9.5) If Send R(6, S) to the smart contract;

[0066] (9.6) The requester uses {EM i Construct a Merkle Tree with root hash MR′ EM ;

[0067] (9.7) If MR′ EM ≠MR EM Send R(6, S) to the smart contract;

[0068] (9.8) Requester Calculation

[0069] (9.9) If num′≠num, send R(6,π) dishonest ), where π dishonest =(2, h l h r ,num′), where h l h r The hashes of the left and right child nodes of the root of the Additional Merkle Tree are respectively.

[0070] (9.10) Otherwise, send R(6) to the smart contract.

[0071] Further, step (10) includes the following sub-steps:

[0072] (10.1) The worker will use sk w Send to the smart contract, the smart contract verifies sk w It's a PK w The private key;

[0073] (10.2) The requester gets the sk w , use sk w Decryption For {a i , π i}, decrypt {EM i} is {M i};

[0074] (10.3) Requester verification π i If it fails, send R(7, π). dishonest ) to the smart contract, where in for At the root Merkle proof in Merkle Tree.

[0075] Furthermore, step (2.6) in the smart contract includes the following sub-steps:

[0076] (2.6.1)π dishonest →(type π , param π );

[0077] (2.6.2) If Punish the requester and terminate the protocol;

[0078] (2.6.3) If type π=2, parsing param π For (h) l h r ,num′), where h l h is the hash of the left child of the root of the Additional MerkleTree. r For the hash of the root's right child, verify H(h) l ||h r ||num′)=AMR, where || represents concatenation. If the concatenation fails, penalize the requester; otherwise, if num′≠num, penalize the worker; otherwise, if num<K, penalize the worker; otherwise, penalize the requester and terminate the protocol.

[0079] (2.6.4) If type π =3, parsing param π for verify If the request fails, penalize the requester and terminate the protocol; if it succeeds, use sk. w Decryption Get a i , π i Verify π i If successful, penalize the requester and terminate the protocol; otherwise, penalize the worker and terminate the protocol.

[0080] Furthermore, step (3.5) in the smart contract includes the following sub-steps:

[0081] (3.5.1)

[0082] (3.5.2) Smart Contract Verification

[0083] (3.5.4) If the request fails, penalize the worker and terminate the agreement;

[0084] (3.5.4) Otherwise, use sk r Decrypting ET i Get T i Check T i The legitimacy;

[0085] (3.5.5) If illegal, punish the worker and terminate the agreement;

[0086] (3.5.6) Otherwise, penalize the requester and terminate the protocol.

[0087] The beneficial effects of this invention are:

[0088] 1. Decentralized testing and transaction processes;

[0089] 2. The requester can evaluate the quality of the model trained by the worker.

[0090] 3. The requester and worker can distribute benefits fairly based on the model's detection results. Attached Figure Description

[0091] Figure 1 This is a flowchart of the first-stage interaction between the model requester and the model trainer worker.

[0092] Figure 2 This is a flowchart illustrating the second-stage interaction between the model requester and the model trainer worker.

[0093] Figure 3 This is a flowchart of the third-stage interaction between the model requester and the model trainer worker.

[0094] Figure 4 This is a flowchart illustrating the fourth stage of interaction between the model requester and the model trainer worker.

[0095] Figure 5 A flowchart for handling requester requests for smart contracts;

[0096] Figure 6 A flowchart for handling worker requests for smart contracts;

[0097] Figure 7 This is a schematic diagram of an addition Merkle tree. Detailed Implementation

[0098] I. For example Figure 1 As shown, the model requester and the model trainer are:

[0099] (1) The requester and the worker agree on the settings of the model to be trained and the optimizer;

[0100] (2) The requester and worker agree on the zero-knowledge proof circuit C. The logic of circuit C is to use the model parameters as private inputs, the test point data as public inputs, and the root of the Merkle Tree generated after encrypting the model parameters and the output of the model based on the test points as the output of circuit C.

[0101] (3) The requester and worker each generate a public-private key pair (sk r , pk r ), (sk w , pk w ), and pk the public key r , pk w Send to the smart contract;

[0102] (4) The requester and worker send their respective identity identifiers to the smart contract, which includes the following sub-steps:

[0103] (4.1) The requester sends R(1, id) to the smart contract. r ), where id r This serves as the identity identifier for the requester.

[0104] (4.2) The worker sends W(1, id) to the smart contract w ), where id w This serves as the identifier for the worker.

[0105] (5) The requester encrypts the test set and uses the encrypted test set to build a Merkle Tree. The root hash, initial settings, and identity information of the Merkle Tree are sent to the smart contract, and the encrypted test set is sent to the worker. This includes the following sub-steps:

[0106] (5.1) The requester encrypts each test point and calculates ET. i =Enc(T i That is, for each

[0107] Test point T i Encrypt it into; ET i ;T i The value is encrypted.

[0108] (5.2) Using {ET i Construct a Merkle Tree with root hash MR ET ;

[0109] (5.3) Send R(2, id) to the smart contract r K, MR ET ,P),id r K is the identity identifier of the requester, K is the threshold number of test points the worker's model needs to pass in the test set, and P is the predicate for determining whether the output of a model passes a test point.

[0110] (5.4) The requester sends the encrypted test set to the worker;

[0111] (6) The worker receives the encrypted test set and constructs the corresponding Merkle Tree to verify whether the verification symbol matches the Merkle Tree root hash on the chain, such as... Figure 2 As shown, the specific steps include the following:

[0112] (6.1) The requester will {ET} i Send to worker;

[0113] (6.2) The worker uses {ET} i Construct a Merkle Tree with root hash MR′ ET ;

[0114] (6.3) If MR′ ET ≠MR ET Send W(3, S) to the smart contract if necessary, otherwise send W(3) to the smart contract; S is the instruction to terminate the protocol.

[0115] (7) The worker trains the model agreed upon in (1), encrypts the trained model, and constructs a Merkle Tree using the encrypted model (with each parameter in the model as a leaf node of the Merkle Tree). The root hash of the Merkle Tree is then sent to the smart contract. This process includes the following sub-steps:

[0116] (7.1) The worker uses the model agreed in (1), or if there is no current model, it directly trains based on the local model to obtain a new model M;

[0117] (7.2) Calculate EM i =Enc(M i That is, for each model parameter M i Encrypt into EM i Finally, the ciphertext model {EM} is obtained. i};

[0118] (7.3) Using {EM i Construct a Merkle Tree with root hash MR EM ;

[0119] (7.4) The worker sends W(4, MR) to the smart contract EM );

[0120] (8) The worker obtains the requester's private key, decrypts it to get the test set, and runs the trained model on the dataset to obtain the results and corresponding proofs. If the results do not meet the threshold specified by the requester, the protocol ends; otherwise, it constructs a Merkle Tree using the results and proofs, and sends the root hash of the Merkle Tree to the smart contract, such as... Figure 3 As shown, the specific steps include the following:

[0121] (8.1) The requester will pass the private key sk r Send to the smart contract, the smart contract verifies sk r It's a PK r The private key;

[0122] (8.2) The worker receives the SK. r Decrypting {ET i}, thus obtaining {T i};

[0123] (8.3) Check {T i Is it legal?

[0124] (8.4) If invalid, send W(5, π) dishonest ) to the smart contract, where in For ET i With root MR ET Merkle proof in Merkle Tree;

[0125] (8.5) If valid, the worker runs the test set T locally, and the result is {a i}, and simultaneously generate zero-knowledge proofs {π} i Here, the zero-knowledge proof protocol zk-STARK is used;

[0126] (8.6) Calculate P i =P(s) i a i That is, using the predicate rule P in (5.3) and the true value s i Evaluate each result a i The evaluation result is P. i ,make If num < K, meaning no evaluation result has been reached and the threshold K has not been reached, send W(5, S) to the smart contract;

[0127] (8.7) Calculate P i hash h i , will {P i} converted to {h iP i};

[0128] (8.8) The worker uses {h i P i Construct an Addition Merkle Tree. The Addition Merkle Tree structure is as follows: Figure 7 As shown, the root is (AMR, num), where AMR is the root hash of the Additional Merkle Tree and num is the weight of the root.

[0129] (8.9) Worker Calculation That is, use result a i Proof of its calculation process π i By concatenating and encrypting the data, we obtain... use Construct a Merkle Tree. The root hash of the Merkle Tree is...

[0130] (8.10) worker will Send to the smart contract;

[0131] (9) The worker receives the test set results and the encrypted model, constructs the corresponding Merkle Tree, verifies whether the encrypted model conforms to the Merkle Tree root hash on the chain, and verifies the correctness and whether the results meet the requirements, such as... Figure 4 As shown, the specific steps include the following:

[0132] (9.1) The worker will {h i P i}, {EM i}Send to requester;

[0133] (9.2) requester uses {h i P i Construct an Additional Merkle Tree with root (AMR′, num′);

[0134] (9.3) If AMR′≠AMR, the worker sends R(6, S) to the smart contract;

[0135] (9.4) requester Construct a Merkle Tree with the root hash as follows:

[0136] (9.5) If Send R(6, S) to the smart contract;

[0137] (9.6) The requester uses {EM} i Construct a Merkle Tree with root hash MR′ EM ;

[0138] (9.7) If MR′ EM ≠MR EM Send R(6, S) to the smart contract;

[0139] (9.8) Requester Calculation

[0140] (9.9) If num′≠num, send R(6,π) dishonest ), where π dishonest =(2, h l h r ,num′), where h l h r The hashes of the left and right child nodes of the root of the Additional Merkle Tree are respectively.

[0141] (9.10) Otherwise, send R(6) to the smart contract;

[0142] (10) The requester obtains the worker's private key, decrypts it to get the trained model from (7), and verifies the correctness of the model, which includes the following sub-steps:

[0143] (10.1) The worker will use sk w Send to the smart contract, the smart contract verifies sk w It's a PK w The private key;

[0144] (10.2) The requester gets the sk w , use sk w Decryption For {a i , π i}, decrypt (EM) i} is (M i};

[0145] (10.3) Requester verification π i If it fails, send R(7, π). dishonest ) to the smart contract, where in for At the root Merkle proof in Merkle Tree;

[0146] (11) The agreement ends.

[0147] The smart contract:

[0148] (1) In the initial state, the status of the smart contract is 0;

[0149] (2) Receive and process request R(type, param), where type is the request type and param is the request parameters, such as... Figure 5 As shown, the specific steps include the following:

[0150] (2.1) If Punish the requester and terminate the agreement;

[0151] (2.2) If type ≠ status + 1, penalize the requester and terminate the protocol;

[0152] (2.3) Verify the validity of param. If it fails, penalize the requester and terminate the protocol.

[0153] (2.5) If param is resolved to the instruction S for terminating the protocol, terminate the protocol;

[0154] (2.6) If param is parsed as a proof of dishonesty towards the other party, π dishonest Processing π dishonest Specifically, it includes the following sub-steps:

[0155] (2.6.1)π dishonest →(type π , param π );

[0156] (2.6.2) If The requester's deposit will be deducted, and the agreement will be terminated.

[0157] (2.6.3) If type π =2, parsing param π For (h) l h r ,num′),,where h l h is the hash of the left child of the root of the Additional MerkleTree. r Verify H(h) as the hash of the root's right child. l ||h r||num′)=AMR,, where || represents concatenation. If it fails, penalize the requester; otherwise, if num′≠num, penalize the worker; otherwise, if num<K, penalize the worker; otherwise, penalize the requester and terminate the protocol.

[0158] (2.6.4) If type π =3, parsing param π for verify If the request fails, penalize the requester and terminate the protocol; if it succeeds, use sk. w Decryption Get a i , π i Verify π i If successful, penalize the requester and terminate the protocol; otherwise, penalize the worker and terminate the protocol.

[0159] (2.7) Update status = status + 1;

[0160] (3) Receive and process request W(type, param), such as Figure 6 As shown, the specific steps include the following:

[0161] (3.1) If Punish the worker and terminate the agreement;

[0162] (3.2) If type ≠ status + 1, penalize the worker and terminate the protocol;

[0163] (3.3) Verify the validity of param. If it fails, penalize the worker and terminate the protocol.

[0164] (3.4) If param resolves to S, terminate the protocol;

[0165] (3.5) If type = 5 and param is resolved to π dishonest Processing π dishonest Specifically, it includes the following sub-steps:

[0166] (3.5.1)

[0167] (3.5.2) Smart Contract Verification

[0168] (3.5.4) If the request fails, penalize the worker and terminate the agreement;

[0169] (3.5.4) Otherwise, use skr Decrypting ET i Get T i Check T i The legitimacy;

[0170] (3.5.5) If illegal, punish the worker and terminate the agreement.

[0171] (3.5.6) Otherwise, penalize the requester and terminate the protocol;

[0172] (3.6) Update status = status + 1.

[0173] Finally, it should be noted that the above examples are merely specific embodiments of the present invention. Obviously, the present invention is not limited to the above embodiments. All modifications that can be directly derived or conceived by those skilled in the art from the disclosure of the present invention are considered to be within the scope of protection of the present invention.

Claims

1. A method for quality detection of a blockchain-based federated learning model, characterized in that, Includes the following steps: (1) The requester and the worker agree on the settings of the model to be trained and the optimizer; (2) The requester and worker agree on the zero-knowledge proof circuit C. The logic of circuit C is to use the model parameters as private input, the test point data as public input, and the root of the Merkle Tree generated after encrypting the model parameters and the output of the model based on the test points as the output of circuit C. (3) The requester and worker each generate a public-private key pair (sk r , pk r ), (sk w , pk w ), and pk the public key r , pk w Send to the smart contract; (4) The requester and worker send their respective identity tokens to the smart contract; (5) The requester encrypts the test set and uses the encrypted test set to build a Merkle Tree. It sends the root hash, initial settings and identity information of the Merkle Tree to the smart contract and sends the encrypted test set to the worker. The worker receives the encrypted test set and builds the corresponding Merkle Tree to verify whether the verification symbol does not match the root hash of the Merkle Tree on the chain. (6) The worker obtains the encrypted test set and constructs the corresponding Merkle Tree to verify whether the Merkle Tree root hash on the chain is true; (7) The worker trains the model as agreed in step (1) and obtains the trained model. The trained model is encrypted and a Merkle Tree is built using the encrypted model. Each parameter in the model is used as a leaf node of the Merkle Tree. The root hash of the Merkle Tree is sent to the smart contract. (8) The worker obtains the private key of the requester, decrypts it to obtain the test set, and runs the dataset with the model trained in (5) to obtain the results and corresponding proofs. If the results do not meet the threshold specified by the requester, the protocol is terminated. Otherwise, the Merkle Tree is built using the results and proofs, and the root hash of the Merkle Tree is sent to the smart contract. (9) The worker obtains the test set results and the encrypted model, constructs the corresponding Merkle Tree to verify whether the encrypted model conforms to the Merkle Tree root hash on the chain, and verifies the correctness of the results and whether they meet the requirements. (10) The requester obtains the worker's private key, decrypts it to obtain the trained model in (7), and verifies the correctness of the model; the protocol ends. The smart contract is specifically: Initially, the smart contract's status is 0; a. Receive and process request R(type, parm), where type is the request type and param is the request parameters, specifically: if Punish the requester and terminate the protocol; If type ≠ status+1, penalize the requester and terminate the protocol; Verify the validity of the parameter; if it fails, penalize the requester and terminate the protocol. If param resolves to the instruction S for terminating the protocol, then the protocol is terminated. If param is interpreted as a proof of dishonesty towards the other party (π) dishonest Processing π dishonest ; Update status = status + 1; b. Receive and process request W(type, param), specifically: if Punish the worker and terminate the agreement; If type ≠ status + 1, penalize the worker and terminate the agreement; Verify the validity of the parameter; if it fails, penalize the worker and terminate the agreement. If param resolves to S, the protocol is terminated. If type = 5 and param is resolved to π dishonest Processing π dishonest ; Update status = status + 1.

2. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (4) includes the following sub-steps: (4.1) The requester sends R(1, id) to the smart contract. r ), where id r This serves as the identity identifier for the requester. (4.2) The worker sends W(1, id) to the smart contract w ), where id w This serves as the identifier for the worker.

3. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (5) includes the following sub-steps: (5.1) Requester calculates ET i =Enc(T i That is, for each test point T i Encrypt it into ET i ;T i The value is encrypted. (5.2) Using list {ET i Construct a Merkle Tree with root hash MR ET ; (5.3) Send R(2, K, MR) to the smart contract ET K is the threshold number of test points that the worker's model needs to pass in the test set, and P is the predicate for determining whether the output of a model passes a test point.

4. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (6) includes the following sub-steps: (6.1) The requester will {ET} i Send to worker; (6.2) The worker uses {ET} i Construct a Merkle Tree with root hash MR′ ET ; (6.3) If MR′ ET ≠MR ET Send W(3, S) to the smart contract if necessary, otherwise send W(3) to the smart contract.

5. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (7) includes the following sub-steps: (7.1) The worker uses the model agreed upon in (1), or if there is no current model, it directly trains based on the local model to obtain a new model M; (7.2) Calculate EM i =Enc(M i That is, for each model parameter M i Encrypt into EM i Finally, the ciphertext model {EM} is obtained. i }; ( 7.3) Using {EM i Construct a Merkle Tree with root hash MR EM ; (7.4) The worker sends W(4, MR) to the smart contract EM ).

6. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (8) includes the following sub-steps: (8.1) The requester will pass the private key sk r Send to the smart contract, the smart contract verifies sk r It's a PK r The private key; (8.2) The worker receives the SK. r Decrypt {ET i }, thus obtaining {T i }; ( 8.3) Check {T i Is it legal? (8.4) If invalid, send W(5, π) dishonest ) to the smart contract, where in For ET i With root MR ET Merkle proof in Merkle Tree; (8.5) If valid, the worker runs the test set T locally, and the result is {a i }, and simultaneously generate zero-knowledge proofs {π} i Here, the zero-knowledge proof protocol zk-STARK is used; (8.6) Calculate P i =P(s) i a i That is, using the predicate rule P in (5.3) and the true value s i Evaluate each result a i The evaluation result is P. i ,make If num < K, meaning no evaluation result has been reached and the threshold K has not been reached, send W(5, S) to the smart contract; (8.7) Calculate P i hash h i , will {P i } converted to {h i P i }; ( 8.8) The worker uses {h i P i Construct an Additional Merkle Tree with the root (AMR, num), where AMR is the root hash of the Additional Merkle Tree and num is the weight of the root. (8.9) Worker Calculation That is, use result a i Proof of its calculation process π i By concatenating and encrypting the data, we obtain... use Construct a Merkle Tree. The root hash of the Merkle Tree is... (8.10) worker will Send to the smart contract.

7. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (9) includes the following sub-steps: (9.1) worker will Send to requester; (9.2) requester uses {h i P i Construct an Additional Merkle Tree with root (AMR′, num′); (9.3) If AMR′≠AMR, the worker sends R(6,S) to the smart contract; (9.4) requester Construct a Merkle Tree with the root hash as follows: (9.5) If Send R(6, S) to the smart contract; (9.6) The requester uses {EM i Construct a Merkle Tree with root hash AR′ EM ; (9.7) If MR′ EM ≠MR EM Send R(6, S) to the smart contract; (9.8) Requester Calculation (9.9) If numAMR′≠num, send R(6,π) dishonest ), where π dishonest =(2, h l h r ,num′), where h l h r The hashes of the left and right child nodes of the root of the Additional Merkle Tree are respectively. (9.10) Otherwise, send R(6) to the smart contract.

8. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (10) includes the following sub-steps: (10.1) The worker will use sk w Send to the smart contract, the smart contract verifies sk w It's a PK w The private key; (10.2) The requester gets the sk w , use sk w Decryption For {a i , π i }, decrypt {EM i } is {M i }; (10.3) Requester verification π i If it fails, send R(7, π). dishonest ) to the smart contract, where in for At the root Merkle proof in Merkle Tree.

9. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (2.6) in the smart contract includes the following sub-steps: (2.6.1)π dishonest →(type π ,param π ); (2.6.2) If Punish the requester and terminate the protocol; (2.6.3) If type π =2, parsing param π For (h) l h r ,num′), where h l h is the hash of the left child of the root of the Additional Merkle Tree. r For the hash of the root's right child, verify H(h) l ||h r ||num′)=AMR, where || represents concatenation. If the concatenation fails, penalize the requester; otherwise, if num′≠num, penalize the worker; otherwise, if num<K, penalize the worker; otherwise, penalize the requester and terminate the protocol. (2.6.4) If type π =3, parsing param π for verify If the request fails, penalize the requester and terminate the protocol; if it succeeds, use sk. w Decryption Get a i , π i Verify π i If successful, penalize the requester and terminate the protocol; otherwise, penalize the worker and terminate the protocol.

10. The method for quality detection of a blockchain-based federated learning model according to claim 1, characterized in that, Step (3.5) in the smart contract includes the following sub-steps: (3.5.1) (3.5.2) Smart Contract Verification (3.5.4) If the request fails, penalize the worker and terminate the agreement; (3.5.4) Otherwise, use sk r Decrypting ET i Get T i Check T i The legitimacy; (3.5.5) If illegal, punish the worker and terminate the agreement; (3.5.6) Otherwise, penalize the requester and terminate the protocol.

Images