Method and system for quickly switching double-password system

Abstract

The invention discloses a quick switching method and system for a double-password system. According to the method, a private identifier is generated based on a unique identifier of equipment and biological characteristic information of a user, a double-password system key pair is generated according to the identifier and channel state information, an optimal password system selection result is obtained through security strength and performance evaluation, a switching instruction set is generated, and a block is allocated for privilege; and confirming the final block according to the block privilege, and executing cryptosystem switching. According to the method and the device, the problems of low key generation reliability and low switching efficiency among the password systems in a channel uncertainty environment in the prior art are solved, and a password system switching mechanism with high efficiency is realized while the security is guaranteed.

Description

Technical Field

[0001] This application relates to the fields of cryptography and blockchain technology, and particularly to a method and system for rapid switching of a dual-cryptosystem. Background Art

[0002] Cryptography is a key technical field for ensuring information security. With the improvement of computing power and the development of quantum computing, existing cryptosystems are facing increasing security challenges. In the modern network communication environment, the secure generation, distribution, and management of keys have always been the core issues of the security of cryptosystems.

[0003] Traditional cryptosystems usually adopt symmetric encryption or asymmetric encryption technologies. Symmetric encryption such as the AES algorithm has the advantage of fast encryption and decryption speed, but key distribution is difficult; asymmetric encryption such as RSA, ECC, etc. algorithms solve the key distribution problem, but have high computational complexity and may face security risks in the quantum computing environment. In blockchain technology, common consensus mechanisms such as Proof of Work (PoW) consume a large amount of computing resources, while Proof of Stake (PoS) may lead to centralization problems.

[0004] The currently more advanced technology is the hybrid cryptosystem, which combines the advantages of symmetric and asymmetric encryption and realizes distributed trust through blockchain technology. This technology usually depends on deterministic channel conditions and static identity identifiers during key generation, and depends on specific hardware facilities or a large amount of resource investment during the block generation process.

[0005] However, the reliability of key generation of this hybrid cryptosystem is low in an environment with high channel uncertainty, and the switching efficiency between cryptosystems is not high, resulting in insufficient system adaptability when security requirements change. At the same time, existing blockchain consensus mechanisms either consume too many resources or require special hardware support, lacking a fair and efficient block proposal mechanism and unable to balance the relationship between decentralization and finality well. Summary of the Invention

[0006] In view of this, this application provides a method and system for rapid switching of a dual-cryptosystem, which solves the problems of low reliability of key generation and low switching efficiency between cryptosystems in the prior art in an environment with channel uncertainty. Embodiments of this application provide a method for rapid switching of a dual-cryptosystem, including:

[0007] Generating a private identifier by using a multi-factor fusion algorithm according to the device unique identifier and the user biometric information; generating a dual-cryptosystem key pair according to the private identifier and the channel state information;

[0008] Performing a security strength evaluation and a performance requirement evaluation on the dual-cryptosystem key pair to obtain an optimal cryptosystem selection result;

[0009] Generate a cryptographic system switching instruction set according to the optimal cryptographic system selection result; allocate the block proposal right based on the cryptographic system switching instruction set;

[0010] Confirm the final block according to the block proposal right allocation result; perform the switching of the dual cryptographic system based on the confirmation result of the final block.

[0011] Generate a dual cryptographic system key pair according to the private identifier and channel status information, including:

[0012] Use the private identifier and the real-time collected channel status information to generate a high-entropy random seed by using an entropy extraction function; generate a symmetric key and an asymmetric key pair according to the high-entropy random seed through a key derivation function;

[0013] Perform quantum resistance verification on the symmetric key and the asymmetric key pair, and output a dual cryptographic system key pair that has passed security verification.

[0014] Perform a security strength evaluation and a performance requirement evaluation on the dual cryptographic system key pair to obtain an optimal cryptographic system selection result, including:

[0015] Use the dual cryptographic system key pair and the current system security requirement parameters to generate a key security strength score through a security strength evaluation algorithm; generate a comprehensive applicability score by using a performance-security balance function according to the key security strength score and the system performance requirement parameters; output a preliminary cryptographic system selection result through a decision tree algorithm based on the comprehensive applicability score and a preset threshold; generate an optimal cryptographic system selection result through time series analysis based on the preliminary cryptographic system selection result and historical switching records.

[0016] Generate a cryptographic system switching instruction set according to the optimal cryptographic system selection result, including:

[0017] Use the optimal cryptographic system selection result and the current system operating state to generate a state transition description through a state difference analyzer;

[0018] Output a resource allocation plan through a resource optimization scheduling algorithm according to the state transition description and system resource monitoring data;

[0019] Generate a cryptographic system switching instruction set by using a timing optimization algorithm according to the resource allocation plan and system response ability parameters.

[0020] Allocate the block proposal right based on the cryptographic system switching instruction set, including:

[0021] Generate a lottery serial number by using a distributed random number generation protocol based on the cryptographic system switching instruction set and network node information;

[0022] Output a node qualification certificate via a verifiable random function based on the lottery serial number and the proof of resources held by the node; obtain a list of qualified nodes through a distributed verification process based on the node qualification certificate and the network-wide verification rules;

[0023] Generate a block proposal right allocation result using a probability allocation mechanism according to the list of qualified nodes and the lottery matching algorithm.

[0024] Confirm the final block according to the block proposal right allocation result, including:

[0025] Generate a candidate block proposal by the node that obtains the proposal right according to the block proposal right allocation result and the preset block template; generate a node reputation score based on the candidate block proposal and the historical behavior records of each node;

[0026] Obtain the block voting result through a weighted voting mechanism using the node reputation score, resource contribution value, and voting weight allocation rules;

[0027] Generate the final block confirmation result through a consensus confirmation algorithm according to the block voting result and the finality condition parameters.

[0028] Generate a node reputation score based on the candidate block proposal and the historical behavior records of each node, including:

[0029] Extract the historical records of the node's participation in block proposal and verification, proposal quality statistics, and community contribution data from the candidate block proposal as the historical behavior records;

[0030] Use the historical behavior records to calculate and output the node basic score via objective measurement indicators;

[0031] Generate the node reputation score through a time decay function according to the node basic score and node behavior pattern analysis.

[0032] Generate the block voting result through a weighted voting mechanism using the node reputation score, resource contribution value, and voting weight allocation rules, including:

[0033] Use the node reputation score and resource contribution value to output the node voting weight via a voting weight calculation function; collect multiple rounds of voting data of the node on the candidate block according to the node voting weight;

[0034] Generate the block voting result using a weighted statistical algorithm based on the voting data and the abnormal voting recognition result.

[0035] Generate the final block confirmation result through a consensus confirmation algorithm according to the block voting result and the finality condition parameters, including:

[0036] Determine whether the block voting result reaches the preset finality condition and output the verification result; according to the verification result, conduct extended voting on the blocks that do not reach the threshold to obtain supplementary voting data;

[0037] Based on the supplementary voting data, update the status of the block voting result to generate the final block confirmation result.

[0038] Based on the confirmation result of the final block, perform a fast switch of the dual-cryptosystem, including:

[0039] Adopt the final block confirmation result and parallelly initialize the operating environment of the target cryptosystem through a double-buffer mechanism;

[0040] According to the operating environment of the target cryptosystem, use the session state migration function to complete the state transfer of the current session;

[0041] Based on the state transfer result, synchronously switch the cryptosystem configurations of all nodes in the network through an atomic update operation. The embodiments of the present application also provide a dual-cryptosystem fast-switching system, including:

[0042] An identifier generation module, configured to generate a private identifier using a multi-factor fusion algorithm according to the device unique identifier and the user biometric information;

[0043] A key generation module, which outputs a dual-cryptosystem key pair based on the private identifier and the channel status information;

[0044] A cryptosystem evaluation module, configured to perform a security strength evaluation and a performance requirement evaluation on the dual-cryptosystem key pair to obtain the optimal cryptosystem selection result;

[0045] An instruction set generation module, configured to generate a cryptosystem switching instruction set according to the optimal cryptosystem selection result;

[0046] A block proposal right allocation module, configured to allocate the block proposal right based on the cryptosystem switching instruction set;

[0047] A block confirmation module, configured to confirm the final block according to the block proposal right allocation result;

[0048] A switching module, configured to perform the switch of the dual-cryptosystem based on the confirmation result of the final block.

[0049] An embodiment of the present application also provides a computer device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the above-mentioned dual-cryptosystem fast-switching method.

[0050] An embodiment of the present application also provides a computer-readable storage medium, which stores computer instructions for causing a computer to execute the above-mentioned dual-cryptosystem fast-switching method. An embodiment of the present application also provides a computer program product, including computer instructions, which implement the steps of the above-mentioned dual-cryptosystem fast-switching method when executed by a processor.

[0051] The present application has the following technical effects: Through an adaptive key generation algorithm based on private identifiers and channel status information, it is possible to generate a secure and reliable dual-cryptosystem key pair in an environment of channel uncertainty, support fast switching, and improve system security and adaptability.

[0052] By evaluating the security strength and performance requirements of the dual-cryptosystem key pair, obtaining the optimal cryptosystem selection result, and generating a cryptosystem switching instruction set based on it, the dynamic optimization selection of the cryptosystem is realized.

[0053] According to the block proposal right allocation result, confirm the final block, and based on the confirmation result of the final block, execute the switching of the dual-cryptosystem, realizing the efficient switching of the cryptosystem, significantly reducing the switching delay, and improving the system's response ability to changes in the security environment. Description of the Drawings

[0054] To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. The drawings here are incorporated into the specification and constitute a part of this specification. These drawings show embodiments that conform to the present disclosure and are used together with the specification to illustrate the technical solutions of the present disclosure. It should be understood that the following drawings only show some embodiments of the present disclosure and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0055] Figure 1 It is a flowchart of the dual-cryptosystem fast-switching method provided by the embodiment of the present application;

[0056] Figure 2 It is a specific flowchart of step S2 provided by the embodiment of the present application;

[0057] Figure 3 This is the specific flowchart of step S3 provided by the embodiment of the present application;

