Metastable Byzantine Agreement

Abstract

An apparatus includes a first processing node configured to participate in a consensus protocol with a plurality of additional processing nodes. The first processing node is further configured in conjunction with its participation in the consensus protocol to implement repeated polling of respective selected subsets of the additional processing nodes, resolve a state of a given transaction to a particular one of a plurality of possible states of the given transaction in response to a result of the repeated polling, and initiate at least one automatic action based at least in part on the resolved state of the given transaction. In some embodiments, the first processing node utilizes the result of the repeated polling to maintain a directed acyclic graph or other data structure of transactions that characterizes a relationship between the given transaction and a plurality of other transactions.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 669,734, filed on May 10, 2018, entitled “Metastable Byzantine Agreement,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The field relates generally to information security and, more particularly, to consensus protocols for use in cryptocurrencies and other applications. Background Art

[0004] Many Byzantine Fault Tolerant (BFT) protocols are known in the prior art. These protocols can in some cases be considered to belong to a subfield of computer science known as "distributed computing". For example, BFT protocols can be used to allow a group of mutually distrusting machines (e.g., servers) to reach an agreement. This agreement is also called "consensus". Typically, as long as no more than a maximum threshold number of servers are damaged (e.g., may behave arbitrarily and may attempt to prevent the network from reaching a consensus), the BFT protocol will be able to operate normally in this case. Conventional BFT protocols include the Nakamoto consensus protocol used in cryptocurrencies such as Bitcoin and Ethereum. Summary of the invention

[0005] The illustrative embodiments provide an improved consensus protocol for use in cryptocurrencies and other applications. In some embodiments, the consensus protocol more specifically includes a leaderless BFT protocol illustratively built on a metastable network detection mechanism.

[0006] For example, some embodiments use a metastable network polling mechanism to reach consensus. The above-mentioned Nakamoto consensus protocols use proof of work to reach consensus, which makes them very inefficient. In contrast, the metastable consensus protocols in the illustrative embodiments described herein are static when no decision is made and do not require proof of work, although some embodiments can be used in combination with proof of work.

[0007] Classical consensus protocols that do not use proof-of-work typically rely on an all-to-all broadcast mechanism that is typically facilitated by a leader. These protocols typically, but not necessarily, incur quadratic message complexity costs. Furthermore, the presence of a leader often creates a performance bottleneck. Some conventional protocols of this type require many rounds of communication until consensus is reached, with all-to-all communication required in each round. For these and other reasons, conventional approaches typically do not scale to large numbers of servers.

[0008] In contrast, the metastable consensus protocol in the illustrative embodiments described herein may be configured to repeatedly sample the network.

[0009] As a result, the metastable consensus protocol in these illustrative embodiments scales well with network size and is very efficient in terms of message complexity, providing higher throughput and lower latency than conventional systems.

[0010] In addition, some embodiments implement techniques for amortizing costs by constructing a directed acyclic graph (DAG) or other data structure that allows a single network poll to implicitly vote for several transactions simultaneously, although it should be understood that it is not necessary to use a DAG or other type of data structure to amortize costs. Examples of other types of data structures that may be used in illustrative embodiments include linked lists of transactions and hash-linked chains of transactions. In some embodiments, the DAG is implemented in the form of a linear, ordered, chained data structure that is configured not only to resolve transaction conflicts, but also to provide a platform in which a consistent, fully ordered log is replicated across the network.

[0011] Although suitable for efficient and large-scale deployment of cryptocurrencies, the disclosed technology can be applied to various other types of applications, including applications outside of cryptocurrency scenarios. For example, the metastable consensus protocol disclosed herein can be used to implement wide-area consensus for certain settings in computer networks.

[0012] In one embodiment, an apparatus includes a first processing node configured to participate in a consensus protocol with a plurality of additional processing nodes. The first processing node is further configured in conjunction with its participation in the consensus protocol to implement repeated polling of respective selected subsets of the additional processing nodes, resolve a state of a given transaction to a particular one of a plurality of possible states of the given transaction in response to a result of the repeated polling, and initiate at least one automatic action based at least in part on the resolved state of the given transaction.

[0013] In some embodiments, resolving the state of a given transaction includes utilizing the results of repeated polling to determine whether the given transaction should be accepted as a valid transaction. Such acceptance of a given transaction as a valid transaction is considered an example of what is more generally referred to herein as "resolving" the "state" of a given transaction. In other embodiments, various other types of transactions, each having multiple possible states that are affected by consensus-based resolution of a particular state, may be processed.

[0014] In some embodiments, the repeated polling is repeated for multiple iterations, wherein a given one of the iterations includes selecting a sample of additional processing nodes and sending a query to a corresponding node in the selected additional processing nodes. In some embodiments, the sample includes a probabilistic sample that is illustratively randomly selected. As another example, the sample can be selected in a deterministic manner (possibly using a seed).

[0015] In response to receiving at least a threshold number of responses to the query, the first processing node determines whether at least a specified portion of the received responses indicates a particular state of the given transaction that is different from a current state of the given transaction in the first processing node. Alternatively, such a determination may be made in response to reaching a particular timeout if sufficient responses were not received before reaching the particular timeout.

[0016] In response to the designated portion of the received response indicating a specific state of the given transaction that is different from a current state of the given transaction in the first processing node, the first processing node updates its current state of the given transaction to the specific state.

[0017] Additionally or alternatively, in some embodiments, the first processing node is configured to maintain a DAG of transactions characterizing relationships between a given transaction and a plurality of other transactions, wherein the transactions are partitioned into mutually exclusive conflict sets. In a given such embodiment, maintaining the DAG illustratively includes selecting a sample of additional processing nodes, sending queries to corresponding ones of the selected additional processing nodes, and updating the DAG based at least in part on responses to the queries. In this embodiment, updating the DAG illustratively includes inserting one or more additional transactions into the DAG, updating confidence values ​​of corresponding ones of the transactions of the DAG, and / or repartitioning the transactions of the DAG into mutually exclusive conflict sets. Again, other types of data structures, such as linked lists and hash-linked chains, may be used in other embodiments.

[0018] These and other illustrative embodiments of the present invention include, but are not limited to, systems, methods, apparatus, processing devices, integrated circuits, and computer program products including processor-readable storage media having software program code embodied therein. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 An information processing system configured with functionality for implementing a consensus protocol for a metastable Byzantine agreement in an illustrative embodiment is shown.

[0020] Figures 2 to 7 A set of example pseudocodes illustrating different variations of the consensus protocol in the illustrative embodiments are shown.

[0021] Figure 8 and Fig. 9 An example of a DAG generated according to a consensus protocol in an illustrative embodiment is shown. DETAILED DESCRIPTION

[0022] Embodiments of the present invention may be implemented, for example, in the form of an information processing system including a computer network or other arrangements of networks, clients, servers, processing devices, and other components. Illustrative embodiments of such systems will be described in detail herein. However, it should be understood that embodiments of the present invention are more generally applicable to various other types of information processing systems and associated networks, clients, servers, processing devices, or other components. Therefore, the term "information processing system" used herein is intended to be interpreted broadly to encompass these and other arrangements. The term "processing device" used herein is similarly intended to be interpreted broadly to further encompass, for example, robots and other automata.

[0023] Figure 1 An information processing system 100 for implementing a consensus protocol for metastable Byzantine agreement in an illustrative embodiment is shown. System 100 includes a plurality of consensus protocol nodes 102-1, 102-2, 102-3, ..., 102-N. Consensus protocol nodes 102 are configured to communicate with each other via a network 105. System 100 also includes a plurality of client devices 104, including client devices 104-1 and 104-2 coupled to network 105 via respective consensus protocol nodes 102-1 and 102-2, and additional client devices 104-m to 104-M coupled directly to network 105. Many other arrangements are possible.

[0024] For example, in some embodiments, each of the client devices 104 is coupled to the network 105 via a corresponding one of the consensus protocol nodes 102. As another example, one or more of the client devices 104 may have a corresponding one of the consensus protocol nodes 102 included therein.

[0025] Each of the client devices 104-m to 104-M directly coupled to the network may be configured to include a consensus protocol node as its internal component, for example in conjunction with other types of internal components configured to perform various other functions. In some embodiments, there are no client devices 104-m to 104-M directly coupled to the network at all.

[0026] It should be noted that in Figure 1 Some of the variables m, M, and N used in the embodiments of the reference node 102 and the client device 104 are used differently in other contexts elsewhere in this document. The different meanings will be clear from the respective different contexts.

[0027] Consensus protocol nodes 102 are examples of what are more generally referred to herein as "processing nodes (each including a processor coupled to a memory)". In some embodiments, such processing nodes are implemented as, or as part of, respective processing devices. Examples of processing nodes (as that term is used broadly herein) include computers, servers, and other types of machines. As a more specific example, in some embodiments, at least a subset of consensus protocol nodes 102 are implemented as respective servers.

[0028] Each of the consensus protocol nodes 102 is configured to participate in a consensus protocol with other consensus protocol nodes in the consensus protocol nodes 102, as will be described in more detail below. A given processing device may implement a consensus protocol node and other related functionality.

[0029] One or more of the client devices 104 may each include, for example, a laptop, a tablet or a desktop personal computer, a mobile phone or another type of computer or communication device, an embedded device or a robot, and combinations of a plurality of such devices. As described above, in some embodiments, at least one of the client devices may implement a corresponding one of the consensus protocol nodes 102. The client devices 104 illustratively generate transactions processed by the consensus protocol nodes 102. The client devices 104 are more generally referred to herein as corresponding “clients”.

[0030] It is assumed that communications between the various elements of system 100 occur via one or more networks, collectively represented in the figure by network 105. Network 105 may illustratively include, for example, a global computer network such as the Internet, a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network implemented using a wireless protocol (such as WiFi or WiMAX), or various portions or combinations of these and other types of communication networks.

[0031] The consensus protocol node 102-1 shown in the figure includes a processor 120, a memory 122, and a network interface 124. The processor 120 is operably coupled to the memory 122 and to the network interface 124. The processor 120 is configured to execute software program code 121 for implementing functions associated with the consensus protocol of the metastable Byzantine agreement.

[0032] The processor 120 may include, for example, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a central processing unit (CPU), an arithmetic logic unit (ALU), a graphics processing unit (GPU), a digital signal processor (DSP), or other similar processing device components, as well as other types and arrangements of processing circuits, in any combination. At least a portion of the software program code 121 executed by the processor 120 is also stored in the memory 122 and retrieved therefrom by the processor 120 for execution.

