Data synchronization updating method and device, storage medium and electronic equipment

Abstract

The invention discloses a data synchronization updating method and device, a storage medium and electronic equipment, and relates to the technical field of data processing, and the method comprises the steps: responding to a data synchronization request of target subscription data, and verifying the data synchronization request through a request node corresponding to the data synchronization request in a plurality of containerized nodes of a block chain network; determining a plurality of consensus nodes based on the configuration information of the plurality of containerized nodes under the condition that the verification of the data synchronization request is passed, and performing consensus verification on the target ordering data through the plurality of consensus nodes; under the condition that the consensus verification is passed, storing the target ordering data in a target storage network; and generating data index information corresponding to the target ordering data in the target storage network, wherein the data index information is used for updating the target ordering data by at least one to-be-updated node. The consensus verification is performed on the target subscription data through the plurality of consensus nodes, so that the security of data synchronization and the accuracy of data synchronization updating can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data synchronization and update method, apparatus, storage medium and electronic device. Background Technology

[0002] Synchronous updating of order relationship data is a key link in multi-system collaboration (such as e-commerce, education platforms, SaaS services, etc.). Its core objective is to ensure that user order behavior generated through any channel (such as Web, App, Mini Program, Third-party platform) can be reflected in all relevant systems in real time and consistently.

[0003] Currently, data synchronization and updates rely on distributed data collaboration between different nodes on a centralized architecture platform. However, this approach relies solely on a single encryption method, mechanical data encryption, during the data synchronization process. This makes the data vulnerable to attacks or data tampering, thus compromising data security within the centralized architecture platform. Summary of the Invention

[0004] In view of this, this application provides a data synchronization and update method, apparatus, storage medium and electronic device. The main purpose is to improve the technical problem that the existing technology relies on only a single encryption method, mechanical data encryption, during the data synchronization process, which makes the data vulnerable to attack or data tampering, thus affecting the data security of centralized architecture platforms.

[0005] Firstly, this application provides a data synchronization and update method, including: In response to a data synchronization request for target order data, the data synchronization request is verified by the requesting node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network; If the data synchronization request is verified, multiple consensus nodes are determined based on the configuration information of the multiple containerized nodes, and consensus verification of the target order data is performed through the multiple consensus nodes. If consensus verification is successful, the target order data will be stored in the target storage network; Generate data index information corresponding to the target order data in the target storage network. The data index information is used by at least one node to be updated to update the target order data.

[0006] Optionally, if the data synchronization request verification passes, determining multiple consensus nodes based on the configuration information of the multiple containerized nodes, and performing consensus verification on the target ordering data through the multiple consensus nodes, includes: If the data synchronization request is verified, a consensus request node is determined from the multiple containerized nodes based on the configuration information of the multiple containerized nodes. Identify at least one consensus verification node corresponding to the requested consensus node; The requesting consensus node requests at least one consensus verification node to perform consensus verification on the target order data.

[0007] Optionally, if the data synchronization request verification passes, a consensus request node is determined from the plurality of containerized nodes based on the configuration information of the plurality of containerized nodes, including: If the data synchronization request is verified, the staking weight data and / or historical reputation score data of the multiple containerized nodes in the current consensus period are determined; Based on the staking weight data and / or the historical reputation score data, the request consensus node is selected from the plurality of containerized nodes using a proof-of-stake mechanism.

[0008] Optionally, determining at least one consensus verification node corresponding to the requesting consensus node includes: Determine the node load data and node network topology information corresponding to the multiple containerized nodes; Based on the node load data and the node network topology information, at least one consensus verification node corresponding to the request consensus node is selected from the plurality of containerized nodes.

[0009] Optionally, requesting the at least one consensus verification node to perform consensus verification on the target order data through the requesting consensus node includes: The consensus verification information corresponding to the data synchronization request is generated by the request consensus node; The consensus verification information is broadcast to the at least one consensus verification node, which is used to vote based on the consensus verification information to perform consensus verification on the target order data.

[0010] Optionally, before storing the target order data in the target storage network after consensus verification is passed, the method further includes: Determine the voting data of the at least one consensus verification node voting based on the consensus verification information; Based on the voting data, determine the pass rate of the target order data verification.

[0011] The step of storing the target order data in the target storage network after consensus verification is passed includes: If the pass rate data is greater than the pass rate threshold, the target order data will be stored in the target storage network.

[0012] Optionally, storing the target order data in the target storage network after consensus verification is successful includes: If consensus verification is successful, the target order data will be divided into multiple data fragments; The multiple data shards are distributed and stored across multiple nodes in the target storage network, wherein the target storage network is a decentralized storage network.

[0013] Optionally, generating the data index information corresponding to the target order data in the target storage network includes: Generate the shard hash data corresponding to each data shard in the plurality of data shards; The shard hash data corresponding to each data shard is aggregated to obtain the content addressing hash value corresponding to the target order data, and the content addressing hash value is recorded in the latest block of the blockchain network.

[0014] Optionally, after generating the data index information corresponding to the target order data in the target storage network, the method further includes: In response to the at least one node to be updated detecting the latest block in the blockchain network, the target order data is obtained from the target storage network according to the content addressing hash value; The target order data is verified by a smart contract in at least one node to be updated, and if the verification is successful, the target order data is updated in the local business database corresponding to the at least one node to be updated.

[0015] Optionally, before the requesting node corresponding to the data synchronization request among the multiple containerized nodes in the blockchain network verifies the data synchronization request, the method further includes: In response to the fact that there are multiple candidate data synchronization requests corresponding to the target order data, a version consistency check is performed on the multiple candidate data synchronization requests; If the version consistency check fails, the smart contract makes a decision on the multiple candidate data synchronization requests according to the target decision conditions to obtain the data synchronization request. The target decision conditions include a first decision condition determined based on timestamps and / or a second decision condition determined based on business priorities.

