Data processing method and device, equipment and storage medium

Abstract

This application provides a data processing method, apparatus, device, and storage medium, applicable to the field of blockchain technology. The data processing method is applied to the master node in a consortium blockchain network. The master node receives transaction data reported by the business end and then determines whether the current block meets the sparse consensus conditions based on the transaction data. These sparse consensus conditions include an interval consensus strategy. If met, the master node initiates a consensus process with each consensus node, enabling them to reach a consensus on the current block. After consensus is achieved, a new block corresponding to the transaction data is generated according to the block formation rules. This application implements an interval consensus strategy in a highly reliable consortium blockchain network by setting sparse consensus conditions, balancing the necessity of consensus with transaction performance. It overcomes the limitations of existing technologies that use multiple transactions per block to improve performance, making blocks easier to manage, reducing communication pressure, and ensuring the stability of the system's carrying capacity.

Description

Technical Field

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

[0002] In high-frequency transaction scenarios on highly reliable consortium blockchains, multiple transactions per block can be used to improve performance. However, this approach has certain limitations. For example, firstly, blocks become too large and difficult to manage; secondly, communication pressure is high; and thirdly, consensus calculations are frequent, and the increasing transaction volume puts greater strain on the system, while the system's capacity is limited. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and storage medium to solve the technical problems of high block management difficulty, high communication pressure, and increased system consumption caused by frequent consensus calculations in high-frequency transaction scenarios on highly reliable consortium blockchains.

[0004] Firstly, this application provides a data processing method applied to a master node in a consortium blockchain network, the method comprising:

[0005] Receive transaction data reported by the business side;

[0006] Based on the transaction data, it is determined whether the current block meets the sparse consensus condition, which is set according to the interval consensus strategy.

[0007] If so, initiate a consensus process to enable all consensus nodes to reach a consensus on the current block, and generate a new block corresponding to the transaction data according to the block formation rules after the consensus is completed.

[0008] In one possible design, if the current block does not meet the sparse consensus condition, a new block corresponding to the transaction data is generated according to the block formation rules.

[0009] In one possible design, determining whether the current block meets the sparse consensus condition based on the transaction data includes:

[0010] Write the transaction data into the target block to obtain the current block;

[0011] Determine whether the current block conforms to the interval consensus strategy;

[0012] If so, determine that the current block satisfies the sparse consensus condition;

[0013] The interval consensus strategy includes a custom block interval or a fixed number of transactions.

[0014] In one possible design, the master node is elected during the previous round of consensus process.

[0015] In one possible design, the method further includes:

[0016] If a consensus failure occurs during the consensus process, the consensus failure information reported by each consensus node will be received.

[0017] In one possible design, if the transaction risk type corresponding to the transaction data is low-risk, after generating the new block corresponding to the transaction data according to the block formation rules, the following steps are also included:

[0018] The first return result is sent back to the service terminal, so that the service terminal can obtain the first return result, which includes the block generation result.

[0019] In one possible design, if the transaction risk type corresponding to the transaction data is high-risk, after the consensus nodes have reached a consensus on the current block, the following steps are also included:

[0020] The second feedback result is sent back to the service terminal, so that the service terminal can obtain the second feedback result. The second feedback result includes the consensus completion result of each consensus node, and the consensus completion result includes consensus failure or consensus success.

[0021] Secondly, this application discloses a data processing apparatus, comprising:

[0022] The receiving module is used to receive transaction data reported by the business side;

[0023] The judgment module is used to determine whether the current block meets the sparse consensus condition based on the transaction data. The sparse consensus condition is set according to the interval consensus strategy.

[0024] The consensus and generation module is used to initiate a consensus process if it is determined that the current block meets the sparse consensus condition, so that each consensus node reaches a consensus on the current block, and generates a new block corresponding to the transaction data according to the block formation rules after the consensus is completed.

[0025] In one possible design, the consensus and generation module is further used for:

[0026] If the current block does not meet the sparse consensus condition, a new block corresponding to the transaction data is generated according to the block formation rules.

[0027] In one possible design, the determination module is specifically used for:

[0028] Write the transaction data into the target block to obtain the current block;

[0029] Determine whether the current block conforms to the interval consensus strategy;

[0030] If so, determine that the current block satisfies the sparse consensus condition;

[0031] The interval consensus strategy includes a custom block interval or a fixed number of transactions.

[0032] In one possible design, the master node is elected during the previous round of consensus process.

[0033] In one possible design, the receiving module is further configured to:

[0034] If a consensus failure occurs during the consensus process, the consensus failure information reported by each consensus node will be received.

[0035] In one possible design, the data processing device further includes: a feedback module; if the transaction risk type corresponding to the transaction data is a low-risk type, the feedback module is used to:

[0036] The first return result is sent back to the service terminal, so that the service terminal can obtain the first return result, which includes the block generation result.

[0037] In one possible design, if the transaction risk type corresponding to the transaction data is a high-risk type, the feedback module is further used for:

[0038] The second feedback result is sent back to the service terminal, so that the service terminal can obtain the second feedback result. The second feedback result includes the consensus completion result of each consensus node, and the consensus completion result includes consensus failure or consensus success.

[0039] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0040] The memory stores computer-executed instructions;

[0041] The processor executes computer execution instructions stored in the memory to implement any of the possible data processing methods provided in the first aspect.

[0042] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the possible data processing methods provided in the first aspect.

[0043] Fifthly, this application provides a computer program product including computer execution instructions, which, when executed by a processor, are used to implement any of the possible data processing methods provided in the first aspect.

[0044] This application provides a data processing method, apparatus, device, and storage medium. The data processing method is applied to the master node in a consortium blockchain network. First, it receives transaction data reported by the business end. Then, it determines whether the current block meets the sparse consensus conditions based on the transaction data. These sparse consensus conditions include an interval consensus strategy. If met, a consensus process is initiated with each consensus node, enabling them to reach a consensus on the current block. After consensus is achieved, a new block corresponding to the transaction data is generated according to the block formation rules. By setting sparse consensus conditions and implementing an interval consensus strategy in a highly reliable consortium blockchain network, the necessity of consensus and transaction performance are balanced. This overcomes the limitations of existing technologies that use multiple transactions per block to improve performance, making blocks easier to manage, reducing communication pressure, and ensuring the stability of the system's carrying capacity. Attached Figure Description

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

[0046] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0047] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0048] Figure 3 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0049] Figure 4 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of another data processing apparatus provided in an embodiment of this application;

[0051] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0052] 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 methods and apparatus consistent with some aspects of this application as detailed in the appended claims.

[0053] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0054] It should be noted that the data processing methods, apparatus, devices and storage media provided in this application can be used in the field of blockchain technology, or in any field other than blockchain technology. The application fields of the data processing methods, apparatus, devices and storage media provided in this application are not limited.

[0055] In high-frequency transaction scenarios on highly reliable consortium blockchains, multiple transactions per block can be used to improve performance. However, this approach has certain limitations. For example, firstly, blocks become too large and difficult to manage; secondly, communication pressure is high; and thirdly, consensus calculations are frequent, and the increasing transaction volume puts greater strain on the system, while the system's capacity is limited.