[0033] Such a given memory storing such program code for execution by a corresponding processor is an example of what is more generally referred to herein as a processor-readable storage medium having program code implemented therein, and may include, for example, electronic memory such as SRAM, DRAM or other types of random access memory, read-only memory (ROM), flash memory, magnetic storage, optical storage, or other types of storage devices in any combination.

[0034] Articles of manufacture including such processor-readable storage media are considered embodiments of the present invention.The term "article of manufacture" as used herein should be understood to exclude transitory, propagating signals.

[0035] In other embodiments, other types of computer program products including processor-readable storage media may be implemented.

[0036] Furthermore, embodiments of the present invention may be implemented in the form of an integrated circuit including processing circuitry configured to implement processing operations associated with the consensus protocol for metastable Byzantine agreement disclosed herein.

[0037] The network interface 124 is configured to allow the consensus protocol node 102 - 1 to communicate with other system elements over the network 105 , and illustratively includes one or more conventional transceivers.

[0038] The consensus protocol node 102-1 also includes a sub-sampled polling module 130, a confidence and / or confidence counter 132, and a directed acyclic graph of known transactions 134. At least a portion of one or more of the sub-sampled polling module 130, the counter 132, and the DAG 134 of the consensus protocol node 102-1 can be implemented at least in part using software stored in the memory 122 and executed by the processor 120. For example, the consensus protocol of the metastable Byzantine agreement disclosed herein illustratively involves sampling other nodes in the consensus protocol node 102 using the sub-sampled polling module 130, and maintaining the counter 132 and the DAG 134.

[0039] As previously mentioned, the term "directed acyclic graph" or DAG as used herein is intended to be interpreted broadly. Moreover, various non-DAG data structures may be used in other embodiments, or a DAG or other data structure may not be used at all, such as in embodiments involving singleton decision making. Therefore, it should be understood that in other embodiments, the DAG 134 may be replaced with other types of data structures or not used at all.

[0040] Assume that each of the other consensus protocol nodes 102 of the system 100 is configured in a manner similar to that described above for consensus protocol node 102-1. Other processing node configurations may be used in other embodiments.

[0041] In operation, when executing a consensus protocol of the type disclosed herein, each of the consensus protocol nodes 102 interacts with a selected subset of other peers in the consensus protocol nodes 102. For example, the consensus protocol node 102-1 implements repeated polling of the corresponding selected subset of other consensus protocol nodes 102 via its subsampled polling module 130, resolves the state of a given transaction to a specific one of a plurality of possible states of the given transaction in response to the results of the repeated polling, and initiates at least one automatic action based at least in part on the resolved state of the given transaction. The repeated polling can be performed on a subset of nodes selected in a probabilistic manner (i.e., randomly) or in a deterministic manner.

[0042] In some embodiments, a given transaction comprises a cryptocurrency transaction, although various other types of transactions may be supported. Thus, the term "transaction" as used herein is intended to be interpreted broadly. For example, parsing the state of a given transaction (as that term is used broadly herein) may include determining a particular one of multiple possible values ​​for a variable, determining whether a command or script should be executed, etc. Thus, a given transaction may include any type of information element having multiple possible states that are suitable for consensus-based parsing of a particular one of the possible values ​​by a consensus protocol node 102 of the system 100.

[0043] In the following, we will combine Figures 2 to 4 In the described exemplary embodiment, parsing a given transaction includes determining a specific value of a variable, such as {red or blue} or {accept or reject}, for example, by executing a consensus protocol. Figures 5 to 9 Other embodiments described refer more generally to transactions.

[0044] It should be understood that in this regard, some embodiments may be configured to support multi-value consensus and / or multi-transaction consensus, as well as other arrangements involving different numbers of candidates. Thus, the illustrative embodiments may resolve states between one, two, or more candidates, and should not be considered limited to any particular bivalent example disclosed herein.

[0045] The consensus protocol nodes 102 are illustratively configured to unanimously “obey” in the direction of the majority, or in other words, “dump” toward a particular state (such as Figures 2 to 4 102) of a certain consensus. Thus, once consensus is reached, the interaction of consensus protocol nodes 102 causes the state of a given transaction to be resolved into a specific one of multiple possible states. The state of a given transaction before its resolution is also referred to herein as a "metastable state". The consensus protocol in this type of embodiment is referred to herein as a metastable consensus protocol.

[0046] In such an embodiment, each of the consensus protocol nodes 102 illustratively selects, establishes, or otherwise determines an initial state for a given transaction, repeatedly samples different subsets of the other consensus protocol nodes 102 in order to determine a particular state currently preferred by those sampled subsets of nodes, and if a threshold is met, defers to the majority state preference. This repeated sampling is illustratively performed by all consensus protocol nodes 102 substantially simultaneously, while each of these nodes performs a sub-sampling poll relative to the other nodes in the node. The consensus protocol nodes 102 with the highest likelihood ultimately reach a consensus on a particular state for a given transaction. As described above, until a consensus on the state is reached by the consensus protocol nodes 102, the state remains unresolved. However, it may evolve over time, for example, from "unknown" to "likely" to "accepted" or otherwise resolved.

[0047] The metastable protocol in the illustrative embodiment is configured to provide Byzantine fault tolerance, as will be described in more detail elsewhere herein.

[0048] Automated actions initiated based at least in part on the resolved state of a given transaction may include various actions associated with the maintenance of the distributed ledger, although many other automated actions may be performed, such as initiating the execution of a command or script.

[0049] For example, in some embodiments, an automated action initiated by consensus protocol node 102-1 based at least in part on the parsed state of a given transaction includes adding an entry representing the given transaction to a distributed ledger maintained jointly by first consensus protocol node 102-1 and other nodes in consensus protocol node 102.

[0050] In some embodiments involving cryptocurrencies, entries in this type of arrangement illustratively include blocks, and the distributed ledger includes a blockchain. A given such blockchain is typically modeled as a plurality of linear chained blocks, but the illustrative embodiments herein more generally refer to a blockchain as any arrangement of structured blocks that potentially encompasses transaction and / or contract information. Therefore, embodiments herein involving blockchains should not be considered limited to linear chained blocks.

[0051] In some embodiments, the blockchain comprises a cryptocurrency blockchain collectively maintained by consensus protocol nodes 102. In such embodiments, a given transaction may comprise, for example, a blockchain transaction for associating a specified amount of cryptocurrency with a cryptocurrency address.

[0052] As noted above, the term "blockchain" as used herein is intended to be interpreted broadly so as to encompass distributed ledgers and other similar arrangements jointly maintained by multiple processing devices performing cryptographic operations involving related blocks of data.

[0053] Thus, blockchains used in embodiments herein may include, for example, "permissionless" or public blockchains (in which any user can participate in building consensus for validation of blockchain transactions), and "permissioned" or private blockchains (in which only a restricted set of users can participate in building consensus for validation of blockchain transactions). In some embodiments, the set of entrants may be restricted using Sybil control mechanisms that illustratively require entrants to present resources in order to limit the number of identities that a single user can represent, including proof of work, proof of stake, proof of authority, proof of space, proof of time, proof of elapsed time, etc., and combinations thereof.

[0054] In some embodiments, a given blockchain may include one or more smart contract programs. Such smart contract programs of the blockchain may themselves include multiple separate programs.

[0055] Other embodiments may be configured to utilize a metastable Byzantine agreement consensus protocol of the type disclosed herein to process payments or other transactions that do not involve a blockchain.

[0056] In some embodiments, the participation of specific nodes in the consensus protocol nodes 102 is controlled according to at least one specified control mechanism that requires each of the consensus protocol nodes 102 to submit one or more specified proofs. In some embodiments, the specified proofs illustratively include proofs other than proof of work, such as the above-mentioned proof of stake or proof of authority. However, it should be understood that some embodiments can be configured to utilize proof of work as a control mechanism. Such proofs given in the illustrative embodiments herein are used to address the problem of Sybil attacks, rather than being used to reach consensus as in some conventional protocols.

[0057] The repeated polling performed by the sub-sampled polling module 130 illustratively repeats a plurality of iterations. In some embodiments, the number of iterations is approximately logarithmic in the number of consensus protocol nodes 102, although such an arrangement is not required. Other types of repeated polling may be used in other embodiments. Terms used herein (such as "sub-sampled polling") are intended to be broadly interpreted to encompass, for example, an agreement in which a consensus protocol node 102-1 randomly or otherwise selects a different subset of other protocol nodes 102 to poll in each of a plurality of polling intervals.

[0058] Such polling is considered "sub-sampled" because the number of other consensus protocol nodes 102 polled by consensus protocol node 102-1 in each of the polling intervals is less than the total number N-1 of other consensus protocol nodes 102 in the system. For example, a given sample of consensus protocol nodes 102 selected for polling in a particular polling interval illustratively comprises a probabilistic sample, illustratively selected randomly using a pseudo-random number generator (PRNG) or other similar arrangement. This type of embodiment is referred to herein as performing probabilistic polling. As another example, samples may be selected in a deterministic manner (possibly using a seed). In such a deterministic sampling arrangement, any deterministic function may be used. Thus, the illustrative embodiments are not limited in terms of the particular sampling type used to select a subset of the consensus protocol for polling.

[0059] In this regard, it should also be noted that the number of nodes polled in the exemplary embodiments disclosed herein is typically much smaller than the number of nodes involved in conventional BFT protocols. For example, conventional BFT protocols typically require at least about 2 / 3 of the N nodes to be involved, or even potentially more than 2 / 3 of the N nodes, while the exemplary embodiments disclosed herein can be configured to utilize polling of a very small sub-sampling of the N nodes, thereby providing significant advantages over conventional BFT protocols.

[0060] The consensus protocol nodes 102 are also collectively referred to as a “network,” and polling of subsamples is referred to as “sampling the network.” An information processing system (such as system 100 ) that includes such a network of consensus protocol nodes is also referred to herein simply as a “system.”

[0061] In some embodiments, consensus protocol node 102-1 is configured to maintain a DAG 134 of known transactions using the results of repeated polling. DAG 134 illustratively represents the relationship between a given transaction and multiple other transactions. DAG 134 is an example of what is more generally referred to herein as a "data structure" that represents known transactions. In other embodiments, other types of data structures that can be used in place of DAG 134 include, for example, linked lists of transactions and hashed linked chains of transactions. Such data structures can take a variety of different types of formats, including tree-based formats, and the illustrative embodiments are not limited in this regard.

[0062] In some embodiments, DAG 134 itself is implemented in the form of a linear ordered chain data structure that is not only configured to resolve transaction conflicts, but also configured to provide a platform in which a consistent, fully ordered log is replicated across the network. In such an embodiment, each entry of the log can be used as a container for specified common user data. For example, the state transition of an application can be encoded as a command in each container. Therefore, the correct node will have a consistent replication of the application state in order to provide a fault-tolerant service.

