Data processing method of block chain network and related products thereof

Abstract

The invention discloses a data processing method of a block chain network and a related product thereof, the block chain network comprises a plurality of block chain nodes, the plurality of block chain nodes comprise block outlet nodes, the plurality of block chain nodes carry out data interaction based on a switch, the switch has a port mirror image module, and the port mirror image module is connected with the block outlet nodes. The method comprises the following steps: receiving a first data packet sent by a switch through a port mirroring module, wherein the first data packet is obtained by mirroring an obtained network data packet related to an out-block node through the port mirroring module by the switch; performing data analysis processing on the first data packet to obtain analysis data; and detecting the out-of-block node based on the analysis data to obtain a detection result which indicates the out-of-block process of the out-of-block node. By adopting the method and the device, the accuracy of detecting and processing the out-of-block node can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more particularly to a data processing method for a blockchain network and related products. Background Technology

[0002] In the consensus network of a blockchain network, there will be a block-producing node, which can be elected by the consensus nodes in the consensus network.

[0003] Current applications focus primarily on the right to produce blocks (i.e., the right to record transactions) within the blockchain network. This leads to the evaluation of each consensus node's block-producing process based on its own identity information (such as authority and credibility). This block-producing process can include both abnormal and normal block production, allowing for the selection of consensus nodes with more reliable identity information as block-producing nodes. However, this approach focuses on too few aspects regarding the block-producing process, resulting in inaccurate evaluations of the block-producing node's progress. Summary of the Invention

[0004] This application provides a data processing method for blockchain networks and related products, which can improve the accuracy of detecting the block-producing process of block-producing nodes.

[0005] This application provides a data processing method for a blockchain network, wherein the blockchain network includes multiple blockchain nodes, and the multiple blockchain nodes include block-producing nodes. The multiple blockchain nodes interact with each other based on a switch, and the switch has a port mirroring module. The method includes:

[0006] The first data packet sent by the switch through the port mirroring module is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block producing node. The network data packets related to the block producing node include at least one of the following: the network data packet containing the data sent by the block producing node, and the network data packet containing the data that the block producing node needs to receive.

[0007] The first data packet is parsed to obtain the parsed data;

[0008] The block-producing nodes are detected and processed based on the parsed data to obtain the detection results, which indicate the block-producing process of the block-producing nodes.

[0009] This application provides a data processing device for a blockchain network. The blockchain network includes multiple blockchain nodes, among which there are block-producing nodes. The multiple blockchain nodes interact with each other based on a switch. The switch has a port mirroring module. The device includes:

[0010] The acquisition module is used to receive the first data packet sent by the switch through the port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block output node. The network data packets related to the block output node include at least one of the following: the network data packet containing the data sent by the block output node, and the network data packet containing the data that the block output node needs to receive.

[0011] The parsing module is used to parse the first data packet to obtain parsed data;

[0012] The detection module is used to detect and process block-producing nodes based on parsed data, obtain detection results, and indicate the block-producing progress of the block-producing nodes.

[0013] Optionally, the block-producing node has N detection indicators, where N is an integer greater than or equal to 1;

[0014] The parsing module performs data parsing processing on the first data packet to obtain the parsed data in the following ways:

[0015] The first data packet is parsed to obtain parsed data related to k of the N detection indicators, where k is an integer less than or equal to N.

[0016] Optional, the N detection metrics include network detection metrics and block output detection metrics;

[0017] Among them, network detection indicators include at least one of the following: network latency indicators, network throughput indicators, and network packet loss rate indicators.

[0018] Block production detection metrics include at least one of the following: basic block production metrics and business block production metrics;

[0019] The basic block production metrics include at least one of the following: metrics for the amount of resources consumed by the transactions in the block, metrics for the number of transactions packaged, and metrics for the block production delay.

[0020] Business block production metrics include at least one of the following: metrics on the frequency of calls to contracts in the block, metrics on the frequency of calls to methods in contracts in the block, and metrics on the frequency of triggering events in contracts in the block.

[0021] Optionally, each of the N detection metrics has its own corresponding sliding window, which is used to perform segmented detection on the block-producing node under the corresponding detection metric.

[0022] Among them, different detection indicators among the N detection indicators may correspond to the same sliding window or to different sliding windows;

[0023] The sliding window includes at least one of the following: a time sliding window, a block height sliding window;

[0024] The time sliding window is used to select a time segment interval, and the block height sliding window is used to select a block height segment interval.

[0025] Optionally, the detection module performs detection processing on the block-producing nodes based on the parsed data to obtain the detection results in the following ways:

[0026] The analytical data related to the k detection indicators are placed into the sliding windows corresponding to the k detection indicators respectively.

[0027] Based on the parsed data placed in the sliding window corresponding to the k detection indicators, the index values ​​of each of the k detection indicators are statistically calculated. The index values ​​are obtained by statistically analyzing the parsed data related to the detection indicator placed in the currently selected segment interval of the sliding window corresponding to the detection indicator.

[0028] Based on the values ​​of k detection indicators, the block-producing nodes are detected and processed under the k detection indicators to obtain the detection results.

[0029] Optionally, any one of the k detection metrics can be the target detection metric. The block production process includes normal block production or abnormal block production. The detection module performs detection processing on the block-producing node based on the metric values ​​of the k detection metrics, and obtains the detection results in the following ways:

[0030] Obtain the reference index value range for the target detection index;

[0031] If the value of the target detection indicator is not within the range of the reference indicator value, the block-producing node is determined to be abnormal under the target detection indicator; if the value of the target detection indicator is within the range of the reference indicator value, the block-producing node is determined to be normal under the target detection indicator.

[0032] If a block-producing node is detected as abnormal under any of the k detection metrics, then the block-producing process is determined to include abnormal block production. If a block-producing node is detected as normal under all k detection metrics, then the block-producing process is determined to include normal block production.

[0033] Optionally, the detection module is also used for:

[0034] If the block production process includes abnormal block production, a switchover of the block producing node in the blockchain network will be triggered.

[0035] If the block production process includes normal block production, then the switching of block-producing nodes in the blockchain network will not be triggered.

[0036] Optionally, the detection module may trigger the switching of block-producing nodes in the blockchain network in the following ways:

[0037] Generate chain configuration transactions for the blockchain network, which are used to trigger the switching of block-producing nodes in the blockchain network;

[0038] The chain configuration transaction is sent to the consensus nodes in the blockchain network, enabling the consensus nodes in the blockchain network to switch the block-producing nodes based on the chain configuration transaction.

[0039] Optionally, the multiple blockchain nodes include multiple consensus nodes, and the multiple consensus nodes include block-producing nodes. The aforementioned data processing device is also used for:

[0040] The second data packet sent by the switch through the port mirroring module is obtained. The second data packet is a network data packet related to other consensus nodes among multiple consensus nodes, excluding the block producing node. The network data packet related to other consensus nodes includes at least one of the following: the network data packet containing the data sent by other consensus nodes, and the network data packet containing the data that other consensus nodes need to receive.

[0041] Based on the second data packet, the network status of other consensus nodes is detected and processed.

[0042] Among them, the network status detected by other consensus nodes is used to select the next block-producing node when the block-producing node is switched.

[0043] Optionally, the port mirroring module has a configured source port and a destination port, where the source port is the port on the switch used for data transmission and reception.

[0044] The acquisition module receives the first data packet sent by the switch through the port mirroring module in the following ways:

[0045] Receive the first data packet sent by the switch through the target port;

[0046] The first data packet is obtained by the switch through the port mirroring module, which mirrors the network data packets related to the block output node received from the source port.

[0047] Optionally, the port mirroring module configured on the switch includes at least one of the following: a single-source port mirroring module and a multi-source port mirroring module;

[0048] Among them, the single-source port mirroring module is used to mirror the traffic of a single port of the switch, while the multi-source port mirroring module is used to mirror the traffic of multiple ports of the switch.

[0049] Both single-source port mirroring modules and multi-source port mirroring modules are either: unidirectional port mirroring modules or bidirectional port mirroring modules.

[0050] The one-way port mirroring module is used to mirror the incoming or outgoing traffic of the switch, while the two-way port mirroring module is used to mirror both the incoming and outgoing traffic of the switch.

[0051] This application provides a computer device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method of this application.

[0052] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described in the above-mentioned aspect.

[0053] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in the various alternative embodiments described above.

[0054] In the blockchain network of this application, multiple blockchain nodes can interact with each other via a switch. These multiple blockchain nodes include block-producing nodes. The switch can have a port mirroring module, which can mirror the network data packets exchanged between the blockchain nodes. The mirrored network data packets can include a first data packet related to the block-producing node, such as a network data packet containing data sent by the block-producing node or a network data packet containing data to be received by the block-producing node. Since the switch is located at the data link layer (Layer 2) in a 7-layer computer model, the first data packet obtained through the switch's port mirroring module can contain data from Layers 2 to 7 of the 7-layer computer model, including the Layer 2 network layer and the Layer 7 application layer (belonging to the business layer, which can contain data from the blocks specifically packaged by the block-producing node and the transactions within those blocks). Therefore, the first data packet obtained through the mirroring process of the switch can enable detection of the block-producing node at multiple levels (such as the network layer and the business layer) to detect the block-producing node's block-producing process, thereby improving the accuracy of detecting the block-producing node's block-producing process. Attached Figure Description

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

[0056] Figure 1 This is a schematic diagram of a network architecture for a detection network provided in an embodiment of this application;

[0057] Figure 2 This is a schematic diagram of a scenario for detecting block-producing nodes provided in an embodiment of this application;

[0058] Figure 3 This is a flowchart illustrating a data processing method for a blockchain network provided in an embodiment of this application;

[0059] Figure 4 This is a simplified view of a network data packet copied by a switch according to an embodiment of this application;

[0060] Figure 5 This is a schematic diagram of a strategy design class diagram provided in an embodiment of this application;

[0061] Figure 6 This is a schematic diagram of a consensus intervention architecture provided in an embodiment of this application;

[0062] Figure 7 This is a schematic diagram of a process for detecting block-producing nodes provided in an embodiment of this application;

[0063] Figure 8 This is a schematic diagram of a scenario for sliding detection of block-producing nodes based on a time-sliding window, provided in an embodiment of this application.

[0064] Figure 9 This is a schematic diagram of a scenario for sliding detection of block-producing nodes based on a sliding window of block height, provided in an embodiment of this application.

[0065] Figure 10 This is a schematic diagram of the structure of a data processing device for a blockchain network provided in an embodiment of this application;

[0066] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0067] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0068] First, it should be noted that all data collected in this application (such as network data packets obtained by the switch through the port mirroring module, etc.) is collected with the consent and authorization of the data subject (such as user, organization or enterprise), and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant region.

[0069] Here, the relevant technical concepts involved in this application are explained:

[0070] Blockchain: A distributed ledger technology in the field of information technology. It generally consists of consensus, transaction blocks and state data storage, cryptographic identity security and other components. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being immutable, traceable and jointly maintained.

[0071] Consensus Mechanism: A blockchain consensus mechanism is a protocol and algorithm that ensures all nodes in a distributed network reach a consensus on the data state. It solves the problems of data consistency and trust in decentralized systems and is a core element of blockchain technology.

[0072] Port mirroring, also known as port monitoring or SPAN (Switched Port Analyzer), is a network monitoring technology that allows all traffic on one or more ports to be copied to another port for real-time analysis.

[0073] Sliding window is a technique widely used in computer science and algorithm design, suitable for handling problems involving continuous data streams, string matching, array processing, and network flow control. It involves maintaining a window on a data structure and sliding this window across the data structure to perform efficient data processing and computation.

