Dynamic evaluation multivariate computing power scheduling method and system fusing quantum and block chain

Abstract

The invention relates to the crossing field of multivariate computing power scheduling, quantum communication and block chain technologies, in particular to a dynamic evaluation multivariate computing power scheduling method and system fusing quantum and a block chain. The method is based on a distributed account book of a block chain and an intelligent contract technology, and combines physical layer security characteristics of quantum key distribution to construct a whole process mechanism of identity authentication-dynamic evaluation-scheduling decision-security execution-feedback optimization. According to the method, the static benchmark and the real-time data are fused, the index weight is adaptively adjusted in combination with the task type, the problem of traditional evaluation staticization is solved, the data counterfeiting risk is completely eradicated, and the high-real-time scene requirement is met.

Description

Technical Field

[0001] This invention relates to the intersection of multi-dimensional computing power scheduling, quantum communication, and blockchain technology. Specifically, it relates to a dynamic evaluation method and system for multi-dimensional computing power scheduling that integrates quantum and blockchain technologies. It is applicable to cross-domain collaborative scenarios of heterogeneous computing power resources such as CPU / GPU / QPU, and is particularly suitable for fields such as the "East Data West Computing" project, AI large model training, and distributed scientific computing, which have extremely high requirements for scheduling reliability, security, and dynamic adaptability. Background Technology

[0002] With the explosive growth in computing power demand, cross-domain collaboration of diverse computing power (supercomputing, intelligent computing, general computing, quantum computing, etc.) has become an inevitable trend. However, existing scheduling technologies have the following core pain points:

[0003] The evaluation mechanism is static: Traditional computing power evaluation relies on preset benchmarks (such as peak computing power and power consumption ratio), without considering the dynamic requirements of tasks (such as real-time performance and accuracy requirements) and changes in node status (such as load fluctuations and failure rates), resulting in a disconnect between "evaluation and scheduling".

[0004] Insufficient data credibility: The performance data and task execution logs of computing power nodes are easily tampered with or forged. The centralized certification model of third-party evaluation agencies has the risk of single point of failure, which makes it difficult to support the trust foundation for cross-domain computing power transactions.

[0005] Security vulnerabilities: Core data such as scheduling instructions and evaluation results rely on traditional encryption algorithms for transmission, which are easily cracked in a quantum computing environment, and node identity authentication is vulnerable to man-in-the-middle attacks;

[0006] Imbalance between scheduling efficiency and security: In existing technologies, high security (such as multiple encryption) often comes at the cost of scheduling response speed, which cannot meet the dual requirements of "millisecond-level response + quantum-level security" in scenarios such as AI large model training.

[0007] To address the aforementioned issues, it is urgent to integrate the physical layer security characteristics of quantum technology with the distributed trust characteristics of blockchain to construct an integrated mechanism of "dynamic evaluation-trusted scheduling-secure execution" to achieve efficient collaboration of diverse computing power. Summary of the Invention

[0008] The purpose of this invention is to provide a dynamic evaluation multi-dimensional computing power scheduling method and system that integrates quantum computing and blockchain to solve problems such as static evaluation, untrustworthy data, weak security protection, and imbalance between efficiency and security in existing multi-dimensional computing power scheduling, and to achieve synergistic optimization of "trustworthy evaluation-dynamic scheduling-quantum security".

[0009] According to a first aspect of the present invention, a dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain is provided. This method, based on the distributed ledger and smart contract technologies of blockchain and combined with the physical layer security characteristics of quantum key distribution (QKD), constructs a full-process mechanism of "identity authentication - dynamic evaluation - scheduling decision - secure execution - feedback optimization". Specifically, this method includes the following steps:

[0010] Computing node registration is completed through quantum-enhanced two-factor authentication, generating a unique identity and establishing an initial capability benchmark;

[0011] Based on the real-time operating status of the authentication nodes, dynamic evaluation data of quantum encryption is collected.

[0012] Based on the static capability benchmark and dynamic collection data stored on the blockchain by smart contract, a multi-dimensional evaluation matrix is ​​constructed. The index weights are adaptively adjusted according to the task type, and the real-time score of the node is calculated and stored on the blockchain.

[0013] Candidate nodes are selected based on real-time blockchain scoring, and the optimal scheduling scheme is determined through a multi-objective optimization model to generate quantum-encrypted scheduling instructions.

[0014] Based on the execution results of the scheduled tasks, update the node scores and evaluation model weights.

[0015] This system, corresponding to the above methods, integrates a blockchain module, a quantum security module, a dynamic evaluation module, a scheduling decision module, and a feedback optimization module to achieve reliable, secure, and efficient scheduling of diverse computing power, specifically including:

[0016] An integrated blockchain module is used to complete the registration of computing power nodes through quantum-enhanced two-factor authentication, generate a unique identity, and build an initial capability benchmark.

[0017] A quantum-secure communication module is used to collect dynamic evaluation data of quantum encryption in real time. This step collects dynamic evaluation data of quantum encryption based on the real-time operating status of the authentication node, ensuring the real-time nature, confidentiality, and integrity of the dynamic evaluation data.

[0018] The dynamic data acquisition and evaluation module is used to read the static capability benchmark and dynamically acquired data stored on the blockchain based on smart contracts, construct a multi-dimensional evaluation matrix, adaptively adjust the indicator weights according to the task type, calculate the real-time score of the node and store it on the blockchain.

[0019] The scheduling decision module is used to screen candidate nodes based on real-time blockchain scoring, determine the optimal scheduling scheme through a multi-objective optimization model, and generate quantum-encrypted scheduling instructions.

[0020] The feedback and optimization module is used to update node scores and evaluation model weights based on the execution results of scheduled tasks.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] More accurate dynamic evaluation: By integrating static benchmarks with real-time data and adaptively adjusting indicator weights according to task type, the static nature of traditional evaluation is solved, and the evaluation accuracy is improved by more than 20%.

[0023] Data is trustworthy and tamper-proof: Blockchain notarization and quantum encryption ensure the integrity and authenticity of evaluation data and scheduling instructions, eliminating the risk of data forgery;

[0024] Quantum-level security protection: QKD key and quantum fingerprint technology resist quantum computing attacks, identity authentication prevents man-in-the-middle attacks, and the security level reaches the national level 4 security protection standard;

[0025] Scheduling efficiency and security are combined: smart contracts are automatically evaluated and scheduled, and quantum encryption does not add extra latency (<100ms), meeting the requirements of high real-time scenarios;

[0026] Strong self-optimization capability: Based on the task feedback iterative evaluation model, it continuously improves scheduling adaptability and is suitable for complex scenarios with dynamic changes in computing power nodes.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0029] Figure 1 A flowchart illustrating a dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain is shown in one embodiment.

[0030] Figure 2 A flowchart of step S1 in one embodiment is shown.

[0031] Figure 3 A flowchart of step S11 in one embodiment is shown.

[0032] Figure 4 A flowchart of step S12 in one embodiment is shown.

[0033] Figure 5 A flowchart of step S2 in one embodiment is shown.

[0034] Figure 6 A flowchart of step S21 in one embodiment is shown.

[0035] Figure 7 A flowchart of step S22 in one embodiment is shown.

[0036] Figure 8 A flowchart of step S23 in one embodiment is shown.

[0037] Figure 9 A flowchart of step S3 in one embodiment is shown.

[0038] Figure 10 A flowchart of step S31 in one embodiment is shown.

[0039] Figure 11 A flowchart of step S32 in one embodiment is shown.

[0040] Figure 12 A flowchart of step S33 in one embodiment is shown.

[0041] Figure 13 A flowchart of step S4 in one embodiment is shown.

[0042] Figure 14 A flowchart of step S42 in one embodiment is shown.

[0043] Figure 15 A flowchart of step S43 in one embodiment is shown.

[0044] Figure 16 A flowchart of step S44 in one embodiment is shown.

[0045] Figure 17 A flowchart of step S5 in one embodiment is shown.