[0058] Figure 4 This is the specific flowchart of step S4 provided by the embodiment of the present application;

[0059] Figure 5 This is the specific flowchart of step S5 provided by the embodiment of the present application;

[0060] Figure 6 This is the framework diagram of the dual - password system fast - switching system provided by the embodiment of the present application. Detailed implementation manners

[0061] As Figure 1 shown, the embodiment of the present application provides a dual - password system fast - switching method, including:

[0062] S1: Generate a private identifier using a multi - factor fusion algorithm according to the device unique identifier and the user biometric information;

[0063] This step requires obtaining two types of initial input data: the device unique identifier and the user biometric information. The device unique identifier usually includes information such as the hardware serial number, MAC address, CPU ID, etc. that can uniquely identify a physical device, and these information have the characteristics of being difficult to copy and forge. The user biometric information includes biometric recognition data such as fingerprint feature points, iris textures, facial feature vectors, or voiceprint features, and these data have uniqueness and persistence.

[0064] Use a multi - factor fusion algorithm to process these two types of data. Specifically, first, normalize the device identifier, convert different types of device identifiers into a binary sequence of a unified format; at the same time, extract features from the biometric data, convert the high - dimensional biometric features into a feature vector of a fixed length. Then combine these two parts of information through a weighted fusion method. For example, feature - level fusion based on principal component analysis (PCA) or decision - level fusion based on support vector machine (SVM) can be used.

[0065] To enhance security, a non - linear transformation and a random salt value are introduced during the fusion process to ensure that even if part of the original input data is obtained, it is difficult to reverse - infer the complete fusion result. This non - linear transformation can be implemented by means of a one - way hash function or a neural network, etc., effectively preventing reverse - engineering attacks.

[0066] Through the above processing steps, a private identifier with high entropy and difficult to replicate is output. This identifier combines the physical uniqueness of the device and the biometric uniqueness of the user, providing a reliable entropy source basis for subsequent key generation. This private identifier has sufficient length (usually not less than 256 bits) and entropy value to effectively resist brute-force attacks and predictive attacks.

[0067] S2: Generate a dual-cryptosystem key pair based on the private identifier and channel status information;

[0068] This step first uses the private identifier and the channel status information collected in real time, and uses an entropy extraction function to generate a high-entropy random seed. The channel status information refers to the change parameters in the communication environment, including physical layer parameters such as signal-to-noise ratio, channel attenuation, multipath effect, frequency offset, etc., and network layer parameters such as network delay, packet loss rate, jitter, etc. A specially designed entropy extraction function is used to process these two parts of information. First, the channel status information is quantified into a discrete numerical sequence, and then the sliding window method is used to capture the time-varying characteristics of the channel status and extract the randomness components therein. To enhance randomness, a randomness amplifier based on the von Neumann entropy extractor or hash collision technology is used to convert the weak randomness in the channel status information into strong randomness. Then, based on the high-entropy random seed, a symmetric key and an asymmetric key pair are generated through a key derivation function (KDF). Implementations of KDF that comply with the NIST SP 800-108 standard, such as HKDF or PBKDF2, etc., are used to generate different types of key materials for the symmetric key and the asymmetric key pair. Quantum resistance verification is performed on the generated symmetric key and asymmetric key pair, and a dual-cryptosystem key pair that has passed the security verification is output. This verification process includes multiple aspects such as key length and entropy value evaluation, quantum computing complexity evaluation, and randomness testing, ensuring that the key has sufficient security strength and quantum computing resistance.

[0069] S3: Evaluate the security strength and performance requirements of the dual-cryptosystem key pair to obtain the optimal cryptosystem selection result;

[0070] Using the key pairs of the dual - password system and the current security requirement parameters, a key security strength score is generated through a security strength evaluation algorithm. The security strength evaluation algorithm is used to evaluate the keys. For symmetric keys, its entropy value, length, and resistance to brute - force attacks are mainly evaluated; for asymmetric key pairs, in addition to evaluating the computational difficulty of basic problems, the efficiency of the known best attack algorithms, the quantum computing impact coefficient, and the feasibility of side - channel attacks are also considered. According to the key security strength score and the performance requirement parameters, a comprehensive applicability score is generated using a performance - security balance function. A performance - security balance function is constructed. This function uses a multi - objective optimization model, taking security strength and performance consumption as two competing objectives, and generates a comprehensive applicability score for each password system. Then, based on the comprehensive applicability score and a preset threshold, through a decision tree algorithm, a preliminary password system selection result is output. The root node of the decision tree makes a preliminary classification based on the main security requirements, and then at each branch node, the decision - making path is further refined according to conditions such as performance constraints, resource availability, and communication environment characteristics. Based on the preliminary password system selection result and the historical switching records, through time - series analysis, an optimal password system selection result is generated. The time - series analysis method is used to study the switching mode, identify the periodic, trend, and sudden patterns in the switching behavior, and introduce a stability constraint mechanism to prevent the password system from switching too frequently.

[0071] S4: Generate a password system switching instruction set according to the optimal password system selection result;

[0072] Using the optimal password system selection result and the current running state, a state transition description is generated through a state difference analyzer. The state difference analyzer compares and analyzes the states of the target password system and the current password system, establishes a state vector model, calculates the difference between the current state vector and the target state vector, and constructs a minimum state transition path based on the difference analysis result. According to the state transition description and the resource monitoring data, a resource allocation plan is output through a resource optimization scheduling algorithm. The resource optimization scheduling algorithm analyzes and allocates the resources required for the switching process, and adopts a phased resource reservation strategy to improve resource utilization efficiency. According to the resource allocation plan and the response - ability parameters, a password system switching instruction set is generated using a timing optimization algorithm. The timing optimization algorithm adjusts and rearranges the instruction sequence, establishes an instruction - dependence graph, identifies the sequential and data dependencies between instructions, and then applies the critical - path analysis method to find the instruction chain that determines the total execution time, and adopts various optimization strategies, including instruction reordering, instruction parallelization, and pre - fetch optimization, etc.

[0073] S5: Allocate the block proposal right based on the password system switching instruction set;

[0074] Based on the cryptographic system switching instruction set and network node information, a lottery serial number is generated using a distributed random number generation protocol. The distributed random number generation protocol is used to generate the lottery serial number. This protocol is based on an extended version of the bit commitment model, which requires each participating node to first generate a local random number and then calculate its cryptographic commitment. When all the commitments from all nodes are collected, the revelation phase is initiated. All the collected valid random numbers are combined through a deterministic algorithm to generate a globally recognized random source. According to the lottery serial number and the resource proof held by the node, a node eligibility proof is output via a verifiable random function. A verifiable random function (VRF) is used to process the lottery serial number and the resource proof. Each node uses its private key as the seed key of the VRF, takes the hash of the lottery serial number and the resource proof as the input, and calculates the VRF output and proof. Then, based on the node eligibility proof and the network-wide verification rules, a list of qualified nodes is obtained through a distributed verification process. The distributed verification process is initiated, and multiple verification nodes in the network process the eligibility proofs in parallel. Each verification node independently executes the verification steps, including checking the integrity and format compliance of the eligibility proof, verifying the validity of the node signature, etc. Based on the list of qualified nodes and the lottery matching algorithm, a block proposal right allocation result is generated using a probability allocation mechanism. The probability allocation mechanism is initiated to allocate the block proposer for each time slot, and a multi-round lottery mechanism is adopted to ensure the fairness and unpredictability of the allocation process.

[0075] S6: Confirm the final block according to the block proposal right allocation result;

[0076] According to the block proposal right allocation result and the preset block template, the node that obtains the proposal right generates a candidate block proposal. The node that obtains the proposal right for the current time slot initiates the block proposal generation process, verifies its own proposal eligibility, selects the transactions to be processed from the transaction pool, packs the selected transactions into the block according to the preset format, and calculates the relevant derived data. Then, it signs the block proposal using its private key to generate a complete candidate block proposal. Based on the candidate block proposal and the historical behavior records of each node, a node reputation score is generated. The reputation calculation model is initiated to evaluate the block proposer and the verification nodes. A multi-level scoring mechanism is adopted to ensure the objectivity and anti-manipulation of the reputation score. Then, using the node reputation score, the resource contribution value, and the voting weight allocation rules, the block voting result is obtained through a weighted voting mechanism. The weighted voting mechanism is initiated to invite the qualified verification nodes to vote on the candidate block proposal. A multi-round voting and threshold confirmation mechanism is adopted to enhance the reliability and anti-attack ability of the voting. According to the block voting result and the finality condition parameters, the final block confirmation result is generated through a consensus confirmation algorithm. The consensus confirmation algorithm is initiated to further process and analyze the voting result, verify whether the voting process meets the protocol requirements, compare the voting result with the finality conditions, and determine whether the block meets the threshold requirements for final confirmation.

[0077] S7: Perform the switch of the dual - cipher system based on the confirmation result of the final block.

[0078] Steps for performing the switch of the dual - cipher system based on the confirmation result of the final block. First, use a double - buffering mechanism to initialize the operating environment of the target cipher system in parallel, including loading relevant cipher libraries, warming up the key generation and processing pipelines, and preparing necessary resources. This parallel initialization method ensures that all preparatory work for the new cipher system has been completed before the official switch, minimizing service interruptions during the switch. Perform session - state migration. For existing active encryption sessions, use a dedicated state - migration function to seamlessly transfer session parameters, key materials, and ongoing transactions from the current cipher system to the target cipher system. This process employs a secure key - conversion protocol to ensure that the confidentiality and integrity of session data are not compromised even during the migration. Synchronize the cipher - system configurations of all nodes in the switched network through an atomic update operation. This operation uses a two - phase commit protocol to ensure that all nodes either successfully switch completely or roll back to the original state entirely, avoiding the risk of network partitioning. After the switch is completed, a comprehensive post - switch verification is carried out to confirm that all components of the new cipher system are working properly, and a log of the switch result is recorded to provide a basis for optimization and auditing.

[0079] Through the implementation of the above steps, the present invention realizes reliable key generation and efficient switch of the cipher system in an environment of channel uncertainty. At the same time, through an innovative blockchain mechanism, it ensures the fairness and reliability of the switch process, providing a new security - enhancement solution for modern cryptography.

