A blockchain-based data processing method, node device, system and platform

Abstract

An embodiment of the present application provides a data processing method, a node device, a system and a platform based on a blockchain. Among them, the method includes: if the transaction data to be consensus in this round of the consensus nodes of the blockchain exceeds the upper limit of the transaction data for a single consensus operation, then divide the transaction data to be consensus in this round into at least two transaction data groups to perform consensus operations in parallel, where the number of transaction data in each transaction data group is less than the upper limit of the transaction data for a single consensus operation. After all the transaction data groups to be consensus in this round reach consensus, the consensus node performs an execution operation on the transaction data to be consensus in this round, and performs a block writing operation on the transaction data execution result generated by the execution operation. The solution of the present application can improve the efficiency of the blockchain in processing transaction data and significantly improve the latency problem of blockchain services.

Description

Technical Field

[0001] This document relates to the field of data processing technologies, and in particular, to a data processing method, node device, system, and platform based on a blockchain. Background Art

[0002] With the development of information technology, the blockchain has been increasingly applied due to its advantages such as openness, immutability, and decentralization. Currently, the transaction data initiated by a blockchain client needs to be consensus-reached by each consensus node in the blockchain before it can be uploaded to the chain. When the transaction data to be consensus-reached exceeds the upper limit of the transaction data quantity for a single consensus operation by the consensus node, it needs to be carried out in multiple rounds. And each round has to go through a consensus process, which mainly includes steps such as the sending, receiving, verification, and parsing of consensus messages, thus consuming more resources and time and causing delays in blockchain services.

[0003] In view of this, there is an urgent need for a technical solution that can improve the efficiency of blockchain data processing. Summary of the Invention

[0004] The purpose of the embodiments of this application is to provide a data processing method, node device, system, and platform based on a blockchain, which can improve the processing efficiency of blockchain transaction data, thereby improving the problem of blockchain service delay.

[0005] To achieve the above purpose, the embodiments of this application are implemented as follows:

[0006] In a first aspect, a data processing method based on a blockchain is provided, including:

[0007] If the transaction data to be consensus-reached by the consensus nodes of the blockchain in this round exceeds the upper limit of the transaction data for a single consensus operation, then divide the transaction data to be consensus-reached in this round into at least two transaction data groups to perform consensus operations in parallel, where the quantity of transaction data in each transaction data group is less than the upper limit of the transaction data for a single consensus operation;

[0008] After all the transaction data groups to be consensus-reached in this round have reached consensus, perform an execution operation on the transaction data to be consensus-reached in this round, and perform a write-block operation on the transaction data execution result generated by the execution operation.

[0009] In a second aspect, a data processing method based on a blockchain is provided, including:

[0010] When the evidence data to be consensus-reached by the consensus nodes of the blockchain in this round exceeds the upper limit of the evidence data for a single consensus operation, divide the evidence data to be consensus-reached in this round into at least two evidence data groups to perform consensus operations in parallel, where the quantity of evidence data in each evidence data group is less than the upper limit of the evidence data for a single consensus operation;

[0011] After all the groups of evidence storage data to be consensus in this round reach consensus, the consensus node performs an execution operation on the evidence storage data to be consensus in this round, and performs a block writing operation on the execution result of the evidence storage data generated by the execution operation.

[0012] Thirdly, a node device of a blockchain is provided, including:

[0013] A transaction data consensus module, configured to divide the transaction data to be consensus in this round into at least two groups of transaction data for parallel consensus operations when the transaction data to be consensus in this round exceeds the upper limit of the transaction data for a single consensus operation, where the number of transaction data in each group of transaction data is less than the upper limit of the transaction data for a single consensus operation;

[0014] A transaction data execution and writing module, configured to perform an execution operation on the transaction data to be consensus in this round and perform a block writing operation on the execution result of the transaction data generated by the execution operation after all the groups of transaction data to be consensus in this round reach consensus.

[0015] Fourthly, a node device of a blockchain is provided, including:

[0016] An evidence storage data consensus module, configured to divide the evidence storage data to be consensus in this round into at least two groups of evidence storage data for parallel consensus operations when the evidence storage data to be consensus in this round exceeds the upper limit of the evidence storage data for a single consensus operation, where the number of evidence storage data in each group of evidence storage data is less than the upper limit of the evidence storage data for a single consensus operation;

[0017] An evidence storage data block writing module, configured to perform an execution operation on the evidence storage data to be consensus in this round and perform a block writing operation on the execution result of the evidence storage data generated by the execution operation after all the groups of evidence storage data to be consensus in this round reach consensus.

[0018] Fifthly, a blockchain system is provided, including the node device as described in the third aspect or the fourth aspect above.

[0019] Based on the solution of the embodiments of the present application, if the transaction data to be consensus by the consensus node in this round exceeds the upper limit of the transaction data for a single consensus operation, the transaction data to be consensus in this round is subdivided into at least two groups of transaction data for parallel consensus operations, so as to complete the consensus on the originally excessive transaction data in one round, and then enter the processes of execution operation and block writing operation faster. The whole solution improves the efficiency of the blockchain in processing transaction data and can significantly improve the latency problem of blockchain services. Description of the Drawings

[0020] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments described in the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0021] Figure 1 It is the first flow schematic diagram of the data processing method provided by the embodiment of the present application.

[0022] Figure 2 It is a comparison schematic diagram of the consensus operation performed by the data processing method provided by the embodiment of the present application and the consensus operation performed by the traditional method.

[0023] Figure 3 It is a timing relationship schematic diagram among the consensus operation, execution operation, and write block operation performed by the data processing method provided by the embodiment of the present application.

[0024] Figure 4 It is another timing relationship schematic diagram among the consensus operation, execution operation, and write block operation performed by the data processing method provided by the embodiment of the present application.

[0025] Figure 5 It is a schematic diagram of the blockchain structure exemplified after the data processing method provided by the embodiment of the present application generates a block.

[0026] Figure 6 It is a flow schematic diagram of the consensus operation performed by the data processing method provided by the embodiment of the present application.

[0027] Figure 7 It is the second flow schematic diagram of the data processing method provided by the embodiment of the present application.

