Semi-synchronous and asynchronous network blockchain consensus switching method and device

Abstract

The application relates to a semi-synchronous and asynchronous network block chain consensus switching method and device, wherein the method comprises the following steps: receiving a consensus switching proposal sent by an administrator, sending the consensus switching proposal to a bottom layer consensus, and judging the output of the bottom layer consensus; if the output is a consensus switching transaction, starting at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus; when any one of the at least one candidate consensus outputs, inputting a locking transaction to the current bottom layer consensus; and when the bottom layer consensus outputs the locking transaction, switching the bottom layer consensus to the corresponding candidate consensus. Therefore, the problems that different consensus algorithms in the consensus module of the consensus switching method are difficult to switch with each other, the consensus switching process is complex, hard forks are easily introduced or the decentralized nature is easily damaged, the consensus algorithm cannot be extended and updated, the applicability range is very small, and the practicability is poor and the like are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and particularly relates to a semi-synchronous and asynchronous network block chain consensus switching method and device. BACKGROUND

[0002] The block chain is a data structure for recording data in the form of a chain table according to time sequence, and relies on cryptographic hash functions and other tools to provide security services for the integrity and non-repudiation of block data. Generally, the content stored in the block is mainly the transaction data of the network within a certain period of time. The consensus mechanism is the basis and core technology of the block chain technology, and determines the way in which all participating nodes in the block chain network reach an agreement on the validity and authenticity of certain specific data (such as transactions, data blocks, etc.), and plays a role in balancing the node state. For most existing consensus protocols, the two requirements of high performance and fault tolerance cannot be met at the same time. Existing research mainly optimizes the communication complexity of the consensus algorithm to improve performance, or improves the security of the algorithm. By designing a consensus switching protocol, the individualized needs of different block chain applications for transaction processing can be met.

[0003] There are mainly four kinds of schemes related to consensus switching in the existing block chain system:

[0004] (1) Execution path switching

[0005] Related researchers have proposed Bolt Dumbo Transformer. The performance of the underlying Dumbo protocol is poor, and a top-level Bolt fast channel is generally used to execute the protocol. If Bolt times out, it will back up to the Transformer and then back up to the pessimistic path of Dumbo. After executing a round, Bolt is restarted again. When the network condition is good, the delay of the semi-synchronous consensus can be achieved.

[0006] The main problem of this scheme is that it can only switch based on the preset execution path to improve the performance of the asynchronous consensus protocol, but it cannot dynamically update the consensus protocol itself according to the dynamic needs of the transaction transaction;

[0007] (2) Stop and restart switching

[0008] The consensus of the domestic self-developed alliance chain Cita chain is disassembled into microservice components, which can support Raft consensus protocol and BFT consensus protocol at the same time, and support node runtime in and out. The main problem of this scheme is that the switching method is to update after shutdown, which causes the service to be interrupted every time the old consensus protocol is switched to the new consensus protocol. And this scheme has only been verified in engineering, and has not been analyzed in theory.

[0009] A consensus switching method and device, and a storage medium are proposed by a related research institution. This method can switch between Raft or MQ consensus protocols in a user-controlled blockchain system. The main problem of this method is that the service needs to be restarted when the consensus switching is completed, which destroys the continuity of the system service.

[0010] (3) Hard fork consensus switching

[0011] Currently, the Ethereum network has realized the switching from PoW consensus to PoS consensus, and this consensus switching process is carried out through hard fork.

[0012] The main problem of using hard fork to switch consensus algorithm is that all nodes need to be manually replaced by the administrator. If it is not replaced in time, it may cause actual chain bifurcation, and then the hard fork promoter (community or influential individual) has obtained the control right of the blockchain network, which destroys the decentralized nature of the blockchain.

[0013] (4) Consensus switching cannot be applied to asynchronous environment

[0014] In addition, some research institutions have also proposed a method that can switch consensus algorithms without stopping. This method has two main problems. First, during the consensus algorithm switching process, transactions cannot be processed, and only pending transactions can be cached. Second, the method needs to be rolled back when the consensus switching fails, returning to processing transactions using the first consensus algorithm. In actual operation, this method judges that the switching fails by the time when the switching is not completed within a certain time. Therefore, this method is not suitable for asynchronous environments.

[0015] Currently, the existing consensus switching scheme has the following three main problems:

[0016] (1) Consensus module decoupling

[0017] In the system module design, different functional components are divided into different modules, and the consensus algorithm is usually decoupled into a consensus module and provides a unified interface to the outside world. However, the above decoupling is a functional decoupling, and different consensus algorithms in the consensus module are independent of each other and do not interact horizontally, so they cannot be switched. For example, the distributed ledger platform Hyperledger Fabric supports three consensus protocols: Solo, Raft, and Kafka. When Fabric starts, it needs to specify which consensus algorithm to choose in the configuration file. Once the system starts, it cannot switch to a new consensus. Only by setting new consensus parameters and restarting Fabric can a new consensus algorithm be replaced, which may cause business processing to be interrupted during the process.

[0018] (2) The consensus switching process is complex, which can easily introduce hard forks or destroy the decentralized nature