[0080] As Figure 2 shown, step S2 generates a dual - cipher - system key pair according to the private identifier and channel - state information, specifically including:

[0081] S2.1: Use the private identifier and the channel - state information collected in real - time, and generate a high - entropy random seed by using an entropy - extraction function.

[0082] This step takes the private identifier generated in step S1 as the basic input and processes it in combination with the channel - state information collected in real - time. The channel - state information refers to the changing parameters in the communication environment, including physical - layer parameters such as signal - to - noise ratio, channel attenuation, multipath effect, frequency offset, etc., and network - layer parameters such as network delay, packet - loss rate, jitter, etc. These parameters are random and unpredictable, especially in wireless communication or complex network environments.

[0083] A specially designed entropy extraction function is used to process these two parts of information. The entropy extraction function first quantizes the channel state information into a discrete numerical sequence, and then uses the sliding window method to capture the time-varying characteristics of the channel state and extract the randomness component therein. In this process, possible deterministic patterns and periodic variations are removed, and only the truly random part is retained.

[0084] To enhance randomness, a randomness amplifier based on the von Neumann entropy extractor or hash collision technology is used to convert the weak randomness in the channel state information into strong randomness. At the same time, the private identifier is used as the initial seed and mixed with the extracted channel randomness, and processed using a cryptographically secure pseudorandom number generator such as HMAC-DRBG or SHA-3.

[0085] After the above processing, a random seed with a high entropy value is output. This random seed combines the randomness of the user identity, device characteristics, and channel environment, and has high unpredictability and non-reproducibility. Even under the same user and device conditions, due to differences in the channel state, the random seeds generated each time will be significantly different, thus providing strong randomness guarantee for subsequent key generation.

[0086] S2.2: Generate a symmetric key and an asymmetric key pair through a key derivation function according to the high-entropy random seed;

[0087] This step takes the high-entropy random seed generated in step S2.1 as the basic input. This random seed contains sufficient entropy value, which is a necessary prerequisite for generating high-quality keys. The key derivation function (KDF) is a class of algorithms that can derive one or more keys from the initial key material, and it can expand the input of finite length into the key material of any required length.

[0088] Implementations of KDF that comply with the NIST SP 800-108 standard are adopted, such as HKDF (HMAC-based KDF) or PBKDF2, etc. These KDFs will first preprocess the input random seed, including padding and formatting, and then expand it through multiple rounds of hash operations or block cipher-based pseudorandom functions. To enhance security, context information (such as application identifier, key usage identifier, etc.) is introduced as an auxiliary input during the KDF process to ensure that even if the same random seed is used, the keys generated for different purposes are independent of each other.

[0089] To support both symmetric and asymmetric encryption cryptosystems simultaneously, the KDF generates two different types of key materials. For symmetric keys, a bit string of an appropriate length (e.g., 256 bits) is directly extracted from the KDF output as the key for algorithms such as AES or ChaCha20. For an asymmetric key pair, a deterministic key generation method, such as the method described in RFC 6979, is used to generate a private key that meets the requirements of elliptic curve cryptography (ECC) or lattice cryptography from the KDF output, and then the corresponding public key is derived through a standard public key generation function.

[0090] Through the above key derivation process, a complete set of key materials for a dual-cryptosystem is output, including a session key for symmetric encryption and a public-private key pair for asymmetric encryption. These key materials have cryptographic security, and due to the use of the same random seed source, there is a cryptographic binding relationship between them, which facilitates the subsequent rapid switching of the cryptosystem.

[0091] S2.3: Perform quantum resistance verification on the symmetric key and the asymmetric key pair, and output a dual-cryptosystem key pair that has passed security verification.

[0092] This step takes the symmetric key and the asymmetric key pair generated in step S2.2 as input, and performs quantum computing resistance evaluation and security verification on them. With the development of quantum computing technology, traditional cryptographic algorithms face new security challenges. For example, the Shor algorithm can effectively break asymmetric cryptography based on factorization and discrete logarithm problems. Therefore, it is crucial to perform quantum resistance verification on the generated keys.

[0093] Adopt a multi-level verification strategy. First, evaluate the key length and entropy value to ensure that the key materials have sufficient complexity and unpredictability; then, for the asymmetric key pair, evaluate the quantum computing complexity of the mathematical problems it is based on, and prefer to select post-quantum cryptography (PQC) such as lattice cryptography, hash-based signatures, or homomorphic encryption-based schemes. For traditional elliptic curve key pairs, evaluate the security of their curve parameters to ensure that they meet the current highest security standards (such as NIST P-384 or higher).

[0094] Use standard cryptographic test suites to perform randomness tests on the keys, such as the tests specified in NIST SP 800-22, including frequency tests, block frequency tests, run tests, longest run tests, etc., to ensure that the keys have no statistical biases or patterns. At the same time, independence verification of the key materials will also be carried out to ensure that there is no exploitable correlation between the symmetric key and the asymmetric key.

[0095] After comprehensive security verification, a set of verified dual-cryptosystem key pairs is output. These keys meet the current highest cryptographic security standards and have a certain degree of resistance to quantum computing, and can maintain security for a certain period in the future quantum computing environment. At the same time, a key security metric report will be generated to provide a decision-making basis for subsequent cryptosystem selection.

[0096] As Figure 3 shown, step S3 performs a security strength assessment and a performance requirement assessment on the dual-cryptosystem key pairs to obtain the optimal cryptosystem selection result, specifically including:

[0097] S3.1: Using the dual-cryptosystem key pairs and the current security requirement parameters, generate a key security strength score through a security strength assessment algorithm;

[0098] This step takes the verified dual-cryptosystem key pairs output by step S2 as the basic input, and at the same time collects the current security requirement parameters. These security requirement parameters include data sensitivity levels (such as public, internal, confidential, top secret, etc.), expected confidentiality periods (such as days, months, years, decades, etc.), estimated computing resources of potential attackers, risk tolerance, and applicable security standards and compliance requirements, etc.

[0099] The multi-dimensional security strength assessment algorithm is used to evaluate the keys. For symmetric keys, mainly evaluate their entropy value, length, and resistance to brute-force attacks. According to cryptographic theory, an n-bit symmetric key theoretically requires 2^n operations to be cracked. Combining the current and expected development trends of computing technologies, calculate the effective security strength of the key. For asymmetric key pairs, in addition to evaluating the computational difficulty of the basic problems, also consider the efficiency of the known best attack algorithms, the quantum computing impact coefficient, and the feasibility of side-channel attacks.

[0100] Map and compare the security strength of each key with the security requirement parameters, and use a risk analysis model (such as an improved version of the CVSS score) to quantitatively evaluate the performance of the key in various attack scenarios. In this process, consider the time factor, that is, the decay curve of the key security strength as the computing power increases and new attack methods emerge. According to the urgency and importance of security requirements, assign different weights to different dimensions of security attributes.

[0101] Through comprehensive calculation, a standardized security strength score is generated for each key, usually using a 0-100 scoring system, where the higher the score, the stronger the security strength. This score reflects the security applicability of the key in the current and foreseeable future, providing a scientific quantitative basis for subsequent cryptosystem selection. At the same time, the key influencing factors in the score, such as quantum computing risks, basic algorithm strength, or key length, etc., will also be marked for subsequent analysis.

[0102] S3.2: Generate a comprehensive applicability score using a performance-security balance function based on the key security strength score and performance requirement parameters.

[0103] This step is based on the key security strength score generated in step S3.1 and comprehensively evaluates by combining the performance requirement parameters. The performance requirement parameters include available computing resources (CPU, memory, dedicated encryption hardware, etc.), the maximum acceptable encryption / decryption latency, communication bandwidth limitations, upper limit of power consumption (especially in mobile or Internet of Things devices), and the ability to handle concurrent requests, etc.

[0104] Construct a performance-security balance function that adopts a multi-objective optimization model, taking security strength and performance consumption as two competing objectives. Specifically, for symmetric encryption (such as AES-256, ChaCha20, etc.), measure the encryption / decryption speed, memory occupancy, and energy consumption under different key lengths, block modes, and implementation methods; for asymmetric encryption (such as RSA, ECC, post-quantum algorithms, etc.), measure performance metrics such as key generation time, signature / verification time, encryption / decryption time, and communication overhead.

[0105] Dynamically adjust the weights of security and performance according to the current application scenario and communication environment. For example, in high-security requirement environments (such as financial transactions, military communications), the security weight will be increased; while in resource-constrained environments (such as Internet of Things devices, mobile terminals) or scenarios with high real-time requirements (such as video conferencing, online games), the performance weight will be increased. In addition, the complementarity of the two cryptographic systems will also be considered to evaluate their overall effect in the mixed usage mode.

[0106] Through the calculation of the performance-security balance function, generate a comprehensive applicability score for each cryptographic system (symmetric encryption, asymmetric encryption, and their different combination methods). This score reflects the ability of the cryptographic system to meet security requirements and performance constraints in the current environment, providing a comprehensive reference basis for subsequent decisions. The scoring results are usually presented in a normalized form for easy direct comparison of the applicability of different cryptographic systems.

[0107] S3.3: Based on the comprehensive applicability score and a preset threshold, output a preliminary cryptographic system selection result through a decision tree algorithm.

[0108] This step takes the comprehensive applicability scores of each cryptographic system output in step S3.2 as the main input, and at the same time introduces preset decision threshold parameters. These threshold parameters include the lowest acceptable security score, hard boundaries of performance requirements, upper limit of resource utilization, and switching cost considerations, etc. These thresholds are usually preset by the administrator according to the organization's security policies and business requirements.

[0109] The decision tree algorithm is used to select the cryptographic system. The root node of the decision tree makes a preliminary classification based on the main security requirements (such as confidentiality, integrity, authentication requirements, etc.), and then further refines the decision path at each branch node according to conditions such as performance constraints, resource availability, and communication environment characteristics. During the construction of the tree, the importance of different decision variables is considered, and the factors with greater influence are placed closer to the root to improve the decision-making efficiency.