[0016] Optionally, the method further includes: Obtain resource utilization metrics for multiple containerized nodes in the blockchain network; The capacity of the multiple containerized nodes is expanded or reduced based on the resource utilization rate index.

[0017] Secondly, this application provides a data synchronization and update apparatus, comprising: The verification module is configured to verify the data synchronization request in response to a data synchronization request for target order data through the request node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network. The determination module is configured to, upon successful verification of the data synchronization request, determine multiple consensus nodes based on the configuration information of the multiple containerized nodes, and perform consensus verification on the target ordering data through the multiple consensus nodes. The storage module is configured to store the target order data in the target storage network upon successful consensus verification. The generation module is configured to generate data index information corresponding to the target order data in the target storage network, and the data index information is used by at least one node to be updated to update the target order data.

[0018] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the data synchronization update method described in the first aspect.

[0019] Fourthly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the data synchronization update method described in the first aspect.

[0020] By employing the above technical solutions, this application provides a data synchronization and update method, apparatus, storage medium, and electronic device. This application enhances the initial verification security of the data synchronization request by verifying the data synchronization request through request nodes corresponding to the data synchronization request among multiple containerized nodes in a blockchain network; by determining multiple consensus nodes based on the configuration information of the multiple containerized nodes when the data synchronization request verification is successful, and having these multiple consensus nodes perform consensus verification of the target order data, the risk of the target order data being tampered with is reduced; by storing the target order data in a target storage network when the consensus verification is successful, secure storage of the target order data is achieved; and by generating data index information corresponding to the target order data in the target storage network, accurate updates of the target order data by at least one node to be updated are achieved, ensuring the consistency of order relationship data among multiple nodes. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0022] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a data synchronization and update method provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating a data synchronization and update method provided in an embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of an example of a containerized blockchain-based intelligent data collaboration platform provided in an embodiment of this application; Figure 4 The illustration shows a flowchart of an example of developing a blockchain for synchronizing order relationships, as provided in an embodiment of this application. Figure 5 This illustration shows a schematic diagram of a data synchronization and update device provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0024] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0025] To address the technical problem that current technologies rely solely on mechanical encryption during data synchronization, making them vulnerable to attacks and data tampering, thus compromising data security in centralized architecture platforms, this embodiment provides a data synchronization and update method, such as... Figure 1 As shown, the method includes: Step 101: In response to the data synchronization request of the target ordered data, the data synchronization request is verified by the requesting node corresponding to the data synchronization request in multiple containerized nodes of the blockchain network.

[0026] In this embodiment of the application, the target order data can be order-related data generated by the user in the business system. For example, the target order data in this embodiment of the application can include order information for monthly subscription services, one-time subscription services, dynamic monthly services, etc. The order information can specifically include information such as transaction serial number, initiating party duns, destination duns, service code, billing number, operation code, and service effective time.

[0027] In this embodiment of the application, a data synchronization request may be a request initiated by the data initiator to the blockchain network based on the update requirements of the target ordered data. For example, the data synchronization request in this embodiment of the application may specifically include data content, target node list, and encryption strategy, etc.

[0028] In this embodiment of the application, the blockchain network can be a decentralized collaborative network built on a container-hosted shared ledger.

[0029] In the embodiments of this application, a containerized node can be a node formed by encapsulating a blockchain node in the form of a lightweight container (such as Docker). For example, the containerized node in the embodiments of this application may specifically include a consensus algorithm module, a data storage module, and a communication interface. The containerized node can be dynamically scheduled using orchestration tools such as Kubernetes.

[0030] In the embodiments of this application, the requesting node can be a node among multiple containerized nodes in the blockchain network that receives and processes data synchronization requests.

[0031] In this embodiment of the application, when the data initiator generates an update to the target order data, it can generate a corresponding data synchronization request. The data initiator sends the data synchronization request to the blockchain network. In response to the data synchronization request of the target order data, the request node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network can receive the data synchronization request and verify the legality of the request, the permissions of the data initiator, etc. The verification process of the data synchronization request can be based on preset permission rules and encryption verification mechanisms (such as using ECC algorithm for signature verification).

[0032] Step 102: If the data synchronization request is verified, determine multiple consensus nodes based on the configuration information of multiple containerized nodes, and verify the target order data through multiple consensus nodes.

[0033] In the embodiments of this application, the configuration information may be the relevant attribute information of the containerized node. For example, the configuration information in the embodiments of this application specifically includes information such as the node's staking weight data, historical reputation score data, node load data, and node network topology information.

[0034] In the embodiments of this application, the consensus node can be a containerized node participating in the consensus verification of the target order data. For example, the consensus node in the embodiments of this application may include a request consensus node and at least one consensus verification node.

[0035] In the embodiments of this application, consensus verification can be a process in which multiple consensus nodes verify and confirm the target ordering data according to preset consensus rules.

[0036] In this embodiment, if the data synchronization request is verified, multiple consensus nodes that meet the conditions can be selected from multiple containerized nodes based on the configuration information of multiple containerized nodes in the blockchain network. The multiple consensus nodes can collaboratively verify the integrity, accuracy, and legality of the target order data according to the consensus mechanism (such as a hybrid mechanism of Proof-of-Stake (PoS) pre-selection and distributed system consensus algorithm (PBFT) confirmation) to ensure that the target order data has consistency in the blockchain network and avoid data tampering or synchronization of erroneous data. The hybrid mechanism of PoS pre-selection and PBFT confirmation may include: introducing a green staking factor in the PoS pre-selection stage to give priority to nodes powered by clean energy; and using batch transaction packaging and parallel verification in the PBFT confirmation stage to improve throughput.