[0074] The OSI seven-layer model: A seven-layer computer model, consisting of the physical layer, data link layer, network layer, transport layer, session layer, presentation layer, and application layer. The switch in this application is located at layer 2, the data link layer, in this seven-layer model. Furthermore, the data in this seven-layer model can be nested; layer 2 data can contain layer 3 data, layer 3 data packets can contain layer 4 data, layer 4 data can contain layer 5 data, and so on. Therefore, the layer 2 data (which can be data packets) obtained by the switch can include data from layers 2 to 7. This application uses this OSI seven-layer model for interconnection between computers.

[0075] TCP: A transport layer communication protocol located at layer 4 of the OSI seven-layer model, namely the transport layer.

[0076] IP: Internet Protocol address used to uniquely identify a device, located at layer 3 of the OSI seven-layer model, namely the network layer.

[0077] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture for a detection network provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture may include a blockchain network, a switch (at least one), and a detection device. The blockchain network contains multiple blockchain nodes, among which there may be block-producing nodes, which are consensus nodes used to produce blocks in the blockchain network. The blockchain nodes in the blockchain network can be connected to the switch, and the blockchain nodes can interact with each other through the connected switch.

[0078] In this blockchain network, both blockchain nodes and detection devices can be composed of computer equipment, which can be servers or terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal device can be a smart terminal such as a smartphone, tablet, laptop, desktop computer, smart TV, in-vehicle terminal, or smart home device.

[0079] The switch in this application may have a port mirroring module, which can be used to copy the traffic of the switch's ports to a detection device. For example, the port mirroring module can copy network data packets (which can be called the first data packet) received by the switch related to the block-producing node to the detection device. The first data packet may include data from layers 2 to 7 of the OSI seven-layer model. Thus, the detection device can detect the block-producing node by acquiring the first data packet, thereby detecting the block-producing process of the block-producing node. This block-producing process may include normal block production or abnormal block production.

[0080] Please see also Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario for detecting block-producing nodes according to an embodiment of this application. The aforementioned block-producing node can have N detection indicators, where N is a positive integer. Here, for example... Figure 2 As shown, the detection device can perform data parsing processing on the acquired first data packet to obtain parsing data related to k detection indicators (including detection indicator z1 to detection indicator zk) among the N detection indicators, where k is a positive integer and k is less than or equal to N.

[0081] Therefore, by analyzing the data related to each of the k detection metrics, the block-producing node can be detected under each detection metric. For example, by analyzing the data related to detection metric z1, the block-producing node can be detected under detection metric z1; by analyzing the data related to detection metric z2, the block-producing node can be detected under detection metric z2; and so on.

[0082] Therefore, by detecting the block-producing node under these k detection metrics, the final detection result of the block-producing node can be obtained. This result indicates the block-producing node's block-producing process, which includes normal block production or abnormal block production. Normal block production indicates that the block-producing node is currently producing blocks normally, while abnormal block production indicates that the block-producing node is currently producing blocks abnormally. In this case, if the block-producing node's block-producing process includes abnormal block production, a switchover process for the block-producing node can be triggered; however, if the block-producing node's block-producing process includes normal block production, a switchover process for the block-producing node does not need to be triggered.

[0083] Using the method provided in this application, data related to the block-producing node and containing layers 2 to 7 of the OSI seven-layer model can be obtained non-intrusively through the port mirroring module of the switch connected to the blockchain node. This process will not affect the normal operation of the blockchain node and the switch at all. Furthermore, the block-producing node can be detected comprehensively and accurately through this data.

[0084] Please see Figure 3, Figure 3 This is a flowchart illustrating a data processing method for a blockchain network provided in an embodiment of this application. The blockchain network can include multiple blockchain nodes, among which there may be block-producing nodes, which are the blockchain nodes currently used to produce blocks (i.e., package blocks) in the blockchain network. These multiple blockchain nodes may interact with each other via a switch. The switch may have a port mirroring module, which can be used to mirror data sent and / or received by the switch's ports. This mirroring can be copying or duplicating. Therefore, the port mirroring module of the switch can obtain the network data packets exchanged between the blockchain nodes, which may include network data packets received and / or sent by the switch. Figure 3 As shown, the method may include:

[0085] Step S101: Receive the first data packet sent by the switch through the port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block-producing node. The network data packets related to the block-producing node include at least one of the following: the network data packet containing the data sent by the block-producing node, and the network data packet containing the data that the block-producing node needs to receive.

[0086] Optionally, the execution entity in this application embodiment can be a processing device (or detection device) outside the blockchain network. This processing device can be a single computer or a cluster of multiple computer devices. The switch in this application can be one or more, and a switch can have one or more ports. The switch is used to send and receive data through its ports. Blockchain nodes can connect to the switch, specifically by connecting to a port of the switch (also known as binding), thereby sending and receiving data through the connected switch.

[0087] Different blockchain nodes can connect to the same or different switches. Furthermore, when connecting to the same switch, different blockchain nodes can connect to the same or different ports on that switch. In other words, a single port on a switch can simultaneously connect to at least one (or more) blockchain node. Connecting a blockchain node to a port on a switch can mean binding the blockchain node's IP address (Internet Protocol address) to that specific port on the switch.

[0088] For example, blockchain nodes in a blockchain network can include blockchain node A1 and blockchain node A2, and the aforementioned switches can include switch B1 and switch B2. Blockchain node A1 can connect to the port of switch B1, and blockchain node A2 can connect to the port of switch B2. When blockchain node A1 needs to send certain data to blockchain node A2, blockchain node A1 can first send the data to the connected switch B1, so that switch B1 can send the data to the switch B2 connected to blockchain node A2, and switch B2 can then send the data to blockchain node A2, thus realizing the data transmission from blockchain node A1 to blockchain node A2.

[0089] Since the data on the blockchain network is public to all blockchain nodes, meaning that all blockchain nodes can access all the data in the blockchain network, the only difference is that the time it takes for each node to access the data may vary. Therefore, it is understandable that regardless of how many switches connect the blockchain nodes, each switch can also access all the data in the blockchain network, although the time it takes for each switch to access the data will also differ.

[0090] Therefore, the switch with a port mirroring module for node detection (such as detecting the block production status of block-producing nodes) in this application can be some or all of the switches connected to the blockchain nodes in the blockchain network. That is, there can be one or more switches with port mirroring modules in this application, and the final effect achieved by detecting node status through one or more switches can be the same. However, when there are multiple switches, node status detection can be performed simultaneously and separately through these switches. This prevents issues caused by some switches being abnormal or having low detection efficiency, and also ensures the reliability of node status detection through other switches. Regardless of whether there is one or more switches with port mirroring modules in this application, since the principle of node status detection through each switch is independent and the same, they are collectively referred to as switches below.

[0091] The port mirroring module of a switch can refer to port mirroring configured on a port of a switch. A port mirroring module of a switch can include at least one of the following: a single-source port mirroring module (which can refer to single-source port mirroring configured on a port of a switch), or a multi-source port mirroring module (which can refer to multi-source port mirroring configured on a port of a switch).

[0092] It should be noted here that a switch can have traffic, which can include inbound traffic and outbound traffic. Inbound traffic can refer to data traffic sent to the switch by other devices (including network data packets received by the switch), and outbound traffic can refer to data traffic sent out by the switch (including network data packets sent out by the switch).

[0093] Therefore, the aforementioned single-source port mirroring module is used to mirror (i.e., copy) the traffic of a single port of the switch. This single-source port mirroring module is configured for one port of the switch, and it is used to mirror the traffic of that single port. The aforementioned multi-source port mirroring module, on the other hand, is used to mirror the traffic of multiple ports of the switch simultaneously. This multi-source port mirroring module is configured for multiple ports of the switch, and it is used to mirror the traffic of those multiple ports simultaneously.

[0094] The single-source port mirroring module and the multi-source port mirroring module mentioned above can be either of the following: a unidirectional port mirroring module (which can refer to unidirectional port mirroring configured on a switch port) or a bidirectional port mirroring module (which can refer to bidirectional port mirroring configured on a switch port).

[0095] The unidirectional port mirroring module is used to mirror unidirectional traffic (such as outgoing or incoming traffic) of the switch. This unidirectional port mirroring module can also be of two types: one that mirrors outgoing traffic from the corresponding configured port of the switch (called outgoing port mirroring), and another that mirrors incoming traffic from the corresponding configured port of the switch (called incoming port mirroring). The bidirectional port mirroring module described above is used to mirror bidirectional traffic (including both outgoing and incoming traffic) of the switch.

[0096] This application allows for more than one switch with a port mirroring module, and a switch can have one or more port mirroring modules. A port mirroring module can be configured for one or more ports of the switch, and different port mirroring modules can be configured for ports of different switches or different ports of the same switch. Each port mirroring module can be configured separately, and the principle of data processing based on each port mirroring module is the same. In some special scenarios, if the computing resources of the processing device are very limited, a one-way port mirroring module can also be configured on the port of the switch. Then, the block-producing node can be detected by the network data packets copied by the one-way port mirroring module, such as by using a detection indicator among the following N detection indicators that is only related to the network data packets copied by the one-way port mirroring module.

[0097] The port mirroring module can have configured source and destination ports. The source port is the port on the switch that transmits and receives data; that is, the port from which the data to be mirrored originates. The destination port can be the port used to receive data copied from the source port. Each port mirroring module can be configured with its own source and destination ports. For the single-source port mirroring module described above, it can be configured with one source port; for the multi-source port mirroring module described above, it can be configured with multiple source ports.

[0098] Optionally, different ports on the switch can be configured with the same type of port mirroring module, or they can be configured with different types of port mirroring modules, depending on the actual application scenario. For example, some ports can be configured with unidirectional port mirroring modules, some ports can be configured with bidirectional port mirroring modules, some ports can be configured with single-source port mirroring modules, and some ports can be configured with multi-source port mirroring modules. This application does not impose any restrictions on this.

[0099] Therefore, the processing device can receive the first data packet sent by the switch through the target port. The first data packet is obtained by the switch through the port mirroring module, which mirrors the network data packets related to the block output node.

[0100] Optionally, the network data packets related to the block-producing node may include at least one of the following: network data packets containing data sent by the block-producing node (such as sent data packets), and network data packets containing data that the block-producing node needs to receive. Specifically, the network data packets containing data that the block-producing node needs to receive may include network data packets containing data sent to the block-producing node by other blockchain nodes. The network data packets containing data sent to the block-producing node by other blockchain nodes may include reply data packets corresponding to the network data packets sent by the block-producing node, i.e., network data packets from other blockchain nodes replying to the network data packets sent by the block-producing node (this network data packet may contain data from the reply of the other blockchain node to the network data packets sent by the block-producing node), and may also include network data packets that other blockchain nodes themselves need to send to the block-producing node, which may not be network data packets replying to the network data packets sent by the block-producing node.

[0101] Therefore, the aforementioned first data packet may be a network data packet sent by the block-producing node, or it may be a network data packet (i.e., a reply packet) sent by other blockchain nodes in response to the network data packet sent by the block-producing node, or it may be a network data packet sent by other blockchain nodes for broadcasting to the block-producing node.

[0102] Optionally, the target port can be a port of the aforementioned processing device, that is, the port used by the processing device for data transmission and reception. Therefore, the processing device can directly receive the first data packet sent by the switch through the target port.

[0103] Alternatively, the target port may not be a port of the processing device, but rather a port of a data relay device. There can be one or more data relay devices, and different data relay devices can be used to receive network packets copied through different port mirroring modules of the switch. That is, the target port of different port mirroring modules can be a port of different data relay devices or a port of the same data relay device. A port of one data relay device is the target port of at least one port mirroring module of the switch. For example, some data relay devices can be specifically used to receive network packets copied through configured outbound port mirroring, while others can be specifically used to receive network packets copied through configured inbound port mirroring. This allows some data relay devices to process inbound traffic from the switch's ports, and others to process outbound traffic from the switch's ports.