[0110] The dependencies and complementarities between cryptographic systems are considered during the decision-making process. For example, in some scenarios, it may be necessary to use symmetric encryption to ensure data transmission efficiency while using asymmetric encryption to solve the key distribution problem. At this time, the overall performance of different combination schemes will be evaluated instead of looking at each cryptographic system in isolation. In addition, a rule engine is also applied to handle some special cases and exception policies, such as mandatory compliance requirements, compatibility limitations, or specific threat responses, etc.

[0111] By traversing the decision tree and applying the pruning strategy, a preliminary result of the cryptographic system selection is output. This result includes: the type of cryptographic system mainly used (symmetric / asymmetric / hybrid), the specific algorithm selection (such as AES-GCM / ECC-P384, etc.), the key parameter configuration, and the operation mode recommendation. This selection result reflects the cryptographic system solution that can best balance security requirements and performance constraints under the current conditions.

[0112] S3.4: Based on the preliminary result of the cryptographic system selection and the historical switching records, an optimal result of the cryptographic system selection is generated through time series analysis.

[0113] This step is based on the preliminary result of the cryptographic system selection output in step S3.3 and retrieves the historical cryptographic system switching records at the same time. These historical records contain information such as the selection results of the cryptographic system, the switching frequency, the triggering conditions for each switch, and the performance evaluation after the switch in the past period (such as several hours, days, or weeks). These data form the basis of the time series analysis.

[0114] The time series analysis method is used to study the switching pattern. Specifically, techniques such as the autoregressive moving average model (ARMA) or the more complex long short-term memory network (LSTM) are used to identify the periodic, trend, and sudden patterns in the switching behavior. This helps to understand the influence law of environmental changes on the selection of the cryptographic system and predict the possible future switching requirements. At the same time, the cost metrics of historical switches will be calculated, including the time overhead, resource consumption, potential security risk exposure, and the short-term impact on application performance required for the switch.

[0115] Introduce a stability constraint mechanism to prevent the cryptographic system from switching too frequently, which is called "jitter control". Specific implementation methods include setting a minimum switching interval time, introducing a hysteresis function (only trigger the switch when the comprehensive score of the newly selected cryptographic system exceeds the score of the currently used cryptographic system by a certain threshold), and implementing a smooth transition strategy (gradually adjusting the usage ratio of the cryptographic system instead of instantaneous switching). In addition, environmental stability prediction will also be considered. If it is predicted that the communication environment is about to change significantly, non-urgent switching decisions may be delayed.

[0116] By comprehensively considering the preliminary selection results, historical switching patterns, and stability constraints, output the optimal cryptographic system selection result with time stability guarantee. This final result not only reflects the current best choice but also takes into account the stable operation requirements in the medium and long term, avoiding the overhead and risks brought by frequent switching. The result includes clear cryptographic system specifications, switching execution time arrangements, and supporting monitoring indicators, providing comprehensive guidance for the next switching control.

[0117] As Figure 4 shown, step S4 generates a cryptographic system switching instruction set according to the optimal cryptographic system selection result, specifically including:

[0118] S4.1: Use the optimal cryptographic system selection result and the current operating state to generate a state transition description through a state difference analyzer;

[0119] This step takes the optimal cryptographic system selection result output by step S3 as input and simultaneously collects the current operating state information. These operating state information include the type of cryptographic algorithm currently used, key length, operating mode, resource occupancy, number of active connections, and encryption tasks being processed, etc.

[0120] Use a state difference analyzer to compare and analyze the states of the target cryptographic system and the current cryptographic system. The analyzer first establishes a state vector model, maps the various parameters into a multi-dimensional state space, and then calculates the difference between the current state vector and the target state vector. The analysis process considers the dependency relationship of parameter changes. For example, changing the encryption algorithm may require updating the key management module first and then adjusting the data processing flow.

[0121] Construct the minimum state transition path based on the difference analysis result. This process uses the shortest path algorithm in graph theory (such as Dijkstra algorithm or A* algorithm), takes various possible intermediate states as the nodes of the graph, takes the state transition operations as the edges of the graph, and assigns weights reflecting the conversion complexity and risk to each edge. By solving the minimum weight path, a state transition sequence that balances efficiency and security is determined.

[0122] Output a detailed description of the state transition, including a list of components to be changed, the current parameter values and target parameter values of each component, the sequence of state transitions, and the verification checkpoints for each step of the transition. This state transition description provides a clear blueprint for subsequent resource allocation and instruction generation, ensuring the logical integrity and traceability of the switching process.

[0123] S4.2: Based on the state transition description and resource monitoring data, output a resource allocation plan through a resource optimization scheduling algorithm;

[0124] This step is based on the state transition description output in step S4.1 and simultaneously collects resource monitoring data. These resource data include real-time monitoring metrics such as CPU usage, memory occupancy, network bandwidth, storage I / O, the status of dedicated encryption hardware, and energy consumption, reflecting the current resource load situation.

[0125] Use a resource optimization scheduling algorithm to analyze and allocate the resources required for the switching process. This algorithm first estimates the resource requirements for each state transition step, including computing resources, memory space, network traffic, etc., and combines the current load conditions to identify potential resource bottlenecks and available resource windows. The algorithm applies heuristic optimization methods (such as genetic algorithms or simulated annealing) to find an approximate optimal solution for resource allocation, with the goal of minimizing the total switching time while ensuring that the resource upper limit is not exceeded.

[0126] To improve resource utilization efficiency, adopt a phased resource reservation strategy. For switching operations on high-priority or critical paths, necessary resources will be reserved in advance; for operations that can be executed in parallel, a parallel scheduling algorithm will be applied to maximize resource utilization; for non-critical operations that can be delayed, they will be scheduled to be executed during periods of low resource utilization. In addition, a resource conflict resolution mechanism will be constructed to handle possible resource contention situations during the switching process through priority management and resource competition arbitration.

[0127] Output a detailed resource allocation plan, including the resource quota, execution time window, priority flag, and alternative resource plan for each switching step. This plan is presented in the form of a Gantt chart or resource schedule, intuitively showing the allocation and usage of each resource during the switching process, providing resource guarantees for subsequent instruction generation.

[0128] S4.3: Generate a password system switching instruction set using a timing optimization algorithm based on the resource allocation plan and response capability parameters.

[0129] This step is based on the resource allocation plan output in step S4.2 and simultaneously introduces response capability parameters. These parameters describe the performance attributes of each component, such as processing delay, task switching overhead, and instruction pipeline characteristics, which are important bases for timing optimization.

[0130] The instruction sequence is adjusted and reordered using a timing optimization algorithm. First, the algorithm constructs an instruction dependency graph to identify the precedence constraints and data dependencies between instructions. Then, it applies the critical path analysis method to find the instruction chain that determines the total execution time. Based on this analysis, multiple optimization strategies are adopted, including instruction reordering (executing instructions on non-critical paths earlier to reduce blockages on the critical path), instruction parallelization (identifying groups of instructions that can be executed in parallel and scheduling them accordingly), and prefetch optimization (executing predictable data loading operations in advance to reduce waiting time).

[0131] Time-sensitive operations during the handover process are considered, especially the seamless handover requirements in encrypted communication. For such operations, double-buffering technology or shadow update mechanisms are adopted to initialize and warm up the new cryptographic system in the background, and then an atomic handover operation is used to achieve a near-zero-latency transition. At the same time, the impact of different instruction ordering schemes on the security state is also evaluated to ensure that no security vulnerabilities are introduced while optimizing execution efficiency.

[0132] Output the instruction set for the cryptographic system handover optimized for timing. These instructions are arranged in the optimal execution order and are marked with precise timing requirements and synchronization points. The instruction set also includes resource allocation instructions, status verification instructions, and exception handling instructions, forming a complete handover execution package. The instruction set adopts a standard format and can be directly parsed and executed by the handover execution engine to achieve an efficient, secure, and low-latency cryptographic system handover.

[0133] As Figure 5 shown, step S5 allocates the right to propose blocks based on the instruction set for the cryptographic system handover, specifically including:

[0134] S5.1: Based on the instruction set for the cryptographic system handover and network node information, generate lottery serial numbers using a distributed random number generation protocol.

[0135] This step takes the instruction set for the cryptographic system handover output by step S4 as input and simultaneously collects information about the participating nodes in the network. These node information includes node ID, network address, public key, current active status, and credibility score, etc., constituting the participant network of the distributed lottery mechanism.

[0136] A distributed random number generation protocol is used to generate lottery serial numbers. This protocol is based on an extended version of the Bit Commitment model. It requires each participating node to first generate a local random number, then calculate its cryptographic commitment (such as using SHA-256 hash), and broadcast the commitment value rather than the original random number to the network. This stage ensures that nodes cannot adjust their inputs based on the choices of others. When all node commitments are collected, the revelation stage is initiated, requiring nodes to disclose their original random numbers and the necessary information for verifying the commitments.

[0137] To prevent nodes from not disclosing or changing their random numbers, a secure multi-party computation protocol and a timeout penalty mechanism are adopted. If a node fails to reveal its random number within the specified time, it will be excluded from the current lottery distribution and its future participation weight may be reduced. All the collected valid random numbers are combined through a deterministic algorithm (such as XOR operation or threshold signature technology) to generate a globally recognized random source. This random source is converted into multiple lottery serial numbers within the block interval through a deterministic derivation function.

[0138] Output a set of unpredictable, publicly verifiable, and non-manipulable lottery serial numbers. These serial numbers are usually large integers or byte sequences of a fixed length, with statistically uniform distribution characteristics, ensuring the randomness and fairness of the lottery distribution. Each serial number is associated with a generation proof, including the contributions of participating nodes and cryptographic proofs of the merging process, enabling any node to independently verify the legality of the serial number.

[0139] S5.2: Output a node eligibility proof via a verifiable random function according to the lottery serial number and the proof of resources held by the node;

[0140] This step takes the lottery serial numbers generated in step S5.1 as input and simultaneously collects the proof of resources provided by the nodes. These proofs of resources can be proof files of quantifiable resources such as the number of tokens held, contributed computing power, storage space, or network bandwidth, and are usually signed and verified cryptographically.

