Transaction data distributed storage method, device and equipment and readable storage medium

Abstract

The invention discloses a transaction data distributed storage method, apparatus and device, and a readable storage medium. The method comprises the steps of obtaining transaction data marked with metadata in a corresponding edge node; according to the importance degree of the transaction data and the resource state of the corresponding edge node, determining the fragment specification; encrypting the transaction data to obtain encrypted transaction information; according to the fragmentation specification, fragmenting the encrypted transaction information to obtain a plurality of fragmentation subsets; based on the metadata, generating fragment metadata of each fragment subset; after the integrity and consistency verification is passed, obtaining signature meta-information of each fragment subset; and uploading each fragment subset and the corresponding fragment metadata and signature meta-information to a block chain consensus layer, so as to carry out distributed storage on each fragment subset and the corresponding fragment metadata. Therefore, safe and reliable storage of the transaction data can be completed by integrating the local TEE of each edge node and the block chain consensus node.

Description

Technical Field

[0001] This application relates to the field of distributed storage technology, and more specifically, to a method, apparatus, device, and readable storage medium for distributed storage of transaction data. Background Technology

[0002] With the rapid development of technologies such as the Internet of Things and 5G communication, edge computing, as a computing mode that is close to the data source, has been widely used in fields such as intelligent transportation, industrial IoT, and financial transactions.

[0003] However, in edge computing scenarios, a large amount of transaction data is generated at edge nodes. This transaction data often contains sensitive information and is characterized by high real-time requirements, large data volume, and dispersed distribution. How to securely process and store this transaction data while ensuring its credibility and privacy has become a critical issue that urgently needs to be addressed. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device, and readable storage medium for distributed storage of transaction data, used for secure processing and storage of transaction data.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] A distributed transaction data storage method is applied to the Trusted Execution Environment (TEE) of each edge node. The distributed transaction data storage method includes:

[0007] Retrieve transaction data marked with metadata from the corresponding edge nodes;

[0008] The sharding specifications are determined based on the importance of the transaction data and the resource status of the corresponding edge nodes.

[0009] The transaction data is encrypted to obtain encrypted transaction information;

[0010] The encrypted transaction information is fragmented according to the fragmentation specifications to obtain multiple fragment subsets;

[0011] Based on the aforementioned metadata, generate shard metadata for each shard subset;

[0012] Each shard subset is validated to verify its integrity and consistency.

[0013] After successful verification, each shard metadata is signed to obtain the signature metadata of each shard subset;

[0014] Each shard subset and its corresponding shard metadata and signature metadata are uploaded to the blockchain consensus layer so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored.

[0015] Optionally, determining the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes includes:

[0016] Based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, the shard size, number of shards, and sharding method are determined.

[0017] Optionally, determining the shard size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, includes:

[0018] Analyze the sensitivity, real-time requirements, scope of impact, and compliance requirements of the transaction data to assess its importance.

[0019] Based on the type and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, the shard size and sharding method are determined.

[0020] The number of shards is determined based on the size and sharding method of the transaction data.

[0021] Optionally, generating shard metadata for each shard subset based on the metadata includes:

[0022] Generate the encryption algorithm identifier, fragment identifier, fragment index, and MAC value for each fragment subset;

[0023] Based on the metadata, the data identifier and node identifier of the transaction data are determined;

[0024] The encryption algorithm identifier, fragment identifier, fragment index, MAC value, data identifier, and node identifier of the same fragment subset constitute the fragment metadata of the corresponding fragment subset.

[0025] Optionally, each shard subset and its shard metadata are validated to verify the integrity of each shard subset, including:

[0026] Generate the encrypted MAC value of the encrypted transaction information;

[0027] The individual fragment subsets are spliced ​​together to obtain the spliced ​​result;

[0028] Generate the splicing MAC value of the splicing result;

[0029] When the encrypted MAC value matches the concatenated MAC value, it is determined that each fragment subset has integrity.

[0030] When the encrypted MAC value is inconsistent with the concatenated MAC value, it is determined that one or more fragment subsets are incomplete, and the process returns to the step of fragmenting the encrypted transaction information according to the fragmentation specification to obtain multiple fragment subsets.

[0031] Optionally, each shard subset is validated to verify its consistency, including:

[0032] Determine whether each shard subset meets the sharding specifications;

[0033] When the condition is met, each shard subset is determined to have passed the consistency check;

[0034] If the conditions are not met, it is determined that each shard subset has failed the consistency check, and the process returns to the step of determining the sharding specification based on the importance of the transaction data and the resource status of the corresponding edge node.

