 going to be discussing here at a high level. Dr. Wang. Okay, yes, thank you very much, Daniel, for the introduction and thanks Dave and everyone for organizing this meeting. So it's my pleasure to share some of my research visiting for the tolerance protocols and in particular impossible to apply this to published fabrics. Can you guys see my screen? Okay, thank you very much, okay. So I will talk about, so my presentation will be a briefly three parts, what's BFT introduction, and then I will talk about some industry popular, the most popular deployed the BFT protocols for Ethereum and Polkadot, HTTTC. And then I will talk about why we design BDOS and how can we, what kind of implementation we have and how can we apply this to published fabrics, okay. So that's my three part. I will break briefly about this, but I will not go into details. I think I'm sure all of you know that the BFT protocol for computer science was introduced in 1980s for distributed computer system or for tolerance computing, okay. It's a traditional, a business agreement, it's a traditional process of the protocols in military protocols in 2000 years ago, but right now we apply that to computer science, okay. So theoretically after the 1980s introduction to computer science, we know that if there are two bad guys, of course they are malicious, they can't do all things, try to crash the protocol. If there are two bad guys, we have to have a 3T plus one total number of participants to make a thing that we can defeat this T bad guy. So we get a rich consensus. But the most important, these theoretical results, but the most important things about this assumption is that we assume that they are, for every two participants, they have a direct communication channel as the added channel has to be reliable. So that's a very, very strong requirement. Many people when you talk about BFT protocols, they overlook those important things because a communication channel, if not reliable is a synchronous, some things really bad things could happen. I will show you some examples about this theorem. So that's important, okay. So that means if we try to design a BFT protocol, we have to think about the assumption about the communication channel. In particular for Hyperledge Fabrica, we think about the communication channel as an interlet. An interlet is not 100% reliable, okay. So interlet is an open network. The derived service attack, message reordering attack, all these kinds of things could happen. As a consequence, of course, some message gets dropped and some message could get reordered. That's very important. Reordering means if I deliver a message before you, post a message before you, but the interlet could make your message to arrive first. And that totally difference could just crash the BFT protocols. So now we think about, of course, we wanted to design some BFT protocol and we wanted to assume that we use the interlet, okay. What's the model for the interlet? So we can think about two kinds of model for interlet. The first kind is called a synchronous network. That means every person tried to broadcasting his message until the other guy received. But then, of course, we do not guarantee when the message received. If I send you an email today, you may receive that tomorrow or you may receive that in next year. That's all possible, okay. So we assume that interlet will delete. So that's a synchronous network model. That's of course, it's based on assumptions. If our protocol could be secure in a synchronous network, that's perfectly okay because the only assumption we make is that if I send a message, you will receive that. I do not care when you receive that. One year later or two years later, that's fine. But that's too strange. So now we think about a model that is very hard to design a protocol that's secure in a synchronous network. So now we think about a partial synchronous network. So that's a common some model that most people will take if you try to design a secure network protocol or based on interlet. That means that our interlet could be very bad for some time period for five seconds or for five minutes. We do not know when the little work will be good. And then after that, little work will be good for some time period. We do not know how long it will be good. But anyway, so we assume that our interlet is performed in such kind of a scenarios. The little work is becoming very bad. Your message is getting lost. Everything is getting lost. As then it become good. As then it become bad again, it become good. So we wanted to design a PFD protocol that should be secure in this kind of network environment, okay? So that's a bad good, bad good. That's alternative environment. So also of course, if we design a consensus protocol, we have to require three requirements. Safety. Safety means no fork. If you talk about consensus or public fabric, a blockchain, that means we assume that no fork will ever happen, okay? We do not want to have a fork over the blockchain. Our leaflets, the second protocol is called requirements called leaflets or accumulations. That basically means we next block will be produced at some time. We do not want a data log. A data log means the blockchain will stop at certain point. Go to a block, something micro-window system like a blue screen, okay? We do not want that happen. So we want to make sure that the protocol will continue. If late work become good at some point, the next block will be continually because it should be produced. That's the basic requirement. Long trivial, the third property of the long trivial means you can always produce the empty block. So without a content, that's trivial. But we want a blockchain that has a consensus that means the next block will be produced at some time and that block is not empty and also no fork shows up. That's the requirements for us to design BFT protocol or consensus for the blockchain. Of course, we assume that these kinds, three kinds of things will happen if late work become good and late work become bad in some points, okay? Oh, what's that? No, I think some guy tried to control a screen. That's something, is something wrong? Okay, so, okay, so, okay, I'm sorry. So someone tried to control a screen, okay? So let's talk about some protocols like this. We know that Ethereum has converted to proof of stake just in this year. And they use the BFT protocol to capture friendly finality gadget, FFT, okay? Essentially, they're based on a block. So the block is of course, everyone can produce these kinds of blocks, like forks. Forks, all these kinds of tree will happen. But we want to make sure the consensus layer want to make sure choose the one path. Our blockchain will only one path. In order to achieve that, so everyone who has a host, they can try to vote, okay? And vote means you cannot vote in this area. So if this is the next block, you cannot vote this and vote this. If you vote that, you will be slashed. Your stake will be taken back. And you cannot vote this. If you can vote this, and you can vote this as a straight subset, you cannot do that. That's only two requirements. As in this Ethereum blockchain, you do not, it's invalid vote. Any other kind of vote will be valid. Or you are not allowed to do this kind of vote. If you do vote this, your deposit will be slashed, okay? So that's formally the specific part in this way. And then normally, because I told you that this is a petition of block chains you have. And we want to vote to find the one, the valid block chains we want this. In order for this chain to be valid from all the folks, we have a super majority vote. Super majority vote means if we have a 3T plus one participants, you have, we have to obtain 2T plus one vote for every name, okay? So that's it. So that's a very simple PISAT-info tolerance protocol for Ethereum. But the important things as I've mentioned, there are some things I'm using in that kind of protocols. There is no specific network assignments. What kind of, no specific little assignments, okay? So what's the little models that you want to talk about? They want to be asynchronous, but that's not happening, okay? So anyway, so there are some kinds of things. There are many, many things that are not, they are not available there as a missing there. But we found out, so let me try to give a very simple attack on this protocol. And my only assumption that in order for me, if we want to, if we want to attack this protocol, how can we do it? The only assumption I will make is that I can choose a message delivery system. That means essentially, assume that I'm the guy can provide internet service to, for some, for US government, for, I'm not US government, for US customers. And I have access to infrastructure. I can read all the message. If your message posted early, but I can make that your message appear in a second. If I can only do that kind of reordering, I can make the Ethereum just completely crash. Crash means didn't lock. How can I do that? So assume that A is the last finalized block. So that means it's finalized already. And then we try to, B is also the next block, okay? No, if I got some, because everyone tried to produce blocks, and C and D are two partition blocks that have been produced after B. So that means that to be full. As the committee needed to reward, which one, the BC we should take or BD we'll take. But the bad guy, because it controls the network environment, I can arrange C and D to be delivered at a different time to different nodes. That's our assumption. The bad guy controls the message to deliver the audio system. If I can control that, I can make that cheap. The C will arrive, cheap good guys first. And the D will arrive at a cheap plus one good guys. And then the bad guy will run deliver. At the end, so we will, C will get a cheap plus one volts. A D will get a cheap plus one volts. That means no one can make a decision on that. No, that means they have to continue again. And then it means that C and D, E is produced at next block of C and F is produced at next block of C. Again, I can arrange E at F to be delivered to the nodes at different times. After that, I will get that E and D will arrive. This kind of process can continue forever and no one who knows the Ethereum network can never produce next block. That means they don't, okay? So that means on this assumption. So we want a good BFG protocol should not allow this kind of things happen because we can assume that the bad guys can do all kinds of things, okay? So because the FFG is not perfect for Ethereum, they are trying to develop a next generation of the consensus protocols for the Ethereum block chains. And that's called the cast the friendly binary consensus or FBC. I will not go into details on this, but the idea is simple. If I receive some kind of message, I will not make a decision. I think which block has high probability to be finalized in next, as they avoid. I think I have a function called prediction function or score function. Then I try to vote for the next block and then after this kind of vote, I can make a decision. This is my estimate for next block, okay? If I think zero has high probability as one, I will vote for zero. If one has high probability, I will vote for one. So that's the next potential generation for the... So next potential generation for the... Can you hear? I think something's wrong, right? No? Can you try to share? No, who can hear you? You can hear me, right? Yeah, you're... Okay, okay. I see, I'll close off. I'll turn. Can you share your screen? Oh, okay. My screen is shared. Yeah, can you try to share your screen again? Oh, why is the block, someone keep me out, right? Okay, yeah, thank you. Okay, so essentially in the next generation of the Ethereum BFT protocol, they think, oh, why is there something? Okay. So essentially, if you think, oh, I think someone controls my screen, right? Okay, so, okay, anyway. So if this happens, we try to see that they will predict A or they will predict based on the prediction, I would vote for zero or one. That's as they... After some kind of decision, they will make a decision which one they will use for the next final block. But we can show that I easily see that I can show that if you can do a message reordering on the infrastructure level, try to reorder the message that has been produced for the Ethereum network. So essentially reordering means if the next block is produced, different people produce different blocks. And then we try to... I can schedule which block to arrive to reach which person first or second. If I can do that, I can show a similar attack that Ethereum can never reach the next block, can never produce the next block. So we have tried, based on this, that means it's not secure. We have designed some kind of protocols based on blockchain reliable protocols in the network. We show that this could be achieved, could be make the Ethereum block secure if they want to use our strategy to do that. But that's not to some extent. They have a different network model. I will not go into that. And I have done some analysis on many, many different protocols for the blockchain in the cryptocurrency in particular. So I'm sure the ground part as a polka dot is a lot of popular cryptocurrency we know as their PFT protocol is ground part. And they use different models to define that. I will not go into the details of the protocol, but I can share you that I have two kinds of attacks. I can do a similar attack by reordering message. If the two blocks are produced for next partition block, I can make that one block arrive at certain person at first or so one protocol reach another person some other nodes first. If I can try to do a schedule on that, I can make sure that the ground part will never produce the next block as they did not there. So I have two kinds of attacks I will not go into details, okay? So now let's talk about, so that's the different things I saw that if you try to analyze many of the cryptocurrency or blockchain consensus protocol, you will find out you can notch a lot of attacks and it certainly means they will not reach the three requirements, safety combination of these kinds of properties. So we want to make sure why we do not use these best practices in the academic to try to design a protocol that is theoretically secure and I have a mathematical proof, no matter what kind of attack you do, you can reordering the message on the interlator, you can do any kind of attacks. I can still, the only requirements for my protocol to work is that interlator will be good at some period and will be bad at some period. So if the interlator becomes synchronized at some period for some time period, our protocol will work. So that's only requirements that we have and all other things could be mathematically be proven that are secure. So let me try to talk about BTOS protocol. BTOS protocol is essentially it's a blockchain version of the DLS protocol. DLS, I'm sure I'm not, you may or may not know that DLS is one of the first protocol in our history based on the partial synchronized networks. It was designed by three persons, DLS and three laters, okay? That's they got a lot of the tuning award as some of some research. So these are just a blockchain version of the most famous DLS protocol. So I will wish I'm introducing to the half-legged fabric, okay? So first I want to just to give an example use this example to show how BTOS protocol works. I think I will give a formal definition and what the challenge I have. But I think if you can understand my, this four notes examples, you will understand how BTOS works, okay? So we have assumed that the four guys, of course this kills each of this bad guy but of course it's a bad guy, only he knows he's bad guy. No one else knows that. In the first round, I assume that the mini is a lead dog. We have a lead rotation dog. Everyone will send the mini, what kind of block they have. He said, okay, I have a big, there's a big message said, okay, I have a B4. This guy, Miki said, okay, I have a B3. As this kills agency dog, I have a B4. I need a mini C-dog, I have a B3. And because no one, you said that B3 get the two volts, B4 get them two volts. That means there's no super majority. I said, okay, Miki said, okay, I cannot reach an agreement. I cannot make a decision on the consensus. So, but the best block I have is B4. So I put post message, broadcast message called B4 to everyone, okay? So that's all I can do. I cannot make a decision, but I know from my knowledge right now, I know that B4 is the best block we can work on. After that, because the meeting's job is done, so this B4 message becomes a leader, okay? Then I mean everything, a voting process will restart. So everyone we are seeing that here's the best block to the B4 message, okay? So Miki has B4, a B4 message has B4, and Miki has a B4. And then of course, this guy, always a bad guy. He tried to use all the products. He tried to send B5, no. But this time, he got three good messages. That's the super majority, okay? Three B4s. So even B5 is much better than B4, but we want to reach agreement on the majority. Well, we do not care about this best block there. So that means because, okay, the big message said, okay, I found a super majority agreement on B4. So he asked everyone to knock that. On knock that, you can always think about this. In our real society, we all think let me put this B4 on ballot. So let's put on ballot means in next step, you cannot vote anything outside the ballot. You can only vote the blocks are put on the ballot, okay? That B4, knock that. After knock, that means let's work on this ballot system model. B4, everyone will commit or something, okay? So these good guys will commit B4, B4, B4. But this is bad guy, he will commit something different, B3. But anyway, for this, because everyone can get a super majority for B3 or B4 are committed, okay? That means the baby master is a good, good guy. We have very, very good news. So B4 has been unanimously, not unanimously, has been approved by the super majority. So that means your broadcast decide B4. That means B4 will be our official next block. So that's how the system works. Now we say that if we have three participants, we cannot reach agreement, okay? Again, we have three participants, the baby master, this is a better guy become leader, okay? Everyone said, I give B3, I get B4. He said, I have a B3, B4. And then he said, okay, please knock this, let's put B3 on the ballot. He will tell us this guy put B4 on the ballot. He will send a different message to different guys. So that means he will think he will take on vote before B3, but he will meet for B3 before baby master. But he will vote for both B3 and B4 at the same time. So he would commit B3, he commit B4, and he commit both B3 and B4. After that, he said ask the Mickey to decide on B3 and ask baby master to decide before because he can't decide both these things. And as you know that if we have only three participants, obviously, so this better guy can make the system work in such a way that Mickey and baby master, they are all good guys. But they agree, they think the next official block will be he will think B3 and he will think B4. That essentially means the system will not work. The system will not work. And we call the fall, that means the system does not work. So theoretically, so we have a very detailed implementation level description of the videos protocol. I will not go into details, but the principle is very similar to what I have described here, but it's mainly some things that try to glue this kind of details, mathematical details. We have to describe that in the mathematical detail and try to give a mathematical proof. So if you have an interest, you try to read the papers, but I will also go into detail about the description of the protocol. Next minute, let me try to do some kind of comparison analysis, compare our protocol with other protocols somewhere over here. PPFT, I tend to mean the liberal BFT, all the hot stuff, the liberal BFT is related to hot stuff, you know that. So we know that this method means this is a communication method we have done. And how many rounds do we have? You know that PPFT of course is that means, so this is a leader broadcast. So what's every step, who do you want? So this is a simple called the leader broadcast. This means all participants send a message to the leader. Leader try to hear, to hear you give the air. So that's how you use this symbol. And this means everyone try to broadcast. Everyone want to try to broadcast to everyone. So this is essentially PPFT, you see that it means first the leader broadcast, and then everyone broadcast, everyone broadcast. That's three steps, that's PPFT. And message communication tune plus, tune plus, tune square plus n, and n is a number of participants. And awesome to gain from me name. So this is 10 minute PPFT, similar to PPFT, but just a little different because this is a, you see that this is a reduce, this is a, there are some differences, PPFT. A liberal BFT or hot stuff, there are same steps. So it's not, so you can think of that as a mesh network. This is a star network. Star network means only a leader broadcast everyone send the message to leader. Is do we do not have one everyone broadcast to everyone? Because everyone broadcast to everyone, we will get a n square message communications. That's a lot. So that's why we, for this liberal PPFT or hot stuff PPFT or BDRS, we reduce the message communication by avoiding this everyone broadcast to everyone, okay? But we have four steps, but the liberal PPFT has seven steps. So that's an advantage of this. Of course, liberal PPFT, they try to achieve some kind of pipeline protocols. That may or may not happen or may not help. It really depends on people to compare that, okay? What's our advantage? But at least we can do that in four steps. We think that's a good luck. Our experiment, experience shows that that's good luck indeed, okay? So we have implemented this in the, using a good language or good program language. And the code will be available from micro GitHub or from the habillage lab, BDRS, lab of the GitHub, okay? So we have implemented different attack scenarios, message reordering, all different kind of attack scenarios and also delete the message. Some people do not malicious attack all these kinds of things. And our simulation says that with our simulation, we have done this in the Linux machines with 64 gigabytes of RAM as this kind of things. This is the configuration, it's called configurations. We know that if we have 20 nodes, it has 1.48 seconds to reach agreement. If we have 100 nodes, we need four seconds, 4.7 seconds to reach agreement. I can tell you that essentially, so that's important comparison to this. So why pipeline we may or may not work from Libre BFT that's advantage or not? Because the reason that we found out for the 4.7 seconds essentially, the major cost comes from the signature verification, okay? So it's not really about BFT protocol itself, DNA. The major complication comes from signature verification. No matter which protocol you use, the signature verification has to be done. So that's the major cost. But if we do not think about the message verification part, all the consensus can be done in one second. So that's, I think it's a very important if we try to deploy this in a blockchain, it's very important to say that what's the practical environment and what's the most expensive part and so that, okay? So, and also, so not the next, so we have, so this is a code has been, BDRS code, core consensus code has been tested and tried very carefully. So everything works perfectly, okay? So we wanted to show that, how can we try to integrate this into habliage, okay? There are two particular ways because right now the habliage fabric uses a raft consensus, okay? So we think about one particular easy solution could be, we try to repact the BDRS implementation to provide all the interface that the raft has such that it's easily or seamlessly to integrate habliage with BDRS. But that may not be the best solution. I think the best solution could be, we try to approach to, we try to directly try to write some interface to interface habliage fabric with BDRS, okay? So that's a petition of two, okay? So we want, right now we are looking for some volunteers who can contribute any kind of contribution strong welcome. So we can work on this as soon as possible, okay? So if you wanted to know the reference, I have all the reference available from the, that's the paper that you need. I think we have shared with you as this is a 2019 version of this early version of this, as they get hab implementation there, okay? So that's my discussion here. Certainly I wanted to emphasize that we have developed the BDRS protocol. That's, it's a blockchain version based on most famous DLS protocol. DLS protocol is the first ever protocol in our academic history that has been produced for the partial synchronous networks by three guys, bigger guys. I think it's three of the DLS, two of them has got plenty of water, okay? So it's a very good protocol, but we try to revise that to the blockchain so that it works with the blockchain. And it has a mathematical proof it works perfectly. And also our implementation experience shows that it's robust against all different attack scenarios. Protocol itself is a very good reliable, but the only expensive part is very significant verification. But for all kinds of consensus protocols, we have to think about, significant verification is mandatory. And it depends on how many nodes we have. Even if we have 100 nodes to do the consensus, we can reach a great, produced every block in five seconds, okay? In a very, very, our little simulation, we assume that traffic is from your pink country to US all across the globe, okay? So we delay all the delay model we build, okay? Okay, so that's all my presentation. Thank you very much. I think the next perhaps Ahmed will present and after that we can go to QACS or Daniel. So what's your? Yeah, thank you, Dr. Wang. Appreciate your presentation. I guess we'll save the Q&A at the end of this event and we'll pass the floor over to Ahmed. But before I do that, I do want to apologize to everyone about what happened earlier. This is the first time that it has actually ever happened to a hyper ledger event. David and I just spoke about it and it has not happened to us before and we're embarrassed about it that it happened but we'll take extra precautionary measures to make sure it doesn't happen again. So with that said, let me go ahead and go ahead and take some controls here. I'm going to make sure that no one is able to start their video and also going to make sure that no one can unmute themselves except for the presenter. So just give me one second here and I'll go ahead and do that. Ahmed, are you able to unmute yourself? Go ahead. Yeah. All right, floor is yours. Appreciate that. Thank you so much. We'll start quickly as we run out of the time. But to continue on the title of this presentation which is VFT consensus for blockchains and hyper ledger fabric, basically it's mean DLS for blockchains and DLS protocol for hyper ledger fabric. So in order to do that, let me just like to use the production relic for myself. My name is Ahmed Saleh. As Daniel said, I'm a senior sort of NGN3 tech lead with a whole delays. Also, I'm a PhD student working with Dr. Yong Wang at the University of North Carolina, Charlotte. Let's have some hands on cards. Run the protocol. I have all the commands that you need to run the protocol or for PDLS as standalone. We'll take more advanced work later on. So I already called the codes. Let me see the time. Yeah, I'm not gonna call it again. So basically I called it a work space. I bought it within the CMD and MuCon. Then we'll start just like spending some machine here. And we see how they communicate. So MuCon. If you wanna see how you can run the protocol, you can just pass the help flag to see the available commands and parameters that you can pass. For myself here, I'm just gonna pass the ID. I'll start with ID zero. And I will pass the lesson to specify the part that I want the protocol to run on. Let's just say zero. In the meantime, I wanna spend another machine. Sometimes when they get bashed, like it's not allow you to write, just like type preset to reset the session. Now, it's all the issue. It's recently, it's happened to me. Let's see one, let's see one, let's just say this one. Spend another machine about a click. You'll notice here, once you spend the machine, another second machine, the first machine, knowledge that also the new node is notifying you that it's joining the network. That's my share of the quick. I can share with you guys later on how we can contribute and make that success. So now we have like four machines spinning on that network, communicating among each other using the PDLS network. We'll see the rounds going on. Here's another test that we can run. But for the time being, I was planning to present it, but you already have it on the slide. Any other data they will share with you. Just go to the root folder of the consensus and you spend that comment. We'll keep them though, sure running while I'm continuing on the presentation. We'll be here real quick. Now I'm gonna talk about the BFT consensus for blockchains in general. We do have some implementation called PDLS chain. The code is in the PDLS organization which is far from Dr. Yong Wang as we create some organization for the PDLS itself. So people can far, can contribute. Also I put the implementation for you guys to give it a try. Basically it's on Gath network which is the implementation of the Ethereum network by default that count is locked. I put some various way to unlock that count using Gath or using the web three. I'm gonna jump to the second part which is the main purpose of this demo if we can get that success. So give it a try on Hyperledger Fabric to integrate the PDLS protocol. For us, David, after the real share, the PLS already being hosted on the Hyperledger lab. We contribute, there is, I create a couple of forks, the expected repos from Fabric that we think that we need to touch to integrate the PDLS to Hyperledger Fabric. Also there is a session open for the Fabric project on PDLS. And there's also a couple of issues that we believe this is like what we are really need to do as initial steps to integrate the PDLS Fabric. Discussion please feel free to add your awareness if you think what route that we need to take if you have the expertise on raft on Fabric, that will be awesome. The default of branch of the Fabric that get worked from Hyperledger Fabric which is 2.3, I name it's PLS release 2.3. Also there is another branch based on 2.4 since we have the getaway over there like I just like when I say take a step on the back to give it a try on 2.3 first. Discussion is up and running, issues bored also for you guys to pick or to add or responsibility. It's open so you can fork it on submit your requests. Also we do have PLS since this community call which is every other Thursday, the next one will be on 22nd. Go through the link on the chat. There's also Discord channel for PDLS on the Hyperledger Discord server as well. Let me send the link the chat for people for their concern to join the community call. And of course like you can contact me I will through also my contact information. So whoever like having the expertise and passion to contribute that project are welcome, everybody like really good opportunity. My email, my GitHub account, my LinkedIn account. I'm gonna hand the podium to Daniel to wrap up the sessions. Any question regarding PDLS, we're glad to have Professor Hongguang here. And thank you Hyperledger for your attention. Appreciate your attendance. Great. Thank you, Ahmed, appreciate it. For anyone who is wanting a copy of the presentation, please reach out to me directly and I can send you a copy over email, the PDF version of it. We're gonna open the floor up, we have about 10 minutes. We're gonna open the floor up to all the participants for any questions that they might have. Go ahead and unmute to allow you to unmute yourselves. So yeah, please go ahead and jump in, ask your questions away. I know that there were some questions on the chat. So please go and verbally speak up if you want. Yes, thank you, Daniel. I saw a question, I think Peter has asked about how we try to scale to 1,000 nodes. We have nodes to be honest, but we can't, obviously we can't try that, but we, because we do all the simulation on a powerful computer, we have not done that. But you are welcome, we can do that, thank you. Okay, any other questions out there? Thank you, Larry, Taco raises his hand. Some question, can I unmute to him? I think there was a pretty good comment up there too from a Taco One player, or a Player One Taco. So let me go ahead and read this real quick. When there is a fall from communicator, is there a mechanism that either removes that communicator for an ever-increasing time in parentheses, resulting in some penalty, or slashing or even reducing the weight of that communication results? Not looking at the fact that leader is a bad actor. How does your system allow one agent to commit or transmit slash lot more than one choice at a time? Would it not be better if the system only allows one choice, even if it is the wrong one? Yes, I think so some of the, so of course we assume that the leader could be better guys, of course. If the leader is a better guy, no agreement would be reached, we have some, so that's interesting thing I can talk about is some academic papers, some discussion of PFT protocol. They talk about the wrong synchronization. They just assume the wrong synchronization is trivial. It's easy free, but if you check the liberal PFT, when they try to implement as a whole to stop liberal PFT, they find it's very challenging to do wrong synchronization. To be honest, the wrong synchronization is a lot of PFT protocols. So that means we have to make sure our implementation addresses the challenges, that you are right and so leader is bad. So he will be, after some wrong synchronization, after some time delay, he will fail and then we will transfer to the next leader. We assume that some leader will be good. It's always possible the leader is bad. And we assume that consecutive leader one, leader two, leader three, that could all be bad. And we hope that when the leader five is a good guy, a leader work is good, at that moment they will reach agreement. And we have a mathematical proof we can achieve that. Thank you for that. There's another question here. How many transactions per second did you observe when running performance evaluation? Do you have a formula for scaled time? Those are two set of questions. Yes, that's a transaction per second. That's a different topic because we only think about the consensus, okay? So if you try to talk about design block chain, the transact, or you can see that the transaction could be in which layer, layer two or layer one, and all you can see for that or not. So we do a lot of exactly see that, we do a lot of claim the transaction per second because it really depends on the block size and the computing power to verify all this block. So it's a, for different block chains that have different systems for that. But we can see that if we have, my picture show you that if we have 10 nodes and 100 nodes, that's how much time we can reach agreement. We assume that the transaction is verified by the block, by the block producers, okay? So, but I also also want to make sure to say that it's also where it depends on the signature verification process. Our experiment show that it's the most expensive part for the delay is not about the transaction. It's about the signature verify. If you have 1000 nodes, you have to verify 1000 signatures. How much tickets for you to do that? That's essentially the major bottlenecks for you to produce the consensus. So the consensus is not really from the block chain, BDOS protocol itself is, if the larger population it is, it comes from, you have, no matter which BDOS protocol you use, you have to verify all the signatures. That's, you cannot avoid that. So it depends on how fast your signature scheme it is. Thank you. Great, thank you so much. Any other questions? I guess we have one more question here. But you had a slide about integrating the library into fabric. So did you have any performance evaluation of the fabric integration or not? Not yet. We have a plan to integrate into your fabric here, but it's not functional yet. So we were not able to test that yet. Thank you. This is a contribution that we are willing from you Yakov to contribute to get that evaluation on the order of service. This was a good event. Any other questions? I feel like this question's kind of slowed down a little bit. Oh, okay. There's another question here from player one taco. Have you thought of multi-layer transactions, settlement separate from execution with a consensus finalized as block seal? Yes. That's a perfect, that's a very good question indeed. So I think so that really depends on the blockchain design. I think that we were thinking about consensus as what you have mentioned as a time at block sale. So that was, I think there are some cryptocurrency blockchains that are trying to do that. The data availability to separate the data availability at consensus. The role of consensus is essentially just to be a timestamp or a sale on the blocks. So in that case, because block transactions are at different layers. So it's only things are BTO as consensus protocol. The only time you need, how often you can finalize a block depends on how fast that you can verify all this 100 or 1000 signatures. So if you can verify signatures, the BTO as protocol itself takes minimal time in that part, thank you. Okay. Great. Is it okay if I ask him to contact me, Phil? Dr. Wang. Okay. There's some people trying to see if they can contact you directly. Is that okay? Can I provide your contact information? Sure. Feel free to share our information and information if someone want to volunteer to contribute. Thank you very much. Okay. I will provide your information separately to these members. Okay. Another question here, since we got a few more minutes, would it be possible to generate a master signature that would be generated when 1000 signatures and use that to speed zone transactions? Speed zone transactions equals a city and parentheses zone. Yes, that's, it really depends on what kind of crypto signatures we want to use. There are some very efficient ones, but it may not be popularly accepted by the community. So we, for the community, for hyperlinked fabric, I think we have already some kind of signature schemes right now. So we have to use that, unless we can change it to a different signature scheme. So, but the faster signature scheme, the better, okay, reduce that. But I think even right now, if I'm not sure of the hyperlinked fabric, normally we need homely blocks, homely nodes to do the consensus. If 100 is a bigger, is a normal size, I think five seconds. This scheme, that's fine. So, yeah, thank you. Oh, Moco, some are asking about similar to the Moco root tree. Yeah, that's good points also indeed. So, yeah, that's good. We have tried to do that, but the details can't be implemented, can't be optimized. If we want to use kind of pipeline ideas, that's what you're talking about in Moco root trees. In that case, my experience, let me share my experience, okay. My experience is that depending on this, so how often does the hyperlinked fabric have produced a fork? If the fork is produced very infrequently, then the Moco tree that come to the logic or pipeline could significantly improve the performance, the delay. So that means significantly. But if the fork is produced more frequently, the pipeline technology or Moco tree may not help because you have to deal with all these kind of forks. That pipeline will waste a lot of your time in implementation. Thank you. One last here. I read a paper about scaling that forgets about branches on a merkle. So that is that it is there, not explored by other nodes unless it is needed. Sort of like hidden map. Yeah, that's always possible. We have a lot of time on that around knowing that PTOA's protocol implemented. That's implementation-specific, optimization technology for the PTOA's. We have a lot to try that, but that's certainly be very important. If you like, we can contribute, we can have a discussion sometimes we can think about that work. Thank you very much. If you have more interesting, continue that kind of implementation with me. I think that I will post my contact information and also talk about the contact information. We can have some meetings, separate meetings to discuss specifically for that. Thank you. Okay. Well, we're right at the thought. Thank you everyone for joining. Appreciate all the good conversations, good input, feedback, and the questions. So it looks like everyone really enjoyed the event today. Thank you again to both speakers here, Dr. Wang and Ahmed. Thank you so much. And we will connect with you again next time. And Ahmed, Dr. Wang, you'd like to connect with you after the event. So there should be an invite coming your way shortly. Thank you very much. Thank you, Daniel, for organizing this. And thanks for all the audience who come to participate in this meeting. Thank you everyone. Thank you. Yeah. Thank you. Thank you. Thank you. All right, bye.