And we are now being streamed live on YouTube and we'll get started in one minute. All right, everyone, thank you for joining us for the Hyperledger Cacti Blockchain Interoperability with Hyperledger Cacti Workshop. We'd like to thank Raphael and Peter for being the workshop leaders for the session. In the chat, if you have any questions or comments, you can leave them there. We will have folks checking it. We also have a Discord at Hyperledger, which I'm gonna put the link to once again, I'll put in there every 10 or 15 minutes in case somebody shows up late, where the Cacti community is there. They're discussing the project. They are working on things together. It's a great place for folks to gather and to ask questions as well. We are also live streaming this on YouTube and I'm gonna put that link into chat as well in case anyone has a colleague who might wanna see this at a later date, you can share that with them. It will be in the Hyperledger Foundation YouTube channel right now on stream, but also later on as we're recording the day, but you can check out. And with that, I would like to turn it over to Raphael and Peter. Thanks a lot, Sean. Hi, everyone, I'm Rafael. We'll be presenting this workshop that we've been organizing the last couple months focused on Hyperledger Cacti. For your information, we started doing the workshop where when the project was Hyperledger Cactus. After that, there was a merge between Cactus and a project called Weaver and hence the name Cacti. So we're going to talk a bit about the Cactus specific components, but also touching a bit on Weaver so you have a good picture. So we were organizing the workshop also with Monica Gomez, our intern, a bit of background about me. I've been contributing to Cactus since March 2020. I've been involved with Hyperledger on the Subnitonship Program and I found Cactus very useful for academic research. So I'm doing my PhD on interoperability and I found a very valuable research platform. And I'm also involved with BlockDemon. So just a quick note about BlockDemon. BlockDemon provides nodes and it's taking services if you have any cryptocurrencies you could do delegation to our nodes. But the interesting thing about BlockDemon is that they provide, we provide a multi-chain API called Ubiquiti similarly to Cactus, but it's more aimed towards public blockchains whereas Cactus more aimed towards private blockchains. So we brought Ubiquiti into Cactus. Now it's currently under review in a pull request, but soon it will be possible for Cactus users to access public blockchains, the Ubiquiti. Peter, it's one of the maintainers to Hyperledger Cactus. He was participating in the project since its inception and he works for Accenture. So the outline is as follows. First, we're going to focus on let's say, first of all on the setup because Hyperledger Cactus takes a while to figure and to build and to be able for us to see things working. So we're going to tackle that first. And after that, we're going to talk about the formalization, systematization of interoperability and also Hyperledger. I have to thank to our partners from UE, Firefly, and also from the Weaver folks that now are our brother in arms with Cacti for being able to and for demonstrating availability to talk about their projects that are related to interoperability and related to our own project. So thank you very much. And then we have a break, 10 minutes break. On the second part, we're going to talk about the different components of Hyperledger Cacti. So it will be a bit shorter. And finally, we're going to have a hands-on session where we talk about the possible example applications we have currently available, a more complex in-depth application that will be presented by Peter, the supply chain app, and also an application made by Andrea Augusto who was doing a summer internship, implemented the CBDC interoperable applied from using Hyperledger Cacti. So that will be very interesting. All right, first things first, the set that takes a while, you have in that QR code a link to the build instructions and there are essentially two ways to do this thing. First of all, the quick setup, we can use a dev container which is a functionality from Visual Studio that allows you to build the environment in a Docker container. Okay, so this should be more or less straightforward if you have a Linux machine and the instructions are there. So you can go to Hyperledger Cacti project, Github project, and then you go to the dot-beth container and then you have the instructions there, you can follow up, you'll have enough time to build the project. Be aware that you need to make sure that your machine has enough RAM and storage. Since Hyperledger Cacti uses a lot of Docker images, the storage grows very quickly. And if your machine runs out of storage of it will be very difficult to do, you'll have strange errors and it won't be possible for you to use Cacti. The manual setup, you need to install the prerequisites. So we tested this for Ubuntu 20, you need Git, you need Node, NPM, Docker, et cetera, et cetera, et cetera. Note that all these instructions are on the build.md, so you can check them there, you don't need to copy from this slide. Right? We also depend on the Indie SDK, Indies, Hyperledger Indie is another Hyperledger project dedicated to identity. So we have a connector to Hyperledger Indie. And that's basically it. Also OpenJDK and Yarn as the package manager.  And when it's done, which takes a while, you're able to run the tests, run the binaries, et cetera. Hey, Rafael, can you show the QR code one more time? I'm gonna... Sure, sure. I'm also going to upload the slides when someone else will be talking. So if you want to copy paste from the slides to be easy, right? One more, one more second. Alrighty, thank you. You're welcome. Good, introduction to Hyperledger. Peter. I'll share my screen real quick. So what is the recommended RAM size to use this? Wait, so what was that? Yeah, recommended RAM size. He said, you know, it would consume a lot of memory. At least 16 gigs. 16 gigs. Yeah. If you're on Windows, that's preferable to have a little more than that as well, because the virtualization and all that takes even more. But if you're on Ubuntu or any other Linux distro or on a Mac, then 16 is usually enough. Thank you. No problem. All right, just a very quick intro to Hyperledger. This is not going to be the best possible introduction because that one is always done by Danielle Landhart, but I'll try my best. Basically, the Hyperledger Foundation is a collection of open source projects aimed at distributed ledger technologies and things tooling interoperability around those. And there's just a couple of things that I want to highlight. One is it's Cryptocurrency Agnostic. So the Hyperledger Foundation does not have their own token and there's no advertisement of any tokens here either. That's important. And then the other thing that I like to doubly highlight is that even though the name says ledger, the Hyperledger Foundation is a collection of projects, so it's not just a single one. There's actually plenty. There's also different tiers. So you can see a list of the projects here. Some of them are graduated projects, which is the stage that you can reach by being an incubation first. Cacti is an incubation. We hopefully get to the graduated stage later this year or maybe early next year, depending on how fast things move. And then some of these other projects we'll get talked about as well, but again, despite the name being Hyperledger, there's separate projects. Some of those are actual distributed ledgers such as Basie and Fabric in the Iroha Soletif, but not all of them. And that said, there's some general information here as well. We do try to have a very, very welcoming and inclusive community, so you can always feel free to drop by and see what kind of contributions you could make or which projects, artifacts you could use for something that you want to build yourself. And there's also mentorships, which are a great way to get some real-world experience with mentors who will actually help you. I'm one of those mentors. So I think the next iteration starts next summer, but if you are in school right now and you're thinking about entering the industry soon, then you should check that out as well. And I will pass it on to Brahma, I believe. I think that would be me. Oh, not bad.  Brahma is after. Right, thanks a lot, Peter. So now we'll provide a quick introduction, a quick overview to the field of watching interoperability. So we know more or less where Hector is positioned against other projects. So there are different models for watching interoperability and tons of great research, great systematizations, and there are different ways to look at the things, but the way we found to be suitable and at the same time comprehensive is to classify the solutions into interoperation modes and then each solution we can conduct such that we can conduct an assessment to each solution. So there are three interoperation modes, data transfers, asset transfers, and asset exchanges. Interoperation modes basically tell you what is the thing that we want to, that is the object of interoperation, right? What is the object that CACTI will manipulate, manage between different ledgers, let's say. And then we have the interoperation assessment. If we want to measure how powerful interoperability solutions are with regard to each other, we can classify them with the P levels and with the C levels. So the P levels tell if the system interoperates with other systems as it is. So the higher the P level, the better the interoperation capabilities of the system. While the C levels evaluate the interoperation capabilities of a set of systems. So how well can a pair of systems interoperate? And we'll talk a bit more in detail about it. So data transfers are very simple. You have piece of data on a source blockchain.  You basically replicate that data and push it onto the target blockchain. These data transfers are relatively easy to do, especially because we don't have any restrictions on these operations. For example, you don't need to assure that there is no double spend of information, contrary to asset transfers. In asset transfers, you have an asset on a source blockchain and you want to move it to a target blockchain. The way to do this is to lock the asset on a source blockchain and to create a representation of that asset on the target blockchain. So effectively you are not transferring assets across blockchains because you can't really do that, but what you can do is lock in one side and unlock in the other. And then the objective of your interoperability mechanism is to synchronize both ledgers such that it is always locked in one side, otherwise we'll have a sort of cross-chain double spend, which happened and quite a lot in the last month. After that, we have asset exchanges, HTLCs are a very common way to implement them. Basically what we can do is to deploy part of smart contracts such that if you provide a key to my smart contract, you can obtain my keys. And after you provide that key, I can use it to open your lock and get my keys on the other chain. Okay, so those are basically the ways you can use to interoperate. Now, let's see how powerful can the interoperation mechanisms be. We divided this classification into four levels, P1 to P4, the higher the P level, the strongest interoperability mechanism, this is the intuition. So for example, if you have a system providing P1 level interoperability, it means that you can have different functionalities on the same subnetwork. That belong to the same DLT network. That belong to the same DLT protocol communicating and exchanging data and working with each other's data. So for example, interoperability across smart contracts, right? If we step on, for example, level P3, we have interoperation across same functionality, same subnetwork, same DLT network, sorry, same functionality, same subnetwork, same DLT network, put across on the same DLT protocol. Okay, so what happens is that, for example, you have to interoperate or to transfer assets across an Ethereum mainnet and an Ethereum testnet, you can do that within a P3 level. And P4, it's among different DLT protocols. For example, Polkadot and Hyper-Lager Fabric. On the other hand, we have the C levels. So the C levels define how well a pair of systems work together, and we basically have three. And the intuition is the higher the more standardized and the more matured those ecosystems are. So if you have level C1, it means that you can communicate in the semantic layer, meaning you can execute one protocol, for example, an asset transfer. If you have level C2, then there are a set of organizations working together to promote some process that benefits from interoperability. And level C3, it's interoperability at the legal layer, meaning that there is some regulation that will, for instance, recognize asset transfers as legal. And as far as we know, there are not many C3 and even C2 levels, systems that support these levels. Okay, and after this, what we do with this information? Well, we can draw a table where we have our different D levels, C levels, and the interoperation modes. And we have a group of references. Imagine that we want a system that supports P4, C1, and asset transfers. We go on to these columns, and then we basically try to match which one stick in all our requirements, okay? And then we can see that for those sites, basically those numbers are citations. This is from an academic paper, and those references refer to interoperability solutions, right? So those interoperability solutions that the others point to can provide level P4, C1, and asset transfers, okay? So these allows you to choose an interoperability mechanism. Basically CACTI is supports level P4 and supports level C2 and asset transfers, data transfers, asset exchanges. So it's quite versatile, right? Some more references for these formalization and standardization. We have a talk on this at Hyperlegical World Forum, and there's also two papers you wrote about this. So feel free to check them out. All right, now I would like to call Rama to present the Weaver-specific parts from CACTI. Are you there, Rama? Yeah, can you hear me? Yes. Great, so whoever's controlling the slides, can you move to the next? Perhaps you could share your screen with the slides. Oh, I don't have it open. I don't think I have the latest one either. Can you do it? I'll get it in a second, yes. While we're getting it together, Stefan, do you have a question? If you'd like to ask questions, please put them in Zoom, but Stefan, do you have a question while we're getting the slide together? Okay, Stefan has his hand raised, I guess he can't hear us.  He's asking if there will be a full recording. There will be a full recording, it's gonna be on YouTube. Stefan, you're good to go. Shane has a question about, can we get a reference to the research paper? Yes, so the slides will be, the slide that will be shared, and then you can copy the link or the title, you'll be able to access the paper. I will make sure to be put the links for this in the YouTube description as well, this way, if folks want to follow along later on, they can. Sorry, go right ahead, guys. Can you move to the next slide, please? Yeah, so Rafael already talked about the use case pattern. So just to give you some history, we started the Weaver project in about three and a half years ago, and it was not named Weaver until about a year and a half ago when we open sourced it to Hyperlegia Labs. So we started off with, by trying to figure out a taxonomy of use case patterns, and this is what we came up with. And we call it data sharing, what Rafael talked about is data transfer. We used to call it data transfer, but we just using the term sharing because people had some confusion with the terminology. But yeah, it's the same, the use case patterns that Rafael was talking about earlier. Moving to the next slide, please. So the Weaver framework, the way we wanted to, we were envision building it, the kind of design choices we wanted to meet was ensuring that different networks would remain independent, self sovereign, maintain their own privacy, and would not require any kind of fresh third party to mediate between them for interoperability purposes. So the mechanism or the appliance we used for that purpose was the envisioned networks possessing one or more relays. And as you can see here, you have a relay representing three networks in the picture. So to run any kind of cross-network protocol, be it for data sharing or for exchanging assets or for transferring NASA from one network to the other, the envisioned data is happening through these relays. So what you can see here is the vision that we can enable using these protocols. And with CACTAI, you get this network of network vision where you can, different networks remain, they function according to their native logic. They run the same business workforce as they were designed for. All they have to do is they have to run an extra relay component using which they can communicate with other networks to share data, exchange assets and transfer assets and so on. And by the way, this is something we will come to maybe later in CACTAI, when we end up merging Weaver and the CACTAI components together, we are going to have different ways in which the sort of wiring can be done, the sort of internet wiring. You can run these kinds of protocols using either CACTAI's kind of node server or Weaver kind of relay, which acts as a gateway as an ingress and egress point for every network. So, and the relay is the component we expect to also allow networks to communicate with traditional enterprise systems of record, that is centralized systems, networks, which have record, which have databases that are not actually shared across multiple peers. Next piece. Yeah, this is, I'm not going to go into the details, this is just a blow up of the relay. The relay has a DLT neutral part, which you see on the left and particular drivers of plugins you can see on the right, which are specific, which are used to drive specific logic into a particular legend. So the DLT neutral part is going to be running a protocol with other relays in a way that is completely agnostic of what the network behind it looks like. So you have, you can imagine DLT protocol A, the DLT protocol C through the relays, the relay to relay protocol is going to be a standardized global protocol, which does not care if protocol A is fabric or protocol C's Ethereum or what have you. It's just going to be running your traditional message-based protocols. And it's going to rely on these protocol drivers, which you see on the right, or protocol adapters, or in order to drive transactions and queries through their respective networks. And those drivers or adapters are going to be running according to the native logic of their DLT platforms, like they be fabric-specific or corridor-specific or basis-specific and so on. Next slide please. So the Envision Networks and the Interoperability System having particular basic capabilities or building blocks using which we can engineer the kinds of protocols that Rafael and I talked earlier, the data sharing, the asset exchange, asset transfers. So the capabilities of the relay, there are certain core capabilities and then there are certain convenience capabilities like syntactic sugar, we can add over. So in order to enable ease of use for developers. So the core capabilities are for the relays, they need to be able to address remote views. View meaning the query for data in the context of a data sharing. You want one network to be able to address some piece of data, either in fundamental form or using some kind of a complex or an aggregated form. And the relay should be able to communicate that desire for a particular piece of data to another relay. And the second relay as a source relay should be able to drive some sort of transaction through its network and produce a view along with some proof that views authentic and then to send back to the requesting relay. Next please. Now on the networks themselves, there are particular core capabilities that they will have to perform in order for this transaction to this cross network operation to remain decentralized and they will be performing them using the logic of smart contracts. So these are capabilities which we will be deploying in the form of smart contracts. In fabric you can imagine them as chain code in Corda, they will be running as a sort of a Corda that is going to be deployed in all the nodes. And set of capabilities they need to do are any access control checks on any requests coming from outside the network, generating the proof for a given legislate, validating the state proof, pledging or locking an asset and the ability to claim or take them an asset. So these operations are core capabilities that have to be performed on the contracts because that's the only way we can ensure that a network-wide decision on these operations. Next slide please. Yeah, our claim is that this is a complete set of building blocks that can realize any sort of cross network dependency. Again, it's a claim. We don't have a theoretical proof for this but something we'll be analyzing as we go by. Go on. Next slide. So the data sharing is we're going to be relying on the basic building blocks of generation and proof verification and asset transfer is the way we implemented this is by relying on multiple instances of a data sharing protocol. Now there are other ways of doing asset transfer as well and maybe, I don't know if you've come to this today but there is standardization effort going on under the ages of the IETF where we're trying to standardize an asset transfer protocol that can ensure that an asset leaves one network and goes to another in an atomic manner. So that's something that we will also be incorporating into GATI. Asset exchange, finally, it's multiple asset logs and claims and possible unlocks if the transistor doesn't go through and it follows the logic of HTLC or the hash time log contract. Next slide please. Not going to go into these details but this was the viewer architecture and we are trying to now merge it with the cactus architecture in order to produce a merged GATI architecture. It's just that the main components here are already talked about the relays and associated with the protocol drivers. Interoperational module is just the kind of very bland name we've given to the set of contracts that are supposed to be deployed on the network. In addition, application helpers on the bottom left you see are the SDK and the API that we provide to an application developer or the business logic that is supposed to be driving any sort of cross-network data query or asset exchange operations. And there's also an identity service don't have time to go into this but we have mechanisms and we were and we have written a couple of research papers on this topic whereby we can use the did concept or the decentralized identity concept to allow two different networks to communicate and sync their CA authority certificates so that they can then validate signatures on the proof that they get from the from some party in another network. Next slide please. So this is typically how a Hyperlegia fabric network would be adapted with viewer components. And yeah, again, going forward there will be GATI components. So you can see a typical fabric network on the top left. It has peers, order and CAs then it has a smart contract as a chain code and above that it has the layer two applications the ones built on the fabric SDK. Now, what you need for in order for that network to be viewer enable this you have to add one or more relays that act as gateways. And so set with the relay you have to have certain drivers which are going to be engineered the same way as you'd build any fabric application. And you're the actual fabric applications that are interested in the interoperation they will be augmented or they will import the viewer SDK and the helper functions in order to drive any sort of constant transactions.  Next slide please. We have something very similar to Corda do not go into this in detail but I think if you're familiar with how Corda works very similar to your peers then you have Corda apps and two different in three different layers you have the contracts and on top of that flows on top of that you can have the client or the UI layer and if you look at the bottom right the viewer components are very similar to what you saw in fabric you have relays, you have drivers you have instead of the interoperational chain code you have an interoperational Corda app and then above that in the client application it can excise the viewer Corda SDK. Yeah, I'll see a question there. Okay, let me add us a question when I finish. Next slide please. Okay, I don't have to go into this in detail click again please. Okay, yeah once more. So yeah, I'm just showing here what are the how to trigger a data sharing or a data transfer query from if you're running a fabric application built-in node that's easy on the top right or a Corda app built-in Kotlin on the bottom right. Next slide. Yeah, I think you can keep going I think I'll probably skip this because we are out of time, right? So yeah, if you want to again this is something we're going to be porting to Cacti very soon but right now if you are eager to try this out there is ample documentation we have a full tutorial that we can where you can run sample test networks which are provided within the viewer code base and sample application that you can install and then run interoperability protocols. Next slide. Yeah, and if you want more information just always go to the RFCs folder and you have a bunch of papers and articles listed in the overview page. Next please. Okay, so how to merge viewer with Cactus? So this is something that the Cactus maintenance and the Weaver maintenance have been discussing and working on for very part of a year and the goals for this joint interoperability film was so there's a lot of similarities in both goals and philosophy between the two projects, Cactus and Weaver and but the two projects also offer something some distinct and unique features so the way we wanted to merge them was we would be fusing together the components that are being roughly the same serving roughly the same purpose and then you're going to be aggregating and offering us choice the other kind of components. So yep that in a nutshell should cover what our vision for merging is. Next slide please. Okay I think I can maybe look at the questions now. Yeah Rama the first question I assume a relay must be created maintained for each DLT protocol. Are there any evolving standards API RPC for common interactions with DLT slash chains to help with interoperability? That's from John Kent. Yeah so yes you don't know you do not have to create a separate relay for each DLT protocol. What you have to create is the protocol adapter of the protocol driver for each DLT protocol. So I mentioned in an earlier slide that they really had two parts the DLT neutral part and the DLT specific part. The DLT neutral part is something you you can just take as a universal appliance and you just have to configure it for your particular network. Are there any evolving standards? Yes so the VR and there's something that Rafael has also been keenly involved in there's a group called the secure asset transfer group which has been trying to build a working group under the IETS in order to standardize exactly this protocol. It's a kind of protocol that will connect to relays or in the SET parlance we call them gateways. The philosophy is a network is represented by a gateway and that if the network wants to send an asset over to another network or communicate some kind of data to another network it is going to rely on its gateway to do that by talking to the gateway of the other network. That's very similar to what I showed you for VR with the two relays. So that is standard which we are still working on a lot of people from different work supplies academia industry who've been working on that kind of standard and we solicit any involvement and help from any of the folks in the audience here. But yeah that is the relay to relay protocol that's something we are working on on standardizing under the IETS. And Maurizio Grazzelli asks so is this relay going to be practically a smart contract if so could one create one for Ethereum? The relay is not a smart contract. The relay is a messaging device. There is a separate smart contract that is running on the network which the relay through its protocol driver is going to hit. So think of this as your two networks and then in the middle you have two relays. So the relays act as a communication component but a lot of the core functionality that actually happen in the networks and because the networks are not centralized modules the logic for running any sort of anything on those end networks involves running them in the native contact logic. So in Fabric you'll be running it as a chain code Corda you'll be running it as a Corda. So see either relay is just a messaging component but backing it in the network is a smart contract. So and yes you can create one for Ethereum. Cool. Shondra Mohan asks can we connect private blockchains and public blockchains using a relay example hyperledger fabric to Cosmos Hub? That is our hope and I think there's nothing theoretically or technically that's stopping it. We just haven't built a POC for that but we hope to in the near future. So right now we have relays and cross network data sharing and asset exchange for Fabric and Corda networks and to some extent for Bezu but we are going to work on extending support for public Ethereum maybe Cosmos, Polkadot and so on. Thanks a lot Rama. That was a very insightful presentation. I see there are some more questions but I think we'll have to defer them to the end of the workshop at the dedicated Q&A session so we can move on with the other presentations. Thanks a lot Rama. Thanks Rama. All right let's keep going with hyperledger web project called Nui. Suzumu, are you here? Yes, yes. Can you hear me? Yes, can you share your screen? Yes, can you see my screen? Yes. Great. Hi everyone, my name is Suzumu Toriyubin, the PO block at Beta Chain. Please allow me to introduce Nui, a hyperledger web project which focuses on the interoperability for heterogeneous blockchain networks. In a nutshell, Nui puts more emphasis on the communication layer compared to Cacti for achieving its trustless general-purpose cross-chain communication. Whereas Cacti as a whole puts more emphasis on the integration of the whole system with blockchains. But since it has a much similarity in the architecture to Weaver, so there is a relay module in Nui which corresponds to the relays in Weaver. So first and foremost, Nui is based on IBC, interblockchain communication protocol from the Cosmos ecosystem. Cosmos is a public blockchain project which aims to build the internet of blockchain. Within the ecosystem, they compile sets of standards for blockchain communication as the foundation for cross-chain communication. You can consider it as a TCP IP for blockchain communication. And Nui derives the standards and provides lecture-dependent IBC modules as well as other modules which facilitate intellectual communication. The core focus of IBC is on-chain verification of counterpart blockchain to achieve trustless communication. This means a smart contract will perform cryptographic verification that certain transactions are finalized on the counterpart chain. Currently, Nui mainly supports hyperledger public-based decoder. And we are working on supporting public Ethereum and Quorum in the family. And yeah, Cosmos supports the IBC itself. So someone asked me a question. Can you connect hyperledger public to Cosmos hub? Yes, with Hyperledger Love, Nui, you can do that through the IBC portable. In this slide, I summarized the typical categorization to achieve interoperability among blockchain. The difficulty of interledger communication is that how one can guarantee a certain transaction is finalized in the cross-chain which ignites the following procedure in the destination chain. So the straightforward way is to let the trustless third party play the role. This would be also called the external validator patterns. The obvious difficulty of this approach is that it is sometimes feasible to have such third party. For this reason, we are taking the alternative approach called lead-a and right-glant pattern. There is also another way for interoperability which is called HDLC but I won't go into details about it. As Lafar as some already mentioned about HDLC. I will explain the essence of the lead-a and right-glant in the following slide. So this is the high level overview of IBC architecture within the IBC module which facilitates communication. There are several abstractions similar to TCPIP such as packet, connection, channel, and client. Client is a central entity for one-chain verification and lead-a handles the physical transport of packets. More specifically, packet has payload and proof. The proof structure and the specification is ledger dependent. Basically, proof is used for the attestation that the certain payload is actually finalized in the source chain. For body data sets and the Markov loot-based chain like Ethereum, this will be confirmed by a check header which verifies the block header is signed by body data set and verify membership which verifies a certain key value pair is included in the world state through Markov path verification. These are the core concepts of overview of UE and its communication model. UE provides the ledger dependent part of the IBC protocol so if you want to apply UE to your network you need to deploy IBC module as a smart contract and you need to also have the off-chain process read-a for physical transport of packets. We also provide the middleware called cross-planework which works with UE IBC module. If we want to facilitate complex transactions such as delivery versus payment, we need more foundation on top of reliable communication. I'm not going into full details of this middleware but basically what it does is to provide functionality of locking store and transaction coordination like two-phase commit. By this functionality you can coordinate transaction in the destination chain if a certain transaction in the source chain succeeds and buys parcel. We are currently working on LCP light client proxy which you can consider as an extension to UE. It facilitates trusted execution environment or T technology for verification. Basically we substitute the computation on the security enhanced hardware for part of on-chain verification. So this will enable efficient verification of counter of blockchain yet does not sacrifice the good security property of IBC. We provide this product with a Japanese financial institution to perform a DVP for stable coins and security tokens. I'm not going into full details of this architecture but basically what it does is that we have this LCP node which facilitates the T security enhanced hardware to substitute the on-chain verification process and that there is a test station service which attests the LCP works in the sound environment. With this help we can substitute the on-chain verification security. So for more information about the UE and cross framework or LCP please visit our website, medium or detailed history and there is a full technical details about the UE as well as a tutorial for token transport. We are more than happy to have your feedback for this product. Thank you very much. Thank you very much Suzumu. Does anyone have any questions? On the meantime let me comment that UE is a very interesting solution because one of the reasons is that it uses IBC which is one of the de facto standards for interoperability in the public blockchain world and effectively the proofs that you carry on those IBC packets are verified on-chain making it the trust assumption being the security of the source chain. Of course you need to be able to assert that an implementation does not have bugs on the proof verification but no bugs are in every software package. Shane asks can the proof be checked from the counterparty blockchain? Exactly, exactly and that's what the IBC is all about. So the source produced the payload with its proof and proof is physically relayed by relayer and checked in the counterpart blockchain on-chain so that the distribution chain makes sure that some transaction actually happened in the source chain. That's correct. For some technical detail Shane you can search for Merkel proofs or in the case of Ethereum, Merkel Patricia 3 proofs that basically you can assert that a certain event or a certain transaction were incorporated into an EVM based blockchain on a counterparty blockchain on-chain that is why the security of such protocols is so nice. It doesn't depend on a centralized set of parties a certain the message is valid. Thank you very much, Suzumu. This was a great presentation. Let me now call Nico for Firefly. Nico are you here? Hey thanks Rafael. Yeah please if you can share your slides. Yep I will share my screen. Can everybody see my slides? Yep. Okay awesome. Yeah thanks. Thank you for the great presentation so far. This is really exciting. So Hyperledger Firefly is another Hyperledger project and Hyperledger Firefly has a little bit of a like interoperability is a big part of Firefly but Firefly has a slightly different focus than the projects that we've looked at so far. So part of what I'll be walking you through is what is Firefly if you haven't heard of it if you're not familiar with it and I'm going to try to go through that really quickly. We'll also be talking about the differences between like Cacti and Firefly and how they can be used together and then I would also love to show it in action but I'm going to try to keep all this really brief. So Firefly is what we describe as a super node. It's a complete stack for enterprises to build and scale secure web 3 applications. So what does this mean? It's not a DLT. It sits a layer above the blockchain and it is a platform that makes it easy to build blockchain applications on. So it provides an API, it provides web sockets and a really familiar user experience to software developers that are used to building traditional web 2 apps. It makes building web 3 apps a familiar look and feel and experience for them. So when we look at all the things you need to build a web 3 app I'm going to go through this really quickly. Hopefully the audience here is familiar with what it takes to build a blockchain app but down at the bottom you have your chain. So say for example I want to build an app that can mint some tokens and trade transfer tokens on a public chain or something like that. I need a blockchain node. I'm going to keep some data off chain as well. There are great open source projects for both of these things already so I'm probably not going to reinvent these things. I might be using an Ethereum node or fabric or base suit or there's a lot of different things I can use here. So I will also need a token smart contract, some code to submit transactions, index events. I'll need some code to talk to my off chain data store. I need to manage all my signing keys while it balances. And I need some code that's going to bridge these two worlds of all the stuff that's happening on chain with all the data that's off chain as well. I need some code that's going to distinguish between what data should be shared publicly on the chain, what data should be kept private. I don't want to put all of my user's information on the chain, that sort of thing. I'm going to need to write the actual business logic of my application and my back end API. And finally my front end, my web UI or mobile app or something like that. So in the previous world before Firefly, this would be all code that I would have to worry about writing. And so Firefly changes this picture and it takes the entire middle chunk of this and says, well, let's have an open source platform that we can reuse that can be extended, it's pluggable, that can work with many different blockchains, that can work with many different types of data stores and have that be open source and have it be a common foundation that lots of different projects can build their applications on top of. And then that lets me, as the application developer, focus on just these top two boxes of what's my business logic and what's my user experience like. Now, maybe I have a custom smart contract already and I still really care about the very particulars of the smart contract or what chain it's running on. Firefly lets you do all these things. I can still come down here to this layer and I can customize all of these things. I can use my own contract. I can run it on my own blockchain node if I want to, but Firefly makes it both easy and still maintains all of the flexibility of customization that I might need if I need really fine-grained control of stuff. So that's where it fits in the stack. So Firefly is designed to be a gateway for an enterprise to connect to the entire Web3 world, whether that is a private blockchain consortium network, whether that is a public chain, layer one, layer two, whether it's a DeFi ecosystem or some sort of exchange, Firefly allows you to be able to connect to any of these things. Firefly allows you to build apps, flows, and digital assets. So it acts as an API gateway. It has a great wonderfully documented HTTP API. It's both RESTful and RPC where appropriate. It can generate, on the fly, it can generate a HTTP API with full swagger documentation from a custom smart contract. It has a lot of really awesome features for smart contracts and interacting with blockchains. It allows you to build complex flows of data, both part of it is on-chain, but also private data needs to be kept off-chain to share data within a multi-party network or to keep certain data private. And it has a great API. It's just really easy to use user experience for managing digital assets like tokens, both non-fungible and fungible tokens. There's a great user interface that we'll look at in just a minute for seeing token balances, transfers, managing wallets, that sort of stuff. So I'm going through this really fast, but there's just a ton of stuff in Firefly that makes it really easy to build applications on top of blockchain. Firefly can operate in two different modes. One of them is called Gateway Mode. And this is, I have a Firefly node and there is a blockchain somewhere that I want to connect to. And maybe it's a public chain, maybe it's a private chain. I just want to connect to it and I want to perform transactions on that chain. I want to query the state of the chain and I want to index events on the chain and keep track of things that are going on, events that my smart contract is emitting or other token contracts are emitting and that sort of thing. Firefly can also operate in multi-party mode. So multi-party mode is, or consortium mode is commonly seen when there are consortiums of companies that are all in the same, maybe they're all insurance companies or maybe they are all financial companies. And they need to integrate with each other and they've chosen to use blockchain to do that. So each organization can run a Firefly node and the Firefly nodes using the same shared ledger will peer with one another. And so the blockchain becomes this safe, neutral integration point that is not wholly owned by any one organization within the consortium or the network. So two different modes of Firefly can run in. Firefly can run in both modes at the same time. It can run in both gateway mode and multi-party mode. Sorry, hold on just, sorry about that. So how does all this fit together with Cacti and Firefly? So Cacti and Weaver as we've seen are focused on chain to chain sync and there's some awesome stuff going on there. So I can sync state or value or data from one chain to another. Firefly can also talk to multiple different blockchains. Its focus is on application to blockchain sync. So my application can use Firefly. Firefly can talk to multiple chains. It can submit transactions on both chains. It can index events on both chains. And it allows my application and application layer to work across different chains. So hopefully this is just a short and sweet picture of kind of how they're different, how they're trying to accomplish different things. With a few minutes that we have left here, I would love to just show a really quick example of sort of this picture of Firefly talking to two different chains. So on my machine over here, I have, this is a one Firefly node that's running and it's been configured with two different namespaces. It's been configured to talk to a fabric network. So this is my consortium, my private consortium network. And there's one other organization within that network as well. And that browser is running over here. I've color coded this one green. So this is the other node, the other organization in my network. But my node in this network is also configured with another namespace that is connected to the Polygon Mumbai testnet. So if I go over here, I can look at, this is actually my signing account on Polygon scan. And I can see I've been performing some transactions here earlier. I deployed a contract and minted some tokens. We'll look at that in just a minute. But I wanted to show you just how easy it is. So I've set up Firefly. There's a great command line tool that makes it easy to get up and running with Firefly. I've done some advanced things, like configured another namespace and connected to two different chains at once. But there's also a sandbox that comes with Firefly out of the box. So the sandbox is a great way to get hands-on with Firefly, try out some of the APIs and see some generated sample code. So the sandbox is not necessarily like a production tool, but it's more of a way to be introduced to Firefly. So Firefly, I don't have time to run you through all the features, but it has some great messaging capabilities built in. So right now I'm in my private fabric consortium network. So I can share data with other members of my consortium. I could share it privately or I could share it publicly. So if I send this is a broadcast to everyone, I can run that. And that will send a public message to everyone else in the fabric network. I could also send a private message and I could attach a file to this. I could browse for a file or I could send a JSON payload or I could just send a string. And I could choose which recipients I want to receive it. I actually only have, because this is connected to the fabric samples test network, there are only two orgs in the network. So there's only one other option here to send to, but so I could send this as a private message. And if I hop back over to my Explorer, I can see there's been some new activity here. Let's go over to the other window and we'll refresh this one. And we should be able to see some messages came in here. Here's my private message that I just received. There's lots of information here. I can go to the actual message and click this one. I could see the the signing key that it was sent. So this is sent from org one. This I'm currently looking at org two's node right now. You can see this is the private one. And just for completion, we'll look at this was the, oops, here's the broadcast to everyone. Okay, so that's pretty cool. But that's just, you know, my private network. My node is also configured to talk to a public chain as well. So I can, I can switch namespaces over to the Mumbai test network. And I can go down to my tokens dashboard here. I can see that I have one token pool configured. It has a hundred FFC in it. And it's currently, I've just minted it to my nodes address. But say I wanted to transfer some of that. Well, Firefly also has a really awesome swagger UI that allows you to use any of its APIs, just builds in here. So there's a lot of endpoints. I'm going to scroll down to the transfer endpoint here. And I'm just going to do a quick token transfer. So I'm going to do this in the Mumbai namespace. I'm going to transfer, we'll transfer 10. And this token contract has 18 decimals. So I think that's 10 followed by 18 zeros. Most of this other stuff I don't need. So this is going to be a transfer from my address, which is, I'm going to copy it from Polygon Scan in here. I'm not going to attach a message to this transfer. I could, there's a lot of really rich metadata capabilities with Firefly. I can attach a message. I can attach data to the transfer as well. Just some really awesome features there. Again, I don't have time to go into all of them today. But I'm going to transfer this to my MetaMask address. So I have, this is a completely different wallet here connected to the same public chain. I'm just going to copy this address here. I'm going to put it in the two address here. And that looks good. Hit execute. And, okay, so I got an ID for that transfer operation. It will take, because this is a public chain and that needs to be mined into a block, it will take just a little bit of time to actually submit that transaction. And while we're waiting for that, what I'm going to do is make sure that my contract is configured in my MetaMask wallet. So MetaMask on test networks doesn't always, it won't pick up new token contracts automatically. So I'm just going to paste the token address in there and I'm going to import it. And look at that. It already sees that I have 10 FFC. So Firefly made that super easy to do a transaction both on my private consortium and on this public chain. And it's super easy. If I go back here, I should be able to refresh. And there now we can see this is new. This transfer with data transaction that I just did here that's now on the public block explorer as well. So tons of cool stuff you could do. I wish I had more time to go into more features, but there's plenty of great material out on the YouTube channel, on the Hyperledger YouTube channel on Firefly and lots of great recordings out there. If you are interested in learning more about Firefly, please get involved. We have a channel on Discord as well. We'd love to chat with you there. Firefly is open source. Like all these other Hyperledger projects, the source can be found in the Hyperledger GitHub org. And yeah, thanks for this time today to present to this group and talk about blockchain interop. And it's my pleasure. And that's all I have for today. I don't know if I have time for questions, but that's all I've got. Thanks. Thanks a lot, Nico. That was super interesting. Firefly has a lot of really cool capabilities. Let's see if anyone has some questions. I can shout one first. You refer the multi-party mode. What are the security assumptions for the consortium mode? Are nodes supposed not to misbehave? Yeah. So I'm also just scanning through chat here. I see your message there as well. So a multi-party mode is typically used in a private permissioned blockchain. So there is some level of trust between the members of the chain there. So a new member of the consortium would be onboarded and other members of the consortium would be aware that, okay, this new company is joining our consortium. That's great. The first time a Firefly node joins a multi-party network, there's a process that it can go through to register itself on the network and it will basically advertise its identity. It will claim an identity on the blockchain using its signing key. And then from that point forward, all of the other nodes will be aware of that node's identity and be able to verify that future messages are indeed from that node. All right. Very, very good. Thank you a lot, Nico. I think we have... Let's have one more question. Nicholas asks, does Firefly allow communication with private and public blockchains? Absolutely. In fact, that's exactly what we just saw. I apologize if we were running through it too quickly, but the first two transactions that I did, the message broadcast and the private message, those were both happening on my fabric test network private chain that was running on my machine. So I cloned the fabric samples repo, I started up test network, and I connected Firefly to it. And I ran those transactions on that private chain that was running on my machine. The token mint and the token transfer that you saw me do, I did that transfer live, that was happening on a public chain. You could actually go look at Polygon scan on your own machine and see those transfers that I just did in real time there. So yeah, absolutely. Both public chains, private chains, at the same time, Firefly can do both. Right, thanks again, Niko, very much for the presentation. We'll, Peter, are you there? Yes, I'll share my screen. All right, thank you, Ron. Let's now keep going with the cacti overview. Yes, thanks, Niko. All right, so cacti. We heard a little bit about the latest and greatest updates from Rama and Rafael, but I just wanted to tie it all together. The bottom line is that we're trying to create a framework that has multiple components that people can pick and choose from. So it's not a one-size-fits-all kind of architecture. I'll mention that a little bit later down in the slides. Ultimately, what we want to aim is to solve the DLT fragmentation. There's a lot of distributed letters out there, and there will likely be more in the future as well. So if you're an organization, then you want to start using it. You want to buy into one of them. You want to have maybe a little bit of a safety net to try and figure out what happens if that particular ledger gets discontinued or you realize later on that some characteristics of it are not a good fit for use case, et cetera. So you kind of have to think about a little bit of an insurance policy, and the framework tries to help with that. And also the idea is to help people to help people not having to reinvent the wheel in certain applications where safety and security of the code is very important, for example, when finances are involved. There's a few stats here. This is a low-key flex. But the most important thing here is that there's three organizations, three different organizations maintaining the project. IBM, which is an Accenture, iRequest Accenture. And the way we govern pull requests to the project is that at least two of the maintaining organizations have to approve each pull request so that there isn't any room for anyone to run the project by themselves. It truly is a community effort. And we've been very explicit and focused on that from day one because we believe that that's the way to go. And then we also have contributors, such as Raphael, who's been awesome from day one since I met him back in the Hyperelectric Global Forum in 2020. So I just wanted to have a shout out for him, thank you Raphael. And then, yeah, that's the stats. Back on the fragmentation problem, I just like to expand on this because the common sense, like intuitive requirement from everybody if you asked them would be that all of these different ledgers, all these different pieces of software should just be able to talk to each other no problem. But then that's just not the case, even though intuitively as humans we would want it to be. And the hard part of it is that the number of ledgers you have, you need a quadratically growing number of integrations if you truly want each ledger to be able to communicate with every other ledger in the set of ledgers that you have. So that means that if you have 100 ledgers, you need 5,000 different integrations. And that's ready to get stuff about that whole reinventing the video question that I mentioned earlier. There's some general information here. We have a GitHub repository. It is in the process of being renamed. I have to frequently tie back to that. We are becoming, we have become cacti as of September. And there will be a direction set up for that. If you have a white paper, the section of that that I recommend the most is the example use cases because those are kind of timeless in the sense that as the architecture has changed some of the diagrams or sections have become a little bit outdated in the white paper but the example use cases are kind of forever. If you have a Discord server just to reiterate that you're very welcome to join there and ask questions. And the most important thing is that we do have daily pair programming calls every weekday. And if you want to join in there, you can. There's no any kind of requirement to qualify. And it is a short call. It's just 15 minutes. But if you have any questions in continuation to what is being said or shown today, then you can count on that daily pair programming call being there indefinitely. And that happens also on Discord. More details about how to actually join are on that link that I put there on the slide. A little bit more about the repository. We have a few slides here, but I will also share the actual directory structure itself because I have a little more to say about it. So the dev container is very important because that contains an environment that is known to work for building the entire framework and also for developing your own applications if you don't actually need to build the framework because you're not planning on contributing to the framework itself. There's also recommendations on how to set up your IDE. We like to recommend Visual Studio Code because most of the maintainers use this as well. And we have a big set of recommended extensions that make it even more convenient to deal with all the daily processes of contributing or using the framework. There's examples, there's packages, which is the heart of the framework. That's where 99% of the code is stored, but also in the very near future, there will be a few more directories specifically containing the code for Viber. And it's hard to show it right now because it hasn't happened yet, but we have been hard at work for months on this and it is very near, so keep an eye out for that. And by the way, thanks for Rama again for all the work that they're putting in there as well. And let me share my browser but on a different... Yes, so can you see the directory structure on my screen? Yes, if you could zoom a bit, that would probably be better. Like this? That was great. Okay, so this is the packages directory and the reason I wanted to come in here specifically outside of the slides is because we have this naming structure that kind of gives flat encoding, hierarchical encoding to the plugins. And for example, if you look at the structure here, you can see that there are keychain plugins and they are nicely grouped together because there's Azure, Google in memory, memory and vault. And then if you go down further, you can see that the connector plugins are grouped together as well. So if you're ever curious, if there's been a newly added connector that is supported, then here's a complete list, you can check them out. And then there's a lot more things. The most interesting one to me personally is the test tooling package, which is the powerhouse behind our testing infrastructure and also for development of applications, writing tests for those and for research purposes. And then there's also the API server, which is basically a shell that loads plugins into it at runtime. And that's what exposes APIs that you can use to deal with or leverage the features, some of the features of the framework. And back to the slides. So just a few very, very quick, very high level examples. One of them could be patient medical records being transferred or updated across different systems of different healthcare providers. I intentionally keep this vague because there's way too many details to expand on and I definitely don't have the time. So this is more of a showcase of what's possible. And then there's something with energy transactions. I know for a fact that there's a project within Hyperledger that does carbon accounting and they do use parts of Cactus for their operations as well. Development architecture, this is a very high level diagram and we're still figuring out how to explain all of this in the wake of us merging or joining forces with the Viva maintainers. But the bottom line is that there are optional components here. You can sort of pick and choose what you're going to use, what is that you need. And also you can pick and choose where your actual application code sits because it can be loaded as a plugin either into the API server or it can run on its own. And Rama already explains much of this and then much higher quality than I could. So this is really just what I wanted to highlight quickly is that it is a framework with a set of tools in it. So it is like a toolbox that has a hammer, a drill, a chisel and all those other stuff. And you don't have to use all of them at the same time. You can pick the one that you need for the specific task. This makes it slightly more complicated to explain on a slide like this. But when you're actually down in the trenches implementing something, it just makes it simpler to actually get the job done because the smaller pieces that you can fit together are easier to deal with than if all of this was just in one giant package deal, all or nothing style. And then I think I'll skip this one because Rama explained this very well about the relays, node server, the protocols and all that. And the development architecture, like I said, the most important part of that is test automation, which should put a very high emphasis on. Every pull request that we have gets tests executed against it in a way that completely pristine ledgers are being pulled up that are running in containers as part of the CI execution. And then the connector plugins, the keychain plugins, all of those things get tested and verified against these pristine ledgers that get set up and torn down automatically for every single test case. This makes it so that our test suite is pretty expensive and it runs for a couple of hours, which we're working on bringing down a little because it would be nice to have it run below an hour. But at the same time, it saved us from a million different bugs. And then a very quick overview at one of the examples we'll be showing is the supply chain example, which depicts a case of trees being harvested in the woods and then bookshelves getting made out of those and then finally getting shipped. And all of these things are done by different organizations who store and administer the data on different distributed ledgers. And the way we have the example application set up is that there's a singular UI where you can get the basic CRUD operations of all of these ledgers just by switching tabs within the application and sending API requests to the cacti deployment behind it. More on this later, I have to stop now because I think I'm pretty sure I'm out of time. So that's it and we have a break unless I actually have some time for questions. Hey Peter, I've been answering to some questions. Some people have some issues because they have M1s. My suggestion is what I'm doing currently, which is having a VM on a cloud provider hopefully will add support for M1 in the near future. Yes, that is correct. I have spoken to some people who managed to get it working on the M1 and we might have an entry for that in the FAQ, but I don't know if their solution was comprehensive and all-encompassing. As in they probably only got the basic build to run, but then other things were just not operational anyway. So the way to go is probably virtual machine. There's a lot of innovation happening in this space that is generic to software development. For example, if you look at GitHub code spaces, I think they're called that feature. You can open up a GitHub repository in a virtual machine that GitHub provisions for you on demand and you can have the build and everything, all your development run in there and you can either connect to that through Visual Studio Code or you can connect to it through a web version of Visual Studio Code straight from your browser depending on what kind of machine you're running on. It's not a free feature of GitHub, I believe, so you do have to pay for that, but I've seen it in action and it is pretty neat when you just literally have a few clicks before you have a complete setup up and running. The code spaces, right? Yes, I think it's called code spaces. I think Suvajit managed to get it working on code spaces. That's cool. Yeah, there you go. Thank you very much, Suvajit. So yeah, we definitely have the option to just run it locally. That's how I do it. I have a PC right next to me at home and it runs Ubuntu 20.04. That's how I do my development. If you don't want to put your credit card details in anywhere, then you can do the same, but also I just wanted to make sure that you know that there's a fallback that is very, very easy, very sort of developer-friendly. Yeah, please feel free to, if you have any troubles with the build, we can use these minutes to try to go around them such that you can follow through on the hands-on part, which is almost here. Okay, five asks if HypervisorCactus is a web application system designed to allow users to securely integrate different blockchains? Yes, basically yes. It's infrastructure and at least we try enterprise-grade infrastructure to integrate with different blockchains. So it allows you to create applications that utilize infrastructure, different blockchains, multi-blockchain infrastructure. Shane asks what's the building block behind the adapter? What adapter in specific? Sounds like maybe you meant the fever adapter. Maybe that's a question for Roma. Yeah, I'm not sure. Roma is here. To the best of my knowledge, the adapter converts the relay messages into specific blockchain transactions, but Roma would be the best person to answer that. Yeah, I was giving Roma some time to answer if he's here, but I think he may not be. So I'll try to chime in with the safe harbor that I may not be the most qualified person to answer. But anyway, adapter, kind of like Raphael's already explained, it is providing the basic communication towards the ledger for the rest of the code of the framework. It's one of those components in Viva that is very similar to what and the old Cactus project we call connectors. So there's ways we're trying to bring those together as well. It's just work in progress for now, how to actually do the code level modes of those components. So that's why for now there's Viva adapters and Cactus connectors, making up the project that is Cactus. Peter, may I share my screen on the? Oh yeah, absolutely. We still have three minutes. I'm just going to share a few tips before we start. So this is the code, right? All the instructions on the build, you run YAR and run configure, which takes a long time, already ran it, so I'm not going to run it again. And you have under the .vscode folder a set of scripts that are very useful for you to debug your plugins or to execute files. So for that you go to this file, template.launch.json, and you rename it to launch.json under .vscode. And what this does is that on VSCode it allows you to have access to these scripts where you can run the current TypeScript test file using TAP or using Jest, which are test runners, different test runners. And this will be very useful even for our demo when we're going to show you the code running and using debug points. So please make sure to configure those as well. All right, let's start going with part two. I'll try to make it short and sweet because we're a bit behind schedule. These are the different cacti components that are relevant for the demos that are going to follow. The first one, the first thing we want to talk about is the plugin architecture. So many things in cacti are defined as plugins such that the idea is for you to have a core plugin where you can join or glue other plugins that you develop. And this cacti core is supported by the API server or the API server is normally a plugin attached to this cacti core such that it can redirect calls. So some of the interesting packages as an example are, for example, the API server plugin, which is basically the API server backbone allows you to connect different plugins to it. It redirects the calls to the correct plugin. It basically does all of the heavy work on having these plugin architecture working. Then we have some utilities like loggers, cryptographic libraries like hashing creation of keys that's in the cactus common. And then we have the cactus core, which have the consortium plugins, some authorization, the plugin registry where you can aggregate different plugin references and so on. We also have, for example, a plugin that allows you to interact with hash time lock contracts. So for a specific contract that's deployed, let's say on Ethereum or on Bazoo in this case, you have a set of interfaces of APIs that you can use to interact with that contract such as deploy, lock, etc. You have a simple key chain that stores key value pairs that you can use to, for example, store cryptographic keys in a testing environment, not in production. We have different ledger connectors. One of them is hyper ledger fabric. And a package that I use a lot and I think it's very important is the test tooling. So it has test ledgers, databases, IPFS, containerization, etc. With this package, you can, for example, create a whole hyper ledger fabric network programmatically. Very easy to use, very easy to configure. Hyper ledger fabric, hyper ledger Bazoo substrate. So for the ones interested in the Polkadot ecosystem, which is quite nice. This is an example where we are creating a plugin registry. See that the plugin registry is an object that contains an array of plugins. And with this registry, you can actually add plugins dynamically and serve them into an API server. So this API server is the interface between your application and the different plugins that you are running within cacti. Okay, I'll try to answer the questions after. So we utilize open API. Sorry, let's talk about the API server first. So the API server is basically serving client requests. It's exposed, managed by a cactus node, what we call a cactus node. And it basically redirects calls to the right plugins. Okay, after you see the supply chain, exemplary to make a lot of sense what this does. Open API. So open API is a specification used describe restful web services or their APIs. The specification defines what are the endpoints that are available. Get endpoints, post endpoints, delete, etc. What are the different authentication methods? What are its parameters? What are the schemas of some objects you want to define? And we utilize these APIs, this open API, this technology to generate between quotes for free clients for the different packages. So I'm going to give you an example. This, for example, is the JSON API definition for the HTLC coordinator. And if you go to the swagger editor, and you paste these JSON on the graphical interface, you get these interface on the right, where you can make calls. Oops. I'm going to show you an example on the editor. Okay. So if we go to packages, plug in ledger connector fabric, and open API JSON, we'll have this file, we can copy paste on the editor swagger. I'm going to show you in a bit. Just notice that these ledger connector has different functionalities. It's one of the largest connectors, I believe. One of it is the transact. Okay, it allows you to issue a transaction against a hyper ledger network. It allows you to get a default gateway. It allows you to a lot of different things. And if we take the JSON that we have defined there, the swagger editor will generate these interface. So basically, we expose the different endpoints of the fabric connector, right? And we get SDKs generated with this application that we can, after that, use programmatically. Again, on the supply chain example, Peter will explain this, how it works. All right, about the open source project governance. So hyper ledger cacti is an open source project, such as many hyper ledger or all of hyper ledger projects, which means that everyone is welcome to participate. Participation is typically done asynchronously because they're contributors from all around the world. And it's a very welcoming community. We help contributors understand and pitch the different contributors how to develop for cacti. One of the things that I like the most about the community, so big kudos for Peter, are these daily pair programming calls, where basically, if you went to university, you probably had those office hours or doubt sessions where you can go to the professors and ask them for clarifications on some homework or assignment. It's basically the same, but for hyper ledger cacti. So Peter gives a bit of his time every day to help on different questions on cacti. You can go for the programming calls and he'll help you out. And there's also the maintainer meetings and contributor meetings where you can attend and see the project progress, basically, and also have some influence, contribution to the overall project direction. Another interesting thing is that contributing codes to cacti is done via pull requests. There's a whole process that's documented on the read me of the project, but essentially, you fought the project, you create a branch, you do your coding, you do one or more commits, typically one, and you open a pull request to the main code base. Then you define what is your contribution on the comments. And there is an iterative review process by the maintainers. Once two out of three maintainers agree to the code, then the code might be merged onto the main code base. And I should emphasize that this process is quite decentralized. So although cacti has support from centralized corporations, the decision making process is decentralized, as in the companies need to agree on what's good for the overall project. And so we require two votes out of N, in this case, three different companies at the moment, being in the maintainers list, for the code to be accepted. So you can see that these specific pull requests already had two approvals. There was one change requested that you have to address. And there are some reviewers that still need to check the code. Furthermore, to make the structure more robust and resilient, we have automated tests that are ran by GitHub every time pull request is made. So you can be more assured that the new code does not break the code that was there. So if you want to learn how to contribute and how the project is managed, you can read the governance document. We also have a list of interesting metrics on the project itself, for example, number of contributors, number of lines of codes, the number of meets, the number of issues, the time to solve issues and so on. One very nice thing that I like a lot are the test ledgers that are implemented in us, all in one containers. And basically they allow you to simulate or execute test ledgers programmatically very easily. And this is done in, let's say, two steps. The first one you have a docker file that implements one of the test ledgers. For example, the fabric calling one has the definition of fabric version 1.4 network and the fabric version 2 network. Then we publish these images onto GitHub so they are available to be pulled as docker images. And then we have a piece of code which is into cactus test tooling that pulls those images and executes those images. So the code here, it's basically code using docker APIs to retrieve the image and then to execute the image to manage the container and, for example, to delete it at the end. So in this way, we can instantiate the test ledger, execute the test ledger, have more code. We can test, for example, our connector, run some transactions against the test ledger and when we're done, we destroy the ledger. This is amazing because you don't have to manually run the network every time you want to test it. And if you want to have automated tests that create a ledger to a specific function, destroy the ledger, it's very easy to. And we use this extensively in all of our, or practically all the plugins that use a blockchain as the foundation, as the architecture, the infrastructure. All right. And I think that that was quick. We're going to go for the hands-on part of the workshop, which I think will be very interesting. Stick around. We'll have a short break again, 10 minutes. On the meantime, if you have any questions, please feel free. We're going to come back at zero, zero. Thank you, Raphael. Let's give it a few more minutes. If anybody is having any issues with building the project, please let me know. Feel free also to unmute yourself and to ask anything. Hello. Okay. Let's keep going with part three. Please try to build the project while we spend a few first minutes on the deployment architecture flavors, which Peter will present. After that, we'll present some simple applications that you can build using cacti. And after that, we're going to talk about the example supply chain application. Before the end, Andre will present on his summary internship that was implementing a CBDC use case using a protocol called ODAP on cacti. And finally, we're going to talk about the future of hyperlinked cacti and answer any questions you have. Peter, can you take it from here? Yes, please. Let me share my screen. Back on the modularity that I mentioned earlier, there's two slides here to highlight that further. There's a low resource usage deployment flavor and there's a production deployment flavor. There's many other possible setups, but these are the two that I would like to call out. One, the low resource usage one for development locally so that you can simulate something close to a production environment but with minimal hardware resources. And then a production example, which is an actual production example. And I think this diagram is a little too small, so I'm just going to reshare the desktop and then go to this page. Yes. So I'm showing the same diagram but zoomed in. What you see here is everything here is contained within the developer machine, which is a laptop or PC, whatever you have at home, within that you can simulate a consortium which is a set of organizations or entities who want to build some sort of blockchain TLT application together by collaborating and connecting their ledgers, their respective ledgers. And so that's what member A and member B stands for within the consortium. And then those members can have their nodes, which then are labeled as node A and node B. And then within those nodes, you can have API servers for both entities as in both members. And you can actually have multiple instances of those API servers because the API server itself is very lightweight and it can contain multiple plugins without much overhead. So the key thing to notice here is that this already resembles a pretty robust setup in terms of having multiple API servers for each member of each node or each node of each member. And this is where I plug in the upcoming supply chain, an example which does look similar to what is being demonstrated here. And I will show exactly why and how. And then on to the next slide, which is the production-grade environment. This is where we're talking about a data center instead of the developer laptop. But other than that, there's a lot of similarities if I can find them. Yes, so here it is. So here instead of talking about the laptop, we talk about data centers, load balancers. But other than that, if you look at the boxes, if you look at the labels, that's basically the same as the load resource deployment example. And this is very intentional. These two are very similar for a reason so that you can try out how a production deployment would work. Minus the parts that are really hard to simulate, such as an actual data center and the load balancer that has a domain associated to it and then handles full back and all that. And then the way, of course, this would work in a production development environment is that you would provision more hardware resources to these individual API servers instead of the API server running on, I don't know, a gigabyte of RAM. You could put it on a dedicated server that has 32 gigabytes of RAM, depending on what your use case is and how much memory that needs. So this is just to showcase and demonstrate that the framework allows you to play with these deployments. And we put a lot of effort into making sure that you can simulate as much of it as possible on a single developer machine instead of having to cross over into cloud provider territory and get built for a regular development time in there. And with that said, I'll pass it back to Raphael to talk about the whole world application. Thank you, Peter. All right. Hands on. The first example we built for this workshop is the Hello World example. It's a super easy, super simple example where we create an API server and a keychain memory plugin and then a server that interacts with the keychain plugin. Okay. You could use this for, for example, managing credentials that access the blockchains that you're participating in. Although this example is specific, it's not meant for production, so it's not secure enough. And also, generally, keeping your keys in memory is also not the best practice. So we also have keychain that connect, for example, to Azure or more secure, let's say, more production-ready keychains. These are some possible interactions you can make, but I'm going to demo it right now. All right. So I hope you were able to get the project building and also to set up the launch.json, right? So it's basically duplicating this file template that launch.json and renaming it launch.json. Then under examples, cactus workshop examples, which you shouldn't see now, by the way, because it's still a pull request. It hasn't been merged onto the main code base, but soon it will be, hopefully. You go to source main typescript and you have the three examples we're going to talk about.  You can check the readme for how to run it. So you can run this command to run the example, or you can use the debugger, which is what we're going to do. And then you can interact with the API server we created with these endpoints. So first, we import the API server from the API server package. We import the logger from our utilities plugin, which is cactus common, cactus core API plugin imports, and express to create a server and our plugin key chain. We create the logger, we create an express app, and then we have a main function and the client. Our application, our launch app function would be the one executed when you run this script, and it basically creates the API server and creates this plugin key chain, and also contains some endpoints to modify it. Let's put the breakpoint and run this. So we can actually run this with the tap runner. So we can see that we have an application bootstrap on port 8000. We have all the logs from the different plugins that are being initialized, and it should be reachable now. We can create another terminal and interact with our key chain. Let's, for example, create a new developer. Okay, so what we did is that we made a post request with Carl to our local host 8000, which is where our API server is running, namely to the set key cm endpoint, which is here. So we have a breakpoint, the code stops here, so we can inspect what's going on. So we basically get the key and the value, so the key is 1234, and the value is XYZ. And then what this does, and again, this is not secure because we're basically taking the user's input and sending it to our internal API without any sanitizing, do not do this, absolutely. Basically, setting the key value pair, and we can see what happens with the step into. So the step into takes us into the plugin king chain memory.ts, which is under the cactus plugin key chain memory plugin, and it goes directly to the set method. What this does is that it sets the backend to our key value, and this backend is simply a map. So as you can see, this is a very simple plugin. And then additionally, it updates the exposed metrics via Prometheus. So later you can inspect what have some alterations, some updates to this plugin in specific. Okay, we log that and we return. So if we go to our server, we see the new key value log there. Okay, so very simple. Then we can also perform a get to get the value from key pair, perform a delete, check if it has the key. So this is a simple example of how you could use the plugin key chain and build an application on top of the plugin key chain, right? Be mindful that this particular example does not require you to build the cacti project, right? You could have a single standalone project that has simply these imports. So the cactus common, the cactus core, the test tooling, that's tooling you actually don't need it for the whole world, but you need it for the test ledger, and then a few more dependencies. Okay, and with this code, you could run these scripts using the commands that are on the read me or the debug. So this is the first example. Any questions so far? Yeah, the workshop examples are still not on the main code base, but they are on this pull request that I'm going to put on the chat now. So if you go to that branch that is on my personal fork, the workshop examples branch, you'll be able to access that code, which by the way, you could do, I guess I can show you really quick, let's stop this. Okay, so if you, you need to do your own fork, right? And then you clone the project that then you get into the directory. If you do git remote add, and then let's say, profile and this link, which you can get via the pull request I've put on the chat, then you should have, you should be able to get that branch. So you add the remote, then you would do something like git checkout, profile workshop examples to get that code. That should be, that should do the trick. Then you need to run yarn run configure. And then you should be able to go to examples, practice workshop examples, and run directly using the debugger again or running the script as instructed here. It also, it does the same. It's again reachable. All right, that's it. Let's go for the next one. Do you mean the supply chain example? No, not yet. Or just your next slide. Okay. The next one, which one is the next one? It's the substrate test. Okay. Yeah, the supply chain is a bit ahead. So now let's go for the substrate test ledger. You see a typo here. All right, that looks better. It's not a Portuguese workshop version yet. What it does, it creates a substrate test ledger programmatically. Basically, you define the options you want for your test ledger, and then you create a ledger, and after these ledger.start, you can interact with the ledger. You can issue transactions, you can read the state. This is super useful. If you're developing, for example, a plugin that uses a polkadot or a substrate based blockchain, and you want to test it. So instead of you cloning from the official repo, the test ledger, running the test ledger each time you need to run the test and then deleting it and doing pruning, et cetera, you can just run this piece of code, and that's it. Let me show you the code. And this will also give you some insight of how complex it looks simple, but it's quite complex to make this all work. So this is it. We import the logger, okay, from cactus common. We import two packages, or rather two definitions from the test tooling, the substrate test ledger, and an interface for the options that test ledger takes. If we go into the test ledger options, you see that it takes several things, publish all ports, and I can show you what is in a moment, what's the log level for your test ledger, so you actually can run, you can have a logger on your test ledger in level info, which is typical for a demo, or you could use, for example, trace if you want to see every little step that the test ledger is performing. You specify an image name and an image tag, and what is this? It's basically what is the name of the image that the program will pull dynamically and execute, and it has a default. That's why it's not here, okay, because it will take the default, and a specific tag. Again, if you don't specify the tag, it will go to the default, but this is the image tag we want to get, okay. We want to see the logs from the container, so it's basically containers running containers, and then we have a mapping of environmental variables, environment variables that you want to give to send to the test ledger upon initialization, which is this map, so the container name is cacti ledger, the working directory is this, the Docker port is this, etc. Then we create the ledger object, then we start the ledger, and then we stop the ledger, okay, so it's, we don't do anything particularly exciting, but behind the scenes there's a lot of stuff happening. Let's see what happens. Okay, so the code has ran until line 38. At this point we have an object which is the ledger object. It has a class name, it has a Boolean thing if we are emitting logs or not. We have the image name, it's here, so we are actually going to pull the image from here, okay, and if we copy this and paste in the browser, we actually get here, so this is where the package is published, you can get the package also manually by doing this, but we do it programmatically, it has some downloads, contributors, etc. Okay, and then we start the ledger, and this is not looking very nice. All right, okay, so I missed some of the steps, but basically when the start method is called, we check if the container is present, if it's not, it pulls the container, it sets the environment variables, and it does this piece of magic which is docker.run, it creates a new container with the image we provided and with the options we provided. Okay, once it started, it emits an event. Okay, and now we have a substrate test ledger running on the background. We could interact with it. We have a polka.substrate connector as a pull request draft somewhere. If it's accepted somehow sometime, like I'm not sure when it will be specifically, we could test it against this test ledger, and then it stops the ledger. It runs the distro mode loads from the ledger. And just a quick tip, if you've ever seen this problem that Rafael had just seen with the debugger jumping into very strange places in the code that you don't recognize, then you most likely need to rebuild the code, the easiest way to do that is to run the configure script or the watch script, whichever. Yeah, thanks Peter. Yeah, that's it. Sorry, I'll stop talking now. No, no, no worries. Thank you. I almost forgot about that. Yes, that's true. If the code is not synchronized, if the JavaScript that is compiled from the TypeScript is not up to date, you'll see strange things happening. And you just need to run as Peter said, yarn and run, watch. And it will look for updates on your TypeScript files and do the compilation. So this problem shouldn't arise. It's good that it arise so we can already talk about this. You could also run tests, other test ledgers, of course. This is a more comprehensive example where you have a test from the fabric connector that runs a transaction. And the way to automate this is to create a cacti fabric test ledger and the fabric connector, which is what we're doing here. So we're defining a fabric test ledger. And we can run this. This is just not top. It's putting some hooks for the shutdown and so on, creating an API server that takes the fabric API. And then it's doing very, let's say, intensive, a lot of operations on setting up the connector correctly. So identities, key chains, API servers, plug-in registries, a lot of different things until it finally creates the connector. And then simply, you just need to use your connector to run a transaction. And these will go against the test ledger that you've initialized. So it's creating the test ledger now. And you can see that it also prints the logs from the test ledger docker container itself. So you can see that we are running a docker container that is running several docker containers, one for the yarder, one for peer, et cetera. So it's a lot of docker container operations. It gets really complicated really quickly. But the way I suggest you to start understanding cacti into more detail is to pick a plug-in you're interested in, let's say, the fabric one because I'm already here, go to test, typescript, integration, and pick a test. For example, this one. Then you can put the debug breakpoint and run it with chess and see what happens, see what packages are used, what is the code flow. And this will allow you to understand not only cacti, but also the underlying blockchains cacti uses. So we can see that the test ledger is already running because the fabric test ledger exposes 7054. So at this moment, we should have a test ledger in the background. If we do docker ps, we'll see that we have one docker container running and exposing a lot of ports. This is no surprise because in this docker container we are running more docker containers. Docker exec. Now what I did, I entered on the docker container with docker exec minus it and I listed the docker containers that it has inside. So not only it has a docker container for the orderer, for the peer, for the peers, for the ca, for each org, but it also has the chain code containers because we deployed the smart contract, the chain code onto this container. So we have like 10 containers running inside our main container. Okay, then we can run a transaction which calls the code generated by the open API and does a request against our connector. Let's see if we can see what happens on the connector because we don't have much time. So it should go onto the transact method. Okay, great. So in our test case, we called the fabric API. She's an API server that's calling the generated code from the open API and it's going for the run transaction v1 endpoint that under the scenes calls our transact method from, from our fabric connector. Okay. And the transact methods takes transaction request. What is this? We can see transaction request has an array of endorsing peers that's optional transit data that's optional, et cetera, et cetera. It has a channel name, contract name, invocation type, method name. So all the, the parameters we need to run a transaction onto fabric. Okay. It gets the contract from the, from the network. Then depending on the invocation, it does a call invocation, depending on the invocation type, it does a call or it does a send. What is our invocation type? You can see here, it's a parameter, invocation type, it's a call. Okay. Okay. So it basically evaluates our transaction. That's a success to true. And then it does a few more things that we don't need to talk into the data. Okay. And that's basically what happens. And it does more than one transaction. That's why it's going to the break point again. At the end of all of this, after some transactions, it, it does some basic testing. So that, you know, our response has an asset or the response we get from the server depicts an asset, what we define as an asset, that it has a defined attribute that is the owner, et cetera, et cetera. And at the end, it tears down the, the ledger, the test ledger did create. So if we go, if we do Docker PS, it still is, it's still here, but when the test executes completely, it shouldn't be. So it's gone, which allows you to create industrial ledgers at will. All right. There's one more example, but I'll go super quick, which is the consortium. Okay. These basically creates a consortium object from the core API and logs, logs that object, but we don't do anything particularly interesting. We're just exploring the different cat die packages available. We can also run it via the readme examples, like this workshop examples, source, main type scripts. Okay. So the logger prints the consortium object that doesn't get fully printed. But in any case, it's basically empty. Okay. It utilizes the consortium from the core API. So very simple illustration. Okay. Consortium, very simple. And now, now onto, onto Peter with the supply chain application. Thank you, Raphael. That was really great because it showed a lot of the debugging and how that's done, not just on the application level, but deep within the frameworks code itself as well. So I just wanted to highlight that because that was something that I was going to highlight as well, but now I don't have to. Let me share my screen real quick. Yes. So we have a supply chain app example. It comes with a readme file that has steps for different things. The absolute simplest that you can go with is if you just want to run it, then you can run it with a Docker container with a single line on the terminal. And then you can visit the web application and test it out. And then if you want to go deeper, if you want to debug it yourself locally, then these are the steps to do. I just did these in advance because it takes about five to 10 minutes depending on how fast your computer is. So after getting to this point, I have the JWT token here. And then if I go in the browser, then here's the user interface. And as you can see, there's three different menu items, which corresponds to the three different ledgers that we were talking about earlier that this application connects. So as part of the example application, we have three different containers running for Fabric, Quorum, and Bezu. And if you look at it, you can see these are the rolling minimatures that Rafael was talking about as well. So this is how these come in handy. And then basically what I want to demonstrate here is that you can create a record here just by pressing this button. This is a bamboo harvest. You fill out the dummy data and then it sends a request from the API client to the backend, which then will also use an API client on the backend to invoke the contract with the data that you passed in from the web interface. You see other parameters here, such as the signing credentials, the keychain ID, and the contract name and the method name. So you can see that this is either a Quorum or a basic transaction, something of the Ethereum flavor. And the reason why we have the API client call here on the backend is because the authentication slash authorization between the browser and this backend code happens through the JSON web token. And then once that happens, that's when here in the backend, the actual signing credentials for the chain gets looked up. And what this means is that in your web application, the code that runs here in the browser on the client side, you do not have to deal with managing securely the keys of the user. Of course, depending on your use case, this can be a plus or a minus, but in a corporate environment where you're developing a business application. Usually this would be considered a plus because the keys would be owned ultimately by the organization anyway, not the end user. Yeah, so I'll just let this execute. And then it returns success. And it shows that there's not two different harvest. We can go on to the bookshelves tab. And you can reference one of the items that were just created to administer the sort of foreign key relationship between the two letters. So now we're going to create a bookshelf that is associated with certain harvest. And then finally, we can create a shipment of a specific bookshelf. And this last one gets stored, I believe, on the Fabric ledger. And if you want to look at this under the hood, you can see in the developer console of the browser that it's just these very simple HTTP requests that get sent up to the API server, which is this host that's running locally. And so the cool thing is that you can try and debug this at home on relatively low resource usage scenarios. And you can modify it as you see fit. You can use it as a template for your own applications. And those don't have to be a part of the framework. The only reason why this code is just happens to be within the frameworks repository is because that's where we develop it. And this way we can execute test cases in an automated way through these examples as well. So that if we make a change and the example breaks, then we immediately know about it or almost immediately after we submitted the pull request and the CI render tests. So this is the high level overview. And then I just wanted to show that there's the UI code, which has a supply chain API API client object, which comes from this package that is called the business logic plugin. And this package contains the code that gets loaded into the API server next to the connector plugins. So this example has free API servers, all of which are loaded up with connector plugins for all three of the ledgers and also this business logic plugin, which is the one that ultimately handles the data management, which you basically see here one example of it that invokes the contract to store the data on the ledger. And if you want to write your own plugin, either for something like a connector interface or for actual business logic, you can do so. It's basically just about implementing these interfaces that you can import from the core API package. I think graph well also touched on these. So I don't want to say the same things again, but it's worth repeating that creating a plugin is very easy. You just have to implement these interfaces, which are also pretty simple. Basically, all this does instantiates endpoints with signing credentials for the ledgers and some other data such as the log level and the keychain ID. And then it buyers these endpoints up so that when the API server gets started, then these are there. And that's what makes it possible to reach these through the API client later on. And I think I'll just stop there with this example. If you want to read all of the code of it, or if you have any specific question about the code, then it's neatly organized within the examples directory as of right now. And you can just see example dash supply chain dash packages such as back end business logic plugin and front end. And the reason why we have a separate package for business logic is so that the front end code and the back end code can share certain model entities, for example, whatever gets exported from this open API file, such as the definition of a harvest or a shipment. Yes. So that was the supply chain example. I think I'm out of time, so I will pass identity. Andrea. Yeah. Thank you, Peter. Let me share the screen. Yeah. Can you confirm you're seeing the slides? We can see it. Yes. Yeah. Perfect. Okay. So we're going to divide this part in two different pieces. First, they'll present the ODOP or SATP. We'll explain that in a minute. And then a CBDC bridging use case between hyperledger fabric and a hyperledger based on network. So first of all, just a few words about me. I'm Andrea Ph.D. student from Lisbon. I have been researching blockchain for interoperability and contributing for CACTI for about a year now. And I'm really interested in collaborating. If you'd like to know more about not only this example, but interoperability projects, just feel free to reach out on social media. So what is ODOP or SATP? So Rama also talked a little bit about this. ODOP is under specification at the ITF, the Internet Engineering Task Force. The name has changed recently from ODOP Open Digital Asset Protocol to secure as a transfer protocol. This is why we still have these two names here. In CACTI, we still have the plugin with ODOP. So I will use that name here today. So ODOP is basically an asset transfer protocol that is suited to work either on blockchains or legacy systems. Right here, we're focused on more on blockchains. And the reason why we choose to work on ODOP is because of standardization. As of today, there are dozens or probably hundreds of interoperability solutions that are really targeted to specific use cases or specific ledgers, but they are not really extendable to other blockchains or other solutions. So we need to work on this standardization of cross-chain communication. And this is why we use ODOP. And again, as Rama told us in the beginning, this is not an asset transfer protocol that runs between these two networks directly. We leverage these two gateways or a gateway for each network. And each of these gateways has read and write access to the ledger. So basically, the ledgers trust these gateways to make operations. And then these gateways run in between ODOP or SATP. So basically, a gateway is divided in two different parts, a ledger-specific part, and then the actual protocol that runs with other gateways. In this case, it is ODOP or SATP. So this is the sequence diagram of ODOP. This is a lot of detail, but don't lose yourselves in so many messages back and forth. The key idea here is that in the beginning, as Rafael said, when we have an asset transfer protocol, we mainly have a lock and deletes in the source ledger where that asset is. And then we kind of recreate or create the representation of that asset in the target blockchain. So this is just an idea of how the protocol works. And the connection between ODOP and CACTI is that we have a cactus-plugging ODOP firms plug-in in the packages folder. So basically, you have the source code for this plug-in and you can instantiate gateways there. And the idea to instantiate the gateways is that you don't actually, there's this plug-in ODOP gateway. This is an abstract class which has basically the gateway logic, the SATP or ODOP logic there. So it cannot be directly instantiated. So what we need is to work on specific implementations of gateways, one for its ledger. So we have, in this case, we have implemented already a fabric and a bezel gateway, but it is possible to create more and connect it to other ledgers. And this might be a very good way for you to contribute to the project if you'd like to extend this plug-in ODOP gateway, connect it to another ledger, and you'll basically need to create smart contracts for that ledger and write the logic for the gateway to interact with those smart contracts. So how do we instantiate a gateway? It's specifically a fabric gateway, let's say. We have here, you know, name, DLTID, this is like the ledger compatibility, this gateway can say that I only talk to gateways that are connected to a DLT2. We have an instance ID, an IPFS path, this is just for logging purposes, not really important right now. We have fabric specific things, since this is a fabric gateway, signing credentials, channels, the chain code name that will be accessed. And then we have things that can be also extended, classes that can also be extended for specific use case implementations. Of course, we might need to do different checks if we have a supply chain example than when we have a CBDC bridging example. So now into the use case that we've built on top of this, and this was in the context of a hyper ledger mentorship project. I was the mentee, my mentors were Imre and Laszlo. If you want to actually see the CBDC prototype, you can check Imre's presentation on hyper ledger global forum this in September. But the idea here is that we have a core CBDC ledger based on a hyper ledger fabric network. This can be maintained by a consortium of central banks, financial institutions, and they manage the CBDC in this ledger. And then we have other ledgers. This can be retail businesses ledgers that serve clients through the exposure of some services to basically clients can access those services. And of course, they need to pay. And if they need to pay, they need access to the core CBDC ledger. So a user needs to be able to transfer tokens from one ledger to the other and the other way around as well. So what we did here was basically first building a bridge with hyper ledger cacti and implementing a gateway for each ledger. So as an example, we developed two different smart contracts or chain code in each ledger. We have the CBDC chain code or smart contract which basically encompasses the actual logic of the CBDC. So the CBDC is a central bank digital currency. I didn't said that. Just think of it as a token if you don't actually know a lot of that in detail. So we have this CBDC definition in this chain code. And then we have an asset reference chain code, which is basically a wrapper of CBDC that will be breached. And the idea is that Alice can escrow 50 CBDC. Let's say this 50 CBDC will be basically in control of the bridge. The CBDC chain code will create an asset reference that represents this 50 CBDC. And then Alice can use the ID of the asset reference to talk to the bridge, in this case, the gateway one and say, I want to bridge out this amount of tokens with this asset reference ID. So gateway one will know that. As we said, this will encompass locking, deleting, and then creating a representation of this asset reference in the bezel ledger. The asset reference smart contract knows what this asset reference is and knows that it needs to mint 50 CBDC to Alice's address in the CBDC smart contract. So Alice will now have 50 CBDC to use in a hyper ledger bezel ledger. And of course, if she wants, she can bridge back these tokens back to the CBDC core ledger. So how do we implement this in cactus? This is mainly the architectural overview of the thing. We have two API servers, as we have been seeing in the other examples, we can create API servers and connect different plugins there. And basically the endpoints that are exposed by those plugins will also be exposed to the exterior. And so we have the LDAP plugin, which is basically the logic of the gateway in this left side. We have a hyper ledger fabric connector that connects to a hyper ledger fabric network. We have the IPFS connector and the local database. Again, this is for logging purposes. I won't get into much detail on this bottom line here. And then on the right side, instead of having a fabric connector, we have a bezel connector to connect to a bezel ledger. And the idea looking a little bit into the code. And again, this is still a full request, but you can try it if you want. And Rafael gave the instructions to actually run the set the remote branch. So if you want to try that, there's this CBDC bridging app file. Basically, we define here the API servers and these API servers have these plugin registries. And these plugin registries are basically a set of plugins that will be exposed by this API server. So on the client side, we have the fabric gateway, the fabric connector, the fabric gateway and the IPFS connector. And on the server side, we have the bezel ledger connector, the IPFS and the ODAP gateway as well. And then when the API servers are running, we can deploy our smart contracts and we're good to go. We can try the application calling the different endpoints and so on. So there's actually an example, a front end that you can try. And I have here also another link basically for these instructions right here, if you would like to test that. It's in this file, in this readme. And the idea is that you will get a front end like this and where you can interact with the different pieces. And you will see the tokens going back and forth in the front end. And this will be, of course, interacting with everything that we deploy with the ledger connectors and with the gateways mainly. So yeah, this is it. There's actually a video here of that front end interacting with the things if you'd like to see that. And yeah, again, if you'd like to try that, if you have an issue, open an issue in the project or reach out to me on social media. And yeah, I don't know if there's any question I might answer. Oh, Andre, great presentation. There's a question. How does this work in terms of transaction gas costs, especially in the fabric side where native currency or tokens might not be mandatory? Okay, so the idea here is that in the fabric side we have the CVDC chain code. This is actually implemented as a sort of ERC-20 smart contract on the fabric side. So we kind of emulate that. And in fabric, we don't have that gas issue in the bezel side we have. So yeah, that's basically it. Of course, in the fabric side we need the authentication authorization. This is a little bit more complex than I showed here. It has multiple organizations with different authorizations for each one of these actions that can be performed either by the bridge or by the users. So yeah, it's explained a little bit better in the documentation. Any other questions? Exactly, Shane. It's that before destroying the asset on the source chain we have before a lock. So we lock the asset before and then we destroy it. It's like preparing for the actual destruction before burning effectively the asset. Yeah, I can put the link for the video here. Might be some problem. Yeah, that's a good question. That actually translates according to some work we have done to a metric called cross-chain cost where you calculate the sum of the costs of all transactions involved in this specific cross-chain transaction. So in the fabric side you don't necessarily pay fees. On the public ledger you pay fees. So the cost would be the cost of the interoperability mechanism of operating it, but cacti doesn't charge fees. Plus the cost of the transactions on the public network and on fabric which is zero. Hey there, guys. May I chime in for a minute? Sorry to interrupt. This is Imera from U of S. Just a minor note of clarification. This is intended to connect private ledgers mostly and if you have Beezoo on the right side in a private setting, save it, click or IBFT I believe is what's supposed to be for production now and fabric on the left side then this is not actually a question of gas and the like is just sizing your network for the given performance guarantees and essentially we can do that for fabric as well as Beezoo. So while on the technical level there's a gas cost on the right side it's really just a technicality stemming from using Ethereum for setting up a consortial network. You can try this whole thing with a public network but I can't really imagine a central bank who wants to see their assets on a public network bridged out. That wouldn't be a long-running bridge service. Let's just say that. Yeah, exactly. Thank you Imera. That's pretty on point. We are out of time so the question is, Sean, can we go or should we just have a hard cut off? There's no hard cut off. No, no, this is your workshop. Peter and Rafael, this is awesome and if we want to keep going we can keep going. There's no hard cut off. The clock is not going to shut down this Zoom so if there are more questions or if you guys want to present more clarifying information by all means this has been a great workshop so I don't want to stop it. Okay, then I shall finish with some of the rest of the slides about the roadmap in one second. Right, so the future of the project is to grow the community that's the most important part we need more contributors because of the aforementioned scaling issue with lateral fragmentation so we need your help and that is a few items feature-wise that we are planning on implementing. It's mostly a personal wish list of mine so there's other items on the roadmap from other maintainers and the roadmap is constantly evolving as we are hammering out the details especially around how to manage the joining forces of the beaver and former cactus maintainers. So with all that pretext the first and most important thing right now is to finalize the version 2.0 design and technical architecture which will include asset exchanges asset transfers in some sort of as ready-made or as out-of-the-box as possible flavor and I mean as possible because or I say as possible because it will have to have some sort of setup step to deploy the framework on the ledgers to have actual asset transfers and asset exchanges that are atomic most likely these will be based on HDLCs and then once we figured out that what goes into 2.0 then we will issue a 2.00 alpha release which will be the first release ever that will contain the beaver and the cactus source code together which is what makes up cacti. Identity is very important and we have not had enough time to work on it. We do have some things like the keychain plugins but I personally want to take it much further. I want to be able to bootstrap consortiums with different trust anchors meaning that the original key exchange of the nodes would be able to come from different sources such as an indie ledger or chasing web signatures x509 anything else. This also has to be a part of the plugin architecture in the sense that I don't want any of this hard-coded I don't want us to find ourselves in a situation next year where we sort of picked a winner quote unquote and then realized later on that we should have picked that other winner. So this also has to be hot swappable in the sense that different implementations can be contributed anytime and the different implementations can be swapped out anytime in the existing deployments as well not just new ones. We want to add support for corridor version 5 which I believe has been released in sometime the past few months they definitely had a release candidate but I'm not sure if and when exactly the actual GA release happened but regardless of that do you need to have support for that and then documentation which is a feature good documentation is just as important as the actual things that the framework can achieve because if you don't know that it can do those things or if you don't know how to use them then in the end the added value will remain zero. So we do have to focus on the documentation I want the reference architecture documented well actually the CBDC example is shaping up really nicely as you can see from Andrea's presentation and I do want a public test deployment something sort of a playground environment that doesn't do anything production worthy but it allows people to look at it have a feel to it and maybe even write some code against it and see how it would work. Performance is an overarching concern and the way we should deal with that is that the CI should have a comprehensive set of tests specifically verifying that there was no regression in performance in the change that is being introduced by a pull request so that if I added however many new lines of code to let's say a connector plugin and somehow it's now 50 slower to run a transaction through that plugin then that should actually get me a rejection on my pull request or not necessarily a full rejection but a call to action to fix the performance issues that I'm trying to introduce. We do have some of this in place but it's very rudimentary compared to what I want us to have so that's definitely on the roadmap as well and we have a call to action here which is just a bunch of links and me saying again that we are looking for contributors and you're always welcome to join the pair programming sessions and I'm not sure if Rafael wanted to show the rest of the slides or if he wanted me to talk about these things. You can go ahead Peter that's fine okay so or I can talk and you can pass the slides too it's not very yeah so thanks Peter. Another call to action is if you're researching or learning about blockchain interoperability if you're a student if you're interested in the area cacti is an excellent platform and cactus and weaver to do research into these areas so we have a series of papers that were published or are on its way to being published on different plugins of cacti or interoperability architectures or systematizations for example the example the CBDC example that Andrea presented already yielded to papers to be submitted and you know since you have such a diverse community with different backgrounds I think it's an ideal place to do research and to learn which we welcome you all please next slide furthermore besides research papers that were already some pieces made presented and accepted on cacti or cacti components in this case two of them from technical legal which I had the pleasure to to help with and there are several ongoing too next slide please more papers slash resources those are mainly from weaver folks they have a very interesting paper which is very foul observation of permission ledgers I really like that paper because it seems to solve or propose a very compelling solution for interoperability across private blockchains which is kind of tricky because their state is not public or open or transparent by default so you need to do some clever tricks to allow for proof verification on on the counterparty blockchain and the presentation on UI by Suzumu on their technology they use IPC so they're mainly interoperating across public blockchains but in specific cases where you don't have this transparency by default it's a bit tricky so please feel free to collaborate with us you literally just need to show up on on the channel and say you want to contribute or to learn into more detail we are researchers programmers and we do different tasks we do a bit of evidence please reach out if you're interested next slide please a huge huge huge thanks to Monica Gomez which did a lot of the heavy pulling to put these workshop together and very very visually appealing as you can I hope confirm and also to Abinav who did a preliminary version of the hell world example next slide please finally some more acknowledgments by the way a huge thanks to Suzumu from UI to Rama from IBM to Nico from Firefly for and to Andrea Augusto from Technico Lisboa for presenting their use cases their technology their view on cacti and related projects huge thanks to Sean and David for helping a lot to organize these workshops very effectively and with a lot of support from Hyperledger and a huge thanks to Peter for being an excellent mentor and running the pair programming calls which are immensely valuable and to push the project a lot and a huge thanks to the other cacti maintainers of course okay now Q&A let's see if you have some final questions for us to wrap up and thanks everyone of course for attending and for your patients and for speaking with us for three hours it's definitely not easy yes more than three hours thank you very much so feel free to unmute yourself yes I think Daniel had a question in chat why use cacti over Firefly what are the differences what is the primary purpose of cacti and how does it differ from Firefly and I think we lost Nico earlier because he had a conflict so he couldn't stay throughout the entire session Daniel if you'd like you can also post that on Discord either on the Firefly or in the cacti channels and I'm sure there'll be a Firefly person around who's able to answer that for you yeah I think that's I can try to answer from cacti's perspective I think that's a very good question because there's a lot of synergies between the projects since Firefly is also trying to abstract infrastructure so you can focus at the application level for my understanding cacti has more connectors it's focused a bit more or maybe a lot more I don't know in detail on the infrastructure level whereas Firefly is more focused on the application level as you could have seen for example they have really nice user interfaces that should come for free for for their for free maybe not for free right but allows you to deploy user interface more easily as opposed to have some templates and they have a set of plugins around the asset transfers and the decentralization of the consortium so I think those folks are more focused on the higher level part of the stack whereas we focus more on infrastructure my good feeling is that there are some synergies that could be probably better explored so we'll see if at some point we cooperate more closely with our fellow developers thanks for answering that Raphael I I just agree I'll pick another one just considering different languages of viewer and cacti is it right time to contribute to code as by manage so I will say yes it's always the right time to contribute code if you have worries about putting in effort into a feature or an improvement that you're not sure if it would be accepted or welcomed because of for whatever reasons then what you can do is open an issue first and say I think this feature is missing or I think there's a bug there I would like to fix it I would like to fix it or implement it in this specific way and then ask the maintainers to chime in on that which would then sort of give you a preliminary approval on the conceptual level this doesn't guarantee that your pull request will go through the first time you submit it but it does guarantee that no one will come back and say oh I disagree with the idea in general so then if you go through this little extra step in the beginning to get the buy-in from the maintainers in advance then you can be sure that that verse you would have to re-factor some things in your pull request that some maintainers may disagree with but not on a conceptual level so no one would say then oh we don't want this at all because you already asked them and they said that they do want it thanks for supporting the the answer Peter sentence awesome um Elizabeth has a question Raphael will there be a way to keep assets locked on a public blockchain uh so Elizabeth uh yes uh sometimes unfortunately by accidents so for example we we have seen that that the parity wallet hack where the hacker basically re-initialized destroyed a smart contract that held thousands of heath resulting in the destruction of a lot of money uh but the logs we're talking about are hopefully not those but it always depends on the implementation so bugs the fact that there are bugs in software might lead to permanent local funds in the case of a bridge we basically want the bridge contract to act as an escrow so you send funds to that smart contract and the bridge keeps the funds so the funds are not are are not locked per se they're held into the bridge account that's what we define by a lock and hopefully the bridge can uh on the other blockchain on the counterparty blockchain the bridge contract can recognize that there has been a lot a successful lock and means some tokens for you that are backed by the tokens that you locked okay and this happens with the help of relayers with specific protocols for interoperability but the general way it's done is like that now there can be a variety of attacks to this scheme that allows you to for example mint assets on the counterparty blockchain even if you didn't lock assets on the on the first blockchain and those are cross-chain attacks and those are the ones responsible for the cross-chain acts that happen to bridges and has resulted in more than one and a half billion dollars in damages only in the last few months so it's a quite serious problem and that is why interoperability re