[0028] Figure 8 It is a schematic diagram of data deposit evidence performed by the data processing method provided by the embodiment of the present application.

[0029] Figure 9 It is the first module structure schematic diagram of the node device provided by the embodiment of the present application.

[0030] Figure 10 It is the second module structure schematic diagram of the node device provided by the embodiment of the present application.

[0031] Figure 11 It is the module structure schematic diagram of the blockchain system provided by the embodiment of the present application.

[0032] Figure 12 It is the module structure schematic diagram of blockchain as a service provided by the embodiment of the present application.

[0033] Figure 13 It is a schematic diagram of the logical structure of blockchain as a service provided by an embodiment of the present application.

[0034] Figure 14 It is a schematic diagram of the module structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0035] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

[0036] As mentioned above, currently, transactions initiated by blockchain clients need to reach a consensus among each consensus node in the blockchain before they can be recorded on the chain. When the number of transactions to be consensus exceeds the upper limit of the number of transactions for a single consensus operation by the consensus nodes, it needs to be carried out in multiple rounds. And each round has to go through a consensus process, which mainly includes steps such as the sending, receiving, verification, and parsing of consensus messages, so it consumes more resources and time. When the transaction fails to reach a consensus and be executed for a long time, it will ultimately lead to delays in blockchain services. To address this issue, the present application aims to propose a technical solution that can improve the efficiency of blockchain transaction processing.

[0037] Figure 1 It is a flowchart of a data processing method based on blockchain in an embodiment of the present application, including:

[0038] S102, if the transaction data to be consensus by the consensus nodes of the blockchain in this round exceeds the upper limit of the transaction data for a single consensus operation, then perform the consensus operation on the transaction data to be consensus in this round in parallel in the form of at least two transaction data groups, where the number of transaction data in each transaction data group is less than the upper limit of the transaction data for a single consensus operation.

[0039] Specifically, the consensus nodes of the blockchain in the embodiments of the present application are divided into: a consensus primary node and a consensus backup node. Among them, the consensus primary node is responsible for initiating a consensus proposal for performing a consensus operation.

[0040] The consensus primary node selects the transaction data to be consensus in this round from its own transaction pool. If the transaction data to be consensus in this round exceeds the upper limit of the transaction data for a single consensus operation, the transaction data to be consensus in this round can be divided into at least two transaction data groups. Obviously, the number of transaction data groups depends on the number of transaction data to be consensus in this round. For example, if the upper limit of the transaction data for a single consensus operation is 50,000, and the transaction data to be consensus in this round is 140,000, then these 140,000 transaction data need to be subdivided into at least 3 transaction data groups.

[0041] After that, the consensus primary node initiates a consensus proposal for each transaction data group to be consensus in this round in parallel, so that the consensus backup nodes of the blockchain can also respond to the consensus proposal of the consensus primary node in parallel to perform the consensus operation on each transaction data group.

[0042] Still taking the upper limit of the transaction data for a single consensus operation being 50,000 and the transaction data to be consensus in this round being 140,000 as an example. Refer to Figure 2 , the traditional consensus scheme needs to perform 3 rounds of consensus operations (consensus operation 1, 2, 3) serially to complete the consensus on 140,000 transaction data, and the total time consumed is T1; the improved consensus scheme of this application only needs to perform the consensus operation on transaction data groups 1, 2, and 3 in parallel in 1 round to complete the consensus on 140,000 transaction data, and the total time consumed is T2. Among them, the difference ΔT between T2 and T1 is the time saved by the improved consensus scheme of this application compared with the traditional consensus scheme.

[0043] S104, after all the transaction data groups to be consensus in this round reach a consensus, the consensus node performs an execution operation on the transaction data to be consensus in this round, and performs a block writing operation on the transaction data execution result generated by the execution operation.

[0044] In practical applications, there may be associated transaction data between different transaction data groups. For example: Account A transfers 1 million digital currencies to Account C through Account B, then two associated transaction data are generated. The first transaction data is that Account A transfers 1 million digital currencies to Account B, and the second transaction data is that Account B transfers the 1 million digital currencies provided by Account A to Account C. If these two transaction data are in different transaction data groups, and the transaction data group of the first transaction data does not reach a consensus while the transaction data group of the second transaction data reaches a consensus, then only the execution operation will be initiated for the second transaction data, which will cause Account B to transfer its own digital currency to Account C without receiving the 1 million digital currencies provided by Account A (the transaction data is not executed), thus causing losses to Account B.

[0045] To avoid the above problems, the consensus node in the embodiment of the present application will only group the transaction data of this round after all the transaction data groups to be consensus in this round have reached a consensus. If any transaction data group to be consensus in this round fails to reach a consensus, the consensus node will directly reject the consensus proposals of all transaction data groups.

[0046] Further, after all the transaction data groups to be consensus in this round have reached a consensus, the consensus node in this step can, according to actual needs, choose to perform the execution operation on each transaction data group in parallel or in series.

[0047] If the blockchain business covers related transaction services that require ensuring the execution order of transactions, such as the example shown above: "Account A transfers 100,000 digital currencies to Account C through Account B", it is necessary to consider that if the two related transaction data are in different transaction data groups, once the execution operation is initiated on the transaction data in the transaction data groups in parallel, it may cause the execution order of the two transaction data to be incorrect, that is: first execute the transaction of Account B transferring 100,000 digital currencies to Account C, and then execute the transaction of Account A transferring 100,000 digital currencies to Account B, which will lead to the following problems:

[0048] If Account B does not reserve 100,000 digital currencies for advance payment to Account C, only the transaction data of Account A transferring 100,000 digital currencies to Account B can be successfully executed, and Account C does not receive any digital currencies.

[0049] Therefore, for blockchain services that require ensuring the execution order of transaction data, the serial method can be selected to perform the execution operation on the transaction data groups to be consensus in this round. That is, the transaction data groups to be consensus in this round are obtained by the consensus master node sorting the transaction data based on the transaction time and dividing the transaction data to be consensus in this round. After all the transaction data groups to be consensus in this round have reached a consensus, the consensus node first performs the execution operation on the transaction data group with an earlier transaction time sorting, and then performs the execution operation on the transaction data group with a later transaction time sorting.