[0141] A verifiable random function (VRF) is used to process the lottery serial numbers and the proof of resources. VRF is a special pseudo-random function that not only generates a random output but also simultaneously generates a proof that enables others to verify that the output is indeed calculated from a specific input through this function without knowing the seed key. In this case, each node uses its private key as the seed key of the VRF, takes the hash of the lottery serial number and the proof of resources as input, and calculates the VRF output and proof. The results generated by this process are unpredictable (for observers who do not know the private key) and verifiable (anyone can verify the results using the node's public key).

[0142] The VRF output is processed, mapped into a standardized probability space, and combined with the resource weight of the node. Specifically, the VRF output is used as a random seed, and the weighted probability value is calculated in combination with the node's resource quantity (such as the number of tokens). This calculation process enables nodes with more resources to obtain a higher eligibility probability, but the introduced randomness ensures that small resource holders still have a chance to obtain eligibility. This design balances the degree of decentralization and the incentive mechanism for resource investment.

[0143] Generate qualification certification documents for each participating node, including node identification, resource certification summary, VRF output, VRF proof, and the final qualification probability value. These certifications can be broadcast across the entire network, and any node can verify their correctness, ensuring the transparency and immutability of the qualification allocation process. The generated qualification certifications serve as vouchers for nodes to participate in subsequent block proposals and are a core component of the distributed lottery mechanism.

[0144] S5.3: Obtain a list of qualified nodes through a distributed verification process based on the node qualification certifications and the network-wide verification rules;

[0145] This step takes the node qualification certifications generated in step S5.2 as input and also introduces the verification rules consensus across the network. These verification rules include format requirements for qualification certifications, valid ranges of VRF outputs, calculation methods for resource weights, and regulations on the timeliness of certifications, etc., which are standards jointly followed by all nodes in the network.

[0146] Initiate the distributed verification process, and have multiple verification nodes in the network process the qualification certifications in parallel. Each verification node independently performs the following verification steps: check the integrity and format compliance of the qualification certifications; verify the validity of the node signature to confirm that the certification indeed comes from the claimed node; use the public VRF algorithm and the node public key to verify the consistency of the VRF output and the proof; check the authenticity of the resource certification, which may require accessing on-chain data or an authoritative Oracle; calculate the qualification threshold according to the verification rules to determine whether the node meets the minimum qualification requirements.

[0147] To improve verification efficiency and reliability, a multi-level verification architecture is adopted. The qualification certifications of nodes are initially verified among local neighbor nodes, and only the passed certifications are submitted to the wider network for network-wide verification. In the network-wide verification stage, a committee mechanism or sharding technology may be adopted to allocate verification tasks to different node groups and confirm the verification results through majority decision or threshold signature. In addition, a verification cache mechanism is constructed to avoid repeated verification of the same certification, improving the overall efficiency.

[0148] Summarize the verification results and generate a list of qualified nodes for this round. This list contains the identification of all verified nodes, summary information of their qualification certifications, and the qualification validity period. The list is broadcast across the network after being confirmed by multi-node signatures and becomes the basic data for block proposal right allocation. At the same time, the nodes that fail the verification and the reasons will also be recorded as monitoring indicators for network health status and references for future rule optimization.

[0149] S5.4: Generate the block proposal right allocation result using a probability allocation mechanism based on the list of qualified nodes and the lottery matching algorithm.

[0150] This step takes the qualified node list generated in step S5.3 as input and introduces a preset lottery matching algorithm. This algorithm defines how to match the lottery serial number with the node qualification certificate and how to allocate the block proposal right based on the matching result.

[0151] Start the probability allocation mechanism to allocate block proposers for each time slot (usually corresponding to a block generation cycle). Specifically, first determine the lottery serial number of the current time slot, and then traverse the qualified node list to perform lottery matching calculations for each node. This calculation usually includes combining the VRF output of the node with time slot specific information (such as slot number, previous block hash, etc.) to generate a unique matching value. According to the preset probability distribution function, map these matching values to the probability space and combine them with the resource weights of the nodes to calculate the final selection probability.

[0152] To ensure the fairness and unpredictability of the allocation process, a multi-round lottery mechanism is adopted. In the first round of lottery, a candidate pool of potential block proposers is selected, and then a second round of lottery is conducted among these candidates to finally determine the main proposer and several backup proposers. This multi-round mechanism increases the difficulty of manipulation and improves fault tolerance through the setting of backup proposers. In addition, measures to prevent Sybil attacks are also implemented, such as requiring nodes to meet a minimum resource threshold to participate and restricting the overall weight of multiple nodes controlled by a single entity.

[0153] Output the block proposal right allocation result, including the main proposer, backup proposer sequence, and their respective selection proofs for each time slot. These information are broadcast to the network in the form of signed messages, and all nodes can verify their correctness. The allocation result is also recorded on the chain as the basis for subsequent block verification and reference for dispute resolution. This fair, transparent, and unpredictable block proposal right allocation mechanism effectively reduces the centralization risk, and at the same time does not require dedicated hardware support, improving the universality and decentralization degree.

[0154] Step S6 confirms the final block according to the block proposal right allocation result, specifically including:

[0155] S6.1: Generate a candidate block proposal by the node that obtains the proposal right according to the block proposal right allocation result and the preset block template.

[0156] This step takes the block proposal right allocation result output by step S5 as input and introduces a preset block template. These templates define the basic structure, necessary fields, transaction packaging rules, and data format requirements of the block, ensuring that the generated block complies with the protocol standard.

[0157] The node that obtains the right to propose the current time slot (the main proposer) initiates the block proposal generation process. This node first verifies its own proposal eligibility to confirm the validity and timeliness of the proposed right allocation result. The node selects the transactions to be processed from the transaction pool and sorts the transactions according to the preset sorting rules (such as fuel fee priority, time priority, etc.). During the transaction selection process, the node needs to verify the signature, format of each transaction, and whether it conforms to the state transition rules, and eliminate invalid or conflicting transactions.

[0158] The node packs the selected transactions into the block according to the preset format and calculates relevant derivative data, such as the Merkle root of the transactions, the state root hash, etc. At the same time, the node will include in the block header the proof of its block proposal right (such as the eligibility proof and matching proof generated in step S5.2), and a reference to the previous block (usually the hash value of the previous block). To enhance the verifiability of the block, the node will also include in the block a snapshot or incremental description of the current state to facilitate other nodes to verify the correctness of the state transition.

[0159] The node signs the block proposal with its private key to generate a complete candidate block proposal. This proposal includes parts such as the block header (including metadata, proof, and reference), transaction list, state information, and proposer signature. The node broadcasts this proposal to the network as the basis for the current round of consensus. If the main proposer fails to generate a valid proposal within the specified time, the backup proposer will take over to generate the block proposal in the order determined in step S5.4 to ensure the continuity and reliability of the block generation process.

[0160] S6.2: Generate node reputation scores based on the candidate block proposal and the historical behavior records of each node;

[0161] These records include multi-dimensional data such as the history of nodes participating in block proposal and verification, proposal quality statistics, malicious behavior marks, and community contribution metrics.

[0162] This step takes the candidate block proposal generated in step S6.1 as the input and retrieves the historical behavior records of each node in the network at the same time. These records include multi-dimensional data such as the history of nodes participating in block proposal and verification, proposal quality statistics, malicious behavior marks, and community contribution metrics.

[0163] Start the reputation calculation model to evaluate the block proposer and verification nodes. For the proposer, the model mainly focuses on the following dimensions: timeliness of the block proposal (whether it is submitted within the time window), integrity (whether it contains all necessary fields), validity (whether the transactions are legal and valid), efficiency (whether the transaction packing is efficient), and fairness (whether specific transactions are intentionally excluded). For the verification nodes, the model focuses on the verification response speed, accuracy, consistency, and whether there is malicious voting behavior.

[0164] To ensure the objectivity and anti - manipulability of the reputation score, a multi - level scoring mechanism is adopted. At the basic level, the basic score is calculated through objective measurement indicators (such as response time, error rate, etc.); then, at the behavioral level, by analyzing the behavior patterns of nodes, suspicious malicious behaviors are identified and punished; at the community level, through a weighted voting or endorsement mechanism, the evaluations of other trusted nodes on the target node are introduced. In addition, the reputation model also adopts a time - decay function, making the impact of recent behaviors on the score greater than that of long - term behaviors, reflecting the current credibility of the node.

[0165] A standardized reputation score is generated for each relevant node, usually using a scoring range of 0 - 100, where a higher score indicates a more trustworthy node. The scoring results include the overall score, sub - scores for each dimension, and the scoring change trend, providing a scientific basis for subsequent voting weight allocation. At the same time, nodes with abnormal reputations (such as nodes with a sudden significant drop or abnormal fluctuations in scores) are marked as key objects for network monitoring. This reputation mechanism based on historical behaviors introduces long - term incentives to the blockchain, prompting nodes to maintain honest behaviors to establish and maintain a good reputation.

[0166] Specifically, S6.2 generates a node reputation score based on the candidate block proposal and the historical behavior records of each node, specifically including:

[0167] S6.2.1 According to the candidate block proposal, extract the historical records of the node's participation in block proposal and verification, proposal quality statistics, and community contribution data as the historical behavior records.

[0168] Analyze the current and past candidate block proposals, and extract the behavior data related to each node from them. For block proposers, record indicators such as the number of blocks proposed, the proportion of blocks passed through verification, and the average proposal time; for verification nodes, record indicators such as the number of blocks participated in verification, verification accuracy rate, and average response time. These data constitute the historical records of the node's participation in block proposal and verification.

[0169] Conduct statistical analysis on the quality of node proposals. For block proposers, evaluate their performance in terms of structural integrity, transaction validity, packaging efficiency, etc.; for important verification nodes, evaluate the accuracy, consistency, and influence of their verification opinions. Adopt a sliding window technique to focus on recent changes in proposal quality to reflect the current capabilities and intentions of the node.

[0170] Collect the community contribution data of nodes in the network. This includes the maintenance contributions of nodes to the network infrastructure (such as providing stable network connections, sufficient storage resources, etc.), the participation in protocol improvements (such as proposing improvement suggestions, participating in tests, etc.), and the positive impacts on the overall ecosystem (such as developing tools, educational resources, etc.). Community contribution data is usually confirmed through the network consensus mechanism or decentralized governance process to ensure its authenticity and objectivity.

[0171] Integrate the above three types of data into the comprehensive historical behavior record of the node. The integration process adopts a weight allocation mechanism, and dynamically adjusts the importance weights of various types of data according to different application scenarios and security requirements. For example, in an environment with high security requirements, verification accuracy may obtain a higher weight; while in an environment emphasizing community autonomy, community contributions may obtain a higher weight. The integrated historical behavior record provides a comprehensive data basis for subsequent reputation scoring.

[0172] S6.2.2 Adopt the said historical behavior record and calculate and output the basic score of the node via objective measurement indicators.

[0173] Define a set of objective measurement indicators for quantitatively evaluating the historical behavior of nodes. These indicators include: time-based indicators (such as average response time, stable online rate, etc.), accuracy indicators (such as verification accuracy rate, error proposal rate, etc.), consistency indicators (such as degree of agreement with the majority opinion, decision stability, etc.), and resource contribution indicators (such as provided computing power, storage space, etc.). Each indicator has a clear definition and calculation method to ensure the objectivity and reproducibility of the evaluation.

[0174] Collect the original data of each node on these indicators and perform standardization processing. The standardization process takes into account the dimensional differences and distribution characteristics of different indicators, and uses appropriate transformation methods (such as Z-score standardization, Min-Max scaling, etc.) to map the values of each indicator to a unified score interval. This step ensures the comparability between different indicators and avoids the excessive influence of some indicators with larger dimensions on the final result.

[0175] Apply a weighted calculation method to combine the standardized indicators into a comprehensive score. The weight allocation is based on the importance and reliability of the indicators and is determined through network governance or by experts. To improve adaptability, the weights may be dynamically adjusted according to the network state and security requirements. The calculation process also takes into account the correlation between indicators and reduces the influence of redundant information through methods such as principal component analysis or factor analysis.

[0176] The basic score of the output node, which is a value reflecting the objective performance of the node's historical behavior. The basic score usually adopts a scoring system of 0-100, where a high score indicates that the node performs well in objective indicators, and a low score indicates potential problems or bad records. This basic score will be an important part of the subsequent reputation calculation.

[0177] S6.2.3 Generate the node reputation score through a time decay function based on the described node basic score and node behavior pattern analysis.

[0178] Conduct an in-depth analysis of the node's behavior pattern based on historical data. This analysis aims to identify potential abnormal or malicious patterns, such as: strategic voting behavior (such as always opposing the proposals of specific nodes), periodic malicious behavior (such as submitting malicious proposals during low supervision periods), Byzantine behavior (such as sending contradictory information to different nodes), etc. Adopt machine learning algorithms, such as clustering analysis, anomaly detection or rule mining and other techniques, to extract these behavior patterns from time series data and generate behavior pattern evaluation results for each node.

[0179] Introduce a time decay mechanism so that recent behavior has a greater impact on reputation than distant behavior. Specifically, an exponential decay function or a half-life model is adopted to assign decay weights to historical behaviors at different time points. For example, the formula W(t) = e-λ(t now -t) can be used, where λ is the decay parameter, t now is the current time, and t is the time when the historical behavior occurred. This mechanism enables the reputation score to better reflect the current state and intentions of the node, while retaining long-term memory and avoiding completely ignoring historical behavior.

[0180] Combine the basic score, the results of behavior pattern analysis and the time decay factor to calculate the comprehensive reputation score. During the calculation process, apply non-linear transformation or threshold effect to impose more severe penalties on specific types of negative behaviors (such as explicit malicious attacks). At the same time, a recovery mechanism is also considered, allowing nodes with poor historical performance but good recent behavior to gradually recover their reputation and encouraging nodes to improve their behavior.

[0181] Output the final node reputation score, which is a comprehensive evaluation considering objective performance, behavior pattern and time factors. The reputation score usually adopts a scoring system of 0-100 and may be accompanied by a confidence indicator indicating the reliability of the score. A reputation score report will also be generated, detailing the contributions of each component and the key influencing factors, enhancing the transparency and interpretability of the scoring process. This reputation score will be directly used for subsequent voting weight allocation, affecting the influence of the node in the consensus process.

[0182] S6.3: Using the node reputation score, resource contribution value, and voting weight allocation rules, obtain the block voting result through a weighted voting mechanism;

[0183] This step takes the node reputation score generated in step S6.2 as input and also introduces a preset voting weight allocation rule. These rules define how to calculate the voting weight of a node based on factors such as the node's reputation score, resource contribution, and historical participation, as well as the specific manner and statistical criteria of the voting process.

[0184] Start the weighted voting mechanism and invite eligible verification nodes to vote on the candidate block proposal. Each verification node first independently verifies the validity of the block proposal, checking the block structure, transaction legality, correctness of state transitions, and proof of the proposer's eligibility, etc. Based on the verification results, the node may cast an approval vote (considering the block valid), a rejection vote (considering the block invalid), or an abstention (uncertain or controversial). When voting, the node needs to attach verification proof to prove that it has indeed carried out the necessary verification work.

[0185] To enhance the reliability and anti-attack ability of voting, a multi-round voting and threshold confirmation mechanism is adopted. In the first round of voting, collect the preliminary voting opinions of all nodes; publicly disclose these voting results and enter the second round of discussion and adjustment stage, where nodes can adjust their voting positions according to the majority opinion and new evidence; conduct the final vote count and determine whether the block passes the verification according to the weighted majority principle. To prevent Byzantine behavior, the voting pattern will be analyzed to identify abnormal voting behaviors (such as nodes whose consistent votes are contrary to the majority), and their reputation scores and voting weights may be adjusted in the future.

[0186] Summarize all valid votes, calculate the weighted result according to the voting weights of each node, and output the block voting result. This result includes the overall passing rate, various vote counts, the voting positions of key nodes, and the determination of whether the passing threshold is reached. The voting result is an important basis for block confirmation and will be passed to the final confirmation algorithm for processing. At the same time, the detailed information of this vote, including the list of participating nodes, the voting content and weights of each node, etc., will also be recorded as important materials for reputation feedback input and historical audit.

[0187] Specifically, S6.3 obtains the block voting result through a weighted voting mechanism using the node reputation score, resource contribution value, and voting weight allocation rules, specifically including:

[0188] S6.3.1 Using the node reputation score and resource contribution value, output the node voting weight using the voting weight calculation function.

[0189] Collect the reputation scores and resource contribution values of each voting node. The reputation scores come from the output of step S6.2 and reflect the credibility of the node's historical behavior; the resource contribution values quantify the node's material input to the network, such as the computing power, storage space, network bandwidth provided, or the number of staked tokens, etc. These two metrics represent the "trust capital" and "economic capital" of the node respectively, and are the core basis for calculating the voting weights.

[0190] Apply the voting weight calculation function to process these input data. This function is designed to balance the goals of decentralization and efficiency, and usually adopts a non-linear combination method, such as the weighted geometric mean or the S-shaped function. The balance parameter β can be dynamically adjusted according to the network's decentralization preference. A higher β value favors reputation orientation, while a lower β value favors resource orientation.

[0191] Introduce a weight limit mechanism to prevent a single node or coalition from obtaining an overly high voting weight. This includes setting a maximum weight ceiling (e.g., the weight of any node does not exceed 5% of the total weight), applying a weight decreasing function (the marginal weight decreases as the total input increases), and implementing a weight dispersion requirement (requiring that the voting decision requires the support of at least a certain number of independent nodes). These limit mechanisms ensure that a sufficient degree of decentralization is maintained to resist potential 51% attacks.

[0192] Output the final voting weights of each node. These weights not only reflect the credibility and contribution of the node, but also are subject to necessary restrictions to ensure security. The weights are usually expressed as a percentage of the total weight, and the sum of the weights of all participating nodes is 100%. The weight allocation results and calculation basis will be made public to ensure the transparency of the voting process. At the same time, a weight distribution statistical report will also be generated to evaluate the decentralization degree and resource utilization efficiency of the current weight allocation, providing a reference for network governance.

[0193] S6.3.2 According to the node voting weights, collect multi-round voting data of the nodes on the candidate block.

[0194] Based on the preset voting rules, initiate the first round of voting process. In this round, each qualified verification node votes on the candidate block proposal according to its own verification results. Typical voting options include "approve" (confirming that the block is valid), "reject" (considering the block invalid), or "abstain" (uncertain or controversial). To ensure the validity of the vote, each node needs to provide verification evidence, such as the result summary of specific verification steps or signature data, etc. Record the voting choices, verification evidence, and corresponding voting weights of each node.

[0195] Release the preliminary results of the first round of voting, including weighted statistical data and the positions of key nodes. At this time, no final decision will be made immediately, but instead, it will enter the discussion and adjustment stage. During this stage, nodes can view the voting positions and verification evidence of other nodes and have the opportunity to adjust their own positions based on new information. For example, if a node finds that most high-reputation nodes consider a block valid while its own verification result shows invalid, the node may re-check the verification process to look for potential errors or misunderstandings.

[0196] Initiate the second round of voting, allowing nodes to submit their final positions. The purpose of this round of voting is to collect opinions after full consideration and discussion, reducing disagreements caused by information asymmetry or verification errors. Similar to the first round, record the final voting choices of each node, the updated verification evidence, and the corresponding voting weights. In specific situations (such as the existence of serious disagreements or the emergence of key evidence), additional voting rounds may be initiated until sufficient consensus is reached or the preset termination conditions are met.

[0197] Integrate the voting data of all rounds, focusing on the results of the final round. During the integration process, abnormal situations during the voting process will be marked, such as significant changes in node positions, nodes that consistently deviate from the majority opinion, etc. These marks do not directly affect the current voting result but will serve as important inputs for future reputation assessments. The integrated multi-round voting data contains rich decision-making information, not only reflecting the final positions of nodes but also the stability and consensus degree of the decision-making process, providing a comprehensive data basis for subsequent result statistics.

[0198] S6.3.3 Based on the voting data and the results of abnormal vote identification, use a weighted statistical algorithm to generate the block voting result.

[0199] Preprocess and clean the multi-round voting data collected. The preprocessing stage mainly includes: verifying the signature validity of each vote, confirming the eligibility of voting nodes, checking the compliance of the voting format, etc. During the cleaning process, invalid votes (such as incorrect formats, mismatched signatures, etc.) will be excluded, and suspicious votes (such as timeout votes, frequent changes, etc.) will be marked for subsequent analysis.

[0200] Apply an abnormal vote identification algorithm to detect possible malicious or incorrect voting behaviors. This algorithm is based on statistical models and behavioral analysis to identify various abnormal patterns, such as: sexual error (the verification results of a certain node are always inconsistent with the vast majority of nodes), collaborative cheating (a group of nodes always synchronously change their voting positions), contradictory voting (the same node submits different votes through different channels), etc. For the identified abnormal votes, corresponding handling strategies will be adopted according to the severity and certainty of the abnormality, such as reducing weights, completely excluding, or marking as suspicious.

[0201] Apply the weighted statistical algorithm to calculate the final voting result. First, the algorithm adjusts the original voting weights of each node according to the results of preprocessing and anomaly recognition. Then, it statistically analyzes the adjusted weighted votes to calculate the weighted percentages of affirmative votes, negative votes, and abstentions. In specific cases, the algorithm may adopt more complex statistical methods, such as Bayesian weighting or credibility adjustment, to further improve the reliability of the results.

[0202] Generate a complete block voting result report. The report includes: the final voting statistics (weighted percentages of various types of votes), the judgment of whether the passing threshold is reached, a summary of the voting positions of important nodes, statistical information on abnormal votes, etc. For cases close to the threshold, special markings will be made, and additional analysis information may be provided. This voting result report will serve as the direct basis for confirming or rejecting the block and also provide important reference for the subsequent consensus process. Through this rigorous statistical process, while fully utilizing the collective wisdom of the nodes, it can effectively resist various voting manipulation attempts and ensure the fairness and reliability of the voting results.

[0203] S6.4: Generate the final block confirmation result through the consensus confirmation algorithm based on the block voting result and the finality condition parameters.

[0204] This step takes the block voting result output by step S6.3 as input and also introduces preset finality condition parameters. These parameters define the conditions that the block needs to meet to reach the final confirmation state, such as the minimum voting passing rate, the number of consecutively confirmed blocks, the minimum confirmation time, etc., reflecting the balanced requirements for security and activity.

[0205] Start the consensus confirmation algorithm to further process and analyze the voting result. First, the algorithm verifies whether the voting process meets the protocol requirements (such as whether the minimum participation rate is reached and whether the voting rules are followed) to confirm the validity of the voting result. The algorithm compares the voting result with the finality conditions to determine whether the block meets the threshold requirements for final confirmation. In some cases, final confirmation may require multiple stages, such as first reaching "probabilistic finality" (the probability of the block being overturned is extremely low), then reaching "economic finality" (the cost of overturning the block is much higher than the possible benefits), and finally reaching "absolute finality" (the block cannot be rolled back under the protocol rules).

[0206] To enhance the reliability and consensus of the confirmation result, additional security mechanisms may be introduced. For example, for blocks that are close to but do not fully meet the finality conditions, an extended voting procedure may be initiated to invite more nodes or a higher-level committee to vote; for blocks with major disputes, an arbitration mechanism may be triggered to resolve the disputes by preselected arbitrators or community governance processes; for special cases that may involve security, a manual review link may also be introduced, and the final confirmation is carried out by the core development team or community representatives.

[0207] Output a highly credible final block confirmation result. This result clearly identifies the confirmation status of the block (such as "tentative", "likely final", or "absolutely final"), the time point when finality is achieved, a summary of the evidence supporting the confirmation (such as signatures of key nodes), and possible conditional constraints. The confirmation result is broadcast to the entire network through an announcement mechanism and recorded on the chain for future verification reference. At the same time, the blockchain state tree is updated to solidify the confirmed state changes, completing the full consensus process. This reputation-based confirmation mechanism provides strong finality guarantees while maintaining decentralization, effectively balancing security and efficiency.

[0208] Specifically, S6.4 generates a final block confirmation result through a consensus confirmation algorithm based on the block voting result and the finality condition parameters, specifically including:

[0209] S6.4.1 Determine whether the block voting result meets the preset finality conditions and output a verification result.

[0210] Analyze the preset finality conditions, which usually include multi-dimensional requirements. Common dimensions include: approval rate requirements (such as the weighted approval votes need to reach more than 2 / 3 of the total weight); participation requirements (such as the total weight of participating in the vote needs to reach more than 51% of the network weight); stability requirements (such as the result needs to be consistent in multiple consecutive blocks); time requirements (such as a certain confirmation period needs to pass after the block is generated). These conditions may have different priorities and combination relationships, jointly defining the criteria for a block to be considered in the "final confirmation" state.

[0211] Conduct a comprehensive analysis of the block voting result output in step S6.3, and calculate the matching degree of each indicator with the preset conditions. For example, calculate the percentage of weighted approval votes in the total voting weight and compare it with the approval rate requirement; calculate the proportion of the total weight of participating in the vote in the network weight and compare it with the participation requirement; check whether the voting result of the current block is consistent with the pre-voting result of this block in the previous block to evaluate the stability of the result; calculate the time since the block was generated and compare it with the minimum confirmation period requirement.

[0212] Based on the analysis result, classify and evaluate the confirmation status of the block. According to the degree of compliance of each dimension indicator with the requirements, the block may be divided into different confirmation levels, such as: unconfirmed (does not meet the basic requirements); preliminary confirmation (meets the basic requirements but has not reached the finality conditions); highly probable confirmation (close to but not fully meeting the finality conditions); final confirmation (fully meeting all finality conditions). Different confirmation levels correspond to different degrees of certainty and security guarantees, and will clearly mark the confirmation level and reason of the current block.

[0213] Output detailed verification results, including: the current confirmation status of the block; the specific values of each dimension indicator and the gap from the preset conditions; whether further confirmation steps are required (such as extended voting); the conditions or time required to reach a higher confirmation level, etc. For cases that are close but do not fully meet the conditions, the key gap items will be specifically marked to provide clear guidance for subsequent decision-making. This verification result serves as the basis for judging whether additional confirmation steps are needed and directly affects the subsequent processing flow.

[0214] S6.4.2 According to the verification result, conduct extended voting on the blocks that do not reach the threshold to obtain supplementary voting data.

[0215] Based on the verification result of step S6.4.1, identify the blocks that do not fully reach the finality threshold but are close to the threshold. These blocks are usually in the "high-probability confirmation" state, but there are small gaps from the finality conditions in some dimensions, such as the approval rate being slightly lower than required, insufficient participation, or the absence of key nodes, etc. These key gaps will be clearly identified as the key areas of focus for extended voting.

[0216] Initiate the extended voting process and select an appropriate extension strategy according to the type of gap. For the case of insufficient participation, more standby nodes or lower-level verification nodes will be invited to participate in the voting; for the case where the approval rate is close but does not meet the standard, a special committee or senior nodes with arbitration rights may be convened for review; for the case of the absence of key nodes, attempts will be made to establish priority communication with these nodes or wait for their response within an extended time window. The design principle of extended voting is to make up for the deficiencies in the original voting as much as possible while maintaining the fairness and transparency of the process.

[0217] Collect the supplementary voting data generated by the extended voting. Similar to regular voting, each node participating in the extended voting needs to provide its verification result, supporting evidence, and signature. The same validity checks and anomaly identifications are performed on these supplementary votes to ensure data quality. The weight allocation of supplementary votes may adopt special rules, such as allocating different weights according to the role or professional field of the node in the extension process to maximize the value of extended voting.

[0218] Integrate the data of regular voting and extended voting to generate an extended complete voting result set. This result set contains all the data of regular voting and the incremental information brought by extended voting, providing a more comprehensive decision-making basis for the final confirmation of the block. At the same time, it will be marked which data comes from extended voting for subsequent analysis and auditing. Through this extension mechanism, edge cases and controversial blocks can be handled, improving the confirmation efficiency without sacrificing security and reducing the block confirmation delay caused by insufficient voting or ambiguous results.

[0219] S6.4.3 Update the status of the block voting result based on the supplementary voting data to generate the final block confirmation result.

[0220] Merge the supplementary voting data obtained in step S6.4.2 with the original voting data. The merging process adopts strict data integration rules to ensure that multiple votes of the same node are not double-counted and no valid vote is missed. For nodes that participated in both regular voting and extended voting, their latest voting stance will be used as the standard, unless there is clear evidence indicating problems with the latest vote. The merged dataset retains the source marker of each vote for subsequent analysis.

[0221] Based on the merged voting dataset, recalculate the key voting metrics. This includes: the updated weighted approval rate, total participation rate, voting distribution of nodes at all levels, etc. The calculation process applies the same weighted statistical algorithm as in step S6.3.3, but some parameters may be adjusted according to the particularity of extended voting. For example, additional weights may be given to specific evidence types in extended voting to reflect their importance in resolving disputes.

[0222] Compare the updated voting metrics with the finality conditions again to make the final confirmation decision. This decision will clearly classify the block status into one of the following: final confirmation (fully meeting all conditions), high-probability confirmation (meeting the main conditions but with minor reservations), tentative confirmation (having a basic consensus but not meeting the strict conditions), or rejection (not meeting the basic confirmation requirements). For the extremely rare cases where a clear conclusion cannot be reached through extended voting, a higher-level dispute resolution mechanism may be initiated, such as community governance voting or joint committee arbitration, but this is beyond the scope of the regular confirmation process.

[0223] Generate a final block confirmation result report. This report is a comprehensive document that includes: the final confirmation status and security guarantee level of the block; the basis for the decision, including key voting metrics and the comparison results with the conditions; a summary of the voting process, including the main data of regular voting and extended voting; a description of special cases, if there are factors that need special attention; and the confirmation timestamp and signature list as the official proof of the result. This confirmation result report will be broadcast across the entire network and permanently recorded on the blockchain as the authoritative proof of the block confirmation status. At the same time, the confirmation result will also trigger corresponding operations, such as status updates, transaction confirmations, or the execution of the cryptographic system switch in the present invention.

[0224] Through this strict and flexible multi-level confirmation mechanism, it not only ensures the high security of block confirmation but also has the adaptability to handle various complex situations, providing a reliable consensus foundation for the entire blockchain and ultimately supporting the secure switch of the dual cryptographic system.

[0225] S7. Based on the confirmation result of the final block, perform the switch of the dual-cryptosystem.

[0226] This decision has passed the dual verification of the distributed lottery mechanism and reputation-based block voting, with high credibility and immutability.

[0227] Start the execution process of the cryptosystem switch. Use the double-buffer mechanism to initialize the operating environment of the target cryptosystem in parallel, which includes loading the relevant cryptographic libraries, preheating the key generation and processing pipelines, and preparing the necessary resources. This parallel initialization method ensures that all preparations for the new cryptosystem have been completed before the official switch, minimizing service interruption during the switch.

[0228] Perform session state migration. For existing active encryption sessions, use a dedicated state migration function to seamlessly transfer session parameters, key materials, and ongoing transactions from the current cryptosystem to the target cryptosystem. This process adopts a secure key conversion protocol to ensure that the confidentiality and integrity of session data are not compromised even during the migration. For sessions that cannot be directly migrated, an elegant degradation strategy will be implemented, such as notifying re-negotiation or migrating in batches according to priority.

[0229] Synchronize the cryptosystem configurations of all nodes in the switch network through atomic update operations. This operation adopts a two-phase commit protocol to ensure that all nodes either switch successfully or roll back to the original state, avoiding the risk of network splitting. After the switch is completed, a comprehensive post-switch verification will be carried out to confirm that all components of the new cryptosystem are working properly, and a switch result log will be recorded, including information such as the switch time, the list of participating nodes, and the comparison of performance metrics before and after the switch, providing a basis for optimization and auditing. Through this carefully designed switch mechanism, the upgrade of the cryptosystem is completed quickly with little impact on normal business, improving the adaptability to security threats.

[0230] As Figure 6 shown, the embodiment of the present application also provides a dual-cryptosystem fast-switching system, including:

[0231] An identifier generation module 10, configured to generate a private identifier using a multi-factor fusion algorithm according to the device unique identifier and the user biometric information;

[0232] A key generation module 20, which outputs a dual-cryptosystem key pair based on the private identifier and the channel state information;

[0233] A cryptosystem evaluation module 30, configured to perform a security strength evaluation and a performance requirement evaluation on the dual-cryptosystem key pair to obtain an optimal cryptosystem selection result;

[0234] The instruction set generation module 40 is used to generate a password system switching instruction set according to the optimal password system selection result;

[0235] The block proposal right allocation module 50 is used to allocate the block proposal right based on the password system switching instruction set;

[0236] The block confirmation module 60 is used to confirm the final block according to the block proposal right allocation result;

[0237] The switching module 70 is used to execute the switching of the dual password system based on the confirmation result of the final block.

[0238] It should be understood that the concept of "password system" in this application covers various security mechanisms and algorithms in cryptography, mainly including two categories: symmetric encryption and asymmetric encryption, as well as their various combinations and application methods. The symmetric encryption system (such as AES, ChaCha20, etc.) uses the same key for encryption and decryption, with the characteristics of fast processing speed and low resource consumption, but faces the problem of difficult key distribution; the asymmetric encryption system (such as RSA, ECC, etc.) uses public and private key pairs, solves the key distribution problem, but has a higher computational complexity and may face security risks in the quantum computing environment.

[0239] The "dual password system" described in this application specifically refers to a hybrid architecture that combines the advantages of symmetric encryption and asymmetric encryption. The two password systems in this architecture can be dynamically switched or work together according to security requirements and operating environments. And "fast switching" refers to a technical means of efficiently and low-latency switching between different password systems while ensuring security. This switching can be an active switching based on a predetermined strategy or a responsive switching to security threats.

[0240] The key innovations of this application include but are not limited to: 1) an adaptive key generation algorithm based on private identifiers and channel status information; 2) a password system evaluation mechanism that comprehensively considers security, performance, and stability; 3) a low-latency password system fast switching control technology; 4) a fair block proposal right allocation method that does not rely on dedicated hardware; 5) a reputation-based block confirmation mechanism. These innovations together constitute a complete technical system, providing a new idea for solving the problem of balancing security and efficiency in existing password systems in a dynamic environment.

