 And YouTube looks to be up. Okay. Thanks so much Helen. All right. Good morning. Good afternoon and good evening everyone. Thank you so much for taking the time to join us here with hyper ledger in depth with font network today. We have a very interesting topic. There's been a lot of buzz and interest for this session. So we look forward to getting started soon. We have a couple of house keeping things that I want to cover before we dive in with Luke. As with any meeting, if you've been to something here before at the Linux foundation or hyper ledger, we have an antitrust policy. So all our meetings. Are require us to say this at the very beginning. Please review this on our website or on our wiki page. And, and you can refer to it there. This session is being recorded. It will be available on our website. Shortly thereafter. And also on YouTube. We're actually currently on YouTube live right now. You will also be able to receive the slides, which will also be available on our website as well. But don't worry about it. No need to take screenshots. This is not like your typical webinar. We encourage and, and hope and expect for the audience to be engaged from the very beginning. So feel free to raise your hand. Feel free to post a message in the chat. And, and also share any Q&A is in the Q&A box. We will be monitoring the chat closely. So if there's anything that is inappropriate or self-promotional there, we will temporarily at least disable the chat. And, and, and manage that as well. So please, we're here to learn. We're here to hear what Luke has to share. And so please make sure that all the conversation is. Professional and appropriate. All right. Let's dive in with Luke. I'll hand it over to you so you can share your screen. Welcome. And let's get it started. Great. Thank you very much, Karen. Just when I share screen. Okay. Yeah. I have permissions now. Okay. You should see my screen now. Yes. Okay. Well, hello everyone and welcome to this talk on categorization and comparison of DLT interoperability solutions. What categories will we be using in this talk? We'll be using the ones that have been defined by the world economic forum. And I'd say last year. So we're going to discuss all the differences of these different categories and how they compare. Between them. So who am I? I'm head of innovation at Quad Network. Please keep your cell phone mute, everybody. Thank you. Yeah. We're getting a bit of, okay. That's better. Yeah. So I'm head of innovation at Quad Network and we've been doing lots of things in the R and D group. We've been working on a multi ledger application design. And implementation. We've been looking at multi ledger standardization. We've been looking at multi ledger standardization. We've been looking at multi ledger standardization. We've been looking at multi ledger standardization between technologies. And we've been working on the design of our DLT API gateway network. Those things might not mean anything to you right now, but hopefully by the end of the talk, you'll understand all of them. Previously I was a DLT researcher at King's College for a couple of years doing lots of different things related to blockchain voting. And I've done a PhD in distributed systems at Liverpool. And there's some more blurb on me to read later. So when I do long talks, I usually have a slide at the beginning to understand my audience. This usually works better in person because I can see people raise their hand much more cleanly, but we can try it on Zoom. So if you're ready to raise your hand or not in response to each of these questions, I can use that to know how to pitch the rest of my talk. So question one, who is actively working on a multi-ledger implementation? So this can be cross DLTs, cross DLNs between UTXOs or accounts. If you've got more information on all those things that you're doing, I would suggest you write them in the chat afterwards. But for now, just raise your hand if you're working on one right now. So three. Okay. Small number. All right. Okay. Next question. And who would like to be working on a multi-ledger implementation as soon, even if this is scheduled or if there's, you know, blue sky thinking. And for either of them, feel free to let us know in the chat for later. Okay. Seven, 10. Okay. 11. So again, 12, it's going up more time. I give it great. Okay. That's a few of us. That's about an eight of the group. Yeah. Yeah. That's, that is a few. Okay. And asking this third question. Cause why not? So who is here because they're interested in what core network is doing at the moment. Let's have a look at that. Oh, a bunch. How many is that? I couldn't see that actually. 44, 45. Okay. Great. Well, I'll, I'll mention a few things closer to the end of the talk. Okay. Thank you so much for the first part of the audience participation. You're very popular Luke apparently. Okay. So we've got a few slides on interoperability introduction. So this is the first slide introducing the first part of the terminology we're using for the rest of the talk. So, and we have got different distributed ledger technologies and different distributed ledger networks. So what is a different distributed ledger technology? Something like Ethereum based hyper ledger fabric based Bitcoin based. These are all different technologies. But then you can have multiple instances of networks using the same technology. So you can have a few different Ethereum networks, test net main net so on many different fabric networks implemented by different consortium. So when we talk about interoperability, we want to connect at least to DLNs together. And they may or may not have the same technology. And then, okay, that's the terminology. Then why do we want to do it? Here's, you know, a few basic ideas. There's different features in different technologies. There's a DLT apps that have already been built on a particular DLN, but actually we want to use a new DLN for some reason. Maybe it's quicker, but we still want to integrate with that app that's already being built. And maybe we just want to connect to multiple consortium networks that have already been established. And we have no say on the establishment of them. And they just ended up using different networks and possibly different technologies. So what are our main scenarios for interoperability? So I've got five categories here. The first three are, I would normally say cryptocurrency. This is a fabric talk. So digital asset, well, digital asset scenarios. So number one, the standard interoperability application is your atomic swap between ledgers. But then, okay, you might want to migrate. You might want to move a digital asset from one DLN to another. And you might want to, that might, migration might need to be permanent, but it could also be temporary and need to loop back. And you might need a different implementation to do a permanent burn and mint compared to lock, mint, lock and unlock on the way back. So there are three separate categories so far. And then we get to the more general categories at the end, reading data, transactional state from one ledger and putting that information on another ledger, or triggering a transaction on a second ledger from a transaction on the first ledger. So those are my suggested main scenarios. And now a bit more terminology I want to introduce the rest of the talk, mDAPs. So I'm sure you'll be familiar with the idea of a DAP. So a single ledger decentralized application. So I'm going to use mDAP for the rest of the talk to mean a DAP which is on, well, is connected to multiple DLNs. And yeah, so what are our assumptions about mDAPs? They can be written in any language. They just like that they'll have on-chain and off-chain components. But when we think of an mDAP, sometimes the on-chain components of an mDAP will be aware that it's operating in a multi-DLN manner. And sometimes it will not. We're going to go through this later. But regardless of which mDAP implementation we use, we like them to be trustless and have those two properties there. So what problems can occur when we interact with different DLNs? From a user perspective, we want to present them with a consistent experience, consistent interaction experience. But to do that, there is burden that needs to be on some developers to perform the integration and possible translation. And where this burden falls depends on what interoperability category you use. We're going to show this with lots of different diagrams in the next few slides. So mention this at the beginning. The different categories of interoperability by the World Economic Forum is these three ones. Cross authentication, oracles, or API gateways. We're going to go through lots of slides and show exactly what these are. And we're going to see how you create an mDAP with each of these categories. But before we do so, we want to just think about interoperability from a bespoke application point of view. Here is a bespoke mDAP that some company has built. And it wants to connect to three different DLNs. So what does the company building this mDAP need to do? It needs to understand how to connect to each DLN. It needs to understand how to call all the functions. It needs to understand what all the data means. It needs to understand how to provide the mapping between them in order to provide a consistent user experience. And this is very difficult to do. You need a highly skilled team to do this. Of course it's possible to do this. But it needs to be highly skilled. And when you start to introduce more and more DLNs, it gets even more complicated. So from a development scalability perspective, you should not go down this route. But even so, if you build a mDAP in this way, you'll have the multi-ledger logic, at least some of it embedded within the application, and possibly some multi-ledger logic embedded in the DLNs themselves. I'm going to give you an example. Using this model, you could write a hash, well, atomic swap via hash time locks by having an escrow and DLN1 and escrow and DLN2. And this logic might not be aware of which asset you're migrating. Sorry. It might not be aware if you're swapping this asset with another one on another chain. It just thinks that we're doing an escrow on one ledger. Or you could build this application with smart contracts that have explicit reference to the atomic swaps inside each DLN1, DLN2. I think that part of the talk will become more clear as we move on to the API gateway section. So our first interoperability category is cross-authentication. If you define this category, it requires separate authorization on each side of the interoperability connection. Here are some examples. So yes, atomic swap via hash time locks would fall under the cross-authentication category. You need to have a transaction on DLN1 signed by someone to lock the asset. Then you need to have the unlock and the unlock. So you can see there's authorized transactions happening on each side of the interoperability connection. DLN1, DLN2. It's a similar idea for bridges as well. An asset will only move on the bridge if a user sends the asset to a particular bridge address on DLN1. And if the asset arrives on the bridge address, then it will be minted on the other side with another transaction. So again, authorized transaction on one DLN, authorized transaction on the second DLN. Cross-authentication. And then the most complex version of this cross-authentication interoperability method is the DLT relays. So if you think of Cosmos, you think of Polkadot, they will they will be, in fact, they will operate as a distributed ledger network in the middle of at least two other distributed ledger networks. There will be a transaction on, let's say, DLN1 which will trigger a breakout into the DLT relayer in the middle, the hub. And then there will be a break-in onto the DLN2 on the other side. We'll show that better with the diagram in a second. But here's a note that I'm going to talk about DLT relays from the perspective that a DLT relayer is themselves a DLN. I'm going to forget about hash time locks on bridges for now but I'm going to be talking about this category of interoperability. Before you move on, Luke, there are a couple of questions. Let's go. One is from Nathan Phillips, what is the difference between federated side chains and relayers, off-chain atomic swaps and intermediary networks? Federated side chains? Off-chain atomic swaps and intermediary networks. So the atomic swaps, they do only one form of interoperability. If you remember those five interoperability scenarios from the beginning, they're only doing the first one, the swapping scenario. So then we've got the side chain and the DLT relayers. It depends how you implement DLT relayer. When I talk, I'm saying every time I mention DLT relayer, I'm talking about a DLN connecting two other DLNs. So if you do it in that way, you can have any form of interoperability from those five different points I described before. When you talk about side chain, side chain is not really an interoperability solution because you need I'm trying to think of how you mean in this question. A side chain, I'm going to come back to that question. Let me think about that question at the end. The other question was, what's the difference between composability and interoperability? Could they define what they mean by composabilities with DLT perspective? Nathan, if you could clarify that question a little bit more in the chat, we can come back to it. I know you're referring to DLT networks generally, Luke, but maybe could you share what blockchains or what DLTs that Quant does permit currently? Let's get to the Quant questions at the end. If we pick out the general questions for now, we'll do some Quant stuff at the end if we've got time. If you just check our website, it will be listed there. For the rest of the talk, I'm going to go between the diagram on the left, which is your DLN with the nodes, each circle is a node with a connection. I'm sometimes going to show a big circle with DLN in the middle for a simplified visualization. Yes, so this might help. A lot better than me just explaining. What does a DLN relayer look like? Sorry, a DLT relayer. It's DLT now because it can connect multiple different technologies together, but the DLT relayer itself is a DLN. Here in this diagram, we've got DLN2, which is natively connected to the DLT relayer because they share the same technology or they share the same protocol. On the left side, we've got DLN1, DLN3 with different technologies and so they need a bridge. They need a bridge to connect them. When you build an Mdap with a DLT relayer, you need to embed at least some of your multi-ledger logic to manage break-out break-ins. Okay. But we should, for resilience purposes, add API gateways when we operate around and with DLT relays. If we have a user on the right-hand side here, for example, and they want to connect to the DLT relayer but also a separate DLN, they should really be going through API gateways to get the resilience it can offer because a DLT API gateway can connect on the backend to multiple nodes so it has a lot more resilience than just building your application off one node. This is the first, we're starting to talk about combinations of interoperability here but not yet because you can see the API gateways at the moment in this slide, I just connected to one DLN each. Okay. I think I agree, oracles. So oracles allow users of a ledger to connect to external data resources because obviously you can't write in a smart contract, find out the weather from BBC Weather website because every node will compute, will look at that in a different time possibly but also behind different paywalls and then immediately you'll lose consensus on all your data. So oracles take data from somewhere else and put it into the ledger so it can be consumed but where they take data from can themselves be another DLN. This is why we're going to talk about it now. So oracles can have different architectures so oracle networks, so we can have a single oracle to bring in some data from an oracle. We can have two forms of decentralized oracle networks, permissioned access or permissionless. And an oracle like other dapps will have an off ledger program and on ledger aspects. So usually let's say an Ethereum or Basel world, Fabric world as well, your oracles are putting data into a smart contract but in the quarter world oracles because the smart contract is a bit different. The more signing transactions if some off-chain data exists. So here's the diagram for oracles. As we can see here when there's an on or off ledger trigger some data is taken from DLN1 and is put in DLN2. And again if you need to create an end app using oracles you will have to embed some of your multi-ledger logic within the ledger itself in the smart contract because you need to understand that you're taking data from an oracle which is from a different distributed network. So that's the centralized oracle on the screen there and then this is what a decentralized, one of the forms of decentralized oracle will look like. So in this diagram we have many different oracles all reading the same data from DLN1 and all pushing this data into DLN2 with a different transaction. But okay, when you have multiple oracles you might have a data consistency problem later so you need to think how to resolve data disagreements. So one way to resolve data disagreements with oracles is actually to come to consensus before you do the imports. So here you have three oracles all reading data from DLN1 and they'll communicate between themselves, come to an agreement probably with a multi-sig and use a single transaction to put that information on DLN2. But in this scenario when they're all doing separate transactions into a smart contract your logic to find the agreement with oracles needs to be in the smart contracts. Here's some possible ways to solve oracle data disagreements. Just a few ideas, you know, if numeric data you take some average or you discard out layers. There's many questions you need to answer when you're designing an oracle system and probably not the best person to say which is the best data disagreement method to choose. And just to finish this oracle section I want to again highlight the role of API gateways. So like in the DLT relayer slide API gateways were used for resilience purposes. Again for the oracle interoperability category we can use API gateways to bring in resilience and breaking the one to one connection between the off-chain component and the on-chain node. And before I take questions I'm going to clarify the difference between oracles and cross authentication. Cross authentication was the first WEF category oracles is the second. So if there's no cryptographic authentication required on the first side of the interoperability connection we have oracle category. So my example data here is the if die exchange rate changes a lot, changes a lot but it's nothing to do with the interoperability system just at some point the oracles are reading this exchange rate and they're going to be putting it on to DLN2. So the transactions that are changing the if die exchange rate and DLN1 have nothing to do with the interoperability system so we're in the oracle category. If there is cryptographic authentication on the first side which is directly related to the interoperability method such as a transaction to a bridge then we're in the cross authentication category. Okay, before I go to API gateways do we have any more questions sitting there that are interested? Yeah, someone is asking John Kenny is asking what are the points of failures of the oracle method? Failures. Well, yeah, if you've got a centralized oracle then you know your point of failure is this centralized off-chain oracle. If you've got decentralized permissionless oracle system then your points of failure is probably game-threatic related and how you resolve data disagreements in the smart contract. If you've got a decentralized permission oracle system your points of failure is probably your number of nodes let's say if you're doing a multi-sig here if some of them crash then you're going to be stuck. Well, if a certain number of them crash. That's a few ideas. Okay, thank you. Anything else? No, I think that's it for now on oracles we can address the others later. Great, okay. API gateways. So the final category from Weff. So what can an API gateway do? We've already in the previous slides we've been introduced to the first points they can provide access to many DLT nodes behind one fixed API. And of course they can do that using different permission systems designed by the gateway owner. They can provide access well like oracles they can provide access to other technologies and not just DLNs. Additionally, if we're talking in an interoperable DLT API gateway they can have shared endpoints across DLNs and they can produce and consume standardized objects and they can compress many actions into one endpoint. Okay, so let's see how that looks from a diagram perspective. An interoperable API gateway. So here we've got DLT API gateway it's connected to three DLNs each DLN has at least one connector and each connector is connected to at least one node from the DLN. And then we can build our end-ups against the API gateway and we can build them similar to the bespoke applications section I was talking about before we can build these end-ups where the multi-ledger logic either completely exists within this end-up application off-chain or partially exists also on the different ledger networks. So with an API gateway many users can share the same end-up or each user can have their own version of the end-up as long as your interoperability logic is stateless. That's why we can run them in multiple different locations. And yeah, this is what QuadNetworks Overledger Implementation is. So QuadNetworks Overledger is an API gateway that allows for this interoperability method. We can also, well, here we've got a centralized point of entry of the API gateway so to start to distribute our system a bit more we can split the API gateway up we can provide each user with an API gateway or we can provide multiple API gateways for different entrance points and advanced way to do this we can arrange, it is that we can arrange the API gateways in some form of network where they can share connectors between themselves. And this is the idea behind QuadNetworks Overledger Network Implementation. Any questions before comparison section? Yeah, Nathan is asking what are the advantages of API gateways over DLT relayers? Here we go, let's start let's start straight away let's do the comparison section. There we go. Thanks Nathan for leading us in. Yeah, yeah, thank you. Okay, so the first comparison I want to talk about is the data translation how each of these interoperability categories handle data translation. So we're going to be visualizing data with different colors here. The native data on DLM1 is the blue data the native data from DLM2 is the green data so on. So when we have a bespoke application we're getting the native data and also the native end points of course I mean as part of the data they're all coming back to the end up and the end up developers have just got a deal of it and just got to understand how one relates to the other and so on. When we have a DLT relayer basically the DLT relayer is forcing their data model onto everyone and so you see DLM2, DLM4 they natively interoperate with the DLT relayer that's because either the data format and the protocol is exactly the same or very similar enough to interoperate natively. But the other two DLNs on the left hand side DLM1, DLM3 they're built with different technologies different data formats, different interaction methods and so the translation between the two things is forced up by the bridge so the DLT relayer themselves is forcing their model onto everyone else effectively but okay that might be a good idea if there's only ever one DLT relayer in the world but that's not true there's many so one DLN so the data format and data interaction method of DLN1 can be translated in two different manners to two different relays so we still so now we have an inconsistency problem between DLT relayer 1 and DLT relayer 2 so we're sort of pushing the problem up a level for oracles the translation is forced upon the oracle developers native data comes out DLN1 and native data goes into DLN2 everything's in the oracle off-chain elements API gateway model there is quite a few API gateways around well especially for one chain and most of them at the moment they just sort of pass through the native data format of the underlying DLN so here you see DLN1 native data passed through straight back to the end up DLN2 native data format passed through to the end up again so API gateways in this form either connected to a single technology or a few others are just again they're just forcing the end up developer to sort it out they're not thinking about it these API gateways are only for to make you know infrastructure more resilient doesn't make the development process easier but okay we can if API gateways we can add another translation when the information the native data goes through the connector it can come out in two forms this is the idea here of the orange arrows from all the connectors orange is supposed to be like standardized data format standardized data format so API gateways can present the native format data and the standardized format of the data to the end up user so in that way it has a bit of an advantage over DLT relays is just forcing one format onto everyone ah yes but then the question is what because we're not being forced because each DLN is not been put into any specific data model like they are in the DLT real layer category actually what format should we be translating into as that is an important question so our idea is to follow the ontologies and the tax that are being created and developed within the ISO standards and to implement them and to implement them make them a bit more detailed so that's our idea of what format we should be translating into but just like the DLT realer scenario we can also have a problem with API gateways different API gateways can present different standardized data so here we've got an API gateway at the top that has an orange standardized data that's coming back so again the data integration problem is going up a little level just like in our DLT realer slides so this is why we are taking a leading role with MIT in developing into DLT API gateway communication because we recognize this problem and we know that we know that different API gateway operators and implementers if they want to work between them will have to come to some agreements on what is the consistent standardized data to present back to the user and we hope this will feed back into the ISO standards and it will all be looped so ISO working on the foundational data models and then this work here that you can look at later working at the API gateway to API gateway communication any questions on that for I go on to other comparisons no, not for now okay so I have another table of comparison here this I think is better summarized in the blog post it's a more detailed version actually in the blog post so if you are interested in all these other different properties that we have compared these categories against please look at the hyperlegic blog and we go in detail into these so the final thing I want to cover is how the categories can in fact all overlap so if you think about a DLT relayer this is how we are going to start our diagram DLT relayer is connecting two different ledges together that are natively interoperable and we are well as well as DLT relayer we might also be using an oracle so one of the chains connected to the relayer might actually be taking data via an oracle from another DLM and now that we have quite a few different networks we can introduce an interoperable DLT API gateway and this interoperable DLT API gateway can have connectors to all these different chains that we've mentioned but because it's an API gateway as well as connectors to distributed ledger networks it can also have connectors to related technologies so one API gateway on the left hand side might also have built a connector for the oracle and the different API gateways might have built connectors to different other technologies like file stores, database, legacy systems and now that we have our interoperable API gateways in place we can build our multi-ledger applications connected to them so if you look on the left hand side there is an atomic swap multi-ledger application and we can build it against the API gateway even though in fact the atomic swap end up is in the cross authentication category of WEF it's actually utilising the API gateway category and it's same on the right side so even though we have a more traditional oracle at the bottom on the top right we have another oracle multi-ledger application built against API gateway and so that's the second category of WEF so we got an application from the second interoperability category of WEF built against the third category and then we got a few other examples there but we can see that they all connect together they can all help each other so I have some conclusions so hopefully you got a nice understanding of this talk of the different categories in my opinion all the categories have their useful features I like them all but all the categories do require API gateway so you notice that in the first two categories I had a slide at the end about where the API gateway can be used for resilience even if it's just connected to one network and then once you introduce at least a single API a single chain API gateway you have the option to expand multi-chain API gateway and then you have the question of whether you should have this DLT API gateway as just having simple pass-through simple data pass-through from the underlying end or you should add more complexity you should have more standardization and standardized data standardized interaction methods so that leads on to my third point where I'm suggesting that the data interaction standardization is too difficult to perform at the Oracle layer especially Oracle's layer is very bespoke but also it's too difficult to perform at the distributed technology layer such as via a real layer because if we force everyone to follow the same standard as one real layer we're going to definitely be another real layer so we need to think at a higher level than just distributed technology about how to perform this standardization let me go a bit further on that for instance if we have DLT practitioners around the world that understand the different technologies that are in place and they come up with ISO standards in two or three years that are perfect to describe everything that is not going to change the data model of distributed technologies already out there it's not going to change the data model distributed technology real layers already out there but API gateway data models they can adapt they can evolve and they can improve they can incorporate new interoperability features as the domain expands that's my conclusion I've got some time for questions thank you so much Luke this is great really comprehensive overview of the different aspects of interoperability and different mechanisms for it we do have a few questions so let me take one of the more recent ones it relates to what you were just talking about what changes are required in existing API gateway products to address the multi DLT requirements well they need to think in a multi DLT world if you think of people like you know like in Fiora they're passing through the data model underneath of the current EF1 implementation I'm not 100% sure how they're going to manage EF2 if it's different but they're going to have different data models and they're going to they could be inconsistent maybe if they start to introduce another technology and then they're going to have the problem that we outlined where you're just pushing the integration to the app developer app developers so it's not a very nice development experience so they need to work out the similarities between the chains and start to present that back to the users so the developers don't have to be worldwide experts or blockchain to understand what they need to do another question we got what from Jacques Bicundo is do the DLT relays act like mediator agents sorry do the DLT relays act like mediator agents I guess they do they're a decentralized decentralized network of agents yes forwarding messages from one chain to another and back again I don't know if they're mediating it well they're not really mediating anything in the sense of resolving anything they would just be forwarding valid messages and returning valid messages the other way so in a sense yes in a sense no okay I'm going to keep looking through the many questions here if anyone wants to ask a question live since we have a good amount of time please just raise your hand and I will invite you to come off of mute so while people are thinking of their live questions I think this was a follow-up onto the last the second to last question we asked was how would key management work in a multi-DLT system how would key management work sorry just one second can you see my slide still yes I can that's good yes you would have to have well depends what you want to do you can either have general wallets for each different chain or you can create general wallets with all your different keys in so I think that's the simple answer to the question if you want to go more complex I mean I think let's leave it there okay Nicholas has a question Nicholas feel free to come off of mute can you hear me yes I can hear you hi Luke great talk as usual and I think I just had a question about so as domains and connector frameworks proliferate I just was wondering how will API gateways deal with that potential overhead and a second question is that do you see a kind of trust spanning layer emerge so that DLTs can communicate with one another without necessarily having to say download an entire library I guess of connector frameworks that in order to like resolve or route messages to and throw DLTs and DLS I might ask you to repeat this the second part in a second so I just yeah you said I was just thinking of the first part so okay how to deal with you know the profiteration of the resources and distributed technologies or not yes and yes this is why we want to move quite never personally we want to move from a single API gateway system to more of a network so that and other members or partners can present connectors for particular the resources so that the load of building connectors moves away from just our team or just someone else's team if they have a similar product and so understanding how to incorporate connectors from third parties in a way that will keep data integrity and keep the data quality good is a very interesting problem for this subcategory that we're working and we're getting there little by little that's the first question and then we have the trust spanning layer and could you just repeat the high level yeah I just wanted to you know thinking about like the domain name system that we have currently it's like very well established and tried and true but I'm just wondering as well like is there a way for a protocol based trust spanning layer between all DLTs and DLNs that is lightweight in essence like that doesn't need for again an entire library of connector frameworks to be managed that possibly can't even be bootstrapped independently of like a DNS routing system is that like do you think that's like somewhere where we could be going it's involved sorry sorry okay trust spanning layer between DLNs and without introducing another blockchain yeah I mean okay so yeah we have been thinking about this and we have this set of a multi ledger token that can exist on multiple chains at the same time and be transacted by it can be transacted by a transaction that lands on any one of the connected chains at the same time yeah we are in the process of trying to get that patented but yeah probably concept me for more details on that I'm not sure where I'm actually absolutely I just actually I'm reminded of just like potentially ODAP as an analogy do you think like ODAP could work is that trust well ODAP currently has the trust assumption on the the API gateways like a permission trust assumption and moving it to a trustless method is also difficult and we've left that as future work at the moment that would be the ideal way to move that forward thank you Nicholas for your questions yeah Luke there's been a couple of questions just generally wanting to understand the difference between a few different of the DLTs out there so for example you know what's the main differences between quantaver ledger hyper ledger cactus inter ledger flair and I think those are all the ones a sore chain and and then a specific question so just sort of speak maybe generally you know what's sort of how does it compare amongst all these other ones that are out there and then there was a specific question on how do the different interoperability approaches compare in performance metrics which I imagine it depends on which one you're using as well so different interoperability solutions so inter ledger is just for assets flair I thought that was another network which requires bridges into it as far as I'm aware swan chain I'm not 100% sure what swan chain is hyper ledger cactus yeah it's an interesting one I'm trying to keep up with it but I'll have a look at more videos but hyper ledger cactus so is there anyone for hyper ledger cactus on the call that silence probably means no type in the chat if you if you're familiar with it well I thought maybe a hyper ledger cactus person was it would appear but okay from my understanding of the current development of cactus is that they don't have the standardized data and they connect to a I think a set of permission nodes in the back end so I mean from I might be wrong because I haven't looked at it for the last few months but from hyper ledger perspective the new things that we are trying to introduce is the resources on the back end so how to build a gate how to build an API gateway system where we're not in control of all the resources behind the gateway so I mean all the connectors behind the gateway and how do we make sure that works you know really resilient system so I mean in my opinion that hasn't been done before and that's why it's so interesting so if anyone wants to clarify anything about cactus I can't see the text but maybe that's something we can produce from our marketing department at some point about all the differences of all these different chains I'm going to write that down yeah there are a few projects hyper ledger focused on interoperability or integration cactus is one of them but we also have a hyper ledger lab that was it's very new so I'm sure you haven't had a chance to look at it Luke call type they're calling themselves weaver so I invite everyone to take a look at our wiki.hyperledger.org to learn more about cactus in the page there we also have several talks in our YouTube related to cactus as well and then you can go to our hyper ledger labs on github to learn more about weaver as well I wanted to give Nathan Phillips who has raised his hand a chance to ask a question Nathan do you want to come off of mute hello can hear me yeah so just one minute real quick hey Luke and Karen thanks very much for hosting the webinar um yeah I just had a question about the transaction finality how would that work if let's say you had two different uh DLNs with different consensus mechanisms how would that change the transaction finality if it went through one API gateway thank you so yeah you're going to have to deal with that as part of your multi ledger logic so of course all the chains that have immediate transaction finality those are all no problems um but okay the ones that can be can be rolled back is what I call it anyway like the proof of work ones that they can go on a different fork um yeah you have to embed the logic within your off-chain system to make sure it's resilient uh and it can it can reverse it if you have the rights depending on the application but okay in an atomic swap one you have to be careful yeah you have to stop your bitcoin after one block make sure make sure you have good logic rules in there I just remember I forgot to look at the performance question previously but the performance of the different categories so so our three categories um the performance of the different interoperability categories are all dependent on the DLT logic the DLTs that you're using really there are gateways, oracles they cannot go around the transactions per second of the DLTs that you're connecting to so um if you want fast finality you need to choose a fast change regardless of which interoperability category you're using thanks so much Luke really appreciate you answering so many questions and thank you everybody for all your questions this is wonderful I already see here in the chat Nicholas and Raphael are talking about how we could talk about how Cactus fits into the WEF interoperability schema that's a conversation you all could take to our chat.hyperlegio.org Cactus has a channel there you could start a discussion there so that you can continue this conversation I'm just going to do a couple of announcements here at the end thank you so much for joining today I hope you found this useful and helpful and feel free to reach out to us or to Luke if you want to learn more like I mentioned at the beginning the recordings and slides will be available on our website we actually have another one of these hyperledger and depth sessions coming up in our Asia community tomorrow on bond blocks so take a look at that and sign up on our website at hyperledger.org we also have our global forum coming up in a few weeks actually June 8 to 10 this is where you could hear a lot more talks just like this we have some amazing keynotes planned for you I believe more than 100 talks and presentations across programming in Europe and America and programming in Asia it's really going to be a very exciting few days so I invite you to please register and join us there thank you so much Luke again thank you everyone for attending and we look forward to seeing you in our community whether it be a meetup group the next webinar in our various working groups and SIGs etc thank you very much, it's been interesting