CN117014445A

CN117014445A - Block chain-based data processing method, device, equipment and storage medium

Info

Publication number: CN117014445A
Application number: CN202311285420.4A
Authority: CN
Inventors: 聂凯轩; 王宗友; 时一防; 朱耿良; 刘区城; 廖志勇; 刘汉卿; 黄杨峻
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-10-07
Filing date: 2023-10-07
Publication date: 2023-11-07
Anticipated expiration: 2043-10-07
Also published as: CN117014445B

Abstract

The embodiment of the application discloses a data processing method, a device, equipment and a storage medium based on a blockchain, wherein the method comprises the following steps: the target service node receives the business transaction sent by the gateway equipment; the business transaction is sent to the gateway equipment by the terminal equipment, the gateway equipment is used for determining a target client language type matched with the business type of the business transaction in the client language types of S blockchain clients, the gateway equipment is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types, and S is a positive integer; the business transaction is co-executed and co-identified in the blockchain service node cluster by an execution client and a co-identified client associated with the target client language type. By adopting the embodiment of the application, the safety of the block chain service node can be improved.

Description

Block chain-based data processing method, device, equipment and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a blockchain-based data processing method, apparatus, device, and storage medium.

Background

Currently, with the development of the blockchain technology, the number of business transactions is increased, so that the access times to the blockchain service nodes are increased frequently, and in order to ensure the normal progress of a large number of business transactions, the blockchain service nodes are required to provide safe and stable services. The current block chain service node is easy to generate single-point faults, so that the block chain service node cannot provide service, the error probability of the block chain service node is increased, and the safety of the block chain service node is reduced.

Disclosure of Invention

The embodiment of the application provides a data processing method, device and equipment based on a blockchain and a storage medium, which can improve the security of a blockchain service node.

In one aspect, the embodiment of the application provides a data processing method based on a blockchain, which is implemented by a target service node in a blockchain service node cluster, wherein the blockchain service node cluster comprises M service nodes, the M service nodes comprise target service nodes, the M service nodes comprise S groups of service node sub-clusters, the blockchain clients configured by the service nodes in one group of service node sub-clusters are the same, the blockchain clients respectively configured by different service node sub-clusters are different from each other, the blockchain clients comprise an execution client and a consensus client, M and S are both positive integers, and S is smaller than or equal to M; the method comprises the following steps:

The target service node receives the business transaction sent by the gateway equipment; the business transaction is sent to the gateway equipment by the terminal equipment, the gateway equipment is used for determining a target client language type matched with the business type of the business transaction in the client language types of the S blockchain clients, and the gateway equipment is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types;

the business transaction is co-executed and co-identified in the blockchain service node cluster by an execution client and a co-identified client associated with the target client language type.

In one aspect, the embodiment of the application provides a data processing method based on a blockchain, which is implemented by gateway equipment, wherein the gateway equipment is connected with a blockchain service node cluster; the block chain service node cluster comprises M service nodes, the M service nodes comprise target service nodes, the M service nodes are composed of S groups of service node sub-clusters, the block chain clients configured by the service nodes in one group of service node sub-clusters are identical, the block chain clients respectively configured by different service node sub-clusters are different from each other, the block chain clients comprise execution clients and consensus clients, M and S are both positive integers, and S is smaller than or equal to M; the method comprises the following steps:

The gateway equipment receives a service request carrying service transaction sent by the terminal equipment, and respectively matches the service types corresponding to the service transaction with the client language types of the S blockchain clients to obtain target client language types matched with the service types of the service transaction;

determining a sub-cluster of service nodes associated with the target client language type;

scheduling and selecting the service node subset group associated with the target client language type to obtain a target service node selected by scheduling;

the business transaction is forwarded to the target service node such that the target service node co-executes and co-shares the business transaction in the blockchain service node cluster through the execution client and the co-shares client associated with the target client language type.

In one aspect, an embodiment of the present application provides a data processing apparatus based on a blockchain, including:

the business transaction receiving module is used for receiving business transactions sent by the gateway equipment by the target service node; the business transaction is sent to the gateway equipment by the terminal equipment, the gateway equipment is used for determining a target client language type matched with the business type of the business transaction in the client language types of the S blockchain clients, and the gateway equipment is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types;

And the consensus executing module is used for executing and consensus business transaction in the blockchain service node cluster through the executing client and the consensus client which are associated with the target client language type.

Wherein, the consensus execution module includes:

the running state detection unit is used for detecting the running state of the S group service node sub-cluster;

the fault marking unit is used for carrying out fault marking on the service node sub-cluster with the running state being the fault state if the service node sub-cluster with the running state being the fault state exists in the S group service node sub-clusters;

and the consensus executing unit is used for determining the service node subset group which is not marked by faults as the service node subset group in a normal state, and executing and consensus business transaction in the service node subset group in the normal state through the executing client and the consensus client which are associated with the target client language type.

Wherein, the data processing device still includes:

the heartbeat connection establishment module is used for receiving communication detection data sent by the detection equipment and establishing a heartbeat connection relation with the detection equipment in a time period indicated by the communication detection data;

the block height sending module is used for sending the highest block height data of the target service node to the detection equipment when receiving the block height detection request sent by the detection equipment based on the heartbeat connection relation, so that the detection equipment stores the relation between the highest block height data and the target service node;

And the backup data generation module is used for carrying out backup processing on the blockchain data of the target service node when receiving a data backup request sent by the detection equipment based on the heartbeat connection relation, generating service node backup data, and sending the service node backup data to the detection equipment so that the detection equipment provides data recovery service based on the service node backup data when the target service node is in an unavailable state.

Wherein, the consensus execution module includes:

the business transaction packaging unit is used for packaging business transactions into blocks to be uplinked through the execution clients associated with the target client language types, and executing the business transactions in the blocks to be uplinked to obtain transaction execution results;

the broadcasting unit is used for broadcasting the block to be uplinked and the transaction execution result to each service node in the block chain service node cluster through the consensus client associated with the target client language type so that each service node in the block chain service node cluster performs consensus voting on the block to be uplinked and the transaction execution result together;

and the upgradeable block determining unit is used for determining the block to be upgradeable as the upgradeable block if the consensus of the block to be upgradeable and the transaction execution result is successful, and storing the upgradeable block and the transaction execution result into the blockchain ledger.

the type matching module is used for receiving a service request carrying service transaction sent by the terminal equipment by the gateway equipment, and respectively matching the service type corresponding to the service transaction with the client language types of the S blockchain clients to obtain a target client language type matched with the service type of the service transaction;

the node sub-cluster determining module is used for determining a service node sub-cluster associated with the target client language type;

the node subset group scheduling module is used for scheduling and selecting the service node subset group associated with the target client language type to obtain a target service node selected by scheduling;

and the business transaction forwarding module is used for forwarding the business transaction to the target service node so that the target service node can execute and consensus the business transaction in the blockchain service node cluster through the execution client and the consensus client which are associated with the language type of the target client.

Wherein, the data processing device still includes:

the signature information acquisition module is used for acquiring interface signature information in the service request; the interface signature information is obtained by signing the business transaction by the terminal equipment based on the terminal private key;

The signature verification module is used for carrying out signature verification on the interface signature information based on the terminal public key corresponding to the terminal private key to obtain a signature verification result;

the matching execution module is used for executing the step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients respectively if the signature verification result is a verification passing result;

and the failure message sending module is used for sending a transaction processing failure message to the terminal equipment if the signature verification result is a verification failure result.

The node subset group scheduling module comprises:

the request head data acquisition unit is used for acquiring request head data corresponding to the service request and acquiring scheduling requirement parameters carried by the request head data;

the scheduling unit is used for scheduling and selecting the service node sub-cluster associated with the target client language type through the scheduling requirement parameter;

and the target service node acquisition unit is used for acquiring the target service node selected by scheduling.

Wherein the scheduling unit includes:

a time-consuming data request sending subunit, configured to send, to the detection device, a time-consuming data request for a service node sub-cluster associated with the target client language type if the scheduling requirement parameter is a time-consuming requirement parameter;

The time-consuming data receiving subunit is used for receiving time-consuming data returned by the detection equipment based on the time-consuming data request; the time-consuming data includes a request response time consumption for each service node in the sub-cluster of service nodes associated with the target client language type;

the service node sequencing subunit is configured to sequence the request response time consumption of each service node in the service node sub-cluster associated with the target client language type, and determine the service node corresponding to the minimum request response time consumption in the sequenced request response time consumption as the target service node.

Wherein the scheduling unit includes:

the service node load detection subunit is used for carrying out service node load detection in the service node sub-cluster associated with the target client language type if the scheduling demand parameter is the load demand parameter, so as to obtain the load to be processed and the load processing rate of each service node in the service node sub-cluster associated with the target client language type;

and the load index subunit is used for generating a load index corresponding to each service node in the service node sub-cluster associated with the target client language type according to the load quantity to be processed and the load processing rate, and determining the service node with the minimum load index as the target service node.

Wherein the scheduling unit includes:

a block height data request sending subunit, configured to send, to the detection device, a block height data request for a service node sub-cluster associated with the target client language type if the scheduling requirement parameter is a block height threshold;

a block height data set receiving subunit, configured to receive a block height data set returned by the detection device based on the block height data request; the block height data set comprises the latest block height corresponding to each service node in the service node sub-cluster associated with the target client language type;

and the service node to be scheduled determining subunit is used for determining the service node with the latest block height larger than the block height threshold as the service node to be scheduled, and selecting a target service node from the service nodes to be scheduled.

Wherein, the data processing device still includes:

the service node deleting module is used for deleting the service node corresponding to the inactivation mark information and the service node corresponding to the block height low mark information in the initial block chain service node cluster when the gateway equipment acquires the inactivation mark information and the block height low mark information sent by the detection equipment, so as to obtain the block chain service node cluster; the inactivation mark information refers to mark information of a service node which does not establish a heartbeat connection relationship with the detection equipment within a set time range; the block height low flag information refers to flag information of a service node whose absolute value of a difference value between a block height and a global highest block height is greater than a difference threshold, and the global highest block height is a service node with a maximum block height in an initial block chain service node cluster.

In one aspect, the application provides a computer device comprising: a processor, a memory, a network interface;

the processor is connected to the memory and the network interface, where the network interface is used to provide a data communication function, the memory is used to store a computer program, and the processor is used to call the computer program to make the computer device execute the method in the embodiment of the present application.

In one aspect, embodiments of the present application provide a computer readable storage medium having a computer program stored therein, the computer program being adapted to be loaded by a processor and to perform a method according to embodiments of the present application.

In one aspect, embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium; the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the method in the embodiment of the present application.

In the embodiment of the application, the client language type of the target service node can be one of a plurality of client language types, and the service transaction sent by the gateway equipment is received through the target service node. The gateway device is used for determining a target client language type matched with the service type of the service transaction in the client language types of the S blockchain clients, and is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types. Further, the target service node co-executes and co-shares business transactions in the blockchain service node cluster through the execution client and the co-shares client associated with the target client language type. The embodiment of the application can enable the service nodes in a group of service node sub-clusters to be mutually replaced through the block chain service node cluster formed by the service nodes with various client language types, thereby expanding the way of the service nodes for providing business transaction service and improving the diversity of the block chain service node cluster. Further, when one node in the blockchain service node cluster fails, the gateway equipment can schedule the service transaction originally distributed to the failed service node to other proper service nodes, so that the service transaction problem when the service node fails at a single point is solved. It should be appreciated that in embodiments of the present application, a blockchain service node cluster includes multiple client language type service nodes (i.e., multiple versions of service nodes). Therefore, when a service node of a certain client language type (i.e., a service node of a certain version) in the blockchain service cluster is in a fault state, the gateway device can schedule service transactions to service nodes of other client language types (i.e., service nodes of other versions) in other non-fault states, so that interference to service processing of the blockchain service node cluster when the client of the certain language type is in a fault state is reduced, namely, the service nodes corresponding to the clients of other non-fault states can normally operate, the fault tolerance performance of the blockchain service node cluster is improved, and the security of the blockchain node cluster is ensured. By adopting the embodiment of the application, the safety of the block chain service node system can be improved.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a blockchain network according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a scenario regarding a business transaction according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of a data processing method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a scenario regarding an execution client and a consensus client according to an embodiment of the present application;

FIG. 5 is a schematic diagram of another scenario regarding an execution client and a consensus client according to an embodiment of the present application;

FIG. 6 is a flowchart of another data processing method according to an embodiment of the present application;

FIG. 7 is a timing diagram of a business transaction according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;

FIG. 9 is a schematic diagram of another data processing apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

It will be appreciated that in particular embodiments of the present application, where data relating to an object or user (e.g., payment data) is involved, when the following embodiments of the present application are applied to particular products or technologies, user approval or consent is required and the collection, use and processing of the relevant data is required to comply with relevant national and regional laws and regulations and standards.

The scheme provided by the embodiment of the application relates to a block chain technology, and the specific process is illustrated by the following embodiment.

Referring to fig. 1, fig. 1 is a schematic diagram of a blockchain network according to an embodiment of the present application. The blockchain network as shown in fig. 1 may include, but is not limited to, a distributed network corresponding to blockchain traffic. The blockchain network may include a plurality of blockchain nodes, and the plurality of blockchain nodes may include a blockchain node 10a, a blockchain node 10b, a blockchain node 10c, a blockchain node 10d, …, and a blockchain node 10n. For example, a blockchain node may be a client or server in a distributed network to which blockchain traffic corresponds. Each blockchain node can receive data sent by the outside during normal operation, perform blockchain uplink processing based on the received data, and also can send the data to the outside. To ensure data interworking between the various blockchain nodes, a data connection may exist between each blockchain node, such as between blockchain node 10a and blockchain node 10b, between blockchain node 10a and blockchain node 10c, and between blockchain node 10b and blockchain node 10 c.

It will be appreciated that data or block transfer may be performed between the blockchain nodes via the data connections described above. The blockchain network may implement data connection between blockchain nodes based on node identifiers, and for each blockchain node in the blockchain network, each blockchain node may store node identifiers of other blockchain nodes having a connection relationship with itself, so as to broadcast the acquired data or generated blocks to other blockchain nodes according to the node identifiers of the other blockchain nodes, for example, the blockchain node 10a may maintain a node identifier list as shown in table 1, where the node identifier list stores node names and node identifiers of the other nodes:

TABLE 1

The node identifier may be any of a protocol (Internet Protocol, IP) address for interconnection between networks, and any other information that can be used to identify a node in a blockchain network, and the IP address is only illustrated in table 1. For example, the blockchain node 10a may send blockchain data (e.g., encrypted data packed in blockwise format) to the blockchain node 10b through the node identification bbb.bbb.bbb.bbb.bbb, and the blockchain node 10b may determine that the information was sent by the blockchain node 10a through the node identification aaa.aaa.aaa.

In a blockchain, a block must be consensus-passed through consensus nodes in the blockchain network before the block is uplink, and the block can be added to the blockchain after the consensus passes. It will be appreciated that when a blockchain is used in some scenarios in an establishment, not all participating nodes in the blockchain (i.e., blockchain nodes in the blockchain network described above) have sufficient resources and necessity to become consensus nodes of the blockchain. For example, in the blockchain network shown in fig. 1, blockchain node 10a, blockchain node 10b, blockchain node 10c, and blockchain node 10d may be considered as consensus nodes in the blockchain network. The consensus nodes in the blockchain network participate in consensus, namely, consensus is carried out on the blocks (comprising a batch of transactions), namely, voting is carried out on the blocks; while non-consensus nodes do not participate in consensus, but will help propagate block and vote messages, and synchronize status with each other, etc.

It can be appreciated that the method provided by the embodiment of the present application may be performed by a computer device, including but not limited to the blockchain node described above (which may be a client or a server in the embodiment of the present application). In the embodiment of the application, the server side can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing a cloud database, cloud service, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, basic cloud computing service such as big data and an artificial intelligent platform. The above-mentioned client may be an electronic device, including, but not limited to, a mobile phone, a tablet computer, a desktop computer, a notebook computer, a palm computer, a vehicle-mounted device, an augmented Reality/Virtual Reality (AR/VR) device, a head-mounted display, a smart television, a wearable device, a smart speaker, a digital camera, a camera, and other mobile internet devices (mobile internet device, MID) with network access capability, or a terminal device in a scene such as a train, a ship, or a flight.

It is to be appreciated that embodiments of the present application may be applied to a variety of scenarios including, but not limited to, cloud technology, artificial intelligence, intelligent transportation, etc. For example, the block link point system may perform consensus on some driving behavior data, road track data, and the like sent by the vehicle-mounted terminal, and store the consensus on the vehicle-mounted terminal after the consensus passes.

It will be appreciated that in a specific embodiment, for example, when a business object needs to manage data assets through its own smart device, a business transaction may be initiated by a personal smart car or smart watch, VR device, etc., a business request carrying the business transaction may be sent to the gateway device, and the business transaction may be sent to the target service node through the gateway device. Further, the gateway device receives a service transaction result of the target service node for service transaction, and the gateway device sends the service transaction result to terminal devices such as a personal intelligent automobile or an intelligent watch, a VR device and the like which initiate service transaction.

The computer device mentioned in the present application may be a server or a client, or may be a system composed of a server and a client.

Further, referring to fig. 2, fig. 2 is a schematic view of a scenario regarding a business transaction according to an embodiment of the present application. As shown in fig. 2, the blockchain service node cluster 2C may include M service nodes, where M service nodes may include service node 24C, service node 25C, service nodes 26C, … …, and service nodes qC, q are positive integers. The M service nodes may include target service nodes, where the M service nodes are composed of S service node sub-clusters, the blockchain clients configured by the service nodes in a group of service node sub-clusters are the same, the blockchain clients respectively configured by different service node sub-clusters are different from each other, the blockchain clients include execution clients and consensus clients, M and S are both positive integers, and S is less than or equal to M. For example, if the execution client of one service node in a group of service node sub-clusters is an execution client of a programming language (golang language) type, the execution clients of other service nodes in the group of service node sub-clusters are all execution clients of a programming language (golang language) type. Correspondingly, if the common client of one service node in the service node sub-cluster is a common client of a programming language (rust language) type, the common clients of other service nodes in the service node sub-cluster are all common clients of a programming language (golang language) type. Wherein, the execution client refers to a client for executing intelligent contracts and processing specific operation steps. Accordingly, a consensus client refers to a client for verifying a consensus business transaction on a consensus network. Specifically, the execution client of any one client language type and the consensus client of any one client language type are combined to obtain the service node.

For example, in one particular embodiment, a group of service node sub-clusters may include service node 24C, service node 25C, and service node 26C. Wherein the execution clients of the group of service node sub-clusters may be execution clients of a programming language (golang language) type. That is, the execution client of the service node 24C is a programming language (golang language) type execution client, the execution client of the service node 25C is also a programming language (golang language) type execution client, and the execution client of the service node 26C is also a programming language (golang language) type execution client. Accordingly, the consensus clients of the subset of the set of service nodes may all be consensus clients of the programming language (rust language) type. That is, the consensus client of the service node 24C is a consensus client of a programming language (rust language) type, the consensus client of the service node 25C is also a consensus client of a programming language (rust language) type, and the consensus client of the service node 26C is also a consensus client of a programming language (rust language) type.