[0037] Step 103: If consensus verification is successful, store the target order data in the target storage network.

[0038] In this embodiment, the target storage network can be a decentralized distributed storage network. For example, the target storage network in this embodiment can specifically be IPFS (InterPlanetary File System). IPFS has high reliability and high scalability, and can support distributed storage and fast retrieval of data.

[0039] In this embodiment, when multiple consensus nodes pass the consensus verification of the target order data, the blockchain network can trigger a storage process to store the target order data in the target storage network. Storing the target order data in the target storage network can adopt a hot and cold data separation strategy. Specifically, the hot and cold data separation strategy can include caching the frequently accessed target order data in memory and archiving the infrequently accessed target order data to distributed storage nodes. At the same time, the data can be encrypted with a symmetric block cipher algorithm (such as the national cryptographic SM4 algorithm) before being written to disk, and the key can be managed by a hardware security module (HSM).

[0040] Step 104: Generate data index information corresponding to the target order data in the target storage network.

[0041] The data index information is used by at least one node to update the target order data.

[0042] In this embodiment, the data index information may be information related to the storage location and data identifier of the target order data in the target storage network. For example, the data index information in this embodiment may specifically be a content addressing hash value, which allows for quick location and retrieval of the target order data.

[0043] In this embodiment of the application, the node to be updated can be a containerized node in the blockchain network that needs to synchronize target order data. For example, the node to be updated in this embodiment of the application can specifically be a block node corresponding to the Business & Operation Support System, a node corresponding to other business platforms, etc.

[0044] In the embodiments of this application, after the target order data is stored in the target storage network, data index information corresponding to the target order data can be generated. The data index information can correspond to the target order data and can identify the storage location of the target order data in the target storage network. At least one node in the blockchain network that needs to be updated can query and obtain the corresponding target order data from the target storage network through the data index information, thereby completing the update of its own data.

[0045] Compared with existing technologies, the embodiments of this application verify the data synchronization request by using the request node corresponding to the data synchronization request in multiple containerized nodes of the blockchain network, thereby improving the initial verification security of the data synchronization request; by determining multiple consensus nodes based on the configuration information of multiple containerized nodes when the data synchronization request verification is successful, and having multiple consensus nodes perform consensus verification on the target order data, the risk of the target order data being tampered with is reduced; by storing the target order data in the target storage network when the consensus verification is successful, the secure storage of the target order data is achieved; and by generating data index information corresponding to the target order data in the target storage network, the accurate updating of the target order data by at least one node to be updated is achieved, ensuring the consistency of order relationship data among multiple nodes.

[0046] Optionally, when executing the step of "determining multiple consensus nodes based on the configuration information of multiple containerized nodes after the data synchronization request has been verified, and verifying the target order data through multiple consensus nodes", the following methods can be used, but are not limited to these: Figure 2 As shown, it includes: Step 201: If the data synchronization request is verified, determine the consensus node from multiple containerized nodes based on the configuration information of multiple containerized nodes.

[0047] In the embodiments of this application, the requesting consensus node can be a node selected from multiple containerized nodes that initiates the consensus verification request and leads the consensus verification process.

[0048] In the embodiments of this application, if the data synchronization request is verified, a consensus request node can be selected from multiple containerized nodes using PoS based on the configuration information of multiple containerized nodes. In the PoS mechanism, a green staking factor can be introduced to prioritize nodes powered by clean energy as consensus request nodes.

[0049] Step 202: Determine at least one consensus verification node corresponding to the requesting consensus node.

[0050] In this embodiment of the application, the consensus verification node may be a containerized node that assists the requesting consensus node in performing consensus verification on the target order data.

[0051] In this embodiment, determining at least one consensus verification node corresponding to the requesting consensus node can first involve collecting node load data (such as CPU utilization, memory utilization, network bandwidth utilization, etc.) and node network topology information (such as the geographical distribution of nodes, communication latency between nodes, network connection stability, etc.) corresponding to at least one containerized node. Based on the node load data and node network topology information, a node with low load, stable network connection, and low communication latency with the requesting consensus node can be selected from multiple containerized nodes as at least one consensus verification node corresponding to the requesting consensus node.

[0052] As an optional approach in this embodiment, the network adaptation scenarios can be expanded by tailoring the blockchain client functions (such as retaining only the verification module) to adapt to consensus verification nodes with limited resources.

[0053] Step 203: Request at least one consensus verification node to perform consensus verification on the target order data by requesting a consensus node.

[0054] In the embodiments of this application, requesting at least one consensus verification node to perform consensus verification on the target order data by requesting a consensus node can involve the requesting consensus node generating corresponding consensus verification information based on the data synchronization request and the target order data. The consensus verification information may include a summary of the target order data, information on the data initiator, and the signature of the requesting consensus node. The signature generation may employ encryption algorithms such as ECC. The requesting consensus node can broadcast the consensus verification information to at least one selected consensus verification node through the P2P communication mechanism of the blockchain network. After receiving the consensus verification information, the consensus verification node can verify the relevant information of the target order data according to its own verification rules and provide feedback on the verification results through voting, thereby achieving consensus verification of the target order data.

[0055] As an optional approach in this embodiment, batch transaction packaging and parallel verification can be used in the PBFT stage to improve the throughput of consensus verification; the overall encryption of the system can also adopt zero-knowledge proof (ZKP) off-chain computation, offloading the ZKP generation and verification process to dedicated hardware (such as FPGA), which can reduce the load on the main chain.