[0046] Figure 18 A flowchart of step S51 in one embodiment is shown.

[0047] Figure 19 A flowchart of step S52 in one embodiment is shown.

[0048] Figure 20 A flowchart of step S53 in one embodiment is shown.

[0049] Figure 21 A block diagram of a prediction device for a dynamic evaluation multi-dimensional computing power scheduling method that integrates quantum computing and blockchain is shown in one embodiment. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0052] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0053] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0054] It should also be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.

[0055] Figure 1 A flowchart illustrating a dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain is shown in one embodiment. Figure 1 As shown, a dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain is provided, which may include the following steps S1 to S5.

[0056] In step S1, computing node registration is completed through quantum-enhanced two-factor authentication, generating a unique identity and establishing an initial capability benchmark. This step provides a reliable benchmark for subsequent dynamic evaluation, while leveraging the immutability of blockchain to ensure the authenticity of node identity and basic information. Specifically, step S1 includes:

[0057] S11: Quantum-enhanced node registration and authentication

[0058] This step involves inputting node registration application information, a quantum random number, and blockchain network access permissions. Node registration application information includes hardware parameters (e.g., GPU model A100, 50 qubits), historical performance data (98% task completion rate in the last 30 days), and physical location (e.g., "Beijing Yizhuang Data Center"). The quantum random number is generated by QRNG and is a truly random sequence used for the challenge code. Blockchain network access permissions include, for example, a consortium blockchain member certificate.

[0059] Specifically, step S11 includes: the computing power node sending a registration application to the blockchain verification node, containing complete hardware and performance information (S111); the verification node sending a quantum random challenge code (256 bits, generated based on QRNG) through a QKD encrypted channel (pre-shared initial key) (S112); the applicant node digitally signing the challenge code using a built-in quantum-safe chip (national cryptographic SM2 standard) to generate a signature value (S113); the applicant node packaging the signature value with its own hardware feature code (such as CPU serial number hash value) and returning it to the verification node through an encrypted channel (S114); verifying whether the signature value matches the challenge code and node hardware features, and if so, performing the on-chain operation (S115); and outputting the unique identity identifier PID, the node identity file block, and the quantum-safe communication session key (S116).

[0060] Among them, signature verification pass rate 99.9% and hardware parameter integrity If the success rate is 100%, the on-chain operation will be executed; otherwise, the application will be rejected and additional information will be requested. The output is a unique identifier (PID), such as "G001" for GPU node 1 and "Q003" for QPU node 3. The node identity file block contains the PID, hardware parameters, and authentication timestamp. The quantum-secure communication session key is used for subsequent data transmission and is dynamically updated based on QKD.

[0061] In this step, the quantum random challenge code avoids the risk of prediction of traditional pseudo-random numbers, the quantum safe chip ensures that the signature private key is not leaked, and the blockchain notarization makes the node identity immutable, solves the problem of identity forgery in cross-domain scheduling, and improves the authentication success rate to 99.99%.

[0062] Step S12: Computing Node Capability Benchmark Modeling

[0063] Specifically, this step includes: forming a standardized capability benchmark vector based on node registration information, industry benchmark parameters, and security level assessment standards. The capability benchmark vector consists of peak computing power, energy efficiency ratio, security level, and historical response rate (S121); writing the capability benchmark vector into the blockchain through a smart contract and binding it with the PID for storage to form an initial capability profile (S122); and outputting the capability benchmark vector and the benchmark storage blockchain address (S123).

[0064] This step obtains the hardware parameters and historical data from the node registration information output in step S11. Based on industry benchmark parameters (such as the current mainstream GPU energy efficiency ratio average of 2e9 FLOPS / W) and security level evaluation standards (levels 1-5, with level 5 being the highest, based on 8 indicators including physical isolation and encryption capabilities), a capability benchmark vector is obtained. :

[0065] P (Peak computing power): CPU / GPU is measured in FLOPS, QPU is measured in equivalent QPS (quantum processing per second), and is uniformly converted to a relative value (e.g., 1.2 times the industry benchmark is recorded as 1.2), representing the maximum computing power of the node;

[0066] E (Energy Efficiency Ratio): Actual value / Industry benchmark value (e.g., node energy efficiency ratio) This reflects the computing power generated per unit of power consumption;

[0067] S (Security Level): Assessed by a third-party security organization and adjusted in conjunction with quantum encryption support (supports QKD plus 1 level), reflecting the node's security protection capabilities;

[0068] R (historical response rate): number of historical tasks / total response time, standardized to a value between 0 and 1, reflecting the node's historical task startup efficiency.

[0069] All indicators in the capability benchmark vector must be 0.5 (values ​​below this are considered edge nodes, limiting the allocation of high-priority tasks); Security Level S 2 (Meet basic encryption requirements; otherwise, only public task scheduling is allowed).

[0070] In this step, the capability indicators of heterogeneous computing power nodes are standardized to solve the cross-type evaluation problem of "CPU / GPU / QPU"; the benchmark stored on the blockchain provides a reliable reference benchmark for subsequent dynamic evaluation and avoids the evaluation benchmark from being tampered with.

[0071] In step S2, dynamic evaluation data of quantum encryption is collected in real time. This step collects dynamic evaluation data of quantum encryption based on the real-time operating status of the authentication node, ensuring the real-time nature, confidentiality, and integrity of the dynamic evaluation data. Specifically, step S2 includes:

[0072] Step S21: Deployment and Data Acquisition of Distributed Edge Sensing Network

[0073] Specifically, step S21 includes: deploying an edge sensing module on each computing node and configuring the sampling frequency (S211); collecting data in real time on the number of currently running tasks, the maximum number of tasks that can be carried, the actual calculation results, the theoretical values, the number of failures, and the transmission delay with the scheduling center to form a dynamic index vector (S212); and outputting the dynamic index vector, the data collection timestamp, and the sensing module status code (S213).

[0074] The adoption frequency is 1Hz (once per second) for normal task scenarios and 10Hz (millisecond-level response) for high-priority task scenarios.

[0075] Dynamic indicator vector :

[0076] L (Real-time load factor) = Number of currently running tasks / Maximum number of tasks that can be supported (e.g., 8 / 10 = 0.8), no unit, range of 0-1;

[0077] ΔA (accuracy deviation) = |actual calculation result - theoretical value| / theoretical value (e.g., AI model inference error 0.02 = 2%), unitless, in the range of 0-1;

[0078] F (instantaneous failure rate) = number of failures in the last 10 minutes / (10 × 60 seconds) (e.g., 1 failure is recorded as 1 / 600≈0.0017);

[0079] D (transmission delay) = RTT / 2 with the scheduling center (e.g., 40ms RTT is recorded as 20ms).

[0080] Specifically, if the integrity of the sampled data is less than 99%, a self-test of the sensor module is triggered. In addition, if at least one of the following is detected: real-time load rate > 0.95 (overload), accuracy deviation > 0.1 (accuracy not up to standard), instantaneous failure rate > 0.01 (high failure), or transmission latency > 100ms (high latency), an early warning is triggered.

[0081] In a specific example, dynamic indicator vector The data acquisition timestamp is [0.6, 0.02, 0, 20], accurate to milliseconds; the sensor module status code is 0 = normal, 1 = warning, 2 = fault.

[0082] In this step, edge hardware sensing avoids data tampering at the software level, and high sampling frequency ensures the timeliness of dynamic evaluation; four-dimensional indicators comprehensively reflect the real-time status of nodes, providing accurate input for dynamic evaluation.

[0083] Step S22: Generate quantum encryption and quantum fingerprint

[0084] Specifically, step S22 includes: using the AES-256 algorithm, encrypting the dynamic index vector and data acquisition timestamp with the session key K to generate ciphertext (S221); converting the PID and ciphertext hash value into a quantum state sequence through single-photon polarization state modulation to form a unique quantum fingerprint (S222); packaging the ciphertext, quantum fingerprint, and node PID into an encrypted transmission packet, and outputting the encrypted transmission packet and key usage record (S223).