[0035] Optionally, the signing of each shard metadata to obtain the signature metadata of each shard subset includes:

[0036] Generate random numbers;

[0037] Based on the generation timestamp of each shard metadata and the random number, each shard metadata is signed to obtain the signature metadata of each shard subset.

[0038] A distributed storage device for transaction data, comprising:

[0039] The acquisition module is used to acquire transaction data marked with metadata in the corresponding edge nodes;

[0040] The determination module is used to determine the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes;

[0041] An encryption module is used to encrypt the transaction data to obtain encrypted transaction information;

[0042] The sharding module is used to shard the encrypted transaction information according to the sharding specifications to obtain multiple shard subsets;

[0043] A generation module is used to generate shard metadata for each shard subset based on the metadata.

[0044] The verification module is used to verify each shard subset, checking the integrity and consistency of each shard subset;

[0045] The signature module is used to sign the metadata of each shard after successful verification, so as to obtain the signature metadata of each shard subset;

[0046] The storage module is used to upload each shard subset and its corresponding shard metadata and signature metadata to the blockchain consensus layer, so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification of the blockchain nodes, the shard subset and its corresponding shard metadata are distributed and stored.

[0047] A distributed storage device for transaction data includes a memory and a processor;

[0048] The memory is used to store programs;

[0049] The processor is used to execute the program to implement the various steps of the above-described distributed storage method for transaction data.

[0050] A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the various steps of the above-described distributed storage method for transaction data.

[0051] As can be seen from the above technical solutions, the transaction data distributed storage method provided in this application can be applied to the Trusted Execution Environment (TEE) of each edge node. The trusted environment of each edge node is used to process the transaction data, blocking the risk of leakage from the perspective of data processing and eliminating the possibility of data fragments being tampered with or replaced. This distributed storage method for transaction data may include acquiring transaction data marked with metadata from corresponding edge nodes; determining sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes; based on this, the sharding specifications can be determined by comprehensively considering the transaction data dimension and the edge node resource dimension, balancing data security and data processing speed; subsequently, the application may encrypt the transaction data to obtain encrypted transaction information; according to the sharding specifications, the encrypted transaction information is sharded to obtain multiple shard subsets; based on the metadata, shard metadata for each shard subset is generated; based on this, the application shards after encryption, ensuring that each shard subset originates from the ciphertext block, and a single shard itself does not contain any information about the original transaction data; whereas if sharding is performed before encryption, the resulting encryption may contain some header information and the size of each encryption result is difficult to unify, providing attackers with clues for cracking. Therefore, by adopting the above-mentioned method of encryption followed by sharding, the possibility of transaction data leakage can be minimized, ensuring the security and privacy of distributed storage of transaction data. Then, this application can verify each shard subset and its shard metadata to confirm the integrity and consistency of each shard subset. Based on this, this application can ensure the trustworthiness and security of shard subsets through integrity and consistency verification. After successful verification, this application can sign each shard metadata to obtain the signature metadata of each shard subset. Based on this, the TEE of this application can generate a "trusted identity identifier" for the data through the signing operation of the shard metadata, and the signature metadata contains the TEE. With the endorsement of the hardware root trust key, blockchain nodes can directly confirm that the data originates from a trusted environment by verifying the signature, preventing forged data from accessing the network. Each shard subset, along with its corresponding shard metadata and signature metadata, is uploaded to the blockchain consensus layer. This allows blockchain nodes to perform integrity verification on each shard subset based on the signature metadata. After confirming that each shard subset passes the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored. Based on this, this application introduces a blockchain with immutable characteristics for reliable distributed storage of transaction data. Therefore, this application can achieve secure and reliable storage of transaction data by combining the local TEE of each edge node and the blockchain consensus nodes. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0053] Figure 1 This is a flowchart of a distributed storage method for transaction data disclosed in an embodiment of this application;

[0054] Figure 2 This is a block diagram of a distributed storage device for transaction data disclosed in an embodiment of this application;

[0055] Figure 3 This is a hardware structure block diagram of a distributed storage device for transaction data disclosed in an embodiment of this application. Detailed Implementation

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

[0057] This application provides a distributed storage method for transaction data. This distributed storage method can be applied to the Trusted Execution Environment (TEE) of each edge node in various transaction systems, and can also be applied to various computer terminals or smart terminals. The execution entity can be the processor or server of the computer terminal or smart terminal.

[0058] Each edge node has basic computing and communication capabilities, enabling it to perform preliminary screening and preprocessing of transaction data, and then send the pre-screened and preprocessed transaction data to the corresponding Trusted Execution Environment (TEE).

