 Okay, so the Wi-Fi project is about implementing existing BFT type consensus in the subnets. And motivation behind the project is that Udica has only two simple consensus protocols consensus protocols. And to investigate and explore new subnet features, we need to add other consensus protocols. And we discussed all candidates and decided that we implement Tendermint protocol, but in black, black box model or service-based model. And current assumptions that restrict us are as follows. So the first is that we work in permission setting. And the second is that we work in permission setting. And the third is that we work in permission setting. And the third is that we work in permission setting. We have one-to-one relationship between Udica nodes and Tendermint nodes. Sidecar design, when users Udica and Tendermint nodes are co-located. And the new one is that Udica node reuses, the corresponding Tendermint nodes. Sec P256 key one key. The design, the main peculiarity of the design from my perspective is that Tendermint is applied in a not typical way as services, services, services, services, as services like ZooKeeper or Chaby. And, but in what does mean to not typical. So the typical Tendermint, the typical design to use Tendermint is to implement abstract blockchain interface for application. So that would a Tendermint-centric design where Udica code base would be used as a backend and Tendermint as a frontend. And we decided to not use this approach because probably we would require to refactor many Udica code and that would fit well with other probably edit in the future protocols. So the idea is to use Tendermint as a message system with VFT total order broadcast properties without any modifications of the file coin state. So Tendermint. Shall we ask questions like, like interrupting the questions? I can keep my question for later. But wait. What do you prefer? Please ask. Okay. Just a clarification. What's ABCI based model? Application blockchain interface. Tendermint. Tendermint. Okay. Yes. This is a special interface that suggests that the developer of the application will implement several methods like check transaction, delivery transaction and block, begin block in four query blockchain and so on. And the developer can implement that model in different languages. So the implementation of the application will be implemented in different languages. So the implementation is not a language specific because the interactions are over JRPC, as I remember. Yes. The next question. Yes. Can you elaborate a little bit more why, why this abstraction is not the right one? Because from my perspective, it would mean that, that we create only, we will use only one Tendermint protocol. So we will refactor many code. We will use only one Tendermint protocol. We will use only one Tendermint protocol. So we will refactor many code. We will refactor many code from Yudica to adopt this model. But this refactoring will not be applied for other consensus. In the proposed way, at least we can use other blockchain protocols in the same way. And we can explore how Yudica properties in this model. What is the latency, throughput and so on and so on. So the most approach can be used with any blockchain protocols that provide the interface. Very nice. Yeah, makes complete sense. So rather than adapting everything to this particular one, we have a different interface and rather adapt, like right to consensus protocol is something that is compatible with. Yes. Yes, yes, exactly. Perfect. Perfect. That's what I had in mind as well. So in the proposed method, we are implementing Yudica consensus interface. Adapted to different protocols. Yes, yes, thanks. And the last one is that we, at least currently we reuse, we use two independent P2P networks. One from TenderMint nodes to spread disseminate TenderMint blocks and another one, the existed one in Yudica. Okay. Marco, you wanted to ask something. Thank you. Thank you. Okay. And this is the basic architecture. For nodes, each node is connected to the corresponding TenderMint node. This, this, this all nodes have different sick P keys. And Yudica clients can access them. And this one is TenderMint P2P network. And another one is Yudica P2P network. And this is, these lines are HTTP interactions over HTTP protocol between two nodes. So basically how it works. Each Yudica node interacts with a trusted TenderMint node. And of course, the corresponding node is considered as a trusted node. Yudica sends all input messages from pools, from cross messages pools and from message, messages pool pools to the TenderMint node. TenderMint validates all messages. As much as it can. And then implement total order broadcast. So that means that all transactions, input transactions from different Yudica nodes will be ordered in the same order. Again, and then each Yudica node use TenderMint RPC interface to retrieve the mind or propose TenderMint, sorry, to retrieve committed TenderMint blocks to perform static and semantic validation, which removes all corrupted messages, generates a file coin block with the only correct messages. And then it does several things. The first is it translates the minor address because the minor is a TenderMint node. And now we want to use Yudica, the corresponding Yudica node address. So we translate the TenderMint node address into a Yudica address. Then we retrieve the original hash of the block from TenderMint and add it into a special field in the file coin block. We send the block over P2P and applies the messages. And I don't know if you can see the picture or not, but this is the block scheme, how it works and how components and real functions from the Yudica are used. So I will describe the flow process. So the same messages, there is a minor, and I should say that consensus interface in Yudica has three main methods, create block, validate block, and validate PubSub block. And another important function is mine. So in that function, we retrieve all messages from original Yudica mem pool and then put them into a special message pool that is only used in our implementation. The idea is that unfortunately, TenderMint has a bug that as a result, the TenderMint node can, that bug can lead to hanging the TenderMint node if we send two the same messages. And it hasn't been fixed so far, unfortunately. So, and another reason is that this mem pool is local and TenderMint RPC is remote. And throughput are different. And without this message pool, we would send the same messages many several hundred times, the same message. So we use broadcast text sync method. This method is implemented in TenderMint and it guarantees that if the function returns, doesn't return an error, then the message will be added into a block eventually. Actually, there are, okay, it doesn't matter. And then we send messages into TenderMint node, TenderMint node does all magic and we use, and there is another flow for validation. So after we send all messages, we are trying to mine a block. We receive the same, we access the block with the same head as we need. We filter all messages because they can be incorrect or corrupted by other TenderMint nodes or an honest Utica nodes. And then we filter them out, perform validation in TenderMint sense and what does it mean? I will describe in the next slide. Add miner, add hash of the block from TenderMint and then send these blocks over the existing P2P connection with other nodes. Any questions related to this scheme? So you said TenderMint-related validation, why does TenderMint-related validation happen in the Utica node and not in TenderMint? Because TenderMint would need to know state and we don't know that. So it can do a basic static validation. The static term is according to FileCoin spec. There are static validation that can be implemented in TenderMint and another one is semantic validation. Sorry, go ahead. Is there a benefit for putting any validation in TenderMint? Yes, it's possible in the first model. In TenderMint-centric. What would you do? Yes, and we decided to not apply that. Yes, but why wouldn't you? You want to help out with something. You want to help out with some TenderMint validation. Yeah, because if I can, rather than pushing like FileCoin-related validation to TenderMint, why don't I just do FileCoin-related validation in the Utica node and TenderMint just orders? That's what she does. Okay, because then it's filtering messages. There is a part here. Correct me, Dennis, if I'm wrong. Yeah, I see. On the slide, it makes sense. Yes, but then didn't you say that you pushed some validation to TenderMint? Basic validation, only very trivial basic validation because there are different messages. At least we have two messages, one cross messages and another one signed messages. And we can validate very trivial properties for that message. And also, I use another type of messages for registration Utica nodes. So if you want, I can highlight this topic. The idea is that, and you will see this in demo. So while I will be starting the deployment, the TenderMint height will be maybe 100. And of course, we know that all these blocks will be empty because we have not started mining. Our Utica nodes have not started mining yet. We don't need to apply, validate, and so on, validate those messages from TenderMint blockchain. Correct? Yeah. And because of that, we can skip them. So I am trying to calculate the blockchain offset between TenderMint and TenderMint blockchain and Filecoin blockchain. And because of that, I need several other types of messages. And because of that, I need to validate them. Validate means in that case is just to look at the last byte and try to decode them. And we should parse this input message as one of the existing messages in the protocol. Signed message, just message, or registration message, and that's all validation in TenderMint. These are TenderMint specific terms, right? Which one? Validation? Other types of messages? This is fine. Okay. Yeah, thanks. The name of the function. Okay. Okay. And so the most, from my perspective, interesting slide. About the slide is about block mining and validation. So this is TenderMint PC interface, and we are going to mine this block. So we are going to mine this block. And suppose that we are going to mine this block. So that means that we received all, so we know the hate, we retrieved all transactions from TenderMint RPC for that hate. And we, we added them into our block template. Then let's suppose that, and there are, of course, several Utica nodes, then we'll do the same. And if they would use, if they use traditional signing, I mean elliptic curve signing, then all valid, then they, all blocks would be valid, but they will have the different signatures. Yes. And because of that, we don't use block signature, it's new. And instead of block signing, we use block hashing. So to validate block, we, the Utica node that has received the block over P2P goes to TenderMint RPC using hate value and compare to hashes, hashes from the original block in TenderMint and the field that is currently, currently live in ticket field in Utica, in Filecoin blockchain messaging. And then address, address, address translation. So, I'm just asking what is ticket use for when it's not used for, it's used to, like, is the proof of a leader in the pipeline processes. But we're using to get, like, because we don't use it in delegated, yeah. Yeah. And the next topic is address translation. So, Utica node received all information that is needed to send the new block. But of course, this node wants to fields. And it must add or own address. But this block from TenderMint has another address. And for only implementation reasons. So, the idea is that address formats in, formats in TenderMint and Utica, in Filecoin are totally different. Utica uses black, black function. TenderMint uses shot to five six. And TenderMint uses ripe MD. Sorry, TenderMint uses ripe MD function and shot to five six. And moreover, the format of public keys is also different. Utica uses compressed, compressed public key and TenderMint uses uncompressed or vice versa. I don't remember. So, the idea that to add the correct address of the target Utica node, we have to resolve the address. So, we know hate, we know proposer address. We can use TenderMint RPC to know, to get its public key. And then we can get a Utica address from this public key. And only then we add this new Utica address in the Filecoin. Future plans. Demo, I mean, today's demo. Then code review. I think that Alfonso will find many things I will have to fix. And of course, the current implementation is not efficient, but it is effective. I mean, it works please so far. Then there is no any testing. And I think that I should add unit testing and maybe AWS light with formal methods. I have experience applying these methods. And I briefly mentioned them on one of the meeting, I think. And maybe we should talk, discuss or even try to implement it. I don't think it's necessary permission less. I think that's all for the comment. Thank you. Sorry. I think Alfonso will have a comment. We were doing. This was a previous discussion, right? We were doing a lot of integration testing rather than. No, we are doing unit testing rather than integration. Oh, yeah. What we do is, I mean, we have a unit test for each of the packages. And then the way we should test it works is. We hope for the best. Yes. And what I was going to ask, then this is how are you? I mean, how are you trying to, if we use the AWS with formal methods, do you think that it's possible to apply them in the current project? Yeah, let me briefly describe the idea. Of the method. So, okay, so they, the idea is to, is to create different implementations of the same interface. So, if I want to implement that method in the Udica plus TenderMint, then I would implement TenderMint RPC with very simple properties. For example, if I send the message to TenderMint, to special endpoint of that implementation, I will receive the same message with the, with the provided hate. And then I can run property-based testing, for example, and ask to prove, informally, of course, prove the engine that if all messages in all blocks are corrupted, then no one block on FileCoin will be, on FileCoin will be mined. Okay, so there is, in real production implementation, I use the real TenderMint implementation interface. And for testing, so this is like a mocking, but this is sophisticated. And the differences between mocking and the approach by AWS is that implementations must be right in languages with very strong guarantees, like Rust, Go, C++, Haskell, and so on. So I can't use, according to the proposed method, I can't use Python, for example, or no JS, okay? So that's the idea. Okay, understood. Yeah, that's it. I don't know if it makes sense for this project, but it's great that we have that tool for placement. Yeah. So you mentioned the implementation is not efficient. So what, like, do you have any intuition on how you mentioned your, I guess, yeah. From my perspective, for example, there are many repeated constructions in the validations functions, even in the Utico. For example, in ValidateBlock and ValidateBlock pops up because ValidateBlock pops up calls ValidateBlock, at least this one. Maybe there is some requirements why we have that. So I think, I thought about some kind of these inefficiencies. Or another one is, of course, MessagePool. So MessagePool is very simple. It's a map in memory that uses hash or the message as a key. And that provides property that all messages will not be sent twice to TenderMint. And it works, but it works not officially, of course, not officially, not so officially as it could. So do you think it would be useful to have a baseline comparison against lean TenderMint versus what you implemented from Utico and have a benchmark, essentially that compares the two? But benchmarking with, so benchmarking two implementations of TenderMint integration or TenderMint. And that same test that you basically put the load, not to TenderMint directly, but you put the load to Utico and you see what happens. We know what will happen. TenderMint will be hanging and it will not work. Well, can you just attach some dummy, like a local clock timestamp in nanoseconds to make each message you need? Yes, this is the MessagePool implementation. But it's very, very simple. Maybe 50 lines of code. Yeah, no, what I think what Mark was suggesting is that we have TenderMint alone, sending a bunch of messages and then have Utico integration with TenderMint, sending a bunch of messages so that we can compare the overhead of adding Utico. So if there are overheads or not, by using just TenderMint and Utico plus TenderMint. This is exactly what I mean. Yeah, about Utico with which consensus? With TenderMint. So to compare the overhead that is introduced by Utico by using TenderMint. Yes, yeah, it makes sense, I think. Do you think this is a lot of overhead to do this kind of performance test? I don't think that it's a lot of work. But I would prefer code review first, then testing and then experiments. I'm not suggesting to prioritize this, no, I'm just suggesting the road map. So my suggestion then it will be like do a PR, draft PR right away that I can start reviewing, even if like the code changes, but that way we can start. And then once we have, we can before merging do these simple tests so that we can include like the benchmark dots and so on and have a nice package to include in the vehicle. What's also, I don't know if you want to write it as a test or not, but just to add what should be done is killing one node and seeing what happens. So if you have a network of four nodes, you need to be able to kill a node, put it back. So a great demo would actually, you know, demo, of course to a good case. And once we are happy, then basically kill one node, bring it up, ideally kill an after sometime while, while this node A, you have nodes A, B, C and D, you kill the node A, node A comes back, it catches up, you kill the node B, and you show that you can basically kill one node at a time. That would be amazing then. Yes. Yeah. I totally agree, but which node? A TenderMint or Yudhiko? I don't care. Well, yeah. No, I mean, we do care. We want to break the assumption that the two nodes are always so, so both. No, no, but like, I mean, in the end, the one that we want to break is TenderMint, because it's the one that runs the consensus. So you want to take out, if I say take out node A, then take out A, TenderMint node, but you can also kill Yudhiko node A. Yeah. Exactly. Yeah. Because that way you don't have to, I mean, it doesn't matter, I guess. Oh, that's a point. You don't want to test your best. Exactly. I mean, it's like, oh, it's testing. And I'm going to kill Yudhiko. I'm going to kill Yudhiko. Please. No. Yeah. If you're going to test, if you're going to kill one, you kill tribal dates. Yeah, yeah, yeah. Make sure that. Some scenarios that make sense, you can, you can, you can propose your own scenario. What you think it's reasonable. Let's, you know, you can quickly review it. For the next meeting. And so these two things, like, I'm pretty sure you're going to do great demos when, when everything goes well, but I would compliment this with some failure scenario. And this performance. And this would already look great. Okay. Make sense. And one more question. Can you, can you elaborate a little bit more on, because this is, this is of a very, a big interest to me. What exactly is the interface between the, the tendermint node and the Unicom node. And actually if you go to the next slide with a colorful arrow. Yes. So basically the vertical arrows are this interface, right? Yes. So how is the, how does this interface exactly work? And why do we have to do the address translation and so on? So this interface provides us access to blocks from tendermint blockchain. So we can, if we want to mine block number 10, we go to via tendermint RPC and ask to provide the block number 10. And then tendermint block has a tendermint address, tendermint validator address, sorry, tendermint proposer address. And the corresponding, the node corresponding to a proposer in tendermint network will be equal to proposer in Unicom network, correct? But because of the address, the address, the addresses have the different format, we can add tendermint address directly because it doesn't make sense in file calling network. Sure. Sure. What I mean. Ah, okay. Okay. I think I need to, so basically in file calling, when I receive a block, I do need to obtain the information who proposed the block. Yeah. Because in, we use P2P from Utica and Utica nodes, my, my, must update the state. And if block addresses will be from tendermint node, tendermint network, we would not be able to update the state correctly. Yes. And now, for example, could it be done that this, these vertical arrows are extremely simple. We just, there's one arrow towards the tendermint or general ordering service. We basically, you give, so in one sentence, it will be, I give it a sequence of byte arrays in arbitrary order and it gives me back some sequence of byte arrays in a consistent order across all Utica nodes. And then whatever I need, on top of that, I will actually encode in whatever I sent to the ordering service. Yes. But we need to validate the given information somehow, right? So we must access also some hashes or signatures from the RPC, right? Do we? But it is basic idea, you're absolutely correct. This is the same algorithm. But we can't, we can't change tendermint implementation. And because of that, we must adapt their features. Yes. I was just thinking whether we can draw a really thick line of abstraction between that and use really tendermint only for ordering byte arrays, nothing else. Because this is, if we can do this, then it's very easy to switch tendermint for, let's say, near BFT or something. And then when the Utica node wants to propose something, it actually attaches all the necessary metadata to this byte array. The ordering just orders that somehow, when it comes out again, then you would unpack it. And it will be completely tendermint unspecific. You can do that with the caveat that you may need for checking, you may need an auxiliary method in the sense that tendermint is not giving you all of the information you access it. So the implementation, it's an implementation detail. The interface can be as you mentioned. Okay. But under the hood, it may require additional calls because like tendermint doesn't give you the plug, you have to access it rapidly. All right. Yeah, but that's what he said, like the high level rapper. It definitely can be. I think that's okay, perfect. Very nice. So I was thinking one thing that I really liked is that Dennis had new BFT in mind when he was implementing this. Actually, he was suggesting new BFT from the script, but the idea is to have an interface and that's why maybe we'll have to iterate on it where you just send a bunch of, that's why we're sending messages and not blog, or something else, because send files, order them, receive them, check them, and like execute them. So hopefully that, I mean, notice it, but like, it's, you know, it was... No, no, it's tricky. No. Yes, please. That's the easy part. Yeah. No, I'm just, I just got slightly worried when we like, were reusing fields and hacking stuff in. This is usually... Implementation detail. Yes. But as soon as the implementation starts to arrive on that, it's tricky. Yes. So the idea is that one of these functions or the interface potentially will have to give you the signature or ticket of the leader or a way of checking that the message is, so that the ordering is correct, because you are just receiving a blog. But I trust the tendermint. Yes. But you trust your tendermint. Yes. Yes. Okay. Yeah. Well, I think it's the same ordering service thing. Yes. But then you don't use the same... So the problem with tendermint is that they're using an independent cash flow layer, which means that when you see from scratch, you're receiving it from Gossip's up. So you need some additional information to check if the message is correct. But like, again, that's implementation detail not... Yeah, okay. Well, I can begin that. We can get it low level, yeah. Because you can also talk to each other as well. Yes. Yeah. Yeah. Yeah. Right. So, so basically, but then basically the payload dissemination part can be taken off the shoulders of the order. Yes. Yes. That's the thing with new BFT is going to be really interesting because they're... So in tendermint, we didn't want to go on like fork tendermint. But with new BFT, we have the interface already. That's why I have to isolate the net interface. What was it? Yes. Because we have it, which means that we can reuse whatever we have. You can just plug that in. Yes. And this won't be a problem. Yeah. Yeah. Yeah. Actually, even the payload dissemination is decoupled in that. So, yeah. Which is not the case here because of the, we didn't want to go. It's a platform for us. So that's why I said like the interface is correct. The implementation may not be because of this. Right. Okay. Very nice. We're looking forward to putting that together. Great. More questions. So we have a demo, right? Dennis. Yeah. We have a demo. And because I didn't perform fault integration testing, I, I will show the video. Okay. And I annotate the video. If you don't mind. It's very good to avoid this problem that you never get an error, but when. We sacrifice people. Okay. So I will use not traditional setup. Alfonso doesn't use such tabs. But anyway, so I will use to mocks. Terminals and my ID. Jet Bricks from Jet Bricks. Okay. So I hope you see my screen. So we. We run our deployment. Okay. This group in the repo. So this one is for subnet. And. The upper one is a tendermint for node deployment. And this one proof of work demon. This one is proof of work minor and bottom. Terminals are from proof of work minor from another subnet. And here we have two nodes, you deco one and you deco zero. And here we'll use subnets. And we can see that. Tender mean. Is working. And now we connect with now we. Get address and connect the node. You deco one to you deco zero over P2P. And now they're in sync. We start consensus and. Subnet. Another wrong address. And this address is wrong. And I will fix it. No errors. And now we will send. Money from address. Trying to send them. We received. The deco one nodes is joining. Start mining in. Tender mean. And the same. For the you deco one node. And this address is wrong. We received. 13 fields. And the same for you deco. One node. And that's all. So. It requires many, many interactions. So probably I should improve that. And. Or maybe. We will use manual approach for fault. Tolerating a demo. So any ideas will. That's all. Where is. Where is. Okay. Any new Christians. Comments. So the unit. As a client to the tendermint order. Right. Also having near BFT in mind. Does tendermint keep explicit. Client. Client identities. Like any information about client identities. And that's, that's a track which clients. Does it any, any form of access control. Not necessarily access control, but that's it. Does it actually. Use any information about what, who submitted what. I'll also correct me if I'm wrong. No, it's right. So the thing is that we, I mean, you need identities in order to sign proposals and votes in tender meet. And our work around for this so that we didn't have to use different identities is that we use a set, like that is the translation so that we can use the same set keys that we used to identify with econos for tender meet. So that there's nothing specific, yeah, we get like cryptographic like primitive use in tender meet should be compatible with our identities. Yeah, and I don't even mean on the implementation level, but fundamentally, actually, and this is, this is a problem with, with mere BFT. It could be a problem in general, that the mere BFT when, when, when somebody submits a request for ordering, maybe if you need to know, like, which plan submitted it and how many, how many requests the plan submitted before. Okay, do you mean at a network layer? No, at the abstract, like, like, I'm a client. Yeah, yeah, yeah. And the e-deco node, I submit a block, then I submit an update. You're signing the messages. I'm signing the messages and, and then I mean it's configured to, to verify the signature and so on or could be. No, no, no, that would come before, right, before sending. So if the enemy is only doing order. Yes. So e-deco will take the message. You could check the source of the message and say, hey, I'm like, keep state of what messages have been sent. Yes, well, no, but it actually interferes with what I was saying before, that you just send a bunch of bytes and you receive a bunch of bytes. Could you do that? So at a time level, you're doing that? I know, I know, but at a, maybe a few level, you actually don't do just that. You do need to attach some meta information to that. I remember why I'm walking towards the bar. Yes. Because, because without that, you are susceptible to some, to some more forms of like those attacks and the imbalance attacks. Let me come back to that. So that was for permission, but how would you work? You would pay a fee for each transaction. Well, I think here it's not even that critical because you know the set of clients. It's a set of unicode notes. So that is totally fine. It's just that we need to somehow come for that maybe. So that would be the same. Yes, but you, yes, so, so trivial set of clients would be just the set of unicode notes, but when you do reconfiguration, you might actually explicitly tell the order and service. I am reconfigured. No, I mean, it's not nothing like nothing. I don't think it's a big problem, but something to kick him up. Well, let's, let's, yeah. Thanks a lot, Dennis. I don't have questions. Thank you for your attention on questions. So next steps we scratched a bit. So essentially like a part. So, so, so can you summarize next steps apart? What we discussed now, maybe like this whole testing for faults and many of the performance tests. So what else? After review and implementation fixing. You mentioned it was like this. So you mentioned this. And then I said about permission less setting and AWS based approach formal method testing. If, if it. Was permissionless. You did permissionless is permissionless setting. So a tender man can be used in permissionless setting because cosmos is a permissionless. So if it's interesting for the project, we, we can at least think about it. I wonder what's, oh, you mean that other. Sorry, is, is that quite the other tender man joints. Yes. Because it's permissionless, even if they don't have matching unicorns. Of course, if they match unicorn notes. So if there was a two notes, we, we can try to join them in the permissionless setting. Yes. Oh, if it's not necessary, I can skip that. Then it's pregnant. I'm wrong. Is that if I'm unable to go out that wants to run. I should be able to include my time. No. Into a family network without any kind of. Yes. At least that possible in tender mean world because cosmos works in this manner. Okay. So, is the demo the following? So you're running the four, four notes and there is a fifth note joining the summer. Is this. I don't know how to do this. I just suggest the ideas for further research. I don't know. Is it simple or not? I have not done this so far. So I don't know. It's important to put it on your agenda. Yeah, because we will need it for any protocol. Yes. We will need this feature. So what do you mean by permission as you mean reconfiguration. Yes. Okay, so that's important. Yes. So we have a full case. We have a whole review. This is, this is like, let's say for checking features, additional features would be. We have a demo with four notes performance benchmarking and actually adding notes and removing notes. Let's put this on the agenda and see how far we go. Ideally, we should get all this covered, but let's, you know, let's try to make it realistically. You know, how much time would you need for each of these things and I guess we can pick it up on Monday. Okay. Yeah, I. So the other thing is, so we do have a demo like this Thursday, right? Which we're not scheduling by five four or we weren't. We could. I mean, we do have a demo. Yeah. I think it would be nice for. Others to see this. I mean, probably. Because it's like. Yeah, I mean it's like 3am for, for, for Dennis. Yeah. Does that sound okay to you Dennis demoing recording five or 10 minutes. I don't know. So the demo you recorded did not have audio rights. Mm hmm. In February. Sorry. When the. You just did. You were speaking live. Or. But was there. That is the question. So the demo is this Thursday at, I think 3am your time. That's why I'm saying recorded. Because we're not that mean. But it could be basically. Of what you showed today. So if you have that already recorded with. I'll do explanation. We can just reuse that. Or if you want. But yes, so, so we would have an advanced demo which was not scheduled. And then for, for the March demo day, which was scheduled, then we will do more stuff. And if we have benchmarks and stuff that could also be pretty cool. So. I will record. The demo correct. Yeah, I mean, if you want to be awake at 3am, you can. I'm just. I'm just saying, yeah, you know.