[0104] Then, the data relay device can parse the acquired network data packets to obtain the corresponding parsed data (i.e., the parsed data in step S102 below), and directly provide this parsed data to the processing device for processing (such as detecting block-producing nodes or detecting the network status of other consensus nodes besides block-producing nodes). Alternatively, the parsed data can be stored in a designated database, and the processing device can retrieve the corresponding parsed data from the database for processing. Using this method, there is no need for the processing device to parse the network data packets on the switch port itself; instead, the data relay device can perform the data parsing, realizing a division of labor between the data relay device and the processing device, and improving the efficiency of detecting the network status of block-producing nodes or other consensus nodes.

[0105] The aforementioned first data packet can be obtained by a switch through its port mirroring module, which mirrors network data packets related to the block-producing node received at the source port. In fact, the switch's port mirroring module can copy all data (such as all network data packets) received at the switch's source port to the target port. From this, the application can retrieve the copied data packets related to the block-producing node (such as the first data packet) for use in detecting the block-producing node.

[0106] Please see Figure 4 , Figure 4 This is a simplified schematic diagram illustrating a network data packet copied by a switch according to an embodiment of this application. Figure 4As shown, the network data packet can be a data packet used to send transactions from block-producing nodes. This network data packet may contain IP (network layer protocol) protocol information, TCP (transport layer protocol) protocol information, and specific transaction information from the application layer, such as transaction ID (transaction identifier), transaction type, invoked contract name (indicating the invoked contract), invoked contract method, executor address, proposer address, input parameters, a signature array for the transaction body, and the public key for multi-signature. Furthermore, the network data packet may also contain other additional information, such as the packet reception time and data packet size. The packet reception time is the time when the processing device obtains the network data packet, and the data packet size can be the amount of data in the network data packet, such as the total number of bytes contained in the network data packet.

[0107] As can be seen, this application, through the port mirroring module configured on the switch, can not only obtain network-related data (such as data related to the network layer and transport layer) in the middle layer of the computer's 7-layer model without intrusion, but also obtain application-related specific data (such as specific transaction information in the application layer) in the lowest layer of the computer's 7-layer model without intrusion.

[0108] Step S102: Perform data parsing processing on the first data packet to obtain parsed data.

[0109] Optionally, the processing device may perform data parsing processing on the received first data packet to obtain parsed data, which may be carried or contained in the first data packet. The data parsing processing of the first data packet may include layer-by-layer parsing of data from layers 2 to 7 of the 7-layer computer model in the first data packet.

[0110] The aforementioned block-producing node can have N detection metrics, where N is an integer greater than or equal to 1. These N detection metrics can be set according to the actual application scenario. Different detection metrics are used to detect the block-producing node on different metric dimensions. Therefore, the parsed data can be used to obtain information on the detection of the block-producing node under these N detection metrics. For example, this information can be the metric value of the block-producing node under these N detection metrics, as described in the following content.

[0111] The processing device can perform data parsing on the first data packet to obtain parsed data related to k of the N detection indicators, where k is an integer less than or equal to N. Depending on the N detection indicators, the parsed data related to these N indicators can be the same or different. Furthermore, the parsed data related to different detection indicators can be obtained by parsing different network data packets related to the block-producing node (such as different types of network data packets, like network data packets sent by the block-producing node, or reply data packets corresponding to network data packets sent by the block-producing node). That is, different network data packets related to the block-producing node can carry or contain data related to each of the N detection indicators for the block-producing node.

[0112] Therefore, the aforementioned k detection indicators refer to the following: if k is less than N, the current first data packet can be used to parse data related to the k detection indicators, but cannot be used to parse data related to other detection indicators among the N detection indicators. In other words, the currently received first data packet can be used to calculate the indicator values ​​of the k detection indicators, but not for calculating the indicator values ​​of other detection indicators among the N detection indicators. Conversely, if k equals N, it means that the first data packet can be used to calculate the indicator values ​​of all N detection indicators.

[0113] As shown above, parsing the first data packet yields parsed data related to some or all (i.e., less than or equal to N, or k) of the N detection indicators. Whether the parsed data relates to some or all of the detection indicators depends on the actual type of the first data packet and the specific content of the N detection indicators. Parsed data related to one detection indicator can be used to calculate the indicator value of that indicator. In other words, the parsed data related to each detection indicator can differ depending on the calculation method for its value.

[0114] Optionally, a feasible method for determining the aforementioned k detection indicators is described herein by way of example. This method may include: each of the aforementioned N detection indicators may have its own corresponding data label, and the data label corresponding to a detection indicator may be used to indicate the data type of the data required to calculate the indicator value of that detection indicator. Therefore, during the data parsing process of the first data packet, the processing device may compare the type of each piece of data parsed from the first data packet with the data type indicated by the data label of the N detection indicators. If the type of a piece of data parsed from the first data packet is the same as the data type indicated by the data label of a certain detection indicator, then the parsed data can be regarded as the parsed data related to that detection indicator, and so on.

[0115] Therefore, after the processing device completes the data parsing process of the first data packet, it can obtain the parsed data related to each of the above k detection indicators. The k detection indicators include those among the above N detection indicators whose data type indicated by the data tag matches (e.g., the same) the data type obtained from parsing the first data packet.

[0116] The following examples illustrate the N detection indicators as described below.

[0117] The aforementioned N detection metrics can include network detection metrics and block production detection metrics; that is, these N detection metrics can be divided into two categories: network detection metrics and block production detection metrics. Network detection metrics are related to the network status (i.e., network condition) of block-producing nodes. These metrics reflect the efficiency and reliability of block production by block-producing nodes and can be used to detect the network status of block-producing nodes. Block production detection metrics, on the other hand, are related to the blocks packaged by block-producing nodes. These metrics reflect the relevant circumstances of block packaging by block-producing nodes, such as whether a block-producing node prioritizes or only packages certain types of transactions (e.g., transactions within a specific group in a consortium blockchain, transactions that call specific contracts, or transactions with the highest returns).

[0118] Optionally, the aforementioned network detection metrics may include, but are not limited to, at least one of the following: network latency metrics, network throughput metrics, and network packet loss rate metrics. The network latency metric reflects the network latency of the block-producing node. The metric value within a segmented interval (such as a time segmented interval or a block height segmented interval) can be the total network latency of the block-producing node within that segmented interval. The calculation method for the network latency metric value may include: Here, we first describe the network latency of the target data packet sent by the block-producing node. This target data packet can be any data packet that the block-producing node needs to send to other devices (such as devices of other blockchain nodes). The block-producing node can send a request packet (belonging to a network data packet) of the target data packet to the connected switch. This request packet may carry the target data packet. This request packet is a network data packet requesting the switch to forward the target data packet. When the switch connected to the block-producing node receives the request packet, it can synchronously mirror the request packet, so that the processing device can also synchronously obtain the request packet. When the processing device acquires the request packet, it can also acquire the acquisition time of the request packet (i.e., the time when the request packet was acquired). The acquisition time of the request packet is the acquisition time of the target data packet carried in the request packet.

[0119] Subsequently, the switch connected to the block-producing node can forward the target data packet carried in the request packet to the target blockchain node (i.e., the blockchain node to which the target data packet ultimately needs to be sent). Upon receiving the target data packet, the target blockchain node can send a reply packet to the switch connected to the block-producing node. This reply packet indicates that the target blockchain node has received the target data packet sent by the block-producing node; this reply packet is also a network data packet related to the block-producing node. After receiving the reply packet, the switch connected to the block-producing node can mirror it, allowing the processing device to also obtain the reply packet. Simultaneously, the processing device can also obtain the time of acquisition of the reply packet, i.e., the time when the processing device acquired the reply packet.

[0120] The processing device can calculate the difference (i.e., the time difference) between the time of acquiring the reply packet and the time of acquiring the request packet. This time difference is the time interval (i.e., the duration of the interval) between acquiring the reply packet and the request packet, such as 1 second. The processing device can use this time difference as the network latency for the target data packet, which is the time from when the target data packet is sent to when it is acknowledged as successfully transmitted.

[0121] For example, if a block-producing node needs to send a target data packet to blockchain node A3, and the block-producing node is connected to switch B1, while blockchain node A3 is connected to switch B2, the block-producing node can first send a request packet for the target data packet to the connected switch B1. Switch B1 can then send the target data packet carried in the request packet to switch B2. Furthermore, switch B1 can simultaneously mirror the request packet, allowing the processing device to synchronously acquire the request packet and obtain the acquisition time, which could be the processing device's own acquisition time. After receiving the target data packet from switch B1, switch B2 can send it to blockchain node A3. Upon successfully acquiring the target data packet, blockchain node A3 can generate a reply packet indicating that it has successfully acquired the target data packet sent by the block-producing node.

[0122] Blockchain node A3 can send the reply packet to the connected switch B2. Switch B2 can then forward the received reply packet to switch B1. Switch B1 can forward the reply packet to the connected block-producing node, allowing the block-producing node to confirm that blockchain node A3 has successfully obtained the target data packet it sent. Simultaneously, switch B1 also mirrors the obtained reply packet, enabling the processing device to also synchronously obtain the reply packet and its acquisition time. This acquisition time can also be the processing device's own acquisition time for the reply packet. The processing device can calculate the time difference between the acquisition time of the reply packet and the acquisition time of the request packet sent by the block-producing node. This time difference can be used as the network latency (i.e., network delay) for the target data packet sent by the block-producing node. This network latency is the round-trip time (RTT) for the target data packet, which is the time from when the request packet of the target data packet is sent to when the reply packet of the target data packet returns.

[0123] The network latency of a block-producing node within a segment interval, also known as the network latency metric, is the value of the aforementioned network latency indicator for the block-producing node within that segment interval. This indicator value can be equal to the sum of the network latency of all network data packets sent by the block-producing node within that segment interval; that is, it is equal to the sum of the network latency (network delay) of each network data packet sent by the block-producing node within that segment interval. If this sum is too large (e.g., greater than or equal to a set network latency threshold), it indicates that the network latency of the block-producing node is relatively severe, suggesting that the block-producing node has an anomaly under this network latency indicator.

[0124] As can be seen from the above process, the analytical data related to network latency indicators can include the acquisition time of network data packets (such as the request packet containing the target data packet sent by the block-producing node and the reply packet for that target data packet).

[0125] Both the request and response packets contain TCP-related protocol information (located in the data at layer 4 of the 7-layer computer model). This protocol information can include the type of the current network data packet (such as the type of a request packet or the type of a response packet). Therefore, the processing device can parse the TCP protocol information at layer 4 (transport layer) of the request or response packet to obtain the type of the current network data packet (such as a request packet or a response packet). This type can be either the type of a response packet or the type of a request packet. There can be a correspondence between a request packet and a response packet for the target data packet carried by that request packet. Furthermore, the network data packets (such as request packets and response packets) exchanged in the network will contain the IP address of their respective sender (such as the blockchain node that sent the network data packet) and receiver (such as the blockchain node to which the network data packet needs to be sent). When the processing device performs data parsing on the received network data packets, it can parse the IP protocol information at layer 3 (network layer) of the 7-layer computer model to obtain the IP address of the sender and the IP address of the receiver, thus identifying the sender and receiver of the network data packet.

[0126] The aforementioned network throughput metric is used to reflect the network throughput of block-producing nodes. The network throughput of block-producing nodes can be used to measure their load capacity. The value of this network throughput metric within a segmented interval (such as a time segment or a block height segment) can be the packet loss rate of the block-producing node within that segmented interval. The calculation method for the value of this network throughput metric within that segmented interval can include:

[0127] The total number of bytes of data processed by the block-producing node within a segment interval can be obtained. The network throughput of the block-producing node can then be calculated from this number of bytes. For example, the unit of network throughput can be bytes / second. The network throughput of the block-producing node within that segment interval can be calculated by taking the duration of the number of bytes within that segment interval (which can be in seconds).

