An Ultimately Guaranteed Protocol for Distributed Ledgers

Abstract

A system and method are disclosed for efficient, secure and ultimately guaranteed block registration into a distributed ledger using a family of protocols named Cordial Miners. The disclosure includes three exemplary embodiments of the distributed ledger block registration protocol. The disclosed protocol can be used as a blockchain consensus protocol that shares a partially ordered data structure and an ordering algorithm. The data structure may be a generalization of a totally ordered blockchain, called a block race. The ordering algorithm can transform the partially ordered block race into a sequence of totally ordered blocks while eliminating invalid blocks such as ambiguities.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 340,047, filed May 10, 2022, U.S. Provisional Application No. 63 / 343,656, filed May 19, 2022, U.S. Provisional Application No. 63 / 393,935, filed July 31, 2022, and U.S. Provisional Application No. 63 / 418,573, filed October 23, 2022, the contents of which are incorporated by reference in their entireties herein.

[0002] The present invention, in some embodiments thereof, relates to distributed computing, and more particularly, but not exclusively, to efficient, secure and eventually guaranteed block registration in a distributed ledger. [Background technology]

[0003] The problem of consensus on the ordering of actions by participants in distributed systems has been studied for 40 years, and has recently focused on two aspects: permissioned, where the set of participants is predetermined by an external authority, and permissionless, where anyone can participate if they pass some "sybil-proof" test, in particular proof-of-work or proof-of-stake. In the permissioned category, methods such as the State-Machine-Replication protocol (SMR), which is a consensus on the ordering of proposals, can be used for the eventual-synchrony model. Additionally, Hotstuff and the Byzantine Atomic Broadcast protocol (BAB), which are based on a consensus on the ordering of all proposals made by correct participants, can also be used for the eventual-synchrony model. For the asynchronous model, DAG-Rider can be used. Since the emergence of cryptocurrencies such as Bitcoin and Ethereum that support smart contracts, permissioned consensus protocols have been proposed. Methods such as stake-based sampling allow permissioned consensus protocols to be used for cryptocurrencies, improving efficiency and throughput compared to proof-of-work protocols. With stake-based sampling, at every epoch (a time span measurable in minutes or weeks), a new set of miners is selected in a random auction, and the probability of being a winner is correlated with the stake bid by the miners. The mechanism design of methods such as stake-based sampling ensures that miners gain benefits by performing the protocol properly, earn less benefits by not performing the protocol properly, and lose their stake if they break the protocol.Miners are therefore expected to do their best, rather than their worst, to execute the protocol, and so the focus of analysis of permissioned consensus protocols has shifted from worst-case complexity to assumptions such as good-case complexity, where miners are generally expected to do the best they can given computing and network limitations. However, defenses against malicious adversaries are still necessary, e.g., to prevent double-spending, hostile takeovers, and meltdowns of the cryptocurrency supported by the consensus protocol.

[0004] The use of DAG-like structures to resolve consensus has also been introduced in previous works, such as asynchronous networks. Hashgraph introduces an unstructured DAG, where each block contains two references to the previous block, and miners run an inefficient binary consensus protocol on the DAG, resulting in high time complexity. Aleph introduces a structured round-based DAG, where a miner advances to the next round once it has received 2f+1 DAG nodes from other miners in the same round. In addition to the DAG protocol, Aleph includes a binary consensus protocol that determines the order of vertices to commit. Nodes in the DAG are assumed to broadcast reliably.

[0005] DAG-Rider is also based on a structured round-based DAG protocol that progresses in rounds. Nodes are also assumed to have reliable broadcast capabilities. The DAG is divided into waves, with each wave consisting of four rounds of nodes. Once a wave ends, miners check locally if the decision rules are met and output blocks accordingly. Bullshark is a dual consensus protocol based on DAG-Rider that provides a fast track to commit nodes every two rounds if the network is synchronized.

[0006] Other DAG-based consensus protocols include HotStuff, which has a final-leader based commit rule. The commit rule is satisfied when there are three consecutive correct leaders. HotStuff is based on Tendermint. HotStuff may not guarantee fairness or liveness, i.e., that every block properly proposed by a miner is eventually included in the blockchain. HotStuff is a leader-based consensus protocol that operates on an eventually synchronous network.

[0007] Blocklace was introduced in Ehud Shapiro's reference "Multiagent Transition Systems: Protocol-Stack Mathematics for Distributed Computing" Arxiv, 2021. For completeness, the necessary definitions and results are included here, but details are referred to "Multiagent Transition Systems: Protocol-Stack Mathematics for Distributed Computing", which is incorporated by reference. A blocklace utility that implements these definitions in particular is shown in Figure 9. Summary of the Invention [Problem to be solved by the invention]

[0008] An object of the present invention is to provide a block registration system and method that uses a partially ordered data structure and a distributed consensus protocol based on the cordiality of miners and a deterministic iterative ordering function. [Means for solving the problem]

[0009] According to an aspect of some embodiments of the present invention, there is provided a system configured for block registration using a partially ordered data structure and a distributed consensus protocol for communicating with a first number of computing nodes over a network, the system comprising: At least one processing circuit, the at least one processing circuit comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of pointers to additional blocks; each of the additional blocks pointed to by a cryptographic hash pointer of the set of cryptographic hash pointers for each cryptographic signature block of the plurality of cryptographic signature blocks is collected in the partially ordered data structure or, if present, adds the cryptographic signature block to the partially ordered data structure; Once a block generated by a designated computing node is finalized, iteratively or recursively, starting with the block as a first block in the order, the immediately previous block generated by the designated computing node in the relevant round and having an associated cryptographic hash pointer in the cryptographic hash pointer set of a second number of blocks in a round following the relevant round, serves as a second block and a first block in a next iteration, until the first block is added to a fully ordered data structure, either by adding to the fully ordered data structure each block reachable by a cryptographic hash pointer, or by iteratively walking through the set of cryptographic hash pointers of blocks reachable by the cryptographic hash pointers, where the cryptographic hash pointer is present in the set of cryptographic hash pointers of the first block but not in the set of cryptographic hash pointers of the second block, and the second block is ordered by a deterministic topological sorting method common to the first number of computing nodes, and prepended with the block generated in the next iteration. A system is provided that is configured to:

[0010] According to an aspect of some embodiments of the present invention, there is provided a method for block registration using a partially ordered data structure and a distributed consensus protocol for communicating with a first number of computing nodes over a network, the method comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of pointers to additional blocks; each of the additional blocks pointed to by a cryptographic hash pointer from the set of cryptographic hash pointers for each cryptographic signature block of the plurality of cryptographic signature blocks is collected in the partially ordered data structure or, if present, adds the cryptographic signature block to the partially ordered data structure; Once a block generated by a designated computing node is finalized, iteratively or recursively, starting with the block as a first block in the order, the immediately previous block generated by the designated computing node in the associated round and having an associated cryptographic hash pointer in the cryptographic hash pointer set of a second number of blocks in a round following the associated round serves as a second block and a first block in a next iteration, until the first block is added to a totally ordered data structure, either by adding to the totally ordered data structure each block reachable by a cryptographic hash pointer or by iteratively walking through the set of cryptographic hash pointers of blocks reachable by the cryptographic hash pointers, where the cryptographic hash pointer is present in the set of cryptographic hash pointers of the first block but not in the set of cryptographic hash pointers of the second block, and the second block is ordered by a deterministic topological sorting method common to the first number of computing nodes, and prepended with the block generated in the next iteration. A method is provided that includes:

[0011] According to an aspect of some embodiments of the present invention, there is provided a method of distributed consensus ordering block registration using a partial order data structure and communicating with a first number of computing nodes over a network, the method comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of cryptographic hash pointers, each cryptographic hash pointer pointing to an additional block; using said network to execute a protocol on said plurality of cryptographic signature blocks conforming to a synchronization specification of said network; generating successive cryptographically signed blocks by appending the set of cryptographically signed hash pointers to the successive cryptographically signed blocks such that a path based on the set of cryptographically signed hash pointers exists for each of the plurality of cryptographically signed blocks; A method is provided that includes:

[0012] In accordance with an aspect of some embodiments of the present invention, there is provided a system configured for distributed consensus ordering block registration using a partial order data structure and communicating with a first number of computing nodes over a network, the system comprising: At least one processing circuit, the at least one processing circuit comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of cryptographic hash pointers, each cryptographic hash pointer pointing to an additional block; using said network to execute a protocol on said plurality of cryptographic signature blocks conforming to a synchronization specification of said network; generating successive cryptographically signed blocks by appending the set of cryptographically signed hash pointers to the successive cryptographically signed blocks such that a path based on the set of cryptographically signed hash pointers exists for each of the plurality of cryptographically signed blocks; A system is provided that is configured to:

[0013] Optionally, the set of cryptographic hash pointers added to the successive cryptographic signature block is generated by giving preference to sources that do not have a cryptographic hash pointer pointing to them in the set of cryptographic hash pointers contained in other blocks.

[0014] Optionally, the processing circuitry is further configured to, if at least one cryptographic hash pointer of the set of cryptographic hash pointers points to at least one unknown block, store that block of the plurality of cryptographic signature blocks in a buffer.

[0015] Optionally, the processing circuitry is further configured, when the at least one unknown block is collected, to move the block from the buffer to the partially ordered data structure.

[0016] Optionally, a block is indicated as unknown to at least one of the plurality of computing nodes until either the block, or a block that includes at least one cryptographic hash pointer that points to the block in the set of cryptographic hash pointers, is received from or transmitted to the at least one of the plurality of computing nodes.

[0017] Optionally, further comprising maintaining a communication history data structure for storing pointers to cryptographic signature blocks received from each of said first number of computing nodes, where a cryptographic signature block is indicated by said communication history data structure as unknown to at least one of said first number of computing nodes.

[0018] Optionally, a protocol conforming to a synchronization specification of the network includes, if a block of the plurality of cryptographically signed blocks is indicated as unknown to at least one of the first number of computing nodes, sending the block to a designated computing node.

[0019] Optionally, generating successive cryptographic signature blocks further comprises verifying that said plurality of cryptographic signature blocks includes blocks of a preceding round from at least a second number of computing nodes; The protocol adapted to the synchronization specification of the network comprises: transmitting the successive cryptographic signature blocks to each of the first number of computing nodes that meet a functionality requirement; receiving blocks of a preceding round from each of at least a second number of computing nodes when the at least one processing circuit implements the designated computing node, and transmitting to at least one of the first number of computing nodes a block indicated as unknown to at least one of the first number of computing nodes when at least one of the first number of computing nodes satisfies a functional requirement. It further includes:

[0020] Optionally, the protocol conforming to a synchronization specification of the network, when the at least one processing circuit implements the designated computing node, comprises: generating successive cryptographic signature blocks further includes verifying that the plurality of cryptographic signature blocks includes blocks of a preceding round from at least a second number of computing nodes; transmitting a block of the plurality of cryptographically signed blocks to at least one of the first number of computing nodes when the block is indicated as unknown to at least one of the first number of computing nodes and at least one of the first number of computing nodes satisfies a functionality requirement; It further includes:

[0021] Optionally, generating successive cryptographic signature blocks further comprises verifying that said plurality of cryptographic signature blocks includes blocks of a previous round from at least a second number of computing nodes; The protocol adapted to the synchronization specification of the network comprises: transmitting the successive cryptographic signature blocks to each of the first number of computing nodes that meet a functionality requirement; and transmitting, when the at least one processing circuit implements the designated computing node, blocks of a predetermined number of preceding rounds are received from each of at least a second number of computing nodes and when the at least one of the first number of computing nodes satisfies the functional requirements, the blocks indicated as unknown to at least one of the first number of computing nodes to at least one of the first number of computing nodes. It further includes:

[0022] Optionally, the designated computing nodes are designated by a method selected from the group consisting of: round robin, a pre-determined pseudo-random sequence, and a global perfect coin.

[0023] Optionally, a block is finalized when it is generated by a designated node of a round, and at least a second number of blocks of the second subsequent round, including blocks generated by a designated computing node of a second subsequent round, have at least a second number of pointers in each of a second associated set of encrypted hash pointers that respectively point to blocks of the first subsequent cycle, each having an encrypted hash pointer in a first associated set of encrypted hash pointers that point to said block, and the encrypted hash pointer that points to said block is the only encrypted hash pointer in the first associated set of encrypted hash pointers that points to a block generated by the designated node of the round in said round.

[0024] Optionally, at least the second number is more than two-thirds of said first number.

[0025] Unless otherwise defined, all technical and / or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. In the practice or testing of embodiments of the present invention, methods and materials similar or equivalent to those described herein may be used, but exemplary methods and / or materials are described below. In case of conflict, the patent specification, including definitions, will control. Furthermore, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

[0026] Implementation of the method and / or system of the present invention may involve performing or completing selected tasks manually, automatically, or a combination thereof. Further, depending on the actual device and apparatus of the method and / or system of the present invention, some selected tasks may be implemented using an operating system, by hardware, software, firmware, or a combination thereof.

[0027] For example, hardware for performing selected tasks according to embodiments of the present invention may be implemented as a chip or circuit. As software, selected tasks according to embodiments of the present invention may be implemented as a number of software instructions executed by a computer using any suitable operating system. In an exemplary embodiment of the present invention, one or more tasks according to exemplary embodiments of the methods and / or systems described herein are performed by a data processor, such as a computing platform for executing a number of instructions. Optionally, the data processor includes a volatile memory for saving instructions and / or data, and / or a non-volatile storage unit, such as a magnetic hard disk and / or a removable media, for storing instructions and / or data. Optionally, a network connection is also provided. A display and / or a user input device, such as a keyboard or a mouse, are also optionally provided.

[0028] Some embodiments of the present invention are described herein, by way of example only, with reference to the accompanying drawings and formulae. Referring now in detail to the drawings, it is emphasized that the particulars shown are by way of example and are intended as illustrative illustrations of embodiments of the invention. In this regard, the description taken together with the drawings will make apparent to those skilled in the art how embodiments of the present invention may be practiced. [Brief description of the drawings]

[0029] [Figure 1] FIG. 1 is a schematic diagram of an exemplary system for registering blocks in a distributed ledger according to some embodiments of the present invention. [Diagram 2] FIG. 1 is a schematic diagram of an exemplary system for registering blocks in a distributed ledger according to some embodiments of the present invention. [Diagram 3] 1 is a basic flowchart of a first exemplary process for registering a block in a distributed ledger according to some embodiments of the present invention. [Figure 4]1 is a basic flowchart of a second exemplary process for registering a block in a distributed ledger according to some embodiments of the present invention. [Figure 5A] FIG. 2 is an exemplary diagram of a partially ordered data structure according to some embodiments of the present invention; [Figure 5B] FIG. 2 is an exemplary diagram of ambiguity, approval, and ratification in a partially ordered data structure according to some embodiments of the present invention; [Figure 6] 11A-11C are a set of diagrams illustrating exemplary causal relationships of blocks according to some embodiments of the present invention. [Figure 7] 4A-4C are a set of diagrams illustrating an exemplary finalization of a block, according to some embodiments of the present invention; [Figure 8] 4 is a table of exemplary protocols conforming to network synchronization specifications according to some embodiments of the present invention; [Figure 9] 4 is an exemplary pseudocode for a utility function associated with a partially ordered data structure, according to some embodiments of the present invention; [Figure 10] 1 is an exemplary pseudocode of a function for adding a block from a partially ordered data structure to a totally ordered data structure according to some embodiments of the present invention. [Figure 11A] 4 is an exemplary pseudocode of a protocol conforming to a network synchronization specification according to some embodiments of the present invention; [Figure 11B] 4 is an exemplary pseudocode of an alternative protocol conforming to network synchronization specifications according to some embodiments of the present invention; [Figure 12] 4 is another exemplary pseudocode of a protocol conforming to a network synchronization specification according to some embodiments of the present invention; [Figure 13] 13 is additional exemplary pseudocode of a protocol conforming to a network synchronization specification, according to some embodiments of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] The present invention, in some embodiments thereof, relates to distributed computing, and more particularly, but not exclusively, to efficient, secure and finally guaranteed block registration in a distributed ledger.

[0031] This disclosure includes three exemplary embodiments of a distributed ledger block registration protocol, sometimes called Cordial Miners. The disclosed protocols can be used as blockchain consensus protocols that share a data structure and ordering algorithm. The data structure is a partially ordered generalization of a totally-ordered blockchain, also called a blocklace. The ordering algorithm can convert a partially ordered blocklace into a sequence of totally ordered blocks while eliminating invalid blocks such as equivocations. The conversion process can be monotonic in that the output sequence is simply expanded with the increase in the input blocklace, in which sense any prefix of the output sequence can be final.

[0032] Some embodiments of the present disclosure include concepts applied to the protocol DAG-Rider, which is a Byzantine atomic broadcast protocol. Some embodiments of the present disclosure include concepts applied to Hotstuff, which is a state machine replication protocol. The concepts applied to Hotstuff may be used when the network conforms to an eventually synchronous model, and the concepts applied to DAG-Rider may be used when the network conforms to an eventually asynchronous model. Additionally, a hybrid protocol is disclosed that integrates the concepts applied to DAG-Rider and Hotstuff.

[0033] The disclosed exemplary protocol, also referred to as the Cordial Miners protocol, may be simpler than DAG-Rider and HotStuff in some respects while maintaining efficiency. The simplicity of the Cordial Miners protocol may be attributed to its use of partially ordered data structures, i.e., block races, for all major algorithmic tasks, including data distribution, disambiguation, leader commitment and ordering, and identification and removal of cordial (faithless) miners, such as non-responsive and ambiguous miners. Protocols may differ by communication patterns: all-to-all for asynchronous, all-to-leader-to-all with timeouts for synchronous protocols, and all-to-all with leader-based backlog distribution for hybrid protocols.

[0034] This protocol may be used in a network where miners generate blocks and send them to other miners. Optionally, miners generate payloads (transactions / actions) in the blocks. Alternatively, the payloads may include transactions received from users of the system, each of which may be connected to one or more miners. The term "node" as used herein may refer to miners and users, where miners may be referred to as miner nodes, and similarly users may be referred to as user nodes.

[0035] The term "block race" as used herein refers to a shared data structure, which may be a partially ordered generalization of a totally ordered blockchain, that contains cryptographically signed blocks, where each block contains a payload and a finite number of pointers, which may be cryptographically hashed to point to previous blocks. Since the cryptographic hash pointers in some embodiments are guaranteed by a compute-bound adversary not to form cycles, a block race may consist of a DAG. A DAG is a chain of events on blocks that contain Lamport's "happened-before" causal relations. JPEG2025515827000002.jpg45 We induce a partial order operator, marked as , i.e., there exists a directed, direct or mediated connection from the DAG vertices associated with a block through the DAG edges. A globally shared block race may be constructed incrementally and collaboratively by all miners, and miners can distribute block races or parts of them to other miners.

[0036] The term "Super-Ratified Leader Ordering" as used here refers to an ordering algorithm that each miner can implement and use locally to transform the locally known portion of the block race into a totally ordered output sequence of blocks while filtering out invalid blocks, including disambiguating them along the way.

[0037] The transformation may be monotonic, and the output sequence may be expanded as miners receive or generate blocks and / or parts of the global block race, in the sense that every output block of each miner may be final.

[0038] Two sequences used here are considered consistent if one is a prefix of the other. If less than one-third of miners are faulty or compromised, the correctness of the Cordial Miners protocol can be shown to be consistent across different miners' outputs, and a valid block known to correct miners will eventually be output by any correct miner. The simplicity of the Cordial Miners family of protocols comes from the use of block racing and its analysis for all major algorithmic tasks.

[0039] Some functions of a correct miner are described below: The term "dissemination" as used here refers to notifying other miners of blocks that have been generated or received according to the following policy: When a new block is created by a miner p, the miner p may acknowledge blocks known to p by including a pointer to the tip, sometimes called the DAG source, of p's local block race, which includes the block previous to p. Correspondingly, a miner p may buffer any received block that has a dangling pointer, i.e., at least one of the pointers points to a block not known to p, rather than including it in the block race. Thus, a block b by p notifies any recipient q of blocks that were not known to p at the time of the creation of b. Thus, when q cordially sends a new q-block to p, it may include in it blocks that have been generated or received by q, but not received by p and not yet sent to p, as indicated by q, thereby achieving block dissemination.

[0040] The term "equivocation" as used herein refers to a pair of blocks by the same miner that are not causally related, i.e., have no pointer path from one to the other, and such blocks are in conflict and the miner who creates them is the equivocator. A shared block race may eventually include any competing blocks that are known to correct miners, and thus will eventually be known to all correct miners. The purpose of this disclosure is to explain how miners can mitigate ambiguity.

