Block chain node state control method and device, equipment, medium and product

Abstract

The embodiment of the invention discloses a block chain node state control method and device, equipment, a medium and a product, and the method comprises the steps: obtaining heartbeat information corresponding to a plurality of application layers of a home terminal node and customized application layer extension information of the home terminal node, the heartbeat information being used for describing the state of the application layer of the home terminal node; common information of the multiple pieces of heartbeat information is extracted, and target heartbeat information of the end node is generated according to a synthesis result obtained through synthesis of the common information and the application layer extension information; determining broadcast time of the target heartbeat information according to at least one of response operation information of the opposite end node for the home end node and the target heartbeat information; and broadcasting the target heartbeat information to an opposite end node according to the broadcasting time of the target heartbeat information. According to the technical scheme, heartbeat sending can be contracted, reasonable combination and efficient transmission of heartbeat information of nodes in the block chain network are achieved, and therefore the performance and communication efficiency of the whole block chain system are optimized.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically, to a blockchain node state control method, a blockchain node state control device, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In a blockchain network, blockchain nodes need to understand each other's status, and usually use a heartbeat mechanism to collect status information of other blockchain nodes. The collection of consensus status is handled by the consensus module itself, which broadcasts its own heartbeat information at regular intervals to collect the status of all consensus nodes. The collection of other status is completed by other modules through regular broadcasting of heartbeat information, resulting in a large number of heartbeats continuously propagating throughout the network, causing congestion problems in the blockchain network. Summary of the invention

[0003] To solve the above technical problems, the embodiments of the present application provide a blockchain node state control method, a blockchain node state control device, an electronic device, a computer-readable storage medium and a computer program product, which realize the reasonable combination and efficient transmission of the heartbeat information of the nodes in the blockchain network, thereby optimizing the performance and communication efficiency of the entire blockchain system.

[0004] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0005] According to one aspect of an embodiment of the present application, a blockchain node state control method is provided, including: obtaining heartbeat information corresponding to multiple application layers of a local node and customized application layer extension information of the local node, the heartbeat information being used to describe the state of the application layer of the local node; extracting common information of multiple heartbeat information, and generating target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extension information; determining the broadcast time of the target heartbeat information according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information, the opposite node including a node connected to the local node; and broadcasting the target heartbeat information to the opposite node according to the broadcast time of the target heartbeat information.

[0006] According to one aspect of an embodiment of the present application, a blockchain node state control device is provided, including: an acquisition module, used to acquire heartbeat information corresponding to multiple application layers of a local node and customized application layer extension information of the local node, the heartbeat information being used to describe the state of the application layer of the local node; a synthesis module, used to extract common information of multiple heartbeat information, and generate target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extension information; a determination module, used to determine the broadcast time of the target heartbeat information according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information, the opposite node including a node connected to the local node; and a broadcast module, used to broadcast the target heartbeat information to the opposite node according to the broadcast time of the target heartbeat information.

[0007] In one embodiment of the present application, the response operation information includes multiple consecutive historical heartbeat response information of the counterpart node; the determination module is further used to obtain the historical response times corresponding to the multiple historical heartbeat response information respectively, and obtain multiple historical response times; based on the relationship between the multiple historical response times and a preset time threshold, determine the broadcast interval between the target heartbeat information and the previous historical heartbeat information; determine the broadcast time of the target heartbeat information based on the broadcast interval and the broadcast time of the previous historical heartbeat information.

[0008] In one embodiment of the present application, the determination module is further used to obtain the broadcast waiting time of the previous historical heartbeat information; if the multiple historical response times all exceed the preset time threshold, the broadcast waiting delay time of the target heartbeat information is determined according to the total number of historical response times exceeding the preset time threshold, wherein the total number of historical response times exceeding the preset time threshold is positively correlated with the broadcast waiting delay time; based on the broadcast waiting time and the broadcast waiting delay time, the broadcast interval between the target heartbeat information and the previous historical heartbeat information is determined.

[0009] In one embodiment of the present application, the determination module is further used to obtain the broadcast waiting time of the previous historical heartbeat information; when the broadcast waiting time of the previous historical heartbeat information is not the default waiting time, if the multiple historical response times do not exceed the preset time threshold, then the broadcast waiting reduction time of the target heartbeat information is determined according to the total number of historical response times that do not exceed the preset time threshold, wherein the total number of historical response times that do not exceed the preset time threshold is negatively correlated with the broadcast waiting reduction time; subtract the broadcast waiting reduction time from the broadcast waiting time to obtain the broadcast interval between the target heartbeat information and the previous historical heartbeat information.

[0010] In one embodiment of the present application, the determination module is further used to generate a verification value of the target heartbeat information based on the information content contained in the target heartbeat information; match the verification value of the target heartbeat information with the verification value of the previous historical heartbeat information; if the verification value of the target heartbeat information is consistent with the verification value of the previous historical heartbeat information, determine the waiting delay time for the target heartbeat information, and determine the broadcast time of the target heartbeat information based on the waiting delay time and the broadcast time of the previous historical heartbeat information.

[0011] According to an aspect of an embodiment of the present application, the determination module is further used to determine the priority of the target heartbeat information based on the information content contained in the application layer extension information; if the priority of the target heartbeat information is greater than the preset priority, the broadcast time of the target heartbeat information is determined to be the current time; or, if the response operation information includes the call trigger information of the peer node, the broadcast time of the target heartbeat information is determined to be the current time.

[0012] In one embodiment of the present application, the determination module is further used to determine the first broadcast time of the heartbeat information according to the first broadcast time determination method and the information content contained in the target heartbeat information; determine the second broadcast time of the target heartbeat information according to the second broadcast time determination method and the response operation information, the first broadcast time determination method and the second broadcast time determination method are different; select the broadcast time closest to the current time from the first broadcast time and the second broadcast time as the broadcast time of the target heartbeat information.

[0013] In one embodiment of the present application, the acquisition module is further used to acquire the application scenario corresponding to the opposite node, and customize the key parameters required for the application scenario; generate the application layer extension information according to the key parameters; the synthesis module is further used to obtain the non-shared information of the multiple heartbeat information, generate the target information based on the non-shared information and the synthesis result, and calculate the verification value of the target information; synthesize the target information and the verification value to obtain the target heartbeat information.

[0014] In one embodiment of the present application, the acquisition module is further used to configure a unique subject identifier for the application scenario corresponding to each peer node according to the node identifier of each peer node and the application type of the application scenario; to associate the key parameters required for the application scenario corresponding to each peer node with the corresponding subject identifier, and to generate application layer extension information according to the associated subject identifiers.

[0015] In one embodiment of the present application, the device also includes an update module, which is used to receive the peer heartbeat information broadcast by the peer node and verify the peer heartbeat information; if the verification of the peer heartbeat information passes, obtain the information in the peer heartbeat information used to describe the node status of the peer node; and update the node status of the peer node according to the information used to describe the node status of the peer node.

[0016] In one embodiment of the present application, the peer heartbeat information also includes customized peer application layer extension information, and the peer application layer extension information is generated based on a subject identifier associated with key parameters required for a local application scenario; the device also includes a distribution module, which is used to obtain a subject identifier corresponding to a node identifier of the local node based on the peer application layer extension information, and obtain a subscription status of a local application layer module to the obtained subject identifier; based on the subscription status, the key parameters associated with the obtained subject identifier are distributed to the corresponding local application layer module for processing.

[0017] In one embodiment of the present application, the update module is further used to obtain the time interval between the last update time of the node status of the counterpart node and the current time; if the time interval is greater than a preset interval threshold, the node status of the counterpart node is updated to an offline state.

[0018] According to one aspect of an embodiment of the present application, there is provided an electronic device, comprising one or more processors; and a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the electronic device implements the blockchain node state control method as described above.

[0019] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor of an electronic device, the electronic device executes the blockchain node state control method as described above.

[0020] According to one aspect of an embodiment of the present application, a computer program product is provided, including a computer program, wherein the computer program is stored in a computer-readable storage medium, and a processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the above-mentioned blockchain node state control method.

[0021] In the technical solution provided in the embodiment of the present application, the heartbeat information corresponding to the multiple application layers of the local node and the customized application layer extension information of the local node are obtained. The heartbeat information is used to describe the state of the application layer of the local node, and then the common information of the multiple heartbeat information is extracted. The target heartbeat information of the local node is generated according to the synthesis result obtained by synthesizing the common information and the application layer extension information. Different from the related art that each module of the node maintains the state information required by itself through its own heartbeat, the content definition of the target heartbeat information of the node is unified in the embodiment of the present application. On the one hand, the state information used by different modules of the node can be satisfied through the customized application layer extension information, and the required information of the modules that depend on the state of other nodes can also be satisfied, thereby reducing the coupling of the blockchain; on the other hand, the state association between the application layers of the node can be identified through the extracted common information of the multiple heartbeat information, thereby realizing efficient sharing and The target heartbeat information is integrated, the content of the heartbeat information is effectively shrunk, and the target heartbeat information obtained is attached to the existing heartbeat information of the node and the application layer extension information, so as to avoid the multiple separate transmissions of different information and shrink the number of heartbeat transmissions, thereby greatly reducing the message transmission in the blockchain network, improving the communication efficiency of the blockchain network, and thus improving the performance of the blockchain system; in addition, in the embodiment of the present application, after obtaining the target heartbeat information, the broadcast time of the target heartbeat information is determined according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information, so that the broadcast time of the target heartbeat information is adaptive, and finally the target heartbeat information is broadcast to the opposite node according to the broadcast time of the target heartbeat information, so that the opposite node can timely understand the status of the local node; through the embodiment of the present application, the reasonable combination and efficient transmission of the heartbeat information in the blockchain network are realized, thereby optimizing the performance and communication efficiency of the entire blockchain system.

[0022] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0024] Figure 1 It is a schematic diagram of the structure of the blockchain network;

[0025] Figure 2A It is a schematic diagram of an implementation environment involved in this application;

[0026] Figure 2B It is a schematic diagram of a blockchain node framework involved in this application;

[0027] Figure 3 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0028] Figure 4 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0029] Figure 5 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0030] Figure 6 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0031] Figure 7 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0032] Figure 8 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0033] Fig. 9 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0034] Fig.10 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0035] Fig.11 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0036] Fig.12 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0037] Fig.13 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0038] Fig.14 It is a flowchart of a blockchain node state control method shown in an exemplary embodiment of the present application;