[0019] In actual blockchain projects, the switching process of the consensus protocol is very complex, and hard fork or even shutdown and restart is usually used. Using the hard fork method to switch the consensus requires all participating nodes to be manually replaced by node administrators. If it is not replaced in time, the network may have a real fork. The shutdown and restart method requires all nodes to be synchronized and restarted, which means someone can control the network to stop, which destroys the decentralized nature of the blockchain network.

[0020] (3) General switching of asynchronous and semi-synchronous consensus

[0021] Asynchronous consensus and semi-synchronous consensus are consensus working in different network environments. Asynchronous consensus can work in a semi-synchronous environment, but semi-synchronous consensus will lose activity in an asynchronous environment. There are some switching schemes in the academic community that can switch in an asynchronous environment, but the above consensus switching schemes can only be used for consensus algorithms with specific properties and attributes, and have very small applicability and are not practical. In addition, they cannot be extended to update the consensus algorithm. Therefore, due to the different structures of different consensus algorithms and the incompatibility of many sub-functions and definitions of consensus, there is currently no general consensus switching scheme that can work in both asynchronous and semi-synchronous environments.

[0022] In summary, the current consensus switching method has different consensus algorithms in the consensus module that cannot be switched or a complex consensus switching process that can easily introduce hard forks or destroy the decentralized nature, and cannot be extended to update the consensus algorithm, which has very small applicability and poor practicality, and needs to be solved urgently. SUMMARY

[0023] The application provides a semi-synchronous and asynchronous network blockchain consensus switching method and device to solve the problems of the consensus switching method, such as the difficulty of mutual switching of different consensus algorithms in the consensus module, the complexity of the consensus switching process, the easy introduction of hard forks or the destruction of the decentralized nature, the inability to update the consensus algorithm, the small range of applicability, and the poor practicability.

[0024] The first aspect of the application provides a semi-synchronous and asynchronous network blockchain consensus switching method, including the following steps: receiving a consensus switching proposal sent by an administrator, sending the consensus switching proposal to a bottom consensus, and judging the output of the bottom consensus; if the output is a consensus switching transaction, starting at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus; when any one of the at least one candidate consensus outputs, inputting a lock transaction to the current bottom consensus, and when the bottom consensus outputs the lock transaction, switching the bottom consensus to the corresponding candidate consensus.

[0025] Optionally, in one embodiment of the application, if the output is a consensus switching transaction, the at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is started, including: sending the messages in the message cache that meet the preset conditions to the candidate consensus, and deleting the messages from the message cache.

[0026] Optionally, in one embodiment of the application, it further includes: if the output is a lock transaction, obtaining the corresponding candidate consensus according to the candidate consensus output and the evidence in the lock transaction, and judging whether all transactions in the output cache of the candidate consensus are output; if there are unoutput transactions in the output cache of the candidate consensus, outputting the unoutput transactions in the output cache of the candidate consensus.

[0027] Optionally, in one embodiment of the application, it further includes: if the output is a normal transaction and the normal transaction is not output, outputting the normal transaction and deleting the normal proposal corresponding to the normal transaction from the proposal cache.

[0028] Optionally, in one embodiment of the application, when any one of the at least one candidate consensus outputs, a lock transaction is input to the current bottom consensus, including: when any one of the at least one candidate consensus outputs, judging whether the any one candidate consensus is the first output; if the any one candidate consensus is the first output, sending the output content with the output evidence to the bottom consensus to form a lock proposal, and adding the output to the corresponding output cache; if the any one candidate consensus is not the first output, adding the output to the output cache.

[0029] The second aspect embodiment of the present application provides a semi-synchronous and asynchronous network blockchain consensus switching device, comprising: a first judgment module, configured to receive a consensus switching proposal sent by an administrator, and send the consensus switching proposal to a bottom consensus, and judge an output of the bottom consensus; a starting module, configured to start a candidate consensus corresponding to the consensus switching proposal in at least one candidate consensus if the output is a consensus switching transaction; and a switching module, configured to input a locking transaction to the current bottom consensus when any one of the at least one candidate consensus outputs, and switch the bottom consensus to the corresponding candidate consensus when the bottom consensus outputs the locking transaction.

[0030] Optionally, in one embodiment of the present application, the starting module comprises a deletion unit configured to send a message in a message cache that meets a preset condition to the candidate consensus, and delete the message from the message cache.

[0031] Optionally, in one embodiment of the present application, further comprising: a second judgment module, configured to obtain a corresponding candidate consensus according to the candidate consensus output and evidence in the locking transaction if the output is a locking transaction, and judge whether all transactions in an output cache of the candidate consensus are output; and a first output module, configured to output a transaction that has not been output in the output cache of the candidate consensus if the output cache of the candidate consensus exists the transaction that has not been output.

[0032] Optionally, in one embodiment of the present application, further comprising: a second output module, configured to output a normal transaction and delete a normal proposal corresponding to the normal transaction from a proposal cache if the output is a normal transaction and the normal transaction has not been output.

[0033] Optionally, in one embodiment of the present application, the switching module comprises an analysis unit, configured to judge whether any one of the at least one candidate consensus is output for the first time when the any one of the at least one candidate consensus outputs; a first adding unit, configured to send a locking proposal formed by the content of the output and the evidence of the output to the bottom consensus if the any one of the at least one candidate consensus is output for the first time, and add the output to a corresponding output cache; and a second adding unit, configured to add the output to the output cache if the any one of the at least one candidate consensus is not output for the first time.

