Data management method, data management device based on blockchain, electronic equipment and storage medium

Abstract

The application provides a data management method, a data management device based on a block chain, an electronic device and a storage medium, and relates to the technical field of Internet. The method comprises the following steps: receiving a data modification task, wherein the data modification task is established by an external system according to abnormal data audited and target data to be modified; converting the data modification task into a transaction request, and performing simulation verification on the transaction request based on a block chain; if the simulation verification is successful, informing the external system to execute the data modification task; otherwise, informing the external system not to execute the data modification task. According to the above scheme, the modification operation is completed by the external system, the block chain only records and verifies data, so that the business coupling is reduced, and the performance of the block chain is improved on the premise of ensuring the data security.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a data management method, a blockchain-based data management device, an electronic device, and a storage medium. Background Technology

[0002] In a blockchain, each block stores certain information, and they are linked together in the order in which they were generated to ensure the immutability and non-forgeability of the stored information through cryptography.

[0003] However, as the number of blockchain users and their business volume increase, the amount of data stored in the blockchain is constantly growing. This massive data volume slows down data verification, thus reducing the blockchain's processing efficiency. Therefore, research on lightweighting blockchain is of great value in improving its business efficiency. Summary of the Invention

[0004] This application provides a data management method, a blockchain-based data management device, an electronic device, and a storage medium for improving the performance of blockchain.

[0005] In a first aspect, this application provides a data management method, comprising: receiving a data modification task, wherein the data modification task is established by an external system based on abnormal data identified during auditing and target data to be modified; converting the data modification task into a transaction request, and simulating and verifying the transaction request based on a blockchain; if the simulation and verification are successful, notifying the external system to execute the data modification task; otherwise, notifying the external system not to execute the data modification task.

[0006] In one possible implementation, the blockchain includes a task interface module, ledger nodes, and endorsement nodes. The step of converting the data modification task into a transaction request and simulating and verifying the transaction request based on the blockchain includes: the task interface module randomly assigning the data modification task to the ledger node; the ledger node converting the data modification task into a transaction request under the blockchain and proposing the transaction request to the corresponding endorsement node according to the data type of the data modification task, wherein the endorsement nodes corresponding to different data types are specified during initialization; the endorsement node simulating and verifying the transaction request, and if the simulation verification is successful, the endorsement node returns the simulation verification result to the ledger node, the simulation verification result including a transaction result with an endorsement signature.

[0007] In one possible implementation, the method further includes: configuring chaincode for the ledger node; the chaincode includes a predetermined data type, an endorser node corresponding to the predetermined data type, and data modification logic; the endorser node performs simulated verification of the transaction request, including: the endorser node performs simulated verification of the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

[0008] In one possible implementation, the blockchain further includes a sorting node; the step of the endorsement node returning the simulation verification result to the ledger node if the simulation verification is successful includes: if the simulation verification is successful, the endorsement node sends the simulation verification result to the sorting node; the sorting node relays the simulation verification result to a message queue cluster via a remote procedure call; the simulation verification results in the message queue cluster are sorted according to the time the simulation verification results arrive at the message queue cluster; the simulation verification results in the message queue cluster are sent to the external system in batches to notify the external system to execute the data modification task corresponding to the simulation verification result.

[0009] In one possible implementation, sending the simulation verification results in the message queue cluster to the external system in batches includes: if the number of simulation verification results in the message queue cluster reaches a preset threshold, or if no new simulation verification results are added to the message queue cluster within a preset time, then a master node is selected from the sorting nodes corresponding to each simulation verification result in the message queue cluster; the master node communicates with the external system to send each simulation verification result in the current message queue cluster as a batch to the external system, so that the external system executes the data modification task corresponding to the batch of simulation verification results.

[0010] In one possible implementation, the method further includes: receiving modification record information returned by the external system after completing the data modification task; generating a corresponding block and updating it in the blockchain based on the modification record information; and synchronizing the update record of this update to the external system.

[0011] Secondly, this application provides a blockchain-based data management device, comprising: a receiving module for receiving a data modification task, wherein the data modification task is established by an external system based on audited abnormal data and target data to be modified; a verification module for converting the data modification task into a transaction request and performing simulated verification of the transaction request based on the blockchain; and a notification module for notifying the external system to execute the data modification task if the simulated verification is successful; otherwise, notifying the external system not to execute the data modification task.