[0039] Fig.15 is a schematic diagram of a node framework shown in another exemplary embodiment of the present application;

[0040] Fig.16A is a schematic diagram of heartbeat information shown in another exemplary embodiment of the present application;

[0041] Fig. 16B is a schematic diagram of application layer extension information shown in another exemplary embodiment of the present application;

[0042] Fig.17 is a schematic diagram of implementing a heartbeat broadcast mode shown in another exemplary embodiment of the present application;

[0043] Fig.18 is a flowchart of a passive broadcast mode shown in another exemplary embodiment of the present application;

[0044] Fig.19 is a flow chart of another passive broadcast mode shown in another exemplary embodiment of the present application;

[0045] Fig. 20 is a schematic diagram of a framework of a node processing heartbeat information shown in another exemplary embodiment of the present application;

[0046] Fig.21 is a flowchart of a node updating state information shown in yet another exemplary embodiment of the present application;

[0047] Fig. 22 It is a structural block diagram of a blockchain node state control device shown in an exemplary embodiment of the present application;

[0048] Fig.23 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0049] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0050] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0051] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0052] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0053] The technical solution of the embodiment of the present application relates to the field of blockchain technology. Before introducing the technical solution of the embodiment of the present application, a brief introduction to blockchain technology is first given.

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

[0055] As mentioned above, blockchain is essentially a decentralized database, and the blockchain is maintained by the nodes in the blockchain network. Figure 1 ,exist Figure 1 The blockchain network shown may include multiple nodes 101, and the multiple nodes 101 may be various servers and terminals forming the blockchain network. Each node 101 may receive input information during normal operation, and maintain the shared data in the blockchain network based on the received input information. In order to ensure the information intercommunication within the blockchain network, there may be an information connection between each node in the blockchain network, and the nodes may transmit information through the above information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as shared data, so that the data stored on all nodes in the blockchain network are consistent.

[0056] Each node in the blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of other nodes. A node identifier list can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnection between networks) address or any other information that can be used to identify the node. Table 1 only takes the IP address as an example for explanation.

[0057] Node Name Node ID Node 1 x1.x2.x3.x4 Node 2 y1.y2.y3.y4 … … Node N z1.z2.z3.z4

[0058] Table 1

[0059] See also Figure 1 The functions of each node in the blockchain network shown include:

[0060] 1) Routing: a basic function of a node, used to support communication between nodes.

[0061] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0062] It is understandable that each node in the blockchain network can be a server or a terminal. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing (Cloud Computing), cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and basic cloud computing services such as big data and intelligent platforms. The terminal can be a smart phone, a tablet computer, a laptop, a desktop computer, a smart speaker, a smart watch, a terminal used in a car, an aircraft, etc., but is not limited to this. Each node can be directly or indirectly connected by wired or wireless communication, and this application is not limited here.

[0063] The technical solution of the embodiment of the present application specifically relates to blockchain technology. The technical solution of the embodiment of the present application is described in detail below:

[0064] See also Figure 2A , Figure 2A It is a schematic diagram of an implementation environment involved in the present application. The implementation environment mainly includes a local node 210 and a peer node 220. Both the local node 210 and the peer node 220 are nodes in the blockchain network. Therefore, both the local node 210 and the peer node 220 involve routing functions to support communication between nodes.

[0065] Among them, the local node 210 is used to obtain the heartbeat information corresponding to multiple application layers of the local node and the customized application layer extension information of the local node, the heartbeat information is used to describe the state of the application layer of the local node, extract the common information of multiple heartbeat information, and generate the target heartbeat information of the local node according to the synthesis result obtained by synthesizing the common information and the application layer extension information. Then, the broadcast time of the target heartbeat information is determined according to the response operation information of the opposite node to the local node and at least one of the target heartbeat information, and finally the target heartbeat information is broadcast to the opposite node according to the broadcast time of the target heartbeat information.

[0066] The peer node 220 is used to confirm the node status of the local node based on the target heartbeat information broadcast by the local node, and provide the application layer extension information in the target heartbeat information to the corresponding application layer module for processing.

[0067] It is understandable that if Figure 2B As shown, the local node 210 can be any node in the blockchain network, and the opposite node 220 can be any node in the blockchain network except the local node or a designated node in the blockchain network.

[0068] like Figure 2B As shown, the local node 210 and the opposite node 220 both include a timer, a broadcaster, a receiver, a state controller and an application layer module, wherein the timer is used to trigger the broadcaster to broadcast the target heartbeat information, the receiver is used to receive the target heartbeat information broadcast by the opposite end, and parse it, provide the application layer extension information to the corresponding application layer module for processing, and provide the information used to describe the state of the application layer to the state controller for status update.

[0069] It should be noted that in the specific implementation of the present application, if the heartbeat information and / or application layer extension information are related to objects, when the embodiments of the present application are applied to specific products or technologies, it is necessary to obtain the permission or consent of the object, and the collection, use and processing of relevant data need to comply with the relevant regulations and standards of the relevant countries and regions.

[0070] The following is a detailed description of various implementation details of the technical solution of the embodiment of the present application:

[0071] like Figure 3 As shown, Figure 3is a flowchart of a blockchain node state control method shown in an embodiment of the present application, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B The blockchain node state control method may include steps S310 to S340, which are described in detail as follows:

[0072] S310: Obtain heartbeat information corresponding to multiple application layers of the local node and customized application layer extension information of the local node, where the heartbeat information is used to describe the state of the application layer of the local node.

[0073] In an embodiment of the present application, the heartbeat information of the local node is used to describe the state of the application layer module of the local node. Multiple heartbeat information may correspond to the states of multiple different application layer modules of the local node, so that the corresponding application layer module of the opposite node can confirm the state of the corresponding application layer module of the local node. The heartbeat information may include the global ledger state (State), that is, the latest state generated after the transaction is sent, such as the global ledger state is the current block height; the heartbeat information may also include a node identifier to enable the opposite node to distinguish each node; the heartbeat information may also include the node's own operating state, such as online state, idle state, block generation state, consensus state, etc.; wherein, depending on the application layer module, the corresponding heartbeat information is also different, for example, heartbeat information 1 corresponds to the node state of the synchronization module, and heartbeat information 1 includes node ID and block height; heartbeat information 2 corresponds to the node state of consensus module 2; heartbeat information 2 includes node ID, block height and consensus state, and the consensus state is the proposal stage, pre-voting stage or submission stage, etc.

[0074] The customized application layer extension information refers to the customized information used by the application layer module of the peer node; the customization can be customized by the local node or instructed by the peer node, which is not limited here; Figure 2B As shown, any node other than the local node 210 in the blockchain network is the peer node 220. After the receiver of the peer node 220 receives the target heartbeat information broadcast by the local node 210, it extracts the application layer extension information from the target heartbeat information and distributes it to the application layer module for processing.

[0075] In one example, the customized application layer extension information may be different depending on the application layer module of the peer node; for example, if the application layer module of the peer node is a consensus module, the customized application layer extension information includes the response of the local node to the voting information in the pre-voting stage, or the block height being consensused, etc.; for another example, if the application layer module of the peer node is a contract module, the customized application extension information includes the contract parameters and address of the smart contract, etc.; in one example, the application layer extension information may be accompanied by information for use by multiple application layer modules, or it may not be accompanied by any extended data.

[0076] In an embodiment of the present application, the local node can obtain heartbeat information and application layer extension information at the same time, or it can obtain heartbeat information from a local database after generating application layer extension information, or it can obtain application layer extension information after obtaining heartbeat information.

[0077] S320, extracting common information of a plurality of heartbeat information, and generating target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extended information.

[0078] In an embodiment of the present application, multiple heartbeat information may correspond to the status of multiple different application layers of the local node. The present application can extract common information of multiple heartbeat information, and the common information refers to the information contained in multiple heartbeat information; in one example, the common information may be data information that must be attached to each heartbeat information.

[0079] Continuing with the above example, heartbeat information 1 includes node ID and block height, and heartbeat information 2 includes node ID, block height, and pre-voting stage. The common information of heartbeat information 1 and heartbeat information 2 can be extracted as node ID and block height.

[0080] After the common information is extracted, the state association between each application layer of the node can be identified through the common information, so the heartbeat contraction of multiple heartbeat information can be performed based on the common information; first, the common information and the application layer extended information can be synthesized, that is, the common information and the application layer extended information are spliced ​​into a whole, and the obtained synthesis result is the common information + application layer extended information; in an example, when the common information and the application layer extended information are synthesized, the corresponding layer extended information can be filtered first. For example, the local node only broadcasts the target heartbeat information to the specified opposite node, then the application layer extended information that is not related to the specified opposite node can be filtered out, and then the filtered application layer information and the common information are synthesized.

[0081] It can be understood that after the common information is extracted, there may still be non-common information between multiple heartbeat information. Therefore, in the embodiment of the present application, non-common information also needs to be considered, wherein the non-common information can be compared with the application layer extension information in the synthesis result to determine whether the information content of the non-common information and the application layer extension information is similar. If the similarity between the non-common information and the application layer extension information is greater than the preset threshold, it means that the information between the non-common information and the application layer extension information is repeated, and the non-common information can be filtered out, and then only the synthesis result is used as the target heartbeat information; if the similarity between the non-common information and the application layer information is less than the preset threshold, the non-common information with a similarity less than the threshold and the synthesis result can be synthesized again to obtain a target heartbeat information, or the non-common information with a similarity less than the threshold can be added to the corresponding application layer extension information, and the common information and the added application layer extension are re-synthesized into a target heartbeat information.

[0082] For example, the common information of heartbeat information 1 and heartbeat information 2 is node ID and block height, and the non-common information is the pre-voting stage. The application layer extended information is the response of the local node to the voting information in the voting stage and the contract parameters of the smart contract. The non-common information is compared with the application layer extended information. If it is determined that the meanings of "pre-voting stage" and "response to voting information in the voting stage" are similar, the non-common information is directly filtered, and then the target heartbeat information is node ID, block height, response to voting information and contract parameters of the smart contract.

[0083] It should be understood that in an embodiment of the present application, heartbeat information 1 can be shrunk into heartbeat information 2 based on shared information, and based on the similarity between non-shared information and application layer extended information, it is determined whether to shrink the non-shared information, thereby obtaining the target heartbeat information, thereby achieving simplification and aggregation of message content.

[0084] S330: Determine a broadcast time of the target heartbeat information according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information.

