Hyperledger Foundation Hyperledger Member Webinars, 19 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Hyperledger In-depth: Quant Network: Categorization/comparison of DLT interoperability solutions

Description

Over the years, there have been many attempts to solve the problem of interoperability. Of the various approaches taken, the World Economic Forum (WEF) identified three main categories: Cross Authentication (DLT-relayers), Oracles and the API Gateway. Which, of course, begs the obvious question: how do these categories compare and which is more suited for enterprise deployments? Join Luke Riley, Head of Innovation for Hyperledger member company Quant Network for this in-depth presentation and discussion.

In the “Hyperledger In-depth: An hour with… .” series, Hyperledger members share learnings from their projects and try to answer all the hard questions about the pains of working with DLTs. It is not yet another webinar: participants will be encouraged to take part, come with prepared questions and voice opinions. Expect live demos and tutorials, stories from the battle field and hopefully some heated discussions. Let’s get out of the zoom fatigue and engage to share experiences and build a stronger community.

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #HyperledgerMemberWebinars

A

And uh youtube looks to be up.

B

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 hyperledger in depth with quant network. Today um we have a very interesting topic. um There's been a lot of buzz and interest for this session, so we look forward to getting started soon, a couple of housekeeping things that I want to cover before we dive in with luke.

B

um As with any meeting, if you've been to something here before at the linux foundation or hyperledger, we have an anti-trust policy. So all our meetings um are uh 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.

B

You will also be able to receive the slides, which will also be available on our website as well. So don't worry about it, no need to take screenshots. um This is not like your typical webinar. We encourage and uh 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. As in the q, a box, we will be monitoring the chat closely.

B

So if there's anything that is inappropriate or self-promotional there, um we will temporarily at least disable the chat um and uh and and manage that as well. So please um we're here to learn we're here to hear what luke has to share, um and so please make sure that all the conversation is professional and appropriate.

B

All right, um let's dive in with luke I'll hand it over to you. So you can share your screen. um Welcome and uh let's get it started.

C

Great, thank you very much. Karen um just with a share screen: okay, yeah. I have permissions now.

C

Okay, you should see my screen now.

A

C

Okay, well, hello, everyone and welcome to this talk on categorization and comparison of dlt interoperability solutions.

C

What categories will we be using in this talk, uh 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.

C

So, who am I I'm head of innovation at quad.

A

B

Please keep your um cell phone mute everybody. Thank you.

C

Yeah we're getting a bit: 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 d group we've been working on uh multi-ledger application, design and implementation. We've been looking at multi-ledger standardization between technologies and we've been working on the design of our dlt api gateway network.

C

Those things might not mean anything to you right now, but hopefully by the end of the talk. You'll understand all of them, and 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.

C

This usually works better in person, because I can see people raise their hand much more cleanly, but we can try it on zoom.

C

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 um cross dlts cross dlns between utxos or accounts.

C

If you've got more information on all 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 uh working on one right now so three, okay, small number, all right, okay, next question: um who would like to be working on a multi-ledger implementation uh soon, uh even if this this, if this is scheduled- or if this you know blue sky thinking and for either of them, feel free to, let us know in the chat for later: okay, seven, ten, okay, eleven!

C

So again, twelve! It's going up more time! I give it great okay. So that's a few of us that's about an eight of the group, yeah yeah! That is a few okay and asking this third question, uh because why not so who is here because they're interested in what quad network is doing at the moment?

C

Let's have a look at that.

B

C

How many is that I couldn't see that actually um 44 45, okay, great well I'll I'll mention a few things closer to the end of the talk. Okay,.

A

Great. Thank you.

C

Very much for the first part of the audience, participation.

B

You're very popular look apparently.

C

You know okay, so we've got a few slides on interoperability introduction. So this is the first slide introducing uh the first part, the terminology we're using for the rest of the talk. So um we have got different, distribute ledger technologies and different distributed legend networks. So what is a different distributed? Ledger technology, something like ethereum hyperledger fabric based bitcoin based these are all different technologies.

C

But then you can have multiple instances of networks using the same technology, so you can have a few different ethereum networks, test net mainnet so on many different fabric networks implemented by different consortium.

C

