 So thank you to everybody who's dialing in for this hyperledger meetup about Byzantine swaps, a rigorously secure way for cross-chain asset exchange. The discussion today will be led by Francis Mendoza, who is currently a software engineer at Ripple and previously was one of the people involved in the hyperledger's mentorship program last year. If you're interested in that, I will drop a link. We run at the Hyperledger Foundation a yearly mentorship program. So if anybody's interested in getting involved in that, you can drop, you can, I just dropped a link in the Zoom chat. You can go to that page on the wiki and find out more. This is an opportunity both for people in the community who want to be mentors. If you're running a project or a lab and you want to work with somebody else and be a mentor for somebody, we are currently accepting applications right now for mentorship proposals. So you can go to that wiki page, submit a proposal and then if that proposal is accepted, we'll help you connect with and work with a mentee. And if you want to be a mentee and work with somebody who's a mentor who will help you learn about these different technologies and get you up and running and successful on a project, we will be accepting applications for that soon. Again, the details are on that wiki page, but if you're interested in taking part in our mentorship projects this year, again, either as a mentor or as a mentee, we welcome that. Go to that wiki page that I just dropped in the Zoom link to find that more. And with that, I'm going to hand it over to Francis who's going to talk about work he did as part of a mentorship project last year. So Francis, take it away. Awesome. Thank you so much for that introduction, David. I'm going to start from the beginning now and set the clock. Not sure how to minimize this window. Let's see. Excellent. So good morning, everyone. I am Francis Mendoza and I will be presenting on Byzantine Swaps, my mentorship project under the Hyperledger Foundation Mentee Ship project. It's a rigorously secure way for cross-chain asset exchange. So the objectives of this call, as free of the audience, is for me to help you understand a sort of general state of blockchain interoperability research, inclusive of its utility and its challenges. Then we're going to explain the functionality of Byzantine Swaps compared to the prior art interoperability mechanisms. And here I have a quick breakdown of how this is going to go. So we're going to talk about why blockchain interoperability matters. We're going to talk about the prior art interoperability efforts and the challenges that resulted from that. Then we will talk about bridges and atomic cross-chain swaps and how they work in detail. We will then talk about the Hyperledger Weaver project, which is what Byzantine Swaps is fundamentally based on the design of Byzantine Swaps, version 2.0, and then it will open up to a quick, like, relevant Q&A. So why should we care about interoperability? So the premise is that interoperability enables users to transfer value and data between different blockchains, creating an interconnected network of blockchain systems. So the ecosystem right now is very much like a set of kingdoms, or game of thrones, if you will, in which there's individual layer ones, there's individual blockchains, which have their own sort of rules and features that sort of constrained their functional design. But this interoperability research is crucial because currently the blockchain ecosystem is highly fragmented. Everybody is sort of trying to run their own show here. If we look at history, computing history in particular, this is very reminiscent of the time that the personal computer revolution was really first getting started. You had a bunch of makers at IBM. You had also Apple in which they were racing to basically make their own personal computer, but the internet came much later. So once the internet, well, which originally started from ARPANET, first came into fruition, then the individual utility of those devices became much, much more useful. And now you no longer needed to have all the data, all the applications on just your one machine, because now for the first time, you could outsource from others. You can collect data from others. And although this is not a hardware product, being able to connect the blockchain system so we can utilize the information and the assets that are stored in separate chains is very much like what HTTP did for the fledgling internet. Because prior to that, we had these main frames are mainly isolated and they basically had very specific tasks. And then with the advent of HTTP, we have something like this. So this is the next computer, which was a company that Steve Jobs started. And once, like, and this was actually one of the first computers that was actually utilizing HTTP at the time. It had its own web server and the implications for that were immediately seen. But HTTP would go on to change computing history forever because now for the first time, we had a clean transition from computing, which was primarily siloed in corporations in academia to the common man in which anybody can use their landline and connect to the internet and access information and eventually applications that were stored on other computers. So what engineering benefits does this concretely give us? So we have increased transaction speed, enhanced security and better scalability. But the end result is that blockchain interoperability enables the transfer of value at the speed of information at machine speed and machine scale in a decentralized zero trust manner beyond borders. And if we remember, blockchain is really the internet of value. And in the best case, there are no constraints, there are no borders, and purely you can transfer value directly between peer to peer. And let's talk about Metcalf's law because this is the fundamental phenomenon in which all sort of networking based technology and especially like this explains why the internet is so significant and so valuable. So Metcalf's law is a telecommunications phenomenon in which the value of a network is directly proportional to the square of the number of users in the nodes or in the network. So in other words, the more users or nodes a network has, the more valuable it becomes. And it becomes more valuable at a nonlinear rate. So you can think of it like if you had a if you had a fax machine, if there are only two fax machines in the entire world, you basically have a very expensive paperweight. You have a fax machine that can send a fax to a billion people. That becomes an invaluable asset. And you know, this phenomenon is basically explains why things like social media networks and you know, like things like Web 3 become valuable. They start off small and as they continue to aggregate more and more nodes in the network, more and more users, the value increases over time because the amount of information that can be captured, the sort of bounds and sort of hops in which you can transmit that information, you basically have more options in order to do so. So we already talked about HTTP and I look at blockchain interoperability as the way in which, well, everybody's trying to run their own show here. There is all these different networks and there are other like tertiary things that are technically not within the pure interoperability space like oracles, but these are all fundamental engineering advances and research advances that will get us closer to basically something like HTTP for the blockchain world. And what sort of implications does that look like when not only we're able to, you know, pull together the various different layer ones, but also, you know, make the information from those disparate layer ones useful. I mean, I'm really quite excited about what that means, because if we were able to merge the worlds of Web 2 and Web 3, you based on the, you know, many advances that we have in this, you know, blockchain interoperability field, we can really unlock the next stage of the Internet in terms of value. We can really see the full potential of Web 3.0. So now we're going to take a broad overview in terms of interoperability efforts in the past. So there's two spaces or two camps, functionally speaking. So there's a permissionless space in which you have interoperability through protocols, right? You can also have networks as the intermediaries themselves or you can have technology specific implementations. But there's also a permission space in which you could have integration frameworks and protocols, like, for example, Hyperledger Cactus, Weaver and Overledger, which is technically is what Byzantine Swaps falls within the realm of. It's in a permission space and it's a framework, technically. You can have a network as an intermediary or you could have a technology specific implementation, which is like some sort of like standard. So in terms of the layers of interoperability, interoperability is not just a technical mechanism, but it encapsulates many layers of the technology stack. So you, I mean, we can build Byzantine Swaps, but you also have to be very cognizant about the tactical layer, the syntactic layer, the semantic layer and also the application layer as to what sort of applications can interface with this. If you can standardize the way which you are able to send data. I mean, the interoperability challenge becomes much, much easier as well as making sure it complies with all legal legalities and regulations. Now, the spectrum of blockchain interoperability. There are many different types of like operational dimensions. For example, you have networks A through E and then they're transmitting data. For example, in the application layer, there's interoperation across different DLT networks, but there's fundamental aspects of concern for each of these. So there is a business consensus model. There's also the governance model sort of constrains like what you can basically get away with if you're trying to basically pool different layer once together. You also have to take into account the scope. Is it a global state in which you're observing or is it a sharded state? In terms of the state model, is it UTXO based like Bitcoin or is it an account model like Ethereum? And you also have to be aware of various forks that stem from major platforms like Ethereum, what the trust model of that individual layer one is as well as the execution model. And because of the fundamental design constraints of what that layer one is, is it do we have instant finality or probabilistic finality? What does the network consensus model look like? So basically, we can make so like although we can make strides as to string a different disparate layer once together, we are still going to be hard bound by the technical limitations regarding exactly what the consensus model looked like for each individual layer one. So if you have a UTXO versus a account model based layer one, I mean, there's sort of a limited leeway you can get versus if they're both running off of UTXO. So there are three functional prerequisites for any interoperability mechanism. You should be able to conduct data sharing, asset exchange and asset transfer. So you should be able to share any sort of data between disparate layer one networks. You should be able to exchange the asset from one network to the other. And you should be able to transfer it freely in return. So in terms of the building blocks, so we have a claim in which any sort of cross network process interdependency can be realized as a combination of these three. And basically it looks like something like this in which if you're talking about asset transfer and asset exchange, this is a bi-directional right process. Whereas if you're just sharing data, this is a unidirectional read-write. So in terms of architectures for general interoperability, so like this is a sort of abstraction as to what this would look like. So you have one or more structural assurances to secondary network. So you have a primary network, which is a relay or settlement network. And this is you can imagine this is sort of like the Silk Road in which it connects these disparate layer one secondary networks. And this is sort of like the data sharing framework that you will need so that these two could functionally talk to each other. But in the primary network, you'll basically need to do these functional things and need to consolidate resources. You need to make sure the value of whatever asset you're pegging into secondary network gets applied cleanly. And most importantly, you need to be able to relay the messages for that value and data exchange to the other secondary network. So an example is Polkadot, Cosmos, and Bitcoin sidechains as well. And the unique challenges of DLT interoperability. So we have single party versus multi-party trust. Again, this is contingent upon what the trust assumptions for each individual layer one are, as well as depending on which one you have, you will have to sort of work with those constraints as to the interoperation should not compromise the invariance of the networks and protections against double spends on assets. So you have to make sure that if you're attempting to basically connect one layer one to another, you need to make sure like, you know, what does like how does a trust model change in terms of and what sort of transactions are you able to get away with? So now we're going to basically talk about the different types of interoperability mechanisms that currently exist. So the first kind is everyone's most familiar with our blockchain bridges. So bridges are a mechanism that basically lock up assets on one blockchain to be transferred basically in equivalent on the counterparty blockchain. So the key stipulation for a blockchain bridge is that there is always going to be some sort of intermediate intermediary here, which sort of facilitates all the data transfer and the asset handling. So and there are many different offshoots of blockchain bridges. So the most important functional property is a third party intermediary of some kind. And because of this sort of like central inherent centralization in which like there is sort of like a base component, there's a core component that's responsible for the exchange of data, the transfer of that asset. You basically have greater flexibility. It's much easier to integrate disparate layer ones, because all they have to do is basically plug into this like bridge ecosystem that already existed. And it's much easier to get throughput because this is a sort of like you can imagine it as like blockchain bridges are like super highways in which you can basically exchange assets between disparate layer ones. It's just a plug and play platform, practically speaking. And all you need functionally under the hood is just a simple locking mechanism that enables easier support for more platforms. And there are several derivatives. There are centralized bridges. There are decentralized bridges and there are bridges that fundamentally use smart contracts, which are technically an offshoot of the decentralized bridge. Now, atomic cross chain swaps are a different category of interoperability mechanism in which they prioritize decentralization and security over speed slash throughput. So the general description is that you are able to enable the swap of tokens or any sort of digital asset between any two blockchain ecosystems directly without an intermediary and this kind. So there is no sort of central infrastructure. It is decentralized in the case in which anybody sort of connecting or trying to utilize an atomic cross chain swap, they have their own sort of component that mirrors that of the counterparty, whereas, you know, in a bridge, you don't really need to make any fundamental make a lot of additions to the layer one in order to basically plug and play. That is not necessarily the case with an atomic cross chain swap in which in this case, you would need your own relay. That's and that basically needs to be standardized and needs to be able to talk to your counterparty's relay. So you all have your own. So there's a system of there's a principle of redundancy in this case in which every party or counterparty that's participating in this swap has their own component and basically that's enforcing this like decentralized system design standard. So functional properties of an atomic cross chain swap, it's fully trustless. So you do not require any third party intermediary to perform the exchange because you're basically hosting those components yourself. The second part, which is the most interesting, in my opinion, is the property of deterministic rollback. So because of the stipulation, so this is of the stipulations outlined within how an atomic cross chain swap works, which is fundamentally built of a hash time lock contract, which I'll explain in the next slide, if some parties behave irrationally. So if they intentionally deviate from the protocol, no rational party, which is a party that follows a protocol and is presumably part of the honest supermajority, they will never, ever, ever end up worse off. So what this means concretely is that if I wanted to send like a hundred Bitcoin to you and trade it for a theorem for a cross chain swap and I choose to violate the protocol, or you choose to violate the protocol either intentionally in which I tried to basically launch like a sore loser attack or unintentionally in which we overran the sort of synchronous time bound limit. Basically, the worst thing that could happen is that the swap will fail. And then all the original assets that were held in escrow just get returned to their original owners. So it's not like I'm going to lose all 100 of my Bitcoin. It's just going to go back to my wallet. Whereas in the bridge, one of the like fundamental weaknesses of the bridge is because it's a central it there. It's fundamentally an intermediary that handles the data exchange. It handles the transfer of these assets. A man in the middle attacks are very possible. And that's how basically things like, you know, all these bridge hacks are able to come in place, not necessarily like, for example, Ronan. That's not necessarily a fault with the bridge itself. I mean, it's sort of like a system administration issue. But the fundamental weakness of a bridge is that you can launch a man in the middle attack and steal the asset away from the party in the counterparty, whereas in an atomic cross-chain swap, that is deterministically guaranteed impossible. So and this would only work if you have basically an out of an honest party. So if all parties are rational, the transaction successfully takes place. So however, the trade off for this because in any, you know, system design, I mean, the point is to sort of like you need to have weaknesses, but you know, to amortize the weaknesses into a relevance. So the weakness in this case or like the trade off is that there's careful management of keys and the coordination and the ordering of the transactions as you're performing this cross-chain swap are absolutely critical, which is why strict adherence to, you know, this protocol in which you follow the steps, you disperse the hash lock, the preimage on the proper order to the correct party, you all have to execute that seamlessly and perfectly within the allotted time limit. So for this example, like this is just an abstract a diagram of what an atomic cross-chain swap looks like. And I'll just like walk you through it. So we have Alice, Bob and Carol. So Alice basically wants to basically buy a car from Carol, but she doesn't have the exact currency that Carol is looking for. So Bob is sort of like an intermediary in the case in which like, I'm going to trade my altcoin for Bitcoin and I'm going to use Bob's Bitcoin to pay for the car that basically I'm going to get. So the first step in the atomic cross-chain swap is that Alice generates a preimage. So that is a secret S. And then she generates a hash of that preimage, which is basically H. So in because of that, the atomic cross-chain swap basically is built upon the principle of hash locks and time locks in which hash locks and time locks are conditions in which we would basically be able to unlock the assets in question. A hash lock is you need to have sort of like the past the cryptographic passphrase required in order to do so, which is basically in the form of the preimage that gets dispersed later in this process. And also the time lock in which you need you can only sort of unlock the asset in question in a particular time step within the atomic cross-chain swap. So the first step is that Alice generates a preimage or just a secret. She has a hash of that secret. And then basically she sends that hash to Bob. Basically, we're, you know, we're expecting to complete this transaction within six steps, right? Then basically Bob says does the same thing, which he has his own preimage, his own secret. He sends an hash lock to Carol. And then basically Carol does basically a similar step. She sends her hash lock to Alice. So now all the parties sort of have their own hash lock as to the sort of disbursement of the assets in question. So Alice is basically going to give altcoins. Bob is going to give bitcoins and Carol is going to give the car and it's going in this basically clockwise direction. Now for the fourth step, so after all the assets have been locked in escrow and in particular to escrow is a hash time lock contract, which we'll get explained in the next slide. So then Alice can now fully reveal the secret S. She can reveal the plain text preimage to Bob. And what this enables Bob to do is basically like to basically eventually for Carol to learn the secret S. So it basically works in reverse in which Alice reveals a secret first and then you work backwards and then the assets that are held within each individual node in escrow get dispersed. So in this case, Alice reveals the secret, which eventually makes all the way to Carol. Carol now learns a secret. She can use that secret to basically it's the key in which she could use to unlock the hash lock, per se. So now she can transfer the car to Alice concurrently. You would have Bob sort of like learn S and then he would transfer the bitcoin to Carol. And then finally, Alice is able to transfer that altcoin balance to Bob. So assuming that everything executed within the proper time step and assuming that all the parties didn't arbitrarily deviate from the protocol, everybody walks away happy. Alice gets a car, Bob gets altcoins and Carol gets the equivalent amount in Bitcoin, which is the only currency she was willing to accept at the time. Now, atomic cross chain swaps are built off of a hash time lock contract. So the key stipulation for an atomic cross chain swap is that it can only work if there's sort of smart contract functionality on the layer one. And moreover, that smart contract has to be a hash time lock contract. So it's a particular flavor of smart contract that basically uses the two components we talked about earlier, a hash lock and a time lock. So yeah, the hash lock you can you basically are able to unlock the smart contract with like, you know, basically a passphrase and a time lock in which, you know, at this particular step, you are able to basically fully disperse that asset. And then there's a preimage, which is the secret that we basically talked about earlier. And you can see, like, you know, you can involve many sort of intermediaries within a cross chain swap, as many intermediate intermediaries as you need. So you can think of it as, like, you know, the trading game in which, like think of bartering. So if you don't have like a pure occurrence, a universal pure currency to like change for everything, like I can I can sort of like barter, like, for example, like a cookie for, you know, a bag of chips and vice versa. So this is sort of like the next best equivalent in which if there is no like unifying currency, which, you know, in this case, it's impossible in this case, because you have disparate layer ones, each layer one will have their own currency. You're basically resorting to bartering in this case. And you're in there's value calculations to make sure you're roughly you're basically getting whatever the equivalent value of is from that barter. So this is an example of like a five step, like hash time lock contract between like five different parties, but the fundamental principle is the same in which each party is going to generate a preimage and they're going to send a hash lock and there's going to be a time lock that's sort of like married to that hash lock in which you're able to sort of unlock the particular asset at a particular point in time. So basically these were the steps that I described earlier in which, you know, each like fundamentally these are just repeat steps. Like these steps will basically get repeated contingent upon how many people are involved in the transaction, but every party will generate a preimage. They will hash said preimage, send a hash to, you know, the next counterparty in line and then when the time comes, send the preimage, the raw preimage directly to that counterparty so they could basically disperse the asset in question. So and again, provided no party deviate from the protocol. So you need an N out of N, like on a supermajority. If anybody violates the protocol, basically the whole transaction will fail and then you'll have a deterministic rollback of so all the assets will just basically disperse back to their original owners in this case. Then we're going to talk about Weaver because Byzantine swaps is fundamentally built off of the Hyperledger Weaver project. So for context, Hyperledger Weaver is an interoperability framework. It's open source code in which they're able to connect basically disparate layer one blockchain. So currently it supports the Hyperledger fabric, Hyperledger Basu and also our three quarter their key components here. So there are relays, which are basically gateways in which you could like, you know, send messages to other networks and relays and are very important because it's sort of like the arbitrary communication layer in which these various nodes in these layer of ones will basically talk to each other. And then there are drivers as well that sort of like go in 10 with relays so they orchestrate the collection of individual ledger states, there's interoperation modules, there's the application helpers and then there's the identity service or, you know, which helps, you know, ensure that you are who you say you are and you have an equivalent identity functionally speaking on the equivalent counterparty blockchain network, right? So in terms of their capabilities, they have the relays are completely DLT agnostic and there are drivers specific to each blockchain and then there are specific contracts specific to each blockchain for proof and lock management and they're associated SDK. So this is what I'm talking about with the stipulation earlier in which it's not like a bridge in which you can immediately plug and play because you're basically making a trade off between like sort of like centralization in which you have this intermediary component in which it's not really that difficult to plug and play immediately. All you need to do is just lock the equivalent asset on your own layer one, but in this case, because every node and every party and counterparty is hosting their own sort of component in order to talk to each other, that's why there is more work required in order to basically do this. And there's a decentralized identity management system because if you're not able to authenticate yourself, I mean, it's very possible to basically launch, you know, an equivalent like not man in middle basically spoof the identity of who you claim to be. So in terms of protocols, we have data sharing with consensus proofs, we have atomic asset exchanges across the network, and then we have cross network asset transfers. So this is sort of a chart that basically tells us what like the current networks we currently support as we mentioned earlier, the data sharing and sort of like what sort of properties are available on each one's and the reason why we're doing fabric to fabric because it supports all three of these sort of interoperability like practices so we could perform data sharing, we could perform asset transfer, we could perform asset exchange, although we will only be demoing asset exchange today. So and in terms of the transaction flows, this is sort of like what it would look like, because as the atomic cross chain swap is underway, we don't necessarily know the final state of that transaction. So technically, this would get this wouldn't get overwritten per se would still be there within their own like layer one blockchain. So as to how the transaction progressed, but the state as to who the owner of that asset is will change. So basically, functionally, there's a new block that will basically say, you know, this bond or this sort of these set of tokens now belong to this wallet address. So the present assumptions in hyperledger weaver. So there is no explicit or automated interconnect network communication. So although this is done over relays, a lot of this is basically done manually, and there's a lot of setup involved. So in terms of the future, we're automating the flow of ledger updates across the networks via relays and cross network events and Byzantine swap solves part of this in which we do introduce additional automation so we could have sort of cross chain messaging across different layers. And there is no global clock per se in terms of the individual hyperledger weaver components and in Byzantine so we changed that by basically mandating that every sort of party and counterparty run their own NTP second node. So we were able to basically confer to confirm that we are running on the correct time without where our clocks are basically synchronized. And subsequently because of that, we're able to ensure that the transactions able to execute in the correct order. So in terms of the general sketch of fabric, we have application chain code that's responsible for locking, claiming and reclaiming the asset. We're able to have the records of the pledge asset on the ledger in one of two ways. So either in the interoperational chain code namespace or basically using the libraries and in terms of Byzantine swaps. So the general description is an iterative improvement on Dr. Marie Hurley. He's original design. So he was a professor from Brown University who invented the concept of an atomic cross chain swap. And we're basically adding additional security guarantees in this case. So the additional guarantees that we add are both some of them are deterministic and some are probabilistic. So now malicious lockup attacks are now impossible. So malicious lockup attack is when a party in a counterpart. Let's say we have Alice and Bob and Alice continues to attempt to a transaction like a cross chain swap with Bob, but intentionally fails. Either she continues to overrun the time limit allocated for that swap or she keeps arbitrarily deviating from the protocol every single time. So malicious lockup is functionally a form of denial of service in which that fungible token or that NFT or whatever asset you're trying to sort of exchange on the cross blockchain networks, it's basically on hold because basically Alice will continue to attempt to launch an atomic cross chain swap every time. It keeps failing. The assets will continuously be held in escrow in the HDLC forever. So Maurice Hurley, he basically dismisses a malicious lockup attack because in an individual transaction, you're basically going to give up if the transaction is unsuccessful for a certain amount of times. But in the context of things like automated market makers or any autonomous process, if you have like a trading bot, for example, you cannot sort of, there is no defense for a malicious lockup attack. But malicious lockup attacks are now impossible because now the Byzantine swap framework basically has a sort of like counter, not necessarily a trust score, or basically have a way to basically track if the number of requests, the reason why they fail and whether the reason they fail is it a communication failure of some kind or is it intentional malice? And if it is a malicious lockup attack, we'll basically blacklist that particular node from the network and because we're utilizing the decentralized identity management system from Hyperledger Weaver, it will be very difficult for an attacker to basically just arbitrarily spin up new identities and attempt another malicious lockup. Again, sore loser attacks for fungible assets are now severely amortized. So a sore loser attack is basically when you were basically just taking the money and running. So if I have $100 and I wanted to trade that with you, basically the way we mitigate a sore loser attack is we just send a large number of smaller payments. I could send, for example, 10 payments of $10 each and a sore loser attack is basically me just refusing, is just stop paying basically. So whatever the difference is when I initiated that attack, basically you lost that amount of money whereas, and this was an attack that's been present in DeFi for a long time. So the way that the risk is amortized in this case is just by breaking up transactions. However, we cannot do that for wholesale transactions in which they occur once. So for example, in NFT, you cannot split up an NFT or a wholesale asset like the car that Carol sold to Alice as many separate transactions, it's one or nothing. So we can, although we can amortize sore loser attacks for fungible assets like a token like Bitcoin, we can make the risk of a sore loser attack basically amortize it so much in which it's practically infeasible for non-fungible ones primarily due to a number of reasons both from a system and network security side. So the reason, the way we're able to basically make sore loser attacks for wholesale transactions for non-fungible tokens, practically infeasible is because we have encrypted containers that make it very difficult and resource-wise infeasible for just average Joe and Jane to arbitrarily cheat the transaction because if she wanted to launch a sore loser attack before like in the previous version of an atomic swaps you had to go through the manual away and you had to basically check the boxes going through the next step of the process. Part of the functionality of Byzantine swap is all of this is automated, it's in an encrypted container and if you wanted to cheat that process you would have to break into the encrypted container you would have to arbitrarily change the code you would basically have to also successfully fool not just the counterparty but also all the witnesses that your encrypted container has the same hash and it's basically playing by the same rules as all your counterparties as well as all the witnesses and basically you're not able to and that you're not arbitrarily deviating for the protocol so the bearer to entry in order to basically launch a sore loser attack due to sort of like system security measures is a lot higher but also because of the network security measures where we install witness consensus so witnesses are a concept in which we basically take an arbitrary like layer two consensus in which we randomly, we do random leader election across each disparate layer one network and we just have them basically observe an atomic cross chain swap because basically witnesses are assumed to have the individual components to participate in a cross chain swap to begin with so you can think of a witness consensus as basically like jury duty at any time you could be called up to stand to basically give a past judgment on a trial but that's basically what we're doing here but the witnesses are randomly selected from each certain disparate layer ones and as an attacker, gaining like a super majority depending on what your consensus is is difficult because not only we're using random leader election but you basically need to have identities for that particular node across each sort of layer one that's participating in the Byzantine swap and the probability that you will have like sort of nodes like sort of like a super, dishonest super majority of nodes in order to corrupt the witness consensus step is extremely low, it is very expensive because basically you will need whatever number of nodes you need to break fault tolerance times K, K being the number of layer ones that are participating in this cross chain swap and the more you have the more computationally difficult it is for the attacker to invest resource into it so we have a system security perspective we have a network security perspective and of course part of the systems we just have secure automated execution so we have autonomous rollback the autonomous execution of the steps so you can arbitrarily pause or choose to deviate from the atomic cross chain swap like that's all run for you with the encrypted container user agent and things like autonomous rollbacks on the behalf of the party and the counterparty basically make it practically much, much more difficult to cheat so the attack scenario in which the only feasible time which you could cheat Byzantine swaps is that you are a skilled systems hacker and you're able to basically find a zero day vulnerability break into the encrypted container you're able to break the encryption for that container you're able to arbitrarily change the code of that container to basically arbitrarily execute the steps you want and you spent a massive amount of resources across many different layer ones to basically have nodes that through chance and you're running witness consensus on each individual cross chain swap and then they sort of disband so it's sort of like an ad hoc formation of witness consensus you need to be basically very, very lucky in which you have a dishonest super majority of nodes controlled by you that happen to be there at the right time to basically all lie on your behalf so the chances that that happened are extremely small and even if you were able to execute it congratulations, you basically were able to, I don't know, cancel an NFT transaction for going through or stop somebody's Bitcoin being exchanged for Ether so it's like the cost that you would have to incur in order to basically stop one transaction is ridiculously high so those are sort of the fundamental properties of Byzantine swaps so in terms of asset exchange this is what it looks like so we have two networks here we have network A and network B and we have an asset M that belongs to party X and we want to transfer it to party Y so basically we have these two networks right here both for the fungible and non-fungible case so for in the case of a fungible asset let's take for example, a CBDC that's perfectly fungible you're able to basically use the same like atomic cross-chain swap asset exchange framework and for a non-fungible asset so like an NFT but in this case for example an investment bond you're able to utilize the exact same framework as well so whether the asset in question is a currency or whether it's a bond is irrelevant because it still utilizes the same framework come here and the asset exchange using HGLC is basically executed with these steps which we've described earlier but for more context you create an agreement basically a hash lock which locks the asset with this hash H of S and you basically you disperse that pre-image not the pre-image you disperse the hash of that pre-image Bob does the same thing in which he also disperses his pre-image back to Alice then after a certain amount of time they basically agree let's go forward with the swap so Alice audits the agreement before moving forward then she claims Bob's asset using the secret S that Bob gave to her so the secret being the pre-image before this time lock expires and concurrently Bob basically does the same thing so this is just a concrete representation of the abstraction that we talked about earlier and in this case this is an example of a bond to CBDC exchange so before this is just an asset to asset exchange but with an asset exchange across Hyperledger Weaver you can basically trade or exchange a non-fungible token, non-fungible asset like a bond for its equivalent value in a fungible asset so for example a currency in this particular case and this is an example of that again the exact same steps you're doing the same thing you make a pre-image you get a hash of that pre-image you disperse it to the counterparty but the only thing that's really different in this case is the asset being exchanged so one sending over a non-fungible asset and the other sending a fungible asset so you're trading a token for a bond in this case and this is a far more detailed diagram as to the subscription and communication framework of Weaver so basically imagine like this diagram is like one blockchain in this case it's fabric this is a fabric to fabric a detailed fabric to fabric diagram and all the communication is taking place in between these relays these are the steps in which we are able to basically subscribe to events and subscribe to subscription to events is basically how is the atomic cross-chain swap progressing same thing with the communication and the publishing of each asset so like they still use the same communication framework but for Byzantine swaps like this is sort of like the modified architecture for that because every sort of node party counterparty is gonna have their own component so you're all gonna have your own NTP sec cluster daemon you're gonna have your own relay you're gonna have your own sort of accounts that are each modeled and authenticated across every layer one that you're transacting with and this is the very simplistic example of it's just two blockchains, two disparate layer ones in this case the layer ones are the same you have both have fabric networks but basically this can scale linearly it just has to go in like a order of a chain and again all these slides also be dispersed at the end of this presentation as well so if you wanted to take a look as to how this works in detail I mean you can look at the slides or ask me questions and now we're gonna have a video demonstration so technically this is 13 minutes long but I'm gonna skip to the parts that sort of like model these steps so for context we spun up a fabric to fabric network in Hyperledger Weaver and we pushed code that actually got merged into the Hyperledger Weaver repository and we're going to be modeling two scenarios we're gonna be modeling the swap of the non-fungible asset in the case of which it succeeds in which you're able to transfer over cleanly and in the case which it fails in which you have the deterministic rollback and in the case of a deterministic rollback the asset just returned to their original owners and also the case of a fungible asset in which it's just tokens in this case so this command is basically saying we're going to like Alice is going to lock her asset and she is going to basically exchange a bond to Bob so bond one A03 and you can basically assume that the even sort of any asset that's odd so for example bond one A03 that belongs to Alice any sort of asset that's even belongs to Bob but by the end of this transaction that's going to basically fall into the hands of Bob so Bob should have basically an odd numbered asset so that's the initialization of the asset exchange we use this terminal to basically check like what's happening here so we locked the asset we confirmed Alice exists is the asset locked in response is true and the query has been complete and the gateways has been disconnected then we get the status of where the asset is so we're taking the sort of status from each individual oh I accidentally skipped back we're taking the status of where the assets lie within each individual network so fabric network one that's technically with Alice and then you are going to see an equivalent record with Bob as well so you have basically like these tokens so you could see for example fabric network one simple asset we have bond one but you don't say A03 because it has been moved out from the network in which it resided in Alice and it's now locked up in a hash time lock contract and until after 60 seconds basically pass assuming all goes well it should basically return back to Bob and basically you should be able to see this record as to whose assets which asset belongs to who and then you have the fabric network as well the fabric network two is basically this is taking into account the fungible assets in this particular point in the demo we haven't done fungible yet so Alice has 10,000 tokens, Bob has 8,000 and as we progress further here we're going to get run the network status again and this time we should be able to see that in fabric network one the bond has actually transferred back to Alice in this case because we overran the time limit so in this particular example this is the case in which the swap was not successful you exceeded the time limit which is basically an arbitrary violation of the protocol and then we basically roll back to the original owner so bond one of ID A03 now belongs to Alice in this case it just rolled back to her and technically in trying to initiate that transaction again we're able to basically have that asset transferred cleanly this time so basically now we're reattempting that transaction but in order to be successful this time we actually progress to the next step so Alice basically locks the transaction and then this is the case in which Bob basically disperses his secret tech so basically Bob is going forward and advancing the next step of this transaction whereas Bob just left Alice hanging before and they exceeded the time limit so that's why the transaction we had the deterministic rollback of that asset as well so we get the status of the asset again and then subsequently from this you could see there's a change here this time in which now we have bond one and A03 it's technically listed with bond one A04 so the stipulation earlier about how Alice owns all the odd number assets and Bob owns all the even number assets now that has been switched because they are ordered they're basically now grouped together in which you had the odd number assets which belonged to Alice in one group and then followed by the even numbered assets which belonged to Bob in the other group but as you could see we have ID A03 which is basically Alice's asset that got successfully transferred to Bob because it's listed along with all the other assets he owned which are numbered even which technically belongs to him so in this case that was the demonstration of non-fungible token or asset transactions in the case of deterministic rollback if there's arbitrary violation and what happens if it's a success and then we're going to basically skip ahead to the case of a fungible asset in this case so fungible assets are basically tokens so in this case we're going to have a timeout for 60 seconds Bob is going to be basically initiating the transaction this time and he's going to send over 167 tokens so that 167 tokens gets locked up in a hash time lock contract and as you can see the balance hasn't shifted yet because the balance will only get really dispersed once the time limit has passed and once Alice actually proceeds further with the transaction itself so as we go further here you can see that now the balance has updated in which like okay well the tokens 163 tokens have been moved off the chain now they're held in the HDLC and in this case we're going to I think in this case Bob doesn't Alice doesn't perform her step so basically what happens here is a deterministic rollback in which like okay well Alice is supposed to basically disperse her secret text or disperse her pre-image so that she's able to claim the defundable assets that were stored in that HDLC but as we run the get status again basically what happens is that we're back to 8000 because the time limit took too long Alice didn't disperse her pre-image and because of that all the tokens just returned to Bob now Bob's going to re-attempt this transaction but this time Alice is actually going to follow the protocol this time so in this case a different amount so 245 tokens will be placed into a hash time law contract that's still in the layer one because it's going to take time to sort of like move that into the HDLC and when we run get status again then we're going to see that sort of like balance update in which now like Alice would have to basically have the secret text and like she wants to progress to the next part of the transaction you could see the fungible asset has been claimed as true and the asset is complete so as we progress forward here we should be able to basically see the difference in balances so now you could see that out of the 245 that Bob was going to transfer to Alice it was indeed successful Alice initially had 10,000 tokens now it's 10,245 and Bob has a new balance of 7,755 tokens so in this video demonstration we basically demo two things the cases of successful and non-successful transfers of non-fungible assets and fungible assets and in the case of non-successful cases whether you overran the time limit or you arbitrarily deviated from the protocol we are able to deterministically roll back to the original owners and all the while witnesses are basically checking to make sure that this is correct and all the sort of system and network security functionality is like hidden under the surface I think I just heard the 45 minute mark go out but yes, this was a very informative it was a very, very enlightening very informative eventing chip I personally like to thank all my mentors at the Hyperledger Foundation as well as the menu, the program chair David, thank you again for having me on and all my mentors from sort of like that sort of like helped me learn more about the prior art of atomic cross chain swaps and help me figure out exactly how we could build upon Maurice Hurley his original design all the code has been merged to Cacti as a disclaimer the Hyperledger Cactus and Hyperledger Weaver repositories will be merged into a single repository as Hyperledger Cacti in the future all the code is open source if you wanted to check out the individual Cactus and Weaver repositories I've linked them here again the slides will be dispersed ahead of the presentation and you can also find the Hyperledger Cacti repository as well I have my contact information my LinkedIn if you wanted to chat and now we will open it up to Q&A and I'll also open the chat here so let's see, YouTube live stream don't the two so we have a question from James Kemp don't the two sides need to agree on a data schema? Yes, you're absolutely correct in which a data schema needs to be the same that's why there are fundamental limitations as to like what sort of like interoperability based transaction you could sort of get away with so if in the case of which they don't agree on a data schema for example an R3 corda and fabric you basically need to do like more sort of groundwork on each layer of ledger one so there's like we could transact the fabric to fabric because they have the exact same data schema but in the case of Weaver when you have like R3 corda and Beisu R3 corda and fabric, you know, transacting with each other there are specific like libraries and additional code in order to make that transaction happen so there's a sort of like if there are differences you need a sort of like compromise in the middle you need to make that sort of shared data schema between the two networks and make them work together. Let's see. Another, we have a question from YouTube. Could I use one chain as a bridge between an EVM client and Cardano mainnet? If there is, if yes, is there documentation how to implement that? So, Anon on YouTube. So, this is not a bridge. This is an atomic cross-chain swap and that's atomic cross-chain swaps are fundamentally different than a bridge. They are an alternative interoperability mechanism so technically I don't have context as to whether you could use when chain as a bridge for EVM chain and Cardano mainnet. If you're asking whether we could utilize when chain to do a cross-chain swap functionality between EVM and Cardano currently weaver only supports R3 corda, Beisu and fabric that functionality will have to be like added into the future because as part of the stipulations discussed earlier, every sort of participant has their own copy of the infrastructure in order to adhere to that decentralization principle. So, in that case like that functionality will all have to be built out and no documentation currently exists for that. Let's see, Daniel Sego has a question. Is there a way to execute business logic in blockchain interoperability off-chain between the two blockchains in a trustless way? So, exchanging one token or several different types and amount of token on another chain with some off-chain program logic. So, off-chain between two different types and blockchains. So, in this case, like the way that atomic cross-chain swaps work is that every individual layer one will have like a block that'll append like sort of what the result of that sort of transaction was on sort of their own blockchain. So, technically the hyper ledger weaver part like the arbitrary communication between different layer ones, the individual components that talk to each other that technically happens like off-chain but you will need to update the state of each individual layer one that sort of those peers are connected to as you know how the cross-chain swap went. So, exchanging one token for several different types and the amount of token on another chain. So, in this case, like every sort of like participant will have, they have their own components and if you're pending different layer ones there needs to be support for those layer ones in order if there needs to be support for each individual layer one that's connected to the hyper ledger weaver framework. So, if we wanted to add land chain for example we need to add additional libraries and stuff in the SDK so that we could have one chain compatible with the hyper ledger weaver framework but like a lot of this is technically done like outside the blockchain you're only like retroactively updating the individual layer one blockchain sort of like after the swap has occurred if that makes sense. Let's see. GQ has a question. HGLC only do swap not transfer between two. Oh, I'm sorry. I think somebody has had a question but I got static. Can you repeat your question? Hello? Oh, okay. Well, in that case, I'll just go back to GQ's question. So, HGLC only does swap not transfer between the two blockchains. So, in this case like a hash time lock contract I mean, not necessarily. So, you can use a hash time lock contract to basically do a transfer in which like a swap is basically you're exchanging one asset for another whereas a hash time lock contract is just a flavor of smart contract in which the two conditions are time as well as like the cryptographic passphrase basically. So, you could have the HGLC can do things one way in which if I as Alice just wanted to send 100 tokens to Bob or a single NFT to Bob but Bob gives nothing in return all Bob needs to do is like, once Alice disperses the individual like the pre-image and Bob is at the correct time he can unlock that 100 Bitcoin or one NFT and claim it but there is no assertion that an HGLC can only do a swap in which Bob has to give something back. So, HGLCs can go one way if that makes sense. Do we have any additional questions at this time? Oh, okay, great. Well, in that case, my contact information's here all the code is sort of like on these links already and yeah, I'll just stop sharing my screen. David, did you wanna close this out or? Yeah, well, just thank you, Francis and thank you for everybody who dialed in both on Zoom and on YouTube and thanks for all your questions. We, if you have additional questions you know, it's an open source community we would love to continue the discussion please feel free to join us on Hyperledger's Discord Server or our mailing list or our project calls. You know, this is not the only opportunity to talk to people about what's going on within our operability in the community. So, hopefully this is the start of many more conversations. I see here a question here but will the recording be available on YouTube? Yes, I hear that may send the link. What I'll also do is I'll send these links over an email to everybody who signed up. So, Francis, if you have those slides if you send them to me I'll send those out to everybody who and I'll send the slides and the YouTube recording to everybody who signed up. Oh sure, sounds good. And with that again, thanks everybody for dialing in and I hope you enjoyed. Thanks Francis, thanks everyone. Bye everyone.