Improving liveness in consensus protocols

Abstract

Various aspects of the technologies described herein relate to systems, methods, and machine-readable media for enhancing liveness within a blockchain. These aspects may include operating a first consensus protocol. The aspects may also include detecting liveness attacks within the first consensus protocol. The aspects may also include suspending the acceptance of new blocks into the first consensus protocol when a liveness attack is detected. The aspects may also include broadcasting a preferred block and, based on the preferred block, operating the first consensus protocol to identify the block with the highest acceptance rate in a set of nodes. The aspects may also include transitioning from the first consensus protocol to a second consensus protocol and operating the second consensus protocol until a consensus value or newly accepted block is determined. The aspects may also include restoring the first consensus protocol based on the newly accepted block and resuming operation of the first consensus protocol.

Description

[Technical Field]

[0001] Cross-reference of related applications This disclosure relates to and claims priority to U.S. Provisional Patent Application No. 63 / 490,153, filed on 14 March 2023, entitled “LIVENESS IN CONSENSUS PROTOCOL,” by Stephen BUTTOLPH et al., the contents of which are incorporated herein by reference in their entirety for all purposes.

[0002] This disclosure generally concerns a migration protocol for blockchain implementations. More specifically, this disclosure concerns a method for migrating between blockchain consensus protocols when the liveness of a consensus protocol is compromised. [Background technology]

[0003] A blockchain is a database that maintains a record of transactions and tracks assets within a block. A blockchain network includes nodes such as validator nodes that participate in consensus. Validator nodes can not only verify, vote, stake, and / or maintain a record of transactions for the blockchain network, but can also store copies of the blockchain. Validators are also responsible for generating and / or proposing blocks to be added to the blockchain network. Validators can participate in consensus voting protocols for implementing blockchain deployments or building on subnets. Factors such as the liveness and security of the consensus mechanism of a blockchain network can be considered and evaluated in various ways depending on the blockchain. The liveness of the consensus mechanism represents the guarantee that the protocol allows messages to be exchanged between nodes of the blockchain network and that nodes can eventually reach consensus. The security of the consensus mechanism represents the guarantee that the consensus or value between nodes is consistent across all nodes of the blockchain network. [Overview of the Initiative]

[0004] The subject matter disclosure provides a system and method for enhancing liveness in a blockchain network that operates a consensus protocol by implementing a transition protocol. In one embodiment, while the existing consensus protocol may have guaranteed security, liveness may be vulnerable to attack at some point. Therefore, the embodiment enables a seamless transition between the existing consensus protocol and a backup high-security-high-liveness protocol. According to the embodiment, once liveness is restored, the system switches back to the initial protocol until another liveness attack is detected.

[0005] According to the embodiment, a computer implementation method for transitioning in a consensus protocol is provided. The method includes running a first consensus protocol on a set of nodes in a blockchain network. The method includes detecting a liveness attack in the first consensus protocol on a node in the set of nodes. The method includes suspending the acceptance of new blocks into the first consensus protocol when a liveness attack is detected. The method includes identifying the highest-accepted block in the set of nodes from running the first consensus protocol. The method includes setting initial basic settings for a second consensus protocol on the highest-accepted block. The method includes transitioning to the second consensus protocol. The method includes determining the consensus value of a newly accepted block based on running the second consensus protocol on the set of nodes.

[0006] According to one embodiment, a system is provided, which includes a processor and a memory containing instructions stored therein, wherein when an instruction is executed by the processor, the processor causes the processor to implement a method for implementing a transition protocol. The method includes operating a first consensus protocol in a set of nodes of a blockchain network. The method also includes detecting a liveness attack in the first consensus protocol at a node in the set of nodes. The method also includes suspending the acceptance of new blocks into the first consensus protocol when a liveness attack is detected. The method also includes identifying the highest-accepted block in the set of nodes from operating the first consensus protocol based on preferred blocks. The method also includes setting initial basic settings for a second consensus protocol at the highest-accepted block. The method also includes transitioning from the first consensus protocol to the second consensus protocol. The method also includes determining the consensus value of a newly accepted block based on operating the second consensus protocol in the set of nodes.

[0007] According to the embodiment, a non-temporary computer-readable storage medium is provided containing instructions (e.g., a sequence of stored instructions), which, when executed by a processor, cause the processor to implement a method for implementing a transition protocol. The method includes operating a first consensus protocol in a set of nodes of a blockchain network. The method also includes detecting a liveness attack in the first consensus protocol at a node in the set of nodes. The method also includes suspending the acceptance of new blocks into the first consensus protocol when a liveness attack is detected. The method also includes identifying the highest-accepted block in the set of nodes from operating the first consensus protocol based on preferred blocks. The method also includes setting initial basic settings for a second consensus protocol in the highest-accepted block. The method also includes transitioning from the first consensus protocol to the second consensus protocol, which operates until a newly accepted block is confirmed. This method also includes restoring the first consensus protocol based on the confirmation of newly accepted blocks, the first consensus protocol being restored from the newly accepted block onward.

[0008] According to the embodiment, a computer implementation method for transitioning in a consensus protocol is provided. The method may include means for running a first consensus protocol in a set of nodes of a blockchain network. The method may include means for detecting a liveness attack in the first consensus protocol at a node in the set of nodes. The method may include means for suspending the acceptance of new blocks into the first consensus protocol when a liveness attack is detected. The method may include means for identifying the highest-accepted block in the set of nodes from running the first consensus protocol. The method may include means for setting initial basic settings for a second consensus protocol in the highest-accepted block. The method may include means for transitioning to the second consensus protocol. The method may include means for determining the consensus value of a newly accepted block based on running the second consensus protocol in the set of nodes.

[0009] Other configurations of the subject art will be readily apparent to those skilled in the art from the following detailed description, where various configurations of the subject art are illustrated and described by example. As should be understood, other different configurations of the subject art are possible, and some of their details can be modified in various other respects, all without departing from the scope of the subject art. Therefore, the drawings and detailed description should be considered illustrative and not restrictive. [Brief explanation of the drawing]

[0010] The accompanying drawings, included to provide further understanding and incorporated herein, and constituting part of herein, illustrate the disclosed embodiments and, together with the specification, help to illustrate the principles of the disclosed embodiments. The drawings are as follows:

[0011] [Figure 1]This is a block diagram of a device operating environment that can implement the embodiments of this disclosure. [Figure 2] This is a block diagram of a consensus protocol that implements a transition mechanism in a blockchain platform / network, according to a specific aspect of this disclosure. [Figure 3] A system configured to process a transition protocol, according to a particular aspect of this disclosure, is illustrated as an example. [Figure 4] This is an exemplary flowchart for enhancing liveness within a consensus protocol, according to a particular aspect of this disclosure. [Figure 5] This is a block diagram illustrating an exemplary computer system capable of implementing aspects of the subject technology.

[0012] Not all components depicted in each figure are necessarily required in one or more implementations, and one or more implementations may include additional components not shown in the figures. The arrangement and types of components may be changed without departing from the scope of this disclosure. Additional components, different components, or fewer components may be used within the scope of the disclosure. [Modes for carrying out the invention]

[0013] The following detailed description includes many specific details in order to provide a complete understanding of the disclosure. However, it will be apparent to those skilled in the art that embodiments of the disclosure can be practiced without some of these specific details. In other examples, well-known structures and techniques are not shown in detail so as not to obscure the disclosure.