[0128] For example, when a switch connected to a block-producing node receives a network data packet destined for the block-producing node, it can send the network data packet to the block-producing node and simultaneously mirror the network data packet, so that the processing device can also receive the network data packet at the same time.

[0129] The processing device can obtain the total number of bytes of network data packets received within a segment interval and used to send to the block-producing node. By dividing this number of bytes by the duration of the segment interval, the network throughput (in bytes per second) of the block-producing node within that segment interval can be obtained. This network throughput is the metric value of the aforementioned network throughput for the block-producing node within that segment interval. If this network throughput is too low (e.g., less than or equal to a set throughput threshold), it indicates that the block-producing node's data processing performance is poor, which means that the block-producing node has an anomaly under this network throughput metric.

[0130] As can be seen from the above process, the parsed data related to network throughput metrics can include network data packets sent to block-producing nodes for processing. The recipient of a network data packet can be determined by parsing the IP address obtained from the Layer 3 network protocol information of that network data packet. This parsed IP address can include the Internet Protocol address (IP address) of the blockchain node to which the network data packet needs to be sent (i.e., the recipient's IP address).

[0131] The aforementioned network packet loss rate metric is used to reflect the network packet loss rate of the block-producing node. The metric value within a segmented interval (such as a time segment or a block height segment) can be the total packet loss rate of the block-producing node within that segmented interval. The calculation method for this packet loss rate can include:

[0132] Through the above calculation process of the network latency index, it can be seen that the switch connected to the block output node can mirror the request packet sent by the block output node and the reply packet for the target data packet carried by the request packet, so that the processing device can also obtain the request packet sent by the block output node and the reply packet for the target data packet carried by the request packet.

[0133] A block-producing node can send several request packets within a segment interval. Some request packets will have a response packet for the target data packet they carry, while others may not have a corresponding response packet for the target data packet they carry. The target data packet without a corresponding response packet can be understood as being lost.

[0134] Therefore, the processing device can count the number of request packets in each request packet sent to the block-producing node within this segment interval where the target data packet does not have a corresponding reply packet. Then, the counted number can be divided by the total number of request packets sent by the block-producing node within this segment interval. The calculated value is the network packet loss rate (which can be simply called packet loss rate) of the block-producing node within this segment interval. This packet loss rate is the index value of the network packet loss rate for the block-producing node within this segment interval.

[0135] As can be seen from the above process, the parsed data related to the network packet loss rate metric can include the request packets sent by the block-producing node and the response packets for the target data packets carried in those request packets. The request packets sent by the block-producing node and the response packets for the target data packets within those request packets can be identified through the IP protocol information and TCP protocol information parsed from the received network data packets. The parsed IP protocol information can be used to determine the sender and receiver of the network data packets, and the parsed TCP protocol information can be used to determine the type of network data packets (such as the type of response packet or request packet).

[0136] Optionally, the aforementioned block detection metrics may include, but are not limited to, at least one of the following: basic block detection metrics and business block detection metrics. The basic block detection metrics are metrics related to certain characteristics of the block itself when the block-producing node packages the block. For example, the basic block detection metrics may include, but are not limited to, at least one of the following: metrics on the amount of resources consumed in processing transactions within the block, metrics on the number of transactions packaged (i.e., transactions packaged within the block), and metrics on the block's production delay.

[0137] The aforementioned indicator of resource consumption for processing transactions within a block can be used to reflect the total resource consumption of transactions in a block packaged by a block-producing node. The indicator value within a segmented interval (such as a time segment or a block height segment) can be: the total resource consumption (i.e., transaction gas fees) required to process all transactions in each block packaged by the block-producing node within that segmented interval. The process of calculating the indicator value within a segmented interval can include:

[0138] The target data packet carried in the request packet sent by the block-producing node can be the block packaged by the block-producing node. The processing device can obtain each request packet sent by the block-producing node within the segment interval, and can obtain each block packaged by the block-producing node within the segment interval carried in each request packet. Thus, the processing device can obtain the amount of resources (i.e., gas fee) required to process each transaction packaged in each block. A transaction will have a gas fee, which is the amount of resources required to process the transaction. This amount of resources is also the amount of resources required to process the transaction in the blockchain network. This amount of resources can also be called the transaction fee required to process the transaction. A transaction itself can carry its gas fee. The type of resources required to process the transaction and the specific amount of resources required can be set and determined according to the actual application scenario.

[0139] The processing device can calculate the total resource consumption required by each transaction packaged in each block. This total is the indicator value of the resource consumption of transactions in the processed block for the block-producing node within that segment interval. In other words, this indicator value is the sum of the resource consumption required by all transactions packaged by the block-producing node within that segment interval. If this total resource consumption is too large (e.g., greater than or equal to a set resource consumption threshold), it indicates that the block-producing node mainly tends to package transactions with higher returns (e.g., gas fees) and not package transactions with lower returns. In this case, it can be considered that the block-producing node has an anomaly in the indicator of the resource consumption of transactions in the processed block.

[0140] The analytical data related to the resource consumption of transactions in the aforementioned processing blocks can include the transactions in the blocks packaged by the block-producing node, obtained from the parsing of the application layer data in the network data packets, as well as the gas fees parsed from each transaction.

[0141] The aforementioned indicator of the number of transactions packaged is used to reflect the number of transactions packaged into a block by the block-producing node. The value of this indicator within a segmented interval (such as a time segment or a block height segment) can be the total number of transactions packaged by the block-producing node within that segmented interval. The calculation method for this indicator value can include:

[0142] The processing device can obtain the blocks packaged by the block-producing node within a given segment (obtained through request packets sent by the block-producing node), and can also obtain the transactions packaged within each block. Therefore, the processing device can calculate the total number of transactions packaged in each block (i.e., the total number of packaged transactions), and use this total number as an indicator of the number of packaged transactions for the block-producing node within that segment. If this total number is too large (e.g., greater than or equal to a set threshold), it indicates that the block-producing node has packaged too many transactions, making it easy for transactions in the blockchain network to become congested or experience severe delays. In this case, the block-producing node can be considered abnormal in terms of the number of packaged transactions.

[0143] The analytical data related to the number of transactions packaged as mentioned above can include each transaction in the block packaged by the block-producing node, obtained by parsing the application layer (layer 7) data in the network data packet.

[0144] The block production delay metric mentioned above is used to reflect the delay of the block-producing node in producing a block. The metric value within a segmented interval (such as a time segmented interval or a block height segmented interval) can be the total delay of the block-producing node in producing a block within that segmented interval. The calculation method for the metric value within a segmented interval can include:

[0145] Here, we first explain the block production delay for a block: For a block, the block production delay (i.e., block production latency) can be equal to the time interval between the block production time of the block and the production time of the previous block. The block production time of a block can be the time when the block producing node sends out a request packet carrying the block. Since the request packet will be synchronously mirrored to the processing device through the switch connected to the block producing node, the time when the processing device obtains the request packet can be used as the block production time of the block carried by the request packet obtained by the processing device.

[0146] The processing device can calculate the block production latency of each block packaged by the block-producing node within a segmented interval, according to the principles described above. It can also sum the block production latency of each block and use this sum as an indicator of the block production latency for the block-producing node within that segmented interval. If the sum of the block production latency is too large (e.g., greater than or equal to a set block production latency threshold), it indicates that the block production latency of the block-producing node is too high. In this case, the block-producing node can be considered to have an anomaly in the block production latency indicator for that block.

[0147] The parsing data related to the block production delay metrics of the aforementioned blocks can include the acquisition time of the request packets belonging to each block, which can be used as the block production time for each block. The type of network data packet (such as the type of the request packet) can be obtained by parsing the TCP protocol information at the fourth transport layer of the network data packet.

[0148] This business block production metric refers to the indicators related to the actual business being packaged by the block-producing node. It can be used to reflect whether the block-producing node has a business bias when packaging transactions. For example, this bias could refer to whether it is more likely to package transactions for processing a specific business. For instance, this business block production metric may include, but is not limited to, at least one of the following: an indicator of the frequency of calls to contract methods in the block's transactions, an indicator of the frequency of contract event triggers in the block's transactions, and an indicator of the frequency of contract calls in the block's transactions.

[0149] The frequency of transaction method calls in the aforementioned block is used to reflect whether the block-producing node has any bias in the contract methods called by the transactions packaged into the block. The value of this indicator within a segmented interval can be the frequency (i.e., number of times) of each contract method call by the transaction pairs in the block packaged by the block-producing node. The calculation method for the value of this indicator within a segmented interval can include:

[0150] The processing device can obtain the blocks packaged by the block-producing node within a given segment (obtainable through request packets carrying these blocks). It can extract the transactions packaged by the block-producing node from these blocks and retrieve the contract methods invoked by each transaction. The processing device can then calculate the call frequency (i.e., the number of calls) of each contract method invoked by each transaction pair. Therefore, the call frequency of each contract method can be used as an indicator of the call frequency of the transaction pair's contract methods within the block, representing the block-producing node's index value within that segment. A transaction itself can contain the contract methods it invokes.

[0151] For example, the transactions packaged into a block by the block-producing node within this segment interval may include transactions 1 through 10. Transaction 1 calls contract method f1, transaction 2 calls contract method f1, transaction 3 calls contract method f1, transaction 4 calls contract method f1, transaction 5 calls contract method f3, transaction 6 calls contract method f2, transaction 7 calls contract method f1, transaction 8 calls contract method f2, transaction 9 calls contract method f1, and transaction 10 calls contract method f3. Therefore, it can be seen that in transactions 1 through 10, the frequency of calling contract method f1 is 6, the frequency of calling contract method f2 is 2, and the frequency of calling contract method f3 is 2. This indicates that the block-producing node has a bias towards contract method f1 when packaging transactions.

[0152] If the frequency of calls to any contract method of the transaction pair packaged by the block-producing node in this segment interval is too high (e.g., greater than or equal to the set method call frequency threshold), it indicates that the block-producing node has a bias towards transactions that call that contract method. In this case, it can be considered that the block-producing node has an anomaly in the indicator of the frequency of calls to the contract method of the transaction pair in this block.

[0153] As can be seen from the above process, the analytical data related to the frequency of transaction calls to contract methods in the above block can also include the various transactions packaged into the block by the block-producing node, as well as the contract methods called by each transaction. Among them, the various transactions packaged into the block can be obtained by parsing the data of the 7th layer application layer, and the contract methods called by each transaction can be obtained by parsing the transaction itself.

[0154] Similarly, the metric of the frequency of transaction pair contract events triggered in the aforementioned blocks is used to reflect whether the block-producing node has a bias towards the contract events triggered by the transactions included in the block. For example, whether the block-producing node will include more transactions that trigger a specific contract event. The value of this metric within a segmented interval can be the frequency (i.e., number of times) of each contract event triggered by the transaction pair in the block included by the block-producing node. The calculation method for the value of this metric within a segmented interval can include:

[0155] The processing device can obtain the blocks packaged by the block-producing node within a given segment (obtainable through request packets carrying these blocks). It can extract the transactions packaged by the block-producing node from these blocks and retrieve the contract events triggered by each transaction. The processing device can then calculate the trigger frequency (i.e., the number of calls) of each contract event triggered by each transaction pair. Therefore, the trigger frequency of each contract method can be used as an indicator of the trigger frequency of contract events for the transaction pair within the aforementioned block, representing the indicator value for the block-producing node within that segment. A single transaction can contain its own triggered contract events.

[0156] For example, the transactions packaged into a block by the block-producing node within this segment interval may include transactions 1 through 5. Transaction 1 triggers contract event s1, transaction 2 triggers contract event s2, transaction 3 triggers contract event s1, transaction 4 triggers contract event s1, and transaction 5 triggers contract event s1. Therefore, among transactions 1 through 5, the trigger frequency of contract event s1 is 4, while the trigger frequency of contract event s2 is 1. This indicates that the block-producing node exhibits a bias towards contract event s1 when packaging transactions.

[0157] If the frequency of triggering any contract event of a transaction pair packaged by the block-producing node in this segment interval is too high (such as greater than or equal to the set event triggering frequency threshold), it indicates that the block-producing node has a bias towards the transactions that trigger the contract event. In this case, it can be considered that the triggering frequency of the transaction pair contract event of the block-producing node is abnormal.

[0158] As can be seen from the above process, the analytical data related to the frequency of contract event triggering indicators in the above block can also include the various transactions packaged into the block by the block-producing node, as well as the contract events triggered by each exchange. Similarly, the various transactions packaged into the block can be obtained by parsing the data of the 7th layer application layer, and the contract events triggered by each transaction can be obtained by parsing each transaction itself.

[0159] Similarly, the metric of transaction call frequency in the aforementioned block is used to reflect whether the block-producing node has any bias towards the contracts called by the transactions packaged into the block, such as whether the block-producing node packages more transactions that call a particular contract. The metric value within a segmented interval can be the frequency (i.e., number of times) of transactions calling each contract in the block packaged by the block-producing node. The calculation method for the metric value within a segmented interval can include:

[0160] The processing device can obtain the blocks packaged by the block-producing node within a given segment (obtainable through request packets carrying these blocks). The processing device can extract the transactions packaged by the block-producing node from these blocks and identify the contracts invoked by each transaction. The processing device can then calculate the call frequency (i.e., the number of calls) of each contract invoked by each transaction pair. Therefore, the call frequency of each contract can be used as an indicator of the call frequency of the transaction pair contracts within the aforementioned block, representing the indicator value for the block-producing node within that segment. A transaction itself can contain the contracts it invokes (i.e., smart contracts).

[0161] For example, the transactions packaged into a block by the block-producing node within this segment interval may include transactions 1 through 5. Transaction 1 calls contract h1, transaction 2 calls contract h2, transaction 3 calls contract h2, transaction 4 calls contract h2, and transaction 5 calls contract h2. Therefore, among transactions 1 through 5, the frequency of calling contract h1 is 1, and the frequency of calling contract h2 is 4. This indicates that the block-producing node has a bias towards contract h2 when packaging transactions.

[0162] If the block-producing node calls any contract of a transaction pair within a segmented interval too frequently (e.g., more than or equal to the set contract call frequency threshold), it indicates that the block-producing node has a bias towards transactions that call that contract. In this case, it can be considered that the block-producing node has an anomaly in the indicator of the frequency of contract calls of the transaction pair in that block.

[0163] As can be seen from the above process, the analytical data related to the frequency of contract calls in the above block can also include the various transactions packaged into the block by the block-producing node, as well as the contracts called by each exchange. Among them, the various transactions packaged into the block can be obtained by parsing the data of the 7th layer application layer, and the contracts called by each exchange can be obtained by parsing each transaction itself.

[0164] Optionally, the blockchain network in this application can be a consortium blockchain, which can be composed of blockchain nodes from multiple groups. Each consensus node in the blockchain network can also be provided by these multiple groups. For example, one group can provide at least one consensus node in the blockchain network. Therefore, when a group's consensus node acts as the block-producing node, it may prioritize packaging transactions initiated by its own group. The contract events triggered by a transaction initiated by a group, or the contract methods and contracts called, are usually relatively fixed and specific. Therefore, in this application, the transactions in the aforementioned blocks... Metrics such as call frequency, call frequency of contract methods in blocks, and trigger frequency of contract events in blocks can be used to detect whether block-producing nodes show bias towards contract events, contracts, and contract methods triggered by exchanges when packaging transactions. This can accurately detect whether block-producing nodes tend to package transactions initiated by their own group, while packaging only a small number of transactions initiated by other groups. In other words, it can detect whether block-producing nodes have business biases when packaging transactions, such as whether most of the transactions packaged by block-producing nodes are used for the business of the block-producing node's own group.

[0165] Step S103: Detect the block-producing node based on the parsed data to obtain the detection result, which indicates the block-producing process of the block-producing node.

[0166] Optionally, each of the above N detection indicators can have its own corresponding sliding window. This application can detect block-producing nodes through the sliding window corresponding to each detection indicator. The sliding window can be used to perform segmented detection on block-producing nodes under the corresponding detection indicator. The specific type of segmented detection can be determined according to the specific window type of the sliding window, such as segmented detection in time or segmented detection in block height, as described below.

[0167] Among the aforementioned N detection indicators, different detection indicators may correspond to the same sliding window or different sliding windows. That is, a sliding window can be used to segment and detect block-producing nodes under one or more corresponding detection indicators. The relationship between detection indicators and sliding windows can be one-to-one, one-to-many, or many-to-one. The specific number of detection indicators (i.e., the specific value of N) and the specific number of sliding windows corresponding to the N detection indicators can be configured according to the actual application scenario, and this application does not impose any restrictions on this.

[0168] For example, the sliding window in this application may include, but is not limited to, at least one of the following: a time sliding window, a block height sliding window. Alternatively, depending on the actual application, other types of sliding windows may be set, and this application does not limit this.

[0169] The aforementioned time sliding window can be used to slide and select a time segment interval (i.e., slide and select a time interval). Therefore, this time sliding window can be used to perform time-segmented detection on block-producing nodes under the corresponding detection indicators, which can also be called time-sliding detection. If the time sliding window can be in minutes (or other time units such as seconds, hours, days, months, etc.), and you can select a time interval of 5 minutes (or other durations such as 1 minute, 10 seconds, or 1 day, etc.) at a time, starting from 12:00 (i.e., 12 o'clock exactly), then the first time interval selected through the time sliding window can be [12:00, 12:05), that is, 12:00 to 12:05; the second time interval can be [12:05, 12:10), that is, 12:05 to 12:10; the third time interval can be [12:10, 12:15), that is, 12:10 to 12:15, and so on.

[0170] The aforementioned block height sliding window can be used to slide and select a block height segment interval (i.e., slide and select a block height interval). Therefore, this block height sliding window can be used to perform segment detection on the block height of the block-producing node under the corresponding detection index, which can also be called sliding detection on the block height. The block height sliding window can select a range of 10 blocks (or other numbers of blocks) at a time, starting from the block height of the first block produced by the current block-producing node (block height start point). If the block height of the first block is 1, then the block height segment range selected by the block height sliding window can be [1, 10], including the first to the tenth blocks packaged by the block-producing node. The selected second block height range can be [11, 20], including the eleventh to the twentieth blocks packaged by the block-producing node. The selected third block height range can be [21, 30], including the twentieth to the thirtieth blocks packaged by the block-producing node, and so on.

[0171] After parsing the acquired first data packet to obtain the parsed data related to the aforementioned k detection indicators, the processing device can place the parsed data related to each of the k detection indicators into the corresponding sliding window for each detection indicator to calculate (or statistically obtain) the corresponding indicator value for each detection indicator. Thus, the block node can be evaluated under the corresponding detection indicator based on the calculated indicator value. The specific process is described below. Figure 7 The relevant descriptions in the corresponding embodiments.

[0172] Please see Figure 5 , Figure 5 This is a schematic diagram of a strategy design class diagram provided in an embodiment of this application. For example... Figure 5 As shown in the design class diagram, it can include basic configuration (BaseConfig), business configuration (BizConfig), and window configuration (WindowsConfig). The basic configuration can be used to configure some basic detection metric attributes, such as the basic block production metrics mentioned above, which may include maximum resource consumption (i.e., the amount of resources consumed by the transactions in the processing block mentioned above), maximum latency (i.e., the block production latency of the block mentioned above), and maximum number of transactions (i.e., the number of transactions packaged mentioned above), etc.

[0173] The aforementioned business configuration can be used to configure some fine-grained detection metrics related to business operations, such as the aforementioned block production metrics, which may include contract name (i.e., the metric of the frequency of calls to the contract of the transaction pair in the aforementioned block), contract method (i.e., the metric of the frequency of calls to the contract method of the transaction pair in the aforementioned block), contract event (i.e., the metric of the frequency of triggering the contract event of the transaction pair in the aforementioned block), etc. This application can set more comprehensive business-related detection metrics according to actual business needs, and the specific configuration can be tailored to the actual application scenario; this application does not impose any restrictions on this.

[0174] In addition, the design class diagram can also include network configuration, which can be used to configure the aforementioned network detection metrics at a fine-grained level. The window configuration can be used to configure the sliding windows corresponding to each detection metric. The relationship between the detection metric and the sliding window can be many-to-one, one-to-many, or one-to-one, depending on the specific application scenario.

[0175] Here, the detection processing of the block-producing node can include detection processing of the block-producing node under the above k detection indicators. The detection result of the block-producing node under one detection indicator can be either normal or abnormal. The processing device can obtain the final detection result of the block-producing node by the detection results of the block-producing node under the k detection indicators. This detection result can indicate the block-producing node's block-producing process. The block-producing process can include whether the block-producing node is producing blocks abnormally or normally. It can be understood that the block-producing process can be the state of the block-producing node producing blocks, and the block-producing state can be either an abnormal block-producing state or a normal block-producing state.

[0176] Specifically, if a block-producing node is detected as abnormal under any of the k detection metrics, the block-producing process indicated by the detection result can include abnormal block production; that is, the detection result is used to indicate that the block-producing node is producing blocks abnormally. Conversely, if a block-producing node is detected as normal under all k detection metrics, the block-producing process indicated by the detection result can include normal block production; that is, the detection result is used to indicate that the block-producing node is producing blocks normally.

[0177] Furthermore, the processing device can determine whether to switch the current block-producing node, i.e., whether to reselect the next block-producing node, based on the detection results of the block-producing node, as described below.

[0178] If the block production process indicated by the above detection results includes normal block production, the processing device may not trigger a switch of the current block-producing node in the blockchain network, and can keep the current block-producing node unchanged in the blockchain network. However, if the block production process indicated by the above detection results includes abnormal block production, the processing device may trigger a switch of the current block-producing node in the blockchain network.

[0179] Optionally, the process of the processing device triggering the switching process of the block-producing node in the blockchain network may include: the processing device may generate a chain configuration transaction for the blockchain network, which may be a transaction for configuring the blockchain network, and the chain configuration transaction may be used to trigger the switching process of the block-producing node in the blockchain network. In other words, the chain configuration transaction may be a transaction for requesting the switching of the current block-producing node in the blockchain network.

[0180] The processing device can send the chain configuration transaction to the consensus nodes in the blockchain network, enabling the consensus nodes to switch the current block-producing node in the blockchain network using the chain configuration transaction. For example, the consensus nodes in the blockchain network can package and reach consensus on the chain configuration transaction, and after the consensus on the chain configuration transaction is passed (i.e., consensus is successful), they can switch the current block-producing node in the blockchain network.

[0181] Furthermore, the aforementioned multiple blockchain nodes in the blockchain network can include multiple consensus nodes, and these multiple consensus nodes can include the aforementioned block-producing nodes. That is, the block-producing node can belong to the consensus nodes in the blockchain network, and the block-producing node is included among the multiple consensus nodes.

[0182] In this application, the processing device can also obtain a second data packet sent by the switch through the port mirroring module. The second data packet can be a network data packet related to other consensus nodes among the above-mentioned multiple consensus nodes, excluding the block-producing node. The relationship between the second data packet and the other consensus node can be the same as the relationship between the first data packet and the block-producing node. For example, the network data packet related to the other consensus node can also include at least one of the following: the network data packet containing the data sent by the other consensus node, and the network data packet containing the data that the other consensus node needs to receive.

[0183] The processing device can use the second data packet to detect the network status of each consensus node other than the block producing node among the multiple consensus nodes. The processing device can use the second data packet associated with a consensus node to detect the network status of that consensus node. The result of the network status detection can be either an abnormality or a normality.

[0184] The principle behind detecting the network state of consensus nodes here is the same as the principle behind detecting the network state of block nodes using the aforementioned network detection metrics and their corresponding sliding windows. Since there can be multiple network detection metrics, if a consensus node's network state is detected as abnormal under at least one network detection metric, then the overall network state of that consensus node can be considered abnormal. Conversely, if a consensus node's network state is detected as normal under all network detection metrics, then the overall network state of that consensus node can be considered normal.

[0185] The network status detected by the consensus nodes other than the block-producing nodes among the aforementioned consensus nodes can be used to select the next block-producing node when the block-producing node needs to be switched (that is, the block-producing node described above, i.e., the block-producing node described separately in this application is the current block-producing node). The next block-producing node is the consensus node used to switch the current block-producing node. That is, after the current block-producing node is switched, the next block-producing node can package the blocks in the blockchain network, i.e., the next block-producing node will continue to produce blocks.

[0186] In one feasible implementation, the method of selecting the next block-producing node based on the network status detected by each consensus node other than the block-producing node can include: avoiding selecting a consensus node with an abnormal network status as the next block-producing node, and instead selecting the next block-producing node from consensus nodes with a normal network status. This avoids selecting a consensus node with poor network status as a new block-producing node, thereby affecting the efficiency and performance of block production in the blockchain network. The next block-producing node is a different consensus node from the current block-producing node.

[0187] For example, the processing device can provide the network status detection results of consensus nodes other than block-producing nodes to each consensus node. After receiving the above chain configuration transaction, each consensus node can elect the next block-producing node from among the consensus nodes whose network status is detected as normal.

[0188] Please see Figure 6 , Figure 6 This is a schematic diagram of a consensus intervention architecture provided in an embodiment of this application. For example... Figure 6 As shown, this application can be applied to any blockchain application, such as applications related to data elements, enterprise services, and supply chains. Accordingly, the blockchain network of this application can be a consortium blockchain related to data elements, in which multiple groups can be groups that share the work of uploading data at various stages of data processing; or, the blockchain network of this application can also be a consortium blockchain related to enterprise services, in which multiple groups can be different enterprise departments, and different enterprise departments can be used to initiate different enterprise transactions; or, the blockchain network of this application can also be a consortium blockchain related to supply chains, in which multiple groups can be groups of different roles in various stages of the supply chain from production to consumption, such as merchants, testing platforms, suppliers, and distributors.

[0189] In this blockchain application, each group can initiate a blockchain transaction (which can be simply referred to as a transaction) through its own blockchain node. The transaction will be sent to the contract node (which belongs to the blockchain node) configured with the invoked contract for processing. The data packet of the transaction (i.e., the network data packet containing the transaction) can be propagated in the blockchain network through the switches connected by each contract node.

[0190] Therefore, the switch can use its port mirroring modules (such as unidirectional port mirroring modules, bidirectional port mirroring modules, multi-source port mirroring modules, and / or single-source port mirroring modules) to copy the data packet to which the transaction belongs to the processing device. The processing device can provide detection services. After obtaining the data packet to which the transaction belongs, the processing device can perform corresponding data parsing processing on the data packet to obtain parsed data. This parsed data can then be used to analyze the network-related information of the block-producing node and the information related to the packaging of blocks, thereby realizing the detection of the block-producing node.

[0191] Therefore, consensus intervention in the blockchain network can be achieved through consensus intervention strategies and the detection results of block-producing nodes. For example, the consensus intervention strategy includes: triggering a switchover of the current block-producing node when the block-producing node's block-producing process includes abnormal block production; and not triggering a switchover when the block-producing node's block-producing process includes normal block production. This improves the functionality and scalability of the blockchain network in terms of business support.

[0192] In addition, the processing device can also send network-related data (such as network layer data) from the acquired network data packets to other data analysis platforms or data analysis tools, enabling the data analysis device to perform more detailed analysis of the network status. For example, the data analysis device can reproduce the network topology of the entire network through network layer data, and by analyzing the data transmission and reception status (such as data transmission and reception time) of each data node (any end used for data transmission and reception) in the reproduced network topology, it can analyze which data nodes currently have large network latency.

[0193] Furthermore, the processing device can also obtain the packet sending and receiving status between various blockchain nodes (such as the network data packets sent between blockchain nodes) and the specific content of the blocks (which may include the specific transactions within the packaged blocks) by copying the network data packets obtained from the switch ports. It can also visualize the packet sending and receiving status and the specific content of the blocks. For example, it can configure a detection client and provide the packet sending and receiving status and the specific content of the blocks to the detection client, thereby displaying the visualization on the client interface of the detection client; or it can import the packet sending and receiving status and the specific content of the blocks into other data analysis tools for further and deeper data analysis and processing, which can be determined according to the actual application scenario.

[0194] This application achieves lossless and non-infringing replication of data from layers 2 to 7 of the 7-layer computer model through the port mirroring module of a switch. The replicated data enables accurate multi-dimensional detection of block-producing nodes and other consensus nodes in the blockchain network. By sensing weak network conditions or network failures of blockchain nodes, block-producing nodes can be adjusted in a timely manner to ensure healthy network operation. This allows for switching intervention (also known as consensus intervention) of block-producing nodes in the blockchain network, thereby improving the performance and stability of block production in the blockchain network.

[0195] Furthermore, since the network data packets obtained through the port mirroring module of the switch are nested into layers 2 to 7, and each layer of data is parsed layer by layer, network-related data (such as network layer and transport layer related data) will be parsed first, and then application-related data (such as specific transaction data in the application layer) will be parsed. Moreover, since the above network detection indicators use the parsed network-related data, this application can first use the network detection indicators to perform segmented detection on the block-producing node. If the block-producing node is detected as abnormal by the network detection indicators, the switching process of the block-producing node can be directly triggered, and there is no need to use the above block detection indicators to detect the block-producing node again.

[0196] If the block-producing node is detected as normal by the network detection metric, it can continue to be segmented for detection using the same metric. If the block-producing node is detected as abnormal, a switchover process for the block-producing node can be triggered. This approach improves the efficiency of block-producing node detection and reduces the workload and overhead of such detection.

[0197] In this application's blockchain network, multiple blockchain nodes can interact via a switch. These multiple blockchain nodes include block-producing nodes. The switch can have a port mirroring module, which can mirror the network data packets exchanged between the blockchain nodes. The mirrored network data packets can include a first data packet related to the block-producing node, such as a network data packet sent by the block-producing node or a reply data packet corresponding to a network data packet sent by the block-producing node. Since the switch is located at the data link layer (Layer 2) of a 7-layer computer model, the first data packet obtained through the switch's port mirroring module can contain data from Layers 2 to 7 of the 7-layer computer model, including the Layer 2 network layer and the Layer 7 application layer (belonging to the business layer, which can include the blocks specifically packaged by the block-producing node and the transactions within those blocks). Therefore, the first data packet obtained through the mirroring process of the switch can enable detection of the block-producing node at multiple levels (such as the network layer and the business layer) to detect the block-producing node's block-producing process, thereby improving the accuracy of detecting the block-producing node's block-producing process.

[0198] Please see Figure 7 , Figure 7 This is a schematic flowchart illustrating a block-producing node detection process provided in an embodiment of this application. This embodiment describes the specific process of detecting block-producing nodes by parsing the parsed data obtained from the first data packet described above. For example... Figure 7 As shown, the process may include:

[0199] Step S201: The parsing data related to the k detection indicators are placed into the sliding windows corresponding to the k detection indicators respectively.

[0200] Optionally, the processing device can place the parsed data related to the aforementioned k detection indicators obtained from parsing the first data packet into the respective sliding windows corresponding to the k detection indicators. It should be noted that the parsed data placed into the sliding window is data within the currently selected segment interval of that sliding window.

[0201] For example, if the sliding window is a time sliding window, the generation time of the parsed data placed in the time sliding window is within the time segment interval currently selected by the time sliding window. The generation time of the parsed data can be the time when the processing device receives the network data packet (such as the first data packet) to which the parsed data belongs.

[0202] For example, if the sliding window is a block height sliding window, then the parsed data placed into this block height sliding window is related to the block height, and the block height of the related block is within the block height range currently selected by the block height sliding window. For example, the parsed data can be transaction data packaged in a block by a block-producing node, then the block height of the block to which the transaction data belongs is within the block height range currently selected by the block height sliding window; or the parsed data can be directly a block packaged by a block-producing node, then the block height of that block is within the block height range currently selected by the block height sliding window; or the parsed data can be directly a network data packet, and when the network data packet is generated (which could be the time when the processing device obtains the network data packet), the current maximum block height in the blockchain network is within the block height range currently selected by the block height sliding window.

[0203] Step S202: In the sliding window corresponding to the k detection indicators, based on the parsing data put in, the indicator values ​​of each of the k detection indicators are statistically calculated. The indicator values ​​are obtained by statistically analyzing the parsing data related to the detection indicator put in the currently selected segment interval of the sliding window corresponding to the detection indicator.

[0204] Optionally, the processing device can statistically analyze the values ​​of each of the k detection indicators by inserting analytical data into the sliding windows corresponding to the k detection indicators. These values ​​are the latest statistical results obtained from the analytical data inserted into the sliding windows corresponding to the k detection indicators. Each detection indicator has its own value, and each indicator can have one value. Therefore, here, one of the k detection indicators can have a statistically obtained value, which is obtained by statistically analyzing the analytical data related to that indicator inserted into the currently selected segment interval of the sliding window corresponding to that indicator. Specifically, the statistically obtained values ​​for the k detection indicators can be obtained by superimposing the original values ​​of each indicator onto the latest analytical data inserted into the sliding windows corresponding to each indicator. The original values ​​of each indicator can be obtained by statistically analyzing the analytical data inserted into the sliding windows corresponding to each indicator previously.

[0205] If k is less than N, then for the other detection indicators among the above N detection indicators besides the k detection indicators, their indicator values ​​are not updated by the first data packet currently received, because the first data packet does not carry or contain parsing data related to the other detection indicators. Therefore, the indicator values ​​of the other detection indicators remain the original indicator values. For example, the original indicator values ​​can be the indicator values ​​obtained by statistically analyzing network data packets related to the block-producing node received before the current first data packet.

[0206] Among the above N detection indicators, the values ​​of the other detection indicators besides the k detection indicators can also be regarded as being updated through the first data packet, but the result of the update is to keep the original values ​​of the other detection indicators unchanged.

[0207] Step S203: Based on the index values ​​of k detection indicators, perform detection processing on the block-producing nodes under the k detection indicators to obtain the detection results.

[0208] Optionally, the processing device can use the index values ​​obtained from the statistical analysis of the k detection indicators to perform detection processing on the block-producing node under those k detection indicators. A block-producing node may be detected as abnormal or normal under one detection indicator. The principle of detecting the block-producing node under each detection indicator can be the same. Any one of the k detection indicators can be called a target detection indicator. The following example illustrates the process of detecting the block-producing node under the target detection indicator by using the index values ​​obtained from the statistical analysis of the target detection indicator.

[0209] The processing device can obtain a reference range of target detection metrics. This reference range defines the reasonable (or normal) range of the target detection metrics' values. Ranges outside this reference range are considered unreasonable (or abnormal). Optionally, this reference range can be defined by a threshold value (such as the aforementioned network latency threshold, throughput threshold, resource threshold, quantity threshold, block production latency threshold, method call frequency threshold, contract call frequency threshold, time trigger frequency threshold, etc.). For example, the reference range can be a range where the metric value is less than or equal to the threshold value, or a range where the metric value is greater than or equal to the threshold value. Alternatively, the reference range can also be the range between two values ​​(such as two unequal reference metric values), which can be set according to the actual application scenario.

[0210] Therefore, if the value of the target detection index is not within (i.e. not within) the range of the reference index value, the processing device can determine that the block output node is currently abnormal under the target detection index, and the latest index value of the block output node under the target detection index is within the abnormal range, rather than within the normal range.

[0211] If the value of the target detection index is within the range of the reference index value, the processing device can determine that the block output node is currently detecting normally under the target detection index, and the latest index value of the block output node under the target detection index is within the normal range.

[0212] If a block-producing node is detected as abnormal under any of the k detection metrics mentioned above, then the block-producing process indicated by the detection results of the block-producing node can include abnormal block production, indicating that the block-producing node is currently producing abnormal blocks. Conversely, if the block-producing node is detected as normal under all k detection metrics, then the block-producing process indicated by the detection results of the block-producing node can include normal block production, indicating that the block-producing node is currently producing blocks normally.

[0213] The processing device can statistically obtain the index values ​​of various detection indicators among the k detection indicators mentioned above within the current sliding window using the above-described principle. Therefore, by using the statistically derived index values, the device can detect the block-producing node based on the first data packet acquired. Specifically, each time the processing device acquires a network data packet related to the block-producing node, it can detect the block-producing node under the aforementioned N detection indicators according to the principle described above.

[0214] It should be noted that within the segmented interval selected by the sliding window, the values ​​of the aforementioned N detection indicators are continuously updated in real time based on the acquired network data packets. Each time a network data packet related to the block-producing node is acquired, the block-producing node can be detected in real time under the aforementioned N detection indicators, that is, the indicator values ​​of various detection indicators are updated in real time, thereby determining in real time whether there are any anomalies in the block-producing node. Once an anomaly is detected, the switching process for the current block-producing node can be immediately triggered. The method for calculating the indicator values ​​of each detection indicator within the segmented interval of the sliding window can be found above. Figure 3 The relevant descriptions in step S103 of the corresponding embodiment will not be repeated here.

[0215] Furthermore, a sliding window can be used to select a segmented interval at the same time. The sliding window can continuously slide to select different and continuous segmented intervals. If an abnormal block-producing node is detected within a segmented interval of the sliding window, and that block-producing node needs to be switched, the sliding window can be reset, and the segmented interval selected by the sliding window can be reset to the current starting point. For example, the current time point can be reset to the new time starting point of the sliding window, or the block height of the first block produced by the next block-producing node after the switch can be reset to the new block height starting point of the sliding window. The data in the sliding window is then cleared, and the next block-producing node can continue to be segmented and detected through the reset sliding window to determine whether the next block-producing node needs to be switched again, and so on.

[0216] Furthermore, if a block-producing node is detected to be producing blocks normally within a segment of the sliding window, after the segment ends (e.g., the current time exceeds the latest time of the time interval, or the block height reached in the current blockchain network exceeds the maximum block height of the interval height), the segment selected by the sliding window can be slid and adjusted to the next segment, and the block-producing node can continue to be detected within the next segment, that is, whether the current block-producing node needs to be switched within the next segment.

[0217] Please see Figure 8 , Figure 8 This is a schematic diagram illustrating a scenario where a time-based sliding window is used to detect the sliding of block-producing nodes, as provided in an embodiment of this application. Figure 8 As shown, this example uses a time sliding window. The starting point of this time sliding window can be 12:00, and the duration of the selected time interval (or simply time interval) is 5 minutes. Therefore, the first time interval selected through this time sliding window is 12:00 to 12:05.

[0218] If, after 12:05, a block-producing node is detected as producing blocks normally within the first time interval, the selected time interval of the time sliding window can be moved to the second time interval, 12:05–12:10, and block-producing nodes can continue to be detected within this second time interval. If a block-producing node is also detected as producing blocks normally within the second time interval, the selected time interval of the time sliding window can be moved to the third time interval, 12:10–12:15, and block-producing nodes can continue to be detected within this third time interval; and so on. This continues until a block-producing node is detected as producing blocks abnormally within a certain time interval. At this point, the time sliding window can be reset to detect the next block-producing node.

[0219] Please see Figure 9 , Figure 9 This is a schematic diagram illustrating a scenario where a sliding window based on block height is used to detect the sliding of block-producing nodes, as provided in an embodiment of this application. Figure 9 As shown, this explanation uses a block height sliding window as an example. Here, the starting point of the block height sliding window can be 50. This 50 can be the block height of the first block that the current block-producing node is selected to produce or that has already produced. The block height segment range selected by this block height sliding window (which can be simply called the block height range) contains 10 block heights. Therefore, the first block height range selected through this block height sliding window is 50 to 60.

[0220] If the maximum block height in the blockchain network exceeds 60, and a block-producing node is detected as producing blocks normally within the first block height range, the selected block height range of the sliding window can be moved to the second block height range (61-70), and block-producing nodes can continue to be detected within this second block height range. If a block-producing node is also detected as producing blocks normally within the second block height range, the selected block height range of the sliding window can be moved to the third time range (71-80), and block-producing nodes can continue to be detected within this third block height range; and so on. This continues until a block-producing node is detected as producing blocks abnormally within a certain block height range. At this point, the block height sliding window can be reset, and the next block-producing node can be detected using the reset block height sliding window.

[0221] It should be noted that since this application can have one or more sliding windows, when any sliding window detects that a block-producing node is producing an abnormal block and triggers a switch process for that block-producing node, all sliding windows can be reset as described above. This allows the next block-producing node obtained after the switch to continue to be detected using the principles described above through each reset sliding window, thereby continuously switching and updating the block-producing nodes in the blockchain network and ensuring the normal and high-performance packaging of blocks in the blockchain network.

[0222] Furthermore, if the switching process for the block-producing node is not triggered by the method described in this application, but the block-producing node automatically triggers the switching process through other normal procedures (such as switching the block-producing node once every time period), then each sliding window can also be reset in the manner described above in this application, so that the detection of the next block-producing node that is automatically switched can continue through the reset sliding windows.

[0223] In addition, the processing device can also detect in real time (e.g., every certain period of time, such as a set duration of 5 seconds) whether the range of reference index values ​​in each sliding window has changed (e.g., whether a new range of reference index values ​​has been configured). If a change is detected, the newly configured range of reference index values ​​can be updated to the corresponding sliding window so that the block-producing node can be subsequently detected using the newly configured range of reference index values.

[0224] Using the method provided in this application, block-producing nodes can be detected under various detection indicators through various sliding windows to determine whether the current block-producing node needs to be switched. Furthermore, the network status of other consensus nodes besides the current block-producing node can also be detected through various sliding windows, thereby avoiding the selection of consensus nodes with abnormal network status as the next block-producing node after switching, thus ensuring the performance and stability of block production in the blockchain network.

[0225] The method described in this application configures a port mirroring module on the local area network egress switch of the blockchain node in the consortium blockchain, and performs packet capture processing to achieve consensus intervention. This solves the problems of excessive node accounting power and difficulty in perceiving the consensus operation status (such as network conditions and block packaging status), without intruding on the node itself. Furthermore, it comprehensively considers common business dimensions in transactions, including factors such as gas fees, contracts, contract methods, and contract events, and uses sliding window technology for corresponding segmentation processing, solving the problem of difficulty in perceiving transaction content in the consensus algorithm and greatly reducing the bias of nodes in packaging transactions.

[0226] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a data processing device for a blockchain network provided in an embodiment of this application. The blockchain network includes multiple blockchain nodes, each containing a block-producing node. Data exchange between the multiple blockchain nodes is based on a switch, which has a port mirroring module. Figure 10 As shown, the data processing device 1 of the blockchain network may include: an acquisition module 11, a parsing module 12, and a detection module 13.

[0227] The acquisition module 11 is used to receive the first data packet sent by the switch through the port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block output node. The network data packets related to the block output node include at least one of the following: the network data packet containing the data sent by the block output node, and the network data packet containing the data that the block output node needs to receive.

[0228] Parsing module 12 is used to parse the first data packet to obtain parsed data;

[0229] The detection module 13 is used to detect and process the block-producing node based on the parsed data, obtain the detection result, and the detection result indicates the block-producing process of the block-producing node.

[0230] Optionally, the block-producing node has N detection indicators, where N is an integer greater than or equal to 1;

[0231] The parsing module 12 performs data parsing processing on the first data packet to obtain the parsed data in the following ways:

[0232] The first data packet is parsed to obtain parsed data related to k of the N detection indicators, where k is an integer less than or equal to N.

[0233] Optional, the N detection metrics include network detection metrics and block output detection metrics;

[0234] Among them, network detection indicators include at least one of the following: network latency indicators, network throughput indicators, and network packet loss rate indicators.

[0235] Block production detection metrics include at least one of the following: basic block production metrics and business block production metrics;

[0236] The basic block production metrics include at least one of the following: metrics for the amount of resources consumed by the transactions in the block, metrics for the number of transactions packaged, and metrics for the block production delay.

[0237] Business block production metrics include at least one of the following: metrics on the frequency of calls to contracts in the block, metrics on the frequency of calls to methods in contracts in the block, and metrics on the frequency of triggering events in contracts in the block.

[0238] Optionally, each of the N detection metrics has its own corresponding sliding window, which is used to perform segmented detection on the block-producing node under the corresponding detection metric.

[0239] Among them, different detection indicators among the N detection indicators may correspond to the same sliding window or to different sliding windows;

[0240] The sliding window includes at least one of the following: a time sliding window, a block height sliding window;

[0241] The time sliding window is used to select a time segment interval, and the block height sliding window is used to select a block height segment interval.

[0242] Optionally, the detection module 13 performs detection processing on the block-producing nodes based on the parsed data to obtain the detection results in the following ways:

[0243] The analytical data related to the k detection indicators are placed into the sliding windows corresponding to the k detection indicators respectively.

[0244] Based on the parsed data placed in the sliding window corresponding to the k detection indicators, the index values ​​of each of the k detection indicators are statistically calculated. The index values ​​are obtained by statistically analyzing the parsed data related to the detection indicator placed in the currently selected segment interval of the sliding window corresponding to the detection indicator.

[0245] Based on the values ​​of k detection indicators, the block-producing nodes are detected and processed under the k detection indicators to obtain the detection results.

[0246] Optionally, any one of the k detection indicators can be used as the target detection indicator. The detection module 13 performs detection processing on the block-producing node based on the indicator values ​​of the k detection indicators, and obtains the detection results in the following ways:

[0247] Obtain the reference index value range for the target detection index;

[0248] If the value of the target detection indicator is not within the range of the reference indicator value, the block-producing node is determined to be abnormal under the target detection indicator; if the value of the target detection indicator is within the range of the reference indicator value, the block-producing node is determined to be normal under the target detection indicator.

[0249] If a block-producing node is detected as abnormal under any of the k detection metrics, then the block-producing process is determined to include abnormal block production. If a block-producing node is detected as normal under all k detection metrics, then the block-producing process is determined to include normal block production.

[0250] Optionally, the detection module 13 is also used for:

[0251] If the block production process includes abnormal block production, a switchover of the block producing node in the blockchain network will be triggered.

[0252] If the block production process includes normal block production, then the switching of block-producing nodes in the blockchain network will not be triggered.

[0253] Optionally, the detection module 13 may trigger the switching process of block-producing nodes in the blockchain network in the following ways:

[0254] Generate chain configuration transactions for the blockchain network, which are used to trigger the switching of block-producing nodes in the blockchain network;

[0255] The chain configuration transaction is sent to the consensus nodes in the blockchain network, enabling the consensus nodes in the blockchain network to switch the block-producing nodes based on the chain configuration transaction.

[0256] Optionally, the multiple blockchain nodes include multiple consensus nodes, and the multiple consensus nodes include block-producing nodes. The data processing device 1 mentioned above is also used for:

[0257] The second data packet sent by the switch through the port mirroring module is obtained. The second data packet is a network data packet related to other consensus nodes among multiple consensus nodes, excluding the block producing node. The network data packet related to other consensus nodes includes at least one of the following: the network data packet containing the data sent by other consensus nodes, and the network data packet containing the data that other consensus nodes need to receive.

[0258] Based on the second data packet, the network status of other consensus nodes is detected and processed.

[0259] Among them, the network status detected by other consensus nodes is used to select the next block-producing node when the block-producing node is switched.

[0260] Optionally, the port mirroring module has a configured source port and a destination port, where the source port is the port on the switch used for data transmission and reception.

[0261] The acquisition module receives the first data packet sent by the switch through the port mirroring module in the following ways:

[0262] Receive the first data packet sent by the switch through the target port;

[0263] The first data packet is obtained by the switch through the port mirroring module, which mirrors the network data packets related to the block output node received from the source port.

[0264] Optionally, the port mirroring module configured on the switch includes at least one of the following: a single-source port mirroring module and a multi-source port mirroring module;

[0265] Among them, the single-source port mirroring module is used to mirror the traffic of a single port of the switch, while the multi-source port mirroring module is used to mirror the traffic of multiple ports of the switch.

[0266] Both single-source port mirroring modules and multi-source port mirroring modules are either: unidirectional port mirroring modules or bidirectional port mirroring modules.

[0267] The one-way port mirroring module is used to mirror the incoming or outgoing traffic of the switch, while the two-way port mirroring module is used to mirror both the incoming and outgoing traffic of the switch.

[0268] According to one embodiment of this application, Figure 3 The steps involved in the data processing method of the blockchain network shown can be derived from... Figure 10 The data processing unit 1 of the blockchain network shown is used to execute this process. For example, Figure 3 Step S101 shown can be performed by Figure 10 The acquisition module 11 in the middle is used to execute, Figure 3 Step S102 shown can be performed by Figure 10 The parsing module 12 in the middle is used for execution; Figure 3 Step S103 shown can be performed by Figure 10 The detection module 13 in the middle is used to perform the operation.

[0269] In this application's blockchain network, multiple blockchain nodes can interact via a switch. These multiple blockchain nodes include block-producing nodes. The switch can have a port mirroring module, which can mirror the network data packets exchanged between the blockchain nodes. The mirrored network data packets can include a first data packet related to the block-producing node, such as a network data packet sent by the block-producing node or a reply data packet corresponding to a network data packet sent by the block-producing node. Since the switch is located at the data link layer (Layer 2) of a 7-layer computer model, the first data packet obtained through the switch's port mirroring module can contain data from Layers 2 to 7 of the 7-layer computer model, including the Layer 2 network layer and the Layer 7 application layer (belonging to the business layer, which can include the blocks specifically packaged by the block-producing node and the transactions within those blocks). Therefore, the first data packet obtained through the mirroring process of the switch can enable detection of the block-producing node at multiple levels (such as the network layer and the business layer) to detect the block-producing node's block-producing process, thereby improving the accuracy of detecting the block-producing node's block-producing process.

[0270] According to one embodiment of this application, Figure 10 The modules in the data processing device 1 of the blockchain network shown can be individually or entirely merged into one or more units, or some of these units can be further divided into multiple functionally smaller sub-units to achieve the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple units, or the function of multiple modules can be implemented by one unit. In other embodiments of this application, the data processing device 1 of the blockchain network may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0271] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0272] According to one embodiment of this application, a computer program capable of executing the steps involved in the corresponding methods shown in the various embodiments of this application can be run on a general-purpose computer device (which may include processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM)) to construct a system as described in the embodiments of this application. Figure 10 The data processing device 1 of the blockchain network shown. The computer program described above can be recorded on a computer-readable recording medium, and can be loaded into the computer device described above through the computer-readable recording medium and run therein.