[0059] TEE is deployed inside edge nodes or in trusted hardware connected to edge nodes, providing a secure and isolated execution environment for the following distributed storage method of transaction data.

[0060] Next, combine Figure 1 The distributed storage method for transaction data described in this application is detailed below, including the following steps:

[0061] Step S1: Obtain transaction data marked with metadata in the corresponding edge node.

[0062] Specifically, it can receive transaction data collected by edge nodes that has undergone preprocessing operations such as format verification and redundancy removal, and each transaction data is marked with metadata such as timestamp, data identifier, and node identifier.

[0063] A data identifier is a unique identifier for a piece of transaction data. It corresponds to a complete unit of original transaction data, which may be a single transaction or a group of related transaction data after batch preprocessing.

[0064] All shards derived from this original transaction data unit are associated with this data identifier, which is used to trace the origin of the shard.

[0065] Step S2: Determine the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes.

[0066] Specifically, it can assess the importance of transaction data;

[0067] Determine the resource status of the corresponding edge node, including computing power, storage capacity, and network bandwidth.

[0068] Based on the importance of the comprehensive transaction data and the resource status of the corresponding edge nodes, determine the shard size, number of shards, and sharding method.

[0069] Step S3: Encrypt the transaction data to obtain encrypted transaction information.

[0070] Specifically, various encryption algorithms can be used to encrypt transaction data, resulting in encrypted transaction information.

[0071] The encryption algorithm can be the Chinese national cryptographic algorithm SM1, SM4 or SM9.

[0072] Step S4: Divide the encrypted transaction information into multiple fragment subsets according to the fragmentation specifications.

[0073] Specifically, the encrypted transaction information is fragmented based on the fragmentation specification, resulting in multiple fragment subsets.

[0074] It can generate Message Authentication Code (MAC) for each shard subset.

[0075] Step S5: Based on the metadata, generate shard metadata for each shard subset.

[0076] Specifically, unique fragment metadata can be generated for each fragment subset based on node identifiers and timestamps in the metadata.

[0077] Step S6: Verify each shard subset to check its integrity and consistency.

[0078] Specifically, a MAC value for each shard subset can be generated, and the MAC value of each shard subset generated at this time can be compared with the previously generated MAC value to perform integrity and consistency checks on each shard subset.

[0079] Step S7: After successful verification, sign the metadata of each shard to obtain the signature metadata of each shard subset.

[0080] Specifically, after each shard subset has passed integrity and consistency checks, a signature algorithm can be used to sign the metadata of each shard, and the signed metadata of each shard subset can be obtained.

[0081] Step S8: Upload each shard subset and its corresponding shard metadata and signature metadata to the blockchain consensus layer.

[0082] Specifically, the blockchain consensus layer can consist of multiple blockchain nodes, responsible for consensus verification and on-chain storage of the shard subsets generated by the TEE, along with their shard metadata and signature metadata. The consensus mechanism ensures the consistency and immutability of the shard subsets, their shard metadata, and signature metadata.

[0083] Each shard subset, along with its corresponding shard metadata and signature metadata, can be uploaded to the blockchain consensus layer. This allows blockchain nodes to verify the validity and integrity of the shard subset based on the signature metadata, confirming the trustworthiness of its origin. Then, a consensus algorithm, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm, is used to verify the shard subset. Once the consensus among all blockchain nodes is consistent, each shard subset and its related information are distributed and stored.

[0084] It can receive storage location indexes containing the storage addresses and storage paths of each shard subset issued by the blockchain consensus layer.

[0085] The storage address may contain the identifier, IP address, or physical address of the blockchain node storing the corresponding shard subset, which is used to accurately locate the physical storage location of the shard in the distributed storage system, ensuring that the shard subset can be quickly retrieved from the corresponding blockchain node during subsequent queries.

[0086] The storage path can be a file path or a database index.