[0050] To give a simple example, assume there are three transactions, namely Transaction 1, 2, and 3, where Transaction 1 has the earliest transaction time and Transaction 2 has the latest transaction time. Then Transaction 1 can be divided into Transaction Data Group 1, Transaction 3 can be divided into Transaction Data Group 2, and Transaction 2 can be divided into Transaction Data Group 3. When Transaction Data Groups 1, 2, and 3 all reach a consensus, the consensus node first performs the transaction execution operation on the transactions in Transaction Data Group 1 (including Transaction 1). After the transaction execution operation of Transaction Data Group 1 is completed, it then performs the transaction execution operation on the transactions in Transaction Data Group 2 (including Transaction 3). Finally, it performs the transaction execution operation on the transactions in Transaction Data Group 3 (including Transaction 2).

[0051] Obviously, through this design, it can be ensured that all the transactions to be consensus in this round can be executed in an orderly manner. It should be noted here that for the transaction data in the same transaction data group, the existing consensus nodes can select the transaction data for execution operations in the order from the earliest to the latest transaction time, and this will not be elaborated specifically here.

[0052] In addition, if the blockchain business mainly covers non-financial transaction services (such as data deposit services), or does not involve related transaction services that require ensuring the execution order of transaction data as shown in the above example of "Account A transfers 100,000 digital currencies to Account C through Account B", then from the perspective of improving execution efficiency, after all the transaction data groups to be consensus in this round reach consensus, the consensus nodes select a parallel method to perform execution operations on each transaction data group.

[0053] It should be understood that whether the consensus nodes perform execution operations on each transaction data group in parallel or serially, whenever the execution operation of a transaction data group is completed, the write-block operation can be immediately performed on the execution result of the transaction data for which the execution operation is completed.

[0054] For the convenience of understanding the timing relationship among the consensus operation → execution operation → write-block operation of each transaction data group, Figure 3 The timing of 3 transaction data groups performing execution operations in parallel after the consensus operation is completed, and the subsequent write-block operation is exemplified. Figure 4 The timing of 3 transaction data groups performing execution operations serially after the consensus operation is completed, and the subsequent write-block operation is exemplified. Among them:

[0055] Figure 3 The consensus nodes configure exclusive threads for each transaction data group to be consensus in this round to perform consensus operations, transaction execution operations, and write-block operations. Among them, Thread 1 is responsible for performing the consensus operation, execution operation of Transaction Data Group 1, and the write-block operation of the execution result of the transaction data corresponding to Transaction Data Group 1; Thread 2 is responsible for performing the consensus operation, execution operation of Transaction Data Group 2, and the write-block operation of the execution result of the transaction data corresponding to Transaction Data Group 2; Thread 3 is responsible for performing the consensus operation, execution operation of Transaction Data Group 3, and the write-block operation of the execution result of the transaction data corresponding to Transaction Data Group 3. That is, the relationship between the thread and the transaction data group is one-to-one.

[0056] Figure 4The consensus nodes configure exclusive consensus threads for each transaction data group to be consensus in this round for consensus operations, configure an execution thread for all transaction data groups to be consensus in this round for execution operations, and configure a block writing thread for all transaction data groups to be consensus in this round to perform block writing operations on the execution results of the transaction data. It should be noted here that usually the time consumption of the block writing operation is shorter than that of the execution operation (the execution operation involves the steps of mutual verification of the execution results of transaction data between consensus nodes and requires interaction of the execution results of transaction data). Therefore, in the case where the execution operations are performed serially, there is no need for parallel execution of the block writing operation. Therefore, only one block writing operation thread can be configured for all transaction data groups to achieve serial work. Among them, transaction data groups 1, 2, and 3 correspond one-to-one with consensus operation threads 1, 2, and 3, and consensus operation threads 1, 2, and 3 perform consensus operations on transaction data groups 1, 2, and 3 in parallel; transaction data groups 1, 2, and 3 only correspond to one execution operation thread 1. This execution operation thread 1 first performs an execution operation on transaction data group 1, then performs an execution operation on transaction data group 2, and finally performs an execution operation on transaction data group 3; transaction data groups 1, 2, and 3 only correspond to one block writing operation thread 1. This block writing operation thread 1 first performs a block writing operation on the execution result of the transaction data in transaction data group 1, then performs a block writing operation on the execution result of the transaction data in transaction data group 2, and finally performs a block writing operation on the execution result of the transaction data in transaction data group 3.

[0057] In addition, since the embodiments of the present application perform consensus operations in parallel with the granularity of transaction data groups, each transaction data group will correspondingly generate a block to be written into the blockchain. To avoid the blockchain branching out different branches, that is, the blockchain fork phenomenon, after the block writing operation is completed, the blocks of each transaction data group in the present application embodiment can have the same block height, and the block hash value of the previous block height recorded in the block header is obtained by combining the block hash values of all blocks of the previous block height.

[0058] As an exemplary introduction, Figure 5 is a blockchain with a depth of 4 blocks generated based on the method of the embodiments of the present application. Based on Figure 5It can be known that the block depth 2 uses two transaction data groups to perform consensus in parallel, so two regions are finally written, namely block 2.1 and block 2.2. In block depth 3, three transaction data groups are used to perform consensus in parallel, and correspondingly, blocks 3.1, 3.2, and 3.3 are written. Taking block depth 3 as an example, blocks 3.1, 3.2, and 3.3 share a block depth 3. Therefore, the block 4 at block depth 4 later will reference all the blocks at the previous block height 3, that is, the block header of block 4 records the block hashes of the previous block height 3, including the block hashes of these three blocks: block 3.1, block 3.2, and block 3.3. Similarly, the block headers of blocks 3.1, 3.2, and 3.3 respectively record the block hashes of the previous block height 2, including the block hashes of these two blocks: block 2.1 and block 2.3. That is, the block hashes of the previous block height referenced by the later block height are composed of the block hashes of all the blocks at the previous block height. Through Figure 3 The design shown in the example, block 2 is composed of blocks 2.1 and 2.2, and block 3 is composed of blocks 3.1, 3.2, and 3.3. Therefore, there is only one topological link from block 1 to block 4, that is: block 1 → block 2 (blocks 2.1, 2.2) → block 3 (blocks 3.1, 3.2, 3.3) → block 4, avoiding the fork of the blockchain.