[0056] Optionally, when performing the action of "determining the request consensus node from multiple containerized nodes based on the configuration information of multiple containerized nodes after the data synchronization request has been verified," the following method may be used, but is not limited to: determining the staking weight data and / or historical reputation score data of multiple containerized nodes in the current consensus period after the data synchronization request has been verified; and selecting the request consensus node from multiple containerized nodes using a proof-of-stake mechanism based on the staking weight data and / or historical reputation score data.

[0057] In this embodiment of the application, the staking weight data can be the weight data corresponding to the assets or resources pledged by the node when participating in the consensus of the blockchain network.

[0058] In this embodiment of the application, the historical reputation score data can be score data formed based on the node's past performance in participating in consensus verification (such as verification accuracy, response speed, whether there is malicious behavior, etc.).

[0059] In the embodiments of this application, when the data synchronization request verification is successful, determining the staking weight data and / or historical reputation score data of multiple containerized nodes in the current consensus period can be achieved by first statistically analyzing the staking weight data of multiple containerized nodes in the current consensus period. The calculation of the staking weight data can be determined based on factors such as the type and quantity of resources staked by the nodes. Different resource types can correspond to different weight coefficients. After summarizing, the staking weight data of each node is obtained. The historical consensus verification records of each containerized node are retrieved, and the verification accuracy, response timeliness, and whether there are any violations of the containerized nodes in the past consensus periods are statistically analyzed. The historical reputation score data of each containerized node is calculated according to the scoring rules.

[0060] In the embodiments of this application, the request consensus node is selected from multiple containerized nodes using the proof-of-stake mechanism based on staking weight data and / or historical reputation score data. This can be done solely based on staking weight data, solely based on historical reputation score data, or by combining both (e.g., by setting weight coefficients for weighted calculation). The node with the best overall performance is selected from multiple containerized nodes using PoS to ensure that the request consensus node has high reliability and credibility.

[0061] As an optional approach in this embodiment, in order to adapt to quantum security requirements, a quantum-resistant upgrade interface can be reserved for the encryption algorithm involved in the process of selecting a consensus request node from multiple containerized nodes, and the encryption algorithm can be replaced with a quantum-resistant encryption algorithm (such as lattice-based NTRU algorithm).

[0062] Optionally, when performing the "determining at least one consensus verification node corresponding to the requesting consensus node", the following method may be used, but is not limited to: determining the node load data and node network topology information corresponding to multiple containerized nodes; and selecting at least one consensus verification node corresponding to the requesting consensus node from multiple containerized nodes based on the node load data and node network topology information.

[0063] In this embodiment, node load data can be collected in real time through a monitoring dashboard of the blockchain network. For example, the node load data in this embodiment may specifically include CPU utilization, memory utilization, disk I / O rate, network bandwidth usage, etc.

[0064] In this embodiment of the application, the node network topology information can be obtained through network detection tools. For example, the node network topology information in this embodiment of the application specifically includes the physical location of the nodes, network link quality, and connection relationships between nodes.

[0065] In this embodiment, node load data and node network topology information corresponding to multiple containerized nodes are determined. Based on the node load data and node network topology information, at least one consensus verification node corresponding to the requesting consensus node is selected from multiple containerized nodes. Nodes with node load data below the load threshold can be screened as candidate verification nodes. Then, the adaptation score of the candidate verification node can be calculated based on the node load data and node network topology information. The adaptation score can comprehensively consider factors such as load redundancy, communication latency with the requesting consensus node, and network stability. Nodes with higher adaptation scores can be selected from multiple containerized nodes as at least one consensus verification node corresponding to the requesting consensus node.

[0066] As an optional approach in this embodiment, in resource-constrained scenarios, lightweight edge nodes (such as ARM architecture devices) can be selected as consensus verification nodes.

[0067] Optionally, when executing "requesting at least one consensus verification node to perform consensus verification on the target order data by requesting a consensus node", the following method may be used, but is not limited to: generating consensus verification information corresponding to the data synchronization request by requesting a consensus node; broadcasting the consensus verification information to at least one consensus verification node, wherein at least one consensus verification node is used to vote based on the consensus verification information to perform consensus verification on the target order data.

[0068] For the embodiments of this application, the consensus verification information may include the hash digest of the target order data (the hash algorithm may include, but is not limited to, SHA-256, SHA-512), key parameters of the data synchronization request (such as the initiator identifier, request timestamp, business type, etc.), and the digital signature of the request consensus node (generated using an asymmetric encryption algorithm (such as ECC algorithm)).

[0069] In this embodiment of the application, broadcasting consensus verification information to at least one consensus verification node can be achieved through a peer-to-peer (P2P) communication protocol of the blockchain network. After receiving the consensus verification information, at least one consensus verification node can first verify the legality of the digital signature of the requesting consensus node, then compare the hash digest of the target order data with the local calculation result, and simultaneously verify the rationality of the data synchronization request parameters. Afterwards, it can vote based on the verification results (the voting result is either "agree" or "disagree") to verify the consensus of the target order data. It should be noted that zero-knowledge proof technology can be used during the voting process to ensure the privacy of node voting.

[0070] Optionally, before executing "Storing the target order data in the target storage network if consensus verification passes," the following method may be used, but is not limited to: determining voting data from at least one consensus verification node voting based on consensus verification information; and determining the pass rate data for the target order data verification based on the voting data. Storing the target order data in the target storage network if consensus verification passes includes: storing the target order data in the target storage network if the pass rate data is greater than a pass rate threshold.

[0071] In this embodiment, voting data can be collected through feedback messages from consensus verification nodes. For example, the voting data in this embodiment may specifically include the voting results, voting time, and node identifiers of each node.

[0072] In this embodiment of the application, the pass rate data for determining the target order data verification based on the voting data can be calculated by dividing the number of nodes that have passed the consensus verification by the total number of consensus verification nodes participating in the vote.