[0014] The detailed descriptions provided below illustrate various configurations of the subject art and are not intended to represent only the configurations in which the subject art can be practiced. The detailed descriptions include specific details for the purpose of providing a complete understanding of the subject art. Therefore, dimensions may be provided for certain embodiments as non-limiting examples. However, it will be apparent to those skilled in the art that the subject art can be practiced without these specific details. In some examples, well-known structures and components are shown in block diagrams to avoid obscuring the concepts of the subject art.

[0015] General Overview Blockchain platforms, such as those for smart contracts, may require a consensus protocol as a fundamental building block for constructing decentralized systems. For example, a blockchain platform may include multiple blockchains, such as a component exchange blockchain for creating and trading digital smart assets, a metadata blockchain for coordinating validators and tracking and creating subnets, and a contract blockchain for creating smart contracts. As used herein, a subnet or subnetwork comprises a dynamic set of nodes (e.g., one or more validators) seeking to achieve consensus on the state of a set of blockchains, so that one blockchain is validated by one subnet, but one subnet can validate multiple blockchains. Nodes can participate in validating multiple subnets and may be subject to the requirements of the blockchains within those subnets for security, licensing, hardware, etc. The blockchains validated by validators may belong to a blockchain network (or platform) with application-level logic defined by multiple virtual machines (VMs), enabling a more decentralized network. Specifically, a blockchain may be an instance of a VM specifying the blockchain's state, state transition functionality, transactions, and application programming interfaces (APIs) for user interaction. VMs enable the execution of smart contracts and decentralized applications on the blockchain, provide a secure and deterministic environment for code execution, and enable interoperability between blockchains or cross-chain communications.

[0016] A consensus protocol can be used to coordinate blockchains on a blockchain platform. For example, a consensus protocol can be used for metadata blockchains and / or contract blockchains to build consensus for validators such as custom subnets and smart contract executions. Nodes in a network can vote to agree on transactions, validate blocks, or make major network decisions. Determining consensus among participants may involve polling, sampling, or subsampling votes to ensure agreement on the order of transactions within the blockchain network. Generally, there is a trade-off between the liveness and security of a consensus protocol. Liveness refers to the protocol ensuring that messages can be exchanged between network nodes and that those messages can reach agreement or consensus. Liveness ensures that the system progresses continuously and that transactions are processed within a reasonable timeframe. Security refers to the guarantee that nothing inappropriate happens within the system and that agreement is reached between nodes. That is, if a transaction is considered final by one properly functioning node, it will eventually be considered final by all properly functioning nodes. Security is essential to maintain the integrity and accuracy of the blockchain network and to ensure that all nodes agree on transactions. A consensus protocol that always maintains high security and high liveness is undesirable due to its lack of applicability, as it cannot maintain efficient confirmation with a very large number of members in the system.

[0017] The disclosure of this subject overcomes the shortcomings described above by providing a transition mechanism that enables a shift between consensus protocols that prioritize liveness over security and / or security over liveness. This transition mechanism can leverage existing high-security-high-liveness consensus protocols to view changes that enhance liveness in the consensus protocol. According to an embodiment, the transition mechanism may implement a quorum-based asynchronous (randomized) Byzantine fault tolerance (BFT) protocol that achieves multi-value consensus as a backup consensus mechanism if liveness is compromised. According to an embodiment, if a liveness attack occurs, the transition mechanism allows a temporary switch from a high-security-low-liveness consensus protocol to a high-security-high-liveness consensus protocol to confirm the next block. Once this is achieved, the blockchain network is returned to implementing a high-security-low-liveness consensus protocol. This can be applied continuously whenever liveness is threatened within the network, boosting liveness when it disrupts the consensus process under Byzantine adversaries acting in a deceptive or flawed manner.

[0018] According to the embodiment, the transition mechanism may be asynchronous in its operational logic, which results in a more robust transition. The transition mechanism facilitates a transition between the first and second consensus protocols when liveness is compromised, and further returns to the first consensus protocol when liveness is no longer compromised (e.g., the next block is committed). In a given instance of processing, the network may be operating either the first consensus protocol or a quorum-based protocol (hereinafter referred to as the "second consensus protocol"). The second consensus protocol is initiated only if a liveness attack occurred in the previous instance, forcing a transition from the first consensus protocol to the second consensus protocol.

[0019] According to an aspect of the embodiment, the first consensus protocol can be a high-speed consensus mechanism with strong security guarantees (having low communication overhead), and the second consensus protocol can be a slower fallback mechanism with strong liveness guarantees as well as security guarantees (e.g., compared to the first consensus protocol). The overall consensus instructions can be divided into epochs that represent protocol instances of the network. Assuming that the network starts with a first consensus protocol that guarantees security (i.e., epoch 0), if the consensus or acceptance of transactions is not progressing, the polling process of network participants and the acceptance of new blocks are stopped. By way of non-limiting examples, the lack of progress of the consensus can be the result of decisions not reached quickly enough, adversaries sending competing information, message delivery delays, or attempts to compromise the network's integrity. In some aspects, a liveness counter is implemented to track the duration of the polling process. When the polling process is stopped, the state of the consensus instances across the network is frozen. Once the state is frozen, the state of the frozen consensus instances of each node is identified and supplied to the second consensus protocol. In this way, the network migrates to a fallback or second consensus protocol (i.e., epoch 1) with higher liveness.

[0020] When migrating to the second consensus protocol, the second consensus protocol determines a new value based on the protocol's safety / liveness parameters. After the new value is determined, the first consensus protocol resumes with the updated latest accepted decision (i.e., epoch 2). This process triggers a migration to a backup consensus protocol whenever liveness is at risk and continues to return to the original consensus protocol when a decision is made using the backup. In some embodiments, the migration mechanism is initiated periodically during normal operation (i.e., even if liveness is not at all compromised within the system).

[0021] According to aspects of the embodiment, supplying in the state from a previous consensus instance enables the current consensus instance to maintain safety properties, for example, even when a node determines a value during the freezing process. By obtaining the local values of the consensus instance and then using those values when inputting subsequent consensus instances, it becomes possible to cause the system to extract a chain that is safe for the second consensus protocol to build. Thus, the safety guarantee remains, and for this reason, the new values determined in the current instance will not be values that conflict with the previous instance.

[0022] The disclosed system addresses a problem in traditional blockchains rooted in computer technology: the technical challenge of maintaining and further enhancing the liveness of consensus protocols implementing a transition mechanism. The disclosed system solves this technical problem by providing a solution, also rooted in computer technology, namely, a system and method for enforcing consensus protocol transitions when liveness is compromised. The disclosed system can easily detect the cause of loss in liveness based on transitions between protocols and correct the problem in the next instance of processing. The disclosed system also improves the capabilities of the computer itself to reduce performance requirements and communication overhead while maintaining high security and increasing liveness, by ensuring that the system can still move forward and make decisions. Furthermore, the asynchronous backup protocol makes the process inherently robust. Moreover, by combining embodiments of the first and second consensus protocols via transitions between consensus protocols, the embodiment provides a consensus mechanism that is fast (or maintains speed) while possessing strong security and liveness characteristics.

[0023] As used herein, the term “blockchain” generally refers to an open, distributed, public ledger containing a growing list of records linked using cryptography. By design, blockchains are resistant to data alteration. A blockchain may include an auditable database that provides a distributed, replicated ledger of cryptographically authenticated artifacts. The contents of an artifact are extremely difficult to tamper with without detection and are therefore very likely to be true copies of the intended content, and their contents are open for inspection via a suitable query interface.

[0024] As used herein, the term “block” generally refers to a record held within a blockchain. For example, each block contains the cryptographic hash of the previous block, a timestamp, and transaction data that can generally be represented as a Merkle tree root hash.