[0041] The term "acknowledge" as used here refers to the following: a block b acknowledges a block b' if there is a path from b to b'. Since the trivial, empty path also counts as an acknowledgement, JPEG2025515827000003.jpg412 The notation [b] denotes the set of blocks that are acknowledged by b, sometimes called the closure of b.

[0042] The term “approve” as used here refers to the following: Block b approves block b’ if it acknowledges block b’ and does not acknowledge a block b’ that conflicts with block b’, i.e., a block from the same miner that is not causally related to b’. A miner will not approve both blocks with ambiguities unless it is an obfuscator. Thus, if obfuscators are less than one-third of miners, ambiguities will not be approved from blocks created by the supermajority.

[0043] The term “supermajority” as used herein, also referred to as the second number of computing nodes, may refer to various numbers, e.g., 60% or 80% of the miner nodes, but a number greater than two-thirds of the miners may be indicated to ensure accuracy of the output.

[0044] "Safety" refers to correct, fault-free, and consistent outputs from two computing nodes that can act as agents.

[0045] "Liveness" means that every block generated by a correct agent will eventually be output by every correct agent with probability 1.

[0046] It can be shown that if the number of faulty computing nodes among n computing nodes is less than f, safety is guaranteed if the supermajority is at least (n+f) / 2. Furthermore, liveness can be guaranteed if f<1 / 3n. However, future modifications of this disclosure may require different thresholds, and in some implementations, higher thresholds may be used. Disambiguation can be enabled in a block race as follows: A miner may finalize a block b when the miner's local blocks include a block that approves b by a supermajority.

[0047] As used herein, the term "depth" of a block b refers to the maximum length of the paths emanating from it.

[0048] As used herein, the term "round" refers to a set of blocks of the same depth.

[0049] The term "Cordial Miner" as used herein refers to a miner that maintains the following properties: first, to distribute blocks to other miners when they may not have received the block as described above, and second, to wait for a round d supermajority before generating a round d+1 block.

[0050] The term "cordial" can also be applied to blocks. If two blocks in a block race b', b ∈ B, are two consecutive p-blocks, then a block b can be considered cordial if [b]\([b'] ∪ {b}) is a supermajority, or if at least the second number of blocks in the most recent round have been acknowledged by b. JPEG2025515827000004.jpg9163

[0051] JPEG2025515827000005.jpg61164

[0052] The term "leader" as used herein refers to a designated node or miner, which may change from round to round. It should be noted that the random sequence, and variations thereof, may retain the leader for several consecutive rounds, e.g., 3 rounds or 12 rounds, deterministically or with a certain probability, and are within the scope of the claims of this application. In some implementations, the designated computing node may be designated by round robin. In some other implementations, the designated computing node may be selected according to a pre-determined pseudo-random sequence. In some other implementations, the designated computing node may be selected during one of the following rounds by Global Perfect Coin, a method for distributed consensus random sequences that may not be known in advance. Variations of the fair and weighted method of selecting the designated node will be apparent to those skilled in the art and are within the scope of the claims of this application.

[0053] A block b can be considered ratified by block b' if [b'] contains blocks from a supermajority of miners that approve b in a subsequent round.

[0054] JPEG2025515827000006.jpg42164

[0055] JPEG2025515827000007.jpg14163 Leader ordering can be implemented using a recursive ordering function (denoted as tau or τ) applied to a leader block b, and may be defined as follows: Apply a block b', the deepest leader block in [b] ratified by b. If no such block b' exists, output the lexicographical ordering of [b] and exit. If such a block b' exists, recursively call the ordering function on b' and output the result according to the lexicographical ordering of [b]\[b'].

[0056] Finality can be demonstrated by super-ratified leaders: an exemplary supermajority of more than two-thirds of the computing nodes, also called miners, may be demonstrated to guarantee that a super-ratified leader will be ratified by a subsequent leader. Thus, an ordering algorithm that may be used by miners is as follows: when identifying a new super-ratified leader b in its block race, apply an ordering function τ to b and output the suffixes (successors) newly added since the previous super-ratified leader. Since the ordering function can be shown to guarantee that it will select the previous super-ratified leader in one of the recursive calls, it may be optimized to return if it does so, rather than recomputing the prefixes it has already distributed.

[0057] The disclosed method may also include the identification and removal of faulty miners: A faulty p-block known to some correct miners will eventually be known to all miners, so that correct miners may stop further communication with p. For example, a miner may verify whether another miner p is cordial in the second sense, i.e., waits for a supermajority of rounds d before producing a block in round d+1, by examining the block race. Furthermore, because each block in the pair is known to a different correct miner, any ambiguity due to p will eventually be known to all miners, and p may be removed as a result.

[0058] The method of the present disclosure may also include excluding non-responsive miners: A cordial miner may ignore non-responsive miners. Miner p may stop sending new blocks to miner q unless q has acknowledged the previous block sent from p to q. If q has crashed, p must not waste resources on q; if q has only stopped or been delayed, eventually q will send a block acknowledging b to p, after which p may cordially send to q all backlogs that have not been acknowledged by new blocks received from q that p had previously refrained from sending. Miners can achieve all of the above through a simple and efficient analysis of the local block races of the miners.

[0059] JPEG2025515827000008.jpg9161 The set of miners is also called the first number of computing nodes, f < n / 3 of which may have failures or intrusions and may act arbitrarily, and these are sometimes called Byzantine. The rest are assumed to be correct, and it is also assumed that messages sent from one correct miner to another will eventually arrive. It is also assumed that every miner has a single and unique key pair (PKI) and can cryptographically sign messages. Each miner p ∈ Π may receive an input, sometimes called a payload, that may arrive from multiple unique or non-unique user processes. The payload property or function can return the payload, e.g., a proposal from a user or the mempool, and the output call deliver(b) (where b is a block).

[0060] JPEG2025515827000009.jpg23163

[0061] Safety and liveness are requirements of correct miners in a block race-based Byzantine atomic broadcast protocol: Safety refers to the consistency of the miners' outputs. The liveness property, which refers to the certainty that blocks created by correct miners are eventually output by every miner, is sometimes called fairness. These safety and liveness requirements, combined with the uniqueness of blocks in a block race, imply the standard Byzantine atomic broadcast guarantees: consensus, consistency, validity, and total ordering.

[0062] The safety and liveness of the two protocols can be shown by assuming that no more than one-third of the computing nodes or miners are faulty and considering the rest as correct miners. The function τ that converts a block race into a sequence of blocks is monotonic with respect to the superset relation, in that the output sequence expands as the input block race grows. Two sequences are consistent if each is a prefix of a third sequence. Note that for two local block races B, B' of miners p, p', the monotonicity of τ means that both τ(B) and τ(B') are prefixes of τ(B ∪ B'). Thus, they are consistent and guaranteed to be safe.

[0063] The method of Algorithm 2 shown in Figure 10 can be shown to implement τ correctly and therefore satisfy safety. Liveness may be shown by the proposed protocol conforming to the synchronization specifications of the network. Although they are different, they share a common structure since the transformation function τ applied to the final leader block b includes all blocks known to the final leader, i.e., all blocks in [b], in the output sequence.

[0064] In addition, given a block b known to a correct miner at some time t during the computation, b will eventually be known to every correct miner at a later point t' during the computation. The eventual block propagation arises from the correctness of the underlying asynchronous data dissemination protocol used, for example, in Algorithm 3 of FIG. 11A. For the other two exemplary algorithms, Algorithm 4 of FIG. 12 and Algorithm 5 of FIG. 13, it can be shown that eventually, some leader block b' of a miner is ratified at a time later than t' with probability 1. Moreover, since b ∈ [b'], b is included in the output of τ applied to b'.

[0065] In a synchronous Cordial Miners protocol, such as Algorithm 4 in Figure 12, every block in a block race is sent to the leader by the miner who created it. In the worst case, there can be a linear number of Byzantine leaders in a row, which means that each block is sent in at most O(n 2 ) times. The block size is linear due to the hash pointer, and the time required per block is O(n 3 ) bit complexity. The leader sends the blocks it receives to all miners. In other words, it sends a linear number of blocks, each of which is linear in size, so the bit complexity is O(n 3 ). However, by batching a linear number of transactions per block, a quadratic number of transactions are committed every time the commit rule is satisfied. Thus, the amortized bit complexity per decision is O(n).

[0066] HotStu achieves this complexity even in the good case, i.e. when all miners are synchronized to the same round. In the asynchronous Cordial Miners protocol, each block is O(n 2 ) message computation protocol. Since each block is of linear size, the bit computation for each node to distribute3 ). As with synchronous protocols, each block can be batched with a linear number of transactions. Thus, when the commit rule is satisfied, a quadratic number of transactions can be committed, again with an amortized O(n) bit complexity per decision. This is the same amortized bit complexity as DAG-Rider.

[0067] The disclosed Cordial Miners protocol family may be simple. It is noted that variations will be apparent to those skilled in the art and are within the scope of the claims of this application. Simpler algorithms are easier to debug, optimize, make robust, and scale. The Cordial Miners protocol family may be implemented with mechanisms aimed at rewarding miners' cooperation, as opposed to the competition that is common among cryptocurrencies.

[0068] Before describing at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of the instruction and arrangement of components and / or methods set forth in the following description and / or illustrated in the drawings and / or examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

[0069]

[0023] Referring now to the drawings, Figure 1 is a schematic diagram of an exemplary system for block registration in a distributed ledger, according to some embodiments of the present invention. An exemplary block registration system environment 100 may perform processes such as 300 and / or 400 for block registration in a distributed ledger. Further details regarding these exemplary processes are described in Figures 3 and 4.

[0070] The block registration system 110 may include a set of interfaces to networks as well as other devices and equipment. The interfaces may include input interfaces 112 and output interfaces 114. The block registration system may also include one or more processors 122 for executing processes such as 300 and / or 400, and a storage unit 116 including memory for storing code (program code storage 126) and / or data (device and / or machine parameters, control scenarios, etc.). The block registration system may be physically located on a site, implemented as a distributed system, virtually implemented on a cloud service, implemented on a machine also used for other functions, and / or implemented by several options. Alternatively, the system or parts thereof may be implemented in dedicated hardware, FPGA, etc. Furthermore, the system or parts thereof may be implemented on a server, a computer farm, a cloud, etc. For example, the storage unit 116 may include a local cache on the device, and some less frequently used data or code parts may be stored remotely.

