Data processing method based on block chain, block chain node and storage medium

Abstract

The invention relates to a data processing method of a block chain, a block chain node, a storage medium and a computer program product. The method is executed by a block chain node, the block chain node is realized through a device cluster, distributed micro-services are deployed in the block chain node, and the micro-services are independently deployed on different devices. The micro service at least comprises a transaction pool service, a consensus service and a storage service; the method comprises the steps that the transaction pool service obtains transaction data and triggers verification of the transaction data, and after the transaction data passes the verification, the transaction data is put into a preset queue; under the condition that the block chain node is a main node, the consensus service obtains transaction data to be subjected to consensus from a preset queue to generate a consensus message, and broadcasts the consensus message to trigger a consensus operation; and the storage service receives a new block generated after the consensus passes, and performs block falling processing based on the new block. By adopting the method, the data processing efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain-based data processing method, blockchain node, storage medium, and computer program product. Background Art

[0002] With the development of computer technology, blockchain has received more and more attention and application due to its characteristics such as decentralization, information immutability and autonomy.

[0003] Traditional blockchain services are deployed in a node-based manner, that is, each node in the blockchain is a server. On each server, multiple functional modules of the node need to be deployed, such as the transaction pool module, AC module (access control, verification module), consensus module, synchronization module, and storage module. These functional modules are deployed on the same server, and each functional module shares resources such as memory, CPU (Central Processing Unit), and disk IO (Input / Output).

[0004] In the traditional blockchain data processing process, it is often the case that each functional module processes its corresponding logic at the same time. At this time, each functional module occupies server resources concurrently, which greatly affects the data processing efficiency of the blockchain. Summary of the invention

[0005] Based on this, it is necessary to provide a blockchain-based data processing method, blockchain node, computer-readable storage medium and computer program product that can improve the data processing efficiency of blockchain in response to the above technical problems.

[0006] In the first aspect, the present application provides a data processing method based on blockchain. The method is executed by a blockchain node, the blockchain node is implemented by a device cluster, and a distributed microservice is deployed in the blockchain node, each microservice is independently deployed on a different device; the microservice includes at least a transaction pool service, a consensus service, and a storage service; the method includes:

[0007] The transaction pool service obtains transaction data and triggers verification of the transaction data. After the transaction data passes verification, the transaction data is placed in the preset queue;

[0008] When the blockchain node is the master node, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger the consensus operation;

[0009] The storage service receives the new blocks generated after consensus is passed, and performs block placement based on the new blocks.

[0010] In the second aspect, the present application also provides a blockchain node, which is implemented by a device cluster, and a distributed microservice is deployed in the blockchain node, each microservice is independently deployed on a different device, and the microservice includes at least a transaction pool service, a consensus service and a storage service, wherein:

[0011] The transaction pool service is used to obtain transaction data and trigger the verification of transaction data. After the transaction data passes the verification, the transaction data is placed in the preset queue;

[0012] Consensus service, used when the blockchain node is the master node, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger the consensus operation;

[0013] The storage service is used to receive new blocks generated after consensus is passed and perform block processing based on the new blocks.

[0014] In a third aspect, the present application further provides a computer-readable storage medium, wherein a computer program is stored thereon, and when the computer program is executed by a processor, the steps of the above-mentioned blockchain-based data processing method are implemented.

[0015] In a fourth aspect, the present application also provides a computer program product. The computer program product includes a computer program, which implements the steps of the above-mentioned blockchain-based data processing method when executed by a processor.

[0016] The above-mentioned data processing method based on blockchain, blockchain node, storage medium and computer program product, wherein the blockchain node is implemented by a device cluster, and distributed microservices are deployed in the blockchain node, and the microservices include at least a transaction pool service, a consensus service and a storage service, and each microservice is independently deployed on different devices. This independently deployed architecture can effectively decouple the functional modules in the traditional blockchain node and reduce the computer resource competition between the functional modules. In the data processing process based on blockchain, the transaction pool service obtains transaction data and triggers the verification of transaction data, and puts the transaction data into a preset queue after the transaction data passes the verification; when the blockchain node is the main node, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, broadcasts the consensus message to trigger the consensus operation, and the storage service receives the new block generated after the consensus is passed, and performs block processing based on the new block. In this application, since each microservice is independently deployed on different devices, the operation process of the transaction pool service, the consensus service and the storage service no longer generates resource competition, thereby improving the data processing efficiency of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is an application environment diagram of a data processing method based on blockchain in one embodiment;

[0018] Figure 2 A structural block diagram of a blockchain node in one embodiment;

[0019] Figure 3 A flowchart of a data processing method based on blockchain in one embodiment;

[0020] Figure 4 It is a structural block diagram of a blockchain node in another embodiment;

[0021] Figure 5 A flowchart of an Internet device workflow in one embodiment;

[0022] Figure 6 A schematic diagram of a verification service call relationship in an embodiment;

[0023] Figure 7 It is a structural block diagram of a blockchain node in yet another embodiment;

[0024] Figure 8 A flowchart of the processing of transaction data in one embodiment;

[0025] Fig. 9 A flowchart of processing transaction data in another embodiment;

[0026] Fig.10 A time sequence interaction diagram of a data processing method based on blockchain in one embodiment;

[0027] Fig.11 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0029] Before going into detail, some terms involved in this application are explained first.

[0030] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0031] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first adapts the interface for parsing and authentication (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status monitoring, node equipment health status monitoring, etc.

[0032] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0033] The blockchain-based data processing method provided in the embodiments of the present application can be applied to Figure 1 In the application environment shown in the figure, the blockchain network can be composed of multiple blockchain nodes, such as Figure 1The application environment shown includes multiple blockchain nodes 102, and different blockchain nodes 102 can communicate with each other through the network. For each blockchain node 102, it can be implemented through a device cluster, and distributed microservices are deployed in any blockchain node 102, and each microservice is independently deployed on different devices or on different device subclusters. The microservices include at least transaction pool services, consensus services, and storage services. This independent microservice deployment architecture can make the transaction pool service, consensus service, and storage service no longer compete for resources, thereby improving the data processing efficiency of the blockchain. Among them, the blockchain in the embodiment of the present application can be a consortium chain, or it can be other chains such as a public chain, which is not limited here.

[0034] In some embodiments, Figure 2 As shown, it is a schematic diagram of the structure of blockchain nodes in a blockchain network. For each blockchain node in the blockchain network, it can be a consensus node, such as blockchain node 1, blockchain node 2, blockchain node 3 and blockchain node 4, etc., which can be a device cluster. For any blockchain node, it can be implemented through a device cluster, that is, through multiple devices. In the blockchain node, each different service is independently deployed on different devices or sub-device clusters. Among them, the sub-device cluster is a cluster composed of at least two devices in the device cluster, and the number of devices in the sub-device cluster is less than the number of devices in the device cluster. For example, the device cluster may include multiple devices such as device A, device B, device C, device D and device E. Device A and device C can constitute sub-device cluster 1, and device B and device E can constitute sub-device cluster 2. For any microservice, it can be deployed on sub-device cluster 1 or sub-device cluster 2, or it can be deployed alone on device D. For example, the transaction pool service can be deployed separately on device D, the storage service can be deployed on sub-device cluster 1, that is, deployed on devices A and C, and the consensus service can be deployed on sub-device cluster 2, that is, deployed on devices B and E. The actual microservice deployment can be adaptively adjusted in combination with the transaction processing performance requirements of the blockchain network, blockchain business application scenarios, etc.

