Distributed account book encryption method and system based on block chain

Abstract

The invention provides a distributed account book encryption method and system based on a block chain. The method comprises the following steps: generating a key identifier hash value containing a key version and a timestamp for each node, constructing a Merkel tree based on the key identifier hash value of each node, calculating a root hash of the Merkel tree, and writing the root hash into a block chain; for each node, dynamically selecting an encryption algorithm in combination with a data sensitivity level, a node computing power and a node delay threshold value, performing security verification on the selected encryption algorithm according to root hash, and outputting a final target encryption algorithm; in response to triggering data conversion, controlling the lightweight node to transmit to-be-converted first plaintext data and an algorithm type identifier matched with a target encryption algorithm to a TEE module according to the lightweight node and a TEE interface address corresponding to the lightweight node; and controlling the TEE module to encrypt the first plaintext data into ciphertext data or decrypt the first plaintext data into second plaintext data according to the conversion requirement, and generating zero-knowledge proof at the same time.

Description

Technical Field

[0001] This application relates to the fields of blockchain and information security technology, and more specifically, to a distributed ledger encryption method and system based on blockchain. Background Technology

[0002] In the rapidly developing field of blockchain technology, the security of distributed ledgers has become one of the key challenges. With the continuous expansion of application scenarios, from financial transactions to medical data processing and IoT device management, the demand for data protection is increasing daily.

[0003] However, traditional encryption methods have revealed some limitations when facing these diverse application scenarios. First, improper key management can easily lead to security vulnerabilities; for example, key reuse or leakage can pose risks to the entire system. Second, a single encryption algorithm is difficult to meet the requirements of different data sensitivities and node computing capabilities, which not only affects the overall security of the system but may also lead to resource waste or performance bottlenecks. Furthermore, with the increasing demand for cross-chain interactions, ensuring compatibility and security between heterogeneous blockchains has become a pressing issue. Existing solutions often cannot simultaneously achieve efficiency, flexibility, and resistance to quantum attacks. Therefore, a new encryption mechanism is needed to improve the security and efficiency of distributed ledgers, especially by supporting the dynamic selection of multiple encryption algorithms to effectively protect lightweight nodes and ensure the security and reliability of cross-chain operations. Summary of the Invention

[0004] The purpose of this application is to provide a blockchain-based distributed ledger encryption method and system that can solve at least one of the aforementioned technical problems. The specific solution is as follows:

[0005] According to a specific implementation of this application, in a first aspect, this application provides a blockchain-based distributed ledger encryption method, comprising:

[0006] A key identifier hash value containing key version and timestamp is generated for each node. A Merkle tree is constructed based on the key identifier hash values ​​of each node, and the root hash of the Merkle tree is calculated and written into the blockchain. For each node, an encryption algorithm is dynamically selected based on data sensitivity level, node computing power, and node latency threshold. The selected encryption algorithm is then verified for security based on the root hash, and the final target encryption algorithm is output. In response to a triggered data conversion, the lightweight node is controlled to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to its corresponding interface address. The TEE module is then controlled to encrypt the first plaintext data into ciphertext data or decrypt it into second plaintext data according to the conversion requirements, while simultaneously generating a zero-knowledge proof.

[0007] In one embodiment, the step of dynamically selecting an encryption algorithm based on data sensitivity level, node computing power, and node latency threshold, and verifying the security of the selected encryption algorithm according to the root hash, and outputting the final target encryption algorithm, includes: dynamically selecting an encryption algorithm based on data sensitivity level, node computing power, and node latency threshold, and filtering candidate encryption algorithms from an encryption algorithm library; in response to detecting that the root hash has not changed and that the hash value of the key identifier currently used by the node is consistent with the root hash, outputting the candidate encryption algorithm as the final target encryption algorithm; and in response to detecting that the root hash has changed, or that the hash value of the key identifier currently used by the node is inconsistent with the root hash, outputting the highest-level encryption algorithm as the final target encryption algorithm.

[0008] In one embodiment, the step of selecting candidate encryption algorithms from the encryption algorithm library includes: in response to the data sensitivity level being a first data sensitivity level, selecting the SM4 symmetric encryption algorithm as a candidate encryption algorithm; in response to the data sensitivity level being a second data sensitivity level, selecting the Paillier homomorphic encryption algorithm as a candidate encryption algorithm; in response to the data sensitivity level being a third data sensitivity level, selecting the LWE lattice cryptography encryption algorithm as a candidate encryption algorithm; and in response to the node computing power being less than 1.5 GHz, or the node latency threshold being greater than 50 ms, selecting the SM4 encryption algorithm as a candidate encryption algorithm.

[0009] In one embodiment, the method further includes: designating each of the nodes as a target node; calculating a node reputation score based on the node behavior logs of the target node and the root hash; and dynamically adjusting the encryption strategy of the target node according to the score range to which the node reputation score belongs; wherein the node reputation score is calculated using the following formula: Reputation=α·Block_Valid+β·Vote_Rate-γ·Penalty+Proot ·μ; where Reputation is the node's reputation score, α, β, γ, and μ are the weighting coefficients, Block_Valid is the number of times the node successfully produces blocks, Vote_Rate is the node's voting success rate, Penalty is the number of times the node violates the rules, and Proot represents the probability of cryptographic data consistency between the node and the root hash within a specified historical period.