[0063] The term "directed acyclic graph" as used herein is intended to be interpreted broadly to encompass such data structures. It should also be understood that other embodiments need not maintain or otherwise utilize a DAG or other data structure of known transactions when parsing the status of a given transaction.

[0064] In some embodiments, resolving the status of a given transaction in response to the result of repeated polling includes using the result of repeated polling to determine whether the given transaction should be accepted as a valid transaction. It should be noted in this regard that invalid transactions can never be accepted, but not all valid transactions will be accepted. Therefore, a valid transaction can have its possible states, for example, at least two states {accepted or rejected}. More generally, there are three possible states in this example, namely accepted, rejected and undecided, where undecided means that one of the first two states has not been reached.

[0065] As previously described, resolving the state of a given transaction in response to the results of repeated polling can involve determining a particular one of multiple possible values ​​for a variable, determining whether a command or script should be executed, etc. In other embodiments, these transactions and various other types of transactions that are affected by consensus-based resolution can be used. Therefore, accepting a given transaction as a valid transaction is considered an example of what is more generally referred to as "resolving" the "state" of a given transaction in this document. Various other arrangements can be used in conjunction with resolving the state of a given transaction (as that term is used broadly herein). Therefore, the illustrative embodiment referring to accepting a transaction should not be viewed as limiting in any way a particular manner of resolving the state of a transaction.

[0066] As described above, the repeated polling is illustratively repeated for a plurality of iterations. In some embodiments, a given one of the iterations performed by the consensus protocol node 102 - 1 more particularly includes selecting a sample of other consensus protocol nodes 102 and sending a query to a corresponding node in the selected consensus protocol nodes 102 .

[0067] In response to receiving at least a threshold number of responses to the query, consensus protocol node 102-1 determines whether at least a specified portion of the received responses indicates a particular state of the given transaction that is different from a current state of the given transaction in consensus protocol node 102-1. Alternatively, such a determination may be made in response to reaching a particular timeout if the threshold number of responses are not received before reaching the particular timeout.

[0068] In response to the designated portion of the received response indicating a specific state of the given transaction that is different from the current state of the given transaction in the consensus protocol node 102-1, the consensus protocol node 102-1 updates the current state of the given transaction in the first processing node to the specific state.

[0069] In such embodiments, resolving the state of the given transaction in response to the results of the repeated polling illustratively includes resolving the state of the given transaction to a current state upon completion of the plurality of iterations.

[0070] In some embodiments, when resolving the status of a given transaction, consensus protocol node 102-1 utilizes one or more of counters 132. Counters 132 illustratively include at least one certainty counter and / or at least one confidence counter.

[0071] For example, in some embodiments, consensus protocol node 102-1 maintains a confidence strength counter indicating a number of consecutive iterations of repeated polling for which at least a specified portion of the received response indicates a particular state of a given transaction. In such embodiments, resolving the state of the given transaction in response to the result of the repeated polling illustratively includes resolving the state of the given transaction to a particular state in response to the confidence strength counter exceeding a threshold.

[0072] Additionally or alternatively, consensus protocol node 102-1 maintains confidence counters for respective ones of the possible states of a given transaction, wherein each of the confidence counters indicates a total number of queries in a plurality of iterations that have produced responses indicating the corresponding state in those iterations. In such an embodiment, resolving the state of the given transaction in response to the results of repeated polling illustratively includes resolving the state of the given transaction to the possible state in response to the confidence counter of one of the possible states exceeding the confidence counter of at least one other one of the possible states.

[0073] In some embodiments of this type, where there are more than two possible states for a given transaction, resolving the state of the given transaction illustratively includes resolving the state of the given transaction to one of the more than two possible states in response to a confidence counter for the possible state exceeding confidence counters for all other possible states. Other embodiments may specify additional or alternative requirements for resolving the state of a given transaction.

[0074] In some embodiments, a poll in which a specified portion of a response indicates a particular status of a transaction may implicitly indicate the particular status of multiple other potentially related transactions. For example, if the system determines that a first user, Alice, spent all of her cryptocurrency coins with a second user, Bob, the system may simultaneously determine that she did not spend those coins with a third user, Charlie.

[0075] As described above, the consensus protocol node 102-1 in the illustrative embodiment maintains a DAG 134 of known transactions. The DAG 134 characterizes the relationship between a given transaction and multiple other transactions. In some embodiments of this type, transactions are divided into mutually exclusive conflict sets, where the concept of conflict is application-defined and can therefore vary from embodiment to embodiment based on factors such as the specific type of transaction being processed. Transactions that conflict with each other are referred to herein as forming a conflict set, in which only a single transaction can be accepted. This acceptance of a single transaction of a conflict set is an example of what is more generally referred to herein as "resolving" the "state" of the transaction.

[0076] Maintaining the DAG 134 in such an embodiment more particularly includes selecting a sample of consensus protocol nodes 102, sending queries to corresponding nodes in the selected consensus protocol nodes 102, and updating the DAG 134 based at least in part on responses to the queries. For example, updating the DAG 134 includes inserting one or more additional transactions into the DAG 134, updating confidence values ​​of corresponding transactions in transactions of the DAG 134, and / or repartitioning transactions of the DAG 134 into mutually exclusive conflict sets. Resolving the state of a given transaction in response to the result of repeated polling in such an embodiment illustratively includes resolving the state in response to the given transaction being the only transaction in its conflict set and the given transaction having a confidence value exceeding a threshold. As another example, resolving the state of a given transaction in response to the result of repeated polling may include resolving the state to one of a plurality of possible states in response to a confidence counter of the possible state exceeding a confidence counter of at least one other state in the possible states.

[0077] As mentioned above, each of the other consensus protocol nodes 102 is illustratively configured to operate in a manner similar to the above-described consensus protocol node 102-1 so as to allow the consensus protocol nodes 102 to collectively reach a consensus on a particular state of a given transaction from among multiple possible states of the given transaction.

[0078] It should be understood that Figure 1 The specific arrangements of components and other system elements shown in are presented by way of illustrative example only, and many alternative embodiments are possible. For example, one or more of the consensus protocol node 102 and the client device 104 may each include additional or alternative components, such as a cryptocurrency wallet used in conjunction with making or receiving cryptocurrency payments associated with a cryptocurrency account. Moreover, as previously described, in some embodiments, a given processing device of the system 100 may include both a consensus protocol node and a client device. Other types of processing nodes, such as blockchain nodes, may be used additionally or alternatively. A variety of alternative arrangements of processing nodes and associated processing devices may be used.

[0079] It should also be understood that the illustrative embodiments are not limited to use with blockchains or cryptocurrencies or any other particular type of transaction. Thus, the metastable consensus protocol of the type disclosed herein can be adapted in a straightforward manner for use with a variety of other types of transactions. Thus, the term "transaction" as used herein is intended to be interpreted broadly so as to encompass, for example, commands or scripts to be executed, or any other type of information element suitable for parsing using the disclosed consensus protocol.

[0080] Now refer to Figures 2 to 9 Describes additional details about the operation of the illustrative embodiments. The embodiments include an example family of metastable consensus protocols, including variants called Slush, Snowflake, Snowball, and Avalanche. These protocol variants are considered to be respective illustrative embodiments, and thus the specific details of their corresponding implementations described below should not be construed as limiting in any way. Such protocol variants may also be viewed as more detailed implementations of the metastable consensus protocol arrangement of the system 100 as previously described.

[0081] As mentioned earlier, conventional BFT protocols include the Nakamoto consensus protocol used in cryptocurrencies such as Bitcoin and Ethereum. Reaching agreement between a group of distributed processing nodes is often at the heart of countless applications, from Internet-scale services serving billions of people to cryptocurrencies worth billions of dollars.

[0082] So far, there have been two major families of solutions to this problem. Traditional consensus protocols rely on all-to-all communication to ensure that all correct nodes make the same decision with absolute certainty. Because they require quadratic communication overhead and accurate knowledge of the members, they are difficult to scale to a large number of participants.

[0083] On the other hand, Nakamoto consensus protocols provide probabilistic safety guarantees: Nakamoto consensus decisions may be reversed with some probability ε. Protocol parameters allow this probability to be arbitrarily small, allowing high-value financial systems to be built on top of it. This family is a natural fit for open, permissionless settings, where any node can join the system at any time. However, these consensus protocols are costly, wasteful, and limited in performance. By construction, they cannot sleep, as their security relies on the continued participation of miners, even when there are no decisions to be made. Mining associated with Bitcoin currently consumes energy at a rate of around 60TWh / year. Furthermore, these and other conventional BFT consensus protocols suffer from inherent scalability bottlenecks that are difficult to overcome by simple reparameterization.

[0084] The following will be combined Figures 2 to 9 The described illustrative embodiments provide a new family of consensus protocols. Inspired by the gossip algorithm, this family obtains its security through an intentional metastable mechanism. Specifically, the system operates by randomly repeatedly sampling the network and steering correct nodes towards the same outcome. Analysis shows that this metastable mechanism is powerful: it can quickly move larger networks to a state that is effectively irreversible.

[0085] Similar to Nakamoto consensus, the family of protocols in these illustrative embodiments provide probabilistic security guarantees using a tunable security parameter that can make the probability of consensus failure arbitrarily small. Unlike Nakamoto consensus, the protocols are green, static, and efficient; they do not rely on proof of work and do not consume energy when no decisions are to be made. The efficiency of the protocols in these illustrative embodiments is at least partially due to the following features: for some small security parameter k, each node requires communication overhead ranging from O(klogn) to O(k) (whereas leader-based consensus protocols have one or more nodes that require O(n) communication), and the protocols only establish partial order between related transactions.

[0086] As will be described in more detail below, the consensus protocol in these embodiments is schematically configured to guarantee liveness only for "benign" transactions, i.e., those transactions that are issued by the correct client and are therefore guaranteed not to conflict with other transactions. In a cryptocurrency setting, cryptographic signatures enforce that only key owners can create transactions that spend specific coins. Since the correct clients follow the prescribed protocol, their security and liveness are guaranteed. In contrast, the protocol to be described cannot guarantee liveness for conflicting malicious transactions submitted by Byzantine clients. Such decisions may stall the network, but have no security impact on benign transactions. We show that this is a sensible tradeoff and that the resulting system is sufficient to build complex payment systems.

[0087] Thus, the illustrative embodiments provide a new family of consensus protocols based on random sampling and metastable decisions, with strong probabilistic safety guarantees and liveness guarantees for correct clients.

