 Our third session speaker is Georgia Azura Marzón from NEC Labs Europe who will be discussing mitosis, practically scaling permissioned blockchains, so I'll hand over the floor now. Yeah, thanks. So I'm presenting a joint work with some of my colleagues from NEC Labs Europe named Ditiabatian Andreina, Konstantin Monicev and Gal San Carame, as well as Lorenzo Aluminio that has been in turn with us a few months ago. And, yeah, so this work is in the context of scaling, sorry, scaling permissioned blockchains and just to... I mean, reiterate on the motivation that was already mentioned in Microsoft. So there has been a lot of effort in towards improving the scalability of permissionless blockchains and mainly this effort is constantly focused on improving the transaction throughput, which is, but it's more for currently deployed systems, particular Bitcoin and Ethereum which are the mostly widely adopted state buffer, about 10 transactions per second while the centralized competitors like Visa credit card goes up to 20, like, yeah, more than 20,000 transactions per second. So ideally scalability for permission and systems would aim at improving transaction getting closer to decentralized systems. There has been many approaches. In the context of permissionless blockchains, which are falling to the umbrella of layer one approaches and layer two approaches on the blockchain or consensus layer and on the smart contact layer. And so in our project we focused on layer one approaches and in particular we were inspired by, so partly at least by blockchain shouting. However, our paper is focused, our work is focused on scaling permissioned, permission based blockchains. So to give some motivation and position at work I would like to look at the advantages and disadvantages that permissionless and permissioned systems provide. So first of all, from the decentralization perspective of course permission based systems are to some extent less decentralized or less open. So with a disadvantage because for some applications, for example for enterprise development, it is actually desirable to have some limit to the participants of the system. So, and this is also why we focus on permission systems. And then looking at scalability in the number of nodes, well, permissionless systems have a big advantage because they can effectively enable any number of nodes without having a performance. So contrast permission systems that rely on classical consensus BFT or BFT protocols, due to the high communication can only scale to very small systems below 100 of nodes typically. So if we look at the other end permissioned blockchains offer very high throughput and low latency they provide finality and in this respect they are much stronger than permissionless blockchains. So given this, we, so if we look a little bit like at the, at the old picture. So basically speaking with permission based blockchains actually the only missing part is indeed the node scalability. And, and this is effectively what we aim to do in our work. Our proposal precisely ends at providing highest scalability in terms of nodes for permission based blockchains. And basically the idea that remains the picture that we envision initially to provide a blockchain ecosystem where multiple individual blockchains run simultaneously and autonomously so they are independent of each other. And in particular, we would like our system to be dynamic in the sense that blockchains can be created and developed when it is, when, when the type comes when it is actually necessary to change and flexible in the sense that each system, each sub system for each blockchain would be able to run its own consensus protocol. And so in a sense of this, this big system that this is a high level system that we have in mind is very similar to shouting because it also partitions the transaction processing among independent set of nodes. However, shouting is more rigid. Because, so first of all, all nodes are expected to run the same consensus protocol, and shall have to be created once for all. And so I'm not created dynamically. So this is a level goal of my doses. And so we also, I mean, we don't want to just have isolated system so we also provide support for cross chain communication so that each node can talk to all the other nodes in principle and effectively the, so this makes sure that the system becomes an ecosystem. Where the blockchains are interconnected. So now going from the high level goal, I'd like to mention what is the effective difference with with blockchain shouting coming beyond the fact that we look at permission based systems. And so here is the main component of our solution. Basically, the main innovation is the way them is the mechanism that instructs when to shout or when to split the system. This component we call chain, chain division, and it is reminiscent of the biological process of cell division and this is why we name the system my doses. Basically, the idea is to let an existing blockchain to give birth to to stop to new blockchains. And this, so this process is triggered. In the moment, a bottleneck in performance is reached, for example, when, when this head of nodes of the system the content is not to become too large, which is effectively the reason for decreasing performance in permission based systems. So the main idea would be to, to let each blockchain evolve in a reactive way, so that optimal performance can be met. Now again, I'd like to give a closer look at the comparison between my doses and shouting so here you can see an illustration of how a blockchain in my doses would evolve on the left. So if we start with a screenshot of a given set of validator of nodes content nodes in my doses. So this would represent a chain. And so at some point this chain might be split into two, giving birth to new to new blockchains with half of the nodes each. And then each of those individual blockchains might evolve and grow as more nodes join the system. And then again, regardless of the when each of these new blockchains grow and reaches a bottleneck then we might invoke so it might decide to invoke change division and and then split again and keep splitting. And it's of course more dynamic the shouting in the sense that shouting shouting will just instruct the system to create all the individual charge shots in one go. So in a sense our solution is a sort of dynamic shouting. So now coming to the security which is with the effectively the main focus of the rest of the talk. We observe the change division clearly also opens to to some risks. And what the reason is that consensus protocols can only tolerate a given number of falls. And when we shot it might happen that some of the fault nodes, the initial system. For me of course these nodes will be spread across the new the two blockchains and even though the initial system is in is secure in the sense of preserving the content is bound it might be that splitting will create an imbalance among the nodes in the two blockchains and and as a consequence, one of the two chains might be my violated content spawns. And so here in the example you can see a system very small system just for illustration where we have initially 20 nodes and six of those are we can assume that they are faulty. And then the system will be split into two shots of 10 nodes each. So here it might be this configuration on the right is problematic because of the six nodes for nodes and up in the first chain, and this violates the content is bound in that chain. Given this issue, we analyzed formally the security of this change division process. In the previous piece we followed the following approach. So we, we consider that parameterized scenario where we have. So we established we fix a maximum number of falls that are tolerated in the in the child chains. So in the example I will just leave me to the standard visiting case where we have at most one third of 40 nodes. And then based on this bound we derived the conditions on the parent chain. So namely on the fault that we can tolerate on the parent chain so that splitting is guaranteed to be secure. So basically there are two cases. The first one is an optimistic case is like very intuitive. We essentially assume that the parent chain has at most the tolerated falls in the, in any of the two child chains so again here in the example we assume standard visiting case with 10 nodes in a time chain. So we have one number of tolerated falls in the child chains is three. And as you can see in the illustration here the parent chain has very few forces or even in the worst case scenario where all the business nodes end up in one chain here security of forces maintained. So in the general case. We parameterized the number of falls in the parent chain, and we allow basically any number between the actual, the maximum tolerated falls in the bigger system and in the smaller system and we show an analytically with which probability based on on the fault duration in the parent chain, we might end up in an unsafe configuration. I mean, in the paper, we have a full analysis and I'm happy to explain that is more detailed if you're interested, and yeah to summarize. So our system I don't use is a provides a novel approach to scale permission based block chance we are using chain division. And the goal is to provide the flexible and dynamic ecosystem that charts reactively when the need arises. I think because of time I didn't discuss but in the paper we also provide to cross chain communication protocols for asset transfer and for knowledge transfer and we also discussed a proof of concept implementation. We have a little fabric and here I'm adding the link to the paper, and I would like to thank you for your attention.