[0010] In one implementation, dynamically adjusting the encryption strategy of the target node according to the rating range to which the node reputation score belongs includes: allowing the target node to use a simplified encryption process in response to the node reputation score belonging to a first rating range; forcing the target node to use homomorphic encryption in response to the node reputation score belonging to a second rating range; and disabling the encryption privileges of the target node in response to the node reputation score belonging to a third rating range; wherein the minimum score in the first rating range is greater than or equal to the maximum score in the second rating range, and the minimum score in the second rating range is greater than or equal to the maximum score in the third rating range.

[0011] In one embodiment, the method further includes: generating a revocation certificate when the node reputation score of the target node is lower than a preset score threshold; and binding the revocation certificate with the node identifier of the target node and writing it into the blockchain.

[0012] In one embodiment, the method further includes: in response to triggering a cross-chain transaction, converting the encrypted data of the current chain into the encrypted format of the target chain according to the encryption standard of the target chain and the algorithm type identifier of the current chain; signing the converted data using a post-quantum signature algorithm, and setting a hash time lock condition so that if the target chain does not receive signature verification within a specified time, it controls the transaction to roll back.

[0013] In one embodiment, the method further includes: in response to completing a single data task, calling a verification node to perform data verification according to the data hash path, zero-knowledge proof digest, and root hash, and outputting the verification result; storing the verification result and the corresponding target data hash in a cache database, and setting a retention period; in response to triggering data verification for the target data within the retention period, retrieving the cached value of the target data from the cache database and outputting it.

[0014] In one embodiment, the method further includes: generating a temporary key in response to the current node triggering a change of encryption algorithm; encrypting the old key of the current node using the temporary key to obtain an encrypted old key; and storing the encrypted old key and the new key in the blockchain.

[0015] According to a specific embodiment of this application, in a second aspect, this application provides a blockchain-based distributed ledger encryption system, comprising:

[0016] A creation unit is used to generate a key identifier hash value containing key version and timestamp for each node, construct a Merkle tree based on the key identifier hash values ​​of each node, calculate the root hash of the Merkle tree and write it into the blockchain; a filtering unit is used to dynamically select an encryption algorithm for each node based on data sensitivity level, node computing power and node latency threshold, and perform security verification on the selected encryption algorithm according to the root hash, and output the final target encryption algorithm; a processing unit, in response to triggering data conversion, controls the lightweight node to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding TEE interface; a control unit is used to control the TEE module to encrypt the first plaintext data into ciphertext data or decrypt it into second plaintext data according to the conversion requirements, and generate a zero-knowledge proof.

[0017] Compared with the prior art, the above-described solution in this application has at least the following beneficial effects: This application provides a blockchain-based distributed ledger encryption method. The process of generating a key identifier hash value containing key version and timestamp for each node, constructing a Merkle tree based on these hash values, calculating its root hash, and writing it into the blockchain not only ensures the transparency and immutability of key management but also enhances system security through on-chain records. This method makes key version changes clear and traceable, while old version keys automatically become invalid after updates, preventing security risks caused by key reuse. Attached Figure Description

[0018] Figure 1 A flowchart of a blockchain-based distributed ledger encryption method is shown.

[0019] Figure 2 A flowchart illustrating a method for outputting the final target encryption algorithm is shown.

[0020] Figure 3 A flowchart illustrating a method for dynamically adjusting the encryption strategy of target nodes is shown.

[0021] Figure 4 A flowchart of a method for disabling nodes is shown;

[0022] Figure 5 A flowchart illustrating a method for completing cross-chain transactions is shown.

[0023] Figure 6 A flowchart illustrating a caching and retrieval method based on data validation is shown.

[0024] Figure 7 A block diagram of a blockchain-based distributed ledger encryption system according to an embodiment of this application is shown. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0027] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0028] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0029] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0030] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0031] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0032] The optional embodiments of this application are described in detail below with reference to the accompanying drawings.

[0033] The embodiments provided in this application are embodiments of a blockchain-based distributed ledger encryption method.

[0034] The following is combined Figure 1 The embodiments of this application will be described in detail.

[0035] Figure 1 A flowchart of a blockchain-based distributed ledger encryption method is shown, such as... Figure 1 As shown, it includes the following steps.

[0036] Step S101: Generate a key identifier hash value containing key version and timestamp for each node, construct a Merkle tree based on the key identifier hash values ​​of each node, calculate the root hash of the Merkle tree and write it to the blockchain.

[0037] Step S102: For each node, dynamically select an encryption algorithm based on the data sensitivity level, node computing power, and node latency threshold, and verify the security of the selected encryption algorithm according to the root hash, and output the final target encryption algorithm.

[0038] Step S103: In response to the triggering of data conversion, the lightweight node is controlled to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding remote trusted execution environment (TEE).

[0039] Step S104: Control the TEE module to encrypt the first plaintext data into ciphertext data or decrypt it into the second plaintext data according to the conversion requirements, and generate a zero-knowledge proof at the same time.

[0040] In this embodiment of the application, dynamic updates of key versions and security assurance are achieved through on-chain multi-key management and lifecycle mechanisms. The following shows some implementation details of the above steps.

[0041] As a specific embodiment, each network node in this application generates a unique node identifier (Node_ID) and creates an initial key pair during initialization. The key version management process includes generating a corresponding timestamp_i for each key version K_i (i≥1), accurate to the millisecond level, and calculating the key identifier hash value: H_kv = SHA256(K_i||timestamp_i). When the key is updated, the old version is retained in the history but marked as invalid.

