 Well, thanks for coming everyone, I'm Hart and I'm going to be talking about hybrid networks. We have a very small crowd so please feel free to ask questions, interrupt me, you can argue if you want, preferably not physically but you know, up to you and we can keep this as interactive as you like. So a little bit of backgrounds, I work for the Hyperledger Foundation and the Open Wallet Foundation. I've been involved in the open source community for a little bit. What I worked at Fujitsu is when I got started in the open source and I have a background in academic cryptography. So this is what I'm going to talk about today and if anything is particularly interesting or particularly non-interesting, you know, please let me know. I'm going to define a hybrid blockchain. I'm going to say why we care about hybrid blockchain, like why is this a thing that enterprises want to use? And then I'm going to talk about a bunch of deployments using Hyperledger technology. So let's get started. Is everyone familiar with this sort of basic conception of blockchains? We have permission versus permissionless and public versus private. So who's familiar with this? Raise your hand if you're comfortable with this. Awesome. So most people are. Great. So very quickly, if you can write, if anyone can write to a blockchain, it's permissionless. If it's restricted and who can write, it's permissioned. And you know, similarly reading, if anyone can read, it's public. And if only certain people can read, it's private. So Indie, which these gentlemen run, are they running the most popular Indie deployment would be a public permissioned network. So just some examples. This is not the greatest because there are some blockchains that can be run in multiple different forms like basu. Basu is an Ethereum client. So it is running on main net Ethereum right now. But there are also people who run private permission basu networks. So you can just sort of see like what each of these, you know, blockchains fits in this niche. Many people aren't quite as aware of some of the public and permissioned blockchains. But those are more and more becoming a thing. So what is a hybrid blockchain? So a hybrid blockchain system is a deployment in which value is exchanged across permissioned or private and permissionless or public blockchains. So I'll explain this a little bit more later. In the public blockchain view, there is a layer one blockchain, which is defined as sort of the main blockchain. You can think of this as like your Ethereum or your Algorand or your Avalanche, if you're familiar with those. And layer two is a connected network in charge of off-chain transactions. So this would be like polygon or optimism or arbitrum. And this is how sort of the public blockchain community like Ethereum thinks of these things. We really just broaden it and call it hybrid blockchain because this is essentially doing exactly some of the same things that are happening with the permissioned blockchains. So what does this look like? So here's kind of a model, right? We have a main blockchain, like you can think of this as Ethereum, for instance, right? And you can think of these side chains as sort of moving faster. And the idea is that we can compress these transactions or the side chain occasionally checks in with the main chain. And this is just a sort of example of what a hybrid blockchain deployment looks like. And precisely, this is drawn from Ethereum main net with a basic side chain. So why do we care about hybrid blockchain? Lots of distributed ledger applications involve many networks that need to interact, right? Today we have a lot of databases. Not all the databases are the same, right? But they need to talk to each other. So some of these networks might require fast consensus algorithms that don't necessarily need a lot of security, while others may need a huge amount of decentralization. We might need different encryption schemes or signature schemes or zero knowledge proofs. We need different database storage. Some databases are going to be optimized for analytics. Others are going to be optimized for storing a large amount of information. Identity management. We have a bunch of identity people in the room. So this is a, should I use a CA or should I use verifiable credentials? I know a lot of you have an opinion on that. So, you know, we really need these modular open source implementations. And there's not going to be, you know, a single blockchain to rule them all, right? You know, everybody needs something different, and it needs to interact. And this is sort of formalized in something called the blockchain trilemma. Have people heard of this before? Raise your hand if you've heard of it. Yeah, so the basic idea is that blockchains cannot typically achieve all of scalability, security, and decentralization at the same time. So you have to sort of consider which property you're willing to give up when you want to have a blockchain. Sort of. It's not a rigorous theorem. So there's no, like, formal proof. And if you're willing to have a quantum computer in your cell phone, you can get around this entirely. But that's a whole different talk. Sorry. Yes, and they do this with this kind of hybrid approach as well. So we're getting to, we'll get to that in a couple of slides. No, no, no, no worries. So, you know, a lot of, you know, I've put some sort of blockchains on where they are, right? So, you know, Zcash, Ethereum, and Bitcoin tend to focus on decentralization and security, right? And they sort of don't try to solve scalability is hard. Where something like AOS or, you know, maybe Solana, right, you know, are a bit more centralized, but, you know, have a bit more throughput. And I'll say, like, please don't compromise on security. You know, this, I'm sort of sad that this got defined as a trial and not a simple trade-off because you really should not be giving up on security. So back to this gentleman's point, right? So good L1 blockchains are typically very secure and decentralized, but very hard to scale, right? And sort of how do we address this in practice, right? So the idea is we want to use hybrid blockchain systems or in the world of public chain, L2 networks, to inherit as much of the security and decentralization of the L1 layer as possible, but also design these systems in a way that addresses the drawbacks of these L1 systems, you know, including things like scalability, privacy, cost, finality. You know, we're really only sort of scratching the surface when we only focus on scalability. So here's sort of a continuum of networks, right? And you can see that we have a, you know, at the top is sort of, at least in theory, I'm not going to go into the practical decentralization of these things, right? How many mining pools totally control Bitcoin today? Probably two. So ignoring the practical concerns, at least in theory, it's fully decentralized, right? But in general, right, as we get more decentralization, we sort of have slower performance, right? So these are approximate TPS numbers for all of these platforms. Please do not shoot me if I am not quite on with your favorite platform. But, you know, the numbers are complicated, particularly for the permission networks that depend heavily on the actual deployment, right? But you can see the sort of trend, right? The slower net, the more decentralized, excuse me, the more decentralized networks have generally slower performance, right? And one network cannot handle all the cases. And the idea is that sort of these side chains in a hybrid network compress many transactions using hashes or zero-knowledge rollups into single or fewer transactions on the main chain. It's possible that they, in fact, only use a time stamp from the main chain. There are a number of different ways to approach this. But the main idea is that you have a side chain or a level two chain that periodically checks in with the main chain. So some of you have seen this slide before, but it's one of my favorites. So can anyone who hasn't seen this before tell me what it is? Close, yes. It is my anonymized credit card history from a week about five years ago. And, you know, let's if this were all in the public chain, right? You know, I might have my public key, right? And I would have, you know, sign transactions to these vendors, right? Maybe the vendors are the public key is known for a lot of people you'd pay on, say, Bitcoin, right? So what would you learn about me, right? If you're just looking through this, right? There are a bunch of restaurants in the South Bay, right? So you'd say, aha, you know, you're buying from a vending machine in the South Bay. That's you probably work there, right? Across multiple days. There's a restaurant, right? You know, and then there's a one corporate catering Sunnyvale, California, right? That's probably my office, right? You know, I'm buying groceries and gas in Redwood City. You could probably say, well, I probably live near there, right? Why am I paying the Stanford gym? There's probably something there, too, right? You know, I'm paying a gastropub. And there are Uber payments around the gastropub visit, right? So you can probably determine that I had some cocktails at the gastropub, right? So even from just this payment history, right? You learned a lot about me. You learned that I worked in Sunnyvale. I probably lived in Redwood City. I had some connection to Stanford, and that I probably enjoy a good cocktail. This doesn't totally de-anonymize me, but if you had my transactions over the whole course of the month, right? You could probably pinpoint me individually. So, you know, being anonymous didn't buy me much, and you know, if this were all on the public chain, it's just all out there, right? You can just see this. And, you know, things like corporate finance or medical records are far more important to keep private than my credit card history, even though I probably wouldn't like my credit card history being public. So by default, everyone can see all transactions on a ledger. So this can make privacy very hard. It's typically much hard. It's a much easier problem to solve in a permission setting, generally speaking. So one way to think about how we might solve this in a private or permission ledger is sort of private data collections or private transactions. And I've sort of put a diagram of how this works in hyperledger fabric here. And the idea is that you limit the data others on the blockchain can see by only posting hashes of the data rather than data itself. And so you can see here, right? The peer is not seeing the important transaction history. It's only seeing hashes. Now, I hope you all went to Stephen's talk this morning about zero knowledge proofs. And I don't have to re-explain these to you because I only have a slide and Stephen gave an excellent talk on it. How many people here are familiar with zero knowledge proofs? How many people have no idea what I'm talking about? Awesome. So, right? So general flows on top. We have a claim statement, the prover knows and I'll put in quotes the answer. It's not really an answer. It's technically something called a witness, but we'll forget about that. And then we can do a proof of knowledge that can be efficiently checked. And a statement is something that's efficiently verifiable. And as of the form, I have a valid signature on the message M from the authority, with public key XYZ, right? Then there are a bunch of different schemes and sort of how we formulate these proofs. And we can use these as a powerful tool for privacy. So on the left, we sort of have a private transactions concept and on the right, we have a ZK-SNARK privacy concept. This is a diagram for BASU. It's how each concept could work on BASU. And a SNARK is what's called a succinct zero knowledge proof. And that just means that the size of the proof is independent of what you're proving, which is great for blockchain, right? Because we don't wanna store a lot of information. We wanna store small things, so succinct things. And that's why SNARKs are really good. So, you know, the idea is that essentially we can just prove everything in zero knowledge and it will only sort of leak minimal outside information to people. This is expensive and it's not practical to really do yet for all but the most basic types of transactions, but it's a technology that's evolving really quickly. And I expect in a couple of years, we'll be able to run general purpose blockchains that do everything in zero knowledge. So, now that we've sort of seen some of the benefits of what we can accomplish with hybrid blockchain, I wanna talk about some examples. So, the first one I'll mention is something called IPV, which is a hybrid blockchain system between CASPER, which is a public permissioned blockchain and fabric. So, you know, they've made a big announcement about this at Davos this year, but the sort of idea is to tokenize patents as NFTs for easy IP rights verification, as well as patent analytics. So, the problem is that it would be really nice to have a public NFT trading space for this IP, but patents have some information that holders wanna keep private. And it's also the case that some regulations stop you from storing some things in a full public deployment. So, the solution is to use a hybrid blockchain system running between CASPER and fabric. And it turns out the connector in the bridge between these two is actually running on hyperledger cacti as well. And so, they said in Davos that it was the largest enterprise blockchain deployment in history. I'm not sure exactly what that means, but the press really said it, so I'll go with it. So, another one. So, have people here heard of Hedera or Hashgraph? So, this is sort of, you know, Hashgraph and Hedera were sort of designed to be used in this kind of hybrid model. And you know, here you can see this sort of overall diagram and some comments on the consensus service, right? So, you know, this is something that runs on Hedera that allows you to sort of do things like verify time stamps, use ordering, while still maintaining privacy for sensitive information. And so, the idea is that you have a fabric deployment communicating with the Hedera mainnet that allows you to get, you know, reliable time stamps from the main blockchain and, you know, certain ordering properties, while still keeping things running privately on a private permission fabric chain. And so, sort of one use case on this is Toco, which is a very interestingly digital asset creation engine from a law firm, a very technologically savvy law firm, but it's a really interesting use case for tokenization and we have a bunch of materials on it if you're interested. And you can see in a little bit more detail, this is kind of what the flow looks like, right? We have a fabric blockchain on the left that is connecting with Hedera network on the right and is, you know, submitting very basic messages that get incorporated in consensus and can act as timestamps. So, Palm, do people know Palm? Anyone other than Rye? I know Rye knows everything in this talk, so it's not a... So, Palm is actually really on the sort of, they're working in blockchain that the NFT space, the NFT art space that a lot of people here would consider pretty far out. And so, they're people who've been doing like the... They did the DC universe NFTs, for instance. And how this works is they're running a Palm network, which is based on Beisu. And they're running that as a side chain to Ethereum mainnet. And they're running a bridge between the two networks and checking in periodically. So, Palm is running Beisu, but it uses IBFT consensus. It offers much faster transaction speed and much lower minting costs than if you wanted to mint an NFT using Ethereum mainnet. So, you know, sort of the evolution of Beisu networks. This is Beisu running on top of Beisu. Or you can at least think of that way. So, next I wanna talk a little bit about Firefly. Has anybody here heard of Firefly? So, what is Hyperledger Firefly? So, this is, you know, it's not in and of itself, you know, a hybrid blockchain system, but it allows for easy hybrid blockchain deployments. And the idea is that when you're building a blockchain application, you have to build a lot of stuff on top of the blockchain that isn't directly related to or unique to your application, right? You have to build a lot of middleware and plumbing to get an application to run. And that's what Firefly provides is this middle layer for, you know, that you don't have to rebuild every time you want to do a blockchain application. They call it a super node. So, you know, Kaleido, which is one of the main developers of Firefly, you know, has heavily embraced hybrid blockchain. And, you know, they provide, you know, they're a huge number of goals they try to achieve with their systems. Everything from gas fees to throughput, you know, to avoid holding cryptocurrency. And this is something, you know, a lot of enterprises might want to use or accept cryptocurrency as payment, but don't necessarily want to hold it, right? The Linux Foundation is one such organization actually. So, you know, to really encompass all of these applications, it's not necessarily good enough just to have two chains, right? You may need a whole spectrum of chains to meet your application needs, right? So you might have sort of a one-party chain or really just a ledger, right? It's not decentralized. But if you want to run an app and record a ledger on it yourself, maybe that's useful, right? You can have consortium chains, you know, you can have, you know, proper, say, Ethereum side chains and then public chains, right? And with Firefly, what's really cool is you can sort of have an app that interacts with all of these layers at the same time, right? So here's an example using Firefly with Polygon, Ethereum, Mainnet and some hypothetical consortium chain, right? So this kind of thing is and has been deployed in the wild. And then, you know, this is sort of what it looks like in a pure sort of Ethereum universe. This is at least consensus's vision for what hybrid blockchain should look like where you have all of these sort of separate chains or layers and they're all connected with zero-knowledge bridges and you can put together various kinds of ZK proofs and have everything work together and sort of compose where like, you know, a chain at the top compresses a bunch of transactions using say a zero-knowledge proof and then post them on the next chain down the layer and this whole thing propagates all the way down, right? And if you're at the top, you sort of get very nice privacy guarantees and, you know, your transactions are still ultimately anchored in this case, the Ethereum, Mainnet. And finally, I want to mention that it's very possible to build your own hybrid system using tools from Hyperledger. So here I'll mention Hyperledger Cacti and Hyperledger Huey. So we have interoperability and integration tools that allow you to build a hybrid blockchain system, in fact, between many different kinds of blockchains. And as I said, you know, Cacti was used in the IPV application earlier, it's been used in a lot of different hybrid blockchain cases, but this is not a talk only on Cacti, so I'll just, you know, briefly mention what it is. It's a pluggable enterprise-grade framework to transact across multiple different distributed ledgers without necessarily introducing another blockchain. So the idea is you shouldn't have to build a blockchain of blockchains if you want to use Cacti, right? You can do that if you want and some people do that, but you don't have to. And sort of one of the problems we faced with bridging and integration is each ledger wants to build a bridge to each other ledger, right? And the problem with this is you get a quadratic number of bridges, right? And in this slide, if you have 100 ledgers, and this is not so unreasonable if you count like different versions of each ledger, then you'd have 5,000 integration scenarios, and this is just completely untenable and unscalable in the long run. And one of the really neat things about the Cacti architecture is that this becomes linear. So I do want to mention something about bridges because people talk a lot about bridges and it's a hot topic, hot in both people talk about it and the bridges are on fire often. So I always encourage people to use atomic swaps whenever possible instead of bridges, right? An atomic swap is when you transfer assets on two different chains simultaneously, but the asset doesn't go between different chains. But in some cases, digital assets do need to move from one chain to another. There are a number of different cases like if you need to inject value represented in public chain crypto to a side chain system, for instance, or something like that. You have to deal with taking an asset out of circulation from one chain before you move it to a target chain. Bridges are secured in a number of different ways, but oftentimes not really well. And I just want to say, this is a recent article from CoinDesk. Are bridges safe? Why bridges are targets of hacks? I'll just say that if you want to use a bridge, be very careful. And finally, I just sort of want to put it all together with a pretty generic application. So here's a hybrid blockchain for trade finance, right? And you can see how a user might use a bridge to go between Ethereum and a DeFi application. And I don't think I need to necessarily read everything out, but this is something that someone interested in a hybrid blockchain might want to build. So yeah, that's about it. Are there any questions? I'm obligated to show this by my marketing folks. Yeah, absolutely. But I'm gonna ask back to you, can you give me a little more information on what exactly you want to do? Can you give me a hypothetical that I can play with? Do you have like this one or do you have a favorite? So yeah, so the idea here is you'd want to be able to move tokens and information right between Casper and private fabric deployments, right? And this was done, I actually do know a good deal about how this was done. This was done using hyperledger cacti. And the actual mechanism of the bridge was HTLCs, so hash time lock contracts. So you familiar with those? Okay, so probably a little bit too much to explain without a slide or a whiteboard, but the basic idea is you sort of, you do a not too complicated locking protocol where you lock a protocol on one chain and sort of, well, you can either use it for atomic swaps or mint and burn. In this case, it would be mint and burn, right? But you would sort of lock it, create a locked version and then unlock and burn in a way that sort of both had to happen or both didn't happen. It's, I really need a screen of math to show you this exactly. But if you look up HTLCs and you can actually go to the hyperledger cacti GitHub and they'll have an explanation of HTLCs, that's exactly what they're using here. Did that answer your question? Yeah. So they, cacti has a number of different ways to do this. There are a number of different contributing companies and they all like to do their, their bridging and atomic swaps a little bit differently. So like IBM particularly likes HTLCs. Accenture likes overlay networks. Fujitsu likes blockchains of blockchains. And the idea is the framework is flexible enough for you to do all of this. Any other questions? I think we have a couple of minutes left. So there's sort of two things, right? I guess what I really like is sort of the dream architecture is we have like a modular set of blockchain components that we can build systems from, right? So I might want to run a private network, right? And, you know, I don't want you on my network. I don't want anyone else to see what's on my network, right? And maybe I want to like check in and interoperate with other networks, right? So in this sense, the sort of proliferation is necessary and it's very hard to avoid. Now the proliferation and different components and like, you know, different like technical blockchains. Yeah, I mean, I like, I don't know what the right numbers of different software is, but if I have to write an application twice, even twice, right? Because I'm working on different chains, that's really frustrating and annoying to me, right? Well, I mean, I don't know, right? We have like certainly networks with 400 databases today, right? That are all interconnected, right? And there may be reasons why they're separated. So, right? Yeah, well, I mean, if you add the, certainly, you know, more centralized networks gives you something with less security, right? There's no question about that. But sometimes that can't be avoided. Like, if you're in finance, right? You know, you absolutely cannot let, you cannot have certain data be public, right? And it's just the law, right? If you don't do that, you go to jail, right? So in this case, right? There are some things you just cannot, like you cannot let them be fully public. You know, look, I agree that we're probably in a place where we have too many networks and there probably is room for some consolidation. But I don't think, you know, we can sort of, we can't consolidate down to the maximum technical limits necessarily because of non-technical reasons, not because of technical reasons. Which system experts? I don't know, I mean, it's, you know, well, yeah, I mean, it's definitely, it's still a space that needs to grow up. Like, it's still quite new, right? I mean, particularly like, yeah, I guess saying that it's new is, you're right. Saying that it's new is not correct. Saying that it's rapidly changing is more correct. And sort of like, we don't know. I don't think layer one can solve everything. I don't think any, I don't know a lot of people to do. I mean, even the, yeah, I mean, I don't know. I don't know what the future of all this, right? I mean, as I said, I think it is changing a lot. And, you know, it's hard to predict the future. Well, I would assume blockchain. I mean, I don't, what is going to be changed on? Why? But we can use post quantum encryption. I mean, most blockchains don't use encryption anyway, right? They just use signatures. They won't actually get that much slower if we use post quantum signatures, right? If we replace ECDSA or whatever your blockchain signature of choice is with a number of different post quantum signature protocols, say Falcon, you know, signatures are, it's about the same in terms of computational speed. The loss is mostly in the key size. I'm sorry. I'm not sure like why, we can just immediately switch to post quantum signatures. We can switch to post quantum cryptographic primitives and sort of everything continues as the same. I don't know. That's a great question. But we can do it on the fly, right? We can just say, you know, we're switching. We're going to resign stuff with post quantum signatures and we're good. So that's a Ford secrecy issue and I agree with you. That is the main issue with a powerful quantum computer, right? Is that if I have data today that's valuable when a powerful quantum computer comes out and you have that data, I'm in trouble. Not necessarily. So smart people are putting information theoretically hiding proofs and hashes on the chain. Right, so if you're familiar with ZKPs, right? You know, they can be perfectly hiding and information theoretically binding or perfectly binding and information theoretically hiding, right? So if I post perfectly hiding ZKPs, right? That means if you have a quantum computer, you can forge a proof, but you can't go back and see what information I had in these proofs because they're perfectly hiding. So all of the, this is like pretty well known in the space and I won't say all because there are some people making not great decisions but the people making good decisions are using information theoretically hiding, perfectly hiding proofs on blockchain for this very use, for this very reason. So yeah, so look, I totally agree with you that you need to understand quantum attacks to design a blockchain of the future. But I mean, I sort of, I view the quantum stuff in a cryptography space, right? So it's sort of, it sits as a different layer than blockchain, right? So blockchain is sort of dependent on that, right? Sure, but I mean, if you use, you know, that they're only a handful of cryptographic protocols, right? Signatures, key exchange, and probably zero knowledge proofs, right? Those are the three primitives. Like there are some blockchains that use more than that, right? You might wanna use threshold signatures, for instance, but there are a relatively small number of primitives that you reuse across the whole stack. And if you just, you know, replace those with post-quantum primitives, then you're good, right? This is another reason not to hard code cryptography in your blockchain, which some people do, unfortunately, but yeah, it's a relatively small number of things, right? You can use, you know, you can use your favorite key exchange protocol. If you like security, maybe Frodo, right? You could use, you know, Falcon for signatures, and then you could use Starks for your ZKP, and they're still pretty efficient, right? And then you'd be good for post-quantum. I'm told we are out of time. I'm more than happy to talk about this. Like, thanks, yeah.