[0088] The following description of the protocol family starts with the non-Byzantine protocol Slush and gradually builds up to Snowflake, Snowball, and Avalanche, all based on a common metastable mechanism. Slush, Snowflake, and Snowball are single-decree binary consensus protocols with increased robustness, and Avalanche extends Snowball to a complete cryptocurrency solution. It will be apparent to those skilled in the art that other extensions for other applications are possible.

[0089] Like Bitcoin's Nakamoto consensus, we use probabilistic security guarantees. This probabilistic guarantee is indistinguishable from traditional security guarantees in practice, because appropriately small choices of ε can make consensus failures practically infeasible, much less frequent than CPU miscalculations or hash collisions.

[0090] This family of protocols together enables the system to implement a useful Bitcoin-like cryptocurrency, but with much better performance and scalability. In other embodiments, other applications involving large-scale probabilistic consensus can be built. In these illustrative embodiments, we focus on cryptocurrency applications due to the many challenges they pose.

[0091] We assume that the node set By the correct node and Byzantine nodes Composition, among which For illustration purposes, we adopt what is commonly referred to as the unspent transaction output (UTXO) model of Bitcoin. In this model, clients are authenticated and issue cryptographically signed transactions that completely consume existing UTXO and issue new UTXO. Unlike nodes, clients do not participate in the decision-making process and only provide transactions to nodes running the consensus protocol. If two transactions consume the same UTXO and produce different outputs, the two transactions conflict. A correct client never issues a conflicting transaction, and it is impossible for a Byzantine client to forge a conflict with a transaction issued by a correct client. However, a Byzantine client can issue multiple transactions that conflict with each other, and the correct client can only consume one of these transactions. Therefore, in these illustrative embodiments, the goal of the consensus protocol family is to accept a non-conflicting set of transactions in the presence of Byzantine behavior. Each client can be considered a replicated state machine (RSM) whose transitions are defined by a completely ordered list of accepted transactions. Again, this acceptance of a given transaction is an example of what is more generally referred to as "the state of resolving a given transaction" in this article.

[0092] The protocol family provides the following guarantees with high probability ("whp"):

[0093] Property P1: Safety. No two correct nodes will accept conflicting transactions.

[0094] Property P2: Liveness. Any transaction published by a correct client (a “good transaction”) will eventually be accepted by every correct node.

[0095] Our approach is not an unconditional agreement, but rather a guarantee that security will be maintained with probability 1-ε, where the choice of the security parameter ε is under the control of the system designer and the application.

[0096] The analysis for the illustrative embodiments assumes a strong adaptive adversary, e.g., one that can observe the internal state and communications of each node in the network but cannot interfere with communications between correct nodes. It is not assumed that all participants know all members of the network, but rather that there may be some temporary variability in the network view. A secure bootstrapping system (similar to Bitcoin's bootstrapping system) is assumed that enables nodes to connect to enough correct nodes to obtain a statistically unbiased view of the network. A public key infrastructure (PKI) is not assumed. Standard cryptographic difficulty assumptions associated with public key signatures and hash functions are made.

[0097] Figure 2A simple metastable protocol (referred to herein as Slush) in an illustrative embodiment is shown. Slush is not tolerant to Byzantine faults, but is used for illustration of the BFT protocol that follows. For ease of illustration, the operation of Slush will be described using a decision between two conflicting colors (red and blue). This decision about multiple possible values ​​for a variable is an example of what is more generally referred to herein as the state of resolving a given transaction.

[0098] In Slush, nodes are initially in the uncolored state. When receiving a transaction from a client, an uncolored node updates its own color to the color carried in the transaction and initiates a query. To perform a query, a node uniformly randomly selects a small, constant-size (k) sample of the network and sends a query message. Upon receiving a query, an uncolored node adopts the color in the query, responds with that color, and initiates its own query, while a colored node simply responds with its current color. Once the querying node has collected k responses, or after a specific timeout is reached, it checks if the score for the same color is ≥ αk, where α>0.5 is a protocol parameter. If αk reaches a threshold and the sampled color is different from the node's own color, the node flips to that color. It then returns to the query step and initiates a subsequent round of queries, lasting a total of m rounds. Finally, the node decides on its color, which ends at time m. It should be noted that timeouts are omitted in the figure for readability.

[0099] This simple protocol has many desirable properties. First, it is almost memoryless: nodes retain no state between rounds except their current color, and in particular do not maintain a history of interactions with other nodes. Second, unlike traditional consensus protocols that query every participant, each round involves randomly sampling only a small, constant-sized slice of the network. Third, even if the network starts in a metastable state with a 50 / 50 red-blue split, random perturbations in the sampling will cause one color to gain a slight advantage, and subsequent repeated sampling will build up and amplify this imbalance. Finally, if m is chosen to be high enough, Slush can ensure that all nodes will be colored identically whp. Each node has a constant, predictable communication overhead per round, and m grows logarithmically with n.

[0100] The Slush protocol does not provide strong safety guarantees in the presence of Byzantine nodes. In particular, if the correct node develops a preference for one color, a Byzantine adversary can try to flip the node to the opposite color in order to keep the network balanced, thereby blocking the decision. We address this issue in the first BFT protocol, which introduces more state storage at the nodes.

[0101] Figure 3A metastable protocol with BFT built on the previously described Slush protocol is shown. Snowflake enhances Slush with a single counter that captures the node's confidence in its current color. This counter is an example of what is also referred to herein as a "confidence counter." This per-node counter stores how many consecutive samples of the network by the node have all produced the same color. When its counter exceeds another safety parameter β, the node accepts the current color. Figure 3 The agreement includes the following modifications:

[0102] 1. Each node maintains a counter cnt;

[0103] 2. Every time the color changes, the node resets cnt to 0;

[0104] 3. For each successful query that produces ≥αk responses of the same color as the node, the node increments cnt.

[0105] When the protocol is correctly parameterized for a given threshold of Byzantine nodes and a desired ε guarantee, it can ensure properties P1 (safety) and P2 (liveness). As shown later, there is a phase shift point after which correct nodes are more likely to favor a decision than a bivalent state. Further, there is an irreversible point after which a decision is inevitable. Byzantine nodes lose control after the phase shift, and correct nodes start committing to the same color whp after the irreversible point.

[0106] Figure 4 The next protocol, called Snowball, is shown, which adds an indication of confidence to Snowflake. Snowflake's notion of state is ephemeral: a counter is reset with each color flip. While in theory the protocol is able to make strong guarantees with minimal state, it will now be improved by introducing a more persistent notion of belief in order to make it harder to attack. Snowball augments Snowflake with confidence counters that capture multiple queries that have produced threshold results for the colors they correspond to, as shown in the figure. A node decides whether it has obtained β consecutive "credentials" for a color, which are described in more detail elsewhere in this paper. However, a node changes preferences only based on the total cumulative confidence. The differences between Snowflake and Snowball are as follows:

[0107] 1. On each successful query (ie, at least αk responses match the node color), the node increments its confidence counter for that color.

[0108] 2. When the confidence of the current color becomes lower than the confidence value of the new color, the node switches color.

[0109] Snowball is not only harder to attack than Snowflake, but is also easier to generalize to multi-legislative protocols.

[0110] Figure 5 , Figure 6 and Figure 7 Various parts of another protocol called Avalanche are shown, which extends Snowball to a multi-fiat protocol that maintains a DAG of all known transactions. The DAG has a single sink node called the "genesis vertex". Figure 8 and Fig. 9 An example of a DAG is shown in . Maintaining a DAG provides two significant benefits. First, it improves efficiency because a single vote on a DAG vertex implicitly votes on all transactions on the path to the genesis vertex. Second, it also improves security because, similar to the Bitcoin blockchain, the DAG interweaves the fate of transactions. This makes it difficult to undo past decisions without the approval of the correct nodes.

[0111] When a client creates a transaction, it names one or more parent transactions that are inseparably included in the transaction and form edges of the DAG. The parent-child relationships encoded in the DAG can, but need not, correspond to application-specific dependencies; for example, a child transaction need not spend funds received in a parent transaction, nor need it have any relationship to funds received in a parent transaction. The term "ancestor set" is used to refer to all transactions historically reachable through a parent edge, and the term "descendants" is used to refer to all child transactions and their children.

[0112] The main challenge in maintaining a DAG is choosing between conflicting transactions. As mentioned before, the concept of conflict in this article is defined for an exemplary application and can therefore vary from one implementation to another. In our cryptocurrency application, transactions that spend the same funds (double spends) conflict with each other and form a conflict set ( Figure 8 ), where only a single transaction can be accepted. Note that the conflicting set of benign transactions is always a singleton.

[0113] Avalanche embodies a Snowball instance for each conflict set. While Snowball uses repeated queries and multiple counters to capture confidence built into conflicting transactions (colors), Avalanche exploits the DAG structure and uses the descendants of transactions. Specifically, when querying for transaction T, all transactions reachable from T by following DAG edges are implicitly part of the query. Nodes only respond positively to a query if T and its entire ancestry are currently the preferred options in their respective conflict sets. If more than a threshold of responders vote positively, the transaction is said to have collected what is referred to as "credentials" in this paper. Nodes then compute their confidence as the total number of credentials in the descendants of that transaction. They query a transaction only once and build up their confidence against new vertices and possible credentials (which are added to the descendants). The initial preference for the original transaction breaks this tie. Note that the credentials are decoupled from the DAG structure, which makes the protocol immune to attacks where the attacker generates a large number of DAG vertices.

[0114] In Avalanche, each correct node u keeps track of the nodes that it has in the set All transactions learned in the above are divided into mutually exclusive conflict sets. Since conflicts are transitive, if T i and T j are conflicting, then they belong to the same conflict set, namely T j This relationship may sound counterintuitive: conflicting transformations are equivalent because they are ambiguous swaps that cost the same amount of money.

[0115] If there is a parent edge of transaction T′, then we write T′←T. A relation is the reflexive transitive closure of the path from T to T′. This ensures that DAGs constructed from different nodes are compatible. Specifically, if T′←T, then every node in the system that has T will also have T′ and the same relation T′←T; conversely, if Then no node will end with T′←T.

[0116] Each node can set the confidence value d according to its children. u (T) is calculated as follows:

[0117]

[0118] Among them C uT′ represents the credential value of T′ of node u. Before the node obtains the query result, each transaction initially has a credential value of 0. If the node collects a threshold number of supporting votes after the query, the value C uT′is set to 1, otherwise it will always remain 0. Therefore, the credential value reflects the result of a one-time query from its associated transaction and becomes immutable thereafter, while d(T) can increase as the DAG grows by collecting more credentials in its descendants. Because, the confidence value c T ∈{0,1} is monotonic.

[0119] In addition, node u maintains its own known nodes that make up the system To simplify the following explanation, we now assume that And omit the subscript u in unambiguous contexts.

[0120] Each node implements an event-driven state machine centered around queries, which are used both to request votes for each transaction and to notify other nodes of the existence of newly discovered transactions. In particular, when node u discovers transaction T through a query, it starts a one-shot query process by sampling k random peers and sending them messages, and then Figure 6 The process ONRECEIVETX delivers T.

[0121] Node u checks whether each T′ makes In competition transactions is currently preferred to answer the query. If every single ancestor T′ satisfies this criterion, then the transaction is considered highly preferred and receives an approval vote (1). Failure of this criterion for any T′ results in a negative vote (0). When u accumulates k responses, it checks whether there are αk approval votes for T and, if so, grants T’s credential (credential value c T :=1). The above process will generate a label of the DAG with the credential value and the associated confidence for each transaction T.

[0122] Figure 8 An example DAG 800 constructed by Avalanche is shown.<chit,confidence> An example of values ​​for . Darker boxes indicate transactions with higher confidence values. At most one transaction in each shaded area is accepted. Similar to Snowball, sampling in Avalanche will create positive feedback for the preferences of individual transactions in its conflict set. For example, because T2 has a greater confidence than T3, its descendants are more likely to collect credentials in the future than T3.

[0123] Similar to Bitcoin, Avalanche leaves it up to the application to determine the acceptance point of a transaction. The application provides an ISACCEPTED predicate that takes into account the value at risk in the transaction and the chance that the decision will be reversed to determine when to decide.

[0124] Committing a transaction can be performed by what is referred to in this paper as "safe early commit". For a benign transaction, T will be accepted when it is the only transaction in its conflict set and has a confidence greater than a threshold β1. As in Snowball, T can also be accepted after a threshold number of consecutive successful queries β2. In the case that a benign transaction fails to be accepted due to liveness issues with its parent transaction, it can be accepted if it is republished with a different parent transaction.

[0125] Figure 6 The pseudocode shown in shows how Avalanche performs parent selection and entangled transactions. Because transactions that consume and generate the same UTXO do not conflict with each other, any transaction can be reissued with a different parent transaction.

[0126] The Avalanche protocol main loop executed by each node consists of Figure 5 In each iteration, the node tries to select a transaction T that has not been queried yet. If no such transaction exists, the loop stops until a new transaction is added to It then selects k peers and queries these peers. If more than αk of these peers return a positive response, the credential value is set to 1. After that, it updates the preferred transaction for each conflicting transaction set in its ancestor. Next, add T to the set In this way, it will not be queried again by the node. As will be appreciated by those skilled in the art, the code for selecting an additional peer in the event that k peers do not respond is omitted for simplicity, but the code can be implemented in a straightforward manner.

[0127] Figure 7 shows what happens when a node receives a query for transaction T from peer j. First it adds T to Unless the latter already has the former. It then determines whether T is currently strongly preferred. If so, the node returns a positive response to peer j. Otherwise, it returns a negative response. Note that in the pseudocode, we assume that when a node knows T, it also recursively knows the entire ancestry of T. This can be achieved by delaying the delivery of T until its entire ancestry has been recursively obtained. In practice, an additional gossip process of propagating transactions is used in parallel, but this additional process is not shown in the pseudocode for simplicity.

[0128] It is shown that, under certain independent and different assumptions, the Avalanche family of consensus protocols described above provides property P1 (safety) and property P2 (liveness) with probability 1-ε, where ε is a safety parameter that can be set according to the needs of the system designer.

[0129] The above consensus protocol family will now be analyzed in detail with respect to properties P1 and P2 as well as other characteristics.

[0130] Regarding property P1, we analyze the protocol through the lens of a global scheduler (also called the system scheduler). Like Bitcoin and other blockchain protocols based on rumor propagation, we assume that rumors propagate to all correct nodes within a known timeframe. In other words, we assume a synchronous communication network in which the system advances in rounds and at the beginning of each round, a single correct node u is uniformly randomly selected by the global scheduler. Node u will sample and update its state before the end of the round. The Byzantine adversary will know the identity of u. Furthermore, the adversary always has full knowledge of the internal states of all nodes in the network and is able to fully update the states of all nodes under its control as soon as u selects its sample set of neighbors. Essentially, the adversary is only limited by the inability to directly update the states of correct nodes.

[0131] We can imagine the network as sets of nodes that are colored red or blue. Each new round will update the state of one of the nodes, either changing its color or increasing its confidence in its current color. The dynamics of this system are similar to those of epidemic networks, where nodes update their states using a function chosen over some probability distribution based on the states of their neighbors. It is infeasible to keep track of all possible execution paths, since in each round the possible number of branch executions is equal to the number of possible correct nodes multiplied by all possible k sampling choices that the node could sample. Furthermore, the difficulty of this task is greatly increased by the fact that a Byzantine adversary chooses its best attack strategy instead of an unknown function (which itself may be nondeterministic).

[0132] The simplification that allows us to analyze this system is to avoid the need to track all execution paths and all possible adversarial strategies, instead focusing entirely on a single state of interest without considering how this state was achieved. More specifically, the key insight of the analysis is to identify irreversible states of the system, i.e. states in which many correct nodes have usurped red or blue such that reverting to a minority color is highly unlikely.

[0133] The Slush protocol is modeled as a birth-death Markov process with two absorbing states, where all nodes are red or all nodes are blue. By construction, all states (excluding the absorbing state) are transient, meaning there is a non-zero probability of never returning to that state. Analysis shows that the Slush protocol reaches the absorbing state with non-zero probability in finite time. Furthermore, the probability of convergence to one of the two colors can be measured exactly using only a local round counter. In fact, Slush converges to the decision whp with a step size that is close to logarithmic.

[0134] For Snowflake, we relax the assumption that all nodes are correct and assume that some subset of the nodes are hostile. The important insight is that there exists an irreversible state or point of no return whp after which the system will converge to an absorbing state. Furthermore, correct nodes only determine when the system exceeds the point of no return. Combining these two guarantees, the probability of a safety violation is strictly less than ε, which can be configured as desired. As expected, there is an inherent tension between safety and liveness, but a suitable parameter can be found that is practical. Larger values ​​of k yield higher levels of safety for correct nodes at the expense of slower convergence.

[0135] Snowball is an improvement on Snowflake where random perturbations in network samples are reduced by introducing partial forms of the history, which we call confidences. Modeling Snowball with Markov chains is difficult due to the state space explosion problem. In particular, it is not enough to just keep track of the color preference of each correct node, the analysis must also maintain information about their confidences. To make the analysis possible, we build a mathematical foundation via the game of balls and urns, where each box represents one of the correct nodes and the count of balls corresponds to the confidence in any color. Using this model, the analysis applies various tail inequalities to prove that Snowball's safety guarantees are stricter than those of Snowflake. In particular, once the system has reached the point of no return, the probability of a reversal is strictly lower than in Snowflake.

[0136] Finally, Snowball's safety guarantees can be mapped to those of Avalanche, a specific instance of Snowball that uses a DAG to amortize costs. We note that the structure of the Avalanche protocol does not correspond to voting per se, which is a subtle difference between other consensus protocols that use DAGs. DAGs are merely performance optimizations and are themselves completely orthogonal to the consensus process.

[0137] Regarding property P2, we note that both Snowflake and Snowball use counters to track consecutive majority support. Since the adversary cannot forge conflicts for benign transactions, initially, all correct nodes will have either red or ⊥, where ⊥ means "not yet defined". A Byzantine node cannot respond to any query with any answer other than red, because it cannot forge conflicts, and ⊥ is not allowed by the protocol. So the only misbehavior of a Byzantine node is to refuse to answer. Since correct nodes will resample if a query times out, by expected convergence all correct nodes will end whp with a consistent red value within a finite number of rounds.

[0138] Avalanche introduces a DAG structure that entangles the fate of unrelated conflicting sets, each of which is a single fiat instance. This entanglement reflects the tension that attaching a benign transaction to an undecided parent helps push the transaction toward a decision, but when the parent turns out to be malicious, it puts the transaction at risk of suffering a liveness failure. Two mechanisms can be used to resolve this tension and provide liveness guarantees.

[0139] First, we utilize an adaptive parent selection strategy where transactions are attached to active edges of the DAG and retried with new parents that are closer to the genesis vertex. This process is guaranteed to terminate with an undisputed, decided parent transaction, thereby ensuring that transactions do not suffer liveness failures due to controversial, malicious transactions. The second mechanism ensures that benign transactions with decided ancestors will obtain sufficient credentials. Correct nodes check the DAG for benign transactions that lack sufficient children and issue no-operation ("nop") transactions to help increase their confidence. With these two mechanisms in place, it is easy to see that in the worst case, Avalanche will degenerate into a detached instance of Snowball and therefore provide the same liveness guarantees for benign transactions.

[0140] Other insights regarding the protocol family in the above exemplary embodiments include the following.

[0141] First, the protocol leads to both safety and liveness guarantees whose underlying functions are smooth rather than step functions. In many other consensus protocols, safety is guaranteed up to a fixed threshold number of adversarial nodes (e.g., 1 / 3), beyond which no guarantees are provided. In our protocol, guarantees degrade gracefully as the adversarial percentage exceeds a pre-established bound. For example, the optimal system parameters can be chosen to tolerate the presence of exactly 1 / 5 adversaries with a failure probability ε. However, if the system faces a hostile presence greater than 1 / 5, the probability of failure decreases to slightly above ε, rather than immediately decreasing to 1.

[0142] Second, these protocols embody a safety-liveness tradeoff. Even under catastrophic events, such as the presence of more than 1 / 2 adversaries, system designers can choose to guarantee safety at the expense of liveness. This is a powerful adjustment not available in classic or Nakamoto-based consensus protocols.

[0143] There are many attack vectors against consensus protocols. We now consider the two most important attack vectors, Sybil attacks and flooding attacks.

[0144] Regarding Sybil attacks, consensus protocols usually provide their guarantees based on the assumption that only a small number of participants are hostile. If the network is naively open to arbitrary participants, these bounds may be broken. In particular, Sybil attacks (in which a large number of identities are generated by adversaries) can be used to exceed hostile bounds. Sybil problems are usually treated separately from consensus, and this is correct because Sybil control mechanisms are different from the underlying, more complex agreement protocols, although this does not mean that every consensus protocol can be coupled with every Sybil control mechanism. For example, the Nakamoto formula uses proof of work to limit Sybils, which requires miners to continue to pledge hardware investments. Other protocols rely on proof of stake or proof of authority. The consensus protocols described in the above exemplary embodiments can adopt any Sybil control mechanism, although proof of stake is most consistent with their static operation. Control mechanisms such as proof of stake or proof of authority avoid the energy inefficiency associated with proof of work. Cryptocurrency can be implemented using the consensus protocol disclosed herein in combination with these and other control mechanisms for dealing with Sybil attacks.

[0145] As for flooding attacks, this attack is a potential problem for any distributed system. Without protection mechanisms, an attacker can generate a large number of transactions and flood the DAG, thereby consuming storage. There are many techniques to prevent this attack, including network layer protection, authority proof, or economic mechanisms. In Avalanche, we use transaction fees to make this attack costly even if the attacker sends money back to an address under his control.

[0146] Regarding communication complexity, since liveness cannot be guaranteed for malicious transactions, we focus on the message complexity analysis for the case of benign transactions only. For the case of benign transactions, both Snowflake and Snowball are guaranteed to terminate after O(knlogn) messages. This stems from well-known results related to epidemic algorithms. The communication complexity of Avalanche is more subtle. Let the DAG induced by Avalanche have an expected branching factor p (corresponding to the width of the DAG and determined by the parent selection algorithm). Given a decision threshold of β, transactions that have just reached a decision point will have associated children Let m be the expected depth If we advance the Avalanche network and then freeze the DAG at depth y, it will have roughly py vertices / transactions, of which p(ym) are expected to be decided. Only the pm most recent transactions will lack descendants required for decision. For each node, each query requires k samples, and thus the total message cost per transaction is expected to be (pky) / (p(ym))=ky / (ym). Since m is a constant determined by the undecided region of the DAG as the system advances, the message complexity per node is O(k), and the total complexity is O(kn).

[0147] To evaluate the operation of the exemplary embodiment, we fully ported Bitcoin transactions to Avalanche and implemented a basic payment system. We will describe below how this example implementation supports value transfer primitives at the cryptocurrency center, then examine its throughput, scalability, and latency through large-scale deployment on Amazon AWS, and finally provide a comparison with known results from other systems.

[0148] It should be understood that the specific features, parameters, and other configuration details of this example system are presented for illustrative purposes only and should not be considered requirements or limitations. It should also be noted that deploying a full cryptocurrency typically involves functions such as bootstrapping, minting, staking, unstaking, and inflation control. Known techniques can be adapted in a straightforward manner to address these issues, to the extent not explicitly addressed herein.

[0149] For the purpose of describing the example implementation, it is assumed that transactions include UTXO transactions. In addition to the DAG structure in Avalanche, the UTXO graph that captures spending dependencies is used to implement the ledger of the payment system. To avoid ambiguity, we represent transactions as data encoding transfer transactions, and we call transactions in Avalanche's DAG vertices

[0150] We inherit the transaction and address mechanism from Bitcoin. In the simplest terms, a transaction consists of multiple inputs and outputs with corresponding redeem scripts. Addresses are identified by hashes of their public keys, and signatures are generated by corresponding private keys. A full scripting language is used to ensure that the redeem script is authenticated as spending the UTXO. UTXOs are fully consumed by valid transactions, and may generate new UTXOs that can be spent by named recipients. Multi-input transactions consume multiple UTXOs, and in Avalanche, may appear in multiple conflicting sets. To illustrate this correctly, we refer to transaction input pairs (e.g., In a1 ) is represented as an Avalanche vertex.

[0151] Fig. 9An example DAG 900 is shown according to the logical DAG structure configuration used by Avalanche in this embodiment. The small shaded squares are virtual vertices. For clarity, they only help form the DAG topology and can be replaced by direct edges. The circular gray areas are conflict sets.

[0152] The conflict relation of transaction input pairs is transitive, since each pair only spends unspent outputs. We use ISACCEPTED binding on all inputs of a transaction to ensure that no transaction is accepted unless all inputs of the transaction are accepted, e.g. Fig. 9 Following this idea, we finally implemented a DAG of transaction input pairs so that each query can batch multiple transactions together.

[0153] We implemented a number of optimizations to help the system scale. First, we use lazy updates for the DAG, since the recursive definition of confidence may otherwise require a costly DAG traversal. We maintain the current value d(T) for each active vertex on the DAG and only update it when a descendant vertex gets a credential. Because the search path can be pruned at accepted vertices, the cost of updates is constant if rejected vertices have a finite number of descendants and the undecided area of ​​the DAG remains a constant size. Second, in practice, conflict sets can be very large because malicious clients can generate a large number of conflicting transactions. Instead of keeping a container data structure for each conflict set, we create a mapping from each UTXO to the preferred transaction that represents the entire conflict set. This enables nodes to quickly determine future conflicts and the appropriate response to queries. Finally, we speed up the query process by terminating early when a threshold αk is met, without waiting for k responses.

[0154] The example implementation described above was tested on Amazon EC2 by running hundreds (125) to thousands (2000) of virtual machine instances. We used c5.large instances, each of which simulated a separate node. AWS provides up to 2Gbps of bandwidth, although the Avalanche protocol utilizes around 100Mbps at most.

[0155] Our example implementation supports two versions of transactions: one is a custom UTXO format, and the other uses code directly from Bitcoin 0.16. Both supported formats use the secp256k1 cryptographic library from Bitcoin and provide the same address format for wallets. Except for cross-region replication, all simulations use the custom format, where results for both are presented.

[0156] A constant stream of new transactions from users is simulated by creating separate client processes, each of which maintains a separate wallet, generates transactions with new recipient addresses, and sends requests to the Avalanche node. Use several such client processes to maximize the capacity of the system. The number of recipients per transaction is adjusted to achieve an average transaction size of about 250 bytes (1-2 inputs / outputs per transaction on average and a stable UTXO size), the current average transaction size for Bitcoin. To efficiently utilize the network, batch up to 40 transactions in a query, but maintain confidence values ​​at the granularity of a single transaction.

[0157] All reported metrics reflect end-to-end measurements from the perspective of all clients. That is, clients check the total number of confirmed transactions per second to get throughput, and for each transaction, subtract the initiation timestamp from the confirmation timestamp to get latency. For security parameters, we utilize k=10, α=0.8, β1=11, β2=150, which yields an MTTF of approximately 1024 years. Other security parameters may be used in other embodiments.

[0158] We first measured the throughput of the system by saturating the system with transactions and examining the rate of transactions confirmed in the steady state. For this experiment, we first ran Avalanche on 125 nodes with 10 client processes, each of which maintained 400 outstanding transactions at any given time.

[0159] It was found that the system achieved 6851 transactions per second (tps) for a batch size of 20, and over 7002 tps for a batch size of 40. The system saturates with small batch sizes compared to other blockchain systems with known performance: Bitcoin batches thousands of transactions per block, Algorand uses 2 to 10 megabyte blocks, i.e. 8.4 to 41.9K tx / batch, and Conflux uses 4Mbyte blocks, i.e. 16.8K tx / batch. These conventional systems are relatively slow at making individual decisions, and therefore require very large batch (block) sizes to achieve better performance. Achieving high throughput with small batch sizes means low latency, as will be described in more detail below.

[0160] To check how the system scales with respect to the number of nodes participating in Avalanche consensus, we ran experiments with the same setup and varied the number of nodes from 125 to as high as 2000.

[0161] We found that with signature verification enabled, total throughput decreases by about 1.34% to 6909 tps when the network grows 16x to n=2000. This decrease is small compared to the performance fluctuations of repeated runs.

[0162] Avalanche derives its scalability from three sources: first, maintaining a partial order that captures only overhead relations allows more concurrency than a classic BFT replicated log that linearizes all transactions; second, the lack of a leader naturally avoids bottlenecks; and finally, the number of messages that each node must process per decision is O(k) and does not increase as the network scales.

[0163] Next, we will investigate where the bottlenecks exist in the example implementation. With signature verification disabled, throughput improves by about 2.6 times. This indicates that cryptographic verification overhead is the current bottleneck in the example implementation. This bottleneck can be addressed by offloading transaction verification to the GPU. Even without such optimizations, 7K tps far exceeds existing blockchains.

[0164] Regarding latency, the latency of a transaction is defined as the time it takes from the moment it is submitted to the moment it is confirmed to be accepted. Simulations of example implementations show that, using the same settings as the throughput measurements with 2000 nodes, most transactions are confirmed within about 0.3 seconds. The most common latency is about 206 milliseconds and has low variance, indicating that nodes converge to the final value as a group around the same time. The maximum latency observed in these simulations is about 0.4 seconds.

[0165] We also simulated transaction latency for different numbers of nodes and found that the median latency is more or less independent of network size.

[0166] Next, we study how malicious transactions issued by misbehaving clients that double-spend unspent outputs affect the latency of benign transactions created by honest clients. We adopt a strategy to simulate misbehaving clients where a portion (from 0% to 25%) of pending transactions conflict with some existing transactions. The client process does this by specifying a flow of some double-spent transactions among all simulated pending transactions and sending conflicting transactions to different nodes. We use the same setting n=1000 as in the previous experiments and measure the throughput and latency of confirmed transactions only.

[0167] It is found that Avalanche's latency is only slightly affected by bad clients. Surprisingly, the maximum latency decreases slightly when the percentage of malicious transactions increases. This behavior occurs because, with the introduction of malicious transactions, the overall effective throughput decreases and, therefore, the system load is reduced. In addition, the throughput of benign transactions decreases with the ratio of malicious transactions. Furthermore, the reduction in throughput appears to be proportional to the number of misbehaving clients, that is, there is no impact on attackers.

[0168] Regarding cross-region replication, 20 major cities were selected that appear to be close to a significant number of reachable Bitcoin nodes. These cities cover North America, Europe, West Asia, East Asia, Oceania, and also cover the top 10 countries with the largest number of reachable nodes. A latency and jitter matrix based on global ping statistics from WonderNetwork nodes was used, and network packet latency in the Linux kernel was simulated using tc and netem. It was assumed that 2000 nodes were evenly distributed to each city, and no additional network latency was simulated between nodes within the same city. The bandwidth of each process was limited to 20Mbps to simulate an Internet-scale setup with many commodity network links. Client processes were assigned to each city, maintaining 400 outstanding transactions in each city at any time.

[0169] In this scenario, Avalanche achieved an average throughput of 3401tps with a standard deviation of 39tps. The median transaction latency was 1.35 seconds and the maximum latency was 4.25 seconds. The native Bitcoin code for transactions was also supported; in this case, the throughput was 3530tps, with σ = 92tps.

[0170] The above example system is compared with the regular Algorand and Conflux systems. Algorand, Conflux, and Avalanche are all fundamentally different in design. Algorand's committee-level consensus algorithm belongs to the classic BFT consensus category, Conflux extends the Nakamoto consensus through a DAG structure to facilitate higher throughput, and Avalanche belongs to a new family of protocols based on metastability. Additionally, Bitcoin is used as a baseline.

[0171] Algorand and Avalanche were evaluated both on EC2 using a decision network of size 2000. The evaluation picked a shared c5.large instance, while Algorand used an m4.2xlarge. The two platforms are very similar, except for a slight CPU clock frequency edge on the c5.large, which was largely unused as our processes consumed only 30% in these experiments. The safety parameters chosen in our experiments guarantee less than 10% in the presence of 20% Byzantine nodes. -9 The security violation probability of Algorand is guaranteed to be less than 5×10 with 20% Byzantine nodes. -9 The probability of violation.

[0172] Neither the Algorand nor the Conflux evaluations account for cryptographic verification overhead. Their evaluations use blocks carrying megabytes of dummy data and express throughput in MB / hour or GB / hour. Therefore, we use the average size of Bitcoin transactions (and therefore our transactions) of 250 bytes to derive their throughput. In contrast, our experiments implement real transactions and fully account for all cryptographic overhead.

[0173] For Bitcoin, the throughput is 3 to 7 tps, for Algorand (with 10 megabyte blocks) the throughput is 874 tps, and for Conflux it is 3355 tps (i.e., 3.84 times the throughput of Algorand under the same settings).

[0174] In contrast, Avalanche consistently achieves over 3,400 tps on up to 2,000 nodes without committees or proof of work. As for latency, transactions are confirmed after 10 to 60 minutes in Bitcoin, around 50 seconds in Algorand, 7.6 to 13.8 minutes in Conflux, and 1.35 seconds in Avalanche.

[0175] Avalanche performs much better than Algorand in terms of throughput and latency because Algorand uses a verifiable random function to elect committees and maintains a completely ordered log, while Avalanche only establishes a partial order. Algorand is leader-based and enforces consensus through a committee, while Avalanche has no leader.

[0176] Avalanche has similar throughput to Conflux, but its latency is 337 to 613 times better. Conflux also uses a DAG structure to amortize the cost of consensus and increase throughput, however it is still rooted in the Nakamoto consensus using proof of work, and therefore cannot offer the very short confirmation times of Avalanche.

[0177] In blockchain systems, throughput can often be increased at the expense of latency through batching. The real bottleneck for performance is the number of decisions the system can make per second, which is fundamentally limited by the Byzantine Agreement (BA*) in Algorand and the Nakamoto Consensus in Conflux.

[0178] It is apparent from the above description that the illustrative embodiments provide significant advantages over conventional consensus protocols.

[0179] For example, the new consensus protocol families described in the above exemplary embodiments are efficient and robust. They scale well, achieve high throughput and fast finality, work without precise membership knowledge, and degrade gracefully under catastrophic adversarial attacks.

[0180] These embodiments more particularly include a family of leaderless Byzantine fault-tolerant protocols built around metastable mechanisms. These protocols provide strong probabilistic security guarantees in the presence of Byzantine adversaries, while their concurrency enables them to achieve high throughput and scalability. Unlike blockchains that rely on proof-of-work, they are static and green. Unlike conventional consensus protocols with a leader node that processes information O(n) (in terms of the number of bits exchanged), no node processes more than O(k) for some security parameter k.

[0181] The consensus protocol disclosed herein can be used in a variety of different applications. For example, the consensus protocol can provide improved performance in cryptocurrency and other blockchain applications. The above experiments show that compared to existing systems that deliver similar functions, the example implementation can achieve high throughput (3400tps), provide low confirmation latency (1.35 seconds), and scale well.

[0182] It should be understood that, in conjunction with Figures 1 to 9 The specific arrangements shown and described are presented by way of illustrative examples only, and many alternative embodiments are possible. Therefore, the various embodiments disclosed herein should not be interpreted as limiting in any way. In other embodiments, a variety of alternative schemes for implementing the metastable protocol can be utilized.

[0183] For example, Figures 2 to 7 The specific processing operations of the example protocol shown in FIG. 5 may vary in other embodiments.

[0184] As another example, the synchronization assumptions in certain embodiments described above may be relaxed in other embodiments, and it is expected that strong guarantees may be possible even in the asynchronous case.

[0185] Those skilled in the art will also recognize that many other alternative arrangements of processing operations and associated system entity configurations may be used in other embodiments.

[0186] Thus, it is possible that other embodiments may include additional or alternative system entities relative to those of the illustrative embodiments. Furthermore, in other embodiments, the specific system and device configurations and associated metastable protocols may vary.

[0187] It should also be noted that the above-described information handling system arrangements are merely exemplary and that alternative system arrangements may be used in other embodiments.

[0188] A given client, server, processing node or other component in the information processing system described herein is schematically configured to utilize a corresponding processing device including a processor coupled to a memory. The processor executes software program code stored in the memory to control the performance of processing operations and other functions. The processing device also includes a network interface that supports communication through one or more networks.

[0189] The processor may include, for example, a microprocessor, an ASIC, an FPGA, a CPU, an ALU, a GPU, a DSP, or other similar processing device components, as well as other types and arrangements of processing circuitry in any combination. For example, a given encryption processing module of a processing device disclosed herein may be implemented using such circuitry.

[0190] The memory stores software program code for execution by the processor in implementing a portion of the functionality of the processing device. Such memory storing such program code for execution by the corresponding processor is an example of what is more generally referred to herein as a processor-readable storage medium having program code implemented therein, and may include, for example, electronic memory such as SRAM, DRAM or other types of random access memory, ROM, flash memory, magnetic storage, optical storage or other types of storage devices in any combination.

[0191] Articles of manufacture including such processor-readable storage media are considered embodiments of the present invention.The term "article of manufacture" as used herein should be understood to exclude transitory, propagating signals.

[0192] In other embodiments, other types of computer program products including processor-readable storage media may be implemented.

[0193] Furthermore, embodiments of the present invention may be implemented in the form of an integrated circuit including processing circuitry configured to implement processing operations associated with the metastable consensus protocol and other related functionality.

[0194] The processing devices in a given embodiment may include, for example, a laptop, tablet or desktop personal computer, a mobile phone, or other type of computer or communication device in any combination. For example, a computer or mobile phone may be used as a processing device for participating in the metastable consensus protocol disclosed herein. These and other communications between various elements of the information processing system including the processing devices associated with the respective system entities may be conducted over one or more networks.

[0195] The information processing systems disclosed herein may be implemented using one or more processing platforms, or portions thereof.

[0196] For example, an illustrative embodiment of a processing platform that can be used to implement at least a portion of an information processing system includes a cloud infrastructure that includes virtual machines implemented using a hypervisor running on a physical infrastructure. Such virtual machines can include corresponding processing devices that communicate with each other through one or more networks.

[0197] In such an embodiment, the cloud infrastructure may further include one or more sets of applications running on corresponding ones of the virtual machines under the control of the hypervisor. Multiple hypervisors may also be used, each hypervisor using at least one underlying physical machine to provide a set of virtual machines. Different sets of virtual machines provided by one or more hypervisors may be used to configure multiple instances of various components of the information processing system.

[0198] Another illustrative embodiment of a processing platform that can be used to implement at least a portion of the information processing system disclosed herein includes a plurality of processing devices that communicate with each other via at least one network. It is assumed that each processing device of the processing platform includes a processor coupled to a memory.

[0199] Again, these specific processing platforms are presented only as examples, and the information handling system may include additional or alternative processing platforms as well as a number of different processing platforms in any combination, with each such platform including one or more computers, servers, storage devices or other processing devices.

[0200] For example, other processing platforms for implementing embodiments of the present invention may include different types of virtualization infrastructures to replace or supplement virtualization infrastructures including virtual machines. Therefore, in some embodiments, it is possible that system components can be run at least partially in a cloud infrastructure or other type of virtualization infrastructure.

[0201] Therefore, it should be understood that in other embodiments, different arrangements of additional or alternative elements may be used.At least a subset of these elements may be implemented together on a common processing platform, or each such element may be implemented on a separate processing platform.

[0202] In addition, many other arrangements of computers, servers, storage devices or other components in the information handling system are possible. These components can communicate with other elements of the information handling system through any type of network or other communication medium.

[0203] As previously mentioned, the components of the system disclosed herein may be implemented at least in part in the form of one or more software programs stored in a memory and executed by a processor of a processing device. For example, certain functions associated with a metastable consensus protocol entity or a related component of the system may be implemented at least in part in the form of software.

[0204] The particular configurations of information handling systems described herein are exemplary only, and in other embodiments a given such system may include other elements in place of or in addition to those specifically shown, including one or more elements of the type normally found in conventional implementations of such systems.

[0205] For example, in some embodiments, an information handling system may be configured to utilize the disclosed techniques to provide additional or alternative functionality in other scenarios.

[0206] Therefore, the techniques shown in some embodiments herein in the context of providing a metastable consensus protocol in the context of cryptocurrency can be adapted in a straightforward manner for use in other contexts. Therefore, the illustrative embodiments of the present invention should not be considered limited to cryptocurrency or its associated processing contexts.

[0207] It should also be understood that the specific processing steps used in the embodiments described herein are merely exemplary, and other embodiments may utilize different types and arrangements of processing operations. For example, certain processing steps shown as being performed serially in the illustrative embodiments may be performed at least partially in parallel with each other in other embodiments.

[0208] It should be emphasized again that the embodiments of the present invention described herein are intended to be illustrative only. Other embodiments of the present invention may be implemented using various different types and arrangements of information processing systems, networks, and devices other than those used in the specific illustrative embodiments described herein, and in many alternative processing scenarios. In addition, the specific assumptions made herein in describing the scenarios of certain embodiments need not be applied to other embodiments. These and many other alternative embodiments will be apparent to those skilled in the art.

Claims

1. An apparatus for implementing a metastable Byzantine agreement, comprising: a first processing node comprising a processor coupled to a memory; The first processing node is configured to participate in a consensus protocol with an additional processing node, the first processing node and the additional processing node comprising respective processing devices in communication with each other over at least one network; The first processing node is further configured in conjunction with its participation in the consensus protocol to: determining an initial state of a given transaction based at least in part on one or more of a plurality of possible states of the given transaction; performing repeated polling of different respective selected subsets of the additional processing nodes, each of the different selected subsets comprising fewer than all of the additional processing nodes, with at least a portion of results of the repeated polling being stored at least in part using one or more counters implemented by the processor and the memory of the first processing node; determining a resolution state of the given transaction as a particular state among the plurality of possible states of the given transaction based at least on the one or more counters and in response to results of the repeated polling of respective ones of the different selected subsets of additional processing nodes each of which includes less than all of the additional processing nodes, wherein the repeated polling causes the particular state to gain an advantage over one or more other possible states of the possible states, and subsequent additional repeated pollings by at least one of the first processing node and the additional processing nodes build upon the advantage to enhance the particular state to the resolution state, the resolution state representing an update of the initial state; storing an indication of the parsing status in the memory of the first processing node; transmitting the indication of the resolution status from the first processing node to one or more other processing nodes over the network under one or more specific conditions, the specific conditions comprising at least one of: (i) in response to a query received from a given one of the additional processing nodes in conjunction with polling performed by the given additional processing node as part of the participation in the consensus protocol; and (ii) in response to a query received from another processing node that is not currently participating in the consensus protocol; and At least one automatic action is initiated based at least in part on the resolved status of the given transaction.

2. The apparatus of claim 1 , wherein the consensus protocol is configured to provide Byzantine fault tolerance.

3. The apparatus of claim 1 , wherein the at least one automatic action comprises adding an entry representing the given transaction to a distributed ledger jointly maintained by the first and additional processing nodes.

4. The apparatus of claim 3, wherein the entries comprise blocks and the distributed ledger comprises a blockchain.

5. An apparatus according to claim 1, wherein the participation of the first and additional processing nodes in the consensus protocol is controlled according to at least one specified control mechanism that requires each of the first and additional processing nodes to submit one or more specified proofs.

6. The apparatus of claim 5, wherein the specified proof comprises a proof other than proof of work.

7. The apparatus of claim 1, wherein a given instance of the repeated polling comprises polling a random sample of the additional processing nodes.

8. The apparatus of claim 1, wherein a given instance of the repeated polling comprises polling the additional processing node for a deterministic sample.

9. The apparatus of claim 1, wherein said repeated polling is repeated a plurality of times, wherein each such iteration polls a different selected subset of said additional processing nodes.

10. The apparatus of claim 1, wherein the first processing node is further configured to utilize the results of the repeated polling to maintain a data structure characterizing the relationship between the given transaction and a plurality of other transactions, the data structure comprising at least one of a directed acyclic graph, a linked list, and a hash link chain.

11. The apparatus of claim 1, wherein resolving the status of a given transaction in response to the results of the repeated polling comprises utilizing the results of the repeated polling to determine whether the given transaction should be accepted as a valid transaction.

12. The apparatus of claim 1 , wherein the repeated polling is repeated for a plurality of iterations, a given one of the iterations comprising: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; in response to receiving at least a threshold number of responses to the query, determining whether at least a specified portion of the received responses indicates a particular state of the given transaction that is different than a current state of the given transaction in the first processing node; as well as In response to the designated portion of the received response indicating a specific state of the given transaction that is different from a current state of the given transaction in the first processing node, updating the current state of the given transaction in the first processing node to the specific state.

13. The apparatus of claim 12, wherein resolving the state of the given transaction in response to the results of the repeated polling comprises resolving the state of the given transaction to the current state upon completion of the plurality of iterations.

14. The apparatus of claim 12, wherein the first processing node is further configured to maintain a confidence strength counter indicating a number of consecutive iterations of the repeated polling for which at least a specified portion of the received response indicates a particular status of the given transaction.

15. The apparatus of claim 14, wherein resolving the state of the given transaction in response to the result of the repeated polling comprises resolving the state of the given transaction to the particular state in response to the confidence strength counter exceeding a threshold.

16. An apparatus according to claim 12, wherein the first processing node is further configured to maintain confidence counters for each of the possible states of the given transaction, wherein each of the confidence counters indicates a total number of queries in multiple iterations of the iterations that have generated responses indicating the corresponding state.

17. An apparatus according to claim 16, wherein resolving the state of the given transaction in response to the result of the repeated polling includes resolving the state of the given transaction to the one of the possible states in response to a confidence counter of the one of the possible states exceeding the confidence counter of at least one other of the possible states.

18. The apparatus of claim 1, wherein the first processing node is further configured to maintain a directed acyclic graph of transactions characterizing relationships between the given transaction and a plurality of other transactions, wherein the given transaction and the plurality of other transactions are partitioned into mutually exclusive conflict sets.

19. The apparatus of claim 18, wherein maintaining the directed acyclic graph comprises: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; as well as updating the directed acyclic graph based at least in part on responses to the query; Wherein updating the directed acyclic graph comprises one or more of the following: inserting the given transaction and one or more of the plurality of other transactions into the directed acyclic graph; updating the confidence value of a corresponding transaction in the transactions of the directed acyclic graph; and The transactions of the directed acyclic graph are repartitioned into mutually exclusive conflict sets.

20. The apparatus of claim 19, wherein resolving the status of the given transaction in response to the result of the repeated polling comprises resolving the status in response to the given transaction being the only transaction in its conflict set and the given transaction having a confidence value exceeding a threshold.

21. An apparatus according to claim 19, wherein resolving the state of the given transaction in response to the results of the repeated polling includes resolving the state to one of the possible states in response to a confidence counter of one of the possible states exceeding a confidence counter of at least one other of the possible states.

22. A method for implementing a metastable Byzantine agreement, comprising: configuring a first processing node, the first processing node comprising a processor coupled to a memory to participate in a distributed consensus protocol with an additional processing node, the first processing node and the additional processing node comprising respective processing devices in communication with each other over at least one network; In conjunction with its participation in the consensus protocol, the first processing node: determining an initial state of a given transaction based at least in part on one or more of a plurality of possible states of the given transaction; performing repeated polling of different respective selected subsets of the additional processing nodes, each of the different selected subsets comprising fewer than all of the additional processing nodes, with at least a portion of results of the repeated polling being stored at least in part using one or more counters implemented by the processor and the memory of the first processing node; determining a resolution state of the given transaction as a particular state among the plurality of possible states of the given transaction based at least on the one or more counters and in response to results of the repeated polling of respective ones of the different selected subsets of additional processing nodes each of which includes less than all of the additional processing nodes, wherein the repeated polling causes the particular state to gain an advantage over one or more other possible states of the possible states, and subsequent additional repeated pollings by at least one of the first processing node and the additional processing nodes build upon the advantage to enhance the particular state to the resolution state, the resolution state representing an update of the initial state; storing an indication of the parsing status in the memory of the first processing node; transmitting an indication of the resolution status from the first processing node to one or more other processing nodes over the network under one or more specific conditions, the specific conditions comprising at least one of: (i) in response to a query received from a given one of the additional processing nodes in conjunction with polling performed by the given additional processing node as part of the participation in the consensus protocol; and (ii) in response to a query received from another processing node that is not currently participating in the consensus protocol; and At least one automatic action is initiated based at least in part on the resolved status of the given transaction.

23. The method of claim 22, wherein the repeated polling is repeated for a plurality of iterations, a given one of the iterations comprising: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; in response to receiving at least a threshold number of responses to the query, determining whether at least a specified portion of the received responses indicates a particular state of the given transaction that is different than a current state of the given transaction in the first processing node; as well as In response to the designated portion of the received response indicating a specific state of the given transaction that is different from a current state of the given transaction in the first processing node, updating the current state of the given transaction in the first processing node to the specific state.

24. The method of claim 22, further comprising the first processing node maintaining a directed acyclic graph of transactions characterizing relationships between the given transaction and a plurality of other transactions, wherein the given transaction and the plurality of other transactions are divided into mutually exclusive conflict sets, wherein maintaining the directed acyclic graph comprises: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; as well as updating the directed acyclic graph based at least in part on responses to the query; Wherein updating the directed acyclic graph comprises one or more of the following: inserting the given transaction and one or more of the plurality of other transactions into the directed acyclic graph; updating the confidence value of a corresponding transaction in the transactions of the directed acyclic graph; and The transactions of the directed acyclic graph are repartitioned into mutually exclusive conflict sets.

25. A computer program product for implementing a metastable Byzantine agreement, the computer program product comprising a non-transitory processor-readable storage medium having program code of one or more software programs stored therein, wherein the program code, when executed by a first processing node, causes the first processing node to perform the following operations in connection with its participation in a consensus protocol, the first processing node comprising a processor coupled to a memory and configured to participate in the consensus protocol with additional processing nodes, the first processing node and the additional processing nodes comprising respective processing devices in communication with each other over at least one network: determining an initial state of a given transaction based at least in part on one or more of a plurality of possible states of the given transaction; performing repeated polling of different respective selected subsets of the additional processing nodes, each of the different selected subsets comprising fewer than all of the additional processing nodes, with at least a portion of results of the repeated polling being stored at least in part using one or more counters implemented by the processor and the memory of the first processing node; determining a resolution state of the given transaction as a particular state among the plurality of possible states of the given transaction based at least on the one or more counters and in response to results of the repeated polling of respective ones of the different selected subsets of additional processing nodes each of which includes less than all of the additional processing nodes, wherein the repeated polling causes the particular state to gain an advantage over one or more other possible states of the possible states, and subsequent additional repeated pollings by at least one of the first processing node and the additional processing nodes build upon the advantage to enhance the particular state to the resolution state, the resolution state representing an update of the initial state; storing an indication of the parsing status in the memory of the first processing node; transmitting the indication of the resolution status from the first processing node to one or more other processing nodes over the network under one or more specific conditions, the specific conditions comprising at least one of: (i) in response to a query received from a given one of the additional processing nodes in conjunction with polling performed by the given additional processing node as part of the participation in the consensus protocol; and (ii) in response to a query received from another processing node that is not currently participating in the consensus protocol; and At least one automatic action is initiated based at least in part on the resolved status of the given transaction.

26. The computer program product of claim 25, wherein the repeated polling is repeated for a plurality of iterations, a given one of the iterations comprising: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; in response to receiving at least a threshold number of responses to the query, determining whether at least a specified portion of the received responses indicates a particular state of the given transaction that is different than a current state of the given transaction in the first processing node; as well as In response to the designated portion of the received response indicating a specific state of the given transaction that is different from a current state of the given transaction in the first processing node, updating the current state of the given transaction in the first processing node to the specific state.

27. The computer program product of claim 25, further comprising the first processing node maintaining a directed acyclic graph of transactions characterizing relationships between the given transaction and a plurality of other transactions, wherein the given transaction and the plurality of other transactions are partitioned into mutually exclusive conflict sets, wherein maintaining the directed acyclic graph comprises: selecting a sample of the additional processing nodes; sending a query to a corresponding node among the selected additional processing nodes; as well as updating the directed acyclic graph based at least in part on responses to the query; Wherein updating the directed acyclic graph comprises one or more of the following: inserting the given transaction and one or more of the plurality of other transactions into the directed acyclic graph; updating the confidence value of a corresponding transaction in the transactions of the directed acyclic graph; and The transactions of the directed acyclic graph are repartitioned into mutually exclusive conflict sets.

Images