[0042] As a specific implementation, the key identifier hash values ​​of all nodes are organized using a Merkle tree. The construction rules of the Merkle tree include: leaf nodes are the H_kv values ​​of each node, middle nodes are the concatenated hashes of the child node hashes, when the number of nodes is odd, the last hash value is copied as a pair, the root hash of the Merkle tree is updated every 5 blocks and stored in a block height binding manner.

[0043] As a specific implementation, the key version index hash generation process is as follows: Each node's key version (K_i) is concatenated with its generation timestamp (timestamp_i), and a key identifier hash value H_kv is generated using the SHA-256 algorithm. For example, if node A generates key K1 (an SM4 key in this example) at timestamp T1, then H_kv1 = SHA256(K1||T1). If it is subsequently updated to key K2 (a Paillier public key in this example), then the corresponding H_kv2 = SHA256(K2||T2) is generated. Based on this, the Merkle tree combines H_kv1 and H_kv2 into a root hash and writes it into the blockchain.

[0044] For example, the process of recording the key lifecycle on the blockchain includes binding the root hash to the block height and storing it in the blockchain's smart contract, forming a key version history chain. Simultaneously, the output includes the updated Merkle tree root hash and the key lifecycle log recorded on the blockchain.

[0045] In one specific implementation, in response to the current node triggering a change in encryption algorithm, a temporary key is generated. The old key of the current node is then encrypted using the temporary key to obtain the encrypted old key. Based on this, the encrypted old key and the new key are stored in the blockchain.

[0046] In this embodiment, key traceability is achieved through Merkle trees and blockchain records. Key version changes are transparent and tamper-proof. An automatic expiration mechanism ensures that when a key version is updated, the hash value of the old key remains in the Merkle tree but is no longer used in subsequent encryption processes, thus preventing security risks caused by key reuse. When it is necessary to change the encryption algorithm, the old key is encrypted by generating a temporary key. This protects the security of the old key while facilitating the deployment and use of the new key. This method simplifies the transition steps in the key management process, ensuring data security without affecting business continuity.

[0047] In the above embodiments, in response to triggering data conversion, the lightweight node transmits the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding TEE interface. The TEE module then encrypts the first plaintext data into ciphertext data or decrypts it into second plaintext data according to the conversion requirements, while generating a zero-knowledge proof. This process ensures the security of encryption / decryption operations through the isolated execution environment of the TEE module and verifies the legality of the operation through zero-knowledge proof, without exposing the key or encryption details.

[0048] In some embodiments, a trusted computing collaboration mechanism is provided, the core of which is to implement data encryption / decryption operations of lightweight nodes through the TEE interface, and to combine zero-knowledge proof technology to ensure the security and privacy of the operation.

[0049] As a specific implementation, the TEE interface specification includes the following input parameters: Plaintext M: The data content to be processed, with a maximum support of 1MB; Algorithm type identifier Algorithm_Type: Used to indicate the type of algorithm required for encryption or decryption operations; Call credential Token: Verifies the legality of the interface call, with a validity period of 5 minutes.

[0050] Based on this, the output includes the following two parts:

[0051] 1. Ciphertext data or second plaintext data: encrypted data or decrypted original data;

[0052] 2. Operation status code: 0 indicates successful operation, and non-zero indicates operation failure or exception.

[0053] As a specific embodiment, the zero-knowledge proof generation process includes a statement, a witness, and a verification process. The statement contains the input data hash, algorithm type, and timestamp, declaring the legality of the operation (e.g., "data has been correctly encrypted"). The witness contains a TEE internal log digest and key usage records, used only for proof generation. The verification process includes a verification node calling Verify(Statement, π) to confirm the correctness of the operation.

[0054] For example, during processing, lightweight nodes need to transmit plaintext data and the matching target encryption algorithm type identifier (Algorithm_Type) to a remote TEE module. The TEE module internally performs encryption or decryption operations but does not directly expose key information, ensuring key security. Subsequently, the TEE module generates a zero-knowledge proof π = Prove(Statement, Witness), where Statement declares the legality of the operation, Witness records the encryption process log within the TEE, and the verification node verifies the correctness of the operation using Verify(Statement, π) without needing to access the TEE's internal state.

[0055] In some embodiments, IoT devices need to encrypt sensor data, but their computing power is insufficient. Therefore, this application sends the data to a trusted execution environment by calling a remote TEE interface. The TEE module completes the encryption and generates a zero-knowledge proof. The verification node confirms the correctness of the encryption operation without needing to obtain the encryption key or sensitive data details.

[0056] The method provided in this application eliminates the need for lightweight nodes to directly handle keys; encryption / decryption operations are performed by the TEE module, reducing the risk of key leakage. Simultaneously, zero-knowledge proofs ensure that the verification process does not reveal any encryption details, only verifying the legality of the operation, thus protecting data privacy.

[0057] Figure 2 A flowchart illustrating a method for outputting the final target encryption algorithm is shown, as follows: Figure 2 As shown, it includes the following steps.

[0058] Step S201: Dynamically select an encryption algorithm by combining the data sensitivity level, node computing power and node latency threshold, and screen out candidate encryption algorithms from the encryption algorithm library.

[0059] In step S202a, in response to the detection that the root hash has not changed and the key identifier hash value currently used by the node is consistent with the root hash, the candidate encryption algorithm is output as the final target encryption algorithm.