[0087] As can be seen from the above technical solutions, the transaction data distributed storage method provided in this application can be applied to the Trusted Execution Environment (TEE) of each edge node. The trusted environment of each edge node is used to process the transaction data, blocking the risk of leakage from the perspective of data processing and eliminating the possibility of data fragments being tampered with or replaced. This distributed storage method for transaction data may include acquiring transaction data marked with metadata from corresponding edge nodes; determining sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes; based on this, the sharding specifications can be determined by comprehensively considering the transaction data dimension and the edge node resource dimension, balancing data security and data processing speed; subsequently, the application may encrypt the transaction data to obtain encrypted transaction information; according to the sharding specifications, the encrypted transaction information is sharded to obtain multiple shard subsets; based on the metadata, shard metadata for each shard subset is generated; based on this, the application shards after encryption, ensuring that each shard subset originates from the ciphertext block, and a single shard itself does not contain any information about the original transaction data; whereas if sharding is performed before encryption, the resulting encryption may contain some header information and the size of each encryption result is difficult to unify, providing attackers with clues for cracking. Therefore, by adopting the above-mentioned method of encryption followed by sharding, the possibility of transaction data leakage can be minimized, ensuring the security and privacy of distributed storage of transaction data. Then, this application can verify each shard subset and its shard metadata to confirm the integrity and consistency of each shard subset. Based on this, this application can ensure the trustworthiness and security of shard subsets through integrity and consistency verification. After successful verification, this application can sign each shard metadata to obtain the signature metadata of each shard subset. Based on this, the TEE of this application can generate a "trusted identity identifier" for the data through the signing operation of the shard metadata, and the signature metadata contains the TEE. With the endorsement of the hardware root trust key, blockchain nodes can directly confirm that the data originates from a trusted environment by verifying the signature, preventing forged data from accessing the network. Each shard subset, along with its corresponding shard metadata and signature metadata, is uploaded to the blockchain consensus layer. This allows blockchain nodes to perform integrity verification on each shard subset based on the signature metadata. After confirming that each shard subset passes the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored. Based on this, this application introduces a blockchain with immutable characteristics for reliable distributed storage of transaction data. Therefore, this application can achieve secure and reliable storage of transaction data by combining the local TEE of each edge node and the blockchain consensus nodes.

[0088] Furthermore, the sharded subsets and their metadata that have passed consensus verification are stored in the corresponding blockchain nodes of the data storage layer. At the same time, the storage location index of the sharded subsets is recorded on the blockchain to facilitate subsequent data querying and reorganization.

[0089] When transaction data is needed, edge nodes can receive data requests from users or applications. Based on the request, they query the storage location index of the required shard subset on the blockchain and retrieve the corresponding shard subset from the data storage layer. Then, each shard subset is sent to the corresponding TEE. The TEE verifies the shard metadata and signature metadata of the shard subset. After confirming that the data has not been tampered with and that its source is trustworthy, it decrypts and reassembles the data to obtain the complete transaction data, which is then returned to the requesting party.

[0090] In some embodiments of this application, the process of determining the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes is described in detail, and the steps are as follows:

[0091] S20. Determine the shard size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes.

[0092] Specifically, the sharding method can be horizontal sharding, vertical sharding, or hybrid sharding.

[0093] The types of transaction data can include financial transactions, transportation transactions, and industrial IoT transactions.

[0094] Among them, financial transaction data may include user transfer records, merchant payment details, and financial product purchase orders. This type of data usually contains key fields such as account information, transaction amount, and payment channel.

[0095] Transportation-related data may include highway toll payment data, charging station fee settlement records, and ride-hailing trip fare transaction data. This type of data typically includes key fields such as vehicle identification, transaction time, and fee amount.

[0096] Industrial Internet of Things (IIoT) data can include procurement transaction data for equipment and parts within a factory, material flow and settlement records across the supply chain, and detailed payment information for equipment maintenance services. This type of data typically includes key fields such as equipment serial number, identifiers of the transacting parties, and material specifications.

[0097] As can be seen from the above technical solution, this embodiment provides an optional method for determining sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes. Through this method, this application can comprehensively consider multiple dimensions such as the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending capabilities of the corresponding edge nodes, to determine the optimal sharding size, number of shards, and sharding method, thereby obtaining the sharding specifications and improving their flexibility and adaptability. This comprehensive method for determining sharding specifications not only optimizes the utilization of storage resources but also improves the speed and reliability of data access.

[0098] In some embodiments of this application, the process of determining the shard size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, is described in detail below:

[0099] S200. Analyze the sensitivity, real-time requirements, scope of impact, and compliance requirements of the transaction data, and assess the importance of the transaction data.

[0100] Specifically, the sensitivity of transaction data can be determined based on the amount of private information contained in the transaction data.

[0101] The amount of privacy information may include the number of accounts, the number of identity identifiers, and the amount of core parameters of industrial equipment.

[0102] The higher the amount of private information, the higher its sensitivity and importance.

[0103] The need for real-time transaction data can be determined based on the losses caused by transaction data delays.

[0104] Among them, transaction data that may result in losses due to delays include high-frequency financial transaction data and real-time vehicle toll transaction data.