[0085] Furthermore, the session key K provided by the QKD key pool is 256 bits and is updated every 10 minutes. This can be adjusted based on the task's security level; in high-security scenarios, the interval can be shortened to 5 minutes. It is updated from the same source as the quantum-secure communication session key generated in step S11. The node PID is used for fingerprint association.

[0086] Furthermore, if the freshness of session key K is detected to be greater than 10 minutes, a key update step is triggered.

[0087] Specifically, encrypted transmission includes ciphertext, quantum fingerprint, and PID; key usage records are used for auditing and stored on the blockchain.

[0088] In this step, quantum key encryption ensures that the data transmission process cannot be eavesdropped on; quantum fingerprints cannot be forged, providing a physical layer basis for subsequent data integrity verification, and improving the resistance to quantum attacks by 100% compared to traditional digital signatures.

[0089] Step S23: Encrypt data upload and integrity verification

[0090] Specifically, step S23 includes: sending the encrypted transmission packet to the blockchain relay node through a dedicated channel (S231); the relay node uses quantum fingerprint verification public key decryption, compares the ciphertext hash value with the fingerprint parsing result, and verifies data integrity (S232); after successful verification, the relay node associates the ciphertext with PID and timestamp, and writes it into the blockchain temporary storage area (S233); returns a reception confirmation signal containing the relay node's signature and the blockchain temporary storage area address to the edge sensing module (S234); and outputs the blockchain temporary storage area address and data reception confirmation signal (S235).

[0091] The blockchain relay node address is a preset consortium blockchain node; the quantum fingerprint verification public key is paired with the generated private key.

[0092] Furthermore, if the quantum fingerprint verification pass rate is not 100%, the data will be rejected from being uploaded to the blockchain and a retransmission will be requested. If the transmission delay exceeds 500ms, the data will be marked as "delayed data" and its evaluation metric weight will be reduced.

[0093] In this step, relay node verification ensures that the uploaded data has not been tampered with, and blockchain storage provides immutable dynamic data records; dedicated channels and latency detection ensure data timeliness and prevent outdated data from affecting the accuracy of the evaluation.

[0094] In step S3, based on the static capability benchmark and dynamically collected data stored on the blockchain using a smart contract, a multi-dimensional evaluation matrix is ​​constructed. The weights of the indicators are adaptively adjusted according to the task type, and the real-time score of the node is calculated and stored on the blockchain, providing a reliable basis for scheduling decisions. Specifically, step S3 includes:

[0095] Step S31: Construction of evaluation index system and data preprocessing

[0096] Specifically, step S31 includes: the smart contract calling the key management module to obtain the session key, decrypting the encrypted dynamic data in the blockchain temporary storage area to obtain the dynamic indicator vector (S311); preprocessing the dynamic indicator vector (S312): if a certain indicator value exceeds the historical mean ± 3 times the standard deviation, replace it with the average of the previous 3 times (S313); mapping each indicator to the 0-1 interval (S314); and constructing the evaluation matrix. Where C_base is the baseline vector for blockchain notarization capabilities, and D_real is the dynamic indicator vector. For static indicator weights, The initial values ​​of the dynamic index weights are determined through training on historical task data (S315); the preprocessed dynamic index vector and evaluation matrix are output (S316).

[0097] In step S314, the real-time load rate and instantaneous failure rate are taken as (1 - actual value) (the lower the load and the fewer the failures, the higher the score), the accuracy deviation is taken as (1 - actual value), and the transmission delay is taken as (1 - actual value / 100ms) (delay). (Valid for 100ms).

[0098] In one specific embodiment, , .

[0099] In one specific embodiment, the real-time load rate and instantaneous failure rate are taken as (1 - actual value) (the lower the load and the fewer the failures, the higher the score), the accuracy deviation is taken as (1 - actual value), and D is taken as (1 - actual value / 100ms) (latency). (Valid for 100ms)

[0100] Furthermore, if the validity of the preprocessed data is detected to be <5%, an alternative data source, such as the predicted values ​​of adjacent nodes, is enabled.

[0101] In one specific embodiment, the preprocessed dynamic index vector is normalized, such as [0.4, 0.98, 1.0, 0.8]; the evaluation matrix M is such as [0.3×1.5, 0.3×1.2, 0.3×4 / 5, 0.3×0.9; 0.7×0.4, 0.7×0.98, 0.7×1.0, 0.7×0.8].

[0102] In this step, data preprocessing eliminates noise interference, and normalization addresses the issue of differences in indicator dimensions; the evaluation matrix integrates static and dynamic characteristics to provide structured input for comprehensive scoring.

[0103] Step S32: Adaptive adjustment of dynamic indicator weights

[0104] Specifically, step S32 includes: obtaining and verifying whether the task type identifier of the current task belongs to at least one of AI training, quantum simulation, real-time inference, and general data processing (S321); detecting whether the sum of the initial index weight vector of the current task is 1, wherein the initial index weight vector includes the corresponding weights of eight benchmark indicators: peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission latency (S322); confirming whether the sensitivity coefficient in the task sensitivity coefficient table of the current task is between 0 and 1, wherein the task sensitivity coefficient table reflects the peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission latency corresponding to each task. Sensitivity coefficients for real-time load rate, accuracy deviation, instantaneous failure rate, and transmission delay (S323); Obtain the sensitivity coefficients for peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission delay corresponding to the current task from the confirmed task sensitivity coefficient table; Calculate a temporary indicator weight vector based on the sensitivity coefficients and benchmark indicator weights for peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission delay. The temporary indicator weight vector includes temporary indicator weights for peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission delay. (S324); If any of the temporary indicator weights for peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and transmission latency is detected to be greater than the maximum weight threshold for a single indicator, then the corresponding temporary indicator weight is reduced to the maximum weight threshold for a single indicator, and the reduction amount is recorded. The indicator weight vector after this temporary indicator weight reduction processing and the cumulative truncation amount are output (S325); If the security level indicator weight in the indicator weight vector is detected to be less than the minimum weight threshold for the security level indicator, the difference between the security level indicator weight and the minimum weight threshold for the security level indicator is calculated, and this difference is proportionally deducted from the indicator weights of other non-security level indicators. Add the weights to the security level indicators to obtain the indicator weight vector that meets the security lower limit (S326); calculate the sum of all indicator weights that meet the security lower limit for each indicator; if the sum of all indicator weights that meet the security lower limit for an indicator is not 1, normalize it proportionally and distribute the cumulative truncation amount proportionally to the indicators that have not exceeded the upper limit to obtain the normalized indicator weight vector (S327); uniformly process the decimal places of the indicator weights in the normalized indicator weight vector to obtain the final indicator weight vector, and output the indicator weight adjustment log on the chain. The indicator weight adjustment log on the chain includes the dynamically adjusted indicator weight vector, task type, comparison of indicator weights before and after adjustment, and adjustment timestamp (S328).

[0105] The task sensitivity coefficient table includes a preset sensitivity matrix for different task types to eight indicators, as shown in the example below:

[0106]

[0107] ΔT_P, ΔT_E, ΔT_S, ΔT_R, ΔT_L, ΔT_ΔA, ΔT_F, and ΔT_D represent, in order, peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, accuracy deviation, instantaneous failure rate, and sensitivity coefficient of transmission delay.

[0108] The adjustment factor k=0.3 is used to control the adjustment range of the indicator weights.

[0109] `max_w` (maximum weight threshold for a single indicator) is a core parameter used to constrain the upper limit of the weight of evaluation indicators. Its core purpose is to prevent any single indicator from excessively dominating the dynamic evaluation process of multi-dimensional computing power, ensuring the balance and rationality of the evaluation system. Among the eight evaluation indicators (peak computing power P, energy efficiency ratio E, security level S, historical response rate R, real-time load rate L, accuracy deviation ΔA, instantaneous failure rate F, and transmission latency D), the final weight of any single indicator must not exceed `max_w`, serving as the "ceiling" constraint in the indicator weight adjustment process. In one embodiment, the maximum weight threshold for a single indicator `max_w` is 0.4, which can be adjusted based on the scenario. For example, in a classified scenario, the `max_w` threshold for the security level indicator can be relaxed to 0.45.

