 All right, we're going to get started. Thanks everyone for joining us. We're very excited to be launching it. No, you joined us during sessions during the week. We were presenting with various clients and consortiums in different industries that have been building platforms and moving to production in this technology. Today we're excited to do a much deeper dive on the technology itself. We did bring along some friends and collaborators from the community to participate throughout the day as well. So right now, we're going to start with the opening keynote from 9 to 940. And we'll do about a 20 minute demo as part of that to take us to the top of the hour. We'll have a one hour deeper dive technical overview. Then a hands-on workshop where you can download the code and get started. Meet the experts panel. And then for people on different time zones, we'll do a closing keynote. If you are attending this one, you might want to actually hop in and spend some time just meeting the community and having some peer conversations. So today it will be Brian Onder. Many of you will let me know. Brian, if you'd like to just say a few quick words to introduce. Hi, I'm Brian Bellendorf. I am executive director of Hyperledger and I'm really excited to be participating today. Thanks, Brian. And Steve. Hi, everyone. I'm one of the co-founders of Collido. And Collido is helping to see this new community. So couldn't be more excited to be with everyone and dig in and talk about Firefly and get this community launched. All right, let's get started then. We wanted to start, actually, Brian, just to get a couple of your thoughts. I know we've been working with you over the last few months on the proposal. And we're really excited to be part of the Hyperledger community now. What really excites you or sparks interest for you with Firefly? Yeah, well, so first off, thanks for hosting this event. And I'm really happy to be here. The thing that's exciting about Firefly to me is we try to ground everything we do at Hyperledger in the reality of how people are building these applications out there. We are idealists, but we're also pragmatists. And we've known for a long time when you operate at the plumbing layer, as you do it with blockchain ledgers. Sometimes when you're a developer and you're just starting to think about how to build decentralized apps, consortia-based kinds of systems, weaving all these different things together, there's all sorts of complexity, not just at the kind of technical layer, but the political layer and the social layer, all these kinds of things. And so, inevitably, you end up rebuilding some common tropes, right? When you build these distributed systems, how to handle off-chain data and on-chain data. How to manage your cluster of systems, that sort of thing. And we did have a project early on called Composer, which was an interesting tool to help people understand what this concept of decentralized systems amongst enterprises, how to design for them, how to think about building those apps. But it was a design tool that people wanted to use in production. And it wasn't really designed to be a production tool, designed to be a development tool. It was more of a almost a design thinking tool but to get you started, right? And when that team moved on to other things and they actually said, because this was encouraging people to use it in production and as an ongoing development tool, they wanted to actually pull this back and say this probably isn't the right approach. And so since Composer left, we haven't really had a tool that made it easy for people to come in and very quickly stand up these kinds of applications or avoid having to rebuild these common kinds of things to build on top of blockchain networks. So when we started to talk and you said you had some code that was built off of the backs of all the different projects that you've been developing and could help also answer something that's really key at Hyperledger, which is how do we start to build systems that span multiple different ledgers, right? I've always talked about the differences between Fabric and Bezu and Sawtooth, just within Hyperledger, but then even Korda and Quorum on the outside, it wasn't like race cars on a racetrack, it was much more like different databases out there in the world, right? MongoDB and MySQL are very different kinds of databases, yet at one level use them to store data and query data, but as developers we know that those differences matter when depending upon the use cases or the rest of the architecture up above. And so Firefly helps talk amongst different ledgers, support for Korda, support, I don't mean to preempt the rest of the day, but support for multiple ledgers and such is also something that's been core at Hyperledger since our inception, like how do we support a diversity of different options at different layers and Firefly really speaks to that. So all these reasons, when we first started talking, I was like, yes, this really belongs at Hyperledger and I think we can build a really big community on top of it. Thanks, Brian. Steven, I remember with Composer, part of the past life that we were involved with. So I think you partially answered this, what's great about, really great about Hyperledger is just the diversity of projects you have, sort of, I think you call it the greenhouse where you lay them all out. I mean, I think when you touched upon it briefly, but just in terms of Firefly now coming into Hyperledger, how do you see the relationship between these other code bases and communities in Hyperledger? It's really important to us that Hyperledger is not just a hosting service. It's not just like GitHub, but smaller, right? Or GitHub, but for blockchain, right? It's really important to us and this is where the greenhouse metaphor comes from, that the projects are aware of each other, that they are helpful to each other, that we aim for what I talked about in my brief keynote opener yesterday, kind of an altruistic groups kind of environment where the projects are, let's just say encouraged, but even that doesn't seem as strong as what it is. Like really, really encouraged to help each other but also think about design in a collective sense. And sometimes this can be a little bit painful, right? Sometimes it can be a little bit like, you know, we're just getting started here, who are all these people. But what it's intended to do is try to help build a hole that's much better and bigger than the sum of its parts. And so, yeah, that's, I think just, that's where I'm just excited about the project coming in and hoping that we get this started in really the right way. Thanks, Brian. I guess the last question is just what are things you think people should keep an eye out for today as we go through the Firefly Hyperledger Day? Well, I think this is a chance for people to dive really into what is Firefly, what are these different components to understand what, you know, where the design of this comes from, from the work that you've done for so many different clients. And just start climbing that learning curve so that not only can people start using this as quickly as possible, but also find a path to becoming a contributor of some sort. You know, it's really important to us that everyone who uses software that comes out of Hyperledger really thinks about, you know, how to understand how do I not just ask for help, but how do I report a bug? And also understands it's a little bit on them to when they report a bug, make it a good bug report, understand where things are going, what's happening below the surface, but that they're also empowered to be able to figure out more about what's going wrong and potentially contribute a bug fix, potentially contribute an improvement, right? And so that's what I hope people understand is that, you know, none of those open source softwares delivered as like a shrink wrap product that they, you know, should be discouraged from looking inside. Now this is something that hopefully folks understand that the rationale, the thinking, the architecture, but also feel encouraged to get their hands dirty. Thanks, Brian. I know this is why open source is the most fun part of the job of a modern enterprise developer. So really appreciate having you on with us today and getting some of your thoughts and perspectives. I know you'll be joining us again on the Meet the Extrudes panel and then for the closing keynote. So thanks again for the support and we've had a great week so far. So looking forward to the rest of today. Thanks again. Sure, I'll be right here. Okay, thank you. So we wanted to, oh, I wanted to dive a little bit into some of the business and industry motivators for Firefly just very briefly, not knowing all the backgrounds of everyone who's attending today. So, you know, why have people been talking about enterprise blockchain for the, you know, more than a half decade at this point? You know, Steve and I have been involved with this from the very beginning of when we start looking at blockchain and decentralized technologies for enterprise. If you look across all the B2B back office processes, many, you know, built on legacy systems are never digitized. There's, you know, tremendous pain points, especially during COVID, we've seen supply chain disruptions and many other issues that have come up in healthcare delivery, et cetera, where there's a lack of transparency and a lack of trust. So, likely not new news for anyone here, but we go to the next slide. You know, we've seen various analysts polling their clients and we've spoken with our clients directly as well. We've researched, wrote maps accelerated by a decade. It's averaged the cost to blend seven to eight years. What does this mean for tech providers and for enterprises? We've really seen that digital transformation of the back office is an imperative now, and we can see put out some very recent research. Only 8% of companies believe that current models will remain as viable business models if they don't digitize. And a lot of people are talking about digital ecosystem. So, bringing multiple parties together around a shared view of data, shared application logic, tackling shared industry problems. So, Mackenzie's saying that these new digital ecosystems could account for more than 60 trillion in revenue 2025. And these, you can see a really interesting graphic, a graphical view across all the industry sectors as you look at, you know, the digital ecosystem economy and how that is now, you know, it's here. And it's continuing to transition over across all the different vertical domains in the coming years. So, one interesting thing we've seen over the last half decade, people are really excited about the promise of decentralized technologies and blockchain, but there have been a lot of challenges. And this has meant projects could take three, four, five years to try to get into production. They've spent tens of million dollars written hundreds of thousands of lines of code. And why is that? It's that when you're really doing things between companies, you know, not just in one company in their own data center, but across companies, these cross-party flows require a lot of sophistication. There's, you know, enterprise space, a lot of requirements around privacy, security, compliance. Enterprises have struggled with the skills, all new frameworks involved, you know, different paradigms, digitizing, moving to the cloud and these peer-to-peer network frameworks and technologies. And as companies were trying to roll their own solutions, they ran into these issues and meanwhile still trying to comply with all of the heavy-duty enterprise requirements. It was just, you know, much too difficult to build an enterprise blockchain use case. What we've seen, that's a very familiar pattern. You know, enterprises think the job is in building their first use case and this can be an emerging tech lab or innovation team. You know, they think it's writing smart contracts. You start a node, you build the web app and you deploy it. Sounds pretty simple. You know, they think it's about three to five components. Maybe, you know, we're talking in the months or maybe half year. What we've seen it repeatedly across industries, across, you know, blockchain initiatives and projects whether it's just one company or we're trying to get to, you know, pilot with multiple parties or even into production, you know, they have to design how to use the blockchain as part of the overall solution. You know, running the node, we, you know, we've seen across industries five to 10% of the total solution. What's, you know, all the other layers of decentralized off-chain technology they need and then of course the application and middleware stack. So building a lot of off-chain plumbing, struggling to code to blockchain APIs and of course across the different protocols, there's different levels of maturity and sophistication there in terms of ease of use or lack of ease of use. And then, you know, getting to the realization that deployment can be a lot further off than what they promised to their stakeholders, investors and to their clients and end users. So, and typically we've seen up to 40 components, 40 is pretty typical and it could take a number of years, probably, you know, looking at two to four years as a general range. So what should the job be? It's, you know, we believe it should be modeling assets and data, defining the process orchestration, coding to very simple APIs, so modern development and then, you know, clicking deploy. So one platform and now you can build these projects in weeks and as, you know, Brian referred to, there are a number of consortia and customers who have already been using this code base to do exactly that. So with that, I think it's the final thought on the business side is really, you know, what does this mean? You know, we are looking at really a next evolution on how to build the solutions and some people are already doing that today, but by open sourcing this really important code base, we want the whole industry to be able to choose to have that option as well and to be able to build these gen two blockchain solutions at a fraction of the cost. And then if you look at on the right hand side, just the distribution of how much time and money is spent on the plumbing, which is the teal or lighter blue color on the gen one that dominates the stat, you know, the bar there, really flipping it. So you're able to move quickly through those phases, use the reusable assets, the infrastructure design and architecture as well. And then a lot of your time and money and focus can be on delivering business value and getting to business outcomes. So that's the most exciting part of this whole initiative. So with that, I'd like to pass it over to Steve. All right, thank you, Sophia. You know, I think it's really striking trying to invert that spend graph. You know, we've just, we've seen, we've seen the movie before like Groundhog Day where companies really are excited to get to that business value. And that's what we think Firefly is about. But let's zoom in now on Firefly itself and start talking about the technology. You know, we are calling Firefly a multi-party system. And we're gonna talk throughout the day about the term multi-party system and defining that. It's something you may have heard of, you may not have heard of. Is a blockchain a multi-party system? Or how is it different? Stay tuned as we really peel back the onion on this emerging term, a multi-party system. But let me start with an analogy. We're all familiar with Docker. When Docker came along, maybe you're a student or newer and you just assumed Docker's a given, maybe you've been around for quite a while and you can remember the first time that you actually touched Docker, you came across it. It was really such a breakthrough. The idea that all software could all of a sudden fit in a uniform box, how powerful that was. You can secure it the same way. You can do networking the same way. You can scale it the same way. You can do high availability the same way. All the hard problems for enterprises all of a sudden inverted. You've inverted the investment or the cost profile of an IT project where you don't spend all of your time doing that stuff. You instead build the application and make it better and drive more value for the user. And that was great. However, there was a problem. The problem with Docker was it worked great on your laptop but for an enterprise to go into production, Docker alone was not enough. A larger system was needed, sort of around Docker underneath. However we think of now Kubernetes today and Kubernetes was such a game changer. When it came along, it sort of a bigger framework. Very pluggable. There's not just one way to do networking. There are many implementations but they all conform to this plug-in interface around Kubernetes so you can select the best implementation. And of course there's this core control plane so you can manage not just one, two, three, hundreds, thousands, I think Kubernetes talks about planetary scale of Docker. Now all of a sudden you have this other layer, this larger system around Docker which I think is interesting, actually delivers on the initial promise of Docker, of helping us to put all of our software inside of that same box. If that's the metaphor, how about blockchain? Let's think about blockchain for a minute and what a big breakthrough that was 2015, 2016. I know my fellow speakers on this session, Sophia and Brian were all, you were there day one, I was also there as it came along and we all looked at it and said, how cool is this? Thinking about how broken the back office, how siloed it is and so on, a shared ledger, automating our business logic and smart contracts and chain codes, et cetera, this is a big breakthrough. But what we've seen since then is a similar sort of a problem where it's just too cumbersome to get into production. You don't have that control plane that there's missing pieces and so we believe then a multi-party system is that larger system just like Kubernetes was for Docker where it's designed to be very pluggable but the blockchain space is thinking about all these off-chain layers, data layers and middleware layers and workflow layers that for an end-to-end, a business application, an app that's a decentralized app where you've got multiple copies of these distributed around, all of that complexity, all the plumbing that Brian was alluding to, Sophia mentioned as well and a control plane to manage all these different pieces of software together. And I think specifically from a hyper ledger lens or from an open source lens, it's interesting when you sit back and you say, okay, if this is the surface area of the problem, all of these layers, there's lots of activity and really interesting projects but they tend to be focused more down into the data layers around the blockchain, obviously itself and around there and there are interesting projects up in the middleware space but we don't see a comprehensive project and that's really what Firefly is trying to solve is to step into this larger umbrella sort of a platform or system and that is what we think of as a multi-party system but before I get into Firefly, one more picture just to level set on what a business network looks like, a consortium, a group of organizations that are trying to build a decentralized application and how this is fundamentally different from the previous applications that they've built. So the light gray shaded area is the business network and the big circles are the small circles are members and you can see that each member is actually deploying their own set of the software and each member needs a private connectivity back into their core systems. They need both business and DevOps, DataOps type of access into the application but the application stack also has a different interface, a network-facing interface and there are multiple things going on here to be clear, there is a ledger there that's providing that shared common source of truth but there's also private data exchange and we talk all the time about how important privacy is but it's important to know that often lots of these cases need, there's different categories of data so some's private but some data is appropriately broadcast and so the ability to broadcast data to define things like assets, to store, there's lots of innovation over the last couple of years but it's important to keep in mind all of this is going on across this business network and data is flowing, there are data flows going on across all of these different arrows and depending upon the technology choice, we see a lot of companies really want to constrain the amount of data flows that are happening on the blockchain itself and so what we've seen and learned is off-chain a tremendous amount of data flows are happening and so the question then becomes well, how do you achieve those off-chain data flows and do they adhere and conform to the same security models and the same network policies and how do you blend all of these different technologies together and manage that along in a consistent way and if you had a control plane to do that a single control plane, it would be a lot easier for you so that in a sense is what Firefly is here for what it's trying to solve. We define that the multi-party system is that larger set of technology run times that are working together to give the application developer a really simple API to do things like share data, move data whether it's a blob or whether it's a structured piece of data whether it's completely private off-chain and pinned to a blockchain whether it's not pinned to a blockchain whether it is put through a blockchain with custom standardized business logic whether there's an exchange involved whether it's data going both ways or whether it's a payment or a value transfer happening for data so DVP or delivery versus payment all these sorts of use cases we've seen are very common building blocks that are used over and over again regardless of the industry across the space and so being able to create these robust data flows in a decentralized way so everyone's still running their own stack still cross-connecting, very event-driven it's an incredibly important part of the design principle here and a flexible technology framework and we'll talk a little bit about the roadmap as the day goes on but I mentioned the term and umbrella project but being able to plug in other things well in a scenario that we'll dive into where an organization wants to share another piece of data with another organization how's the discoverability of that? Well, maybe they broadcast the fact that this data exists you bring in the broadcast capability maybe they need to pay for that the data as they receive it so you bring in tokens maybe you need to prove that you have the data without disclosing the data so now you're getting into confidential computing so you can see how this larger system it's really important for Firefly to be able to plug in more and more technologies as it evolves I do want to let you know where the C contributions come from Brian has mentioned one of the things that's interesting from a hydro ledger perspective is that this code has gone through generations but it was actually a core part of the Clido product itself so it takes our six years of learnings and three years of active development and there's about 80,000 lines of code that have gone in to this contribution we think Firefly is actually a next generation evolution of the codes sort of a V2 or V2.5 and we've taken the opportunity for this launch to really improve a lot of things based upon real world use and so we've got customers that are using the prior generation of code that we're going to move over to Firefly but just having that feedback loop already in place gives Firefly, we're not starting just out of the blocks we're actually starting already in motion so that's exciting a part of the project. We're going to go deep into the Firefly node and we're going to take you through all these different layers different parts of Firefly itself starting with the core which is sort of the brain where you have simple APIs that you can build with as an application developer you're really interacting with the core and the core is helping and facilitating everything for you and it's almost like the wizard behind the curtain that it's hiding all of the complexity behind these simple APIs. It's very event driven as I said a minute ago so you can register callbacks and just get events delivered not worry about transaction pools and all of the goop down into the plumbing we've abstracted that away and we give you configuration down in these different layers and we've brought a tremendous amount of engineering down into these different connector layers to handle the coordination and the complexity of interacting with these systems and so that again means to you as a developer you have a really nice simple microservice in the core to integrate with and to build your application upon so down in the connector layer there are really lightweight connectors there are heavy weight connectors they adhere to the plug-in architecture which is something that we'll talk about throughout the day there we don't force for example any particular protocol between the connectors and the actual run times we built flexibility there and knowing that the run times themselves that are built on different technologies but some of these connectors are doing quite a lot of lifting for example the blockchain interface there's ETH Connect out there, Korda Connect and there's a lot of interest and activity and kicking off Fabric Connect as well and so the blockchain interface is interacting with the blockchain directly and it's important to point out that the blockchain itself is playing a critical role in the operation of Firefly really important and relied upon it's there at startup you need to select as part of your base configuration which protocol you want to use and you're off and running but in addition to the blockchain there are data exchange components that use completely off chain methods of delivery and blockchain back methods of delivery as well so there's broadcast there's a public storage implementation using IPFS or in planetary file system as a shared storage or broadcast that's tied to the broadcast type operations and then looking forward as well token this is an area of active design now and active work the ability to use tokens really simply and easily as you build your Firefly based applications and then a network map so these technologies each require their own organizational identity so having a single place where that's accumulated distributed across the network things like permissioning and so on it's almost thinking about it like in a dress book where if you want to send something to organization your organization A you want to send something to organization B you can do that readily and easily so that's a quick view and we'll certainly beginning into lots more detail just a couple more points before we get over to the demo I did want to highlight the fact that Firefly is really designed for multi-protocol support there's a lot of interest in the community already even at its launch to have full support for the big three protocols out there and we really anticipate that that's the direction the community is going to go with to ensure full support for all the big three Firefly is ready for enterprise that's why as Kaleido when we look to see this contribution to really build this community Hyperledger was a no-brainer for us with its enterprise focus for DLT and ledgers and all the related decentralized technologies seeding a multi-party system within this community we're really hopeful and excited about the path ahead there it is 100% designed for enterprise use so starting with the Apache II enterprise license friendly license we're committed to the open governance and the values of Hyperledger and the Linux Foundation and building this community we invite everyone to get involved and to find a way to be involved and we'll talk about ways to do that throughout the day enterprise-grade cloud-native, cloud-ready, very modern a scalable, resilient type of software and then I touched on this already but the idea of the extensibility of it sort of future-proofing this multi-party system we see that other technologies will emerge things like zero-knowledge-proofs confidential computing which are sort of coming of age of their own right so making it really pluggable and sensible and what else this could mean is this pluggability is hey, maybe you're a really large enterprise or you're part of a really large network maybe you need a completely custom way of exchanging data that just makes sense for you well, this plug-in interface is really simple for you to pick up so you could be building on standard APIs at the Firefly layer but have your own custom extensions as well and that's all permissible and understood as part of the project I wanted to emphasize one more time just how important blockchain is to Firefly pieces around core blockchain technology that's running things like global ordering and finality are really important to coordinate across the organizations and that's sort of the bedrock upon which we build it things like the immutability of data and being able to agree and have that single source of truth of what the data is and what order of the data it arrived in and then building upon that sequencing and triggering but also the larger conservation of value and thinking about that other layer of tokens that is really powerful programming model as well for developers Firefly is bringing all that to bear but we are extending it with simple APIs with off-chain mechanisms for data delivery thinking about efficiency so we're going to talk about how batching happens and how grouping happens and some of the other techniques that we've seen are really necessary to achieve enterprise levels of scale so that's all easy and solved and sort of in the box for you large off-chain payloads we'll talk about how those sorts of things happen maybe it's sensitive regulated data and then thinking going a little bit beyond events happening and thinking about going from triggering to streaming and thinking about how we can really up the level of process orchestration and make it that much simpler to build upon and then also unifying or simplifying the identity problem of the fact that these different technologies need to plug in identity in different ways thinking about I mentioned emerging technologies as well well we've we've given thought to how decentralized identity or self-sovereign identity could plug into the system and so that's going to be an area ahead on the exploration front we see lots of opportunities with different hyperledger projects and other technologies out there in the broader open-source world and those explorations will go on today we're launching Firefly we are formally establishing and starting to build the community if we will be pointing you and you can check out the booth as well if you want more specific conversations around this but we'll be kicking off bi-weekly open meetings that anyone can join I encourage folks to go over to the hyperledger website and to find us there on the Firefly channel and to get plugged in Firefly channel on Rocket Chat but just a really quick snapshot of high-priority items that there's active investigation going on full fabric support we've heard loud and clear from folks is going to be a really great capability to pick up as well as thinking about doing more with tokens and building more simple APIs for some of the common scenarios that we see are sort of the 90% case around tokens and all of this we want to build towards a 1.0 release targeting the end of the year where Firefly itself's hardened and we really use the glide path of hyperledger and think about things like security and audit verification and so on that you really value from the hyperledger community and get that 1.0 release out there and so we'll be on a sprint as a community to get there I think it's going to be a lot of fun to get there and with those thoughts that sort of concludes the overview or the opening keynote