[0071] The input interface 112 and the output interface 114 may include one or more wired and / or wireless network interfaces for connecting to one or more networks, such as, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cellular network, the Internet, or a combination thereof. The input interface 112 and the output interface 114 may further include one or more buses 130. The buses may include wired and / or wireless interconnection interfaces, such as a universal serial bus (USB) interface, a serial port, etc. Furthermore, the output interface 114 may include one or more wireless interfaces for ledger-related communication, such as receiving requests from a user, and the input interface 112 may include one or more wireless interfaces for receiving information from one or more devices. Furthermore, the input interface 112 may include specific means for communicating with one or more sensor devices, such as a camera, a microphone, a card reader, a mobile phone, etc. Similarly, the output interface 114 may include specific means for communicating with one or more display devices, such as a speaker, a display, etc.

[0072] The one or more homogeneous or heterogeneous processors 122 may include one or more processing nodes arranged for parallel processing, as a cluster and / or as one or more multi-core processors. The processors may include units optimized for large scale arithmetic operations, large scale matrix operations, etc., such as a graphic processing unit (GPU). The storage 116 may include one or more non-transient persistent storage devices, such as a hard drive, a flash array, etc. The storage 116 may also include one or more volatile memory devices, such as a random access memory (RAM) component, an extended bandwidth memory such as a video RAM (VRAM), etc. The storage 116 may further include one or more network storage resources, such as a storage server, a network attached storage (NAS), a network drive, etc., accessible via one or more networks via the input interface 112 and the output interface 114.

[0073] The one or more processors 122 may execute one or more software modules, such as, for example, a process, a script, an application, an agent, a utility, a tool, an operating system (OS), etc. A software module may include program instructions stored in a non-transitory medium in program code 126, which may reside on storage medium 116. For example, the one or more processors 122 may execute a process, such as 300 and / or 400, including registering a block into a distributed ledger.

[0074]

[0023] Referring now to FIG. 2, there is shown a schematic diagram of an exemplary system for registering blocks in a distributed ledger, according to some embodiments of the present invention.

[0075] A network can be used to provide a platform for multiple users that constitutes a distributed ledger and is labeled as a LAN, a WAN, a cloud service, a network for banking, non-fungible token (NFT) trading, software as a service (SaaS), compute servers, etc. The network can enable communication with virtual machines acting as miner nodes such as 210, 212, 214, and 240, and user nodes such as 216, 236, and 238. The correspondence between virtual machines and physical machines can be any positive rational number. For example, the physical machine shown at 230 hosts both virtual machines 236 and 238, while virtual machine 240 is implemented by both physical machines 242 and 244.

[0076] A network may be connected to external networks, e.g., the Internet, through a gateway such as 224 or 222. The gateway may include functions such as routing, security, load management, billing, etc., although some or all of these functions may be handled by other machines within or outside the network.

[0077] 3, a basic flowchart of a first exemplary process for registering a block in a distributed ledger, according to some embodiments of the present invention. The exemplary process 300 may be performed for registering a block in one or more distributed ledgers, such as cryptocurrency, logging of sensitive information, verifying the integrity of information, voting, medical records, etc. The process 300 may be performed by one or more processors 122.

[0078] The exemplary process 300 begins with collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of a first number of computing nodes, as shown at 302. Each block of the plurality of cryptographic signature blocks includes a set of cryptographic hash pointers, each of which points to an additional block.

[0079] A block may be received directly from the computing node that generated it, or indirectly through another cordial node that may be specified in some implementations. The miner that generated the block may be identified by a cryptographic signature and may include a payload, which may include a set of cryptographic hash pointers. The payload may include information, transactions, signatures, codes, etc., which may be verified by different means by the miner, etc.

[0080] The cryptographic hash pointers may consist of pointers to additional blocks known to the miner. The first block produced by a miner may have an empty set of cryptographic hash pointers, pointing to NULL or to the initial block. Subsequent blocks may have cryptographic hash pointers to the most recent block produced by the same miner, as well as cryptographic hash pointers to the most recent blocks received from each other miner.

[0081] Links to other blocks generated by this or other miners may also be included in the set of cryptographic hash pointers and are added to the successive cryptographic signature blocks. However, in a preferred implementation, the set of cryptographic hash pointers was generated by prioritizing directed graph sources, i.e., more recent blocks from each miner, that are characterized by having no cryptographic hash pointers pointing to them in the set of cryptographic hash pointers contained in other blocks.

[0082] The example process 300 continues, as shown at 304, by using the network to execute a protocol on the plurality of cryptographic signature blocks that conforms to the synchronization specifications of the network.

[0083] The protocol can control the process by which miners share blocks, also called distribution. Three instances of the Cordial Miners protocol family are included in this disclosure, although variations and other protocols may be developed in the future and be included within the scope of the claims of this application. One instance corresponds to DAG-Rider, which is a Byzantine Atomic Broadcast (BAB) protocol in an asynchronous model. Another instance corresponds to HotStuff, which is an SMR protocol in an eventually synchronous model. The third instance is a hybrid protocol that includes elements of both.

[0084] Protocols compatible with the synchronization specifications of the network may be selected from these instances, variations, future developments, etc., based on the specifications of the network. These protocols may include transmitting blocks to each of the other miners directly and / or via one or more designated computing nodes.

[0085] If required by a protocol conforming to the synchronization specification, the example process 300 continues by verifying that the received plurality of cryptographically signed blocks includes blocks of a preceding round from at least a second number of computing nodes, as shown at 306. Generation of successive cryptographically signed blocks may be delayed until a supermajority (sometimes referred to as a supermajority) of the second number of computing nodes is satisfied.

[0086] Some protocols conforming to the Synchronization Specification require each node to wait until it has received the most recent or last round block from at least a second number of computing nodes before generating successive cryptographically signed blocks. Other protocols conforming to the Synchronization Specification have less strict requirements, such as receiving at least one of the blocks from at least a second number of computing nodes in the most recent three rounds, or have no requirement to receive a block from a previous round before generating a successive block.

[0087] Next, as shown at 308, process 200 may continue by generating successive cryptographic signature blocks by appending the set of cryptographic hash pointers to the successive cryptographic signature blocks such that a path based on the set of cryptographic hash pointers exists for each of the multiple cryptographic signature blocks.

[0088] Generating the successive cryptographic signature blocks may include generating a payload. Additionally, generating the successive cryptographic signature blocks may include appending the set of cryptographic hash pointers to the successive cryptographic signature blocks such that a path based on the set of cryptographic hash pointers exists for each of the multiple cryptographic signature blocks.

[0089] If there is a cryptographic hash pointer to a block, the length of the path may be 1. If the path is indirect, i.e., there is a cryptographic hash pointer to an additional block, which has a cryptographic hash pointer to another block in its pointer set, the length of the path may be 2, and there may be longer indirect paths as well. Paths to buffered blocks not yet included in the partially ordered data structure may also be generated. The set of paths and the blocks to which the cryptographic hash pointers point, directly or indirectly, may be referred to as a closure of consecutive cryptographically signed blocks.

[0090] Referring also to FIG. 4, there is shown a basic flowchart of a second exemplary process for registering a block in a distributed ledger according to some embodiments of the present invention.

[0091] The exemplary process 400 may be performed to execute one or more distributed ledger block registration protocols. The process 400 may be performed by one or more processors 122.

[0092] The example process 400 begins with collecting a plurality of cryptographically signed blocks from a plurality of computing nodes of a first number of computing nodes, as shown at 402. Each block of the plurality of cryptographically signed blocks includes a set of pointers to additional blocks.

[0093] The multiple cryptographically signed blocks may be from the current round, the last round, and / or previous rounds, and in some implementations a miner computing node may receive blocks from cycles that the miner has not yet reached.

[0094] The block source may be identified by a cryptographic signature and may be received directly or indirectly from a computing node of a plurality of computing nodes of the first number of computing nodes.

[0095] The example process 400 continues by adding, as shown at 404, each additional block pointed to by a pointer in the set of pointers for each cryptographic signature block of the plurality of cryptographic signature blocks to the partially ordered data structure as the cryptographic signature block is collected or present in the partially ordered data structure.

[0096] As blocks are received and each block pointed to by a pointer in the set of cryptographic hash pointers for that block is collected, the blocks may be placed into a partially ordered data structure, also known as a block race.

[0097] Some implementations may be configured to store at least one unknown block of the plurality of cryptographically signed blocks in a buffer if at least one cryptographic hash pointer of the set of cryptographic hash pointers points to the at least one unknown block. Once the at least one unknown block is collected, a position of the buffered block in the partially ordered block race may be determined, and the buffered block may be moved from the buffer to a partially ordered data structure.

[0098] The exemplary process 400 continues as shown at 406. Once the block generated by the designated computing node is finalized, iteratively or recursively starts with the block as the first block in the order, and the immediately previous block generated by the designated computing node in the relevant round and having an associated cryptographic hash pointer in the cryptographic hash pointer set of the second number of blocks in the round following the relevant round acts as the second block and the first block in the next iteration, until the first block is in a totally ordered data structure, either by adding to the totally ordered data structure each block reachable by a cryptographic hash pointer or by iteratively walking through the set of cryptographic hash pointers of blocks reachable by a cryptographic hash pointer, the cryptographic hash pointer of which is in the set of cryptographic hash pointers of the first block but not in the set of cryptographic hash pointers of the second block, the second block is ordered by a deterministic topological sorting method common to the first number of computing nodes, and is prepended with the block generated in the next iteration.

[0099] A block may be considered finalized when it is generated by a designated node of a round, and at least a second number of blocks of the second subsequent round, including blocks generated by a designated computing node of the second subsequent round, have at least a second number of pointers in each of the second associated set of cryptographic hash pointers that respectively point to blocks of the first subsequent cycle, each having a cryptographic hash pointer in the first associated set of cryptographic hash pointers that point to a block that is the only cryptographic hash pointer in the first associated set of cryptographic hash pointers that points to a block generated by the designated node of the round in that round. The second number may be two-thirds or more than two-thirds of the first number, and the liveness and security of the method may be demonstrated, although a number less than two-thirds of the first number, the number of common miners, may also be used.

[0100] Referring also to FIG. 5A, an exemplary diagram of a partially ordered data structure according to some embodiments of the present invention.