[0073] In this embodiment of the application, storing the target order data in the target storage network when the consensus verification is successful may include: if the pass rate data is greater than the pass rate threshold, it can be determined that the consensus verification of the target order data is successful, triggering the storage process to store the target order data in the target storage network; if the pass rate data is less than or equal to the pass rate threshold, it can be determined that the consensus verification is unsuccessful, and the verification failure information is fed back to the data initiator, who then verifies the data and re-initiates the request.

[0074] Optionally, when performing the action of "storing the target order data in the target storage network after consensus verification is passed", the following method may be used, but is not limited to: dividing the target order data into multiple data shards after consensus verification is passed; and distributing the multiple data shards in multiple nodes of the target storage network, wherein the target storage network is a decentralized storage network.

[0075] In this embodiment of the application, after consensus verification is passed, the target order data can be divided into multiple data fragments according to the fragmentation rules. The fragmentation rules can be set based on factors such as data size (e.g., each fragment is 100KB-1MB in size) and data type (e.g., fragmentation is classified according to business fields). The distributed storage of multiple data fragments on multiple nodes of the target storage network can be achieved through the fragmentation storage protocol of the target storage network, and each data fragment will be stored on multiple nodes. During the distributed storage process, each data fragment can be encrypted using a symmetric block cipher algorithm (e.g., the national cryptographic SM4 algorithm), and the key can be managed by the hardware security module (HSM).

[0076] Optionally, before executing "generating data index information corresponding to the target order data in the target storage network", the following method may be used, but not limited to: generating shard hash data corresponding to each data shard in multiple data shards; aggregating the shard hash data corresponding to each data shard to obtain the content addressing hash value corresponding to the target order data, and recording the content addressing hash value in the latest block in the blockchain network.

[0077] In the embodiments of this application, the shard hash data corresponding to each data shard in generating multiple data shards can be calculated using a hash algorithm (including but not limited to SHA-256, SHA-512, Keccak), and each data shard can correspond to a unique shard hash data. The shard hash data corresponding to each data shard is aggregated, and the aggregation process can adopt a structure such as a Merkle Tree, with all shard hash data as leaf nodes, and the root hash value is obtained through layer-by-layer hash calculation. The root hash value is the content addressing hash value corresponding to the target ordered data. Recording the content addressing hash value in the latest block in the blockchain network can be achieved by the block-producing nodes of the blockchain network generating the latest block according to the block-producing interval, and writing the content addressing hash value into a specific field in the latest block.

[0078] Optionally, after executing "generating data index information corresponding to the target order data in the target storage network", the following method may be used, but not limited to: in response to at least one node to be updated detecting the latest block in the blockchain network, obtaining the target order data from the target storage network according to the content addressing hash value; verifying the target order data through a smart contract in at least one node to be updated, and updating the target order data in the local business database corresponding to at least one node to be updated if the verification is successful.

[0079] In the embodiments of this application, at least one node to be updated can monitor the block generation status in the blockchain network in real time through the block listening mechanism of the blockchain network. In response to the detection of the latest block in the blockchain network, it can obtain multiple corresponding data fragments from the target storage network according to the content addressing hash value using the retrieval protocol of the target storage network (such as the Bitswap protocol of IPFS). During the process of obtaining multiple data fragments, the integrity of the data fragments can be verified through the fragment hash data.

[0080] In the embodiments of this application, the smart contract can be a data synchronization verification template in a modular contract template.

[0081] For the embodiments of this application, the verification content may include data integrity (comparison of aggregate fragment hash and content addressing hash value) and legality (data format and permission compatibility verification), etc.

[0082] In this embodiment, the target order data is verified by a smart contract in at least one node to be updated. If the verification is successful, the target order data can be updated in the local business database corresponding to at least one node to be updated to complete the data synchronization. At the same time, the node to be updated can use the remove(uint64_ttime, uint64_t size) function (where time can represent the time threshold for deleting data and size can represent the number of data entries to be deleted) to delete the downloaded and updated data in the local memory at a preset time point to release memory resources.

[0083] Optionally, before executing "verifying the data synchronization request by the request node corresponding to the data synchronization request in multiple containerized nodes of the blockchain network", the following method may be used, but is not limited to: in response to the fact that there are multiple candidate data synchronization requests corresponding to the target ordered data, performing version consistency verification on the multiple candidate data synchronization requests; if the version consistency verification fails, making a decision on the multiple candidate data synchronization requests through a smart contract according to the target decision conditions to obtain the data synchronization request, wherein the target decision conditions include a first decision condition determined based on a timestamp and / or a second decision condition determined based on business priority.

[0084] In this embodiment of the application, the first decision condition may be to select the candidate data synchronization request with the latest operation timestamp.

[0085] In this embodiment of the application, the second decision condition may be to set priorities according to the importance of the business and select the candidate data synchronization request with the highest priority of the corresponding business.

[0086] In this embodiment, in response to multiple candidate data synchronization requests corresponding to the target order data (the multiple candidate data may come from different business systems, different operation times, or different operators), a version consistency check is performed on the multiple candidate data synchronization requests. The version consistency check may include information such as the target order data version number, data content, operation timestamp, and initiator permissions corresponding to each candidate data synchronization request, to determine whether there are version conflicts among the multiple candidate data synchronization requests (such as inconsistent data content, conflicting operation times, etc.). If the version consistency check fails, a smart contract can make a decision on the multiple candidate data synchronization requests according to the target decision conditions to obtain the data synchronization request, wherein the smart contract can be a conflict resolution template in a modular contract template.

[0087] Optionally, embodiments of this application may also employ the following methods, but not limited thereto: the method includes: obtaining resource utilization indicators of multiple containerized nodes in the blockchain network; and scaling up or down the capacity of the multiple containerized nodes based on the resource utilization indicators.

