 All right. Hello, everyone, and welcome to a new presentation, demo presentation for the HyperLayer Global Forum. Today we're going to be talking about blockchain interoperability using Cactus. My name is Enrique. I'm a tech product manager at Accenture, and I work with Cactus. The first thing to cover, something real quick, is why we are using Cactus. The first point is to address blockchain fragmentation. Blockchain, one of the objectives was to liberate information from being siloed. And now we have just different tons of different silos, blockchain networks that can't talk to each other. Cactus fixes that. We are also saving developers from reinventing the wheel, doing more complex stuff such as advanced key management on different cloud environments. Those, or ABI management in the case of Bezo, for example, all of those things that are just a little bit more complicated that we usually overlook when we are building POCs, that are usually a headache when we are taking solutions to production. Cactus handles all of that. It has a plug-in architecture. So basically, you plug in a DOM component for your POCs. And when you want to take it to production, you just switch it for a different component that's, for example, going to manage your keys in AWS KMS. And it's literally just switching a plug-in, reconfiguring your plug-in, and your whole solution still works. This brings us to a last point, which is lowering the risk of adopting a specific DLT technology, specific blockchain technology. Because as we are going to see, if today you want to choose to develop your solution on top of HyperLayer Fabric and tomorrow, for any reason, you want your solution to work on a client's network, which is on HyperLayer Besu, you can really simply just change the instance of your plug-in. And if the smart contracts, if compatible smart contracts are deployed in the other network, you don't need to do any other changes to your whole stack, to your whole application. And certainly, your application works on a different DLT protocol. So we do all of this by using plugins, as we said before. We have really simple plugins, such as the keychain memory plug-in that we are seeing there on the top left, which basically allows us to store data on memory. This is a typical plug-in that we would use for a POC, because it's just a really easy way to manage the APIs for other smart contracts, to way more complicated plug-ins, such as the connectors to different DLTs. And this is an example of an instance of the plug-in for the ledger connector Besu, which allows us to interact with a hyperlayer Besu node. All of the plug-ins, they fit together inside of what we call a plug-in registry. They can be used to stand alone without a problem. But by orchestrating your plug-ins in a specific manner, we can do really cool things that we're going to see later. Finally, just to note here an example of how a plug-in can be used. Here, we have declared the plug-in connector Besu. And here, we are using it to invoke a contract. And if you have noticed, all of these parameters are compatible with most DLT solutions, which means that if you want to change your Besu connector for a hyperlayer fabric connector, you just need to change your sign-in credential for a sign-in credential that's compatible for Besu. You can parametrize this, so you don't have to change either. You change the invocation type of your calls, and suddenly you can read your balance from the first account from a hyperlayer fabric smart contract that has whichever name they want to put here. So the example that we're going to be seeing, it's going to be involving three different DLTs. So currently, I have in my local machine running a hyperlayer Besu, a GoQuorum, and a hyperlayer fabric network. And they are from three different participants, which are all running their three separate networks, which are on their own network with other participants. And they want to do a traditional supply chain application. Here we can see a simple example where we are going to register a bamboo harvest. We are then going to create a bookshelf referencing that bamboo harvest that's on a different DLT. And finally, we are going to ship that bookshelf that we are creating for the bamboo harvest. So jumping really quick to a demo, here we can see that we already created one previously, number 20. I'm just going to create a new one. Obviously, I can configure a lot of these parameters however we want. We'll see later how that works behind the scenes. And when I create it, here we can see that we are B8. Now we can go to a bookshelf. We're going to create a new bookshelf. And you can see that we're going to be using the B8 that we used, that we just created, and the other one that's also available because it hasn't been consumed yet. I click on submit and there is the new bookshelf, A2. And finally, sorry, and finally, I go to the shipment to the ship roll and there you go. And he can pick one bookshelf. I believe it was A2, the one that we just created as to follow all the way around. And we click on submit and this should create the shipment order for the bookshelf. So how does all of this work? Well, it's basically we have the smart contracts behind the scenes, which are for this example as simple as possible, literally an insert of a specific data model for the bamboo harvest and the bookshelf. So the bookshelf has some extra parameters such as the number of shelves as we've seen on the demo. And then we have the connector, which is going to be used in order to interact with the node that belongs to a network that has the smart contracts. Fortunately, with some luck, you will never have to actually see the code of the connectors themselves. You will just have to use them. And finally, we have the business logic. In this case, as we said before, we are using a plugin registry and every component of the system is a plugin. So we have the plugin here, where it is in the plugin consortium manual to manage a meta consortium, a consortium of different DLDs networks. We have the different parameters that are used to identify the different members of this meta consortium. We also have the consortium database where we are storing different pieces of information that we want the consortium to have access to. And we also have three different clients. The clients are just connectors as we're seeing here on the left. We have a Web3 signing credential, which is used for both the Quorum and the HyperLayer Besu nodes. And we are seeing here as well something different, which is a supply chain cactus plugin. This is literally what we call a business logic plugin. Here we've taken the business logic of this application and we have created another plugin with it. Those plugins basically are endpoints which implement the iWebService endpoint. They can look like this. You can look it later into the example if you want to learn more about it. And in order to use them for the frontend, since we have declared them as a business logic plugin, it is directly accessible from your frontend. Here we can see that literally just takes one line of code or to reference the supply chain API and to call the insert from boot harvest endpoint, which is this one that we have defined here. And there are the parameters that we are sharing. What we're achieving here is through just one simple line of frontend code. We have an application that is executing all of the logic behind the scenes that's right now managing the keys on memory. And for example, if we want to scale this, we would change the key management plugin for let's say the HashiCore football that we have, which is connected to AWS KSM. We change the smart contracts and we don't have to touch this one either. So it allows us to build applications really, really simply and plainly, saving a lot of time for the developer if you are using all of the plugins correctly. And as you want to improve this application and scale it, you can just simply switch around the plugins and as long as they meet the same interface, they will work and they will allow you to create better applications, more consistent applications. This demo that we've seen specifically, it's in our repository, you can run it directly from Docker if you want to just experiment with it and it's divided into a frontend application and a backend application. Both of them are in our examples folder, cactus example supply chain frontend and cactus example supply chain business logic plugin. Now, if you want to try this, if you go to our repo, you will see the Docker command that you have to run. Please bear in mind that it may take some time because it has to start up three different DLTs. And yeah, before we jump to the end, I wanted to squeeze in a second part of the demo which is gonna showcase a different example which is gonna have an HTLC anatomic swap of tokens across two different users operating into different networks. And this is just to showcase as well a more direct interoperability through atomic swaps. So we've created a bunch of scripts which will also become available for everyone to see. The key ones here are the ones that we're gonna be using to create an actual HTLC. We'll see that we just defined the HTLC of our structure and we have Alice and Bob. Alice is gonna create a contract to exchange 10 of her tokens in her network for one ether in Bob's blockchain network. Bob's is gonna create the same thing. As you can see, it is as simple as just basically defining a new contract request with the parameters that you wanna exchange. And then just declaring that new contract once you have instantiated the plugin for the HTLC plugin. The HTLC plugin in this case, it just needs the parameters to implement the I plugin HTLC BESU ERC 20 in this case because this is an ERC 20. And for Bob's case, it's just directly ETH what we are exchanging. Now, let us jump directly to see the code. I'm initiating and deploying all of the required contracts because we are using two ganache networks. This one is for Alice and this one is for Bob. And right now we can, for example, get the balance for Alice. And we can see that Alice in her network has 100 tokens. And if we run the same command for Bob, please excuse the slowness on the execution. It has to do with the fact that we are using MPX and TypeScript directly for the demo. But the actual execution is blazing fast. This is what comes after when appears this one here. And we can see that Bob has zero tokens here. Okay, there are two questions in the Q and A. When do I, I don't know if you saw those. Nope, let's leave them for the end. Well, that's just about now. Okay. Then really quickly, I'm gonna execute the remaining commands to deploy the contracts. And then to actually reclaim the tokens on the other side. And in the meantime, let's see the questions. All right. So the first one is the demo contains quite a few components, which ones are shipped with Cactus and which ones are custom business components. So basically everything is that we have seen is within Cactus repository. The part that will have to be made new for a new application will be just the business logic plugin, which is not a requirement. You can use the existing plugins as a standalone things. So for example, you can just have your, you can just use directly a hyper layer fabric connector using the key chain memory plugin inside of your application, just like you would use the regular SDK, the regular fabric node SDK. And the second question is, could you show the structure of the application? Where are the plugins and endpoints defined in the three smart contracts or in fabric chain code? So, yes, yes, we can do that. So the endpoints are defined on the, so everything as we said before is part of a cactus and they are cactus plugins. The endpoints is what the business logic plugin is. It's just basically where the endpoints are defined. And in this case, let me just find here. This is what the business logic plugin looks like. This is the actual Corvette. And here is where the different interfaces for the different endpoints are defined. Since we don't have time, I wouldn't encourage everyone to either go directly to a rocket chat or we have a daily call at 530 GMT where you can actually, it's an open call inside of hyper layers calendar where you can join the developers and we do per programming sessions. So the best way to actually to get started besides just running our examples and trying to go through our code is to join one of those sessions. Join one of those sessions and we'll help you get started with your first project. We'll help you go through the specific demo, build it on your own environment and you can play around with it. You can change things and that's usually the best way to experiment it. We're still iterating in our documentation but we don't have as well, I read the docs. And I don't believe there were any other questions. And just to finish this really quickly. I don't know if I did that correctly. Yes, so we finished executing everything. So now if we check out Alice's balance, she's gonna have 10 less tokens and a little bit more ether. There you go. She used to have 100 and if we do the same thing for Bob, he's gonna have now 10 tokens. And what we've seen here is an atomic swap across two different DLTs. This means that, well, we all know what an atomic swap is. We'll know more or less how HTLCs work and if you don't, I encourage you again to just jump into the rocket chat and ask the questions and we can maybe provide some guidance. And I believe that's I'm already a minute overtime. We're done with the questions. Yeah, we have other events starting. So thank you very much. It was an excellent presentation. Thank you. Thank you everyone. Have an excellent. Bye bye.