[0105] The greater the loss, the greater the need for real-time performance, and the higher its importance.

[0106] The scope of impact of transaction data can be determined based on the number of collaborating nodes.

[0107] The more collaborative nodes there are, the larger the transaction scale, the wider the scope of influence, and the higher the importance.

[0108] Compliance requirements for transaction data can be determined based on the level of risk of non-compliance.

[0109] Among them, the higher the level of risk of violation, the greater the importance.

[0110] S201. Based on the type and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, determine the sharding size and sharding method.

[0111] Specifically, if the type of transaction data indicates that it is structured and the fields are highly independent, then the sharding method can be determined to be vertical sharding.

[0112] If the transaction data type is batch records, then the sharding method can be determined as horizontal sharding.

[0113] If the type of transaction data indicates that it has both structured fields and batch record characteristics, then the sharding method can be determined to be hybrid sharding.

[0114] The higher the importance, the smaller the shard size; however, the smaller the shard size, the higher the requirements for the computing power, storage performance, and network lending of the edge nodes.

[0115] Therefore, the shard size can be determined by comprehensively considering the importance of transaction data, the computing power, storage performance, and network lending of edge nodes.

[0116] S202. Determine the number of shards based on the size and sharding method of the transaction data.

[0117] Specifically, it can assess the overall size of the transaction data and the sharding method, and calculate the number of shards.

[0118] As can be seen from the above technical solution, this embodiment provides an optional method for determining the shard size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes. This method comprehensively considers multiple dimensions of information such as the sensitivity, real-time requirements, scope of impact, and compliance requirements of the transaction data to determine the sharding method and shard size. Based on this, the sharded data is then determined, thereby optimizing data processing performance and improving overall efficiency.

[0119] In some embodiments of this application, the process of step S5, generating shard metadata for each shard subset based on the metadata, is described in detail below:

[0120] S50. Generate the encryption algorithm identifier, fragment identifier, fragment index, and MAC value for each fragment subset.

[0121] Specifically, it can generate a unique shard identifier, shard index, and MAC value for each shard subset.

[0122] Identify the encryption algorithm identifier for each fragment subset for subsequent decryption.

[0123] Fragment identifiers are typically generated using hash algorithms such as SHA-256 combined with core fragment characteristics such as fragment content hash value, generation timestamp, and node identifier, or by directly using a universally unique identifier (UUID).

[0124] For example, the hash value of the shard content, signature timestamp, and node identifier of the corresponding shard subset can be integrated to generate a globally unique identifier for the corresponding shard subset, thus avoiding identifier conflicts between different shards.

[0125] The essence of a shard index is a sequence number, used to identify the position of the corresponding shard subset within all shards of the transaction data.

[0126] For example, if the transaction data is divided into 5 shards, the shard indices are 1, 2, 3, 4, and 5 respectively. Their function is to determine the splicing order of each shard subset during data reorganization, so as to ensure that the complete transaction data is restored.

[0127] S51. Based on the metadata, determine the data identifier and node identifier of the transaction data.

[0128] Specifically, the data identifier of the transaction data and the node identifier of the corresponding edge node can be selected from the metadata.

[0129] S52. The fragment identifier, fragment index, MAC value, encryption algorithm identifier, and data identifier of the same fragment subset constitute the fragment metadata of the corresponding fragment subset.

[0130] Specifically, the shard metadata for each shard subset includes the generation timestamp of the corresponding shard subset, shard identifier, shard index, MAC value, encryption algorithm identifier, and data identifier.

[0131] The generation timestamp is a precise time information mark added to the shard metadata after the MAC value is generated, typically accurate to milliseconds. It is used to record the moment when a shard subset is generated, primarily for shard lifecycle management and traceability.

[0132] As can be seen from the above technical solution, this embodiment provides an optional method for generating shard metadata for each shard subset based on the metadata. The above method can use multi-dimensional information as shard metadata, thereby improving the effectiveness of shard metadata.

[0133] In some embodiments of this application, the process of verifying the integrity of each fragment subset in step S6 is described in detail, and the steps are as follows:

[0134] S60. Generate the encrypted MAC value of the encrypted transaction information.

[0135] Specifically, the MAC of encrypted transaction information can be generated as an encrypted MAC value.

[0136] S61. The various fragment subsets are spliced ​​together to obtain the spliced ​​result.

[0137] Specifically, the fragment subsets can be concatenated according to their fragment indexes to obtain the concatenated result.

[0138] S62. Generate the splicing MAC value of the splicing result.

[0139] Specifically, the MAC value of the spliced ​​result can be generated as the spliced ​​MAC value.

[0140] S63. When the encrypted MAC value is consistent with the concatenated MAC value, it is determined that each fragment subset has integrity.

[0141] Specifically, it can be determined whether the encrypted MAC value is consistent with the concatenated MAC value.

[0142] If they are consistent, then it can be determined that each fragment subset has completeness.

[0143] S64. When the encrypted MAC value is inconsistent with the concatenated MAC value, it is determined that one or more fragment subsets are incomplete, and the process returns to step S4.

[0144] Specifically, if the encrypted MAC value is inconsistent with the concatenated MAC value, it can be determined that one or more fragment subsets are incomplete, and the process can return to step S4 to regenerate the fragment subsets.

[0145] As can be seen from the above technical solution, this embodiment provides an optional method for verifying the integrity of each fragment subset. The integrity verification can be performed by comparing information authentication codes, thus avoiding plaintext leakage while completing the integrity verification.

[0146] In some embodiments of this application, the process of verifying the consistency of each shard subset in step S6 is described in detail, and the steps are as follows:

[0147] S60. Determine whether each shard subset meets the sharding specification.

[0148] Specifically, it can be analyzed whether the size of each shard subset meets the shard size requirement.

[0149] Analyze whether the sharding of each shard subset meets the requirements of the sharding method.

[0150] Does the total number of all fragment subsets meet the requirement for the number of fragments?

[0151] S61. When the condition is met, determine that each shard subset passes the consistency check.

[0152] Specifically, when each shard subset meets the requirements of sharding method, shard size, and shard number, each shard subset is determined to pass the consistency check.

[0153] S62. If the condition is not met, determine that each shard subset has failed the consistency check and return to step S4.

[0154] Specifically, if any shard subset does not meet the requirements for sharding method and / or shard size, and / or the total number of all shard subsets does not meet the requirement for the number of shards, it can be determined that each shard subset has failed the consistency check, and the process can return to step S4 to regenerate the shard subset.

[0155] The generation timestamp of each shard subset can be used to assess whether the corresponding shard subset was generated within a reasonable time window. If it is, the corresponding shard subset can be determined to have passed the consistency check; otherwise, it will not pass the consistency check.

[0156] As can be seen from the above technical solution, this embodiment provides an optional method for verifying the consistency of each shard subset. The consistency verification can be completed by verifying the matching of each shard subset with the shard specification.

[0157] In some embodiments of this application, the process of signing each shard metadata after successful verification to obtain the signature metadata of each shard subset is described in detail, and the steps are as follows:

[0158] S70. Generate random numbers.

[0159] Specifically, random numbers can be generated based on timestamps.

[0160] S71. Based on the generation timestamp of each fragment metadata and the random number, sign each fragment metadata to obtain the signature metadata of each fragment subset.

[0161] Specifically, the generation timestamp of each shard metadata can be the generation timestamp recorded in the corresponding shard metadata or the timestamp corresponding to the formation of each shard metadata.

[0162] Using the generated timestamp and the random number as keys, each shard metadata is signed to obtain the signature metadata of each shard subset.

[0163] As can be seen from the above technical solution, this embodiment provides an optional method for generating signature metadata for each fragment subset. The above method can further utilize timestamps and random numbers to improve the reliability of the signature metadata of this application.

[0164] Next, we will combine Figure 2 The transaction data distributed storage device provided in this application will be described in detail. The transaction data distributed storage device described below can be compared with the transaction data distributed storage method described above.

[0165] See Figure 2 It can be observed that the distributed storage device for transaction data may include:

[0166] The acquisition module 10 is used to acquire transaction data marked with metadata in the corresponding edge node;

[0167] The determination module 20 is used to determine the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes;

[0168] Encryption module 30 is used to encrypt the transaction data to obtain encrypted transaction information;

[0169] Sharding module 40 is used to shard the encrypted transaction information according to the sharding specifications to obtain multiple shard subsets;

[0170] The generation module 50 is used to generate shard metadata for each shard subset based on the metadata.

[0171] The verification module 60 is used to verify each shard subset, and to verify the integrity and consistency of each shard subset;

[0172] The signature module 70 is used to sign each shard metadata after verification to obtain the signature metadata of each shard subset;

[0173] The storage module 80 is used to upload each shard subset and its corresponding shard metadata and signature metadata to the blockchain consensus layer, so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification of the blockchain nodes, the shard subset and its corresponding shard metadata are distributed and stored.

[0174] Furthermore, module 20 may include:

[0175] The sharding method determination unit is used to determine the sharding size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes.

