 Hello everyone, I'm excited to be at Virtual Crypto 2020. I'm Mohimna and I'm a PhD student at Cornell University and Cornell Tech. Today I will be presenting our paper, Order Fairness for Byzantine Consensus. This is joint work with other authors at Cornell Tech, Fan Zhang, Stephen Goldfeder and Ari Jules. So let's begin. First, I thought it would be a good idea to briefly recall the state machine replication problem and some of its properties. So the problem setup is as follows. The system consists of a set of servers or nodes and some of these may be Byzantine. There's clients or users in the system that send transactions to these nodes. And the goal for the nodes is to agree on a consistent ordering of these user transactions. So consistent in the sense that all of the honest nodes should output the same ordering. This linearly ordered log of transactions is what we call a blockchain. So just a side note in this top, I'll use the term state machine replication and Byzantine consensus interchangeably. And I'll also frequently use terms more common in the blockchain literature, like transactions or linearly ordered log. But note that all of what I say is analogously true for the original formulation using state transitions and system states. Okay, so there's two properties that consensus protocols need to satisfy. Consistency and liveness. So the first requirement, consistency, ensures that all of the honest nodes have the same view of the linearly ordered log. And the second requirement, liveness, ensures that the system makes progress. So basically any fresh transactions that are input by clients are incorporated into this log soon. But unfortunately, neither consistency nor liveness says anything about the actual ordering of transactions in this log. So for example, the consistency requirement can be satisfied, even if there's a single adversarial node that completely chooses the ordering of all the transactions. And as it turns out, this transaction ordering is often easy to manipulate in existing protocols. So almost all classical protocols are what we call leader-based, which means that a single leader node is responsible for proposing the ordering of the transactions. So take protocols like PBFT, for instance, which have a single leader node for the entire protocol, except when the leader tries to equivocate by proposing two different transactions or it becomes unresponsive. There's more recent protocols like hot stuff, which will randomly select leaders for each round. And then the leader for that round is responsible for the ordering proposal for that round. But even then the current round leader can sort of propose any ordering at once. And when the leader's adversarial, it can manipulate the transaction ordering arbitrarily. This type of reordering isn't really handled by existing protocols. So all of this talk on order manipulation raises the central question that drove our paper. So why exactly is fair ordering so important? Consensus as a primitive has been studied for several decades now and the field is reasonably mature. So recent protocols mostly try to improve scalability or reduce communication complexity or opt for simpler designs or fewer assumptions. But in this paper, we look back at the standard consensus properties to see whether they fit real world requirements for blockchains in particular. So in the next few minutes, my goal is to motivate fair ordering and tell you why it's so important for blockchains. And our paper has more examples of these, but I'll discuss the primary motivations here. So the biggest motivator for order fairness is decentralized exchanges. And I claim that results could be catastrophic here without fair ordering. So for context, Michael Lewis had this best seller book in 2014 called Flash Boys, which brought to light the high frequency trading practices in the early days of Wall Street. So this is when investment firms spent millions of dollars building low latency channels to the New York Stock Exchange and NASDAQ so that they could receive information and act on it in the matter of microseconds. So they capitalize on this information asymmetry in order to make small profits on a really large volume of transactions. And over the years, high frequency trading has been subject to a lot of regulation and it's no longer the wild beast it once was, but in some sense, high frequency trading is exactly what we're seeing on decentralized exchanges today. So this recent paper by Phil Diane and others at S&P 2020 showed the rampant rise of bots on the Ethereum network waiting to make profits from unsuspecting users by manipulating the transaction ordering. So these bots would wait for favorable opportunities and then front run users by inserting their own transactions and trying to get them sequenced earlier. So this allowed them to execute arbitrage, which is when you buy a security and then quickly turn around and sell it to a user at a higher price. So in unlike in real world exchanges, there's not so much regulation in these blockchain exchanges. So it's important to use cryptography to provably prevent these types of attacks. So there's a lot of practical motivation actually for order fairness and I'm really only scratching the surface. I highly encourage you to read this Diane at all paper if you're interested in these types of reordering attacks. But we think that there's a strong theoretical motivation as well. And for cryptographers, I think that's equally important. So order fairness as it turns out is a natural analog of the validity condition, the closely related Byzantine agreement problem. So in the BA problem, all nodes are input some value in a value set. And the goal is for them to agree on the same output value. The validity property says that if all of the honest nodes are input a value V, then all of the honest nodes should also output the value V. I haven't formally defined order fairness, but here's the gist. If all of the honest nodes are input M1 before M2, then all of the honest nodes should agree to output M1 before M2. So in a sense, order fairness is exactly the analog of validity extended to a more continuous version of the agreement problem. So just to put order fairness in the context of current techniques, I'll briefly compare to related notions, but see our paper for the full comparison to related ones. So usually there's a couple of different techniques in which ordering can be manipulated by a node. So a malicious node can censor transactions or insert its own or try to reorder transactions in general. So there's several protocols that provide the so-called censorship resistance property. So this informally means that any honest user transaction will eventually make its way into the log. So censorship resistance is a great first step, but it doesn't really prevent any form of insertion or reordering attacks. Another line of work has focused on electing the leaders randomly. So you don't give a particular leader too much power. So let's say a leader is elected at every round and then for that round, the leader is responsible for the proposal. But here adversarial leaders will also get elected every now and then. And whenever they are elected, they can manipulate the ordering at will. Probably heavy weight technique that's been explored recently is to use threshold encryption to ensure that the order of transactions is fixed before the actual contents are revealed. So this is quite nice actually. From a purely definitional standpoint, an adversary should still be able to randomly or blindly censor reorder. But you may argue that there's no real incentive for an adversary to do this in practice. So threshold encryption does prevent a lot of real world attacks, but it still has one major problem. If the adversary will notice colluding with the user, it knows which encryption corresponds to the user transaction and therefore it can try to sequence it first. So our property of order fairness is actually strictly stronger than these earlier considered notions. So it should be able to prevent all kinds of censorship and insertion and reordering attacks. All right, so hopefully by now I've convinced you that order fairness is indeed important to study and that no current protocol actually achieves this notion. So next I'll like to go into a little more detail about our model and our definitions of order fairness. So we model a permission network with N nodes in total and out of these at most F can be adversarial. We also allow clients to collude with protocol nodes. In terms of the communication, we model two different kinds of networks, an external network and an internal network. So the external network is the communication channel between the clients and the consensus nodes and the internal network is the one that's usually modeled in literature and it's the channel amongst the consensus nodes. So for the external network, we assume that the clients send their transactions to all of the nodes instead of just one liter node. We also assume that the adversary is not in charge of the message delivery here. So intuitively this makes sense because otherwise it would essentially imply that the adversary is in charge of the client's connection to the internet. The adversarial assumptions for the internal network are standardly modeled. So basically the adversary handles all of the message delivery and can reorder messages and can't drop messages. It also moves last in every round so it can see the broadcast from other nodes before deciding on its own messages. Okay, so next I'll describe what it means for protocols to be synchronous. In this talk, I'll focus mostly on our synchronous protocol but our protocols can actually be made to work for completely asynchronous models as well. So to define synchrony, we assume that the protocols take place in rounds and our nodes have consistent clocks. So the external network is said to be Delta synchronous if the following condition holds. If a transaction is input to some node in round R, then all of the honest nodes will have received it as input in round R plus Delta. So informally this is the assumption that a client's connection to one node isn't much slower than its connection to other nodes. So for the internal network, our synchrony assumption is the same as prior work. So formally the internal network is said to be Delta synchronous if when an honest node sends a message in round R, all of the intended recipients should have received it in round R plus Delta. Okay, so having set up the groundwork for our model, we can now start to think of how best to define this order fairness. So here's a natural definition which we call receive order fairness. So for an order fairness parameter gamma, which is at least half and at most one, gamma order fairness is defined as follows. So if gamma times N nodes are input M1 before M2, then all of the honest nodes should deliver M1 before M2. And this is very similar to the definition I mentioned when comparing it to BA validity, but here we now add an extra order fairness parameter. So the receive order fairness definition is probably the most natural way to define fair ordering, but it does have one major flaw. Basically carefully chosen transaction orderings can lead to a global intransitivity or a cycle in the ordering. So for this we'll draw from a surprising connection to social choice theory, particularly the Condorcet paradox. So the Condorcet paradox is the situation resulting from a global non-transitive preference, even when all of the individual preferences are transitive. In the context of order fairness, let's look at a simple example. So suppose we have three protocol nodes, Alice, Bob and Carol, and there's three transactions X, Y and Z input into the system. So Alice receives them in the order X, Y, Z, Bob in the order Y, Z, X, and Carol in the order Z, X, Y. So now two nodes have received X before Y, two nodes have received Y before Z, and two nodes have received Z before X. So any majority receive order fair protocol should order transactions this way. But now if you look closely at the constraints, you'll see that the final ordering needs to be cyclic, which results in a contradiction. We can extrapolate this impossibility result to a general N. Our informal result is that for any N, for any F greater than or equal to one, and any gamma, no protocol can achieve all of consistency, liveness and receive order fairness. If the external network synchrony bound is at least N. For gamma less than one, the impossibility result actually holds even if X equals zero. So to weaken our definition, we considered several alternative ones in our paper, but here's the one we settled on. We call this block order fairness. So we think this intuitively captures the same first and first out notion, but we can construct protocols to realize it. The key difference between this definition and the receive order fairness definition is that the protocol is now allowed to deliver M1 and M2 in the same block, so hence the aptly named block order fairness. M1 just can't be delivered in the later block. So this is a small definitional change, but it's actually quite significant because it allows us to sidestep the condorcet paradox. So this is done by placing the transactions with contradictory or non-transitive orderings into the same block. An important point here is that the transactions in a block are still totally ordered. It's just that the reordering within a block is no longer considered to be unfair. So we'll use minimal use of this relaxation. Our protocols will actually achieve the stronger receive order fairness definition except when it's actually impossible to achieve because of the condorcet paradox. Okay, before I get into describing our actual protocols, I wanna put forth a strawman protocol to build intuition on why it's non-trivial. The first thought that comes to mind is, well, why not just use a median timestamping protocol as a proxy for the ordering? So clearly, if all of the honest node receive a transaction TX1 before TX2, then the median timestamp for TX1 will be smaller. So the problem with this logic lies in the presence of even a single adversary, which can flip its own ordering by claiming to have received different ordering than it actually did. So I'll illustrate this with a simple example. So suppose there's five nodes, A, B, C, D, and E, and there's two transactions, TX1 and TX2. So TX1 is highlighted in yellow and TX2 is highlighted in green. And all of the nodes have received TX1 before TX2. So now if you calculate the median timestamps, you'll find that the median for TX1 is two and the median for TX2 is three. So everything's good so far. Now let's see what happens when E is malicious and decides to claim a different ordering than the one it actually received. So recall that since the adversary has the ability to move last, it can strategically choose its own input ordering after seeing the broadcast by other nodes. So let's say E claims to have received TX2 and round two and TX1 and round three. Now if you calculate the median timestamp, you'll notice that the median for TX1 is three, which is larger than the median for TX2. So this means that a median timestamp protocol would order TX2 before TX1, even though all honest nodes received the transactions in the opposite order. So this clearly wouldn't work. Okay, so let me now talk a little bit about our actual fair ordering protocols. So we describe our protocol Iquitas, which is named after the Roman personification for fairness. So broadly the Iquitas protocol will take place in three stages, the gossip stage, the agreement stage and the finalization stage. And the transactions that are input into the system will go through each of these three stages before finally being delivered as part of the blockchain. In the next several slides, I'll go through the key ideas for each one of these three stages. So the first stage that a transaction goes through is the gossip stage. So in this stage, honest nodes broadcast transactions to all of the other nodes in the order that they were received. So and at the same time, nodes process the broadcasts received from others and store them in local logs. So local log subscript I superscript J contains node I's view of how the transactions were received by node J. So at the end of the stage, we wanna guarantee that these local logs are consistent. So basically two honest nodes should not have different views of the broadcast by another node. To accomplish this, we use the FIFO or first in first out broadcast primitive. In a FIFO broadcast protocol, there's a single defined sender that sends a series of messages to all of the other nodes. So FIFO broadcast guarantees that if the sender is honest, then its broadcast will be delivered in the same order as they were initially broadcast. Even if the sender is malicious, its broadcast will be delivered in a consistent order. So all of the nodes should deliver them in the same order as each other, but this may not be the same order as they were initially broadcast by the adversarial sender. Prior work has shown how to realize FIFO broadcast just from standard reliable broadcast. In our protocol, nodes will instantiate this FIFO broadcast primitive in order to broadcast their transactions. So there will be N different instances of the FIFO broadcast, one for each node. So the gossip stage will end when enough time has passed for all of the honest nodes to broadcast this transaction TX. The second stage of our Iquitas protocol is the agreement stage. So after the gossip stage for some particular transaction TX has ended, all of the honest nodes will have a set of local logs that contain TX. But these nodes may have received different, like local logs from different nodes by the time the gossip stage ends. And in the agreement stage, the goal is to agree on exactly which local logs to use to order TX. The main guarantee that we want is that all of the honest nodes should use the same local logs to finalize the ordering. Since the logs are already consistent from the gossip stage, this means that all of the nodes will use the same data to compute the final ordering. So this agreement stage can be easily extrapolated from standard Byzantine agreement. The third and last stage is the not so cleverly named finalization stage where you might have guessed it, nodes will finalize the ordering for a given transaction TX. So our finalization stage is leaderless and involves no further communication between the consensus nodes. All of the computation can be performed locally. The main sub-problem for the finalization stage that we need to solve is to decide on the ordering for a given pair of transactions, TX and TX prime. So for this, a node will look at if one transaction occurs before the other in a large number of these local logs. So for example, if many local logs contain TX prime before TX, then ideally TX prime should be delivered first. This means that before proceeding with the finalization stage for TX, we should wait until TX prime has been delivered in the final log. So in this case, we say that TX is waiting for TX prime. And these sort of relations between transactions can be viewed as a directed graph, which we call the dependency or the waiting graph. So in this graph, vertices will represent transactions and an edge from A to B will represent that B is waiting for A to be delivered. Okay, so what if there's no clear winner? So what if there's not one of these transactions that occurs before the other large number of times? So this will correspond to there not being an edge in the graph between these two transactions. So essentially, there's two main problems that we need to solve. The first problem is that the graph may not be complete or even connected. So this means that some transactions may not be comparable as of now. So to retrieve a total ordering from this graph, we need some way to compare these transactions. The other problem is that the graph may still have cycles, courtesy of the condorsate paradox. So to solve the first problem, the key idea is to wait for a common descendant before ordering transactions that don't have an edge. So now the ordering can be based on the maximum number of descendants for each of the transactions. And in case there's a tie, we can use a predetermined tiebreaker function. So the intuitive explanation for why this works is that once a common descendant arrives, any other transaction that arrives later will also be a common descendant. So this means that the difference between the descendants will stay the same henceforth. So this is crucial to maintain consistency. So whenever a node decides to order two transactions, the difference between the number of descendants will be the same as when another node decides to order the same number, the same pair of transactions. So this will ensure that all of the nodes take the same ordering decision. The second problem is that the dependency graph may still have cycles. So to get a total ordering, we'll compute the condensation graph by collapsing the strongly connected components. So the condensation graph is now guaranteed to be acyclic and vertices in a cycle will be included in the same strongly connected component. So now we can use the trick I mentioned earlier by delivering these cycles together. So this is done by delivering the transactions in the same strongly connected component as part of the same block. So that's pretty much the gist of our protocol. There's a few more considerations that need to be dealt with carefully, but I won't go into detail of them here. In terms of adversarial corruption threshold, our synchronous protocol requires n greater than 2f over 2 gamma minus one. So in the easiest case of gamma equals one, we still require an honest majority. The asynchronous protocol will require n greater than 4f over 2 gamma minus one. I'll also briefly mention some caveats. Our protocol only achieves a weaker form of liveness, which informally will require that new transactions are input sufficiently late in order to deliver current transactions. But this should be reasonable in practice. We also achieve conventional liveness when the external network has a small synchrony value. Another point to note is that the adversary can always unfairly order if it controls the whole interim. For example, if it controls the client's access to all of the consensus nodes. And in our modeling, we sidestep this by assuming that the adversary does not control the external network. A very cool byproduct of our protocol is that it serves as a fair ordering compiler. So our protocols use FIFO broadcast and agreement primitives, which are sort of weak primitives in the sense that they can be realized from any consensus protocol. So this results in a sort of interesting observation. Our Iquitas technique provides a general compiler that can take any standard consensus protocol and transform it in a black box way into one that also provides order fairness. Just to give some final concluding thoughts, our work is the first to formalize this order fairness notion and provide protocols to realize it. And we think order fairness is an important property for many decentralized blockchain applications. I mentioned decentralized exchanges earlier, which is a $2.4 billion market in 2019. Another important use case is that of ICOs or initial coin offerings, which could benefit from first in first out ordering for fair investing. This is a $12 billion market. In general, we think that decentralized finance or DeFi applications should also benefit from this notion of the ordering. So this concludes my presentation. I've put my Cornell email address as well as a link to the paper on this slide if you wanna take a look. Thank you and I hope you have a great virtual crypto 2020 experience.