[0025] As used herein, the terms “subnet” or “subnetwork” generally refer to a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. For example, each blockchain may be validated by only one subnet. A subnet can validate any number of blockchains. A validator node can be a member of any number of subnets. A subnet may manage its own membership and may require its constituent validators to have certain properties.

[0026] As used herein, the term “primary network” generally refers to a special subnet that validates the embedded blockchain. Members of the subnet may be members of the primary network. In some embodiments, a subject that is a member of the primary network stakes (e.g., acquires or “purchases”) one or more tokens from the primary network. As a result, a blockchain validator can validate the embedded blockchain on the primary network and will also be staking primary network tokens.

[0027] In some embodiments, a customized blockchain may include a VM marketplace having subnets serviced by unique VM modules that allow users to create feature sets tailored to specific needs. For example, a gaming application within the VM marketplace might have a different VM module than a financial application.

[0028] Exemplary Architecture Figure 1 illustrates a network architecture 100 for providing a blockchain platform (e.g., a blockchain network implementation / deployment platform) for managing consensus protocols. The network architecture 100 in Figure 1 includes one or more participants 110 and one or more participants 130 that are communicatively connected via a network 150. The blockchain architecture of network architecture 100 may be a decentralized database that maintains a continuously growing list of ordered records as blocks. The blockchain architecture can handle their assets and transactions, hosting applications that bridge subnets and operate across multiple blockchains on participants 110 and / or participants 130. Participants 110 and / or participants 130 may be used by users and administrators of the blockchain. This includes contributors to the blockchain, transaction validators, miners, smart contract parties, etc. The blockchain architecture may implement a transition mechanism that switches between consensus protocols operating within the blockchain based on protocol parameters and protocol liveness. The transition mechanism is designed to facilitate a seamless transition and ensure the safety and liveness of the system, and by increasing the liveness of high-security protocols throughout the transition, the chain can reach decisions quickly.

[0029] Participant 130 is understood to include Participant 110, just as Participant 110 is an equal. For example, Participant 130 may include a cloud server or a group of cloud servers. In some embodiments, the servers may not be cloud-based (i.e., they may be implemented outside a cloud computing environment) or may be partially cloud-based. Participant 110 includes one or more desktop computers or rack-mounted panels, etc. Participant 110 may be any one of the following: mobile devices, laptops, desktops, tablet (e.g., palm or pad) devices, televisions, display devices, etc. Participant 110 may be controlled by a user as a set of validator nodes for collaborative decision-making, such as to facilitate the operation or design of the blockchain implementation of the blockchain platform. For example, Participant 110 may be a client of the blockchain platform for creating, expanding, or otherwise modifying a customized blockchain network and / or private or public subnets. For example, Participant 110 may function as a validator or virtual machine (VM) forming a node of the blockchain network architecture 100. Participant 110, acting as a node, can run software to check block and transaction data, store and verify data, and respond to network requests for data and / or similar requests for existing blockchains. The VM may be a computer that operates on the blockchain and allows smart contracts from multiple sources to interact with each other. By non-limiting examples, participant 110 may, at a specific time such as during a specified time submission window, send messages or issue transactions at the request of participant 130, via a module of participant 130, etc. Blocks that are generated and proposed for addition to an existing blockchain may be verified as valid blocks before their addition.

[0030] Network 150 may include wired networks (e.g., via optical fiber or copper wire, telephone lines, etc.) or wireless networks (e.g., cellular networks, radio frequency (RF) networks, Wi-Fi, Bluetooth, etc.). Network 150 may include one or more of the following: local area networks (LANs), wide area networks (WANs), and the internet. Furthermore, Network 150 may include, but is not limited to, one or more network topologies, such as bus networks, star networks, ring networks, mesh networks, star bus networks, tree or hierarchical networks. Multiple participants 110 may access the blockchain platform hosted by participant 130 via Network 150 with online or offline connections, such as wireless, wired, ad-hoc, mobile, or satellite connections.

[0031] As discussed herein, blockchain network architecture 100 can incorporate the application of a consensus protocol that is high-throughput, fully ordered, and effective for smart contracts. A smart contract may refer to a self-executing computer program, application, or contract for executing transactions, such as financial transactions involving cryptocurrencies. Blockchain network architecture 100 can be used to create custom blockchains (including private blockchains) and decentralized applications (dApps). The consensus protocol may be implemented to reach agreement on user transactions, add blocks to existing blockchains, interact with external resources (e.g., off-chain), etc. The consensus protocol implemented by blockchain network architecture 100 may be a decentralized, leaderless block proposal mechanism that processes multiple valid block proposals simultaneously and restricts the submission of proposals to existing blockchains. As an example, blockchain network architecture 100 may use repeated subsample voting, and validators may provide strong probabilistic guarantees of accuracy (e.g., security and liveness) without communicating with other validators.

[0032] Participant 130 can store data from existing blockchains in database 152 using a peer-to-peer (P2P) and / or distributed ledger method. Database 152 can store relevant information regarding rules for implementing, for example, execution and confirmation logic, and / or consensus protocols. Database 152 can store blockchain transactions, smart contracts, signatures, and backup files from digital assets, including tokens, cryptocurrencies, smart contracts, crypto keys, signing keys, and financial data. Participant 130 can work together to autonomously manage a decentralized database of existing blockchains via a P2P network and Participant 130's distributed timestamp server. Participant 130 can be configured to implement multiple chains of blockchain network architecture 100. For example, participant 130 can implement multiple chains of blockchain network architecture 100, such as an asset blockchain (for creating new assets, asset exchanges, and cross-subnet transfers), a metadata blockchain (for coordinating validators, tracking active subnets, and creating new subnets), and a smart contract blockchain (for creating smart contracts and applications requiring overall ordering). These multiple chains can be validated by the primary network of blockchain network architecture 100, which includes all existing subnets.

[0033] Generally, participants 110 and 130 include a computing device (e.g., a computing platform 302, described later in Figure 3) which includes at least a memory for storing instructions and a processor configured to execute instructions for at least partially performing one or more execution applications, functions, steps, and / or operations according to embodiments described according to one or more embodiments. The techniques described herein may be implemented as a method implemented by a physical computing device, or as one or more non-temporary computer-readable storage media that store instructions causing the method to be implemented when executed by the computing device, or as a physical computing device specially configured with a combination of hardware and software causing the method to be implemented. For example, the memory of participant 110 can be used to implement functions associated with a blockchain platform hosted by participant 130. The processor can be used to operate participant 110, such as by executing applications and their functions that are rendered on at least one of participants 110 and 130.

[0034] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0035] Figure 2 illustrates an exemplary consensus protocol 200 that implements a transition mechanism in a blockchain platform / network according to a particular aspect of the embodiment. The consensus protocol 200 may include subprotocols, namely a first consensus protocol and a second consensus protocol. The operations described herein with reference to Figure 2 may be carried out by one or more processors according to one or more embodiments.

[0036] In some embodiments, the blockchain platform includes a custom chain 210 (e.g., a P-chain) containing a shared registry. This custom chain may be included in the primary network of the blockchain platform. The shared registry defines which nodes belong to which underlying chain or subnet (i.e., which nodes validate which one or more subnets / chains). Nodes may include, by non-limiting examples, validators configured to validate blocks, and / or proposers configured to propose blocks to the custom chain. In some embodiments, a transition mechanism requires nodes to know which set of nodes is responsible for validating a given component. Thus, the shared registry can be utilized to ensure that the set of nodes within the blockchain platform is well-defined and consistent across all participants in the consensus protocol 200.