[0034] The third aspect embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor executes the program to implement the semi-synchronous and asynchronous network blockchain consensus switching method as described in the above embodiments.

[0035] The fourth aspect of the present application provides a computer readable storage medium storing a computer program, which is executed by a processor to implement the semi-synchronous and asynchronous network blockchain consensus switching method as above.

[0036] Therefore, the embodiments of the present application have the following beneficial effects:

[0037] The embodiments of the present application can receive the consensus switching proposal sent by the administrator, send the consensus switching proposal to the underlying consensus, and judge the output of the underlying consensus. If the output is a consensus switching transaction, at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is started. When any one of the at least one candidate consensus outputs, a lock transaction is input to the current underlying consensus. When the underlying consensus outputs the lock transaction, the underlying consensus is switched to the corresponding candidate consensus, so that the general switching between the asynchronous and semi-synchronous consensus can be realized, and the consensus protocol can be upgraded to adapt to the network environment. Therefore, the problems of the consensus switching method that different consensus algorithms in the consensus module are difficult to switch with each other or the consensus switching process is complex, easy to introduce hard fork or destroy the decentralized nature, and unable to extend and update the consensus algorithm, and the scope of applicability is very small, and the practicality is poor, etc. are solved.

[0038] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0039] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, including the accompanying drawings, in which:

[0040] Figure 1 The logic architecture of the semi-synchronous and asynchronous network blockchain consensus switching method of the present application is shown in the figure;

[0041] Figure 2 The flowchart of the semi-synchronous and asynchronous network blockchain consensus switching method according to the embodiments of the present application is shown in the figure;

[0042] Figure 3 The execution logic diagram of the semi-synchronous and asynchronous network blockchain consensus switching method according to an embodiment of the present application is shown in the figure;

[0043] Figure 4 The structure diagram of the semi-synchronous and asynchronous network blockchain consensus switching system according to an embodiment of the present application is shown in the figure;

[0044] Figure 5 The example diagram of the semi-synchronous and asynchronous network blockchain consensus switching device according to the embodiments of the present application is shown in the figure;

[0045] Figure 6 A structural schematic diagram of an electronic device provided by an embodiment of the present application is shown.

[0046] The 10-semi-synchronous and asynchronous network blockchain consensus switching device, the 100-first judgment module, the 200-startup module, the 300-switching module, the 601-memory, the 602-processor, and the 603-communication interface. DETAILED DESCRIPTION

[0047] Embodiments of the present application are described in detail below, examples of which are shown in the accompanying drawings, in which the same or similar reference numerals represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the drawings are exemplary and are intended to explain the present application, and cannot be understood as limiting the present application.

[0048] The semi-synchronous and asynchronous network blockchain consensus switching method and device of the embodiments of the present application are described below with reference to the accompanying drawings. In view of the problems mentioned in the above background art, the present application provides a semi-synchronous and asynchronous network blockchain consensus switching method, in which the consensus switching proposal sent by the administrator is received, the consensus switching proposal is sent to the underlying consensus, and the output of the underlying consensus is judged. If the output is a consensus switching transaction, at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is started. When any one of the at least one candidate consensus outputs, a lock transaction is input to the current underlying consensus, and when the underlying consensus outputs the lock transaction, the underlying consensus is switched to the corresponding candidate consensus. The present application abstracts the function of consensus, decouples the internal of switchable consensus, thereby supporting general consensus switching. Furthermore, the present application can deterministically complete or reject the consensus switching process, and will not cause the bifurcation of the blockchain. In addition, the consensus switching process of the present application is completely performed on the blockchain, and will not destroy the decentralized nature of the blockchain network, thereby realizing the general switching between asynchronous and semi-synchronous consensus, and being able to adapt to the network environment for upgrading the consensus protocol. Thus, the problems of the consensus switching method, such as the difficulty of different consensus algorithms in the consensus module to switch with each other, the complexity of the consensus switching process, the easy introduction of hard forks or the destruction of the decentralized nature, the inability to extend and update the consensus algorithm, the small range of applicability, and the poor practicability, are solved.

[0049] In order to facilitate the introduction of the semi-synchronous and asynchronous network blockchain consensus switching method of the present application, the symbols, assumption conditions, and properties of consensus involved in the semi-synchronous and asynchronous network blockchain consensus switching method of the present application are described herein.

[0050] (1) Symbol definition

[0051] The application uses capital Greek letter Π to represent the switchable consensus protocol; uses lowercase Greek letter π to represent the basic consensus protocol, such as Honey Badger BFT; and uses [] to represent the integer set from 0 to n-1, that is, [n] = 0, 1, …, n-1.

[0052] The consensus introduced in the application can also be referred to as consensus mechanism, consensus algorithm, distributed consistency algorithm, distributed fault tolerance, Byzantine fault tolerance, crash fault tolerance, etc.

[0053] (2) Assumptions

[0054] The semi-synchronous and asynchronous network blockchain consensus switching method of the application can be applied in a semi-synchronous network environment or an asynchronous network environment, therefore, the application needs to meet one of the following assumptions:

[0055] Semi-synchronous assumption: there is an unknown global synchronization time (Global Stabilization Time, GST), before GST, messages can be arbitrarily delayed, and after GST, all messages will be delivered within a known Δ time;

[0056] Asynchronous assumption: the adversary can arbitrarily delay or reorder the messages of honest users, only ensuring that the messages of honest users can eventually reach each other.

[0057] (3) Properties of consensus

[0058] In order to realize the consensus protocol switching method in semi-synchronous and asynchronous network environments, certain restrictions need to be made on the properties of the consensus protocol. The consensus protocol that meets certain properties can be switched using the semi-synchronous and asynchronous network blockchain consensus switching method of the application, and is not limited to a certain specific consensus protocol, therefore the application requires the consensus protocol to have the following properties:

[0059] Property 1 (consistency): consistency includes public prefix and self-consistency:

[0060] Public prefix: assuming that the log output by honest node i is LOG, and the log output by honest node j is LOG ′ , then there must be LOG ′ or LOG ′ < LOG. Where < represents prefix, for any LOG, satisfies and LOG < LOG;

[0061] Self-consistency: if the log output by honest node i at a certain time is LOG, and the log output after a period of time is LOG', then LOG < LOG'.

[0062] Property 2 (liveness):

[0063] If an honest node receives a transaction tx as input, then eventually all honest nodes output a log containing tx.

[0064] Property 3 (verifiable output):

[0065] When a node (possibly malicious) outputs tx, it attaches a proof proof. When a node receives proof, if verify(tx, proof) = 1, then the node can output tx directly (if it has not already outputted tx).

[0066] For PBFT algorithm, proof can be 2f+1 votes of commit round. For Honey-Badger BFT algorithm, proof can be block header containing tx, Merkle tree proof and a certain amount of block headers following tx.

[0067] Among the three basic properties of the underlying consensus described above, consistency and liveness are general properties of consensus protocols; although the verifiable output property is not a general property of consensus protocols, almost all blockchain consensus mechanisms actually have this property.

[0068] The switchable consensus protocol Π in the present application contains a series of consensus protocol instances {π i |i∈[N]}, Π controls the working and switching process of consensus protocols, and each node's underlying consensus protocol π does not directly interact with each other, but interacts through the Π of the node, π obtains messages from Π, and sends outputs to Π, and then outputs by Π. For any i∈[N], assume that the protocol π i satisfies the above consistency, liveness and verifiable output properties, the running of Π is divided into epochs, and one consensus protocol is run in each epoch, and there can be multiple candidate instances of the next epoch. The instance consensus running in the epoch can be represented as As shown in the following formula: Figure 1 wherein, is the underlying consensus currently running; bufin is the proposal buffer, which saves the normal messages that have been input but have not been output; bufmsg is the message buffer, which saves the messages that have not been started by the current receiver; CANDI is the candidate underlying consensus set of the next epoch started after receiving a valid consensus switching proposal and the output buffer bufout corresponding to each candidate consensus, that is, Wherein cnt represents the candidate consensus number of epoch+1 that has been started. Epoch has a unique number starting from 0. There are several rounds in each epoch, and each round in each round has a unique number starting from 0.

[0069] In addition, the consensus protocol in the present application supports three types of transactions: consensus switching transactions, locking transactions, and ordinary transactions; and supports four types of messages: consensus switching proposal messages, locking proposal messages, ordinary proposal messages, and ordinary messages. In the process of consensus for consensus switching transactions, the present application assumes that the specific instance of the underlying consensus π to which the ordinary transaction message needs to be sent can be determined according to the message itself.

[0070] Specifically, Figure 2 A flowchart of a semi-synchronous and asynchronous network blockchain consensus switching method provided by an embodiment of the present application.

[0071] As Figure 2 shown, the semi-synchronous and asynchronous network blockchain consensus switching method includes the following steps:

[0072] In step S201, a consensus switching proposal sent by an administrator is received, and the consensus switching proposal is sent to the underlying consensus, and the output of the underlying consensus is determined.

[0073] The embodiment of the present application first initializes each node to the instance of the corresponding switchable consensus Π, and sets epoche = 0. The switchable consensus Π of all nodes is initialized to the same consensus underlying consensus π.

[0074] It should be noted that the embodiment of the present application assumes that only one administrator can send a consensus switching proposal. The administrator serves as a role in the embodiment of the present application, and in practice, it can also be composed of a certain threshold of nodes to issue a switch proposal that can be verified. Specifically, it can be a certain person, an intelligent contract, or a group of voting results, etc. For example, in a consortium chain environment, the administrator can be jointly played by several enterprises, and in a public chain environment, it can be a pre-designed intelligent contract, a community voting decision, etc. In the embodiment of the present application, only the consensus switching proposal sent by the administrator can be verified by all nodes.

[0075] When the administrator sends a consensus switching proposal, in the embodiment of the present application, the switchable consensus can receive the consensus switching proposal sent by the administrator, and then the embodiment of the present application can receive the message sent from the administrator and other nodes through the underlying consensus, and analyze and judge the type of the received message:

[0076] 1. When the underlying consensus receives a consensus switch proposal message <consensus-update-propose>When the consensus switching proposal message is sent to the underlying consensus currently running by the node