[0241] The above are only the preferred embodiments of this application and are not used to limit this application. For those skilled in the art, this application can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this application shall be included in the protection scope of this application.

Claims

1. A dual password system fast switching method, characterized in that: include: Generate a private identifier using a multi-factor fusion algorithm based on the device's unique identifier and the user's biometric information; Generate a dual cryptographic system key pair according to the private identifier and the channel state information; Performing security strength assessment and performance requirement assessment on the dual cryptographic system key pair to obtain an optimal cryptographic system selection result; Generating a cryptographic system switching instruction set according to the optimal cryptographic system selection result; Based on the cryptographic system switching instruction set, the block proposal right is allocated; Confirm the final block according to the block proposal rights allocation result; Based on the confirmation result of the final block, the dual cryptographic system is switched.

2. The dual password system fast switching method according to claim 1, characterized in that: Generating a dual cryptographic system key pair according to the private identifier and the channel state information includes: Using the private identifier and the channel status information collected in real time, and using an entropy extraction function to generate a high entropy random seed; Generate a symmetric key and an asymmetric key pair through a key derivation function according to the high entropy random seed; The symmetric key and the asymmetric key pair are quantum-resistant and a dual-cryptographic key pair with security verification is output.

3. The dual password system fast switching method according to claim 1, characterized in that: Perform security strength assessment and performance requirement assessment on the dual cryptographic system key pair to obtain the optimal cryptographic system selection result, including: Using the dual cryptographic system key pair and current system security requirement parameters, a key security strength score is generated through a security strength assessment algorithm; Generating a comprehensive suitability score using a performance-security balance function based on the key security strength score and system performance requirement parameters; Based on the comprehensive applicability score and the preset threshold, outputting a preliminary cryptographic system selection result through a decision tree algorithm; Based on the preliminary cryptographic system selection result and the historical switching record, an optimal cryptographic system selection result is generated through time series analysis.