[0101] Schematic diagram 500 depicts the rounds as synchronous, with each of the miners generating their blocks at the same time, although for ease of reading the blocks may be generated at different times. However, the arrows indicate that the source block was generated when the block it points to was known. For example, block 502 generated by the bottom miner in the second round has cryptographic hash pointers to blocks from the top and second-to-top miners in the first round, as well as blocks generated by the same miner. In this example, three out of four is more than two-thirds, so an overwhelming majority of the clocks from previous rounds have been collected, and in this sense the block is cordial.

[0102] For ease of reading, the leader blocks of the odd rounds (e.g. 510, 520, 530) are shown marked with *. The leader block of the fifth round, shown at 520, acknowledges three blocks of the fourth round (marked by V and 2), shown at 514. The block marked with V and 1 of the fourth round acknowledges the leader of the third round, shown at 510, and also approves 510, since the competing block does not acknowledge it. However, since only two blocks acknowledge the leader of the third round, and these have been acknowledged by the leader of the fifth round, the requirement of super-ratification or finalization is not met and the block of the third round is only ratified.

[0103] The sixth round, denoted by 524, has three blocks marked with V, which have acknowledged the fifth round leader as well as been acknowledged by the seventh round leader, denoted by 530, so the requirement of super-ratification is met for the fifth round leader, and therefore the fifth round leader may be finalized. With the finalization of the leader, denoted by 520, a miner with a partially ordered data structure, i.e., a snapshot of the block race as depicted, may deliver the lighter and smoother blocks that are in the closure of the fifth round leader 520. Note that the ordering function may place the lighter blocks, i.e., the third round blocks, in preference to the darker colors, and place the blocks of each round in a deterministic order, such as lexicographically. A similarly generated subchain of smooth blocks from the first round to the third round may then be added as a prefix.

[0104] The 7th round leader block is shown acknowledging exactly three blocks, as required for a block to be cordial, although some implementations may determine different thresholds for block production and block ratification.

[0105] It is emphasized that the block races shown, and characteristics such as the number of minors, codification, etc., are simplified examples shown for ease of reading and understanding, and should not be construed as limiting the scope of the claims of this application.

[0106] Referring also to FIG. 5B, an exemplary diagram of ambiguity, approval, and ratification in a partially ordered data structure according to some embodiments of the present invention.

[0107] Figure 5B shows an example block race data structure, ambiguity, approval, and ratification. Four miners are shown, which can also be called the top miner red, the second-highest miner green, the second-lowest miner blue, and the bottom miner yellow. Each circle represents a block, and each line is a hash pointer to the block to the left.

[0108] Subfigure A shows one wave of five consecutive rounds. The block with the top halo in round r may be the designated block, i.e., the leader block. Each of the yellow highlighted blocks in rounds r+1 and r+4 may have a path to the leader block, making it the finalized leader block. The blocks with grey halos are ordered by τ once the leader block is finalized. In subfigure B, The top, top red miner is ambiguous, the top red block is endorsed by the second-top green block in the next round, the bottom red block is endorsed by the bottom yellow block in the next round, and the second-bottom blue block in the next round observes both ambiguous red blocks and endorses neither of them, so neither red block has the three endorsements (including the red block itself) required for ratification. In subdiagram C, the blue block in the next round only observes the bottom red block and therefore endorses it. This causes the yellow block and the red block themselves to form a supermajority, so the bottom red block is ratified, but the top block is not ratified. In subdiagram D, the blue miner ambiguizes in the next round, and the top blue block in the next round endorses the top red block, forming a supermajority with green and red to ratify it. Similarly, the bottom blue block, the yellow block, and the red block (not shown) may ratify the bottom red block. In fact, if there are two ambiguists out of four (red and blue), ambiguity can be ratified.

[0109] A key component of the Cordial Miners protocol is the block race, a distributed DAG-like structure that miners build together, shown in Figure 5B with four miners, each in a different color. A block race may consist of rounds of more than 12n+f blocks, each by a different miner. A set of blocks by more than 12(n+f) miners is also called a supermajority, and when f=0, a supermajority can be a simple majority.

[0110] Subfigure A of Figure 5B shows an example block race constructed by four miners, where each column is a single round representing blocks from different miners, and each row of the same color is composed of blocks from the same miner. Thus, each correct miner creates one block in each round.

[0111] Although miners may see partial differences in the block race, the goal of disclosure is to have the order of blocks "converge" to a consistent order for all miners.

[0112] Each block can hold a set of transactions and pointers to blocks from the previous round, i.e. edges in the DAG. When a miner observes a new round r (sometimes called a cordial round) with a supermajority of blocks, the miner can create a new block b of round r+1 that contains a pointer to the tip of the known block race up to round r (a block in the block race with no incoming edges).

[0113] A block can be considered to observe other blocks if there is a path of pointers from that block to other blocks. The tip is expected to contain the vast majority of blocks in round r, but there may be blocks from earlier rounds that have not yet been observed by blocks received in round r. For example, if subfigure A represents a block race observed by a red miner, then round r+4 is cordial, so the red miner can create a new block b in round r+5 that has pointers to all blocks in round r+4. The miner can then send b to all other miners.

[0114] Cordial Miners can use block races for the three algorithmic components of consensus: distribution, fuzziness, and ordering.

[0115] Now, let us turn to the distribution process. In some cases, distribution can be performed by each miner simply sending a new block to all other miners. However, failures, which may be intentional, can occur due to faulty miners or communication problems, and new blocks may be sent to only some miners. Block race-based Byzantine-resistant distribution can be achieved by having new blocks created by correct miners also function as ack / nak messages, informing other miners or receivers of blocks known to the sender at the time of transmission, and also informing them of blocks that the sender does not yet know due to the lack of notification. For example, the second-top green block in round r+4 serves as an ack message for all blocks it has observed, including the red, green, and blue blocks in round r+3. It also serves as a nak message for the bottom yellow block in round r+3.

[0116] This makes it easier to maintain the principle of cordial distribution, i.e., sending blocks that you have received but that others have not received to other miners. In this example, if the top red miner sends the block he created to the second green miner in round r+5, he will also send the bottom yellow block to the green miner in round r+3.

[0117] Byzantine miners can be ambiguous, i.e., they send ambiguous blocks to different honest miners. Two blocks b1, b2 can be considered ambiguous if neither has observed the other, i.e., there is no path of pointers from b1 to b2, or from b2 to b1. Block races can contain ambiguities, which must be eliminated when each miner locally applies an ordering to the blocks in a block race into a sequence of final blocks.

[0118] The supermajority can be used to disambiguate such that for each set of ambiguous blocks, at most one is included in the final output. In addition, after detecting an ambiguity, honest miners can ignore the Byzantine miner and stop including that block in the block race or distributing blocks, so that a Byzantine miner can only be ambiguous at most once before being detected and ignored, limiting the power of the Byzantine miner.

[0119] Disambiguation is part of the τ-ordering. The ordering of a partially ordered block race may be done by a topological sort of the DAG. The challenge is for all correct miners to disambiguate and order the blocks identically, so that all miners produce the same complete ordering. To this end, the block race may be divided into waves, each consisting of several rounds, the number of which may be different for the final synchronous ES and asynchronous (e.g., 2 and 5 rounds per wave, respectively). For example, subfigure A of FIG. 5B shows an exemplary asynchronous version with 5 rounds in each wave.

[0120] For each wave, one of the miners may be elected as the leader, and when the first round of a wave has a block produced by the leader, that block can be called the leader block. The diagram shows the second-to-top green block of round r with a green halo as the block leader of that wave. When the wave ends, i.e., the last round of the wave is cordial, the leader block will be finalized if there are enough confirming blocks, i.e., the leader block to be finalized is unambiguous and there is a supermajority of blocks that each observe the leader block.

[0121] Reference is also made to FIG. 6, which is a set of diagrams illustrating exemplary causal relationships of blocks, according to some embodiments of the present invention.

[0122] The terms "Acknowledgement", "Approval", "Equivocation", "Ratification", and "Super-Ratification" relate to the causality of blocks, which are represented in a Directed Acyclic Graph (DAG) generated by a set of cryptographic hash pointers.

[0123] JPEG2025515827000010.jpg28164

[0124] The middle diagram (B) is an example ratification: the block at the bottom of round r, indicated by the black dot, is ratified by the block at the top of round r+2, indicated by the grey dot, because the black block was approved in round r+1 by a supermajority indicated by the horizontal line in the middle that was acknowledged by the grey block.

[0125] The right diagram (C) is an exemplary super-ratification: A leader block, indicated by the bottom dot, of round r is super-ratified if there is a supermajority, i.e., at least a second number of computing nodes, indicated by light horizontal lines, including the leader block indicated by the dot of round r+2, and each member of the supermajority ratifies the leader of round r, i.e., acknowledges the supermajority, indicated by the dark horizontal lines, of round r+1, each of which acknowledges the leader of round r. Note that approval is a stronger requirement that there be no conflicting blocks that are not acknowledged in addition to causality, whereas acknowledgement only requires causality.

[0126] Reference is also made to FIG. 7, which is a set of diagrams illustrating an exemplary finalization of a block, according to some embodiments of the present invention.

[0127] The finality of a super-ratified leader block is shown for a leader block of round r, shown as the bottom dot, where the leader block is super-ratified and therefore can be ratified by any subsequent leader, shown as the top dot. The left diagram (A) shows that a leader of round r+2 meets the definition of super-ratification for the leader block of round r, i.e., acknowledges a supermajority approving the leader. In the middle diagram (B) and right diagram (C), the next leader is in a subsequent round r+k (k>2) and cordially acknowledges a supermajority marked by a horizontal line in the previous round r+k-1, which requires a correct agent marked by a dot in r+2 in common with the super-ratification supermajority of round r+2 marked by a light horizontal line. (B) If the supermajority is the same as that of round k=2, there exists at least one block connecting the most recent top leader and the bottom leader via an approving supermajority shown by a dark horizontal line in round r+1. (C) Otherwise, when the supermajorities are in different rounds, i.e., k>2, there are two blocks b1, b2 in the immediate agent B^ and the supermajority in the light line B', and they are connected by a path because the blocks in the supermajority are correct. This connects the top leader ^b to the bottom leader b through the ratifying supermajority B shown by the dark green horizontal line in round r+1. In all cases, the immediate leader ^b ratifies the blue leader b.