So um when we talk about interoperability, we want to connect uh at least two dlns together and they may or may not have the same technology.

C

And then okay, that's the terminology, then why do we want to do it? uh Here's a you know a few basic ideas, there's different features in different technologies: there's uh 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.

C

That's already been 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.

C

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, um they're, all digital asset scenarios, so number one. The standard interoperability application is your atomic swap between ledges, 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.

C

My 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 um triggering a transaction on a second lecture from a transaction on the first ledger.

C

So those are my suggested main scenarios and now a bit more terminology. I want to introduce the rest of the talk mdapps, 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 endapp for the rest of the talk to mean a dap which is on well is connected to multiple dlns and yeah. So what are some? What are our assumptions about? Mdaps?

C

They can be written in any language um they just like dapps they'll have on-chain and off-chain components, but when we think of an mdap, um sometimes the on-chain components of an end app will be aware that it's operating in a multi dln manner. Sometimes it will not we're going to go through this later, um but regardless of which mdap implementation we use. We like them to be trustless and have those two properties there.

C

So what problems can occur when we interact with different dlns and 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.

C

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 end up with each of these categories.

C

But before we do so, we want to just um think about interoperability from a bespoke application point of view. Here is a bespoke md, app that some company has built and it wants to connect to three different dlns.

C

So what does the company buildings mdap need to do? It needs to understand how to connect to each dln. It needs to understand how to call all the functions needs to understand what all the data means and it needs to provide the mapping between them in order to provide a consistent user experience- and this is this is very difficult to do. You need a highly skilled team to do this.

C

Of course, it's possible to do this, but it needs to be highly skilled and um when you start to introduce more and more dlns, uh it gets even more complicated. um So it's from the development scalability perspective. uh You should not go down this route.

C

But even so, if you build a mdap in this way, you'll have the multi-ledger logic, uh at least some of it embedded within the application and possibly some multiledger logic embedded in the dlns themselves. I'm going to give you an example: you can um using this model, you could write um a hash, well, atomic swap via hash time locks um by having an escrow and dlm-1 and escrow and dln2, and they this logic might not be aware of which um asset you're migrating sorry.

C

It might not be aware on if you're swapping this asset with another with another one on another chain. It just thinks that we're doing an escrow on one ledger or you could build uh this application with smart contracts that have explicit reference to the atomic swaps inside each dln1. Dln2.

C

I think that that part of the talk will become more clear as we move on to the api gateway section.

C

So our first interoperability category is cross-authentication.

C

How do we define this category? It requires separate authorization on each side of the interoperability connection.

C

Here are some examples, so, yes, um hash time, lock, atomic swap via hash time locks would fall under um the cross authentication category. You need to have a transaction on dln1 signed by someone to lock to lock the asset. Then you need to have a transaction on dln2 signed by someone else to lock the asset um there. Then you need to have the unlock and the unlock, so you can see. There's uh authorized transactions happening on each each side of the interoperability connection on dln1 dln2.

C

It's a similar idea for bridges as well, so um an asset will only move on the bridge if, uh if a user sends the asset to a particular bridge address on dln1, and if if the asset arrives on the br 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 more the most complex version of this cross. Authentication interoperability method is the dlt relays.

C

So if you think of cosmos, you think of polka dot, um they will, they will be effect. They will operate as a distributed. Ledger network in the middle of at least two other distributed: ledger networks and there'll, be a transaction on, um let's say dlm-1, um which will trigger a breakout into the um dlt relay in the middle, the hub and then there'll be a break in onto the dln 2 on the other side.

C

We'll show that better with the diagram in a second but here's. Here's a note that I'm going to talk about dlt relays from the perspective that a dlt ruler isn't is themselves a dln. I'm going to forget about um hash time, locks and bridges. For now, when talking about this category of interoperability,.

B

Before you move on luke, there are a couple questions.

D

A

Let's go yeah so getting quite.

C

Detailed already.

B

um So one is from nathan phillips what is the difference between federated side chains and real layers, off-chain atomic swaps and intermediary networks.

C

It's so federated side chains, off-chain atomic.

B

Swaps and intermediary networks.

C

