Order-Fairness for Byzantine Consensus

Abstract

Decades of research in both cryptography and distributed systems has extensively studied the problem of state machine replication, also known as Byzantine consensus. A consensus protocol must satisfy two properties: consistency and liveness. These properties ensure that honest participating nodes agree on the same log and dictate when fresh transactions get added. They fail, however, to ensure against adversarial manipulation of the actual ordering of transactions in the log. Indeed, in leader-based protocols (almost all protocols used today), malicious leaders can directly choose the final transaction ordering.

To rectify this problem, we propose a third consensus property: transaction order-fairness. We initiate the first formal investigation of order-fairness and explain its fundamental importance. We provide several natural definitions for order-fairness and analyze the assumptions necessary to realize them.

We also propose a new class of consensus protocols called Aequitas. Aequitas protocols are the first to achieve order-fairness in addition to consistency and liveness. They can be realized in a black-box way using existing broadcast and agreement primitives (or indeed using any consensus protocol), and work in both synchronous and asynchronous network models.

The full version of this paper is available at https://eprint.iacr.org/2020/269  [27].

1 Introduction

The abstraction of state machine replication has been investigated in cryptography and distributed systems literature for the past three decades. At a high level, the goal of a state machine replication protocol is for a set of nodes to agree on an ever-growing, linearly ordered log of messages (transactions). Two properties need to be satisfied by such a protocol: (1) Consistency - all honest nodes must have the same view of the agreed upon log—that is, they must output messages in the same order; and (2) Liveness - messages submitted by clients are added to the log within a reasonable amount of time. In this paper, we will use the terms state machine replication and consensus¹ interchangeably.

Unfortunately, neither consistency nor liveness says anything about the actual ordering of transactions in the final log. A protocol that ensures that all nodes agree on the same ordering is deemed consistent regardless of how the ordering is generated. This leaves room for the definition to be satisfied even if an adversary directly chooses the actual transaction ordering, which is discomforting considering that the ordering is often easy to manipulate  [7]. Moreover, in all existing protocols that rely on a designated “leader” node (e.g., [15, 34, 44]), which includes most used in practice, an adversarial leader may choose to propose transactions in any order.

In this paper, we formulate a new property for byzantine consensus which we call order-fairness. Intuitively, order-fairness denotes the notion that if a large number of nodes receive a transaction $\textsf {\text {tx}}_1$ before another one $\textsf {\text {tx}}_2$, then this should somehow be reflected in the final ordering.

Importance of Fair Transaction Ordering. The need for a notion of fair transaction ordering is immediately clear when looking at financial systems. Here, the execution order can determine the validity and/or profitability of a given transaction. Suppose Bob has $0, and two transactions are initiated: $\textsf {\text {tx}}_0$, which sends $5 from Alice to Bob, and $\textsf {\text {tx}}_1$, which sends $5 from Bob to Carol. If $\textsf {\text {tx}}_0$ is sequenced before $\textsf {\text {tx}}_1$, then both transactions are valid; the opposite ordering invalidates $\textsf {\text {tx}}_1$. Manipulation of transaction ordering is a well known phenomenon on Wall Street  [32], but recent work has shown it to also be commonplace in consensus-based systems such as permissionless blockchains. A recent paper by Daian et al.  [20], for example, reports rampant adversarial manipulation of transactions in the Ethereum network  [23] by bots extracting upwards of USD 6M in revenue from unsophisticated users.

Comparison to Validity in Byzantine Agreement. Beyond its critical practical importance, we believe that order-fairness is a key missing theoretical concept in existing consensus literature. To underscore this point, consider Byzantine agreement  [30], or single-shot agreement, another well-studied problem in consensus literature. For Byzantine agreement, each node starts with a single value within a set $\mathcal {V}$. The goal is for all nodes to agree on the same value. Validity requires that if all honest nodes start with the same value v, then the agreed upon value should also be v.

The property of order-fairness is a natural analog of validity formulated for the consensus problem, i.e., extension of Byzantine agreement to multiple rounds. If all honest nodes start with the belief that a transaction $\textsf {\text {tx}}_1$ precedes another transaction $\textsf {\text {tx}}_2$, by natural analogy with validity, the final output log should sequence $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$. Consequently, we maintain that order-fairness is a natural property of independent theoretical interest in the consensus literature.

1.1 Our Contributions

The main contributions of our paper are three-fold: (1) First, we investigate a natural notion of fair transaction ordering and show why it is impossible to realize. (2) Second, we investigate slightly weaker notions of fair ordering that are intuitive yet achievable. Still, we find that no existing consensus protocol achieves them. (3) Third, we introduce a new class of consensus protocols that we refer to as ${\textsf {Aequitas}}$². ${\textsf {Aequitas}}$ protocols achieve fair transaction ordering while also providing the usual consistency and liveness. We discuss ${\textsf {Aequitas}}$ protocols in both synchronous and asynchronous settings.

Defining Order-Fairness and Impossibility Results. To model our consensus protocols, we use an approach similar to prior work by Pass et al.  [39, 40], wherein protocol nodes receive transactions from clients and need to output or deliver them in a way that satisfies consistency and liveness. We detail our model in Sect. 2. Within this model, we provide the first formalization of the property of order-fairness (Sect. 4). We start with a natural definition based on when transactions are received by nodes.

Definition 1

(Receive-Order-Fairness, informal; formalized in Definition 9). If sufficiently many (at least $\gamma$-fraction) nodes receive a transaction $\textsf {\text {tx}}$ before another transaction $\textsf {\text {tx}}'$, then all honest nodes must output $\textsf {\text {tx}}$ before $\textsf {\text {tx}}'$.

While Definition 1 is intuitive, it turns out that it is impossible to achieve unless we assume very strong synchrony properties and/or a non-corrupting adversary. This result draws from a surprising connection with voter preferences in social choice theory. To highlight this using a simple example, consider three nodes, A, B, and C, that each receive 3 transactions, x, y, and z. A receives them in the order [x, y, z], B in the order [y, z, x] and C in the order [z, x, y]. Notice that a majority of nodes have received (x before y), (y before z) and (z before x)! This scenario, often called the Condorcet paradox  [18], can cause a non-transitive global ordering even when all local orderings are transitive. This is problematic for the notion of receive-order-fairness. Theorem 1 gives an informal description of our impossibility result.

Theorem 1

(Impossibility of receive-order-fairness, informal; formalized in Theorem 2). Consider a system with n nodes where the external network (between users and protocol nodes) is either asynchronous or the maximum delay $\delta$ is at least n rounds. Then, no protocol can achieve all of consistency, liveness, and receive-order-fairness.

Given this impossibility result, we consider a natural relaxation of receive-order-fairness that we call block-receive-order-fairness, or simply block-order-fairness. To see the primary difference between the two definitions, we look at two transactions, $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$, where sufficiently many nodes have received $\textsf {\text {tx}}$ before $\textsf {\text {tx}}'$. While receive-order-fairness requires that $\textsf {\text {tx}}$ be output “before” $\textsf {\text {tx}}'$, block-order-fairness relaxes this to “before or at the same time as.” We refer to transactions delivered at the same time as being in the same “block.”

Definition 2

(Block-Order-Fairness, informal; formalized in Definition 11). If sufficiently many nodes (at least $\gamma$-fraction) receive a transaction $\textsf {\text {tx}}$ before another transaction $\textsf {\text {tx}}'$, then no honest node can deliver $\textsf {\text {tx}}$ in a block after $\textsf {\text {tx}}'$.

This small relaxation allows us to evade the Condorcet paradox by a simple trick: placing paradoxical orderings into the same “block.” We emphasize that block order-fairness does not mean that transactions are partially ordered. Consistency still requires that all nodes output transactions in the same order (within the same block or not). The only difference is that unfair ordering of a set of transactions in our definition without blocks is now, with the use of blocks, considered fair, provided that these transactions appear in the same block.

Further, we note that while receive-order-fairness is impossible to achieve (as pointed out informally in Theorem 1 and formalized later in the paper in Theorem 2), block-order-fairness is not and we provide protocols that guarantee it. We would also like to highlight that our proposed ${\textsf {Aequitas}}$ protocols actually make minimal use of this relaxation. In particular, they achieve the stronger notion of receive-order-fairness except when non-transitive preferences are observed.

${\textsf {Aequitas}}$: Achieving order-fairness. We present a new class of consensus protocols, ${\textsf {Aequitas}}$, that achieve block-order-fairness, in addition to providing consistency and liveness. ${\textsf {Aequitas}}$ protocols make use of two basic primitives in a black-box way: (1) FIFO Broadcast ($\textsf {FIFO}\text {-}\mathsf{BC}$)  [26], which is a basic extension of standard reliable broadcast; and (2) Set Byzantine Agreement ($\textsf {Set}\text {-}\mathsf{BA}$; defined in Sect. 3), which can be achieved from Byzantine agreement.

We note that these are weak primitives and any standard consensus protocol (that achieves consistency and liveness) can also be used to build the $\textsf {FIFO}\text {-}\mathsf{BC}$ and $\textsf {Set}\text {-}\mathsf{BA}$ primitives. This results in an interesting observation: The ${\textsf {Aequitas}}$ technique provides a generic compiler that takes any standard consensus protocol and converts it into one that also provides order-fairness. At a high level, ${\textsf {Aequitas}}$ protocols proceed in three major stages. Each transaction $\textsf {\text {tx}}$ goes through these stages before being delivered.

• 1. Gossip Stage. Nodes gossip transactions in the order that they are received. That is, each node gossips its local transaction ordering.

  For this purpose, we use the FIFO broadcast primitive ($\textsf {FIFO}\text {-}\mathsf{BC}$), which guarantees that broadcasts by an honest node are delivered by other honest nodes in the same order that they were broadcast. Even if the sender is dishonest, $\textsf {FIFO}\text {-}\mathsf{BC}$ guarantees that all honest nodes deliver messages in the same order. As a result, nodes have a consistent view of the transaction orderings of other nodes.

  We use $\mathsf {Log}^j_i$ to denote node i’s view of the order in which node j received transactions, according to how j gossiped them. Note that if node j is malicious, $\mathsf {Log}^j_i$ may arbitrarily differ from the actual order in which j received transactions, but FIFO-BC prevents j from equivocating, i.e., any two honest nodes i and k will have consistent $\mathsf {Log}^j_i$ and $\mathsf {Log}^j_k$. When i records enough logs $\mathsf {Log}^k_i$ that contain $\textsf {\text {tx}}$, we say that the “gossip phase” for $\textsf {\text {tx}}$ is complete.

• 2. Agreement Stage. Nodes agree on the set of nodes whose local orderings should be considered for deciding on the global ordering of a particular transaction.

  To elaborate, at the end of the gossip stage for a transaction $\textsf {\text {tx}}$, a node i ends up with a set $U^\textsf {\text {tx}}_i$ of other nodes whose local orderings i has obtained. That is, $k \in U^\textsf {\text {tx}}_i$ if $\textsf {\text {tx}}\in \mathsf {Log}^k_i$. Note that different nodes may end up with a slightly different set U, but agreement proceeds when enough honest nodes are present in each set. Nodes perform Byzantine agreement to agree on a set $L^\textsf {\text {tx}}$ of nodes whose ordering will be used to finalize the ordering for $\textsf {\text {tx}}$. For this, we define a new primitive $\textsf {Set}\text {-}\mathsf{BA}$ whose validity condition guarantees that if $k \in U^\textsf {\text {tx}}_i$ for all i, then $k \in L^\textsf {\text {tx}}$. It is easy to see how $\textsf {Set}\text {-}\mathsf{BA}$ can be realized by using standard Byzantine agreement to determine the inclusion of each possible value k individually.