[0088] In this embodiment of the application, the resource utilization rate of multiple containerized nodes of the blockchain network can be obtained in real time through the monitoring dashboard of the blockchain network.

[0089] For embodiments of this application, resource utilization metrics may include CPU utilization, memory utilization, disk storage utilization, network bandwidth utilization, etc.

[0090] In this embodiment, scaling up or down the capacity of multiple containerized nodes based on resource utilization metrics can be achieved by first setting resource utilization thresholds (e.g., CPU utilization threshold of 70% and memory utilization threshold of 80%). If the resource utilization metrics are higher than the resource utilization thresholds, it can be determined that the containerized nodes are overloaded, and the number of containerized nodes can be automatically increased (scaling up) using Kubernetes orchestration tools. The new nodes can be packaged in the form of lightweight containers. If the resource utilization metrics are lower than the resource utilization thresholds, it can be determined that the containerized nodes have redundant resources, and idle resources can be released by automatically reducing the number of containerized nodes (scaling down).

[0091] As an optional approach in this embodiment, if an anomaly occurs during the scaling up or scaling down of a containerized node, the containerized node can be automatically restarted or migrated to a healthy host.

[0092] As an optional approach in this embodiment, resource isolation can be achieved by limiting container resource quotas (CPU or memory) to avoid resource contention between nodes.

[0093] As an optional approach in this embodiment, predictive scaling can be achieved by integrating machine learning models to dynamically analyze business load patterns based on historical load data and predict resource requirements, thereby further improving resource utilization efficiency.

[0094] As an alternative approach, this application also provides an example of a containerized blockchain-based intelligent data collaboration platform. The structure of the containerized blockchain-based intelligent data collaboration platform can be as follows: Figure 3 As shown, Figure 3 The containerized blockchain-based intelligent data collaboration platform adopts a layered architecture design, which can include a containerized node layer, a blockchain core layer, a security collaboration layer, and an application interface layer. The containerized node layer can be the infrastructure, which can encapsulate nodes and dynamically schedule them (elastic scaling, fault self-healing, and resource isolation). The blockchain core layer can be the consortium blockchain network layer, including the storage layer, consensus layer, and smart contract engine. The security collaboration layer can include dynamic encryption modules and privacy protection modules. The application interface layer can be the business layer, which can include standardized APIs and monitoring dashboards.

[0095] As an optional approach, this application embodiment also provides an example of developing a blockchain for synchronizing order relationships. The process for developing a blockchain for synchronizing order relationships can be as follows: Figure 4 As shown, the specific process may include the following steps: Step 1, Data Synchronization: The data initiator generates a transaction request (i.e., the data synchronization request in this embodiment) through a smart contract, including data content (i.e., the target ordered data in this embodiment), a list of target nodes (the target nodes are the nodes to be updated in this embodiment), and an encryption strategy; after the transaction is verified by the consensus layer (i.e., the consensus verification in this embodiment), the storage layer is triggered to store data fragments in the IPFS network (i.e., the target storage network in this embodiment), generating a unique hash index (i.e., the data index information in this embodiment); the target node (i.e., the node to be updated in this embodiment) obtains the data fragments through the P2P network and uses a smart contract to verify data integrity and permissions; the data receiver (i.e., the node to be updated in this embodiment) decrypts the data and writes it to the local database, and monitors the data of multiple nodes in real time through a smart contract, downloading and parsing new data when it is detected, and deleting the downloaded data (corresponding to the operation of the node to be updated deleting the locally downloaded data in this embodiment).

[0096] Step 2, Conflict Resolution: The smart contract monitors the data version numbers of multiple nodes in real time. When a version conflict is detected, an alarm is triggered (i.e., the version consistency check in this application embodiment). If the conflict is data overwriting, the latest version priority strategy is adopted (i.e., the first decision condition determined based on the timestamp in this application embodiment). A confirmation signal is fed back to the blockchain network to update the global state (corresponding to the process of determining the data synchronization request and updating the global data after the decision in this application embodiment).

[0097] Step 3, Cross-chain collaboration: Encapsulate the differences between heterogeneous chains through a general cross-chain protocol (such as Polkadot XCMP) to achieve inter-chain communication; use Hash Time Locked Contracts (HTLC) to ensure that all cross-chain transactions are successful or completely revoked and restored to the initial state before the transaction.

[0098] Compared with existing technologies, the embodiments of this application improve the rationality of consensus node selection by using staking weights and / or historical reputation scores to select consensus nodes; optimize node configuration by selecting consensus verification nodes based on node load and network topology; ensure the validity of verification by generating and broadcasting consensus verification information; improve the reliability of data storage by determining verification results through voting ratios; achieve secure storage of target subscription data through data sharding and distributed storage; ensure accurate and traceable data indexing by aggregating and recording shard hashes; ensure the accuracy and security of updates by obtaining verification and updating data through nodes to be updated; ensure the validity of data synchronization requests by verifying candidate requests and making decisions according to rules; and improve resource utilization efficiency by dynamically adjusting node capacity based on resource utilization.

[0099] Furthermore, as Figure 1 and Figure 2 To illustrate the specific implementation of the method shown, this embodiment provides a data synchronization and update device, such as... Figure 5 As shown, the device includes: a verification module 31, a storage module 32, and a generation module 33.

[0100] Verification module 31 is configured to verify the data synchronization request in response to the data synchronization request of the target order data through the request node corresponding to the data synchronization request in multiple containerized nodes of the blockchain network. The verification module 31 is also configured to determine multiple consensus nodes based on the configuration information of multiple containerized nodes when the data synchronization request is verified to be successful, and to perform consensus verification on the target order data through multiple consensus nodes. Storage module 32 is configured to store the target order data in the target storage network if consensus verification is successful. The generation module 33 is configured to generate data index information corresponding to the target order data in the target storage network. The data index information is used by at least one node to be updated to update the target order data.

