A cross-nuclear power plant commissioning personnel capability joint evaluation and authorization mutual recognition system and method based on federated learning and differential privacy
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-27
- Publication Date
- 2026-08-11
AI Technical Summary
现有技术缺乏一种可数学验证、不泄露具体培训细节的授权互认机制
1、跨企业联合能力评估从无到有:首次实现了多个核电集团在不共享敏感数据的情况下,联合训练调试人员能力评估模型。通过联邦学习框架,全局模型在跨电厂测试集上准确率相比单电厂本地模型提升15%-25%,为行业级人才评价体系奠定技术基础。
Smart Images

Figure CN122549987A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of nuclear power digital management technology, specifically involving a joint assessment and authorization mutual recognition system and method for the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy. Background Technology
[0002] With the continued growth of the global economy and the increasing population, energy demand continues to rise. Traditional fossil fuels such as coal, oil, and natural gas produce large amounts of greenhouse gases and pollutants, including carbon dioxide, sulfur oxides, and nitrogen oxides, during combustion, causing serious environmental impacts. To address global climate change and environmental pollution, countries are actively seeking clean and efficient energy alternatives, making nuclear power an important strategic choice.
[0003] The entire lifecycle of a nuclear power plant mainly consists of two phases: the commissioning phase and the production phase. The commissioning phase is a crucial stage after construction and before commercial operation. Its primary purpose is to verify whether the performance and functionality of the plant's various systems and equipment meet design requirements and to ensure the safe and stable operation of the plant. With the rapid development of the nuclear power industry, the number of new and retrofitted nuclear power units is increasing. As a critical stage in the transition from construction to operation, the commissioning phase has extremely high requirements for safety and compliance.
[0004] The commissioning period involves numerous complex system integration tests, equipment verifications, and emergency response drills. To ensure nuclear power production safety, all personnel working at the power plant must undergo rigorous pre-job training, examinations, and authorization application processes, possessing strict qualification certifications and professional skills before being allowed to work. Therefore, any user on duty during the commissioning period must pass training and examinations and apply for authorization before using the production management system. Only after authorization is approved can they obtain access to other functional modules.
[0005] Currently, there are three main models for the authorization management of commissioning training in nuclear power plants, each with its own obvious shortcomings: 1. Traditional manual management model; This model, which relies on paper-based records and manual review, has the following problems: In terms of cost: the initial investment is low, but the maintenance costs in the middle and later stages are high, and the long-term preservation cost of paper archives is huge. In terms of security: security is low; paper records are easily lost, damaged, or leaked. In terms of standardization: the level of standardization is low, paper archives are difficult to manage in a standardized manner, and different power plants have different formats; In terms of management efficiency: The management efficiency is low, and the paper-based file and manual review model is adopted. The authorization process is time-consuming, inefficient, and prone to omissions and loss. Technical support: No professional technical support is required, but it is highly dependent on manual operation; In terms of operational difficulty: it is simple to operate when the data volume is low, but complex when the data volume is high, and it relies entirely on manual operation. Regarding issue tracing: Issue tracing is very difficult, as nuclear power plants have a lifespan of more than 60 years, and it is extremely difficult to retain paper records for a long period of time.
[0006] 2. International digital system management models; Some nuclear power plants use digital systems developed by foreign manufacturers for commissioning, training, and authorization management, but the following problems still exist: In terms of costs: procurement and maintenance costs are high, and the costs of foreign software licenses and subsequent upgrades are huge; In terms of security: the security is low, the data relies on foreign systems, and there are risks of data leakage and supply chain security. In terms of standardization: the degree of standardization is low, each power plant uses different manufacturers' systems, and the data during the commissioning period and the production period are independent, making it difficult to achieve standardized management; In terms of management efficiency: management efficiency is low, relying on existing system standards, and it is difficult to meet the complex and ever-changing business needs on site; In terms of technical support: reliance on foreign suppliers, untimely technical support response, and the risk of being "strangled" by them; In terms of operational difficulty: the system is relatively complex and requires professional technical support; Regarding issue tracing: Issue tracing is difficult, as training records and authorization records are scattered and stored in different systems.
[0007] 3. Preliminary plan for domestically produced system; The initial versions of existing domestically developed systems and the management models commonly used in the industry have not yet solved the following core technical problems: The challenges of data silos and joint assessment across nuclear power plants. Different nuclear power plants each have their own independent commissioning personnel training and authorization management systems. When personnel move between power plants, mutual recognition of qualifications is required. However, because the operational data of each power plant (such as work order completion quality, anomaly handling records, operation time, etc.) involves trade secrets and personal privacy, it cannot be directly shared with a centralized platform. How to achieve joint modeling and capability assessment across power plants without data leaving the plant's domain (i.e., without data leaving the local area of each power plant) is a pressing technical problem that needs to be solved.
[0008] Privacy and anti-counterfeiting challenges in cross-power plant authorization and mutual recognition. When personnel from one power plant are transferred to another, they need to provide authorization certificates from the original power plant. Traditional methods rely on paper certificates or PDF scans, which are easy to forge and difficult to verify. Even with centralized digital certificates, there is a single point of trust risk; if the centralized institution is compromised or used maliciously, the entire mutual recognition system will fail. Current technology lacks a mathematically verifiable authorization and mutual recognition mechanism that does not disclose specific training details. How to utilize cryptographic technology to achieve privacy protection and anti-counterfeiting in cross-power plant authorization and mutual recognition is another key technical challenge. Summary of the Invention
[0009] The purpose of this invention is to provide a joint assessment and authorization mutual recognition system and method for the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy. While retaining the basic functions such as course maintenance, job course configuration, and authorization application approval, it introduces federated learning, differential privacy, zero-knowledge proof, and consortium blockchain technologies to solve three core technical challenges: data silos across nuclear power plants, privacy protection, and anti-counterfeiting of authorization mutual recognition. It achieves joint capability assessment without data leaving the domain, mathematically verifiable privacy-protected authorization mutual recognition, and tamper-proof audit evidence storage.
[0010] To achieve the above objectives, this application proposes a joint assessment and authorization mutual recognition system for commissioning personnel capabilities across nuclear power plants based on federated learning and differential privacy, including: The local proficiency assessment model module is deployed locally at each nuclear power plant. It is used to train a proficiency assessment model based on the plant's operation behavior log data and output the personnel proficiency level and confidence level. The federated learning aggregation server module, deployed by a third party, is used to receive encrypted parameter updates from the local models of each nuclear power plant, generate a global model through an improved federated averaging algorithm, and distribute it back to each nuclear power plant. The zero-knowledge authorization proof generation and verification module is used when personnel move between nuclear power plants. The original nuclear power plant system generates a zero-knowledge proof, and the target nuclear power plant verifies the mathematical validity of the proof to recognize the qualification. The smart contract mutual recognition chain module is used to store the hash digest of authorized mutual recognition on the chain, forming an immutable mutual recognition record.
[0011] As an improvement to the above system, the local proficiency evaluation model adopts a hidden Markov model or a temporal neural network. Input features include time consumption ratio, number of assistance requests, error rate, rework rate, exception handling response time, and work order completion quality score; The output hidden state is high proficiency, medium proficiency, or low proficiency.
[0012] As an improvement to the above system, the federated learning aggregation server module includes: The differential privacy noise injection unit is used to add random noise that follows a Laplace or Gaussian distribution before the parameter update is uploaded. The amount of noise is dynamically adjusted by the differential privacy scheduler according to the current privacy consumption. The secure aggregation unit, deployed in a trusted execution environment, is used to decrypt encrypted parameters and perform weighted average aggregation. An abnormal node detection unit is used to identify poisoning parameters uploaded by malicious nuclear power plants based on geometric median or cosine similarity.
[0013] As an improvement to the above system, the zero-knowledge authorization proof generation and verification module adopts the zk-SNARKs protocol; Public inputs include the person's ID hash, authorization level, and validity period; Private witnesses include a course list, course grades, training timestamps, and the approver's digital signature; The circuit logic verifies identity matching, course completeness, passing grades, time validity, and approval legitimacy.
[0014] As an improvement to the above system, the smart contract mutual recognition chain module adopts a consortium blockchain architecture and includes three smart contract functions: recording mutual recognition events, querying mutual recognition history, and revoking authorization. The on-chain content includes the mutual recognition event ID, the original power plant ID, the target power plant ID, the personnel ID hash, the authorization level, the zero-knowledge proof hash value, the verification result, and the timestamp.
[0015] This application also provides a method for joint assessment and authorization mutual recognition of the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy, implemented based on the aforementioned system, including: Step 1: Each nuclear power plant locally trains its proficiency assessment model to obtain local parameter updates; Step 2: Add differential privacy noise to the local parameter update, encrypt it using the national cryptographic SM2 algorithm, and then upload it to the federated aggregation server; Step 3: The federated aggregation server decrypts and executes the weighted average aggregation in a trusted execution environment to generate global model parameters; Step 4: Encrypt and distribute the global model parameters back to each nuclear power plant to replace the local model; Step 5: When personnel move between nuclear power plants, the original nuclear power plant generates zero-knowledge proofs based on the personnel's training authorization records; Step 6: The target nuclear power plant verifies the mathematical validity of the zero-knowledge proof. If the verification is successful, its qualification is recognized. Step 7: Upload the hash digest of the authorized mutual recognition event to the blockchain for evidence storage.
[0016] As an improvement to the above method, the differential privacy noise injection in step 2 adopts an adaptive privacy budget allocation strategy. A larger privacy budget is used in the early stage of training, and the privacy budget is gradually reduced as training progresses. Furthermore, sparse vector technology is used to add noise only to important parameter updates.
[0017] As an improvement to the above method, the zero-knowledge proof generation in step 5 adopts the Plonk protocol, compiles the training authorization rules into arithmetic circuits through hierarchical circuit design and lookup table optimization, and uses distributed proof generation to control the proof generation time to the second level.
[0018] As an improvement to the above method, the consortium blockchain in step 7 adopts a layered PBFT or HotStuff consensus algorithm, dividing nodes into a core layer and a participation layer; the core layer is responsible for final consensus, and the participation layer is responsible for transaction endorsement and verification.
[0019] Compared with existing technologies, the advantages of this application are: 1. Cross-enterprise joint capability assessment from scratch: For the first time, multiple nuclear power groups were able to jointly train a capability assessment model for commissioning personnel without sharing sensitive data. Through a federated learning framework, the global model achieved a 15%-25% improvement in accuracy on cross-power plant test sets compared to a single-power plant local model, laying the technical foundation for an industry-level talent evaluation system.
[0020] 2. Authorization and mutual recognition security level reaches cryptographic proof level: The introduction of zero-knowledge proof technology upgrades authorization and mutual recognition from a "trusted third party" model to a "trustless" mathematical verification model. zk-SNARKs proofs are unforgeable. Any attacker attempting to forge a proof must solve a computationally difficult discrete logarithm problem or a difficult problem on an elliptic curve, which is infeasible under real-world computing resources, thus completely eliminating the risk of certificate forgery.
[0021] 3. Balancing Privacy Protection and Model Performance: Through joint optimization of differential privacy and federated learning, a strong privacy protection level of ε=0.5 (meeting medical / nuclear industry-grade privacy standards) is achieved with a model accuracy loss of less than 3%. Adaptive privacy budget allocation and sparse vector techniques are employed to maximize model utility while ensuring privacy.
[0022] 4. Reduce personnel mobility management costs: The time for cross-power plant mutual recognition is shortened from several days in the traditional model (telephone verification, mailing of paper materials, and manual review) to minutes (automatic certificate generation and verification), and no manual telephone verification is required. Based on 1,000 personnel moving between power plants per year, this can save the industry thousands of person-hours in management costs.
[0023] 5. Meets nuclear safety regulatory requirements: The consortium blockchain ensures the transparency and non-repudiation of mutual recognition activities. All authorized mutual recognition records are traceable and auditable, meeting nuclear safety regulatory requirements. The zero-knowledge proof's principle of minimum disclosure ensures that unnecessary privacy information is not leaked during the audit process. Attached Figure Description
[0024] Figure 1 The diagram shows the system architecture for joint assessment and authorization mutual recognition of the capabilities of commissioning personnel across nuclear power plants, based on federated learning and differential privacy. Detailed Implementation
[0025] The technical solution of this application will be described in detail below with reference to the accompanying drawings.
[0026] Example 1 The cross-nuclear power plant commissioning personnel competence joint assessment and authorization mutual recognition system provided in this application, based on federated learning and differential privacy, adopts a dual-drive architecture of "federated learning + blockchain", including a local proficiency assessment model, a federated learning aggregation server, a zero-knowledge authorization proof generation and verification module, and a smart contract mutual recognition chain.
[0027] 1. Local proficiency assessment model; Each nuclear power plant locally deploys a proficiency assessment model based on a Hidden Markov Model (HMM) or a Long Short-Term Memory (LSTM) neural network, which is trained using the plant's operational behavior log data to output the proficiency level (high / medium / low) and confidence level of personnel.
[0028] The local proficiency assessment model is illustrated using HMM as an example: Each power plant independently trains an HMM model for its local system to assess the operational proficiency of its personnel.
[0029] 1) The model input features include: Operational behavior feature vector, including: Time-to-operation ratio: The ratio of actual operation time to standard operation time; Number of times assistance was requested: the number of times assistance was requested or procedures were consulted during the operation; Error rate: The percentage of errors in a single operation step out of the total number of steps. Rework rate: The number of times rework is caused by improper operation; Exception handling response time: The time interval from the occurrence of an exception to the correct response; Work order completion quality rating: The quality level determined by the work supervisor or automatically by the system.
[0030] 2) Model output includes: The hidden state sequence is defined as having three proficiency levels: High proficiency: Able to independently complete complex operations and has strong exception handling capabilities; Medium proficiency: Able to perform routine operations, occasionally requiring assistance; Low proficiency: The operator is not proficient and requires close supervision.
[0031] 3) Training algorithm; The Baum-Welch algorithm (forward-backward algorithm) is used for parameter estimation, and the model parameters are iteratively optimized through Expectation-Maximization (EM). The training process is entirely local, without involving cross-power plant data sharing. This model serves as the foundational model for subsequent federated learning tasks, providing initial parameters and a local loss function.
[0032] Detailed description of the model structure: The Hidden Markov Model (HMM) is defined by the following quintuple: The set of states S = {S1(high), S2(medium), S3(low)}; Observation set O = {O1, O2, ..., O M}, where M is the number of discretized observation feature dimensions; State transition probability matrix A = [a ij ], where a ij = P(q t+1 = S j | q t = S i ); Observation probability matrix B = [b j(k) ], where b j(k) = P(O k | q t = S j ); Initial state probability distribution π = [π i ], where π i = P(q1= S i ).
[0033] During training, for each operator, the observation sequence O = (O t1 O t2 , ..., O tT The parameters λ = (A, B, π) are iteratively updated using the Baum-Welch algorithm until convergence.
[0034] 2. Federated learning aggregation server; Deployed by a third party, this system coordinates the participation of various power plants in joint training. Each power plant uploads encrypted parameter updates (not raw data) of its local model to the aggregation server. The server then uses an improved federated averaging algorithm (FedAvg) to generate a global model, which is then distributed back to the power plants. Differential privacy technology protects individual information throughout the process. Without sharing raw operation logs, data from multiple power plants is combined to train a more robust and generalizable proficiency assessment model. This model is used to evaluate the initial capabilities of personnel moving between power plants, avoiding inaccurate assessments caused by biases in data from a single power plant.
[0035] The specific implementation steps include: Step 1: Local Training Suppose there are K nuclear power plants participating in federated learning, and each plant k has a local dataset D. k = {(x i , y i )}, where x i For the sequence of operational behavior features, y i For proficiency labels. Local model parameters θ k By minimizing the local loss function L k (θ k ) get: in, Indicates power plant k The local loss function value measures the difference between the model's prediction and the true label; k Indicates the power plant index. k=1,2,…,K,K The total number of power plants participating in federal learning; Indicates power plant k Local model parameters, such as the state transition matrix and observation probability matrix of the HMM; Indicates power plant k The number of local training samples; i Indicates the sample index. i=1,2,…, ; Indicates the first i The operational behavior feature sequence of each sample, including time consumption ratio, number of auxiliary attempts, error rate, etc. Indicates the first i The proficiency labels for each sample are set to {high, medium, low}. The loss function is represented by Cross-Entropy Loss, which measures the difference between the predicted probability distribution and the true label. This represents the model's prediction function, which outputs the probability distribution of proficiency levels. This represents the regularization coefficient, which controls the strength of the regularization term and prevents the model from overfitting. This indicates a regularization term, using L2 regularization.
[0036] In this round of iterations, power plants k Train for E epochs using local data, and obtain the parameter update amount using stochastic gradient descent (SGD) or the Adam optimizer: Step 2: Differential privacy noise injection To prevent the leakage of individual information through parameters, each power plant sends... Previously, random noise was added to it. Specifically: First, calculate the sensitivity for each parameter dimension. For gradient descent updates, the sensitivity is defined as: in, This represents the sensitivity of the query function, which is the maximum L2 norm difference in the gradients of the loss function on adjacent datasets. Represents any dataset; Indicates and Adjacent datasets, i.e. and The difference is only one sample (the core definition of differential privacy); Represents the dataset The gradient of the loss function on; Representing adjacent datasets The gradient of the loss function on; This represents the L2 norm (Euclidean norm), which is the square root of the sum of the squares of the elements of a vector.
[0037] Then, add random noise that follows a Laplace or Gaussian distribution to each parameter dimension: For the Laplace mechanism: η ~ Lap(0, Δf / ε) For the Gaussian mechanism: η ~ N(0, σ) 2 ), where σ = Δf * sqrt(2*ln(1.25 / δ)) / ε.
[0038] Where ε is the privacy budget, controlling the strength of privacy protection; δ is the relaxation parameter (only required for Gaussian mechanisms). The noise level is dynamically adjusted by the differential privacy scheduler based on the current privacy consumption, and the cumulative privacy loss is accurately calculated using the Moments Accountant method to ensure that the total privacy budget does not exceed the preset upper limit.
[0039] The parameters after adding noise are updated as follows: Step 3: Secure Upload Parameter updates after adding noise Encryption is performed using the SM2 asymmetric encryption algorithm, a national standard. The specific process is as follows: power plant k Use the SM2 public key pair of the federated aggregation server Encryption is performed; the encrypted ciphertext is uploaded to the federated aggregation server via a TLS 1.3 secure channel; two-way certificate authentication is used during transmission to prevent man-in-the-middle attacks.
[0040] Step 4: Secure Aggregation After receiving the encrypted parameters from all power plants, the aggregation server decrypts them in a Trusted Execution Environment (TEE, such as Intel SGX or domestic Hygon CSV) and performs a weighted average: in, Indicates the first t Global model parameters after +1 round of communication; K This represents the total number of power plants participating in federal learning; This represents the number of samples from power plant k after differential privacy perturbation. It is the value of the local sample count of power plant k after differential privacy perturbation (Laplace noise is added to the actual sample count) to protect the data scale privacy of each power plant.
[0041] After aggregation is complete, the global model parameters are re-encrypted inside the TEE to ensure that plaintext parameters are not exposed outside the TEE.
[0042] Step 5: Model Distribution Aggregated global model parameters Each power plant encrypts its own data using its SM2 public key and distributes the encrypted data back to each plant via a TLS channel. Each power plant decrypts the data in its local TEE, replaces its local model parameters, and begins the next iteration.
[0043] Step 6: Abnormal Node Detection The aggregation server uses anomaly detection algorithms based on geometric median or cosine similarity to identify poisoning parameters uploaded by malicious power plants (such as intentionally disabling models or implanting backdoors).
[0044] Geometric Median Method: Calculate the updated geometric median for all parameters. Then, updates that are more than τ away from GM are removed.
[0045] Cosine similarity method: Calculate the cosine similarity between each pair of parameter updates. If the similarity between the update of a certain power plant and the updates of most other power plants is lower than the threshold γ, it is judged as abnormal.
[0046] If an anomaly is detected, the aggregation server removes the node from the current update and records the anomaly event, while also notifying the power plant to retrain or conduct a security audit.
[0047] Challenges and solutions in implementing federated learning aggregation server technology: Challenge 1: Non-independent and identically distributed (Non-IID) data problem Due to differences in unit type, operating procedures, and personnel structure, the local data distribution varies significantly among power plants, making it difficult for the standard FedAvg algorithm to converge, and even causing it to diverge.
[0048] Solution: Employ a dynamic weight adjustment strategy. Dynamically adjust the aggregation weights based on the performance of each power plant's local validation set. in, For power plants k Dynamic weights in global aggregation; For power plants k The local validation loss reflects the data quality of the power plant; The average validation loss is represented by β, which is a temperature coefficient. Power plants with lower validation losses (higher data quality) receive higher weights, and vice versa.
[0049] Meanwhile, the concept of Personalized Federated Learning is introduced, with the global model serving as the base model, and each power plant making a small amount of local fine-tuning on the basis of the global model to adapt to the local data distribution.
[0050] Challenge 2: Privacy-Utility Trade-off The addition of differential privacy noise will reduce model accuracy, and a fine balance needs to be struck between the privacy budget ε and model performance.
[0051] Solution: Adopt an adaptive privacy budget allocation strategy. Use a larger ε in the early stages of training (weaker privacy protection, stronger model learning), and gradually decrease ε as training progresses (enhanced privacy protection). Simultaneously, employ the sparse vector technique, adding noise only to updates of important parameters and not adding noise to updates close to zero, reducing unnecessary accuracy loss.
[0052] Challenge 3: Preventing poisoning attacks Malicious power plants may upload carefully crafted poisoning parameters, causing the global model to be biased towards specific predictions or to fail completely.
[0053] Solution: Use robust aggregation algorithms, such as Krum or Trimmed Mean.
[0054] Krum algorithm: Select (Kf-2) updates that are most similar to other updates from K updates (where f is the number of assumed malicious nodes), and calculate their geometric median as the aggregation result.
[0055] Trimmed Mean algorithm: For each parameter dimension, the maximum and minimum β ratio values are removed and then averaged to resist extreme outliers.
[0056] 3. Zero-knowledge authorization proof generation and verification module; When personnel move between power plants, the original power plant's system generates a zero-knowledge proof (ZKP) to demonstrate that the personnel possess a certain authorization level and meet all training requirements, but does not disclose specific course grades, operational details, or other private information. The target power plant can recognize the personnel's qualifications by verifying the mathematical validity of this proof.
[0057] When personnel are transferred from power plant A to power plant B, power plant B needs to verify the personnel's authorization status at power plant A. This invention employs zero-knowledge succinct non-interactive argument of knowledge (zk-SNARKs) to achieve privacy-preserving authorization verification.
[0058] (1) Proof of generation (Power Plant A side) 1) Public input includes: The hash value H(uid) of the personnel ID is SHA-256(uid), which protects the true identity of the personnel; Authorization level L ∈ {Basic safety authorization for debugging, Level 1 authorization for debugging positions, Level 2 authorization for debugging positions, Level 3 authorization for debugging positions, Level 1 authorization for debugging skills, Level 2 authorization for debugging skills, Level 3 authorization for debugging skills, and qualification of the person in charge of the work}; Validity period T = [T start , T end ].
[0059] 2) Private Witness includes: The list of courses completed by this person is C = {C1, C2, ..., C...} n}; Course Scores i , i = 1, 2, ..., n; Training timestamps for each course (TS) i ; Approver's digital signature Sig j j = 1, 2, ..., m (multi-level approval); Personnel's real identity identifier (UID).
[0060] 3) Circuit Logic: Compile the training authorization rules into an arithmetic circuit and verify that the following conditions are true: Authentication: hash(uid) == H(uid), meaning the provided uid hash matches the public input; Course completeness: For the set M(L) of all required courses corresponding to the authorization level L, satisfying C M(L); Passing grade: For all compulsory courses C i ∈ M(L), Score i ≥ Passing score (The passing score for basic safety authorization during debugging, authorization for debugging positions, and qualification of the person in charge of the work is 80 points, with a full score of 100 points); Time validity: For all courses C i TS i ∈ T, meaning the course completion time is within the authorized validity period; Approval legitimacy: The approval process involves a valid digital signature, i.e., verify(Sig) j PubKey j H(authorization record) == true, where PubKey j The public key for the j-th level approver; Equivalent course processing: If course equivalence exists (such as equivalent training instructors, equivalent work abilities, equivalent similar training courses, equivalent qualification certificates), verify that the equivalence conditions meet the preset rules.
[0061] 4) Proof generation: Run the zk-SNARKs generator to output the proof of π (only a few hundred bytes in size). Specifically, use either the Groth16 or Plonk protocol: Groth16 protocol: The proof size is about 200 bytes and the verification time is about 1.5 milliseconds, but it requires TrustedSetup to generate a Common Reference String (CRS).
[0062] Plonk protocol: proof size is about 400-600 bytes, verification time is about 3 milliseconds, supports universal and updatable SRS, and is more suitable for multi-power plant scenarios.
[0063] (2) Proof verification (Power plant B side) 1) Input: Common input (H(uid), L, T) and proof of π.
[0064] 2) Verification: Run the zk-SNARKs verification algorithm verify(π, H(uid), L, T, VK), where VK is the verification key. If the output is "Accept", it proves that the person does indeed have legal authorization at power plant A and meets all training requirements.
[0065] 3) Privacy protection effect: During the verification process, Power Plant B only knows that the person has a certain level of legal authorization and that it is within the validity period. It does not disclose any course name, specific grades, approver identity, training timestamp or other private information, which complies with the principle of minimum disclosure.
[0066] Technical challenges and solutions for the zero-knowledge authorization proof generation and verification module: Challenge 1: Circuitization of complex rules The training authorization rules include multiple matrix tables (such as the professional × level × course matrix in the list of authorized courses for debugging positions) and equivalent course rules (equivalent training instructors, equivalent work abilities, equivalent similar training courses, equivalent qualification certificates), involving a large amount of Boolean logic and arithmetic operations, which are directly compiled into a huge circuit.
[0067] Solution: Use a layered circuit design. Divide the circuit into three layers: First layer: Course existence verification circuit, using a Merkle tree to prove that the course is in the authorization list; The second layer: a grade calculation circuit that accumulates and compares grades for required courses; The third layer: the approval chain verification circuit, which verifies the legality of multi-level signatures.
[0068] The equivalent course rules are optimized by using a lookup table, which pre-computes the equivalent relationships as a lookup table, so that only table lookup operations are needed in the circuit instead of complex logic operations.
[0069] Challenge 2: Proving generation time optimization For authorization records that include dozens of courses and multiple levels of approval, directly generating proof may take several minutes, which does not meet actual business needs.
[0070] Solution: Replace Groth16 with the Plonk protocol, leveraging its Polynomial Commitment Scheme to optimize proof generation. Simultaneously, employ distributed proof generation, breaking down the circuit into multiple sub-circuits and utilizing multi-core CPUs or GPUs for parallel computation. Through optimization, the proof generation time is controlled to the second level (<10 seconds).
[0071] Challenge 3: Generation of Cross-Power Plant Common Parameters (CRS) zk-SNARKs require a common reference string (CRS). If generated by a single power plant, there is a risk that the power plant knows that the certificate for "toxic waste" can be forged.
[0072] Solution: A Multi-Party Computation (MPC) protocol is used to generate the CRS. Each power plant participates in the MPC protocol, and the CRS is secure as long as at least one participant honestly destroys its random number. An Updatable SRS scheme is adopted, allowing each power plant to update its CRS sequentially without needing to perform a complete trusted setup ceremony again.
[0073] 4. Smart Contract Interoperability Chain Each power plant, acting as a node in the consortium blockchain, uploads the authorized and mutually recognized hash digests to the blockchain for verification, forming an immutable and mutually recognized record for auditing purposes.
[0074] (1) Consortium blockchain mutual recognition and storage To prevent power plant A from denying the proof it generated afterward, or power plant B from tampering with the verification record, this invention uses a consortium blockchain (Hyperledger Fabric or the domestic Chang'an Chain) to store the hash digest of the mutual recognition behavior.
[0075] (2) Consortium blockchain architecture A consortium blockchain consists of the following nodes: Orderer: Responsible for transaction ordering and block generation, using Raft or Kafka consensus algorithms; Endorser nodes: These are the power plants themselves, responsible for executing smart contracts and endorsing transactions. Committer: Responsible for verifying the endorsement policy and writing blocks into the ledger; Certificate Authority (CA): Issues identity certificates to each node based on the national cryptographic SM2 / SM3 algorithm.
[0076] (3) On-chain content Each mutual recognition event generates a transaction record containing the following fields: Mutual recognition event ID: A globally unique identifier, using a UUID or a timestamp-based sequence number; Original power plant ID: The power plant identifier used to generate the certificate; Target power plant ID: The power plant identifier used for verification; Personnel ID hash: SHA-256(uid), protecting personnel privacy; Authorization level L; The hash value of a zero-knowledge proof is SHA-256(π), which is not the proof itself, thus avoiding privacy leaks. Verification result: Pass / Fail; Timestamp: The time when mutual recognition occurred, using blockchain timestamp services; Transaction hash: The hash value of the entire transaction, used for quick verification.
[0077] (4) Smart contract function Smart contracts are written in Go or Java and deployed on a consortium blockchain. Their main functions include: 1) recordMutualRecognition: Records a mutual recognition event.
[0078] Input: Mutual recognition event ID, original power plant ID, target power plant ID, personnel ID hash, authorization level, proof hash, verification result, timestamp; Verification: Check if the caller is an endorser node and verify the validity of the digital signature; Execution: Write transaction records to the ledger and update relevant indexes; Output: Transaction hash and block number.
[0079] 2) queryRecognitionHistory: Queries a person's mutual recognition history (for auditing purposes).
[0080] Input: Personnel ID hash, query time range; Verification: Check if the caller has auditing privileges (via attribute-based encryption or role-based access control). Execution: Query historical records based on the personnel ID hash index; Output: A list of mutual recognition history, including time, original power plant, target power plant, authorization level, and verification results.
[0081] 3) RevokeRecognition: When the authorization is revoked, the original power plant can call this contract to mark it invalid.
[0082] Input: Mutually recognized event ID, reason for revocation, timestamp of revocation, digital signature of the person revoking; Verification: Check if the caller is the original power plant, and verify the validity of the revocation of permissions and the signature; Execution: Append a cancellation marker to the original record to generate a new cancellation transaction; Output: Reversal transaction hash.
[0083] Technical challenges and solutions for smart contract mutual recognition chains: Challenge 1: Adapting consensus algorithms for consortium blockchains The multi-party governance structure of the nuclear power industry involves multiple nuclear power groups and regulatory agencies. Traditional PoW consensus consumes too much energy, while PBFT consensus becomes less efficient when there are many nodes.
[0084] Solution: Employ Hierarchical PBFT or HotStuff consensus algorithms. Nodes are divided into a core layer (regulatory bodies, industry associations) and a participating layer (power plants). The core layer is responsible for final consensus, while the participating layer is responsible for transaction endorsement and verification, balancing efficiency and decentralization.
[0085] Challenge 2: On-chain storage and privacy protection If the complete proof is put on the blockchain, it can be verified but privacy is compromised; if only the hash is put on the blockchain, there is a risk of hash collision (although the collision probability of SHA-256 is extremely low).
[0086] Solution: Employ a dual-hash strategy. The zero-knowledge proof π is hashed twice: H1 = SHA-256(π) for on-chain storage, and H2 = SHA-3(π) for auxiliary verification. Simultaneously, the proof π itself is stored in the distributed file systems (such as IPFS or private storage clusters) of each power plant; only the content addressing hash is stored on-chain, achieving an architecture of "on-chain storage, off-chain storage".
[0087] In addition to the modules mentioned above, this system also includes several basic functional modules: course maintenance module, job-specific course module, and authorization application module.
[0088] 1. Course Maintenance Module This module implements the data maintenance function for courses, and the administrator role is responsible for maintaining the basic data of the courses.
[0089] Business Rules: Course rules are divided into: elective courses and required courses; Training methods include: online learning, self-study, and classroom training (centralized instruction). The assessment methods include: closed-book exams, interviews, and mock tests.
[0090] Course maintenance form fields:
[0091] 2. Job-related course modules This module enables data maintenance for debugging courses, with the administrator role responsible for maintaining the basic data of the major and courses.
[0092] (1) Classification of authorization types: Debugging basic safety authorization; debugging job authorization; debugging skills authorization.
[0093] (2) Debugging post authorization and debugging skill authorization are divided into five categories according to profession: Engineering Technology; Electrical Engineering; Instrumentation and Control Engineering; Technical Management; Overall Testing.
[0094] List of Basic Security Authorization Courses for Debugging:
[0095] List of authorized courses for debugging positions:
[0096] List of Debugging Skills Authorization Courses:
[0097] List of courses for the qualification certification of work supervisors:
[0098] (3) Qualification Standard: The passing score for basic safety authorization during debugging is 80 points, out of a possible 100 points. The passing score for the authorized training and assessment for debugging positions is 80 points, out of a total of 100 points. The passing score for the qualification assessment training for the person in charge of the work is 80 points, out of a total of 100 points.
[0099] (4) Fields in the job course maintenance form: Professional Positions Tab:
[0100] 3. Authorization Request Module This module implements the debugging training authorization function / authorization application function, including the following roles and processes: (1) Roles and Responsibilities: Applicant's role: Initiating an authorization request; Training Engineer: Verify the completeness of the application materials and the authenticity of the training records; Department managers: Review the applicant's professional competence and job suitability; Debugging team leader: Review the applicant's overall qualifications and team requirements; General Manager of the Debugging Center: Conducts final review and fills in the processing comments, deciding whether to approve the authorization.
[0101] (2) Authorization type and business logic: 1) Debugging basic security authorization For first-time applications: the application type can be selected as "Initial Application", "Basic Security Authorization Approval", or "New Authorization"; Data that already initiates the process: When adding a new authorization request, all options for the nature are unavailable; Valid status data already exists: Submit a new authorization request, with the option of "authorization extension" for the current status. After the license expires: You can apply for a new license, and the type of application can be "Initial Application", "Basic Security License Approval" or "New License".
[0102] 2) Authorization of debugging positions First-time application: The nature can be selected as "Initial Application"; For existing data that has already initiated the process: When adding a new authorization application for the same specialty: all options for the nature are unavailable; When adding a new authorization application for a different specialty: the nature can be either "Authorization Change" or "New Authorization". Valid status data already exists: For new authorization applications in the same specialty: the nature can be selected as "Authorization Upgrade" or "Authorization Extension"; For new authorization applications in a different specialty: the nature can be selected as "Authorization Change" or "New Authorization"; After the authorization expires: Apply for a new authorization, and select "Initial Application" as the type.
[0103] 3) Debugging skills authorization First-time application: The nature of the application can be selected as "Initial Application"; For existing data that has already initiated the process: When adding a new authorization application for the same specialty: all options for the nature are unavailable; When adding a new authorization application for a different specialty: the nature can be either "Authorization Change" or "New Authorization". Valid status data already exists: For new authorization applications in the same specialty: the nature can be selected as "Authorization Upgrade" or "Authorization Extension"; For new authorization applications in a different specialty: the nature can be selected as "Authorization Change" or "New Authorization"; After the authorization expires: Apply for a new authorization, and select "Initial Application" as the type.
[0104] Debugging training authorization application process: The application process is as follows: Applicant initiates application → Training engineer reviews → Professional department manager reviews → Debugging team leader reviews → Debugging center general manager reviews and provides processing comments → Authorization takes effect / rejection.
[0105] An application may be rejected at any stage of the process, and the applicant may resubmit or withdraw the application after rejection.
[0106] Relevant reports (including approval processes):
[0107]
[0108]
[0109]
[0110]
[0111] List of debugging training authorization application forms are as follows:
[0112] The details page for the debugging training authorization application includes the following forms:
[0113]
[0114] 4) Detailed explanation of the equivalent course rules: When an applicant possesses the relevant skills but has not received standard course training, they can apply for an exemption under the following four equivalent conditions: Equivalent to a training instructor: The applicant has served as a training instructor for this course and possesses teaching ability; Equivalent work ability: The applicant has been performing relevant operations in actual work for a long time and has been assessed as having the corresponding ability; Equivalent to similar training courses: The applicant has completed other training courses with similar content, and the content coverage is determined to be ≥90% after comparison; Equivalent Qualification Certificate: Applicants must hold a nationally or industry-recognized qualification certificate. The certificate number and name must be filled in.
[0115] An equivalent application must include detailed reasons and supporting documentation, and will only be effective after joint review and approval by the training engineer and the professional department manager.
[0116] Example 2 This example is an assessment of cross-nuclear power plant federated learning capabilities.
[0117] Scenario Description: Nuclear Power Group A's Power Plants A and B, and Nuclear Power Group B's Power Plant C, want to jointly train a commissioning personnel competency assessment model to evaluate the initial proficiency of personnel transferred across power plants. The three power plants have 5000, 8000, and 6000 operational behavior records, respectively.
[0118] Implementation steps: Step S101: System Deployment and Initialization Each power plant deploys a federated learning client locally, which includes a local HMM model training environment, a differential privacy noise generator, and an SM2 encryption module. The federated aggregation server is deployed in a third-party private cloud environment, equipped with an Intel SGX trusted execution environment.
[0119] Initialize global model parameters The Xavier initialization method was adopted. The federated learning hyperparameters were set as follows: local training rounds E=5, batch size B=32, learning rate η=0.01, total communication rounds R=100, privacy budget ε=1.0, and gradient pruning threshold C=1.0.
[0120] Step S102: Local model training (taking power plant A as an example) Power plant A extracts operational behavior logs from its local database to construct training dataset D. A Data preprocessing includes: Missing value imputation: Forward imputation method is used; Outlier handling: Outlier records are removed using the 3σ principle; Feature normalization: Normalize features such as time consumption ratio and error rate to the [0,1] interval; Sequence truncation / padding: Unifies the operation sequence to a length T=50.
[0121] The local HMM model was trained using the Baum-Welch algorithm to obtain the local parameters θ. A Then, the gradient of the local loss function is calculated, and SGD updates are performed for 5 epochs to obtain the parameter update amount Δθ. A .
[0122] Step S103: Differential privacy noise injection Calculate the sensitivity after gradient pruning, Δf = 2C = 2.0. Dynamically adjust the privacy budget allocation based on the current privacy consumption status. Assume the current round allocates a privacy budget ε. t = 0.01, generating Laplace noise: For each parameter dimension i Add noise: .
[0123] Step S104: Secure Upload Use the SM2 public key pair of the aggregation server Encryption is performed. SM2 encryption process: Generate random numbers k ∈ [1, n-1]; Calculate the point C1 = [k]G = (x1, y1) on the elliptic curve; Calculate [k]PB = (x2, y2), where P B This is the server's public key; Calculate t = KDF(x2||y2, len), where KDF is the key derivation function; Calculate C2 = M ⊕ t, where M is the plaintext parameter update; Calculate C3 = Hash(x2||M||y2); The ciphertext is (C1, C2, C3).
[0124] Upload ciphertext to the aggregation server via TLS 1.3 channel.
[0125] Step S105: Secure Aggregation The aggregation server decrypts all power plant parameter updates within the SGX trusted execution environment. The decryption process corresponds to the encryption process, using the server's private key d. B Calculate [k]P B = [d B C1, recover t and plaintext M.
[0126] Perform weighted average aggregation: in, , Privacy budget for sample size.
[0127] Step S106: Anomaly Detection Calculate the pairwise cosine similarity updated with three parameters. Assume... , , All values are greater than the threshold γ=0.7, indicating no abnormal nodes.
[0128] If the similarity of an update from a power plant to other power plants is less than 0.7, it is marked as an anomaly, its update is removed, and a safety event is recorded.
[0129] Step S107: Model Distribution and Local Update Aggregated global model parameters Each power plant's data is encrypted using its public key and then distributed. Each power plant decrypts the data, updates its local model, and begins the next iteration.
[0130] Step S108: Convergence Judgment and Termination After every 10 rounds of communication, each power plant evaluates the model's performance on its local validation set. If the accuracy improvement on the validation set is less than 0.1% for three consecutive rounds, training is terminated early. The final model achieves an accuracy of 85% on the cross-power plant test set, a 15% improvement compared to the average accuracy of 70% for a single-power-plant local model.
[0131] Example 3 This embodiment is a zero-knowledge authorization mutual recognition.
[0132] Scenario Description: Commissioning personnel Zhang is transferred from Power Plant A (Nuclear Power Group A) to Power Plant B (Nuclear Power Group B). Power Plant B needs to verify Zhang's authorization for the commissioning position (Level 2 Process Specialist) at Power Plant A.
[0133] Implementation steps: Step S201: Proof of generation preparation (Power Plant A side) Power Plant A's system retrieved Zhang's authorization records: Common input: H(uid) = SHA-256("zhangsan_12345"), L = "Debugging Post Authorization - Process - Level 2", T = [2024-01-01, 2026-12-31]; Private Witness: Course list C = {Commissioning Management, Basic Equipment Testing, Process System Testing, Unit Start-up and Performance Testing, DCS Commissioning, Isolation Operation Training}, Course Score = {85, 88, 90, 82, 86, 91}, Training timestamp, Digital signature of three-level approver.
[0134] Step S202: Circuit Compilation The authorization rules are compiled into a Plonk arithmetic circuit, with a circuit size of approximately 10. 5 One constraint. Main circuit logic: Course existence verification: Use the Merkle path to prove that each required course is in the authorization list; Grade Comparison: For each required course, verify the score. i ≥ 80; Time verification: Verify that the completion time of all courses ∈ [2024-01-01, 2026-12-31]; Signature verification: Verify three-level approval signatures using ECDSA or SM2 verification algorithms.
[0135] Step S203: Trusted Setup and CRS Generation Power plant A, power plant B, and the industry association participate in Plonk's universal trust settings to generate an updatable structured reference string (Universal SRS). Each party contributes randomness and then destroys the SRS, ensuring that no single party is aware of the "toxic waste" information.
[0136] Step S204: Proof generation Running the Plonk proof generation algorithm, with the input circuit, witness, and CRS, generates proof π. GPU acceleration (CUDA implementation of multiscalar multiplication and Fast Fourier Transform) optimizes the proof generation time to 5 seconds. The proof size is approximately 500 bytes.
[0137] Step S205: Prove Transmission Power plant A sends (H(uid), L, T, π) to power plant B via a secure channel. Simultaneously, it uploads the proof hash H(π) and the mutual recognition event digest to the consortium blockchain.
[0138] Step S206: Verification (Power Plant B side) Power Plant B runs the Plonk verification algorithm, taking π, a common input, and the verification key VK as input, and performs a bilinear pairing operation to verify the validity of the proof. The verification time is approximately 3 milliseconds, and the verification result outputs "Accept".
[0139] Step S207: Authorization Takes Effect Power Plant B confirmed that Zhang possessed the authorization for a Level 2 commissioning position in process engineering and granted him the corresponding system access, without requiring retraining or reassessment. The entire mutual recognition process took approximately 10 seconds (including network transmission) and required no manual intervention.
[0140] Step S208: Evidence Storage and Blockchain Application Power Plant B invokes the smart contract `recordMutualRecognition` to record the mutual recognition event on the blockchain for evidence storage. The recorded content includes: Mutual recognition event ID: MR-2026-001-001; Original power plant ID: SPIC-A; Target power plant ID: CNNC-B; Personnel ID hash: SHA-256("zhangsan_12345"); Authorization Level: Debugging Position Authorization - Process - Level 2; Proof hash: SHA-256(π); Verification result: Passed; Timestamp: 2026-04-22T14:30:00Z.
[0141] After a transaction is endorsed by the endorsing nodes (Power Plant A and Power Plant B), it is packaged into a block by the sorting nodes, and then written into the ledger after verification by the submitting nodes.
[0142] Example 4 This example is an application for authorization of an equivalent course.
[0143] Scenario Description: Mr. Li is applying for authorization to work as a commissioning engineer (Level 1 in Electrical Engineering). He already holds a Registered Electrical Engineer certificate and is applying for an exemption from the "Electrical System Testing" course based on "equivalent qualification certificate".
[0144] Implementation steps: Step S301: The applicant initiates the application Li logged into the system, selected the authorization type "Debugging Position Authorization", the major "Electrical", and the level "Level 1". The system automatically displayed a list of required courses: Debugging Management (Required), Basic Equipment Testing (Required), Electrical System Testing (Required), and DCS Debugging (Required).
[0145] Step S302: Completion of Equivalent Application In the "Electrical System Experiment" course, Li selected "Course Equivalence" as the grading method and "Certificate Equivalence" as the equivalence condition. The system automatically expanded the certificate number and certificate name fields. Li filled in: Certificate Number: REE-2019-XXXXX; Certificate Name: Registered Electrical Engineer Professional Qualification Certificate; Equivalent grounds: I passed the Registered Electrical Engineer Examination (Power Transmission and Transformation Specialty) in 2019 and possess the professional knowledge and practical skills required for electrical system testing. Therefore, I am applying for an equivalent exemption.
[0146] Upload a scanned copy of the certificate as an attachment.
[0147] Step S303: Training Engineer Review After receiving the application, the training engineer verifies the authenticity of the certificate: Verify the certificate number through the professional qualification registration center; Verify that the certificate's specialization is "power generation, transmission and transformation"; Assess whether the certificate coverage meets the requirements of the "Electrical Systems Testing" course (≥90%).
[0148] After the review is approved, please fill in the review comments: "The certificate is authentic and valid, the professional direction matches, and it is deemed equivalent." Step S304: Review by the Professional Department Manager The Electrical Engineering Department Manager reviewed Li's actual work ability and its match with the job requirements, confirming that he indeed possessed the ability to test electrical systems, and filled in the review comments: "Agreed to be equivalent, authorization recommended." Step S305: Debugging team leader reviews The commissioning team leader reviewed the team's personnel requirements, confirmed the need for Level 1 electrical engineers, and filled in the review comment: "Authorization approved." Step S306: Approval by the General Manager of the Debugging Center The general manager of the debugging center reviewed all materials and confirmed that the equivalent application met the requirements, thus approving the authorization. The system automatically generated an authorization certificate, valid for 3 years.
[0149] Step S307: Federated Learning Model Update Li's operational behavior data (actual work performance after the equivalent course) was incorporated into the local HMM model training dataset to continuously optimize the model's accuracy in evaluating equivalent authorized personnel. Model parameter updates were shared to the global model through a federated learning framework, improving the ability to evaluate equivalent authorized personnel across power plants.
[0150] Example 5 This application also provides a method for joint assessment and authorization mutual recognition of the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy, implemented based on the above system, including the following steps: Step 1: Each power plant trains its proficiency assessment model locally to obtain local parameter updates; Step 2: Add differential privacy noise to the local parameter update, encrypt it using the national cryptographic SM2 algorithm, and upload it to the federated aggregation server. The differential privacy noise injection adopts an adaptive privacy budget allocation strategy. A larger privacy budget is used in the early stage of training, and the privacy budget is gradually reduced as training progresses. Sparse vector technology is used to add noise only to the updates of important parameters.
[0151] Step 3: The federated aggregation server decrypts and executes the weighted average aggregation in a trusted execution environment to generate global model parameters; Step 4: Encrypt and distribute the global model parameters back to each power plant to replace the local model; Step 5: When personnel move between power plants, the original power plant generates zero-knowledge proofs based on the personnel's training authorization records. The zero-knowledge proof generation adopts the Plonk protocol, and the training authorization rules are compiled into arithmetic circuits through hierarchical circuit design and lookup table optimization. Distributed proof generation is used to control the proof generation time to the second level.
[0152] Step 6: The target power plant verifies the mathematical validity of the zero-knowledge proof. If the verification is successful, its qualification is recognized. Step 7: Upload the hash digest of the authorized mutual recognition event to the blockchain for evidence storage. The consortium blockchain uses a layered PBFT or HotStuff consensus algorithm, dividing nodes into a core layer and a participation layer. The core layer is responsible for final consensus, while the participation layer is responsible for transaction endorsement and verification.
[0153] This application may also provide a computer device, including: at least one processor, memory, at least one network interface, and a user interface. The various components in this device are coupled together via a bus system. It is understood that the bus system is used to implement communication between these components. In addition to a data bus, the bus system also includes a power bus, a control bus, and a status signal bus.
[0154] The user interface can include a display, keyboard, or clicking device. Examples include a mouse, trackball, touchpad, or touchscreen.
[0155] It is understood that the memory in the embodiments disclosed in this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.
[0156] In some implementations, the memory stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof: operating systems and applications.
[0157] The operating system includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application programs include various applications, such as media players and browsers, used to implement various application functions. Programs implementing the methods of the embodiments of this disclosure can be included in the application programs.
[0158] In the above embodiments, the processor can also invoke programs or instructions stored in memory, specifically programs or instructions stored in an application program, for the following purposes: Follow the steps described above.
[0159] The above methods can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic diagrams disclosed above. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the disclosed methods can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.
[0160] It is understood that the embodiments described in this application can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in this application, or combinations thereof.
[0161] For software implementation, the technology of this application can be implemented by executing the functional modules (e.g., procedures, functions, etc.) of this application. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or outside the processor.
[0162] This application may also provide a non-volatile storage medium for storing a computer program. When the computer program is executed by a processor, it can implement the steps in the above method embodiments.
[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of this application do not depart from the spirit and scope of the technical solutions of this application, and should all be covered within the scope of the claims of this application.
Claims
1. A joint assessment and authorization mutual recognition system for the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy, characterized in that, include: The local proficiency assessment model module is deployed locally at each nuclear power plant. It is used to train a proficiency assessment model based on the plant's operation behavior log data and output the personnel proficiency level and confidence level. The federated learning aggregation server module, deployed by a third party, is used to receive encrypted parameter updates from the local models of each nuclear power plant, generate a global model through an improved federated averaging algorithm, and distribute it back to each nuclear power plant. The zero-knowledge authorization proof generation and verification module is used when personnel move between nuclear power plants. The original nuclear power plant system generates a zero-knowledge proof, and the target nuclear power plant verifies the mathematical validity of the proof to recognize the qualification. and The smart contract mutual recognition chain module is used to store the hash digest of authorized mutual recognition on the chain, forming an immutable mutual recognition record.
2. The cross-nuclear power plant commissioning personnel competency joint assessment and authorization mutual recognition system based on federated learning and differential privacy as described in claim 1, characterized in that, The local proficiency assessment model employs a hidden Markov model or a temporal neural network. Input features include time consumption ratio, number of assistance requests, error rate, rework rate, exception handling response time, and work order completion quality score; The output hidden state is high proficiency, medium proficiency, or low proficiency.
3. The cross-nuclear power plant commissioning personnel competence joint assessment and authorization mutual recognition system based on federated learning and differential privacy as described in claim 1, characterized in that, The federated learning aggregation server module includes: The differential privacy noise injection unit is used to add random noise that follows a Laplace or Gaussian distribution before the parameter update is uploaded. The amount of noise is dynamically adjusted by the differential privacy scheduler according to the current privacy consumption. The secure aggregation unit, deployed in a trusted execution environment, is used to decrypt encrypted parameters and perform weighted average aggregation. An abnormal node detection unit is used to identify poisoning parameters uploaded by malicious nuclear power plants based on geometric median or cosine similarity.
4. The cross-nuclear power plant commissioning personnel competence joint assessment and authorization mutual recognition system based on federated learning and differential privacy as described in claim 1, characterized in that, The zero-knowledge authorization proof generation and verification module adopts the zk-SNARKs protocol; Public inputs include the person's ID hash, authorization level, and validity period; Private witnesses include a course list, course grades, training timestamps, and the approver's digital signature; The circuit logic verifies identity matching, course completeness, passing grades, time validity, and approval legitimacy.
5. The cross-nuclear power plant commissioning personnel competence joint assessment and authorization mutual recognition system based on federated learning and differential privacy as described in claim 1, characterized in that, The smart contract mutual recognition chain module adopts a consortium blockchain architecture and includes three smart contract functions: recording mutual recognition events, querying mutual recognition history, and revoking authorization. The on-chain content includes the mutual recognition event ID, the original power plant ID, the target power plant ID, the personnel ID hash, the authorization level, the zero-knowledge proof hash value, the verification result, and the timestamp.
6. A method for joint assessment and authorization mutual recognition of the capabilities of commissioning personnel across nuclear power plants based on federated learning and differential privacy, implemented based on the system described in any one of claims 1-5, comprising: Step 1: Each nuclear power plant locally trains its proficiency assessment model to obtain local parameter updates; Step 2: Add differential privacy noise to the local parameter update, encrypt it using the national cryptographic SM2 algorithm, and then upload it to the federated aggregation server; Step 3: The federated aggregation server decrypts and executes the weighted average aggregation in a trusted execution environment to generate global model parameters; Step 4: Encrypt and distribute the global model parameters back to each nuclear power plant to replace the local model; Step 5: When personnel move between nuclear power plants, the original nuclear power plant generates zero-knowledge proofs based on the personnel's training authorization records; Step 6: The target nuclear power plant verifies the mathematical validity of the zero-knowledge proof. If the verification is successful, its qualification is recognized. Step 7: Upload the hash digest of the authorized mutual recognition event to the blockchain for evidence storage.
7. The method for joint assessment and authorization mutual recognition of cross-nuclear power plant commissioning personnel capabilities based on federated learning and differential privacy as described in claim 6, characterized in that, The differential privacy noise injection in step 2 adopts an adaptive privacy budget allocation strategy. A larger privacy budget is used in the early stage of training, and the privacy budget is gradually reduced as training progresses. Sparse vector technology is used to add noise only to the updates of important parameters.
8. The method for joint assessment and authorization mutual recognition of commissioning personnel capabilities across nuclear power plants based on federated learning and differential privacy as described in claim 6, characterized in that, The zero-knowledge proof generation in step 5 adopts the Plonk protocol. Through hierarchical circuit design and lookup table optimization, the training authorization rules are compiled into arithmetic circuits, and the proof generation time is controlled to the second level by using distributed proof generation.
9. The method for joint assessment and authorization mutual recognition of commissioning personnel capabilities across nuclear power plants based on federated learning and differential privacy as described in claim 6, characterized in that, The consortium blockchain in step 7 adopts a layered PBFT or HotStuff consensus algorithm, dividing nodes into a core layer and a participation layer; the core layer is responsible for final consensus, and the participation layer is responsible for transaction endorsement and verification.