• 3. Finalization Stage. Nodes finalize the global ordering of a transaction $\textsf {\text {tx}}$ using the set of local orderings decided on in the agreement stage.

  Suppose that the agreement stage for a transaction $\textsf {\text {tx}}$ resulted in the set $L^\textsf {\text {tx}}$. Now, if there is any other transaction $\textsf {\text {tx}}'$ such that $\textsf {\text {tx}}'$ is ordered before $\textsf {\text {tx}}$ in a large number of these local logs, it signifies that $\textsf {\text {tx}}$ should be delivered after $\textsf {\text {tx}}'$. In other words, the finalization of $\textsf {\text {tx}}$ depends on waiting until $\textsf {\text {tx}}'$ has been delivered.

  To characterize such ordering dependencies between transactions, a node i maintains a directed graph $G_i$, where vertices represent transactions and an edge from a to b denotes that b is waiting for a. Since nodes are building this graph on the same “data” (the set of local logs agreed upon in the agreement phase), nodes will have consistent graphs. That is, if an edge (a, b) exists in $G_i$, then it will also (eventually) exist in $G_j$, if i and j are both honest.

  We present two finalization techniques, a leader-based one and a leaderless one. For the leader-based technique, resolving any partial ordering within the graph is delegated to a leader node. We emphasize that order-fairness is not lost. The leader is only able to choose the ordering for transactions that are not required to be ordered a certain way. We present another, leaderless technique that requires no further communication between nodes. We find that both realize a slightly weaker notion of liveness than the standard one, even in the synchronous setting. Specifically, future transactions are required to be input to the system in order to “flush out” earlier transactions. We formally define “weak-liveness” in Sect. 2.

It is worth pointing out that the first two stages (gossip and agreement) are fairly straightforward to understand and easy to achieve. The third stage is somewhat complex, as it needs to avoid the Condorcet paradox while continuing to maintain both consistency and order-fairness.

${\textsf {Aequitas}}$ Protocols. In summary, we present the first consensus protocols that provide order-fairness. We provide a leader-based and a leaderless protocol each for the synchronous and asynchronous settings, for a total of four protocols that follow the same general outline. These protocols all provide consistency, block order-fairness, and some form of liveness. Figure 1 shows a comparison.

Fig. 1.

The ${\textsf {Aequitas}}$ protocols

Paper Organization. The rest of the paper is organized as follows. We discuss our results in the context of related work in Sect. 1.2. We describe our formal framework, along with other preliminaries, in Sect. 2. In Sect. 3, we provide the building blocks for our protocol constructions. Section 4 formally introduces our notion of order-fairness. Section 5 provides a general overview of our constructions; we detail our leaderless construction for the synchronous setting in Sect. 6. Due to space constraints, we defer other constructions and results, as well as several proofs to the full version  [27] of our paper.

1.2 Related Work

While there is an extensive literature on consensus protocols, to the best of our knowledge, no previous work formally captures a notion of order-fairness like the one we introduce. The term “fairness” has been used widely in blockchain and cryptography literature, but for properties unrelated to ours.

Broadcast Primitives. Byzantine broadcast, or the Byzantine Generals Problem [30], is the elementary broadcast primitive where a designated sender broadcasts a single value to a set of receiving nodes. In a Byzantine broadcast protocol with the key property of consistency, all honest receivers output the same value. Reliable broadcast is a continuous version of Byzantine broadcast where the sender broadcasts multiple values which must be eventually delivered by nodes if the sender is honest. Three orthogonal properties can be added onto reliable broadcast to give stronger notions. FIFO-ordering provides first-in first-out ordering on the messages broadcast by an honest sender. We refer to such a protocol as FIFO Broadcast or OARcast [26]. Local-ordering (also called causal-ordering) ensures that if a node broadcasts a message $m'$ after receiving some other message m, then m will be ordered before $m'$. The total-ordering property ensures that all honest nodes deliver messages broadcast potentially by different senders in the same order. This notion is usually called atomic broadcast [19], which is well-known to be equivalent to the consensus problem. Adding all three properties to reliable broadcast results in the notion of Causal FIFO Atomic Broadcast which still does not provide the order-fairness property that we are looking for. The main problem is none of the requirements consider a global notion of FIFO ordering based on multiple senders.

Our order-fairness property does enforce such a notion according to the following idea: If enough nodes broadcast a message m before another message $m'$, then honest nodes will respect this ordering. Adding this property to atomic broadcast results in a new broadcast notion, which we call “Global FIFO Atomic Broadcast.” Consequently, requiring order-fairness along with standard consensus properties of consistency and liveness will be equivalent to this new notion of Global FIFO Atomic Broadcast.

We note that our setup is also slightly different than earlier notions. We assume that any message broadcast by an honest node is also eventually broadcast by all honest nodes. This allows us to redefine liveness in terms of being broadcast by enough nodes. This also means that identical messages broadcast by different nodes can now be delivered together as a single message. Global FIFO ordering is defined on the ordering of these messages. Note that it no longer makes sense to talk about (single source) FIFO order or causal order as identical messages, potentially broadcast at different positions by different nodes, are now delivered as a single message.

Consensus Protocols. Hundreds of Byzantine fault tolerant consensus protocols have been proposed over the years, with PBFT [15] being perhaps the most well known. Multiple survey papers [7, 10] have aimed to systematize this vast literature. Many papers provide efficiency improvements while maintaining the basic leader-based structure of PBFT. That is, a leader or primary node is responsible for proposing the transactions in the current round. In such leader-based protocols ([2, 3, 5, 8, 17, 34, 42,43,44], just to name a few), the leader node can propose transactions in the order of its choosing. The leader is also capable of suppressing transactions, at least temporarily, until an honest node becomes the new leader. We highlight that in previously explored leader-based protocols, nodes do not know the ordering in which transactions were received by everyone. This means that a leader’s proposal can only be rejected based on validity of transactions rather than the fairness of their ordering. Order-fairness is thus not achieved in existing leader-based protocols.

Some protocols provide transaction censorship resistance, such that malicious nodes cannot censor specific transactions based on their content. For this, in protocols like [4, 11, 36], transactions are encrypted, and the contents are revealed only once their ordering is fixed. Separately, protocols like [4, 29, 31] rely on a reputation based system to detect unfair censorship. Censorship resistance is strictly weaker than the order-fairness we consider for three reasons. First, in practice, even if transaction data is temporarily encrypted, metadata such as a user identifier or a client IP address can be used to censor a particular transaction. Second, a malicious leader can still blindly reorder or censor transactions based on just their ciphertext. But perhaps more importantly, a malicious leader colluding with a user will know the ciphertext corresponding to the user’s transaction and can thus unfairly order this transaction before others.

Other Uses of the Word Fairness. The term fairness has been used before in consensus literature for notions unrelated to ours. One popular use case relates to fairness in block mining in Proof-of-Work (PoW) blockchains, which intuitively requires that a node’s mining rewards be proportional to its relative computational power. That is, no node should be able to mine selfishly [24] to obtain more rewards than its fair share. This fairness notion is met by protocols in [1, 31, 33, 35, 37], among others.

Another related definition considers fairness in terms of the opportunities each node gets to append transactions to the ledger. This includes both fair leader election (in leader based protocols) and fair committee election (in hybrid consensus protocols). This definition is considered in [1, 25, 28, 31, 38]. We note that even if the leader election process is fair, the current leader still has the power to manipulate transaction ordering.

Fairness has also been used in the context of “fair exchange,” which provides a way for mutually distrusting parties to exchange digital goods in a secure way. This notion is unrelated to ours but we mention it for completeness.

Works That Mention Fair Transaction Ordering. Helix  [4] alludes to fair transaction ordering, but only considers censorship resistance and fair committee election. It uses threshold encryption to choose a random set of pending transactions for inclusion in the current block. Hashgraph  [6] considers our notion of receive-order fairness, but provides no formal definitions. Moreover, it fails to realize the impossibility of this notion of fairness resulting from the Condorcet paradox  [18]. As a result, we identify an elementary attack on the Hashgraph protocol that allows an adversarial node to control transaction ordering. The main problem in Hashgraph is the use of timestamp based ordering. In Sect. 5, we provide a brief explanation for why this does not work and defer the description of our attack to the full version  [27].

2 Definitions, Framework, and Preliminaries

In this section, we describe the general execution framework that we will use for expressing and analyzing consensus protocols. We adopt an approach like that of Pass and Shi  [39, 40] and Chan et al.  [16]. We focus on the “permissioned” setting, where the number of consensus nodes n, as well as their identities, are known a priori to all participants. While arbitrary clients can send messages to these nodes, only a fixed set of nodes will take part in the consensus protocol. We are interested in protocols for several network settings (e.g. synchronous, partially synchronous, and asynchronous) and define constrained environments for these settings by imposing restrictions that an adversary must respect. Due to space constraints, we only include the relevant formalism for the constructions in this paper. For the complete details of the model, we refer the reader to the full version  [27].

2.1 Protocol Execution Model

Interactive Turing Machines (ITMs). We adopt the widely used Interactive Turing Machine (ITM) approach rooted in the Universal Composability framework  [12]. Informally, a protocol details how nodes interact with each other, where each node is represented by an ITM. As standard practice in cryptography literature  [12,13,14], we use an environment $\mathcal {Z}(1^{\kappa })$ (where $\kappa$ is the security parameter) to direct the protocol execution. $\mathcal {Z}$ is responsible for activating nodes as either honest or corrupt, providing messages as inputs to nodes, and delivering messages between nodes. Honest nodes follow the protocol description while corrupt nodes are assumed to be controlled by an adversary, denoted by $\mathcal {A}$. $\mathcal {A}$ is able to read all inputs/messages sent to corrupt nodes and can set all outputs/messages to be sent. The adversary also decides when messages sent over the network get delivered, subject to any network assumptions.

Rounds. We assume that $\mathcal {Z}$ maintains a global clock. The clock is a global functionality [14] that contains a simple monotonic counter which can be updated adversarially by the environment. In the synchronous setting, we can model protocol execution in discrete time steps or rounds. At the start of each round, each node receives a set $\mathsf {txs}$ of transactions from the environment $\mathcal {Z}$. Transactions are assumed to be submitted by clients, but using the environment abstraction avoids having to model clients explicitly. At the end of each round, each node outputs an ordered log ${\textsf {LOG}}$ to $\mathcal {Z}$ which intuitively represents the list of transactions ordered by the node so far. We assume that $\mathcal {Z}$ always signals the start of a new round to each node. Rounds in the partially synchronous setting work similarly to the synchronous setting. In the asynchronous setting, the clock is not accessible to the protocol nodes. $\mathcal {Z}$ can provide user transactions and communication messages to nodes at any time. Any protocol that works in the asynchronous setting should not rely on the current time. Throughout the paper, we may use the terms “time” and “round” interchangeably.

Notational Conventions. We use $\kappa$ to denote the security parameter. $\mathcal {N}$ denotes the set of protocol nodes. For a protocol $\mathrm {\Pi }$, ${\textsf {EXEC}}^{\mathrm {\Pi }}(\mathcal {A}, \mathcal {Z}, \kappa )$ represents the random variable for all possible execution traces of $\mathrm {\Pi }$ w.r.t. adversary $\mathcal {A}$ and environment $\mathcal {Z}$. We use to denote randomly sampling an execution. $\left| {\textsf {view}}\right|$ denotes the number of rounds in ${\textsf {view}}$.

Corruption Model. Since we are concerned only with the permissioned setting, we consider environments $\mathcal {Z}$ that spawn a set of nodes, numbered from 1 to n at the start, and never spawn additional nodes. At any point, $\mathcal {A}$ can ask $\mathcal {Z}$ to corrupt a particular node for which $\mathcal {Z}$ sends a ${\texttt {corrupt}}$ signal to that node. When this happens, the internal state of the node gets exposed to $\mathcal {A}$ and $\mathcal {A}$ henceforth fully controls the node. A node is said to be honest in a given ${\textsf {view}}$ if it is never under adversarial control. Otherwise, it is said to be corrupt or Byzantine. $\mathcal {A}$ can corrupt nodes at any point during the protocol’s execution; but once a node is corrupted, it cannot become honest at a later point. The corruption parameter f denotes the maximum number of nodes that $\mathcal {A}$ can corrupt.

Communication and Network Model. As mentioned before, $\mathcal {Z}$ provides transactions sent by users as inputs to nodes and also handles communication between nodes. We assume that a node can broadcast messages to others through authenticated channels. Furthermore, we assume that the adversary $\mathcal {A}$ cannot modify messages sent by honest nodes but can reorder or delay messages, possibly constrained by the specific setting.

We differentiate between two networks in our model—an internal network for communication between nodes and an external network for how external users send transactions to nodes. We emphasize that $\mathcal {A}$ is only in charge of scheduling message delivery for the internal network. The external network may reside in other parts of the application (not relevant to the consensus protocol) and is managed by $\mathcal {Z}$ (and possibly by some other network adversary). For both networks, we consider the synchronous setting  [22] (where the network delay bound is known), the partially synchronous setting  [21] (where the network delay bound is finite but unknown), and the asynchronous setting  [9] (where the network delay is unbounded).