[0012] In one possible implementation, the device further includes a task interface module, an accounting node, and an endorsement node; the task interface module is used to randomly assign the data modification task to the accounting node; the accounting node is used to convert the data modification task into a transaction request under the blockchain, and propose the transaction request to the corresponding endorsement node according to the data type of the data modification task, wherein the endorsement node corresponding to different data types is specified during initialization; the endorsement node is used to simulate and verify the transaction request, and if the simulation and verification is successful, the endorsement node returns the simulation and verification result to the accounting node, the simulation and verification result including the transaction result with endorsement signature.

[0013] In one possible implementation, the apparatus further includes: a configuration module for configuring chaincode for the ledger node; the chaincode includes a predetermined data type, an endorsement node corresponding to the predetermined data type, and data modification logic; the endorsement node is specifically used to simulate and verify the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

[0014] In one possible implementation, the apparatus further includes a sorting node and a verification module; the verification module is configured to send the simulation verification result to the sorting node if the simulation verification is successful; the sorting node is configured to relay the simulation verification result to a message queue cluster via a remote procedure call; the simulation verification results in the message queue cluster are sorted according to the time the simulation verification results arrive at the message queue cluster; the verification module is further configured to send the simulation verification results in the message queue cluster to the external system in batches to notify the external system to execute the data modification task corresponding to the simulation verification result.

[0015] In one possible implementation, the verification module is specifically configured to select a master node from the sorting nodes corresponding to each simulation verification result in the message queue cluster if the number of simulation verification results in the message queue cluster reaches a preset threshold, or if no new simulation verification results are added in the message queue cluster within a preset time. The verification module is further configured to communicate with the external system through the master node, sending each simulation verification result in the current message queue cluster as a batch to the external system, so that the external system executes the data modification task corresponding to that batch of simulation verification results.

[0016] In one possible implementation, the device further includes: a modification module, configured to receive modification record information returned by the external system after completing the data modification task; the modification module is further configured to generate a corresponding block and update it to the blockchain based on the modification record information, and synchronize the update record of this update to the external system.

[0017] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described in any one of the first aspects.

[0018] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which are executed by a processor as described in any one of the first aspects.

[0019] This application provides a data management method, a blockchain-based data management device, an electronic device, and a storage medium. The method includes: receiving a data modification task, wherein the data modification task is established by an external system based on abnormal data identified during audits and the target data to be modified; converting the data modification task into a transaction request, and simulating and verifying the transaction request based on the blockchain; if the simulation and verification are successful, notifying the external system to execute the data modification task; otherwise, notifying the external system not to execute the data modification task. In this solution, the modification operation is handled by an external system, while the blockchain only records and verifies the data, thereby reducing business coupling and improving blockchain performance while ensuring data security. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating an application scenario of a data management method provided in an embodiment of this application.

[0021] Figure 2 A flowchart illustrating a data management method provided in Embodiment 1 of this application;

[0022] Figure 3 This is a simulation verification example provided for an embodiment of this application;

[0023] Figure 4 This is an example of sorting simulation verification results provided in the embodiments of this application;

[0024] Figure 5 This is a structural example diagram of a blockchain-based data management device provided in Embodiment 2 of this application;

[0025] Figure 6 This is a block diagram of a data management device provided in Embodiment 3 of this application;

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of this application. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] First, let's explain the terms involved:

[0029] Remote Procedure Call: A protocol that allows a program running on one server to call a subroutine on another server.

[0030] Figure 1 This illustration illustrates an application scenario of a data management method provided in this application. Using the illustrated scenario as an example: A user's complete data is stored in an external system's database. The external system creates modification tasks based on abnormal data identified during database audits and sends these tasks to the blockchain. The blockchain simulates and verifies the modification tasks. For verified tasks, it notifies the external system to make the necessary modifications. The external system returns the database modification information to the blockchain. The blockchain generates blocks based on this modification information and updates the blockchain, thereby reducing the workload of the blockchain and improving its performance while ensuring data security.