[0059] Similarly, in the consensus proposals initiated in parallel by the consensus main node of the blockchain for each transaction data group to be consensus in this round, the block hashes of all the blocks at the current local highest block height also need to be carried. In this way, during the consensus operation process, the consensus backup node can verify the block height of the transaction data group corresponding to the consensus proposal according to the block hashes of all the blocks at the consensus main node's local highest block height.

[0060] Next, combined with the actual application scenario, the method of performing simultaneous operations in parallel with the transaction data group as the granularity in the embodiments of the present application will be introduced in detail.

[0061] In this application scenario, the consensus protocol of the blockchain adopts the Practical Byzantine Fault Tolerance (PBFT) consensus protocol. By default, the consensus node (consensus) uses a single thread to execute the consensus proposal. When the transaction data to be consensus in this round exceeds the transaction limit of a single consensus operation, the transaction data to be consensus in this round is divided into at least two transaction data groups, and the number of transaction data in each transaction data group is less than the transaction limit of a single consensus operation, and a dedicated thread is started for each transaction data group to perform the consensus operation.

[0062] Among them, the consensus process that requires dividing the transaction data group includes:

[0063] Step 1: The consensus master node of the blockchain first selects the unconsensused transaction data from its own transaction pool as the transaction data to be agreed upon in this round. The unconsensused transaction data selected by the consensus master node can be all the unconsensused transaction data in its own transaction pool, or part of the unconsensused transaction data in its own transaction pool, which is not specifically limited in this article.

[0064] Step 2: The blockchain consensus master node groups the transaction data to be agreed upon in this round.

[0065] Here, assuming that the blockchain business in this application scenario has no requirements on the execution order of transaction data, the consensus master node of the blockchain can first determine the number of transaction data groups to be divided based on the number of transaction data to be agreed upon in this round. For example, if the upper limit of transaction data for a single consensus operation is 50,000, and there are 140,000 transaction data to be agreed upon in this round, the number of transaction data groups is 3.

[0066] Afterwards, the consensus master node performs a modulo operation on the transaction data identifier of each transaction data to be agreed upon in this round and the number of groups to obtain the modulus corresponding to each transaction data, and divides the transaction data into transaction data groups based on the modulus grouping rule corresponding to the number of groups.

[0067] For example, the modulus of transaction data group 1 is set to 0-2, the modulus of transaction data group 2 is set to 3-5, and the modulus of transaction data group 3 is set to 6-9. Through modulus operation, the transactions to be agreed in this round can be divided into 3 transaction data groups. If the transaction data in one of the transaction data groups reaches the upper limit, no new transaction data will be added to it.

[0068] Afterwards, the consensus master node numbers the divided transaction data groups, with the minimum number being 0 and the maximum number being n-1, where n-1 is the number of transaction data groups, that is, the number of threads performing consensus operations.

[0069] Step 3: The consensus master node initiates a consensus proposal for consensus operations on each transaction data group in parallel. The consensus master node and consensus backup node of the blockchain begin to execute the consensus operation of the PBFT protocol on each transaction data group in parallel.

[0070] Here, we take one of the target transaction data groups as an example. The process of PBFT protocol consensus operation is as follows: Figure 6 As shown, including:

[0071] Pre-prepare stage:

[0072] The consensus master node of the blockchain packs the proposal number (Sequence n), view value (View v), transaction data hash list, etc. of the target transaction data grouping, as well as the hashes of all blocks at the previous highest block height, into a pre-prepare message, signs it, and broadcasts the signed pre-prepare message to each consensus backup node in the blockchain. Among them, the hashes of all blocks at the previous highest block height are used to check whether the block depth of the target transaction data grouping is correct during the prepare process.

[0073] Prepare stage:

[0074] After receiving the pre-prepare message, the target consensus backup node of the blockchain (the target consensus backup node represents any consensus backup node) first checks the Sequence: n, View: v in the pre-prepare message, and the hashes of all blocks at the previous highest block height.

[0075] If the check fails, the consensus proposal for all transaction data groupings in this round is rejected. That is, if the target transaction data grouping fails to pass the check, it will lead to the failure of the consensus proposal for all transaction data groupings in this round.

[0076] If the check passes, it means that the consensus proposal for the target transaction data grouping initiated by the consensus master node is recognized in the prepare stage, and the following steps are further executed.

[0077] Based on the transaction hashes of the transactions in the transaction data hash list in the prepare stage, the target consensus backup node matches the same transaction data from the transaction pool of the target consensus backup node. Specifically, in this matching process, the target consensus backup node can respectively reverse calculate the transaction data hashes in the transaction data hash list based on the transaction hash calculation logic jointly agreed upon by each consensus node to obtain the digest information of each transaction data; then, the target consensus backup node searches its own transaction pool based on the digest information of each transaction data to match the same transaction data from the transaction pool.

[0078] After the target consensus backup node matches the same transactions from the transaction pool of the target consensus backup node, it further extracts these transaction data from the transaction pool. Then, the target consensus backup node performs a consensus check on these transaction data based on the consensus check rules (such as Merkle tree check).

[0079] If the consensus verification passes, the target consensus backup node enters the prepare phase, determines the state on its own consensus as prepared, adds the pre-prepare message to the local Log, and sends the prepare message to other consensus nodes.

[0080] Commit phase:

[0081] After each of all consensus nodes enters the prepared state, it sends a commit message to other consensus nodes and adds the commit message it sends to the local Log (representing its own approval). When a consensus node finds that a quorum (a quorum is a set of a certain number of consensuses required to ensure all consensus data consistency requirements and fault tolerance requirements) agrees to the allocation of number n, it broadcasts a commit message to all other consensus nodes. At the same time, it will also successively receive commit messages from other consensus nodes. If a certain consensus node receives 2f + 1 (f is the number of consensus nodes that the blockchain supports for fault tolerance) commit messages (including its own one, and these commits from different nodes carry the same number: n and view: v), it means that the consensus node has a certificate named committedcertificate, and the consensus proposal reaches the committed state on this consensus node. At this time, only through this one consensus node, it can be determined that the request has reached the prepared state in a quorum, that is, all consensus nodes in the same quorum have agreed to the allocation of number n. When the consensus node is in the committed state, it means that the consensus proposal for the target transaction data packet is reached.