2.2 Execution Environments

Clients submit transactions by sending them to all nodes. As mentioned before, we do not explicitly model clients, but rather have transactions input by $\mathcal {Z}$.

External Network. The external network models the channel between the system clients and the protocol nodes. By a synchronous external network, we mean that any transaction that is received from $\mathcal {Z}$ by a node reaches all other nodes within a known time. This is formally defined in Definition 3.

Definition 3

(External Synchronous Setting). We say that $(\mathcal {A}, \mathcal {Z})$ respects $\varDelta _\mathrm {\mathsf {ext}}= (\mathrm {\mathsf {full}}, \delta )$ $\mathrm {\mathsf {ext}}$-synchrony w.r.t. protocol $\mathrm {\Pi }$ if for every $\kappa \in \mathbb {N}$ and ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, the following conditions hold: (1) $\mathcal {Z}$ provides $\delta$ to all nodes upon spawning; (2) If $\mathcal {Z}$ provides an input message m to a node in the $\mathsf {txs}$ set at time t, then at any time $t' \ge t + \delta$, all other nodes will also have received message m as input.

For the partially synchronous setting, we assume that $\delta$ exists but is unknown to the nodes, and not provided by $\mathcal {Z}$. For the asynchronous setting, we only assume that transactions are not dropped by the network—they eventually get delivered to all the nodes.

Internal Network. The internal network represents the network between nodes and is usually the standard network considered for consensus problems. We formalize the internal synchrony assumption in Definition 4. The partially synchronous and asynchronous settings are defined similarly to the corresponding notions for the external network.

Definition 4

(Internal Synchronous Setting). We say that $(\mathcal {A}, \mathcal {Z})$ respects $\varDelta _\mathrm {\mathsf {int}}= (\mathrm {\mathsf {full}}, \delta )$ $\mathrm {\mathsf {int}}$-synchrony w.r.t. protocol $\mathrm {\Pi }$ if for every $\kappa \in \mathbb {N}$ and ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, the following conditions hold: (1) $\mathcal {Z}$ provides $\delta$ to all nodes upon spawning; (2) If an honest node sends a message at time t, then at any time $t' \ge t + \delta$, all recipient(s) will have received the message.

Network Nomenclature. We say that the network is completely synchronous (resp. completely asynchronous) if both the external and the internal network are synchronous (resp. asynchronous). We use $\textsf {not}\text {-}\textsf {async}$ to denote both the synchronous setting and the partially synchronous setting.

Permissioned Setting. For the “permissioned” or “classical” environment, we require that $\mathcal {Z}$ spawn all nodes up front and not spawn any new nodes during the protocol execution. Furthermore, all nodes know the identity of all other nodes in the protocol. We define the permissioned environment in Definition 5.

Definition 5

(Classical Permissioned Environment). We say that $(\mathcal {A}, \mathcal {Z})$ respects $(n,f, \varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}})$-classical execution w.r.t. a protocol $\mathrm {\Pi }$ if it respects $\varDelta _\mathrm {\mathsf {int}}$ $\mathrm {\mathsf {int}}$-synchrony, $\varDelta _\mathrm {\mathsf {ext}}$ $\mathrm {\mathsf {ext}}$-synchrony and for every $\kappa \in \mathbb {N}$ and ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, the following conditions hold: (1) $\mathcal {Z}$ spawns a set of nodes numbered from 1 to n at the start of the protocol and never spawns any nodes later; (2) $\mathcal {Z}$ does not corrupt more than f nodes; (3) $\mathcal {Z}$ provides all nodes n, f as well as any other public parameters upon spawning.

For all constraints on $(\mathcal {A}, \mathcal {Z})$, when the context is clear, we may choose to exclude the protocol we are referring to.

2.3 The State Machine Replication Abstraction

In the state machine replication or consensus problem, a set of nodes try to agree on a growing, linearly ordered log. At the start of each round, $\mathcal {Z}$ provides a set $\mathsf {txs}$ (possibly empty) of transactions to protocol nodes. We assume that the transactions input by $\mathcal {Z}$ are unique. At any time, nodes may also choose to deliver transactions by outputting a ${\textsf {LOG}}$ to $\mathcal {Z}$. The ${\textsf {LOG}}$ can be thought of as a totally ordered sequence where each element is an ordered set of transactions. We refer to the set of transactions at an index of the ${\textsf {LOG}}$ as a “block.” The ${\textsf {LOG}}$ represents the set of transactions committed by a node so far.

Transaction Nomenclature. When discussing the trajectory of a transaction, we say that a transaction $\textsf {\text {tx}}$ is received by a node when it is given as input to the node by $\mathcal {Z}$. A transaction $\textsf {\text {tx}}$ is delivered or output by a node when it is included in a ${\textsf {LOG}}$ output by the node to $\mathcal {Z}$.

Notation for the Ordered Log. $\mathcal {T}$ denotes the space of all possible transactions. Let ${\textsf {LOG}}_i$ represent the most recent log output by node i to the environment, i.e., the ordered list of transactions that node i has delivered so far. For two logs ${\textsf {LOG}}$ and ${\textsf {LOG}}'$, we define a relation $\preceq$ which intuitively signifies a “prefix” notion. ${\textsf {LOG}}\preceq {\textsf {LOG}}'$ stands for “${\textsf {LOG}}$ is a prefix of ${\textsf {LOG}}'$.” We assume that for any x, we have $x \preceq x$ and $\emptyset \preceq x$. ${\textsf {LOG}}[p]$ denotes the $p^\text {th}$ element in ${\textsf {LOG}}$. ${\textsf {LOG}}(m)$ denotes the number p such that ${\textsf {LOG}}[p]$ contains m.

The security of a state machine replication protocol is now defined as follows:

Definition 6

(Security of state machine replication [40]). We say that a protocol $\mathrm {\Pi }$ satisfies consistency (resp. $(T_\mathrm {warmup}, T_\mathrm {confirm})$-liveness) w.r.t. $(\mathcal {A}, \mathcal {Z})$ if there exists a negligible function ${\textsf {negl}}(\cdot )$ such that for any $\kappa \in \mathbb {N}$, consistency (resp. $(T_\mathrm {warmup}, T_\mathrm {confirm})$-liveness) is satisfied except with ${\textsf {negl}}(\kappa )$ probability over the choice of where ${\textsf {negl}}$ is negligible in $\kappa$. For a particular ${\textsf {view}}$, we define the properties as below:

• (Consistency) A ${\textsf {view}}$ satisfies consistency if the following holds:

  • Common Prefix. If an honest node i outputs ${\textsf {LOG}}$ to $\mathcal {Z}$ at time t and an honest node j outputs ${\textsf {LOG}}'$ to $\mathcal {Z}$ at time $t'$, then it holds that either ${\textsf {LOG}}\preceq {\textsf {LOG}}'$ or ${\textsf {LOG}}' \preceq {\textsf {LOG}}$.

  • Future Self Consistency. If a node that is honest between times t and $t'$, outputs ${\textsf {LOG}}$ at time t and ${\textsf {LOG}}'$ at time $t' \ge t$ to the environment $\mathcal {Z}$, then it holds that ${\textsf {LOG}}\preceq {\textsf {LOG}}'$.

• (Liveness) A ${\textsf {view}}$ satisfies $(T_\mathrm {warmup}, T_\mathrm {confirm})$-liveness if the following holds: At a time t such that ${T_\mathrm {warmup}< t \le \left| {\textsf {view}}\right| }$, if an honest node either received a transaction m from $\mathcal {Z}$ or output m in its log to $\mathcal {Z}$, then for any honest node i and any time $t' \ge t + T_\mathrm {confirm}; t' \le \left| {\textsf {view}}\right|$, it holds that m is in the log output by node i at time $t'$.

Here, $T_\mathrm {confirm}$ and $T_\mathrm {warmup}$ are polynomial functions in $\kappa$, n, f, any maximum network delay bounds as defined in $\varDelta _\mathrm {\mathsf {ext}}$ and $\varDelta _\mathrm {\mathsf {int}}$, as well as the actual network delay. $T_\mathrm {warmup}$ is the protocol’s warmup time, until which point liveness need not be satisfied. $T_\mathrm {confirm}$ is the maximum time it takes for a transaction (input after the warmup time) to be delivered by all honest nodes.

Weak Liveness. The standard definition of liveness of a transaction $\textsf {\text {tx}}$ (from Definition 6) is independent of what happens in the rest of the protocol’s execution. Sometimes however, it may be enough for a protocol to be live only if transactions continue to be received by the system. For example, a transaction $\textsf {\text {tx}}$ will only be delivered if there is some transaction that is received by all nodes sufficiently after $\textsf {\text {tx}}$. Intuitively, later transactions will cause earlier ones to be “flushed out” of the system. We note that this subtle distinction between the two liveness definitions is rarely considered in the literature. We found that some leaderless protocols (i.e. those that are not based on a leader node) like  [6, 41] implicitly ignore this distinction. Along similar lines, we define a weaker version of conventional liveness, which we call “weak-liveness.” Despite the technical difference, we think that it should be acceptable in most real world systems. For a particular ${\textsf {view}}$, we define weak-liveness below.

• (Weak Liveness) A ${\textsf {view}}$ satisfies $(T_\mathrm {warmup}, T_\mathrm {confirm})$-weak-liveness if the following holds: Suppose that at a time t such that $t > T_\mathrm {warmup}$, an honest node either received a transaction m from $\mathcal {Z}$ or output m in its log to $\mathcal {Z}$. Let $\mathsf {T}$ be a set built recursively as follows: (1) Add m to $\mathsf {T}$; (2) For $m_0 \in \mathsf {T}$, add to $\mathsf {T}$, all transactions $m_0'$ that were received by at least one honest node before $m_0$. Now if another transaction $m'$ was received at time $t'$ and is such that it was first received by a node after all nodes received all transactions in $\mathsf {T}$, then for any honest node i and any time $t'' \ge t'+T_\mathrm {confirm}; t'' \le \left| {\textsf {view}}\right|$, it holds that m is in the log output by node i at time $t''$.

3 Building Blocks

We start by describing some useful primitives that will form the foundation for designing our fair ordering consensus protocols. More specifically, we will utilize two primitives: (1) Set Byzantine Agreement $(\textsf {Set}\text {-}\mathsf{BA})$; and (2) FIFO Broadcast $(\textsf {FIFO}\text {-}\mathsf{BC})$. We show how to build $\textsf {Set}\text {-}\mathsf{BA}$ from Byzantine agreement and $\textsf {FIFO}\text {-}\mathsf{BC}$ from reliable broadcast in the full version  [27].

Subroutines and Composition. We follow standard conventions to enable secure composition. Each instance of a protocol is spawned with a session identifier $\mathsf {sid}$. We use $\mathrm {\Pi }[\mathsf {sid}]$ to denote the instance of protocol $\mathrm {\Pi }$ with session id $\mathsf {sid}$. Each protocol may take inputs from and return outputs to an environment. Note that this “environment” may be different for any subroutines called.

3.1 Set Byzantine Agreement

Definitions. In a ($\mathsf {poly}$) Set Byzantine Agreement protocol (Set-BA), participating nodes will try to agree on a set of values. At the start of the protocol, each node receives any public parameters from $\mathcal {Z}$. Each node i in the set $\mathcal {P}$ of participating nodes also receives a set $U_i \subseteq S$ as input from $\mathcal {Z}$. The set S is also known to all nodes and its description is polynomial in $\kappa$. At the end of the protocol, each honest node $j \in \mathcal {P}$ outputs a set of the agreed upon values $O_j$.

Definition 7

(Security of Set-BA). A $\textsf {Set}\text {-}\mathsf{BA}$ protocol ${\mathrm {\Pi }_{\text {sba}}}$ satisfies agreement, inclusion validity, and exclusion validity w.r.t. $(\mathcal {A}, \mathcal {Z})$ if for all $\kappa \in \mathbb {N}$, the following properties hold except with negligible probability over .

• (Agreement) If honest nodes i and j output the sets $O_i$ and $O_j$ respectively, then $O_i = O_j$.

• (Inclusion Validity) If an element is in the input sets of all nodes, then it will also be in the output sets of all honest nodes.

• (Exclusion Validity) If an element is not in any input set, then it is not in any honest output set.