[0035] In some embodiments, in the process of blockchain-based data processing methods, the transaction pool service of blockchain node 102 obtains transaction data and triggers verification of transaction data, and puts the transaction data into a preset queue after the transaction data passes the verification; when blockchain node 102 is the master node, the consensus service of blockchain node 102 obtains transaction data to be consensused from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger a consensus operation; the storage service of blockchain node 102 receives the new block generated after the consensus is passed, and performs block placement processing based on the new block.

[0036] Among them, the device cluster can be a cluster composed of multiple servers, or a cluster composed of multiple terminals, or a cluster composed of computer devices including both servers and terminals. Among them, the terminal can be, but is not limited to, various desktop computers, laptops, smart phones, tablet computers, Internet of Things devices, portable wearable devices, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle-mounted devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server can be implemented with an independent server or a server cluster composed of multiple servers, and can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal and the server can be directly or indirectly connected via wired or wireless communication. The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

[0037] The following is a detailed introduction to the blockchain-based data processing method of this application:

[0038] In an exemplary embodiment, Figure 3 As shown, a data processing method based on blockchain is provided, which is described by taking any blockchain node in the blockchain network as an example, and includes the following steps:

[0039] Step 302, the transaction pool service obtains the transaction data and triggers verification of the transaction data, and puts the transaction data into a preset queue after the transaction data passes the verification.

[0040] Among them, the transaction pool service is a service unit that realizes the functions of the transaction pool. The transaction pool service is independent of the consensus service and storage service, and no longer competes with the consensus service and storage service for various resources, such as memory resources, CPU, disk IO resources, etc. The functions of the transaction pool may include receiving transaction data, broadcasting received transaction data, verifying the basic information of transaction data, maintaining the data structure of transaction data to be packaged, etc.

[0041] The verification of transaction data is a process of verifying transaction data, which may include verifying basic information of transaction data, signature information, transaction information, etc. The preset queue is a data structure for storing verified transaction data.

[0042] Specifically, the transaction pool service can obtain transaction data sent by the transaction data processing requester, and the transaction data processing requester can be a terminal device, for example, the terminal device can be a terminal such as a mobile phone used by a user that can receive user operation information, or it can be a terminal used by an organization or institution, without limitation. Further, the transaction pool service triggers the verification of the transaction data based on the acquired transaction data. If the transaction pool service determines that the basic information, signature information, transaction information, etc. of the transaction data are all qualified, it means that the transaction data has passed the verification. Then the transaction pool service can put the transaction data into a preset queue.

[0043] In some embodiments, when transaction data fails verification, the transaction pool service may discard the transaction data, thereby freeing up memory and improving data processing efficiency to a certain extent.

[0044] In some embodiments, the preset queue may be any data structure that can store data, such as a list, a tuple, a linked list, etc. When actually setting the preset queue, it may be adaptively set in combination with the type and characteristics of the transaction data.

[0045] In some embodiments, the verification of transaction data triggered by the transaction pool service can be carried out by the transaction pool service itself; or the transaction data can be sent to other microservice units with data verification functions for verification; or it can be multi-stage verification, such as the transaction pool service first verifies itself, and if it passes the verification, it sends the transaction data that has passed its own verification to other microservice units with data verification functions for verification. The specific transaction data verification process can be adaptively selected in combination with the actual blockchain application, data verification accuracy requirements, etc.

[0046] In some embodiments, when the transaction pool service performs verification itself, it can use function calls and other methods to call the corresponding functional verification function, and perform verification of the transaction data based on the functional verification function.

[0047] In some embodiments, the communication between microservices in the same blockchain node, such as the communication between the consensus service and the storage service, and the communication between the transaction pool service and the consensus service, can be carried out based on a pre-set communication method, and the communication protocol can be various protocols such as RPC (Remote Procedure Call) protocol and RTMP (Real Time Messaging Protocol).

[0048] Step 304, when the blockchain node is the master node, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger the consensus operation.

[0049] Among them, blockchain nodes can include consensus nodes. The master node is the consensus node used to initiate consensus in the blockchain network and lead the block update in this round of consensus phase.

[0050] Consensus messages are generated based on transaction data and are used to trigger consensus among other blockchain nodes in the blockchain network.

[0051] Consensus operation is the process by which each blockchain node in the blockchain network determines whether a consensus has been reached based on the received consensus message. The consensus operation can be specifically a voting of blockchain nodes on the transaction data of the consensus message to complete the verification and confirmation of the transaction data. When actually performing consensus operation, it can be based on various algorithms such as PoW (Proof of Work), PoS (Proof of Stake), BFT (Byzantine Fault Tolerance) and hybrid consensus.

[0052] Specifically, if the blockchain node is the master node, the consensus service can obtain transaction data from the preset queue to generate a consensus message. The consensus service can obtain transaction data according to the set data acquisition order, and the data acquisition order can be set according to the time sequence of transaction data writing, the type of transaction data processing requester, etc. Furthermore, the consensus service can transmit the consensus message to other blockchain nodes to trigger the consensus operation.

[0053] In some embodiments, when the consensus service obtains transaction data in the order of the time when the transaction data is written, it may give priority to obtaining the transaction data with an earlier time, that is, the transaction data written first in the preset queue.

[0054] In some embodiments, when the consensus service obtains transaction data for generating consensus messages from a preset queue, it can obtain only one transaction data at a time, or it can obtain transaction data in batches. In the case of obtaining only one transaction data at a time, consensus can be initiated for transaction data in a targeted manner, and the cause of consensus failure can be determined more quickly when consensus fails. When obtaining transaction data in batches, consensus can be initiated for multiple transaction data at the same time to improve the data processing efficiency of the blockchain.

[0055] In some embodiments, when the consensus service obtains transaction data in batches from a preset queue in chronological order, the transaction data may be obtained at a set time interval or time point. For example, if the transaction data is obtained at a time interval, the transaction data is obtained once each time the set time interval is reached; if the transaction data is obtained at a time point, the transaction data may be obtained once each time the set time point is reached.

[0056] Step 306: The storage service receives the new block generated after the consensus is passed, and performs block placement based on the new block.

[0057] Specifically, the storage service receives the new block generated after the consensus is passed, and can trigger block verification for the new block, such as verifying whether the submitted new block data is legal, whether the data is complete, etc. After the new block verification is passed, the storage service can process the new block in sequence according to the set block placement order.

