 So, welcome everyone to the Hyperlayer Global Forum and to my presentation around blockchain interoperability, a demo using Cactus. My name is Enrique Alcázar and I'm the Tech Product Manager at Accenture currently working with Cactus. So the first thing that we want to address before we get to the code is why you would want or why would someone want to use Cactus. There are three main points, the first one being that we want to address blockchain fragmentation. Blockchains were designed with the idea of destroying silos and now we just have tons of different networks that are siloed from each other. Cactus can help those different networks talk to each other. It also saves the application developers from having to reinvent the wheel every time they want to do something new, every time they want to do something, every time they want to iterate over what they have. And finally, they heavily lower the risk of adopting specific DLT technologies by businesses. This means that if today you choose to build your application on top of a specific blockchain protocol, let's say that you build your solution on top of fabric and you have a client that just has a BESU network and they want you to move to their Hyperlayer BESU network, you can do so with close to zero effort. And we can do this thanks to the concept of plugins and thanks to how we are using all of those plugins. Here on the top left, we are seeing the most simple example of a plugin that we have and that is the Keychain plugin. Specifically, it's the Keychain memory plugin. This is a plugin that's just purely used to store data on memory. And in order to make this accessible to other plugins, sometimes we emulate processes such as key management directly within this plugin, Keychain memory. But again, the power here of a plugins is that you can do this during development because as you can see, it's trivially easy to use. We just define a map where we are defining, for example, the contract APIs that we are going to be using and then we can store, if we want into this map, more contract APIs for different functions that we may want to use. So contract name and right here we have the JSON when we are using the Keychain plugin. The advantage of using plugins in this manner is that if tomorrow we want to store all of these APIs instead of in, let's say, on the memory itself, we want to store them onto a specific cloud provider's environment, we do have plugin keychains that allow you to connect to those environments. And just by changing the Keychain plugin definition that we have here, you will automatically be storing all of this information, whatever you want. And again, if you have a specific place that's right now not part of the that there's not a cactus plugin portal just yet, it's as easy as implementing the same interface, which are all defined and are all as trivial as possible. And just by defining that interface, you can have all of your code that you did for a POC compatible for a production, just by basically updating and upgrading where the calls are made, where the connectors reside. This is something really, really important. That's another principle that we have in cactus is that it has to be secure and it has to be integral by default. We'll see what that means later on. Here we have a more core plugin to cactus, which are the connectors themselves. The plugin connectors are the plugins that are in charge of speaking with the different blocks and protocols. In this case, we are seeing the plugin for HyperLayer Besu. And as you can see, we do more or less the same stuff that we do when we are using Web3. We want to keep that compatibility with the most popular tools out of the box. So behind the scenes, cactus is still using all of those tools. And here on the right, we can see how we are invoking a contract. You can see that we are using the same connector. And we just have to define the contract name, the kitchen ID, the sign-in credential, because we might want to change this, say, for a sign-in credential that's on a hash you got bought, the invocation type, the method name, and the parameters that we're calling. Something that you may already notice here, if you've been working on this for a while, is that all of these things that we are seeing here, they are compatible across most DLT protocols. What this means is that if tomorrow, as we said before, you want to change from Besu to Fabric, you simply change what the plugin connector looks like here. And then you just do a replace to say that you are using, instead of a Web3 sign-in credential, you're using a hash you got signed-in credential, for example. You do a replace for your invocation type. So you're using invocation type compatible with Fabric. And your whole application and your whole stack just works. It still works in the exact same way. We also have the concept of plugin registries. Our applications can be made, the backend of your application can be made basically by just putting plugins together, including the business logic which can be defined on plugins we're going to see now. So we're going to go through an example, which is going to showcase three different entities that are interacting with each other through a supply chain that each of them are connected exclusively to their own blockchain network. So right now, on my machine, I'm running three blockchain networks for Hyperlayer Besu, one for Go Quorum, and another one for Hyperlayer Fabric. Each of them has a separate role. And we're going to be seeing how we can create an asset on Besu. We can turn that asset into a different asset into Quorum and how we can ship that using Fabric. So here in the first one, right now, I have the role of the bamboo harvester, and I can submit a new bamboo harvest details. When I create this, it appears here, and now this is only in the scope of my Hyperlayer Besu network. Now, if I want to create a bookshelf, here I can select which bamboo harvest I want to use from the Hyperlayer Besu network. This one is the one that I just created. And obviously, I can configure any data that I want, that I have defined in my smart contract, which we'll see later on. And here I have created my bookshelf. And I want to ship it using Fabric because the shipment companies, they use Fabric. So here I just defined my bookshelf that I just created, and I click on Submit, and there it appears. So here what we've shown is how we can use three different, is how we can have the same application with three different entities or members of the same consortium across three different DLTs. I agree that a bamboo harvest was created, that it was used for something, it was consumed, and that it was shipped to a specific part, to a specific place. Now going back to the presentation, here we can see what the smart contracts look like. They are basically Solidity smart contracts here we're showing the smart contracts for the Besu and Quorum ones because this demo, we're going to focus on that. And basically, we can insert records. We can recover all of the records. And the same thing for both of them. Just that one is for the bamboo harvest, and the other one is for the bookshelves themselves. The model for the bookshelf entity, for example, is the one that defined that bookshelves has a number of shelves, as we've seen in the demo. The connector themselves, this is probably, and with some luck, the one that you will have to actually touch on the use and never modify, because we're working on supporting as many protocols as possible, not just most popular ones. But obviously, if there is no support right now for a specific protocol that you're using, you will have to implement your own i-plugging ledger connector, as we're seeing here, with the functions that we have here. And when we created, you can see that behind the scenes, we're still using Web3. You can see that we're still using a plug-in registry, as we've said before, in order to leverage Prometheus metrics collections. And we do some logging behind the scenes. But whenever you are invoking a function, as we've seen, we are using Web3 behind the scenes. So it's basically an abstraction ledger as well for all of the popular SDKs that are used to develop blockchain applications. The business logic is maybe a little bit more complicated to understand and to go through. Here, we can see again how we are creating a plug-in ledger connector in order to send transactions. And here on the right, we have the full registry that we were using for the demo application that we just saw. We are using the plug-in consortium manual, which allows us to manage consortiums, which is leverage for the demo that we just saw. We need to create meta consortiums now if we have different networks involved. And in here, you can define the keys that you're using for that consortium. You can define where that consortium is stored, where it is the consortium database, where we are going to be pulling information from, et cetera. And here, we have a new supply, a supply chain package plug-in, which is basically the business logic plug-in that was developed for this application. It's important to say that you don't have to create a business plug-in for your application, a business logic plug-in for your application if you don't want. You can develop them in a traditional way and just leverage the connectors individually, as we've seen before. But by doing things this way, we create a really consistent and cohesive way to interact with your application into one. What does this look? Well, basically, the supply chain plug-in that I have defined on my code, I can see that it's going to be using three different clients, that it's going to have a web design credential for the best on coding components. And from the front end, if in my business logic plug-in, I just basically implement, for example, the functionality to insert bamboo harvest endpoints directly from the front end, I can just call supply chain API dot whichever method I want to call in here. This means that just from me clicking the bottom of confirming the creation, the front end developer only needs to say that he wants to do this. And behind the scenes, this is using the business logic plug-in, which is using the different connectors of plug-ins which are using the different signer and signing mechanisms. So what this could translate to a production ready application is a line of code for the front end developer. And we are securely invoking a smart contract by securely connecting to a node, but also by securely signing that transaction whatever we want. For example, we have a connector for HashiCoreVault. So you could be signing your transaction into a HashiCoreVault itself, just by clicking a button on the front end. So yeah, we've seen the demo. Here you have a couple of links. If you want to try to run this into your own environment, you will need a powerful machine specifically for this demo because this demo, as we said before, is running three different blockchain networks. And the easiest way to run this and to test this is to run this command. Because as we've done for absolutely everything, everything in Cactus is dockerized. So from our unique tests to our more complex demo applications to the individual plugins, you can instantiate and use and run everything as a microservice if you want as well because everything can live within a container. So yeah, that's basically everything that we wanted to cover for the demo. If you want to try this out, the easiest way to do so is to join some of our daily per-programming sessions. You can visit that link, and you can also just look into the hyper-layer calendar schedule. And every day, we spend some time with the community doing per-programming in case they have a specific problem. We jump into a line with them, and we try to get their environment set up to try to help them build their first application. We're still working on Cactus. It's still a fairly early stages in terms of its documentation. So the best way to actually learn is getting your hands dirty and what better way to do so than actually working with the maintainers of the solution. So we encourage everyone to talk to us through a rocket chat, obviously, to join on the main list, obviously, as everyone else. But if you are actually interested on doing some development with this, please do join these sessions, and we'd be there to help you out. So that's everything for the presentation and the demo. And we just wanted to leave around four minutes to quickly discuss any potential questions.