In particular, the target service node may receive the traffic transaction sent by gateway device 22F. Wherein the service transaction is sent by the terminal device 21A to the gateway device 22F, the gateway device 22F is configured to determine a target client language type matching the service type of the service transaction from among the client language types of the S blockchain clients, and the gateway device is further configured to schedule the target service node in the service node sub-cluster associated with the target client language type. Further, the business transaction is commonly performed and consensus among the blockchain service node clusters by the execution client and the consensus client associated with the target client language type. Further, the target service node may receive the communication detection data sent by the detection device 23P, and establish a heartbeat connection relationship with the detection device 23P in a period indicated by the communication detection data. The gateway device may send the state data corresponding to each service node to the detecting device 23P at regular time, so that the gateway device may schedule the service node by using the state data, recorded by the detecting device 23P, of each service node in different time periods, so as to schedule and determine the target service node. Specifically, the state data may include current block height data and current state data (such as a failure state or a normal state), etc.

Further, referring to fig. 3, fig. 3 is a flow chart of a data processing method according to an embodiment of the application. As shown in FIG. 3, the method may be performed by a target service node in a cluster of blockchain service nodes, which may be the blockchain node 10b shown in FIG. 1 and described above, without limitation. For easy understanding, the embodiment of the present application is described by taking the method performed by the target service node as an example, and the data processing method may at least include the following steps S101 to S102:

step S101, a target service node receives business transaction sent by gateway equipment; the business transaction is sent by the terminal device to the gateway device, the gateway device is used for determining a target client language type matched with the business type of the business transaction in the client language types of the S blockchain clients, and the gateway device is further used for dispatching out target service nodes in the service node sub-clusters associated with the target client language type.

Specifically, the target service node may receive a service transaction sent by the gateway device for consensus on the blockchain. The block chain service node cluster comprises M service nodes, the M service nodes comprise target service nodes, the M service nodes are composed of S groups of service node sub-clusters, the block chain clients configured by the service nodes in one group of service node sub-clusters are identical, the block chain clients respectively configured by different service node sub-clusters are different from each other, the block chain clients comprise execution clients and consensus clients, M and S are both positive integers, and S is smaller than or equal to M. Wherein, the execution client refers to a client for executing intelligent contracts and processing specific operation steps. Accordingly, a consensus client refers to a client for verifying a consensus business transaction on a consensus network. Specifically, the execution client of any one client language type and the consensus client of any one client language type are combined to obtain the service node. Wherein, the client language type refers to a programming language used in a computer programming process. For example, commonly used client language types may include a programming language (golang language), a programming language (java language), a programming language (rust language), and the like. Further, the target service node may perform communication between the client and the consensus client through a communication protocol in the blockchain protocol. In a particular embodiment, the target service node may communicate and translate between execution clients of different client language types and consensus clients of different client language types via the hypertext transfer (Hypertext Transfer Protocol, HTTP) protocol. For example, the target service node may communicate and translate between the execution client of the golang language type and the consensus client of the rust language type via the hypertext transfer (Hypertext Transfer Protocol, HTTP) protocol. In a specific embodiment, a service node formed by an execution client of any client language type and a consensus client of any client language type may provide a set of remote procedure call transfer protocol (JSON-RPC) interfaces to the outside. Wherein, the interface applies a cross-language remote call protocol in a programming language object profile (JavaScript Object Notation, JSON) format. Wherein the remote procedure call transfer protocol (JSON-RPC) uses HTTP as the communication protocol. Specifically, the JSON-RPC interface may include components such as a request message, a response message, a version number, and a method name. Wherein the request message may include a method name and request parameters of the request; wherein the response message may include the result of the response and error information; wherein the version number may include version data for identifying the JSON-RPC interface; wherein the method name may be used to indicate the method that needs to be invoked. For example, in one particular embodiment, the JSON language may include four basic type components (String, numbers, boolean and Null) and two structured type components (Objects and Array).

In a specific embodiment, the target service node may communicate with the gateway device through JSON-RPC interfaces provided externally by the execution client and the consensus client. Specifically, the JSON-RPC interface may include queries for blocks, transactions, event logs. Specifically, the execution client may include: a geth client and an erigon client in a golang language, a nethermid client in a javascript language, an akula client in a java language and a besu client in a rust language. Accordingly, the consensus client may include: a prysm client in a golang language, a teku client in a java language, a nimbus client in a nim language, a lodestar client in a javascript language and a lightouse client in a rust language.

In particular, business transactions are understood in a broad sense as computer terms transactions (transactions). Accordingly, in a refinement, a business transaction refers to a transfer of data across a blockchain. For example, the business transaction may include asset transfer between usage objects of the blockchain business, data transfer of blockchain associations, or transfer of executing a smart contract, etc. In another aspect, a business transaction may include a business request, an operation that needs to be submitted to a blockchain network to perform, from the component of the business transaction. Further, the target service node may send the traffic transaction to the gateway device. That is, communication may be made between the target serving node and the gateway device. In particular, other types of messages, such as notification messages, or time stamps, etc., may also be sent between the target serving node and the gateway device.

Further, the blockchain service node cluster can be formed into M service nodes by arranging consensus clients of different language types and execution clients of different language types. The at least two execution clients and the at least two consensus clients may form a blockchain service node cluster, and the blockchain service node cluster formed by the M service nodes may include S groups of service node sub-clusters. For ease of understanding, please refer to fig. 4, fig. 4 is a schematic diagram of a scenario regarding an execution client and a consensus client according to an embodiment of the present application. In fig. 4, in one possible embodiment, the specific configuration of the service node may be as shown in fig. 4: for example, the blockchain serving node cluster 4C may include 2 groups of serving node sub-clusters. Among them, the execution clients 41C in the blockchain service node cluster 4C may include a geth client (execution client) 411 in a golang language, a geth client (execution client) 411 in a C, golang language, a geth client (execution client) 413 in a C, golang language, an akula client (execution client) 414C in a C, java language, and an akula client (execution client) 415C in a java language. Accordingly, the consensus clients in the blockchain service node cluster 4C may include a prysm client (consensus client) 421 in the golang language, a prysm client (consensus client) 422 in the C, golang language, a prysm client (consensus client) 423 in the C, nim language, a nimbus client (consensus client) 424C in the nim language, and a nimbus client (consensus client) 425C in the nim language. Specifically, a group of service node sub-clusters only includes execution clients of the same language type and consensus clients of the same language type. For example, in one particular embodiment, one service node sub-cluster may include 5 different service nodes (e.g., service node 431C, service node 432C, service node 433C, service node 434C, and service node 435C), which 5 different service nodes (i.e., service node 431C, service node 432C, service node 433C, service node 434C, and service node 435C) may have executing clients of the same language type, and which 5 different service nodes have consensus clients of the same language type. Accordingly, the other group of service node sub-clusters only contains execution clients of the other language type and consensus clients of the other language type. For example, in one particular embodiment, one service node sub-cluster may include 5 different service nodes (e.g., service node 441C, service node 442C, service node 443C, service node 444C, and service node 445C), the 5 different service nodes (i.e., service node 441C, service node 442C, service node 443C, service node 444C, and service node 445C) may have executing clients of the same language type, and the 5 different service nodes have consensus clients of the same language type. In other words, more than 2 execution clients or consensus clients of different language types may not appear in one service node sub-cluster. As another example, in one particular embodiment, there are 6 different service nodes (e.g., service node 451C, service node 452C, service node 453C, service node 454C, service node 455C, and service node 456C), the 6 different service nodes (i.e., service node 451C, service node 452C, service node 453C, service node 454C, service node 455C, and service node 456C) may have executing clients of the same language type, and the 6 different service nodes may have consensus clients of the same language type. That is, different service nodes may have executing clients of the same language type and have consensus clients of the same language type, the different service nodes belonging to the same group of service node sub-clusters.

For ease of understanding, fig. 5 is a schematic diagram of another scenario regarding an execution client and a consensus client according to an embodiment of the present application. In fig. 5, in one possible embodiment, the service node may be configured as shown in fig. 5: the blockchain serving node cluster 5C may include 25 groups of serving node sub-clusters. The execution clients 51C in the blockchain service node cluster 5C may include: a geth client (execution client) 511C in the golang language, a nethermind client (execution client) 513C, java in the language of the erigon client (execution client) 511C, and a besu client (execution client) 515C in the rust language. The consensus client 52C in the blockchain service node cluster 5C includes: a prysm client (consensus client) 521 in the golang language, a teku client (consensus client) 522 in the C, java language, a nimbus client (consensus client) 523 in the C, nim language, a lodestar client (consensus client) 524C in the C, javascript language, and a lightouse client (consensus client) 525C in the rust language. In the embodiment of the present application, the number of service nodes in each group of service node sub-clusters may be 1. That is, the blockchain service node cluster 5C may include 25 service nodes. Specifically, a group of service node sub-clusters only includes execution clients of the same language type and consensus clients of the same language type. For example, in one particular embodiment, one service node sub-cluster may include 4 different service nodes (e.g., service node 531C, service node 532C, service node 533C, and service node 534C), the 4 different service nodes (i.e., service node 531C, service node 532C, service node 533C, and service node 534C) may have executing clients of the same language type, and the 4 different service nodes have consensus clients of the same language type. Accordingly, the other group of service node sub-clusters only contains execution clients of the other language type and consensus clients of the other language type. For example, in one particular embodiment, one service node sub-cluster may include 3 different service nodes (e.g., service node 541C, service node 542C, and service node 543C), the 3 different service nodes (i.e., service node 541C, service node 542C, and service node 543C) may have executing clients of the same language type, and the 3 different service nodes have consensus clients of the same language type. In other words, more than 2 execution clients or consensus clients of different language types may not appear in one service node sub-cluster. For another example, in one particular embodiment, there are 7 different service nodes (e.g., service node 551C, service node 552C, service node 553C, service node 554C, service node 555C, service node 556C, and service node 557C), the 7 different service nodes (i.e., service node 551C, service node 552C, service node 553C, service node 554C, service node 555C, service node 556C, and service node 557C) may have executing clients of the same language type, and the 7 different service nodes may have consensus clients of the same language type. That is, different service nodes may have executing clients of the same language type and have consensus clients of the same language type, the different service nodes belonging to the same group of service node sub-clusters.