[0058] In some embodiments, the order of block placement can be set in chronological order, that is, the blocks are placed in order according to the time when the new blocks are generated. That is, the new blocks generated first are placed first. For each new block generated, there is usually a corresponding block height, and the block height of the block generated earlier is lower than the block height of the block generated later. Therefore, before each block is placed, the new blocks with low block heights in the new blocks will be placed first. For example, the current block height of the blockchain is 100. Only when the new block with a block height of 101 is placed can the new block with a block height of 102 be placed. Since the transaction data in the new block with a block height of 101 will modify the account book, if the new block with a block height of 102 is placed in advance, once a transaction verification error occurs in the new block with a block height of 101 and the transaction is kicked out, it will easily cause abnormal account book information.

[0059] In some embodiments, the new block received by the storage service may be submitted by a master node or a slave node. The specific node that submits the new block may be determined by a pre-set consensus algorithm and is not limited here.

[0060] In the above-mentioned data processing method based on blockchain, the blockchain node is implemented by a device cluster, and distributed microservices are deployed in the blockchain node. The microservices include at least a transaction pool service, a consensus service and a storage service. Each microservice is independently deployed on different devices. This independently deployed architecture can effectively decouple the functional modules in the traditional blockchain node and reduce the computer resource competition between the functional modules. In the data processing process based on blockchain, the transaction pool service obtains transaction data and triggers the verification of transaction data. After the transaction data passes the verification, the transaction data is placed in a preset queue; when the blockchain node is the master node, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, broadcasts the consensus message to trigger the consensus operation, and the storage service receives the new block generated after the consensus is passed, and performs block processing based on the new block. In this application, since each microservice is independently deployed on different devices, the operation process of the transaction pool service, the consensus service and the storage service no longer generates resource competition, thereby improving the data processing efficiency of the blockchain.

[0061] In some embodiments, the blockchain node includes a network interconnection device, and the blockchain-based data processing method also includes: the network interconnection device receives a data processing request; when the data processing request is a transaction on-chain request, the transaction data in the transaction on-chain request is routed to the transaction pool service in the blockchain node.

[0062] Among them, the network interconnection device is a tool with routing function, which can be a device that realizes communication between blockchain nodes in the blockchain network. The transaction chain request is a request to write transaction data into the blockchain, and the transaction chain request carries the transaction data.

[0063] Specifically, the network interconnection device receives the data processing request, identifies the type of the data processing request, and executes an action that matches the type of the data processing request based on the identified type of the data processing request. If the data processing request is identified as a transaction on-chain request, the network interconnection device can route the transaction data in the transaction on-chain request to the transaction pool service in the blockchain node based on the address of the transaction pool service.

[0064] In some embodiments, the network interconnection device can be any device that can realize communication between blockchain nodes, such as a gateway, a repeater, a network card, etc. For each blockchain node, a corresponding network interconnection device can be deployed. Specifically, the setting of the network interconnection device can be set in combination with the actual application scenario of the blockchain, communication efficiency, etc.

[0065] In some embodiments, the network interconnection device corresponds to an address, which may specifically be an IP address (Internet Protocol Address). For each blockchain node, its network interconnection device corresponds to a matching IP address.

[0066] In some embodiments, the IP address of the network interconnection device in the blockchain node is shared with other blockchain nodes, so the transmission address of the consensus message between blockchain nodes can be the IP address of the network interconnection device of each blockchain node.

[0067] In some embodiments, the network interconnection device is a gateway, and the data processing request is received through the gateway. The gateway can identify the type of the data processing request and perform routing based on the type of the data processing request. When identifying the type of the data processing request, the gateway can parse the data processing request, extract the header data in the data processing request, and determine the type of the data processing request based on the header data.

[0068] In some embodiments, the header data includes source information of the data request, such as whether the data request comes from the user's terminal device or other blockchain nodes.

[0069] In some embodiments, when the network interconnection device recognizes that the data processing request is submitted by the user through the terminal device, the network interconnection device can automatically forward the transaction data to the transaction pool service of the blockchain node.

[0070] In other embodiments, when the network interconnection device recognizes that the data processing request is sent by the transaction pool service, the network interconnection device can automatically forward the transaction data to the transaction pool services of other blockchain nodes except the blockchain node that sent the data processing request.

[0071] In some embodiments, Figure 4 As shown in Figure 2 The blockchain node structure diagram based on the structural diagram shown. For each blockchain node in the blockchain network, its deployed microservices may also include a gateway.

[0072] In the above embodiment, the network interconnection device can identify the type of data processing request for the received data processing request, and when the data processing request is a transaction on-chain request, the transaction data in the transaction on-chain request is routed to the transaction pool service in the blockchain node. Different types of requests can be routed to corresponding microservices through the network interconnection device, which not only ensures the accuracy of data processing in the blockchain network, but also realizes communication between clustered blockchain nodes.

[0073] In some embodiments, the blockchain-based data processing method also includes: when the data processing request is a consensus request, routing the consensus message in the consensus request to the consensus service in the blockchain node to instruct the consensus service to perform a consensus operation based on the consensus message.

[0074] Among them, the consensus request is a request sent by the consensus node during the consensus phase.

[0075] Specifically, the network interconnection device receives a data processing request. When the data processing request is a consensus request, the network interconnection device can route the consensus message in the consensus request to the consensus service in the blockchain node based on the address of the consensus service, thereby instructing the consensus service to perform a consensus operation based on the consensus message.

[0076] In some embodiments, when the network interconnection device recognizes that the data processing request is a consensus message sent by other blockchain nodes, the network interconnection device can automatically forward the consensus message to the consensus service of the blockchain node.

[0077] In some embodiments, the IP address of the network interconnection device in the blockchain node is shared with the user's terminal device, so the transmission address of transaction data between the terminal device and any blockchain node can be the IP address of the network interconnection device of the blockchain node.

[0078] In some embodiments, Figure 5 As shown, it is a flowchart of routing messages when the network interconnection device is a gateway:

[0079] For clustered blockchain nodes, the gateway IP address can be the IP address of this blockchain node, and the gateway IP address is shared with other blockchain nodes and user's terminal devices. When a user sends a transaction data through a terminal device, the actual submitted address can be the gateway IP address; the consensus message transmission address between blockchain nodes is also the gateway IP address of each blockchain node.

[0080] When the user's terminal device submits a transaction data to the gateway of blockchain node 1, the gateway will automatically forward the transaction to the transaction pool service within the cluster according to the message type. The gateway will also automatically forward the consensus message sent by other blockchain nodes, such as blockchain node 2, to the consensus service according to the message type. That is, if the transaction data is sent by the user's terminal device, it will be directly routed to the transaction pool service; if it is a consensus message sent by other blockchain nodes, it will be directly routed to the consensus service.

[0081] In the above embodiment, the network interconnection device can route the consensus message in the consensus request to the consensus service in the blockchain node when the data processing request is a consensus request. Different types of requests can be routed to corresponding microservices through the network interconnection device, which can ensure the accuracy of data processing in the blockchain network to a certain extent.

[0082] In some embodiments, the microservice also includes a verification service, which is mainly used to verify the legitimacy of information such as transaction data. Before describing the detailed data processing process of the verification service, the relationship between the verification service, the transaction pool service, the storage service, and the consensus service is described first.