[0060] In step S202b, in response to the detection that the root hash has changed or that the key identifier hash value used by the current node is inconsistent with the root hash, the highest level encryption algorithm is output as the final target encryption algorithm.

[0061] In this embodiment, the root hash serves to verify the key status and enhance security. On one hand, before performing encryption operations, it may be necessary to verify whether the key of the relevant node is valid or has been updated. By comparing the hash value of the currently used key identifier with the root hash stored on the blockchain, it can be confirmed whether the node's key version information is correct and has not been tampered with, which is crucial for ensuring the security and correctness of encryption operations. On the other hand, using the root hash as one of the input parameters can provide an additional layer of security when selecting encryption algorithms. For example, in some cases, if a change in the root hash is detected, it may be necessary to re-evaluate the encryption strategy or enforce the use of a higher-level encryption algorithm to protect the data.

[0062] In some embodiments, an encryption path selection algorithm can be used to filter encryption algorithms from a library of encryption algorithms, based on the following rules:

[0063] (1) Matching data sensitivity level with encryption algorithm: When the data sensitivity level is the first data sensitivity level (S_level=0), the SM4 symmetric encryption algorithm is selected as the candidate encryption algorithm; when the data sensitivity level is the second data sensitivity level (S_level=1), the Paillier homomorphic encryption algorithm is selected as the candidate encryption algorithm; when the data sensitivity level is the third data sensitivity level (S_level=2), the LWE lattice cipher encryption algorithm is selected as the candidate encryption algorithm.

[0064] (2) Adjustment of computing power and latency constraints: If the node computing power is less than 1.5GHz, or the node latency threshold is greater than 50ms, the SM4 encryption algorithm will be forced to be used as the alternative encryption algorithm to reduce computing overhead.

[0065] As a specific embodiment, the encryption algorithm parameter adaptation process includes the following methods.

[0066] SM4 encryption: key length is 128 bits, block size is 128 bits;

[0067] Paillier encryption: Key length is 2048 bits, supports additive homomorphism;

[0068] LWE lattice cryptography: Based on the learning error-prone problem, the key length is 4096 bits, which meets the requirements for resistance to quantum attacks.

[0069] For example, if the root hash is detected as unchanged and the key identifier hash value currently used by the node matches the root hash, the candidate encryption algorithms selected above are output as the final target encryption algorithm. Conversely, if the root hash is detected as changed, or the key identifier hash value currently used by the node does not match the root hash, the highest-level encryption algorithm is output as the target encryption algorithm.

[0070] As a specific implementation, if node B needs to encrypt medical data (S_level=2), its CPU is 2.0GHz, and the latency threshold is 60ms. According to the rules, LWE lattice encryption is selected, ciphertext is generated, and Algorithm_Type=2 is marked. This process dynamically adapts the highly sensitive data and the node's computing power to ensure that the encryption strength meets the quantum resistance requirements while avoiding resource waste.

[0071] In this embodiment, the encryption algorithm is dynamically selected based on a comprehensive assessment of data sensitivity level, node capabilities, and latency thresholds. This avoids resource waste due to over-encryption or security vulnerabilities caused by insufficient algorithms. Furthermore, highly sensitive data is encrypted using LWE lattice cryptography by default. LWE cryptography is based on quantum mathematical problems and can resist future quantum computing attacks. Combined with a root hash verification mechanism, it further ensures the consistency between the encryption strategy and the on-chain key state.

[0072] In this embodiment, the encryption algorithm is dynamically selected based on data sensitivity level, node computing power, and latency threshold, and security verification is performed based on the root hash, which helps to improve efficiency while ensuring security. When it is detected that the root hash has not changed and the key identifier hash used by the node is consistent with the root hash, the alternative algorithm is used; otherwise, the highest level encryption algorithm is used. This mechanism ensures that the system can maintain a high level of security protection even when the network state changes or potential threats occur.

[0073] Figure 3 A flowchart illustrating a method for dynamically adjusting the encryption strategy of a target node is shown, such as... Figure 3 As shown, it includes the following steps.

[0074] Step S301: Designate each node as a target node.

[0075] Step S302: Calculate the node reputation score based on the node behavior log and root hash of the target node.

[0076] Step S303: Dynamically adjust the encryption strategy of the target node according to the rating range to which the node's reputation score belongs.

[0077] For example, the node reputation score is calculated using the following formula:

[0078] Reputation=α·Block_Valid+β·Vote_Rate-γ·Penalty+P root ·μ;

[0079] Where Reputation is the node's reputation score, α, β, γ, and μ are the weighting coefficients, Block_Valid is the number of times the node successfully produces blocks, Vote_Rate is the node's voting success rate, Penalty is the number of times the node violates the rules, and Proot represents the probability of cryptographic data consistency between the node and the root hash within a specified historical period.

[0080] In related technologies, the number of successful block productions, successful votes, and violations by a node are commonly used as factors in node reputation scoring.

[0081] In this embodiment of the application, based on the establishment that the root hash is a reference for node reputation, the factors that can meet the evaluation requirements are adaptively configured according to the influence of node reputation score, the number of successful block productions by the node and the number of violations by the node on the node reputation score, and the importance of the root hash relative to other factors, namely the probability of cryptographic data consistency between the node and the root hash within a specified historical period.

[0082] In this application, considering that setting the specified historical period too long would lead to the storage of too much junk data, while setting it too short would be detrimental to data accuracy, the specified historical period is set to 30 days as a specific embodiment.