Further, the target service node may receive the communication detection data sent by the detection device, and establish a heartbeat connection relationship with the detection device in a period indicated by the communication detection data. Further, when the block height detection request sent by the detection device is received based on the heartbeat connection relationship, the target service node may send the highest block height data of the target service node to the detection device, so that the detection device stores the relationship between the highest block height data and the target service node. Further, when receiving the data backup request sent by the detection device based on the heartbeat connection relationship, the target service node can perform backup processing on the blockchain data of the target service node to generate service node backup data, and send the service node backup data to the detection device, so that the detection device provides data recovery service based on the service node backup data when the target service node is in an unavailable state. The heartbeat connection relationship established between the target service node and the detection device may refer to a communication state, for example, the heartbeat connection relationship may be established between the target service node and the detection device through http. The block height refers to the number of blocks between a block and the created block. The creation block is the first block on a block chain, that is, the creation block is the starting point and the base of the whole chain. In particular, the detection device may refer to a device for performing a detection function. Optionally, the detection device may send the detection message to the target service node, and obtain a detection result according to a reply of the target service node to the detection message, and further send the detection result to the gateway device, so that the gateway device schedules task allocation of the target service node.

Step S102, executing and consensus business transaction in the blockchain service node cluster through an executing client and a consensus client associated with the target client language type.

Specifically, the target service node may detect an operation state of the S-group service node sub-cluster. Further, if the service node sub-cluster with the running state being the fault state exists in the S group of service node sub-clusters, the service node sub-cluster with the running state being the fault state is subjected to fault marking. Further, the target service node determines the service node subset group which is not marked by the fault as a service node subset group in a normal state, and commonly executes and consensus business transaction in the service node subset group in the normal state through an execution client and a consensus client which are associated with the language type of the target client. Where Consensus (Consensus) may refer to a process in a blockchain network for agreeing on transactions in blocks among the multiple service nodes involved, the agreed blocks will be appended to the tail of the blockchain.

Specifically, the target service node may package the business transaction into a block to be uplink through the execution client associated with the target client language type, and execute the business transaction in the block to be uplink to obtain a transaction execution result. Further, the target service node may broadcast the to-be-uplinked block and the transaction execution result to each normal-state service node in the blockchain service node cluster through a consensus client associated with the target client language type, so that each normal-state service node in the blockchain service node cluster performs a consensus vote on the to-be-uplinked block and the transaction execution result together. Further, if the consensus of the block to be uplinked and the transaction execution result is successful, the block to be uplinked is determined to be the uplinkable block, and the uplinkable block and the transaction execution result are stored in the blockchain ledger.

It can be understood that, in the specific embodiment of the present application, data such as data related to a business transaction, data corresponding to a service node, and data associated with a gateway device are related, and when the above and following embodiments of the present application are applied to specific products or technologies, relevant data collection processing should strictly obtain informed consent or individual consent (or have a legal basis) of a personal information body when the embodiments are applied according to requirements of relevant national laws and regulations, and develop subsequent data use and processing actions within the scope of legal regulations and authorization of the personal information body. When the related face (or other biological characteristics) recognition technology is involved, the related data collection, use and processing processes should comply with national legal regulation requirements, information processing rules should be notified and independent consent (or legal basis) of a target object should be solicited before face information is collected, and the face information is processed strictly according to legal regulation requirements and personal information processing rules, so that technical measures are taken to ensure the safety of related data.

In the embodiment of the application, the client language type of the target service node can be one of a plurality of client language types, and the service transaction sent by the gateway equipment is received through the target service node. The gateway device is used for determining a target client language type matched with the service type of the service transaction in the client language types of the S blockchain clients, and is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types. Further, the target service node co-executes and co-shares business transactions in the blockchain service node cluster through the execution client and the co-shares client associated with the target client language type. The embodiment of the application can enable the service nodes in a group of service node sub-clusters to be mutually replaced through the block chain service node cluster formed by the service nodes with various client language types, thereby expanding the way of the service nodes for providing business transaction service and improving the diversity of the block chain service node cluster. Further, when one node in the blockchain service node cluster fails, the gateway equipment can schedule the service transaction originally distributed to the failed service node to other proper service nodes, so that the service transaction problem when the service node fails at a single point is solved. It should be appreciated that in embodiments of the present application, a blockchain service node cluster includes multiple client language type service nodes (i.e., multiple versions of service nodes). Further, when a service node of a certain client language type (i.e., a service node of a certain version) in the blockchain service cluster is in a fault state, the gateway device can schedule service transactions to service nodes of other client language types (i.e., service nodes of other versions) in other non-fault states, so that interference to service processing of the blockchain service node cluster when the client of the certain language type is in a fault state is reduced, namely, the service nodes corresponding to the clients of other non-fault states can normally operate, fault tolerance performance of the blockchain service node cluster is improved, and safety of the blockchain node cluster is ensured. By adopting the embodiment of the application, the safety of the block chain service node system can be improved.

Further, referring to fig. 6, fig. 6 is a flowchart illustrating another data processing method according to an embodiment of the present application. As shown in fig. 6, the method may be performed by a gateway device connected to a target service node in the blockchain service node cluster, and the gateway device may be a gateway device connected to the blockchain node 10b (i.e., the target service node) shown in fig. 1 and is not limited herein. For easy understanding, the embodiment of the present application is described by taking the method performed by the gateway device as an example, and the data processing method may at least include the following steps S201 to S204:

in step S201, the gateway device receives a service request carrying a service transaction sent by the terminal device, and matches service types corresponding to the service transaction with client language types of S blockchain clients, so as to obtain a target client language type matched with the service types of the service transaction.

Specifically, the blockchain service node cluster includes M service nodes, where the M service nodes include target service nodes, the M service nodes are composed of S service node subsets, the blockchain clients configured by the service nodes in a service node subset are the same, the blockchain clients respectively configured by different service node subsets are different, the blockchain clients include execution clients and consensus clients, M and S are both positive integers, and S is less than or equal to M. Specifically, the gateway device may obtain a service transaction in the service request sent by the terminal device, and detect a service type corresponding to the service transaction. Specifically, the service type corresponding to the service transaction may be included in the request header data, for example, the service transaction may refer to a transfer transaction, and the type corresponding to the service transaction may be a first transaction type. The gateway device may divide the service types into a plurality of first transaction types, a plurality of second transaction types, a plurality of … … and a plurality of p transaction types according to the service transaction, wherein p is a positive integer. In particular, the gateway device may determine the total number of traffic types based on historical transaction data. For example, the gateway device may determine that the total number of traffic types is 2 based on the historical transaction data, that is, when the traffic types include the first transaction type and the second transaction type. Specifically, the first transaction type may refer to a data modification class, and the second transaction type may refer to a setting modification class. Optionally, the gateway device may further divide the service types of the service transaction according to the data volume level of the service transaction, where the division of the service types is not specifically limited. For example, the gateway device may determine a first transaction type as a first magnitude type, a second transaction type as a second magnitude type, and so on, based on the magnitude of the data volume of the business transaction. Further, the gateway device may further match the service type corresponding to the service transaction with the client language types of the S blockchain clients according to the association index between the service type and the client language types of the service transaction, to obtain a target client language type matched with the service type of the service transaction. The association index between the business type of the business transaction and the language type of the client side can be obtained by the gateway device through data analysis based on the historical business transaction data record. Further, the gateway device may sort the client language types according to an association index between the service type and the client language type of the service transaction, and determine the client language type with the highest association index as the client language type associated with the service type of the service transaction. Among other things, client language types may refer to programming languages used in a computer programming process. For example, commonly used client language types may include a programming language (golang language), a programming language (java language), a programming language (rust language), and the like. In a particular embodiment, the client language type may include an execution client language type and a consensus client language type. Specifically, for example, the client language types are classified according to the execution client language type and the consensus client language type: the execution clients may include a geth client and an erigon client in a golang language, a nethermed client in a javascript language, an akula client in a java language, and a besu client in a rust language; correspondingly, the consensus client may include a prysm client in the golang language, a teku client in the java language, a nimbus client in the nim language, a lodestar client in the javascript language, and a lightouse client in the rust language. It is understood that a gateway device refers to an intermediate layer device located between a terminal device (i.e. a client) and a service node, which may receive a service request from the terminal device (i.e. a client), perform route forwarding and signature filtering processing according to the service request, and then forward a service transaction to the service node. Specifically, the gateway device has the functions of load balancing, security authentication, current limiting and the like, and can also help developers manage and maintain the architecture of the whole blockchain system.

