The Nuts, Bolts and Impossibility of Trustless Cross-Chain Communication

Transcript

yeah after stand here can I stand sideways okay hi my name is Alexei I'm a PhD

candidate at the Imperial College in London and I'll be talking about the nuts bolts and impossibility of crushing communication yeah and we're also making a small announcement along just along the way so the motivation behind this talk is quite simple there exist over 5,000 cryptocurrencies which different designing purpose and taking into account all the different communities and use cases and designs it's quite unlikely and it's probably fair to say that there will not be one change all them all so the goal of this talk and the research that we've been doing is we want to find a way to securely communicate across different distributed legends now nowadays the best way to do this or the most simple way to do this

is through centralized exchanges but I think we can all agree that we've seen as history of theft and loss most related to failures of centralized providers so recently over the past 1 or 2 years decentralized exchanges have emerged which try to provide an alternative to centralized providers but on one hand the ADIZ exchange is not necessarily decentralized but rather noncustodial so users retain custody of the assets but and on the other hand unfortunately as of this day they don't account for a large fraction of the volume in fact it's very small and one possible reason for this is apart from that they're probably harder to use the transfer as exchange 'iz is that they're do not operate cross chain so you can't really

trade bitcoin or like you know set cache on the central exchanges yet and essentially that's where we come in so I'm happy to say that we launched a company called interlay which essentially the goal of interlay is to allow users to access any asset on any platform and this basically all started off as research so we've been doing research for the past three four years focusing on blockchain security and into probability and we actually managed also to publish papers at top three security conferences which is a challenge itself because people in academia tend to be very skeptical of abduction topics and yeah we've been around giving workshops and talks at various developer and community conferences and as such all of these kind of effort and research for

the past years and to announce that we're the team who is going to be building a poker bridge to Pokhara Bitcoin breach the baccarat and the idea is that you'll be able to move bit compact assets on into the pool called ecosystem in a truss minimized manner so we have a 200-page spec online which describes in detail how this visual work and we have a kid live repository which you can follow now so what are the steps we have a specification and we're currently in the progress of building the bridge in rust and substrate and we're revamping our efforts to bring bit country theorem as well so we had a first proof of concept for a bridge - bit from bit country theorem like one a half years ago but

being academics we did not push it further so we're actually now moving into practice so yeah and what we want to do is I mean in the long run our goal is to allow you to access financial products for Bitcoin specifically the idea is that you can use Bitcoin with the centralized exchanges with lending protocols stable coins and actually will have an inbuilt way for you to earn interest on your Bitcoin if you integrate them in other blog chains cool now folk back to the tech the talk is split into three parts so on one hand we'll talk about cross chain communication and give an overview and then I'll argue why it's impossible to achieve this without a trusted third party and then discuss how we can circumvent this result using incentives

so essentially the concept that made Bitcoin work and practice so this talk and the research I've been doing is based on two papers so exclaim and we have a systematization of knowledge so it's a survey on the entire field of cross chain communication and we provide a framework for people basically to design your system so you can choose for each step of the protocol what you want to use essentially so across blockchain communication I mean so the this problem is not necessarily new and it relates back to the non-blocking atomic commit problem which has been researched for at least 30 years by now and the idea is back then where we only had databases we wanted to synchronize and move

information from one database to the other and you typically assume that you have an administrator which you trust and your main problem was that weren't a database may crash and you wanted to make sure that your updates across multiple databases are atomic so you basically need to make sure that you're resilient against crash videos now in distributed Ledger's we have a different problem apart from crash videos we actually have actors who want to behave maliciously who want to try to steal your money potentially so we need to account for bits and tiin failures which makes this quite bit more complicated than just moving information from one database to the other now I'm sure all of you have heard about you know interoperability and different startups and platforms offering these services but if you think about the different use cases the most

famous one are exchanges and transfer of assets across different platforms however there is also less known applications to crushing communications specifically one of the ones that's going to be quite relevant in the future is charlie when you shard a system and separate or distribute the domain and the responsibility for dates and specific application across different shards you still need to be able to communicate across them and there's a famous problem here that's quite popular and it's well often cited in the film community it's the Train and hotel problem and imagine you have an application on one shard that allows you to book a train ticket and another shark is responsible for Hotel platform but you want to make sure that you only get your train ticket if you actually get the hotel and the question is well how

do you ensure that if you fail to book your hotel that you actually also don't pay for the train ticket because well no point of going there another case which is probably even less known is bootstrapping and migration of blockchains so the first use case for cross chain communication was actually emerged mining which was launched in 2000 in 2011 and allowed namecoin to use Bitcoin security model and bootstrap on on that so essentially namecoin miners and participants would include a piece of data in Bitcoin blocks and this way checked that name coin is leveraging petkins prefer work for its security and finally a term that is often misused are side chains typically people refer to

side chains as a concept for interoperability in general what we try to use it for is extension of features so if you have one system a parent chain and you want to for example add some additional features to Bitcoin but you use Bitcoin secure model or use Bitcoin as the native acid in your system this would be considered a site in our model but again the definitions here are not coherent now being an academic we like to define models and you know build systems from scratch so if we talk about cross chain communication we assume we have two distributed Ledger's or block chains both both of which have consensus committees so essentially we misuse the term committee because we know the Bitcoin and aetherium actually have a

random leader election process where we sample one leader each round from a dynamic set but essentially in for our case we can just assume and say it's a committee now we also have two participants Alice and Bob and Alice's and Bitcoin Bob Pisani theorem and then there's we have two transactions and let's assume transaction TX one in blue is owned by Alice so only she can broadcast it and it's a bit conscience action and transaction TX 2 is a theorem transaction which is controlled by Bob now in crushing communication we try to solve the problem where Alice wants transaction teks 2 to be written to aetherium and she knows how it so she knows how exactly texture looks like and vice versa Bob once at transaction 1 is written to Bitcoin now this seems quite

abstract but their goal is to synchronize this so essentially either transaction takes one antiques two are both written to Bitcoin anything respectively or none of them are and to make this a more practical accessible you can imagine this as an exchange so let's assume Alice and Bob are performing I want to perform an atomic swap Alice will receive aetherium if she gives Bitcoin to Bob now and the argument that is that well it's impossible to do this I mean I so in my PhD my goal was to actually find a way to do such a swap without a centralized provider and well after two years we figured out well you cannot do it unfortunately but what you can do is use incentives so let's again so basically so we proved that you cannot achieve

cross gene communication without a trusted third party and I'll try to lead you through this process of how we actually prove these things in academia and then give an intuition about the result so we like to define properties so we say we have three properties for cross stream communication one is effectiveness which basically states if everything is fine if Alice and Bob won't to perform the communication or the exchange well both transactions are valid then we can actually trigger the communication protocol then it can be executed and next we want to reduce the set of possible outcomes to the ones that are interesting to talk to us specifically we want to ensure that neither Alice nor Baba left at a disadvantage this means transaction takes one antiques two are either both included or none of them are and finally we'll need

a lightness property to ensure that the protocol progresses at some points and on this participant will at some point write a transaction to the blockchain if it is valid and essentially what we do is we show that crossing communication is as hard as fair exchange so if you actually manage to solve the cross chain communication protocol without a trusted third party you essentially have solved fair exchange but the fair exchange problem is a very old thing and it's known to be impossible in fact there's a paper from 1999 and even older papers discuss this that you cannot solve this problem and you need a trusted third party to achieve a fair exchange protocol now what we do in our paper will provide a reduction so I will not go into the details of formalisms and so

on but rather I'll provide try to provide an intuition and explained with examples why this result actually holds now let's go back to our user scenario and assume Alice and Bob want to exchange Bitcoin against ether and now we'll make our model a bit stronger sorry weaker actually because we introduced a smart contract and aetherium which can now enforce correct behavior of Bob so we assume that Bob Lux is ether or transaction t2 with the contract and essentially if Alice sends Bitcoin to Bob the contract will force Bob to release ether to Alice so essentially the theorem consensus participants will enforce that the exchanges execute and I've come aetherium so the idea is that once committed Bob can no longer misbehave so Alice will send bitcoins to Bob on the

Bitcoin side and then the question is what happens next and essentially Alice would now or Bob would have to prove to the theorem consensus participants that the Bitcoin transaction actually happened and this is exactly what the impossibility result comes in to be sure that the exchange is always executed successfully we need to assume one of two things either we assume that alice is always online and self-honest and will basically submit the proof to the smart contract on time and we need to assume that the communicate network is synchronous so we know that the message that alice is sending will eventually be delivered within a certain known amount of time so let's say one hour so we know if Alice sends a message to the contract within one hour the contract will actually see it and finalize the exchange the other

option is that we have a trusted third party that does this for Alice so there's someone who is online and honest and that will basically tell the contract ok yes Alice sent Bitcoin to Bob please release the ether to Alice and if we think about this more in more detail we realize it's actually the same thing if Alice has to be online and the network is synchronous she becomes her own third party because she is obviously self-honest and if we assume in our protocol that Alice will always be online and finalized it's essentially the same thing as if we're students someone else being Alice in the third party so the main challenge of cross chain communication actually is selecting a trusted third party for your protocol and essentially this depends on what the participants agree on this can

be Alice and Bob and you assume that both are online at the network is synchronous or you can use an external party or committee so I've shown it here in the center and this can be a single user it can be a committee it can be a thousand of users which vote it can even be a separate blockchain which is able to verify Bitcoin and aetherium if we agree on it we can also ask the Bitcoin combiners to actually take over this role and be the ones to prove to the theorem contract that Alice behaved correctly or vice-versa we can we can ask the team consensus participants to do this for us and that they check the Bitcoin transactions and finally something that's been coming more and more our so called watchtowers or optimistic trusted third parties and the idea is that you have a hybrid protocol

where you first allow users to try themselves but if Alice crashes then there's a third party that will basically take over the role and make sure that everything goes right and in the paper we basically provide a framework for like showing at each step of the crossing communication protocol you actually can take a different party and it this allows it to either evaluate the existing protocols or if you want to design a new one based on your use case and model you can select the right basically pride principles and plug them into your protocol now something that we hear quite often is well what about trust atomic swaps because these are trustless for a trusted mechanism to exchange assets and essentially yes it works in theory but it's the probability result still holds

so in atomic swaps via symmetric locks they work for example hash number contracts what happens is Alice and Bob agree that they will lock Bitcoin and etherium with the same locking conditions so essentially Alice generates a secret computes the hash over the secret head and says okay on Bitcoin if this hash is the the secret to this hash is revealed then you can't Bob can take the Bitcoin and on the theorem said Bob does the same thing he says if Alice reveals the secret she can take the etherium and essentially to finalize a protocol Alice spends the ether on the etherium side releasing the secret to the network because obviously otherwise you cannot take the money and then Bob can spend on the Bitcoin side and this ensures atomicity if Alice

never reveals the protocol is never executed no one gets the funds but that's also a problem because if Alice never reveals a secret the funds will stay up stay locked up indefinitely so that's what we need time locks so essentially hto sees introduced this concept where you abort after some period of time so if Alice never reveals a secret Bob and Alice hers herself can actually take back their coins and restore back to the initial state so no one loses money and this is where the problem happens because what what if Alice spends the ether on the theorem side but then Bob is unable to spend the Bitcoin so because we have an a synchronous network his messages are lost or he's simply off line and what can happen then if Bob does not come online and send the

message within the time lock on the Bitcoin side Alice can recover her Bitcoin and what will what this means is that she basically stole from Bob she got the ether she got the Bitcoin and Bob has lost basically everything so either we assume the Bob is online and the network is synchronous or someone else needs to force Alice to give back the money to Bob so a third party and the same thing holds for us my conscious example I mean we did we had this on the previous slides but to recap again if Bob locks is offer in smart contract and Alice has to prove to him that she sent in Bitcoin on a theory on the Bitcoin side then alice is the one bearing the risk because if she submits the proof she will get the etherium back but what if she is unable to send the

proof to the smart contract well then if the time that expires Alice recovers her ether and now she has both Bitcoin Bitcoin and aetherium whereas Bob sorry yeah Bob basically won and Alice lost in the same case here to enforce Bob to behave correctly and return the money the contract would have to know that Alice actually sent Bitcoin to Bob on the Bitcoin blockchain and for this we again it either someone to prove it and in this case Bob why would he prove to the country that Alice bathed correctly if we can steal the money so either Alice's online or we need a third party so I hope this result makes sense I mean if you're interested please have a look at the paper we'll also have a blog post series of the next couple of weeks explaining this in more detail and trying to also emphasize that you can

still circumvent this theoretical result by introducing incentives essentially what made bit firmer through practice and the idea is that while it's possible that parties crash and misbehave we want to ensure that users do not face financial damages so we use collateral and proofs of misbehavior to build the system that incent more or less incentive compatible before we dive into exclaim there's two main groups of cross-chain communication protocols previously we've been talking about exchanges so we are going to swap assets on two different blog chains so you coordinate how assets change hands on to systems and you have a committing abort protocol so both parties first commit you verify that everything is correct and then you either abort if it's not

all you commit them both blockchains but there is a lot of use cases where you don't just want to swap but you actually want to permanently move objects in one system to the other and this is what we do in exclaim so the idea is that we create so-called on chain cryptocurrency back assets so a cryptocurrency fact asset as the name stead states is a token or asset is one to one backed by existing cryptocurrencies so for example we can create bit compact tokens on atheria or on polka rot in as in the previous case and the idea is quite simple the protocols are simple you lock up your Bitcoin you create bits come back tokens you can use these tokens like a give acid which is quite interesting in the user for the use cases because now you can make the centralized exchanges

use Bitcoin you can use Bitcoin and letting protocols maybe with flash loans who knows and when you're done using your bit come back tokens you destroy them and you receive your Bitcoin back sounds simple but to actually build this in practice we have to overcome a few challenges specifically if you want to make the system compatible with as many selections as possible you need to solve the problem of having conditional logs without smart contracts the problem is that we want to unlock the Bitcoin only when the tokens are burnt and destroyed but Bitcoin has no idea what's going on with on the etherium side in fact we don't have smart contracts there so he can't really encode the same functionality as a bit kind of speedy client on aetherium which is possible so the first intuition that we would have is well why don't we

use hash locks and the problem is that you cannot do this because for hash logs to be useful you'd need to generate a secret and a theorem smart contract and release the secret only when the tokens are burned but we know that smart contracts are currently at least publicly verifiable and that you cannot store a secret there because everyone will see at the moment you put it there so we need someone to actually hold Bitcoin on the Bitcoin side and release them on time but there's someone and this is the trusted third party can be incentivized to do this so in our system model we have users which are the participants will basically send Bitcoin to this vaults which hold them until the users are done with using the tokens and then users burn the tokens and receive the Bitcoin from the vaults now votes

are Bitcoin users and essentially anyone can become a vault by locking up collateral and aetherium so the idea is that you don't have to trust vaults for your financial monies for financial value that you send them but you have a guarantee that if they misbehave you'll be reimbursed and this guarantee is given to you by a unchain contract which basically monitors correct behavior of the vaults on the Bitcoin side so if you look at the architecture of exclaim a bit more detail we see I mean it's a quite complex system and while that here is quite easy to understand the practical problems that we face are actually quite vast so on one hand we need an exchange with Oracle because the collateral or that at least at the moment is in different currency

bitcoins in our case for the etherium and then we have a registry for vaults so anyone can register is about by locking up collateral and finally we have the different protocols we also have a replace protocol which allows vaults to leave the system at any time so you don't want people to be forced to stay in an inn exclaim if they want to basically leave and get the collateral out and another very important component is actually BTC relay so this allows us to verify that specific actions have happened on Bitcoin and how this works is it's just like any Bitcoin SPV client that you would have on your phone except that it's encoded in a smart contract so BTC relay accepts Bitcoin block headers and then allows you to submit a transaction inclusion proof which is

basically a miracle tree path so it shows that the specific transaction was included in a specific block and this way because we can then parse the transactions we can be sure that specific but specific actions have happened on the Bitcoin side so for example Alice's same bit going to Bob now this thing has a lot of challenges in practice and if we have time we can talk about this later but let's go into the extreme protocols first so in our system model we have Alice was Bitcoin we have a vault and in this case Alice can be her own vault so it can be the same person there is no restrictions so it's a that that dynamic set and then we have the smart contract and aetherium which is basically the treasure treasure chest up there and we'll the second component called BTC

relay which again allows us to verify the state of Bitcoin now what happens first is that the vault locks of collateral in the theorem smart contract and this collateral defines how many bit comic tokens can be created and the the essential thing here is that we have to over collateralize to account for exchange it fluctuations because we know the prices can change fairly quickly so we need to make sure that if the price changes while the tokens are issue that the vault is not incentivized to run away with the Bitcoin because it will earn more money doing by doing that so what happens next is Alice sends Bitcoin to the vault and then proves that she did this through the DC relay which confirms this to the smart contract which then issues paid comeback tokens to Alice and that's it and the

interesting part about this is that the vault has no is not interactive it can be offline the whole time and the benefit that this gives us is that the vault cannot censor users selectively so once the vault has locked up collateral it cannot prevent specific users from participating in the process so either you participate in this process as a vault or you don't but you cannot block specific users from getting bit comeback tokens now one problem that we do have here is that we can erase conditions because obviously networks can be slow what kind of message delay people can go offline and we have two problems and one hand two participants can try to issue a bit come back token simultaneously for the same amount of collateral and only one of them will have the security of you know if something goes wrong I'll get my money

back so what you and the other problem is that the vault before Alice sends the proof here can try to withdraw the collateral so the vault gets Bitcoin and takes a collateral out and then basically runs away so we have to what we have to do is we have to account for this so in one hand the vault cannot just simply take our collateral but has to have a multi-step process where you first announce that you want to take out your collateral wait until pending requests are finalized and then you can take out what is left and another second thing we need to do is a two-phase commit protocol for the issue requests so before sending bitcoins to Bob Alice must make a commitment to the contract stating that she wants the issue for example one bit come back token and this

locks up or blocks the necessary collateral buy of the vault and then Alice can finalize the protocol however if we do not prevent Alice from you know locking up the vault collateral in but never issuing the tokens you can launch the analysis attacks in the system by simply you know having a dozen of users constantly locking up the collateral of all participating vaults so what we have to do is we have to require Alice to provide some minimum amount of grief and collateral in ether which is then returned to her when she finalized as a process okay something went wrong there we go and yeah once you have your bit come back tokens you can use him like any native asset and etherium so with decentralized exchanges easier payment

channels or stable coins and so on and so on so let's assume Bob then received his sum bit come back tokens from Alice and he wants to actually get his Bitcoin back so what she has to do is he has to lock his Bitcoin and burn them eventually in the smart contract which will emit an event and this is the first time the vaults actually have to become active because the vault observes this event and has to return the Bitcoin to Bob on the Bitcoin side however the protocol is not done yet the vault has now to prove to the smart contract using very similar that it behaved correctly and only once this proof is included in the etherion blockchain only then the collateral is returned to the vault

which means that if the vault misbehaves does not send bit country Bob stole the bit come before or something of sorts Bob will be reimbursed and this means that either Bob Rob has a guarantee either he will receive Bitcoin or he'll receive he'll be reimbursed in etherium plus a premium so essentially this means he actually makes profit when vaults misbehave so he can basically use this aetherium collateral plus the premium to go and buy the same amount of Bitcoin that you should have received and actually earn money on this so the vault has no incentive to steal from Bob as long as the exchange rate is stable and speaking of the exchange rate obviously we need to account for mitigations fluctuations so what we do is we have a multi-stage cauterization

scheme where we predefined sum over collateralization rate so in the paper we say it's 200% it can be higher it can be lower we actually have a paper so my co-founder has a paper of how to reduce this over time and the idea is that as long as you're in the Green Zone everything is fine users can create your bit come back tokens you can take out free collateral however if the exchange rate drops and you fall into the yellow zone well users can no longer issue requests the vaults are recommended either to add more collateral or to ask users to basically execute the redeem protocol with them which means that they free up collateral because bitcoins are returned to users and finally this is not on the slides but the vault can also offer it's the Bitcoin of this holding

as an auction to other participants who wish to take its place as a vault so that's whereby we have the replaced protocol so you actually have an open market for participating in the protocol however if things really go south and nobody is willing to replace the vault or the exchange rate keeps crashing we have an automatic liquidation in place which means that at some point the vault will be forced to execute a routing protocol and either it returns the Bitcoin to the user or it loses its entire collateral so X couldn't give this like again in academia but like to define a lot of properties but essentially what is interesting is that we are guarantee that you have consistency so you only have bit comeback tokens if you actually have the bitcoins locked on a Bitcoin

side and since it's a public blockchain you can always check this you also have a guarantee that as a user you'll get your bet come back or you'll receive etherium and basically not look at face any financial damages and you do not need any third party in that sense so you have from disable assistance perspective you have a third party being the vault but you yourself can be this vault and essentially you can pick about it at random so you don't always have to trust the same person so speaking of so before before like discussing the implementation let's talk about the system requirements so one of our main goals was to make this as compatible as possible with existing systems so while on the issuing blockchain you need smart

contracts like on aetherium so you need to be able to create tokens and verify which is actual inclusion proofs in the consensus of the blockchain that you're creating tokens for so for example Bitcoin on the backing side so in the for Bitcoin we have no restrictions so the only thing you need to be able to do is make a normal transaction obviously if you were to have smart contracts on both sides you could basically optimize the system by requiring even less third parties in the sense so you only have choose my contracts and the vaults become an optimization this does make things quite tricky and implemented on the implementation side because you now need to synchronize to smart contracts constantly so we implemented exclaim for Bitcoin in aetherium I think a year ago

or more and we tested it on Rob's team and initially we use the old deprecated beliefs usually which has been around for quite some time but it fell behind Bitcoin I think over 90,000 blocks so we by now have a reimplementation solidity and what we're doing right now is we're building exclaim in rusts specifically for polka dot using substrate and the proof of concept for this will be online probably in April so yeah so if we talk about the cost so in the case of it theorem would made some measurements and we saw that back then I think the price is actually our amount about the same of what we measured a year ago or even longer it costs your maximum two dollars to issue an arbitrary amount of it come

back tokens and aetherium which is quite cheap and we actually see if we look at the figures at the main delay in the main costs are obviously in the Bitcoin side because that's the main cost factor typically so we also compared our implementation to hoc swaps between Bitcoin and etherium and what we saw is that if you were to issue a bit comic tokens execute a thousand consecutive swaps between your bid come back token and etherium and then return to Bitcoin you will be 95% faster and 65% cheaper than if you were to use HT OC swaps each time and the main reason is that you don't need to synchronize both block chains with each step but you have a slow synchronization process at the start fast swaps and you can even take

these swaps off chain if you use an ethereal payment channel system or a commit chain or some sorts and then you just have a slow redeem process again whereas in haste you'll see swaps you have the setup phase each time so it's a member of this process and you don't gain anything from actually establishing a channel with your counterparty exchanging secrets and so on great so summarizing crushing communication is impossible that I chose the third party but you can circumvent this radical result by using incentives and that's what we do in exclaim and we're building exclaim to bring Bitcoin to polka dots and then later on for other systems we have a lot of papers and links to git repositories so yeah thanks for your attention and happy to take questions

[Applause] well thank you for the presentation and good luck for the end of your PhD I'm sure you will have great success I see a very immediate usage of exclaiming the serum ecosystem is initiative ecosystem we are looking at what we call side chain while you might consider being multiple Ledger I'm in particular thinking of X day and we need to bridge assets like diet between block chains and the question is I guess exclaim could be used for that is it something that you've considered will you build

tuning to basically move assets between the Syrian block chains and also one thing is would it be meaningful and possible in that sense to to back and asset using is the same as that for example I've died on the main net X died on the X ty blach chain and have somehow this whole process being backed by die so let me to answer the first question so yes you can use exclaim for this essentially the always depends on which trust mall you want to have that your Vic's plane was that you have a dynamic set of participants where anyone can become a third party if you have a permission sidechain which has a PFD consensus protocol you can introduce exclaim on top of that but you can also

rely on the beef T consensus participants because you have to trust them anyway for the correct operation of the sidechain so it always depends on how much you want to open up the system obviously if you just want to say okay the consensus participants are responsible for the sidechain consensus but you want to like open up the system what you can do is you can lock up the collapse on the etherium side and basically require the consensus participants on the sidechain to actually even commit to specific state transitions and that's why if something goes wrong they also slashed regarding the second question I'm not quite sure if I follows I mean I can't say I don't know it's it's could be but it's a bit of a complicated process if you want to

back this issuing of this like if you want to back the same asset using the same asset collateral that's definitely possible the question is on which chain do you do this so one of our research projects that we're doing for Bitcoin is trying to figure out whether you can have collateral and Bitcoin site to avoid the whole exchange rate fluctuations so we have solutions for that the problem is that if you need smart contracts on a bit conside for this if you have two aetherium chains yes you can basically have collateral only on one side so in the same asset basically yes the question back there Thanks so my question is you said that if you if we are using hoc contracts

then we need a third party I don't really agree on that I think that it could be done without third party and the second thing is it could be stew incentive if you are using hash time worked contracts if for example when one of the party is trying to abandoned you in the middle entry fund after a few hours or a day they could have some penalty for example to leave one or two percent of the amount that they wanted to exchange and in that way they will have incentive to finalise the process even though it's two-step process so yeah the first question is more important why do you think that you need third party with hoc kind of protocol so I mean it's not that we think it we

prove it essentially so that we show that it's the same it's a threat achill result so you actually have a proof and that it's as hard as fair exchange so it's you can basic so what you can say is that you don't agree with the model the proof holds though and I mean I tried to explain in the example that you I you need a third party I think what is what is a bit confusing in the sense is the word trustless means something different in nowadays in the in the blockchain space compared to what it was used for previously initiative systems nowadays we typically say we're trustless meaning that you don't trust them with your like financial assets and stuff like that and you should be the system's it means that you have some party that will adhere the protocol rules and do exactly what he worked what

it told it to do and then it's online and essentially that's what the result is about I mean if you don't have anyone as explained in the in the hit show see examples if you don't of anyone who will give the proof or sort actually make sure that Alice spends or Bob spends on time then you it fails and and so there is no way around it so either you need to assume that both parties are online which is a synchronous sumption or you need a third party but from principle Theory wise it's the same thing that's that's that the result actually states answering your second question I'm think what you're speaking about is a financial option a financial free option problem so if yes you can add penalties for abandoning HTC's but it still doesn't solve the fair exchange problem so

there's a slight difference between those two fair exchange states that it will either be executed atomically or not at all had a financial free option problem basically stays that Alice being the one who can decide when to trigger the exchange or not she obviously can you know decide whether this is still beneficial for her a bit later whereas bob has no decision yeah I was wondering like the costs of doing these swaps do they include the cause I mean part of the architecture was relaying all the Bitcoin blocks into a theorem right so do these cost kind of include the cost of of relaying all the blocks because I mean if you want to prove

something in a block you need the block headers and all that and I mean in some sense it would be most economical if all possible like relay transactions would be crammed into one block on the Bitcoin side you would only take those blocks right you are kind of but I mean I guess you kind of have to take all of the Bitcoin blocks or do you know the other chain blocks into into your I mean is the cost of storing those block headers and and you know is that that like significant or so we didn't we didn't include to cut these costs and essentially have a fixed cost so you assume that you're approximately funded

44 Bitcoin block headers per day and essentially we looked at this and given the prices back then which more or less represent the prices today it'll cost you around five to ten thousand dollars per year to maintain BTC really which sounds a lot but if it's a copy number company or if people actually this splits up and it's not that high per user ten thousand a year five to ten yeah like what gas price yes the one that stated here oh okay yeah it's five to I think it's ten I just don't remember by heart because we've been doing calculations let's say it's ten let's say it's ten it's still not as high I mean obviously if it's one person who doing this it's quite expensive but if you had a hundred people a thousand

people then it becomes quite marginal and the fact is it's it's fixed that's what it costs you to run this and obviously there are improvements there are so called logarithmic SPD clients which basically reduce the number of blockers that you submit so with but the name is Vivek Klein you need F each and every Bitcoin block header what you can do basically you can use concepts like NEPA powers with super blocks or fly client to basically skip over blocks that you're actually know they're irrelevant for a protocol and we've also been working on extensions to this to basically ensure that you only submit the blocks that you need and not the entire bid convention yeah all right cool if there's any more questions you guys can do that outside and yeah oh and a round of applause for them too thanks

also like our next speaker is Leo nod if you are here yeah