[0037] Nodes 230-1, 230-2, 230-3, 230-4, 230-5, 230-6, and 230-7 across the network (hereinafter collectively referred to as "Nodes 230") must agree on a block in chain 210 (e.g., chain blocks 240-1, 240-2, 240-3, 240-4, 240-5, 240-6, and 240-7 (hereinafter collectively referred to as "Chain Block 240")). Given a selected height for a block on chain 210, node membership can be determined by a staking set (e.g., staking set 202-1 and staking set 202-2 (hereinafter referred to as "Staking Set 202")).

[0038] To ensure a globally consistent selection of chainblock 240 and that all nodes agree on the chainblock, the accepted block (proposed by the second consensus protocol 206) includes an additional field for the height within chain 210. Embedding the height of chain 210 as part of the accepted block would ensure that it is a consistent selection, similar to the blocks on the chain in the first consensus protocol 204.

[0039] In some embodiments, due to the asynchronous nature of the protocol, a node may initiate a transition from a different height in the first consensus protocol 204 process. To synchronize the views, each block proposed by the second consensus protocol 206 accurately captures an instance in the history (i.e., a transition from the first consensus protocol to the second consensus protocol). Thus, each proposed block (more specifically, the proposed value within the accepted block determined by operating the second consensus protocol 206) can be used to point to the corresponding block in chain block 240. Furthermore, each proposed block can be used to count the number of past proposed blocks as an identifier for the operation of the second consensus protocol 206 (e.g., instances 220-1 and 220-3). For example, the accepted block 214 determined at node 230-3 points to its corresponding chain block 240-3. The corresponding chain block 240-3 is determined based on the chain height value embedded in the accepted block 214. Similarly, the accepted block 216 determined at node 230-6 points to its corresponding chain block 240-5. The corresponding chain block 240-5 is determined based on the chain height value embedded in the accepted block 216.

[0040] In some embodiments, multiple second consensus protocol operations may occur simultaneously within the network due to asynchronous nature, using a staking set 202 from chainblock 240 pointed to by the most recent accepted block that precedes the second consensus protocol. That is, the second consensus protocol operation that determines the current accepted block B can be identified using the number of accepted blocks that precede (i.e., ancestors) the current accepted block B (e.g., accepted block 214 and / or accepted block 216).

[0041] In some embodiments, the blockchain platform includes a counter that tracks the number of previously accepted blocks. This counter can be used as an identifier for the operation (i.e., cycle) of the transition mechanism within the platform. For example, if id represents the transition instance (or epoch) when the consensus protocol 200 is running, and id(B) represents the number of accepted blocks that came before the current accepted block B, then id(B) is also the transition instance id that determines the current accepted block B. Each id uniquely identifies an instance (e.g., among instance 220). In some embodiments, if an instance is invoked based on a given id and does not exist, a new instance can be created for a given id using an empty execution context.

[0042] As shown in Figure 2, instances of the transition mechanism include, but are not limited to, instances 220-1, 220-2, 220-3, and 220-4 (hereinafter collectively referred to as "instances 220"). All instances are standalone processes of the overall consensus protocol 200, each with its own designated execution context. A given instance can execute at least one of the first or second consensus protocols to make decisions regarding transactions within the blockchain. In one or more rounds of processing consensus protocol 200 (for example, at node 230), a set of nodes can be queried to determine newly accepted blocks. By a non-limiting example, in the event of a liveness failure, an instance of consensus protocol 200 may transition from the first consensus protocol 204 to the second consensus protocol 206 to confirm a new block.

[0043] According to one embodiment, for each instance 220, the chain block 240 includes a staking set (e.g., staking set 202). This staking set may include a set of all nodes in the network. For example, for the current instance id, the set of nodes N may be the staking set determined by the accepted chain 210 block at the height indicated in the current accepted block B determined by the current second consensus protocol operation (i.e., id-1). The current accepted block may use the staking set from the chain block 240 pointed to by the most recent accepted block that came before the current second consensus protocol operation and selection of the chain block.

[0044] Initially (i.e., epoch 0), a set of nodes may be queried for one or more values ​​according to the first consensus protocol 204. In some embodiments, in response to a query, each node reports its final values ​​(i.e., accepted blocks), as well as preferred values ​​(i.e., preferred blocks). This preferred block refers to a block verified by the nodes in the set of nodes. In some embodiments, one or more nodes in the set of nodes may begin accepting preferred blocks, depending on the number of nodes that prefer the block. A preferred block can describe a preferred chain as the most recently accepted block in a preferred blockchain. If the final value determined by node 230-1 remains unchanged (e.g., the nodes in the set of nodes agree on and commit to the value), a message may be sent to all other nodes in the network indicating that node 230-1 wishes to proceed to the next epoch and continue operating the first consensus protocol 204. Each of these messages may be signed using the signing key associated with node 230-1. In some embodiments, before node 230-2 enters the consensus protocol, at least a threshold number of nodes (in the set of nodes) must also broadcast a message indicating that those nodes agree to continue operating the first consensus protocol 204. In the example in Figure 2, the final value at node 230-1 remains unchanged during the first round of processing, and therefore node 230-2 continues operating the first consensus protocol 204 in the next round.

[0045] Node 230-2, running the first consensus protocol 204, encounters a liveness failure, the protocol freezes (i.e., stops further polling), and a preferred block is broadcast to the network. This preferred block is used to determine the highest acceptable block that any node in the set of nodes may have committed. All blocks accepted before the highest acceptable block are considered safe and can be arbitrarily selected as a preferred block (or to represent a preferred block). A transition then occurs from the first consensus protocol 204 to the second consensus protocol 206, and instance 220-1 is started to run the second consensus protocol 206 in subsequent rounds of processing at node 230-3. The preferred block identified by node 230-2 is used as the initial block (i.e., block 0) for processing at instance 220-1 when running the second consensus protocol 206. In further processing, the preferred block identified in the previous instance is used in the initiated instance as the initial block of a new epoch or round, serving as the starting point for all subsequent blocks. For example, the preferred block identified based on node 230-5 in instance 220-2 is used (in instance 220-3) as the initial block for running the second consensus protocol 206 in node 230-6.

[0046] The second consensus protocol 206 operates and decides on the accepted block 214 based on the initial block. The accepted block 214 is the accepted confirmed block of instance 220-1. Once the accepted block 214 is decided, a message is broadcast to the network. An extra field about the height in chain 210, embedded in the accepted block 214, is used to verify that the agreed chain block 240-3 is consistent. If consistent, the first consensus protocol 204 is restored, and consensus protocol 200 moves to the next instance (i.e., instance 220-2) at the beginning of the newly accepted block 214. Operating the first consensus protocol 204 in the new instance (with a new unique ID) avoids conflicting with any preceding migrations within consensus protocol 200. Similarly, for example, instance 220-2, which is operating the first consensus protocol 204, encounters a liveness failure. A transition occurs from the first consensus protocol 204 to the second consensus protocol 206, switching to instance 220-3. The second consensus protocol 206 determines the accepted block 216 using the preferred block from node 230-5 in instance 220-2. The accepted block 216 is broadcast to the network, and the height embedded in the accepted block 214 is used to verify that the agreed chain block 240-5 is consistent. At that point, the first consensus protocol 204 is restored in instance 220-4 and operates at node 230-7, which is at the beginning of the accepted block 216.

[0047] According to one embodiment, during the operation of the second consensus protocol 206 in any instance, the correct node will select the height of the most recent known block in chainblock 240 for its proposal. The height number of chainblock 240 must be within a valid accepted block (e.g., accepted block 214 and accepted block 216) and greater than any ancestral (preceding) accepted block.

