 OK, I think we can get started. Hello, everyone, welcome. Before I start my presentation, I just wanted to say feel free to type in in the chat or write down your questions in the Q&A. I have the platforms page on my other monitor, and I will be able to try to monitor it during my presentation. Great. So before I get started, I want to give you a little bit of introduction about myself and about my background. My name is Sarah Gaimi, and I'm currently a technology specialist at Telus in Canada. Today, I'm first going to talk a little bit about blockchain interoperability and give you some background on that whole thing. And then I'm going to tell you a little bit about the latest project that I've been doing on this topic. The project is called a PubSub Architecture to Promote Blockchain Interoperability. And it has been a part of the Hyperledger mentorship program. I was a mentee in this program last summer, and I had the opportunity to work with my amazing mentors, Sarah Rouhani, Raphael Boucher, and Professor Recruz. At the time, I was also a master's student at the University of Alberta studying software engineering and intelligence systems. And my master's supervisors, Dr. Hamza Khazai and Dr. Pech Musilik, were also part of this project. So when we started the project, we had four main objectives in mind. We wanted to design a blockchain interoperability solution that can be used by Hyperledger technologies. We wanted to implement a proof of concept for the design compared with other interoperability solutions and analyze the performance. So before I tell you about the project, I want to tell you a little bit about why blockchain interoperability is important and why we need it. So there are different aspects that we can think about this question. First of all, there are a lot of blockchain networks being built around the world for specific use cases. And all of these blockchains are working independent from each other and they're isolated. This is limiting the opportunities that this technology has. And we cannot really take advantage of all of these networks when they cannot work together. But other than that, different distributed leisure technologies have unique features. And I should clarify here that when I talk about distributed leisure technologies, I'm talking about the underlying technology. Like, for example, Hyperledger Fabric is a DLT and Hyperledger Indies, another one. But when we implement a network based on each of these technologies, then I'm going to refer to that as the blockchain network and not the blockchain technology. So when I say different distributed leisure technologies have unique features, I mean, for example, Hyperledger Indies designed for digital identity specifically, but Hyperledger Fabric is a more general solution for different permissioned use cases. So since different technologies have unique features, if we can allow interoperability, we can actually take advantage of these unique features of different technologies instead of having to implement everything from the scratch every time. Also, there are distributed applications that have already been built on different networks. And if we can allow interoperability, we can use the underlying and the technologies that they have, all of the features that they are providing as an application. We can use that in other applications as well instead of implementing everything in each application separately. Finally, we may need an asset from another network. So this one is separate from the previous ones. For example, let's say I have a decentralized identifier or did on a Hyperledger Indie network. And I want to use that asset in a Hyperledger Fabric network or any other network. So this is where I have a specific asset. And if we can allow interoperability, I may be able to use that specific asset on different networks. And now when we think about interoperability, there are different scenarios that come to mind. First of all, we may need to swap different assets across networks. Let's say for example, I have some Bitcoin and my friend has some Ethereum and we want to swap these between networks. So this is when we say this is an asset swap, but then we may want to migrate an asset from a network to another. For example, if you have a decentralized identifier on one Hyperledger in the instance, I may need to migrate that to another Hyperledger in the instance. And that's when the second point is that basically asset migration from a network to another with the same technology. So I'm talking about two Hyperledger Indies, so they have the same technology, but my asset is on one of them and I want to migrate it to the other one. This is the second point. And it's different from the third one, which is when I want to migrate the asset to another network with a different technology. Let's say for example, I want to migrate that same asset to a Hyperledger Fabric Network. So this has a little bit more challenges that we need to consider compared to the previous one. Another scenario is when we want to query data from another ledger. So let's say for example, one blockchain has weather information on it and I have this application that I want to use that weather information. So I can just query that data from that blockchain. I don't really need to migrate the asset or swap any asset, but I just need to query some data from another ledger. And the last scenario that I have here is invoking another ledger. So let's say for example, I want to sell some product and there are two blockchains. One of them is responsible for the financial transactions. Let's call that the bank blockchain or the banking blockchain. And there's another blockchain that is responsible for delivering the product and it handles all the things on that part. When I sell something, I expect that after the financial transaction is done on the banking blockchain, that blockchain itself invokes and initiates a new transaction on the delivery blockchain that we have. So this would be invoking from one ledger to another ledger. So now that we have some idea where blockchain interoperability can be used and what scenarios there are, we can talk about different categories of blockchain interoperability. One of the most famous categorization is proposed by the World Economic Forum. If you scan the QR code on this page, you can download their white paper and read about the details. Also in the last few weeks, I think it was two or three weeks ago, I watched this talk that Dr. Luke Riley gave on this categorization and he goes into the details. I really recommend this talk if you're interested on this topic. You can access it using the hyperledger.org website slash webinars. I'm just going to give you some overall information about this category because there's not much time to go into the details. So let's start with cross authentication. When we expect both of the parties, both of the interoperability parties to cryptographically authenticate the transactions, that's when we fall under the cross authentication. And there's no central trusted party in this category and the blockchain networks work together directly. Then we have oracles. An oracle is an agent that enables the transfer of external data. This external data could be from another blockchain or it could be from any other source on the internet. And here we need to trust that oracle and that oracle could be either a centralized or a decentralized solution. Then we have API gateways. In this one, each distributed leisure network needs to implement their own connector. And as a result, these interoperability solutions can provide access to a lot of different distributed leisure networks. And the reason is that each of the networks separately is implementing their own connector. Another categorization is proposed by my mentor, Raphael Bulture. He also gave a talk a few days ago, I think two days ago in the Hyperleisure Global Forum. And you can scan the QR code on this page to download the research paper that he has written on this topic. So the first category here is the public connectors. Every interoperability solution that wants to connect two public blockchains can fall under this one. Under this category, we have side chains. Here the idea is to delegate the responsibility of the interoperability to the side chain and not handle it on the main chain. Then we have a hash lock time contracts. Here the idea is that we do cross chain atomic operations using smart contracts. Then we have notary schemas. Here the notaries or the trusted parties help participants on one blockchain confirm transactions of another blockchain. The next category is the hybrid connectors. Here every interoperability that wants to connect a private and a public blockchain together falls under this one. We have trusted relays here. Trusted relays are trusted parties that redirect transactions from one blockchain to another. Then we have blockchain agnostic protocols. These solutions allow arbitrary distributed leisure technologies to interoperate by providing a blockchain abstraction layer. So you don't even know what the technology behind that is. You use this blockchain agnostic protocol to interact with it, no matter what the blockchain is. Then we have blockchain migrators. Here the idea is to migrate a state of a blockchain to another. And finally we have blockchain of blockchains. Here this is a framework that provides reusable data, network, contract, or even consensus algorithm. And the blockchain that wants to be created uses these reusable parts and creates the blockchain from the scratch. And since different blockchain networks use the same pattern, they can easily interoperate with each other. So now I wanna go into the details of our solution. Our idea was to use the published subscribe architecture to enable interoperability. So here we have a broker blockchain that comes in the middle and it has two smart contracts. It has the connector and the topic smart contract. The connector smart contract is responsible for handling all the connections to different blockchains and the networking and everything. The topic smart contract holds the information about the assets that are being transferred or the information about that asset that is being transferred. So imagine a source and a destination network that want to work together. We call the source network the publisher and the destination the subscriber. For each of these blockchains to be able to interact with our platform, they need to implement a connector smart contract. When they do that, they can use the connector to enroll in the system. And after the enrollment is done, they can start interacting. The first step would be for the publisher to create a new topic. That would be step two in this diagram. When they create a new topic, all the other blockchain networks can come in as subscribers and subscribe to that specific topic. From that point on, every time the publisher updates the topic, all of the subscribers will be notified of that change. And that topic, as I mentioned earlier, it could be just an information about an asset or when something about an asset changes, we can update the topic. It depends on the use case, but the main idea is that. I mentioned we have two smart contracts, the connector and the topic smart contract on our broker blockchain. I want to tell you a little bit about different functionalities that they support. So here we have the init ledger function. That's a standard function that all the smart contracts in Fabric have. And that's basically the function that runs when you initiate the smart contract. Then if you look at the connector smart contract, we have create blockchain. This function is used every time a new blockchain wants to enroll in the network. And then we can use the unique idea of that blockchain to query information about it. And we can also query all the blockchains that are on the network. On the topic smart contract, the publisher can create a topic and then the unique idea of the topic can be used to query information about that. You could also query all the topics that are on the network. And the subscribers can subscribe to the topic or unsubscribe from the topic whenever they want. And the publisher can publish your topic and the publisher uses this functionality every time they want to update information about it. So we implemented a proof of concept for our design to make sure that it's feasible and it makes sense. All of our code are on the Hyperleisure Labs GitHub page and you can scan the QR code on this page to go to that link. We implemented the broker blockchain using Hyperleisure Fabric version 2.2 and it will talk about why we used Fabric for this one. We used Hyperleisure Caliper to analyze the performance and Hyperleisure Explorer to monitor the performance of our network. And for the publisher and subscribers, we implemented these in different technologies and different versions of Fabric because we wanted to show that this could eventually be used with other permission blockchains as well. So we implemented one publisher using Fabric version 2.2 and two subscribers using Fabric version 1.4 and another in Hyperleisure Bazoo. So why did we choose Fabric for the broker blockchain? First of all, we were working on an interoperability solution for permissioned blockchains. So our broker needs to have the same level of access and the same level of control. So it had to be permissioned. Then also the permissioned blockchains are usually used by the enterprises and Fabric is specifically designed for enterprises. So it was a good match for our solution. And Fabric supports smart contracts written in general purpose programming languages, which made it much easier for us to implement different smart contracts and different functionalities that we had. And Fabric is highly modular and configurable and that allowed us to change the configuration a little bit and try different things and come up with a better one. So here I have a demo for you to show you how this whole thing works. So here you can see the Hyperleisure Explorer page that shows you the transactions of the broker blockchain and we have 11 blocks and 11 transactions right now. Here you can see four windows. The top left one is the broker, the bottom left one is the publisher and the two right windows are the subscribers. The top one is Fabric subscriber, the bottom one is the Bazoo subscriber. So the first thing I wanna do is to query all the topics on the network. I just wanna make sure that there are no topics because I'm just starting the demo. And I wanna do the same thing on publisher to make sure there are not any topics there. Then I want to create a new topic from the publisher network. And I will give it a name first topic and a message initial message. And I expect that this topic gets created on the publisher and on the broker. So I'm gonna query again on the publisher. We can see that the topic has been created. And if you query the broker, we can see the topic has been created with a unique ID and the list of subscribers is empty right now. So if I go to one of my subscribers, I first want to query that topic and make sure that it doesn't exist on my subscribers. So it doesn't exist. And then I can subscribe to that topic. Let's see what happens. So if you query the subscriber again, we can see that the topic has been created on this network. And if we query the broker again, we can see that blockchain zero, which is my fabric subscriber has been added to the list of subscribers. And I wanna do the exact same thing for my Bezu subscriber. First I make sure that the topic does not exist on this network. And then I wanna subscribe to that topic. And if I query again, I can see that the topic has been created and the formatting is a little bit different because this is Bezu and the other ones were fabric. And if I query the broker again, I can see that blockchain one, which is my Bezu subscriber has been added to the list. So the next step is to update the message of my topic from the publisher. So I'm basically publishing to the topic again. So I update the message to new message and I wanna see what happens. I expect that all the other blockchain networks get notified of this change. So I first query the broker again. I can see that the message has been updated and it has new message. And if I query the subscribers, they all have the new message as well, which means the transaction was successful. So if you go back to the Hyperledger Explorer page, we can see here that the number of blogs and the number of transactions have been updated. So this is for the broker. So we're all done here. Okay, I mentioned earlier that we use Hyperledger Caliper to analyze the performance of our network. So these are the results. What we did was that we changed the transaction send rate which is shown on the top. We changed the send rate throughout time and we monitored the throughput and the average latency for all the functionalities that our broker blockchain supports. There are a lot of details here in this plot, but one thing that I want to mention is that the publish to topic functionality, which is the purple one, that's actually our bottleneck. We can see here that we couldn't even increase the send rate as much as we did for the other functionalities. And the throughput gets limited really fast and the average latency increases to up to 80 seconds even. If you look at the subscribe and subscribe and create, they follow the same pattern. The throughput is capped from some point on and from that point, the average latency increases which makes sense. And for the query function, we didn't really reach the limit in this experiment. So what are the next steps for this project? We can add support for other permission blockchains. Right now we support Hyperledger Fabric and Hyperledger Bezu and we have written smart contracts for connecting these to our broker blockchain. But we can work on adding support for other permission blockchains as well. But any blockchain, as long as they implement a connector, they can connect it to this network. So it's not like we have to do anything on the broker side. It's mainly on the publisher and subscriber side. And then we can add an access control layer. Right now, everyone can see and access all the topics on the network. We can add another layer of control. For example, the publisher network can control who can access the topics that they're publishing to. And we can work on enhancing the performance. So we already know the bottleneck of our network is the published to topic functionality. So we can work on improving that and making a little bit more performant. And we can work on enhancing the transaction verification. Right now, we're not doing much verification other than what Fabric does in its default version. But we can add more verification steps to our platform. And finally, this solution can possibly be integrated with hyperledger cactus in the future. Thank you so much for listening. I'll be happy to answer any questions that you may have. Okay, I'm gonna stop sharing here. So hello, everyone. Hello, Brian. Hello, Tommaso. Sandy, I am not sure, like oracles and notaries that I talked about, they are in the categorizations that are proposed by the, by Ralph Alba's chair and by the organization that I talked about. So these are not concepts that I'm proposing here. So they could come from Corda, but I'm not sure about that. Thank you. Thank you, everyone. Oh, we have some questions in the Q and A as well. Do you wait? So the question is, do you wait that all the subscribers commits the operation to their blockchain prior to removing the posted message? So we don't remove the message, actually. The message is gonna be there as long as the publisher wants it to be there. When the message on that topic is changed, we're gonna replace it with a new one. So if the subscribers get the new version, so that could happen, like before they get the older version and new version comes in, but they basically need the newer version so they should be good. Assuming a subscribed to a topic, can a get the notifications automatically? Yes, they will get the notifications automatically. So that's the idea. The A does not need to query anything and that's the whole point of using the published subscriber architecture. We don't want the subscribers to keep checking and keep querying the publisher to get the latest version, but the broker will let everyone know of the change. So the question is, what would be a typical use case? So there are a lot of use cases that you can think of. I don't have a specific one in mind right now, but any blockchain network that wants to query information from another network and wants to do something with that information, they can use this platform because they don't need to keep querying it and every time it changes. Let's think about the weather example again. So for example, I want to have an application that does something based on the weather change. So by default, I have to keep checking the weather every time. I have to query it to see when it changes, how it changes. But in this platform, you can just subscribe to that and you can get notified every time it changes. So the question is, could you talk a little bit about your roadmap for adding other blockchains? Are you mostly focused on those within the Hyperledger umbrella or looking at others as well? So our platform is open source and all of our code is open source and we would appreciate anyone who is interested in adding different blockchains to our network. We're not limited to Hyperledger at all. We are open to adding others as well, but I don't have a roadmap right now to tell you, for example, in a few months, we're gonna achieve that or the other. I don't have exact timings for that, but we are definitely open to adding other permissioned blockchains as well. Okay, what MQ are you using for this or is that pluggable? Sorry, what do you mean by MQ, Sandy? Okay, Mohan, your question is, I mean, could a transaction occur on Fabric and then a notification can trigger a payment in Bezu? Yes, this is totally up to the subscribers. So for example, if we have a publisher that is in Fabric, it's written in Fabric and we have a subscriber that is written in Bezu, something happens on the Fabric, the Bezu gets notified, it's up to the Bezu network what they wanna do with that notification. So they can trigger a payment if they want, they can add it to their application to do something else. It's up to the subscriber. So right now, okay, let me just read the question. Also, does data flow bidirectionally from Fabric to Bezu and back or is Bezu currently only able to operate as a subscriber? So currently, Fabric can be both a subscriber and a publisher, but Bezu, we currently only have subscriber connector implemented for it. So the question is how do you guarantee to the subscriber that the transaction went through the consensus protocol and it's correct? That is a great question and that's one of the points that I had for the future work. So basically right now, we're just using the default verification of all of our platforms. That's definitely something that can be added to the network and it's of great value to have another layer of verification about consensus. Oh, okay, the message queue. So the PubSub is implemented as a smart contract in the hyper leisure Fabric network in the broker. So we have implemented the message queue basically. Great, I think I've covered all the questions and we're out of time. Thank you so much all for joining and feel free to contact me, reach out to me. I'll be happy to have a discussion on this or anything else related to blockchain. Oh, okay, let me just get this last question that I got in the Q&A. How do we choose who acts as publisher node in a network? So the blockchains that want to participate, they choose whether they want to act as a publisher or a subscriber, it's up to them. So Sandy, the presentation is up on the website and you can go ahead and download it and all the links are there if you want to go to the documentations on different things. Thanks again all for joining, feel free to reach out to me. And yeah, I think we're all good.