[0176] Furthermore, the segmentation method determination unit may include:

[0177] The first segmentation method determines the sub-units, which are used to analyze the sensitivity, real-time requirements, scope of impact and compliance requirements of the transaction data, and to assess the importance of the transaction data.

[0178] The second sharding method determination subunit is used to determine the sharding size and sharding method based on the type and importance of the transaction data and the computing power, storage performance and network lending of the corresponding edge nodes;

[0179] The third sharding method determination subunit is used to determine the number of shards based on the size of the transaction data and the sharding method.

[0180] Furthermore, the generation module 50 may include:

[0181] The first generation unit is used to generate the encryption algorithm identifier, fragment identifier, fragment index and MAC value for each fragment subset;

[0182] The second generation unit is used to determine the data identifier and node identifier of the transaction data based on the metadata;

[0183] The third generation unit is used to generate the fragment metadata of the corresponding fragment subset, which consists of the encryption algorithm identifier, fragment identifier, fragment index, MAC value, data identifier and node identifier of the same fragment subset.

[0184] Furthermore, the verification module 60 may include:

[0185] An encrypted MAC value generation unit is used to generate the encrypted MAC value of the encrypted transaction information;

[0186] The fragment subset splicing unit is used to splice the various fragment subsets to obtain the splicing result;

[0187] A MAC value generation unit is used to generate the MAC value of the splicing result;

[0188] The integrity determination unit is used to determine that each shard subset has integrity when the encrypted MAC value is consistent with the concatenated MAC value; and to determine that one or more shard subsets do not have integrity when the encrypted MAC value is inconsistent with the concatenated MAC value, and to call the sharding module 40.

[0189] Furthermore, the verification module 60 may also include:

[0190] The sharding specification comparison unit is used to determine whether each shard subset meets the sharding specification.

[0191] The consistency determination unit is used to determine that each shard subset passes the consistency check when the condition is met; and to determine that each shard subset fails the consistency check when the condition is not met, and to call the sharding module 40.

[0192] Furthermore, the signature module 70 may include:

[0193] The first signature unit is used to generate random numbers;

[0194] The second signature unit is used to sign each piece of metadata based on the generation timestamp of each piece of metadata and the random number, so as to obtain the signature metadata of each piece of metadata subset.

[0195] The transaction data distributed storage device provided in this application embodiment can be applied to transaction data distributed storage devices, such as PC terminals, cloud platforms, servers, and server clusters. Optionally, Figure 3 The hardware structure block diagram of the distributed storage device for transaction data is shown below. Figure 3 The hardware structure of a distributed storage device for transaction data may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0196] In this embodiment, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4.

[0197] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0198] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0199] The memory stores a program, which the processor can call. The program is used for:

[0200] Retrieve transaction data marked with metadata from the corresponding edge nodes;

[0201] The sharding specifications are determined based on the importance of the transaction data and the resource status of the corresponding edge nodes.

[0202] The transaction data is encrypted to obtain encrypted transaction information;

[0203] The encrypted transaction information is fragmented according to the fragmentation specifications to obtain multiple fragment subsets;

[0204] Based on the aforementioned metadata, generate shard metadata for each shard subset;

[0205] Each shard subset is validated to verify its integrity and consistency.

[0206] After successful verification, each shard metadata is signed to obtain the signature metadata of each shard subset;

[0207] Each shard subset and its corresponding shard metadata and signature metadata are uploaded to the blockchain consensus layer so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored.

[0208] Optionally, the refined and extended functions of the program can be referred to the above description.

[0209] This application embodiment also provides a readable storage medium that can store a program suitable for execution by a processor, the program being used for:

[0210] Retrieve transaction data marked with metadata from the corresponding edge nodes;

[0211] The sharding specifications are determined based on the importance of the transaction data and the resource status of the corresponding edge nodes.

[0212] The transaction data is encrypted to obtain encrypted transaction information;

[0213] The encrypted transaction information is fragmented according to the fragmentation specifications to obtain multiple fragment subsets;

[0214] Based on the aforementioned metadata, generate shard metadata for each shard subset;

[0215] Each shard subset is validated to verify its integrity and consistency.

[0216] After successful verification, each shard metadata is signed to obtain the signature metadata of each shard subset;

[0217] Each shard subset and its corresponding shard metadata and signature metadata are uploaded to the blockchain consensus layer so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored.

[0218] Optionally, the refined and extended functions of the program can be referred to the above description.