[0083] Usually, if Figure 6 As shown in the figure, the transaction pool service, storage service, and consensus service will all call the verification service. After receiving new transaction data, the transaction pool service will verify the legitimacy of the transaction based on the verification service; when the blockchain node is a slave node, the consensus service will verify the legitimacy of the transaction in the proposal based on the verification service after receiving the consensus message. After the consensus is completed, when the new block is submitted, the storage service will verify the legitimacy of the transaction based on the verification service. Therefore, the verification service deployed by the independent service still needs to support these functions.

[0084] In some embodiments, the microservice also includes a verification service; the transaction pool service obtains transaction data and triggers verification of the transaction data, and places the transaction data into a preset queue after the transaction data passes the verification, including: the transaction pool service obtains transaction data, and performs basic information verification on the transaction data, and sends the transaction data to the verification service if the basic information verification passes; the verification service performs legitimacy verification on the received transaction data, and feeds back information to the transaction pool service after the legitimacy verification passes; when the transaction pool service receives feedback information indicating that the legitimacy verification passes, it places the transaction data into a preset queue.

[0085] Among them, basic information verification is to verify the basic information of transaction data. The basic information of transaction data may include transaction timestamp, version number, difficulty target, random number, etc. of transaction data.

[0086] The verification service is a microservice deployed in the blockchain node in addition to the transaction pool service, consensus service and storage service. The verification service can be used to verify the legitimacy of transaction data, which can include verifying the signature information and data length of the transaction data.

[0087] Specifically, the transaction pool service can perform basic information verification on the transaction data. If the transaction timestamp, version number, etc. of the transaction data meet the basic information requirements, it indicates that the basic information verification has passed. If the basic information verification has passed, the transaction pool service can send the transaction data that has passed the basic information verification to the verification service through the set communication protocol, and the verification service will perform legitimacy verification. The verification service performs legitimacy verification based on the received transaction data, and feedback information to the transaction pool service after the legitimacy verification passes. If the legitimacy verification fails, the transaction data is discarded to release memory. Then, when the transaction pool service receives feedback information indicating that the legitimacy verification has passed, it puts the transaction data into the preset queue.

[0088] In some embodiments, Figure 7 FIG. 1 is a schematic diagram of the structure of a blockchain node in another embodiment. For each blockchain node in the blockchain network, the deployed microservices may also include a verification service.

[0089] refer to Figure 8 , Figure 8 This is a flowchart of data processing for transaction data in one embodiment:

[0090] Figure 8 The transaction pool service in is a distributed deployed microservice. It is no longer a small module deployed together with other modules, but an independent service.

[0091] Among them, the user can send transaction data through the terminal device, and the sent transaction data first reaches the gateway of blockchain node 1. The gateway routes the transaction data to the transaction pool service.

[0092] The transaction pool service will first verify the basic information of the transaction data, such as a round of verification of basic information such as the transaction timestamp. If the verification fails, the transaction data will be discarded. If the transaction verification passes, it will be sent to the verification service through a communication protocol such as RPC, and the verification service will verify the legitimacy of the transaction data. When the verification service passes the verification, it will inform the transaction pool service. When the verification service fails the verification, the transaction data will be discarded. The transaction pool service will put the transaction data that has passed the verification service's legitimacy verification into the preset queue and wait for the consensus service to pull it. The preset queue can be a list of transactions to be packaged.

[0093] When the consensus service enters a round of consensus, it will request a batch of transaction data from the transaction pool service. The transaction pool service only needs to extract a batch of transaction data from the list to be packaged and hand it over to the consensus service. The consensus service can generate a consensus message based on the obtained transaction data and trigger a consensus operation based on the consensus message.

[0094] In the above embodiment, the transaction pool service first verifies the basic information of the transaction data. When the basic information verification is passed, the transaction data that has passed the basic information verification is sent to the verification service, which verifies the legitimacy. When the feedback information indicating that the legitimacy verification has passed is received, the transaction data is placed in a preset queue. On the one hand, through double verification, the accuracy of transaction data verification in the blockchain network can be improved; on the other hand, some transaction data with unqualified basic information can be eliminated through basic information verification, reducing the amount of calculation for subsequent legitimacy verification, which can improve the efficiency of transaction data processing.

[0095] In some embodiments, the consensus service obtains transaction data to be consensused from a preset queue to generate a consensus message, and broadcasts the consensus message to trigger a consensus operation, including: when entering a new round of consensus phase, the consensus service obtains transaction data to be consensused from a preset queue to generate a consensus message; waits for the storage service to feedback a signal that the previous block has been successfully landed; upon receiving a signal from the storage service that the previous block has been successfully landed, broadcasts a consensus message to trigger a consensus operation.

[0096] The data processing process in the blockchain network may include multiple rounds of consensus phases. The specific number of rounds of the consensus phase may depend on the set consensus algorithm, which may be DBFT (Delegated Byzantine fault tolerance), BFT (Byzantine Fault Tolerance), etc.

[0097] Specifically, in each round of consensus, the consensus service can continuously obtain transaction data to be consensused from the preset queue to generate consensus messages, that is, the consensus service can continuously obtain transaction data and generate multiple consensus messages such as consensus message A, consensus message B... consensus message N. If the consensus service receives a signal from the storage service that the previous block has been successfully landed, it broadcasts the consensus message to trigger the consensus operation.

[0098] In some embodiments, consensus message A is a consensus message sent by the consensus service in a certain round of consensus phase. The consensus service may not wait for the storage service to feedback the signal that the block corresponding to consensus message A has been landed before generating the consensus message, but may continue to generate consensus message B, consensus message C, etc. When the consensus service receives the information that the block corresponding to consensus message A has been landed from the storage service, the consensus service may send the generated consensus message B and repeat the above process until the set consensus phase round is reached, that is, the generation of consensus messages is stopped.

[0099] In the above embodiment, the consensus service does not need to synchronously wait for the response of the storage service, and can enter the consensus message generation stage of a new round of consensus in advance, and only wait for the signal of the storage service before broadcasting the proposal. Compared with the current consensus service waiting for the block to be completed before starting the next stage of the process, the execution time of the consensus stage can be shortened, and the data processing efficiency in the blockchain network can be improved.

[0100] In some embodiments, the consensus service obtains transaction data to be consensused from a preset queue to generate a consensus message, including: the consensus service extracts a preset amount of transaction data from the preset queue, and packages the preset amount of transaction data into a blockchain proposal, serializes the blockchain proposal to obtain a byte stream, and uses the byte stream as a consensus message.

[0101] Serialization is the process of converting data into a form that can be stored or transmitted. Specifically, the consensus service can package the transaction data extracted from the preset queue, that is, package the transaction data into a blockchain proposal. Furthermore, in order to broadcast the blockchain proposal, the consensus service can serialize the blockchain proposal to obtain a byte stream and use the obtained byte stream as the consensus message.

[0102] In some embodiments, when the consensus service serializes the blockchain proposal, it can use various serialization methods such as ProtoBuf (Protocol Buffers, a lightweight data exchange format) serialization and Json (JavaScript Object Notation, a lightweight data exchange format) serialization.

