 My name is Andrei. I'm a summer PhD fellow at Consensus Lab. And in the next few minutes, I will show you how you can take pseudo code from a textbook or a series of white paper and convert it to an actual implementation using the MIRA framework. And MIRA has been developed by the Y3 team whose slack avatars you can see at the bottom of the screen. The outline is pretty simple. We are going after a high-level view of MIRA, we are going to take a textbook algorithm, convert it, implement it in MIRA and run it. The basic abstraction of MIRA is a node. And the node consists of modules which communicate by exchanging events. This events can also be intercepted and later replayed for debugging purposes, but basically it's just an event loop. And this is the core of MIRA. And we want to keep this core as small and simple as possible. And most of the complexity is actually implemented on top of this core. And today we'll talk about specific components called DSL, which stands for domain-specific language. And the goal of this component is to provide better abstraction, better programming abstractions. Because the core provides you with an interface to implement a module. But implementing module directly, implementing this interface directly, it's akin to writing software in assembly. So there is a natural conflict between keeping the core as simple as possible and providing the user with nice structures. That's why we need this extra layer, which is the DSL. One of the main goals of DSL and MIRA in general is to mimic the way that theoreticians write their pseudocode in textbooks and white papers. This snippet of code is taken from the famous textbook of Christian Cachon, Rashid Guravi and William Rodriguez called Introduction to Reliable and Secure Distributed Program. So while there is no single universally accepted pseudocode notation, there are some common trends. For example, you don't see people opening TCP connections or marshalling and not marshalling messages in the pseudocode. You are also quite unlikely to see people dealing with mute access and concurrency in general again in the pseudocode. So what you see instead quite often is this error, is this event-based paradigm where the protocol is basically represented by a set of event handlers, which are executed one at a time without concurrency. So this way they can access the shared state without any race conditions without any problems. So other than normal event handers, what is quite common to have in the pseudocode is condition handers. So this handler here is being executed when this condition over here is satisfied. And this is something completely strange to most programming languages. At least I've never seen any similar abstractions in programming languages. So just for the context, I'm going to quickly explain you what this pseudocode does. It actually implements an abstraction called business inconsistent broadcast. And the goal is for a single node, for the leader to be able to broadcast a single message to a fixed set of nodes. And it should be able to do so consistently, which means that Byzantine leader and malicious leader will not be able to send different messages to different nodes. So you can see that some sort of particular location prevention mechanism. Okay. So let us quickly compare the pseudocode to mere code and see how they are similar or different. So the code in mid DSL, it starts from this comment from this function DSL.newModel, which creates this handle M, which is sort of representation of our module, which we'll use to register handlers. And as for the state, we can simply actually use a local variable. Here is an example of a simple event handler. In the pseudocode, what happens is when the leader wants to broadcast some message, it iterates over the list of all processes and it sends to each process the message. This is the first step of the protocol. And how we implement in here is very similar. We invoked this upon broadcast request function, which registers a handler for the broadcast request event. So the event has some data. And here we check some condition, which in the pseudocode, we simply could leave a comment that, okay, this handler, you can be only provoked by process S, which is the leader. So in the actual code, we probably want to actually check this condition to avoid some silly mistakes. Then we also save the data to the state, but it's a minor detail for mostly for convenience. And then we invoke the DSL send message, which emits an event for sending the message and send this event to the networking module, which is mc.net. And the event contains the message that we want to send and the list of nodes to which we want to send this event, which is in this case, all nodes. So you can see that transformation from here to here from the pseudocode to the actual code. In this case, it can be done almost mechanically, even though the actual code tends to be a little bit more verbose. And here's this idea, more complicated example. Here, when a node receives some message, it checks some conditions. And if this condition is satisfied, it creates a digital signature and sends it back to the leader. And this is something where me slightly differs from the pseudocode because creating signatures is an expensive operation. And recall that we want the protocol implementation to be basically single threaded. So that's why we actually create, we do such heavy operations asynchronously. So instead of just creating signature in place here and sending it back to the leader, we send the request to the crypto module to create a signature for us. And eventually the crypto module notifies us that the signature is ready and only then we send it to the leader. So the moral here is that sometimes for the sake of performance, we may actually take a single event handler in pseudocode and split it into several event handlers and mirror, but still the transformation from here to here is still pretty simple. So that's, which is the main goal here. And finally, there is a cool thing that media cell actually supports conditional handlers, which is fun because no other programming languages, no real programming language is supported and but it's actually quite common to use in white papers. So yeah. And yeah, let me just quickly show you that it actually runs that actually works. So this is a very toy application. As I said, it's a simple broadcast which allows the first node, which is a leader to send a single message to all other nodes, which are represented by the four terminals here. And we're just going to say, hello, let's for example, and yeah, as you can see the message is delivered and it is done through a Byzantine filter and algorithm. And so the leader will not be able to create. Okay. And finally, I'd like to mention that mirror is still work in progress. There are a lot of challenges that we need to address. For most of them, we sort of know how to address them, but we are still working on that. And I guess that's it from me for today. And you can also come and chat with us and meet the Slack channel on Filecoin Slack. Thank you.