[0082] The above is only an exemplary introduction to the consensus process of one target transaction data packet using the PBFT protocol. On the basis of not departing from the above principles of this article, other consensus protocols can also be used for consensus operations, and these changes should also be regarded as the protection scope of the embodiments of this application.

[0083] In addition, it should also be understood that blockchain services are initiated by clients through blockchain exchanges. Blockchain services are not limited to digital currency services, but can also be data storage and certification services. The transaction data described in this article should represent the data that the client needs to store and certify in the data storage and certification service. The following is an exemplary introduction to the data storage and certification service.

[0084] Figure 7 The following is the process of implementing data storage and certification based on the blockchain data processing method of the embodiments of this application, including:

[0085] S702. If the evidence storage data to be consensus in this round by the consensus nodes of the blockchain exceeds the upper limit of the evidence storage data for a single consensus operation, then divide the evidence storage data to be consensus in this round into at least two evidence storage data groups for parallel consensus operations. Among them, the quantity of the evidence storage data in each evidence storage data group is less than the upper limit of the evidence storage data for a single consensus operation.

[0086] S704. After all the evidence storage data groups to be consensus in this round by the consensus nodes reach consensus, perform an execution operation on the evidence storage data to be consensus in this round, and perform a node device on the result of the evidence storage data generated by the execution operation.

[0087] Based on Figure 7 The method shown. If the evidence storage data to be consensus in this round by the consensus nodes exceeds the upper limit of the evidence storage for a single consensus operation, then subdivide the evidence storage data to be consensus in this round into at least two evidence storage data groups for parallel consensus operations, so as to complete the consensus on the originally excessive evidence storage data in one round, and then enter the process of the execution operation and the block writing operation faster. The whole scheme can significantly improve the efficiency of the blockchain for evidence storage of data.

[0088] Figure 8 It is a schematic diagram of the data evidence storage service in the actual application scenario. The blockchain can provide the data evidence storage service to users through the data evidence storage APP of the client.

[0089] Here, it is assumed that the blockchain is set with four consensus nodes, namely node1, 2, 3, and 4. The target user accesses node2 in the blockchain through the data evidence storage APP.

[0090] At this time, the target user needs to use the data evidence storage APP to initiate a data evidence storage request to node2, and the data evidence storage request carries the evidence storage data that the target user expects to be on the chain.

[0091] After receiving the data evidence storage request, node2 adds the evidence storage data that the target user expects to be on the chain to the local transaction pool for waiting for consensus. When node2 becomes the consensus primary node in this round of the blockchain, group all the evidence storage data (including the evidence storage data of the target user) in the local transaction pool to obtain each evidence storage data group. Then, node2 initiates a consensus proposal for each evidence storage data group in parallel, that is, sends the consensus proposal of each evidence storage data group to node1, 3, and 4 of the blockchain in a broadcast manner.

[0092] After that, all nodes perform corresponding consensus operations on the consensus proposals of each archived data packet initiated by node2 in this round. After all archived data packets reach consensus, all nodes perform execution operations on the archived data to be consensus in this round. For example, perform equipment work related to writing blocks such as summarizing and encoding all archived data in this round, and perform block writing operations on the execution results of the archived data generated by the execution operations. That is, nodes 1, 2, 3, and 4 add blocks recording all archived data (including the archived data of the target user) initiated by node2 in this round on their respective blockchain links, and the data archiving process of the target user ends.

[0093] In addition, an embodiment of the present application further provides a node device of a blockchain, as Figure 1 the execution subject of the method shown. Figure 9 is a schematic structural diagram of the node device 900 of the blockchain, including:

[0094] A transaction data consensus module 910, configured to divide the transaction data to be consensus in this round into at least two transaction data packets for parallel consensus operations if the transaction data to be consensus in this round exceeds the transaction data upper limit of a single consensus operation, where the number of transaction data in each transaction data packet is less than the transaction data upper limit of a single consensus operation.

[0095] A transaction data execution and writing module 920, configured to perform execution operations on the transaction data to be consensus in this round and perform block writing operations on the execution results of the transaction data generated by the execution operations after all transaction data packets to be consensus in this round reach consensus.

[0096] Based on the node device of the embodiment of the present application, when the transaction data to be consensus in this round exceeds the transaction data upper limit of a single consensus operation, the transaction data to be consensus in this round is subdivided into at least two transaction data packets for parallel consensus operations, so as to complete the consensus on the originally excessive transaction data in one round, and then enter the execution operation and block writing operation processes faster. The entire solution improves the efficiency of the blockchain in processing transaction data and can significantly improve the latency problem of blockchain services.

[0097] Optionally, the node device of the embodiment of the present application further includes:

[0098] A transaction data packet module, configured to divide the transaction data to be consensus in this round into at least two transaction data packets before performing parallel consensus operations on the transaction data to be consensus in this round in the form of at least two transaction data packets if the consensus node to which it belongs is the consensus master node of the blockchain; and a proposal initiation module, which parallelly initiates consensus proposals for performing consensus operations on each transaction data packet to be consensus in this round.

[0099] Among them, the transaction data grouping module can determine the number of groups for dividing the transaction data groups based on the number of transaction data to be consensus in this round; then, perform a modulo operation on the transaction identifiers of each transaction data to be consensus in this round and the number of groups to obtain the modulus corresponding to each transaction data; and divide the transaction data to be consensus in this round into the transaction data groups of the number of groups according to the pre-set modulus grouping rule. Alternatively, the transaction data grouping module can also divide the transaction data to be consensus in this round based on the transaction time sorting.

[0100] Optionally, the consensus proposal corresponding to each transaction data group contains the block hash value of the highest block height of the consensus master node locally. Among them, if the consensus node to which the transaction data consensus module 910 belongs is the co-backup node of the blockchain, during the consensus operation, the block height of the transaction data group corresponding to the consensus proposal can be verified based on the block hash value of the highest block height of the consensus master node locally in the consensus proposal.