For a given ${\textsf {view}}$, we also say that ${\mathrm {\Pi }_{\text {sba}}}$ satisfies $T^\text {sba}_\mathrm {confirm}$-liveness, if all honest nodes output in at most $T^\text {sba}_\mathrm {confirm}$ rounds after all honest nodes have input their starting value. Lemma 1 shows a helpful result that any outputs are “honestly proposed.”

Lemma 1

Consider any set Byzantine agreement protocol ${\mathrm {\Pi }_{\text {sba}}}$ that satisfies agreement, inclusion validity, and exclusion validity (w.r.t $(\mathcal {A}, \mathcal {Z})$). Except for a negligible number of views, ${\mathrm {\Pi }_{\text {sba}}}$ also satisfies the following:

• (Honest Proposal) If an honest node outputs the set O, then for every $c \in O$, there exists $i \in \mathcal {P}$ such that i is honest and $c \in U_i$.

3.2 FIFO Broadcast

Single source FIFO (first in, first out) broadcast (also called Ordered Authenticated Reliable broadcast or OARcast in  [26]) is a broadcast primitive in which all honest nodes in the protocol need to deliver messages in the same order as they were broadcast by the sender. In one instantiation of a FIFO broadcast protocol, we consider a single designated sender who broadcasts a sequence of messages to all other nodes. If the sender is honest, each honest node must deliver the messages in the same order as they were broadcast. If the sender is dishonest, all honest nodes must deliver messages in the same order as each other; except now, this order may be different than the one broadcast by the sender. When composing several FIFO broadcast primitives together with different senders, FIFO order is maintained for each individual sender but different honest nodes may deliver messages from different senders in different orders.

Definitions. At the start of the FIFO Broadcast $(\textsf {FIFO}\text {-}\mathsf{BC})$ protocol, each node receives the appropriate public parameters from the environment. At any time, the designated sender may also receive as input a message m from the environment. At any time, nodes can choose to deliver messages.

Definition 8

(Security of $(\textsf {FIFO}\text {-}\mathsf{BC})$). A $\textsf {FIFO}\text {-}\mathsf{BC}$ protocol ${\mathrm {\Pi }_{\text {fifocast}}}$ satisfies liveness, agreement, and FIFO-order w.r.t. $(\mathcal {A}, \mathcal {Z})$ if for all $\kappa \in \mathbb {N}$, the following properties hold except with negligible probability over .

• ($(T^\mathrm {fifocast}_\mathrm {warmup},T^\mathrm {fifocast}_\mathrm {confirm})$-Liveness) If the sender is honest and receives a message m as input in round $r > T^\mathrm {fifocast}_\mathrm {warmup}$, or if an honest node delivers m in round $r > T^\mathrm {fifocast}_\mathrm {warmup}$, then all honest nodes will have delivered m by round $r + T^\mathrm {fifocast}_\mathrm {confirm}$.

• (Agreement) If an honest node delivers a message m before $m'$, then no honest node delivers $m'$ unless it has already delivered m.

• (FIFO-Order) If the sender is honest and is input a message m before $m'$, then no honest node delivers $m'$ unless it has already delivered m.

$T^\mathrm {fifocast}_\mathrm {confirm}$ is a polynomial in $\kappa , n, f$ and the internal network delay.

Notation. Let ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid}, j)]$ denote the instance of the protocol ${\mathrm {\Pi }_{\text {fifocast}}}$ where node j is the designated sender. In a consensus protocol that invokes ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},j)]$, we assume that each node i keeps track of the messages delivered (i.e. messages broadcast by node j) in a local log $\mathsf {Log}^{(\mathsf {sid},j)}_i$. This represents node i’s view of broadcasts from node j in the session $\mathsf {sid}$. When the session id is clear from context, we may simply write $\mathsf {Log}^j_i$. Two local logs $\mathsf {Log}$ and $\mathsf {Log}'$ are called “equal until $\textsf {\text {tx}}$”, denoted by $\approx _\textsf {\text {tx}}$, if they are equivalent until the occurrence of $\textsf {\text {tx}}$. $\mathsf {Log}[p]$ denotes the $p^\text {th}$ element in $\mathsf {Log}$. $\mathsf {Log}(m)$ denotes the number p such that $\mathsf {Log}[p]$ contains m. Consequently, $\mathsf {Log}(m) < \mathsf {Log}(m')$ signifies that m appears before $m'$ in $\mathsf {Log}$.

4 Defining Fair Ordering

We formally define fair ordering in this section. As it turns out, providing a definition that is achievable by protocols, yet intuitive, is not trivial. Some natural definitions are not achievable except under strong assumptions. We use this section to also go through these definitions that led to our final definition.

(Attempt 1) – Send-order-fairness. A strawman approach is to require ordering to be in terms of when transactions were sent by clients. For instance, if a transaction $\textsf {\text {tx}}_1$ was sent by a client before another transaction $\textsf {\text {tx}}_2$ (possibly by another client), then $\textsf {\text {tx}}_1$ should appear before $\textsf {\text {tx}}_2$ in the agreed upon log. Not surprisingly, this can lead to several problems: most importantly, there needs to be a trusted way to timestamp a transaction at the client side. We discuss the possibility of achieving it in practice using trusted hardware in the full version  [27].

(Attempt 2) – Receive-order-fairness. The challenges of send-order-fairness suggest it would be more prudent to define fair ordering in terms of when the consensus nodes actually receive transactions. Intuitively, “receive order” means that the fair ordering is defined by looking at when enough nodes receive a particular transaction. For instance, if sufficiently many nodes receive a transaction $\textsf {\text {tx}}_1$ before another transaction $\textsf {\text {tx}}_2$, then $\textsf {\text {tx}}_1$ must appear before $\textsf {\text {tx}}_2$ in the final log. “Sufficiently many” is parameterized using $\gamma$.

Definition 9

(Receive-order-fairness, restatement of Definition 1 ).

For a ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, define receive-order-fairness as follows:

• A ${\textsf {view}}$ satisfies $(\gamma , T_\mathrm {warmup})$ receive-order-fairness if the following holds: For any two transactions m and $m'$, let $\eta$ be the number of nodes that received both transactions between times $T_\mathrm {warmup}$ and $\left| {\textsf {view}}\right|$. If at least $\gamma \eta$ of those nodes received m before $m'$ from $\mathcal {Z}$, then for all honest nodes i, i does not deliver $m'$ unless it has previously delivered m.

A protocol $\mathrm {\Pi }$ satisfies $(\gamma , T_\mathrm {warmup})$ receive-order-fairness w.r.t $(\mathcal {A}, \mathcal {Z})$ if there is a negligible function ${\textsf {negl}}(\cdot )$ such that for any $\kappa \in \mathbb {N}$, the order-fairness property is satisfied except with probability ${\textsf {negl}}(\kappa )$ over .

4.1 Condorcet Paradox and the Impossibility of Fair Ordering

The Condorcet paradox  [18], or the “voting paradox”, is a result in social choice theory that shows how some situations can lead to non-transitive collective voting preferences even if the preferences of individual voters are transitive. To illustrate how this applies to fair ordering, let us look at a simple example:

Example 1

Suppose that there are 3 nodes: A, B, and C. In the protocol execution, 3 transactions, $\textsf {\text {tx}}_1, \textsf {\text {tx}}_2$, and $\textsf {\text {tx}}_3$ are sent by clients to all the nodes.

• Node A receives transactions in the order $\textsf {\text {tx}}_1, \textsf {\text {tx}}_2, \textsf {\text {tx}}_3$.

• Node B receives transactions in the order $\textsf {\text {tx}}_2, \textsf {\text {tx}}_3, \textsf {\text {tx}}_1$.

• Node C receives transactions in the order $\textsf {\text {tx}}_3, \textsf {\text {tx}}_1, \textsf {\text {tx}}_2$.

Now, 2 nodes (A and C) received $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$, 2 nodes (A and B) received $\textsf {\text {tx}}_2$ before $\textsf {\text {tx}}_3$, and 2 nodes (B and C) received $\textsf {\text {tx}}_3$ before $\textsf {\text {tx}}_1$. It is easy to see that no protocol can satisfy fair ordering for $\gamma \le \frac{2}{3}$, since such a protocol would have to include $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$; $\textsf {\text {tx}}_2$ before $\textsf {\text {tx}}_3$; and $\textsf {\text {tx}}_3$ before $\textsf {\text {tx}}_1$ in its final log.

Theorem 2 generalizes this observation to show an impossibility for $\gamma \le \frac{n-1}{n}$. Furthermore, it also shows that when $f \ge 1$, even $\gamma = 1$ receive-order-fairness is impossible to achieve.

Theorem 2

(Restatement of Theorem 1). Consider any $n,f \ge 1,\varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}}$ where $\varDelta _\mathrm {\mathsf {ext}}$ is either asynchronous or $(\textsf {not}\text {-}\textsf {async}, \delta _\mathrm {\mathsf {ext}}\ge n)$. Let $\gamma \le 1$. If a consensus protocol $\mathrm {\Pi }$ satisfies consistency and $(T_\mathrm {warmup}, T_\mathrm {confirm})$ liveness w.r.t. all $(\mathcal {A}, \mathcal {Z})$ that respect $(n,f,\varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}})$-classical execution, then it cannot also satisfy $(\gamma , T_\mathrm {warmup})$ receive-order-fairness.

Proof (Sketch)

Taking inspiration from the counterexample in Example 1, we first show the result for $\gamma \le \frac{n-1}{n}$. Denote the nodes in the system by the numbers 1 to n. Suppose that clients submit n transactions $\textsf {\text {tx}}_1$ to $\textsf {\text {tx}}_n$. Further, suppose that node 1 receives the transactions in the order $\textsf {\text {tx}}_1, \textsf {\text {tx}}_2, \cdots , \textsf {\text {tx}}_n$ and any node $i \ne 1$ receives the transactions in the order $\textsf {\text {tx}}_i, \cdots , \textsf {\text {tx}}_n, \textsf {\text {tx}}_1, \cdots , \textsf {\text {tx}}_{i-1}$.

Now, it is straightforward to see that all nodes except node 2 received $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$, all nodes except node 3 received $\textsf {\text {tx}}_2$ before $\textsf {\text {tx}}_3$ and so on. Finally, all nodes except node 1 received $\textsf {\text {tx}}_n$ before $\textsf {\text {tx}}_1$. This means that any consensus protocol that provides order-fairness for $\gamma \le \frac{n-1}{n}$ must order $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$, $\cdots$, $\textsf {\text {tx}}_{n-1}$ before $\textsf {\text {tx}}_n$, and $\textsf {\text {tx}}_n$ before $\textsf {\text {tx}}_1$ which is a contradiction.

To see the result for $\gamma = 1$, since $f \ge 1$, we observe that the adversary $\mathcal {A}$ can simply crash a single node N. Suppose that all other nodes receive $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$. Now, since the node N sends no messages, other nodes do not know the order in which it received $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$. Therefore, any protocol that satisfies receive-order-fairness for $\gamma = 1$ would order $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$ even when N actually received $\textsf {\text {tx}}_2$ first. In other words it would also need to satisfy receive-order-fairness for $\gamma = \frac{n-1}{n}$, which we showed to be impossible.

4.2 Environments that Support Receive-Order-Fairness

We find that the Condorcet paradox can be circumvented in a few ways by assuming specific network properties.

External Synchrony Assumption. The primary reason for the impossibility of fair-ordering is that different nodes may receive the same client transaction several rounds apart, resulting in non-transitive collective ordering. Suppose that $\varDelta _\mathrm {\mathsf {ext}}= (\mathrm {\mathsf {full}}, \delta )$ where $\delta \le 1$ (e.g., an instant synchronous external network). Then, any client transaction that a node receives will reach all other nodes within 1 round. This implies that if some node receives transactions $\textsf {\text {tx}}_1, \textsf {\text {tx}}_2$ and $\textsf {\text {tx}}_3$ in that order, then no node can receive $\textsf {\text {tx}}_3$ before $\textsf {\text {tx}}_1$. It is now straightforward to see how this circumvents the Condorcet paradox.

Non-corrupting Adversary and $\varvec{\gamma = 1}$. If the adversary does not corrupt any nodes, and its power is restricted to influencing network delays, we find that it is possible to achieve receive-order-fairness for $\gamma = 1$. In this setting, a single leader can receive the transaction orderings from individual nodes, and decide on a final ordering that preserves receive order-fairness.