[0048] In some embodiments, consensus protocol 200 implements a leader-based consensus protocol. This consensus protocol may randomly select a leader. A leader is a node or entity responsible for initiating and coordinating the consensus process, proposing new blocks, verifying transactions, and ensuring agreement among network participants. The leader may also be responsible for maintaining network integrity, managing communication between nodes, and driving decision-making processes within the network. The leader node broadcasts its decision regarding proposed values ​​(blocks) to the network, enabling other nodes to verify and agree on the proposed blocks. In some embodiments, the current leader may fail to make a decision that results in a liveness failure. To ensure the progress and acceleration of the consensus mechanism within the network, a view change is implemented to suspend the failed leader and re-select a new leader. According to embodiments, a view change includes calling a transition between one or more consensus protocols.

[0049] Figure 3 illustrates a system 300 configured to process a consensus protocol using a transition protocol to enhance liveness within the system, according to one or more embodiments. The consensus protocol adds a new block to the blockchain network by validating values, while ensuring that all nodes in the blockchain network agree to the addition of a new block. The transition protocol can enhance the liveness of the first consensus protocol by sequentially looping transitions between a first consensus protocol and a second consensus protocol, with each node operating through a series of first and second operating modes. By non-limiting examples, the transition protocol may enable a transition from a fast, secure consensus instance to a second, slower (relative to the first consensus instance) consensus instance with higher security and higher liveness. According to embodiments, each (honest) node in a set of nodes may manage its own blockchain replica and participate in either the first or second consensus protocol.

[0050] In some implementations, system 300 may include one or more computing platforms 302. A computing platform 302 can be configured to communicate with one or more remote platforms 304 according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. A remote platform 304 can be configured to communicate with other remote platforms via computing platform 302 and / or according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. Users can access system 300 via remote platforms 304. Computing platforms 302, external resources 324, and remote platforms 304 may communicate and / or be mutually accessible via network 150.

[0051] The computing platform 302 may be composed of machine-readable instructions 306. The machine-readable instructions 306 include one or more instruction modules. The instruction modules include computer program modules. The instruction modules include one or more of the following: a first consensus module 308, a second consensus module 310, a detection module 312, a transition module 314, a count module 316, a broadcast module 318, and / or other instruction modules.

[0052] The first consensus module 308 can be configured to operate in a first operating mode. In the first operating mode, the first consensus protocol operates within the set of nodes until a liveness attack is detected. Operating the first consensus protocol may involve querying values ​​in the set of nodes. A block is accepted into the first consensus protocol only if the determined chain of the protocol decision chain contains the block, and only if it contains the block. The first consensus protocol may be a consensus protocol with a high guarantee of security. According to the embodiment, all nodes prefer block B pref It has the following characteristics. When a node reports a preferred block, the preferred block has been verified by the node. A block is preferred in the first consensus protocol if the preferred chain of the protocol contains the block. The node's preferred block ID can be broadcast to all nodes in the blockchain network.

[0053] The second consensus module 310 can be configured to operate a second operating mode. In the second operating mode, the second consensus protocol is configured so that the protocol accepts new values ​​(i.e., newly accepted blocks).

number

number

number

[0054] The detection module 312 can be configured to perform liveness failure detection. This liveness failure detection includes determining when the first consensus protocol is no longer progressing (i.e., liveness is lost) and initiating a transition protocol. For example, when the detection module 312 determines that the first consensus protocol has encountered a liveness attack at node u, the first consensus module 308 freezes the acceptance of all new blocks at any other members in the set of nodes.

[0055] The transition module 314 is configured to switch operating modes. According to one embodiment, when the detection module 312 determines that the first consensus protocol has encountered a liveness attack, the transition module 314 switches the system 300 from the first operating mode to the second operating mode. According to one embodiment, once the operating mode is switched, the second consensus module 310 determines that the consensus has been accepted.

number

[0056] The count module 316 is configured to maintain an instance counter for tracking instances of the transition protocol (i.e., transitioning from running the first consensus protocol to the second consensus protocol). This instance counter can increase monotonically from zero. According to one embodiment, the second consensus module 310 is newly accepted block B SD When a decision is made, node u increments its instance counter u.id and completes the instance id of the migration protocol. In this way, each accepted block represents a successful migration. Each accepted block on the chain can be identified by its instance counter. If the current instance counter u.id is incremented, any ongoing migration instance of the preceding instance (i.e., id-1) stops and accepts all blocks from its operation up to the most recently accepted block (including the most recently accepted block).