[0031] The technical solutions of this application will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. In the description of this application, unless otherwise expressly specified and limited, the terms should be broadly understood within the art. The embodiments of this application will now be described with reference to the accompanying drawings.

[0032] Example 1

[0033] Figure 2 This is a flowchart illustrating a data management method provided in Embodiment 1 of this application. The method includes the following steps:

[0034] S201. Receive a data modification task, wherein the data modification task is established by an external system based on the abnormal data identified during auditing and the target data to be modified;

[0035] S202. The data modification task is converted into a transaction request, and the transaction request is simulated and verified based on the blockchain.

[0036] S203. If the simulation verification is successful, notify the external system to execute the data modification task; otherwise, notify the external system not to execute the data modification task.

[0037] As an example, external systems include traditional databases that store complete user data, while blockchains do not store complete user data.

[0038] In a scenario example, due to its security, blockchain has become a crucial medium for user data storage, with users often storing their complete data on it. However, as the number of users and the amount of data per user increases, the massive amount of data in the blockchain consumes its resources, slowing down its processing speed. If user data is stored in a database, while data operation records are stored on the blockchain, modifications must first be verified by the blockchain before proceeding. This approach can save blockchain resources while simultaneously improving its processing speed.

[0039] In one example, the blockchain includes a task interface module, ledger nodes, and endorsement nodes. S202 specifically includes: the task interface module randomly assigning the data modification task to the ledger node; the ledger node converting the data modification task into a transaction request under the blockchain, and proposing the transaction request to the corresponding endorsement node according to the data type of the data modification task, wherein the endorsement nodes corresponding to different data types are specified during initialization; the endorsement node performs simulated verification of the transaction request, and if the simulation verification is successful, the endorsement node returns the simulation verification result to the ledger node, the simulation verification result including a transaction result with an endorsement signature.

[0040] As an feasible approach, the data types for data modification tasks include, but are not limited to, user data and product data. The simulated verification process can check the compliance of data modification tasks; non-compliant data modification tasks will result in verification failure.

[0041] Based on the above implementation methods, simulation verification can identify non-compliant data modification tasks, thereby reducing the operational risk of secondary anomalies after abnormal data modification.

[0042] In one example, the data management method further includes: configuring chaincode for the ledger node; the chaincode includes a predetermined data type, an endorser node corresponding to the predetermined data type, and data modification logic; the endorser node simulates and verifies the transaction request, including: the endorser node simulates and verifies the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

[0043] As one feasible approach, the chaincode configured for the ledger nodes can vary, and these different chaincodes include different predetermined data types, different endorsing nodes corresponding to those predetermined data types, and different data modification logic. For example... Figure 3 As shown, Figure 3 This is a simulation verification example. Ledger node C1 has chaincodes A and B installed, and ledger node C2 has chaincodes B and C installed. Chaincode A corresponds to data type D1, endorser node E1, and data modification logic L1; chaincode B corresponds to data type D2, endorser node E2, and data modification logic L2; and chaincode C corresponds to data type D3, endorser node E3, and data modification logic L3. If a transaction request is located on ledger node C1 and the data type corresponding to the transaction request is D2, then according to the configuration of chaincode B, the transaction request is assigned to the endorser node E2 corresponding to chaincode B. Endorser node E2 executes the modification logic L2 corresponding to chaincode B to simulate and verify the transaction request.

[0044] It should be noted that the application does not limit the predetermined data type in the chaincode, the endorsement nodes corresponding to the predetermined data type, or the number of data modification logic.

[0045] As an example, based on the pluggable nature of chaincode, chaincode can be added, deleted, and modified according to actual usage requirements.

[0046] In practical applications, user data types are rapidly expanding. Therefore, it's necessary to update the chaincode's corresponding data types promptly to match user data types, and to update the chaincode's corresponding data modification logic to handle data modification strategies for newly added user data types. For example, the chaincode's data modification logic could check whether current data can be modified to the target data by a certain account through a specific method. If a certain account's permissions only allow modification of certain regions or certain data, the data modification logic would determine the legality of the modification based on permissions. The chaincode's data modification logic could also check whether the target data conforms to the conventions of that data type. For example, ID card information might only support string modifications of a specific number of characters, or a product's traffic might only support a data range of 10G-100G.