Further, the gateway device may obtain interface signature information in the service request. The interface signature information is obtained by signing the business transaction by the terminal equipment based on the terminal private key. Further, the gateway device can perform signature verification on the interface signature information based on the terminal public key corresponding to the terminal private key, and a signature verification result is obtained. Further, if the signature verification result is a verification passing result, executing a step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients respectively. Correspondingly, if the signature verification result is a verification failure result, a transaction processing failure message is sent to the terminal equipment. Specifically, the gateway device may obtain a terminal public key corresponding to a terminal private key of the terminal device, and perform signature verification on the interface signature information in the service request through the obtained terminal public key. Specifically, if signature verification is successful, the service request is proved to be qualified for executing the blockchain service. Accordingly, if signature verification fails, the service request is proved to be unqualified for executing the blockchain service.

In a specific embodiment, the interface signature information acquired by the gateway device may include a programming language object profile signature (JSON Web Token, JWT), which is an open signature standard (RFC 7519), and belongs to a compact, self-contained signature information that may be used as a signature way for JSON objects to securely transfer information between blockchain parties. Specifically, the gateway device can verify the interface signature information in a data signature manner, and obtain the credibility of the interface signature information. Specifically, JWT is generally composed of three parts: header, payload, and signature. The header of the JWT may include information such as the type, algorithm, and key of the token corresponding to the interface signature information, and the payload of the JWT includes identity information of the user, where the signature of the JWT may ensure that the interface signature information corresponds to the token without tampering.

Step S202, determining a service node sub-cluster associated with the target client language type.

Specifically, the gateway device may sort the service types of the service transaction according to the association index between the service type and the client language type of the service transaction, and select the client language type with the highest association index to determine the client language type associated with the service type of the service transaction. Further, the gateway device may determine the service node sub-cluster corresponding to the highest association index as the service node sub-cluster associated with the target client language type. For example, the service node sub-cluster associated with the target client language type determined by the gateway device may be a service node sub-cluster composed of a geth client (execution client) of the golang language and a prysm client (consensus client) of the golang language.

Step S203, scheduling selection is performed on the service node subset group associated with the target client language type, and the target service node selected by scheduling is obtained.

Specifically, the gateway device may obtain request header data corresponding to the service request, and obtain a scheduling requirement parameter carried by the request header data. Further, the gateway device may perform scheduling selection in the service node sub-cluster associated with the target client language type through the scheduling requirement parameter, to obtain a target service node selected by scheduling. In a particular embodiment, for example, the request header data may include a request header key pair, and in particular, the request header key pair may include a request header key (key) and a request header value (value). Further, the gateway device may determine a request header key value pair in the request header data as the scheduling requirement parameter. That is, the gateway device may obtain the target service node selected by scheduling the service node sub-cluster associated with the target client language type by requesting the header key value.

Specifically, a specific implementation procedure of one possible scheduling selection may be as follows: if the scheduling requirement parameter is a time-consuming requirement parameter, the gateway device sends a time-consuming data request for the service node sub-cluster associated with the target client language type to the detection device. Further, the gateway device may receive time-consuming data returned by the detection device based on the time-consuming data request. Wherein the time consuming data comprises a request response time consuming for each service node in the sub-cluster of service nodes associated with the target client language type. Further, the gateway device may sort the request response time consumption of each service node in the service node sub-cluster associated with the target client language type, and determine the service node corresponding to the minimum request response time consumption of the sorted request response time consumption as the target service node.

In particular, another possible implementation procedure of scheduling selection may be as follows: if the scheduling demand parameter is a load demand parameter, the gateway device performs service node load detection in the service node sub-cluster associated with the target client language type, and obtains the load quantity to be processed and the load processing rate of each service node in the service node sub-cluster associated with the target client language type. Further, the gateway device may generate a load index corresponding to each service node in the service node sub-cluster associated with the target client language type according to the load amount to be processed and the load processing rate, and determine the service node with the smallest load index as the target service node.

In particular, a further possible implementation of the scheduling selection may be as follows: if the scheduling requirement parameter is a block height threshold, the gateway device sends a block height data request for a service node sub-cluster associated with the target client language type to the detection device. Further, the gateway device may receive a block height data set returned by the detection device based on the block height data request. The block height data set comprises the latest block height corresponding to each service node in the service node sub-cluster associated with the target client language type. Further, the gateway device may determine a service node with a latest block height greater than the block height threshold as a service node to be scheduled, and select a target service node from the service nodes to be scheduled. For example, the gateway device may select a service node with the highest block height from the service nodes to be scheduled as the target service node.

Step S204, forwarding the business transaction to the target service node, so that the target service node can execute and agree the business transaction in the blockchain service node cluster through the execution client and the consensus client associated with the target client language type.

Further, when the gateway equipment acquires the inactivation mark information and the block height low mark information sent by the detection equipment, deleting the service node corresponding to the inactivation mark information and the service node corresponding to the block height low mark information in the initial block chain service node cluster to obtain a block chain service node cluster; the inactivation mark information refers to mark information of a service node which does not establish a heartbeat connection relationship with the detection equipment within a set time range; the block height low flag information refers to flag information of a service node whose absolute value of a difference value between a block height and a global highest block height is greater than a difference threshold, and the global highest block height is a service node with a maximum block height in an initial block chain service node cluster.

It should be appreciated that in the embodiments of the present application, various measures are employed to ensure that the target service node in the blockchain service node cluster operates properly, such as redundancy design, load balancing, failover, etc. The redundancy design refers to adding spare parts or devices (such as service nodes with different client language types) into a blockchain service node cluster so that the spare parts or devices can be automatically switched to when the main device fails. For example, in a data center of a blockchain service node cluster, multiple service nodes may be used to store data and a load balancer may be used to distribute requests to different service nodes to ensure that other service nodes may continue to provide service should one service node fail. Load balancing is a technique for distributing traffic over multiple service nodes so that the burden on a single service node can be reduced when it is overloaded. In particular, the load balancer may allocate traffic transactions in a traffic request to different service nodes according to different algorithms (e.g., polling, minimum number of connections, etc.). Wherein, the failover refers to that when a service node in the blockchain service node cluster fails, the workload can be transferred to other available service nodes. For example, in a distributed database system, if a primary service node fails, a backup service node may be used to take over the workload of the primary service node. The embodiment of the application realizes the high availability of the block chain service node cluster through the measures of redundancy design, load balancing, fault transfer and the like, namely, when the service nodes in the block chain service node cluster fail, the block chain service node cluster has the service capability of continuously providing service transaction processing.

Optionally, it should be noted that, in the embodiment of the present application, the gateway device may directly schedule the service node with the highest block height as the target service node. That is, the gateway device may not perform the step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients, respectively, and directly schedule the service node with the highest blockheight as the target service node. It should be understood that in the embodiment of the present application, the matching process of the client language type may not be performed, and the scheduling may be directly performed based on the service node with the highest block height. For example, in a specific embodiment, the request header key may be a Route Type (Route-Type), the request header value may be a Latest high service Node (last-Node), and the scheduling requirement parameter in the request header data is a block height threshold, where the service request indicates that the gateway device is required to send the service transaction to the target service Node with the Latest block height (i.e., the maximum block height).

Alternatively, the gateway device may directly schedule the service node with the minimum block height as the target service node. That is, the gateway device may not perform the step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients, respectively, and directly schedule the service node with the minimum blockheight as the target service node. It should be understood that in the embodiment of the present application, the matching process of the client language type may not be performed, and the scheduling may be directly performed based on the service node with the highest block height. For example, in a specific embodiment, the request header key may be a Route Type (Route-Type), the request header value may be a minimum Height (Least-Height), and the scheduling requirement parameter in the request header data is a block Height threshold, where the service request indicates that the gateway device is required to send the service transaction to the target service node with the minimum block Height.

Optionally, the gateway device may also select the target service node by using a consistent hash word (key). That is, the gateway device may directly schedule the target service node through the consistency hash word (key) without performing the step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients, respectively. Specifically, the gateway device may query history information of the service request, determine a history hash key of the service request according to the history information of the service request, obtain a service node corresponding to the history hash key, and determine the service node corresponding to the history hash key as the target service node. The gateway equipment can select the target service node through the consistent hash key, so that the service transaction corresponding to each service request is ensured to be sent to the same service node. In a specific embodiment, for example, the request header key may be a Route Type (Route-Type), the request header value may be a consistency Hash word (consistency-Hash), and the scheduling requirement parameter in the request header data is a consistency Hash word, where the service request indicates that the gateway device is required to send the service transaction to the target service node corresponding to the consistency Hash word.

Optionally, in a specific embodiment, the request header Key may be a consistency word (consistency-Key), the request header value may be a hash word (i.e. a consistency hash Key of any string type), and the scheduling requirement parameter in the request header data is a consistency hash word, where the service request indicates that the gateway device is required to send the service transaction to the target service node corresponding to the consistency hash word. Further, the request header data may be used in combination with request header data of which the request header key is a Route Type (Route-Type) and the request header value is a Consistent Hash word (consistency-Hash), that is, the gateway device may select the target service node through the Consistent Hash key.

Optionally, in a specific embodiment, the request header key may be a minimum Height (class-Height), the request header value may be a block Height, and then the scheduling requirement parameter in the request header data is a block Height, where the service request indicates that the gateway device may determine a service node with a latest block Height smaller than a block Height threshold as a service node to be scheduled, and select a target service node in the service node to be scheduled. Further, the request header data may be used in combination with request header data whose request header key is a Route Type (Route-Type) and whose request header value is a minimum Height (Least-Height), i.e., the gateway device may send the service transaction to the target service node with the minimum block Height.