[0101] Optionally, each transaction data group to be consensus in this round corresponds to its own block after the write block operation is completed. The block heights of the respective blocks of each transaction data group are the same, and the block hash value of the previous block height recorded in the block header is obtained by combining the block hash values of all blocks of the previous block height.

[0102] Optionally, after all the transaction data groups to be consensus in this round reach consensus, the transaction data execution writing module 920 performs an execution operation on each transaction data group in parallel, and after each execution operation of a transaction data group is completed, a write block operation is performed on the execution result of the transaction data of the execution operation.

[0103] Or the transaction data groups to be consensus in this round are divided by the consensus master node of the blockchain based on the transaction time sorting for the transactions to be consensus in this round. After all the transaction data groups to be consensus in this round reach consensus, the transaction data execution writing module 920 performs an execution operation on each transaction data group serially, where the transaction data group with an earlier transaction time sorting is executed earlier than the transaction data group with a later transaction time sorting, and after each execution operation of a transaction data group is completed, a write block operation is performed on the execution result of the transaction data generated by the transaction execution.

[0104] Optionally, the transaction consensus module 910 starts a dedicated thread for each transaction data group to perform the consensus operation.

[0105] Obviously, the node device in the embodiment of the present application can be used as the execution subject of the data processing method shown above Figure 1 and thus can implement the functions achieved by the data processing method in Figure 1 Since the principle is the same, it will not be elaborated here.

[0106] In addition, an embodiment of the present application further provides a node device of a blockchain, which serves as Figure 7 the execution subject of the method shown. Figure 10 is a schematic structural diagram of the node device 1000 of the blockchain, including:

[0107] The evidence storage data consensus module 1010 is configured to, if the evidence storage data to be consensus in this round exceeds the upper limit of the evidence storage data for a single consensus operation, divide the evidence storage data to be consensus in this round into at least two evidence storage data groups to perform consensus operations in parallel, where the quantity of the evidence storage data in each evidence storage data group is less than the upper limit of the evidence storage data for a single consensus operation.

[0108] The evidence storage data execution and writing module 1020 is configured to, after all the evidence storage data groups to be consensus in this round reach consensus, perform an execution operation on the evidence storage data to be consensus in this round, and perform a block writing operation on the evidence storage data execution result generated by the execution operation.

[0109] When the evidence storage data to be consensus in this round of the node device in the embodiment of the present application exceeds the upper limit of the evidence storage for a single consensus operation, the evidence storage data to be consensus in this round is subdivided into at least two evidence storage data groups to perform consensus operations in parallel, so as to complete the consensus on the originally excessive evidence storage data in one round, and then enter the processes of the execution operation and the block writing operation faster. The entire solution can significantly improve the efficiency of the blockchain in storing evidence for data.

[0110] Optionally, the node device in the embodiment of the present application further includes:

[0111] The evidence storage data grouping module is configured to, if the consensus node to which it belongs serves as the consensus master node of the blockchain, divide the evidence storage data to be consensus in this round into at least two evidence storage data groups before performing consensus operations on the evidence storage data to be consensus in this round in the form of at least two evidence storage data groups; and, the proposal initiation module initiates a consensus proposal for performing a consensus operation on each evidence storage data group to be consensus in this round in parallel.

[0112] Among them, the evidence storage data grouping module can determine the number of groups for dividing the evidence storage data groups based on the quantity of the evidence storage data to be consensus in this round; then, perform a modulo operation on the evidence storage identifiers of each piece of evidence storage data to be consensus in this round and the number of groups to obtain the modulus corresponding to each piece of evidence storage data; and divide the evidence storage data to be consensus in this round into the number of evidence storage data groups according to the preset modulus grouping rule.

[0113] Optionally, the consensus proposal corresponding to each evidence preservation data packet includes the block hash value of the highest block height of the consensus master node locally. Wherein, if the consensus node to which the evidence preservation data consensus module 1010 belongs is a co-backup node of the blockchain, during the consensus operation, the block height of the evidence preservation data packet corresponding to the consensus proposal can be verified based on the block hash value of the highest block height of the consensus master node locally in the consensus proposal.

[0114] Optionally, each evidence preservation data packet to be consensus in this round corresponds to its own block after the write-block operation. The block heights of the blocks of each evidence preservation data packet are the same, and the block hash value of the previous block height recorded in the block header is obtained by combining the block hash values of all blocks of the previous block height.

[0115] Optionally, after all the transaction data packets to be consensus in this round reach consensus, the transaction data execution writing module 1020 performs execution operations on each evidence preservation data packet in parallel, and after each execution operation of an evidence preservation data packet is completed, a write-block operation is performed on the evidence preservation data execution result generated by the execution operation.

[0116] Obviously, the node device in the embodiment of the present application Figure 10 can be used as the execution subject of the above-mentioned Figure 7 shown data processing method, and thus can implement the functions realized by the data processing method in Figure 7 . Since the principle is the same, it will not be elaborated here.

[0117] In addition, as Figure 11 shown, the embodiment of the present application also provides a blockchain system 1100, and the blockchain system 1100 includes a plurality of node devices 1100.

[0118] Wherein, the node device 1100 of the blockchain system 1100 can be Figure 9 shown node device, and when the transaction data to be consensus in this round exceeds the transaction data upper limit of a single consensus operation, the transaction data to be consensus in this round can be consensus-operated in parallel in the form of at least two transaction data packets, wherein the number of transaction data of each transaction data packet is less than the transaction data upper limit of a single consensus operation; and after all the transaction data packets to be consensus in this round reach consensus, a write-block operation is performed on the transaction data to be consensus in this round and the transaction data execution result generated by the execution operation.

[0119] Or, the node device 1100 of the blockchain system 1100 is Figure 10The node device shown can, when the evidence storage data to be consensus in this round exceeds the upper limit of the evidence storage data for a single consensus operation, divide the evidence storage data to be consensus in this round into at least two evidence storage data groups to perform consensus operations in parallel, where the quantity of the evidence storage data in each evidence storage data group is less than the upper limit of the evidence storage data for a single consensus operation; and, after all the evidence storage data groups to be consensus in this round reach consensus, perform an execution operation on the evidence storage data to be consensus in this round, and perform a block writing operation on the evidence storage data execution result generated by the execution operation.