[0057] According to one embodiment, when the second consensus module 310 is completed (i.e., when the second consensus protocol has made a decision), the current instance of the transition protocol (i.e., u.id=id-1) is marked as complete. According to one embodiment, a quorum certificate (e.g., QC(

number

number

number

number

[0058] In some embodiments, the node holds a flag indicating whether an instance of the second consensus protocol is operating and the instance id (i.e., u.id) that was last completed.

[0059] The broadcast module 318 is configured to broadcast the preferred block B for the current instance id after the first consensus module 308 has stopped answering queries. By way of non-limiting example, the preferred block B pref is broadcast to all nodes (e.g., a set of nodes) via the blockchain network (e.g., by <preferred, id, B pref 〉). The broadcast module 318 may be further configured to wait for a pre-set number of broadcast messages of the preferred block B from all other nodes in the network. The current number may represent the stake percentage of the nodes operating the first consensus protocol. When the pre-set number of broadcast messages is satisfied, the initial proposal for the second consensus protocol is set to the accepted block B pref that has received a pre-set number of transitional base settings. pref SD

[0060] According to an embodiment, the accepted block B SD may be the most highly accepted block from the first consensus protocol and is determined based on the preferred block B pref . The accepted block B SD is used as the first proposed block for the second consensus protocol. As a non-limiting example, the accepted block B SD is set to be equal to the initial block B0 of the current instance id (i.e., B SD ​​:=B0). Initial block B0 is the first block to be added to the blockchain. In this way, initial block B0 defines the initial base settings used to sow the seeds of proposals within the consensus protocol. This ensures that all nodes following the transition protocol (i.e., running the second consensus protocol on the current instance ID) have initial base settings that do not conflict with any accepted blocks in the preceding first consensus protocol instance. In some embodiments, to ensure that the second consensus protocol running on the current instance ID makes useful progress, accepted block B SD The new child block is bundled with the current instance ID as a new proposed block.

[0061] According to the embodiment, the second consensus protocol accepts the block

number

[0062] According to the embodiment, since the complete message is tagged by the instance ID, past instances (i.e., ≤u.id) can be ignored in the current migration protocol instance. Furthermore, future messages (i.e., id" ≤u.id+1) do not need to be buffered, for example, if node u has already received the complete message (e.g., <complete, id"-1, *>), and therefore the instance counter u.id has already been promoted.

[0063] In some implementations, the computing platform 302, the remote platform 304, and / or the external resources 324 can be operationally linked via one or more electronic communication links. For example, such electronic communication links can be established at least in part via a network such as the Internet and / or other networks. This is not intended to limit the scope of the disclosure, and it will be understood that the scope of this disclosure includes implementations in which the computing platform 302, the remote platform 304, and / or the external resources 324 can be operationally linked via some other medium of communication.

[0064] A given remote platform 304 includes one or more processors configured to run a computer program module. The computer program module may be configured to enable an expert or user associated with the given remote platform 304 to interface with system 300 and / or external resources 324, and / or to provide the remote platform 304 with other functions attributed herein. As a non-limiting example, a given remote platform 304 and / or a given computing platform 302 includes one or more of the following: a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms.

[0065] External resources 324 include information sources outside of system 300, external entities participating in system 300, and / or other resources. In some implementations, some or all of the functions attributed to external resources 324 herein may be provided by resources included in system 300.

[0066] Computing platform 302 includes electronic storage 326, one or more processors 328, and / or other components. Computing platform 302 includes communication lines or ports that enable the exchange of information with a network and / or other computing platforms. The illustrative solutions of computing platform 302 are not intended to be limiting. Computing platform 302 includes multiple hardware, software, and / or firmware components that work together to provide the functions attributed to computing platform 302 herein. For example, computing platform 302 can be implemented by a cloud of computing platforms working together as computing platform 302.

[0067] The electronic storage 326 may include non-temporary storage media for electronically storing information. The electronic storage media of the electronic storage 326 may include either or both system storage provided integrally with the computing platform 302 (i.e., substantially inremovable), and / or removable storage that can be detachably connected to the computing platform 302 via, for example, a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage 326 may include one or more of the following: optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage 326 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The electronic storage 326 may store software algorithms, information determined by the processor 328, information received from the computing platform 302, information received from the remote platform 304, and / or other information that enables the computing platform 302 to function as described herein.

[0068] The processor 328 can be configured to provide information processing capabilities in the computing platform 302. Therefore, the processor 328 includes one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 328 is shown as a single entity, this is for illustrative purposes only. In some implementations, the processor 328 includes multiple processing units. These processing units may be physically located within the same device, or the processor 328 may represent the processing capabilities of multiple devices working together. The processor 328 can be configured to run modules 308, 310, 312, 314, 316, and / or 318, and / or other modules. The processor 328 may be configured to execute modules 308, 310, 312, 314, 316, and / or 318, and / or other modules, by any combination of software, hardware, firmware, software, hardware, and / or firmware, and / or other mechanisms for configuring processing power on the processor 328. As used herein, the term “module” may refer to any component or set of components that perform the functions belonging to the module. This includes one or more physical processors, processor-readable instructions, circuits, hardware, storage media, or any other components in which processor-readable instructions are executed.

[0069] While modules 308, 310, 312, 314, 316, and / or 318 are illustrated as being implemented within a single processing unit, it should be understood that in embodiments where processor 328 includes multiple processing units, one or more of modules 308, 310, 312, 314, 316, and / or 318 may be implemented remotely from other modules. The descriptions of the functions provided by the different modules 308, 310, 312, 314, 316, and / or 318 described below are illustrative and not intended to limit any of the modules 308, 310, 312, 314, 316, and / or 318, as they may provide more or fewer functions than those described. For example, one or more of modules 308, 310, 312, 314, 316, and / or 318 can be excluded, and some or all of their functions can be provided by other modules among modules 308, 310, 312, 314, 316, and / or 318. As another example, processor 328 can be configured to run one or more additional modules that can perform some or all of the following functions that belong to one of modules 308, 310, 312, 314, 316, and / or 318.

[0070] The techniques described herein can be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0071] Figure 4 illustrates an exemplary flowchart (e.g., Process 400) for enhancing liveness within a consensus protocol using a transition mechanism, according to a particular aspect of the present disclosure. For illustrative purposes, the steps of the exemplary Process 400 are described herein as occurring sequentially or linearly. However, multiple instances of the exemplary Process 400 may occur in parallel, overlapping in time, occurring nearly simultaneously, or in an order different from the order illustrated in Process 400. In addition, the blocks of the exemplary Process 400 do not have to be performed in the order shown, and / or one or more blocks of the exemplary Process 400 may not be performed.

[0072] In step 402, process 400 includes running a first consensus protocol on a set of nodes in the blockchain network. The first consensus protocol may be a protocol that ensures high security so that when a node agrees on a value, other nodes in the network do not agree on a conflicting value. According to the embodiment, running the first consensus protocol includes polling the set of nodes for the value of a new block. In step 404, process 400 includes detecting a liveness attack in the first consensus protocol on a node in the set of nodes. As a non-limiting example, a liveness attack includes a case where the first consensus protocol does not reach an agreement on a value quickly enough. Thus, a liveness attack is characterized by the first consensus protocol no longer proceeding.

[0073] In step 406, process 400 includes triggering a transition protocol based on the detection of a liveness attack. This transition protocol allows the consensus process to transition from a first consensus protocol to a second consensus protocol. According to the embodiment, the second consensus protocol may be a protocol that guarantees high security and high liveness. The second consensus protocol may be a slower protocol compared to the first consensus protocol.

[0074] In step 408, process 400 includes suspending the acceptance of new blocks in the first consensus protocol when the transition protocol is initiated. Suspending acceptance may include stopping all polling (or querying) of a set of nodes. When polling stops, process 400 may include broadcasting preferred blocks of the set of nodes to the blockchain network.

[0075] In step 410, process 400 includes identifying the most accepted block in a set of nodes by running the first consensus protocol. Preferred blocks may be used to determine the most accepted block based on running the first consensus protocol.

[0076] In step 412, process 400 includes setting an initial baseline for the second consensus protocol to the most accepted block. This initial baseline will be used to sow the seeds for the proposal of the second consensus protocol. In some embodiments, process 400 waits for a number of current broadcast messages containing preferred blocks from a set of nodes and sets an initial baseline for activating the second consensus when a predetermined number is met.

[0077] In step 414, process 400 includes transitioning from the first consensus protocol to the second consensus protocol.

[0078] In step 416, process 400 includes running the second consensus protocol on a set of nodes using the initial basic configuration as the initial block (i.e., block 0). In step 418, process 400 includes determining the consensus value of a newly accepted block (i.e., a committed block). According to the embodiment, the second consensus protocol will run until a decision is made about the newly accepted block. According to the embodiment, the newly accepted block may represent the successful completion of the protocol transition. In some embodiments, process 400 includes generating a complete message containing the transition instance ID based on the newly accepted block and broadcasting that complete message to the blockchain network. According to some embodiments, process 400 includes maintaining a flag on a set of nodes indicating whether the second consensus protocol is running. This flag may also contain the ID of the last completed transition instance.

[0079] According to one embodiment, process 400 may include incrementing a transition instance counter based on the second consensus protocol determining the newly accepted block. In some embodiments, this transition instance counter is incremented after the complete message has been broadcast. The transition instance counter can track each transition from the first consensus protocol to the second consensus protocol in the blockchain network. Thus, the value of the transition instance counter may represent the number of blocks previously accepted, as an identifier for the transition instance.

[0080] According to one embodiment, process 400 may include determining the staking set included in a shared chain block of the blockchain network based on a newly accepted block, using the height field included in the newly accepted block, where the height field refers to a shared chain block.

[0081] In step 418, process 400 includes restoring the first consensus protocol after the consensus value of the newly accepted block has been determined. The first consensus protocol is restarted at the beginning of the newly accepted block. Step 418 completes the entire cycle of the transition mechanism.

[0082] The techniques described herein (e.g., process 400) may be implemented as a method performed by a physical computing device, or as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when performed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0083] In some embodiments, one or more operational blocks in Figure 4 may be implemented by memory circuits, client devices, remote servers, or processor circuits that execute instructions stored in a database, all of which are connected communicably via a network (e.g., processor 328, memory as described in Figure 1, participant 110, participant 130, database 152, and network 150).