[0085] In an embodiment of the present application, the counterpart node includes a node connected to the local node. For example, the counterpart node can be all blockchain nodes in the blockchain network, or a designated blockchain node in the blockchain network. The designated blockchain node can be an adjacent node, or a node that can implement a certain business, such as a consensus node. In other embodiments of the present application, the counterpart node can also be a server node for managing all blockchain nodes.

[0086] The response operation information of the peer node to the local node may be the response operation information of the peer node to the historical heartbeat information of the local node, or may be the response operation information triggered by the peer node to the local node.

[0087] In one example, the broadcast time of the target heartbeat information can be determined based on the information content contained in the target heartbeat information, or based on the response operation information of the opposite node to the local node. The broadcast time of the target heartbeat information can also be determined based on the information content contained in the target heartbeat information and the response operation information of the opposite node to the local node.

[0088] It should be noted that the broadcast time of the target heartbeat information in the embodiment of the present application is adaptive, that is, a dynamically adjustable time, not a fixed time.

[0089] S340: Broadcast the target heartbeat information to the opposite node according to the broadcast time of the target heartbeat information.

[0090] In an embodiment of the present application, the local node broadcasts the target heartbeat information to the opposite node based on the broadcast time of the target heartbeat information. For example, a timer can be set to immediately broadcast the target heartbeat information to the opposite node when the broadcast time of the target heartbeat information is reached.

[0091] In the embodiment of the present application, different from the related art in which each module of the node maintains the state information required by itself through its own heartbeat, in the embodiment of the present application, the content definition of the target heartbeat information of the node is unified. On the one hand, the state information used by different modules of the node can be satisfied through the customized application layer extension information, and the required information of the modules that depend on the state of other nodes can also be satisfied, thereby reducing the coupling of the blockchain; on the other hand, by extracting the common information of multiple heartbeat information, the state association between the application layers of the node can be identified, thereby realizing efficient sharing and integration of state information, effectively shrinking the content of the heartbeat information, and obtaining a target heartbeat information, which attaches the existing information of the node and the application layer extension information together, avoiding multiple separate transmissions. Different information is delivered, the number of heartbeat transmissions is reduced, thereby significantly reducing the message transmission in the blockchain network, improving the communication efficiency of the blockchain network, and further improving the performance of the blockchain system; in addition, in the embodiment of the present application, after obtaining the target heartbeat information, the broadcast time of the target heartbeat information is determined according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information, so that the broadcast time of the target heartbeat information is adaptive, and finally the target heartbeat information is broadcast to the opposite node according to the broadcast time of the target heartbeat information, so that the opposite node can timely understand the status of the local node; through the embodiment of the present application, the reasonable combination and efficient transmission of heartbeat information in the blockchain network are realized, thereby optimizing the performance and communication efficiency of the entire blockchain system.

[0092] In one embodiment of the present application, another blockchain node state control method is provided, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Figure 4 As shown, the blockchain node state control method is Figure 4 On the basis of, S330 is expanded to S410~S430. Among them, the response operation information includes multiple continuous historical heartbeat response information of the opposite end node, and the multiple continuous historical heartbeat response information is a response to multiple continuous historical heartbeat information of the local end node, wherein the historical heartbeat information is the heartbeat information synthesized by S320 before the current time. Steps S410~S430 are described in detail as follows:

[0093] S410. Obtain historical response times corresponding to a plurality of historical heartbeat response information to obtain a plurality of historical response times.

[0094] In an embodiment of the present application, the local node can record the corresponding response time each time it receives a heartbeat response message from the other node. Therefore, the local node can obtain the historical response times corresponding to multiple historical heartbeat response messages from the recorded response time to obtain multiple historical response times.

[0095] It should be noted that the multiple historical heartbeat response information is the multiple historical heartbeat response information closest to the current target heartbeat information. For example, if the current target heartbeat information is j, the multiple historical heartbeat response information is the previous historical heartbeat response information j-1, the previous previous historical heartbeat response information j-2, etc. In an example, the number of the historical heartbeat response information includes at least two, which can be flexibly adjusted according to actual conditions.

[0096] S420: Determine a broadcast interval between the target heartbeat information and the previous historical heartbeat information according to a relationship between a plurality of historical response times and a preset time threshold.

[0097] In an embodiment of the present application, the preset time threshold is the latest response time corresponding to the peer node's response to the heartbeat information set by the local node. For example, if the preset time is 3s, then the preset time threshold is the latest time from the local node broadcasting the target heartbeat information to the peer node to receiving the heartbeat response information of the peer node, which is 3s.

[0098] In one example, the relationship between multiple historical response times and a preset time threshold includes that multiple historical response times all exceed the preset time threshold, or that multiple historical response times all do not exceed the preset time threshold. According to the different relationships between the multiple historical response times and the preset time threshold, the method of determining the broadcast interval between the target heartbeat information and the previous historical heartbeat information is different; for example, if multiple historical response times all exceed the preset time threshold, the corresponding determined broadcast interval is greater than the corresponding determined broadcast interval if multiple historical response times all do not exceed the preset time threshold.

[0099] S430: Determine the broadcast time of the target heartbeat information according to the broadcast interval and the broadcast time of the last historical heartbeat information.

[0100] In one example, the broadcast time of the last historical heartbeat information refers to the time when the last historical heartbeat information was broadcast, and the sum of the broadcast time of the last historical heartbeat information and the broadcast interval is used as the broadcast time of the target heartbeat information.

[0101] In another example, the specified time can be increased or decreased based on the broadcast interval determined in S420. For example, if the determined broadcast interval exceeds the maximum broadcast interval, the determined broadcast interval will be reduced by the specified time so that the determined broadcast interval is equal to or less than the maximum broadcast interval; if the determined broadcast interval is less than the minimum broadcast interval, the determined broadcast interval will be increased by the specified time so that the determined broadcast interval is equal to or greater than the minimum broadcast interval, and then the broadcast time of the target heartbeat information is determined based on the increased or decreased broadcast interval and the broadcast time of the previous historical heartbeat information; wherein the minimum broadcast interval and the maximum broadcast interval can be flexibly adjusted according to actual conditions, for example, the more idle the local node is, the smaller the minimum broadcast interval is, and the busier the local node is, the larger the maximum broadcast interval is.

[0102] It should be noted that Figure 4 For other detailed descriptions of steps S310 to S320 and S340 shown in Figure 3 The steps S310 to S320 and S340 shown are not described in detail here.

[0103] In an embodiment of the present application, the local node determines the broadcast interval between the target heartbeat information and the previous historical heartbeat information based on the relationship between multiple consecutive historical heartbeat response information of the opposite node and the preset time, and then determines the broadcast time, so that the broadcast time is flexible and meets the actual situation of the opposite node.

[0104] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Figure 5 As shown, the blockchain node state control method will Figure 4 The S420 shown in FIG. 1 is extended to steps S510 to S530. Steps S510 to S530 are described in detail as follows:

[0105] S510: Obtain the broadcast waiting time of the previous historical heartbeat information.

[0106] In an embodiment of the present application, the broadcast waiting time of the last historical heartbeat information refers to the time spent by the last historical heartbeat information waiting to be broadcasted, such as the broadcast waiting time being the broadcast interval between the last historical heartbeat information and the last historical heartbeat information. In one example, the broadcast waiting time of the last historical heartbeat information can be used as the last broadcast interval.

[0107] S520. If multiple historical response times all exceed the preset time threshold, the broadcast waiting delay duration of the target heartbeat information is determined based on the total number of historical response times exceeding the preset time threshold, wherein the total number of historical response times exceeding the preset time threshold is positively correlated with the broadcast waiting delay duration.

[0108] In an embodiment of the present application, if multiple historical response times all exceed a preset time threshold, it means that the historical response times of multiple historical heartbeat response information have timed out continuously, wherein the multiple historical response times include the historical response time of the previous historical heartbeat information and multiple historical response times before the historical response time of the previous historical heartbeat information, such as the multiple historical response times are the historical heartbeat times of historical heartbeat response information j-1, j-2 and j-3; at this time, it is necessary to trigger a broadcast delay, and it is necessary to determine the broadcast waiting delay duration of the target heartbeat information, and the broadcast waiting delay duration of the target heartbeat information refers to the delay duration relative to the broadcast waiting duration of the previous historical heartbeat information, that is, the required delay duration based on the previous broadcast interval.

[0109] The broadcast waiting delay time of the target heartbeat information is determined according to the total number of historical response times exceeding the preset time threshold. The greater the total number of historical response times exceeding the preset time threshold, the greater the broadcast waiting delay time.

[0110] In one example, there is a regularity between the total number of historical response times exceeding a preset time threshold and the broadcast waiting delay period, such as satisfying a linear relationship. For example, the broadcast waiting delay period is a specified multiple of the total number of historical response times exceeding the preset time threshold. Therefore, the broadcast waiting delay period of the heartbeat information can be determined based on the total number of historical response times exceeding the preset time threshold according to this linear relationship.

[0111] S530: Determine a broadcast interval between the target heartbeat information and the previous historical heartbeat information based on the broadcast wait time and the broadcast wait delay time.

[0112] In an embodiment of the present application, the sum of the broadcast waiting time and the broadcast waiting delay time can be used as the broadcast interval between the target heartbeat information and the previous historical heartbeat information. For example, the broadcast waiting time of the previous historical heartbeat information is 5s, that is, the broadcast interval between the previous historical heartbeat information and the previous previous historical heartbeat information is 5s. Assuming that the broadcast waiting delay time of the target heartbeat information is 3s, the broadcast interval of the current target heartbeat information is 8s.

[0113] It is understandable that the broadcast interval between the target heartbeat information and the previous historical heartbeat information is greater than the previous broadcast interval. In other embodiments of the present application, the broadcast waiting delay duration of the target heartbeat information is determined based on the total number of historical response times exceeding a preset time threshold, and the broadcast interval between the target heartbeat information and the previous historical heartbeat information determined in this way satisfies the preset mathematical law with the previous broadcast interval, and then the broadcast waiting delay duration can be reversely inferred based on the preset mathematical law, and then the relationship between the total number of historical response times exceeding the preset time threshold and the broadcast waiting delay duration can be inferred in combination with the total number of historical response times exceeding the preset time threshold.

[0114] It should be noted that Figure 5 For a detailed description of steps S310 to S320, S410, S430, and S340, see Figure 4 The steps S310 to S320, S410, S430, and S340 shown are not repeated here.

