 Our final speaker for this session is Mahima Kautar from Cornell Tech who will be discussing fast strong order fairness in business team consensus. Okay, cool. Today I'll be talking about our new protocol FEMIS, which is a fast strong order fair protocol for business team consensus. And this is joint work with Shaw Big Deb, C.Chan Long, R.E. Jules, and Triram Dunn. So just as a quick summary of the consensus abstraction and the permission setting, there's a set of servers or notes that receive transactions from clients and the goal is to order these transactions in a consistent manner, even in the case of some F number of malicious servers. So usually there's two properties that are expected from consensus protocols. The first is consistency or safety and the second is liveness. So consistency will ensure that honest parties agree to the same sort of view of the final log and liveness means that new transactions from users are incorporated into this log eventually. But neither consistency or liveness provides any guarantees on the actual ordering of transactions. So this is particularly discomforting seeing usually it's very easy to manipulate this ordering. For example, in like all common permission protocols like PBFT and hot stuff, we're their leader base. So any leader node can propose any ordering that wants. So an adversarial leader can arbitrarily manipulate ordering. And there's sort of no way to check the fairness of the leader proposal. I'll also emphasize that leader less protocols are not inherently fair since there's still no way to check the fairness of the ordering. And a way to visualize this is that the just the unpredictability of the output is usually not enough because it could still be unfair. So a very recent line of work kind of laid this foundation for the research direction on consensus protocols with some notion of fair transaction ordering. And this consists of some of my prior work with co-authors as well as concurrent work by saying it all and the high level motivation for why fair transaction ordering is important is that transaction ordering is very critically important for decentralized finance or DeFi since adversarial ordering can cause unnecessary losses for the user. The long line of work has shown the prevalence and impact of adversaries manipulating the transaction ordering, which can cause losses for ordinary users, systemic bribery incentives, and sometimes even fundamental protocol instability. And this kind of necessitates research into protocols with strong ordering properties that are resistant to such manipulation. And recent work has attempted to tackle this fair ordering problem at a more fundamental consensus level in a way that's application agnostic, as well as able to handle a broad class of transaction order manipulation that's not just restricted to front running or censorship or arbitrage. The problem is this though that existing fair ordering protocols are not ideal. For example, our Iquitas protocol from our previous work at crypto 2020 satisfies a very strong fairness property that requires at least cubic communication in the number of nodes. So other works proposed the Wendy protocol and the Pompei protocol from the earlier works that are described require only quadratic communication, but still, but satisfy only a somewhat weaker fairness property. Plus quadratic is usually still worse than current state-of-the-art protocols like hot stuff without fair ordering. So this work sort of proposes a new protocol Themis, which satisfies the same strong fairness property of Iquitas, but only needs linear communication in the optimistic case. And this is equivalent to widely used protocols like hot stuff, which don't have any fairness guarantees. So just to provide a brief summary, to understand our protocol Themis better, I'll begin with some sort of a short background on Iquitas. So the Iquitas paper started with a property called receive order fairness. So informally, we have a large fraction of the protocol nodes are input some message M1 before M2, then all of the honest notes should deliver M1 before M2. And here the large fraction is parameterized by an order fairness parameter gamma. So unfortunately, it turns out that although receive order fairness is quite intuitive, it's only achievable in a few specific settings and not the general case. And this is linked to a well-known result in social choice theory called the Condorcet paradox, which shows how global orderings can be non-transitive, even when the individual orderings are transitive. So let's take a simple example, we have like three nodes, Alice, Bob and Carol, who receive transactions in a specified manner. So now if you look closely, we have two nodes, Alice and Carol, that have received X before Y. We have two nodes that have received Y before Z, and two nodes that have received Z before X. But this forms a cycle, which means that no protocol will be able to satisfy receive order fairness in such a setting. And we'll call these cycles Condorcet cycles. So now the Icotox protocol provides a general result where receive order fairness is impossible, but for more general settings, it provides like a minimal relaxation of the definition, which they call batch order fairness. So the only difference here is that the transaction M1 will now be allowed to be delivered at the same time or in the same batch as M2. Essentially, this allows us to evade the Condorcet paradox by delivering transactions in the same cycle at the same time. The paper also shows how batch ordering is sort of a minimal relaxation in the sense that if there's no paradoxical orderings because of this Condorcet paradox, the Icotox protocol satisfies the stronger receive order fairness notion. So very briefly, the Icotox protocol takes place in three stages. In the first two gossip and agreement, nodes gossip their local orderings received from clients and agree on whose preferences to use for the final ordering. So the finalization step is the third step in their protocol is this non-interactive step where all the nodes can locally compute the fair ordering. So the finalization step at a very high level builds a transaction ordering graph where vertices will represent transactions and edges will represent ordering preferences. So an edge from X to Y denotes that a large fraction of nodes are received X before Y. So you kind of end up with a graph like this with transactions and edges between transactions. And in this graph, cycles can arise because of the Condorcet paradox. So what the Icotox finalization does to retrieve the final ordering is it computes the condensation graph by collapsing the strongly connected components and then it can deliver these transactions at a topological order. But first, you need to wait for these strongly connected components to stabilize or in other words, the set of transactions that are in one SEC will no longer change after this time, which allows you to deliver them together. So the asynchronous Icotox protocol requires n greater than 4f over 2 gamma minus 1. So in the case of gamma equals 1, it requires n greater than 4f. There's a couple of drawbacks with the Icotox protocol though. One of the main concerns was that it has a high communication complexity, which is at least cubic even in the best case. And in fact, it could be even higher if it's built using a generic black box reduction that the paper provides for converting any consensus protocol into a fair one. Another sort of potentially more problematic thing is that the Icotox protocol only satisfies a weaker form of liveness. So it turns out that this strongly connected component stabilization can take arbitrarily long due to the fact that converse cycles can chain together. So finding when the current cycle ends actually takes arbitrarily long. And now basically liveness can only be achieved when the current cycle ends. And this usually depends only on the specific input ordering and not the adversary. But this is still problematic. So now our work Themis will kind of fix at a high level the main concerns with Icotox. I'll briefly introduce the Themis design next. So as a very basic structure, Themis is a very minimal modification to any existing partially synchronous leader based protocol. And it has the same communication complexity of the underlying protocol. We'll only need to change the protocol in three things. First, we provide an algorithm for the leader to generate a partial fair ordering. Second, we provide a technique for the replicas to check this fair ordering. And third, we provide a way to retrieve the final fair ordering from the agreed upon blocks. So as a first step, each replica sends their local transaction ordering only to the leader. So here are some servers sending the transaction list L1, another one is sending L3 and so on. So note that existing fair ordering protocols require gossiping the transaction orderings to everyone else as their first step. And this kind of results in this n-square communication complexity at least. Themis only requires the replicas to send the orderings to the current leader. So that's why we're able to achieve optimistic linear complexity. So now the leader uses n minus f of these to compute a fair proposal using an algorithm I'll describe in a bit. So here, let's say one of the malicious nodes ordering was included and one of the honest nodes ordering was excluded. And we can still guarantee fairness even if all of the malicious nodes ordering are included. So now the leader computes this fair ordering using this fair proposal algorithm and also computes a proof that it did this computation correctly using generic purpose smarts. And now it provides these as a part of the block proposal. The replicas can now check the fairness by verifying the proof. And sort of everything else can be taken from the underlying protocol like sort of the actual consensus mechanisms of rotating the leaders or view changes or ensuring consistency by preventing any sort of equivocation. So the only thing that Themis adds to the complexity is a single communication step to the existing protocol for replicas to submit their orderings to the leader. So the overall communication complexity in the number of nodes n is the same as the underlying protocol. So naively done, this actually still doesn't get rid of the weak liveness problem since if the converse cycles chain together then nothing can be output from the leader proposal. So here we sort of make a nice observation. In practice, transactions in a cycle will still need to be totally ordered. And this kind of means that it should be fine to output these cycles continuously rather than together. So essentially we can output a partial cycle as long as we make sure that nothing from a later cycle can come in between. And the upshot of this observation is that the next leader can continue the same cycle without breaking liveness. A sort of note here is that finding when the cycle ends still brings us back to the weak liveness problem, but we no longer need to do this. Okay, so I'll briefly talk about the fair proposal algorithm next. So essentially the leader builds a transaction graph that's very similar to Iquitas, but now it actually proposes a partial graph whose edges can be added to by a later honest leader. And this later addition will happen when those transactions are received as input by enough nodes. And so it'll only depend on the actual network delay and not on any weak liveness concerns. And we'll sort of make sure that every fully specified proposal is a tournament graph, which means that there's one edge between every vertex pair. So now to retrieve the sequence, given like a sequence of graph proposals, you can determine the ordering by a completely local computation. So similar to Iquitas, we'll compute the condensation graph and within every strongly connected component, which will represent some sort of cyclic ordering from the conversation paradox, we'll use Hamiltonian cycles to totally order transactions. And the beauty of this is that it actually allows us to cleanly connect the ordering across different strongly connected components. And very informally, this ensures fairness even if the converse cycle has been split across multiple leaders. And I'm only describing these protocols in not very much detail and there's a lot of subtlety that I'm sweeping over the rug, but I'm happy to discuss more offline. So we implemented our famous protocol using hot stuff and compared it to hot stuff as a baseline. So for n equals five nodes in both the same data center setting and a geo-distributed setting, the latency between the two protocols is quite comparable. So within the same data center, the throughput is a couple of times lower than hot stuff, but it should still suffice in practice because we can do still over 40,000 transactions a second. And the geo-distributed setting, the throughput is almost exactly the same as hot stuff with the same parameter choices. Another contribution of our work is trying to more formally understand how different fairness notions compare to each other. So basically, we propose this suite of fairness experiments that will allow not only comparison between our protocol and existing fairness protocols, but also for any future work on fair ordering can take advantage of this suite of experiments to understand the fairness of the protocols. So we provide a couple of experiments in this suite of fairness experiments. I'll describe them very briefly here, and you can look at the paper for more details. So the first kind of experiment we do is how do these different fairness notions correspond to some ideal notion in a non-adversarial setting? So in the best case possible, when there's no adversaries, there's no network adversary, there's no node adversary, is the notion of fairness close to some ideal notion of fairness in like a simulated environment? The second thing we sort of look at is how easy is it to front-run transactions or change the ordering of transactions at a network layer? So for this, what we do is we look at a random collection of nodes and look at the ping timings between these nodes and understand how easy is it for an adversarial node to receive a transaction from a client and then quickly front-run or send its own transaction to all of the other nodes in a way that it gets ordered earlier. And we find that our fairness properties are massively better than other fairness properties that have been considered. So just as a very brief data point, we found that some other fairness definitions, you can front-run 80 to 90% of node pairs. Like a node A can front-run node B, which is a node pair, 90% of the time in like a real-world setting. Whereas for our fairness definitions, we can do such a front-running can happen less than 1% of the time. And this is without any sort of privacy notion. So adding privacy to any of these layers will additionally prevent these kind of order manipulation attacks. The third sort of experiment that we do is how easy is it for an adversary to change the ordering of the transaction as a protocol node? So by considering the ordering that it received from the clients and claiming to have received a different ordering instead, how much can it influence the final ordering that all of the nodes agree to? Here also we find that our protocols perform significantly better than other considered definitions of the path. So I'll end my talk here. I'm happy to take any questions or discuss offline about the paper. The paper will be posted in a few days and it is forthcoming. Thank you.