In the embodiment of the application, a gateway device receives a service request carrying service transaction sent by a terminal device, and the service type corresponding to the service transaction is respectively matched with the client language types of S blockchain clients to obtain a target client language type matched with the service type of the service transaction; determining a sub-cluster of service nodes associated with the target client language type; scheduling and selecting the service node subset group associated with the target client language type to obtain a target service node selected by scheduling; the business transaction is forwarded to the target service node such that the target service node co-executes and co-shares the business transaction in the blockchain service node cluster through the execution client and the co-shares client associated with the target client language type. The embodiment of the application can enable the service nodes in a group of service node sub-clusters to be mutually replaced through the block chain service node cluster formed by the service nodes with various client language types, thereby expanding the way of the service nodes for providing business transaction service and improving the diversity of the block chain service node cluster. Further, when one node in the blockchain service node cluster fails, the gateway equipment can schedule the service transaction originally distributed to the failed service node to other proper service nodes, so that the service transaction problem when the service node fails at a single point is solved. It should be appreciated that in embodiments of the present application, a blockchain service node cluster includes multiple client language type service nodes (i.e., multiple versions of service nodes). Further, when a service node of a certain client language type (i.e., a service node of a certain version) in the blockchain service cluster is in a fault state, the gateway device can schedule service transactions to service nodes of other client language types (i.e., service nodes of other versions) in other non-fault states, so that interference to service processing of the blockchain service node cluster when the client of the certain language type is in a fault state is reduced, namely, the service nodes corresponding to the clients of other non-fault states can normally operate, fault tolerance performance of the blockchain service node cluster is improved, and safety of the blockchain node cluster is ensured. The detection equipment detects the service nodes and feeds back the gateway equipment, so that the grasping degree of the gateway equipment on the load information (namely the load to be processed and the load processing rate) of the service nodes in the blockchain service node cluster can be improved, the gateway equipment can conveniently select a matched route for service transactions in the service requests when receiving the service requests sent by the terminal equipment, the detection equipment feeds back the load information of the service nodes in the blockchain service node cluster on the basis of the gateway equipment, the time spent on matching the target service nodes with the service transactions is saved, the matching speed of the target service nodes with the service transactions is accelerated, the scheduling speed of the gateway equipment on the service nodes can be improved, the stable transaction environment of the service nodes of the blockchain node cluster for the service transactions is provided, and the safety of the blockchain node cluster is ensured. By adopting the embodiment of the application, the safety of the block chain service node system can be improved.

For convenience of understanding, please refer to fig. 7, fig. 7 is a timing diagram of performing a business transaction according to an embodiment of the present application. In fig. 7, the terminal device, the gateway device, the detecting device and the service node may be regarded as computer devices that perform the business transaction, which are grouped together on one local area network. For ease of understanding, embodiments of the present application will be described with the method being performed by a computer device, and the data processing method may include at least the following steps S70-S78:

in step S70, the terminal device sends a service request carrying a service transaction.

Specifically, the process of the terminal device sending the service request carrying the service transaction is referred to in step S201 in fig. 6, and the detailed description of the process of the gateway device receiving the service request carrying the service transaction sent by the terminal device is omitted here.

Step S71, the gateway device authenticates the service request.

Specifically, the process of authenticating the service request by the gateway device is described in detail with respect to the process of signature verification of the interface signature information in the service request by the gateway device in step S201 in fig. 6, which is not described herein.

In step S72, the gateway device acquires the target client language type.

Specifically, the process of the gateway device obtaining the target client language type is described in detail in step S201 in fig. 6, and the detailed description of the process of the gateway device obtaining the target client language type matched with the service type of the service transaction is omitted here.

In step S73, the gateway device sends a request related to the scheduling requirement parameter to the detection device.

Specifically, if the scheduling requirement parameter is a time-consuming requirement parameter, the gateway device sends a time-consuming data request for the service node sub-cluster associated with the target client language type to the detection device. Further, the gateway device may receive time-consuming data returned by the detection device based on the time-consuming data request. Wherein the time consuming data comprises a request response time consuming for each service node in the sub-cluster of service nodes associated with the target client language type. Further, the gateway device may sort the request response time consumption of each service node in the service node sub-cluster associated with the target client language type, and determine the service node corresponding to the minimum request response time consumption of the sorted request response time consumption as the target service node.

Specifically, in another possible case, if the scheduling requirement parameter is a block height threshold, the gateway device sends a block height data request for the service node sub-cluster associated with the target client language type to the detection device. Further, the gateway device may receive a block height data set returned by the detection device based on the block height data request. The block height data set comprises the latest block height corresponding to each service node in the service node sub-cluster associated with the target client language type. Further, the gateway device may determine a service node with a latest block height greater than the block height threshold as a service node to be scheduled, and select a target service node from the service nodes to be scheduled.

Optionally, if the scheduling requirement parameter is a load requirement parameter, the gateway device performs service node load detection in the service node sub-cluster associated with the target client language type, to obtain a load amount to be processed and a load processing rate of each service node in the service node sub-cluster associated with the target client language type. Further, the gateway device may generate a load index corresponding to each service node in the service node sub-cluster associated with the target client language type according to the load amount to be processed and the load processing rate, and determine the service node with the smallest load index as the target service node.

Specifically, the process of sending the request related to the scheduling requirement parameter by the gateway device to the detecting device is described in detail in step S203 in fig. 6, and the detailed description of the scheduling selection process for the service node sub-cluster associated with the target client language type is omitted here.

In step S74, the detection device sends data requesting return to the gateway device.

Specifically, the process of sending the data requested to be returned by the detection device to the gateway device is described in detail in steps S203-S204 in fig. 6, and the detailed description of the process of sending the block height data, the time-consuming data, the deactivation flag information, etc. by the detection device to the gateway device is omitted here.

Step S75, the gateway equipment dispatches and selects to obtain the target service node.

In particular, the process of scheduling selection by the gateway device is described in detail in step S203 in fig. 6, and the detailed description of the process of scheduling selection of the service node sub-cluster associated with the target client language type is omitted here.

In step S76, the gateway device forwards the business transaction to the target service node.

In particular, the process of forwarding the business transaction to the target service node by the gateway device is described in detail in step S204 in fig. 6, and the detailed description of the process of forwarding the business transaction to the target service node by the gateway device is omitted here.

Step S77, the target service node performs and agrees with the business transaction.

In particular, the process of executing and sharing the service transaction by the target service node is referred to the above detailed description of the process of executing and sharing the service transaction in the blockchain service node cluster in step S102 in fig. 3, and will not be described herein.

In step S78, the target service node sends a service transaction result to the gateway device, and the gateway device sends a service transaction response to the terminal device.

Wherein, the business transaction result refers to the processing result of the business transaction. For example, the business transaction results may include a business transaction success or a business transaction failure, etc. Optionally, the business transaction result may further include a completion time of the business transaction, a failure step of the business transaction, overall process data of the business transaction, and the like.

Wherein, the business transaction response refers to a response to the business transaction result. It is understood that the business transaction response may contain the business transaction results. In particular, the format of the business transaction response may refer to the format of the business request. For example, the business transaction response may use a JSON-RPC interface. In particular, the business transaction response may include a header, a payload, and a signature. Specifically, the description of the service transaction response may be referred to the description related to JWT in step S101 in fig. 3, which is not repeated here.

Further, referring to fig. 8, fig. 8 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing means may be a computer program (comprising program code) running in a computer device, for example the data processing means is an application software; the device can be used for executing corresponding steps in the method provided by the embodiment of the application. As shown in fig. 8, the data processing apparatus 1 is applied to a service management platform, and the data processing apparatus 1 may include: the business transaction receiving module 11 and the consensus executing module 12.

A service transaction receiving module 11, configured to receive a service transaction sent by a gateway device by using a target service node; the business transaction is sent to the gateway equipment by the terminal equipment, the gateway equipment is used for determining a target client language type matched with the business type of the business transaction in the client language types of the S blockchain clients, and the gateway equipment is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types;

the consensus executing module 12 is configured to execute and consensus business transactions in the blockchain service node cluster by executing clients and consensus clients associated with the target client language type.

The specific functional implementation manner of the service transaction receiving module 11 and the consensus executing module 12 may refer to step S101-step S102 in the corresponding embodiment of fig. 3, and will not be described herein.

Referring again to fig. 8, the consensus executing module 12 includes:

an operation state detecting unit 121, configured to detect an operation state of the S-group service node sub-cluster;

the fault marking unit 122 is configured to perform fault marking on the service node subset group whose operation state is the fault state if it is detected that the service node subset group whose operation state is the fault state exists in the S group of service node subset groups;

the consensus executing unit 123 is configured to determine the service node subset group that is not marked by the fault as a service node subset group in a normal state, and execute and consensus business transaction together in the service node subset group in the normal state through an executing client and a consensus client associated with the target client language type.

The specific functional implementation manners of the running state detection unit 121, the fault marking unit 122, and the consensus executing unit 123 may refer to step S102 in the corresponding embodiment of fig. 3, and are not described herein.

Referring again to fig. 8, the data processing apparatus 1 further includes:

the heartbeat connection establishing module 13 is configured to receive communication detection data sent by the detection device, and establish a heartbeat connection relationship with the detection device in a time period indicated by the communication detection data;

the block height sending module 14 is configured to send, when receiving a block height detection request sent by the detection device based on the heartbeat connection relationship, highest block height data of the target service node to the detection device, so that the detection device stores a relationship between the highest block height data and the target service node;

and the backup data generating module 15 is configured to, when receiving a data backup request sent by the detecting device based on the heartbeat connection relationship, perform backup processing on the blockchain data of the target service node, generate service node backup data, and send the service node backup data to the detecting device, so that the detecting device provides a data recovery service based on the service node backup data when the target service node is in an unavailable state.