[0056] To address the aforementioned problems in the existing technology, this application provides a data processing method, apparatus, device, and storage medium. The inventive concept of the data processing method provided in this application lies in: setting sparse consensus conditions. When a business terminal reports transaction data to the consortium blockchain network, the master node in the consortium blockchain network first determines whether the current block meets the sparse consensus conditions based on the transaction data. If it does, a consensus process is initiated, enabling all consensus nodes in the consortium blockchain network to reach a consensus on the current block. After consensus is completed, the master node then packages and groups the blocks, that is, generates a new block corresponding to the transaction data according to the block formation rules. If the conditions are not met, consensus is not initiated, and the master node directly generates a new block corresponding to the transaction data according to the block formation rules. Among them, the sparse consensus condition can be set according to the interval consensus strategy. Therefore, consensus is only achieved when the sparse consensus condition is met, that is, when the interval consensus strategy is followed. If the condition is not met, consensus is not achieved. Thus, by setting the sparse consensus condition, the interval consensus strategy is implemented in the highly trusted consortium blockchain network, balancing the necessity of consensus and transaction performance. This overcomes the limitations of using multiple transactions per block to improve performance in existing technologies, making blocks easier to manage and reducing communication pressure while ensuring the stability of the system's carrying capacity.

[0057] The following describes exemplary application scenarios of the embodiments of this application.

[0058] Figure 1 This is a schematic diagram of an application scenario provided in an embodiment of this application, such as... Figure 1 As shown, business terminal 100 initiates a transaction to blockchain network 200, thereby generating transaction data. The blockchain network can be, for example, a consortium blockchain network, which includes multiple blockchain nodes. Among these multiple blockchain nodes, one is elected as the master node 201. The master node 201 can be configured to execute the data processing method provided in this embodiment. First, it receives the transaction data reported by business terminal 100, then determines whether the current block meets the sparse consensus condition based on the transaction data. If it does, the master node 201 initiates a consensus process to each consensus node, enabling each consensus node to reach a consensus on the current block, and then packages the blocks after the consensus is completed. It can be understood that each consensus node is also a corresponding blockchain node in blockchain network 200, and the specific consensus node is determined from the blockchain nodes of blockchain network 200 based on the specific content of the transaction.

[0059] It is understood that the business terminal 100 can be configured with corresponding electronic devices, such as computers, POS machines, and smartphones, for initiating transactions. This application embodiment does not limit the type of electronic device configured in the business terminal 100. Figure 1 The example shown is a computer. Each blockchain node in the blockchain network 200 is equipped with electronic devices, such as servers, computers, and server clusters. Figure 1 Each blockchain node in the example is a server. Furthermore, this application does not limit the specific content of the transaction; it can be any transaction conducted on a consortium blockchain network used in applications such as finance.

[0060] It should be noted that the above application scenarios are merely illustrative, and the data processing methods, apparatus, devices, and storage media provided in the embodiments of this application include, but are not limited to, applications in the above application scenarios.

[0061] Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of this application. Figure 2 As shown in the embodiments of this application, the data processing method includes:

[0062] S101: Receive transaction data reported by the business terminal.

[0063] When a business initiates a transaction on the blockchain network, for example, the parties involved can organize a transaction to generate transaction data. This transaction data is then reported by the business to various blockchain nodes in the network. The blockchain node elected as the master node will inevitably receive the transaction data reported by the business. In other words, the master node in the blockchain network receives the transaction data reported by the business.

[0064] The specific content of the transaction data is determined by the transaction itself, and this application embodiment does not limit the specific content of the transaction data.

[0065] Optionally, the master node is elected in the previous consensus process, that is, a leader node is elected when the consensus nodes reach a consensus in the previous round, and the elected leader node is the master node for the next round relative to the previous round. In some embodiments, the election of the master node may follow a pre-set election strategy, such as a valid, not disconnected, or preset election criteria, etc. The embodiments of this application do not limit the election strategy for the master node.

[0066] S102: Determine whether the current block meets the sparse consensus condition based on the transaction data.

[0067] Among them, the sparse consensus condition is set according to the interval consensus strategy.

[0068] The interval consensus strategy sets corresponding sparse consensus conditions. After receiving transaction data, the master node determines whether the current block corresponding to the transaction data meets the sparse consensus conditions. If it does, it initiates consensus execution step S103. Otherwise, if it does not meet the sparse consensus conditions, it executes step S104.