[0047] In the case of the scenario example, for the new data types added by the user, the existing data modification logic does not have a corresponding modification strategy. Therefore, the existing data modification logic also needs to be updated synchronously to achieve effective verification.

[0048] Based on the above implementation methods, by simulating and verifying transaction requests through chaincode, transaction requests can be effectively verified even with the rapid expansion of user data types.

[0049] In one example, the blockchain also includes a sorting node; if the simulation verification is successful, the endorsing node returns the simulation verification result to the accounting node, including: if the simulation verification is successful, the endorsing node sends the simulation verification result to the sorting node; the sorting node relays the simulation verification result to a message queue cluster via a remote procedure call; the simulation verification results in the message queue cluster are sorted according to the time the simulation verification results arrive at the message queue cluster; the simulation verification results in the message queue cluster are sent to the external system in batches to notify the external system to execute the data modification task corresponding to the simulation verification result.

[0050] As an feasible approach, such as Figure 4 As shown, Figure 4 This example demonstrates how to sort simulation verification results. Different sorting nodes relay their corresponding simulation verification results to the message queue cluster, sorting them according to the time they arrive at the cluster. For instance, simulation verification result 4, sent by sorting node 4, arrives first and is placed at the top of the message queue cluster. All simulation verification results in the message queue cluster are treated as a batch and sent to an external system, which then modifies the data according to the sorted order.

[0051] In a scenario example, the simulation verification results come from different sorting nodes. Since there is no unified management between the different sorting nodes, there will be modification conflicts. By sorting and batch sending the simulation verification results from different sorting nodes, the modification conflict problem can be avoided.

[0052] As an example, for transaction requests that fail to be verified during simulation, there is no need to sort them. In order to improve processing efficiency, the external system is directly notified of the simulation verification result, and the processing flow of transaction requests that fail to be verified during simulation is terminated.

[0053] Based on the above implementation method, by sorting the simulation verification results and sending the sorted batch simulation verification results to the external system, modification conflicts can be avoided, thereby effectively realizing data modification.

[0054] Specifically, regarding how to send simulation verification results in batches, in one example, sending the simulation verification results in the message queue cluster to the external system in batches includes: if the number of simulation verification results in the message queue cluster reaches a preset threshold, or if no new simulation verification results are added to the message queue cluster within a preset time, then a master node is selected from the sorting nodes corresponding to each simulation verification result in the message queue cluster; the master node communicates with the external system to send each simulation verification result in the current message queue cluster as a batch to the external system, so that the external system can execute the data modification task corresponding to the batch of simulation verification results.

[0055] As an implementable approach, for example, Figure 4 As shown, a threshold of 10 simulated verification results is set in the message queue cluster. If the number of simulated verification results in the current message queue cluster reaches 10, these 10 results are sent to the external system as a batch. A time threshold of 2 minutes is set. If the number of simulated verification results in the current message queue cluster has not reached 10, and no new simulated verification results are added within 2 minutes, the simulated verification results in the current message queue cluster are sent to the external system as a batch.

[0056] In a scenario example, if the amount of data modification is relatively small over a period of time, the number of simulated verification results in the message queue cluster may fall below the threshold for a period of time. In order to ensure that the simulated verification results already in the message queue cluster can be sent normally, a time threshold is set.

[0057] It should be noted that the method for determining the number of batches without application and without restriction can also be adjusted according to actual usage needs. For example, a dynamic batch number can be set to match the real-time access volume of the blockchain.

[0058] Based on the above implementation method, by determining the number of simulated verification results in a batch through a preset method, it can be ensured that the simulated verification results in the message queue cluster can be sent normally.

[0059] In one example, the data management method further includes: receiving modification record information returned by the external system after completing the data modification task; generating a corresponding block and updating it in the blockchain based on the modification record information; and synchronizing the update record of this update to the external system.

[0060] As a feasible approach, after an external system completes a data modification task, to enhance data security, the modification record information is returned to the blockchain. This blockchain, with its high security, stores the modification record to ensure its immutability. The modification record information includes the modification time, the account that modified the data, information about any abnormal data, the target data, and the method of modification. These various types of modification record information facilitate subsequent traceability.

