 Our next speaker is Chang-Pong from the University of Sydney, who will be discussing the Dumbo Protocol family, making asynchronous consensus practical. Thanks for the introduction and I'm Chang-Pong Sydney. And we are going to talk about our recent, actually sequence of progress on asynchronous consensus. We call it the Dumbo family. And this joint work with a bunch of colleagues and particularly my former student Yuan and the current student Zhen-Liang. So since this is consensus day, I think I don't need to explain the definition of consensus. And we are focusing today basically on the continuous in the conventional setting, the best ending for tolerance setting and the conditional continuous version and one variant to call the automatic broadcast. As usual, we require the conventional safety and the likeness. Well, as we all know that most of the consensus protocols rely on some kind of timing assumption, right? Depending on if they required underlying network to deliver message within some time D, then they are considered as synchronous or partially synchronous protocol. They might be okay in the conventional at data center setting, but now we are talking about deploying consensus on the open internet. Well, the internet that knows might be across the globe, right? And in general, it might be too optimistic to assume the open internet to be synchronous. And what's worse is that actually it's shown in the literature that if we do denial service attack on a small number of nodes, many synchronous protocols will simply get stuck. And essentially it means they're gonna lose like the critical liveness property. So this call for a more robust protocol, asynchronous protocol that does not rely on any timing assumption. Unfortunately, most of the deployed consensus are not asynchronous. Well, I think it's not that they don't want to deploy asynchronous consensus simply because it's complicated. Well, the famous FLB impossibility already hinted a little, right? Like no deterministic asynchronous protocol can ever exist. So over the years people spend a lot of efforts design all kind of randomized protocol trying to circumvent the impossibility. But those classical protocols are mostly with a very high complexity and very, very, very few of them has ever been implemented until very recently because we are now talking about deploying consensus in the open internet. People to start to seriously wonder can asynchronous consensus ever be practical? And probably one of the most visible result is a Honeybeger BFT LA optimizer classical protocol and the show implementation. Well, we give a more affirmative answer to this question and but we do need some efforts. So the evolving of the Dumble protocol starts from a Honeybeger actually, but one of the critical then one of the source of inspiration actually come from a very similar result from Kashin Adol back to like 20 years ago. They formulated a nice, very nice notion called the multivalidated BASANIA agreement called MVBA. So in our, in last this year's the protocol we call Dumble classic we kind of remove the major obstacle or major bottleneck in Honeybeger that we can preserve there like optimal linear per transaction communication but at the same time, we don't need to run a lot of randomized protocols. Basically, we just need to get the best of both of Kashin Adol and Honeybeger. And at similar time, we also improve the critical component of MVBA itself. Then we move more ahead to try to bring down other complexity as well. So in the recent work of speeding Dumble we also bring the message complexity to optimal. Now we essentially have all the complexity asymptotically optimal. So we also strive to compress the concrete number of runs which turns out to be actually a highly non-trivial task. We kind of bring down the number of runs from a few dozen to like one dozen. And we are still not happy enough and we continued exploration in another recent work we call Dumble NG. We try to make the protocol structure kind of seamless in the sense that we want to eliminate all the idle moment like waiting or without any progressing. So in this way, we can harvest essentially all the available bandwidth. And the last but not least with all those better components at hand we actually designed a general framework to leverage those are better components. We are trying to bridge the gap between the asynchronous consensus and the deterministic counterpart. So obviously I cannot explain all those results unless I want to explain nothing. And so I will just spend one slice to illustrate like the math design methodology inspiration from the earlier Dumble protocols and then explain a little bit of the general framework. In order to construct the asynchronous atomic broadcast or consensus there's a common intermediate abstraction called the asynchronous common subset. Essentially it's like everyone gonna output a subset of values. There are different parts of constructing. One of the well-known results past actually is proposed by Kaxi et al using MVB and everyone gonna have a vector of inputs. Of course, you might also be used MVB directly to construct atomic broadcast but now essentially like have one output one transaction per block. Then doing this obviously you're gonna lose the benefit as in Honeybeader you cannot do the batch and you cannot get the linear amortized communication. Well, actually there's even more ancient ideas like using a bunch of binary agreement here. ABA means a binary agreement. And interestingly Honeybeader BFT actually explicitly chose this path because they consider MVB might incur potential communication blow-up when the batch size is large. And interestingly actually now Dumble classical we show if we do the reduction to MVB more carefully even if the MVB protocol might have slightly higher communication but the resulting atomic broadcast actually will be strictly better than Honeybeader. And also we also open the box app over MVB and at least in theory we show the communication blow-up might not be necessary. So the real takeaway for these two earlier Dumble protocols is that actually the elegant notion formulated by Casciado this MVB might be still be the right notion right way to construct practical asynchronous consensus. And actually the experimental evaluation clearly justifies the advantage of Dumble over Honeybeader. So then what's next? We get a protocol much better than Honeybeader, are we done then? Well, unfortunately not. If we look at the just the basic latency alone. So here the Dumble is indeed much better than Honeybeader. But if we compare to the deterministic counterpart for example, Hostoff, then the situation become dramatically different. So basically we are facing essentially a live-ness latency dilemma, right? Like deterministic protocols are usually very fast because just a few rounds, but they don't have live-ness because of the FLP. Well, randomized protocols are robust but still quite slow. So that's basically the situation we are facing now. So in the next few minutes I'm trying to answer and the following question. Can we design asynchronous protocol that could be as fast as the state of art deterministic protocol? This brings out to another nice notion of optimistic asynchronous consensus. Well, the basic idea is very intuitive. First of all, I mean in the usual case we run the fast deterministic protocol as a fast lane, when things happen then we run an asynchronous fallback. And again, this notion actually was proposed many years back and the Christian again played a vital role in this line of work. But unfortunately the asynchronous fallback might not be as simple as it looks. So at least you need to finish two basic phases. The first, when everybody wants to fall back, right? They need to decide where to fall back. For example, I might be at block 10 while Christian already at block 100. We need to determine which block we're gonna agree on. So this single procedure alone already hints us this paste synchronization phase might already need a multi-valued asynchronous consensus which might incur exponential communication. And the next phase is we need to make a real progress running some asynchronous protocol. And fortunately the two elegant work before leveraged again that the critical component of MVBA successfully realized this functionality. But let's catch, still MVBAs are quite complicated. It despite the asymptotic improvement but the concrete efficiency is still bad. So if we just run MVBA directly as the paste synchronization so over because it's much slower than the fast lane. So the overall protocol is still much slower even if the network might be stable for quite some time. So that's the base. Then basically we need much lighter paste synchronization or of course we also need the better pessimistic paths and maybe we even want to minimize the best pessimistic paths. So for this reason, we propose a new practical framework we call both Dumbo transformer is very long name. And so the key observation is that we actually provide the new abstraction of the fast lane or we call both, which is a handicapped version which is not even a full fledged consensus protocol. It only requires something called notarizability which basically like every block contains a certificate or something it's very easy to get. But interestingly, this is gonna prepare us to use the cheapest possible paste synchronization which we call transformer. But if you think about it for 10 seconds what could be the conceptually minimal asynchronous agreement? And since this is a generic framework actually the illustration gonna be very simple it's highly modular, but a few notes I would like to give. So since both is not a is a handicapped version of atomic broadcast, right? It can be really achieved very easily by basically sequentially running multicast or of course with some proofs. While interestingly this simple notarizability already prepared us in the way that everyone's progress will not be too far away. So in this way, we really can use the simplest possible probably many of you already got answered like 10 seconds ago the simplest possible asynchronous agreement protocol which is binary agreement. And since it is a generic framework, right? So there are a bunch of benefits. So of course, first we can use the best instantiation for every component. So for example, immediately you're gonna inherit the nice property or linear communication per transaction. And of course, even though our pessimistic path is called Dumbo, we don't have to use Dumbo, right? We might even use a better version like Dumbo-NG or speeding Dumbo. And since this protocol is highly modular actually we can also easily do something like we try to minimize the use of pessimistic pass. Basically we only use pessimistic pass until we have to use it. What does that mean? Whenever we see any progress in paste synchronization we're gonna directly skip the pessimistic pass and switch to the fast lane direct. And interestingly, actually there's a concurrent worker Ditto, I think Lefteros were gonna be presenting like in one minute or two. So they have a, they break the box actually they have a concrete construction so we can share different type of trade-offs. We did extensive experiments and first thing to note is our machine is not so fancy. It's a very normal machine as a poor academics we cannot afford like a very fancy machine for experiments, but still the experimental result kind of very as show mostly shows as what we expected. And even in the best case we always intentionally run the transformer once in a while try to simulate the network of fluctuation. So here as we clearly see the green lines are Dumbo's and the yellow ones are the BDD and both are more transformer and the actual another benchmark is our host stuff. So clearly the latency is close to host stuff. And we also done some very interesting experiment which kind of mimics a very, very bad scenario. Basically we intentionally mute one-third of the machine but what's more is that we also intentionally trigger paste synchronization for every single crash. So I mean, in reality, once you meet a good leader you might not need to switch again but we just try to see the best case and the very best situation. And still we can see clearly that the capacity line kind of demonstrate in the middle between Dumbo and the host stuff. And here actually the real performance host stuff should be somewhere here because in the experiment we only did the stable leader. That's when we do the leader rotation with one-third of crash, the obviously the latency can be higher. And we also did the basic latency and overhead and probably I'm going to skip. And we also have the throughput by varying the batch size for the throughput. And also we also have different instantiations for the fast lane showing different kind of interesting performance. And there are many more experimental in New York analysis in the paper if you are interested you can check there. So let me quickly wrap up and we walked a long way for asynchronous consensus from the jungle. And now the situation now is really much, much better than before. And I believe we are really in the close to the actual deployment. And the one reflection is that it seems like similarly simple broadcast and the grid structure actually have a lot of redundancy. We can simplify it in many, many, in several even surprising different ways. And of course there are many remaining questions, right? Like since we are now really in the edge what would be the best trade-off among the like various different metrics like communication and runs. And theoretically I believe the low bounds are not tight yet. And of course can we have asynchronous protocol that scale to thousands or even more not. That's it. Thank you.