 It is time for Q&A for the clarification. So for our protocol we use mostly well we try to do the load balancing based on the size of the transactions or the cost of processing the transactions. And it was suggested by address to extend it also to have a look at the state size to make sure that in every single shot we have also dissimilar size. We initially didn't think about it because the storage doesn't seem to be a bottleneck. On the other hand, the long run it may be because if you say that you will store something in the blockchain while you get to store it for potentially forever which is complicated. So we are currently also looking on on to that. Although it is not clear whether you want to calculate the storage as for instance for smart contracts is the size of the state of the smart contracts or the amount of the modification to the smart contract probably both. That's the question and an answer. I just wanted to take a note on the implementation of our protocol ring bft which is inside the resilient db I really suggest everyone to take a look at our resilient db platform and take a look and to see how we can implement actual blockchain means permission blockchain system or if the consensus charting protocol and other. I want to ask a question about ring bft. So basically, the theoretical advantage of linear communication amongst shards is kind of clear but is there a practical advantage and like the did you quantify this. Can you can you detail this a bit. When it comes to the consensus in multi short transaction when you scale up up to 15 regions, the previous work usually have all to all communication and in the practical system when you scale up to hundreds of multiple hundreds of nodes. The communication would always be a bottleneck, for example in previous work like a HL reference committee would be the bottleneck and. This pattern of all 12 communication would make the performance of the system to true put the latency, a little bit even worse, and usually when people talk about the communication and the latency it's all about round trip. But when it comes to the actual protocol when it comes to the practical system working the RTT or round trip time is not the only barrier for the ratings for the latency and the performance of the system. The amount of communication the amount of messages messages that are being processed for one instance of cross short consensus to happen is the is one of the main and most important overlooked teams that are missing in the previous work that we take a look into. And this whole ring architecture that we go over the ring the linear amount of communication, which makes performance increasing and scaling the performance by increasing the number of short company linear so. It's scaling up to more sharp with the linear but in the previous work, since there's a all 12 communication scaling would not be linear. So in BFT scale is much, much better than our other previous charting consensus for all. And to that, of course we have your two linear terms we have the linear terms due to the cluster sending, but that's the small thing because if your shots are not going to be too big that that is an optimization but we're really really talking about communication between chart and chart so one chart talks to one other chart, whereas indeed like I explained in a lot of protocols that really try to do it as fast as possible, if you have five shots in your transactions you're going to have five shots talking to all five other charts, and that will blow up if your transaction become anything more than just move something from one shot to another. So yeah, so I understand I understand the argument. But you had experiments which would actually be apples to apples meaning like you would use cluster sending support for previous work and for your work, just to make sure that for cluster sending there is no difference. But, so I would just like to understand how did you measure this. So, your question is that if the cluster sending the crossing that the cluster sending solution applies to the other to the other protocols. Yes, if you would do that what would be the difference yes. Actually, this part is not trivial as you are saying you can apply the cluster sending problem the cluster sending solution to all those protocols, because the proof of the proof of safety and liveness of these, these protocol are based on the pattern of communication the whole the whole recovery process of ring BFD and other protocol relies on the pattern of communication the fault you know how would be the novelty here the solid point here is that when there's a when there is a faulty notes in different two clusters and the cluster coming the cluster sending is not behaving as expected what would be the recovery process, how we can fast recover from this process and do your cross shot transaction in that order to see our recovery, our recovery solutions that are explained the paper deep and completely in the pay in detail will also explain how we are handled those those scenarios and situation. So cluster sending solution can be added to any paper but the design of the protocol itself will not change right and, for example, a hl itself is having a reference committee which is basically talking to all other committees or all the shots. And that itself, even if you have a linear communication that does not mean hl will stop talking to all of the shots or shopper will stop talking to all of the shots that itself means there's a huge amount of commission which is bound to have in ring bft we just ensuring that one shot talks to another shot in a ring pattern so I mean the combination of so this as yellow said, there are two levels of linear communication happening one is plus sending other is the protocol itself the protocol is basically asking things to go in the ring flow. So, even if you remove one combination the other will still remind there's a bottleneck. So the bottleneck is the bottleneck reference committee, another protocol this one, sending to everyone so the bottlenecks still exist so this that's half of the solution. And from my experience I looked at actually similar things in a model project, but in that project what you did see if you have a multi shot and protocol that works just like in three foot to a three phase with just massive amounts of communication that works fine as long as you have the resources for that. Then it's going to have very good latency, very good performance of course, but it also will cause issues if you want to do blocking to do like transaction management. It will cause a lot of performance issues if you're really trying to max out throughput on all charts and it's actually really much more optimized for single-share transaction than multi-share. If you want to reliably support multi-share transactions, get some sort of blocking to do concurrency control then doing it in the ring BFT way is basically the only thing that can give you not too much issues from what I've seen and some prior to another projects. So for the first talk, Mitosis, given that you guys are from EDC, what's the status of the code? So we implemented, we have a very basic proof-of-contact implementation in fabric where we, so okay, honestly, I was not taking care of the implementation but I tried to answer as again and maybe my colleague can take over and answer really in the chat. So I believe we, so we implemented the crash-fort tolerance protocol where we created, yeah, chains with 10 to 20 nodes, 14 nodes, I think up to 15 nodes and we split that and we measure how long it takes to effectively to boost new, so the title chains from that. Then we have cross-chain protocols for asset transfer and for knowledge transfer that allow us proving the statement about the blockchain to another so that clients can communicate with each other, even if they are touched to different chains and also get 10 transactions from one another. I mean, again, I would have to look at this exact numbers but for our implementation, we, for splitting, so if I recall, to split a shadow with 20 nodes, we need like to, I think 35 seconds or so and the time to split a bigger chain grows linearly with the number of nodes but this can be, could be optimized just that we didn't do that in our code. Yeah, it was like below five minutes for splitting. Thank you, thank you, Giorgio. I have no more questions. Yeah, I have a quick question. Will this affect miners in any way or should I say storage providers? You're specifically referring to Biocoin? Correct. So, of course, this is the independent work that we invited because it's interesting. I mean, if authors of the papers already thought about this, I'm inviting them to answer the question, yes. Okay, thank you.