[0077] 2、When the underlying consensus receives the ordinary proposal message <propose>At this time, the underlying consensus can add the ordinary proposal into an input buffer bufin, and send the ordinary proposal to the current underlying consensus of the node and all the consensus in CANDI;

[0078] 3、When the underlying consensus receives the ordinary message <other>At this time, the underlying consensus can judge whether the receiver of the message has started and not stopped according to the content of the message, if yes, the message is sent to the corresponding receiver, otherwise, the epoch to which the message belongs is judged, if e ′ ≥ e, the message is added to msgbuf, otherwise the message is discarded.

[0079] It should be noted that in the embodiments of the present application, since the lock proposal message <lock-propose>That is, the message proposing the locking transaction is generated by the underlying consensus, so the underlying consensus does not receive the locking proposal message.

[0080] It can be understood that when the underlying consensus receives the consensus switching proposal message and outputs the transaction, the embodiments of the present application can broadcast the output and the proof to all nodes through Π, the receiver is specified as the corresponding underlying consensus instance, and the embodiments of the present application need to judge the type of the transaction, thereby providing a basis for subsequent semi-synchronous and asynchronous network blockchain consensus switching.

[0081] In step S202, if the output is a consensus switching transaction, start a candidate consensus corresponding to the consensus switching proposal in at least one candidate consensus.

[0082] When receiving the output of the underlying consensus of the current epoch , the embodiments of the present application can judge the type of the output transaction. When the current consensus outputs a consensus switching transaction, the embodiments of the present application can start a candidate consensus according to the consensus switching proposal, as shown in Figure 3 When any one of the candidate consensus outputs, a locking transaction containing the output and the proof of the candidate consensus is input into the current consensus.

[0083] In the embodiments of the present application, the above-mentioned consensus switching transaction should contain certain configuration information, and the configuration information needs to ensure the security of the consensus. For example, the configuration information of the committee consensus should contain the members of the committee, and the proportion of malicious nodes should have an upper limit.

[0084] It can be understood that the embodiments of the present application effectively solve the problem that the candidate consensus proposed by the administrator node at a single time may not run normally by using a candidate consensus set instead of a single candidate consensus.

[0085] Optionally, in an embodiment of the present application, if the output is a consensus switching transaction, a candidate consensus corresponding to the consensus switching proposal in at least one candidate consensus is started, including: sending the messages in the message cache that meet the preset conditions to the candidate consensus, and deleting the messages from the message cache.

[0086] Those skilled in the art can understand that, in an asynchronous environment, all honest nodes cannot start the consensus protocol synchronously, and there are problems such as that a node has not started a new consensus, and a new consensus message has already arrived. Therefore, the embodiments of the present application design a message cache to store the consensus messages that have not been started temporarily, so as to meet the asynchronous assumption (the message can be delayed indefinitely, but will not be discarded).

[0087] Therefore, when any one of the candidate consensus outputs, the embodiments of the present application can initialize the output cache as If there are messages in the message cache msgbuf with the specified receiver as the candidate consensus, the messages are sent to the candidate consensus and deleted from the message cache msgbuf.

[0088] Thus, the embodiments of the present application solve the problem of consensus messages arriving earlier than consensus starting in semi-synchronous and asynchronous networks by using the message cache, and thus can be applied to poor network environments.

[0089] Optionally, in an embodiment of the present application, if the output is a locked transaction, the corresponding candidate consensus is obtained according to the candidate consensus output and evidence in the locked transaction, and it is determined whether all transactions in the output cache of the candidate consensus are output; if there are unoutput transactions in the output cache of the candidate consensus, the unoutput transactions in the output cache of the candidate consensus are output.

[0090] It should be noted that if the output of the underlying consensus of the current epoch is a locked transaction, the locked transaction should contain the first round output of the next consensus, and the embodiments of the present application can find the corresponding candidate consensus according to the candidate consensus output and evidence contained in the locked transaction. For all transactions in the candidate consensus bufout, if they have not been output before, they are output and deleted from bumin, and then the candidate consensus is set as the underlying consensus of epoch+1. Meanwhile, the number of the epoch is increased by 1. For all transactions in bumin, they are re-proposed to all messages in msgbuf with the epoch number less than or equal to e are deleted, and the consensus switching is completed.

[0091] Optionally, in an embodiment of the present application, if the output is a normal transaction and the normal transaction has not been output, the normal transaction is output and the normal proposal corresponding to the normal transaction is deleted from the proposal cache.

[0092] In actual execution, if the output transaction of the underlying consensus of the current epoch is a normal transaction and the transaction has not been output before, the transaction is output and the corresponding proposal is deleted from bumin.

[0093] In step S203, when any one of the at least one candidate consensus outputs, a locked transaction is input to the current underlying consensus, and when the underlying consensus outputs the locked transaction, the underlying consensus is switched to the corresponding candidate consensus.

[0094] When any one of the candidate consensus inputs a locked transaction to the current underlying consensus, when the underlying consensus outputs the first locked transaction, the embodiments of the present application can switch the consensus, and switch the underlying consensus to the corresponding candidate consensus.