Okay, so the so the atomic swaps, uh they do only one form of interoperability. If you remember those five interoperability scenarios from the beginning, uh they're only doing you know the the first one, the the swapping scenario. So then we've got the side chain and the dlt relayers.

C

uh It depends how you implement dlt uh relayer, so yeah this this slide is all about I'm for the for this talk, I'm uh I'm saying every time I mentioned dlt relay I'm talking about a dln connecting two other dln's.

C

So if, if you do it in that way, and you can have any form of interoperability from those five different points I described before and when you talk about side chain, um a side chain is, is not really an interoperability solution, because you need I'm trying to think of trying to think of how you mean in this question.

C

A side chain I'm going to come back to that question. Let me think about that question. At the end.

B

Okay, yeah. um The other question was: what's the difference between composability and interoperability,.

C

And could they define what they mean by composability from dlt perspective.

B

um Nathan, if you could clarify that question a little bit more in the chat, we can come back to it. um I know you're referring to dlt networks generally luke, um but maybe could you share what chain, what blockchains or what dlts that quant does permit? Currently.

C

uh Okay, let's get to the quant questions at the end, I think yeah, let's do if we pick out the general questions for now and we'll do some quant stuff at the end, if we've got time, okay.

B

C

Yeah, but I mean, if you just check our website, that you'll be listed there.

C

Okay for the rest of the talk, um I'm going to uh go between the diagram on the left, which is your uh dln with the the nodes. Each circle is a node with a connection and I'm sometimes going to show a big circle with dln in the middle just for a simplified visualization.

C

uh Yes, so this might help a lot better than me just explaining uh what does a dln relay? Look like sorry, a dlt relayer, it's dlt now, because it can connect multiple different technologies together, but the dlt relay itself is a dln.

C

So here in this diagram, we've got dln2 dln4 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 a dln1 dln3 with different technologies, and so they need a bridge. We need a bridge to connect them um and when you build a an mdap, a with a dlt relayer, you need to embed at least some of your multi-ledger logic inside the ledges themselves to manage break up break-ins.

C

Okay, but um we should for resilience purposes, uh add api gateways when we operate around and with dlt relays. So um if we have a user on the right hand, side here, for example- and they want to um connect to the dlc reload, but also a separate dln, they should really be going through api gateways to get the resilience it can offer, because a a dlt api gateway can connect on the back end to multiple nodes. So it has a lot more resilience than just building your application off one node.

C

So 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 are just connected to one dln, each okay, uh so the second category oracles, so oracles um oracles allow uh users of a ledger to connect to external data resources, because you can't, obviously, you can't write in a smart contract, find out the weather from a bbc weather website, because every node will will compute we'll look at that at a different time, possibly and also behind different paywalls and then immediately you'll lose consensus on all your data.

C

So oracles take data from somewhere else and put it in to the ledger, so it can be consumed, but where they take, data from can themselves uh be another dln. This is why we're going to talk about it now so oracles can have um different architectures oracle networks. So we can have a single oracle to bring in some some data. That would be a centralized oracle.

C

We could have two forms of decentralized oracle networks, permissioned permission, permissioned access or permissionless, and an oracle, uh like other adapts kind of will have an off ledger program and on ledger aspects.

C

So usually, let's say an ethereum or basu world fabric world as well. The oracles are putting data into a smart contract, but in in coda world and your oracle's, uh because the smart contract's a bit different, the more signing transactions. If some offchain data exists.

C

So here's the diagram for oracle's, um as we can see here, the when there's an on or off ledger trigger um some data is taken from dlm-1 and is put in dln2 and again. If, 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 we need you need to understand that you're taking data from an oracle which is from a different distributor network.

C

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.

C

But okay, when you have multiple oracles, you might have a data consistency problem later, so you need to think how to resolve um data disagreements.

C

So one way to resolve data disagreements with oracle's is actually to come to consensus before you do the import.

C

So here um you have three oracles all reading data from dln1, then they'll communicate between themselves uh 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 agreement between the oracles needs to be in the smart contracts.

C

And here's some possible ways to solve um oracle data disagreements. uh Just a few ideas. You know if numeric data you take some average or you discard outliers, um there's many questions.

C