[0083] In some embodiments, the probability of cryptographic data consistency between a node and the root hash within a specified historical time period is determined based on the ratio between the number of times cryptographic data is consistent and the number of comparisons. For example, if the cryptographic data between a node and the root hash is compared 20 times within a historical 30-day period, and the number of consistency is 18, then the probability of cryptographic data consistency is 90%.

[0084] Since the factors used to calculate the node reputation score all need to be multiplied by their weighting coefficients to provide specific numerical values, and the probability of encrypted data consistency typically differs by orders of magnitude from the number of successful block productions, the node voting success rate, and the number of node violations, it is considered that the weighting coefficients α, β, and γ are generally set to values ​​between 1 and 0.1. Therefore, the weighting coefficient μ is set to be consistent with the order of magnitude of the number of successful block productions, the node voting success rate, and the number of node violations.

[0085] Based on this, the weighting coefficient μ is set to be on the same order of magnitude as the number of successful block productions, the node voting success rate, and the number of node violations. The encrypted data consistency probability is on the same order of magnitude as α, β, and γ. The differences in the products of the four factors are all on the same order of magnitude, and each factor can play a decisive role in the value of the node reputation score. Therefore, the encrypted data consistency probability can be considered an effective factor.

[0086] As a feasible implementation, in order to make the weight coefficient μ consistent with the order of magnitude of the number of successful block productions, the success rate of voting, and the number of violations by nodes, the value of the weight coefficient μ can be set to the average of the number of successful block productions, the success rate of voting, and the number of violations by nodes.

[0087] As some other feasible embodiments, α, β, and γ are taken as 0.2, 0.3, and 0.4, respectively.

[0088] For example, the encryption strategy of the target node can be dynamically adjusted according to the score range to which the node's reputation score belongs, including the following three methods:

[0089] Method 1: In response to the node's reputation score falling within the first scoring range, the target node is allowed to use a simplified encryption process.

[0090] Method 2: In response to the node's reputation score falling within the second scoring range, force the target node to use homomorphic encryption.

[0091] Method 3: In response to the node's reputation score falling within the third scoring range, disable the target node's encryption permissions.

[0092] Among them, the minimum score in the first scoring range is greater than or equal to the maximum score in the second scoring range, and the minimum score in the second scoring range is greater than or equal to the maximum score in the third scoring range.

[0093] In some embodiments, the dynamic adjustment mechanism may be a sliding window mechanism, with the time window being the most recent 1000 blocks, and the score being recalculated every 100 blocks.

[0094] As a specific implementation, the dynamic adjustment rules of the encryption strategy include:

[0095] High-reputation nodes (first rating range: Reputation≥85): Allow the use of simplified encryption processes (such as SM4 single encryption) and prioritize the allocation of new keys.

[0096] Medium reputation nodes (second rating range: 60≤Reputation<85): enforce standard encryption procedures, such as Paillier homomorphic encryption.

[0097] Low-reputation nodes (third rating range: Reputation < 60): Encryption permissions are disabled and require manual review to restore; transaction latency is increased by 30%.

[0098] By analyzing the behavior logs of target nodes to calculate reputation scores and dynamically adjusting encryption policies accordingly, good behavior is encouraged within the network. Nodes with high reputation scores enjoy the efficiency advantages of simplified encryption processes, while low-reputation nodes face stricter encryption requirements or may even have their encryption privileges disabled. This mechanism effectively prevents potential threats to the system from malicious nodes.

[0099] Figure 4 A flowchart of a method for disabling nodes is shown, such as Figure 4 As shown, it includes the following steps.

[0100] Step S401: When the node reputation score of the target node is lower than the preset score threshold, generate a certificate revocation certificate.

[0101] Step S402: Bind the revocation certificate to the node identifier of the target node and write it into the blockchain.

[0102] In this embodiment, while adjusting the encryption strategy based on the node reputation score, when the node reputation falls below a certain threshold, a revocation certificate is generated and bound to the node identifier before being written into the blockchain. This step strengthens the control measures for low-trust nodes and improves the security and stability of the entire network.

[0103] Figure 5 A flowchart illustrating a method for completing cross-chain transactions is shown, such as... Figure 5 As shown, it includes the following steps.

[0104] Step S501: In response to triggering a cross-chain transaction, the encrypted data of the current chain is converted into the encrypted format of the target chain according to the encryption standard of the target chain and the algorithm type identifier of the current chain.

[0105] Step S502: Sign the transformed data using the post-quantum signature algorithm and set a hash time lock condition so that if the target chain does not receive signature verification within a specified time, the transaction is rolled back.

[0106] In some embodiments, a cross-chain compatibility encryption module design is provided. Its core lies in combining an Encryption Aggregator Converter (EAC) with post-quantum signature technology to achieve encrypted data format conversion and secure transaction protection between heterogeneous blockchains. This module can adapt to the encryption standards of various blockchains, ensuring efficient and secure data exchange between different encryption systems.

[0107] As a feasible implementation, the invocation process of the Encryption Convergence Converter (EAC) includes the following operations: First, the input data is parsed, receiving cross-chain transaction data D, the target chain's encryption standard (Target_Encryption_Standard), and the encryption algorithm type identifier Algorithm_Type output in step two. Then, encryption format conversion is performed according to the encryption standard supported by the target chain. If the target chain supports Paillier encryption, Algorithm_Type = 1 is retained, and the original ciphertext is directly output; if the target chain only supports SM4 encryption, the Paillier ciphertext is converted to SM4 ciphertext through a key migration mechanism, generating cross-chain compatible encrypted data D′. This conversion process relies on an encryption parameter mapping table and a key negotiation mechanism to ensure data consistency and security across different encryption systems.