[0061] Based on the above implementation method, the modification operation is completed by an external system, and the blockchain only records and verifies the data, reducing business coupling, improving blockchain performance, and realizing a closed loop for the entire data modification task process.

[0062] In the data management method provided in this embodiment, a data modification task is received. This data modification task is established by an external system based on abnormal data identified during audits and the target data to be modified. The data modification task is converted into a transaction request, and the transaction request is simulated and verified based on the blockchain. If the simulation verification is successful, the external system is notified to execute the data modification task; otherwise, the external system is notified not to execute the data modification task. In this scheme, the modification operation is handled by an external system, while the blockchain only records and verifies the data, thereby reducing business coupling and improving blockchain performance while ensuring data security.

[0063] Example 2

[0064] Figure 5 This is a schematic diagram of the structure of a blockchain-based data management device provided in Embodiment 2 of this application, as shown below. Figure 5 As shown, the device includes:

[0065] The receiving module 61 is used to receive data modification tasks, which are established by an external system based on abnormal data identified during audits and target data to be modified.

[0066] Verification module 62 is used to convert the data modification task into a transaction request and to perform simulated verification of the transaction request based on the blockchain;

[0067] The notification module 63 is used to notify the external system to execute the data modification task if the simulation verification is successful; otherwise, it notifies the external system not to execute the data modification task.

[0068] As an example, external systems include traditional databases that store complete user data, while blockchains do not store complete user data.

[0069] In a scenario example, due to its security, blockchain has become a crucial medium for user data storage, with users often storing their complete data on it. However, as the number of users and the amount of data per user increases, the massive amount of data in the blockchain consumes its resources, slowing down its processing speed. If user data is stored in a database, while data operation records are stored on the blockchain, modifications must first be verified by the blockchain before proceeding. This approach can save blockchain resources while simultaneously improving its processing speed.

[0070] In one example, the blockchain-based data management device further includes a task interface module, ledger nodes, and endorsement nodes. The task interface module is used to randomly assign the data modification task to the ledger nodes. The ledger nodes are used to convert the data modification task into a blockchain transaction request and, based on the data type of the data modification task, propose the transaction request to the corresponding endorsement node, wherein the endorsement nodes corresponding to different data types are specified during initialization. The endorsement nodes are used to simulate and verify the transaction request. If the simulation verification is successful, the endorsement node returns the simulation verification result to the ledger node, and the simulation verification result includes a transaction result with an endorsement signature.

[0071] As an feasible approach, the data types for data modification tasks include, but are not limited to, user data and product data. The simulated verification process can check the compliance of data modification tasks; non-compliant data modification tasks will result in verification failure.

[0072] Based on the above implementation methods, simulation verification can identify non-compliant data modification tasks, thereby reducing the operational risk of secondary anomalies after abnormal data modification.

[0073] In one example, the blockchain-based data management device further includes: a configuration module 64, used to configure chaincode for the ledger node; the chaincode includes a predetermined data type, an endorsement node corresponding to the predetermined data type, and data modification logic; the endorsement node is specifically used to simulate and verify the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

[0074] As one feasible approach, configuration module 64 configures different chaincodes for the accounting nodes. These different chaincodes include different predetermined data types, different endorsement nodes corresponding to the predetermined data types, and different data modification logic. For example... Figure 3 As shown, Figure 3This is a simulation verification example. Ledger node C1 has chaincodes A and B installed, and ledger node C2 has chaincodes B and C installed. Chaincode A corresponds to data type D1, endorser node E1, and data modification logic L1; chaincode B corresponds to data type D2, endorser node E2, and data modification logic L2; and chaincode C corresponds to data type D3, endorser node E3, and data modification logic L3. If a transaction request is located on ledger node C1 and the data type corresponding to the transaction request is D2, then according to the configuration of chaincode B, the transaction request is assigned to the endorser node E2 corresponding to chaincode B. Endorser node E2 executes the modification logic L2 corresponding to chaincode B to simulate and verify the transaction request.

[0075] It should be noted that the application does not limit the predetermined data type in the chaincode, the endorsement nodes corresponding to the predetermined data type, or the number of data modification logic.

[0076] As an example, based on the pluggable nature of chaincode, chaincode can be added, deleted, and modified according to actual usage requirements.