4.3 Towards Weaker Definitions for Order-Fairness

We give two natural relaxations of the original definition. The first is approximate receive order-fairness (or simply approximate-order-fairness) while the second is block receive order-fairness (or simply block-order-fairness). For approximate-order-fairness, we only look at unfairness in the ordering of two transactions if they were received sufficiently apart in time. We emphasize that approximate-order-fairness only makes sense in synchronous and partially synchronous settings. On the other hand, for block-order-fairness, we choose to ignore the ordering within a block while considering fair ordering. Notably, this allows us to circumvent the Condorcet paradox by aggregating any transactions with non-transitive orderings into the same block. This is reasonable to consider even in asynchronous environments. First, we look at approximate-order-fairness. For a given ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, we define the property below.

Definition 10 (Approximate-Order-Fairness)

A ${\textsf {view}}$ satisfies $(\gamma , T_\mathrm {warmup}, \xi )$ approximate-order-fairness if the following holds: For any two transactions m and $m'$, let $\eta$ be the number of nodes that received both transactions between times $T_\mathrm {warmup}$ and $\left| {\textsf {view}}\right|$. If at least $\gamma \eta$ of those nodes received m more than $\xi$ rounds before $m'$ from $\mathcal {Z}$, then for all honest nodes i, i does not deliver $m'$, unless it has previously delivered m.

A protocol $\mathrm {\Pi }$ satisfies $(\gamma , T_\mathrm {warmup}, \xi )$ approximate-order-fairness w.r.t $(\mathcal {A}, \mathcal {Z})$ if there is a negligible function ${\textsf {negl}}(\cdot )$ such that for any $\kappa \in \mathbb {N}$, the above property is satisfied except with probability ${\textsf {negl}}(\kappa )$ over .

Quickly, we notice a protocol that satisfies $(T_\mathrm {warmup}, T_\mathrm {confirm})$-liveness, also satisfies $(1, T_\mathrm {warmup}, \xi )$ approximate order-fairness for any $\xi \ge T_\mathrm {confirm}$. Clearly, if a transaction $\textsf {\text {tx}}_2$ was received after $\textsf {\text {tx}}_1$ was delivered by all nodes, then $\textsf {\text {tx}}_2$ will be delivered after $\textsf {\text {tx}}_1$. Moreover, we also find that if $\xi < T_\mathrm {confirm}$, then any protocol that satisfies $(\gamma , T_\mathrm {warmup}, \xi )$ approximate-order-fairness must also satisfy $(\gamma , T_\mathrm {warmup})$ receive-order-fairness (for environments with a different network synchrony bound).

Theorem 3

Consider any ${n, f \ge 1, \varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}}}$. Let ${\varDelta _\mathrm {\mathsf {int}}= (\textsf {not}\text {-}\textsf {async}, \delta _\mathrm {\mathsf {int}})}$ and ${\varDelta _\mathrm {\mathsf {ext}}= (\textsf {not}\text {-}\textsf {async}, \delta _\mathrm {\mathsf {ext}}\ge 1)}$. Also consider $\gamma \le 1$ and $\xi < T_\mathrm {confirm}$. If a protocol $\mathrm {\Pi }$ achieves consistency, $(T_\mathrm {warmup}, T_\mathrm {confirm})$-liveness, and $(\gamma , T_\mathrm {warmup}, \xi )$ approximate-order-fairness. w.r.t. all $(\mathcal {A}, \mathcal {Z})$ that respect $(n,f,\varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}})$-classical execution, then it also satisfies $(\gamma , T_\mathrm {warmup})$ receive-order-fairness w.r.t all $(\mathcal {A}', \mathcal {Z}')$ that respect $(n,f,\varDelta '_\mathrm {\mathsf {int}}, \varDelta '_\mathrm {\mathsf {ext}})$-classical execution where $\varDelta '_\mathrm {\mathsf {int}}= (\textsf {not}\text {-}\textsf {async}, \delta '_\mathrm {\mathsf {int}}= \frac{\delta _\mathrm {\mathsf {int}}}{\xi + 1})$ and $\varDelta '_\mathrm {\mathsf {ext}}= (\textsf {not}\text {-}\textsf {async}, \delta '_\mathrm {\mathsf {ext}}= \frac{\delta _\mathrm {\mathsf {ext}}}{\xi + 1})$.

Consequently, approximate-order-fairness doesn’t turn out to be very useful since it suffers from the same problems as the previously defined receive-order-fairness. Note that from Sect. 4.2, we can infer that approximate-order-fairness can be achieved when $\delta _\mathrm {\mathsf {ext}}\le \xi$. Still, since it only applies to non-asynchronous networks, we propose a second definition, block-order-fairness, that performs much better since it provides a way to handle any cycles in transaction ordering and also applies to asynchronous networks. We note that our synchronous protocol (Sect. 6) also satisfies approximate-order-fairness for $\xi \ge \delta _\mathrm {\mathsf {ext}}$.

For a given ${\textsf {view}}$ in the support of ${\textsf {EXEC}}^\mathrm {\Pi }(\mathcal {A}, \mathcal {Z}, \kappa )$, we state the block-order-fairness property below.

Definition 11 (Block Order-Fairness)

A ${\textsf {view}}$ satisfies $(\gamma > \frac{1}{2}, T_\mathrm {warmup})$-block-order-fairness if the following holds: For any two transactions m and $m'$, let $\eta$ be the number of nodes that received both transactions between times $T_\mathrm {warmup}$ and $\left| {\textsf {view}}\right|$. If at least $\gamma \eta$ of those nodes received m before $m'$ from $\mathcal {Z}$, then for all honest nodes i, i does not deliver m at a later index than it delivers $m'$.

A protocol $\mathrm {\Pi }$ satisfies $(\gamma , T_\mathrm {warmup})$-block-order-fairness w.r.t $(\mathcal {A}, \mathcal {Z})$ if there is a negligible function ${\textsf {negl}}(\cdot )$ such that for any $\kappa \in \mathbb {N}$, the above property is satisfied except with probability ${\textsf {negl}}(\kappa )$ over .

5 Overview of the ${{\textsf {Aequitas}}}$ Protocols

We provide a general overview of our ${\textsf {Aequitas}}$ protocols in this section. Specifically, we give four constructions:

• $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ is a leaderless protocol that provides consistency, (weak) liveness, and block-order-fairness in the completely synchronous setting.

• $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, lead}}$ is a leader-based protocol that provides consistency, (weak) liveness, and block-order-fairness in the completely synchronous setting.

• $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {async, nolead}}$ is a leaderless protocol that provides consistency, eventual (weak) liveness, and block-order-fairness in any setting.

• $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {async, lead}}$ is a leader-based protocol that provides consistency, eventual (weak) liveness, and block-order-fairness in any setting.

We present a detailed account only for the synchronous leaderless protocol $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ in this paper (Sect. 6) and defer the other constructions to the full version  [27].

Construction Overview. Our ${\textsf {Aequitas}}$ protocols utilize the FIFO-broadcast $(\textsf {FIFO}\text {-}\mathsf{BC})$ and the set Byzantine agreement $(\textsf {Set}\text {-}\mathsf{BA})$ primitives described in Sect. 3 in a black-box way to provide order-fairness. We elaborate on the three major stages of our ${\textsf {Aequitas}}$ protocols below:

• Stage I: Gossip/Broadcast. Each node FIFO-broadcasts transactions as they are received as input from the environment. When a node i receives a set of transactions $\mathsf {txs}$ from $\mathcal {Z}$, it sends $\mathsf {txs}$ as input to the protocol ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},i)]$ with i as the designated sender. Note that all broadcasts can be sent in the same session $\mathsf {sid}$. Different session ids need to be used only when considering composition of several protocols in the system.

  In parallel to broadcasting transactions, a node also receives and processes broadcasts from other nodes. For a node i, broadcasts sent by node j are appended to a local log $\mathsf {Log}_i^j$ when they get delivered to i by ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},j)]$. Intuitively, $\mathsf {Log}_i^j$ denotes node i’s view of how transactions were received by node j.

• Stage II: Agreement on local logs. To determine the ordering for a particular transaction $\textsf {\text {tx}}$, a node i waits until it has received $\textsf {\text {tx}}$ from sufficiently many other nodes. In other words, node i waits until there are sufficiently many k such that its local log $\mathsf {Log}_i^{k}$ contains $\textsf {\text {tx}}$. When both the external and internal networks are synchronous, this can alternatively be achieved by waiting for enough time. The properties of $\textsf {FIFO}\text {-}\mathsf{BC}$ guarantee that if two honest nodes i and j have local logs $\mathsf {Log}^k_i$ and $\mathsf {Log}^k_j$ respectively that both contain $\textsf {\text {tx}}$, then $\mathsf {Log}^k_i \approx _\textsf {\text {tx}}\mathsf {Log}^k_j$. We state this fact as Lemma 2. Recall that $\mathsf {Log}^k_i \approx _\textsf {\text {tx}}\mathsf {Log}^k_j$ holds when $\mathsf {Log}^k_i$ and $\mathsf {Log}^k_j$ are identical until $\textsf {\text {tx}}$ occurs.

  Now, the next step is for all nodes to agree on which local logs to use to determine the ordering for $\textsf {\text {tx}}$. For a node i, let $U_i^{\textsf {\text {tx}}}$ denote the set of nodes k such that $\mathsf {Log}_i^k$ contains $\textsf {\text {tx}}$. Node i starts an instance of the protocol ${\mathrm {\Pi }_{\text {sba}}}[(\mathsf {sid}, \textsf {\text {tx}})]$ and provides it the input $U_i^\textsf {\text {tx}}$. Upon the completion of the $\textsf {Set}\text {-}\mathsf{BA}$ protocol, all honest nodes receive the same set $L^\textsf {\text {tx}}$. Intuitively, $\textsf {Set}\text {-}\mathsf{BA}$ is used to agree which nodes’ orderings should be used to determine the final ordering for transaction $\textsf {\text {tx}}$. Recall that Lemma 1 guarantees that if $k \in L^\textsf {\text {tx}}$, then there is some honest node j such that $\textsf {\text {tx}}\in \mathsf {Log}_j^k$. This, along with the liveness property for $\textsf {FIFO}\text {-}\mathsf{BC}$ ensures that all honest nodes will eventually receive $\textsf {\text {tx}}$ broadcast by node $k \in L^\textsf {\text {tx}}$ (even if k is malicious).

  Finally, we note that at the end of the agreement phase, every honest node has agreed on a set of nodes $L^\textsf {\text {tx}}$ whose transaction orderings should be used to determine the final ordering for the transaction $\textsf {\text {tx}}$ in consideration. We say that a node i has received the agreed logs for $\textsf {\text {tx}}$ if for all $k \in L^\textsf {\text {tx}}$, it holds that $\textsf {\text {tx}}\in \mathsf {Log}_i^k$.

• Stage III: Finalization. To decide on the final ordering for a transaction $\textsf {\text {tx}}$, we provide two options for the finalization step: a leader based one and a leaderless one. For both the leader-based and leaderless finalizations, nodes first build a graph that represents any ordering dependencies between transactions. Specifically, a node i maintains a directed graph $G_i$, where vertices represent transactions and edges represent ordering dependencies. We refer to $G_i$ as the “dependency graph” or the “waiting graph” maintained by i. After the agreement stage for $\textsf {\text {tx}}$ is completed, the protocol now uses the local logs to see if some other transaction might have come before. If there is another transaction $\textsf {\text {tx}}'$ that appears before $\textsf {\text {tx}}$ in sufficiently many local logs (e.g., $n-f$ times), then i adds an edge from $\textsf {\text {tx}}'$ to $\textsf {\text {tx}}$ in $G_i$. Intuitively, an edge $(a,b) \in G_i$ denotes that the finalization stage for b is “waiting” for a to be delivered. Since the same $L^\textsf {\text {tx}}$ is used by all honest nodes, if an edge (a, b) exists in $G_i$, then it will at some point exist in $G_j$, when nodes i and j are both honest. However, we note that $G_i$ is neither guaranteed to be complete nor acyclic. Two vertices in $G_i$ might never have an edge between them. Moreover, the Condorcet paradox can still create cycles in $G_i$. To break ties between transactions without an edge, we use the following two techniques.