[0110] min_w_S (minimum weight threshold for security level indicators) is a lower limit constraint specifically set for the security level indicator (S). Its core function is to ensure that security factors always occupy an indispensable position in multi-dimensional computing power evaluation, avoiding the sacrifice of security in pursuit of other indicators (such as computing power and efficiency). Among the eight evaluation indicators, the final indicator weight of the security level indicator (S) must not be lower than min_w_S, serving as a "safety bottom line" constraint in the indicator weight adjustment process. In one embodiment, the minimum indicator weight of the security level indicator min_w_S = 0.1, and it must not be lower than 0.08.

[0111] Apply the formula for adjusting temporary weights to each of the eight indicators: : The standardized initial weight of the i-th indicator (8 indicators, summing to 1); k: Adjustment factor (default 0.3), controlling the adjustment range of the weights; ΔT[i]: Task sensitivity coefficient of the i-th indicator (0-1 interval), reflecting the sensitivity of the task to the indicator. Taking w_D of the "real-time inference" task as an example, the initial w_D=0.2, ΔT_D=0.9, Calculate the temporary indicator weights for all indicators sequentially to form a temporary indicator weight vector w_temp.

[0112] In step S325, iterate through all indicators in w_temp and check if there exists a w_i_temp > max_w. If an indicator exceeds the limit, truncate it to max_w and record the truncation amount (excess = w_i_temp - max_w). Output the truncated indicator weight vector (w_cut) and the cumulative truncation amount (excess_total). Example: If an indicator w_i_temp = 0.45, after truncation it becomes 0.4, and excess = 0.05.

[0113] In step S326, the weights of the security level indicators are extracted. ,like Calculate the difference The weights of other non-safety level indicators are proportionally deducted (prioritizing the portion exceeding the initial indicator weights) and added to w_S_cut, outputting an indicator weight vector (w_safe) that meets the safety lower limit. Example: w_S_cut=0.08, deficit=0.02 → 0.02 is deducted from the total weights of other indicators, making w_S_cut=0.1.

[0114] In step S327, the sum of w_safe (sum_w) is calculated; if (Due to truncation or addition), normalized proportionally: Distribute the cumulative cutoff value (excess_total) proportionally to the metrics that have not exceeded the limit (prioritizing metrics with high sensitivity); output the normalized metric weight vector (w_norm, ensuring the sum is 1).

[0115] In this step, the weight of indicators is dynamically adjusted according to the task type, solving the problem of "one-size-fits-all" evaluation and improving the targeting of evaluation by 30%; ensuring the minimum weight of core indicators such as safety, and avoiding sacrificing safety for efficiency.

[0116] Step S33: Comprehensive score calculation and on-chain evidence storage

[0117] Specifically, step S33 includes: obtaining the index scores corresponding to the eight indicators from the evaluation matrix, obtaining the index weights corresponding to the eight indicators from the dynamically adjusted index weight vector, and obtaining the node real-time score based on the sum of the products of the index scores and index weights corresponding to each indicator (S331); binding the node real-time score with the PID and calculation timestamp according to the smart contract to generate a score block (S332); and writing the score block into the blockchain after consensus among the consortium chain nodes to generate an immutable score record (S333).

[0118] The real-time node scoring formula is as follows: Let M_j be the standardized score of the j-th indicator (0-1 interval, from evaluation matrix M); w''_j be the dynamically adjusted weight of the j-th indicator (summed to 1); and Score be the real-time score of the node (0-100 points, rounded to one decimal place). Example: If the values ​​of the 8 indicators in M ​​are [0.45, 0.36, 0.24, 0.27, 0.28, 0.686, 0.7, 0.56], and w'' is [0.05, 0.05, 0.1, 0.05, 0.15, 0.05, 0.1, 0.45], then... .

[0119] If a node's real-time score is detected to be outside the 0-100 range, it is considered a calculation error and the process is repeated. The consensus time is less than 2 seconds to ensure real-time scoring.

[0120] In addition, the scoring record includes indicator values, indicator weights, and intermediate results for auditing purposes. The scoring blockchain address supports querying across the entire network.

[0121] In this step, the smart contract automatically calculates the score, avoiding human intervention, and the calculation process is traceable; blockchain storage ensures that the score results are tamper-proof, providing a credible basis for cross-domain scheduling, and enhancing the credibility of the score to 100%.

[0122] In step S4, candidate nodes are screened based on real-time blockchain scoring, the optimal scheduling scheme is determined through a multi-objective optimization model, and quantum-encrypted scheduling instructions are generated to ensure secure transmission and reliable execution of the instructions. Specifically, step S4 includes:

[0123] Step S41: Extract the task type identifier, computing power requirement, time constraint, security level requirement and cost budget from the user task request, and standardize them to obtain a standardized requirement vector;

[0124] The standardized requirement vector is T = [Q_req, T_max, S_req, C_max, Type], where Q_req, T_max, S_req, C_max, and Type are the standardized values ​​for computing power requirement, time constraint, security level requirement, cost budget, and task type identifier, respectively. Specifically, computing power requirement Q_req is, for example, 1e18 FLOPS, which needs to be differentiated between classical and quantum computing power; time constraint T_max is the maximum execution time, such as 48 hours; security level requirement S_req is, for example, level 4, corresponding to nodes S≥4; cost budget C_max is, for example, 500,000 yuan; and task type identifier is, for example, "AI large model training".

[0125] Furthermore, the integrity of the task parameters during the process is checked and confirmed to be 100%; Q_req is between 10% and 80% of the total system computing power to avoid resource waste or overload.

[0126] In this step, the user's natural language requirements are transformed into machine-processable quantitative parameters, providing clear objectives for scheduling decisions; standardization ensures the comparability of task requirements and node capability indicators.

[0127] Step S42: Candidate node selection and optimization modeling based on scoring

[0128] Specifically, step S42 includes:

[0129] The dispatch center calls the blockchain API to query the real-time scores of all nodes (S421).

[0130] The filtering threshold is determined based on the task type, and the first candidate node is determined based on the real-time score not being less than the filtering threshold (S422).

[0131] If the number of first candidate nodes obtained by screening is greater than or equal to 3, then the static security level of the first candidate node is read from the blockchain, and the second candidate node is selected from the first candidate node based on the security level in the task requirement vector which is not less than the static security level (S423).

[0132] If the number of second candidate nodes obtained by screening is greater than or equal to 2, then the peak computing power of the candidate nodes is read, the minimum computing power requirement of a single node is calculated, and a third candidate node is selected from the second candidate nodes based on the peak computing power not being less than the minimum computing power requirement of a single node (S424).

[0133] If the number of third candidate nodes after screening is greater than or equal to 1, the final candidate node list is formed (S425).

[0134] Define a 0-1 variable x_i for each third candidate node: x_i=1 indicates that the node is selected, and x_i=0 indicates that it is not selected. Define a computing power allocation ratio q_i (0<q_i≤1) for the selected node: it represents the proportion of the computing power of the task undertaken by node i to the total demand Q_req (S426).

[0135] Based on the unit computing power cost c_i of nodes, and the decision variables x_i and q_i, a total cost minimization objective function is constructed: And set computing power constraints for the objective function of minimizing the total cost. Latency upper limit constraint Decision variable constraints .

[0136] Furthermore, if the number of first candidate nodes obtained through screening is less than 3, the screening threshold is lowered by 5 points each time until the number of first candidate nodes is reduced. 3. Or confirm that no nodes are available (S4230). For example, in step S423 or S4230, task Type = "AI training". ; In all nodes The nodes that score points are G001 (78 points), C002 (72 points), and Q003 (75 points). These three nodes will be retained.