[0273] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. In some embodiments, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 11 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0274] exist Figure 11In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0275] The receiving switch sends a first data packet through a port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block-producing node. The network data packets related to the block-producing node include at least one of the following: the network data packet containing the data sent by the block-producing node, the network data packet containing the data that the block-producing node needs to receive, the blockchain network contains multiple blockchain nodes, the multiple blockchain nodes include block-producing nodes, and the multiple blockchain nodes interact with each other based on the switch, which has a port mirroring module.

[0276] The first data packet is parsed to obtain the parsed data;

[0277] The block-producing nodes are detected and processed based on the parsed data to obtain the detection results, which indicate the block-producing process of the block-producing nodes.

[0278] It should be understood that the computer device 1000 described in the embodiments of this application can execute the data processing method of the blockchain network described in the embodiments of this application, and can also execute the methods described above. Figure 10 The description of the data processing device 1 for the blockchain network in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0279] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program. When a processor executes this computer program, it can perform the data processing methods for blockchain networks described in the various embodiments of this application; therefore, these methods will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0280] As an example, the aforementioned computer program can be deployed and executed on a single computer device, or deployed and executed on multiple computer devices located in one location, or executed on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network can form a blockchain network.

[0281] The aforementioned computer-readable storage medium can be an internal storage unit of the computer device, such as a hard drive or memory. It can also be an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD) card, or flash card. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. This computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. It can also be used to temporarily store data that has been output or will be output.