• Finalization via leader-based proposal. $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, lead}}$ and $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {async, lead}}$ both use a leader-based approach to finalize transactions in the graph. For this, any leader-based consensus protocol can be run along with the gossip and agreement stages above. When a designated leader proposes and broadcasts a new block, instead of just checking the syntactical validity of transactions, each node i checks that the proposal does not conflict with any required order-fairness in the graph $G_i$. That is, node i checks that for any transaction $\textsf {\text {tx}}$ in the proposed block, if $(\textsf {\text {tx}}', \textsf {\text {tx}})$ is in $G_i$, then either $\textsf {\text {tx}}'$ has already been delivered or $\textsf {\text {tx}}'$ is also in the current proposed block.

  Abstractly, we allow the leader node to choose the transaction ordering but only as long as order-fairness is still satisfied. For transactions among which there is no clear winner, the leader may choose any ordering.

• Finalization via local computation. $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ and $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {async, nolead}}$ both use a leaderless approach to finalize transactions in the graph and require no further communication. At a high level, to order transactions $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$ between whom there in no edge in $G_i$, the protocol will wait until $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$ have a common descendant, with the final ordering being based on which transaction vertex has the most descendants. We prove that any other graph vertex that is a descendant of only one of $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$ is present in $G_i$ when node i makes the decision for ordering $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$. This will ensure that all honest nodes will order $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$ the same way.

We highlight that the above description of the finalization stage is a simplified one. As described, it is not sufficient to avoid the Condorcet paradox. Furthermore, adversarial transactions could result in a node waiting for unbounded periods of time. The actual technique to get around these obstacles is quite nuanced and we dedicate Sect. 5.1 to its details.

Lemma 2

If two honest nodes i and j have local logs $\mathsf {Log}^k_i$ and $\mathsf {Log}^k_j$ respectively where k is any other node such that both logs contain a transaction $\textsf {\text {tx}}$, then $\mathsf {Log}^k_i \approx _\textsf {\text {tx}}\mathsf {Log}^k_j$.

Proof

This result follows directly from the agreement property of $\textsf {FIFO}\text {-}\mathsf{BC}$.

Before diving into the details of the finalization step, we take a step back to understand why it turns out to be quite non-trivial. We look at a simple strawman protocol based on transaction timestamping that looks intuitive and analyze why it does not work.

The Problem with Timestamp-Based Ordering. Consider a simple synchronous protocol $\mathrm {\Pi }_\text {timestamp}$ that works as follows:

• 1. When an honest node i receives a transaction $\textsf {\text {tx}}$ from $\mathcal {Z}$ in round t, it assigns $\textsf {\text {tx}}$ the timestamp t and broadcasts $(\textsf {\text {tx}},t)$ to all other nodes.

• 2. Upon waiting for $\delta _\mathrm {\mathsf {ext}}+ T_\mathrm {confirm}$ rounds where $\delta _\mathrm {\mathsf {ext}}$ is the network delay bound for the external network and $T_\mathrm {confirm}$ is the liveness polynomial for the broadcast primitive, nodes reach agreement on the set of timestamps $\mathsf {T}$ to use to calculate the final timestamp for $\textsf {\text {tx}}$.

• 3. Each node calculates the final timestamp for $\textsf {\text {tx}}$ as the median of all the timestamps in $\mathsf {T}$. We represent this final timestamp by $\textsf {final}(\textsf {\text {tx}})$.

Notice how the first two steps almost perfectly resemble the gossip and agreement stages. The finalization (third) step is also surprisingly simple, but unfortunately can lead to easy manipulation of final timestamps by a single adversary. To see why, consider 5 nodes, A, B, C, D and E, where E is malicious and two transactions, $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$. $\textsf {\text {tx}}_1$ is received by nodes $A,\dots , E$ at rounds 1, 1, 4, 4, 2 while $\textsf {\text {tx}}_2$ is received by the nodes at rounds 2, 2, 5, 5, 3. Now, all nodes have received $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$ and consequently, $\textsf {final}(\textsf {\text {tx}}_1) < \textsf {final}(\textsf {\text {tx}}_2)$ should hold. However, notice how E can invert the ordering of the final timestamps simply by switching around its own timestamps for $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$. E can make $\textsf {final}(\textsf {\text {tx}}_1) = 3$ and $\textsf {final}(\textsf {\text {tx}}_2) = 2$ which results in a timestamp of 3 for $\textsf {\text {tx}}_1$ (median of (1, 1, 3, 4, 4)) and 2 for $\textsf {\text {tx}}_2$ (median of (2, 2, 2, 5, 5)), and thus an unfair ordering.

5.1 The Finalization Stage

We describe the general theme of the finalization stage here.

Ordering Two Transactions. For a pair of transactions $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$, how does a node i choose which one to deliver first? Suppose that the agreement phases for $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$ result in the outputs $L^\textsf {\text {tx}}$ and $L^{\textsf {\text {tx}}'}$. Define $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ as below.

$$ l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')} = \left| \left\{ k \in L^\textsf {\text {tx}}\cup L^{\textsf {\text {tx}}'} \;|\; \mathsf {Log}_i^k(\textsf {\text {tx}}) \le \mathsf {Log}_i^k(\textsf {\text {tx}}') \right\} \right| $$

$l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ denotes the number of logs $\mathsf {Log}_i^k$ where $\textsf {\text {tx}}$ was ordered at or before $\textsf {\text {tx}}'$. Now, if $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ is “small,” it means that a large number of nodes have received $\textsf {\text {tx}}'$ before $\textsf {\text {tx}}$. This means that the finalization stage for $\textsf {\text {tx}}$ should wait until $\textsf {\text {tx}}'$ has been delivered. This provides a partial ordering between any two transactions.

Additional Notation. Let $\textsf {\text {tx}}\lhd _i \textsf {\text {tx}}'$ represent that i is waiting to deliver $\textsf {\text {tx}}'$ before proceeding with the finalization phase for $\textsf {\text {tx}}$. Lemma 3 shows that $l_{(\textsf {\text {tx}},\textsf {\text {tx}}')}$ and $l_{(\textsf {\text {tx}}',\textsf {\text {tx}})}$ cannot both be “small”. Consequently, both $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$ will not wait for each other or equivalently, at most one of $\textsf {\text {tx}}\lhd _i \textsf {\text {tx}}'$ and $\textsf {\text {tx}}' \lhd _i \textsf {\text {tx}}$ will be true.

Lemma 3

$l_{(\textsf {\text {tx}},\textsf {\text {tx}}')} + l_{(\textsf {\text {tx}}',\textsf {\text {tx}})} \ge \left| L^\textsf {\text {tx}}\cup L^{\textsf {\text {tx}}'} \right|$

Proof

Let $X = L^{\textsf {\text {tx}}} \cup L^{\textsf {\text {tx}}'}$. For any $k \in X$, at least one of $\mathsf {Log}_i^k(\textsf {\text {tx}}) \le \mathsf {Log}_i^k(\textsf {\text {tx}}')$ and $\mathsf {Log}_i^k(\textsf {\text {tx}}') \le \mathsf {Log}_i^k(\textsf {\text {tx}})$ is true. k is therefore counted in either $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ or $l_{(\textsf {\text {tx}}', \textsf {\text {tx}})}$ which proves the required result.

Adversarial Transactions. The calculation of $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ needs to wait for the agreement phases of both $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$ to finish. Now, if an adversarial node FIFO-broadcasts a transaction $\textsf {\text {tx}}_\text {fake}$ claiming it to be a real user transaction, then the ordering between $\textsf {\text {tx}}_\text {fake}$ and a real transaction $\textsf {\text {tx}}$ cannot be calculated since the agreement phase for $\textsf {\text {tx}}_\text {fake}$ will never finish. So that this does not happen, the protocol needs to ensure that at least one honest node has received $\textsf {\text {tx}}_\text {fake}$ before $\textsf {\text {tx}}$ (from $\mathcal {Z}$). For the synchronous protocol, this is done by checking that a transaction $\textsf {\text {tx}}'$ is added to the graph only when there is another transaction $\textsf {\text {tx}}$ that has finished its agreement stage and $\textsf {\text {tx}}'$ is present in at least $\left| L^{\textsf {\text {tx}}}\right| \,-\, (n\,-\,f)\, +\, 1$ among the local logs in $L^\textsf {\text {tx}}$. Note that the agreement stage will only finish for honest transactions.

Non-transitive Waiting. The Condorcet paradox can still cause non-transitive waiting. It is still possible to have transactions $\textsf {\text {tx}}_1, \textsf {\text {tx}}_2,$ and $\textsf {\text {tx}}_3$ such that $\textsf {\text {tx}}_1 \lhd \textsf {\text {tx}}_2$; $\textsf {\text {tx}}_2 \lhd \textsf {\text {tx}}_3$; and $\textsf {\text {tx}}_3 \lhd \textsf {\text {tx}}_1$. The way we get around this is by delivering such transactions at the same time—by placing them in the same block.

Graph Based Approach. Instead of a separate thread waiting for the resolution of each transaction, representing the “waiting” between transactions as a graph provides a nice way to modularize the protocol. Suppose that each node i maintains a directed graph $G_i = (G_i.V, G_i.E)$ where $G_i.V$ denotes the set of vertices and $G_i.E$ denotes the set of edges in $G_i$. Each vertex represents a transaction and an edge from y to x (equiv. $(y,x) \in G_i.E$) represents that x is waiting on y i.e. $x \lhd _i y$. When the agreement phase for a transaction $\textsf {\text {tx}}$ completes, i does the following:

• Add $\textsf {\text {tx}}$ to the graph $G_i$ if it does not already exist.

• For all transactions $\textsf {\text {tx}}'$ such $\textsf {\text {tx}}\lhd _i \textsf {\text {tx}}'$, first, if $\textsf {\text {tx}}'$ does not exist in the graph, add a new vertex. Then, add the edge $(\textsf {\text {tx}}',\textsf {\text {tx}})$ to $G_i$.

As mentioned before, $G_i$ may not be acyclic. In order to deal with the Condorcet paradox, we consider the strongly connected components of $G_i$. Recall that a subgraph $G'$ of a directed graph G is called strongly connected if every vertex in $G'$ can reach every other vertex in $G'$. A strongly connected component is a maximal strongly connected subgraph.

Intuitively, all transactions in a strongly connected component will be delivered in the same block. A cycle that exists in $G_i$ (due to non-transitivity of transactions) will be entirely contained in the same strongly connected component. On the other hand, if a transaction does not need to wait on any other one, then it will be in a strongly connected component by itself. We can collapse $G_i$ into a new graph $G^*_i$ where each strongly connected component is represented as a single vertex. $G^*_i$ is also called the condensation of $G_i$. Each vertex in $G^*_i$ will now denote a set of transactions. We note that $G^*_i$ will now be acyclic.

Graph Notation. Since a vertex in $G_i$ contains a single transaction, we may use a transaction and its corresponding vertex interchangeably when referring to the vertex in $G_i$. Let $\mathsf {TXS}_i(v)$ be the set of transactions for a vertex $v \in G^*_i.V$. Let $\mathsf {SCC}_i(v)$ denote the strongly connected component of $G_i$ that contains the vertex v. $\mathsf {SCC}_i(v)$ also denotes the corresponding vertex in the condensation graph $G^*_i$.

Ordering Incomparable Vertices in $\varvec{G^*_i}$ and Breaking Ties. As mentioned before, not all pairs of vertices in $G^*_i$ are connected by an edge. This only gives a partial ordering for delivering transactions. We still need a way to totally order vertices in $G^*_i$. In the leader-based version of the finalization step, we delegate this responsibility to the leader node. We elaborate on the technique used in the synchronous leaderless protocol in Sect. 6.

Delivering a Transaction. Recall that a transaction enters the finalization stage when it has completed the agreement stage, while it is delivered when it gets output to $\mathcal {Z}$ as part of the ${\textsf {LOG}}$. For the leaderless protocols, the set of transactions $\mathsf {TXS}_i(v)$ corresponding to the vertex $v \in G^*_i.V$ can be delivered in the ${\textsf {LOG}}$ output to $\mathcal {Z}$ when it is not waiting for any other transaction and is preferred over any other transaction that it is incomparable with in the graph. For this, care must be taken to ensure that the set of transactions that $\textsf {\text {tx}}$ is incomparable with is the same when all honest nodes are deciding to deliver $\textsf {\text {tx}}$, which we defer to the actual protocol description in Sect. 6.

