 Okay, so let's be real live. Great. Hi everyone. I'm Gusha. I'm a master's student in University of Manitoba. And I had this opportunity to be a mentee in Hyperledger Fabric Mentorship Program in 2023. Before starting anything, I should thank especially my mentors, Dr. Sara Rohani, Fahib Fuhedari and Rui Pan for supervising me for this project. And also I should thank David and Ninu for giving me this opportunity to present you our solution here. So let's begin with a short introduction here. So in the introduction, I'm going to talk about our team and I'm going to give you a sense of interoperability in the realm of blockchain. So let's begin with our team. Okay, Sara, do you want to start? Yeah, sure. Hello everyone and thanks for participating. So I have been working with this Hyperledger Mentorship Program for a couple of years and I have this chance to work with amazing mentees like you, Gusha, in a different projects. So we have looked into the interoperability actual problem from a different perspective by integrating solutions like digital identities with other blockchain platforms or looking into the different architecture such as published subscribes, actually. And in this particular project we have focused on interoperability through like built-in features of Hyperledger Fabric or like smart contract as a gateway, which Gusha will dive in and give you more details. I would just again thank Hyperledger Community for providing us this opportunity to do these exciting projects and be part of this contribution. Okay, thank you, sir. And next one is Wahid. Sure. Good morning. Good afternoon everyone. Thanks for allocating your precious time attending this session. My name is Wahid. I'm the application development manager and the solution architect at the ISM, which is a kind of company. The second year that I'm participating in this great program, the Hyperledger Mentorship Program as a mentor. I've been researching and following blockchain technology, especially its use case in access control and data sharing since 2017. I've worked on a few projects, academia project and industry project, and I'm so excited about what Gusha is going to present. I'm going to be around hopefully till the end of the meeting, but if I needed to jump in another call, you can reach out to me on LinkedIn. If you have any further questions, I'm going to ping my LinkedIn address here into the chat. Thanks everyone. Thanks, David. And my next mentor who is not here unfortunately is Rui Pan. And he was an engineering manager at Graeme Discovery and he has been my mentor in this great program since June. And here is me. My name is Gusha. I'm a master's student at the University of Manitoba in Canada. And my research interest is about blockchain distributor system and especially blockchain interoperability. And I have had this honor to be a mentor in Hyperledger Fabric Mentorship Program. And I have worked on an interoperability solution during this program, which I am going to share it with you. But speaking of interoperability, let's talk about that a little bit. Interoperability basically means when we have this ability to let two different blockchain platforms talk to each other, communicate with each other, and you know, submit transaction over each other. And given this fact that we have different various, you know, blockchain networks, interoperability can be very critical. But why? Well, it's really vital for the community, I believe, because first of all, it can let different services be shared among different blockchains. So for example, imagine that on Ethereum network, you have NFTs and in your company, you have like Hyperledger Fabric and you want to connect your Hyperledger Fabric in your company to the Ethereum and, you know, do some products with NFTs. So with interoperability, instead of creating a new valid on Ethereum, you can just use the services there. Also, data can be shared among different blockchains. Not only that, the financial transactions can be done over different blockchains. For example, you can have these atomic transactions. For example, you can imagine that you have some sort of assets on Hyperledger Fabric and you want to convert them to the Ethereum on Ethereum. And you can do that through interoperability instead of doing it, instead of using exchange centers. The next things that matters is about decentralized applications. Then, I believe as an application developer, it's really great if I can, if I, you know, just develop an application for Hyperledger Fabric and my application can be used over Ethereum or over different blockchain platforms. So, so far, we got some insights about blockchain interoperability, but we should know that there are some problems here. Problems in interoperability are mainly around two main concepts. The first one is various technologies. Well, if you have been in the field of interoperability like me, you might have faced different technologies here. For example, we have Axolar, we have Hyperledger CACV, we have Viva, we have full product. All of them have their own specific architecture. So, it makes the, this institution will be really hard for you as a system architect to choose between them. Because, you know, they all have their own technology, they all have their own design. For example, Axolar or full product, they use a blockchain to create interoperability. We had Hyperledger CACV, which used a node server to create interoperability. Now, we have Hyperledger CACV, which is basically a combination of Viva, the Hyperledger CACV. And, you know, to select a proper interoperability platform for your, for your vectorial architecture, you have to know all the differences, all the, you know, architecture and concept of, you know, these prominent technologies to decide between them. And also, you should measure, we should consider the fact that the IT products has this ever-changing nature, you know, during years, your needs and your architect, architecture will be different from the early years. So, your needs will be different, you might need to select different technologies as well. And also, you know, this ever-changing nature does apply to the interoperability platforms as well. So, for example, the Hyperledger CACV that we have today, we might not have that in the next two, three years. And, you know, all of these changes, all of these vast amount of technologies sometimes can be really overwhelming for you. The next problem, which is intertwined with the previous one, is the cost. So, as I said, we have these different technologies. When you want to apply interoperability to your technology, you have to learn them. You have to learn architecture and, you know, all aspects of Valkyrie or Hyperledger CACV to apply them to your code. And also, you should check the compatibility between your IOP product and the interoperability platforms. Not only that, sometimes you need to code. You need to learn some new technologies, new programming languages. And, for example, in PortCardot, you should develop some bridges to just connect your blockchain platform to the PortCardot. So, you should do all of them by yourself, or you should hire people who have already done these things. And all of these are going to cost you a considerable amount of money and time. So, so far, we see that we have vast various interoperability technologies, which can be a headache sometimes. And also, using them can be costly because you have to learn something new. So, what is a good solution here? First, you should know that we believe a good solution is the one that simply does not have dimension problems. A good solution should let the owners of the blockchain decide for their policies. You know, for example, in Axolar or in PortCardot, they are all developed by a third party company. So, they are the one who decide over the features of these interoperability programs, not you. So, we believe a good interoperability solution should let you as a blockchain owner to set the policies. Also, you should have different, you should have access to different sections of interoperability solutions. The more important thing is we believe a good interoperability solutions should be as self-reliant as possible. By self-reliant, I mean that you don't need to rely on different technologies outside your technology stack. For example, if you are developing a hyperledger fabric and maintaining a hyperledger fabric network, by knowing the aspects and the architecture of hyperledger fabric, you should be able to communicate with other blockchains. The next point is a good solution should minimize the need for learning a new tech stack. And as I said, it can decrease the challenges for you. And the last one is obviously a good solution should be time and cost efficient. We believe we have created a good solution here. So, let me watch you through our solution. Our solution name is Automated Gateways. Well, Automated Gateways is basically a library that you can add to your code and you can call it and it can work with its APIs. Through these APIs, you can work with three main smart contracts which determine the policies in interoperability. So, for using this Automated Gateway, in addition to using the library and adding that to your code, you should just install three smart contracts. So, let's walk you through the scenario. Imagine that we have a hyperledger fabric A and we have a destination hyperledger fabric B. On both of them, we have the Automated Gateways. Both of them have used our library and have installed our smart contracts. So, through the library, they can talk to each other because our library consists of two different sections. The first one is network neutral power, which basically is a GRPC server and can make the connection happen between two different blockchains regardless of they talk. And that's why we call it network neutral. It does the authentication and actually the major part of authentication using the certificate authentication. As I said, it uses GRPC IT score and messages between two different blockchains are created here and they are sent and received in this section. The next section is the network specific part in our village. Well, this one creates and manages this connection between relay and the blockchain that we are using. It gets the messages from network neutral power and translates it to the protocol that blockchain can understand. And for each supported blockchain, this section is implemented based on the CK provided by the blockchain provider. So, for example, in this scenario, when we have hyperledger fabric, our network neutral is a GRPC server and client, but our network specific part is implemented using the hyperledger fabric SDK. Now, let's look at the smart contracts here. So, the first one is accessible network manager. In this smart contract, we keep the data of blockchain network that we have access to and these are actually our destinations. So, we keep the data of them and we apply policies there. The data that we keep for these accessible networks or our destination networks are their name, their IP, their address, their company name and their accessible network ID. The methods of this smart contract is basically a crowd. We can create, we can remove update and read or get the data from the blockchain here. And also we can check the existence of that. The next smart contract is permitted network manager. The task in this smart contract is controlling data and the level of access of an outsider blockchain network. And data we keep for permitted network here is network name, IP, its address, which is the URL, the company name and permitted network ID. The methods that we have here is again a crowd and also we check the existence of a permitted network here. The last one is permitted methods. Well, in the permitted methods, we can manage and control methods of a specific chain code that an outside blockchain can invoke. And data we keep for permitted methods here is permitted method ID and method name, chain code name, channel name, method input type and output type. And also the methods that we have in this smart contract is a crowd again. So now you have some sort of vision over our product over our solution. And our solution basically gives you this ability to invoke a service to the smart contract of another hyperledger fabric. So, for example, I own the Hyperledger Fabric A and I want to invoke a method on Hyperledger Fabric B. I want to have access to a service of Hyperledger Fabric B. The first thing for me is to add Hyperledger Fabric B as my accessible network and then Hyperledger Fabric B should add me as its own permitted network. And for example, if I want to invoke the method, let's call it some addition, for example, on Hyperledger Fabric B, Hyperledger Fabric B owners should give me the permission for having access to the addition method here. So automated gateways is basically a platform for sharing services over different log chains. And, you know, as I said, from Hyperledger Fabric A, your source, you can invoke the permitted services on Hyperledger Fabric B. So let's look at the architecture of our relay here. So as I said, our relay is the one who is basically our library and we add it to our code. This library will be connected to our Hyperledger Fabric and it allows us to call services and methods of another Hyperledger Fabric. This relay consists of different parts. It has a mediator here, which is the heart of our system, which I will explain more. And also it has the GRPC component, it has a command line interface, and it has an on-chain complex. Also, it can interact with user's code and it needs a config file to be adaptable with the user's code. And let's go to each one of these components one by one. So the first component is mediator. It, as I said, is the heart of our system. The things that it does, it connects different sections of the relay to each other. It connects user code or outside their blockchain to our blockchain. It manages the access control and interoperability process and it connects CLI and user's code to GRPC component for interoperability. In the implementation of mediator, we used factory design pattern to make our mediator compatible with different blockchain networks. So basically, as you saw, we had three different smart contracts. For each of these, we have defined an interface which we implemented for each blockchain. For example, in a scenario that we have a Hyperledger Fabric and an Ethereum network, and on both Hyperledger Fabric and Ethereum, we have installed smart contracts. We will implement these interfaces for both Ethereum and Hyperledger Fabric. And, you know, this implementation is based on our supports for different blockchain. Right now, we only support Hyperledger Fabric, so all of these interfaces are implemented for Hyperledger Fabric. The connection between an outsider component to a targeted blockchain through mediator will be like this. So the outsider component will talk to the relay and it will get, for example, imagine our outsider component wants to talk to the Hyperledger Fabric. Through factory pattern, it gets the implementation of interfaces which are related to Hyperledger Fabric, and the outsider component, which is usually a user code, can work with that implementation of the interfaces. And through those interfaces, it can communicate with the chain codes here. And so, as you can see here, we have outsider component, it works with the relay, and we have the implementation of the interfaces. And first, outsider component asks factory pattern to just generate the correct implementation based on our targeted blockchain. And after using that, it can just communicate with the smart contracts. The other things that our mediator does is handling the interoperability. So through our command line interface, and through our users going over the code that we implement for using the library, we can call services on other Hyperledger Fabrics. So we just need to talk with a specific part of our mediator, which is our IOP mediator. So we just call some method on IOP mediator and everything will be handled. And I will show you that in my demo of the command line interface. And you just select the Hyperledger Fabric that you have access to. And you just call the specific method that again you have access to with your inputs. And you got the result from an outsider Hyperledger. And as you can see in the image here, CLI or user code, they just have interaction IOP mediator. And our IOP is the component that will connect us to the targeted outsider server. So the CLI and user code, they only see the mediator. So mediator is basically an abstraction for the users of our library. The next component is our on-chain component. But as the name shows, this on-chain component connects our relay to the targeted blockchain. And the way it connects the relay to our targeted blockchain is to connecting the mediator to the targeting blockchain. So mediator with interact with this on-chain component, this on-chain component, which basically gives some interfaces for calling different methods of the smart contract that I talked about. You know, it gives those interfaces and a mediator can call those interfaces based on the user's invocation. And that's it. You have connection to your targeted blockchain. You have connection over your smart contract. It determines your policy and you can handle the policies through them. The next important part of our relay is our GRPC component. Well, our GRPC component is basically a GRPC server or a GRPC client. We use GRPC client sending messages and we have GRPC server for receiving messages from outside. So we basically in this component have authentication based on the certificate authentication, which I talked about more. And so far, an outsider blockchain can send messages to our blockchain through this GRPC component. So our GRPC component gets the messages from outsider blockchain, sends this to the mediator, mediator sends this to the on-chain and on-chain sends this to the blockchain. And again, a blockchain return answer to the on-chain, on-chain return answer to the mediator, and mediator return to the GRPC and GRPC return answer to the outsider blockchain. And we have the same thing for calling an outsider blockchain. Our user code or our CLI ask mediator to get something from an outsider blockchain. Mediator will connect us to the GRPC component and GRPC connects us to the outsider blockchain. And we can get data from outsider blockchain through that. About our authentication, we use certificate-based authentication. The certificate-based authentication is the process of establishing or doing the authentication process using digital certificates. And the steps of the authentication process is for our GRPC server gets a request. It extracts the identity from client certificate. It checks the identity with the blockchain to see if it's registered as a permitted network here. And if the outsider blockchain is a permitted network and has permission over our data, we allow the request process to be started. The next component is a command line interfaces, which is developed to let the blockchain owner have access to the smart contracts or invoke different methods from the outsiders. So basically what we have in our... So we handle all the... Everyone, can somebody give me an answer? We lost you for a few seconds, Kousha. Okay, so can you hear me right now? Yes. So let me just review the command line interface. Well, the command line interface is basically a terminal-based command line, which gives the owner of blockchain some abilities. These abilities are basically for working with the smart contracts or invocation of the services from other blockchains. As I said, our smart contracts are in charge of creating and maintaining the policies. And these policies should be determined by the network owner. So network owner can set those policies in the smart contracts using this command line interface. Not only that, the owner of the blockchain can invoke services from the outsider blockchains, which it has access to. The next part is a configuration file. It's simply a YAM file, and it does the all configuration that we need to use this library for connecting our Hyperledger Fabric to other Hyperledger Fabrics. So it basically consists of three different sections. The first section is a CA and server. And the next section is for clients, which are basically the networks that we have access to. And the last section is about the platforms that we are supporting right now. For example here, this section contains CA configs and server configs. You can see here we have the CA for the certificate authority. We have the set pass of the CA. For our GRPC server, we have the airport. Here is the part that we can determine our port. And here is the pass of our certification for the TLS communication. And the TLS communication is basically the way that we do the authentication. And also we have the G pass here. The next part is the client. And this section contains the configuration for the clients, which are basically the networks that we have access to. Well, here we have IDs of the network that we have access to. We have the name for the network. We have a company name. We have a certificate pass for them. We have their certificate. We have their G. And also we have their certificate authority for creating the TLS here. And let me talk more about these certificates. Then we want to be connected to another Hyperledger Fabric B, Hyperledger Fabric, the Scotty Hyperledger Fabric B. The owner of Hyperledger Fabric B should add us to its permitted networks. And it should give us some accessibility to the different methods there. But also it needs to give us a certificate for being connected to their GRPC server. So they should issue a certificate for us. They should give us the certificate, the key pass, and also they should give us the TLS root certificate as well. And when we got them from the Hyperledger Fabric B, we can be connected to them. And the last one is about our platform. And here is the place when we just do the configuration for the platform that we use. For example, here we are supporting Hyperledger Fabric platform. We have a name for that. We have an MSV ID for the peer that we want to be connected. We have certificate. We have key and TLS root certificate here. We have address of the peer endpoint. We have the gateway peer address. And also we should have the channel name and chain code name of our accessible network channel and our accessible network chain code. We need the name of the permitted network chain code and the channel that is installed on. And also we need the permitted method chain code as well. The last part is IOP history, which is under developments. And we are trying to create a traceability smart contracts for tracing different transactions. So overall, we had this architecture of the relay. And in the relay, as I said, we have this GRPC server. We have mediator. We have on-chain. We have CLI. And also we have the user's code and config file. So here is a demo part. Sorry, Kousha, for interrupting you. Before moving on to the demo section, there is a question in the chat about CAs and how different fabric networks can communicate considering that each of those might have a different CA. And also if you want to connect your fabric to another external blockchain base system, it might not even use certificates. You already touched base on that, but maybe it's appropriate to provide an answer to your question right now. Okay. So let me divide this question in two different sections. First of all, about the certificate issuance. Well, let me go to this solution part again and just explain it here. Okay. So imagine that we have a hyper-liter fabric B and another blockchain. Let's call it blockchain B. It can be, as you said, a blockchain that doesn't support certificates at all. Okay. We don't have that. So here we have a relay on hyper-liter fabric B and we want to invoke some methods on blockchain B and have access to some specific methods of blockchain B chain codes. So having access to that, first of all, we should add blockchain B as our accessible network here. Blockchain B owners should add us as their own permitted network and permitted methods. And now about the certificates. For connecting our relay to their relay on blockchain B platforms, they should issue a certificate. This certificate issuance is not related to the blockchain at all. Okay. You can just issue a self-signed certificate as long as you set the certificates. For your GRPC server here and send me the proper certificates to let me act as a GRPC client. It's all done. So blockchain B here creates a set of certificates for the GRPC server for its own GRPC server and issues a certificate and a key for any GRPC client, specifically me, for a GRPC client that I will use. Okay. And they sent the certificates to me and then I can connect my GRPC client here to the GRPC server on the relay of blockchain B. So that's it. We don't need blockchain B to support certificate authority like Hyperledger Fabric to let us be connected to that. They can use literally any certificate authority. They can use self-signed if they want. And about connecting on-chain to the Hyperledger Fabric. Well, the point is every blockchain has its own needs. You can set them. Let me just walk you through that. Okay. You can, you know, you can set them in the config file. And also, as I said, you have to implement the on-chain part based on the needs that we have. So for example, our module currently supports Hyperledger Fabric. For connecting a code to Hyperledger Fabric, we need different certificates. We need some features. And we have implemented that on-chain section specifically for Hyperledger Fabric. In the future, when we support, for example, Ethereum or a blockchain that doesn't support like certificates, we will follow the SDK of that specific blockchain. Yes. And in the configuration file, we might not need any, you know, set up for the certificates there. And let me walk you through the architecture here again. And, yeah. So in the architecture, as I said, let me make it fully working. In the architecture, as I said, we have this one specifically for each blockchain. In the config file, we determined that what we need for each blockchain, as you can see here. For example, for Hyperledger Fabric, we need these certificates. But as you said, maybe some blockchain doesn't need that. So we will not add these items in our YAMP for like, I don't know, blockchain B. And that's it. So as long as your blockchain supports a smart contract, it can be used, our library to use other services from other blockchains. And I hope that I answered you, Jeri, I guess. Thanks, Gusha. Jeri, I hope that it answered your question, but we can definitely discuss more in the QA session. Thanks, Gusha. Okay. So let's continue with the demo here. I guess during this demo, I can give you a better understanding about everything. I guess there's a message in chat. Okay. But thank you, Jeri. So let's have a demo here. And for that, I can share my full script with you. And in this demo, I have two systems. One is that the local laptop that I'm working with right now. And another is another computer. And another computer, I have a hyper-liter fabric. And I installed a smart contract on that, which I will show you the code of that smart contract. And I will try to call that smart contract from another hyper-liter fabric using our code and using our measure here. And I will show you how we can develop a code to use this measure. So I guess I should change the mode of sharing my screen. I should just stop sharing right now. And again, share it here. Yeah. And let's, let's begin. Okay. So I guess right now you should see my terminal here. I am in my desktop in the demo folder. In my demo folder, I have prepared three things. The first one is the certificates that I will use for the GRPC connections. Okay. So let's look at it. Here, I have certificate server and certificate keys, which are issued by my own certificate authority. I have client key and client certificate, which are issued by the certificate authority of the other system. Okay. And I will use that to be connected to the other system. The other thing is, it's basically a need for hyper-liter fabric is the chain search here. So I have, you know, the user certifications because my code is basically a user for hyper-liter fabric. And the next part, which I am going to show you is my configuration file. And so we have this configuration file. We have the CA part, which is set. We have the server certification addresses here. We have a client, which is my other computer, which is a Dell computer. And I set the port for its GRPC server. I set IP. I set the address of that. And so I set the key and the certificate that I got from the other computer here. And here is the settings for the platforms that we are supporting and we are willing to be connected to. It's a hyper-liter fabric. The version is two, five, three. And I have the, I have some settings for the peers that I want to be connected to. I have the peer endpoint. I have the gateway peer. And I have the name and the chain code name and the channel name of my smart contracts, which are the policy-based smart contracts. And well, let's start the journey. So for using our library, everything is so simple. You just need, first of all, create a go-by. Just got a demo.go here. And I have prepared the code for, you know, just make everything faster. So basically, it's just two imports of our module, which is published on the Github. And I just set the config file and I just start the interoperability. It will run the IOP module for me and it will give me the CLR. So, yeah. So for running this Go file, I have to just do some adjustment. And the first one is Go mode. It's called our module, like demo meetup. Now we have this Go mode and let's add our requirement here. I have this one prepared. Okay. And I will get the module here. So I will run my demo here. So the job server is started and it's a welcome message. And, you know, you can just use information from outside ledger or from your own ledger. First of all, we should add the other computer as our accessible network here. So I'm going to work with my own ledger. So I select the number two option. And then I'm going to select the number one accessible network handler. I will create an accessible network. The network name is like the IP is 100 and 125. The address is, this address is the URL that the certificate is issued for. The company name, let's call it like one. And okay, it uses the mediator to be connected to my ledger. And now I have the response here. The only thing that I should do is to get this ID and, you know, just add it to my configuration file, which is basically the same name, but the number is 14. So, okay, now I should do the same thing to the next to the other hyper ledger fabric. So I will have this search and I will connect myself to the other one. I will go to the part that I have my demo ready. Here I have already set up the demo file. I have already set up everything. It's basically the same thing. And I just write. Oh, just before that, let's check to go on that. Okay, we need to add go here. Okay. So, let's try it. Go on. More here. Okay. So here, as a here I'm acting as an owner of the hyper ledger fabric. Here I shoot at the hyper ledger fabric a the permitted network because the authentication is based on the permitted network smart contract. So, I'm going to create a new permitted network here. The name of the network will be, let's call it the HP because my hyper ledger fabric a it's being installed on my HP laptop. My IP is is one three seven my address is. And my company that's two. And here is, here is the permitted network that is issued for my for hyper ledger fabric a as a permitted network. And here is the ID and I need this ID to give access to the specific method. Okay. And let's talk about the method before going into the method. I will show you with the smart contract here that I'm willing to run. Let me show you that. And it's, let me show you through this. Sorry for I guess I just. It's, yeah, there's a problem with my goal and here. So I have to show you through this and sorry for that. So, my sample chain code here is smart contract. It just does a simple addition. Okay, I just designed it very simple to, you know, just save some times it the name is add two numbers. And it just got two numbers it add these two to each other and it returns the results. And I installed that as the name of the chain code is addition chain code and I installed that on my second computer. And so, yeah. Let's continue our journey here. So, for adding the permitted method. I will create the permitted method. The permitted network ID, I just copy that the permitted method name is add two numbers I copy that from here and add it right now. Then I entered chain code here. The chain code name is addition chain code. The channel name is my channel. And my outputs are basically two integer. So, I have these two integers. And my output is an integer again. And yeah, we have it. And so, so far, we have created permitted network. And also, we created permitted methods on that. So, everything should be fine by now I just returned to my hyper ledger fabric a and I will try to call that method from hyper ledger fabric B. So, for calling that I need here I need to get information from outside. So, it's if there is a list of the outsider network that I have access to here. I just have one network is push a dash still. And okay, first of all, I should get my network information from outside ledger. So, my address is. Here I send my own address to the outsider ledger, and it will check my name is permitted network and it will return some info to me. So here, as you can see the ledger on hyper ledger fabric B is called to the mediator, and it returns some information here for me. It says that I have I'm a permitted method network there and there is my it is my IP is my name and my ID there and my address. So, and now I want to see what methods do I have access to. So, here I put the network ID. And it to return the method that I have access to which is add to numbers and the chain code name and the channel name they are all returned to me. And it gives me the inputs and outputs that I should use. And here is the core of the demo which is invoking the method on an outside ledger, you know. So, we will the method that we want to call is add to number. The chain code is addition chain code. The channel is my channel and my inputs here, but it should be to integer. I will use, for example, 100 and like 25, and I should expect an integer here as my output. And I call it. So, the hyper ledger fabric be here, as you can see here's the result the hyper ledger fabric be here, got my request for invocation of a method of its own. So, it got the request, you check the chain code name and check my permission and check the method name and again change check my permission. And it then after see that I have permission, it just got my inputs and gave them to the method and got the results from the method and returned them to me. So, that was basically a very simple demo about what our module is capable of. So, so far you have seen that everything you know just by having this file and connecting that to a hyper ledger fabric peer, you can call methods from other hyper ledger fabrics as simple as these two lines. So, as I said, you do not need to learn a huge another huge technology, you should just know go programming languages, and you should just know the goal programming languages deep enough to call a method to import two modules and to set a conflict, which is basically a value. And through that, you can have the you can just interact with your policy based smart contracts and you can call services on other hyper ledger fabrics. It just these two simple these two simple lines of the code. So, I'm going to stop sharing my screen and then I will return to the slides one more time. Okay, let's share the slides here. Okay. So, so far, you had seen the demo and, you know, for in case of any incident of Merphilla I had created a video for you as well. But you really doesn't need that because we had this demo successfully as a live demo. And now you have so far you have seen our library, you have seen our plan for interoperability, and you have seen a simple demo of what our interoperability library is capable of. But let's talk about some plans for the future. As you saw, this solution have a lot of potentials, I believe. For example, we can use it in banking systems. We can suck me transactions among hyper ledger fabrics, which are being used by different financial companies. I want you to imagine the scenario that on bank a, which is using hyper ledger fabric. I have like an account and my balance is like, for example, $200. Okay. And I want to add, I have another account in bank B. And I have created on bank B. And I want to use my, my balance on bank a to just, you know, make my credit things. Okay. So I can do this interoperability. The bank a can send my balance to, for example, $100 to other banks for my credit. The other part is the other sample is data sharing. So you can share data in a, and you can control the access of data sharing using our library. So two hyper ledger fabrics can share some, they're allowed data and, you know, to each other. And you have access to the data, you can inbox them and you can call them. You know, it's like you have access to the data on hyper ledger fabric. But as an owner of hyper ledger fabrics, B can control your access to that. The other future plan is know your customer applications. For example, we have, we can have all of our customers information on a hyper ledger fabric a and hyper ledger fabric. B can use the data that we have on hyper ledger fabric a to just, you know, for financial transaction and as a K vice machine. So these are the plans that are really feasible for the future. And the last part is questions. So if you have any questions, I'm here. You can send in chats or you can ask me whatever you prefer. Thank you very much Kousha for giving us a walkthrough to your design and implementation for this automated gate phase. We believe that the interoperability challenge is a key to open a new door into the blockchain applications and creating a bigger and meaningful blockchain ecosystem. As Kousha said, the plan is yours. If you have any question, if you have any further question after this meeting, I believe that the slide deck will be shared with you post session. Feel free to contact Kousha and Dr. Rohani there will be more than happy to assist you with your questions. Yes, sure. Okay, if there is no questions at this moment again, you have this opportunity to review the slide deck and get back to us with your question will be more than happy to have further discussion around the interoperability challenge and the suggested solution that Kousha has worked on in the last few months, considering that I can't see any questions in the chat. David, we can give it over to you. Okay, that's great. Well, thank you so much for that. And as you say, this is not the only time to have questions. I will follow up with an email with some resources and then a place to go. If you do have questions about how to continue the conversation. So thanks everyone for joining the meetup today and we hope to see you in the community going forward. Sounds good. Thanks everyone. Have a great rest of your day. Thanks everyone. Great. Thank you.