[0282] This application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the data processing methods for the blockchain network described in the embodiments of this application; therefore, these methods will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0283] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0284] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0285] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method for a blockchain network, characterized in that, The blockchain network includes multiple blockchain nodes, among which there are block-producing nodes. The multiple blockchain nodes interact with each other via a switch, which has a port mirroring module. The method includes: The switch receives a first data packet sent through the port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block-producing node. The network data packets related to the block-producing node include at least one of the following: the network data packet containing the data sent by the block-producing node, and the network data packet containing the data that the block-producing node needs to receive. The first data packet is parsed to obtain parsed data; The block-producing node is detected based on the parsed data to obtain a detection result, which indicates the block-producing process of the block-producing node.

2. The method as described in claim 1, characterized in that, The block-producing node has N detection indicators, where N is an integer greater than or equal to 1; The step of parsing the first data packet to obtain parsed data includes: The first data packet is parsed to obtain parsed data related to k of the N detection indicators, where k is an integer less than or equal to N.

3. The method as described in claim 2, characterized in that, The N types of detection indicators include network detection indicators and block output detection indicators; The network detection metrics include at least one of the following: network latency metrics, network throughput metrics, and network packet loss rate metrics. The block detection metrics include at least one of the following: basic block detection metrics and business block detection metrics; The basic block production metrics include at least one of the following: metrics for the amount of resources consumed by transactions in processing a block, metrics for the number of transactions packaged, and metrics for block production delay. The business block output metrics include at least one of the following: metrics for the frequency of calls to contracts in the block, metrics for the frequency of calls to methods in the block, and metrics for the frequency of triggering events in the block.