[0137] Furthermore, if the number of second candidate nodes obtained from the screening is less than 2, only the node with the highest security level is retained. Even if S = S_req - 1, a "security level downgrade prompt" must be sent to the user simultaneously. After the user confirms, the process continues (S4240). For example, in step S424 or S4240, S_req = level 4; among the candidate nodes, G001 (S=4), C002 (S=3), and Q003 (S=5), C002 is excluded, leaving G001 and Q003.

[0138] Furthermore, if the number of third candidate nodes obtained from the screening is 0, it indicates insufficient computing power, and the user is prompted to reduce Q_req or extend T_max (S4250). For example, in step S425 or S4250, Q_req=6e17FLOPS, P_min=6e16FLOPS; All of them are retained, and the final candidate list is [G001,Q003].

[0139] Specifically, x_i determines "which nodes to select", and q_i determines "how many tasks each node undertakes", together forming the core decision dimensions of the scheduling scheme.

[0140] In the objective function of minimizing total cost, c_i×Q_req: the total cost of a single node to complete all tasks; q_i: the proportion of tasks undertaken by node i, so the actual cost of node i is c_i×q_i×Q_req; x_i: only selected nodes (x_i=1) are included in the total cost, and the cost of unselected nodes (x_i=0) is 0.

[0141] Example: Candidate nodes G001 (c_i = 1e-13 yuan / FLOPS), Q003 (c_i = 3e-13 yuan / FLOPS); Q_req = 6e17FLOPS; if x_G001 = 1, q_G001 = 0.6, x_Q003 = 1, q_Q003 = 0.4, then .

[0142] The meaning of satisfying the constraint is that the total computing power of all selected nodes needs to meet the constraint. The total task requirement is determined to avoid insufficient computing power preventing task completion. P_i comes from C_base, and Q_req comes from the task requirement vector T. The latency upper limit constraint ensures that the weighted average latency of all selected nodes must be less than or equal to the longest allowed task time, guaranteeing task real-time performance. D_i comes from the dynamic data collection in the large step S2.1, and T_max comes from the task requirement vector T. The decision variable constraint defines x_i as a 0-1 variable (selected / not selected); q_i as the effective proportion (0-1); and the total proportion sums to 1 (all tasks are allocated). The scheduling decision logic is preset.

[0143] Example of computing power constraints: ( );

[0144] Example of delay constraint: (satisfy);

[0145] Example of variable constraints: (satisfy).

[0146] The candidate node list obtained in this step provides the node parameters for solving the optimization model. Subsequent steps only need to calculate the optimal combination for the nodes in this list. The multi-objective optimization model with the total cost minimization objective function and constraints obtained in this step can be used as input for the optimization algorithm. The algorithm needs to find the (x_i, q_i) combination with the minimum cost within the constraints. Through this step, the transformation from evaluation results to scheduling model is realized, laying a solid foundation for the subsequent efficient solution to the optimal solution, while ensuring a balance between safety, performance, and cost.

[0147] Step S43: Solving the optimal scheduling scheme and generating quantum encryption instructions

[0148] Specifically, step S43 includes: using an improved branch and bound algorithm, based on the objective function of minimizing total cost, to select the optimal combination and computing power allocation ratio from candidate nodes under the conditions of computing power constraints, latency constraints, and variable constraints (S431); generating a scheduling instruction containing TID, a list of target node PIDs, computing power allocation q_i for each node, and execution time window (S432); encrypting the scheduling instruction with K' using AES-256 to generate an encrypted instruction packet I (S433); the scheduling center signing I with a private key to generate a signature value _I, and the final instruction packet is {I, signature value _I, quantum fingerprint of K'} (S434).

[0149] Specifically, in step S431, if G001 (60%) + C002 (40%) is selected, the following conditions are met: ; (Converted to milliseconds, this is small enough); Steps S433 and S434 respectively encrypt the instruction and attach a blockchain signature.

[0150] In this step, the optimization algorithm quickly finds the optimal solution (<100ms for a scale of 100 nodes) to meet the real-time scheduling requirements; quantum encryption and blockchain signature ensure that the instructions are not tampered with, forged or eavesdropped on, and the security of the instructions reaches the physical layer level.

[0151] Step S44: Scheduling instruction transmission and node execution

[0152] Specifically, step S44 includes: the scheduling center sending the instruction packet to the target node through a dedicated quantum channel (S441); verifying the target node based on the matching of the instantaneous failure rate F and K' of the quantum fingerprint and the verification of the blockchain signature value _I (S442); after verification, the node decrypts I with its private key to obtain the scheduling instruction details (S443); calling up computing resources according to the allocated ratio, starting the task process, the node executes the task, and returns "execution confirmation" to the scheduling center (S444).

[0153] If the command verification pass rate is not 100%, a resend request will be made, up to a maximum of 3 times. If the node resource readiness time exceeds 1 minute, a resource shortage signal will be sent.

[0154] In this step, process verification ensures that instructions are executed reliably and prevents malicious instruction injection; the real-time feedback mechanism ensures that the scheduling center is aware of the task's startup status and can handle anomalies in a timely manner.

[0155] In step S5, the node scores and evaluation model weights are updated based on the execution results of the scheduled tasks. This forms a closed-loop optimization process of evaluation, scheduling, and feedback. Specifically, step S5 includes:

[0156] Step S51: Encrypted feedback of task execution results

[0157] Specifically, step S51 includes: generating a result report containing actual computing power, actual time, actual accuracy deviation and resource utilization based on the node task execution log (S511); calculating the task completion degree (S512); encrypting the result report and task completion degree with the quantum session key, generating result ciphertext R, attaching a quantum fingerprint and sending it to the blockchain (S513).

[0158] Among them, task completion rate This refers to using the shortest board indicator. Task completion rate is between 0-100% (any percentage exceeding this range is considered a calculation error). P_act: Actual computing power provided by the node (unit: FLOPS); -Q_req: Task computing power requirement (unit: FLOPS); T_act: Actual task execution time (unit: hours / minutes, consistent with T_max); -T_max: Maximum allowed execution time for the task; ΔA_act: Actual accuracy deviation of the task; ΔA_max: Allowable accuracy deviation of the task; C: Task completion rate (0-100%, calculated using the shortest board indicator).

[0159] In this step, the task completion rate is quantified to provide an objective basis for updating node scores; quantum encryption ensures the security of the result feedback process and prevents the results from being tampered with, thus affecting the fairness of the evaluation.

[0160] Step S52: Iterative node scoring based on completion

[0161] Specifically, step S52 includes: calculating the updated score based on the task completion percentage and the node's current score read from the blockchain by the smart contract (S521); issuing an additional trigger warning flag if the task completion percentage is less than 80% (S522); writing the updated score and update timestamp to the blockchain, overwriting the old score (S523); and outputting the updated score and score update log, which includes the task completion percentage, the calculation formula for the updated score, and the old and new scores (S524).

[0162] The formula for calculating the updated score is as follows: Score_old is the current score of the node (0-100 points); C is the task completion rate; λ is the scoring iteration coefficient, generally taken as λ=0.1 to control the update magnitude; Example: C=95%, Score_old=78, then If C < 80%, an additional warning will be triggered (no points will be deducted directly; points will only be deducted after 3 warnings).

[0163] Specifically, the score update range is maintained at ≤±5 points to avoid excessive influence from a single result. If the cumulative number of warnings exceeds 3, a deep evaluation process is triggered.

[0164] In this step, the score is dynamically adjusted based on the actual task performance to make the evaluation more in line with the actual ability of the node; the smooth update mechanism avoids score fluctuations caused by accidental factors and maintains the stability of the evaluation.

[0165] Step S53: Evaluation of model weight optimization and anomaly handling.

