 Sounds like we're getting started. Hello, everybody. This is Jim and Peter from Collidal. Really great to be back on the Global Forum, this exciting annual event of everybody from all over the world that care about blockchain, especially its adoption in enterprise use cases. So today we'd like to talk about privacy in particular. So the agenda is two parts. We'd like to first spend a few minutes just to recap on the current techniques and each addressing this different aspect of privacy. And then the second part, we'd like to take a look at the evolving multi-party systems and see if there's a framework that can tie them together and through plugins to bring all these different techniques together into a coherent system. So when you build your solutions, you might use different pieces depending on your specific requirements. So you don't have to hung down individual technologies yourself. So starting with sort of a lay of the land in terms of privacy techniques that are being used when you are building a multi-party system with the foundation on the blockchain. Obviously you can create separate instances of blockchain so data and identity is completely isolated. If you're not part of this chain, then you don't know what's going on. You can use techniques that mask your submitters, transaction submitters identity, either using true random or pseudo-random keys to sign the transaction so they look like they come from completely random parties. But you can hold the master key to all of them so that your trading pattern would not be leaked. And then you can have off-chain communications. So your sensitive data or kind of business data that's very key to your business competitive edge are transferred to your parties off the chain. So it's not a broadcast to everybody and you keep your private data private. And then in these green boxes, we see emerging technologies that are utilizing more advanced cryptography in terms of producing zero knowledge proofs using a trusted compute on the special hardware or using multi-party compute to make the output collaborative but no one has the whole secret. So let's take a quick look of each of them in more details. This is obviously a very easy to understand if you create different instances of blockchains then obviously both the data and the transactions are completely separate. It's worth mentioning that technologies like Hyperledger Fabric makes this much easier with their channel technology so that on the same network with the same set of identities, you can create essentially multiple instances of blockchains called channels with its own governance model, its own permissioning configurations. And if you're not part of a channel, you have no idea what's going on inside that channel. Next, we have private transactions where we're all utilizing a same shared ledger with the same permissioning model. But on the transaction by transaction basis, I can choose who my transactional counterparties are. And the true payload for the real transactional data is sent between those parties in off-chain channels directly, sometimes in encrypted format. And the blockchain in this case is utilized to, number one, identify that a transaction has happened off-chain. So there's a representation of that usually in the form of a hash that represents the transaction payload. It's sent to the chain. So everybody on the chain is paying the duty of protecting that transaction's data commitment on the chain. But the actual data is only communicated among the parties involved in the transaction. And so that's about protecting the payload of the transaction. So what about protecting the identity of the transaction submitter? In certain use cases, you don't want your trading pattern to be analyzed by your competitors on the same chain, so you want to protect your submission's identity, signing identity. In certain chains, this is more easily accomplished than other chains, depending on what kind of permissioning model is utilized, whether you are able to use random signing keys to sign transactions and be still allowed to submit. The idea is you just go ahead and use complete random transaction signing keys, but then you have to keep track of each of them. So that's a pretty big headache and overhead. Or you can use this technique using key derivation so that a single master secret can be used to generate billions of derived keys that to the outside world looks complete random, even though they are all generated from the same key. Then we talk about two off-chain communication technologies. Sometimes you just want to send some structured data or a smaller piece of JSON from one party to another. App-to-app messaging, it's a pretty popular technique, even though there are different implementations by different vendors. It's usually backed by an enterprise-grade Q, so that data can transfer from one party to another without getting lost, even if the receiver at the time is not online. So using Kafka or other queuing technologies. And then utilize encryption. You have a data that's transferred among parties reliably and securely. This is very similar document exchange from one party to another. It's not small and structured data anymore. It's arbitrary large files that needs to be chunked into smaller pieces to travel through the secure pipe with the queue and then in encrypted format. And then on the other hand, on the other side, they are taken off the queue and decrypted and then put together into the file again. And then on to the more advanced technologies using more advanced cryptography. Now we're talking about so if when you put all of your processing logic on chain, it's pretty difficult to protect it from leakage. Because, number one, everybody will see that if it's stored on the chain. And data, because the processing logic is on chain, the data itself must be on chain as well. So what if we take both the processing and data off the chain and make it happen somewhere else? But now you have the burden of proving to all the parties on the chain that you haven't cheated. If you are spending $100, then your transaction is deducting $100 from your account. You didn't cheat by deducting only $50 and claim you have deducted $100. So how do you prove to everybody that you've done this transaction honestly? So there are two techniques. One is using cryptography of generating a proof that I've done this particular computation. And this is the proof that I've carried out that computation according to the claim. The other technique is you can sort of log all this logic and data into a secure place so no one can see it. Not even the administrator of that chip can see it. But you can ask the chip, did you just do perform a transaction that did this? And the chip through its attestation interface can tell you yes or no. And with this, you're basically trusting the chip's manufacturer and the cryptography applied to this technique that all the computations are done correctly. So that is called a trusted execution environment. So with all these techniques, it's pretty exciting that you are able to use these for depending on your specific requirements. But using each of them is hard enough. Think about generating the zero knowledge proofs. Think about creating the off-chain channels that are reliable, that are utilizing end-to-end encryption. Doing all of that is like doing at least some of that is necessary to create a real-world enterprise blockchain-based solution. So now it get us thinking, what if we have a framework that makes all of this easier? What if we have a framework that has out-of-box support for some of this and then have plugging systems to support future technologies that may be developed? So we don't have to understand them individually. We just stay within the network and they all get plugged into it in the future. So now we're very excited to talk, to introduce to you guys Firefly. And this is really a multi-year evolution within the Clido team. And now it's part of Hyperledger Labs. In fact, seven individual code repositories encompassing I think tens of thousands of lines of code just landed today in the Hyperledger Labs repository. And we're very excited to share this with you. The previous generation that's also in production with many of our customers were written by our awesome engineer Gabriel Indyk. And the new generations have taken all the lessons we've learned from the deployment, from building the solutions for our customers. And we have a more efficient, a better architected framework that's now contributed to Hyperledger. So now I'm going to introduce you guys to Peter Broadhurst, our head of engineering and the creator of Firefly. Thank you, Jim. Yeah, so I guess 75,000 lines of code, I think, dropped us the seed contribution for this. And it's, I think a significant gap that's being addressed in what we really are striving to be a vibrant open community here to solve the real problem, the elephant in the room for blockchain. How can you make it useful for building enterprise use cases? There is no enterprise use case that doesn't have private data. There is no enterprise use case that's just, you know, an on-chain NFT on its own in isolation. It's an enterprise use case because it integrates with the 100 plus years of innovation on the business side that's happening between these large organizations coming together to form a business ecosystem. And we've seen over and over again the same journey being taken by business networks. The start of the journey, it's the same feeling, right? Surely what we need to do is we need to write some smart contracts. We'll write some smart contracts there. That's where we'll focus our time. And I'm sure like, you know, four to six months we'll have a use case and we'll be deployed. And the reality, and you're almost certainly this is familiar to everybody here is that actually you find designing how blockchain fits into what you're actually building, which is trying to digitize an industry through collaboration, what you're actually building is trying to build a multi-party system. Where that little kernel of on-chain logic fits, it's not the whole problem. It's just a piece of the puzzle and actually the time, the effort, the energy, the resource, the collaboration over many years we see where if you start from scratch goes into the plumbing, goes into the integration with your core systems, goes into reconciling data formats and the differences between all of the hundreds of years of business evolution that's happened separately across these organizations and combining it together. And actually the number of projects that can get through that show business value quickly enough, quickly enough to really keep the interest, the motivation, the projects alive. It's not easy to do nowadays. It's getting stuck in the plumbing just seems to be so common and we're lucky, right? We were able to, we've been able as one of the sort of players in the industry that tries to sort of focus on this particular problem, sort of fish people out of the lake when they've been stuck for multiple years and get them forwards. Now, we don't think that that is enough for multi-party systems. So blockchain and all of the other technologies that are about allowing systems to collaborate in a different way to how they have done in the past. We don't think it's enough to just have a company that's there trying to help individual companies. We think that industry can achieve a hundred times more things. We can have an order of magnitude more projects being successful in the blockchain space. If we have a comprehensive open source projects that means regardless of your technology choice, you can come, you can model your business process, you can get your glue off the shelf, that the plumbing works, you can take existing skills, fantastic developers who now have to build mobile apps, great user experiences, fantastic business APIs. You can take organizations with their own distinct core systems and integrate them to this thing. And you can innovate in weeks and months, not years of just trying to get the plumbing together. And we're almost astonished that after so many years, if you're just down that last slot chart for a second, Jen. But actually, these layers in the middle between the place where we've seen fantastic open source project, not just the big three with Ethereum, Bessu and Fabric, and then the Corder community, not just those at that level, but a layer above, the sort of second layer of technology, huge amounts of strong open source projects that focus on that area. But actually, that's sort of 10% of the overall job for a business network that's trying to actually build a solution here. And this center in the middle, that's all about that private data, all about the plumbing, all about the integration that happens off chain as much as it happens on chain, that piece in the middle that's sort of between the innovation that's business specific at the top and the core blockchain technology at the bottom, there's just nothing there that's comprehensive. So we're really excited to be part of the formation of this, Jim, if you just move on to the next slide. So it's Firefly, it's there, it's in the open, it's a really big engineering commitment to get it started, but we're at the beginning of that journey on the community side, which means that everybody has the opportunity to really be start at the start of the transformation that this can cause. And what Firefly is, is about accepting the reality, the reality that building a multi-party system between large enterprises is about more than blockchain. It's about more than blockchain. And actually more than anything about else, it's about allowing the developers, web traditional enterprise, API, microservice developers, the developers and the integration teams of these organizations that are trying to get together to build the solution. It's about saying they matter, they matter. Let's make their life easy. Let's make it so that like they're used to for databases and messaging and all of the other technologies, it's actually straightforward and achievable to develop and build a solution in a multi-party system environment. Let's make the technology serve the business use case and the developers. Let's have a great REST API. Let's have events that you don't need to like be some specialist to decode and understand the hashes to use. Let's have it so that the program model is easy to understand and easy to describe so that you just get on with building your use case. And let's brace the fact that multi-party systems are never gonna be just one technology. It's never gonna be just choose your blockchain. Like I've chosen Fabric or I've chosen Hyperledger Bessu. Like it's never gonna be that and I'm done. It's actually gonna be, well, okay, well that's the blockchain piece of its souls but what about the off-chain messaging? Am I using Kafka? Am I using RabbitMQ? Am I using ActiveMQ? What am I doing there? Do I need end-to-end encryption of that off-chain messaging? What about the shared storage that's too big to actually go on the blockchain? Things like IPFS or Swarm, where do they plug in? What about the fact that you've actually need your own private copy of your own private data and your application needs this fast cash where it can query the stuff and find the stuff? What's the history? How do they get to this state of the world? What did I say versus everyone else say? Well, none of the technologies give you that in isolation. Where's that database fit in that's unique to me and private to me, right? It's not everybody else's data. This is my data. Maybe I share some of it with other people but I've got my data that I submitted. I've got some data that I've shared. I've got lots of data that I've received from other people. Like that's got to go somewhere as well. Aggregate all of that together and put it in a box. And that's the Firefly node. So Firefly, more than anything else, is about plugins that assemble together all the tech, all the tech that you need to solve multi-party systems and really built through people like GM who've got so many years of experience in sort of across multiple projects. Be that having contributed to all the top three of the blockchain ones, but also Avalon and these other projects to actually say, well, just a minute, all of this innovation that's happening, the lines that are blurring between what's a ZKP solution versus a blockchain solution? Where does off-chain compute fit in? All of that can integrate into this ecosystem as well. And to do it with enterprise-grade engineering, a truly open approach and actually bring all of this sort of production experience that we've got because we've bought these years of code along with it. Well, also a lot of it is being intentionally started to get in order to make it open and pluggable and to bring the community in. So if you go forward to one more here, Jim, we're not going to spend a lot of time on this today, but I'm going to talk about Friday where we actually have a much bigger event that you can all participate in and see what's inside of the tech. But we put a lot of effort into the extensibility, getting the foundations there to allow lots of parts of the hyperledger community to come together and plug into this, but also allowing lots of innovation of other projects that aren't necessarily quite so blockchain. So for example, we're great friends with projects like Node-RED, for example, for low code, low code development and business logic. They're a place where they can come together. So we sort of talk about a periodic terrible of elephants as the way that you can sort of plug into the system. And the Firefly Node is a microservices architecture, which means that it can take Java code. So if you've got the Corder plugins as all Java, because that's the only way to do it in Corder, well, that can fit even though that core brain is go now that that's been built in. You move forward again, Jim. And when you think about it, this makes it a very, very different shape project. One of the things that's unique about Firefly is that it's not linked to an individual one of the, you know, what I guess, in some places have become a little bit siloed, pieces sort of spaces of innovation in the enterprise blockchain space. We've actually got projects that started on one of the big three and moved to another one. I'm not gonna say which direction they went in, but between Ethereum and Corder, we've actually proved that it's actually genuinely possible to have applications that are one layer detached from the blockchain in cases it makes sense. And that's when you're using reusable constructs that are universal, like sequencing. For me, it's amazing that blockchain's solved one of the hardest problems in multi-party systems that existed the whole of my career of allowing multiple organizations to sequence things in the same way. Like that magic problem, absolutely magic problem. Everyone can have that soft. You don't need to build a smart contract for it. It can come with the technology. Same to NFTs, where NFTs really well understood. We know how to do them. As a developer, you just shouldn't need to like think, where do I go and get the source of an ARC721 form? And is that really the standard I want? Well, you don't have to do that day-to-day basis. You just have to go, well, where's my SQL query? I'll just call it. So moving away from a world of everything is like a stored procedure, build it from scratch to reusable patterns. And then the ability to drill down and use the unique features of each of these technologies where you want to, right? You've got some specialist logic that's only available. Someone's built it just for fabric. Great, fantastic. You need the channels of fabric. Absolutely brilliant. You really like the community around tokens and the tri-by-far ARC20 standard of Ethereum. Brilliant, just go and use that. You can drill down and use the best features of these. And it extends more than just the Hyperledger family, more than just actually the blockchain tax. I mean, we haven't got IPFS on here. We haven't got Kafka or all of the off-chain messaging technologies here, but they all can plug in as well. So a project there to serve the real, you know, who really matters in this, which is developers building use cases and to try and abstract where it makes sense, the technologies and to definitely make it easier to integrate with these things, right? Make them feel like REST APIs, make them easy to code to. And if you move forward to one more, Jim, also focus on user experience. And we think about three very, very important personas inside of the seeding of the Firefly project, right? We're not got hubris here. We're not trying to say this is done, but we do think that we needed to kick off a set of things. And there's three kind of personas that we're really trying to get going with the creation of the Firefly project. The first, and I think the most important, is non-blockchain developers. I just want to use you like I use a database. I don't care how the internal transaction replay system of the database works, I just use SQL and it works. Or I just use no SQL and it works if you're a more modern developer. Give that kind of great experience to developers. And that means they expect tooling that's going to allow them to see when things have gone wrong. So we've started with a CLA comes with this out of the box. There's a whole CLA project. Get started in 30 seconds. Do it yourselves, come along on Friday. Enjoy actually getting started with the tech. Make it really easy. A user experience will actually let you see what's going on as you're doing it. See all the coordination, the ping-pong we call it, between the on-chain stuff and the off-chain stuff and how everything works together. So a user experience with it. So a big focus on that developer. And then the second focus is on the operational side. So a lot of effort's gone in to make it plugably from an operational perspective. Think about things like active-active HA which get forgotten in a lot of projects after until a long period in. Think about things like, well, just a minute, how does this integrate with my database? How does this integrate with the on-chain stuff? How does it all fit together? And how do I view what's going on? So that's another big persona for us. So that's the second one. And then the third one, and this really isn't the best for last, I guess, which is the community. But this is the sort of project we want to unify things. A little bit like the nascent potential of a Docker had right at the beginning, this fantastic transformative technology, it wasn't actually achieved for enterprise until Kubernetes came along. And Kubernetes allowed it to be consumable and work from the perspective of all of those operational and non-functional requirements that are needed and to make it really easy. And that happened because of collaboration. That happened because Kubernetes is not like a one technology thing. It's a plug point that allows all of the technologies to get and to come in. And we think multi-body systems and blockchain is just crying out for that kind of project. And we don't see it out there. And we're excited to be what we hope is at the beginning of really making that community come together. So we expect to see lots of community building here, calls, great ways to contribute to the code level, but also to contribute in terms of on the application side as well, to come together to really try and do something net new and interesting in this space. If you move forward to one, and I know we're just at time here, this is a teaser today. And I think it will be fantastic for everybody here and tell your friends and share about it. If you think that there's a problem to get to solve here, come along on Friday and let's talk about it. Let's see where we've got to with this seeds. Let's try it on our laptops. Let's poke at it. Let's see the potential value that's here and whether this particular direction is something that's really going to create the transformation that we all need in the blockchain space. And let's get things going. So we've put together a full half day of activities on Friday with hands on labs, lots of chance to talk to all of the developers. I'm in Collido and to talk about how we take this thing forward, is deep dive into the architecture, deep dive into where does blockchain fit in, where does the off-chain fit in, how do they collaborate together. So I really hope to see you all there on Friday. And also, please do share it around, because our feeling is that this is a problem that really does need solving in the space and that we can get together and we can solve it in a really meaningful way. And thank you so much for the time today. I guess that wraps up our talk. Thanks Dominic for hosting us and thanks everyone for joining. Have a great day.