[0128] The designated computing node that generates the leader block of a round, also referred to as the leader of the round, may be designated by a method selected from the group consisting of round robin, a pre-determined pseudo-random sequence, and global perfect coin.

[0129] In some implementations, a retroactive leader election with a shared coin can be used since in the asynchronous model an adversary may be able to control the order of message delivery indefinitely. For example, the method adopted in DAG-Rider applies a shared random coin, which elects the leader retroactively, allowing more rounds for a final leader to emerge. Since the miners are cordial, the concept of a common core can be applied to prove a lower bound on the probability that the leader will be finalized despite such a strong adversary. The same approach can be applied to the Cordial Miners protocol, but at the cost of delaying the expected finality from 2 to 4 rounds, since the use of threshold signatures requires a secure method for key distribution.

[0130] A ratified and finalized leader block may be defined as follows: A block b ∈ B may be considered ratified if there exists at least a second number, i.e. a supermajority, of blocks at depth d(b)+1 that approve b. A leader block b at depth r may be considered finalized if there exists a supermajority B at depth d(b)+2 that includes the leader block, and each member of B ratifies b. A finalized block may be shown to be ratified by any subsequent cordial block as well. JPEG2025515827000011.jpg38163 This shows that given a block race B, a finalized leader b of B can be ratified by any subsequent finalized leader and thus can be included in the sequence of finalized leaders. Thus, the finalized sequence up to finalized leader b is entirely determined by b itself, independent of the continually changing identity of the last finalized leader. Thus, the finalized sequence up to finalized leader b is "cached" and does not change as the size of the block race grows. Super-ratified, or finalized, leaders are anchors of finality in the growing chain, each one used as a basis for tracing history back to its previous ratified leader. The term "Okazaki fragment" or subchain can be used for the sequence calculated backwards from each finalized leader to its previous leader, analogous to the way one of the DNA strands of a replicated DNA molecule can be extended via stitching Okazaki fragments synthesized in the opposite direction.

[0131]

[0041] Referring also to FIG. 8, there is shown a table of exemplary protocols conforming to network synchronization specifications, according to some embodiments of the present invention.

[0132] The protocols are illustrated as algorithmic components written in pseudocode, with some components being common between them: The Asynchronous Cordial Miners protocol with module “Asynchronous Data Distribution” is composed of Algorithms 1, 2, and 3. The Synchronous Cordial Miners protocol with “Block Race Distribution” is composed of Algorithms 1, 2, and 4. The Asynchronous Cordial Miners protocol with “Block Race Distribution” is composed of Algorithms 1, 2, and 5. The diagram shows the distinct components (green / blue / red) that are common to the three protocols in the family. Algorithm 1 contains a description of the blocks of the block race and the utility of the block race. Algorithm 2 describes the local transformation in which each miner transforms its local copy of the partially ordered block race into a sequence of totally ordered blocks using a function τ. Then there are two algorithms: Algorithm 3 is an all-to-all communication protocol similar to DAG-Rider, utilizing asynchronous data distribution as the underlying communication protocol. Algorithm 4 is a leader-based communication protocol similar to HotStuff. Algorithm 5 can be seen as a hybrid of Algorithms 3 and 4: it uses all-to-all communication like Algorithm 3, but omits the outward distribution protocol by having the leader of each round send the backlog required for distribution like Algorithm 4. Some optimizations, such as filtering out faulty or non-responsive leaders, may also be used in all protocols.

[0133] For the analysis of security and liveness properties, three models of communication with an adversary are considered: Asynchrony: The adversary controls a finite number of message delays for each message. Eventual Synchrony: The adversary controls message delays for an unknown but finite number of messages, beyond which messages arrive within bounded delays. Eventual Random Asynchrony: The adversary controls message delays for an unknown but finite number of messages, beyond which messages arrive with random delays with finite expectation.

[0134] Eventual asynchronous is the natural opposite of eventual synchronous, but is obviously unexplored. The synchronous Cordial Miners protocol may be suitable for eventual synchronous, and the asynchronous Cordial Miners protocol can be applied to eventual asynchronous with pseudorandom leader selection, and asynchronous with random retroactive shared coin leader selection. Both protocols support Byzantine atomic broadcast.

[0135] Algorithms 1 and 2 are common components among protocols conforming to the network synchronization specification. Algorithm 1 includes basic block race utilities, and Algorithm 2 realizes block race ordering. Algorithm 3 integrates Algorithms 1 and 2 with a modular asynchronous data dissemination protocol, realizing Byzantine atomic broadcast (BAB) in an eventually asynchronous / asynchronous model depending on the leader selection function applied. Algorithm 4 integrates Algorithms 1 and 2 with a cordial all-to-leader-to-all block race distribution, realizing Byzantine atomic broadcast in an eventually synchronous model. Algorithm 5 integrates the first two ideas: Algorithms 1 and 2 with cordial all-to-all block communication and cordial leader-to-all block race distribution, realizing Byzantine atomic broadcast in an eventually asynchronous / asynchronous model depending on the leader selection function adopted. For each, we give the number of lines of pseudocode.

[0136] It should be noted that these algorithms are exemplary and that variations may be apparent to those skilled in the art or may be developed in the future and are within the scope of the claims of this application.

[0137] Reference is also made to FIG. 9, which is an exemplary pseudocode for a utility function associated with a partially ordered data structure, according to some embodiments of the present invention.

[0138] These utilities are exemplary implementations of basic elements of the method, such as block definition, collision-free cryptographic hashing, path extraction, closure extraction, depth calculation, leader designation and labeling, approval, ratification, and ambiguity checking.

[0139] For example, ambiguity is defined as when two blocks are produced by the same miner node, yet neither of them is present in the closure of the other block.

[0140] Reference is also made to FIG. 10, which is an exemplary pseudocode of a function for adding a block from a partially ordered data structure to a fully ordered data structure according to some embodiments of the present invention.

[0141] Adding blocks from a partially ordered data structure to a totally ordered data structure can be performed by a deterministic function τ that transforms the block race into a sequence of some of its blocks in a stepwise manner. τ can be shown to be monotonic with respect to the subset relation if no more than f miners, i.e., less than one-third, are ambiguous. The intention is to allow each miner in the blockchain consensus protocol to execute τ and locally compute the final output sequence of blocks with a local copy of the block race as input, as realized in Algorithm 2. Monotonicity guarantees finality, since it means that the output sequence extends as long as the input local block race increases over time. Monotonicity is a sufficient condition for the safety of each protocol used. To guarantee liveness, it is necessary to prove that every valid block in the input block race is eventually included in the output of τ, and this proof is protocol-dependent and is proved separately for asynchronous and synchronous protocols.

[0142] The following recursive ordering function τ can map a block race into a sequence of blocks. Each time τ is applied, the entire sequence can be calculated backwards from the last final leader. In practice, as shown in Figure 7, the sequence up to the finalized leader is final and can therefore be cached. This allows τ to iteratively calculate subchains, called "Okazaki fragment" increments, from the new final leader back to the previous final leader.

[0143] JPEG2025515827000012.jpg42164

[0144] Note that τ' may use the notion of a leader that is ratified by other leaders, rather than a finalized leader. When there are fewer ambiguists than f, the last leader can be shown to be final in the sense that it can be guaranteed to be ratified by a subsequent leader that may or may not be finalized. Monotonicity and finality of τ can be shown by saying that if there is ambiguity of up to f, then the function τ is monotonic in ⊆. JPEG2025515827000013.jpg42164

[0145] JPEG2025515827000014.jpg28163

[0146] JPEG2025515827000015.jpg9158 Note that τ may not output all blocks in its input, since any blocks in its input that are not acknowledged by the last finalized leader are not delivered to the totally ordered data structure.

[0147] JPEG2025515827000016.jpg9160 Thus, every block known to a correct miner will be known to all correct miners, and if every finalized leader has a successor block, every block will eventually be acknowledged by a finalized leader and therefore distributed at τ. Algorithm 2 implements these conditions, preserving distributed blocks that contain a prefix of the output of τ that we have already computed.

[0148] As shown in line 24, adding a new block to the block race will result in the block being added to the most recently finalized leader b 1and then apply tau to it. This is intended to be a literal realization of the definition of τ, optionally with optimizations, where the recursive call returns containing the delivered blocks. Thus, the following proposition holds: Given the safety of any protocol that uses Algorithm 2 for ordering block races, in particular the safety of the asynchronous and synchronous Cordial Miners protocols, Tau can be shown to implement τ.

[0149] It should be emphasized that variations in the protocol will be apparent to those skilled in the art and are included within the scope of the claims of this application.

[0150] Reference is also made to FIG. 11A, which is an exemplary pseudocode of a protocol conforming to a network synchronization specification according to some embodiments of the present invention.

[0151] The protocol based on Algorithm 3 is the counterpart of DAG-Rider, a BAB protocol designed for the asynchronous model. It assumes an adaptive adversary that eventually distributes messages between any two correct miners. In DAG-Rider, miners jointly build a DAG of blocks. The vertices are blocks, and the edges are pointers to previously created blocks, which are divided into strong and weak edges. The strong edges are used for the commit rule, and the weak edges are used to ensure fairness. The protocol may be based on an underlying reliable broadcast election protocol, which guarantees that the local DAG of all correct miners eventually converges and removes ambiguity. Each miner can independently implement a global coin that retroactively selects one of the miners as the leader for each round using threshold signatures, transforming the local DAG into an ordered sequence of blocks. The decision rule for distributing a block is whether a vertex created by the leader is observed by at least 2f+1 miners in 3 rounds after its creation. DAG-Rider has an expected amortized linear message complexity and has an expected constant latency.

[0152] The Asynchronous Cordial Miners protocol is a protocol corresponding to DAG-Rider. This protocol is a combination of algorithms 1, 2, and 3 based on an underlying data distribution protocol such as Fischer et al.'s "Impossibility of distributed consensus with one faulty process". Algorithm 3 is based on the asynchronous data distribution protocol as a subprotocol, and when a miner running the Cordial Miners protocol calls disseminate(b), it sends block b to all other miners. This ensures that 2f+1>f+1 correct miners receive b, satisfying the condition for asynchronous data distribution (ADD) to work correctly.