[0166] Specifically, step S53 includes: calculating the score prediction error, minimizing the total error using the gradient descent algorithm, updating the static and dynamic indicator weights of the current evaluation model, and making the new indicator weights effective after smart contract consensus for evaluation the next day (S531); if a node is detected to have a task completion rate of <80% for 3 consecutive times, it is marked as an "inefficient node" and its allocation of high-priority tasks is restricted (S532); if quantum fingerprint verification detects data tampering, it is marked as an "untrusted node," its participation in scheduling is suspended, and manual review is triggered (S533); if the total error reduction rate after indicator weight optimization is detected to be less than 5%, the static and dynamic indicator weights of the current evaluation model are not updated (S534); and the optimized static and dynamic indicator weights of the current evaluation model, node anomaly marking, and anomaly handling instructions are output (S535).

[0167] The formula for calculating the rating prediction error is as follows: Let be the deviation between the score of the i-th node and the task completion score. This step obtains a set of task completion scores {C1, C2, ..., C...} from at least the past 24 hours. n This step also acquires records of abnormal node behavior (such as data tampering, continuous low completion rates) to perform the judgment in step S533.

[0168] Furthermore, anomaly markers must be confirmed by at least three blockchain nodes to avoid misjudgments. Node anomaly markers include "inefficient" and "untrustworthy"; anomaly handling instructions include task restrictions and suspension of eligibility.

[0169] In this step, the daily optimization of indicator weights enables the evaluation model to continuously adapt to the actual scenario, reducing the prediction error by 10%-20%; the anomaly handling mechanism eliminates low-quality or malicious nodes, ensuring the health of the scheduling ecosystem and improving the overall task completion rate of the system by 15%.

[0170] In the dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain provided by this invention, the node PID generated in step S11 runs through the entire process, serving as the benchmark for identity identification and capability association, dynamic data, scoring, scheduling instructions, and feedback results; the quantum key generated by QKD is kept updated from the same source in data acquisition, scheduling instructions, and result feedback (e.g., every 10 minutes) to ensure the consistency of the encryption system; the node score is directly used as the basis for screening candidate nodes, and the task completion degree has a feedback effect on the update of the node score, forming a closed loop.

[0171] In the dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain provided by this invention, the security level S always adopts the 1-5 standard, and S_req is directly compared with node S; parameters such as indicator weight adjustment factor k=0.3, scoring iteration coefficient λ=0.1, and minimum scoring threshold θ=60 points are kept consistent throughout the process; the time unit is unified (e.g., latency D is ms, task time T is hours) to avoid dimensional confusion.

[0172] The following describes an embodiment of the dynamic evaluation multi-dimensional computing power scheduling system integrating quantum computing and blockchain, which can be used to execute the dynamic evaluation multi-dimensional computing power scheduling method integrating quantum computing and blockchain in the above embodiments of this application.

[0173] Corresponding to the above method, this system includes an integrated blockchain module (801), a quantum security module (802), a dynamic evaluation module (803), a scheduling decision module (804), a feedback optimization module (805), and a collaborative control center (806), to achieve reliable, secure, and efficient scheduling of multi-power computing. Specifically, it includes:

[0174] The integrated blockchain module (801) is used to complete the registration of computing power nodes through quantum-enhanced two-factor authentication, generate unique identity identifiers, and build an initial capability benchmark.

[0175] The integrated blockchain module (801) includes distributed ledger nodes, a smart contract engine, a quantum-enhanced authentication unit, and an identity profile database. The quantum-enhanced authentication unit generates challenge codes via QRNG and completes node identity authentication using a quantum-safe chip; the distributed ledger stores node PIDs, capability benchmarks C_base, real-time scores, and task execution records, supporting tamper-proof evidence storage; the smart contract engine deploys contract logic such as identity registration, score updates, and anomaly handling, automatically executing trusted operations.

[0176] The quantum-secure communication module (802) is used to collect dynamic evaluation data of quantum encryption in real time. This step collects dynamic evaluation data of quantum encryption based on the real-time operating status of the authentication node, ensuring the real-time nature, confidentiality, and integrity of the dynamic evaluation data.

[0177] The quantum-secure communication module (802) includes a QKD key generator, a quantum random number generator (QRNG), a quantum encryption chip, and a dedicated transmission channel. The QKD key generator generates physical layer security keys for inter-node communication, and the key update cycle is configurable (default 10 minutes). The QRNG provides a truly random challenge code for identity authentication, avoiding the risk of pseudo-random numbers being predictable. The quantum encryption chip implements data encryption (AES-256) and quantum fingerprint generation, ensuring the confidentiality and integrity of transmitted data.

[0178] The dynamic data acquisition and evaluation module (803) is used to read the static capability benchmark and dynamic acquisition data stored on the blockchain based on the smart contract, construct a multi-dimensional evaluation matrix, adaptively adjust the indicator weights in combination with the task type, calculate the real-time score of the node and store it on the blockchain.

[0179] The dynamic data acquisition and evaluation module (803) includes an edge sensing unit, a data preprocessing engine, a multi-dimensional evaluation calculator, and a weight adaptive unit. The edge sensing unit acquires dynamic indicators such as L, ΔA, F, and D in real time, and the sampling frequency is dynamically adjusted according to the task type (1-10Hz). The data preprocessing engine performs noise reduction and normalization on the acquired data to eliminate outlier interference. The evaluation calculator calculates the real-time score based on matrix M, and the weight adaptive unit adjusts w_i according to the task type.

[0180] The scheduling decision module (804) is used to screen candidate nodes based on real-time blockchain scoring, determine the optimal scheduling scheme through a multi-objective optimization model, and generate quantum-encrypted scheduling instructions.

[0181] The scheduling decision module (804) includes a task parser, a candidate node filter, a multi-objective optimizer, and a scheduling instruction generator. The task parser extracts key parameters such as Q_req, T_max, S_req, and C_max of the user task. The candidate node filter filters nodes with a score ≥ θ based on the blockchain score. The multi-objective optimizer solves the cost minimization model to determine the optimal node combination. The scheduling instruction generator generates encrypted instructions, attaches a blockchain signature, and then issues them.

[0182] The feedback and optimization module (805) is used to update the node score and evaluation model weights based on the execution results of the scheduled tasks.

[0183] The feedback and optimization module (805) includes a result verification unit, a scoring iterator, a model update engine, and an anomaly handling unit. The result verification unit compares the actual task results with the expected indicators and calculates the task completion rate; the scoring iterator updates the node scores based on the task completion rate; the model update engine optimizes the evaluation matrix weights daily to improve evaluation accuracy; and the anomaly handling unit performs operations such as marking or pausing nodes with low completion rates or data tampering.

[0184] The collaborative control center (806) includes a system status monitoring panel, a cross-module interface gateway, and an emergency response unit; it monitors the operating status of each module in real time (such as QKD key generation rate and blockchain consensus efficiency); it realizes data interaction between modules through the interface gateway (such as pushing evaluation results to the scheduling module); and the emergency response unit triggers a degradation mechanism (such as switching to the backup key pool) when the system is abnormal.

[0185] The following section provides a detailed description of the method and system of this invention in the context of a "cross-domain AI large model training computing power scheduling" scenario.

[0186] Multi-functional computing nodes: Beijing GPU cluster (PID=G001), Shanghai Supercomputing Center (PID=C002), Hefei QPU Laboratory (PID=Q003);

[0187] User task: Train a large model with hundreds of billions of parameters. The computing power requirements are Q_req=1e18FLOPS, T_max=48 hours, S_req=4 levels, C_max=500,000 yuan.

[0188] Initial evaluation weights: , The weight of the real-time performance indicator D is w_D=0.3, and the weight of the accuracy indicator ΔA is w_ΔA=0.3.

[0189] 1. Node identity authentication and capability modeling:

[0190] The three nodes undergo quantum-blockchain dual-factor authentication, and their registration information is written into the blockchain.

[0191] (Peak computing power 1e18FLOPS, energy efficiency ratio 2e9FLOPS / W, security level 4, response rate 100 tasks / second).

[0192] ;

[0193] ;

[0194] 2. Dynamic evaluation data collection:

[0195] The edge sensing module collects real-time data:

[0196] (Load rate 60%, accuracy deviation 2%, no faults, latency 20ms);

[0197] ;

[0198] ;

[0199] Data is uploaded to the blockchain after being encrypted with a QKD key (updated every 10 minutes).

[0200] 3. Dynamic evaluation calculation:

[0201] Construct an evaluation matrix M and calculate the score based on the weights:

[0202] G001: ;

[0203] C002: Score=72 points; Q003: Score=75 points;

[0204] All nodes satisfy θ=60 points and are included as candidate nodes.

[0205] 4. Scheduling decision generation:

[0206] Multi-objective optimization model solution: Select G001 (60% computing power) + C002 (40% computing power). ; ; ;

[0207] The scheduling instructions are encrypted with a QKD key and signed by the blockchain before being sent to the two nodes.

[0208] 5. Feedback optimization:

[0209] After the task was completed, the actual execution time was 45 hours, the accuracy deviation was 1.8%, and the completion rate was C=95%.

[0210] Smart contract update rating: ;

[0211] The model updates the weights after 24 hours. , (Because dynamic indicators have a greater impact on the task).

[0212] Hardware configuration

[0213]

[0214] Software Configuration

[0215] Blockchain: Hyperledger Fabric 2.4; smart contracts are developed using the Go programming language.

[0216] Quantum encryption: Integrates QKDSDK to achieve automatic key management;

[0217] Evaluation algorithm: Implemented in Python, using the PyTorch framework to train a weight model;

[0218] Scheduling optimization: Implement the branch and bound algorithm in C++ to solve multi-objective models;

[0219] Monitoring system: Grafana + Prometheus, providing real-time visualization of system status.

[0220] Running effect

[0221] Node authentication time: <500ms (quantum challenge code generation + blockchain consensus);

[0222] Dynamic evaluation delay: <1s (from data collection to scoring on the blockchain);

[0223] Scheduling decision time: <100ms (for 100 candidate nodes);

[0224] Task completion rate: Average improvement of 15% (compared to traditional static scheduling);

[0225] Security: Successfully resisted quantum simulation attacks (Shor algorithm simulation test), with a data tampering detection rate of 100%.

[0226] If implemented in software executed by a processor, the functionality can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For instance, due to the nature of software, the functionality described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0227] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0228] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0229] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes: a USB flash drive, a read-only memory (ROM), etc. Real-time load rate (yMemory), random access memory (RAM), external hard drives, magnetic disks or optical disks, and other media that can store computer program instructions.

[0230] The relevant terminology in this application is explained as follows:

[0231] 1. Parameters related to quantum technology

[0232] Parameter name Supplementary Explanation Application scenarios QKD device transmission rate The quantum key distribution (QKD) device has a key generation rate of ≥8kbps, a transmission rate of 10kbps, and supports the 1550nm communication band (compatible with operator fiber optic networks). Step S1, quantum key generation; step S2, data encryption; and step S4, scheduling instruction encryption, ensure that key generation and transmission efficiency match the computing power scheduling requirements. Quantum Random Number Generator (QRNG) Output Rate QRNG's true random number output rate is ≥1Mbps, and the random number uniformity deviation is ≤1%, ensuring the unpredictability of challenge codes and quantum fingerprints. Step S1 generates a quantum random challenge code, and step S2 generates a quantum fingerprint to prevent pseudo-random numbers from being cracked, which could lead to identity forgery or data tampering. Quantum-safe chip encryption rate The quantum-secure chip adopts the national cryptographic standard SM2, with a signature generation rate of ≥1000 times / second, and the private key is stored in a hardware-isolated area (cannot be exported). The challenge code signing in step S1 and the scheduling instruction signing in step S4 ensure signing efficiency and private key security. Quantum fingerprint generation success rate The success rate of quantum fingerprint generation based on single-photon polarization state modulation is ≥99.9%, and the polarization state stability deviation is ≤0.05 rad (within 24 hours). The dynamic data encryption in step S2 ensures that quantum fingerprints can be generated effectively and are not easily lost due to polarization drift.

[0233] 2. Parameters related to computing power and energy efficiency

[0234] Parameter name Supplementary Explanation Application scenarios Quantum computing power equivalent conversion coefficient One quantum bit (qubit) is equivalent to 1e6 FLOPS of classical computing power (based on the parallel computing characteristics of quantum superposition, suitable for medium-complexity metric tasks). Step S1, capability benchmark modeling (QPU node P-value calculation), and step S4, candidate node computing power screening, achieve a unified evaluation of quantum and classical computing power. Maximum number of tasks a node can handle Based on the peak computing power (P) of a node and the average computing power requirement per task, for example, when a GPU node (P=1e18FLOPS) requires 1e14FLOPS per task, the maximum number of tasks it can support is 1e18 / 1e14=10000. Step S2 calculates the real-time load rate (L) (L = current number of tasks / maximum number of tasks), ensuring the accuracy of the load rate calculation. Industry benchmark energy efficiency ratio The industry benchmark energy efficiency ratio for classic computing nodes (CPU / GPU) is 2e9 FLOPS / W, while the industry benchmark energy efficiency ratio for quantum computing nodes (QPU) is 5e8 FLOPS / W (due to the power consumption characteristics of quantum computing hardware). Step S1 calculates the energy efficiency ratio (E) (E = actual node energy efficiency / industry benchmark), unifying the energy efficiency evaluation standard for heterogeneous nodes.

[0235] 3. Scheduling and Evaluation Related Parameters

[0236] Parameter name Supplementary Explanation Application scenarios Task sensitivity coefficient adjustment factor (k) The adjustment factor k defaults to 0.3, with a range of 0.1-0.5. For high-priority tasks (such as classified calculations), k is set to 0.5, while for ordinary tasks, k is set to 0.1. Step S3 involves adaptive weight adjustment (temporary weight = initial weight × (1 + k × ΔT)), controlling the weight adjustment magnitude to match the task priority. Scoring iteration coefficient (λ) The scoring iteration coefficient λ defaults to 0.1, with a range of 0.05-0.2, to avoid excessive fluctuations in the completion rate of a single task affecting the node score. Step S5 updates the node score (Score_new=Score_old×(1+λ×(C / 100-1)))) to maintain score stability. Allowable accuracy deviation for the task (ΔA_max) The default value is 0.1 (10%). For high-precision tasks (such as quantum chemistry simulations), ΔA_max = 0.02 (2%), and for ordinary tasks, ΔA_max = 0.2 (20%). Step S5 calculates the task completion rate (C=min(...,(1-ΔA_act) / (1-ΔA_max),...)), adapting to different precision requirements. Number of blockchain consensus nodes The consortium blockchain has at least 8 consensus nodes, uses the PBFT consensus algorithm, and has a consensus confirmation time of less than 2 seconds, ensuring the real-time nature of scoring and data storage. Step S1, which involves recording node identity on the blockchain, step S3, which involves recording the scoring on the blockchain, and step S5, which involves storing the results, all ensure the efficiency of blockchain operations.

[0237] 4. Parameters related to abnormal handling

[0238]

[0239] 5. Supplement to the dynamic indicator calculation logic

[0240] Indicator Name Supplementary calculation logic Application Scenarios and Data Flow Instantaneous failure rate (F) Calculation formula: F = Number of failures in the last 10 minutes / (10 × 60 seconds), where a failure is defined as a node computing power output fluctuation > 10% or a task interruption > 1 second. In step S2, dynamic data acquisition uses the F-value to evaluate node stability. An alert is triggered when F > 0.01 (once per 10 minutes), and the data is then passed to step S3 for scoring. Transmission delay (D) The moving average method is used to calculate: D = (average of the last 5 RTT measurements / 2), with an RTT measurement error ≤ 1ms, to avoid the influence of single network fluctuations. In step S2, dynamic data acquisition uses the D value for real-time evaluation. When D > 100ms, the node scoring weight is reduced. The data is then passed to step S4 to participate in the time delay constraint calculation.