[0095] It can be understood that the embodiments of the present application can realize dynamic smooth hot switching of blockchain consensus in a semi-synchronous or asynchronous network. Compared with a consensus protocol that only supports path switching, the embodiments of the present application can completely switch the consensus protocol, provide an interface for consensus switching in the future, and complete switching when a better consensus protocol selection appears. Compared with a consensus protocol switching method based on shutdown and restart, the embodiments of the present application can complete consensus switching without stopping the system. Compared with a consensus switching method based on hard fork, the consensus switching method provided by the embodiments of the present application has no risk of running fork and does not damage the integrity of the system.

[0096] Optionally, in an embodiment of the present application, when any one of the at least one candidate consensus outputs, a lock transaction is input to the current underlying consensus, comprising: when any one of the at least one candidate consensus outputs, it is judged whether the any one candidate consensus is the first output; if the any one candidate consensus is the first output, the output content is attached to the evidence of the output to form a lock proposal, which is sent to the underlying consensus, and the output is added to the corresponding output cache; if the any one candidate consensus is not the first output, the output is added to the output cache.

[0097] It should be noted that in the embodiments of the present application, when the candidate consensus of epoch+1 outputs, since only ordinary proposals have been proposed to it, it can only output ordinary transactions.

[0098] If it is the first output, the output content is attached to the evidence of the output to form a lock proposal to Π, and the output is added to the corresponding bufout, otherwise only the output is added to bufout.

[0099] In actual execution process, the embodiments of the present application can unify the blockchain consensus switching method in semi-synchronous network environment and the consensus switching method in synchronous network environment, so that switching between semi-synchronous consensus protocol and asynchronous consensus protocol can be realized. When the network condition is relatively good, the semi-synchronous consensus protocol can be switched to obtain higher work efficiency, and when the network condition is very poor, the asynchronous consensus protocol can be used to ensure the progress of consensus switching in the worst case.

[0100] Further, the semi-synchronous and asynchronous network blockchain consensus switching system in the embodiments of the present application as a whole comprises three modules, as shown in Figure 4 application module, storage module and consensus module, which are described as follows:

[0101] (1) Application module

[0102] The application module is a service layer of the blockchain, and is used to specifically execute transactional transactions. An externally entered transaction is first sent to the application module, and then the application module notifies the consensus module to reach consensus on the transaction. The completed consensus transaction is sent by the consensus module to the application module for execution in a blockchain virtual machine. The application module relies on the storage module to provide storage of state data, and the application module provides a service for the consensus module to verify the validity of a transaction. The application module and the consensus module interact using an application blockchain interface (ABCI) based on gRPC.

[0103] (2) Storage module

[0104] The storage module is a key-value type database that supports data persistence. The storage module is used to save state data of the application layer and transaction data used by the consensus module.

[0105] (3) Consensus module

[0106] The consensus module is used to reach consensus on transactions. A bottom-layer consensus and 0 or more candidate consensuses are simultaneously run in the consensus module, and the bottom-layer consensus and the candidate consensuses interact through a pipeline-based ABCI.

[0107] The ABCI uses three connections, namely a consensus connection, a memory pool connection, and an information connection. The consensus connection includes five requests, namely InitChain, BeginBlock, DeliverTx, EndBlock, and Commit. The memory pool connection includes one request, CheckTx. The information connection includes three requests, namely Info, SetOption, and Query.

[0108] When the consensus module receives a memory pool request or an information request from the bottom-layer consensus or the candidate consensus, the request is directly forwarded to the application module, and the reply is forwarded to the requester.

[0109] When the InitChain, BeginBlock, EndBlock, and Commit requests of the bottom-layer consensus are received, the requests are directly sent to the application module. When the DeliverTx request of the bottom-layer consensus is received, the request can be processed in the above manner. If the transaction needs to be submitted, the DeliverTx request is forwarded to the application module.

[0110] When receiving the InitChain, BeginBlock, EndBlock request of the candidate consensus, only record the information, and do not forward the request. When receiving the DeliverTx request of the candidate consensus, cache the tx in the candidate consensus, and when receiving the Commit request of the candidate consensus, record the committed transaction, generate a locking transaction, and send it to the current underlying consensus.

[0111] According to the semi-synchronous and asynchronous network blockchain consensus switching method proposed in the embodiments of the present application, the consensus switching proposal sent by the administrator is received, the consensus switching proposal is sent to the underlying consensus, and the output of the underlying consensus is judged. If the output is a consensus switching transaction, the candidate consensus corresponding to the consensus switching proposal in at least one candidate consensus is started. When any one of the at least one candidate consensus outputs, a locking transaction is input to the current underlying consensus, and when the underlying consensus outputs the locking transaction, the underlying consensus is switched to the corresponding candidate consensus. The present application abstracts the function of consensus, decouples the internal of switchable consensus, thereby supporting general consensus switching. Furthermore, the present application can determine the completion or rejection of the consensus switching process, and will not cause the forking of the blockchain. In addition, the consensus switching process of the present application is completely carried out on the blockchain, and will not damage the decentralized nature of the blockchain network, thereby realizing the general switching between asynchronous and semi-synchronous consensus, and being able to adapt to the upgrading of the consensus protocol in the network environment.

[0112] Secondly, the semi-synchronous and asynchronous network blockchain consensus switching device proposed according to the embodiments of the present application is described with reference to the accompanying drawings.

[0113] Figure 5 is a block diagram of the semi-synchronous and asynchronous network blockchain consensus switching device of the embodiments of the present application.