The specific functional implementation manners of the heartbeat connection establishment module 13, the block height sending module 14, and the backup data generation module 15 may refer to step S101 in the corresponding embodiment of fig. 3, and are not described herein.

Referring again to fig. 8, the consensus executing module 12 includes:

the service transaction packaging unit 124 is configured to package, by using an execution client associated with the target client language type, a service transaction into a block to be uplinked, and perform processing on the service transaction in the block to be uplinked, so as to obtain a transaction execution result;

a broadcasting unit 125, configured to broadcast, by a consensus client associated with the target client language type, the to-be-uplinked block and the transaction execution result to each service node in the blockchain service node cluster, so that each service node in the blockchain service node cluster performs a consensus vote on the to-be-uplinked block and the transaction execution result together;

and the upgradeable block determining unit 126 is configured to determine the to-be-upgradeable block as an upgradeable block if the to-be-upgradeable block and the transaction execution result are successfully identified together, and store the upgradeable block and the transaction execution result in the blockchain ledger.

The specific functional implementation manner of the service transaction packaging unit 124, the broadcasting unit 125, and the uplink block determining unit 126 may refer to step S102 in the corresponding embodiment of fig. 3, and will not be described herein.

Further, referring to fig. 9, fig. 9 is a schematic structural diagram of another data processing apparatus according to an embodiment of the present application. The data processing means may be a computer program (comprising program code) running in a computer device, for example the data processing means is an application software; the device can be used for executing corresponding steps in the method provided by the embodiment of the application. As shown in fig. 9, the data processing apparatus 2 is applied to a service management platform, and the data processing apparatus 2 may include a type matching module 21, a node subset group determining module 22, a node subset group scheduling module 23, and a service transaction forwarding module 24.

The type matching module 21 is configured to receive a service request carrying a service transaction sent by a terminal device, and match service types corresponding to the service transaction with client language types of S blockchain clients respectively, so as to obtain a target client language type matched with the service types of the service transaction;

a node sub-cluster determination module 22 for determining a service node sub-cluster associated with the target client language type;

the node subset scheduling module 23 is configured to perform scheduling selection on a service node subset associated with the target client language type, so as to obtain a target service node selected by scheduling;

the service transaction forwarding module 24 is configured to forward the service transaction to the target service node, so that the target service node performs and consensus service transaction in the blockchain service node cluster through the execution client and the consensus client associated with the target client language type.

The specific functional implementation manners of the type matching module 21, the node subset group determining module 22, the node subset group scheduling module 23, and the service transaction forwarding module 24 may be referred to the above-mentioned step S201-step S204 in the corresponding embodiment of fig. 6, and will not be described herein again.

Referring again to fig. 9, the data processing apparatus 2 further includes:

a signature information acquisition module 25, configured to acquire interface signature information in the service request; the interface signature information is obtained by signing the business transaction by the terminal equipment based on the terminal private key;

the signature verification module 26 is configured to perform signature verification on the interface signature information based on a terminal public key corresponding to the terminal private key, so as to obtain a signature verification result;

the matching execution module 27 is configured to execute a step of matching the service types corresponding to the service transaction with the client language types of the S blockchain clients, respectively, if the signature verification result is a verification passing result;

and the failure message sending module 28 is configured to send a transaction processing failure message to the terminal device if the signature verification result is a verification failure result.

The specific functional implementation manners of the signature information obtaining module 25, the signature verification module 26, the matching execution module 27 and the failure message sending module 28 may refer to step S201 in the corresponding embodiment of fig. 6, and are not described herein.

Referring again to fig. 9, the node subset group scheduling module 23 includes:

a request header data obtaining unit 231, configured to obtain request header data corresponding to the service request, and obtain a scheduling requirement parameter carried by the request header data;

A scheduling unit 232, configured to perform scheduling selection in a service node sub-cluster associated with the target client language type through the scheduling requirement parameter;

the target service node obtaining unit 233 is configured to obtain the target service node selected by the scheduling.

The specific functional implementation manners of the request header data acquiring unit 231, the scheduling unit 232, and the target service node acquiring unit 233 may refer to step S203 in the corresponding embodiment of fig. 6, which is not described herein.

Referring to fig. 9, the scheduling unit 232 includes:

a time-consuming data request sending subunit 2321, configured to send, to the detection device, a time-consuming data request for a service node sub-cluster associated with the target client language type if the scheduling requirement parameter is a time-consuming requirement parameter;

a time-consuming data receiving subunit 2322, configured to receive time-consuming data returned by the detection device based on the time-consuming data request; the time-consuming data includes a request response time consumption for each service node in the sub-cluster of service nodes associated with the target client language type;

the service node ordering sub-unit 2323 is configured to order the request response time consumption of each service node in the service node sub-cluster associated with the target client language type, and determine the service node corresponding to the minimum request response time consumption in the ordered request response time consumption as the target service node.

The specific functional implementation manner of the time-consuming data request sending subunit 2321, the time-consuming data receiving subunit 2322, and the serving node ordering subunit 2323 may refer to step S203 in the corresponding embodiment of fig. 6, which is not described herein again.

Referring to fig. 9, the scheduling unit 232 includes:

a service node load detection subunit 2324, configured to perform service node load detection in the service node sub-cluster associated with the target client language type if the scheduling requirement parameter is a load requirement parameter, so as to obtain a load amount to be processed and a load processing rate of each service node in the service node sub-cluster associated with the target client language type;

the load index generating subunit 2325 is configured to generate, according to the load amount to be processed and the load processing rate, a load index corresponding to each service node in the service node sub-cluster associated with the target client language type, and determine the service node with the smallest load index as the target service node.

The specific functional implementation manner of the service node load detection subunit 2324 and the load index generation subunit 2325 may refer to step S203 in the corresponding embodiment of fig. 6, which is not described herein.

Referring to fig. 9, the scheduling unit 232 includes:

a chunk height data request sending subunit 2326, configured to send, to the detection device, a chunk height data request for a service node sub-cluster associated with the target client language type if the scheduling requirement parameter is a chunk height threshold;

a block height data set receiving subunit 2327, configured to receive a block height data set returned by the detection device based on the block height data request; the block height data set comprises the latest block height corresponding to each service node in the service node sub-cluster associated with the target client language type;

the service node to be scheduled determination subunit 2328 is configured to determine a service node with a latest block height greater than the block height threshold as a service node to be scheduled, and select a target service node from the service nodes to be scheduled.

The specific functional implementation manner of the block height data request sending subunit 2326, the block height data set receiving subunit 2327, and the service node determining subunit 2328 to be scheduled may refer to step S203 in the corresponding embodiment of fig. 6, which is not described herein.

Referring again to fig. 9, the data processing apparatus 2 further includes:

The service node deleting module 29 is configured to delete, when the gateway device obtains the deactivation flag information and the block height low flag information sent by the detection device, a service node corresponding to the deactivation flag information and a service node corresponding to the block height low flag information in the initial block chain service node cluster, so as to obtain a block chain service node cluster; the inactivation mark information refers to mark information of a service node which does not establish a heartbeat connection relationship with the detection equipment within a set time range; the block height low flag information refers to flag information of a service node whose absolute value of a difference value between a block height and a global highest block height is greater than a difference threshold, and the global highest block height is a service node with a maximum block height in an initial block chain service node cluster.

The specific functional implementation manner of the service node deleting module 29 may refer to step S204 in the corresponding embodiment of fig. 6, and will not be described herein.

Further, referring to fig. 10, fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, a memory 1005, at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display (Display), a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others. The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may also optionally be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 10, the memory 1005, which is one type of computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

In the computer device 1000 shown in FIG. 10, the network interface 1004 may provide network communication functions; while user interface 1003 is primarily used as an interface for providing input to a user; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

the target service node receives the business transaction sent by the gateway equipment; the business transaction is sent to the gateway equipment by the terminal equipment, the gateway equipment is used for determining a target client language type matched with the business type of the business transaction in the client language types of the S blockchain clients, and the gateway equipment is also used for dispatching out target service nodes in the service node sub-clusters associated with the target client language types; the business transaction is co-executed and co-identified in the blockchain service node cluster by an execution client and a co-identified client associated with the target client language type.

The gateway equipment receives a service request carrying service transaction sent by the terminal equipment, and respectively matches the service types corresponding to the service transaction with the client language types of the S blockchain clients to obtain target client language types matched with the service types of the service transaction; determining a sub-cluster of service nodes associated with the target client language type; scheduling and selecting the service node subset group associated with the target client language type to obtain a target service node selected by scheduling; the business transaction is forwarded to the target service node such that the target service node co-executes and co-shares the business transaction in the blockchain service node cluster through the execution client and the co-shares client associated with the target client language type.

It should be understood that the computer device 1000 described in the embodiments of the present application may perform the description of the data processing method in the embodiments corresponding to fig. 2, 3, 4, 5, 6 and 7, and may also perform the description of the data processing apparatus 1 in the embodiments corresponding to fig. 8 and the description of the data processing apparatus 2 in the embodiments corresponding to fig. 9, which are not repeated herein. In addition, the description of the beneficial effects of the same method is omitted.

The embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program includes program instructions, where the program instructions, when executed by a processor, implement a data processing method provided by each step in fig. 2, fig. 3, fig. 4, fig. 5, fig. 6, and fig. 7, and specifically refer to an implementation manner provided by each step in fig. 2, fig. 3, fig. 4, fig. 5, fig. 6, and fig. 7, which is not described herein again. In addition, the description of the beneficial effects of the same method is omitted.

The computer readable storage medium may be the data processing apparatus provided in any one of the foregoing embodiments or an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the computer device. Further, the computer-readable storage medium may also include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