[0108] As a specific implementation, the processing flow of combining Hash Time Lock (HTLC) with post-quantum signature is as follows: After completing the encryption format conversion, the converted data D′ is signed using the Dilithium post-quantum signature algorithm, generating a signature S = SignDilithium(D′), with a signature length of 2592 bytes and a verification time of less than 15ms. Subsequently, HTLC conditions are set: if the target chain fails to complete signature verification within a specified time (e.g., 10 minutes), a transaction rollback mechanism is triggered, restoring the transaction state to the source chain, ensuring the atomicity and reversibility of cross-chain operations.

[0109] For example, in a cross-chain transaction scenario, chain A uses the Paillier encryption algorithm, while chain B uses the SM4 encryption algorithm. Once the EAC module detects that the target chain B only supports SM4 encryption, it automatically converts the Paillier ciphertext from chain A into SM4 ciphertext via key migration and signs the converted data using the Dilithium algorithm. If chain B fails to complete signature verification within 10 minutes, the HTLC mechanism automatically triggers a transaction rollback, restoring the state to chain A, thereby avoiding the risks of fund locking or transaction failure.

[0110] The intermediate data processing flow includes: first, identifying the encryption standard and matching the algorithm; then, performing key migration and format conversion; next, generating a post-quantum signature on the converted data and binding the signature to the data; finally, sending the data and signature together to the target chain and monitoring the status according to the hash time lock condition. All parameters involved in the entire process, such as encryption algorithms, key lengths, and signature verification times, are standardized to ensure compatibility and performance stability.

[0111] Regarding exception handling mechanisms, it possesses multiple fault-tolerance capabilities. When the target chain's encryption standard cannot recognize or supports it, the exception is automatically recorded and an error code is returned, prompting the caller to check the configuration. If key migration fails or the integrity verification of the converted data fails, a retry mechanism will be triggered or the transaction will be rolled back to its original state. In the event of signature verification failure or HTLC timeout, transaction rollback will be automatically executed, and audit logs will be generated for subsequent analysis. Furthermore, a signature caching mechanism is supported to avoid duplicate signature operations and improve processing efficiency.

[0112] In the above embodiment, the final output includes cross-chain compatible encrypted data D′ and a post-quantum signature S. D′ can be correctly identified and decrypted by the target chain, while S ensures data integrity and transaction non-repudiation. This output can be directly used for cross-chain transaction broadcasting, node verification, and consensus processes. The beneficial effects of this embodiment include: In terms of heterogeneous chain compatibility, the EAC module supports multiple encryption standards such as Bitcoin-based (ECDSA), Ethereum-based (SM2), and consortium chains (Chinese cryptographic algorithms), unifying the encryption formats of different chains and reducing the complexity of cross-chain communication; in terms of quantum security, the Dilithium signature algorithm meets the NIST post-quantum cryptography standard, ensuring that cross-chain transactions remain reliable even under quantum computing attacks; and in terms of efficiency, the EAC conversion latency is less than 200ms, and combined with a hash time lock mechanism, it significantly reduces the latency and failure risk of cross-chain transactions.

[0113] The embodiments of this application are widely applicable to scenarios such as cross-chain bridging, multi-chain asset transfer, and heterogeneous chain interoperability, which can effectively improve the interconnection capabilities between blockchain systems and enhance the security and efficiency of cross-chain transactions.

[0114] Figure 6 A flowchart illustrating a data validation-based caching and retrieval method is shown, such as... Figure 6 As shown, it includes the following steps.

[0115] Step S601: In response to the completion of a single data task, the verification node is invoked to perform data verification according to the data hash path, zero-knowledge proof digest, and root hash, and the verification result is output.

[0116] Step S602: Store the verification result and the corresponding target data hash in the cache database and set the retention period.

[0117] Step S603: In response to triggering data verification for the target data within the retention period, retrieve the cached value of the target data from the cache database and output it.

[0118] In some embodiments, an encryption verification path optimization and caching mechanism is provided, the core of which is to reduce the overhead of repeated calculations by caching verification results and improve the response efficiency of high-frequency data verification.

[0119] As a feasible implementation, the cache verification function call process includes: input data including the hash path (path_hash) of frequently accessed data, the zero-knowledge proof digest (ZKP_digest), and the Merkle tree root hash output in step one. The verification node calls the verification function Vresult = Verify(root hash, path_hash, ZKP_digest), where "root hash" is the Merkle tree root hash of the current block, "path_hash" represents the verification path of the data in the Merkle tree, and "ZKP_digest" is the zero-knowledge proof digest value generated using the SHA256 algorithm, used to quickly determine whether the operation is legal. After execution, the function returns a boolean value as the verification result, which, along with the corresponding data hash, is stored in the cache database.

[0120] As a specific implementation, the cache storage and retrieval mechanism includes the following rules: The cache data structure consists of a Key and a Value, where the Key is a data hash generated using the SHA3-256 algorithm, and the Value contains the verification result (1 bit), a timestamp (64 bits), and a proof digest (256 bits). The caching strategy uses the LRU eviction algorithm to manage cache entries, with a maximum cache entry count of 100,000. The default time-to-live (TTL) for cache entries is 300 seconds, and it supports dynamic configuration according to business needs. When the cache capacity reaches its limit or a cache entry expires, an automatic cleanup mechanism is triggered to ensure the freshness and availability of cached data.