You need to answer when you're designing an oracle system, uh I'm probably not the best person to say which is the the best data disagreement, a little data agreement method to choose.

C

And just to finish this oracle section, I want to again highlight the role of api gateways so like in the dlt relayers slide api gateways we use for resilience purposes uh again for the oracle interoperability category. We can use api gateways to bring in resilience um breaking the one-to-one connection between the off-chain component and the on-chain node.

C

And before I take questions, I'm going to clarify the difference between oracles and cross-authentication. Cross-Authentication was the first west category oracle's the second.

C

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 uh the if die, exchange rate changes a lot changes a lot, but it's nothing to do with the interoperability system. uh Just at some point, the oracles are reading this exchange rate and they're going to be putting it onto dln2, so uh the transactions that are changing the if die, exchange rate and blm1 have nothing to do with really interoperability system, so we're in the oracle category.

C

If there is um 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.

C

uh Okay, before I go to api gateways, do we have any more questions sitting there that are interesting.

B

uh Yeah um someone is asking uh john kenny's asking what are the points of failures of the oracle method.

C

With failures um well yeah, if you've got a centralized oracle, then you know your um point of failure. Is this centralized off-chain oracle if you've got decentralized, um decentralized, permissionless, oracle system, then your point of failure is uh probably game, theoretic related and how you resolve data disagreements in the smart contract um if you've got a decentralized permission, oracle system, your points of failure is um probably your number of nodes, your um let's say, if you're doing a multisig here, if some of them crash, then you're gonna be stuck uh well.

C

If a certain number of them crash, that's a few ideas.

B

Okay, thank you.

C

B

No, I think that's it for now on articles we can address the others later.

C

Great okay, uh api gateways, uh so the final category from 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.

C

They can provide access well, like oracle's. They can provide access to other technologies, not just dlns. um Additionally, if we're talking interoperability 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, uh an interoperable api gateway.

C

So here we've got a 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.

C

And then we can build our mdaps 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, uh where the multi-ledger logic either completely exists within this mdap application, off-chain or partially exists also on the different ledgers ledger networks.

C

So, with an api gateway, many users can share the same end app or each user can have their own version of the end up as long um as your interoperability logic is uh trustless. Sorry naturals um is stateless yep and that's why we can run them in multiple different locations and yeah. This is what quad networks overlapped. Your implementation is, uh you can have so quad networks over ledger is an api gateway that that allows for this interoperability method.

C

We can also um well you know here: we've got a centralized point of entry, 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 an advanced way to do this we can arrange is that we can arrange the api gateways in some form of network where they can share connectors uh between themselves, and this is the idea behind quant networks, network's overledger network implementation,.

C

Any questions uh before comparison section.

B

Yeah um nathan is asking what are the advantages of api gateways over dlt relayers.

C

um Here we go, let's start, let's start straight away: let's do the comparison section. Oh.

B

That's there we go thanks.

C

For leading us in yeah yeah, thank you, okay. So the first comparison I want to talk about um 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. uh The native data on dln1 is the blue data. The native data from dln2 is the green data, so on so when we have a bespoke application, we're getting the native data and also the native endpoints.

C

Of course I mean in uh as part of the the data and they're all coming back to the end up and the end-up developers have just got to deal with it and just got to understand how one relates to the other and so on.

C

When we have dlt relayer it's basically, the dlt relayer is forcing their data model onto everyone, and so you see dln2 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, the lm1, dln3 they're, built with different technologies, uh different data formats, different interaction methods, and so the translation between uh the two things is forced up by the bridge.

C

um So the dlrt reeler themselves is forcing their model onto everyone else effectively.

C

um But okay. um That might be a good idea if that, if there's only ever one dlt relay in the world- but uh that's not true, um there's many so one dln, so the date of format and the data interaction method of dln1 can be translated in two different manners uh to two different relays.

C

So we still so now we have a inconsistency problem between dlt relayer, 1 and dll dlt, reload 2.. So we're sort of pushing the problem up a level.

C

For oracles, the translation is forced upon the oracle developers. Native data comes out, dln1 and native data goes into dln2. Everything is in the oracle of chain elements.

C