[0103] In the above embodiment, the consensus service obtains transaction data from a preset queue, packages the transaction data into a blockchain proposal, and then serializes the blockchain proposal to obtain a byte stream, thereby using the byte stream as a consensus message, so that the consensus message can be transmitted in the network.

[0104] In some embodiments, the blockchain node includes a network interconnection device; broadcasting a consensus message to trigger a consensus operation includes: the consensus service sends the consensus message to the network interconnection device in the blockchain node; the network interconnection device in the blockchain node forwards the consensus message to the network interconnection devices of other blockchain nodes in the blockchain network to instruct the network interconnection devices of other blockchain nodes to pass the consensus message to the corresponding consensus service to perform a consensus operation.

[0105] Specifically, the consensus service can forward the consensus message to the network interconnection device based on the address of the network interconnection device in the blockchain node. After receiving the consensus message, the network interconnection device in the blockchain node can forward the consensus message to the network interconnection devices of other blockchain nodes in the blockchain network based on the addresses of the network interconnection devices of other blockchain nodes in the blockchain network, so as to instruct the network interconnection devices of other blockchain nodes to pass the consensus message to the corresponding consensus service for consensus operation.

[0106] In some embodiments, the consensus service of any blockchain node can save the IP addresses of the network interconnection devices of other blockchain nodes in the blockchain network. When the consensus service needs to forward the consensus message, it can directly forward the consensus message based on the saved IP address of the network interconnection device.

[0107] In the above embodiment, the consensus service can forward the consensus message to the network interconnection device based on the address of the network interconnection device in the blockchain node, and the network interconnection device forwards the consensus message to the network interconnection devices of other blockchain nodes in the blockchain network to instruct the network interconnection devices of other blockchain nodes to pass the consensus message to the corresponding consensus service for consensus operation. The communication between each blockchain node can be achieved through the network interconnection device, so that the consensus message can be accurately and quickly passed to the corresponding consensus service for consensus operation.

[0108] In some embodiments, the microservice also includes a verification service, and the storage service receives the new block generated after the consensus is passed, and performs block placement processing based on the new block, including: the storage service receives the new block generated after the consensus is passed, and sends the block information of the new block to the verification service; the verification service verifies the block information, and if the verification is passed, instructs the storage service to perform block placement processing based on the new block.

[0109] The block information is used to record the characteristics and attributes of the new block. The block information may include the height information, signature information, data length, timestamp and other information of the new block.

[0110] Specifically, after receiving the new block generated after consensus is passed, the storage service can send the block information of the new block to the verification service through the set communication protocol, such as the RPC protocol, and the verification service will verify the legitimacy of the block information. If the verification service determines that the legitimacy verification has passed, it will send feedback information to the storage service. If the storage service receives feedback information indicating that the legitimacy verification has passed, it will process the new block.

[0111] In the above embodiment, the storage service will also verify the legitimacy of the acquired new block through the verification service before placing the block, and place the new block after receiving feedback information indicating that the legitimacy verification has passed. This can ensure the legitimacy of the transaction data in the entire consensus stage and the reliability of data processing in the blockchain network.

[0112] In some embodiments, the blockchain-based data processing method also includes: when the blockchain node is a slave node, the consensus service receives a consensus message transmitted by the master node, performs a consensus operation based on the received consensus message to obtain an operation result, and feeds back voting information to the master node based on the operation result; the voting information is used to determine whether the consensus is passed.

[0113] Among them, slave nodes are consensus nodes in the blockchain network that participate in consensus and vote on consensus proposals initiated by master nodes. Consensus operations in the blockchain network can be completed by the collaboration of slave nodes and master nodes.

[0114] Voting information is transmitted from the slave node to the master node, which is used to represent its recognition and support for the consensus message.

[0115] Specifically, when the blockchain node is a slave node, the consensus service receives the consensus message transmitted by the master node, and performs consensus operations based on the received consensus message, such as verifying the legitimacy of the transaction data in the consensus message, obtaining the legitimacy verification result, and feedbacking the consensus message used to determine whether the consensus is passed to the master node based on the legitimacy verification result.

[0116] In some embodiments, when a blockchain node is a consensus node, any blockchain node can be used as a master node in the current consensus phase or as a slave node in the next consensus phase. In each round of consensus phase, whether a blockchain node is a master node or a slave node can be determined by a specific consensus algorithm.

[0117] In some embodiments, the master node can determine whether the consensus is passed based on the received voting information. For example, the master node determines that the consensus is passed when it determines that it has received the voting information of all slave nodes in all blockchain networks; for another example, the master node determines that the consensus is passed when it receives the voting information fed back by half of the slave nodes or two-thirds of the slave nodes.

[0118] In some embodiments, Fig. 9 As shown, this is a workflow diagram of the consensus service:

[0119] When the blockchain node is the master node, when the consensus service enters a new round of consensus, it will extract transaction data from the transaction pool service and package the transaction data into a blockchain proposal. Furthermore, in order to broadcast the blockchain proposal, the consensus service can serialize the blockchain proposal to obtain a byte stream and use the obtained byte stream as a consensus message.

[0120] When asynchronous block submission is enabled, the consensus service waits for the storage service to feedback the signal that the previous block was successfully submitted. After receiving the signal, it will immediately broadcast the consensus message. Compared with the traditional synchronous block submission service, the asynchronous operation here can shorten the synchronous execution time of operations such as extracting transaction data, packaging blockchain proposals, and serialization.

[0121] After the consensus service broadcasts the consensus message, it will collect votes. When enough votes are collected, the consensus operation is completed. After the consensus operation is completed, the consensus service will submit the new block to the storage service. After the storage service itself receives the new block submitted by the consensus service, it needs to hand it over to the verification service to verify whether the transaction data in the new block is legal. The storage service provides asynchronous notification services, that is, the consensus service does not need to synchronously wait for the storage service to respond to the successful block placement, but can enter the proposal preparation for the next round of consensus in advance. When the storage service completes the block placement, it asynchronously notifies the consensus service of the completion of the block placement, and then the consensus service can immediately start the next round of consensus proposal broadcast. Therefore, asynchronous notifications will greatly improve the performance of the consensus service.

[0122] In the above embodiment, when the blockchain node is a slave node, the consensus service receives the consensus message transmitted by the master node, performs a consensus operation based on the received consensus message, obtains the operation result, and feeds back a consensus message to the master node based on the operation result to determine whether the consensus is passed. Thus, the master node and the slave node jointly complete the consensus process, which reflects the principle of fairness of the blockchain network when it is decentralized.

[0123] In some embodiments, the microservice also includes a verification service, which performs a consensus operation based on the received consensus message to obtain an operation result, and feeds back voting information to the master node based on the operation result, including: the consensus service deserializes the consensus message and sends the deserialization result to the verification service; the verification service verifies the legitimacy of the transaction data in the deserialization result; and when the consensus service receives feedback information from the verification service indicating that the legitimacy verification has passed, it feeds back voting information to the master node.