[0153] The first miner to receive a suitable block b initiates the ADD protocol for b. Suitable may refer to signed, cordial, no dangling pointers, etc. Every shard of b created by the ADD protocol may be tagged with the hash value of b, so that multiple instances of the ADD protocol on multiple blocks may proceed simultaneously, i.e., asynchronously, in parallel, without confusion between blocks of a shard. Once the ADD protocol reconstructs block b', the reception condition of the Cordial Miners protocol may be satisfied for block b'.

[0154] The correctness of ADD can guarantee that every block distributed by a correct miner is eventually reconstructed and received by every correct miner. The Asynchronous Cordial Miners protocol is designed for an eventually asynchronous model, where the adversary controls the message delay for an unknown but finite number of messages, above which the messages arrive within a bounded delay. The distribution component may be called by disseminate(m) for some block b, and can output receipt(b). The underlying protocol can guarantee that if a correct miner calls disseminate(b) or receive(b), eventually all correct miners will execute receipt(b).

[0155] Algorithm 3 can buffer incoming blocks as shown in line 65, receive them when there are no dangling pointers as shown in line 39, and receive them when observing a new cordial round as shown in line 72. Algorithm 3 can create blocks for recent cordial rounds that it did not participate in and distribute blocks for recent cordial rounds as shown in line 22. This allows the distribution protocol to guarantee that all correct miners eventually get the same block.

[0156] An adversary familiar with the "celebrated FLP theorem" may order the delivery of messages in any round such that the supermajority initially observed by all correct miners does not include the leader of that round. Thus, there may be no ratified leader, let alone a finalized leader. However, in the eventual asynchronous model, the adversary only controls the delivery times of some finite number of messages, and random network delays may delay subsequent ones. Thus, from any point in the computation, the leader may eventually be finalized and acknowledged by that leader, and any blocks not yet delivered may be delivered.

[0157] Thus, Algorithm 3 can be shown to satisfy the liveness requirement by considering the suffix of an infinite computation of Algorithm 3 beyond the control of an adversary. The underlying asynchronous data dissemination protocol can guarantee that every block b known to a miner will eventually be known to every miner. The probability that each leader block in this suffix will be ratified by a successor block is higher than some given ε, and therefore the probability that the leader block will be finalized is higher than some smaller given ε'. Thus, the probability measure of an infinite computation in which no correct leader block is finalized is zero. Thus, for any block b and point t in the computation, some leader block b' that acknowledges b will be finalized at a point later than t' with probability 1. Thus, for any block b known to a correct miner, there will be a final leader block b' that acknowledges b and thus distributes b, satisfying the liveness requirement.

[0158] In Algorithm 3, generating successive cryptographic signature blocks includes verifying that a number of cryptographic signature blocks, including blocks of preceding rounds from at least a second number of computing nodes, i.e., a supermajority, satisfy the codacity requirement.

[0159] It should be emphasized that variations in the protocol will be apparent to those skilled in the art and are included within the scope of the claims of this application.

[0160] Reference is also made to FIG. 11B, which is an alternative exemplary pseudocode for a protocol conforming to network synchronization specifications, according to some embodiments of the present invention.

[0161] In this alternative protocol, the correct block is considered to be buffered until there are no more dangling pointers, and is received in response to the completion of the pointer. After including the received block in the block race, the miner can call τ (line 47), which can generate a new block if adding the received block results in a new final leader block.

[0162] When a new round in the block race is completed (line 48), the miner creates a new block (line 49), computes a new round (line 50), and sends the new block to other fellow miners. The package sent to miner q may contain blocks up to the previous round that p knows but q may not know, based on the last block received from q (line 52). Note that since the network is reliable, send is defined to be idempotent, i.e., it sends each block at most once to each agent.

[0163] This is an example where if blocks from a predetermined number of preceding rounds (in this example, two) have been received from each of at least a second number of computing nodes and at least one of the first number of computing nodes meets the functionality requirements, the miner sends a block that has been indicated as unknown to at least one of the first number of computing nodes to at least one of the first number of computing nodes.

[0164] Note that there is a tradeoff between latency and message complexity, and various optimizations and heuristics are possible. An exemplary protocol for this alternative is the latency-optimized Cordial Miners protocol, where every block is communicated between every pair of correct miners, although every block may be communicated between every trio, quartet, dozen, etc.

[0165] Reference is also made to FIG. 12, which is another exemplary pseudocode of a protocol conforming to network synchronization specifications, according to some embodiments of the present invention.

[0166] Algorithm 4 is the counterpart of HotStuff and is an SMR protocol designed for the eventual synchronization model. The protocol involves all-to-leader, leader-to-all communication: in each round, a designated leader, selected deterministically, proposes a block to everyone and can collect all signatures for that block. Once the leader has 2f+1 signatures, the designated node, i.e., the leader, may incorporate them into a threshold signature and send it back to everyone. The decision rule for distributing a block may be three consecutive correct leaders. This can lead to linear message complexity and constant latency in the good case. The protocol can distribute a block if there are three consecutive correct leaders. This is guaranteed to happen after the GST, as defined by the eventual synchronization model. The synchronous Cordial Miners protocol is designed for the eventual synchronization model and consists of Algorithms 1, 2, and 4. Unlike the asynchronous Cordial Miners protocol (Algorithm 3), which may rely on other protocols to perform distribution, the synchronous Cordial Miners protocol in Algorithm 4 employs a block race structure to perform distribution. Thus, each miner maintains a history array that records its communication history with other miners, and updates it when it receives a block, as shown in line 49, and when it sends a block, as shown in line 78.

[0167] By registering the communication history, the cordial miner node is able to indicate a block as unknown to at least one of the plurality of computing nodes until either the block or a block that includes at least one cryptographic hash pointer pointing to the block in its set of cryptographic hash pointers is received from or transmitted to at least one of the plurality of computing nodes.

[0168] Maintaining a communication history data structure for storing pointers to cryptographically signed blocks received from each of the first number of computing nodes and cryptographically signed blocks and / or cryptographically signed blocks sent to each of the first number of computing nodes may be used to indicate a block as unknown to at least one of the first number of computing nodes.