[0114] As Figure 5 shown, the semi-synchronous and asynchronous network blockchain consensus switching device 10 includes a first judgment module 100, a starting module 200, and a switching module 300.

[0115] The first judgment module 100 is configured to receive the consensus switching proposal sent by the administrator, send the consensus switching proposal to the underlying consensus, and judge the output of the underlying consensus.

[0116] The starting module 200 is configured to start the candidate consensus corresponding to the consensus switching proposal in at least one candidate consensus if the output is a consensus switching transaction.

[0117] The switching module 300 is configured to input a locking transaction to the current underlying consensus when any one of the at least one candidate consensus outputs, and switch the underlying consensus to the corresponding candidate consensus when the underlying consensus outputs the locking transaction.

[0118] Optionally, in an embodiment of the present application, the starting module 200 comprises a deleting unit configured to send the message in the message cache satisfying the preset condition to the candidate consensus and delete the message from the message cache.

[0119] Optionally, in an embodiment of the present application, the semi-synchronous and asynchronous network blockchain consensus switching device 10 of the embodiment of the present application further comprises a second judging module and a first output module.

[0120] The second judging module is configured to, if the output is a lock transaction, obtain the corresponding candidate consensus according to the candidate consensus output and the evidence in the lock transaction, and judge whether all transactions in the output cache of the candidate consensus are output.

[0121] The first output module is configured to, if there is a transaction not output in the output cache of the candidate consensus, output the transaction not output in the output cache of the candidate consensus.

[0122] Optionally, in an embodiment of the present application, the semi-synchronous and asynchronous network blockchain consensus switching device 10 of the embodiment of the present application further comprises a second output module configured to, if the output is a normal transaction and the normal transaction is not output, output the normal transaction and delete the normal proposal corresponding to the normal transaction from the proposal cache.

[0123] Optionally, in an embodiment of the present application, the switching module 300 comprises an analyzing unit, a first adding unit and a second adding unit.

[0124] The analyzing unit is configured to, when any one of the at least one candidate consensus is output, judge whether the any one candidate consensus is first output.

[0125] The first adding unit is configured to, if the any one candidate consensus is first output, send the lock proposal composed of the output content and the evidence of the output to the underlying consensus, and add the output to the corresponding output cache.

[0126] The second adding unit is configured to, if the any one candidate consensus is not first output, add the output to the output cache.

[0127] It should be noted that the foregoing explanation and description of the semi-synchronous and asynchronous network blockchain consensus switching method embodiment are also applicable to the semi-synchronous and asynchronous network blockchain consensus switching device of the embodiment, which will not be described here.

[0128] The semi-synchronous and asynchronous network blockchain consensus switching device provided by the embodiment of the application receives the consensus switching proposal sent by the administrator, sends the consensus switching proposal to the underlying consensus, and judges the output of the underlying consensus; if the output is a consensus switching transaction, at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is started; when any one of the at least one candidate consensus outputs, a lock transaction is input to the current underlying consensus, and when the underlying consensus outputs the lock transaction, the underlying consensus is switched to the corresponding candidate consensus. The application can support the general consensus switching by abstracting the function of the consensus and decoupling the internal part of the switchable consensus, and then the application can determine the completion or rejection of the consensus switching process, and will not cause the bifurcation of the blockchain. In addition, the consensus switching process of the application is completely carried out on the blockchain, and will not damage the decentralized nature of the blockchain network, so that the general switching between the asynchronous and semi-synchronous consensus can be realized, and the network environment can be adapted to upgrade the consensus protocol.

[0129] Figure 6 The structure schematic diagram of the electronic device provided by the embodiment of the application is provided. The electronic device can include:

[0130] The memory 601, the processor 602 and the computer program stored in the memory 601 and executable on the processor 602.

[0131] The processor 602 implements the semi-synchronous and asynchronous network blockchain consensus switching method provided in the above embodiment when executing the program.

[0132] Further, the electronic device further includes:

[0133] The communication interface 603 is used for communication between the memory 601 and the processor 602.

[0134] The memory 601 is used to store the computer program executable on the processor 602.

[0135] The memory 601 can include a high-speed RAM memory, and can also include a non-volatile memory, for example, at least one disk memory.

[0136] If the memory 601, the processor 602 and the communication interface 603 are implemented independently, the communication interface 603, the memory 601 and the processor 602 can be connected with each other through a bus and complete communication between each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For convenience of representation, Figure 6 Only one thick line is used to represent the bus in the figure, but it does not mean that there is only one bus or only one type of bus.

[0137] Optionally, in a specific implementation, if the memory 601, the processor 602 and the communication interface 603 are integrated on a chip, the memory 601, the processor 602 and the communication interface 603 can complete communication between each other through an internal interface.

[0138] The processor 602 can be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0139] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program, and the program is executed by a processor to implement the semi-synchronous and asynchronous network block chain consensus switching method as above.

[0140] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example" or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples without contradiction.

[0141] Moreover, the terms "first", "second", etc. are used herein only to describe different instances, and do not imply or suggest relative importance or a number of indicated technical features. Thus, features defined with "first", "second" can include at least one of such features, either explicitly or implicitly. In the description of the present application, the meaning of "N" is at least two, for example two, three, etc., unless otherwise explicitly and specifically limited.