[0069] The interval consensus strategy refers to a approach used in consortium blockchain networks with extremely low consensus error probabilities. Instead of block-by-block consensus, it balances the necessity of Byzantine consensus with transaction performance. In other words, for highly reliable consortium blockchain networks, due to the low risk of the Byzantine problem, block-by-block consensus is not always necessary; interval consensus can be used to balance consensus and performance. It should be noted that an extremely low consensus error probability can be represented by setting a corresponding error threshold. Error probabilities below this threshold are considered extremely low. The error threshold can be set based on the specific transactions involved and the blockchain nodes of the consortium blockchain network; this embodiment does not limit this setting.

[0070] S103: Initiate the consensus process so that all consensus nodes can reach a consensus on the current block.

[0071] If the current block is determined to meet the sparse consensus condition, the master node initiates a consensus process to all consensus nodes, which then perform Byzantine consensus on the current block. Here, the current block refers to the target block for which transaction data is written.

[0072] After consensus is reached, the master node generates a new block corresponding to the transaction data according to the block formation rules, which is to execute step S104.

[0073] S104: Generate a new block corresponding to the transaction data according to the block formation rules.

[0074] If the master node determines that the current block does not meet the sparse consensus conditions, the master node will not initiate a consensus process but will directly generate a new block corresponding to the transaction data according to the block formation rules. This application embodiment does not limit the specific content of the block formation rules; its purpose is to package and group blocks.

[0075] As described in steps S103 and S104 above, after each consensus is completed in the Byzantine consensus mechanism, or when the current block does not meet the sparse consensus condition, the master node packages the transaction data into blocks to generate a new block. This reduces the workload of block assembly and the complexity of node selection, while also providing a certain degree of system stability, facilitating block management, and reducing communication pressure. The introduction of the sparse consensus condition enables the implementation of an interval consensus strategy. Consensus is only initiated when the current block meets the sparse consensus condition, making consensus computation less frequent. This prevents the system's capacity from being challenged by increased system consumption due to continuously increasing transaction volume, thus ensuring the stability of the system's capacity.

[0076] The data processing method provided in this application is applied to the master node in a consortium blockchain network. First, the master node receives transaction data reported by the business terminal. Then, the master node determines whether the current block meets the sparse consensus conditions based on the transaction data. These sparse consensus conditions include an interval consensus strategy. If the conditions are met, the master node initiates a consensus process with each consensus node, enabling them to reach a consensus on the current block. If the conditions are not met, the master node directly generates a new block corresponding to the transaction data according to the block formation rules. By setting sparse consensus conditions and implementing an interval consensus strategy in a highly reliable consortium blockchain network, the necessity of consensus and transaction performance are balanced. This overcomes the limitations of existing technologies that use multiple transactions per block to improve performance, making blocks easier to manage, reducing communication pressure, and ensuring the stability of the system's carrying capacity.

[0077] Figure 3 This is a flowchart illustrating another data processing method provided in an embodiment of this application. Figure 3 As shown in the embodiments of this application, the data processing method includes:

[0078] S201: Receive transaction data reported by the business terminal.

[0079] The possible implementation methods, principles and technical effects of step S201 are similar to those of step S101. For a detailed description, please refer to the foregoing content, and it will not be repeated here.

[0080] S202: Write the transaction data to the target block to obtain the current block.

[0081] Each blockchain node stores the consortium blockchain corresponding to the transaction data. When the master node, as one of the blockchain nodes, receives the transaction data reported by the business end, it writes the transaction data into the corresponding block in the consortium blockchain. This corresponding block is the target block, and the target block into which the transaction data is written is the current block. Therefore, the master node obtains the current block.

[0082] S203: Determine whether the current block conforms to the interval consensus strategy.

[0083] The master node determines whether the current block conforms to the interval consensus strategy, which is preset in advance and may include, for example, a custom block interval or a fixed number of transactions.

[0084] Specifically, custom block interval refers to customizing the block interval for consensus, such as initiating a consensus every 10 blocks. It determines whether there is a 10-block interval between the current block and the previous consensus. If so, the current block meets the interval consensus strategy; otherwise, the current block does not meet the interval consensus strategy.

[0085] Fixed transaction count refers to using a fixed number of transactions for consensus. For example, consensus is initiated every 5 transactions to determine if the number of transactions written to the current block is a multiple of the fixed number of transactions (5). If so, the current block meets the interval consensus strategy; otherwise, it does not. The transaction count refers to which number of transactions the data is written to the target block.

[0086] The master node determines whether to initiate consensus for the current block. For example, if the current block meets the interval consensus policy, then consensus is initiated, which means that the current block meets the sparse consensus condition, and step S204 is executed. Otherwise, if the current block does not meet the interval consensus policy, it means that the current block does not meet the sparse consensus condition, and consensus is not initiated, i.e., step S205 is executed directly.

[0087] It should be noted that the specific details of the interval consensus strategies listed above are merely illustrative examples. In actual operation, the strategies can be configured according to the content of the transactions and the deployment of each blockchain node in the consortium blockchain network. For example, in high-throughput scenarios, a fixed number of transactions can be used for consensus. If the minimum throughput makes the block interval too long, a tiered interval strategy can be added to shorten the excessively long block interval. For instance, in a long block interval, consensus can be initiated after each transaction data is written to the target block. In a short block interval, a fixed number of transactions can be used for consensus, or a number of transactions greater than that in a long interval can be set for consensus. The specific details of the tiered interval strategy can be configured according to the actual operating conditions. This application does not limit the specific details of the interval consensus strategy; its purpose is to avoid block-by-block consensus, thereby balancing the necessity of consensus and transaction performance.

[0088] S204: Initiate a consensus process to enable all consensus nodes to reach a consensus on the current block.

[0089] If the current block is determined to conform to the interval consensus strategy, the master node initiates a consensus process to each consensus node, and each consensus node performs Byzantine consensus on the current block.

[0090] After consensus is reached, the master node generates a new block corresponding to the transaction data according to the block formation rules, which is step S205. It is understandable that after each consensus node completes its consensus, it will report the consensus completion result to the master node. The consensus completion result includes whether the consensus failed or succeeded.

[0091] Optionally, each consensus node executes the consensus process. If consensus fails during the process, each consensus node reports the failure to all other blockchain nodes except itself. Conversely, if consensus succeeds, each consensus node reports the success to all other blockchain nodes. As one of the blockchain nodes, the master node will inevitably receive both the failure and success reports from each consensus node.

[0092] In some embodiments, if consensus fails, the master node regenerates all blocks within the interval involved in the consensus process and calculates the scope of the error's impact. If the consensus failure information involves a transaction, a notification is sent to the relevant parties of the transaction. The delay between the two consensus attempts is a system-level delay.

[0093] S205: Generate a new block corresponding to the transaction data according to the block formation rules.

[0094] If the master node determines that the current block does not conform to the interval consensus strategy, the master node does not initiate a consensus process but directly generates a new block corresponding to the transaction data according to the block formation rules. This application embodiment does not limit the specific content of the block formation rules; its purpose is to package and group blocks.

[0095] Furthermore, if the transaction risk type corresponding to the transaction data is low risk, step S206 may be included after step S205.

[0096] S206: Send the first return result back to the business end, so that the business end can obtain the first return result.

[0097] The first return result includes the block generation result.

[0098] If the transaction risk type corresponding to the transaction data is low-risk, after the master node generates a new block corresponding to the transaction data according to the block formation rules, it sends the first feedback result back to the business end, allowing the business end to obtain the first feedback result. The first feedback result includes the generation information of the new block, that is, the block generation result.

[0099] Optionally, if the transaction risk type corresponding to the transaction data is a high-risk type, step S207 may be included after step S204.

[0100] S207: Send the second return result back to the business end, so that the business end can obtain the second return result.

[0101] The second feedback result includes the consensus completion results of each consensus node, which includes consensus failure or consensus success.

[0102] If the transaction risk type corresponding to the transaction data is high-risk, after the master node completes consensus on the current block with each consensus node, for example, after the master node receives consensus success information or consensus failure information sent by each consensus node, the master node generates a second feedback result based on the consensus success information or consensus failure information, and sends the second feedback result back to the business end, so that the business end knows whether the consensus completion result is consensus failure or consensus success.

[0103] It is understandable that the type of transaction risk can be determined in advance as either low-risk or high-risk based on the specific content of the transaction. This application does not limit the classification of transaction risk types.

[0104] Optionally, for the business side, if subsequent steps of the transaction begin after a new block is formed, a reversal mechanism needs to be set up for the transaction. For example, if the master node receives a consensus failure message that includes a transaction error, meaning the consensus failure was caused by a transaction error, and the second feedback result received by the business side also indicates a consensus failure caused by a transaction error, the business side needs to reverse the transaction.

[0105] The data processing method provided in this application is applied to the master node in a consortium blockchain network. First, the master node receives transaction data reported by the business terminal. Then, the master node writes the transaction data into the target block to obtain the current block and determines whether the current block conforms to the interval consensus strategy. If it does, the current block is determined to meet the sparse consensus condition. The master node then initiates a consensus process to each consensus node, enabling them to reach a consensus on the current block. After the consensus nodes complete their consensus, a new block corresponding to the transaction data is generated according to the block formation rules. If the block does not conform, the master node directly generates a new block corresponding to the transaction data according to the block formation rules. Implementing an interval consensus strategy in a highly reliable consortium blockchain network balances the necessity of consensus with transaction performance, thereby overcoming the limitations of existing technologies that use multiple transactions per block to improve performance. This makes blocks easier to manage, reduces communication pressure, and ensures the stability of the system's carrying capacity.

[0106] Figure 4 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. Figure 4 As shown, the data processing apparatus 400 provided in this embodiment includes:

[0107] The receiving module 401 is used to receive transaction data reported by the business terminal;

[0108] The judgment module 402 is used to determine whether the current block meets the sparse consensus condition based on the transaction data. The sparse consensus condition is set according to the interval consensus strategy.

[0109] The consensus and generation module 403 is used to initiate a consensus process if it is determined that the current block meets the sparse consensus conditions, so that all consensus nodes reach a consensus on the current block, and generate a new block corresponding to the transaction data according to the block formation rules after the consensus is completed.

[0110] In one possible design, the consensus and generation module 403 is also used for:

[0111] If the current block does not meet the sparse consensus conditions, a new block corresponding to the transaction data will be generated according to the block formation rules.

[0112] In one possible design, the decision module 402 is specifically used for:

[0113] Write the transaction data to the target block to obtain the current block;

[0114] Determine whether the current block conforms to the interval consensus strategy;

[0115] If so, determine that the current block meets the sparse consensus condition;

[0116] Among them, the interval consensus strategy includes a custom block interval or a fixed number of transactions.

[0117] In one possible design, the master node is elected during the previous consensus process.

[0118] In one possible design, the receiving module 401 is also used for:

[0119] If a consensus failure occurs during the consensus process, receive consensus failure information reported by each consensus node.

[0120] exist Figure 4 On this basis, Figure 5 This is a schematic diagram of another data processing apparatus provided in an embodiment of this application. Figure 5 As shown in the embodiment of this application, the data processing device 400 further includes a feedback module 404. If the transaction risk type corresponding to the transaction data is low-risk, the feedback module 404 is used to:

[0121] The first return result is sent back to the business end, so that the business end can obtain the first return result, which includes the block generation result.