[0101] In some examples of this embodiment, the verification module 31 is specifically configured to, when the data synchronization request verification is successful, determine the request consensus node from multiple containerized nodes based on the configuration information of multiple containerized nodes; determine at least one consensus verification node corresponding to the request consensus node; and request at least one consensus verification node to perform consensus verification on the target order data through the request consensus node.

[0102] In some examples of this embodiment, the verification module 31 is further configured to, upon successful verification of the data synchronization request, determine the staking weight data and / or historical reputation score data of multiple containerized nodes within the current consensus period; and, based on the staking weight data and / or historical reputation score data, select a consensus requesting node from the multiple containerized nodes using a proof-of-stake mechanism.

[0103] In some examples of this embodiment, the verification module 31 is further configured to determine the node load data and node network topology information corresponding to multiple containerized nodes; and select at least one consensus verification node corresponding to the request consensus node from multiple containerized nodes based on the node load data and node network topology information.

[0104] In some examples of this embodiment, the verification module 31 is further configured to request consensus nodes to generate consensus verification information corresponding to the data synchronization request; broadcast the consensus verification information to at least one consensus verification node, and the at least one consensus verification node is used to vote based on the consensus verification information to perform consensus verification on the target order data.

[0105] In some examples of this embodiment, the verification module 31 is further configured to determine voting data from at least one consensus verification node voting based on consensus verification information; and to determine the pass rate data for the target order data verification based on the voting data. If the consensus verification is successful, the target order data is stored in the target storage network, including: storing the target order data in the target storage network if the pass rate data is greater than the pass rate threshold.

[0106] In some examples of this embodiment, the storage module 32 is specifically configured to divide the target order data into multiple data shards when the consensus verification is successful; and to distribute the multiple data shards across multiple nodes in the target storage network, wherein the target storage network is a decentralized storage network.

[0107] In some examples of this embodiment, the storage module 32 is further configured to generate shard hash data corresponding to each data shard in multiple data shards; aggregate the shard hash data corresponding to each data shard to obtain the content addressing hash value corresponding to the target order data, and record the content addressing hash value in the latest block in the blockchain network.

[0108] In some examples of this embodiment, the storage module 32 is further configured to, in response to at least one node to be updated detecting the latest block in the blockchain network, retrieve target order data from the target storage network based on the content addressing hash value; verify the target order data through a smart contract in at least one node to be updated, and update the target order data in the local business database corresponding to at least one node to be updated if the verification is successful.

[0109] In some examples of this embodiment, the verification module 31 is further configured to, in response to the fact that there are multiple candidate data synchronization requests corresponding to the target ordering data, perform version consistency verification on the multiple candidate data synchronization requests; if the version consistency verification fails, make a decision on the multiple candidate data synchronization requests through a smart contract according to the target decision conditions to obtain a data synchronization request, wherein the target decision conditions include a first decision condition determined based on a timestamp and / or a second decision condition determined based on business priority.

[0110] In some examples of this embodiment, the generation module 33 is specifically configured to obtain the resource utilization rate indicators of multiple containerized nodes of the blockchain network; and to expand or shrink the capacity of the multiple containerized nodes based on the resource utilization rate indicators.

[0111] It should be noted that other corresponding descriptions of the functional units involved in the data synchronization and update device provided in this embodiment can be found in [reference]. Figure 1 and Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0112] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The method shown.

[0113] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0114] like Figure 6 The diagram shown is a hardware structure schematic of an electronic device according to the present invention, comprising: At least one processor 401; and, Memory 402 is communicatively connected to at least one processor 401; wherein, The memory 402 stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the data synchronization update method as described above.

[0115] Figure 6 Take a processor 401 as an example.

[0116] The electronic device may also include an input device 404 and an output device 404.

[0117] The processor 401, memory 402, input device 403, and output device 404 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0118] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the data synchronization update method in the embodiments of this application, for example, Figure 1 and Figure 2 The method flow is shown. The processor 401 executes various functional applications and data processing by running non-volatile software programs, instructions, and modules stored in the memory 402, thereby realizing the data synchronization update method in the above embodiments.

[0119] The memory 402 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created according to the use of the data synchronization update method, etc. Furthermore, the memory 402 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 402 may optionally include memory remotely located relative to the processor 401, and these remote memories may be connected via a network to the apparatus performing the data synchronization update method. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0120] Input device 403 can receive user clicks and generate signal inputs related to user settings and function control for data synchronization update methods. Output device 404 may include display devices such as a display screen.

[0121] One or more modules are stored in memory 402, and when run by one or more processors 401, the data synchronization update method in any of the above method embodiments is executed.

[0122] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0123] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0124] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0125] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the scheme of this embodiment, compared with the prior art, this application embodiment verifies the data synchronization request by the request node corresponding to the data synchronization request in multiple containerized nodes of the blockchain network, thereby improving the initial verification security of the data synchronization request; by determining multiple consensus nodes based on the configuration information of multiple containerized nodes when the data synchronization request verification is successful, and having multiple consensus nodes perform consensus verification of the target order data, the risk of the target order data being tampered with is reduced; by storing the target order data in the target storage network when the consensus verification is successful, secure storage of the target order data is achieved; and by generating data index information corresponding to the target order data in the target storage network, accurate updating of the target order data by at least one node to be updated is achieved. This system ensures the consistency of order relationship data among multiple nodes; selects consensus request nodes based on staking weights and / or historical reputation scores to improve the rationality of consensus request node selection; optimizes node configuration by selecting consensus verification nodes based on node load and network topology; ensures the effectiveness of verification by generating and broadcasting consensus verification information; improves the reliability of data storage by determining verification results through voting ratios; achieves secure storage of target order data through data sharding and distributed storage; ensures accurate and traceable data indexing by aggregating and recording shard hashes; ensures the accuracy and security of updates by obtaining verification and updating data through nodes to be updated; ensures the effectiveness of data synchronization requests by verifying candidate requests and making decisions according to rules; and improves resource utilization efficiency by dynamically adjusting node capacity based on resource utilization.