Api gateway model- and there is there- is quite a few api gateways uh around well, especially for one chain um and most of them at the moment they just uh sort of pass through the native data format of the underlying uh dln. So here you see dln1 native data passed through straight back to the end up. Dln2 native data format pass through to the end up again so api gateways in this form uh either connected to a single technology or a few others.

C

uh I just again they're just forcing the mdap developer, to sort it out, they're they're, not thinking about it. These api gateways are only for uh to make your node infrastructure more resilient. Doesn't make the development process easier? What I'm trying to say, but, okay, we can for api gateways. We can add another translation when the information the native data goes through the connector, it can come out in two forms.

C

This is the idea here of the orange arrows from all the connectors orange is supposed to be like standardized data format, standardized interaction, method and 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, uh it has a bit of an advantage over dlt relays is just forcing one format onto everyone.

C

ah Yes, but then the question is what, uh because we're not being forced, because each dln is not being forced into any specific data model like they are in the dlt real layer category. Actually, what format should we be translating into? That is an important question, so our idea is to follow the onotologies and the taxonomies that are being created and developed within the iso standards and to implement them and to implement them. Make them a bit more detailed feed them back. So that's our idea of what format we should be translating into.

C

But just like the dlt relay scenario, uh we can also have a problem with api gateways. uh 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 and an api gateway at the bottom. That has a black standardized data. That's coming back um so again.

C

The data integration problem is going up. Another level just like in our dlt relay slides.

C

So this is why um we are taking a leading role with mit in developing into dlt api gateway communication, because we recognize this problem and we know that different api gateway operators and implementers where, if they want to work between them, we'll have to come to some agreements on what is the consistent standardized data to present back to the user, and we hope you know this will feed back into the iso standards and it will all uh be looped so iso working on the foundational data models and then this work here that you can look at later working at the working at the api gateways, api gateway, communication.

C

Any questions on that before I go on to other comparisons.

B

No not for now.

C

uh So I have another table of comparison here and this this, I think, is better summarized uh in the blog post, um it's more it's a more detailed uh version actually in the blog post. So if you're interested in all these other um different properties that we've compared these categories against, please look at the hyperledger blog and yeah. We go in detail into these.

C

So the final thing I wanted to cover is um how the categories can, in fact all overlap.

C

So if you think about a dlt relayer, this is how we're going to start. Our diagram. Dlt relay is connecting uh two different ledges together that are natively interoperable and um we are well as well as a dlt relay. We can. 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 dln.

C

And now that we have quite a few different networks and 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.

C

But because it's an api gateway as well as connectors to distribute ledger networks, it can also have a connectors to related technologies. So with 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.

C

So if you look on the left-hand side- and there is an atomic swap multiledger application and we can build it against the api gateway, even though in fact the atomic swap end up is quite in the cross authentication category of uh of west, it's actually uh utilized in the api gateway category and it's same same on the right side.

C

So, even though we have a more traditional oracle at the bottom of the screen uh on the top right, we have another oracle, uh multi-ledger application built against api gateway, and- and so that's the second category of wef. So we got an application from the set second interoperability category of wef built against the third category, and then we've got a few other examples there, but we can see that they all can connect together. They can all help each other.

C

So I have some conclusions. um So hopefully you got a nice understanding in this talk of the different categories. um In my opinion, all the categories have their useful features. um Yeah I like them all, but all the categories do require api gateways.

C

You notice that in the first two categories, I 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 to a multi, multi-chain api gateway, and then you have um the question of whether you should have this dlt api gateway as just having simple pass-through, simple data pass-through from the underlying dlns or you should add more complexity.

C

We should have more standardization, standardized uh data, standardized interaction methods uh so, and that leads on to my third point, where I'm suggesting that um 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 ledger technology layer uh such as viral relayer, because if we force everyone to follow the same standard as one rear layer, we're gonna well there'll, definitely be another rear layer, and so we need to think at a higher level than just distribute ledger technology about how to perform the standardization.

C

Let me go a bit further on that and, for instance, if we have um dlt practitioners around the world trying to understand the different technologies that are in place and they come up with iso standards in uh in two or three years that are that are perfect to describe everything, and that is not going to um change the data model of as distributed ledger. Technology is already out there. It's not going to change the data model, distributed ledger technology relays already out there, but api gateway data models that can adapt.