6 The Synchronous ${{\textsf {Aequitas}}}$ Protocol

We describe $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$, the leaderless ${\textsf {Aequitas}}$ protocol for the completely synchronous setting. By “complete synchrony,” we mean that both the external and internal networks are synchronous. For this section, we assume that $(\mathcal {A}, \mathcal {Z})$ respects $\varDelta _\mathrm {\mathsf {ext}}= (\mathrm {\mathsf {full}}, \delta _\mathrm {\mathsf {ext}})$ $\mathrm {\mathsf {ext}}$-synchrony and $\varDelta _\mathrm {\mathsf {int}}= (\mathrm {\mathsf {full}}, \delta _\mathrm {\mathsf {int}})$ $\mathrm {\mathsf {int}}$-synchrony.

To build the $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ protocol, we assume a secure $\textsf {FIFO}\text {-}\mathsf{BC}$ protocol ${\mathrm {\Pi }_{\text {fifocast}}}$ (from Definition 8) and a secure $\textsf {Set}\text {-}\mathsf{BA}$ protocol ${\mathrm {\Pi }_{\text {sba}}}$ (from Definition 7) that both work for any $(\mathcal {A}, \mathcal {Z})$ that respects $(n,f, \varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}})$-classical execution. Let $(T^\mathrm {fifocast}_\mathrm {warmup}, T^\mathrm {fifocast}_\mathrm {confirm})$ and $T^\textsf {Set}\text {-}\mathsf{BA}_\mathrm {confirm}$ denote the liveness parameters for ${\mathrm {\Pi }_{\text {fifocast}}}$ and ${\mathrm {\Pi }_{\text {sba}}}$ respectively. We note that any bound for the number of corruptions f will be at least as restrictive as bounds required by ${\mathrm {\Pi }_{\text {fifocast}}}$ and ${\mathrm {\Pi }_{\text {sba}}}$.

6.1 Protocol Description

The $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ protocol follows much of the same general techniques from Sect. 5. The gossip and agreement stage take place exactly as described there. In the gossip stage, a node i forks an instance of ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid}, i)]$ and uses it to broadcast transactions as they are received from $\mathcal {Z}$. After broadcasting a transaction $\textsf {\text {tx}}$, it waits until the broadcasts from all honest nodes would have arrived. Let $U_i^\textsf {\text {tx}}$ denote the set of nodes k such that $\textsf {\text {tx}}\in \mathsf {Log}^k_i$. Note that all honest nodes are present in $U_i^\textsf {\text {tx}}$. In the agreement stage, i forks an instance of ${\mathrm {\Pi }_{\text {sba}}}[(\mathsf {sid}, \textsf {\text {tx}})]$ to agree on a set $L^\textsf {\text {tx}}$ indicating the nodes whose logs to use to order $\textsf {\text {tx}}$.

For the finalization stage, we now present the remaining details that were deferred from Sect. 5.1. Please refer to Sect. 5 for any notation.

Building the “Waiting” Graph $\varvec{G_i}$. Recall that each node i builds a graph $G_i$ where vertices are transactions and edges denote ordering dependencies between transactions. For two transactions $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$, an edge $(\textsf {\text {tx}}', \textsf {\text {tx}})$ is added to $G_i$ if $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')} \le \left| L^\textsf {\text {tx}}\cup L^{\textsf {\text {tx}}'}\right| - \gamma n + f$. Each node i also maintains the condensation graph $G^*_i$ where each strongly connected component in $G_i$ is condensed to a single vertex.

Ordering Incomparable Vertices in $\varvec{G^*_i}$. Suppose that v and $v'$ are two vertices in $G^*_i$ that are currently not comparable i.e. they do not have an edge between them. To determine which vertex to deliver first, we wait until they have a common descendant, after which we order based on number of descendants. We note that once a common descendant arrives, any other transaction that arrives will also be a descendant of both v and $v'$. In other words, the vertex with the higher number of descendants will become fixed allowing for a consistent ordering across protocol nodes. Lemma 4 shows a helpful result on when vertices can be “incomparable.”

A subtle point to note here is that the common descendant itself can cause v and $v'$ to be combined into the same strongly connected component if it creates a cycle containing them. This is precisely why our protocol achieves weak-liveness, where we achieve liveness, if a transaction arrives late enough that it cannot create a cycle with transactions in v and $v'$. Effectively, we need to wait for a transaction to arrive sufficiently late in order to “flush out” earlier transactions.

Lemma 4

Let $v_1$ and $v_2$ be two vertices in $G^*_i$ that do not have an edge between them. Let $r_\textsf {first}$ denote the time when any transaction in $\mathsf {TXS}_i(v_1)$ was first received by a node. Let $r_\textsf {last}$ denote the time when any transaction in $\mathsf {TXS}_i(v_2)$ was last received by a node. Then $r_\textsf {last} - r_\textsf {first} \le 2 \delta _\mathrm {\mathsf {ext}}$.

Breaking Ties. We use an a priori known ordering relation to break any ties that arise (e.g., two vertices with equal number of descendants). In particular, suppose that $\textsf {Ord}$ is a binary relation on $2^\mathcal {T}\times 2^\mathcal {T}$ that is known a priori to all nodes. $2^\mathcal {T}$ represents the power set of $\mathcal {T}$. The relation is defined on sets of transactions (rather than individual transactions only) since we may deliver several transactions at once. We assume that $\textsf {Ord}$ is supplied to all nodes on initialization by $\mathcal {Z}$. We will use this function to deterministically break ties between two sets of transactions when neither should clearly come before the other. For two sets $S_1$ and $S_2$, $(S_1, S_2) \in \textsf {Ord}$ implies that all nodes agree $S_1$ should come before $S_2$ if there is no clear winner. $\textsf {Ord}$ can also be used to order transactions in the same block. We note that $\textsf {Ord}$ can be defined using a simple alphabetical or ascending order. In general, $\textsf {Ord}$ needs to satisfy two properties:

• $\forall (a,b) \in 2^\mathcal {T}\times 2^\mathcal {T}; a \ne b$, exactly one of (a, b) and (b, a) is in $\textsf {Ord}$.

• $\forall a,b,c \in 2^\mathcal {T}$, if $(a,b) \in \textsf {Ord}$ and $(b,c) \in \textsf {Ord}$ then $(a,c) \in \textsf {Ord}$.

Delivering Transactions. The transactions $\mathsf {TXS}_i(v)$ of a vertex v in $G^*_i$ can be delivered when:

• v is a source vertex i.e., it has no incoming edge. This ensures that v is not waiting on any other transaction to be delivered first.

• $2 \delta _\mathrm {\mathsf {ext}}$ rounds have passed since v was added to the graph. This ensures that any other vertex $v'$ that v is incomparable to, is also present in the graph.

• For any other source vertex $v'$, v has a common descendant with $v'$ and either has more descendants or has an equal number of descendants and $(\mathsf {TXS}_i(v), \mathsf {TXS}_i(v')) \in \textsf {Ord}$ holds. This ensures that every node will order v before $v'$.

Bound on f. Suppose that $(\gamma , \cdot )$ order-fairness needs to be realized. This implies that if $\gamma n$ nodes receive transactions in a particular order, it must be reflected in the final ordering. Since f nodes can be adversarial, the output must be the same even if $\gamma n - f$ of those orderings are seen. Now, as we don’t want a bi-directed edge to be added to $G_i$, $\gamma n - f > \frac{n}{2}$ must hold. Equivalently, $n > \frac{2f}{2\gamma - 1}$. For block-order-fairness with $\gamma = 1$, we require an honest majority.

6.2 Protocol Pseudocode

Initialization. At the start of the protocol, we assume that i receives the identities of other protocol nodes, n, f, the maximum network delays $\delta _\mathrm {\mathsf {int}}$, $\delta _\mathrm {\mathsf {ext}}$, and the binary relation $\textsf {Ord}$. A $\textsf {FIFO}\text {-}\mathsf{BC}$ protocol ${\mathrm {\Pi }_{\text {fifocast}}}$ and a $\textsf {Set}\text {-}\mathsf{BA}$ protocol ${\mathrm {\Pi }_{\text {sba}}}$ have also been agreed upon a priori. Let $T_\mathrm {confirm}^\mathrm {fifocast}$ and $T_\mathrm {confirm}^\text {sba}$ represent the liveness bounds for ${\mathrm {\Pi }_{\text {fifocast}}}$ and ${\mathrm {\Pi }_{\text {sba}}}$ respectively. Now, for each $j \in \mathcal {N}$, i initializes . It also initializes an empty graph $G_i$ and a final output log ${\textsf {LOG}}_i$.

$\bullet$ At the start of round r, when a node i receives a set of transactions $\mathsf {txs}$ from $\mathcal {Z}$, it does the following:

• 1. (Gossip)

  • (a) Fork an instance of ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},i)]$, if it does not already exist.

  • (b) Send $\mathsf {txs}$ as input to ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},i)]$.

  • (c) Record $(\mathsf {sid}, \textsf {gossip}\text {-}\mathsf{end}, \mathsf {txs}, r + \delta _\mathrm {\mathsf {ext}}+ T^\mathrm {fifocast}_\mathrm {confirm})$

• 2. (Agreement)

  • (a) Check if there is any recorded tuple $(\mathsf {sid}, \textsf {gossip}\text {-}\mathsf{end}, \mathsf {txs}',r')$ such that $r = r'$.

  • (b) For such a tuple for $\mathsf {txs}'$, for each $\textsf {\text {tx}}\in \mathsf {txs}'$, fork an instance of ${\mathrm {\Pi }_{\text {sba}}}[(\mathsf {sid},\textsf {\text {tx}})]$ and provide it the input $U_i^\textsf {\text {tx}}$.

  • (c) Record $(\mathsf {sid}, \textsf {agreement}\text {-}\mathrm {end}, \textsf {\text {tx}}, r + T^\text {sba}_\mathrm {confirm})$ for each $\textsf {\text {tx}}\in \mathsf {txs}'$.