[0124] Among them, deserialization is the process of converting the data generated for transmission during the serialization process back into a data structure or object. Specifically, after receiving the consensus message, the consensus service can deserialize the consensus message to obtain the deserialization result, and send the deserialization result to the verification service through the set communication protocol, such as the RPC protocol, and the verification service verifies the legitimacy of the deserialization result. When the verification service determines that the legitimacy verification has passed, it will send feedback information to the consensus service. When the consensus service receives feedback information indicating that the legitimacy verification has passed, it will feedback the voting information to the master node.

[0125] In the above embodiment, the consensus service will also verify the legitimacy of the obtained consensus message through the verification service, and feedback the voting information to the master node after receiving feedback information indicating that the legitimacy verification has passed. This ensures the legitimacy of the transaction data in the entire consensus phase and the reliability of the data processing of the blockchain.

[0126] In some embodiments, the verification service verifies the legitimacy of the transaction data in the deserialization result, including: the verification service determines the transaction identifier of the transaction data corresponding to the consensus message transmitted from the master node; the verification service obtains the transaction hash value obtained after verification in the transaction pool stage based on the transaction identifier, and obtains a first hash value; the verification service calculates the transaction hash value of the transaction data in the deserialization result to obtain a second hash value; the verification service compares the first hash value with the second hash value, and determines that the legitimacy verification is passed when the first hash value is consistent with the second hash value.

[0127] The transaction identifier refers to identification information that can uniquely identify transaction data. The transaction identifier can be composed of one or more characters, and the characters can include at least one of numbers, letters, symbols, etc.

[0128] Transaction hash value is the hash value obtained by hashing the transaction data.

[0129] The first hash value and the second hash value are hash values ​​obtained by performing hash calculations on transaction data at two different stages. The first hash value is the hash value calculated for transaction data after verification at the transaction pool stage. The second hash value is the hash value calculated at the consensus stage.

[0130] Specifically, when the verification service receives the consensus message transmitted by the master node, it can extract the transaction identifier of each transaction data, and directly query and obtain the first hash value that matches the transaction identifier based on the transaction identifier. Furthermore, the verification service can also calculate the transaction hash value of the transaction data in the deserialization result to obtain the second hash value, so that the verification service determines whether the legitimacy verification has passed by comparing the first hash value with the second hash value. If they are consistent, the legitimacy verification has passed. If they are inconsistent, it means that the legitimacy verification has failed.

[0131] In some embodiments, the verification service may store the hash value calculated for the transaction data that has passed the verification in the transaction pool stage in association with the transaction identifier of the corresponding transaction data.

[0132] In some embodiments, if the verification service determines that the first hash value and the second hash value of any transaction data in the consensus message are inconsistent, it means that the current round of consensus has failed; of course, it can also be that the verification service determines that the first hash value and the second hash value of most transaction data, such as two-thirds or three-quarters, are consistent, which means that the current round has reached a consensus and the blockchain block can be updated. Specifically, the judgment of consensus failure or success can be adaptively adjusted in combination with actual blockchain application scenarios.

[0133] In some embodiments, the transaction identifier is a DID identifier that complies with the DID (Decentralized Identity) protocol and is uniformly managed by the DID identity service node in the underlying chain.

[0134] In the above embodiment, the verification service obtains the first hash value calculated for the transaction data after verification in the transaction pool stage based on the transaction identifier of the transaction data, and compares it with the second hash value recalculated for the transaction data in the consensus message, so as to quickly and accurately determine whether the transaction data is legal.

[0135] In some embodiments, the blockchain node includes a network interconnection device, which is used to realize the function of communicating between the microservices in the blockchain node and other blockchain nodes. The blockchain-based data processing method also includes: when the blockchain node needs to be upgraded, shutting down the network interconnection device; upgrading the microservices that need to be upgraded in the blockchain node; and reopening the network interconnection device after the upgrade is completed.

[0136] Among them, upgrading is to introduce new functions and fix problems for blockchain nodes. Through upgrading, the performance of blockchain nodes can be improved.

[0137] Specifically, the shutdown of the network interconnection device is related to the upgrade of the blockchain node. When the blockchain node needs to be upgraded, it is only necessary to configure the status of the network interconnection device. When the network interconnection device is shut down, all other messages will not be forwarded to the transaction pool service and consensus service inside the device cluster. In this way, each microservice inside the device cluster can be maintained and upgraded separately. When the upgrade is completed, the network interconnection device can be reopened. The network interconnection device in this embodiment can specifically be a gateway.

[0138] In the above embodiment, when the blockchain node needs to be upgraded, it is only necessary to configure the status of the network interconnection device, so that the upgrade can be completed quickly and efficiently, and business services can be provided more efficiently.

[0139] The present application also provides an application scenario, which applies the above-mentioned blockchain-based data processing method. Specifically, the application of the blockchain-based data processing method in this application scenario is as follows:

[0140] At present, in the data processing process of the blockchain network, when the transaction pool module, consensus module, and storage module are processing the corresponding logic at the same time, the computer resources such as CPU (Central Processing Unit), memory, and storage are occupied concurrently, resulting in a low TPS (number of transactions that can be processed per second) of the blockchain network.

[0141] The blockchain node in the embodiment of the present application is implemented by a device cluster, that is, a blockchain node is changed from a server to a server cluster, in which the verification service, storage service, consensus service and transaction pool service are independent on different servers. Each server is responsible for its own independent microservice, and the servers communicate with each other through RPC, so that computing and other resources are reasonably allocated to different servers. For the verification service and storage service, it is not necessary to communicate with other blockchain nodes, so the access rights of the verification service and storage service can be limited to the cluster. For the consensus service and the transaction pool service, it is necessary to communicate with the external network. Therefore, a gateway is set up to enable the consensus service and the transaction pool service to be connected to the outside. The transaction data sent by the user will be forwarded to the server where the transaction pool service is located through the gateway, and the communication between the consensus nodes will also be forwarded through the gateway.

[0142] like Fig.10 The figure shows a timing diagram of the actual data processing process of the blockchain. The data processing request sent by the user will reach the gateway of the blockchain node. The gateway can process the data processing request. When it is determined that the data processing request is a transaction on-chain request, the transaction data will be routed to the transaction pool service. The transaction pool service will verify the basic information of the transaction data. If the verification passes, the transaction data will be sent to the verification service, which will verify the legitimacy of the transaction data. After the legitimacy verification passes, the verification service will inform the transaction pool service. The transaction pool service will put the transaction data that has passed the verification service into the list of transactions to be packaged, that is, the preset queue, and wait until the consensus service pulls it.

[0143] In addition, for the transaction data in the list of transactions to be packaged, the transaction pool service will broadcast the transaction data to the transaction pool services of other blockchain nodes, and the transaction pool services of other blockchain nodes will also verify the transaction data through their own verification services. After the verification is passed, the transaction pool services of all blockchain nodes will cache the transaction data. At the same time, the verification service will cache the transaction identifier and the calculated transaction hash value of the transaction data for subsequent rapid verification of the transaction data.