[0241] 6. Supplement to the scoring logic of the evaluation matrix indicators

[0242] Indicator Name Supplementing the scoring logic (0-100 point mapping) Data Sources and Circulation Peak computing power (P) score P-score = (Node P / System maximum P-value) × 20, where the system maximum P-value is the maximum value of all node P values ​​(e.g., 1e19 FLOPS), with a maximum score of 20. In step S1, the C_base score is passed into the evaluation matrix in step S3, accounting for 20% of the total score. Security Level (S) Score S rating = S × 5 (Level 1: 5 points, Level 5: 25 points), plus 5 extra points for supporting QKD technology, maximum 25 points. In step S1, C_base is passed to the evaluation matrix in step S3, accounting for 25% of the total score (the default value of w_S=0.1 corresponds to 25 points × 0.1 = 2.5 points). Historical response rate (R) score R score = R × 20 (R is standardized to 0-1, with a maximum score of 20), R = number of historical tasks / total response time of historical tasks (unit: tasks / second). In step S1, the C_base score is passed into the evaluation matrix in step S3, accounting for 20% of the total score.

[0243] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A dynamic evaluation multi-element power scheduling method fusing quantum and blockchain, characterized in that, Comprising: Registration of computing power nodes through quantum-enhanced two-factor authentication, generation of unique identity and construction of initial capability benchmark; Based on the real-time running state of the authentication node, dynamic evaluation data of quantum encryption is collected; Based on the static capability benchmark and dynamic collected data stored in the blockchain, a multi-dimensional evaluation matrix is constructed, the index weight is adjusted adaptively according to the task type, the node real-time score is calculated and stored in the chain; Based on the real-time score of the blockchain, the candidate nodes are screened, the optimal scheduling scheme is determined through the multi-objective optimization model, and the quantum encrypted scheduling instruction is generated; Based on the execution result of the scheduling task, the node score and evaluation model weight are updated.

2. The method of claim 1, wherein, Registration of computing power nodes through quantum-enhanced two-factor authentication, generation of unique identity and construction of initial capability benchmark, including: Quantum-enhanced node registration and identity authentication; Capability benchmark modeling of computing power nodes.

3. The method of claim 1, wherein, Based on the real-time running state of the authentication node, dynamic evaluation data of quantum encryption is collected, including: Distributed edge sensor network deployment and data collection; Generation of quantum encryption and quantum fingerprint; Chaining and verifying the integrity of encrypted data.

4. The method of claim 1, wherein, Based on the static capability benchmark and dynamic collected data stored in the blockchain, a multi-dimensional evaluation matrix is constructed, the index weight is adjusted adaptively according to the task type, the node real-time score is calculated and stored in the chain, including: Evaluation index system construction and data preprocessing; Dynamic index weight adaptive adjustment; Comprehensive score calculation and chain storage.

5. The method of claim 1, wherein, Based on the real-time score of the blockchain, the candidate nodes are screened, the optimal scheduling scheme is determined through the multi-objective optimization model, and the quantum encrypted scheduling instruction is generated, including: Extracting task type identifier, computing power demand, time constraint, security level demand and cost budget from user task request, standardizing to get standardized demand vector; Based on the scoring of candidate nodes, screening and optimization modeling; Optimal scheduling scheme solving and quantum encryption instruction generation; Transmission of scheduling instruction and node execution.

6. The method of claim 1, wherein, Based on the execution result of the scheduling task, the node score and evaluation model weight are updated, including: Encrypted feedback of task execution result; Node score iteration based on completion degree; Evaluation model index weight optimization and abnormal handling.

7. The method of claim 2, wherein, Quantum-enhanced node registration and identity authentication, including: The computing power node sends a registration application to the blockchain verification node, containing complete hardware and performance information; The verification node sends a quantum random challenge code through the QKD encryption channel; The applicant node uses the built-in quantum security chip to digitally sign the challenge code and generates a signature value; The applicant node packs the signature value and its own hardware feature code and returns them to the verification node through the encryption channel; Verify whether the signature value matches the challenge code and node hardware features, and if so, perform the on-chain operation; Output unique identity PID, node identity profile block and quantum secure communication session key.

8. The method of claim 4, wherein, Dynamic index weight adaptive adjustment, including: Obtain and verify whether the task type identifier of the current task belongs to at least one of AI training, quantum simulation, real-time inference and ordinary data processing; detecting whether the initial indicator weight vector of the current task is 1, the initial indicator weight vector including corresponding eight benchmark indicator weights of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay; confirming whether the sensitivity coefficients in the task sensitivity coefficient table of the current task are between 0 and 1, the task sensitivity coefficient table reflecting the sensitivity coefficients of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay corresponding to each task respectively; obtaining the sensitivity coefficients of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay corresponding to the current task from the confirmed task sensitivity coefficient table, and calculating a temporary indicator weight vector according to the sensitivity coefficients of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay and the benchmark indicator weights, the temporary indicator weight vector including temporary indicator weights of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay; if any of the temporary indicator weights of peak computing power, energy efficiency ratio, security level, historical response rate, real-time load rate, precision deviation, instantaneous failure rate and transmission delay is greater than a single-indicator maximum weight threshold, reducing the corresponding temporary indicator weight to the single-indicator maximum weight threshold, recording the reduction amount, and outputting the indicator weight vector after the temporary indicator weight reduction processing and the cumulative truncation amount; if the security level indicator weight in the indicator weight vector is less than a security level indicator minimum weight threshold, calculating the difference between the security level indicator weight and the security level indicator minimum weight threshold, deducting the difference from the indicator weights of other non-security level indicators in proportion, and adding the difference to the security level indicator weight to obtain an indicator weight vector satisfying the security lower limit; calculating the sum of all indicator weights satisfying the security lower limit of each indicator, if the sum of all indicator weights satisfying the security lower limit of the indicator is not 1, normalizing it in proportion, and distributing the cumulative truncation amount to indicators not exceeding the upper limit in proportion to obtain a normalized indicator weight vector; performing unified processing on the decimal places of the indicator weights in the normalized indicator weight vector to obtain a final indicator weight vector, and outputting an indicator weight adjustment log chain, the indicator weight adjustment log chain including the dynamically adjusted indicator weight vector, the task type, the comparison of the indicator weights before and after adjustment, and the adjustment timestamp.

9. The method of claim 4, wherein, comprehensive score calculation and chain storage, including: obtaining indicator scores corresponding to eight indicators from an evaluation matrix, obtaining indicator weights corresponding to eight indicators from a dynamically adjusted indicator weight vector, and obtaining a node real-time score according to the sum of the products of the indicator scores and the indicator weights corresponding to each indicator; binding the node real-time score, PID and calculation timestamp according to a smart contract to generate a score block; The score block is written into the blockchain after consensus by the alliance chain node, generating an unalterable score record. 10.A dynamic evaluation multi-element computing power scheduling system fusing quantum and blockchain, characterized in that, Comprise: An integrated blockchain module is used to complete the registration of the computing power node through quantum-enhanced two-factor authentication, generate a unique identity, and build an initial capability benchmark; A quantum secure communication module is used to collect dynamic evaluation data of quantum encryption in real time. Based on the real-time running state of the authentication node, dynamic evaluation data of quantum encryption is collected to ensure the real-time, confidentiality and integrity of the dynamic evaluation data; A dynamic data collection and evaluation module is used to read the static capability benchmark stored in the blockchain and the dynamically collected data based on the smart contract, build a multi-dimensional evaluation matrix, adaptively adjust the index weight according to the task type, calculate the real-time score of the node, and store it in the chain for evidence; A scheduling decision module is used to select candidate nodes based on real-time scoring of the blockchain, determine the optimal scheduling scheme through a multi-objective optimization model, and generate a quantum encryption scheduling instruction; A feedback and optimization module is used to update the node score and evaluation model weight based on the execution result of the scheduling task.

Images