4. The method as described in claim 2 or 3, characterized in that, Each of the N detection indicators has its own corresponding sliding window, which is used to perform segmented detection on the block output node under the corresponding detection indicator. Among them, different detection indicators in the N types of detection indicators correspond to the same sliding window or correspond to different sliding windows; The sliding window includes at least one of the following: a time sliding window, a block height sliding window; The time sliding window is used to select a time segment interval, and the block height sliding window is used to select a block height segment interval.

5. The method as described in claim 4, characterized in that, The detection process based on the parsed data to obtain the block-producing node and the detection result includes: The parsed data related to the k detection indicators are respectively placed into the sliding window corresponding to each of the k detection indicators; Based on the parsing data placed in the sliding window corresponding to the k detection indicators, the index values ​​of each of the k detection indicators are statistically calculated. The index values ​​are obtained by statistically analyzing the parsing data related to the detection indicator placed in the currently selected segment interval of the sliding window corresponding to the detection indicator. Based on the index values ​​of the k detection indicators, the block-producing node is detected and processed under the k detection indicators to obtain the detection results.

6. The method as described in claim 5, characterized in that, The block production process includes normal block production or abnormal block production. Any one of the k detection indicators is a target detection indicator. The block production node is detected based on the indicator values ​​of the k detection indicators to obtain the detection results, including: Obtain the reference index value range for the target detection index; If the value of the target detection indicator is not within the range of the reference indicator value, then the block output node is determined to be abnormal under the target detection indicator; if the value of the target detection indicator is within the range of the reference indicator value, then the block output node is determined to be normal under the target detection indicator. If the block-producing node is detected as abnormal under any of the k detection indicators, then the block-producing process is determined to include the abnormal block production; if the block-producing node is detected as normal under all of the k detection indicators, then the block-producing process is determined to include the normal block production.