[0144] When the consensus service enters the next round of consensus, it will request a new batch of transaction data from the transaction pool service. The transaction pool service only needs to extract a batch of transaction data that is first put into the list from the list to be packaged and hand it over to the consensus service. Then the consensus service generates a proposal based on the transaction data, that is, a consensus message. At the same time, the consensus service will wait for the signal of successful block placement. When the signal of successful block placement is received, the proposal will be transmitted to the gateway, and the gateway will broadcast it to other blockchain nodes. For other blockchain nodes, when they receive the broadcasted proposal, they are not clear whether the transaction data in the proposal is legal. Therefore, it is also necessary to verify the legitimacy of the transaction based on the verification service. Due to the transaction pool stage, all transactions have been broadcast to other blockchain nodes before being packaged. Therefore, the verification service can compare the transaction hash value obtained from the transaction pool stage verification with the hash value recalculated from the transaction data in the broadcast proposal to determine whether the transaction data is legal.

[0145] When the consensus service completes a round of consensus, it will package the proposal into a new block and submit it to the storage service. The storage service also needs to verify the new block submitted by the consensus module based on the verification service. The storage service provides asynchronous notification service, that is, the consensus service does not need to synchronously wait for the storage service to respond to the successful block placement, but can enter the proposal preparation for the next round of consensus in advance. When the storage service completes the block placement, it asynchronously notifies the consensus service of the completion of the block placement, and then the consensus service can immediately start the proposal broadcast for the next round of consensus.

[0146] Throughout the entire process, there are many places where disk read and write operations will be performed. There are two types of disk read and write: the use of WAL (Write Ahead Log System), and the behavior of storage service block dropping. In high-concurrency scenarios, storage services will continue to write to disk, often filling up the disk's I / O (Input / Output). Although the storage service does not write and flush to disk when writing to disk, but enables caching. However, the disk is full, it will continue to exist. Even if the consensus has been stopped, the behavior of storage writing to disk will continue for a long time. Therefore, the use scenario of WAL will be affected. Whether it is the cache of transaction data in the transaction pool, the intermediate state cache in the consensus process, or the cache of the verification service, WAL will be written to some data in the process to prevent data loss. If the disk is continuously occupied by the storage service, it will seriously affect the performance of other services using WAL. Therefore, by making the storage service service-oriented, the disk occupation will not affect the use of other services. This solves the biggest performance bottleneck during concurrent performance testing.

[0147] In this application, the blockchain node is implemented through a device cluster, and each microservice is deployed separately and independently, which solves the resource competition between them. It is also scalable, and any independent microservice can expand resources according to the actual scenario. At the same time, from the consensus process, an asynchronous method is adopted, which greatly improves the concurrency capability. Thereby improving the TPS of the entire chain.

[0148] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0149] In some embodiments, the embodiments of the present application further provide a blockchain node, which is implemented by a device cluster, and a distributed microservice is deployed in the blockchain node, each microservice is independently deployed on a different device, and the microservice includes at least a transaction pool service, a consensus service, and a storage service, wherein:

[0150] The transaction pool service is used to obtain transaction data and trigger the verification of transaction data, and put the transaction data into the preset queue after the transaction data passes the verification.

[0151] The consensus service is used when the blockchain node is the master node. The consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger the consensus operation.

[0152] The storage service is used to receive new blocks generated after consensus is passed and perform block processing based on the new blocks.

[0153] In some embodiments, the blockchain node includes a network interconnection device; the network interconnection device is used to receive a data processing request, and when the data processing request is a transaction on-chain request, route the transaction data in the transaction on-chain request to the transaction pool service in the blockchain node; and also when the data processing request is a consensus request, route the consensus message in the consensus request to the consensus service in the blockchain node to instruct the consensus service to perform a consensus operation based on the consensus message.

[0154] In some embodiments, the microservice also includes a verification service;

[0155] The transaction pool service is also used to obtain transaction data and verify the basic information of the transaction data. If the basic information verification passes, the transaction data will be sent to the verification service;

[0156] Verification service, used to verify the legitimacy of received transaction data and feedback information to the transaction pool service after the legitimacy verification is passed;

[0157] The transaction pool service is also used to place transaction data into a preset queue upon receiving feedback indicating that the legality verification has passed.

[0158] In some embodiments, when entering a new round of consensus phase, the consensus service is further used to obtain transaction data to be consensused from a preset queue to generate a consensus message; it is also used to wait for the storage service to feedback a signal that the previous block was successfully landed; and it is also used to broadcast a consensus message to trigger a consensus operation when receiving a signal from the storage service that the previous block was successfully landed.

[0159] In some embodiments, the consensus service is further used to extract a preset amount of transaction data from a preset queue, package the preset amount of transaction data into a blockchain proposal, serialize the blockchain proposal to obtain a byte stream, and use the byte stream as a consensus message.

[0160] In some embodiments, the consensus service is also used to send consensus messages to the network interconnection devices in the blockchain node; the network interconnection devices in the blockchain node are also used to forward the consensus messages to the network interconnection devices of other blockchain nodes in the blockchain network to instruct the network interconnection devices of other blockchain nodes to pass the consensus messages to the corresponding consensus service to perform consensus operations.

[0161] In some embodiments, the microservice also includes a verification service;

[0162] The storage service is used to receive the new blocks generated after the consensus is passed and send the block information of the new blocks to the verification service;

[0163] The verification service is also used to verify the block information, and if the verification passes, instruct the storage service to perform block placement based on the new block.

[0164] In some embodiments, when the blockchain node is a slave node, the consensus service is also used to receive consensus messages transmitted by the master node, perform consensus operations based on the received consensus messages to obtain operation results, and feedback voting information to the master node based on the operation results; the voting information is used to determine whether the consensus is passed.

[0165] In some embodiments, the consensus service is further configured to receive a consensus message transmitted by the master node, deserialize the consensus message, and send the deserialization result to the verification service;

[0166] Verification service is also used to verify the legitimacy of transaction data in the deserialization result;

[0167] The consensus service is also used to feedback voting information to the master node when receiving feedback information from the verification service indicating that the legitimacy verification has passed.

[0168] In some embodiments, the verification service is further used to determine a transaction identifier of transaction data corresponding to the consensus message transmitted from the master node;

[0169] The verification service is further used to obtain the transaction hash value obtained after verification in the transaction pool stage based on the transaction identifier to obtain the first hash value;

[0170] The verification service is further used to calculate the transaction hash value of the transaction data in the deserialization result to obtain a second hash value;

[0171] The verification service is further used to compare the first hash value with the second hash value, and determine that the legitimacy verification has passed when the first hash value is consistent with the second hash value.

[0172] In some embodiments, when a blockchain node needs to be upgraded, the network interconnection device is turned off; the microservices that need to be upgraded in the blockchain node are upgraded; after the upgrade is completed, the network interconnection device is reopened.

[0173] In one embodiment, a computer device is provided. The computer device is any device in a device cluster, specifically a server or a terminal. Its internal structure diagram can be as follows: Fig.11 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store transaction data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a data processing method based on blockchain is implemented.