C

They can evolve and they can improve. They can incorporate new interoperability features. As you know, the domain expands that's my conclusion. I've got some time for questions.

B

Thank you so much luke. This is um great, really um comprehensive overview of the different aspects of interoperability um and different mechanisms for it. We do have a few questions, so um let me take one of the more recent ones, since it relates to what you were just talking about. um What changes are required in existing api gateway products to address the multi-dlt requirements.

C

um Well, they need to think um in a multi-dlt world, if you think of uh people like uh you know like in fiora, they're passing through the the the data model underneath of um the current uh if1 implementation, I'm not 100 sure how they're going to manage ev2 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 um you're just pushing the integration to the the app developer app developers.

C

So it's not very nice development experience, so they they need to um 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 of blockchain to understand what they need to do.

B

um Another question we got what from jacques bikundu is: do the dlt relayers act like mediator agents.

C

B

Relayers act like mediator agents.

C

um I guess they do they're a decentralized uh decentralized network of agents. Yes, that are forwarding messages from one chain to another, and back again, I don't. 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.

B

Okay, um 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- um and I will invite you to come off of mute.

B

So while people are thinking of their live questions, um I think maybe this was a follow-up on to the last. The second to last question we asked was: how would key management work in a multi-dlt system.

C

How would key management work? um Sorry, just one second: can you see my slides still because they've.

B

Yes, I can okay.

C

Yeah, that's good, um yes, you'd have to have well, it depends what you want to do. You can either have uh multiple um wallets for each different chain or you can. You can create. um You know a general wallet um with all your different keys in. So I think that's the simple answer to the question. Before they go more complex, I mean, um I think, let's leave it. There.

B

Okay um nicholas has a question nicholas, feel free to come off of mew.

D

uh Can you hear me yes,.

B

Yes, I can hear you.

D

Hi uh luke hi great talk as usual, um and uh I think uh I just had a question about um so. As you know, domains and connector frameworks proliferate. I just was wondering how 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 one another without necessarily having to like say, download an entire um library?

D

I guess of connector frameworks that, um in order to like you know in order to like decide like you know, resolve or route messages to and throw uh dlts and dlms. Thank you.

C

I might ask you to repeat this: the second part in a second, so I just uh yeah, you said I was just thinking of the first part, so, okay, how to deal with you know the configuration of the resources and distribute legend technologies or not yes, and yes. This is why we want to move quantum over personally.

C

We want to move from a single api gateway system to more of a network so that um other members or partners can present connectors, for particular the resources so that the load of connect, 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 uh in a in a in a way that will keep data integrity and keep the data. Quality.

C

Good is a very interesting problem for this subcategory that we work in uh and we're getting there a little by little.

C

That's the third, that's the first question so and then we have the trust spanning layer and could you just repeat the high level.

D

Yeah yeah- I just wanted to you, know thinking about like the domain name system that we have currently, it's like very um well established and tried and true, but I'm just wondering as well like.

D

Is there a way for for a tr a protocol based trust spanning layer between all dlts and dlns? That um is, is lightweight in essence like that, doesn't need for again an entire library of uh connector frameworks to be managed um that that possibly can even be bootstrapped independently of uh like a dns routing system. Is that like do you think that's like somewhere, where we could be going?

D

It's involved. Sorry, sorry,.

C

Okay, a trust splinting layer between the lns um without introducing another blockchain. That's what you're talking.

A

C

I mean okay, so yeah.

C

We have been thinking about this and we have this concept of a multi-ledger token that can exist on um multiple chains at the same time and be transacted by um it can be transaction transacted by a transaction that lands on any one of the connected chains. At the same time, yeah um we have. We are in the process of trying to get that patented.

C

If you have probably contact, could probably contact me for more details on that. uh I'm not sure where I'm at.

D

Absolutely absolutely I just actually I'm I'm reminded of just like potentially odap as a as an analogy. Do you think like odap could work? Is that.

C

Well, the odap currently has the trust assumption on um the the get the api gateways, uh like a permission, trust assumption. um Moving it to a trustless method uh is also difficult, and we've left that as future work at the moment.

C

That would be the ideal way to move that forward. Yeah.

