CN116319822A - Switching method and device of consensus algorithm, computer equipment and medium - Google Patents

Switching method and device of consensus algorithm, computer equipment and medium Download PDF

Info

Publication number
CN116319822A
CN116319822A CN202211082561.1A CN202211082561A CN116319822A CN 116319822 A CN116319822 A CN 116319822A CN 202211082561 A CN202211082561 A CN 202211082561A CN 116319822 A CN116319822 A CN 116319822A
Authority
CN
China
Prior art keywords
consensus
node
algorithm
block
switching
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211082561.1A
Other languages
Chinese (zh)
Inventor
黄方蕾
邱炜伟
李兆硕
尚璇
张珂杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Qulian Technology Co Ltd
Original Assignee
Hangzhou Qulian Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Qulian Technology Co Ltd filed Critical Hangzhou Qulian Technology Co Ltd
Priority to CN202211082561.1A priority Critical patent/CN116319822A/en
Publication of CN116319822A publication Critical patent/CN116319822A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Retry When Errors Occur (AREA)

Abstract

The embodiment of the application is applicable to the technical field of block chains, and provides a switching method, a switching device, computer equipment and a medium of a consensus algorithm, wherein the method is applied to nodes of block chains and comprises the following steps: if the block to be consensus obtained from the transaction pool is a configuration block, generating check point information, wherein the check point information is used for recording the current consensus state of the node; if the preset number of other nodes in the block chain are consistent with the current consensus state of the nodes, storing the consensus state into the on-chain data of the block chain; acquiring configuration transaction from a configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched; switching the current consensus algorithm used by the node into a target consensus algorithm; and initializing the node according to the target consensus algorithm and the consensus state to finish the switching of the consensus algorithm on the node. By the method, the switching of the consensus algorithm of the block chain can be performed in an on-line environment, and the stability of the block chain is ensured.

Description