[0121] For example, in a high-frequency trading scenario, the hash path of a piece of data is path_hash = [H1, H2, H3], and the corresponding zero-knowledge proof digest is ZKP_digest = SHA256(π). After the verification node calls the Verify function, it writes the verification result Vresult(True / False) and the hash value of the data as a key-value pair to the cache database and sets the TTL to 5 minutes. When the same data is requested for verification again, the result is read from the cache first, avoiding repeated execution of the complete verification process, thereby significantly reducing computational overhead and improving response speed.

[0122] In the above embodiments, the intermediate data processing flow includes: first, performing layered processing on the original data, constructing a Merkle tree structure and extracting path hashes; then, calculating the digest of the zero-knowledge proof to generate a fixed-length ZKP_digest; and finally, passing the above information as parameters into the verification function for logical verification. Based on this, if the verification passes, the result is cached and the timestamp and TTL information are updated; if the verification fails, an exception log is recorded and a retry mechanism is triggered. In the event of a cache miss, the complete verification process is automatically initiated, and upon completion, the new result is written to the cache for subsequent use.

[0123] In the above embodiments, the exception handling mechanism has multiple fault tolerance capabilities. When a cache read fails or data expires, it automatically rolls back to the complete verification process and records relevant exception events for subsequent analysis. If errors such as path hash mismatch or invalid ZKP digests occur during verification, the request will be marked as a suspicious operation, and an audit process will be initiated for further inspection. In addition, to address issues such as cache penetration, cache breakdown, and cache avalanche, techniques such as random TTL offsets, hot data preloading, and Bloom filters are introduced to effectively ensure the stability and security of the cache.

[0124] In the above embodiment, the final output includes the verification result Vresult (True / False) and a cache update record, the latter detailing the information of newly added or updated cache entries. The beneficial effects of this embodiment include: performance improvement, reducing redundant verification calculations through the caching mechanism, resulting in a throughput increase of over 50%; significantly reduced response latency, with verification time for frequently accessed data decreasing from milliseconds to microseconds; and more efficient resource utilization, effectively balancing cache usage and data timeliness requirements by combining the LRU eviction algorithm with a configurable TTL mechanism. This mechanism is widely applicable to multiple fields such as distributed ledgers, high-frequency trading, and blockchain consensus, significantly improving overall response speed and processing capacity.

[0125] This application also provides system embodiments that follow the above embodiments, for implementing the method steps of the above embodiments. The interpretation of the same names is the same as that of the above embodiments, and they have the same technical effects as those of the above embodiments, so they will not be repeated here.

[0126] like Figure 7 As shown, this application provides a blockchain-based distributed ledger encryption system 700, comprising:

[0127] Create unit 701 to generate a key identifier hash value containing key version and timestamp for each node, construct a Merkle tree based on the key identifier hash values ​​of each node, calculate the root hash of the Merkle tree and write it to the blockchain.

[0128] The filtering unit 702 is used to dynamically select an encryption algorithm for each node based on the data sensitivity level, node computing power, and node latency threshold, and to perform security verification on the selected encryption algorithm according to the root hash, and output the final target encryption algorithm.

[0129] Processing unit 703, in response to triggering data conversion, controls the lightweight node to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding remote trusted execution environment (TEE).

[0130] The control unit 704 is used to control the TEE module to encrypt the first plaintext data into ciphertext data or decrypt it into the second plaintext data according to the conversion requirements, and at the same time generate zero-knowledge proofs.

[0131] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0132] Although the operations are described in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order or serial order shown, or requiring all of the operations shown to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous.

[0133] The methods and systems of this application can be implemented using standard programming techniques, utilizing rule-based logic or other logic to implement various method steps. It should also be noted that the terms "system" and "module" as used herein and in the claims are intended to include implementations using one or more lines of software code and / or hardware implementations and / or devices for receiving input.

[0134] Any step, operation, or procedure described herein may be performed or implemented using one or more hardware or software modules, either alone or in combination with other devices. In one embodiment, the software module is implemented using a computer program product comprising a computer-readable medium containing computer program code, which is executable by a computer processor to perform any or all of the described steps, operations, or procedures.

[0135] The foregoing description of implementations of this application has been provided for illustrative and descriptive purposes. The foregoing description is not exhaustive and is not intended to limit this application to the exact forms disclosed. Various modifications and variations may exist in accordance with the foregoing teachings, or may arise from practice of this application. These embodiments were chosen and described to illustrate the principles of this application and its practical application, enabling those skilled in the art to utilize this application in various implementations and modifications to suit the specific purpose of the concept.

[0136] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0137] It can be further understood that, unless otherwise specified, "connection" includes both direct connections where no other components exist between the two parties and indirect connections where other components exist between them.

[0138] It is further understood that although the operations are described in a specific order in the accompanying drawings in the embodiments of this application, this should not be construed as requiring these operations to be performed in the specific order or serial order shown, or requiring all the operations shown to be performed to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous.