[0115] In an embodiment of the present application, when multiple historical response times exceed the preset time threshold, it is necessary to add a delay to the broadcast of the target heartbeat information, and the total number of historical response times exceeding the preset time threshold is positively correlated with the increased delay, thereby making the broadcast interval corresponding to the current target heartbeat information longer than the previous broadcast interval.

[0116] The present application also provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Figure 6 As shown, the blockchain node state control method will Figure 4 The S420 shown in FIG. 1 is expanded into steps S610 to S630. Steps S610 to S630 are described in detail as follows:

[0117] S610: Obtain the broadcast waiting time of the previous historical heartbeat information.

[0118] Get the broadcast interval between the last historical heartbeat information and the previous historical heartbeat information, that is, the last broadcast interval.

[0119] S620. When the broadcast waiting time of the previous historical heartbeat information is not the default waiting time, if multiple historical response times do not exceed the preset time threshold, the broadcast waiting reduction time of the target heartbeat information is determined according to the total number of historical response times that do not exceed the preset time threshold, wherein the total number of historical response times that do not exceed the preset time threshold is negatively correlated with the broadcast waiting reduction time.

[0120] In an embodiment of the present application, if the broadcast waiting time of the previous historical heartbeat information is not the default waiting time, it means that the broadcast interval between the previous historical heartbeat information and the previous previous historical heartbeat information is not the default broadcast interval, but the broadcast interval after the delay. At this time, multiple historical response times do not exceed the preset time threshold, which means that multiple historical heartbeat response messages are replied on time, and it is necessary to determine the broadcast waiting reduction time for the target heartbeat information. The broadcast waiting reduction time refers to the time required to be reduced based on the previous broadcast interval; wherein, the larger the total number of historical response times that does not exceed the preset time threshold, the smaller the broadcast waiting reduction time; that is, in the initial stage, the broadcast waiting reduction time is larger; in the subsequent stage, the broadcast waiting reduction time is smaller, so as to avoid the broadcast interval obtained by reducing the broadcast waiting time in the subsequent stage being too small.

[0121] In one example, there is a regularity, such as a linear relationship, between the total number of historical response times that do not exceed the preset time threshold and the broadcast wait reduction time, which is related to the linear relationship between the total number of historical response times that exceed the preset time threshold and the broadcast wait delay time.

[0122] S630: Subtract the broadcast waiting reduction time from the broadcast waiting time to obtain the broadcast interval between the target heartbeat information and the previous historical heartbeat information.

[0123] For example, the broadcast waiting time of the previous historical heartbeat information is 13s, that is, the broadcast interval between the previous historical heartbeat information and the previous previous historical heartbeat information is 13s. Assuming that the broadcast waiting time of the target heartbeat information is reduced to 5s, the broadcast interval of the current target heartbeat information is 8s.

[0124] It should be noted that Figure 6 For other detailed descriptions of steps S310 to S320, S410, S430, and S340 shown in Figure 4Steps S310 to S320, S410, S430, and S340 shown in FIG. 1 are not described in detail here.

[0125] In an embodiment of the present application, when multiple historical response times do not exceed the preset time threshold, it is necessary to reduce the delay in broadcasting the target heartbeat information so that the broadcast interval corresponding to the current target heartbeat information is shorter than the previous broadcast interval.

[0126] In one embodiment of the present application, another blockchain node state control method is also provided, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Figure 7 As shown, the blockchain node state control method is Figure 3 Based on the above, S330 is expanded to S710 to S730. Steps S710 to S730 are described in detail as follows:

[0127] S710. Generate a verification value of the target heartbeat information according to information content contained in the target heartbeat information.

[0128] In an embodiment of the present application, the verification value of the target heartbeat information is used to verify the information integrity of the target heartbeat information; in one example, the verification value of the target heartbeat information can be obtained by calculating the information content contained in the target heartbeat information through a fixed hash algorithm, and the hash algorithm includes MD5 (MD5 message digest algorithm, MD5 Message-DigestAlgorithm), SHA-1 (Secure Hash Algorithm 1, Secure Hash Algorithm 1), SHA-256, etc.; in another example, before performing the hash calculation, the information content contained in the target heartbeat information needs to be properly encoded, and the encoding method may include converting the information content into a byte stream, using a specific encoding format such as Base64, etc., to ensure that the information content can be correctly passed to the hash algorithm.

[0129] S720: Match the verification value of the target heartbeat information with the verification value of the previous historical heartbeat information.

[0130] In an embodiment of the present application, the local node caches the verification value of the heartbeat information before broadcasting the heartbeat information, thereby obtaining the verification value of the previous historical heartbeat information from the cache, and then matching the verification value of the current target heartbeat information with the verification value of the previous historical heartbeat information to determine whether the information content contained in the current target heartbeat information is the same as the information content contained in the previous historical heartbeat information.

[0131] S730: If the verification value of the target heartbeat information is consistent with the verification value of the previous historical heartbeat information, determine the waiting delay time for the target heartbeat information, and determine the broadcast time of the target heartbeat information according to the waiting delay time and the broadcast time of the previous historical heartbeat information.

[0132] If the verification value of the target heartbeat information is consistent with the verification value of the previous historical heartbeat information, it means that the heartbeat information continuously broadcast by this end node is the same, then it is necessary to delay broadcasting of the target heartbeat information and determine the waiting delay time for the target heartbeat information. The waiting delay time is the delay time for delaying broadcasting of the target heartbeat information.

[0133] In one example, the waiting delay time may be a fixed time, such as 3 seconds.

[0134] In another example, the waiting delay time may also be a dynamically changing time. For example, if the verification values ​​of multiple consecutive historical heartbeat information are the same, the waiting delay time is determined according to the number of the multiple historical heartbeat information.

[0135] In an embodiment of the present application, after determining the waiting delay time, the waiting delay time can be increased based on the set broadcast interval. For example, if the set broadcast time between two target heartbeat information is set to 2s, then the broadcast interval between the previous historical heartbeat information and the target heartbeat information is 2+3, i.e. 5s. Then, based on the broadcast time of the previous historical heartbeat information, the broadcast time of the target heartbeat information is set to 5s later.

[0136] In other embodiments of the present application, the waiting delay time can be increased on the basis of the broadcast interval of the previous historical heartbeat information to obtain the broadcast interval between the previous historical heartbeat information and the current target heartbeat information, and the broadcast time of the target heartbeat information can be set after the broadcast interval based on the broadcast time of the previous historical heartbeat information.

[0137] In other embodiments of the present application, if the verification value of the target heartbeat information is inconsistent with the verification value of the previous historical heartbeat information, the broadcast interval between the target heartbeat information and the previous historical heartbeat information is the set broadcast interval, and then the broadcast time of the target heartbeat information is determined based on the set broadcast interval and the previous historical heartbeat information.

[0138] It should be noted that Figure 7 For other detailed descriptions of steps S310 to S320 and S340 shown in Figure 3 The steps S310 to S320 and S340 shown are not described in detail here.

[0139] In an embodiment of the present application, by matching the verification value of the current target heartbeat information with the verification value of the previous historical heartbeat information, the waiting delay time is determined for the target heartbeat information, and then the broadcast time of the target heartbeat information is determined based on the waiting delay time and the broadcast time of the previous historical heartbeat information, so that the broadcast time conforms to the actual situation.

[0140] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Figure 8 As shown, the blockchain node state control method is Figure 3 On the basis of, S330 is expanded to S810 or S820. Step S810 or S820 is described in detail as follows:

[0141] S810. Determine the priority of the target heartbeat information according to the information content included in the application layer extended information. If the priority of the target heartbeat information is greater than the preset priority, determine the broadcast time of the target heartbeat information as the current time.

[0142] As described above, the application layer extension information is used for the application layer module of the peer node. For the application layer module of the peer node, some information needs to be broadcast in real time. Therefore, the priority of the target heartbeat information can be determined according to the information content contained in the application layer extension information. The higher the priority of the target heartbeat information, the more important the application layer extension information is. In one example, the peer node and / or the local node can formulate a relationship table between the priority of the application layer extension information and the target heartbeat information, such as the priority of the application layer extension information corresponding to the consensus module is the highest level of priority, the priority of the application layer extension information corresponding to the contract module is the secondary level of priority, and the priority of the application layer extension information corresponding to the synchronization module is the lowest level of priority, and then the corresponding priority is determined by the relationship table and the information content contained in the current application layer extension information.

[0143] In another example, the priority of the target heartbeat information is determined according to the information content contained in the application layer extended information. The opposite node may configure the information content and priority accordingly according to the specific situation, and determine the priority of the current target heartbeat information based on the information content and priority configured by the opposite node.

[0144] If the priority of the target heartbeat information is greater than the preset priority, such as the priority is greater than the lowest priority level, the broadcast of the target heartbeat information is determined to be a real-time broadcast, that is, the broadcast time is the current time.

[0145] S820: If the response operation information includes the call trigger information of the peer node, determine that the broadcast time of the target heartbeat information is the current time.

[0146] In an embodiment of the present application, the opposite node can also actively trigger so that the local node broadcasts the target heartbeat information in real time, wherein the opposite node can send a call trigger information to the local node, and the call trigger information is used to instruct the local node to broadcast in real time. Therefore, if the response operation information includes the call trigger information of the opposite node, the broadcast time of the target heartbeat information is determined to be the current time.

[0147] It should be noted that Figure 8 For other detailed descriptions of steps S310 to S320 and S340 shown in Figure 3 The steps S310 to S320 and S340 shown are not described in detail here.

[0148] In an embodiment of the present application, real-time broadcasting can be triggered by calling trigger information of the peer node or judging the priority of the information content of the application layer extended information by the local node to ensure timely broadcasting of the target heartbeat information to meet various application scenarios.

[0149] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Fig. 9 As shown, the blockchain node state control method is Figure 3 The S330 shown in FIG. 1 extends S910 to S930. The steps S910 to S930 are described in detail as follows:

[0150] S910: Determine a first broadcast time of the target heartbeat information according to a first broadcast time determination method and information content included in the target heartbeat information.

[0151] In the embodiment of the present application, the first broadcast time of the target heartbeat information is determined according to the first broadcast time determination method and the information content contained in the target heartbeat information. For details, see Figure 7 shown.

[0152] S920: Determine a second broadcast time of the target heartbeat information according to a second broadcast time determination method and the response operation information, wherein the first broadcast time determination method and the second broadcast time determination method are different.

[0153] If the response operation information includes a plurality of continuous historical heartbeat response information of the peer node, the second broadcast time can be determined by the second broadcast time determination method and the plurality of continuous historical heartbeat response information. Figures 4 to 6 shown.