[0126] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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. Unless otherwise specified, 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 the element.

[0127] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement 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. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A data synchronization and update method, characterized in that, include: In response to a data synchronization request for target order data, the data synchronization request is verified by the requesting node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network; If the data synchronization request is verified, multiple consensus nodes are determined based on the configuration information of the multiple containerized nodes, and consensus verification of the target order data is performed through the multiple consensus nodes. If consensus verification is successful, the target order data will be stored in the target storage network; Generate data index information corresponding to the target order data in the target storage network. The data index information is used by at least one node to be updated to update the target order data.

2. The method according to claim 1, characterized in that, If the data synchronization request is verified successfully, then based on the configuration information of the multiple containerized nodes, multiple consensus nodes are determined, and consensus verification of the target order data is performed through the multiple consensus nodes, including: If the data synchronization request is verified, a consensus request node is determined from the multiple containerized nodes based on the configuration information of the multiple containerized nodes. Identify at least one consensus verification node corresponding to the requested consensus node; The requesting consensus node requests at least one consensus verification node to perform consensus verification on the target order data.

3. The method according to claim 2, characterized in that, If the data synchronization request is verified successfully, the step of determining the consensus request node from the multiple containerized nodes based on the configuration information of the multiple containerized nodes includes: If the data synchronization request is verified, the staking weight data and / or historical reputation score data of the multiple containerized nodes in the current consensus period are determined; Based on the staking weight data and / or the historical reputation score data, the request consensus node is selected from the plurality of containerized nodes using a proof-of-stake mechanism.

4. The method according to claim 3, characterized in that, The step of determining at least one consensus verification node corresponding to the requested consensus node includes: Determine the node load data and node network topology information corresponding to the multiple containerized nodes; Based on the node load data and the node network topology information, at least one consensus verification node corresponding to the request consensus node is selected from the plurality of containerized nodes.

5. The method according to claim 2, characterized in that, The step of requesting at least one consensus verification node to perform consensus verification on the target order data through the requesting consensus node includes: The consensus verification information corresponding to the data synchronization request is generated by the request consensus node; The consensus verification information is broadcast to the at least one consensus verification node, which is used to vote based on the consensus verification information to perform consensus verification on the target order data.

6. The method according to claim 3, characterized in that, Before storing the target order data in the target storage network after consensus verification is passed, the method further includes: Determine the voting data of the at least one consensus verification node voting based on the consensus verification information; Based on the voting data, determine the pass rate of the target order data verification; The step of storing the target order data in the target storage network after consensus verification is passed includes: If the pass rate data is greater than the pass rate threshold, the target order data will be stored in the target storage network.

7. The method according to claim 1, characterized in that, The step of storing the target order data in the target storage network after consensus verification is passed includes: If consensus verification is successful, the target order data will be divided into multiple data fragments; The multiple data shards are distributed and stored across multiple nodes in the target storage network, wherein the target storage network is a decentralized storage network.

8. The method according to claim 7, characterized in that, The step of generating the data index information corresponding to the target order data in the target storage network includes: Generate the shard hash data corresponding to each data shard in the plurality of data shards; The shard hash data corresponding to each data shard is aggregated to obtain the content addressing hash value corresponding to the target order data, and the content addressing hash value is recorded in the latest block of the blockchain network.

9. The method according to claim 8, characterized in that, After generating the data index information corresponding to the target order data in the target storage network, the method further includes: In response to the at least one node to be updated detecting the latest block in the blockchain network, the target order data is obtained from the target storage network according to the content addressing hash value; The target order data is verified by a smart contract in at least one node to be updated, and if the verification is successful, the target order data is updated in the local business database corresponding to the at least one node to be updated.

10. The method according to claim 1, characterized in that, Before the requesting node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network verifies the data synchronization request, the method further includes: In response to the fact that there are multiple candidate data synchronization requests corresponding to the target order data, a version consistency check is performed on the multiple candidate data synchronization requests; If the version consistency check fails, the smart contract makes a decision on the multiple candidate data synchronization requests according to the target decision conditions to obtain the data synchronization request. The target decision conditions include a first decision condition determined based on timestamps and / or a second decision condition determined based on business priorities.

11. The method according to claim 1, characterized in that, The method further includes: Obtain resource utilization metrics for multiple containerized nodes in the blockchain network; The capacity of the multiple containerized nodes is expanded or reduced based on the resource utilization rate index.

12. A data synchronization and update device, characterized in that, include: The verification module is configured to verify the data synchronization request in response to a data synchronization request for target order data through the request node corresponding to the data synchronization request among multiple containerized nodes in the blockchain network. The determination module is configured to, upon successful verification of the data synchronization request, determine multiple consensus nodes based on the configuration information of the multiple containerized nodes, and perform consensus verification on the target ordering data through the multiple consensus nodes. The storage module is configured to store the target order data in the target storage network upon successful consensus verification. The generation module is configured to generate data index information corresponding to the target order data in the target storage network, and the data index information is used by at least one node to be updated to update the target order data.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 11.

14. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 11.

15. A computer program product, the computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 11.

Images