[0169] A normal, non-leader miner p only needs to send to the leader a cryptographically signed block b that it has created, containing pointers to blocks that p knows, as shown in line 77. Meanwhile, a designated node, i.e., leader p, can send to each responding miner q not only block b, but also all blocks that p knows but that q does not know, i.e., [b]\[history[q], as shown in line 76. Excluded from the closure of b are the closures of all q-blocks known to p and all blocks that p has sent to q, both of which are recorded in miner p's history[q]. A miner q is considered to have responded to p if q responded to the last block that p sent to q, as shown in line 63. When sending a block to miner q, miner p can use the communication history to create a package of all blocks that p knows but q may not know, and send the entire package. Based on these packages, Algorithm 4 shows that if a correct miner knows block b, then eventually every correct miner will know b.

[0170] Given a correct miner p with a block b ∈ block and a miner q, if p is correct, then eventually p will send a block to q, one of which will become the leader. If at that point p's communication history with q indicates that q knows p's b, then the block is known to both. Otherwise, p can include b in a package to q along with all blocks in [b] that p does not have evidence that q knows based on the communication history. Then q can finally receive the package. There are no blocks with dangling pointers in the package. This is because p has included in the package all blocks that p knows but q may not know, so q can receive the package and include it in q's block along with b. The block communication in Algorithm 3 is all-to-all, while the block communication in Algorithm 4 is all-to-leader-to-all, which does not require all miners to be cordial as in Algorithm 3, only the leader needs to be cordial, so it requires less synchronization and in the good case, the leader in each round acts as a relay for all miners in that round, which reduces the message computation. As a result, the liveness argument for the protocol is slightly different. Since every block known to a correct miner will be known to every correct miner, it is possible for there to be a suffix of infinite computation beyond the control of the adversary. Any miner may eventually reach the suffix, despite the adversary, because a timeout may be reached. In this synchronous suffix, the probability that a leader block is confirmed by a subsequent block is (2 / 3) 2 So the probability that the leader block is finalized is (2 / 3) 3Therefore, the probability of an infinite computation where no correct leader block is finalized is zero. Thus, for any block b and any point t in the computation, a leader block b' that acknowledges b is final at a point after t' with probability 1. Thus, for any block b known to a correct miner, there exists a subsequent final leader block b' that acknowledges b and therefore distributes b, satisfying the liveness requirement.

[0171] Algorithm 4 is an exemplary protocol conforming to the network synchronization specification, where a designated leader node may transmit a block of a plurality of cryptographically signed blocks to a designated computing node if the block is indicated as unknown to at least one of the first number of computing nodes. Some variations may transmit a block of a plurality of cryptographically signed blocks to a designated computing node for transmission to at least one of the first number of computing nodes if the block is indicated as unknown to at least one of the first number of computing nodes.

[0172] It should be emphasized that variations in the protocol will be apparent to those skilled in the art and are included within the scope of the claims of this application.

[0173]

[0071] Referring also to FIG. 13, there is shown additional exemplary pseudocode for a protocol conforming to network synchronization specifications, according to some embodiments of the present invention.

[0174] Algorithm 5 is a hybrid of Algorithm 3 and Algorithm 4. Algorithm 5 employs all-to-all block communication, as in Algorithm 3. However, instead of using an underlying asynchronous data distribution protocol, as in Algorithm 4, it performs the distribution en passant, and a regular non-leader miner p may send a block b that it has created, including a pointer to the block known to p, to all miners, as shown in line 77. A designated leader p may act similarly to the leader in Algorithm 3 by sending to each responding miner q not only block b, but also all blocks known to p but not known to q to p's knowledge, i.e., [b]\[history[q]. This package may be constructed as in line 76. A miner q may be considered to be responding to p if q responded to the last block sent by p, as shown in line 63.

[0175] In Algorithm 5, the designated leader node may be required to verify that a previous round of blocks has been received from each of at least a second number of computing nodes from which the multiple cryptographically signed blocks were collected, or that the collected blocks include a previous round of blocks from at least a second number of computing nodes, before generating the successive cryptographically signed blocks. The designated leader may also transmit a block indicated as unknown to at least one of the first number of computing nodes, if at least one of the first number of computing nodes meets the functional requirements.

[0176] All miners of Algorithm 5 may send consecutive cryptographically signed blocks to each of a first number of computing nodes that meet the functional requirements. The functional requirements may include unambiguity, responsiveness, coherence, etc.

[0177] If a correct miner knows block b, then eventually every correct miner can know b. This is because for a correct miner p with block b ∈ block and a miner q, if q is correct, q will eventually send a block to p and consider a subsequent round r in which p becomes a cordial leader. If in round r, p's communication history with q indicates that q knows p, then the block is known. Otherwise, p can include b in a package to q along with all blocks in [b] that p does not have evidence that q knows based on the communication history. Thus, q can eventually receive the package. There may be no blocks in the package that contain dangling pointers. This is because p includes everything q may not know in the package, and therefore q can receive it and include them, along with b, in q's block.

[0178] Algorithm 5 can be shown to satisfy the liveness requirement of Definition 1.3 by the infinite computation suffix of Algorithm 5 being beyond the adversary's control. Every block b known to a miner will eventually be known to all miners, just like in the algorithms above.

[0179] Algorithm 6 consists of optimization utilities such as functions that check whether a miner meets functional requirements (e.g., not ambiguous) and functions that check properties of whether a block is valid (e.g., proper, cordial, not ambiguous).

[0180] Optimizations can also be used to weed out faulty miners for reasons such as ambiguity, non-responsiveness, and / or not being cordial. These can easily be developed in different directions, for example to improve leader utilization by bypassing rounds containing faulty leaders immediately, i.e. without timeouts.

[0181] It should be emphasized that variations in the protocol will be apparent to those skilled in the art and are included within the scope of the claims of this application.

[0182] It is expected that many related distributed computing synchronization models, ordering algorithms, and the like will be developed during the life of any patent resulting from this application, and the claims and scope of the terms network, synchronization, and hashing herein are intended to proactively encompass all such new technologies.

[0183] The terms "comprises," "comprising," "includes," "including," "having" and their conjugations mean "including but not limited to."

[0184] The term "consisting of" means "including and limited to."

[0185] The term "consisting essentially of" means that a composition, method, or structure may include additional components, steps, and / or moieties, but only if the additional components, steps, and / or moieties do not materially alter the basic and novel characteristics of the claimed composition, method, or structure.

[0186] As used herein, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" can include a plurality of compounds, including mixtures thereof.

[0187] Throughout this application, various embodiments of the invention may be presented in an approximate format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Thus, the approximate descriptions should be considered as specifically disclosing all practical ordering regimes for distributed computing computations.

[0188] It will be understood that certain features of the invention that are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or with any other described embodiment of the invention, as appropriate. Certain features described in the context of various embodiments should not be construed as essential features of those embodiments, unless the embodiment is inoperable without those elements.

[0189] While the present invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

[0190] It is the intention of the applicants that all publications, patents, and patent applications mentioned herein are incorporated by reference herein as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. In addition, citation or identification of any reference in this application should not be construed as an admission that such reference is available as prior art to the present invention. Section headings, when used, should not be construed as necessarily limiting. Additionally, the priority documents of this application are incorporated herein by reference in their entireties.

Claims

1. 1. A system configured for distributed consensus ordering block registration using a partial order data structure and communicating with a first number of computing nodes over a network, comprising: at least one processing circuit, the at least one processing circuit collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of cryptographic hash pointers, each cryptographic hash pointer pointing to an additional block; using said network to execute a protocol on said plurality of cryptographic signature blocks conforming to a synchronization specification of said network; generating successive cryptographically signed blocks by appending the set of cryptographically signed hash pointers to the successive cryptographically signed blocks such that a path based on the set of cryptographically signed hash pointers exists for each of the plurality of cryptographically signed blocks; The system is configured as follows.

2. 2. The system of claim 1, wherein the set of cryptographic hash pointers added to the successive cryptographic signature blocks is generated by prioritizing sources that do not have a cryptographic hash pointer pointing to them in the set of cryptographic hash pointers included in other blocks.

3. 2. The system of claim 1, wherein the processing circuitry is further configured to: store in a buffer at least one of the plurality of cryptographic signature blocks if at least one cryptographic hash pointer in the set of cryptographic hash pointers points to at least one unknown block.

4. The system of claim 3 , wherein the processing circuitry is further configured to: when the at least one unknown block is collected, move the block from the buffer to the partially ordered data structure.

5. 2. The system of claim 1, wherein a block is indicated as unknown to at least one of the plurality of computing nodes until either the block or a block that includes at least one cryptographic hash pointer that points to the block in a set of cryptographic hash pointers is received from or transmitted to the at least one of the plurality of computing nodes.

6. 2. The system of claim 1, further comprising: maintaining a communication history data structure for storing pointers to cryptographic signature blocks received from each of the first number of computing nodes, wherein the cryptographic signature blocks are indicated by the communication history data structure as unknown to at least one of the first number of computing nodes.

7. 7. The system of claim 6, wherein a protocol conforming to a synchronization specification of the network includes sending a block of the plurality of cryptographically signed blocks to a designated computing node if the block is indicated as unknown to at least one of the first number of computing nodes.

8. generating the successive cryptographic signature blocks further includes verifying that the plurality of cryptographic signature blocks includes blocks of a preceding round from at least a second number of computing nodes; The protocol conforming to the synchronization specification of the network is transmitting the successive cryptographic signature blocks to each of the first number of computing nodes that meet a functionality requirement; receiving blocks of a preceding round from each of at least a second number of computing nodes when the at least one processing circuit implements the designated computing node, and transmitting to at least one of the first number of computing nodes a block indicated as unknown to at least one of the first number of computing nodes when at least one of the first number of computing nodes satisfies the functional requirements. The system of claim 7 further comprising:

9. generating the successive cryptographic signature blocks further includes verifying that the plurality of cryptographic signature blocks includes blocks of a preceding round from at least a second number of computing nodes; The protocol conforming to the synchronization specification of the network is transmitting the successive cryptographic signature blocks to each of the first number of computing nodes that meet a functionality requirement; and transmitting to at least one of the first number of computing nodes a block indicated as unknown to at least one of the first number of computing nodes when blocks of a predetermined number of preceding rounds are received from each of at least a second number of computing nodes and at least one of the first number of computing nodes satisfies the functional requirements, if the at least one processing circuit implements the designated computing node. The system of claim 7 further comprising:

10. The protocol conforming to a synchronization specification of the network, when the at least one processing circuit implements a designated computing node, comprises: generating the successive cryptographic signature blocks further includes verifying that the plurality of cryptographic signature blocks includes blocks of a preceding round from at least a second number of computing nodes; transmitting a block of the plurality of cryptographically signed blocks to at least one of the first number of computing nodes when the block is indicated as unknown to at least one of the first number of computing nodes and at least one of the first number of computing nodes satisfies a functional requirement. The system of claim 6 further comprising:

11. 8. The system of claim 7, wherein the designated computing nodes are designated by a method selected from the group consisting of round robin, a pre-determined pseudo-random sequence, and global perfect coin.

12. 1. A system configured for block registration using a partially ordered data structure and a distributed consensus protocol for communicating with a first number of computing nodes over a network, comprising: at least one processing circuit, the at least one processing circuit collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of pointers to additional blocks; each of the additional blocks pointed to by a cryptographic hash pointer of a set of cryptographic hash pointers for each cryptographic signature block of the plurality of cryptographic signature blocks is collected in the partially ordered data structure or, if present, adds the cryptographic signature block to the partially ordered data structure; When a block generated by a designated computing node is finalized, iteratively or recursively, starting with the block as a first block in an order, the immediately previous block generated by the designated computing node in an associated round and having an associated cryptographic hash pointer in the set of cryptographic hash pointers of a second number of blocks in a round following the associated round serves as the second block and the first block in a next iteration, until the first block is added to a totally ordered data structure, either by adding to the totally ordered data structure each block reachable by a cryptographic hash pointer or by iteratively walking through the set of cryptographic hash pointers of blocks reachable by the cryptographic hash pointers, where the cryptographic hash pointer is in the set of cryptographic hash pointers of the first block but not in the set of cryptographic hash pointers of the second block, the second block is ordered by a deterministic topological sorting method common to the first number of computing nodes, and the block generated in the next iteration is prepended. The system is configured as follows.

13. 13. The system of claim 12, wherein a block is finalized when it is generated by a designated node of a round, and wherein at least a second number of blocks of the second subsequent round, including blocks generated by a designated computing node of a second subsequent round, have at least a second number of pointers in each of a second associated set of cryptographic hash pointers that respectively point to blocks of the first subsequent cycle, each having a cryptographic hash pointer that points to the block in a first associated set of cryptographic hash pointers, and the cryptographic hash pointer that points to the block is the only cryptographic hash pointer in the first associated set of cryptographic hash pointers that points to a block generated by the designated node of the round in the round.

14. The system of claim 12 , wherein the second number is at least more than two-thirds of the first number.

15. 1. A method for block registration using a partially ordered data structure and a distributed consensus protocol for communicating with a first number of computing nodes over a network, comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of pointers to additional blocks; each of the additional blocks pointed to by a cryptographic hash pointer from a set of cryptographic hash pointers for each cryptographic signature block of the plurality of cryptographic signature blocks is collected in the partially ordered data structure or, if present, adds the cryptographic signature block to the partially ordered data structure; When a block generated by a designated computing node is finalized, iteratively or recursively, starting with the block as a first block in an order, the immediately previous block generated by the designated computing node in an associated round and having an associated cryptographic hash pointer in the set of cryptographic hash pointers of a second number of blocks in a round following the associated round serves as the second block and the first block in a next iteration, until the first block is added to a totally ordered data structure, either by adding to the totally ordered data structure each block reachable by a cryptographic hash pointer or by iteratively walking through the set of cryptographic hash pointers of blocks reachable by the cryptographic hash pointers, where the cryptographic hash pointer is in the set of cryptographic hash pointers of the first block but not in the set of cryptographic hash pointers of the second block, the second block is ordered by a deterministic topological sorting method common to the first number of computing nodes, and the block generated in the next iteration is prepended. The method includes:

16. 1. A method of distributed consensus ordering block registration using a partial order data structure and communicating with a first number of computing nodes over a network, comprising: collecting a plurality of cryptographic signature blocks from a plurality of computing nodes of the first number of computing nodes, each block of the plurality of cryptographic signature blocks including a set of cryptographic hash pointers, each cryptographic hash pointer pointing to an additional block; using said network to execute a protocol on said plurality of cryptographic signature blocks conforming to a synchronization specification of said network; generating successive cryptographically signed blocks by appending the set of cryptographically signed hash pointers to the successive cryptographically signed blocks such that a path based on the set of cryptographically signed hash pointers exists for each of the plurality of cryptographically signed blocks; The method includes:

Images