 Our next speaker is Jela Hellings from McMaster University who will be discussing efficient fault-tolerant cluster sending, reliable and efficient communication between Byzantine fault-tolerant clusters. Jela, take it away. Well, thanks for the interaction so I can skip the title page. So our motivation is basically already told by Marco and his keynote talk. Normal blockchains permission permission is not really matter have limited bandwidth. So one way to scale up is to shorty systems and to divide our data into different parts and then the individual parts can operate on the data independently. And as of course we have more complex stuff. So that's the main motivation of the work I'm going to present. And what we realized if you're going to try to do something like this, of course operating these individual clusters, we can do that with sensors, proof of work, PBFT dependent system, but to have interoperability between the clusters, you need something more right. And we decided to look into the communication between these blockchains between fault-tolerant clusters in depth and then in the permission setting. So how does that behave in the rest of the blockchains here? So if we look at permissionless blockchains actually, of course we know them Bitcoin Ethereum are the other ones. They're one of the earliest interoperability projects was actually the Bitcoin relay where we were able to translate data from the Bitcoin network to the Ethereum network. And lately there have also been quite a lot of white papers about sharded Ethereum systems like Cosmos and Pokedotti proposed some designs for that. And if you go into the research direction of things that are quite a lot of recent papers on how to do cross-chain interactions via atomic swaps, via atomic commitment to cross-chain deals, which all provide some form of communication between blockchains with some kind of guarantees. And this shows that, well, in the last decade, they have quite a bit of different approaches toward interoperability in this permissionless system. So it's a fundamental problem we take. And we looked at it, well, in the other side of the world, in the permission world, where or if we simplify everything a bit, everything is operated by a PBFT-like algorithm. And in the earliest projects where we saw actually interoperability being applied was Stuart and GBFT, which were both geo-skill-aware systems that divided the blockchain up into smaller pieces that, well, we're far apart and then have interoperability between them. And certainly we've seen quite a lot of sharding projects. So we have a tested hyperledger a few years ago, we have Bishard this year, Chainspace mentioned in the previous talk. Serbers, they all basically say, well, we have a permission chester, we sharded, and we got to make sure that we can do multi-shard transaction processing. And with all these papers, the core there is of course your consensus protocol to operate the shards, but also the communication primitive to communicate between shards. And some of the papers address that all this don't. So we decided let's just look at that problem at a core to see whether it's a different problem than consensus, and if so, how does it behave, right? So our first step was to just formalize it as simple as we could. So how do you formalize cluster sending? We have a value v and we have a cluster one and a cluster two. Those are Byzantine fault-tolerant, right? I fault the replicas in them. I want to send a value from C1 to C2 with three quantities. The replicas in the cluster C2 will receive that value, at least all the good replicas. The replicas in the sending cluster will get some confirmation that they know that sending was successful, otherwise, well, we don't know whether anything happened. And of course, the receiving cluster will only receive a value if that value was actually intended to be sent. So faulty replicas should not be able to forge a message sent to the other cluster and then convince them that that should have happened. And we figured that this is basically the most basic requirements you can get for any form of communication if faulty replicas are involved. So we looked at this, and we looked at it with a very specific stage of a specific angle, namely, we really want to minimize on some of our system the communication between clusters. Because what we found, if you want to have very large scale systems with geo-aware placement of replicas, then of course within region bandwidth and round trip times are not really an issue. And if you use PBFT, but between regions, that's going to be a problem next. So we want to minimize that kind of communication. And this already rules out the easiest solution to cluster sending and that just to do podcasting and that do majority voting. So our next question was then, is actually a lower bound on cluster sending? Is there a lower bound on how many messages we need to send between clusters? And we quickly realize that this is the case. So I will not go over all the proof details, but we're going to sketch it here. So here we have a big cluster with 15 replicas and seven of which are faulty. And we have a small cluster with five replicas, two of which are faulty. In this case, I can claim that I need at least 40 messages. So whenever I send less than 30 messages between these clusters, cluster sending can fail. And to illustrate why that's the case, we started five messages, because, well, the small cluster has five replicas. So if I send five messages, I can make sure that every sender is distinct, and if the receiver is distinct, so that if any of these are faulty, their impact is minimized, right? But I can do that for the other seven messages that I have left, eight messages, sorry. So if I'm going to send 13 messages or less, some replicas will send either several messages or receive several messages. And in this case, there are three replicas that get three messages and two replicas that get two. And we know of all these replicas, two can fail. In the worst case, of course, those are the ones that get the most messages. So, no matter what I do, I can already lose six messages by just two failures in the receiving cluster. Well, if we do that, we have seven messages left, and we have 30 messages total, and we have seven replicas that could be faulty in the sending cluster. So, no matter how I send my 30 messages, I can always pick my photo replicas in this way to make sure that nothing happens. This is for crash failures. You can also do a similar analysis for Byzantine failures, but you're going to have a factor two somewhere. And you can also do a similar analysis if you have a crystal sampling certificate with threshold signatures and that's reduced to this case again. Well, the idea is all the same. And if we completely formalize it, by the end of the line, the conclusion is going to be you have two clusters. We're going to send an amount of messages that's linear in the size of the cluster. And the exact details, of course, depends a bit on the ratio between the clusters, you can have some amount of errors and stuff like that. So that's why the exact formulation has these diff and these small terms. Well, let's just forget about those. Then the next step in our work was, well, we have a lower bound, but that doesn't mean that that's a strict one, right? So we want a nice protocol that actually achieves the lower bound. And the simplest is, of course, if the cluster are the same size, in which case we can just one-on-one map replicas, something between them, and that will actually work out correctly. And we call that bijective sending. We have sketched, well, this is the journal code, but we have sketched working here. Similar size clusters. If we put on all the numbers in the formula of the formation, we see that we need to send six messages. So I sent six messages one-on-one. And no matter how I pick my, well, three-fold replicas in the first cluster or my two-fold replicas in the second cluster, at least one of these messages will arrive. In turn, we can redistribute these messages. Of course, we can then ask, can we do better? Because a linear amount of messages between clusters, especially if your clusters become bigger, that's still a scalability issue, right? Well, the pessimistic person in me would say, no, we can't. We've proven that these algorithms are worst case optimal, but very low guarantees. And of course, in practice, you probably want even more guarantees, so it's going to be even harder. And so whatever we do, we cannot do a better than linear amount of communication in terms of the sizes of the clusters. Of course, we can also be a bit more optimistic about things and try things out to see whether we can make an algorithm that behaves good in practice. But in the worst case, it evolves in something that's linear, right? And one way to do that is to just solidize, use a probabilistic approach. And in that case, we can actually show we can do a whole lot better. So protocol in that case is really simple. What you do, you randomly choose replicas to send from and to send to. You do a step that is a sending step. I'll skip over the details, but that sending step should finish in some finite amount of time, of course. And if that doesn't happen, then we just retry with auto path replicas. Of course, this basic approach. In the worst case, we're going to always pick wrong ones. So this is not guaranteed to finish. But it is guaranteed, but expected to finish actually in a constant number of rounds, typically configuration will take four or five rounds at most. If you want stronger guarantees, we can do that. And that case, of course, we're not going to do just random permutations, we can do some pre arranging of the options we're going to take. And then we do that order and in that case, going to have the same expected case complexity. After you're going to do all the mathematics involved, but it's going to finish in linear time, it will actually finish in a similar number of communication as the optimal approach. So you can have expected case constant and worst case optimal. That's possible. But of course, because this operates advance is going to have a longer latency than optimal protocol. So some, some graphs for performance. In this graph, we have the two probabilistic approaches. So the green line is the one that terminates always in linear time. And the orange one is the one that might not terminate because it's completely probabilistic and as you see, they're quite similar. And the best thing is they cap off at around like four to five message rounds, which is completely independent of how big your clusters, if you have 1000 replicas in your clusters, it's still going to take five messages between these questions. So that's really good. And if we add the optimal approach, well, optimal approach. Of course, I already mentioned it's going to be linear in the size of the classes or very small clusters going to be slightly faster. But for anything that resembles, well, what we look at nowadays like clusters with 10 to 20 replicas already it's going to be slower. Now, of course, in the literature, like I said, there are already quite a few projects that do some form of interoperability between dbt style systems. So if we look at those in a bit more detail than dbt designed a quite interesting, optimistic approach that tries to do it right thing. If you're bbp primers are correct. And if that fails it as a recovery process that's quite costly but an optimistic approach is actually faster than our optimal approach because that's really optimized for the good case. The chain space mentioned in the previous talk also as approach they basically do broadcasting. Which, if you're going to run that in a single data center, it's going to be super fast, because it has just the least amount of recovery of overhead. But of course, if you're going to have wide area network and broadcasting is not the way to go of course because it's going to be quadratic amount of communication. There are some alternatives in the literature of what we did, and some are faster in some case some are faster in other cases. But what we have at least shown is that there are strict limits, and these limits that we've shown at this linear up about is definitely different from what the limits are the theoretical limits at least on the contract of consensus of broadcasting broadcast and stuff like that so it's. It's a different problem. And we can solve it in different ways some of which have benefits others which have drawbacks. We've also already seen some applications of cluster sending and projects. So, I can mention to do BFT was a wide scale. BFT deployment that was optimized for global communication, and that has at its core and inter cluster communication protocol to minimize communication between the local clusters. Well, it's not an approach we described in this work, but it is certainly an interesting approach. And a recent charting protocols that we've been developing, like by short or in BFT, which is the next talk and servers we really put clusters and just as a core part together with consensus and then with these tools try to design a basically database style of sharding so by short shows that you can do two phase commit and two phase locking and that's kind of system servers really try to minimize. Use of consensus and cluster sending cluster sending by abusing and the UTXR type data model, which actually allowed us to skip a lot of steps. We really looked at engineering aspect as how can we actually implement this and make it super fast with a very clean semantics with a very clean transaction semantics that makes sense for normal users that do not want to worry about the complexities of multi-shard transaction processing so. I would say, look at the next talks very interesting. All the works we've seen around the big ones are tested hyperledger. And that's such that it doesn't go into too much detail on how they do communication between charge so I actually cannot tell how they do it. Change space actually specifies a really clean protocols, the podcasting but like I said the podcasting does require quite a lot of communication. That's probably the simplest protocol to prove its correctness so good choice if you want to know for sure that you're doing the writing. Well that's basically all I have to tell for today. If you want to see more information we have. I have the slides with this talk and all other talks related to that on my website we also have two technical reports on archive, so take a look at those. Well that should be it.