4. The dual password system fast switching method according to claim 1, characterized in that: According to the optimal cryptographic system selection result, a cryptographic system switching instruction set is generated, including: Using the optimal cryptographic system selection result and the current system operation state, a state transition description is generated via a state difference analyzer; Outputting a resource allocation plan through a resource optimization scheduling algorithm based on the state transition description and system resource monitoring data; According to the resource allocation plan and system response capability parameters, a cryptographic system switching instruction set is generated using a timing optimization algorithm.

5. The dual password system fast switching method according to claim 1, characterized in that: Based on the cryptographic system switching instruction set, the block proposal right is allocated, including: Based on the cryptographic system switching instruction set and network node information, a lottery serial number is generated using a distributed random number generation protocol; Output the node qualification certificate via a verifiable random function based on the lottery serial number and the resource certificate held by the node; Based on the node qualification certificate and the network-wide verification rules, a list of qualified nodes is obtained through a distributed verification process; Based on the qualified node list and the lottery matching algorithm, a probability allocation mechanism is used to generate the block proposal right allocation result.

6. The dual password system fast switching method according to claim 1, characterized in that: According to the block proposal rights allocation results, the final block is confirmed, including: According to the block proposal right allocation result and the preset block template, the node that obtains the proposal right generates a candidate block proposal; Generate a node reputation score based on the candidate block proposal and the historical behavior records of each node; The node reputation score, resource contribution value and voting weight allocation rules are used to obtain the block voting results through a weighted voting mechanism; Based on the block voting results and finality condition parameters, the final block confirmation result is generated through the consensus confirmation algorithm.