[0219] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0220] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0221] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. The various embodiments of this application can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A distributed storage method for transaction data, characterized in that, The trusted execution environment (TEE) applied to each edge node, the distributed storage method for transaction data includes: Retrieve transaction data marked with metadata from the corresponding edge nodes; The sharding specifications are determined based on the importance of the transaction data and the resource status of the corresponding edge nodes. The transaction data is encrypted to obtain encrypted transaction information; The encrypted transaction information is fragmented according to the fragmentation specifications to obtain multiple fragment subsets; Based on the aforementioned metadata, generate shard metadata for each shard subset; Each shard subset is validated to verify its integrity and consistency. After successful verification, each shard metadata is signed to obtain the signature metadata of each shard subset; Each shard subset and its corresponding shard metadata and signature metadata are uploaded to the blockchain consensus layer so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification by the blockchain nodes, each shard subset and its corresponding shard metadata are distributed and stored.

2. The distributed storage method for transaction data according to claim 1, characterized in that, The step of determining the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes includes: Based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, the shard size, number of shards, and sharding method are determined.

3. The distributed storage method for transaction data according to claim 2, characterized in that, The process of determining the shard size, number of shards, and sharding method based on the type, size, and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, includes: Analyze the sensitivity, real-time requirements, scope of impact, and compliance requirements of the transaction data to assess its importance. Based on the type and importance of the transaction data, as well as the computing power, storage performance, and network lending of the corresponding edge nodes, the shard size and sharding method are determined. The number of shards is determined based on the size and sharding method of the transaction data.

4. The distributed storage method for transaction data according to claim 1, characterized in that, The step of generating shard metadata for each shard subset based on the metadata includes: Generate the encryption algorithm identifier, fragment identifier, fragment index, and MAC value for each fragment subset; Based on the metadata, the data identifier and node identifier of the transaction data are determined; The encryption algorithm identifier, fragment identifier, fragment index, MAC value, data identifier, and node identifier of the same fragment subset constitute the fragment metadata of the corresponding fragment subset.

5. The distributed storage method for transaction data according to claim 1, characterized in that, Each shard subset and its shard metadata are validated to verify the integrity of each shard subset, including: Generate the encrypted MAC value of the encrypted transaction information; The individual fragment subsets are spliced ​​together to obtain the spliced ​​result; Generate the splicing MAC value of the splicing result; When the encrypted MAC value matches the concatenated MAC value, it is determined that each fragment subset has integrity. When the encrypted MAC value is inconsistent with the concatenated MAC value, it is determined that one or more fragment subsets are incomplete, and the process returns to the step of fragmenting the encrypted transaction information according to the fragmentation specification to obtain multiple fragment subsets.

6. The distributed storage method for transaction data according to claim 1, characterized in that, Each shard subset is validated to verify its consistency, including: Determine whether each shard subset meets the sharding specifications; When the condition is met, each shard subset is determined to have passed the consistency check; If the conditions are not met, it is determined that each shard subset has failed the consistency check, and the process returns to the step of determining the sharding specification based on the importance of the transaction data and the resource status of the corresponding edge node.

7. The distributed storage method for transaction data according to claim 1, characterized in that, The process of signing each shard metadata to obtain the signature metadata of each shard subset includes: Generate random numbers; Based on the generation timestamp of each shard metadata and the random number, each shard metadata is signed to obtain the signature metadata of each shard subset.

8. A distributed storage device for transaction data, characterized in that, The Trusted Execution Environment (TEE) applied to each edge node, the distributed storage device for transaction data includes: The acquisition module is used to acquire transaction data marked with metadata in the corresponding edge nodes; The determination module is used to determine the sharding specifications based on the importance of the transaction data and the resource status of the corresponding edge nodes; An encryption module is used to encrypt the transaction data to obtain encrypted transaction information; The sharding module is used to shard the encrypted transaction information according to the sharding specifications to obtain multiple shard subsets; A generation module is used to generate shard metadata for each shard subset based on the metadata. The verification module is used to verify each shard subset, ensuring the integrity and consistency of each shard subset. The signature module is used to sign the metadata of each shard after successful verification, so as to obtain the signature metadata of each shard subset; The storage module is used to upload each shard subset and its corresponding shard metadata and signature metadata to the blockchain consensus layer, so that the blockchain nodes can perform integrity verification on each shard subset based on each signature metadata. After determining that each shard subset has passed the integrity verification of the blockchain nodes, the shard subset and its corresponding shard metadata are distributed and stored.

9. A distributed storage device for transaction data, characterized in that, Including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the distributed storage method for transaction data as described in any one of claims 1-7.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the various steps of the distributed storage method for transaction data as described in any one of claims 1-7.

Images