[0142] Any process or method descriptions or blocks in flow charts herein, and elsewhere, can be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the preferred embodiments of the present application in which additional functionality can be added or some functionality can be removed, by, for example, adding one or more steps performing a similar or reciprocal function, combining two or more steps into a single step, or splitting one step into two or more steps.

[0143] The logic and / or steps represented in flow charts herein, and elsewhere, can be considered as a sequence of executable instructions, for implementing logical functions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For purposes of this specification, a "computer-readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can specifically include a hardware apparatus (e.g., an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CDROM)). Additionally, the computer-readable medium can be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via an optical scanner, then compiled, interpreted, or otherwise processed, and stored upon a computer memory in order to be executed.

[0144] It should be understood that parts of the present application can be realized in hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be realized by software or firmware stored in a memory and executed by a suitable instruction execution system. If realized in hardware and in another embodiment, any one or a combination of the following technologies known in the art can be used: discrete logic circuit with logic gate circuit for implementing logic functions on data signals, application specific integrated circuit with suitable combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA), etc.

[0145] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment methods can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0146] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The above-mentioned integrated module can be realized in the form of hardware or in the form of a software functional module. The integrated module, if realized in the form of a software functional module and sold or used as an independent product, can also be stored in a computer readable storage medium.

[0147] The above-mentioned storage medium can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application. < / other> < / propose>

Claims

1. A method for switching consensus in semi-synchronous and asynchronous network blockchains, characterized in that, Includes the following steps: Receive a consensus switching proposal sent by the administrator, send the consensus switching proposal to the underlying consensus, and determine the output of the underlying consensus; If the output is a consensus switching transaction, then at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is started; When any one of the at least one candidate consensus outputs, a locking transaction is input into the current underlying consensus. When the underlying consensus outputs the locking transaction, the underlying consensus is switched to the corresponding candidate consensus.

2. The method according to claim 1, characterized in that, If the output is a consensus switching transaction, then at least one candidate consensus corresponding to the consensus switching proposal in the candidate consensus is initiated, including: Messages that meet preset conditions in the message cache are sent to the candidate consensus, and the messages are deleted from the message cache.

3. The method according to claim 1, characterized in that, Also includes: If the output is a locked transaction, then the corresponding candidate consensus is obtained based on the candidate consensus output and evidence in the locked transaction, and it is determined whether all transactions in the output cache of the candidate consensus are output; If there are unoutputted transactions in the output cache of the candidate consensus, then the unoutputted transactions in the output cache of the candidate consensus are output.

4. The method according to claim 1, characterized in that, Also includes: If the output is a normal transaction, and the normal transaction has not been output, then the normal transaction is output, and the normal proposal corresponding to the normal transaction is deleted from the proposal cache.

5. The method according to claim 1, characterized in that, When any one of the at least one candidate consensus outputs, a locking transaction is input into the current underlying consensus, including: When any one of the at least one candidate consensus is output, determine whether the candidate consensus is the first output; If any of the candidate consensuses is the first output, then the content of the output, along with the evidence of the output, constitutes a locking proposal and is sent to the underlying consensus, and the output is added to the corresponding output cache; If any of the candidate consensuses is not the first output, then the output is added to the output cache.

6. A semi-synchronous and asynchronous network blockchain consensus switching device, characterized in that, include: The first judgment module is used to receive the consensus switching proposal sent by the administrator, send the consensus switching proposal to the underlying consensus, and judge the output of the underlying consensus; The startup module is configured to, if the output is a consensus switching transaction, start at least one candidate consensus corresponding to the consensus switching proposal among the candidate consensuses; The switching module is used to input a locking transaction into the current underlying consensus when any one of the at least one candidate consensus outputs, and to switch the underlying consensus to the corresponding candidate consensus when the underlying consensus outputs the locking transaction.

7. The apparatus according to claim 6, characterized in that, The startup module includes: The deletion unit is used to send messages that meet preset conditions in the message cache to the candidate consensus and delete the messages from the message cache.

8. The apparatus according to claim 6, characterized in that, Also includes: The second judgment module is used to determine whether all transactions in the output cache of the candidate consensus are output if the output is a locked transaction. The first output module is configured to output the unoutput transactions in the output cache of the candidate consensus if there are unoutput transactions in the output cache of the candidate consensus.

9. The apparatus according to claim 6, characterized in that, Also includes: The second output module is used to output the ordinary transaction and delete the ordinary proposal corresponding to the ordinary transaction from the proposal cache if the output is an ordinary transaction and the ordinary transaction has not been output.

10. The apparatus according to claim 6, characterized in that, The switching module includes: The analysis unit is used to determine whether any one of the at least one candidate consensus is being output for the first time when any one of the candidate consensuses is output. The first adding unit is configured to, if any candidate consensus is the first output, send the content of the output along with the evidence of the output to the underlying consensus to form a locking proposal, and add the output to the corresponding output cache; The second adding unit is used to add the output to the output buffer if any candidate consensus is not the first output.

11. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the semi-synchronous and asynchronous network blockchain consensus switching method as described in any one of claims 1-5.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the semi-synchronous and asynchronous network blockchain consensus switching method as described in any one of claims 1-5.

Images