Switching method and device of consensus algorithm, computer equipment and medium
Technical Field
The application belongs to the technical field of blockchain, and particularly relates to a switching method, device computer equipment and medium of a consensus algorithm.
Background
The blockchain system may maintain consistency of cluster states in the blockchain system through a consensus algorithm. Different consensus algorithms have respective characteristics, so that the method has an own optimal applicable scene. For example, the non-Bayesian family scene of the simplest scene can be considered to use the non-Bayesian family fault tolerance consensus algorithm raft algorithm; when the Bayesian scene is considered and the number of nodes is not large, a practical Bayesian fault-tolerant consensus algorithm pbft algorithm is considered to be used; when the bayer scene is considered, the number of nodes is large, and the network bandwidth resources are limited, a modified algorithm hottstuff pipeline algorithm using the PBFT algorithm can be considered.
In order to enable the blockchain system to use different consensus algorithms according to different scenes, switching of the consensus algorithm can be performed in the blockchain system. There are generally two methods for common algorithm switching in a block chain.
The first method is to perform an offline handoff. The consensus algorithm switching can be performed by manually stopping the original algorithm and adding a new algorithm-initiated configuration file. The new consensus algorithm after switching is initialized by reading the configuration file of human intervention, thereby achieving the purpose of switching algorithm. However, switching the consensus algorithm using this method can result in partial transaction loss when the original algorithm is stopped, thereby reducing the reliability of the blockchain system.
Another method is to implement switching of the consensus algorithm in an on-line environment by two algorithms in parallel. However, the two algorithms are parallel, which inevitably leads to an increase in bandwidth usage and a relatively high requirement on the network.
Disclosure of Invention
In view of this, the embodiments of the present application provide a method, an apparatus, a computer device, and a medium for switching a consensus algorithm, which are used for switching the consensus algorithm in an online environment, so as to ensure reliability of a blockchain in a switching process of the consensus algorithm.
A first aspect of an embodiment of the present application provides a method for switching a consensus algorithm, applied to a node of a blockchain, the method including:
if the block to be consensus obtained from the transaction pool is a configuration block, generating check point information, wherein the check point information is used for recording the current consensus state of the node;
if the preset number of other nodes in the block chain are consistent with the current consensus state of the nodes, storing the consensus state into the on-chain data of the block chain;
acquiring a configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched;
switching the current consensus algorithm used by the node into the target consensus algorithm;
And initializing the node according to the target consensus algorithm and the consensus state to finish switching of the consensus algorithm on the node.
A second aspect of an embodiment of the present application provides a switching device of a consensus algorithm, applied to a node of a blockchain, the device including:
the generation module is used for generating check point information if the block to be identified obtained from the transaction pool is a configuration block, wherein the check point information is used for recording the current identification state of the node;
the system comprises a block chain module, a block chain module and a data processing module, wherein the block chain module is used for storing the current consensus state of other nodes with preset quantity in the block chain into the on-chain data of the block chain if the current consensus state of the other nodes is consistent with the preset quantity in the block chain;
the acquisition module is used for acquiring configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched;
the switching module is used for switching the current consensus algorithm used by the node into the target consensus algorithm;
and the initialization module is used for initializing the node according to the target consensus algorithm and the consensus state so as to complete the switching of the consensus algorithm on the node.
A third aspect of the embodiments of the present application provides a switching module of a consensus algorithm, applied to a node of a blockchain, including a consensus layer, an algorithm layer, and a transaction pool; wherein,,
The consensus layer is used for packaging a specific consensus algorithm;
the algorithm layer is used for carrying out cluster consensus operation of corresponding algorithm logic on the block according to the current consensus algorithm in the block chain;
and the transaction pool is used for storing the transaction received by the node.
A fourth aspect of the embodiments of the present application provides a computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to the first aspect described above when executing the computer program.
A fifth aspect of embodiments of the present application provides a computer readable storage medium storing a computer program which, when executed by a processor, implements a method as described in the first aspect above.
A sixth aspect of the embodiments of the present application provides a computer program product for, when run on a computer device, causing the computer device to perform the method of the first aspect described above.
Compared with the prior art, the embodiment of the application has the following advantages:
according to the embodiment of the application, when the nodes in the block chain share the configuration blocks, the switching of the consensus algorithm can be determined, so that the current consensus state of the nodes can be recorded by generating the check point information. When the node determines that the preset number of other nodes in the blockchain are consistent with the consensus state of the node, the current consensus state can be determined to have reached consensus in the blockchain, and at the moment, the current consensus state can be subjected to data uplink. After the consensus state is uplink, the node can stop the current consensus algorithm, and switch the consensus algorithm into a target consensus algorithm included in the configuration block; and then acquiring the consensus state stored before the node from the data on the chain, and initializing the node by adopting a target consensus algorithm and the consensus state, thereby completing the switching of the consensus algorithm of the node. The embodiment can realize the switching of the online consensus algorithm based on the configuration transaction in the configuration block. The embodiment performs consensus algorithm switching in an online environment, so that transaction loss during algorithm switching can be avoided, and the reliability of a blockchain is ensured; meanwhile, in the embodiment, two consensus algorithms cannot be operated at the same time in the node, so that the consumption of network bandwidth in the switching process of the consensus algorithm is reduced.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings that are required to be used in the embodiments or the description of the prior art. It is apparent that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.
Fig. 1 is a schematic flow chart of a step of a handover method of a consensus algorithm according to an embodiment of the present application;
FIG. 2 is a schematic flow chart of exception handling in a handover procedure of a consensus algorithm according to an embodiment of the present disclosure;
fig. 3 is a schematic step flow diagram of a handover method of another consensus algorithm according to an embodiment of the present application;
fig. 4 is a schematic diagram of a switching module of a consensus algorithm according to an embodiment of the present application;
fig. 5 is a flow chart of a switching method of another consensus algorithm according to an embodiment of the present application;
fig. 6 is a schematic diagram of a node state after switching of a consensus algorithm according to an embodiment of the present application;
fig. 7 is a schematic diagram of a switching device of a consensus algorithm according to an embodiment of the present application;
Fig. 8 is a schematic diagram of a computer device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in this specification and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
In addition, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
At present, when the consensus algorithm is switched, if an offline switching method is adopted, the original algorithm is required to be manually stopped, and a configuration file is manually added to start a new algorithm, so that on one hand, the flexibility and the verifiability of a blockchain system are reduced due to the manually added configuration file; on the other hand, the switching period of the consensus algorithm has a period without the consensus algorithm, which is easy to cause transaction loss.
It is thus possible to consider that the on-line handover is achieved by running both algorithms in parallel. This type of approach can integrate all consensus algorithms through one switcher. During reconfiguration of the consensus algorithm, nodes in the blockchain may run both algorithms in parallel, forwarding all consensus messages received by the nodes to both protocols simultaneously. After the original algorithm is in a stop state, the message that the original algorithm does not complete the consensus continues to be consensus by the new algorithm. However, this approach results in a significant increase in bandwidth usage during reconfiguration, as all messages are agreed upon in both protocols. Thus, this optimization can only be applied to systems where the network has no bottlenecks.
Based on the above, the application provides an on-line switching scheme of the consensus algorithm based on configuration transaction implementation, which can realize on-line switching of the consensus algorithm under the condition of not consuming a large amount of network bandwidth. The technical scheme of the present application is described below by specific examples.
Referring to fig. 1, a schematic step flow diagram of a handover method of a consensus algorithm provided in an embodiment of the present application is shown, which may specifically include the following steps:
and S101, if the block to be consensus obtained from the transaction pool is a configuration block, generating check point information, wherein the check point information is used for recording the current consensus state of the node.
The implementation subject of this embodiment is a node in the blockchain, which may be a computer device, such as an electronic computer, a server, etc., that deploys the blockchain network. A plurality of nodes may be included in the blockchain, and a master node may be included in the plurality of nodes. When the blockchain manager switches the consensus algorithm of the blockchain, the blockchain manager may send a configuration transaction to a master node in the blockchain, where the configuration transaction may include the consensus algorithm information to be switched. After receiving the transaction sent by the blockchain manager, the master node may identify the transaction type of the transaction. If the master node recognizes that the transaction is a configuration transaction, the transaction can be individually packaged into a configuration block; the configuration block is then broadcast to nodes in the blockchain, including the master node, which can switch the consensus algorithm based on the received configuration block. The execution body of the embodiment may be any node in the blockchain, and the node may be a master node or not.
In one possible implementation, if the node is a master node, a configuration transaction sent by a blockchain administrator may be received, the configuration transaction is individually packaged into a configuration block, and then the configuration block is stored in a transaction pool; the master node may also broadcast the configuration block to other nodes in the blockchain. If the node is not the master node, the node may receive a configuration block broadcast from the master node and then store the configuration block in the transaction pool.
Each node, upon receiving the configuration blocks, may store the configuration blocks in its own transaction pool. The transaction pool of the node can store a plurality of blocks to be shared, and the node can acquire the blocks to be shared from the transaction pool according to a certain sequence and share the blocks to be shared. For example, the node may obtain blocks to be consensus from the pool in the order in which the blocks to be consensus were received.
After the node obtains the block to be shared from the transaction pool, the block to be shared needs to be analyzed, so that transaction information needing to be shared in the block to be shared is obtained. In a general block to be consensus, batch transaction information is stored, namely the block to be consensus comprises a plurality of transactions to be consensus; and only one configuration transaction is included in the configuration block. If the node identifies that only one transaction is included in the block to be shared and the transaction is a configuration transaction, the block to be shared can be determined to be the configuration block.
In one possible implementation manner, the configuration block may carry identification information, and after the node obtains the block to be identified, if it is identified that the block to be identified carries the identification information of the configuration block, the node may determine that the block to be identified is the configuration block.
If the node identifies the configuration block, the node is indicated to enter a state of switching the consensus algorithm. In order to ensure the cluster consistency of the blockchain system before and after the switching of the consensus algorithm, the node can generate check point information to record the current consensus state of the node. This checkpoint information is then broadcast into each node of the blockchain.
Each node of the blockchain may broadcast checkpoint information to other nodes and receive other checkpoint information from other nodes. S102, if a preset number of other nodes in the block chain are consistent with the current consensus state of the nodes, storing the consensus state into the on-chain data of the block chain.
Because the check point information can record the current consensus state of the nodes, whether the consensus states among different nodes on the blockchain are consistent can be judged through the check point information.
The node can receive other check point information from a plurality of other nodes, and then count the quantity of other check point information with the consensus state consistent with the check point information of the node; if the number is greater than the preset value, it may be indicated that there are other nodes with preset numbers consistent with the current consensus state of the node. That is, the cluster consistency check of the blockchain system may be considered to pass.
Then, stable checkpoint information can be generated according to the checkpoint information, and a consensus state consistent with other nodes can be recorded in the stable checkpoint information; and then the node can carry out data uplink on the stable point information, so that the consensus state of the node before switching the consensus algorithm can be stored in the on-link data.
S103, acquiring a configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched.
The configuration block may include a configuration transaction, where configuration information may be carried in the configuration transaction, and the configuration information may include a target consensus algorithm to be switched.
In one possible implementation, the consensus algorithm in the node has version information, e.g. the version of the target consensus algorithm is higher than the version of the consensus algorithm currently used by the node. After receiving the configuration transaction, the master node can determine the version of the currently used consensus algorithm, then determine the version corresponding to the consensus algorithm in the configuration transaction as a version one level higher than the currently used consensus algorithm, and generate a corresponding version number. After each node acquires the configuration transaction, determining whether the version of the currently used consensus algorithm is behind the version of the consensus algorithm corresponding to the configuration transaction according to the version number; if the version of the consensus algorithm currently used by the node is later than the version of the consensus algorithm corresponding to the configuration transaction, it can be determined that the consensus algorithm needs to be switched according to the configuration transaction, otherwise, the consensus algorithm does not need to be switched.
S104, switching the current consensus algorithm used by the node into the target consensus algorithm.
The node may stop the original algorithm and then switch the consensus engine to switch the consensus algorithm of the node to the target consensus algorithm. The consensus algorithm engine may include a plurality of consensus algorithms, and different consensus algorithms may perform consensus based on different consensus logic. And switching the consensus engine to switch the consensus logic in the node to the consensus logic of the target consensus algorithm, so that the node can perform consensus according to the new consensus logic.
And S105, initializing the node according to the target consensus algorithm and the consensus state so as to complete switching of the consensus algorithm on the node.
Since the stable checkpoint information is stored on the blockchain, the consensus status of the node prior to switching consensus algorithms can be obtained from the chain. Based on the consensus state before switching the consensus algorithm, the node can initialize by using the target consensus algorithm, so that the node reaches the consensus state before switching the consensus algorithm, thereby completing switching the consensus algorithm on the node, and then adopting the target consensus algorithm to perform consensus on the blocks to be consensus after configuring the blocks. Based on this, in this embodiment, one consensus block will be commonly known by only one consensus algorithm, and two consensus algorithms will not be simultaneously run in the blockchain node.
After identifying the configuration block, the node may block the consensus process after the configuration block so that there is no collision of algorithms during the consensus algorithm switch. After the switching of the consensus algorithm is completed, the node can continue the consensus process, acquire the block to be consensus after the configuration block from the transaction pool, and perform consensus on the block to be consensus by adopting the target consensus algorithm. In one possible implementation, a flag bit may be included in the node, and the flag bit may be used to identify whether the node is performing a handover of the consensus algorithm. For example, in the consensus process, if a configuration block is identified, the flag bit may be set to a first preset value; after the configuration block consensus is completed, the flag bit may be set to a second preset value. In the consensus process, if the node recognizes that the flag bit is a first preset value, it can determine that the consensus of the configuration block and the switching of the consensus algorithm are currently performed, and then the consensus process after the configuration block can be stopped; if the flag bit is identified as the second preset value, it can be determined that the switching of the consensus algorithm is completed or the switching of the consensus algorithm is not currently performed, and at this time, the block to be consensus can be obtained from the transaction pool for consensus. Due to problems such as network delay and efficiency difference among nodes, all nodes in a cluster may not be able to complete switching of the consensus algorithm at the same time. Thus, the node may receive a consensus message that does not match the consensus algorithm in the present node, thus requiring exception handling.
The node can receive consensus messages from other nodes, wherein the consensus messages have corresponding source nodes and a first version, and the first version is a version of a consensus algorithm adopted by the consensus messages; if the first version is not matched with the second version corresponding to the node, switching exception processing of the consensus algorithm can be performed; the second version is the version of the consensus algorithm currently adopted by the node; and if the first version is matched with the second version corresponding to the node, adopting a consensus algorithm corresponding to the second version to consensus the consensus message. For example, the version of the first consensus algorithm used in the blockchain is 1, the version of the second consensus algorithm is 2, and so on, the currently used version of the consensus algorithm may be identified with a number size. When a node is to broadcast a consensus message to other nodes, the version of the consensus algorithm used by the node may be encapsulated in the consensus message.
The first version and the second version mismatch may include both a first version lower than the second version and a first version higher than the second version. If the first version is lower than the second version, indicating that the common-mode algorithm of the source node is not switched, returning configuration information of the common-mode algorithm corresponding to the second version to the source node, and switching the currently used common-mode algorithm into the common-mode algorithm corresponding to the second version by the source node according to the received configuration information; if the first version is higher than the second version, indicating that the consensus algorithm of the current node is not switched, returning a consensus message to the source node, and receiving configuration information of the consensus algorithm of the first version returned by the source node aiming at the consensus message; and switching the consensus algorithm of the node into the consensus algorithm corresponding to the first version according to the configuration information.
In one possible implementation, a switching module of the consensus algorithm may be deployed in the node, and the switching module may include a consensus layer and an algorithm layer. The consensus layer is used for packaging a specific consensus algorithm. The consensus layer can be provided with a consensus state management component, and the consensus state management component can process abnormal situations of switching of a consensus algorithm. Fig. 2 is a schematic flow chart of exception handling in a handover process of a consensus algorithm according to an embodiment of the present application. As shown in fig. 2, a message processor in a node may process a received message to determine the version of the consensus algorithm used for the message; and then judging whether the version of the consensus algorithm is matched with the current consensus algorithm in the node. If the two are matched, continuing to use an algorithm layer for consensus; if the two are not matched, the message can be forwarded to a consensus state management program in the consensus state management component, and the consensus state management component performs exception handling. The consensus status management component may determine whether the version of the consensus algorithm used by the message is lower than the version of the consensus algorithm currently used by the node. If the version of the consensus algorithm used by the message is lower than the version of the consensus algorithm currently used by the node, the message indicates that the remote node sending the message does not complete the switching of the consensus algorithm. The node can send all the common identification state verification related information from the remote node lag state to the current node state to the remote node; after receiving all the correlation information of the correlation state verifiability from the remote node lag state to the current node state, the lag remote node can switch the correlation algorithm after finishing the correlation verification and the synchronous work. If the version of the consensus algorithm used by the message is higher than the version of the consensus algorithm currently used by the node, the node is indicated to not complete the switching of the consensus algorithm, at the moment, a consensus state synchronization request message can be sent to other nodes through a consensus state management program of a consensus layer, then a consensus state synchronization proving message returned by the other nodes is received, and the consensus state synchronization proving message can comprise all consensus state verification related information from the backward state of the node to the state of the other nodes. After receiving the consensus configuration message, the node can switch the consensus algorithm engine after finishing the related verification and the synchronous work, thereby updating the consensus algorithm of the node to a higher version.
In this embodiment, switching of the consensus algorithm may be implemented based on the configuration transaction. The configuration transaction is independently packed into one configuration block, so that the configuration transaction is not affected by other transactions when being subjected to consensus, and the consensus of other transactions is avoided when the consensus algorithm is switched, thereby ensuring that the consensus of other transactions is not missed. When the configuration block is identified, the embodiment generates the check point information, and confirms that the consensus state of the current node is consistent with other nodes according to the received check point information, thereby ensuring the consistency of the cluster and being beneficial to maintaining the reliability of the blockchain system. The embodiment also provides an exception handling method for switching the consensus algorithm, so that the lagged nodes in the blockchain can timely switch the consensus algorithm, thereby ensuring the safety and flexibility of the blockchain system in the process of switching the consensus algorithm.
Referring to fig. 3, a schematic step flow diagram of a handover method of another consensus algorithm provided in an embodiment of the present application is shown, which may specifically include the following steps:
s301, if a configuration transaction for switching the common algorithm in the blockchain is received, the configuration transaction is packed into the configuration block.
The execution body of the embodiment is a master node of a blockchain, and the master node can package data to be commonly recognized into blocks. When a configuration transaction is received by the master node, the configuration transaction may be individually packaged into a block, which is referred to as a configuration block. The configuration block may have a corresponding identifier, according to which the block may be identified as the configuration block.
S302, packaging the new block to be consensus is stopped.
After identifying the configuration transaction, the master node may cease packaging of the subsequent data to be consensus.
After the configuration block is identified, each node in the block chain needs to switch the consensus algorithm according to the configuration block, and when the consensus algorithm is switched, the consensus process after the configuration block needs to be blocked.
The master node does not package the block to be consensus after the configuration block, and each node in the blockchain does not receive a new block to be consensus after receiving the configuration block before switching the consensus algorithm, which is equivalent to that the node can block the consensus process after the configuration block, so that no algorithm conflict exists during switching the consensus algorithm.
And S303, if the block to be consensus obtained from the transaction pool is a configuration block, generating check point information, wherein the check point information is used for recording the current consensus state of the node.
And S304, if the preset number of other nodes in the block chain are consistent with the current consensus state of the nodes, storing the consensus state into the on-chain data of the block chain.
S305, acquiring a configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched.
S306, switching the current consensus algorithm used by the node into the target consensus algorithm.
S307, initializing the node according to the target consensus algorithm and the consensus state to finish switching of the consensus algorithm on the node.
S303 to S307 of the present embodiment are similar to S101 to S105 of the previous embodiment and are not described in detail herein.
And S308, after the switching of the consensus algorithm in the block chain is completed, continuously packaging the new block to be consensus, and broadcasting the block to be consensus to each node in the block chain, wherein the node is used for consensus on the received block to be consensus by adopting the switched consensus algorithm.
If the configuration block completes the consensus in the blockchain, the blockchain has completed switching of the consensus algorithm, at which point the consensus process may continue. The master node may continue to package the data to be consensus as a block to be consensus and broadcast the block to be consensus to each node, which may continue the consensus process.
In one possible implementation, after identifying the configuration transaction, the master node may set a preset flag bit to a first preset value; after the configuration block consensus is completed, the flag bit may be set to a second preset value. The value of the flag bit may be determined before the master node packs the block to be consensus. If the value of the flag bit is the first preset value, the fact that the consensus of the configuration block is not completed is indicated, and at the moment, the state can be continued to wait for the value of the flag bit to be changed into the second preset value. If the value of the flag bit is a second preset value, the flag bit indicates that the consensus of the configuration block is completed, that is, the block chain has completed switching of the consensus algorithm, at this time, the block to be consensus can be continuously packaged, and broadcast to each node, and after each node receives the block to be consensus, the block to be consensus can be continuously consensus by adopting the consensus algorithm after switching.
In the embodiment, the packaging process of the master node can be blocked, and then the consensus process after the configuration block is blocked, so that algorithm conflict caused by the consensus of the subsequent blocks can be avoided during the switching of the consensus algorithm, and the reliability of the blockchain system is ensured.
It should be noted that, the sequence number of each step in the above embodiment does not mean the sequence of execution sequence, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.
Fig. 4 is a schematic diagram of a switching module of a consensus algorithm according to an embodiment of the present application; as shown in fig. 4, the handover module of the consensus algorithm may include a consensus layer consensus-layer, an algorithm layer algoritm-layer, and a transaction pool txpool-layer. The consensus layer can encapsulate and isolate specific consensus algorithm. The algorithm layer can be specific consensus algorithm logic, and can realize decoupling of transaction distribution and transaction consensus, so that the cluster can complete distribution and local storage of the transaction before a certain batch of transaction consensus. The transaction pool may be used for the node to store all transactions received. The consensus layer may further include a consensus status management component, which may include a consensus status manager, through which the consensus status management component may handle abnormal situations of switching of the consensus algorithm.
The handover module of the consensus algorithm shown in fig. 4 may be deployed into each node of the cluster for completing handover of the consensus algorithm. Fig. 5 is a flowchart of a switching method of another consensus algorithm according to an embodiment of the present application. As shown in fig. 5, the specific flow of algorithm switching may be as follows: a algorithm switch configuration transaction sTx enters the switching module of the consensus algorithm, is first received by the consensus layer and passed to the algorithm layer. The type of the transaction is perceived at an algorithm layer, a master node individually packages the configuration transaction into an algorithm-switched configuration block s-Batch, and then broadcasts the s-Batch to each node in a blockchain; each node, upon receiving s-Batch, may store the s-Batch in a transaction pool.
The cluster may begin consensus of s-Batch until all blocks preceding s-Batch have been consensus completed. At this time, the node may perceive that the block is a special block with changed configuration, switch on the switching state, and block the consensus process after the s-Batch after the node enters the switching state.
In this embodiment, in order to facilitate regular cleaning of the common blocks and periodic checking of the cluster consistency status, each time K blocks are completed or one configuration block is commonly obtained, a checkpoint is generated to record the current node consensus status. Therefore, when the node identifies a special configuration block of the change consensus algorithm, it is also necessary to generate a checkpoint. After the algorithm layer completes the submitting work of the configuration block, the node may broadcast its own checkpoints and collect the checkpoints of the quorum same consensus states at the same time, thereby generating a stable checkpoint stable checkpoint. The execution layer may then perform a uplink process on stable checkpoint, so that the switched consensus algorithm may acquire the execution state of the original algorithm for initialization and perform a subsequent possible verification operation.
After the node finishes the uplink of the checkpoint, the consensus layer directly executes switching operation, namely, the original algorithm is stopped, the consensus algorithm engine is switched, and the new algorithm reads information on the link to initialize. So far, the handover is completed.
The consensus of the s-Batch can ensure that the algorithm switching configuration transaction obtains consistency verification of the cluster; the consensus process of the checkpoint is used for ensuring that the final state is verified to be consistent with the cluster when the original algorithm is stopped.
After the algorithm switch is completed, the state of each node may be as shown in fig. 6. As shown in FIG. 6, the node may continuously obtain batch transactions from the transaction pool to perform consensus, and after identifying the configuration block s-batch, the node may complete switching of the consensus algorithm according to the s-batch. s-batch is the last block of the old consensus algorithm consensus before the consensus algorithm switches; after the switch is completed, a new algorithm may be continued to be used to consensus the batch transaction batch after s-batch.
In this embodiment, all received transactions may be cached in the transaction pool, and the received transactions are stored in the transaction pool, so that the received transactions and the consensus transactions may be asynchronously processed, thereby ensuring the reliability of the blockchain.
The above is a processing flow under an ideal state that a single node normally completes the switching of the consensus algorithm, but due to the problems of network delay, efficiency difference among nodes and the like, it is difficult to realize that all nodes in a cluster complete the flow at the same time to realize the switching of the algorithm. There are two cases when an algorithm switch event occurs: the node in the new algorithm receives the messages of other nodes in the old algorithm; the node in the old algorithm receives messages from other nodes in the new algorithm.
Thus, exception handling is required. Abnormal situation handling may be handled by the consensus layer.
The consensus layer is responsible for further packaging the consensus message and distributing the same to the corresponding algorithm. In this embodiment, there is one and only one algorithm running at the current node at a time. The consensus layer forwards the message to the algorithm layer if and only if the encapsulated consensus message type matches the current consensus algorithm type. Epoch may be used in this embodiment to identify the version of the current consensus configuration.
When the algorithm type of the consensus message received by the consensus layer is not matched with the current node, the epoch of the two nodes can be compared, so that the node in the laggard state is determined. The state management component of the consensus layer of the node may complete the handover-related fall-behind synchronization operation of the consensus algorithm. For example, if the local state is later, the consensus layer initiates the synchronization operation, and the whole synchronization process can be completed by the consensus state management component of the consensus layer until the synchronization is completed, and then the switching operation is executed to complete the algorithm switching; if the correspondent node is backward, the help synchronization message can be sent to the correspondent node by the consensus status management component so that the cluster can quickly reach the consistency status. The switching method in the embodiment ensures the reliability of the block chain. The embodiment does not lose transaction in the process of switching the consensus algorithm, thereby ensuring the reliability of the blockchain system, avoiding the need of manually configuring a new algorithm and ensuring the flexibility of the blockchain system.
The switching method in this embodiment has no additional message overhead, does not need to run two algorithms at the same time, does not need a new protocol, and does not affect the overall consensus flow.
The switching method in the embodiment ensures consistency of cluster states. Since the node has completed the consensus of the configuration transaction and the checkpoints containing the cluster consistency state before the consensus algorithm switches, it can be ensured that the state of the clusters after the switching is consistent.
Referring to fig. 7, a schematic diagram of a switching device of a consensus algorithm provided in an embodiment of the present application is shown, where the device may be applied to a node of a blockchain, and specifically may include a generating module 71, a uplink module 72, an obtaining module 73, a switching module 74, and an initializing module 75, where:
the generating module 71 is configured to generate checkpoint information if the block to be identified acquired from the transaction pool is a configuration block, where the checkpoint information is used to record a current identification state of the node;
the uplink module 72 is configured to store the consensus state into the on-chain data of the blockchain if a preset number of other nodes exist in the blockchain and the current consensus state of the nodes is consistent;
an obtaining module 73, configured to obtain a configuration transaction from the configuration block, where the configuration transaction includes a target consensus algorithm to be switched;
A switching module 74, configured to switch a consensus algorithm currently used by the node to the target consensus algorithm;
and an initialization module 75, configured to initialize the node according to the target consensus algorithm and the consensus state, so as to complete switching of the consensus algorithm on the node.
In one possible implementation manner, if the node is a master node, the apparatus further includes:
the packaging module is used for packaging the configuration transaction into the configuration block if the configuration transaction for switching the common algorithm in the blockchain is received;
and the broadcasting module is used for broadcasting the configuration blocks to all nodes in the block chain, wherein each node is used for switching a consensus algorithm according to the configuration blocks, and each node comprises the master node.
In a possible implementation manner, the master node is configured to package the block to be consensus, and the apparatus further includes:
the blocking and packing module is used for stopping packing the new block to be identified;
and the continuous packaging module is used for continuously packaging the new block to be recognized after the switching of the recognition algorithm in the block chain is completed, broadcasting the block to be recognized to each node in the block chain, and carrying out the recognition on the received block to be recognized by the node through the switched recognition algorithm.
In one possible implementation, the uplink module 72 includes:
a broadcast sub-module for broadcasting the checkpoint information to other nodes in the blockchain;
a receiving sub-module, configured to receive other checkpoint information broadcast by other nodes in the blockchain;
a determination sub-module for determining a first amount of the other checkpoint information received consistent with the checkpoint information status;
the judging submodule is used for determining that other nodes with preset quantity exist in the block chain and are consistent with the current consensus state of the nodes if the first quantity is larger than or equal to a preset value;
a generation sub-module for generating stable checkpoint information according to the checkpoint information;
and the chaining sub-module is used for carrying out data chaining on the stable check point information.
In one possible implementation, the apparatus further includes:
the system comprises a consensus message receiving module, a first version and a second version, wherein the consensus message receiving module is used for receiving a consensus message, and the consensus message is provided with a corresponding source node and the first version which is a version of a consensus algorithm adopted by the consensus message;
the exception handling module is used for performing consensus algorithm switching exception handling if the first version is not matched with the second version corresponding to the node; the second version is the version of the consensus algorithm currently adopted by the node;
And the consensus module is used for consensus the consensus message by adopting a consensus algorithm corresponding to the second version if the first version is matched with the second version corresponding to the node.
In one possible implementation manner, the exception handling module includes:
the first synchronization module is used for returning configuration information of a consensus algorithm corresponding to the second version to the source node if the first version is lower than the second version, and the source node is used for switching the currently used consensus algorithm into the consensus algorithm corresponding to the second version according to the configuration information;
the second synchronization module is used for returning a consensus message to the source node if the first version is higher than the second version, and receiving configuration information of a consensus algorithm of the first version returned by the source node for the consensus message; and switching the consensus algorithm of the node into the consensus algorithm corresponding to the first version according to the configuration information.
In one possible implementation manner, the apparatus further includes:
a continuing acquisition module, configured to continue acquiring the block to be consensus after the configuration block from the transaction pool;
and the continuing consensus module is used for consensus the block to be consensus by adopting the target consensus algorithm.
For the device embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference should be made to the description of the method embodiments.
Fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 8, the computer device 8 of this embodiment includes: at least one processor 80 (only one shown in fig. 8), a memory 81 and a computer program 82 stored in the memory 81 and executable on the at least one processor 80, the processor 80 implementing the steps in any of the various method embodiments described above when executing the computer program 82.
The computer device 8 may be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The computer device may include, but is not limited to, a processor 80, a memory 81. It will be appreciated by those skilled in the art that fig. 8 is merely an example of computer device 8 and is not intended to be limiting of computer device 8, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.
The processor 80 may be a central processing unit (Central Processing Unit, CPU), the processor 80 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 81 may in some embodiments be an internal storage unit of the computer device 8, such as a hard disk or a memory of the computer device 8. The memory 81 may in other embodiments also be an external storage device of the computer device 8, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which are provided on the computer device 8. Further, the memory 81 may also include both an internal storage unit and an external storage device of the computer device 8. The memory 81 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs etc., such as program codes of the computer program etc. The memory 81 may also be used to temporarily store data that has been output or is to be output.
Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps that may implement the various method embodiments described above.
The present embodiments provide a computer program product which, when run on a computer device, causes the computer device to perform the steps that can be carried out in the various method embodiments described above.
The switching method of the consensus algorithm is implemented in the form of a software functional unit and may be stored in a computer readable storage medium when sold or used as a stand alone product. Based on such understanding, the present application implements all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a computer device, a recording medium, computer Memory, read-Only Memory (ROM), random access Memory (RAM, random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in this application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other ways. For example, the apparatus/computer device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting. Although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims (12)

1. A method of switching a consensus algorithm, applied to nodes of a blockchain, the method comprising:
if the block to be consensus obtained from the transaction pool is a configuration block, generating check point information, wherein the check point information is used for recording the current consensus state of the node;
If the preset number of other nodes in the block chain are consistent with the current consensus state of the nodes, storing the consensus state into the on-chain data of the block chain;
acquiring a configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched;
switching the current consensus algorithm used by the node into the target consensus algorithm;
and initializing the node according to the target consensus algorithm and the consensus state to finish switching of the consensus algorithm on the node.
2. The handover method of claim 1, wherein if the node is a master node, the method further comprises:
if a configuration transaction for switching the common algorithm in the blockchain is received, packaging the configuration transaction into the configuration block;
and broadcasting the configuration block to each node in the blockchain, wherein each node is used for switching a consensus algorithm according to the configuration block.
3. The switching method of claim 2, wherein the master node is configured to package the block to be consensus, and after packaging the configuration transaction into the configuration block if a configuration transaction is received for switching a common algorithm in the blockchain, the method further comprises:
Stopping packaging the new block to be consensus;
and after the switching of the consensus algorithm in the block chain is completed, continuously packaging the new block to be consensus, and broadcasting the block to be consensus to each node in the block chain, wherein the node is used for consensus of the received block to be consensus by adopting the switched consensus algorithm.
4. The method of switching of claim 1, wherein storing the consensus state in the on-chain data of the blockchain if there are a predetermined number of other nodes in the blockchain that are consistent with the current consensus state of the node, comprises:
broadcasting the checkpoint information to other nodes in the blockchain;
receiving other checkpoint information broadcast by other nodes in the blockchain;
determining a first amount of the other checkpoint information received consistent with the checkpoint information state;
if the first number is greater than or equal to a preset value, determining that other nodes with preset numbers exist in the blockchain and the current consensus state of the nodes is consistent;
generating stable checkpoint information from the checkpoint information;
and (5) data are uplink to the stable check point information.
5. The handover method according to any one of claims 1-4, wherein the method further comprises:
receiving a consensus message, wherein the consensus message is provided with a corresponding source node and a first version, and the first version is a version of a consensus algorithm adopted by the consensus message;
if the first version is not matched with the second version corresponding to the node, performing consensus algorithm switching exception processing; the second version is the version of the consensus algorithm currently adopted by the node;
and if the first version is matched with the second version corresponding to the node, adopting a consensus algorithm corresponding to the second version to consensus the consensus message.
6. The handover method of claim 5, wherein if the first version does not match a second version corresponding to the node, performing a consensus algorithm handover exception handling; the second version is a version of a consensus algorithm currently adopted by the node, and includes:
if the first version is lower than the second version, returning configuration information of a consensus algorithm corresponding to the second version to the source node, wherein the source node is used for switching the currently used consensus algorithm into the consensus algorithm corresponding to the second version according to the configuration information;
If the first version is higher than the second version, returning a consensus message to the source node, and receiving configuration information of a consensus algorithm of the first version returned by the source node aiming at the consensus message; and switching the consensus algorithm of the node into the consensus algorithm corresponding to the first version according to the configuration information.
7. The handover method according to any one of claims 1-4 or 6, wherein after the initializing the node according to the target consensus algorithm and the consensus status, the method further comprises:
continuing to acquire the block to be consensus after the configuration block from the transaction pool;
and adopting the target consensus algorithm to consensus the block to be consensus.
8. The switching module of the consensus algorithm is characterized by being applied to nodes of a blockchain and comprising a consensus layer, an algorithm layer and a transaction pool; wherein,,
the consensus layer is used for packaging the configuration transaction into a configuration block when receiving the configuration transaction for switching the consensus algorithm in the blockchain;
the algorithm layer is used for broadcasting the configuration block to slave nodes in the blockchain;
and the transaction pool is used for storing the transaction received by the node.
9. The consensus algorithm switching module as recited in claim 8, wherein the consensus layer comprises a consensus management component for handling an abnormal situation of a consensus algorithm switch.
10. A switching apparatus for a consensus algorithm, the apparatus comprising:
the generation module is used for generating check point information if the block to be identified obtained from the transaction pool is a configuration block, wherein the check point information is used for recording the current identification state of the node;
the system comprises a block chain module, a block chain module and a data processing module, wherein the block chain module is used for storing the current consensus state of other nodes with preset quantity in the block chain into the on-chain data of the block chain if the current consensus state of the other nodes is consistent with the preset quantity in the block chain;
the acquisition module is used for acquiring configuration transaction from the configuration block, wherein the configuration transaction comprises a target consensus algorithm to be switched;
the switching module is used for switching the current consensus algorithm used by the node into the target consensus algorithm;
and the initialization module is used for initializing the node according to the target consensus algorithm and the consensus state so as to complete the switching of the consensus algorithm on the node.
11. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1-7 when executing the computer program.
12. A computer readable storage medium storing a computer program, which when executed by a processor implements the method according to any one of claims 1-7.
CN202211082561.1A 2022-09-06 2022-09-06 Switching method and device of consensus algorithm, computer equipment and medium Pending CN116319822A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211082561.1A CN116319822A (en) 2022-09-06 2022-09-06 Switching method and device of consensus algorithm, computer equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211082561.1A CN116319822A (en) 2022-09-06 2022-09-06 Switching method and device of consensus algorithm, computer equipment and medium

Publications (1)

Publication Number Publication Date
CN116319822A true CN116319822A (en) 2023-06-23

Family

ID=86832845

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211082561.1A Pending CN116319822A (en) 2022-09-06 2022-09-06 Switching method and device of consensus algorithm, computer equipment and medium

Country Status (1)

Country Link
CN (1) CN116319822A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117478299A (en) * 2023-12-27 2024-01-30 湖南天河国云科技有限公司 Block chain consensus algorithm switching method, device and computer equipment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117478299A (en) * 2023-12-27 2024-01-30 湖南天河国云科技有限公司 Block chain consensus algorithm switching method, device and computer equipment
CN117478299B (en) * 2023-12-27 2024-03-01 湖南天河国云科技有限公司 Block chain consensus algorithm switching method, device and computer equipment

Similar Documents

Publication Publication Date Title
US7145837B2 (en) Global recovery for time of day synchronization
US7668923B2 (en) Master-slave adapter
US20050081080A1 (en) Error recovery for data processing systems transferring message packets through communications adapters
US20050091383A1 (en) Efficient zero copy transfer of messages between nodes in a data processing system
US11080404B2 (en) Firmware upgrade method, slave station of robot, and machine readable storage medium
CN111683118B (en) Block chain-based consensus method and device, master node equipment and slave node equipment
US20050080869A1 (en) Transferring message packets from a first node to a plurality of nodes in broadcast fashion via direct memory to memory transfer
CN114338651A (en) File transmission method and device, electronic equipment and readable storage medium
US20080313426A1 (en) Information Processing Apparatus and Information Processing Method
CN116319822A (en) Switching method and device of consensus algorithm, computer equipment and medium
CN112650626A (en) Consensus algorithm switching method and device, electronic equipment and storage medium
US20050080920A1 (en) Interpartition control facility for processing commands that effectuate direct memory to memory information transfer
US8055934B1 (en) Error routing in a multi-root communication fabric
CN108228789B (en) Synchronous abnormity recovery method and device triggered by slave node
CN105373563B (en) Database switching method and device
US20050080945A1 (en) Transferring message packets from data continued in disparate areas of source memory via preloading
CN113395348B (en) Vehicle-mounted chip, functional fault checking method and electronic equipment
US20050078708A1 (en) Formatting packet headers in a communications adapter
KR20170117326A (en) Direct memory access control device for at least one processing unit having a random access memory
US7120828B2 (en) System and method for in-order queue draining
CN116009940A (en) Method, device, computer equipment and medium for changing consensus cluster
US20230415757A1 (en) Data processing network for performing data processing
CN115361210A (en) Data processing method and device, electronic equipment and computer readable storage medium
US9509780B2 (en) Information processing system and control method of information processing system
US11663314B2 (en) Method for authenticating an on-chip circuit and associated system on-chip

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination