 Okay, you're live. So then hello everybody or good afternoon. Good morning. I'm not quite sure about the time So this is high. This is hyperlegia meetup. I'm gonna have basically Like brief presentation or a short workshop on atomic cross-chain swaps today There's there's gonna be one one example That's having like an atomic cross-chain swap between hyperlegia fairbanks and and and the tedium I'm not quite sure if if people are still coming I Slowly actually start by introducing step by step just the beginnings. I mean just the just the introductory stops So perhaps perhaps people still still coming basically. I I Think it's gonna be like one hour and Sometimes my internet connection is not always the best So if I just get you know, very much as a robot then it might happen for a for a second or two But I hope it's it's gonna work. I don't share myself basically on a video on the one hand It's because Being So I I don't look very much, you know, I mean, I mean as I say as people On the other hand, I mean if I just if I just have my video running them Basically, I my my connection will be even more chubby So basically, let me just start this is the agenda for today Again, it's it's not gonna be something as it's ready to go to what I'm presenting today But it will be a demonstration How you can do like hash or how you can implement like hash time lock contracts or autonomy cross-chain swaps between between each between different blockchains Especially between like ET human type or ledger fabric. So what I'm gonna do today as an agenda I will just try to introduce step-by-step The concept of atomic cross-chain swaps and hash time lock contracts. So basically I will start somehow with the problem statement What's the problem? So why why do we need this whole stuff at all? We just this guy basically the basic building blocks. That's that's the hash time lock contract HTIC Based on to HTIC we can do an atomic cross-chain swap. So basically it's it's something again that I'm gonna demonstrating I have one example implementation as well as the title of the presentation says it's an it's an implementation for an for an atomic cross-chain swap between between hyper ledger fabric and and DTU so there will be some some demonstrations both for the swaps and basically for for the for the individual HTICs as well So this will be like like two demonstrations and At the end, I will just List some some practical considerations. So that's the agenda for today And at the end we can have like a longer discussion if you have like, you know I mean shorter questions in the middle or if you if you don't understand anything or If my voice is getting very choppy or or my connection unstable then just interrupt me and then I try to answer Or or somehow repair the technical problems as soon as I can or as fast as I Can but if if we have like, you know, like like longer considerations or longer discussions Then I would propose to have it have it somehow at the end. I Will have one Demonstration code as well. It's it's in a bit hub repo. It is linked here So you can basically find in github as well it's under Daniel minus slash atomic cross chain and This repository basically includes all of the codes that I'm that I'm gonna present in today So let me start basically with the introduction Why don't we need why do we need such such a stuffs? Why do we need like this this magical things like like hashtag of contracts and and atomic cross-chains boss So the problem is is basically the usual problem as as The problem for blockchain. We want to have something as a value exchange without trusted intermediary Of course, there's one possibility That's the blockchain for that so we can have like like value exchange in one chain Without trusted intermediary with the help of a peer-to-peer network But we would like to focus a little bit here on something as a cross-chain interoperability Interoperability So supposing we want to somehow exchange values That are basically Somehow manifested on on two different Chains two different blockchains then we will have a problem and So I have this picture here at the end It might look funny So basically what we want to do we have like several blockchains or several systems It might even be actually centralized as well and we want to do Kind of a transactions on on these systems But in a way that I don't all transactions are executed or none of them executed So that's that's what we want to do somehow Might be a funny thing. This is kind of an opposite of a Mexican standoff So in our case, I mean if all all transactions are executed We are happy if none of the transactions are actually executed We are not so happy if If some of the transactions are executed and the other parts are not then we are absolutely not happy So that's our value exchange actually a Mexican standoff is the opposite So if you know, I mean every every transaction is executed then then none of the participants are happy If some of them executed and some not then perhaps one or two actors are happy So it's just you know, it's a little bit like off-chain introduction to the to the topic So again So the problem is we want to do value exchange value transfer and veto trans trusted intermediary And it works pretty well if we have one chain So like we have ethereum, we can do value exchange for Or for years it can see in it in ethereum Works it works pretty well We get blockchain like Bitcoin So we can do like like value exchange value transfer in the Bitcoin blockchain as well And of course you get like other ledgers as well like like consortium ledgers like like hyper ledger fabric So we can do kind of a value transfer without trusted intermediary. This is actually not so much exactly right with hyper ledger fabric It's hyper ledger fabric is rather kind of a semi trusted network. So I would say we can do kind of a Value exchange with a bit of semi trusted intermediary with hyper ledger fabric But the point is as soon as we want to Somehow cooperate between two different blockchains. I mean this whole situation is is getting more more and more complicated and somehow the idea is want to do like Cross-chain interoperability in a way that it's it's it's not trusted. So basically Let me have the very simple example. That's the classical example Let me have let me assume that there's Alice and Bob Cryptography, that's usually a symbol and then what we want to do is that Alice and Bob wants to Want to basically exchange ether for Bitcoin? That's the classical example We will see another I mean if I say he be here Bitcoin We will see some kind of a token on hyper ledger fabric later on the demonstration But usually like Introducing atomic cross-chain stops or HTL C's Start with with the example of ether and Bitcoin. So I would just stay with ether and Bitcoin for the first round But again, if you don't like it just just imagine Instead of Bitcoin, we will use like kind of a hyper ledger fabric account and token based stuff in a long run So what we want to do we got two chains. We want to exchange ether for Bitcoin Alice wants to send some ether to Bob and Bob wants to send some Bitcoin to ether as an exchange So that's that's actually the problem and the main problem is that these are two chains So the question is how can we do these two transactions? In a way that I mean both are executed, of course or none of them executed, of course And both Alice gets the Bitcoin and Bob gets the ether or none of them gets that money In a way that we are working on two different chains So one way is a pretty much centralized Solution we can have As a centralized component So one way of doing is that like Alice sends this ether to this Let's call it as a Casto DRS row It's a centralized component and then Bob sends basically Bitcoin to this component to this centralized component And while this component checks if both money arrived and if they arrived then basically it sends back So it sends back like Bitcoin to Alice and it sends ether to Bob minus some kind of a fee So that's a possible architecture However, I mean so having like decentralized protocols People usually don't like this solution because it's pretty much centralized It has some counterparty risk. So it has actually all the problems That's basically centralized into institutions having a Very cool such an idea having having in a blockchain space So what we should do basically that we should somehow implement this kind of a mechanism in a decentralized way And basically we should somehow Decentralize this exchange. This is S2. So it shouldn't be like a centralized party Or a centralized S2 It should be somehow decentralized working working in both both chains And what should happen basically that Yes, I mean Alice sends this this ether not directly to Bob, but to this somehow decentralized Astral service and Bob sends the Bitcoin not directly to Alice But somehow to this decentralized Astral service And if both Astral services or the one decentralized Astral service Gets the money actually then they can do the real transfer So like transferring Bitcoin to Alice and transferring ether to Bob So that's actually an atomic cross-chain swap in a very high level That's the idea behind and that's actually a solution for such a value exchange Having in a in a in a totally decent decentralized way between two blockchains So again, just consider that basically I mean one part this part is basically On on ether on ethereum and the other part of the problem is on bitcoin Or as we see it later, I mean these these are just two arbitrary chains Uh, the first one can be ethereum. The second one can be hyper leisure fabric Or this can be actually any kind of two two blockchains In in between we want to do kind of an interoperability service So that's an atomic cross-chain swap. So the question is how we build up such an atomic cross-chain swap And for that we have to actually introduce building blocks And the building block is the hash time lock contract So basically hash time lock contract is a kind of a transaction that we will see in a second Which helps building up atomic cross-chain swaps. So hdic is is not just for fun The main idea for hdic is kind of a cryptographic protocol Which helps building up cross-chain interoperability and atomic cross-chain swaps So that's the idea for hdic hash time lock contract So let me just start and take a look. Uh, what is exactly an hdic or hash time lock contract? So if we have like a standard transaction in blockchain A standard transaction is blockchain is is either executed or non-executed It differs a little bit Between different blockchains. So like if you have like the Hyper leisure fabric transaction hyper leisure transit fabric transactions are final So they will be executed With the probability of one And then basically like bitcoin transactions are probabilistic So they won't be executed with the probability of one But like with the probability of 99.999 percent. It's usually after six confirmations You can say that basically it's 99.999 percent Probability that the transaction is executed and it even it's even more complicated Because it used to be like fully probabilistic But there's some final finality settlements as well as far as I know at the moment With like hundred blocks as well. So it's a bit more complicated But nevertheless, uh, so we can say that after a certain confirmations of block basically A kind of a transaction like a value transfer like if I just just transfer bitcoin from one account to another one Is executed on the blockchain? So it's it's final. I mean in a final either either I'd be a probabilistic final or or or or really final So that's a classical transaction And what we want to do in uh in an htlc We want to do kind of a transaction that is not fully executed, but only partially executed so, um Supposing we want to send like bitcoin or ether to bob We want to create such a transaction. Uh, that doesn't create actually it doesn't send Bitcoin or ether to bob But that sends this bitcoin or ether to kind of a temporal state So this temporal state that you can see here below Is neither related to ellis nor nor to bob It's it's just an intermediary state somehow And then it can happen something with this intermediary state But like, you know, I mean if you just send like five bitcoin From ellis to bob, uh, but you don't send it directly but with the help of this Intermediary state Then it looks that way that this five bitcoin or five ether will be in a temporal state So it won't I mean ellis won't have this five bitcoin anymore Neither bob, but this five bitcoin or five ether will be in a temporal state somehow So that's important. This this transaction is kind of not final or not even probabilistic final But first we want to transfer This like five bitcoin or five ether To a temporal state to an intermediary state to something which is which is still not final So that's the first building block And as a second one, we want to have some conditions in this temporal transactions in this temporal state Actually two conditions One condition would basically send this Send this money really to bob So from the intermediary state to bob and the second transaction would actually deliver this transaction So these are the two conditions that we want to somehow build in in this temporal transaction And then the first condition is a hash lock So what we want to do we want to have basically a secret password We want to create a transaction That that has kind of an intermediary state And then we want to have a password and as soon as this password is activated We want to make sure that this transaction is fully executed so Bitcoin or five ether to bob it doesn't send She doesn't send it directly But to an intermediary state where there's a hash hash lock Which is basically a secret password and as soon as the secret password revealed then bob gets the money If this password is not revealed then basically bob doesn't get the money Um, it can be imagined as basically as a lock And if you have the key or the password then this transaction will be fully executed If you if you do not have the key, uh, then basically this transaction won't be executed That's the hash lock The reason is that it's it's hash lock because it is actually Implemented with the help of a cryptographic hash function. So cryptographic has hash function Um, I'm not gonna go very much into the details, but basically you have some some password or some keys This is a cat and then cryptographic hash function Create some some cryptic output with like 32 bytes Innovated based on this output. I mean, I mean, uh, the key or the password, uh, can't be revealed It can't be helped but as soon as you have the key or the password Basically, uh, uh, this output this lock can be very easily computed So that's what we have here Basically, it looks that way, uh, that we want to have a hash lock condition Hash lock condition for the hash lock condition We will have basically a pre image of a hash function. That's the that's our password And as soon as we know the password, uh, basically we can fully, uh, fully have this transaction fully commit our transaction So that's our hash lock So this is the slide for unlocking the unlocking the transaction again We start this sending one bitcoin to an intermediary state where we have basically a hash value Of an unknown secret of an unknown lock of an unknown password And as soon as somebody reveals in a special way this password this key then this transaction will be fully executed So that's the hash lock part of a hash time lock contract And we got basically another part that's called the time lock So supposing we have this temporal transaction, uh, that can be basically Somehow carried out or committed, uh, with the help of a password, which is actually a pre image of a hash function Uh, we wouldn't like actually to wait forever For unlocking this transaction So as as you see or as you can imagine, uh having this intermediary transaction It looks that way that at the moment neither Alice nor both Has basically this like one bitcoin or five bitcoin or five bidders because it's somehow in an intermediary state Which is not very much practical if it if this money, uh remains there forever Because it means that it is lost, um, which is not so much practical So what we want to do is to build in a kind of a kind of a time lock Kind of a time out So we do this transaction, uh to an intermediary state, uh, we wait Like six blocks or six hours or six minutes If anybody gets the password, uh, which is the pre image of a hash function Then we can fully execute this transaction But if this time lock, uh, basically expires then then we would revert this transaction So after that we say that hey if if nobody, uh, gets the Password nobody wants to have this transaction fully executed In this time limit, then let me just revert this transaction. Then then it's somehow not gonna work And this is the time lock, uh, basically In a hash time lock contract. So this is what happens After a certain time lock It doesn't possible, uh, it's not possible to to activate the best password anymore You can't you can't have this pre image of the hash anymore You can't commit the transaction to both But what's gonna happen is that there's a revert transaction And then the fund from this intermediary state is simply reverted to Alice So Alice gets back basically, uh, the money So that's all that's the time lock. Uh, and basically that's hash time lock contract Again, it's very simple, uh We don't have one one fully executed transaction on the blockchain like fully executed transaction For transferring a monitor or one bitcoin From Alice to Bob But we execute this transaction somehow into an intermediate state and from this intermediate it states There are just two conditions How this how this transaction can be either fully executed or reverted and then you can fully fully executed if If you know the password if you know the key, uh, which is basically the Uh, the pre image of a hash value Then Bob gets the money money and if you don't know or if you don't want to use for some reasons This uh, this lock this hash lock then the after a certain time Timeout this transaction can be reverted. So basically Alice gets bad the money Pretty simple. So that's like a hdrc And then I'm gonna show some very simple Examples, uh, how such hdrcs can be implemented in ethereum or or even with with hyper ledger fabric It's important to note. These are these are not productive ready solutions. These are mostly for So what i'm having here basically I just use remix. I hope I hope you can see actually the code It can be deployed basically, uh to to the mainnet as well I I use here remix because it's just you know, I mean, I mean much much faster Uh, to to demonstrate both the code and actually the transactions If I just deploy it to to the mainnet like or even drop stand I mean for for all transaction. I should wait basically a couple of couple of like, uh, you know, I mean, I mean not minutes, but About 10 seconds at least So what i'm having here Is a very simple hdrc Implementation It looks that way As I mentioned, so we got like at least Hey Daniel sorry to interrupt and at least Yeah, sure sure, uh, let me have some some some questions if you if you feel like, uh Just I mean some some short questions, uh, or let me just much better. Let me just take a look on the chat. Yeah, I should So you don't see the code, uh So you don't see the code at the moment There should be a chat window and some some solidity code basically on my on my screen The presentation is on the screen. Okay So Let's take a look so how about now Perfect now Okay. Yeah, um, so let me just know I I think I think it should be uh So if I just change window theoretically I was I was sharing my desktop, but if I change window it doesn't always work. So it might be the case. Yeah Uh, so what I'm having here is a very simple hdrc on ethereum It looks that way, uh I hope if I play with the window You'll still see it. So basically from Alice I want to send some ether to bob And this is not a general smart contract So it's actually used just for this use case just for a very simple example So supposing we have ethereum, uh, and supposing the value transfer in ethereum is sending ether Then the intermediary state can be basically a smart contract. So what I do basically I don't send directly ether From Alice to bob, but I will send it to a smart contract. That's basically an hdrc and that implements my logic Uh, so this is very simple solidity uh if I just If we just take look basically we have like the addresses So we have like the address is from Alice. Uh, we have to bob. We have one timeout and one hash lock So basically this whole hdrc is the smart contract itself. It's nothing special We get one even that's committing actually the evens. So if we if we commit the transaction There will be an even trace a reason We get the constructor. I mean constructor looks that way. We initiate the transaction from Alice So basically Alice always who deploys this the smart contract And again, this is a very very simple example So it is assumed that for for each hdrc You just deploy a new contract. Uh, it can be done in a more complicated way, of course and more productive way, of course But that's actually the the simplest thing implementation So basically Alice deploys the smart contract So Alice will be the deployer and we get some parameters parameters like both the hash lock and the time lock Which is actually a timeout so nothing special Uh, it allows payment. So basically It works that way. I don't send directly either to bob, but I will send it to this intermediary state That's my intermediary state. That's a smart contract And what's gonna happen is uh, there will be from this Smart contract Two functions, uh, that we have it actually with green And with red so one will be the commit And the second one will be delivered So the other one will be delivered So if you just go back We see these functions. I have one function which which gets how much balance do I have in my contract? And I have just two two functions two transactions One is the commit. I can commit the transaction With one input. That's the secret hash That's the that's the pre image of the hash or we can say it as a password of basically this hash And then I'm checking is the password is good. Uh, so I mean if I initiate this contract I will have the hash lock. So if I have the password I should take a look that this special password is really the pre image of this That's important. I take a look if time lock is not activated not already activated So if timeout is still not happened, then I'm pretty happy with that Uh, and if everything said I just transfer basically this money to Bob So this is like the this is like the commit part basically and what's important or it's gonna be important in the future I just raised basically one event which contains this this secret secret password basically And the second one is revert. I just you see a revert thing because revert is uh is uh Is a keyboard in solidity. So I can't Can't have it as uh with the name as river. So it's just a river thing Uh, it's very simple. Basically. I take a look if if time lock is active Uh, so it's I mean if the timeout already happened and and if so then I revert this transaction Which means that I just I just send that the money to Alice It's pretty simple. Uh, let me just uh, let me just show how it works. Uh, I just compile it. I hope it works So I just use basically this this remix stuff. I hope it's It's spectacular enough Not quite sure if I have my transactions somewhere Yeah, here is my transaction window So what i'm doing basically I just set up here the the basic So I have like one one I mean let we have let me just change this. Uh, let we have just two accounts This one will be the deployer This was the third one, uh, and then the deployer will be Alice And then the first account this was the this was the first account and the fifth account is gonna be Bob So this is the fifth account. So what I'm gonna do I'm gonna initialize this contract as Alice Uh, this is the account for Alice Uh, and if I have one to deploy I should use three parameters Uh, I should use basically the the address of Bob. Uh, I should use the hash lock and I should use the timeout as well So I'm gonna have this address to Bob Uh, I will generate One password So let we have this, uh hdrc That will be our password at the moment. Uh, so what I'm using here is the hash function of our of our secret So that's our secret or that's our password and I'm just using the the hash Hash function for that And then it looks that way This is my second parameter So I should use like 0x and I want to use a timeout, uh Timeout is I mean pretty much In a simple way. It's like unix timestamp. So I will use kind of a 2050 for instance, or I don't know 30 So I just want to make sure that it's it's not expired It's just for demonstration for for normal use cases You can set this like, you know, I mean for the next hour or 10 minutes or 15 minutes or something similar So that's my timeout And I just transact. So basically, I mean, let me just transact again because it was already deployed So let's just have it again. So my contract is deployed and it looks that way Just try to zoom a little bit in So I'm not quite sure if you familiar with remix, but on the left side We can actually take a look on the smart contract So we can take a look like the transactions and and some of the Parameters that you can read out. So we can read out that From Alice address is this one Smart contract doesn't have money at the moment Our hash look that's the hash Is this one and our timeout is something. This is I don't know If I'm not mistaken that should be like 2030 So it's a pretty I mean, you know, it's a pretty long time So what I'm going to do is it's pretty simple. I send some some ether to this contract And I do it in a way. I just send like 10 ether To this contract and I'm having this This is Alice So you can check that it's having like 99 ether on this 10 account and I'm sending like 10 ether to this smart contract with transact So We got 10 ether she's in this intermediary state. So it's it's neither Neither on the account of Alice nor from the account of it's somehow on the smart contract That can be so as an intermediary state So I got here two ways of of somehow resolving this intermediary state And then of course the one way is like committing this transaction If I want to commit the transaction, what I have to do Is to sign this password is to have this password that was htic So supposing I just want to commit this transaction I have to basically sign or have this password this preimage hash preimage And then say commit and if we say commit then theoretically Bob that is the next account Should get basically this 10 ether So let's take a look if it works So the transaction has been executed. It looks great If I take a look get balance is zero So basically the the ether has been transferred from the smart contract from the intermediary state And if I take a look here, you can see that Bob which was the following account has something as 110 ether Okay, I mean the word is pretty much the same I should make sure that I have some some values that is somehow in the In the near future and then wait a little bit and we can reward the transaction as well So this is basically an implementation in ethereum On the private game, I mean the private key. I mean the smart contract doesn't have private keys Smart contract in ethereum can actually send send either As it is programmed Smart contract I mean even the address of the smart contract is created with the help of the creator account So smart contracts do not basically have have private keys ethereum works that way that you got externally on the account and smart contracts externally on the accounts having private keys can interact with the network can interact with smart contracts But smart contracts themselves do not have private keys So anyway, let me take a look how such a thing look like with hyper ledger fabric And uh, so first question if you see my screen. I just changed to visual studio. I I hope actually Uh, I mean desktop sharing followed my visual studio code So let me know if you if you don't see okay Awesome If you don't see I will So first problem in hyper ledger fabric, you don't get something as as token or ether or crypto or anything So what I'm doing is that I implement something similar So what they do basically I I have some some tokens tokens are very easy I will have some basic token functions It's like mint token. Uh, minting token Is nothing special if you're familiar with with hyper ledger fabric I just use I just put into blockchain An account which is an ID that will be alice and bob and basically a balance So that's all it will be a very simple use case So if I mint token, it means that I basically put something into a blockchain So this function is called as with an ID and with an amount And what I do is that I put this amount into this ID So basically I will have like like basic IDs in hyper ledger fabric and for these basic IDs There will be a kind of a kind of an amount associated And this is a very simple like token use case in hyper ledger fabric You can have it in a more complicated way, but it's again. It's just for demonstration So first I had to create actually some some primitive functions So we get like get balance get balance looks that way that we get actually the ID That will be alice and bob and then what's happening is that I just get the balance So I read out the value What's in this ID and then it's a number So if it's 100 I got 100 tokens if it's 150 I got 150 tokens that door So the I have something token the mint token actually adds some some money to the to the token It's it's not money. It's you know, it's just a fictive money or fictive token So I just read out the amount that's on the that's basically on the on the given account And then I just I just add some some more money for that So if like if I mint token for alice then alice Is previously having like 100 tokens if I mint like 100 more then she will have 200 tokens pretty simple I will have some burn tokens as well. It's the opposite of mint So I decrease the the amount of money for alice And what I'm having for the first run I get a transfer And transfer is a final transaction is a final value transfer. Let me put it that way So it's very simple. I just burn some tokens From the from account and I mint some token to the to account Add or handling stuff like that. I basically just the wrong version So basically transfer looks that way. I got from I got to and I get an amount And then if alice having like 100 coin and or token both having like like 100 coins as well If I just transfer like 50, then one will having like like 50 and the other one is like 150 So this is a transfer and this is a this is a this is a very classical transfer as a transfer in in ethereum Again, I mean hyper leisure fabric do not have this basic structure For tokens. So I had to implement something to work with You can do it in a more complicated way as well. There are there are examples Even for hyper leisure fabric, but you can use different token standards even So what I have to do is to extend this very basic transfer function In a way that it works with In an in an hdlc way in a in a in a hash timelow contract way And for that, I will have something as as transfer conditional And transfer conditional is a conditional transfer which is pretty similar to ethereum. So I'm having for the first One id which is which basically lock id It's registered in the in ledger. It's perhaps not so important But what I'm having is a from id is a to id Similarly to to the transfer or to ethereum and I have the amount amount is pretty simple as well And what I'm having is two more parameters. I got the hash lock and I got a timelock as well So transfer conditional is more complicated. Basically, it's it makes I mean it burns From one account, but it doesn't add tokens to another account, but it somehow Puts these tokens to a temporal state which looks that way that I just create a hash timelock Which is again a structure that I that I put into the blockchain to the hyper ledger fabric blockchain And that's transfer conditional and similarly as in as in ethereum I will have I mean I have one function. I can read out this Hash timelock, but basically I have two functions. One is commit And commit works that way that basically I have to refer to this hash timelock contract that I created But basically what I have here is the preimage. So the preimage of my of my Of my hash that I created in the conditional transfer And if this preimage is cool, then basically The party gets the money. So the so the transaction committed fully So basically there will be the other part Which was missing in the conditional Transfer and that's minting the money And there's another way which is reward So reward is again similar. I just use this look this hash timelock ID But basically a reward looks that way that if basically This timestamp is already in the past So the timelock has been activated. Then basically bob gets the money back. Basically. So bob gets the tokens minted So let me just start and let me just take a look if it works Again, I'm not quite sure if you're familiar with hyper ledger fabric, but this is usually not so spectacular. So what I'm having here is to Just start And let me just show what I'm having here I just prepared the very simple presentation here. So it's a very simple network I don't want to go very much into the details. I just use it to to start basically everything So what I'm having here In the middle in the meantime, it starts what I'm having here. I just basically what I want to do here Let me just go back to my sketch pad Uh, I just want from bob To send some money to eat to alice So that's our use case in a second Hashtime of contract. So I want to send some some hyper ledger fabric token From bob to alice And then this gets to an intermediate state and then basically If I commit Then this transaction will be fully executed. Uh, and if I revert then bob gets actually these hyper ledger fabric tokens back So, uh, something is not right. So I hope it will work eventually Just a second. This is the Classical demo effect So what's gonna happen here, uh, I will have some comments, uh, which demonstrate that kind of stuff First, I will just get the balances of alice and bob Basically, again, it's a very simple command. It's get balance and I have just the id it's bob So basically that's the account for bob. I have the id as alice. That's the that's the account for alice Uh, and then first I will mint mint some token So I will mint like 100 tokens for alice and I will mint like 200 tokens, uh for bob at the moment After minting tokens, I just again get the balances again for bob and alice Uh, and then after that I just create a classical transfer So classical transfer looks that way. Uh, I just want to send some some some Hyperledger fabric tokens from bob to alice. It's just 50 token So after this step basically bob and alice should get like 150 and 150 tokens And after this step, I will execute a conditional transfer And conditional transfer looks that way that I will send from bob to alice 50 tokens, but in a conditional way That means that I'm having on the one hand basically A hash of a pre-image password This is actually not exactly the same hash It's it's the hash of password if I'm not mistaken And I'm having basically a time value as well. This is here a normal time at the moment So basically, uh, this Temporary transaction this conditional transfer can be executed with the help of the of the Pre-image of the hash and up to Up to 2022 basically So that's all and after having this stuff first I should get Basically a time lock which is a complex structure written in the written in the In the blockchain and I would expect something that bob getting like 50 50 tokens less But alice didn't get this 50 token So this 50 token in a temporal state and after that I will commit basically this explicitly this This transfer this htlc So what I would expect that actually alice gets this 50 token that was in a conditional state previously So let me take a look if it works and then it looks much better So I can I can show these steps basically up and running as well So the first step is bob and alice both are having like zero tokens So the first step is that I mean like 100 and 100 tokens or 100 and 200 tokens for alice and bob So basically after this alice sorry bob having 200 tokens and alice having 100 tokens After that, I just make a classical transfer Where bob transfers 50 token to alice So getting the balance basically both bob and alice having like 150 tokens So after that, I just do a conditional transfer Which is basically the htlc. That's the hash time lock contract with two conditions with the hash and with the time lock and both send basically 50 tokens but conditionally So it means that first there will be a time lock a hash time lock That's registered in the hyperlager fabric blockchain And after that it looks that way that the account from bob was decreased by 50 But basically this money didn't arrive to alice. So it's in a in a temporal state in an htlc contract So what's gonna happen as the last step? I just commit this step Here actually the the secret was password itself And that was that was the hash that I that I that I gave in Uh, I don't do not have reworked at the moment, but I mean, uh, it's in the code So you can you can make a look you can take a look so basically like Like executing this commit. Uh, what's gonna happen is that bob having 100 but alice having like 200 tokens So basically the plus 50 tokens Right The apple alice That's a simple htlc implementation are basically on hyperlager fabric. Um, I would stop here perhaps for a little bit if you have some questions, uh, some Short questions, uh, and then and then I would just Continue with one more. It's gonna be like 50 more minutes probably how you can build up like atomic cross-chain spots between like these two Hashtimes of contracts Yeah, uh, David. So, uh How it is different from the centralized way like previously you were saying, uh, we have one ethereum and bitcoin Block chain network. So and there's a one third party e so that's uh, we are sending ethereum to e and again It's sending some ethereum converting the ethereum to Uh, bitcoin not converting like he's taking ethereum and if they're having some bitcoin again He is sending that bit um that value of bitcoin to the bitcoin network So Here we are doing the same. We are having one Converter we are sending some transactions from ethereum to that converter and again that converter sending the transaction to the It uh, hyperlager fabric So how it is different from the previous So, uh, uh, I will answer in the in the next next session this question. So based on the two Two htlcs, uh, we can build up an atomic cross-chain swap and that will be that will be non custodial So It will it will work without a without a central party without the central trusted party. Yeah, got it. Thanks The htlc is basically the building blocks. It's like, you know, I mean the cryptographic building blocks of of doing something It's like you need you need a cryptographic hash functions function for a lot of things Uh, but itself does just like a cryptographic primitive So in this sense htlc is basically a kind of an algorithmic protocol cryptographic primitive, uh, that can be used to build up cool things No, I was just asking it is centralized or the, you know, distributed that new way that uh HLTC it's a centralized or it's a distributed So, uh, I mean htlc is is just kind of a concept running on a blockchain It's still not it's decentralized because it's it's on a blockchain basically Um, but the idea is show the protocol in a second basically and and and you can see Uh, how it works, uh, without the central, uh, without the central, uh Uh, counterparting Okay, got it. Yeah so The not to just color basically this protocol because I mean, uh, as I see We we got we got already the questions related this one So what we want to do we want to build up this atomic cross-chain swap. Uh, we don't have the htlcs And this is how the protocol looks like. Um, it has four steps So first Alice creates creates basically a secret password and then What she does she creates a hash of this password Which is actually the lock itself So password is like the key and then uh, then hash of the password is is like a lock and She sends this information. I mean the hash itself And the and the time lock to Bob Uh, so basically, I mean she sends the the hash of the password And they somehow agree in a time lock as well So basically, uh, let me just perhaps, uh, show it on the screen What we want to do Is that we got here either etu and We have here high privilege And what we want to do this is Alice And this is Bob And here this is Bob And this is Alice And what we want to do is that uh, Alice wants to send some ether to Bob And Bob wants to some send some Some some high pleasure fabric tokens to Alice on high pleasure fabric And we want to somehow reach or achieve that these two transactions either happening I mean either both happens or or none of them happen. So that's that's what we want to do And the first step is that Alice actually Finds out somehow a password And the hash of this password And what she sends and and extra time lock as well So what she sends for for Bob Is this the hash of the password So again, it's important here that actually Alice Is uh, Alice knows the password. So she knows here the password But Bob doesn't know the password But she sends actually the hash of the password and basically the time lock for Bob So that's the first step the second step both Alice and Bob creates an htlc Uh with the parameters So htlc requires the hash lock and basically the timeout So what they're doing is the next step They both creating uh this This htlc So money transfers to an intermediate state With like two conditions again. One is the hash of this password and the second one is the time lock And both does the same one. Uh, sorry, but we but with high pleasure fabric. So what he does He creates this intermediary state Uh But with like two parameters one is the hash of this password and the second one is the is the timeout itself So that's the second step and the fourth step. Uh, it looks that way That you know, I mean whoever knows the password Can execute the function. Uh, so that's what happens. Let me just Change to green So in this example, basically Alice initiated the whole atomic cross-chain swap So she knows the password. So what what she can do is that she sees that there's basically Or an htlc that can be executed with the help of the password Bob doesn't know the password itself. Only Alice knows it. So what Alice can know She can basically execute this transaction with the help of the of this password Okay, so that's that's what she does. Uh, that's the next step. Okay But basically it looks that way, uh, it has to be implemented in a way that as soon Alice, uh, basically Commits this commits this transaction. Uh, this with the password the password itself is revealed Okay, so if we can take a look both in the in both in both implementations So basically, I mean, I mean in ethereum everything is basically public So if you if you have a transaction with the secret hash, it will be revealed In a better implementation, I even have basically An even uh, that publishes this password basically Um, same is in hyperledger fabric. It's just a little bit more complicated. But anyway, uh If I just commit the transaction what I'm gonna do Is that I commit the password uh in an even so I just publish this password in an even so this this password can be seen I will discuss the problems of that. But anyway, uh in the normal way, this will be Seen basically so what's gonna happen is that Alice knows the password She goes to hyperledger fabric commits this transaction, uh with the password So basically it means that Bob will know the password as well because this is the password So but what Bob can do, uh, he can go to ethereum There's here basically an htlc with that was created like with two parameters One is the timeout and the second one is the hash of the password So what he can do, he can basically Activates and commits this transaction as well. So he will get the ether And that's what we expect basically at the end of the happy case that we say that this is the happy case Alice committed the transaction in hyperledger fabric So she gets the hyperledger fabric token the public the password is revealed So we do have of the password Bob basically commits the transaction on ethereum So basically at the end of the day, both transactions are committed on both ledgers Okay, so that's the happy case We got a set set case as well So what happens if like, you know, I mean, at least at least do not She doesn't want to to to to have this transaction for some reasons So she doesn't commit this this part of the transaction Then what's happening is that basically the time lock expires and as soon as the time lock expires basically The this htlc this hash time lock contract is reverted. So the same is going to happen in ethereum If the the action is not activated It's if it's not committed then the time lock will be expired and basically The transaction will be reverted. So that's what we have wanted to achieve It's a protocol that makes sure that either both transactions are executed on both chains Or none of these none of these transactions are executed in none of these chains. So both are reverted So that's an atomic cross-chance lock And then protocol like like here Pictures but I think what I'm having here was perhaps a little bit more Visualized. So basically this is what happens Both part is doing an htlc, which is this decentralized s2 in a way And then basically Alice knows the password So she can actually activate the htlc that was initiated by bob on another chain And then as bob sees the password he can basically execute fully the the the transaction on ethereum And then it means both transactions will be executed That's the happy case and the unhappy case is that for some reasons, I mean, I mean the htlcs are created But for some reasons, they are not fully committed because I don't know at least goes offline So you can imagine like here that at least goes offline for instance So she doesn't activate the password on hyperlager fabric And then for some reasons it's she's just not activated So it means that basically the time lock will be expired and then all the funding gonna go back basically to the to the original initiator So that's the atomic cross-chain swap Between between two two ledgers With the help of the with the help of the code that I shown You can actually make it. I mean, I can do it Very fast if you feel like but perhaps I would just have some practical considerations Before before showing the demo So this is the theoretical way of of doing like atomic cross-chain swaps between hyperlager fabric and and ethereum or between any Any two blockchains It's important to note that it's not so straight If you do it between ethereum and hyperlager fabric, there are some tricks actually that you should be aware And then there are some general tricks that are not related to fabric So like usually it's not the best idea to to implement it on your own Such an hglc unless unless you do not have any other chance So basically there's like like erc standards for that That are pretty much a little bit like work in progress, but like for ethereum, there's an erc standards. That's the erc 130 There's no such thing for for for for hyperlager fabric as far as I know So that's one thing if there's already something implemented. It's just better to use it The other one it's it's important to know that I mean this algorithm Work works pretty well if you transfer tokens Because I mean there's there's an assumption and that's an that's an economical assumption That both party want to get the token So it's it's better if if I have ether than if I don't have the ether It's better if I have the bitcoin then then if I don't have bitcoin It's better if I have the the hyperlager fabric token than if I don't have this hyperlager fabric token But it's important to know that's an economical consideration So it's it's it's usually valid for for such a tokenization stuff But it's not necessarily valid for any transaction So like even if we have token Just imagine that the token is is not money It is not ether or bitcoin or or something positive But like getting the token is something negative So like if like getting the token that is like, you know, it's it's like a penalty for a for a driving Or a driving license penalty point or something Then it might not work so well because I'm not really interested of of getting an additional Pity point for my driving license So I have here like opposite economical interest then then getting ether or getting bitcoin or getting something positive Token in hyperlager fabric So that's important. Uh, it it must be Take That this is a crypto economical protocol and it has some economical consideration as well and the economical assumption as well Is that I mean getting this ether or token or or fabric token is something better So it's it's better if I have it then if I don't have it basically That's the second one and the third one Is basically so the point is that hyperlager fabric is a consortium blockchain Which means it's permissioned So hts is an atomic cross chain swaps work pretty well if you have like public blockchains But it might be tricky if you have consortiums consortium blockchains And the point is that if you have permission ledgers I mean the system might be tricked a little bit So for instance, you have to make sure that if this passport is activated here then then bob needs to Needs to have needs to have the rights to read it So as it is a permission ledger, uh, there might be some attack that you know, I mean Somehow makes sure that both doesn't have the access anymore to hyperlager fabric She just activates this transaction with the with the passport. Bob doesn't see the passport anymore So he he can't really actually execute the the the transaction on ethereum So it's not always happens. It depends where you start this transaction, but there might be Tricky, uh, if you have one ledger as a consortium one if you have both ledgers as consortium ledgers It's even more tricky So it has to make sure make sure that the the parties I mean the right of of reading out the informations for the parties are not revoked in the mean in in the middle of the protocol and a lot but last but not least there can be some uh, some timing issues between the different Blockchains as well that must be implemented carefully So this is the basic idea. So I would stop here and then I would just Try to have uh, answer the questions uh, again This is the basic idea here So, uh, is there any specific values there like if uh, alice sending a hundred ether to bob So how much? Happy the fabric token bob needs to again sent to alice. So is there any link between them or Like for some amount of ethereum, how much amount of happy the fabric token needs to be needs to be shared So, I mean I mean regarding the value with It can be somewhat negotiated. So like you know, I mean, it's this is like hundred ether and On the high collager fabric. It's like, I don't know two tokens Who will define that who should you find it? Who will define it? It will be it will be divided by the participants So as you basically, I mean as alice initiates basically the this whole protocol But you know, I mean bob has to agree Uh, so they they have to agree in the in the in the hash of the password and in the time lock as well And they must agree at the beginning In the exact value exchange as well So so they must agree that that okay one transaction will look like in one chain that I have I have I have hundred ether and the second one will look like that. Okay. I have two two tokens So they they must agree at the beginning As they as they exchange these two parameters What's the what's the exact value value exchange? Uh, that's one way actually a as fun as I know there there might be some Some protocols as well, uh, that try to The try to integrate, uh, hdlc with with like, uh, with like decentralized exchanges And in in that sense, there might be but it's you know, it's it's way more complicated But this, uh, valuation might might not negotiated by alice and bob But might come from from a from a decentralized exchange somehow and then they only have to agree It's it's possible, but you know, it's not part of the the atomic cross-chain swap Atomic cross-chain swap itself a protocol that can be integrated So if you have like a decentralized exchange that makes some kind of an order book matching, for instance And based on the order order book matching, uh, saying that that the current valuation of of two token is hundred ether And it's it's okay for both parties then this valuation might come from a decentralized exchange, for instance But again, it's like a a little bit more complicated use case Is it is this use case is applicable for supply chain? We can implement in supply chain So so supply chain is tricky, uh, and the problem is with supply chain. Um, so so so as you see, I mean I mean what you see here basically is that these these assets exist fully on the blockchain And then as they as they exist fully on the blockchain This is simple, uh, because you can have this uh this intermediate state If you have if you have supply chain, uh, you can have some more consideration Because I mean if you have supply chain, then usually Your two tokens is is something tangible So it's like two physical containers Okay, so you want to do kind of an exchange that two weeks to two physical containers Are exchange for like hundred ether? Uh, so you can model this intermediate state, uh, of course in the blockchain in hyper ledger fabric But of course the question is what's gonna happen with these physical containers So I mean if you have supply chain, uh the trick, uh, what must be called Is that you got some physical goods and then I mean Perhaps you have this intermediate state in the blockchain But it's the question is if the if the if if this intermediate state Can really be interpreted in the physical world as well So like you know, I mean you got two containers So how you put two containers into an intermediate state? Uh, it's it's probably not uh, not the most trivial question Yeah, I got it. You got it. Thanks. Thanks, Daniel Uh, so let me take a look on the questions Who's going to call The the smart contract When the time out when the time When the time is finished for the for that for the For the defined time is out So always Yep That would be it's called as what you should be called by the website Yeah, so so it should be called by Uh, it's simple. Let's just imagine this situation that this password is not activated. So Something went wrong. This password is not here. So what's gonna happen is that that we have here basically are these these This intend. I mean this like hundred e-tor which is in an intermediate state So Actually, anybody can call this contract. So anybody calls this contract with a reward function Alice gets back the money So it might happen that we have some some centralized stuff working Or calling this function, but it's not necessary. So Alice It's her it's her own interest calling this function and reverting the money because I mean if if she reverts She gets the money back very simple, but actually I mean anybody can can call it But usually Alice who calls it because she wants to get the money back And similarly here, I mean we get some hyper ledger fabric transaction Some in an intermediate state some tokens So supposing it has value Then of course bob wants to get this value back And then bob gets this value back if he calls this reward function So he will reward this he will call this reward function But again, it's not necessary. So theoretically anybody can call this reward function But you know, I mean, it is supposed that those Who will profit from it will call it For the hyper ledger contract Alice can tell you How to call it immediately? She has to have access to the hyper ledger network Yeah So so that's right. That's correct. So again, uh, basically, uh, so So that's that's one of the that's one of the things uh, seeing that that want to be that must be actually, uh, that one that must be Considered if you have like hyper ledger fabric network. So so one one thing is basically It's a permission ledger. So we got like read access and write access and then So one problem can be if like Alice Alice really is the password here commits this transaction And then basically before committing this transaction. She just drops out bob somehow from hyper ledger fabric That's a problem The other problem might be if the transaction should be reverted But before reverting the transaction somehow in the meantime, uh, bob bob access will be will be denied from the network So yeah, um, the algorithm works well if if basically Uh, I mean the access rights of Alice and bob Will not change in the middle of in the middle of the protocol That's uh, that's what's tricky and then yeah, we can say that I mean if if we have hyper ledger fabric It's it's not a totally trustless solution It's just because hyper ledger fabric is is not totally trustless. So it's like a semi trusted network So if we integrate like, you know, a totally trustless public blockchain, which is which is semi trusted blockchain um, then Then for the first for the naive implementation what we get is not a totally trustless But it's kind of a semi trusted atomic cross chain swap That assumes that in the middle of the protocol The access right of the parties in hyper ledger fabric will not change Daniel um to to protect against this attack Is it is it an idea that uh, you play with who which of the two parties starts the transaction? meaning is there an importance to either start on the on the the semi uh permissible Blockchain rather than on on ethereum or the other way around That's a good point so So you can you can protect Until so if you if you start from hyper ledger fabric Then then you protect you protect against one you protect against one attack Because if you start in hyper ledger fabric, then basically both book finds out basically the the password The hash of the password and the time and he sends it to ellis So it means that the first step of revealing the password Happens on ethereum. So it means ethereum is always public So so it protects again this this kind of attack against revoking the the read write of a party in the middle of the In the middle of the transaction Uh in the middle of the protocol I'm not quite sure if it if it protects against the other part of other attack as well So it's like if if like bob wants to revoke the transaction but before After creating this htlc But before before revoking before having the possibility of revoking the transaction if his axis is revoken I mean if he can't can't access anymore to hyper ledger fabric. It can still be a problem Okay, thank you, but but you're absolutely right So if we start from another direction Then then then revealing the password happens on the ethereum and and you can't block Basically ethereum So any anything happens on the ethereum is public. So it will be seen. Yep. Yes, exactly. That's fine. Thank you So let me see the chats I'm not sure where we where we start but So question if It is any of the importance which is where this starts Yeah, so that was the question that I that that I was investigating a little bit. So normally in In in an atomic rush change swap between two public blockchain. Uh, there's there's no importance who starts first if you have one, uh, one, uh consortium ledger, uh, then then It's usually better to start on the consortium ledger Because then your password is revealed on a public blockchain, which which can't be So which htls in its shorter timeout the one created by Bob in this case, since then it's not the password so the, uh The one then executes first. I think that should be the That must be the the the the shorter timeout Uh, I should think it over at the moment. I just I don't have like ready answer it. It can be just a problem are that it should be taken care that you got like two blockchains So the time is is is never the same on the on the on the same blockchain So even if the if the time lock is agreed Then it might be a couple of seconds delay between the two that can be had actually In some cases and I should think it over. Uh, but if you have the the the right order Then there's no such, uh, hacking possibility Exploiting the the delay of the time, uh, the delay of the times Can Bob check to see if Felice actually sends then either Or could she send less than finds finds out later. Yeah, so so the basic basically they can check everything So on the ETU everything is is public. Uh, so If you just go to remix, uh, if we start such a contract This contract is visible for everybody. Um, so it looks that way I mean even the code itself can be seen and Usually, uh, you know reviewed but it can be seen that, you know, I mean it's from Alice It's to Bob. Uh, so basically the the addresses can be checked. The balance can be checked It's zero at the moment, but if it's like five meter, then it's five meter. It's if it's teneter. It's teneter and so So again, it's more thinking on the hyper ledger fabric Hyper ledger fabric assumes, uh, for for such a use cases that if you want to review basically Your code then then it must I mean you have to have the access, uh for your for your hyper ledger fabric network Uh, if it is revoken, uh, I mean if your access is denied in the middle that that might be a problem Uh Yeah, sure. I mean, I mean the video will be available. Uh, and then basically Everything will be available. Uh, my code and then My slideshow and everything will be publicly available Uh, you will find it both in both in youtube I will link it just just under the youtube presentation and I will link everything in in meetup, uh in meetup as well I have a question, please Uh, can the tedium contract, uh Call hyper ledger fabric, uh Immediately without radiator Uh, which contract, uh Yes, so, uh, so you mean that like the So like the the contract execution of hyper ledger fabric It's much faster than in ethereum. I mean the processing time of hyper ledger fabric transaction Is like, uh, three to three to six, uh, seconds I mean the it's like more complicated a little bit. Uh, then like, uh Then like, uh ethereum. I mean the whole the whole consensus algorithm is more complicated Uh, but it's much faster than ethereum. Uh But I guess you mean something if the transactions can be front running front run Uh, and then yeah, it's a good question. I mean if there's a front running attack for the whole system Then then probably you can do it for the first time against ethereum Um, I'm not quite sure if there's attack, uh, uh in for front running But there might be But I don't think it's very critical because uh Yeah, so so what happens if you see the transaction before Before getting to the to the network, uh, so you can't double spend, uh You can't do anything before so you can't river before your time lock expires It can be an issue if you If you put your transaction to a network very fast before Before the time lock expires and there's there's this kind of a front running attack I'm not quite sure sure so so there might be some kind of an attack But again, so so hyperlegia fabric is faster than ethereum It's like three to five second of of processing time And it's just not so easy to see the transaction than in than in ethereum I'm not quite sure if I if I understood correctly, but so so there might be the possibility to to have here centralized components generally uh But again, so the point of the algorithm is that it can work in a fully decentralized way as well If you want to some put some some centralized server in the middle And then start the transactions from a centralized server Sure, it's possible. Uh, it's again, it's just uh, so that's the main not the main idea of the of the whole protocol so I don't know if I have any more questions or Basically, I'm not quite sure if I have the youtube Link, there's the youtube link. So just give me one minute and I will try to Start the youtube version And perhaps we're gonna have some Questions in you mean idea of the of the whole protocol Yeah So we're gonna have the youtube version and there's no question. Uh, which looks great So So then do we have any more questions? So if not, I would say I would like to thank you very much for the presentation And for the for the for the for the audience For for hearing my presentation Actually, uh, you can find the code and and everything on on on uh, I'm gonna post it I didn't show actually the the exact atomic cross-chain swap But based on the to hash time of contract, I think it's it's it's more or less real I will also Also put it here. So in the read me file How you can play a little bit with like With like an atomic atomic cross-chain swap between the two two examples code and then then you can actually take a look So again, then if there's no more questions or comments, then thank you very thank you very much for everybody and then Yeah, I don't know Just some final question Can the ethereum contract called the outside world or attempt to to read information about the From the hybrid fabric contract So so the point is with ethereum that you can't really call external you can't You can't call actually external. So we got an ethereum network. That's our smart contract And basically the smart contract can call outside word So this is like the ethereum smart contract If you want to import information From the outside world what you have to do is to have an oracle And it can be a centralized or a decentralized or equal Structure. So this is like the outside world. I don't know how to so this is the word outside of blockchain This is the this is an oracle Structure, it's like I think chain link. It was like or equalized perhaps a couple of years ago So oracle is responsible for reading outside the data oracle In the world and then having this information in your blockchain. That's for ethereum It's pretty much the same in hyperledger fabric as well. I mean in hyperledger fabric, you can theoretically call outside the Outside your chain codes. So as far as I know or even in the one point one point three or four version Or perhaps two version it was still possible I'm not quite sure if it's about the two two version But I mean it was possible for a smart contract for a chain code In hyperledger fabric to call call outside And like call a call a call an api or a web service or something But it was it was very strong and anti pattern And the reason is for that because if you did such a things and Usually you got like inconsistent data, which destroyed your your whole consensus So in ethereum, it's not possible to call outside in hyperledger fabric theoretically. It's it's it was possible But it's very strongly and an anti pattern If you want to integrate like external data into your blockchain, then then you should have some oracle algorithm or structure or Or components it can be centralized or or or even decentralized as well. So it's not necessarily centralized You can have like more oracle Integrating or reading out data from the real world in an independent way Having some consensus here as well. And that's what we call a decentralized oracle oracle structure or algorithm Thank you very much So that's what it looks like so Then any any more questions So if there's there's no more question, then thank you very much again and then Yeah, I don't know. See you see you somehow next time Perhaps I can bring some more interesting presentations in the future