Embodiments of the present application also provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the data processing method in the embodiments corresponding to fig. 2, 3, 4, 5, 6 and 7, which are not described herein. In addition, the description of the beneficial effects of the same method is omitted.

The term "comprising" and any variations thereof in the description of embodiments of the application and in the claims and drawings is intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, article, or device that comprises a list of steps or elements is not limited to the list of steps or modules but may, in the alternative, include other steps or modules not listed or inherent to such process, method, apparatus, article, or device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The method and related apparatus provided in the embodiments of the present application are described with reference to the flowchart and/or schematic structural diagrams of the method provided in the embodiments of the present application, and each flow and/or block of the flowchart and/or schematic structural diagrams of the method may be implemented by computer program instructions, and combinations of flows and/or blocks in the flowchart and/or block diagrams. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or structural diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or structures.

The foregoing disclosure is illustrative of the present application and is not to be construed as limiting the scope of the application, which is defined by the appended claims.

Claims

1. The data processing method based on the blockchain is characterized in that the method is executed by a target service node in a blockchain service node cluster, the blockchain service node cluster comprises M service nodes, the M service nodes comprise the target service nodes, the M service nodes are composed of S groups of service node sub-clusters, the blockchain clients configured by the service nodes in one group of service node sub-clusters are identical, the blockchain clients respectively configured by different service node sub-clusters are mutually different, the blockchain clients comprise an execution client and a consensus client, M and S are positive integers, and S is smaller than or equal to M; the method comprises the following steps:

the target service node receives service transaction sent by gateway equipment; the service transaction is sent to the gateway device by a terminal device, the gateway device is used for determining a target client language type matched with the service type of the service transaction in client language types of S blockchain clients, and the gateway device is also used for dispatching the target service node in a service node sub-cluster associated with the target client language type;

The business transaction is commonly executed and consensus-known in the blockchain service node cluster by an execution client and a consensus client associated with the target client language type.

2. The method of claim 1, wherein the jointly executing and consensus-consensus the business transaction in the blockchain service node cluster by an execution client and a consensus client associated with the target client language type comprises:

detecting the running state of the S group service node sub-cluster;

if the service node sub-cluster with the running state being the fault state exists in the S group of service node sub-clusters, carrying out fault marking on the service node sub-cluster with the running state being the fault state;

and determining the service node sub-cluster which is not marked by faults as the service node sub-cluster in a normal state, and commonly executing and commonly recognizing the business transaction in the service node sub-cluster in the normal state through an executing client and a commonly recognized client which are associated with the language type of the target client.

3. The method as recited in claim 1, further comprising:

receiving communication detection data sent by detection equipment, and establishing a heartbeat connection relationship with the detection equipment in a time period indicated by the communication detection data;

When receiving a block height detection request sent by the detection device based on the heartbeat connection relationship, sending highest block height data of the target service node to the detection device so that the detection device stores the relationship between the highest block height data and the target service node;

when a data backup request sent by the detection device is received based on the heartbeat connection relation, carrying out backup processing on the blockchain data of the target service node, generating service node backup data, and sending the service node backup data to the detection device so that the detection device provides data recovery service based on the service node backup data when the target service node is in an unavailable state.

4. The method of claim 1, wherein the jointly executing and consensus-consensus the business transaction in the blockchain service node cluster by an execution client and a consensus client associated with the target client language type comprises:

packaging the business transaction into a block to be uplinked through an execution client associated with the target client language type, and executing the business transaction in the block to be uplinked to obtain a transaction execution result;

Broadcasting the block to be uplinked and the transaction execution result to each service node in the blockchain service node cluster through a consensus client associated with the target client language type, so that each service node in the blockchain service node cluster commonly performs consensus voting on the block to be uplinked and the transaction execution result;

if the consensus of the block to be uplinked and the transaction execution result is successful, the block to be uplinked is determined to be an uplinkable block, and the uplinkable block and the transaction execution result are stored into a blockchain ledger.

5. A blockchain-based data processing method, characterized in that the method is performed by a gateway device, the gateway device being connected to a blockchain service node cluster; the block chain service node cluster comprises M service nodes, the M service nodes comprise target service nodes, the M service nodes are composed of S groups of service node sub-clusters, the block chain clients configured by the service nodes in one group of service node sub-clusters are identical, the block chain clients respectively configured by different service node sub-clusters are mutually different, the block chain clients comprise execution clients and consensus clients, M and S are both positive integers, and S is smaller than or equal to M; the method comprises the following steps:

The gateway equipment receives a service request carrying service transaction sent by the terminal equipment, and respectively matches the service type corresponding to the service transaction with the client language types of the S blockchain clients to obtain a target client language type matched with the service type of the service transaction;

performing scheduling selection on a service node subset group associated with the target client language type to obtain the target service node selected by scheduling;

forwarding the business transaction to the target service node such that the target service node commonly executes and consensus the business transaction in the blockchain service node cluster through an execution client and a consensus client associated with the target client language type.

6. The method of claim 5, wherein the method further comprises:

acquiring interface signature information in the service request; the interface signature information is obtained by signing the business transaction by the terminal equipment based on a terminal private key;

performing signature verification on the interface signature information based on a terminal public key corresponding to the terminal private key to obtain a signature verification result;

If the signature verification result is a verification passing result, executing the step of matching the service type corresponding to the service transaction with the client language types of the S blockchain clients respectively;

and if the signature verification result is a verification failure result, sending a transaction processing failure message to the terminal equipment.

7. The method of claim 5, wherein scheduling the subset of service nodes associated with the target client language type to obtain the selected target service node comprises:

acquiring request header data corresponding to the service request, and acquiring scheduling requirement parameters carried by the request header data;

and performing scheduling selection in the service node sub-cluster associated with the target client language type through the scheduling demand parameter to obtain the target service node selected by scheduling.

8. The method of claim 7, wherein said scheduling selection among the service node sub-clusters associated with the target client language type by the scheduling requirement parameter comprises:

if the scheduling demand parameter is a time-consuming demand parameter, sending a time-consuming data request aiming at a service node sub-cluster associated with the target client language type to detection equipment;

Receiving time-consuming data returned by the detection equipment based on the time-consuming data request; the time-consuming data includes a request response time consumption of each service node in the service node sub-cluster associated with the target client language type;

and sequencing the request response time consumption of each service node in the service node sub-cluster associated with the target client language type, and determining the service node corresponding to the minimum request response time consumption in the sequenced request response time consumption as the target service node.

9. The method of claim 7, wherein said scheduling selection among the sub-clusters of service nodes associated with the target client language type by the scheduling requirement parameter, to obtain the target service node for scheduling selection, comprises:

if the scheduling demand parameter is a load demand parameter, carrying out service node load detection in the service node sub-cluster associated with the target client language type to obtain the load quantity to be processed and the load processing rate of each service node in the service node sub-cluster associated with the target client language type;

And generating a load index corresponding to each service node in the service node sub-cluster associated with the target client language type according to the load quantity to be processed and the load processing rate, and determining the service node with the minimum load index as the target service node.

10. The method of claim 7, wherein said scheduling selection among the sub-clusters of service nodes associated with the target client language type by the scheduling requirement parameter, to obtain the target service node for scheduling selection, comprises:

if the scheduling requirement parameter is a block height threshold, sending a block height data request for a service node sub-cluster associated with the target client language type to detection equipment;

receiving a block height data set returned by the detection equipment based on the block height data request; the block height data set comprises the latest block height corresponding to each service node in the service node sub-cluster associated with the target client language type;

and determining the service node with the latest block height larger than the block height threshold as a service node to be scheduled, and selecting the target service node from the service nodes to be scheduled.

11. The method of claim 5, wherein the method further comprises:

when the gateway equipment acquires the inactivation mark information and the block height low mark information sent by the detection equipment, deleting a service node corresponding to the inactivation mark information and a service node corresponding to the block height low mark information from an initial block chain service node cluster to obtain the block chain service node cluster; the inactivation mark information refers to mark information of a service node which does not establish a heartbeat connection relationship with the detection equipment within a set time range; the block height low marking information refers to marking information of a service node, wherein the absolute value of the difference value between the block height and the global highest block height is larger than a difference value threshold, and the global highest block height is the service node with the largest block height in the initial block chain service node cluster.

12. A blockchain-based data processing device, the data processing device comprising:

the business transaction receiving module is used for receiving business transactions sent by the gateway equipment by the target service node; the service transaction is sent to the gateway device by a terminal device, the gateway device is used for determining a target client language type matched with the service type of the service transaction in client language types of S blockchain clients, and the gateway device is also used for dispatching the target service node in a service node sub-cluster associated with the target client language type;

And the consensus executing module is used for jointly executing and consensus the business transaction in the blockchain service node cluster through an executing client and a consensus client which are associated with the target client language type.

13. A blockchain-based data processing device, the data processing device comprising:

a node sub-cluster determining module, configured to determine a service node sub-cluster associated with the target client language type;

and the business transaction forwarding module is used for forwarding the business transaction to the target service node so that the target service node can jointly execute and consensus the business transaction in a blockchain service node cluster through an execution client and a consensus client which are associated with the language type of the target client.

14. A blockchain-based computer device, comprising: a processor, a memory, and a network interface;

the processor is connected to a memory, a network interface for providing data communication functions, the memory for storing a computer program, the processor for invoking the computer program to cause the computer device to perform the method of any of claims 1-11.

15. A blockchain-based computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program adapted to be loaded and executed by a processor to cause a computer device with a processor to perform the method of any of claims 1-11.

16. A blockchain-based computer program product, characterized in that the computer program product comprises a computer program stored in a computer readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device with a processor to implement the steps of the method of any of claims 1-11.