 Hi, can everyone hear me okay in the back? Awesome. Well, welcome. I'm going to jump in. We've got an action packed 40 minutes for you all. We're going to be talking about Firefly. Just to help me, could you just raise your hand if you've heard of Firefly before? Okay. Can you raise your hand if you're somewhat familiar with what Firefly is and what problem it's solving and how it could help? Okay. Awesome. You're in the right place. Let's jump in then. My name is Steve and I'll be covering the first half. I'll take you through some slides, an overview of Firefly and then Niko, my teammate who's one of the Firefly maintainers is going to drive a live demo, and we'll see what the demo gods have in store for us today. Yes, so I just said overview demo. Hopefully, we'll have some Q&A time and if not, we'll hang out upfront to chat. So big picture, right? Over here on the right is the wild, wonderful world of Web 3. Kind of decomposed it into some different bubbles that probably make sense to you. Over on the left is your enterprise, the company that you work with and you have a set of existing systems and you want to build a Web 3 application. What this has looked like before Firefly, which I'm calling the Gen 1 era of Web 3, of enterprise blockchain, of these early blockchain applications, is to connect out to Web 3, really a lot of the Gen 1 is focused on that consortium bubble up there, and to do that, you may have stood up your own blockchain nodes, you may have used a Cloud Vendor service or a service from Kaleido or a company like us. There was a Web 3 infrastructure provider. So you got the node, great, but actually you're only 5 percent of the way there, because your application, the little bubble, the Web 3 applications that you want to build, still need a whole lot of software, a whole lot of code written to get your end-to-end solution up. That code is pretty Web 3 specific code. You need to solve a lot of problems, and I'll get into that in a second. By contrast, Firefly has come along for Gen 2. In Gen 2, building your Web 3 applications is a whole lot simpler. Not only that, but Firefly can help you to do more than just be-to-be consortium style blockchain, it can help you connect out to public chains and do lots of other things in the Web 3 space. This is a lot more scalable approach. A lot of the companies that we work with say, hey, we have 30 Web 3 use cases, and I always ask, how many are you working on right now? Well, two, but we have 30. Getting to a much faster build-out of the applications, a lot higher quality. We just saw that there was an opportunity for a new open-source project to accelerate and drive standardization across the board. One thing that we noticed that if you look first on the right-hand side of this slide, what Firefly is not, is it's not another blockchain protocol. We think the world has enough of those, the world has enough chains out there and so forth, and that's the dotted line here. But in between that and your business application, is a whole software stack. Like many other areas of IT, there's always a software stack. When we looked at the space within Collider, we noticed there wasn't a single open-source project out there that was trying to accelerate building the whole stack. What we saw these Gen 1 projects, we saw them moving so slowly because all the budget for the project got sucked into building these middleware layers custom, one-off. Almost as a side effect of trying to build your app, you had to build the whole stack and it was just really inefficient. The Clado actually seeded with an initial contribution into Hyperledger. Now, many organizations are involved. It's a very quick-growing project moving forward. To give you an example of some of the complexity around building your application, many of the considerations around how to build a decentralized architecture into your application, idiosyncrasies of the protocol, how to handle privacy. The orchestration of transactions on these event-driven systems, doing that reliably, seeing a transaction through end-to-end. These are pretty hard problems, and Firefly handles them out of the box. You now have the wisdom of the herd of lots of other companies, using this code, hardening it, all the benefits of an open-source project. Firefly is multi-protocol, as you see on the right, so we sometimes say, we're not trying to be religious here, we understand there's multiple protocols out there, and we didn't pick one. We actually are shaping Firefly to help insulate you from that choice, and even give you flexibility if you need to evolve your protocol choice going forward. This is a logical architecture for Firefly. You can see at the middle of it is the core, that orchestration engine. Again, blockchains are event-driven systems, and so just the complexity of getting a transaction maybe into a pending pool, mined into a block, written to a chain and understanding that whole process. Your application not having to deal with that is a big relief to the developers on your team. The orchestration engine at the core of that, but you can see there's a whole framework of functionality that's built around that. The three colorful boxes at the top are the API pillars. There's an application, a set of APIs for building apps, with some cool capabilities there, which I'll dig into in a minute. The second pillar is for what Firefly calls flows. So what we see a lot of times, especially in enterprise applications, is not just on-chain activity, but off-chain activities as well. For example, data exchange going from B to B. There's a whole set of APIs and patterns for how to coordinate off-chain and on-chain activities. Those are called flows. Then finally, digital assets. So an API pillar around interacting with digital assets easy and simple. So minting, transfer, burn, the standard tenants of managing a token, having built-in wallets, plug point to bring your own wallet, making things like transfers, simple moving from party to party. In addition, in the digital asset space, the state and the data parts of the core work hand-in-glove. So if you're running Firefly in gateway mode and you're connecting out to polygon, and there's 2 billion NFTs out on the polygon chain but you only care about 1,000 of those, Firefly becomes your system of record. It's tracking the state out on all the chains only the state that you care about. So it almost becomes your world view and helps you to build smart intelligent applications. So I'm going to step through a couple of these concepts in just a little more detail and then we'll get on to the demo. On that first pillar of APIs that building your apps. So one of the things that Firefly does that's pretty cool is you can teach Firefly about the smart contract that you've written. So when you feed in your smart contract into Firefly, it hands you back a set of REST APIs, so that when you build your application, you can just code to REST APIs. That allows any developer on your team to build Web3 apps. The Web3 specialty then is constrained, adjust or it's isolated just to the developer who's writing the smart contracts. This allows your team to scale and get solutions out more quickly. So another concept here is acting as a gateway. So once you're coding to these simple APIs, you can rely on the orchestration engine that's inside of Firefly to do all the heavy lifting for you. So you say, hey, I want to mint this token, or I want to put this transaction onto the chain, and then the 100,000 lines of code of Firefly that manage these sorts of things kick in. Again, Firefly can connect to multiple chains, so this scales out to, hey, I have one project that's based on fabric, I have another project that's based on Ethereum, Firefly can help simplify both of those projects for you. Moving on to the second pillar, flows. Firefly now in V.1.1 can be started up either in consortium mode or it can be started up in gateway mode. If you start Firefly up in multi-party or a consortium mode, it will instinctively want to connect out to other Firefly nodes in a consortium style B2B network. You can see that Firefly has both the blockchain rail that it knows how to interact with, as well as other off-chain rails. So things like IPFS for a shared storage layer, and then also a peer-to-peer messaging layer. So Firefly can connect or gate or be in a private channel off chain to exchange data or or gate or D in a private channel to exchange data and so forth. Firefly has an address book built into it as well. So all the different identities, public-private key pairs, all of that is made simple for you within the Firefly engine. So as the network dynamically changes over time, the address book in this B2B network is going to be kept up to date. The implementation for this is even based on the DID spec. So the community is looking towards the future and trying to pull in all kinds of cool technologies. So then moving on to the third pillar, just for a minute, thinking about digital assets here and talking about that. Here, the focus of the community is really on scale and thinking about institutional scale for digital assets. Standing up a single coin is one thing or minting an NFT is one thing. But really thinking about institutional scale opens up a whole new set of challenges. So I was mentioning a minute ago, things like automatically tracking the history of a token. So if you mint a token through the API, it automatically gets registered in the database that's part of the Firefly stack, and that token history is tracked for you. You can also point Firefly, for example, out of public chain and a token that already exists and say, hey, pull in all the history of this token and track it going forward. So almost like an audit trail or the lineage in the history of a token, and then you have an efficient way to query that going forward. As you know, blockchains can be pretty slow, when you ask them questions, they're not really optimized or designed for that. So having all of that state tracked for you in an efficient and fast query way can be pretty handy. Then on wallets, if you're in the financial services space, wallets are a pretty big deal. I tend to call the space custody. Who's managing the keys? And Firefly comes similar to many areas of Firefly. It comes with a wallet or implementation for that, but it's also designed to be pluggable. So the community is looking at things like, well, what are some popular wallets out there? Can we have plug points or integrations into all of those wallets? It's something again that's important for institutional scale. I think we're going to do questions at the end just due to the time. Okay. I'm going to skip forward just a bit here, and there are out on YouTube longer form overviews of this. But I did want to touch on Firefly 1.1. So coming out this week is Firefly 1.1 time to the event. There are a few new things that I want to touch on just for a second. To give you an idea of the history of the project, it was launched initially as a hyperledger lab mid-2021. It was then promoted a few months later to project status within a hyperledger again, due to the amount of interest and activity and engagement through the community. Firefly, it was seated by code from Kaleido, which really was several years old and things that we've was already in production code that we used for a number of our clients projects. It moved to 1.0 status this last April, essentially reaching ready for production use or acknowledged for production use, and then just this week, Firefly 1.1 is being cut. As it stands today, there's 19 repos and about a quarter million lines of code and growing over a thousand new commits came in between 1.0 and 1.1, so a very active and growing project. What's new in 1.1? A few things. I talked about how Firefly now runs in, both can run in either consortium mode or gateway mode. The idea with gateway mode is that you can connect out to many different chains and have Firefly act as a gateway for all of those. In conjunction with that, Firefly now knows how to connect to a number of public blockchains through a new connector in the connector framework layer called EVM Connect. If you're familiar with the Ethereum VM, any EVM-based chain Firefly now knows how to connect with, and the additional complexities of public blockchains, things like gas management and other areas of complexity, are now also baked in to EVM Connect, so making it simple to connect to public blockchains, and there are very many EVM-based chains out there. It's almost the de facto standard. There are a number of guides in the docks for things like Polygon and Optimism, or Arbitrum, Ethereum itself, and more. Namespaces, so Firefly now can run multi-tenant, so what we've seen in large organizations is, you have different teams building different use cases, and you want to keep those isolated. Now on Firefly, there's a degree of isolation, that's called Namespace, which if you're familiar with things like Kubernetes, that's an isolation technique on a lot of tools, and now it's there on Firefly. There's a new connector toolkit, so it's really easy to build your own connector. The community is looking at self-service. I know that there are teams out there looking to contribute a connector. Hey, we're a layer one chain, it would be great if Firefly could connect to us. We want to contribute a connector. So expect to see more growth as far as the number of connectors out there going forward. And advancements in some other areas as well. So with that, I'm going to wrap up the overview portion, and I'm going to turn over Niko to drive the demo. Thank you, Steve. Is this Mike on? Can you guys hear me okay out there? Okay, great. Hello everyone, my name is Niko Geier. I'm a maintainer on Hyperledger Firefly and the open-source community leader. I'm also a software engineer at Kaleido and I'm really excited to talk about Firefly 1.1 and some of the really exciting new features in it today. I see a couple of people have come in. There's still some seats if you guys want to take a seat, you're more than welcome to. So thank you, Steve, for the great overview on Firefly. What I want to talk about today is some of the new stuff. So I'll very briefly touch on existing features and how they relate to new features. But I'm not going to spend a lot of time demoing stuff that you may have already seen. If you've seen a Firefly demo because I like new stuff. So what we're going to look at today is we're going to see a Firefly Supernode and I'm running a Supernode on my laptop. I've used the Firefly CLI and I've set up just a local development environment. So that local development environment is using several different plugins. I'm using SQLite database, I'm using the data exchange plugin that comes out of the box, IPFS for my shared storage, and I'm using FabConnect. Jim Zhang gave a great session on FabConnect a little bit ago and how it makes using Hyperledger Fabric easier and providing a nice API layer for it. It's also a blockchain connector for Hyperledger Firefly. So my Firefly core talks to FabConnect, which talks to a fabric network that's also running on my laptop. I've set this network up like a consortium. So there are actually multiple Supernodes running on my machine that represent other organizations. So you have many different organizations collaborating with the same fabric network and we can exchange data, we can pin data to the blockchain, we can privately exchange data all through our Supernodes. So this is an example of what Firefly has done since launch, which is allowing you to build a consortium that uses blockchain as an integration point, or a multi-party network as you may have heard us call it sometimes. So how does this change in 1.1? Well, Steve mentioned that now you can have multiple namespaces simultaneously. So here's the rest of my demo. I'm going to be using the same database, I'm using the same Firefly Supernode, but I'm actually going to also be connecting in a different namespace to an EVM Connect blockchain connector, which Steve also mentioned is the new EVM compatible blockchain connector for Firefly, uses a new open-source Ethereum signer called Firefly Signer. It's an Apache 2 very enterprise-friendly license, and it's available as part of the, it can be used standalone or it can be used as part of Firefly as well. This stack is actually connected to the Polygon Mumbai Testnet. So what I'm going to demonstrate is being able to run transactions privately in my fabric consortium network, and also interact with tokens or execute other smart contract functions on a very public permissionless Polygon Testnet. So hopefully that makes sense. I think things make more sense, like seeing pictures is great, but I like seeing things in action more, so let's actually do it. All right, so I'm going to slide over here, and okay, so this is, I've got two different color browsers to represent two different Firefly nodes, two different organizations in my network. So over here, you can see in the right-hand corner, I've got node one, and over here, I've got node zero and they're just color-coded, so just visually so you can see the difference. If you look closely, you'll notice that the port number is different. So I'm running two different super nodes on my computer to simulate an entire consortium running here, so I can build apps and use the consortium. So if you've seen a Firefly demo before, I'm just going to very briefly touch on some of the things you can do with Firefly. The Firefly command line interface has set all of this up for me. I'm happy to chat through how that works later, but I wanted to skip all that so we could get to the good part. So everything's already set up and running. The Firefly command line interface also sets up the Firefly Sandbox. Sandbox is a great tool for being able to just really quickly in a browser, use Firefly. I can click a couple of buttons and try out different major features in Firefly. So we talked about the three pillars earlier, and right across the top, we have tabs for messages, tokens, and contracts. So those are the three main sets of functionality, three main sets of APIs within Firefly. So I can send a message. I can broadcast a message. We'll say, this is my demo. I have a hard time typing and talking at the same time. I don't know if you guys have that too. I hope it works. All right. So I'll publish that. This will run a batch pin transaction on my fabric network. So I could go hop over and look at my fabric nodes, and I could actually see that that got mined into a block on my fabric channel, that these Firefly nodes are configured to use. I can go to my Firefly Explorer, and I can see that I just submitted a transaction here. My message was confirmed. I can go look at the off-chain data. So when you broadcast data in Firefly, the payload itself remains off-chain. The fact that something was broadcasted is what goes onto the chain and triggers an event, which triggers other Firefly nodes listening for that event to know, hey, I have a message from somebody. Let me go retrieve that payload from IPFS and see what it was. So I can look in data, and I can click on this one. Here's my demo. Hope it works. Let's go check out the other Firefly node running over here. So we'll look at the green one or node one. So we can see that there was a message that happened here as well. Let's go check to make sure we also got the data payload. We can look under off-chain data and yeah, this is my demo. I hope the rest of it works too. So this is nothing new from Firefly 1.0, but I just wanted to demonstrate that everything that was there is still there, but here's what's new. So now in my Explorer, I also have this dropdown up here and this lets me switch between different namespaces that I have in my Firefly node. So my Firefly node in this demo is the red one. The imaginary other organization that I'm communicating with is the green one. So the green one only has its default namespace, which is the one that's configured to talk to the fabric network, our consortium namespace. If we go look at my red node, I notice that I have the default namespace that's connected to fabric. I also have a polygon namespace that I've set up. If I hop over to that polygon namespace, we'll notice that my node diagram looks different because I'm using a different set of plugins. We'll notice that there's some different pieces of data in here. Also before this demo, I went ahead and I deployed an ERC-20 contract to Polygon Testnet. We can hop over here and we can take a look at that. So here's the contract address. This is public. You can go to this URL right now on your machine and you can see my contract. You can see that I deployed it. We can see that it was first in this particular transaction, that particular block number. Then what I did is I went and I created a token pool in Firefly. That was super easy. I just went to the Swagger UI, scroll down here to the token pool endpoint. There's a lot of these now. I'm just going to search real quick to find it faster pools. So there are a set of endpoints. If you're using the default namespace and there's a set of endpoints where you can fill in a custom namespace, which is what we had to do. So I just came down here and I did a post to, yep, there's tokens pools and that set up a token pool. Now what that does is it uses Firefly's token connector to go index the chain. So Steve talked about earlier, block chains aren't necessarily efficient for queries that they're not designed to make. And one of those is, get me the entire history of this token and everything that's happened on it since the beginning of whatever block number that was that we just looked at. So when I did that earlier in the day, what happened in the background was Firefly set up a job through the blockchain connector through EVM Connect that went and it started at the first block and it said, okay, I'm going to go query the blockchain and I'm going to build that whole history. And so that's already happened. So if we go look in our dashboard, we can see under tokens, we can go see our token pool that's here. And it has, so I've deployed this thing. I called it FFC, Firefly Coin, if you will. And there's a hundred of them. I don't know, maybe that font is, is it hard to read in the back of the room? Okay, I'll zoom in a little bit here. Maybe not that much, okay. The response of you I was kicking in there, I thought I was on a phone because I zoomed in so much. So yeah, so there's a hundred of them here. We can see that there was one mint action that's taken place and that's it. So to demonstrate that this really is a public chain and that this all really works and I can actually transfer tokens with this, I have a wallet on Polygon Testnet that I'm gonna transfer to. I would love some audience participation though. Just by happenstance, does anyone have an Ethereum wallet configured on a Polygon Testnet? And I can give you some FFC right now if you want as a souvenir. Andrew, do you? All right, never mind. I'll send it to my MetaMask, that's fine. It was a long shot, but okay. So over on this other desktop over here, okay, I've got my MetaMask wallet. I have some, this is configured to use Polygon Testnet. I don't really own 200 Matic. Well actually I do, but it's in a different wallet. So this one is configured to use Polygon Testnet. You can see I have zero FFC though. So I've told MetaMask, hey here's my contract address on a Polygon Testnet and what I'm gonna do is I'm gonna copy my account address here and I'm gonna go over to my Swagger UI and I'm gonna go down to the transfer endpoint and I'm gonna create a token transfer here. All right, so I'm gonna hit try it out. My namespace is Polygon. Most of this I don't need. So I'm actually just gonna type out what I do need. I'm gonna transfer it to my, this is my MetaMask address. I'm gonna transfer it from, let me go look that up here. My, yeah, so this is the address that I use to deploy the contract. It's also the address that my Firefly node is configured to use. So I have the private key for this address on my Firefly signer. That's kinda how that works behind the scenes. So I'm gonna copy this address here. So this is the address that owns the currently only existing 100 FFC that exist on this chain and save this from this address and then we're gonna say the amount is, so for the amount, just quick background information here if you aren't super familiar with how ERC 20 works. There's a configured number of decimal places. So the Ethereum EBM only works in integer math. So if you wanna represent a decimal, you have to add a whole bunch of zeros to everything and then divide by the appropriate number of decimals. So my contract is configured to use 18 decimals. So if I wanted to transfer 10, I would actually do 10 followed by 18 zeros. So that's why I'm gonna type a super long number here. One, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13, 14, 15, 16, 17, 18. Okay, so that should transfer 10 tokens and then we will hit execute. Okay, we got a 202 back, which means it has accepted my token transfer and it will happen in the background. So what's gonna happen now is that will get submitted to my remote RPC node that I've configured to talk to the Polygon Testnet. I've configured my EVM connector to wait for four confirmations. So what that means is I need to know, because this is a public chain, so the behavior of it is wildly unpredictable. What that means is I wanna wait to know that I get four consecutive blocks mined on the chain that all have my transaction in them. And so for this testnet, I determined just arbitrarily that four is sufficient, but for a network that may be more unpredictable or maybe you want even more guarantee you could set that confirmation number much higher. It means it will take much more time before we consider the transaction to be definite or that it's not going to be reverted or that we're not gonna get conflicting blocks and have to rewind the block head. So there's a bunch of really complex stuff that's happening behind the scenes in the blockchain connector right now. And so it's probably finished. We could go hop over to look at our contract here and we'll refresh this page. Okay, yeah, so there was a minute ago, there was another transfer here. So there was a transfer from and there's my addresses. And if I go hop over to my Firefly Explorer, I get this refresh button now and I can see now there is a new account that has a balance of 10 and my Firefly nodes balance has decreased to 90. So that transfer was successful. Now let's go look at MetaMask. So my MetaMask wallet is in no way, shape or form connected to Firefly. It's connected to the blockchain over the public internet. And if we go look at MetaMask now, and I think it's on this desktop, now it says we've got 10. And so if I wanted to, I could transfer, if I knew someone else that had a polygon testnet wallet, I could transfer some of these 10 tokens there. And because my Firefly node is indexing this token, that transfer would show up there as well. So Firefly is now aware of all of the transactions that happen on this public chain. So that's kind of what I want to highlight for the demo. This hits on a bunch of the new features in Firefly. It touches on multiple namespaces. It touches on both public and private chain interactions at the same time in the same Firefly node, multiple namespaces and a bunch of other really cool things that all combine together to make a really powerful platform to build blockchain apps. Thanks for coming out today. We've got about five minutes and we'll take some questions now and really appreciate you coming. Thank you. Hey, my question's primarily centered around identity and access control. So that Swagger UI tab, you're able to go in there and execute that transaction without authentication. Is there an access control you can put on top of that that says, okay, you need to have this? And if so, what sort of controls do you support there? Yeah, absolutely, great question. So for context, this is a local development environment that's running on my laptop, which is why there's no HTTPS, it's all local host. So new in Firefly 1.1 is pluggable API security. So there is a basic auth plugin that's built in. You can configure it at the HTTP listener layer so you can say I want username and password on everything. You can configure it on the namespace layer. So you might have one team in your organization that is working within a certain namespace and you give them one set of credentials, you may have another team that's working in another namespace. So you can separate them that way. Because it's a plugin, anyone can write an authorizer for Firefly and plug into any kind of user authentication system they want. Other options also includes some sort of network appliance in front of Firefly, like a reverse load balancer that handles the off outside of the process as well. But there's options for both. We like to try to be generic, as Steve said, we don't try to be religious or prescribed like, this is the technology that you should use, but try to be open to allowing integrations to many different forms of authentication. Thank you, and then on a similar vein, I assume that inside of the Ethereum connector, that's where you put the key pair or at least the wallet that controls access to the key pair for the on-chain contract, is that correct? So there's two pieces to the Ethereum architecture. If we look at, I'll just pull up the diagram again. So, EVM Connect is the blockchain connector, Firefly Signer is the, so these are both Docker containers that are running on my machine. Technically speaking, Firefly Signer is the one that actually my private key is inside that container and that's where transactions get signed and the private key never leaves that space there. Okay, and then I see this fabric consortium network and there's a connection there from Fab Connect. So then is there some notion of identity that goes beyond the fabric network that sort of identifies an account inside of Firefly across both the EVM Connect and the fabric consortium network? Yeah, it's a great question. I probably don't have time to go into, identity is a big topic. So Firefly, so Fabric obviously has fabric organizations within the Fabric network. Firefly also has a concept of an organization that can map one to one or one to many with fabric identities as well. Within this public chain namespace, that's less relevant because I'm using this in what we call gateway mode where this is just, it's just an appliance, an API gateway that I've set up where my organization can talk to a public chain. So identity, the sorts of org identities and node identities are less relevant in that space. My last question on identity is there a new, is it just essentially using it in password authentication with Firefly or is there also, you mentioned plugability, is there some notion of a key pair that provides some sort of access similar to how Fabric does or other networks do? Yeah, so good question. So API authentication and identity are completely separate. So the actual identity that I sign a transaction and put on the blockchain is not necessarily tied to the API credentials that are, like you could have a different set of API credentials to access a certain namespace. They can be obviously, like maybe a certain team has an identity that they use when they sign transactions, but they're two distinct concepts within Firefly. So then a small follow-up is the API credential, like an API access key that's different, it's not necessarily an identity, just like a, Okay, thank you. Yeah, so for an enterprise, they're gonna have their own PKI system. And you mentioned briefly a signer. Is that something that would enable Firefly to be talking to the PKI, like to help people set that up? Or does that need to be, yeah? Yeah. Don't you elaborate on that? I'm sorry. Can you elaborate on that? So the Firefly signer is relatively new. It's a new, it was first released in 1.1, which came out a couple hours ago. It is, but there are going to be more the ability to plug into different types of key management systems. But yes, the goal, it's a very enterprise-friendly license where some other signing things are maybe a little bit trickier around licensing. It's written in Golang, and it's meant to be extensible as well. Great. Do you have educational material? Yes, there are, so the docs are a great resource. If you go to, I believe it's, it's linked in our, it's pinned in Discord. If you go to, it's a hyperledger.github.io slash Firefly. These are the main docs for Firefly. This is a great place to start learning. Full disclosure, we have a lot more docs that we should write, they're coming soon. But yeah, this is a great place to start. Yeah, I just want to add one thing on organizational identity. So PKI is existing organizational identity. Some of these Web3 technologies don't use PKI at all. So the ETH signer there, Ethereum has no concept of PKI. What it uses is Ethereum addresses. So in that sense, Firefly is providing the plugins for the right key management solution. For Fabric, which is PKI-based, you know, Firefly knows how to connect to Fabric and interact with it. What Firefly does is it accumulates all of that identity information into an address book. So when you're in consortium mode, your Firefly node will create an address book of all that PKI information for all the different organizations that you connect to. I think we had one more question and then we'll hang up, we'll let you all go and we'll hang up out front for you. As you mentioned before, you're starting the data from different token transfers, et cetera. So is the, as we are on the enterprise level, is the database selectable? So you can select either SQL, non-SQL, et cetera, implementations. So today there is a plugin for SQL style databases, the specific, so there's a plugin today for Postgres, there's a plugin today for SQL Lite. When you set up the development environment, the default is SQL Lite just to not have yet another Docker container running in production, you probably wanna run Postgres. But it's very easy to add a plugin for a different type of SQL database. Perhaps a no SQL database will come down the road, but it doesn't currently support no SQL databases for Firefly's internal database, which is really sort of the current state of the world. That being said, there's also a shared, a separate from the database, there's also shared storage is what we call it, which the current implementation of that is IPFS. So if you wanna store blobs of JSON or binaries or whatever you want, those go to IPFS. That's a good question. Cool, really great questions. Thank you all for coming out. I think we're a few minutes over, so we'll let you all go, but we'll hang out here if there's any more questions. Thanks. Thank you.