[0077] In practical applications, user data types are rapidly expanding. Therefore, it's necessary to update the chaincode's corresponding data types promptly to match user data types, and to update the chaincode's corresponding data modification logic to handle data modification strategies for newly added user data types. For example, the chaincode's data modification logic could check whether current data can be modified to the target data by a certain account through a specific method. If a certain account's permissions only allow modification of certain regions or certain data, the data modification logic would determine the legality of the modification based on permissions. The chaincode's data modification logic could also check whether the target data conforms to the conventions of that data type. For example, ID card information might only support string modifications of a specific number of characters, or a product's traffic might only support a data range of 10G-100G.

[0078] In the case of the scenario example, for the new data types added by the user, the existing data modification logic does not have a corresponding modification strategy. Therefore, the existing data modification logic also needs to be updated synchronously to achieve effective verification.

[0079] Based on the above implementation methods, by simulating and verifying transaction requests through chaincode, transaction requests can be effectively verified even with the rapid expansion of user data types.

[0080] In one example, the blockchain-based data management device further includes a sorting node and a verification module 62. The verification module 62 is configured to, if the simulated verification is successful, send the simulated verification result to the sorting node. The sorting node relays the simulated verification result to a message queue cluster via a remote procedure call. The simulated verification results in the message queue cluster are sorted according to the time the simulated verification results arrive at the message queue cluster. The verification module 62 is also configured to send the simulated verification results in the message queue cluster to the external system in batches to notify the external system to execute the data modification task corresponding to the simulated verification result.

[0081] As an feasible approach, such as Figure 4 As shown, Figure 4 This example demonstrates how to sort simulation verification results. Different sorting nodes relay their corresponding simulation verification results to the message queue cluster, sorting them according to the time they arrive at the cluster. For instance, simulation verification result 4, sent by sorting node 4, arrives first and is placed at the top of the message queue cluster. All simulation verification results in the message queue cluster are treated as a batch and sent to an external system, which then modifies the data according to the sorted order.

[0082] In a scenario example, the simulation verification results come from different sorting nodes. Since there is no unified management between the different sorting nodes, there will be modification conflicts. By sorting and batch sending the simulation verification results from different sorting nodes, the modification conflict problem can be avoided.

[0083] As an example, for transaction requests that fail to be verified during simulation, there is no need to sort them. In order to improve processing efficiency, the external system is directly notified of the simulation verification result, and the processing flow of transaction requests that fail to be verified during simulation is terminated.

[0084] Based on the above implementation method, by sorting the simulation verification results and sending the sorted batch simulation verification results to the external system, modification conflicts can be avoided, thereby effectively realizing data modification.

[0085] Specifically, regarding how to send simulated verification results in batches, in one example, verification module 62 is specifically used to select a master node from the sorting nodes corresponding to each simulated verification result in the message queue cluster if the number of simulated verification results in the message queue cluster reaches a preset threshold, or if no new simulated verification results are added in the message queue cluster within a preset time. Verification module 62 is also specifically used to communicate with the external system through the master node, sending each simulated verification result in the current message queue cluster as a batch to the external system, so that the external system can execute the data modification task corresponding to that batch of simulated verification results.

[0086] As an implementable approach, for example, Figure 4 As shown, a threshold of 10 simulated verification results is set in the message queue cluster. If the number of simulated verification results in the current message queue cluster reaches 10, these 10 results are sent to the external system as a batch. A time threshold of 2 minutes is set. If the number of simulated verification results in the current message queue cluster has not reached 10, and no new simulated verification results are added within 2 minutes, the simulated verification results in the current message queue cluster are sent to the external system as a batch.

[0087] In a scenario example, if the amount of data modification is relatively small over a period of time, the number of simulated verification results in the message queue cluster may fall below the threshold for a period of time. In order to ensure that the simulated verification results already in the message queue cluster can be sent normally, a time threshold is set.

[0088] It should be noted that the method for determining the number of batches without application and without restriction can also be adjusted according to actual usage needs. For example, a dynamic batch number can be set to match the real-time access volume of the blockchain.

[0089] Based on the above implementation method, by determining the number of simulated verification results in a batch through a preset method, it can be ensured that the simulated verification results in the message queue cluster can be sent normally.

