 For those who don't know me yet, I think there's quite some of you. I'm Matej, I'm from Consensus Lab and I'm working on a consensus algorithm that is fast and scalable for being deployed in the subnets that Alfonso was just showing. So let me share my screen. I hope you see everything very good. So I will be talking about MirBFT, which is a scalable consensus implementation for everyone, not just for the subnets, hopefully. And since this is a project that most of you haven't seen yet, I will first spend a few minutes on introducing it, say what it is, how it works and how it can be used. And then I show a little demo of how it can actually be used for an application. So MirBFT is a framework for implementing distributed protocols that has a focus on consensus protocol, but ideally should be able to implement any kind of distributed protocols or let's say a wide variety of consensus protocols. It is available on GitHub and it is part of the Consensus Lab wide view project, which is the project about scalable consensus and you can look at more details about the project also. Actually, I will post in the chat when I find the chat window. Here is the chat. I will post the link to this presentation so you can look at the presentation and click on the links. Okay, just a little, just a little heads up. The name MirBFT and the location GitHub might be updated in the very near future, so stay tuned for that. Don't focus on the naming for now. Alright, so how does the implementation of the framework work? Basically, a distributed protocol always has some nodes that interact and they send each other messages and they collaborate to perform some tasks in common. So the basic abstraction is the node and every machine that is running the protocol instantiates one node like this. And the implementation is as modular as possible so the node basically just provides an internal mechanism for different modules of the node to communicate with each other and for each perform to its task. So there is some application module, there is a module that actually contains the protocol logic, there is a module that takes care of the network communication like sending actual messages on the network. There is a module that stores the payloads of the requests that are being agreed upon in the consensus protocol and there are some other modules that are not really that important for this explanation now. And once you instantiate the module, you have three functions that you can run on it. It's that you can call one function is run, which starts all the machinery and the processing that is necessary for the node to function. There is the submit request function. So for a consensus protocol, when somebody wants to, when a client wants to submit a request for ordering, for agreeing upon, they need to call the submit request function and insert a request in the node. And the status function is just for debugging purposes, we don't need to know too much about the node. Now, the node itself is just basically implementing a slightly fancier event loop that is getting all the events produced by the modules, storing them in the buffer and then processing them and disputing those events to the modules where they should go. Each module then processes whatever events it needs to process, potentially creating more events and so on and so on. So this is just an event loop. Okay, so this is the very high level architecture of it. Now, how do we use that. So this is an excerpt from the code, how how mere BST can be actually used to implement a distributed application and to offload as much as possible from from the programmer, such that the programmer can just implement the application or the protocol they need without worrying about too much more. So, let me show you a few lines of the code now so if we want to implement a simple chat application where everybody running a node can will participate in in a in a in a group where they can exchange messages. So we need to implement the logic of the chat application and this is a very simple one. We have a chat application here, and the only state the chat application has is an array of messages that that is totally ordered from from each participant. And it needs also the reference to the request store which is a request or module so it can actually access the payloads of the messages that that are being sent around. And so if you want to implement an application, if you want a distributed application with mere BST, you need to create, you need to create an object that implements an interface that consists of only three functions apply, which receives a batch of requests. And whatever the requests are, they just get applied to the state. So in this concrete case, we just cycle through all the requests in the batch. And what we do, we create a chat message, we print it. We say client so and so send message so and so. And the message is bait is just a request data, and we append it to the list of messages that that the application has. And then, in order to be able to restart and catch up with the state we need to, the application needs to be able to create a snapshot, which is simply serializing all the state in an array of bytes. And it needs to be able to restore its state from such an array of bytes, which is not that important for now. All right. So how do we actually do it. As we saw, as we saw here, we have a node that has several modules. And this is exactly how it looks at what it looks like in the code. So first we create some modules, like the networking module, which the library, the library has some packages that actually provide some implementations of those modules. So we have a GRPC based network transport module. We have a request store for now we just use a volatile request store also provided by the implementation itself. We need to also tell the node which distributed protocol it actually should be executed so which protocol logic there is. In this case, we use the only protocol that is being implemented. It's not even yet implemented it's it's quite stubby but it already can be used for for the demo purpose. It's a total order broadcast protocol. It's a consensus protocol. And we create some configuration for it and we create a protocol. Also using a library function, because the ISS packages provided also by the library. And then we assemble the node the same way that has was shown on the slide. We create a new node we give it its own ID we give some configuration parameters and we say which modules it should be using. It will be using the net module the request or the protocol module that we just created and we just tell it what application should be there for processing the agreed upon request. The crypto module as you can see it also needs a crypto module we only have a dummy crypto module implementation stuff but this will change soon hopeful. And then we create some other boilerplate code for actually passing the requests to the implementation and we read messages from the command line and we submit the requests to the node. So how does it work I really prepared for the deployment of four nodes. And basically, we just run the chat demo application here which is, which is the main file I was just showing it executes the main file there was a showing. One is with one is with ID zero one is with ID one ID to ID three. So I let me start all of them. So they all initialize they connect to each other. And I put a say I pressed enter once more on client to that's why everybody already sees that client to send an empty message. So basically, when I type in some message some low message. I press enter. What happens is that it creates a request for the for the total of the broadcast system. It submits it to the to the node. The note agrees on receiving that request and have all of these deliver the request to the chat application which which prints it on the screen now. And given the implementation of the protocol. All these will will be in total order so if I really quickly. If I really quickly type something in different windows like I would have to be very fast manually is not possible. Then everybody would receive the messages in the same order because they're totally. Now this is a demo application. But the same principle applies to the concept of protocol implemented in the subnet. And that's the the goal for the for the next months to actually make this part of the subject. So that's it for the first demo of this. Thank you very much. And I leave the floor for the next demo.