 Thanks again. This topic is on blockchain interoperability. My name is Vinayak Pandit. Blockchain and supply chain strategy at IBM Research based out of and this point of view really is a joint work with my colleagues from IBM Research. Venkat Raman Ramakrishna, Raman in short and Irmiya Abibi who was part of IBM Research till recently. Yeah. So here is the talk that I'm going to give. Right. So to blockchain interoperability. What are the drivers for blockchain interoperability? What are the unique challenges, you know, when it comes to blockchain interoperability? Because very widely studied topic and has been around with us at least for last two to three decades. And what are the of interoperability in blockchain? Right. So that will be the background. A brief overview. It's not an exhaustive overview of some of the emerging patterns, right, when it comes to blockchain interoperability. Then I will provide an overview of two of the projects which are focused on this topic within the Hyperledger umbrella. One is the Hyperledger cactus. And then second is a Hyperledger Labs project that we call as Weaver. Right. My goal will be to try and cover this as quickly as possible so that we can have some time for discussions. Okay. So Ivers for blockchain interoperability. Right. So if you can really look at this question from two points of view. One is looking at the stage in the technology evolution when it comes to blockchain. Right. In some sense, especially in the enterprise setting, is still in its infancy. Right. And we have many different abstractions of the concept and for many different implementations of these abstractions. Right. And these abstractions, right, are actually implemented on different type of technical stacks. Right. So there's really a heterogeneity of technical stacks. And then we have networks that are specialized on certain kind of purposes. We have a certain kind of networks or slash, you know, meant to build general purpose. For example, we have certain networks which are meant only for certain networks which are meant only for certain aspects of trade finance. Whereas we might have very general networks looking at all aspects of, let's say, trade. So that's one aspect, technology, the heterogeneity of technical stacks, different abstractions and implementations. And the second aspect is really the way the technology adopts in the enterprise setting. Right. So the adoption is really a very gradual adoption and the adoption through use cases. Right. So people are finding meaningful use cases that give immediate benefit. Many of them have very limited score in terms of their operations. And most cases are built, are built by companies that come and define network boundaries. These progress are fairly narrowly defined. And the use cases themselves, even if you look at it from the point of a single organization, they just cover a slice of the business. Right. For example, you know, point of view of a single organization. Right. You know, its trade logistics related aspect might be covered on a trade logistics network. You know, and its trade finance related aspects might be covered on another network like VDOT trade. Right. And therefore, many of these networks, they are complementary for a finance network and trade logistics networks, they are complementary in nature. But isolated as of today. Right. So this is the reason that, you know, we have a really complementary but isolated set of networks that are coming up, that are coming up on heterogeneity of technical stacks, which really call, I'll not spend much time on this chart, except that the timing seems to be quite right when it comes to blockchain interoperability. Right. So in the last two years on the left hand side, I have pointed out some of the market research reports that have come out. Right. And you can see familiar names like IDC, World Economic Forum, EU Commissioned Foresterents. Right. And then some of the major vendors when it comes to blockchain adoption, like Korda, IBM, Accenture, they all have come out with their whole view of interoperability, in which there are a lot of commonalities. Right. So which is actually a good sign that this is the right time to look at this particular topic. So what are the objects of interoperability? Right. So as I said, you know, we have networks that are coming up in isolation. And in some sense, the picture on the left hand side, you know, depicts that. Right. So you might have a, you know, a logistics network, which is really not talking to trade finance network, and so on and so forth. Right. And what we really want them to be able to do is to kind of seem and give an user, as if that user is seamlessly working across a complex workflow by connecting all these different networks. Right. So to remove the data silos. Right. So that's actually one important thing. And second thing is it will allow individual networks to focus on what is they are most competent. Right. Like the payment network and focus exclusively on payments. A logistics network can exclusively and it will create very new and novel type of network effects. Right. For example, certain kind of business interactions that today do not take place. Let's say between a logistics trade finance and insurance kind of categories might actually start in the future. Right. And that's why on the right hand side, you know, we have even depicted that as a, as an outcome of blockchain interoperability, we might even have new networks that come up. Overall, we expect that this will be blockchain market size and, you know, increase liquidity of assets within the networks and actually create a next level of efficiency. Right. So here I'll just take a pause and just go back to the chat room to see that, to make sure that you are all able to view the slides easily. I'll presentation mode, but that a bit of a complication for me. Plus the screen sharing issues I'm facing. Still, let's try it. So, you know, blockchain interoperability is a simple technical matter. Right. So as a technology, really focus on levels of interoperability. Right. You know, the technical layer, which really looks at wire protocols, what kind of, you know, delivery guarantees are there, et cetera. Syntactic layer, which focuses on the protocol structures and how the payloads are formatted and so on. And then the semantic layer, right, which is where the blockchain aspect really starts coming into the form of different, you know, type of all messages, whether they are data transfer, asset transfer, asset exchange, we will actually look at what they mean. And, you know, associated concepts like state transfer, cryptographic proofs, identity, et cetera. Right. But this alone, we know is not really sufficient to realize the full benefit of interoperability. What are really important are existence of, you know, domain standards in application areas where the needs to work. In the case of supply chain and logistics, you know, existence of standards like GS1, et cetera, which will allow, you know, the underlying exchange across different blockchain networks to be made sense of at the application layer are very important. And there are already existing standards there, which is actually a very important aspect, which will make that up. And we also want to acknowledge that even at the governance and legal regulations level, there are roles for other parties to play. And there are already parties playing role here, as we have noted here, for example, at the governance and enablement level, World Trade Organization, International Chamber of Commerce are playing very active role. And people are actually advocating and considering, you know, changes to local laws and regulations to actually make blockchain-based business flows valid. Right. And to call out here that when we say, when we talk about blockchain in the context of multiple networks, one can actually think of different integration patterns. And hence, we want to call out the pattern that we are most concerned with. Right. So one pattern is very simple. Right. So you are a big organization, big retailer. And, you know, and you are participating in a supply network, you are participating in a trade logistics network, you are participating in a trade finance network and so on. And you just want to get a single view of your participation across different networks. Right. And this is actually very easily possible by just actually having a single peer which participates across multiple networks. Right. The second one is that, you know, you might want a single network in which bring up the peer infrastructure in the way that they actually feel most comfortable with. Right. For example, you know, you might have peers that are on on different services and so on. And you should be able to orchestrate a single network and possible today. Right. And the third pattern, you know, the interaction between the two networks actually take place at the application layer through API. Okay. Part is exposing those APIs. This is also possible today. But the problem with this pattern is that the underlying decentralization tenants that are associated with the decentralized test actually get lost. Right. So the we are really interested is in this what I'm calling out as a pattern for in which the networks are interacting while enabling data and value exchange. Right. While preserving the DLT tenants. Right. So this is really the most important aspect that we, you know, we want to kind. And this is the pattern that we are really focused on. Right. So let me very briefly call out what makes blockchain interoperability really hard. Right. So here you can see there are two networks, you know, one on the left hand side, which is in orange and one on the right hand side, which is in brown. Right. And, and, and really, you know, the network a natural definition of network boundary can reason about the identities, transaction and state of everyone inside its network, which are presented in orange can do the same for entities, transactions and states on which are in the brown network. But when we create blockchain interoperability between these two networks, what we are really doing is we are creating a new boundary of trust, which encompasses all right, which is while network a continues to operate as an independent network in itself, it should be able to reason about the identities, transaction and state of the right. And that's really hard, because while we you want to give the full independence, we want to allow them to reason about each other. And, and while preserving decentralization, right, without introducing trusted third parties and really the big challenge. Right. And the really the spectrum of blockchain interoperability, right. Just wanted to, although I will not be spending much time on it, is that, you know, we should, if you have, for example, you might have a, you know, in the context of fabric, you might have a network in which there are two different channels, and they may want to actually interrupt it amongst each other. So that is one level of interoperability. Interoperability is that there are two different networks that are built on, let's say a fabric, one is a supply chain finance network, another is a logistics network, and you, they should be able to exchange in information between each other. Right. Another level. And then you might have a network, which is built on one protocol, like let's say fabric trade finance network, and you payment network, which is on, let's say Ethereum, should be able to interact with each other. That's the third level of interoperation. Right. And then, as I said, for the sake of completion, you might also have the application layers talking with each other. And you all have the systems to be able to interrupt with non-DLT system. Although for the purpose of this talk, we will be focusing exclusively on these three. Right. So just to say, so the unique challenges is really, you know, the fact that the ownership of a state in a single party system lies with just one party. And if that party says something about its state, you can trust it. Whereas in a multi-party system, like in a blockchain network, the state is really owned by the collective. And that is defined by the participants and the consensus protocol of that. And a party which is really trying to consume, right, that information we have shown for three different patterns here, necessarily have the full view of, you know, either the set of participants or each of the transactions that actually get recorded on the network from which it is actually trying to consume the information. So the roles that proves and verification play is very important. And then finally, you know, in the traditional context of interoperability, we typically talk about data interoperability, right. People are able to exchange messages, but here we are actually also talking in terms of assets, which is right. The assets that, you know, we are interested in is asset exchange, right. So essentially, the change of ownership of an asset in a source network and a corresponding change of ownership in another network, right. So for example, delivery versus payment in the context of trading. So this is one classic example. Asset transfer, right. So here, you know, the movement of an asset from one source ledger to consuming ledger, right. So the asset, the asset cannot be double spent, which means that on the source network, asset should locked and then be released to be used in the consumer ledger, right. Simple example here could be movement of money from a wholesale CBD, retail CBD scenario. The third pattern that we are talking about here, which is covered that much in the literature is what we call as data sharing, right. Which is the consuming ledger is able to query and obtain state ledger with a proof of validity, right. An example is a trade fine network, right. I want to make sure that there is a valid bill of leading in a trade logistics network before issuing letter of credit, right. So this is, right. I will try to cover a little faster now so that we have some time for discussion, right. Four different emerging patterns in the literature. One is a very simple one, which happens in most token exchange that are there today, centralized token exchanges, right. There is a trusted intermediary, which is exchange helping exchange assets. Then we have a trusted federation, right. In which there is a set of entities, which are federating the exchange of assets as well as information. And so you can actually think of this itself as a network, which is doing this and like, this is like a primary network and these are secondary network. And this is a pattern that is, you know, that is followed by some of the networks like Cosmos and Polkadot, etc. And then we have, you know, interoperability in which there are no intermediaries, right. That's independently and simple example here is, you know, asset exchange using a protocol like hash time lock contract. And then we have which through a project, which I will be covering in some detail is, you know, there is a consortium of network cross chain validators in which the consortium has presence of cross chain validators in each one of the networks. And then they talk amongst themselves to create federation, right. So this is the one pattern that I kind of talked about, not will not go into detail, but essentially the primary network provides resources as well as structural and sometimes in terms of the data and exchanges that the secondary networks consume from other networks. And the other pattern, which we said is for the networks to operate independently and then basically interact with each other using the format of claims and proofs, right. So this network is making a particular claim and providing a proof of that state and this network is able to consume. These proofs can be as simple as digitally signed messages in permission networks. If you know any is like sufficient information about the source network, really be in the form of Merkle proofs and zero knowledge proofs as well. Right. So again, a very quick summary, right. And the permission less space we have interoperability like ILPs, a very well known pattern polka.com as like as I said, networks as intermediaries, right. And in the permission space we have integration frameworks like Hyperledger Charters, independent networks without intermediaries, Hyperledger, right. So we will talk a little bit about these projects, right. Charters is actually a Hyperledger incubation project, right. And this follows this pattern in which there is a consortium of what we call as cross chain validators. And the consortium has some of its verifiers there quite participate in each one of these networks, right. So they're not part of the consensus, you know, building the consensus in these networks, but they participate and observe all the state changes, right. And when information needs to be ferried across, cross chain validators have a way to talk amongst each other. They run a consensus amongst themselves and based on that consensus allow for exchange of value and information, right. So more details can be found in the links I have given. So it's a plug-in architecture, meaning, you know, they are providing maximum flexibility in terms of different ledgers to which, you know, interoperability can be enabled by building specific plugins for each type of these ledgers, and they do not make any other ledgers themselves. And the idea is security by default, meaning that you do not have to worry about the security of the framework itself. There's a very interesting concept they have called toll free, which is that users should be not charged for, you know, participate users to create interoperations, right. So in the kind of quickly cover the Weaver project, which is a project that we are currently working on from IBM Research, right. This is a, you know, we have built based on the following and so forth, right. So we, inclusiveness, we want to avoid approaches that are specific to any particular DLT implementation. We want the networks to retain their independence and reduce the trust to what is really essential, right. For example, just the network, right. And privacy by design, which means that any interaction between parties across networks is kept private and confidential and revealed only to those parties that are, right. And we avoid the presence of trusted third parties, right. And practical considerations very similar to cactus, right. We do not assume any, that we do not permit any changes to underlying DLT platforms themselves, right. And you do not have to worry about already existing network operations and be able to work as is, right. So very quickly, you know, this is that, you know, in the form of we actually allow communication between interacting ledgers. And all of this is a particular pattern that we call as relay, which is really a component, which allows networks to exchange messages of different types, identify different type of messages, whether it is data exchange and asset exchange and so on. And the relay is built in such a way that it plays us very minimal, right. And the relay really cannot play any adversarial role in this setting other than perhaps playing a denial of service attack, which can again be mitigated with the replication of relay components, right. So here is really broad vision, you know, we have different type of protocols, including ERP systems, which will be using their own relays, there will be, and then they can actually exchange do asset transfers and so on. That for each of these networks, for the DLT protocols, we have an adapter, which is the best SDK for that particular protocol. And that adapter is able to actually identify different message types and convert them into the language that the relying protocol needs to consume. And it also is able to talk with the remote other relay components. I will not spend time on this and maybe, you know, end it here and see if there are any questions. Any questions? Okay, so there's just one question. I'll probably take just one minute. If you had to implement improperly this year, which protocol would you use? You know, I think unfortunately, I think it depends on the use case that you have and what kind of trust you want to work with. As I said, the different patterns assume different trust models. So I do not want to really pick any sides here. Any other questions? We will be stable enough. Actually, we were is quite stable now, but at least in the quarter from now, we will be expecting it for people to use what we call the data exchange patterns. And by the end of the year, you know, asset exchange patterns. There is a whether it can be a collaboration between cactus and weaver. We definitely do not rule it out. As I said, there are a lot of commonalities considerations that there could be slight changes in the technical approaches. And we believe while there might be some effort involved in it, there can be an harmonization, but we have not visited that question yet. Okay. I guess we have to end this now. Unfortunately, we are two minutes over. Please feel free to reach out to me and my collaborators if you have any other questions. Thanks a lot.