[0154] S930: Select the broadcast time closest to the current time from the first broadcast time and the second broadcast time as the broadcast time of the target heartbeat information.

[0155] In an embodiment of the present application, the first broadcast time and the second broadcast time are different broadcast times. The broadcast time closest to the current time can be selected from the first broadcast time and the second broadcast time as the broadcast time of the heartbeat information. For example, if the first broadcast time is 13:00, the second broadcast time is 13:01, and the current time is 12:58, the first broadcast time is selected as the broadcast time of the target heartbeat information.

[0156] In other embodiments of the present application, the broadcast time farthest from the current time can be selected from the first broadcast time and the second broadcast time as the broadcast time of the target heartbeat information; weights can also be set for the first broadcast time and the second broadcast time respectively, and the weighted sum of the first broadcast time and the second broadcast time can be used as the broadcast time of the target heartbeat information.

[0157] It should be noted that Fig. 9 For other detailed descriptions of steps S310 to S320 and S340 shown in Figure 3 The steps S310 to S320 and S340 shown are not described in detail here.

[0158] In the embodiment of the present application, different broadcast times can be determined through different determination methods and different information, and then a more reasonable broadcast time can be selected, so that the determination of the broadcast time is more accurate and reliable.

[0159] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Fig.10 As shown, the blockchain node state control method is Figure 3 Based on the above, S310 is expanded into steps S1010 to S1020, and S320 is expanded into S1030 to S1040. Steps S1010 to S1040 are described in detail as follows:

[0160] S1010, obtaining heartbeat information corresponding to multiple application layers of the local node and obtaining application scenarios corresponding to the opposite node, and customizing key parameters required for determining the application scenarios.

[0161] In the embodiment of the present application, the application scenario of the peer node refers to the application layer scenario corresponding to the specific service implemented by the peer node according to the actual service needs. For example, if the peer node can implement the consensus service, the application scenario includes the consensus scenario.

[0162] In one example, the local node can determine the application scenario corresponding to the peer node based on the business of the peer node. The business of the peer node can be obtained by the local node through the peer heartbeat information of the peer node, or can be determined by the local node through things broadcast by the peer node in the blockchain network.

[0163] After obtaining the application scenario corresponding to the peer node, the local node can customize the key parameters required for the application scenario. For example, the consensus scenario of the peer node is the RAFT consensus algorithm scenario, and the key parameters required by the peer node to achieve consensus are the block height and Leader information being consensused.

[0164] In one example, the key parameters required for the application scenario can also be customized by the peer node, that is, the peer node can arbitrarily customize its own information content and broadcast it to the local node through the peer heartbeat information of the peer node. Then the local node searches the local database for the key parameters corresponding to the information content based on the customized information content.

[0165] S1020, generating application layer extension information according to key parameters, extracting common information of multiple heartbeat information, and synthesizing the common information with the application layer extension information to obtain a synthesis result.

[0166] In an embodiment of the present application, the key parameters can be directly used as application layer extension information, and the key parameters can be processed and then the application layer extension information can be generated based on the processed key parameters, such as filtering the key parameters to filter out invalid parameters, which can be parameters that are irrelevant to the opposite node; then, the common information of multiple heartbeat information is extracted, and the common information is synthesized with the application layer extension information to obtain a synthesized result.

[0167] S1030, obtaining non-common information of multiple heartbeat information, generating target information based on the non-common information and the synthesis result, and calculating the verification value of the target information.

[0168] There may also be non-common information between multiple heartbeat information. Therefore, the non-common information can be compared with the application layer extended information in the synthesis result to determine whether the information content of the non-common information and the application layer extended information is similar. If similar, the non-common information is filtered out and the synthesis result is directly used as the target information; if not similar, the non-common information and the synthesis result are synthesized to obtain the target information.

[0169] In order to verify the integrity of the information content contained in the target heartbeat information, the embodiment of the present application needs to calculate the verification value based on the target information, such as by using a hash algorithm.

[0170] S1040. Synthesize the target information and the verification value to obtain target heartbeat information.

[0171] In an embodiment of the present application, the target information and the verification value are encapsulated to obtain the target heartbeat information, for example, the verification value is located at the head of the heartbeat information, and the target information is located at the tail of the target heartbeat information.

[0172] It should be noted that Fig.10 For a detailed description of steps S330 to S340 shown in Figure 3 Steps S330 to S340 shown in FIG. 1 are not described in detail here.

[0173] In an embodiment of the present application, key parameters required for the application scenario are customized to generate application layer extension information, and based on the similarity between the non-shared information and the application layer extension information, it is determined whether to shrink the non-shared information, thereby further achieving the simplification and aggregation of the message content; data integrity is ensured by calculating the verification value, and finally the target heartbeat information is synthesized, thereby unifying the content and format of the target heartbeat information and ensuring the reliability of the target heartbeat information.

[0174] It is worth noting that the present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Fig.11 As shown, the blockchain node state control method is Fig.10 The S1020 shown in FIG. 1 is expanded into steps S1110 to S1120. Steps S1110 to S1120 are described in detail as follows:

[0175] S1110: Configure a unique subject identifier for each application scenario corresponding to each peer node according to the node identifier of each peer node and the application type of the application scenario.

[0176] In an embodiment of the present application, the number of peer nodes includes multiple, that is, the local node can broadcast the application layer extension information corresponding to each peer node to multiple peer nodes in one heartbeat information; wherein, in order to distinguish different application layer extension information of different peer nodes, the object belonging to the application scenario can be distinguished by the node identifier of each peer node, and then the different application scenarios can be distinguished by the application type of the application scenario, so that a unique subject identifier can be configured to distinguish different peer nodes and the application types of different application scenarios.

[0177] For example, the peer nodes include A and B, and the application type of the application scenario corresponding to the peer node A includes consensus type 1 and synchronization type, and the application type of the application scenario corresponding to the peer node B includes consensus type 2 and synchronization type. Then, a unique subject identifier is assigned to the application scenario of consensus type 1 of the peer node A: A consensus 1, and a unique subject identifier is assigned to the application scenario of the synchronization type of the peer node A: A synchronization; a unique subject identifier is assigned to the application scenario of consensus type 2 of the peer node B: B consensus 2, and a unique subject identifier is assigned to the application scenario of the synchronization type of the peer node B: B synchronization.

[0178] S1120, associating the key parameters required by the application scenarios corresponding to each peer node with the corresponding subject identifier, generating application layer extension information according to each associated subject identifier, and synthesizing the common information of multiple heartbeat information with the application layer extension information to obtain a synthesis result.

[0179] In an embodiment of the present application, after customizing the key parameters required for the application scenarios corresponding to each peer node, the corresponding key parameters and the corresponding subject identifier are associated, such as generating a parameter queue based on the subject identifier, and writing the corresponding key parameters into the corresponding parameter queue; and then generating application layer extension information based on the associated subject identifiers.

[0180] It should be noted that Fig.11 For a detailed description of steps S1010, S1030-S1040, S330-S340, see Fig.10 Steps S1010, S1030-S1040, S330-S340 shown in the figure are not repeated here.

[0181] In an embodiment of the present application, a unique subject identifier is configured for the application scenario corresponding to each peer node through the node identifier of each peer node and the application type of the application scenario, so that the subject identifier can distinguish different peer nodes and the application types of different application scenarios, and then after parameter association, the application layer extended information can correspond to different nodes and application scenarios.

[0182] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B The blockchain node state control method is executed by the local node shown in Figures 3 to 11 Based on the above, S1210 to S1230 are added, such as Fig.12 As shown, S1210 to S1230 are described in detail as follows:

[0183] S1210: Receive the heartbeat information of the opposite end broadcasted by the opposite end node, and verify the heartbeat information of the opposite end.

[0184] In an embodiment of the present application, the peer node may also broadcast the peer heartbeat information to the local node. When the local node receives the peer heartbeat information, it will verify the peer heartbeat information. The verification includes whether the heartbeat information belongs to a node of the blockchain network. When it belongs to a node of the blockchain network, it indicates that the node is online. The integrity of the heartbeat information is further verified, for example, the information content in the peer heartbeat information is extracted, and a verification value is generated through a hash algorithm. If the calculated verification value is the same as the verification value carried in the peer heartbeat information, it indicates that the verification is passed.

[0185] S1220: If the verification of the heartbeat information of the other end passes, obtain the information in the heartbeat information of the other end that is used to describe the state of the application layer of the node at the other end.

[0186] If the verification of the peer information is passed, the peer heartbeat information is parsed, and the information used to describe the state of the peer node application layer in the peer heartbeat information is extracted. It should be noted that the heartbeat information between two nodes in the embodiment of the present application may only include information used to describe the application layer state, or may include information used to describe the application layer state and application layer extension information. The principle of the peer heartbeat information can be referred to S310~S320, which will not be repeated here.

[0187] S1230: Update the node status of the opposite node according to the information used to describe the status of the application layer of the opposite node.

[0188] After obtaining the information used to describe the status of the application layer of the peer node in the heartbeat information of the peer, the information used to describe the status of the application layer of the peer node includes a node ID and a block height. The local node maintains a node status list. If the node ID of the information used to describe the node status of the peer node is not in the node status list, the node ID and block height of the peer node are added to the node status table; if the node ID exists in the node status list, the block height corresponding to the node ID in the node status table is updated.

[0189] It should be noted that Fig.12 For a detailed description of steps S310 to S340 shown in Figure 3 Steps S310 to S340 shown in FIG. 1 are not described in detail here.

[0190] In an embodiment of the present application, the peer heartbeat information of the peer node is received, and the reliability of the peer heartbeat information is determined by verifying the peer heartbeat information, and then the peer heartbeat information updates the node status of the peer to achieve status collection of the peer.

[0191] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Fig.13 As shown, the blockchain node state control method is Fig.12 Based on the information shown in , S1310 to S1320 are added. Among them, the peer heartbeat information in S1210 also includes customized peer application layer extension information, which is generated based on the subject identifier associated with the key parameters required by the local application scenario. For the specific generation process, please refer to Fig.11 S1310~S1320 are described in detail as follows:

[0192] S1310. Obtain a topic identifier corresponding to the node identifier of the local node according to the peer application layer extension information, and obtain a subscription status of the local application layer module to the obtained topic identifier.