[0090] In one example, the blockchain-based data management device further includes: a modification module 65, configured to receive modification record information returned by the external system after completing the data modification task; the modification module 65 is also configured to generate a corresponding block and update it to the blockchain according to the modification record information, and synchronize the update record of this update to the external system.

[0091] As a feasible approach, after an external system completes a data modification task, to enhance data security, the modification record information is returned to the blockchain. This blockchain, with its high security, stores the modification record to ensure its immutability. The modification record information includes the modification time, the account that modified the data, information about any abnormal data, the target data, and the method of modification. These various types of modification record information facilitate subsequent traceability.

[0092] Based on the above implementation method, the modification operation is completed by an external system, and the blockchain only records and verifies the data, reducing business coupling, improving blockchain performance, and realizing a closed loop for the entire data modification task process.

[0093] In the blockchain-based data management device provided in this embodiment, a receiving module is used to receive data modification tasks, which are established by an external system based on abnormal data identified during audits and the target data to be modified. A verification module is used to convert the data modification task into a transaction request and perform simulated verification of the transaction request based on the blockchain. A notification module is used to notify the external system to execute the data modification task if the simulated verification is successful; otherwise, it notifies the external system not to execute the data modification task. In this scheme, the modification operation is handled by an external system, while the blockchain only records and verifies the data, thereby reducing business coupling and improving blockchain performance while ensuring data security.

[0094] Example 3

[0095] Figure 6 This is a block diagram of a data management device according to an exemplary embodiment. The device may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0096] The device 800 may include one or more of the following components: a processing component 802, a memory 804, a power supply component 806, a multimedia component 808, an audio component 810, an input / output interface 812, a sensor component 814, and a communication component 816.

[0097] Processing component 802 typically controls the overall operation of device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 802 may include one or more processors 820 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

[0098] Memory 804 is configured to store various types of data to support the operation of device 800. Examples of such data include instructions for any application or method operating on device 800, contact data, phonebook data, messages, pictures, videos, etc. Memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0099] Power supply component 806 provides power to various components of device 800. Power supply component 806 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to device 800.

[0100] Multimedia component 808 includes a screen that provides an output interface between the device 800 and the user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen may be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0101] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when device 800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

[0102] Input / output interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0103] Sensor assembly 814 includes one or more sensors for providing status assessments of various aspects of device 800. For example, sensor assembly 814 may detect the on / off state of device 800, the relative positioning of components such as the display and keypad of device 800, changes in the position of device 800 or a component of device 800, the presence or absence of user contact with device 800, the orientation or acceleration / deceleration of device 800, and temperature changes of device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include an optical sensor, such as a complementary metal-oxide-semiconductor (CMOS) image sensor or a charge-coupled device (CCD), for use in imaging applications. In some embodiments, sensor assembly 814 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0104] Communication component 816 is configured to facilitate wired or wireless communication between device 800 and other devices. Device 800 can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra-Wide Band (UWB), Bluetooth, and other technologies.

[0105] In an exemplary embodiment, the apparatus 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0106] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of the device 800 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0107] Example 4

[0108] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 7 As shown, the electronic device includes:

[0109] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0110] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0111] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, thereby implementing the methods in the above-described method embodiments.

[0112] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0113] This application provides a non-transitory computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the foregoing embodiments.

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

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

Claims

1. A data management method, characterized in that, The method includes: Receive data modification tasks, which are created by an external system based on abnormal data identified during audits and the target data to be modified; The data modification task is transformed into a transaction request, and the transaction request is simulated and verified based on the blockchain. If the simulation verification is successful, the external system is notified to execute the data modification task; otherwise, the external system is notified not to execute the data modification task. Receive modification record information returned by the external system after completing the data modification task; Based on the modification record information, a corresponding block is generated and updated in the blockchain, and the update record of this update is synchronized to the external system; The blockchain includes a task interface module, ledger nodes, and endorsement nodes; the process of converting the data modification task into a transaction request and simulating and verifying the transaction request based on the blockchain includes: The task interface module randomly assigns the data modification task to the accounting node; The ledger node transforms the data modification task into a transaction request under the blockchain, and proposes the transaction request to the corresponding endorsement node according to the data type of the data modification task. The endorsement nodes corresponding to different data types are specified during initialization. The endorsing node performs a simulated verification of the transaction request. If the simulated verification is successful, the endorsing node returns the simulated verification result to the accounting node. The simulated verification result includes the transaction result with the endorsement signature.