[0120] In addition, as Figure 12 shown, an embodiment of the present application further provides a blockchain as a service platform 1200, including: a service interface 1210 for receiving requests from platform clients for blockchain services, and a blockchain system 1220. Among them, the blockchain system 1220 of the blockchain as a service platform 1200 is specifically Figure 11 the blockchain system shown, and the blockchain services corresponding to the blockchain system 1220 may include digital currency services and / or data evidence storage services.

[0121] Figure 13 is the logical structure diagram of the blockchain as a service platform 1200 in an embodiment of the present application, including an interface layer, a management layer, a chain core layer, an interconnection core layer, and a basic layer. Among them:

[0122] The interface layer is configured with different types of service interfaces and an interactive console. The service interfaces include remote procedure call (RPC) protocol interfaces, software development tool (SDK) interfaces, etc. The interactive console interacts with the client through the service interfaces for blockchain service messages, for example: receiving client evidence storage data requests, query data requests, and feeding back evidence storage results and query results to the client, etc.

[0123] The management layer is configured with various management functions for the blockchain system, such as access management (managing the permissions for clients to access the blockchain), consensus management (managing the consensus configuration of the blockchain, such as consensus timeout time, view time, etc.), permission management (managing the open permissions of blocks in the blockchain), parameter management (managing the configuration parameters of the blockchain), etc.

[0124] The chain core layer and the interconnection core layer belong to the functional layer of the blockchain system. The chain core layer is configured with an execution engine for blocks / transactions of the blockchain system, and a distributed storage driver, etc. The interconnection core layer is configured with a consensus protocol (PBFT protocol) and a distributed consistency protocol (RAFT protocol) of the blockchain system. The PBFT protocol in the embodiment of the present application can control the consensus nodes of the blockchain system to implement parallel consensus operations at the granularity of groups.

[0125] The basic layer is provided with underlying algorithms and source codes for supporting the blockchain system to implement digital currency services and data deposit services. For example: cryptographic algorithms, privacy algorithms, etc. used for consensus operations in the blockchain system, database drivers of node devices, BOOST basic libraries, etc.

[0126] Figure 14 It is a schematic structural diagram of an electronic device according to an embodiment of this specification. Please refer to Figure 14 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory, such as at least one disk memory, etc. Of course, the electronic device may also include hardware required for other services.

[0127] The processor, network interface, and memory can be interconnected through an internal bus, and the internal bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 14 only a bidirectional arrow is used in

[0128] The memory is used to store programs. Specifically, the program may include program codes, and the program codes include computer operation instructions. The memory may include a memory and a non-volatile memory, and provide instructions and data to the processor.

[0129] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming the node device of the above blockchain at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0130] When the transaction data to be consensus in this round exceeds the upper limit of the transaction data for a single consensus operation, divide the transaction data to be consensus in this round into at least two transaction data groups for parallel consensus operations, where the number of transaction data in each transaction data group is less than the upper limit of the transaction data for a single consensus operation.

[0131] After all the transaction data groups to be consensus in this round reach consensus, perform execution operations on the transaction data to be consensus in this round, and perform block writing operations on the execution results of the transaction data generated by the execution operations.

[0132] Alternatively, a processor executes the program stored in the memory and is specifically configured to perform the following operations:

[0133] When the evidence data to be consensus in this round exceeds the upper limit of the evidence data for a single consensus operation, divide the evidence data to be consensus in this round into at least two evidence data groups to perform consensus operations in parallel, where the amount of evidence data in each evidence data group is less than the upper limit of the evidence data for a single consensus operation;

[0134] After all the evidence data groups to be consensus in this round reach consensus, perform execution operations on the evidence data to be consensus in this round, and perform block writing operations on the execution results of the evidence data generated by the execution operations.

[0135] The methods disclosed in the above embodiments of this specification Figure 1 or Figure 7 can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor or by instructions in the form of software. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed by the hardware decoding processor, or executed by a combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0136] It should be understood that the electronic device according to the embodiments of the present application can implement Figure 1 or Figure 7 the functions of the embodiments shown, which will not be elaborated herein.

[0137] Of course, in addition to the software implementation, the electronic device described in this specification does not exclude other implementation manners, such as logical devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logical unit, and can also be hardware or logical devices.

[0138] In addition, the embodiments of the present application also propose a computer-readable storage medium, which stores one or more programs, and the one or more programs include instructions.

[0139] Wherein, when the above instructions are executed by a portable electronic device including multiple application programs, the portable electronic device can be enabled to execute Figure 1 the methods of the embodiments shown, and specifically used to execute the following methods:

[0140] When the transaction data to be consensus in this round exceeds the upper limit of the transaction data for a single consensus operation, divide the transaction data to be consensus in this round into at least two transaction data groups to perform consensus operations in parallel, where the number of transaction data in each transaction data group is less than the upper limit of the transaction data for a single consensus operation.

[0141] After all the transaction data groups to be consensus in this round have reached consensus, perform an execution operation on the transaction data to be consensus in this round, and perform a block writing operation on the execution result of the transaction data generated by the execution operation.

[0142] Or, when the above instructions are executed by a portable electronic device including multiple application programs, the portable electronic device can be enabled to execute Figure 7 the methods of the embodiments shown, and specifically used to execute the following methods:

[0143] When the evidence storage data to be consensus in this round exceeds the upper limit of the evidence storage data for a single consensus operation, divide the evidence storage data to be consensus in this round into at least two evidence storage data groups to perform consensus operations in parallel, where the number of evidence storage data in each evidence storage data group is less than the upper limit of the evidence storage data for a single consensus operation.

[0144] After all the evidence storage data groups to be consensus in this round have reached consensus, perform an execution operation on the evidence storage data to be consensus in this round, and perform a block writing operation on the execution result of the evidence storage data generated by the execution operation.

[0145] It should be understood that when the above instructions are executed by a portable electronic device including multiple application programs, the blockchain consensus device described above can be enabled to implementFigure 1 and Figure 2 The functions of the embodiments shown are not described herein again.

[0146] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system or a computer program product. Therefore, this specification can take the form of an all-hardware embodiment, an all-software embodiment or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0148] The above are only the embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this document.

Claims

