 So how's everyone doing today? Welcome to this demonstration of Casper Hyperledger Interoperability. So interoperability and open source of the teams today, and these are the two things that we're going to talk about in today's demonstration. I'm Ashok Ranadeva, Director of Professional Services at Casper Labs. With me, I have Shyam Nagarajan, Executive Partner, Web 3, and Interoperability Sustainability for IBM. All right. Thank you, Ashok. It's interesting. The journey for Hyperledger has been around seven years, and in those seven years, we have been very quite successful in standing up private permission networks across different enterprises. We've seen and done that very successfully. Instance, the business case that we're going to talk about is actually interoperability of a private permission network with the public permission less network, and this is the real live engagements that we are doing with some large institutions, government organizations that's in progress as well. So the scenario that we are sharing here is about a bond network that has the assets. These are financial assets that are issued by the Treasury of the country and are maintained in the private permission ledger. A number of banking organizations are part of this ledger, and they are entitled to buy and sell within this network. Parallely, we have a cash network that's running on a public blockchain that is permission less, and the cash network is primarily used for settlement across all different parties. So the cash side of it, the currency side of it, and the token side of it is actually maintained in the public chain. The interoperability scenario is where a party, Alice that owns a bond, is willing to sell the bond to anyone else in the network, and Bob is a buyer, and buyer wants to get this bond from Alice. Now the asset ledger primarily allows transfer of the bonds, but the settlement has to occur on the cash ledger. So in the cash ledger, Alice and Bob have equivalent accounts where they have tokens and can settle between the both parties. The equation that we have to solve here is, how do you do a transaction making sure the both networks are aware of the state of the transaction in each network? So in this situation, Ashok is going to walk us through how we are solving this. This is a scenario where we have used project weaver, and atomic swap, especially hash time lock scenario in order to solve this problem. Ashok, why don't you walk through the next chart? Yeah. So let's go through the sequence of events here. Alice and Bob both have accounts on both ledgers. So the asset ledger which is running on fabric and the cash ledger which is running on Casper which is a public permission less network. So Alice owns a bond and Bob shows interest in buying that. So Alice locks the asset with a hash. Bob creates agreement on the cash side to, Bob shows interest to buy this asset and then transfers the tokens on the cash network to Alice's account. Again, that is also time lock. When Alice accepts these cash transfer, the bond is released for Bob on the asset side. So this is interlocked. If the transaction fails at any stage, the original state is established. So if, for example, within the time period given if Bob doesn't transfer the cash or Alice doesn't accept the tokens or the cash, this state will be restored but Alice will go back to owning the asset and Bob will retain the cash that he was. And I'm going to demonstrate this on a live with our test network. So you will see the deploy is actually happening. Let me switch over. So this is the bond network and this is the cash network. So the cash network as I mentioned is running on Casper and the bond network is running on Hyperledger Fabric. So let's log in as Alice. So Alice has certain bonds. There is one bond that I've specifically kept the number as 111 value. So it's easy to spot. This is the bond she owns and Bob is interested in buying this bond. So when I log in as Bob here, I see the number of bonds and I see this bond 111 face value is owned by Alice and I want to initiate purchase. So I initiate purchase and send a request. When the request is sent, Alice will see this request when she locks in. So you see the notification? This tells Alice that Bob is interested in buying the bond. She looks at the scenario and she's happy to sell the bond to Bob and she creates a secret phrase which will be locking the asset. We are seeing it here because this is a demo in real scenario. Obviously, we won't see any of these. So she creates and she approves the transfer. Now this is going to get locked with a certain time as a parameter. So it will be locked for a certain time. Now this is the locked hash. Let's just copy this and I'll just paste it here. Now we go to the cash ledger which is running on Casper. We log in as Bob. We go to transfer tokens. We see that the same hash is here. So Bob knows that Alice has now accepted the offer and he is now transferring the tokens or the cash. So he approves from his side. This is the deploy hash. Let's record this. Since this is a public network, we can observe the behavior of the transaction on the Casper Block Explorer. So what's happening behind the scene here is if I go to the Casper network. So the Casper network has a block time of 32 seconds. So it's going to take time for the transaction to be recorded but we can observe this here. So when you see the deploy going through the network, that means that particular token transfer has occurred. Let's give it a couple of seconds. And what has happened so far is the transaction. The asset was locked in the Hyperledger blockchain network. Hash time lock was initiated. So there's a period of time that the asset is locked for. Then it was handshaked with the Casper network. And in the Casper network, that approval for transfer of tokens came through and you saw Bob actually approve the transfer of tokens to Alice who's in the Casper network. And that approval is going through this network. And this is where you're seeing that confirmation. You see that the deploy hash that we had recorded is the same deploy hash and token transfer has happened. If you go through the details of the raw data, you will see the number of tokens that are transferred in all the details. So let's go back to the Casper network. One network, login as Alice, login as Bob here, and to the cash ledger. So you actually see the number of tokens also would be reduced. So when you log in as Alice, you have to accept the tokens that Bob has transferred. You're now giving the same secret key that you had typed in on the asset site. For locking, for locking. Locking, you claim the tokens. Again, this claim goes in as a deploy through to the network. Because now the tokens are getting transferred from the locked contract to Alice's account. Let's note down this deploy hash and go back to our block explorer. Again, we have to wait for like half a minute here. And what has happened is it's still within that time lock period, right? In this situation, I think the time lock period is about five minutes. But you could set it up to whatever is possible just because the workflow has multiple networks and you have to log back, all those kind of things. So as Alice claims the token, then the confirmation of the claim is now going to be corresponded back to the Hyperledger network. And in the Hyperledger network, now Bob is going to see the transfer as well. So here you see the same deploy hash here. So now, sorry. So now what has happened is Alice has now got possession of the tokens, right? But it is still locked into the contract if the bond doesn't get transferred, it will be reverted, right? So let's go back to Bob here. Since he has completed his commitment towards the transaction, he should be able to see the bond. Now, one thing that we should note here is if you go to the data here, the secret code is actually revealed into the chain. However, nobody else who's observing the chain will be able to claim the bonds, because the bonds are now locked for Bob and nobody else can get them transferred. So here is the secret, let me increase the font size a little bit. You see the secret code here, that's here, and it's observable on chain, but nobody else can misuse it, so to say. So Bob goes to his saying, and he now knows the secret as it is tied. He claims the bonds, okay, bond claims successfully. And now if you go here, you'll see that the bond is transferred in Bob's account. So to conclude, what we have demonstrated here is a transaction of asset on a permissioned network is enabled through a synced and locked transaction of cash or tokens on a permissionless network. So this opens up a huge number of applications, as Shyam was saying, because a lot of financial institutes have permissioned network and their assets are locked on permissioned network. And that's something that they need from security perspective. But as the public chains have demonstrated more traction and more reliability and CBDCs are coming into play, it's kind of imperative that we demonstrate how they can interrupt it together. This code is going to be open sourced. We are going to keep it open for people to use it and play around with it. And internally it uses Project Viva, which now is going to get merged into Cactus. And the new name is Cacti. So we are very excited that this is a very scalable industrialized piece of code that can be put into production or used in your projects as you work with your clients. So, wait, thank you very much for the opportunity. So that's all, thanks a lot. Any questions, happy to take any questions? Yes, we will definitely put it up. There's always a negative side of using blockchain. Sometimes organizations over engineering, you may not need a blockchain. So really qualifying what you're applying the technology for is very important. And the other side is also a choice of permission versus public as well. When do you need one versus the other? So it's basically application, like is there a negative side of using a hammer? Maybe yes, if you use it on a nail, that's a right application. Use it on a thumb. On a head it may not be. So it's a technology where you use it. Find the right application and the balance between the options that technology gives you. As Shyam mentioned, permission, art permission, so those things that you need to keep in mind, how decentralized it is, what kind of security it is giving you, what is your right application, right? If you use, if you keep that in mind, it's totally the right thing to do. So we were handles the relay part behind the scene. So the secret actually is revealed only when Alice is accepting the tokens. And that's when it's available on the public. So we have to understand the difference between public and private network, right? So in a permission network, there is no access for others to kind of go through it, right? But for a public network, your data is getting posted and it's available open. Anybody can query the data and see what the secret code is. But it's revealed at a point where it's no longer possible to use that secret code and claim the bond for anybody else other than Bob. So there are ways to do it, either Bob goes through that or you find another means to pass on that secret code to Bob. It could be done through several different ways, right? And then there are established technologies to pass messages across two parties in a very secure manner. So we could use that or Bob just goes through the explorer, I mean that's. But remember the time of the secret exchange is only after Alice has been paid or claims the tokens. Yeah, that's important, yeah. The SDK allows you to register for events. So if you're Bob, you're listening for events of a lock, let's say from Alice. And then in your application, you add suitable code in your image listener to submit a lock in response or submit a claim. So there's a four step protocol that Ashok showed you earlier, right? So you can, yeah, yeah, which is perfectly fine. Because the locks are made in favor of some party. If you supply a secret, if a third party, let's say David supplies a secret. It's not like David does that, Bob. David will not be able to, because it's transferred only to that account. And by the way, that's Ram who leads viewer project for IBM Research. Yeah, he's the guy who wrote the code. So, what is the question? Is there anyone on earth who can turn off the blockchain? So that's the best thing. If you go to any centralized parties, like one of these big, big organizations, they have the keys to turn on and turn off. In case of blockchain, let's take the example of Casper. Casper has 100 validators on the chain. Now, if 10 of them shut down, the chain will continue, right? So there is a minimum threshold after which the chain is not sustainable. But that's a large number. Typically, what we call it as a 51% account, right? But it's a very large number. So in case of blockchain, that's one of the advantages that you have, that there is no one who can turn off the blockchain. Well, just to add to that, this is why decentralized is a bottom. There is also the distributed side of it that is also, again, gives you a level of comfort, not as much as decentralized. Distributed is better than centralized, and then there is a centralized. So the reality is that when we started out as puritans for blockchain, we said everything has to be decentralized. And then realized that is not the only way how you could use blockchain, there are other forms of doing it, and ranges because of what you're applying it to, right? And in those situations, I've seen Amazon as offering out there, which is a QLDB, which is a centralized blockchain ledger, right? Which only makes sense if all you want is irrefutable proof that's in a ledger, and that you want access to all other people. You don't care about the distributed or the decentralized nature of it. At the same time, you have these public networks that are offering a different level of comfort where there is no reason how the network will be disturbed because of any outage or a government taking over a computer system and the likes because of decentralization, right? It all depends on what you're playing it for. Yeah, your application matters a lot, but Capsper, for example, can give you that option. So Capsper can run as a permission network, the same node with a config file set up can be run as a permission network, or we already have a public network that is running. And you can kind of find a space in between what we call as a hybrid network, right? We can find exactly what you want to go on public network, what you want to retain on private network. Companies may want to have private network because they have certain regulatory constraints on data visibility of their customers, or they may want to keep that data to themselves. They may want to reveal a certain portion of that data. So again, it comes to what business problem am I going to solve, right? That's a good question. Yeah, we'll have to manage. So that's a problem which is separate and which kind of this is a contained solution that we are offering. Identity management in itself is something important. And how do you make sure that Alice here and Alice there is same is a problem. But that's not addressed by this solution. But I think there are enough available solutions to ensure that. They can, but you also don't want to over engineer it, right? There are already established IAMs that can help you make those kind of associations. That said, if you had a decentralized identity already established, there's no reason why these networks can work with it. But good question. All right, thank you very much. Thank you so much.