[0139] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the field of this application that are not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0140] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0141] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A distributed ledger encryption method based on blockchain, characterized in that, include: Generate a key identifier hash value containing key version and timestamp for each node, construct a Merkle tree based on the key identifier hash values ​​of each node, calculate the root hash of the Merkle tree and write it into the blockchain; For each node, an encryption algorithm is dynamically selected based on the data sensitivity level, node computing power, and node latency threshold. The selected encryption algorithm is then verified for security based on the root hash, and the final target encryption algorithm is output. In response to the triggering of data conversion, the lightweight node is controlled to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding remote trusted execution environment (TEE). The TEE module is controlled to encrypt the first plaintext data into ciphertext data or decrypt it into the second plaintext data according to the conversion requirements, while generating zero-knowledge proofs.

2. The method according to claim 1, characterized in that, The process of dynamically selecting an encryption algorithm based on data sensitivity level, node computing power, and node latency threshold, and verifying the security of the selected encryption algorithm according to the root hash, and outputting the final target encryption algorithm, includes: The encryption algorithm is dynamically selected by combining the data sensitivity level, node computing power and node latency threshold, and candidate encryption algorithms are screened from the encryption algorithm library; In response to the detection that the root hash has not changed and that the key identifier hash value currently used by the node is consistent with the root hash, the alternative encryption algorithm is output as the final target encryption algorithm; In response to the detection that the root hash has changed, or that the key identifier hash value used by the current node is inconsistent with the root hash, the highest level encryption algorithm is output as the final target encryption algorithm.

3. The method according to claim 2, characterized in that, The step of selecting candidate encryption algorithms from the encryption algorithm library includes: In response to the data sensitivity level being the first data sensitivity level, the SM4 symmetric encryption algorithm is selected as the alternative encryption algorithm. In response to the data sensitivity level being the second data sensitivity level, the Paillier homomorphic encryption algorithm is selected as the alternative encryption algorithm. In response to the data sensitivity level being the third data sensitivity level, the LWE lattice cryptography encryption algorithm is selected as the alternative encryption algorithm; When the node's computing power is less than 1.5 GHz or the node's latency threshold is greater than 50 ms, the SM4 encryption algorithm is used as the alternative encryption algorithm.

4. The method according to claim 1, characterized in that, The method further includes: Each of the aforementioned nodes is designated as the target node; Calculate the node reputation score based on the node behavior log of the target node and the root hash; The encryption strategy of the target node is dynamically adjusted according to the score range to which the node's reputation score belongs; The node reputation score is calculated using the following formula: Reputation=a·Block_Valid+b·Vote_Rate-c·Penalty+P root ·m; Where Reputation is the node's reputation score, α, β, γ, and μ are weighting coefficients, Block_Valid is the number of times the node successfully produces blocks, Vote_Rate is the node's voting success rate, Penalty is the number of times the node violates rules, and P root This represents the probability that the encrypted data between the node and the root hash is consistent within a specified historical time period.

5. The method according to claim 4, characterized in that, The step of dynamically adjusting the encryption strategy of the target node according to the score range to which the node's reputation score belongs includes: In response to the node's reputation score falling within the first score range, the target node is allowed to use a simplified encryption process; In response to the node's reputation score falling within the second scoring range, the target node is forced to use homomorphic encryption; In response to the node's reputation score falling within the third rating range, the encryption permissions of the target node are disabled; Wherein, the minimum score in the first scoring range is greater than or equal to the maximum score in the second scoring range, and the minimum score in the second scoring range is greater than or equal to the maximum score in the third scoring range.

6. The method according to claim 4 or 5, characterized in that, The method further includes: When the node reputation score of the target node falls below a preset score threshold, a certificate revocation is generated; The revocation certificate is bound to the node identifier of the target node and then written into the blockchain.

7. The method according to claim 1, characterized in that, The method further includes: In response to triggering a cross-chain transaction, the encrypted data of the current chain is converted into the encrypted format of the target chain according to the encryption standard of the target chain and the algorithm type identifier of the current chain; The transformed data is signed using a post-quantum signature algorithm, and a hash time lock condition is set so that if the target chain does not receive signature verification within a specified time, the transaction is rolled back.

8. The method according to claim 1, characterized in that, The method further includes: In response to the completion of a single data task, the verification node is invoked to perform data verification according to the data hash path, zero-knowledge proof digest, and root hash, and the verification result is output. The verification result and the corresponding target data hash are stored in the cache database, and the retention period is set. In response to triggering data verification for the target data within the retention period, the cached value of the target data is retrieved from the cache database and output.

9. The method according to claim 1, characterized in that, The method further includes: In response to the current node triggering a change in the encryption algorithm, a temporary key is generated. The old key of the current node is encrypted using the temporary key to obtain the encrypted old key; The encrypted old key and the new key are stored in the blockchain.

10. A blockchain-based distributed ledger encryption system, characterized in that, include: A creation unit is used to generate a key identifier hash value containing key version and timestamp for each node, construct a Merkle tree based on the key identifier hash value of each node, calculate the root hash of the Merkle tree and write it into the blockchain; The filtering unit is used to dynamically select an encryption algorithm for each node based on the data sensitivity level, node computing power, and node latency threshold, and to perform security verification on the selected encryption algorithm according to the root hash, and output the final target encryption algorithm. The processing unit, in response to the triggering of data conversion, controls the lightweight node to transmit the first plaintext data to be converted and the algorithm type identifier matching the target encryption algorithm to the Trusted Execution Environment (TEE) module according to the interface address of the lightweight node and its corresponding remote trusted execution environment (TEE). The control unit is used to control the TEE module to encrypt the first plaintext data into ciphertext data or decrypt it into the second plaintext data according to the conversion requirements, and at the same time generate zero-knowledge proofs.

Images