[0174] Those skilled in the art will understand that Fig.11 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0175] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0176] In one embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0177] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0178] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0179] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0180] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0181] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A data processing method based on blockchain, characterized in that: The method is executed by a blockchain node, the blockchain node is implemented by a device cluster, and a distributed microservice is deployed in the blockchain node, each microservice is independently deployed on a different device; the microservice includes at least a transaction pool service, a consensus service and a storage service; the method includes: The transaction pool service obtains transaction data and triggers verification of the transaction data, and puts the transaction data into a preset queue after the transaction data passes the verification; In the case where the blockchain node is a master node, the consensus service obtains the transaction data to be consensus-processed from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger a consensus operation; The storage service receives the new block generated after the consensus is passed, and performs block placement processing based on the new block.

2. The method according to claim 1, characterized in that: The blockchain node includes a network interconnection device, and the method further includes: The network interconnection device receives a data processing request; In the case where the data processing request is a transaction on-chain request, the transaction data in the transaction on-chain request is routed to the transaction pool service in the blockchain node.

3. The method according to claim 2, characterized in that The method further comprises: In the case where the data processing request is a consensus request, a consensus message in the consensus request is routed to a consensus service in the blockchain node to instruct the consensus service to perform a consensus operation based on the consensus message.

4. The method according to claim 1, characterized in that The microservice also includes a verification service; the transaction pool service obtains transaction data and triggers verification of the transaction data, and puts the transaction data into a preset queue after the transaction data passes the verification, including: The transaction pool service obtains the transaction data, and performs basic information verification on the transaction data. If the basic information verification passes, the transaction data is sent to the verification service; The verification service verifies the legitimacy of the received transaction data and feeds back information to the transaction pool service after the legitimacy verification passes; When receiving feedback information indicating that the legality verification has passed, the transaction pool service puts the transaction data into a preset queue.

5. The method according to claim 1, characterized in that The consensus service obtains the transaction data to be consensus-processed from the preset queue to generate a consensus message, and broadcasts the consensus message to trigger a consensus operation, including: When entering a new round of consensus, the consensus service obtains the transaction data to be consensused from the preset queue to generate a consensus message; Wait for the storage service to feedback a signal that the previous block has been successfully dropped; When receiving a signal from the storage service indicating that the previous block has been successfully landed, the consensus message is broadcast to trigger a consensus operation.

6. The method according to claim 1, characterized in that The consensus service obtains the transaction data to be consensus-processed from the preset queue to generate a consensus message, including: The consensus service extracts a preset amount of transaction data from the preset queue, packages the preset amount of transaction data into a blockchain proposal, serializes the blockchain proposal to obtain a byte stream, and uses the byte stream as a consensus message.

7. The method according to claim 1, characterized in that The blockchain node includes a network interconnection device; the broadcasting of the consensus message to trigger the consensus operation includes: The consensus service sends the consensus message to the network interconnection device in the blockchain node; The network interconnection device in the blockchain node forwards the consensus message to the network interconnection devices of other blockchain nodes in the blockchain network to instruct the network interconnection devices of other blockchain nodes to pass the consensus message to the corresponding consensus service to perform consensus operations.

8. The method according to claim 1, characterized in that The microservice also includes a verification service. The storage service receives a new block generated after consensus is passed, and performs block placement based on the new block, including: The storage service receives the new block generated after the consensus is passed, and sends the block information of the new block to the verification service; The verification service verifies the block information, and if the verification passes, instructs the storage service to perform block drop processing based on the new block.

9. The method according to claim 1, characterized in that: The method further comprises: In the case where the blockchain node is a slave node, the consensus service receives a consensus message transmitted by the master node, performs a consensus operation based on the received consensus message to obtain an operation result, and feeds back voting information to the master node based on the operation result; the voting information is used to determine whether the consensus is passed.

10. The method according to claim 9, characterized in that The microservice also includes a verification service, which performs a consensus operation based on the received consensus message to obtain an operation result, and feeds back voting information to the master node according to the operation result, including: The consensus service deserializes the consensus message and sends the deserialization result to the verification service; The verification service verifies the legitimacy of the transaction data in the deserialization result; When the consensus service receives feedback information from the verification service indicating that the legitimacy verification has passed, the consensus service feeds back voting information to the master node.

11. The method according to claim 10, characterized in that The verification service verifies the legitimacy of the transaction data in the deserialization result, including: The verification service determines the transaction identifier of the transaction data corresponding to the consensus message transmitted by the master node; The verification service obtains the transaction hash value obtained after verification in the transaction pool stage based on the transaction identifier to obtain a first hash value; The verification service calculates a transaction hash value of the transaction data in the deserialization result to obtain a second hash value; The verification service compares the first hash value with the second hash value, and determines that the legitimacy verification is passed when the first hash value is consistent with the second hash value.

12. The method according to any one of claims 1 to 11, characterized in that The blockchain node includes a network interconnection device, and the network interconnection device is used to realize the function of the microservice in the blockchain node communicating with other blockchain nodes. The method also includes: When the blockchain node needs to be upgraded, shut down the network interconnection device; Upgrading the microservices that need to be upgraded in the blockchain node; After the upgrade is completed, restart the network interconnection device.

13. A blockchain node, characterized in that: The blockchain node is implemented by a device cluster, and a distributed microservice is deployed in the blockchain node, each microservice is independently deployed on a different device, and the microservice includes at least a transaction pool service, a consensus service and a storage service, wherein: The transaction pool service is used to obtain transaction data and trigger verification of the transaction data, and put the transaction data into a preset queue after the transaction data passes the verification; The consensus service is used for obtaining the transaction data to be consensused from the preset queue to generate a consensus message, and broadcasting the consensus message to trigger a consensus operation when the blockchain node is a master node; The storage service is used to receive the new blocks generated after the consensus is passed, and perform block placement processing based on the new blocks.

14. The blockchain node according to claim 13, characterized in that: The blockchain node includes a network interconnection device; The network interconnection device is used to receive a data processing request, and when the data processing request is a transaction on-chain request, route the transaction data in the transaction on-chain request to the transaction pool service in the blockchain node; And it is also used to route the consensus message in the consensus request to the consensus service in the blockchain node when the data processing request is a consensus request, so as to instruct the consensus service to perform a consensus operation based on the consensus message.

15. The blockchain node according to claim 13, characterized in that: The microservice also includes a verification service; The transaction pool service is further used to obtain transaction data and perform basic information verification on the transaction data. If the basic information verification passes, the transaction data is sent to the verification service; The verification service is used to verify the legitimacy of the received transaction data and feedback information to the transaction pool service after the legitimacy verification passes; The transaction pool service is further configured to place the transaction data into a preset queue upon receiving feedback information indicating that the legality verification has passed.

16. The blockchain node according to claim 13, characterized in that: The microservice also includes a verification service; The storage service is used to receive the new block generated after the consensus is passed, and send the block information of the new block to the verification service; The verification service is further used to verify the block information, and if the verification passes, instruct the storage service to perform block placement based on the new block.

17. The blockchain node according to claim 13, characterized in that: The microservice also includes a verification service; The consensus service is further configured to receive a consensus message transmitted by the master node, deserialize the consensus message, and send the deserialization result to the verification service; The verification service is also used to verify the legitimacy of the transaction data in the deserialization result; The consensus service is further configured to feed back voting information to the master node upon receiving feedback information from the verification service indicating that the legitimacy verification has passed.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images