[0122] In one possible design, if the transaction data corresponds to a high-risk transaction type, the feedback module 404 is also used for:

[0123] The second feedback result is sent back to the business end, so that the business end can obtain the second feedback result. The second feedback result includes the consensus completion result of each consensus node, which includes consensus failure or consensus success.

[0124] The data processing apparatus provided in this application embodiment can execute the corresponding steps of the data processing method in the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0125] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 500 may include a processor 501 and a memory 502 communicatively connected to the processor 501.

[0126] Memory 502 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0127] Memory 502 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0128] The processor 501 is used to execute computer execution instructions stored in the memory 502 to implement the above-described data processing method.

[0129] The processor 501 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0130] Optionally, the memory 502 can be either standalone or integrated with the processor 501. When the memory 502 is a device independent of the processor 501, the electronic device 500 may further include:

[0131] Bus 503 is used to connect processor 501 and memory 502. The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not mean there is only one bus or one type of bus.

[0132] Optionally, in a specific implementation, if the memory 502 and the processor 501 are integrated on a single chip, the memory 502 and the processor 501 can communicate through an internal interface.

[0133] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores computer-executable instructions, which are used in the methods described in the above embodiments.

[0134] This application also provides a computer program product, including computer execution instructions that, when executed by a processor, implement the methods described above.

[0135] 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 claims.

[0136] 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 processing method, characterized in that, The method, applied to master nodes in a consortium blockchain network, includes: Receive transaction data reported by the business side; Based on the transaction data, it is determined whether the current block meets the sparse consensus condition, which is set according to the interval consensus strategy. If so, initiate a consensus process to enable all consensus nodes to reach a consensus on the current block, and generate a new block corresponding to the transaction data according to the block formation rules after the consensus is completed; If the current block does not meet the sparse consensus condition, a new block corresponding to the transaction data is generated according to the block formation rules.

2. The data processing method according to claim 1, characterized in that, The step of determining whether the current block meets the sparse consensus condition based on the transaction data includes: Write the transaction data into the target block to obtain the current block; Determine whether the current block conforms to the interval consensus strategy; If so, determine that the current block satisfies the sparse consensus condition; The interval consensus strategy includes a custom block interval or a fixed number of transactions.

3. The data processing method according to any one of claims 1-2, characterized in that, The master node is elected in the previous consensus process.

4. The data processing method according to any one of claims 1-2, characterized in that, The method further includes: If a consensus failure occurs during the consensus process, the consensus failure information reported by each consensus node will be received.

5. The data processing method according to claim 1, characterized in that, If the transaction risk type corresponding to the transaction data is low-risk, after generating the new block corresponding to the transaction data according to the block formation rules, the method further includes: The first return result is sent back to the service terminal, so that the service terminal can obtain the first return result, which includes the block generation result.

6. The data processing method according to claim 1, characterized in that, If the transaction risk type corresponding to the transaction data is high-risk, after the consensus nodes have reached a consensus on the current block, the process further includes: The second feedback result is sent back to the service terminal, so that the service terminal can obtain the second feedback result. The second feedback result includes the consensus completion result of each consensus node, and the consensus completion result includes consensus failure or consensus success.

7. A data processing apparatus, characterized in that, include: The receiving module is used to receive transaction data reported by the business side; The judgment module is used to determine whether the current block meets the sparse consensus condition based on the transaction data. The sparse consensus condition is set according to the interval consensus strategy. The consensus and generation module is used to initiate a consensus process if it is determined that the current block meets the sparse consensus condition, so that each consensus node reaches a consensus on the current block, and generates a new block corresponding to the transaction data according to the block formation rules after the consensus is completed; if the current block does not meet the sparse consensus condition, it generates a new block corresponding to the transaction data according to the block formation rules.

8. 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 data processing method as described in any one of claims 1 to 6.

9. 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 data processing method as described in any one of claims 1 to 6.

Images