[0193] In an embodiment of the present application, the application layer extension information of the peer node may include application layer extension information of multiple nodes, and the local node only needs to extract the information corresponding to the local node, wherein the application layer extension information of the peer node includes multiple subject identifiers, and the subject identifier can distinguish different nodes and different application scenarios. Therefore, the local node searches for the subject identifier corresponding to the node identifier of the local node from the multiple subject identifiers, and the subject identifier may include subject identifiers of types of different application scenarios; the local node also obtains the subscription status of the local application layer module to the subject identifier, wherein the application layer module can subscribe to the specified subject identifier based on the application scenario, or subscribe to the subject identifiers of other application scenarios to obtain information corresponding to other modules.

[0194] S1320: Distribute the key parameters associated with the acquired topic identifier to the corresponding local application layer module for processing based on the subscription status.

[0195] In an embodiment of the present application, the local node distributes the key parameters associated with the corresponding topic identifier to the corresponding application layer module for processing based on the subscription status of the application layer module to the topic identifier. For example, if the local consensus module subscribes to the consensus of the topic identifier, the key parameters associated with the consensus topic identifier are distributed to the consensus module for processing.

[0196] It should be noted that Fig.13 For a detailed description of steps S310 to S340 and S1210 to S1230 shown in Fig.12 Steps S310 to S340 and S1210 to S1230 shown in FIG. 1 are not described in detail here.

[0197] In an embodiment of the present application, by obtaining the topic identifier corresponding to the node identifier of the local node, and based on the subscription status of the local application layer to the topic identifier, the associated key parameters are distributed to the local application layer, thereby realizing subscription and distribution based on the topic identifier, ensuring that the corresponding key parameters are processed in an orderly manner at the application layer.

[0198] The present application embodiment provides another blockchain node state control method, which can be applied to Figure 2A or Figure 2B In the implementation environment shown, the method can be implemented by Figure 2A or Figure 2B Execute on the local node shown in Fig.14 As shown, the blockchain node state control method is Fig.12 Based on the above, S1410 to S1420 are added. S1410 to S1420 are described in detail as follows:

[0199] S1410. Obtain the time interval between the last update time of the node status of the opposite node and the current time.

[0200] In an embodiment of the present application, the local node also needs to maintain the online status of the peer node and obtain the last update time of the node status of the peer node. The node status upload update time can be the reception time of the peer heartbeat information broadcast by the peer node, and then calculate the time interval between the last update time of the node status and the current time.

[0201] S1420: If the time interval is greater than a preset interval threshold, the node state of the opposite node is updated to an offline state.

[0202] If the time interval exceeds the preset interval threshold, it indicates that the peer node may be offline, and the state of the peer node is updated to an offline state until the peer heartbeat information of the peer node is received again, and then the state of the peer node is updated to an online state.

[0203] In one example, after the status of the peer node is updated to an offline state, the block height and block ID of the peer node can be consistently maintained in the node status list, and the block height of the peer node status can be continued to be updated after receiving the peer heartbeat information of the peer node again.

[0204] In another example, after the status of the opposite node is updated to an offline state, the local node deletes the data related to the opposite node from the node status list to save storage resources.

[0205] In an embodiment of the present application, whether the peer node is online is determined by the time interval between the last update time of the node status of the peer node and the current time, and then the node status of the peer node is updated to ensure the rationality of the peer node status.

[0206] It should be noted that Fig.14 For a detailed description of steps S310 to S340 and S1210 to S1230 shown in Fig.12 Steps S310 to S340 and S1210 to S1230 shown in FIG. 1 are not described in detail here.

[0207] For ease of understanding, the following is based on Figure 2B The implementation environment shown describes in detail the blockchain node state control method provided by the embodiment of the present application: each blockchain node is equipped with a state engine, which is used to send and receive heartbeats, and also needs to define the format and content of the message; at the same time, it is necessary to dynamically adjust the frequency of the heartbeat and the state change of the node, so a complete state engine includes: a heartbeat broadcaster, a heartbeat receiver, and a state controller.

[0208] like Fig.15 As shown, the heartbeat broadcaster is responsible for broadcasting the target heartbeat information of its own node. It can broadcast its own target heartbeat information to the nodes that have been connected to the blockchain network or the designated consensus nodes according to the usage scenario. The heartbeat receiver is responsible for asynchronously detecting the target heartbeat information broadcast by other nodes, decoding the received target heartbeat information, submitting it to the state controller, and returning its own target heartbeat information to other nodes through the heartbeat broadcaster. The state controller is responsible for updating and maintaining the state information of all nodes. When the heartbeat receiver receives the target heartbeat information and submits it to the state controller after parsing, the state controller adds or updates the state information of the node.

[0209] In the embodiments of the present application, Fig.16AAs shown, the target heartbeat information contains information used to describe the state of the local node, which can be the state information that must be sent for each heartbeat, excluding user-defined information. For the state engine, the network information is the responsibility of the blockchain network module, so there is no need to specifically set the network address and other information, only the node ID needs to be formulated, and the network module can send the heartbeat packet to the executed blockchain node according to the node ID. Receiving a node's heartbeat only means that the node is online, but the block height of the node is unknown. For the blockchain network, the block height is almost the primary information that all nodes need to detect other nodes. Therefore, the information used to describe the state of the local node only encapsulates two data, namely the node ID and the current block height of the node.

[0210] In one example, the information used to describe the state of the local node may be common information between the heartbeat information corresponding to multiple application layer modules.

[0211] The target heartbeat information also includes application layer extension information, that is, the information that users can attach to the heartbeat according to their own application scenarios. For some application layer modules, such as the synchronization module, you only need to know the block height of other nodes to select the appropriate node to synchronize data to the local node based on this information; however, there are still some other modules that rely on node information, not limited to block height, such as: consensus module; assuming that the consensus algorithm used in the current blockchain network is the RAFT consensus algorithm, then in addition to knowing the current block height, you also need to know the block height and Leader information that is being consensused, etc.; therefore, application layer extension information is customizable data information specifically used to provide to application layer modules; in one example, the application layer extension information also includes non-shared information between the heartbeat information corresponding to multiple application layer modules, and this non-shared information is different from the customizable data information provided to the application layer modules.

[0212] It should be noted that in the extended information, the user can customize the content of his own information at will. However, it is necessary to customize a dedicated Topic (the aforementioned topic identifier) ​​because the same target heartbeat information may be accompanied by the accompanying information of different users, and the same target heartbeat information may also be accompanied by the accompanying information of multiple different businesses of a user. Only by customizing the corresponding Topic can the sending and receiving of this information be completed. The different application layer modules of each user subscribe to different Topics to complete the reception and processing of the information they need. Therefore, each application layer module needs to specify a unique Topic for sending the application layer extended information content; and the application layer extended information may contain one or more Topic information; or it may not contain any Topic information; when receiving the target heartbeat information, the application layer extended information can be obtained by subscribing to the Topic uniquely specified by its own module. The application layer module can also subscribe to the Topics of other modules belonging to the same node to obtain the information sent by other modules.

[0213] like Fig. 16B As shown, for the application layer extended information required by node B, node A writes the consensus key parameters corresponding to the consensus module, such as the block height and Leader information that are being consensused and required by node B, into Topic A, and node A writes the synchronization key parameters corresponding to the synchronization module into Topic C; after broadcasting the target heartbeat information of node A to node B, the consensus module of node B subscribes to Topic A, and can obtain the consensus key parameters written to Topic A, and the synchronization module of node B subscribes to Topic C, and can obtain the synchronization key parameters written to Topic C. For Topic B and Topic D in the node, they may be customized information for the business needs of other nodes. The consensus module and synchronization module of node B can subscribe to the Topic corresponding to node B, but cannot subscribe to the Topics of other nodes, that is, they cannot obtain the information written to Topic B and Topic D.

[0214] In the embodiment of the present application, the heartbeat broadcaster includes two broadcast modes, namely passive broadcast and active broadcast. Fig.17 As shown, in passive broadcasting, a timer needs to be maintained. This timer is responsible for triggering a broadcast event at regular intervals. The regular intervals here are not fixed time, but a dynamically adjustable data; active broadcasting is triggered in real time.

[0215] For passive broadcast, the timer triggers a broadcast event at a certain interval, and the adjustment of the time is affected by two aspects: one is whether the heartbeat response information ack received from the peer node is timely; the other is whether the information sent by itself is continuously the same. Fig.18 As shown in the figure, the timer will send heartbeats according to the default 1s delay, and then wait for the ack return signal from the other end; when the ack of the other end times out for more than 1 time in a row, that is, the ack returned by the peer node for 2 or more times exceeds the preset time, it will trigger delay superposition, that is, delay ++. The preset time is configurable and defaults to 2s. When the ack returned for 2 or more times in a row is received on time, it will trigger delay reduction, that is, delay --, with a minimum of 1s.

[0216] It is worth noting that Delay++ means that the heartbeat broadcast interval delay between the two target heartbeat messages has increased, and the heartbeat broadcast interval has entered the next Fibonacci sequence element. The Fibonacci sequence is: 1 1 2 3 5 8 1321 34... If the current heartbeat broadcast interval is 1s, and the ack of the peer node has timed out twice in a row, the heartbeat broadcast interval will be delayed to 2s. If it is currently 5s, it will be delayed to 8s. After the delay is increased, the maximum heartbeat broadcast interval will not exceed 34s, and after each delay++, the continuous calculation will be reset to zero. Therefore, delay++ will not be triggered continuously due to stable ack.

[0217] For example, the timer starts at 0 o'clock, and at 1 second, the target heartbeat information 1 is broadcast to the peer node, and the ack returned by the peer node times out. After an interval of 1 second, the target heartbeat information 2 is broadcast to the peer node at 2 seconds, and the ack returned by the peer node still times out, that is, the peer node has timed out twice in a row, and the delay is increased to 2 seconds later, that is, at the 4th second, the target heartbeat information 3 is broadcast to the peer node, completing one delay++. At this time, the timeout of the peer node is continuously calculated to zero, that is, if the ack returned by the peer node still times out, it is counted as 1 timeout. After an interval of 2 seconds, the target heartbeat information 4 is broadcast to the peer node at the 6th second, and the ack returned by the peer node still times out, which is counted as 2 consecutive timeouts. The delay continues to increase to an interval of 3 seconds, that is, at the 9th second, the target heartbeat information 5 is broadcast to the peer node.

[0218] It can be understood that when the target heartbeat information 3 is broadcast, the total number of timeouts of the peer node is 2 times, and the delay duration is 1s; when the target heartbeat information 5 is broadcast, the total number of timeouts of the peer node is 4 times, and the delay duration is 2s, that is, the more total timeouts of the peer node, the longer the delay duration.

[0219] Delay refers to the time it takes for the heartbeat broadcast interval to enter the last Fibonacci sequence element. For example, if the current heartbeat broadcast interval is 5s, the delay will be reduced to 3s. If the current heartbeat broadcast interval is 2s, it will be reduced to 1s. If it is already 1s, it will not be reduced any more. Similarly, delay will not be triggered continuously.

[0220] For example, the current heartbeat broadcast interval is 5s. At time t, the target heartbeat information n is broadcast to the peer node, and the peer node ack replies on time. The current heartbeat broadcast interval is still 5s. At time t+5, the target heartbeat information n+1 is broadcast to the peer node, and the peer node ack replies are still on time, that is, the peer node has been on time for two consecutive times. The delay is reduced to an interval of 3s, that is, at time t+5+3, the target heartbeat information n+2 is broadcast to the peer node, and the continuous calculation is reset to zero. If the peer node ack replies are still on time, the broadcast interval is maintained at 3s. After two consecutive on-time replies, the delay is reduced to 1s.

[0221] It should be understood that the broadcast intervals of Delay++ and Delay-- may also satisfy other number series rules, such as arithmetic series, geometric series, prime number series, etc. The embodiment of the present application only takes the Fibonacci series as an example.

[0222] For the target heartbeat information sent by the local node itself, if the data is the same continuously, Delay++ will be triggered. Each target heartbeat information will be accompanied by a sum value generated by a fixed hash algorithm to verify the integrity of the sent heartbeat packet data. If the content of the target heartbeat information is the same, the generated sum value must also be the same. Fig.19 As shown, from synthesizing the target heartbeat information to sending the target heartbeat information, the content of the target heartbeat information needs to be hashed to generate the corresponding sum value; and after each target heartbeat information is sent, the sum value is updated to the cache, and each time the sum value is calculated for the target heartbeat information, it will be compared with the previous sum value in the cache. If the sum values ​​are inconsistent, it means that the content of the target heartbeat information is different, so no processing is required; if the sum values ​​are consistent, it means that the content of the target heartbeat information is consistent with the previous one, so the broadcast interval of the target heartbeat information is delayed++.

[0223] It should be noted that the delay mode of Delay++ triggered by the same sum value and Delay++ triggered by ack can be the same or different; for example, Delay++ triggered by the same sum value satisfies the arithmetic progression, while Delay++ triggered by ack satisfies the Fibonacci sequence; and when Delay++ triggered by ack and sum are not synchronized; when ack triggers Delay++ and sum calculation also triggers Delay++, it is calculated only once and Delay++ will not be calculated repeatedly. At this time, you can choose a broadcast interval with less delay to broadcast the target heartbeat information.

[0224] In active broadcast, the heartbeat broadcaster will provide an interface to support other modules, directly call and trigger the heartbeat sending, that is, when the local node detects the trigger call information of the peer node, it will broadcast the target heartbeat information in real time. Usually, the actively broadcast heartbeat will be accompanied by the data attached by the user in the extended information; of course, the actively broadcast heartbeat can also be without any extended data, just to send the heartbeat in time.

[0225] In active broadcast, it can also be triggered by application layer extended information. For application layer modules, some information communications need to be sent in real time. For example, the node's reply to voting information in the consensus module needs to be replied in real time. Therefore, if the application layer extended information contains information that needs to be sent in real time, the target heartbeat information is broadcast in real time.

[0226] In the embodiment of the present application, the heartbeat receiver is used to receive the target heartbeat information broadcast by the peer broadcaster, such as Fig. 20 As shown, after the heartbeat receiver receives the target heartbeat information, it will first verify the sum value of the target heartbeat information. If the verification fails, it means that the content of the target heartbeat information is wrong, or it has been tampered with or the information has been lost, and the heartbeat can be directly discarded; after the sum value verification passes, the target heartbeat information is parsed to obtain the information used to describe the state of the node and the application layer extended information content, and the information used to describe the state of the node is handed over to the state controller to update the node state of the heartbeat source node, including the current latest block height; the application layer extended information will be distributed to all subscribers according to the local subscription to the Topic, and the subscribers will process the content information corresponding to the subscribed Topic.

[0227] like Fig.21As shown, the state controller is used to collect and store the state information of other nodes. If the state controller is just started, the node state list it maintains does not contain any information. The node ID in the information used to describe the state of the node and the maintained node state list can be used to determine whether the node exists. If the node does not exist, the node information is added to the maintained node state list and a new node addition event is sent. If the node already exists, the node information is updated and a node update event is sent.

[0228] In the embodiment of the present application, the state controller maintains a timer to scan all maintained nodes at regular intervals. If the time when the node last updated its status and the current time interval exceed a certain value, the node will be triggered to go offline. The node offline will first update the node status to offline (offline) and trigger the node offline event. When the heartbeat information of the offline node is received again, the node will be triggered to go online; the node online will first update the node status to online (online) and trigger the node online event.

[0229] The method provided in the embodiment of the present application provides a unified state management function, which reduces the coupling of the blockchain system for modules that rely on the state of other nodes; uniformly shrinks the sending and receiving of heartbeats, greatly reduces the message transmission in the blockchain network, and improves the communication efficiency of the blockchain network, thereby improving the performance of the blockchain system; provides an extensible heartbeat information definition mechanism and heartbeat sending mechanisms in different modes, making the capabilities that the blockchain system can support more diversified.

[0230] The device embodiment of the present application is introduced, which can be used to execute the blockchain node state control method in the above embodiment of the present application. For details not disclosed in the device embodiment of the present application, please refer to the embodiment of the blockchain node state control method in the above embodiment of the present application.

[0231] The present application embodiment provides a blockchain node state control device, such as Fig. 22 As shown, the blockchain node state control device can be configured in a blockchain node, and the device includes:

[0232] An acquisition module 2210 is used to acquire heartbeat information corresponding to multiple application layers of the local node and user-defined application layer extension information of the local node, wherein the heartbeat information is used to describe the state of the application layer of the local node;

[0233] A synthesis module 2220, configured to extract common information of a plurality of heartbeat information, and generate target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extended information;

[0234] A determination module 2230, configured to determine a broadcast time of the target heartbeat information according to the response operation information of the opposite end node to the local end node and at least one of the opposite end nodes;

[0235] The broadcast module 2240 is configured to broadcast the target heartbeat information to the peer node according to the broadcast time of the target heartbeat information.

[0236] In one embodiment of the present application, based on the aforementioned scheme, the response operation information includes multiple consecutive historical heartbeat response information of the counterpart node; the determination module 2230 is further used to obtain the historical response times corresponding to the multiple historical heartbeat response information respectively, and obtain multiple historical response times; according to the relationship between the multiple historical response times and the preset time threshold, determine the broadcast interval between the target heartbeat information and the previous historical heartbeat information; determine the broadcast time of the target heartbeat information according to the broadcast interval and the broadcast time of the previous historical heartbeat information.

[0237] In one embodiment of the present application, based on the aforementioned scheme, the determination module 2230 is further used to obtain the broadcast waiting time of the previous historical heartbeat information; if the multiple historical response times all exceed the preset time threshold, the broadcast waiting delay time of the target heartbeat information is determined according to the total number of historical response times exceeding the preset time threshold, wherein the total number of historical response times exceeding the preset time threshold is positively correlated with the broadcast waiting delay time; based on the broadcast waiting time and the broadcast waiting delay time, the broadcast interval between the target heartbeat information and the previous historical heartbeat information is determined.

[0238] In one embodiment of the present application, based on the aforementioned scheme, the determination module 2230 is further used to obtain the broadcast waiting time of the previous historical heartbeat information; when the broadcast waiting time of the previous historical heartbeat information is not the default waiting time, if the multiple historical response times do not exceed the preset time threshold, then the broadcast waiting reduction time of the target heartbeat information is determined according to the total number of historical response times that do not exceed the preset time threshold, wherein the total number of historical response times that do not exceed the preset time threshold is negatively correlated with the broadcast waiting reduction time; the broadcast waiting time is subtracted from the broadcast waiting reduction time to obtain the broadcast interval between the target heartbeat information and the previous historical heartbeat information.

[0239] In one embodiment of the present application, based on the aforementioned scheme, the determination module 2230 is further used to generate a verification value of the target heartbeat information according to the information content contained in the target heartbeat information; match the verification value of the target heartbeat information with the verification value of the previous historical heartbeat information; if the verification value of the target heartbeat information is consistent with the verification value of the previous historical heartbeat information, determine the waiting delay time for the target heartbeat information, and determine the broadcast time of the target heartbeat information according to the waiting delay time and the broadcast time of the previous historical heartbeat information.

[0240] In one embodiment of the present application, based on the aforementioned scheme, the determination module 2230 is further used to determine the priority of the target heartbeat information according to the information content contained in the application layer extension information. If the priority of the target heartbeat information is greater than the preset priority, the broadcast time of the target heartbeat information is determined to be the current time; or, if the response operation information includes the call trigger information of the peer node, the broadcast time of the target heartbeat information is determined to be the current time.

[0241] In one embodiment of the present application, based on the aforementioned scheme, the determination module 2230 is further used to determine the first broadcast time of the heartbeat information according to the first broadcast time determination method and the information content contained in the target heartbeat information; determine the second broadcast time of the target heartbeat information according to the second broadcast time determination method and the response operation information, the first broadcast time determination method and the second broadcast time determination method are different; select the broadcast time closest to the current time from the first broadcast time and the second broadcast time as the broadcast time of the target heartbeat information.

[0242] In one embodiment of the present application, based on the aforementioned scheme, the acquisition module 2210 is further used to acquire the application scenario corresponding to the opposite node, and customize the key parameters required for the application scenario; generate the application layer extension information according to the key parameters; the synthesis module 2220 is further used to obtain the non-shared information of the multiple heartbeat information, generate target information based on the non-shared information and the synthesis result, and calculate the verification value of the target information; synthesize the target information and the verification value to obtain the target heartbeat information.

[0243] In one embodiment of the present application, based on the aforementioned scheme, the acquisition module 2210 is further used to configure a unique subject identifier for the application scenario corresponding to each peer node according to the node identifier of each peer node and the application type of the application scenario; associate the key parameters required for the application scenario corresponding to each peer node with the corresponding subject identifier, and generate application layer extension information based on the associated subject identifiers.

[0244] In one embodiment of the present application, based on the aforementioned scheme, the device also includes an update module, which is used to receive the peer heartbeat information broadcast by the peer node and verify the peer heartbeat information; if the verification of the peer heartbeat information is passed, obtain the information in the peer heartbeat information used to describe the status of the application layer of the peer node; update the node status of the peer node according to the information used to describe the status of the application layer of the peer node.

[0245] In one embodiment of the present application, based on the aforementioned scheme, the peer heartbeat information also includes customized peer application layer extension information, and the peer application layer extension information is generated based on a subject identifier associated with key parameters required for the local application scenario; the device also includes a distribution module, which is used to obtain a subject identifier corresponding to the node identifier of the local node based on the peer application layer extension information, and obtain the subscription status of the local application layer to the obtained subject identifier; based on the subscription status, the key parameters associated with the obtained subject identifier are distributed to the corresponding local application layer for processing.

[0246] In one embodiment of the present application, based on the aforementioned scheme, the update module is further used to obtain the time interval between the last update time of the node status of the counterpart node and the current time; if the time interval is greater than a preset interval threshold, the node status of the counterpart node is updated to an offline state.

[0247] It should be noted that the device provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0248] An embodiment of the present application also provides an electronic device, comprising one or more processors and a storage device, wherein the storage device is used to store one or more computer programs, and when the one or more computer programs are executed by one or more processors, the electronic device implements the above-mentioned blockchain node state control method.

[0249] Fig.23 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0250] It should be noted that Fig.23 The computer system 2300 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application, wherein the electronic device may be a terminal or a server.

[0251] like Fig.23As shown, the computer system 2300 includes a processor (Central Processing Unit, CPU) 2301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (Read-Only Memory, ROM) 2302 or the program loaded from the storage part 2308 to the random access memory (Random Access Memory, RAM) 2303, such as executing the method in the above embodiment. In RAM 2303, various programs and data required for system operation are also stored. CPU 2301, ROM 2302 and RAM 2303 are connected to each other through bus 2304. Input / output (Input / Output, I / O) interface 2305 is also connected to bus 2304.

[0252] In some embodiments, the following components are connected to the I / O interface 2305: an input section 2306 including a keyboard, a mouse, etc.; an output section 2307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 2308 including a hard disk, etc.; and a communication section 2309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 2309 performs communication processing via a network such as the Internet. A drive 2310 is also connected to the I / O interface 2305 as needed. A removable medium 2311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 2310 as needed, so that a computer program read therefrom is installed into the storage section 2308 as needed.

[0253] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 2309, and / or installed from the removable medium 2311. When the computer program is executed by the processor (CPU) 2301, various functions defined in the system of the present application are executed.

[0254] It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (Erasable Programmable Read Only Memory), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0255] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the devices, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0256] The units or modules involved in the embodiments described in this application may be implemented by software or hardware, and the units or modules described may also be set in a processor. The names of these units or modules do not, in some cases, constitute limitations on the units or modules themselves.

[0257] Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the method described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0258] Another aspect of the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the electronic device executes the method provided in the above-mentioned embodiments.

[0259] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0260] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0261] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person of ordinary skill in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A blockchain node state control method, characterized in that: include: Acquire heartbeat information corresponding to multiple application layers of the local node and customized application layer extension information of the local node, wherein the heartbeat information is used to describe the state of the application layer of the local node; Extracting common information of a plurality of heartbeat information, and generating target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extended information; Determine the broadcast time of the target heartbeat information according to at least one of the response operation information of the opposite node to the local node and the target heartbeat information, wherein the opposite node includes a node connected to the local node; The target heartbeat information is broadcast to the peer node according to the broadcast time of the target heartbeat information.

2. The method according to claim 1, characterized in that The response operation information includes a plurality of continuous historical heartbeat response information of the peer node; and the determining the broadcast time of the target heartbeat information according to at least one of the response operation information of the peer node to the local node and the target heartbeat information includes: Obtain the historical response times respectively corresponding to the multiple historical heartbeat response information to obtain multiple historical response times; Determine the broadcast interval between the target heartbeat information and the last historical heartbeat information according to the relationship between the multiple historical response times and the preset time threshold; The broadcast time of the target heartbeat information is determined according to the broadcast interval and the broadcast time of the previous historical heartbeat information.

3. The method according to claim 2, characterized in that The determining, according to the relationship between the plurality of consecutive historical response times and a preset time threshold, a broadcast interval between the target heartbeat information and the last historical heartbeat information comprises: Get the broadcast waiting time of the previous historical heartbeat information; If the multiple historical response times all exceed the preset time threshold, the broadcast waiting delay duration of the target heartbeat information is determined according to the total number of historical response times exceeding the preset time threshold, wherein the total number of historical response times exceeding the preset time threshold is positively correlated with the broadcast waiting delay duration; A broadcast interval between the target heartbeat information and the previous historical heartbeat information is determined based on the broadcast wait time and the broadcast wait delay time.

4. The method according to claim 2, characterized in that: The determining, according to the relationship between the plurality of consecutive historical response times and a preset time threshold, a broadcast interval between the target heartbeat information and the last historical heartbeat information comprises: Get the broadcast waiting time of the previous historical heartbeat information; When the broadcast waiting time of the previous historical heartbeat information is not the default waiting time, if the multiple historical response times do not exceed the preset time threshold, the broadcast waiting reduction time of the target heartbeat information is determined according to the total number of historical response times that do not exceed the preset time threshold, wherein the total number of historical response times that do not exceed the preset time threshold is negatively correlated with the broadcast waiting reduction time; The broadcast waiting time is subtracted from the broadcast waiting reduction time to obtain the broadcast interval between the target heartbeat information and the previous historical heartbeat information.

5. The method according to claim 1, characterized in that: The determining the broadcast time of the heartbeat information according to at least one of the response operation information of the opposite end node to the local end node and the target heartbeat information comprises: Generate a verification value of the target heartbeat information according to the information content contained in the target heartbeat information; Matching the verification value of the target heartbeat information with the verification value of the previous historical heartbeat information; If the verification value of the target heartbeat information is consistent with the verification value of the previous historical heartbeat information, a waiting delay duration is determined for the target heartbeat information, and a broadcast time of the target heartbeat information is determined according to the waiting delay duration and the broadcast time of the previous historical heartbeat information.

6. The method according to claim 1, characterized in that The determining the broadcast time of the heartbeat information according to at least one of the response operation information of the opposite end node to the local end node and the target heartbeat information comprises: Determine the priority of the target heartbeat information according to the information content contained in the application layer extended information, and if the priority of the target heartbeat information is greater than the preset priority, determine the broadcast time of the target heartbeat information as the current time; Or, if the response operation information includes the call trigger information of the opposite node, the broadcast time of the target heartbeat information is determined to be the current time.

7. The method according to claim 1, characterized in that The determining the broadcast time of the heartbeat information according to at least one of the response operation information of the opposite end node to the local end node and the target heartbeat information comprises: Determine a first broadcast time of the target heartbeat information according to a first broadcast time determination method and information content included in the target heartbeat information; determining a second broadcast time of the target heartbeat information according to a second broadcast time determination method and the response operation information, wherein the first broadcast time determination method and the second broadcast time determination method are different; A broadcast time closest to the current time is selected from the first broadcast time and the second broadcast time as the broadcast time of the target heartbeat information.

8. The method according to claim 1, characterized in that The step of obtaining heartbeat information respectively corresponding to multiple application layers of the local node and the customized application layer extension information of the local node includes: Obtaining an application scenario corresponding to the peer node, and customizing key parameters required for determining the application scenario; Generate the application layer extension information according to the key parameters; Generating the target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extended information, including: Acquire non-shared information of the plurality of heartbeat information, generate target information based on the non-shared information and the synthesis result, and calculate a verification value of the target information; The target information and the verification value are synthesized to obtain the target heartbeat information.

9. The method according to claim 8, characterized in that The number of the peer nodes includes a plurality; and the generating the application layer extension information according to the key parameters includes: According to the node identifier of each peer node and the application type of the application scenario, a unique subject identifier is configured for each application scenario corresponding to each peer node; The key parameters required by the application scenarios corresponding to the respective peer nodes are associated with the corresponding subject identifiers, and application layer extension information is generated according to the associated subject identifiers.

10. The method according to any one of claims 1 to 9, characterized in that: The method further comprises: Receiving the peer heartbeat information broadcasted by the peer node, and verifying the peer heartbeat information; If the verification of the peer heartbeat information is passed, obtaining information in the peer heartbeat information for describing the state of the application layer of the peer node; The node state of the counterpart node is updated according to the information used to describe the state of the application layer of the counterpart node.

11. The method according to claim 10, characterized in that The peer heartbeat information also includes customized peer application layer extension information, and the peer application layer extension information is generated according to a subject identifier associated with key parameters required by the local application scenario; the method also includes: Acquire a topic identifier corresponding to the node identifier of the local node according to the peer application layer extension information, and acquire a subscription status of the local application layer module to the acquired topic identifier; Based on the subscription situation, the key parameters associated with the acquired subject identifier are distributed to the corresponding local application layer module for processing.

12. The method according to claim 10, characterized in that After updating the node state of the opposite node according to the information used to describe the state of the application layer of the opposite node, the method further includes: Obtaining the time interval between the last update time of the node status of the peer node and the current time; If the time interval is greater than a preset interval threshold, the node state of the opposite node is updated to an offline state.

13. A blockchain node state control device, characterized in that: include: An acquisition module, used to acquire heartbeat information corresponding to multiple application layers of a local node and user-defined application layer extension information of the local node, wherein the heartbeat information is used to describe the node status of the local node; A synthesis module, used for extracting common information of a plurality of heartbeat information, and generating target heartbeat information of the local node according to a synthesis result obtained by synthesizing the common information and the application layer extended information; A determination module, configured to determine a broadcast time of the target heartbeat information according to at least one of the response operation information of the opposite end node to the local end node and the target heartbeat information, wherein the opposite end node includes a node connected to the local end node; A broadcast module is used to broadcast the target heartbeat information to the opposite end node according to the broadcast time of the target heartbeat information.

14. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to execute the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of an electronic device, the electronic device executes the method according to any one of claims 1 to 12.

16. A computer program product, characterized in that The computer program product comprises a computer program, wherein the computer program is stored in a computer-readable storage medium, and a processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the method according to any one of claims 1 to 12.

Images