[0084] Figure 4 shows an exemplary block of process 400, but in some embodiments, process 400 may include additional blocks, fewer blocks, different blocks, or blocks in a different arrangement than shown in Figure 4.

[0085] Hardware Overview Figure 5 is a block diagram illustrating an exemplary computer system 500 that can implement an embodiment of the technology in question. In a particular embodiment, the computer system 500 may be implemented using hardware or a combination of software and hardware, either located in a dedicated server, integrated in another entity, or distributed across multiple entities.

[0086] The computer system 500 (e.g., a server and / or participant) includes a bus 508 or other communication mechanism for transmitting information and a processor 502 coupled to the bus 508 for processing information. For example, the computer system 500 may be implemented by one or more processors 502. Each of the one or more processors 502 may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, a discrete hardware component, or any other suitable entity capable of performing computation or other operations on information.

[0087] In addition to the hardware, the computer system 500 may include code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof, stored in the accompanying memory 504, such as code that creates an execution environment for the computer program in question, for example, random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, hard disks, removable disks, CD-ROMs, DVDs, or any other suitable storage devices coupled to the bus 508 for storing information and instructions executed by the processor 502. The processor 502 and memory 504 may be supplemented by or incorporated into special-purpose logic circuits.

[0088] Instructions may be stored in memory 504 and implemented in one or more modules of computer program instructions, i.e., one or more computer program products, i.e., one or more modules of computer program instructions, which are encoded on a computer-readable medium for execution by the computer system 500 or for controlling the operation of the computer system 500, in accordance with any method well known to those skilled in the art, including but not limited to computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). Instructions can also be implemented in computer languages ​​such as array languages, aspect-oriented languages, assembly languages, authoring languages, command-line interface languages, compiled languages, concurrent languages, curly brace languages, data flow languages, data structure languages, declarative languages, esoteric languages, extended languages, fourth-generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list-based languages, little languages, logic-based languages, machine languages, macro languages, metaprogramming languages, multi-paradigm languages, numerical analysis, non-English-based languages, object-oriented class-based languages, object-oriented prototype-based languages, offside rule languages, procedural languages, reflexive languages, rule-based languages, scripting languages, stack-based languages, synchronous languages, syntactic processing languages, visual languages, Worth languages, and XML-based languages. Memory 504 can also be used to store temporary variables or other intermediate information during the execution of instructions performed by processor 502.

[0089] Computer programs as considered herein do not necessarily correspond to files in a file system. A program may be stored in part of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subprograms, or parts of code). Computer programs may be deployed to run on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logical flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform their functions by manipulating input data and producing outputs.

[0090] The computer system 500 further includes a data storage device 506, such as a magnetic disk or optical disk, coupled to a bus 508 for storing information and instructions. The computer system 500 may be coupled to various devices via an input / output module 510. The input / output module 510 can be any input / output module. An exemplary input / output module 510 includes a data port, such as a USB port. The input / output module 510 is configured to connect to a communication module 512. An exemplary communication module 512 includes a networking interface card, such as an Ethernet card and a modem. In certain embodiments, the input / output module 510 is configured to connect to multiple devices, such as an input device 514 and / or an output device 516. An exemplary input device 514 includes a keyboard and a pointing device, such as a mouse or trackball, through which a user can provide input to the computer system 500. Other types of input devices may also be used to provide user interaction, such as a tactile input device, a visual input device, a voice input device, or a brain-computer interface device. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, voice, tactile, or electroencephalogram (EEG) input. An exemplary output device 516 includes a display device such as an LCD (liquid crystal display) monitor for displaying information to the user.

[0091] According to one aspect of the present disclosure, the system described above may be implemented using a computer system 500 in response to a processor 502 executing one or more sequences of one or more instructions contained in a memory 504. Such instructions may be read into the memory 504 from another machine-readable medium, such as a data storage device 506. When executing the sequence of instructions contained in the main memory 504, the processor 502 performs the process steps described herein. One or more processors in a multiprocessing configuration may also be used to execute the sequence of instructions contained in the memory 504. In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions to implement various aspects of the present disclosure. Thus, the aspects of the present disclosure are not limited to any specific combination of hardware circuits and software.

[0092] Various embodiments of the subject matter described herein may be implemented in a computing system that includes, for example, backend components such as data servers, middleware components such as application servers, or frontend components such as client computers having a graphical user interface or a web browser. Users may interact with the implementations of the subject matter described herein through the graphical user interface or a web browser, or with any combination of one or more such backend, middleware, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communication network. The communication network may include, for example, one or more of LANs, WANs, and the Internet. Furthermore, the communication network may include, but is not limited to, one or more network topologies, such as bus networks, star networks, ring networks, mesh networks, starbus networks, tree or hierarchical networks. The communication module may be, for example, a modem or an Ethernet card.

[0093] The computer system 500 may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship is established by computer programs running on each computer that have a client-server relationship with each other. The computer system 500 may be, for example, a desktop computer, a laptop computer, or a tablet computer, for example. The computer system 500 may also be embedded in another device, for example, a mobile phone, a PDA, a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and / or a television set-top box, for example.

[0094] The terms “machine-readable storage medium” or “computer-readable medium” as used herein refer to any medium or medium involved in providing instructions to the processor 502 for execution. Such mediums can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks such as data storage device 506. Volatile media include dynamic memory such as memory 504. Transmission media include coaxial cables, copper wires, and optical fibers, including wires that constitute bus 508. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tapes, any other physical media having a pattern of holes, RAM, PROMs, EPROMs, FLASH EPROMs, any other memory chips or cartridges, or any other media that a computer can read. A machine-readable memory medium can be a machine-readable memory device, a machine-readable memory substrate, a memory device, a composition of a substance that affects machine-readable propagated signals, or a combination of one or more of these.

[0095] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0096] The phrase “at least one of” preceding a set of items, accompanied by the terms “and” or “or” to separate any of the items, when used herein, qualifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require the selection of at least one item; rather, the misphrase allows for meanings including at least one of any one of the items, and / or at least one of any combination of items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0097] To the extent that terms such as “include” and “have” are used in the description or claims, such terms are intended to be inclusive in the same manner as the term “comprise” is interpreted as “comprise” when it is adopted as a transitional term in a claim. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” No embodiment described herein as “exemplary” should necessarily be construed as being preferable or advantageous to any other embodiment.

[0098] References to elements in the singular form are intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise. All structural and functional equivalents to elements of the various configurations described throughout this disclosure, whether known to those skilled in the art or subsequently known, are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein, whether such disclosure is expressly stated in the above description or not, is intended to be for the public only.

[0099] While this specification contains many details, these should not be interpreted as limitations on the scope that can be claimed, but rather as descriptions of specific implementations of the subject matter. Certain features described herein in the context of separate embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any preferred partial combination. Furthermore, features are described above as acting in a particular combination and are initially claimed as such, but in some cases, one or more features from the claimed combination may be removed from the combination, and the claimed combination may be subject to a partial combination or a variation of a partial combination.

[0100] While the subject matter of this specification is described in terms of specific embodiments, other embodiments may be implemented and are within the scope of the following claims. For example, although the operations are depicted in a specific order in the drawings, this should not be understood as meaning that such operations must be performed in a specific order or sequence shown, or that all illustrated operations must be performed in order to achieve a desired result. The actions described in the claims may be performed in a different order and still achieve the desired result. As an example, the processes depicted in the accompanying drawings do not necessarily require a specific order or sequence shown to achieve a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as meaning that such separation is necessary in all embodiments, and the described program components and systems may generally be integrated in a single software product or packaged in multiple software products. Other variations are within the scope of the following claims.

