 We have Alberto Sanino from Facebook's Novi talking about Narwhal and Tusk, a dag-based mempool and efficient BFT consensus. So I'll let you take it from here. So my name is Alberto Sanino, and this work is about Narwhal and Tusk. So I'm trying to give you a brief overview, it's a 15 minute overview, but if you're to ask questions, since the paper is probably going a bit longer than that explained. So this is John Warp with these people, so George, Lesteris and Sasha, and the work has been done when all the authors were at Facebook Novi. So I'm skipping all the introductions about blockchains, why they're cool, why we need them, and so on and so forth. I guess by now everybody knows them. Just to say here we work on a permission setting. So that's classical Byzantine poems. So what is all about, so this talk is just about how to build really high performance blockchains. So we've been trying that for a long time, different techniques, and we believe we have one that works fairly well. So here is the beginning of the story, right. We have those consensus protocols for a long time. And either that you look at early versions of TMBFT, previously Libra, GFT, hot staff, whatever it means. We realize that they're all being monopoly protocols that share transaction data as part of the consensus protocol. Then we have a 30 years literature that tells us how to minimize the overall message complexity of the consensus protocol itself. And so these is probably one of the key problems that we have for a scalability state. So here is a traditional leader-based protocol. So we have a leader that typically makes a proposal, it makes a blog, broadcast it to all the other replicas, gather some votes into a certificate, and then we broadcast back the certificate. Something like that, potentially they don't use a leader for aggregator, but the general story is the same. And when we look at the resource authorizations of all those machines, we realize that when a node is elected leader, it's the bottleneck. It uses a lot of its storage, CPU, bandwidth, and all the resources it has, while the other replicas are brutally underutilized. Anyway, the leader rotates because it's a blockchain, and so it means that all machines need to be overprovisioned, while only one of them at every single time uses the full capacity of the machine. But not what we want. What we want is to see the graph there, where it's read everywhere. Every machine needs to be utilized at maximum capacity all the time. And so, after a lot of thinking, we realized that the mempool is actually the key in all of this, that reaching consensus on metadata, if those are small, it's actually very cheap and message complexity does not really matter a lot for consensus. Again, if the mempool already did the bulk of the work and sheets all the data around. So here it's about separating the data propagation, which is will be the role of the mempool from reaching consensus of metadata, which will be the role of the consensus protocol. So first of all, normal. So that's the mempool. I'm going after to explain you how we take that normal, the mempool and build the consensus protocol on top of it, or actually add any consensus protocol on top of it. So here is the mempool. It works like that. So nothing complicated at the beginning, we have the client's transaction, the left and the normal mempool, which runs on every single note. So the mempool is composed of a number of entities, the workers and workers and the primary one primary for mempool. So I had that question a lot so don't look too much for the trust relationship between those workers and the primary. If it's easy just assume that all the process each worker is a process on the same machine as the primary. So all a single machine, imagine them like that. And so it's a single guy a single trust authority that operates a single note. Then we can actually say well that node operator actually can own multiple machines, again under its own authority, and then you can have one worker per machine if you if you like. So these have not changed at all the trust model and the threat model of the Byzantine forum. So what happens is the client submits the transactions to the workers through some kind of low balancing each worker receives different transactions from the client. Here is where we can apply techniques from your gift your others. These are complete your program. Every worker receives its transactions and add them into batches and each worker broadcast the patch to all other workers to the worker of all other nodes. So take an example worker one gets transaction from a client makes a batch and I'll broadcast the batch to all other workers number one of all other nodes worker number two makes its own batch and sends the batch to all workers number of all other nodes. But so no worker one is not going to send any message to worker number two, for instance. So you'll see a little bit how these will enable the scalability of the system. So in addition to composing those batches, every workers hash the batch as well and sends the digest to the primary. So these are various modes like 32 bytes, the primary is the process or dedicated machines that receives from a lot of very small amount of data and what it does with that it runs the mempool protocol. So what's the mempool protocol right I'm going to explain it now just keep in mind the mempool protocol protocol is per se lightweight in the sense that it only operates on mid data. It's a block header that embeds all the all the digest that it got so far that block header, well, the very first release will lead to three to 12 plus one Genesis blocks. It broadcast the header to all primary machines of all other nodes and gather some votes. And it's very easy is just that you votes for a header. If it's the first header you see from a validator from validator for specific ground number. Then the validator just creates all the votes into a certificate and rebroadcast back the certificate. So that's a very common pattern. So the next block not linked to the Genesis of course it would just link to 12 plus one certificates of the previous round so that we build a structured round. These what you see on the graph here, we consider it around one. And for those who want to do more of those things you realize that if we do that a lot of time we eventually achieve some Byzantine consistent broadcasts. So every node does that in parallel right so here I removed all the links except for node one for clarity on the on the graph but every node does the same thing. Round one is all the things that I showed before round two similar but it links to 12 plus one certificates of round one. And so we have that day. So that's what the member gives you that's what it outputs to the consensus layer. So now we have that we have a structured member and let's see what we can do with that to have a consensus protocol. We're going to present tasks, which is a zero message asynchronous consensus protocols. What we mean by zero message is that we just look at the bag and we interpret to derive a total order of transactions. So new consensus engine will not send any message at all. So let's assume that we have the back like that right so round one happened and run to and now we're about to reach around around three so we already saw as a node 12 plus one messages of from three. So first small modification. We include a share of random coin every every odd round so that every odd round we can actually open and look around the coin. So once the threshold of the random point is 12 plus one so we arrive at round three. We have been with 12 plus one certificates for round three right enough shares to compute the coin and we use it to elect a leader or from air minus two. So now that we have the common coin we can see what was the leader or from one. The leader of ground one was at one. The one you see on the screen there. And now we ask ourselves the second question, which is how much support does that either have. So what support means it means how many nodes from around to linked to the leader. Here we see on the picture that it's only one. What we want is actually at plus one support for a leader. If not we say just leave the rest, not enough support, and we just continue we don't do anything. So really there it's pretty nice because we do not have you change also a leader is considered to have failed according to some definitions of fate right. So, let's go on the bag continue to grow. For instance, we may have some gaps in the bag that happens, not a big problem. And now we're on round five. So round five. It's an odd number again so we can open the new common coin. We open the new common coin that tells us who's the leader of round three. So it's a two. In the previous before we look, what's the support for the leader of two. Let's just look at round four and check how many blocks of round four actually linked to the leader. Now it's cool we have F plus one support F plus one notes links to the leader, and now we can commit. So that is the commit for now. How does it work. So we look at leader two, the one that we just found has not support, and we check if it had if it's linked to the bag to any previous leader, but here you see on the graph, well it's linked to one the leader of one. So now what we do we first commit one, and then committed to. So that's very important we need to be a little bit cursive we go back and we start from the earliest leader, we commit the leader, and then we advance until we commit the leader to. So what does committing a leader means we're committing a leader means committing all it's so that. So for instance, when we say we managed to commit to, it actually means that we commit all the green blocks there, whatever it's linked by or to. So whenever we manage to get a leader with enough support, we actually commit a gigantic number of transactions at once. And so that was the task consensus protocol. If you follow that, it's actually really that simple there is very little more more than that. So this is task on top of normal, but in fact we can also have other consensus protocols on top of the number member. So what we do, we try to have hot stuff running on top of normal, we just replace the member and we have the traditional hot stuff consensus protocol, running on metadata provided by the member. We just have one flight modifications to commit through. Well, it's every time that we commit that hot stuff commits certificates that we use as payloads, what we can commit towards that is just we order the certificates and then they're cosily links so there is no problem in just ordering deterministic. And so we see that the member grows synchronously and whenever hot stuff managed to commit whatever it's payload, when we commit everything that follows. So you can see when hot stuff gets a payload we contain C1 and C2. The blue blocks are committed. The yellow one are next and then when hot stuff commits a blog that contains C3 what all the green one are committed as well. So we implemented that and try to see how the real thing works. We wrote that in drafts everything is open source. We use Tokyo for networking rocks to be for storage and Dalek for cryptography. So this is not quite production ready but we believe it's quite close to production ready system. And we're still working to improve that. So we took an experimental set of like the following we take five data centers as far as we can in the world, and we put an equal amount of machines. So here is the happy path, the throughput late Instagram. Just for the sake of time, forget about the orange line, the baseline hot stuff is the red one what happens if you just take hot stuff as it is, and we run it in the same condition so it's not the one that you may see on other papers that are actually in the data center, and compared on the same condition same transaction size to the rest of the protocols, the normal over task is just the same hot stuff protocol but just using normal as a medical and task is the protocol explained before. You can see that actually on those conditions task managed to have 150,000 transaction per seconds. So again, these are your complicated experiments with about three seconds latency. So that's about 20x above the state of the art for a synchronous consensus protocols have one more minute. So what about scalability. What happens is now we take a worker. And we, we have every worker on different machines, and we increase the number of workers. And so you can see that the protocol scales linearly very well. Here it's set up with four nodes, and we take 147 and 10 workers, and we look at the throughput latency graph. If you look at the one on the right, the line, the straight line, you see that we get about half a million transactions per second. 10 workers. Again, the latency does not suffer much at all actually three seconds per task and still about two seconds for hot stuff. And that's it. So, in conclusion, a separate consensus in the data dissemination is what enables high performance on these blockchain designs. So, again, one of the regulatory resource utilizations was actually key. So we all use auto machines as much as we can, the workers are the heavy, heavy base, everything else is quite light and operates on metadata. That's why we scale and link to the paper, link to the code. Let me know if you have any other question.