• 3. (Build Graph)

  • (a) Check if there is any recorded tuple $(\mathsf {sid}, \textsf {agreement}\text {-}\mathrm {end}, \textsf {\text {tx}},r')$ such that $r = r'$.

  • (b) For such a tuple for $\textsf {\text {tx}}$, first add a vertex denoted by $\textsf {\text {tx}}$ to $G_i$ if it does not already exist. Now, for any other transaction $\textsf {\text {tx}}'$ seen so far that has not yet been delivered,

    • i. Let $u = \left| \left\{ k \in L^\textsf {\text {tx}}\;|\; \textsf {\text {tx}}' \in \mathsf {Log}_i^k \right\} \right|$.

    • ii. If $u \ge \left| L^\textsf {\text {tx}}\right| - (n-f) + 1$, compute $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')}$ as per Sect. 5.1.

    • iii. If $l_{(\textsf {\text {tx}}, \textsf {\text {tx}}')} \le \left| L^\textsf {\text {tx}}\cup L^{\textsf {\text {tx}}'}\right| - \gamma n + f$, then record $\textsf {\text {tx}}\lhd \textsf {\text {tx}}'$. Add an edge $(\textsf {\text {tx}}', \textsf {\text {tx}})$ to $G_i$ if it does not already exist.

  • (c) Record $(\mathsf {sid}, \textsf {graph}\text {-}\mathsf{end}, \textsf {\text {tx}}, r + 2\delta _\mathrm {\mathsf {ext}})$ for $\textsf {\text {tx}}$.

• 4. (Finalization)

  • (a) Compute the condensation graph $G^*_i$ of $G_i$ by collapsing each strongly connected component into a single vertex.

  • (b) Let $V_\textsf {source}$ be the set of vertices in $G^*_i$ where $v \in V_\textsf {source}$ if it satisfies:

    • All transactions in $\mathsf {TXS}(v)$ have been received.

    • v is a source vertex in $G^*_i$. That is, v has no incoming edges.

  • (c) Let $V_\textsf {finalize} \subseteq V_\textsf {source}$ be the set of vertices v that also satisfy:

    • For all $\textsf {\text {tx}}^* \in \mathsf {TXS}(v)$, there is any previously recorded tuple $(\mathsf {sid}, \textsf {graph}\text {-}\mathsf{end}, \textsf {\text {tx}}^*,r')$ with $r \ge r'$

  • (d) For $v \in V_\textsf {source}$, let $\textsf {Desc}(v)$ denote the descendants of v in $G^*_i$. Let $\textsf {nDesc}(v) = \left| \textsf {Desc}(v) \right|$ i.e. the number of descendants.

  • (e) For $v \in V_\textsf {finalize}$ and $v' \in V_\textsf {source}$, let $\textsf {common}\text {-}\mathsf{desc}_{(v,v')}$ be a boolean that denotes whether v and $v'$ have a common descendant. That is, we define $\textsf {common}\text {-}\mathsf{desc}_{(v,v')} := ( \textsf {Desc}(v) \cap \textsf {Desc}(v') \ne \emptyset )$

  • (f) If there is a $v \in V_\textsf {finalize}$ such that for all other $v' \in V_\textsf {source}$,

    • $\textsf {common}\text {-}\mathsf{desc}_{(v,v')} = \mathsf {true}$

    • Either $\textsf {nDesc}(v) > \textsf {nDesc}(v')$ holds or $(\textsf {nDesc}(v) = \textsf {nDesc}(v')) \wedge (\mathsf {TXS}(v), \mathsf {TXS}(v')) \in \textsf {Ord}$.

    then, deliver transactions in v by appending $\mathsf {TXS}(v)$ to ${\textsf {LOG}}_i$. Remove v from $G^*_i$ and the corresponding vertices form $G_i$.

  • (g) Repeat steps 4b to 4f until there is no such v in step 4f.

  • (h) Output the current ${\textsf {LOG}}_i$ to $\mathcal {Z}$.

$\bullet$ When i receives $\mathsf {txs}$ from ${\mathrm {\Pi }_{\text {fifocast}}}[(\mathsf {sid},j)]$, it appends $\mathsf {txs}$ to $\mathsf {Log}_i^j$ and adds j to the set $U_i^\textsf {\text {tx}}$.

$\bullet$ When i receives the output from ${\mathrm {\Pi }_{\text {sba}}}[(\mathsf {sid},\textsf {\text {tx}})]$, it stores it as $L^{\textsf {\text {tx}}}$.

Transaction Lifecycle. Suppose that a transaction $\textsf {\text {tx}}$ is input to node i in round $r_0$. Since the external network is synchronous, by round $r_0 + \delta _\mathrm {\mathsf {ext}}$, all nodes will have been input $\textsf {\text {tx}}$ by $\mathcal {Z}$. Consequently, by round $r_1 = r_0 + \delta _\mathrm {\mathsf {ext}}+ T^\mathrm {fifocast}_\mathrm {confirm}$, node i will have received the gossip broadcasts from all other honest nodes. By round $r_2 = r_1 + T^\text {sba}_\mathrm {confirm}$, node i will receive the output of the agreement stage for $\textsf {\text {tx}}$, and $\textsf {\text {tx}}$ can be added to the graph $G_i$. Now by round $r_3 = r_2 + 2 \delta _\mathrm {\mathsf {ext}}$, any other transaction that $\textsf {\text {tx}}$ could be incomparable with will also get added to $G_i$. Waiting for this time ensures that $\textsf {\text {tx}}$ does not get delivered before ensuring that all relevant transactions have been placed in the graph.

6.3 Consistency, Liveness, and Order-Fairness Results

We present the consistency, liveness, and order-fairness results for $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ in Theorem 4. We provide brief proof sketches, and defer the formal proofs to the full version  [27]. As a corollary, we also note that $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ also satisfies receive-order-fairness, and (conventional) liveness when the external network has $\delta _\mathrm {\mathsf {ext}}= 1$, since non-transitive Condorcet cycles can no longer arise.

Theorem 4

(Consistency, Liveness, and Order-Fairness of $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$). Consider any $n,f,\gamma > \frac{1}{2}, \varDelta _\mathrm {\mathsf {ext}}= (\mathrm {\mathsf {full}}, \delta _\mathrm {\mathsf {ext}}), \varDelta _\mathrm {\mathsf {int}}= (\mathrm {\mathsf {full}}, \delta _\mathrm {\mathsf {int}})$ with $n > \frac{2f}{2\gamma -1}$. Let ${\mathrm {\Pi }_{\text {fifocast}}}$ be a secure $\textsf {FIFO}\text {-}\mathsf{BC}$ protocol and ${\mathrm {\Pi }_{\text {sba}}}$ be a secure $\textsf {Set}\text {-}\mathsf{BA}$ protocol. Further, suppose that ${\mathrm {\Pi }_{\text {fifocast}}}$ satisfies $(T^\mathrm {fifocast}_\mathrm {warmup}, T^\mathrm {fifocast}_\mathrm {confirm})$ liveness, and ${\mathrm {\Pi }_{\text {sba}}}$ satisfies $T^\text {sba}_\mathrm {confirm}$ liveness. Then $\mathrm {\Pi }_\mathsf {Aequitas}^\mathrm {\mathsf {sync, nolead}}$ satisfies consistency, $(T^\mathrm {fifocast}_\mathrm {warmup}, T^*_\mathrm {confirm})$ weak-liveness where $T^*_\mathrm {confirm}= 2\delta _\mathrm {\mathsf {ext}}+ T^\mathrm {fifocast}_\mathrm {confirm}+ T^\text {sba}_\mathrm {confirm}$, and $(\gamma , T^\mathrm {fifocast}_\mathrm {warmup})$ block-order-fairness w.r.t. any $(\mathcal {A}, \mathcal {Z})$ that respects $(n,f,\varDelta _\mathrm {\mathsf {int}}, \varDelta _\mathrm {\mathsf {ext}})$-classical execution.

Consistency Proof Sketch. To show consistency, we need to prove that two honest nodes i and j remove transactions from their graphs $G^*_i$ and $G^*_j$ in the same order. For this, we first present a helpful lemma (Lemma 5).

Lemma 5

Suppose that when an honest node i delivers $\textsf {\text {tx}}$, $v = \mathsf {SCC}_i(\textsf {\text {tx}})$ is the vertex that contains $\textsf {\text {tx}}$ in $G^*_i$. Now, if another honest node j delivers $\textsf {\text {tx}}$ and $v' = \mathsf {SCC}_j(\textsf {\text {tx}})$ at that point, then $\mathsf {TXS}_i(v) = \mathsf {TXS}_j(v')$, or equivalently $\mathsf {SCC}_i(\textsf {\text {tx}}) = \mathsf {SCC}_j(\textsf {\text {tx}})$ when $\textsf {\text {tx}}$ is output by each of the nodes. This means that we can drop the node subscripts.

Now, suppose that node i delivers a transaction $\textsf {\text {tx}}_1$ before another one $\textsf {\text {tx}}_2$. Let $v_1 = \mathsf {SCC}_i(\textsf {\text {tx}}_1)$ and $v_2 = \mathsf {SCC}_i(\textsf {\text {tx}}_2)$ be vertices in $G^*_i$ when $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$ were delivered. Note that by Lemma 5, we can also use $v_1$ and $v_2$ to denote the vertices when j delivers $\textsf {\text {tx}}_1$ and $\textsf {\text {tx}}_2$. Now, either $\textsf {\text {tx}}_1$ was delivered even before $\textsf {\text {tx}}_2$ was added to $G_i$, or there is an edge from $v_1$ to $v_2$ in $G^*_i$ (which caused $\textsf {\text {tx}}_1$ to be output before) or $v_1$ and $v_2$ are incomparable.

• If $\textsf {\text {tx}}_1$ was delivered before $\textsf {\text {tx}}_2$ was added to $G_i$, then at least $\gamma n-f$ nodes received $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$. Therefore, even if $\textsf {\text {tx}}_2$ gets added to $G_j$ before $\textsf {\text {tx}}_1$, there will be an edge from $\textsf {\text {tx}}_1$ to $\textsf {\text {tx}}_2$ in $G_j$. By Lemma 5, $\textsf {\text {tx}}_1$ cannot be in the same $\mathsf {SCC}$ as $\textsf {\text {tx}}_2$ either, which implies that j cannot deliver $\textsf {\text {tx}}_2$ first.

• If $(v_1, v_2)$ is an edge in $G^*_i$, then it will also be in $G^*_j$ when j delivers $\mathsf {TXS}(v_2)$. This means that j cannot deliver $\mathsf {TXS}(v_2)$ before it delivers $\mathsf {TXS}(v_1)$.

• If there is no edge between $v_1$ and $v_2$ in $G^*_i$, then node i delivers $\mathsf {TXS}(v_1)$ before because $v_1$ had more descendants (or because of the deterministic tie-breaker). Since j waits for $2 \delta _\mathrm {\mathsf {ext}}$ time, both $v_1$ and $v_2$ are present in its graph $G^*_j$ when j outputs $\mathsf {TXS}(v_2)$, causing j to wait for a common descendant of $v_1$ and $v_2$ to be added. By this time, any other vertex that is not a common descendant will also be in $G^*_j$, and the difference in the number of descendants of $v_1$ and $v_2$ will remain constant henceforth. This means that j will take the same decision as i to deliver $\mathsf {TXS}(v_1)$ before $\mathsf {TXS}(v_2)$.

Weak-Liveness Proof Sketch. To show weak-liveness for a transaction $\textsf {\text {tx}}$, first, in Lemma 6, we prove that if a transaction is input sufficiently after $\textsf {\text {tx}}$, it cannot be coalesced into the same strongly connected component as $\textsf {\text {tx}}$.

Lemma 6

Consider a transaction $\textsf {\text {tx}}$ and build the set $\mathsf {T}$ as per the weak-liveness definition. Now, let $\textsf {\text {tx}}'$ be a transaction that is input to all nodes after all transactions in $\mathsf {T}$. Then $\mathsf {SCC}_i(\textsf {\text {tx}}) \ne \mathsf {SCC}_i(\textsf {\text {tx}}')$ for any honest i.

Now, suppose that $\textsf {\text {tx}}$ was first input by $\mathcal {Z}$ in round $r > T^\mathrm {fifocast}_\mathrm {warmup}$. Consider the set $\mathsf {T}$ built form $\textsf {\text {tx}}$ as in the weak-liveness definition. Suppose now that a transaction $\textsf {\text {tx}}_\mathsf {flush}$ is input to all nodes after all transactions in $\mathsf {T}$. Let $r_\mathsf {flush}$ be the round that $\textsf {\text {tx}}_\mathsf {flush}$ is first input to some node. Then, $\textsf {\text {tx}}_\mathsf {flush}$ is received by all nodes by round $r_\mathsf {flush} + \delta _\mathrm {\mathsf {ext}}$ and therefore added to all honest graphs $G_i$ by round $r_\mathsf {flush} + 2\delta _\mathrm {\mathsf {ext}}+ T^\mathrm {fifocast}_\mathrm {confirm}+ T^\text {sba}_\mathrm {confirm}$. From Lemma 6, $v = \mathsf {SCC}_i(\textsf {\text {tx}}) \ne \mathsf {SCC}_i(\textsf {\text {tx}}_\mathsf {flush})$ for any honest i. Now, any transaction $\textsf {\text {tx}}'$ that $\textsf {\text {tx}}$ is incomparable was input to at least one honest node no later than $\textsf {\text {tx}}$, i.e. $\textsf {\text {tx}}_\mathsf {flush}$ was received after $\textsf {\text {tx}}'$ by all honest nodes. Consequently, $\textsf {\text {tx}}_\mathsf {flush}$ will be a descendant of both $\textsf {\text {tx}}$ and $\textsf {\text {tx}}'$. This means that node i can deliver $\mathsf {TXS}_i(\textsf {\text {tx}})$ when $\textsf {\text {tx}}_\mathsf {flush}$ gets added to its graph, which happens by round $r_\mathsf {flush} + T^*_\mathrm {confirm}$.

Order-Fairness Proof Sketch. First, we note that if $\gamma n$ nodes receive $\textsf {\text {tx}}_1$ before $\textsf {\text {tx}}_2$, then at least $\gamma n - f$ honest ones do. This means that there will be an edge from $\textsf {\text {tx}}_1$ to $\textsf {\text {tx}}_2$ in all honest $G_i$. Consequently, either $\textsf {\text {tx}}_1$ will be delivered before $\textsf {\text {tx}}_2$ by all nodes, or it will end up in the same strongly connected component as $\textsf {\text {tx}}_2$ and be delivered at the same time.