2. The method according to claim 1, characterized in that, The method further includes: Configure chaincode for the accounting node; the chaincode includes a predetermined data type, an endorsement node corresponding to the predetermined data type, and data modification logic; The endorsing node performs simulated verification of the transaction request, including: The endorsing node simulates and verifies the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

3. The method according to claim 1, characterized in that, The blockchain also includes sorting nodes; if the simulation verification is successful, the endorsing node returns the simulation verification result to the accounting node, including: If the simulation verification is successful, the endorsement node will send the simulation verification result to the sorting node. The sorting node relays the simulation verification results to the message queue cluster via remote procedure call; the simulation verification results in the message queue cluster are sorted according to the time the simulation verification results arrive at the message queue cluster. The simulation verification results in the message queue cluster are sent to the external system in batches to notify the external system to execute the data modification task corresponding to the simulation verification results.

4. The method according to claim 3, characterized in that, The step of sending the simulation verification results from the message queue cluster to the external system in batches includes: If the number of simulated verification results in the message queue cluster reaches a preset threshold, or if no new simulated verification results are added in the message queue cluster within a preset time, then a master node is selected from the sorting nodes corresponding to each simulated verification result in the message queue cluster. The master node communicates with the external system to send each simulation verification result in the current message queue cluster as a batch to the external system, so that the external system can execute the data modification task corresponding to the batch of simulation verification results.

5. A blockchain-based data management device, characterized in that, The device includes: The receiving module is used to receive data modification tasks, which are established by an external system based on abnormal data identified during audits and the target data to be modified. The verification module is used to convert the data modification task into a transaction request, and the blockchain simulates and verifies the transaction request. The notification module is used to notify the external system to execute the data modification task if the simulation verification is successful; otherwise, it notifies the external system not to execute the data modification task. The modification module is used to receive modification record information returned by the external system after the data modification task is completed; The modification module is also used to generate a corresponding block and update it to the blockchain based on the modification record information, and to synchronize the update record of this update to the external system; The device also includes a task interface module, an accounting node, and an endorsement node; The task interface module is used to randomly assign the data modification task to the accounting node; The ledger node is used to transform the data modification task into a transaction request under the blockchain, and to propose the transaction request to the corresponding endorsement node according to the data type of the data modification task, wherein the endorsement node corresponding to different data types is specified during initialization; The endorsing node is used to simulate and verify the transaction request. If the simulation verification is successful, the endorsing node returns the simulation verification result to the accounting node. The simulation verification result includes the transaction result with the endorsement signature.

6. The apparatus according to claim 5, characterized in that, The device further includes: A configuration module is used to configure chaincode for the accounting node; the chaincode includes a predetermined data type, an endorsement node corresponding to the predetermined data type, and data modification logic; The endorsing node is specifically used to simulate and verify the transaction request by executing the data modification logic in the chaincode on the data in the transaction request.

7. The apparatus according to claim 5, characterized in that, The device also includes a sorting node and a verification module; The verification module is configured such that if the simulation verification is successful, the endorsement node sends the simulation verification result to the sorting node. The sorting node is used to relay the simulation verification results to the message queue cluster via remote procedure call; the simulation verification results in the message queue cluster are sorted according to the time when the simulation verification results arrive at the message queue cluster. The verification module is also used to send the simulated verification results in the message queue cluster to the external system in batches, so as to notify the external system to execute the data modification task corresponding to the simulated verification results.

8. The apparatus according to claim 7, characterized in that, The verification module is specifically used to select a master node from the sorting nodes corresponding to each simulation verification result in the message queue cluster if the number of simulated verification results in the message queue cluster reaches a preset threshold, or if no new simulated verification results are added in the message queue cluster within a preset time. The verification module is further configured to communicate with the external system through the master node, and send each simulated verification result in the current message queue cluster as a batch to the external system, so that the external system can execute the data modification task corresponding to the batch of simulated verification results.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-4.

Images