[0101] In this specification, it should be understood that the original applicant will determine which technologies to use and / or commercialize, and what is best for the technology, its players, and users, based on the usefulness and relevance of the technologies in the ever-evolving field. Accordingly, the systems and methods described herein may not yet be used by the original applicant, and / or may not be used, and / or commercialized in the future. It should also be understood that the implementation and use of the systems and methods described herein will be carried out by the original applicant, if any, in accordance with its privacy policy. These policies are intended to respect and prioritize the privacy of players and are intended to meet or exceed the governmental and legal requirements of the respective jurisdictions. To the extent that such implementation or use of these systems and methods enables or requires the processing of users' personal information, such processing will be carried out in accordance with (i) the privacy policy outlined herein, (ii) an effective legal mechanism including, but not limited to, providing appropriate notice, or, where necessary, obtaining the consent of the respective user, and (iii) the privacy settings or preferences of the player or user. Furthermore, the original applicant should understand that, if implemented or used by other entities, the systems and methods described herein are intended to comply with privacy policies and practices consistent with their purpose of respecting the privacy of players and users.

Claims

1. A computer implementation method for carrying out a migration protocol, In a set of nodes on a blockchain network, the first consensus protocol is to be run, In the set of nodes, detect a liveness attack within the first consensus protocol. When the aforementioned liveness attack is detected, the acceptance of new blocks into the first consensus protocol is temporarily suspended, By operating the first consensus protocol described above, the most accepted block in the set of nodes is identified, The most highly accepted block will be used to set the initial basic settings for the second consensus protocol, A computer implementation method comprising transitioning to the second consensus protocol, wherein the second consensus protocol operates until a newly accepted block is confirmed.

2. The computer implementation of claim 1, further comprising restoring the first consensus protocol after the consensus value of the newly accepted block has been determined by operating the second consensus protocol, wherein the first consensus protocol is restored to a point after the newly accepted block.

3. The computer implementation method according to claim 1, wherein the first consensus protocol is a high-speed protocol that guarantees high security, and the second consensus protocol is a protocol that guarantees high security and high liveness.

4. Broadcasting to the blockchain network the preferred blocks of the set of nodes, based on the operation of the first consensus protocol, wherein the most accepted block is determined based on the preferred blocks. The computer implementation method according to claim 1, further comprising waiting for a number of current broadcast messages containing the preferred blocks from the set of nodes, wherein the initial basic settings for operating the second consensus are set based on the fulfillment of a predetermined number of broadcast messages.

5. The computer implementation of claim 1, further comprising, based on the detection of the liveness attack, initiating a transition protocol that enables a transition from the first consensus protocol to the second consensus protocol, wherein the newly accepted block represents a successful protocol transition.

6. Based on the newly accepted block, generate a complete message including the migration instance identification information (ID), The computer implementation method according to claim 1, further comprising broadcasting the complete message to the blockchain network, wherein the broadcasting includes the nodes.

7. The second consensus protocol further includes monotonically incrementing a migration instance counter based on the determination of the newly accepted block, The computer implementation method according to claim 1, wherein the migration instance counter tracks each migration from the first consensus protocol to the second consensus protocol as a migration instance in the blockchain network, and the value of the migration instance counter represents the number of blocks previously accepted as an identifier for the migration instance.

8. The computer implementation method according to claim 1, wherein the second consensus protocol is a quorum-based asynchronous Byzantine fault tolerance protocol.

9. The computer implementation method according to claim 2, further comprising maintaining a flag in the set of nodes indicating whether the second consensus protocol is running, wherein the flag includes the ID of the last completed instance.

10. The computer implementation of claim 1, further comprising determining a staking set included in a shared chain block of the blockchain network based on the newly accepted block, using a height field included in the newly accepted block, wherein the height field points to the shared chain block.

11. A system for implementing a transition protocol, Processor and A memory that includes instructions stored therein, and when the instructions are executed by the processor, the processor In a set of nodes on a blockchain network, the first consensus protocol is to be run, In the set of nodes, detect a liveness attack within the first consensus protocol. When the aforementioned liveness attack is detected, the acceptance of new blocks into the first consensus protocol is temporarily suspended, Based on the preferred blocks, the first consensus protocol is operated to identify the block that is most accepted in the set of nodes, The most highly accepted block will be used to set the initial basic settings for the second consensus protocol, Transitioning from the first consensus protocol to the second consensus protocol, A system comprising memory and a set of nodes, which determines the consensus value of a newly accepted block based on the operation of the second consensus protocol in the set of nodes.

12. The instruction further includes, when the instruction is executed by the processor, the processor: The system according to claim 11, wherein the first consensus protocol is restored after the consensus value of the newly accepted block is determined, and the first consensus protocol is restored from the newly accepted block onward.

13. The system according to claim 11, wherein the first consensus protocol is a high-speed protocol that guarantees high security, and the second consensus protocol is a protocol that guarantees high security and high liveness.

14. The instruction further includes, when the instruction is executed by the processor, the processor: Broadcasting the preferred block of the set of nodes to the blockchain network based on the operation of the first consensus protocol, wherein the most accepted block is determined based on the preferred block, The system according to claim 11, wherein the initial basic settings for operating the second consensus are set based on the number of pre-configured broadcast messages being met, and the system waits for a number of current broadcast messages containing the preferred block from the set of nodes, and the initial basic settings for operating the second consensus are set based on the number of pre-configured broadcast messages being met.

15. The instruction further includes, when the instruction is executed by the processor, the processor: The system according to claim 11, wherein, based on the detection of a liveness attack, a transition protocol is initiated to enable the transition from the first consensus protocol to the second consensus protocol, and the newly accepted block represents a successful protocol transition.

16. The instruction further includes, when the instruction is executed by the processor, the processor: Based on the newly accepted block, generate a complete message including the migration instance identification information (ID), The system according to claim 11, wherein broadcasting the complete message to the blockchain network and having the node perform the broadcasting, the system comprising the node.

17. The instruction further includes, when the instruction is executed by the processor, the processor: Based on the second consensus protocol determining the newly accepted block, the migration instance counter is monotonically incremented. The system according to claim 11, wherein the migration instance counter tracks each migration from the first consensus protocol to the second consensus protocol in the blockchain network, and the value of the migration instance counter represents the number of blocks previously accepted as an identifier for the migration instance.

18. The system according to claim 11, wherein the second consensus protocol is a quorum-based asynchronous Byzantine fault tolerance protocol.

19. The instruction further includes, when the instruction is executed by the processor, the processor: The system according to claim 11, wherein the set of nodes maintains a flag indicating whether the second consensus protocol is running, and the flag includes the ID of the last completed instance.

20. A non-temporary computer-readable storage medium that includes instructions stored therein, wherein when an instruction is executed by one or more processors, the one or more processors are instructed to perform a method, and the method is In a set of nodes on a blockchain network, the first consensus protocol is to be run, In the set of nodes, detect a liveness attack within the first consensus protocol. When the aforementioned liveness attack is detected, the acceptance of new blocks into the first consensus protocol is temporarily suspended, Based on the preferred blocks, the first consensus protocol is operated to identify the block that is most accepted in the set of nodes, The most highly accepted block will be used to set the initial basic settings for the second consensus protocol, The transition is to move from the first consensus protocol to the second consensus protocol, wherein the second consensus protocol operates until a newly accepted block is confirmed. A non-temporary computer-readable storage medium, comprising restoring the first consensus protocol based on the confirmation of the newly accepted block, wherein the first consensus protocol is restored to its state after the newly accepted block.

Images