1. A data processing method based on blockchain, characterized in that Including: If the consensus nodes of the blockchain have transaction data to be consensus in this round exceeding the upper limit of transaction data for a single consensus operation, then divide the transaction data to be consensus in this round into at least two transaction data groups for parallel consensus operations, where the number of transaction data in each transaction data group is less than the upper limit of transaction data for a single consensus operation; After all the transaction data groups to be consensus in this round have reached consensus, the consensus nodes perform an execution operation on the transaction data to be consensus in this round, and perform a block writing operation on the transaction data execution result generated by the execution operation. All the transaction data groups to be consensus in this round correspond to the same consensus proposal.

2. The method according to claim 1, wherein: If the consensus node is the consensus primary node of the blockchain, then before dividing the transaction data to be consensus in this round into at least two transaction data groups for parallel consensus operations, the method further includes: The consensus node divides the transaction data to be consensus in this round into at least two transaction data groups; And, The consensus node parallelly initiates a consensus proposal for performing a consensus operation on each transaction data group to be consensus in this round.

3. The method according to claim 2, wherein The consensus node dividing the transaction data to be consensus in this round into at least two transaction data groups includes: The consensus node determines the number of groups for dividing the transaction data groups according to the number of transaction data to be consensus in this round; The consensus primary node performs a modulo operation on the transaction data identifier of the transaction data to be consensus in this round and the number of groups, to obtain the modulus corresponding to each transaction data to be consensus in this round; The consensus primary node divides the transaction data to be consensus in this round into the number of transaction data groups according to the pre-set modulus grouping rule.

4. The method according to claim 3, wherein: The consensus proposal corresponding to each transaction data group includes the block hash value of the highest block height locally at the consensus primary node, so as to verify the block height of the transaction data group during the consensus operation.

5. The method according to any one of claims 1 to 4, wherein: Each transaction data group to be consensus in this round corresponds to its own block after the block writing operation is completed. The block heights of the blocks corresponding to each transaction data group are the same, and the block hash value of the previous block height recorded in the block header is obtained by combining the block hash values of all the blocks of the previous block height.

6. The method according to any one of claims 1 to 4, wherein: The consensus node performing an execution operation on the transaction data to be consensus in this round and performing a block writing operation on the transaction data execution result generated by the execution operation after all the transaction data groups to be consensus in this round have reached consensus includes: After all the transaction data groups to be consensus in this round have reached consensus, the consensus node parallelly performs an execution operation on each transaction data group, and after each execution operation of a transaction data group is completed, performs a block writing operation on the transaction data execution result generated by the execution operation.

7. The method according to claim 6, wherein: The consensus node configures an exclusive thread for each transaction data packet to be consensus in this round to perform consensus operations, execution operations, and block writing operations.

8. The method according to any one of claims 1 to 4, wherein: The transaction data packets to be consensus in this round are obtained by the consensus master node of the blockchain based on the time sorting of the transaction data and dividing the transaction data to be consensus in this round; After all the transaction data packets to be consensus in this round reach consensus, the consensus node performs execution operations on the transaction data to be consensus in this round, and performs block writing operations on the transaction data execution results generated by the execution operations, including: After all the transaction data packets to be consensus in this round reach consensus, the consensus node serially performs execution operations on each transaction data packet, wherein the transaction data packet with an earlier time sorting of the transaction data is prior to the transaction data packet with a later time sorting of the transaction data in performing the execution operation, and after each transaction data packet's execution operation is completed, a block writing operation is performed on the transaction data execution result generated by the execution operation.

9. The method according to claim 8, wherein: The consensus node configures an exclusive consensus thread for each transaction data packet to be consensus in this round to perform consensus operations, configures one execution thread for all the transaction data packets to be consensus in this round to perform execution operations, and configures one block writing thread for all the transaction data packets to be consensus in this round to perform block writing operations.

10. A data processing method based on blockchain, characterized in that, Including: If the evidence data to be consensus in this round by the consensus node of the blockchain exceeds the upper limit of the evidence data for a single consensus operation, the evidence data to be consensus in this round is divided into at least two evidence data packets to perform consensus operations in parallel, wherein the amount of evidence data in each evidence data packet is less than the upper limit of the evidence data for a single consensus operation; After all the evidence data packets to be consensus in this round reach consensus, the consensus node performs execution operations on the evidence data to be consensus in this round, and performs block writing operations on the evidence data execution results generated by the execution operations, and all the transaction data packets to be consensus in this round correspond to the same consensus proposal.

11. A node device of a blockchain, characterized in that, Including: A transaction data consensus module, configured to divide the transaction data to be consensus in this round into at least two transaction data packets to perform consensus operations in parallel if the transaction data to be consensus in this round exceeds the upper limit of the transaction data for a single consensus operation, wherein the amount of transaction data in each transaction data packet is less than the upper limit of the transaction data for a single consensus operation; A transaction data execution and writing module, configured to perform execution operations on the transaction data to be consensus in this round and perform block writing operations on the transaction data execution results generated by the execution operations after all the transaction data packets to be consensus in this round reach consensus, and all the transaction data packets to be consensus in this round correspond to the same consensus proposal.

12. A node device of a blockchain, characterized in that, Including: The evidence-preserving data consensus module, if the evidence-preserving data to be consensus in this round exceeds the upper limit of the evidence-preserving data for a single consensus operation, divides the evidence-preserving data to be consensus in this round into at least two evidence-preserving data groups to perform the consensus operation in parallel, wherein the number of evidence-preserving data in each evidence-preserving data group is less than the upper limit of the evidence-preserving data for a single consensus operation; The evidence-preserving data write block module, after all the evidence-preserving data groups to be consensus in this round reach consensus, performs an execution operation on the evidence-preserving data to be consensus in this round, and performs a write block operation on the evidence-preserving data execution result generated by the execution operation. All the transaction data groups to be consensus in this round correspond to the same consensus proposal.

13. A blockchain system, characterized in that, It includes the node device as described in claim 11 or 12.

14. A blockchain as a service platform, characterized in that, It includes: A service interface for receiving requests from the platform client for blockchain services, and the blockchain system as described in claim 13, where the blockchain services include digital currency services and / or data evidence-preserving services.

Images