B

A

Nicholas for your.

B

D

B

um Luke, there's been a couple of questions just generally wanting to understand um the difference between a few different of the dlts out there. um So, for example, um you know, what's the main differences between quant over ledger, hyper ledger, cactus um interledger.

B

Flair- and I think those are all the ones a sore chain um 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? um And then there was a specific question on um how do the different interoperability approaches compare in performance metrics, which I imagine um it depends on which one you're using as well.

C

Yes, okay, so different interoperability solutions, so interledger is uh just for assets um flair. I I thought that was another network which requires bridges into it. As far as I'm aware as one it's one chain, I'm not 100 sure what swan chain is hyperlogic, cactus yeah, it's an interesting one, uh I'm trying to keep up with it, but maybe I need to have a look at more videos, but um I pledge a cactus. So is there anyone from hyperledger cactus on the call.

C

um That silence probably means no type.

B

In the chat, if you, if you're familiar with it,.

C

Well, since I thought maybe a hypothetical person was, it would appear, but okay from my understanding of the current development of cactus is that uh they don't have the standardized data and- and they connect to, uh um I think, a set of permission nodes in the back end. um So I mean for from.

C

uh I might be wrong because I haven't looked at it the last few months, um but from overledger's 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?

C

uh You know 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. um So if anyone wants to clarify anything about cactus, I can't see the text, but um maybe that's something we can produce from our marketing department at some point about all the all the differences of all these different chains. I'm going to write that down.

B

Yeah there are a few: um there are a few projects, hyperledger focused on interoperability or integration. um Cactus is one of them, but we also have a hyperledger lab. That was it's very new, so I'm sure you haven't had a chance to look at it. um Luke um called type uh they're calling themselves weaver. um So um I invite everyone to take a look at our wiki.hyperledger.org to learn more about cactus and the page there.

B

We also have several um talks in our youtube related to cactus as well, um and then you can go to our hyperledger labs on github to learn more about weaver as well.

B

um 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.

A

Hello, can you hear me.

B

Yeah so just one minute, real, quick.

A

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 dlns with different consensus mechanisms? How would how would that change uh the transaction finality if it went through uh one api gateway? Thank you.

C

And so yeah you're gonna have to deal with that as part of your multi-ledger logic. So, of course, all the chains that have uh transaction finance, immediate transaction finale- those are all no problems, um but okay, the ones that can be wrought 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 and it can.

C

It can reverse if you have the rights uh depending on the application, uh but okay in atomic swap one. You have to be careful yeah, don't don't swap your bitcoin after one block uh make sure make sure you have good logic rules in there. I just remember I forgot to um look at the performance question uh previously, but the performance of the different categories.

C

um So, what's up so three categories, um the performance of different interoperability categories are all dependent on the dlt logic that the dlts that you're, using really I mean the api gateways oracles. They cannot go around the transactions per second of the dlts that you're connecting to. So um if you want, if you want fast fast finality, you need to you need to choose a fast change, regardless of which interoperability category you're using.

B

Thanks so much luke um really appreciate you answering so many questions and thank you. Everybody.

A

B

All your questions- this is wonderful. I already see here in the chat, nicholas and rafael, are talking about how we could um talk about how cactus fits into the wef interoperability schema. That's a conversation you all could take to our chat.hyperledger.org.

C

B

Has a channel there, you could um start a discussion there so that you can continue this conversation, um I'm just going to do a couple of announcements here at the end.

B

um Thank you for 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. um Like I mentioned at the beginning, the recordings and slides will be available on our website. We actually have another one of these um hyperledger in-depth sessions coming up in our asia um community uh tomorrow on bond blocks. So take a look at that.

B

If you're interested you can sign up on our website at hyperledger.org events, we also have um our global forum coming up in uh a few weeks actually um june 8-10. This is um where you could hear a lot more talks. Just like this. um We have some amazing keynotes plan for you. We have some, I believe, more than 100 talks and presentations across um programming in europe and north america and programming in asia. um It's really going to be a very exciting few days, so I invite you to please register and join us there.

B

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 um in our various working groups and sigs, etc, have a wonderful day. Everybody.

C

Thank you very much been interesting.