7. The dual password system fast switching method according to claim 6, characterized in that: Based on the candidate block proposal and the historical behavior records of each node, a node reputation score is generated, including: According to the candidate block proposal, extract the historical records of the node's participation in block proposal and verification, proposal quality statistics and community contribution data as the historical behavior record; Using the historical behavior records, the basic score of the output node is calculated through objective measurement indicators; Based on the node basic score and node behavior pattern analysis, a node reputation score is generated through a time decay function.

8. The dual password system fast switching method according to claim 7, characterized in that: The node reputation score, resource contribution value and voting weight allocation rules are used to generate block voting results through a weighted voting mechanism, including: Using the node reputation score and resource contribution value, a voting weight calculation function is used to output the node voting weight; According to the node voting weights, multiple rounds of voting data on candidate blocks are collected; Based on the voting data and the abnormal voting identification results, a weighted statistical algorithm is used to generate block voting results.

9. The dual password system fast switching method according to claim 8, characterized in that: Based on the block voting results and finality condition parameters, the final block confirmation result is generated through the consensus confirmation algorithm, including: Determine whether the voting result of the block meets the preset finality condition and output the verification result; According to the verification results, the blocks that do not reach the threshold are extended to vote to obtain supplementary voting data; Based on the supplementary voting data, the block voting result is updated to generate the final block confirmation result.

10. A dual password system fast switching system, characterized in that: include: An identifier generation module, used to generate a private identifier using a multi-factor fusion algorithm based on a device unique identifier and user biometric information; A key generation module, wherein the private identifier and the channel status information output a dual cryptographic system key pair; A cryptographic system evaluation module, used to perform security strength evaluation and performance requirement evaluation on the dual cryptographic system key pair to obtain an optimal cryptographic system selection result; An instruction set generation module, used for generating a cryptographic system switching instruction set according to the optimal cryptographic system selection result; A proposal right allocation module, used to allocate block proposal rights based on the cryptographic system switching instruction set; A block confirmation module, used to confirm the final block according to the block proposal right allocation result; The switching module is used to execute the switching of the dual password system based on the confirmation result of the final block.

Images