7. The method according to any one of claims 1-6, characterized in that, The block production process includes normal block production or abnormal block production, and the method further includes: If the block production process includes the abnormal block production, a switchover process for the block producing node in the blockchain network is triggered. If the block production process includes normal block production, then the switching process for the block producing node in the blockchain network will not be triggered.

8. The method as described in claim 7, characterized in that, The process of triggering the switching of the block-producing node in the blockchain network includes: Generate a chain configuration transaction for the blockchain network, the chain configuration transaction being used to trigger a switchover process for the block-producing node in the blockchain network; The chain configuration transaction is sent to the consensus node in the blockchain network, so that the consensus node in the blockchain network can switch the block producing node based on the chain configuration transaction.

9. The method according to any one of claims 1-8, characterized in that, The plurality of blockchain nodes includes a plurality of consensus nodes, and the plurality of consensus nodes includes the block-producing node. The method further includes: The second data packet sent by the switch through the port mirroring module is obtained. The second data packet is a network data packet related to other consensus nodes among the plurality of consensus nodes, excluding the block-producing node. The network data packets related to the other consensus nodes include at least one of the following: the network data packet containing the data sent by the other consensus nodes, and the network data packet containing the data that the other consensus nodes need to receive. Based on the second data packet, the network status of the other consensus nodes is detected and processed. The network status detected by the other consensus nodes is used to select the next block-producing node when the block-producing node is switched.

10. The method according to any one of claims 1-9, characterized in that, The port mirroring module has a configured source port and a target port, wherein the source port is the port on the switch for sending and receiving data; The receiving of the first data packet sent by the switch through the port mirroring module includes: The first data packet sent by the switch is received through the target port; The first data packet is obtained by the switch through the port mirroring module by mirroring the network data packets related to the block output node obtained from the source port.

11. The method according to any one of claims 1-10, characterized in that, The port mirroring module of the switch includes at least one of the following: a single-source port mirroring module and a multi-source port mirroring module; The single-source port mirroring module is used to mirror the traffic of a single port of the switch, and the multi-source port mirroring module is used to mirror the traffic of multiple ports of the switch. Both the single-source port mirroring module and the multi-source port mirroring module are either: a unidirectional port mirroring module or a bidirectional port mirroring module. The unidirectional port mirroring module is used to mirror the incoming or outgoing traffic of the switch, and the bidirectional port mirroring module is used to mirror both the incoming and outgoing traffic of the switch.

12. A data processing device for a blockchain network, characterized in that, The blockchain network includes multiple blockchain nodes, among which there are block-producing nodes. The multiple blockchain nodes interact with each other via a switch, which has a port mirroring module. The device includes: The acquisition module is used to receive a first data packet sent by the switch through the port mirroring module. The first data packet is obtained by the switch through the port mirroring module by mirroring the acquired network data packets related to the block-producing node. The network data packets related to the block-producing node include at least one of the following: the network data packet containing the data sent by the block-producing node, and the network data packet containing the data that the block-producing node needs to receive. The parsing module is used to perform data parsing processing on the first data packet to obtain parsed data; The detection module is used to perform detection processing on the block-producing node based on the parsed data, and obtain the detection result, which indicates the block-producing process of the block-producing node.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-11.

14. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the steps of the method according to any one of claims 1-11.

Images