 Okay. I think we can start. So, hi. Good afternoon, everyone. So, welcome to block hash live 2020 session consensus and the consortia know house with Mr. I don't SM. So, I just wanted to let you know that this session is being recorded. Also, the session is conducted in collaboration with type ledger Kerala and coaching communities. I want to welcome our speaker today. Many of you might already know him for those who don't know him. Mr. I don't SM. He's a senior software engineer blocking platforms at Walmart labs. That is his day job. But he's a man who has many hats. He's a hyper ledger TSE member and co lead of hyper ledger India chapter is a maintainer of the hyper ledger sort of project. He's also a co organizer of hyper ledger Bangalore meetup group, etc, etc. So, we are very happy to have him for this session. So, I would like to welcome Arun on behalf of everyone here today. Over to you, Arun. Thanks, Sean. And hello, everyone. Good afternoon. So, I would like to keep myself. It's simple. You could call me and then thanks for that quick introduction. I skipped this part then. I will quickly brief about what is going to be covered in today's session. Right. So I kept the slides to be more simple to understand. And if required, we'll go in the to understand what each of them mean, and feel free to notify me at any point in time. We'll then debate or those slide or those concepts and then understand how things work much deeper. This content was prepared for to help both beginners as well as to those who already understand what consensus is to think differently when they design the application systems. So, this is how we structure for the next 30 minutes will understand what consensus is and why does it matter for blockchain. And we'll also understand what does consortium really mean. And do we really need consensus in consortium and how is it handled. Then we'll go on debating on few of the points, which we which we may come across when we design a blockchain solution to understand is consensus algorithm really playing a role in making a decision or not. Leave with some open questions for you to go back and debate on those things. So, first, what is consensus. What is consensus algorithm really mean. So what do we understand by consensus right so in in practical in reality, we may see this kind of issues everywhere whenever there is a whenever there is a group whenever there are a set of organizations are for any column for that matter. A small group of people, if they want to agree upon a particular topic, they follow some process they they all agree. They all start debating foreign arguments topic and then they agree upon it, or there could also be a process for agreeing upon a particular topic. For example, in our parliament elections, we do send our elected representatives and then they go on debate in the parliament and make laws, which again we will follow. So that's a that's a process which they follow. And similarly, in any distributed systems when we think about a distributed system, we need those machines to agree upon some data point. We want those machines to know what other mission is talking about. And that's where the consensus algorithm really play a role. And where do we see consensus algorithms in reality, you will find this. In fact, you, you are using this even now to be on this call to provide high availability of the streaming service. Maybe the streaming service provider is using consensus algorithm behind the scenes, running on their set of masternodes. And it's also being used in Kubernetes, which is widely used deployment platform and then it's also used in let's say your cloud RDB MS database systems. It's used in a clock synchronization is used in load balancers. It's actually used everywhere. It's not something which is new only for blockchain. But this is some, this is a concept which is there in place for a while now. And what is consensus really main in terms of distributed systems. What it means is, we want our system to be available, and we want our system to continue as expected, even if there are some failures. Let's look at what the failures really mean, which I was talking about. So, in terms of availability, as I said, it's used in Kubernetes, it's used in load balancers. So consensus algorithms are widely adopted. And why do we use it in Kubernetes? We have set of masternodes. So these are the nodes which decide where a particular workload is going to be deployed on. And now when we have multiple people with equal powers, they all want to come back with each other and then they all may end up with different decisions. And how do we know which decision to abide by? That's where Kubernetes follows HCD raft as one of the consensus. So in simple terms, what we need to understand about a consensus is that we want our system to be available all the time. And when we say our system is available all the time, we are really talking in these two broader terminologies. We are talking in terms of a particular node crashing or going down randomly because of some reason which we don't know. And then other reason could be that we are really talking about a bad behavior in the network. It could be that a particular mission is not able to handle particular floating point numbers. So it's not really intended errors which we expect in our result. Or it could be as vague as a particular node is really malicious and then they are trying to come up with a wrong response. I mean in the consortia or in the network. So what we need to understand, we can classify these consensus processes into two categories. One which we can put them under clash fault tolerance systems. So these are the algorithms or mechanisms which provides the solution to the first problem, the availability problem. As long as we have, depending on which algorithm we follow, as long as we have specified number of nodes up and running, we have our system available all the time. And when we talk about BFT, Byzantine fault tolerance, by the way, that term Byzantine comes from one of the Greek. So it's really interesting algorithm. It takes its own separate time to discuss what that Byzantine general problem is. I would suggest you to go and research more about it. And within that Byzantine fault tolerance, it could be intentional or unintentional behavior of involved party. So now that we understand what consensus is a quick recap of what blockchain is to understand how why are we even talking about consensus and a blockchain conference. So what is blockchain, blockchain, I would put in it, I would put it in these three words, it's a distributed system, it's a decentralized system. It provides us immutable ledger of records. So at its core, any blockchain would some way or other, it provides these capabilities for us. And in addition, of course, there are things such as smart contracts, which will help us in verifying if all the, if a certain rule, which is set initially, they are made properly by all the participants when they send transactions. So I would not categorize I mean I did not catch them up in the slide rather I just put them in these flow in this flow which you see on the screen. So in Hello, Arun. Use this as a legal proof and we can also stop some malicious behaviors if required behind beforehand. So these are the things which we generally do in multiple blockchain platforms they enable these capabilities through different means. Everyone could do it differently when compared to Hyperledger fabric and saw tooth can do it differently from basic. Each of them have their own mechanism of handling this getting this done. Now that we know what blockchain is and let's try to see what is consensus in blockchain really mean. This has been a debate question for at least the beginners of blockchain technology who think that consensus is when you might all have already been heard about mining in Bitcoin or mining in some other ecosystems like Ethereum. So what is, what is consensus and blockchain really mean is it just a mining. See the slide I put that crossbar on the minor person. It's supposed to be taken as it's not only mining through which we can achieve consensus in a network. So mining is in fact one of the way of achieving consensus. But when we think about enterprise blockchain applications, we really don't consider mining as one of the things. So what do we achieve with consensus in any blockchain network. We achieve in any blockchain network we want those features those capabilities which we just discussed in the previous slide to be enabled. And mechanism through which we provide those features are things are is by creating the blocks. So various consensus really involved in a blockchain. In this light, I'm giving you an impression that consensus process is involved to create the block and to commit the block. Okay. So we will, we'll come across few examples of how the creation and committing works across different blockchain networks and what options do we really have. But in at a broad level what we need is we need one person responsible in the network who can take who everybody in the network agrees upon to create a block and block has list of all the transactions. It has list of transactions which everybody agrees upon that's a way of getting consensus. So let's say a client sends a transaction and then a node receives it and then they are, they don't know if the transaction is successful or it's should be accepted. What do we do with that. So that's where a smart contract would run and then there is this whole process of consensus algorithm which runs and it determines whether the transaction is valid or not should be considered as done or not. Everybody so that everybody in the network, they are on the same page. Let me move quickly to the next page. So in coming slides I'm going to discuss quickly about to broad cat to other categories of consents achieving consensus. Earlier we saw that we could classify consensus as CFT and BFT crash Byzantine fault tolerance systems. Over here. I'm now going to discuss them a little different in a little different manner. And Nakamoto style consensus algorithms and I can categorize the others section as far as finality based consensus algorithm. So what does Nakamoto style consensus algorithm really mean. So these are the systems which are proof based right so if any person in the network wants to create a block or wants to say that this particular transaction is valid. Everybody should consider this transaction at this point in time. If you see, I mean if you see a blockchain network, we really talk about blocks and we also talk about position of the transaction in a chain. So we need to know not exactly we not exactly not only create a block but we also put that particular transaction in one particular block in our chain. So that's a guarantee that anybody with that particular block with them, they agree to that transaction. It's not that they skip that block. One person can have the transaction in block one other person can have that same transaction in block two. No, that is not how a consensus is achieved because every transaction could change the state of the system underneath. And blockchain is of course a state full set applications like so within Nakamoto style as I said it involves some kind of proof to be produced so that they claim to be owners. It's kind of passive consensus or it's I would put this as eventual consistency which is achieved through Nakamoto style algorithms. What that means is there is a possibility that initially even though a transaction is accepted. Maybe that's that's the only node in the network which thinks that a transaction is successful. Maybe everybody else they also think the same way with other transactions and only when this subset these two different subsets they talk to each other they come to know. Okay, so other person did a better work than me. So the other person deserves to be a creator of the block. So that's why the proof is proof is required and coming across different proofs that are proof of work proof of state proof of a lapse time. And there are again a number of variants of of it right including proof of stories proof of. So there are even algorithms which would show hey this is how much compute power I have kind of consensus algorithms. So many things to take away are being highlighted on the right side such as these kind of algorithms are susceptible to 51% attack. Like if you are a majority holder in the network, then you get hold on to the network completely. These generally also come with some some limitations because of its eventual consistency in us. So it is possible that the throughput or expected number of transactions may not be agreed upon as quickly as we want them to be agreed upon. And the other category I was talking about can be categorized or put them under first finality algorithms. And what does this mean? This means we want immediate result on a particular block. We want to know if a block is accepted by everybody or not immediately right away at that moment in time. And again, there are multiple algorithms in this section I just highlighted to often for a quick reference. Like for example in PBFT there are it follows a step by step approach at each step. For example, it starts with prepare prepare and then commit those transitions and then there are views involved. So what that means is let's say let's say you have a time-slotted work hours. So a node imagine that node is a worker and node has time slots and let's say a node wants to work in a node members agree for it. Then yes, that particular node becomes leader for that view that you could consider. And in that term again, it's not that the node which has won the election has complete authority. It could be implemented in a way that even though the proposer is sending transactions which are to be added to the block. Others in the network they do have a say whether to agree for the transaction or not to agree. So that's how the malicious behavior can be caught. And that there's a requirement that we need at least two thirds of the network to be up in PBFT consensus. And of course raft is a well known algorithm, which is also used in multiple other distributor systems as I said any initial slide type initial slides. And now that we understand I'll go it consensus algorithms and some extent to some extent. Let's understand what consortium is. So, so this is the definition which we can find on the internet that what consortium means is really a group of members trying to do something to achieve a known result. Why does it matter for a blockchain project or blockchain solution. So when we think about blockchain, we are talking about multiple organizations coming together and helping to build something which will help each of those organizations indeed. And when we have multiple organizations, there will be multiple things to be there will be multiple things which need which are needed to be taken care, such as those organizations need a legal framework around. When to call for a transaction or not, or you didn't just need a garden and structure to know who else they should agree upon to join that network of those initial notes. And they all they may also request for a way to know what kind of transactions that can be submitted in terms. But they may not necessarily go hand in hand. For example, we may have a Nakamoto style consensus algorithm, which provides both CFD and BFT behavior. And there are force finality based consensus algorithms. One of them could provide CFD other could provide BFT. Right, for example, rough broids crash fault tolerance and then PBFT provides BFT behavior. How do we choose what's the right balance between these and isn't there a solution which maps to most of the needs. Okay I need I don't I want to catch malicious behaviors in my network I want to stop my system from crashing. Is there a balance between that. Unfortunately, the answer for this question is not as straightforward as we can come up with problem statement. Let's try to understand a different approach to consensus. I would bring up a topic from Hyperledger Fabric to discuss this this this phenomena. So, it may not often be that we mean we follow one of the consensus which which is available over there or we come up with our own consensus approach, and we decide how to create a block in a blockchain network. No, it may not always be that case. For example, in Hyperledger Fabric, the consensus is a multi multi-stage process right where a client sends it on the action gets all the endorsements and then those endorsements are then sent to ordering service. The ordering service has a responsibility of ordering them and the endorsing organization and ordering organization they may not be the same. And you can have any kind of consensus running on the ordering service clusters and their responsibility is to know which transaction will go into which block and depending on the endorsements, which they have received. So, if you really see where exactly to be used raft and fabric, we are using them at we are using that algorithm at the ordering service layer. Does it mean that it's that's that's the only place where the consensus is being achieved in a blockchain. No, because as I said, the actual parties are getting into agreement through their endorsements to the transaction that happens much before a transaction is sent to ordering service clusters. So, when we decide upon when we go for enterprise applications, we may end up seeing much more complicated much more multi stage consensus approaches. It may not be just straight straight forward as we initially discussed in concepts. Having discussed a particular scenario from Hyperledger Fabric. What other things are available within Hyperledger umbrella. So, different projects. In fact, how different algorithm supports. You can find quiet draft PVFT or BFT, maybe FD, and of course, so many of these frameworks within Hyperledger umbrella they do provide option, where in which you can go and create your own new consensus systems. They provide pluggable interfaces. You define the process you define when should a block be accepted by everyone you define what should be done when a block is accepted you define when should a transaction has to be accepted. So, they provide interfaces for you and you can implement your own algorithm through those interface expose interfaces as well. Having dealt with these things now, how do we what kind of questions do we really need to answer when we need to choose consensus or does it even matter when we go for a consortium work. Yes, it does. As long as we answer these following questions or maybe the questions I put up here are more simplified. And depending on the use case, you may have some additional questions in to these. But you will need to look it into look look into multiple aspects. You need to check. Hey, is this particular consensus approach providing me privacy, which is expected by let's say, this particular law requirement. The California Act or maybe the European Privacy Act or maybe Indian Privacy Act, which has been defined. Can I just, I mean, can I approve or can I pass through that legal process with this approach. Can I, and what will be size of my network. If the size is big, then the fast finality algorithms, they may take a toll on on the network. The reason is, again, being in a larger network in fast finality approved based algorithms, we generally tend to have a fully connected network. And as we know number of connections in the network, it grows exponentially. So that's, that's another reason which another thing which we need to be wary about the size of the network and the choice of consensus. If we go for multi stage consensus approaches, again, yes, it provides us some flexibility or there's in the sense that I can choose a part of like only in the case of fabric, only the participants in the channel, they get involved in the endorsing policy process. For ordering service, I can choose with latest release of fabric, I can choose part of ordering service custom notes, which have responsibility of creating the block. So those kind of features are available. And another question which may we need to discuss more in deeper before you make a choice is of course the degree of decentralization. Complete decentralization where every party has equal right to do what they want to do in the network. Is the model where somebody else ordering the transaction or as long as I endorse the transaction, which is supposed to go in there. It is fine with me is that kind of thing sufficient. And also it's like the speed of execution, all those factors do come in in that. And finally, like the performance and throughput factor. Right. So some of these consensus algorithm, they may sometimes get limited because of just a sheer number of messages exchange in the network. And nodes they tend to limit themselves like maybe because of network limitations maybe their computer resource limitations. That's another thing which we may need to choose. Think about before you make a choice. We have last two minutes. I want to ask, is it fine to extend or do I need to end in the next two minutes. I think if you have time, then we can extend it for how much long do you think. Okay, I'll probably skip the I wanted to briefly talk about the smart contract and then the deterministic nature which we expect in the smart contracts. So, yeah, yeah, I think we can extend. Okay. So, quickly, I'll brief that up right instead of spending more time on it. So, another thing which plays very critical role in achieving consensus or maybe avoiding. So most of these consensus algorithm they may not be such like coming out of the box, providing solution to each of the problems. So far I have been discussing the problems that distributed networks, which are more towards agreeing upon something kind of questions right, but there are other questions such as how do I solve the network security related aspects in my network is consensus really related to that. So I need to worry. I mean about my security when it when I make a decision of consensus algorithm. Those are the other questions which would also come up. So, there are there are possibility of denial of service attacks in in consensus algorithms which are like, for example, PBFT is susceptible to that. One way I mean there are mechanisms again through which we can limit those kind of attacks. So make sure that yours. I mean these are the simple checks right so quickly talk about the smart contracts and this and the need for determinism in the smart contract smart as long as you keep your smart contracts. Deterministic in nature as long as you know that what is the expected outcome from your smart contract no matter when it is executed or what time and it is executed. You should get the same results so that rules out that no node is giving you intentionally. I mean, yeah, the wrong results right and then there are mechanisms through which you can store the complete smart contract on chain. You can have the governing related settings or gardening related network governance related operations to be performed through on chain operations, which means you are getting all the features which blockchain provide the immutability the decentralization the distributed behavior for managing the network itself. Since because of limitation in the time I'll probably go to. I'll probably stop that discussion at that point and so that's, that's how we that these are the kind of questions which come to us when we need to decide upon on a consensus. Thank you for your time today. I'm not sure if we have time for you. Yeah, we can. We can have questions. Questions for questions from audience. If you can. Either you can put in the chat or you can unmute yourself and ask the question. Okay, let me ask one question myself. So, I don't. So, I want to ask about the consortium concept of our question. Okay, so I think we have a question. What is 51 attack. So, let's let's consider a network where you have a proof of work. Let's say you have an automotive consensus algorithm right there. As I said, they really work in a phase where they do eventual consistency as part of their agreement process. What does means is, let's say if you have 10 notes in the network, and you come up with a block or you come up with a particular order of transactions and then you say hey this is the order in which transactions are to be accepted. What if remaining participants on your network they don't agree upon. It's just that you are thinking the order, the transaction should be ordered in particular mannered, but remaining parties in the, in the, in the consortium they don't think it that way. So, with 51% participants on the network agreeing upon your block or agreeing upon your ordering sequence of ordering. I'm really sure that majority of the nodes in the network they agreed for you. So that leaves behind the small portion which is minority to also follow up with the majority. So 51% attack means you falsifying node identity by yourself. It's also called civil attack is also one of those. It also falls under that category right. You falsifying identities and you claiming to be having more number of notes in the network, and then you voting for yourself. So that's like you have control of majority of the network. And then you're saying, hey you are producing the block in that majority. So that's why it should be accepted by everyone. That's what the 51% attack means. So we have another question. I mean, whether fast finality comes under CFD or BFT. Sure. So fast finality can be achieved. So as I said these days, so they don't go hand in hand right in one of the slide I showed you the four directions. So they not necessarily go hand in hand. So why is Raft provides CFD behavior whereas BFT provides BFT behavior in your network. And they both are fast finality based algorithms. So why is Raft only CFD because once a leader is elected, then that leader stays on to be the leader for as long as the majority of the network agree for that leader agree for that the leader is up and running fine. These are the CFD algorithms majorly they are used for high availability systems. In cases where you want your network to be always up the load balancers right and they run cluster within themselves to know which service is available. If the node goes down then the other nodes takes the responsibility of identifying where to redirect the request to in Kubernetes. As I said the master nodes they run the Raft again. So that is used to determine which node should get the submitted workloads to run. Also it does many other things. I'm just oversimplifying the things which master node does in Kubernetes. Is there an implementation for BFT in Hyperledge Fabric. So I may not know the latest state on that. But there were talks on providing BFT behavior. If not directly through PBFT kind. So as I said in fabric the consensus process is a multi stage process right it's not straightforward as you go and say hey I want this algorithm or that I want other. It's not that how fabric works. There are endorsements from participating organizations and those endorsements are sent to ordering service for ordering the transactions. So it's a multi stage process. You are in fact getting agreement from all the participants beforehand. And then going to ordering service ordering service at max can only put them one after the night. And again over there there are possibilities of providing BFT behavior. If may not be through PBFT which is not I'm not sure if it is already implemented or not available. Sorry for that. But there are projects within Hyperledge Labs which work towards providing BFT behavior in fabric. You may look into a private chain code project. That's in Hyperledge Labs that provides that behavior. How can identity. How can we identify the false identity in the network. So that's a good question right so multiple blockchain networks they provide multiple ways of identifying if identity is not belonging to them. If you think of it's the same concept of CAs. Let's go back in time and understand how CA works. So what is CA. I mean I'm talking with respect to fabric of course I can then give you another example on Southwood as well. Fabric follows the identities and those identities are permissioned in the sense you can configure your network to know I mean tell the network. Hey if a person comes to you and submits a term to action or if a new node comes and joins your network. You should accept them only if they have this certificate issued by this party. So the delegation of proof goes to the CA as long as your identity is issued by the CA. And then your network is configured to accept your see I mean to trust your CA. That's how the trust is achieved in fabric. Whereas in Southwood they go by a pure model of public photography. You have your private key which is your private information then you have a public associated with it. You permission yourself in the network such that you put all the public keys on chain you store your public keys on the blockchain network and you tell. Here are the public keys if somebody signs a transaction signing involves of course using your private key and it tells who signed or who submitted the transaction. Then you are telling the network is somebody signs the transaction using and you can verify the signature using these public keys. Then they are the valid people to be in the network. Again you can do a validator level permissioning you can do transaction level permissioning. You can do smart contract level permissioning within the smart contract you can do again check by yourself if a public key is what you expect for from the sender. So this is how we can identify false identity in the network. I think I may have used a wrong word when I spoke about civil attack so civil attack is not necessarily always with the false identity civil attack could also be with multiple identities which are valid. Which everybody trust in the network multiple identities but behind the same they all belong to the same group of people same person. I think there is one more question can we receive documentation in this context BFT. So yes sure so I'll do one thing I'll share across this documentation I guess the video recording will also be placed on some days. I think we can share it on the meetup groups as well as on the KBA forums. Sure I'll send you those slide day. Okay. These are good questions by the way. So I don't think we might have more questions. So does anyone have any questions. Just one question. It's not really a technical one, maybe a philosophical one. If you want to answer. So the consortium concept. So unlike a public network where you have rules but doesn't really have governance layer or let's call it a consensus social consensus layer below it, similar to a consortium. So does this consortium have kind of similar problems when it comes to scale, similar to the consensus and the actual consensus algorithms, maybe not similar ones but something different like you have consortium it skates up to maybe 100 people or 100 members. It's an interesting question. The reason I would say that is because when we say consortium is growing, the group of organizations coming together and building a solution is growing. It may not necessarily translate to a physical infrastructure of computer resources growing in the same ratio. But it could still be that we still have a limited number of participants willing to physically lend their computer resources be burning question as such, at least the one which I haven't come across in any use case or any examples, which is one thing. Like, so I was asking especially because you are in hyper ledger TSE. So it was more really about coming to some consensus on the decision like on the governance layer, because consortium is mostly deal with. I mean, other than the infrastructure part or the technical part, you have to deal with a lot of things that people have to agree on right. So does that have any problem when it comes to scale? Have you come across? I mean if you're asking the TSE decision. Not specifically TSE but I was just asking like does consortium have that kind of a problem when you want to scale it to more people or not more people but more organizations. Okay. Generally, I have seen consortiums where they form a group of, so there will be like, for example, I'll take a hyper ledger, it's one of the things right so within hyper ledger, they have a governing board where parties spent from different organizations they come together and then they run the organization or that they run the hyper ledger project. So again, there are places within that governing board, which will be elected via election process. So the core set of group or this governing board, if you consider hyper ledger itself as one big consortium, which involves so many organizations that core part of people they make decisions on behalf of the rest of them because they get elected to be in that core set of groups. So you could, I mean you could consider similar things happening in application or solution space use cases as well when even though consortium keeps growing there would be a part of organizations through some mechanism they tend to represent the bigger forum. And that is the decisions will be made through them. And that should still be handled in the same fashion. Okay, so, so basically, you build layers as you grow that. Okay, we have one question, what should be the size of ordering service cluster in hyper ledger fabric. I don't know if you are. So, sure, I think I will not speak only for fabric but I'll speak generally for draft, I think, for now the majority adoption of fabric is happening on draft as consensus algorithm for ordering service cluster. So for draft to work as it requires, at least three nodes to be present in the network, but the more than it mean more the participants, the better it is, have at least three, having at least three is more susceptible to the failure because even if one node goes down then you fall short of the quorum, who can vote and get a new leader in the network. So having four is ideal in that case because even if one node goes down, you still have three people and out of four to elect a leader you still need three votes. So that's a possibility. You still tend to get a leader, but anything greater than that is what is a good behavior or good network configuration. But again, we need to keep an eye on the total size of ordering service cluster, because if we grow it to a larger size, like more than 10 or 15. Then there is possibility of because of that in the connection from each node to each other node, which is a fully connected network. It tends to be more slower. What can we use the concept of consensus within an organization between departments? Can you explain your question more, Jinsha? For example, sir, if you are considering a college and if I am doing some blockchain network inside the college, can we do any consensus between the departments like that? That is what I am asking. Sure. So, I mean, if departments are competing to do something with each other, like for example, each department has a choice of who gets to represent the college in some event and they can run a consensus, get to choose a leader. I'm not able to correlate which exact use case I can give with respect to this college and department scenario. But you would require consensus when you have multiple parties and when they all try to do something or you consider multiple parties having equal powers to do something. You need them to agree upon one common thing. You could say, hey, let's do a meetup or let's say, let's do a hackathon and everybody comes up with their own names, but you need a consensus on one particular name to be chosen for the event. So you could ask all the departments to come up with one name and then vote for each other, whichever gets the highest vote that could be a consensus. And that would be a way of achieving consensus. I'm not able to think of any other use case for college departments. Okay, thank you sir. So I think we can have a stop here. So we are over time for good reason. So I guess we can stop here. So I just want to thank Arun for this wonderful session. So it was very informative and comprehensive based on the questions I can see. And do you want to say something Arun. I wanted to ask if recording is going to stop. Can you say that. Oh, I see that session is still getting recorded. Yeah, yeah, yeah, session is still getting recorded. So thank you. Thank you everyone for joining. And I just want to give a special thanks to Arun for taking his time on the middle of the day of the work day for work day to come and speak with us. Thank you. Thank you. It was my pleasure to speak here. Thank you all. And yeah, let me just stop the recording.