EthCC 2: Alexei Zamyatin

okay hi my name is Alex aim I'm a G student and research assistant at the Imperial College in London and today i'll talk about interoperability with crypto currency backed assets now specifically I'll present our leaders protocol cross-claim we have a paper accepted at the I Triple E SNP conference and wherever code online if you want to check that out now just please don't use it yet it's not completely finished so this is joint work with my colleagues from Imperial College and it's answered by Pew Research outlet ventures and blockchain so the motivation behind this talk is pretty much straightforward right we have over 2000 cryptocurrencies which differ in design in purpose and what we want to achieve is trust less and scalable cross chain communication because we assume there won't be one blockchain to rule them all in the end now I think we can all agree to some extent that we've had a history of theft and loss in currencies and they're mostly related to centralized providers now as a counter-movement centralized exchanges have appeared a super idea however to this state the Dobson is still quite low and most of them only operates on a theorem and use you see 20 tokens so they're not really cross-chain yet so to this date that seems that atomic cross chain swaps with HTC's remain the only mechanism to do cross chain communication and they've been around since 2012 now there must be a reason why the adoption is not that high yet and I will assume that most of you know how HDFC's work I won't have time to explain but the main problem I guess is that all parties must be online throughout the process plus we also need an out-of-band channel to exchange so-called revocation transactions because otherwise our funds may be locked up forever if one of the parties crashes furthermore all parties must monitor all involve blockchains to be sure that they act at the right moment otherwise well you could lose your funds even if the protocol goes correctly and finally maybe a problem more interesting to developers is there is no standardized interface for HDL ceased even in Bitcoin there is like different formats you can use you can also use script or scripts and so on so all in all this is kind of a cool idea it's been around for some time but it's not really gaining traction that at least yet so that you behind cryptocurrency back tassets is very simple that we want to lock up coins on the backing blockchain for example Bitcoin and issue a one-to-one representation on an issuing blockchain for example aetherium and the process is very simple and the idea itself has been floating around ever since the theorem was launched so we locked Bitcoin we create one-to-one backed assets on etherium and then we can actually use them in to make decentralize exchanges actually cross chain to have cross stream payment channels in etherium because essentially then any payment channel becomes cross chain rights and we can use the smart contract functionality of etherium to build more potent atomic swaps now finally when we're done with all these cool features we say we want to go back to Bitcoin and then we destroy the tokens and ideally receive back Bitcoin now the challenge is well Bitcoin has no idea that something like that happened on aetherium which cannot validate the state of ether and yeah so what do we do the first work which comes to our mind is well can we use hash timer contracts and this will be very nice but we can't really generate secrets in a theorem smart contracts which is one problem and the other problem is you don't really know who is going to own the token when you generate the htl sea and bitcoin so what you will have is a race between all people who see the secret and then want to get the bid come back from the Bitcoin side so we do need some kind of intermediary Bitcoin and before everyone leaves the room let me show you how can we can do this trust lessly now yeah so if we look at our system model we have a requester who locks coins and two issues tokens where have the Redeemer who then once they go back to bitcoins and the receiver is quite simple and the interesting part is the vault the vault is responsible for redeeming on on the backing blockchain specifically on Bitcoin however it's non trusted and it's collateralized and the smart contract that is deployed on etherium is responsible for the whole process of issuing trading redeeming basically every action that you do goes through the smart contract and this we can also enforce honest behavior of the vault now if you briefly look at the smart contract I won't have time to go through all the components if you're on have a look you can check out the paper but the most important one and how we actually achieved Trust lessness is the chain relay now for those of you who don't know what a chain relay is a chain relay can be understood as a cross chain as Pedialyte client and the idea is quite simple you want to be able to verify transaction inclusion proofs for under the blockchain on a theorem for example and for Bitcoin there is a thing called BTC really which has been around since I think 2016 now how it works is you submit block headers to the contract the contract checks that the difficulty adjustment is a correct it checks if there's any Forks and then if a user submits a transaction and a miracle path to the identifier of that transaction in the Merkle tree of the block header it can actually verify programmatically that yes this transaction was indeed in a Bitcoin block now there is a few things you need to think about when implementing this and I'll refer you to the paper there's a few sections where we discuss the security assumptions here but what before we continue with the protocols one thing to mention are the system requirements so we know that we need smart contracts on the etherium however the goal of this project was to make sure that we do not need anything on the backing blockchain so basic that we can support Bitcoin and the cool thing is we only need to be able to make transactions that's it nothing else now obviously if we would have smart contracts on the backing blockchain it would with it would make things a bit more practical we could get rid of intermediaries or at least use them as an optimization the question is how do we keep the two countries up to sync and that just introduced a few challenges now let's have a look at the protocols so in the first step we see okay we have the smart contract deploy it up there it's this Treasury box we have the BTC relay and we have the vault and Alice who has Bitcoin and wants to go on a theorem and get her Bitcoin there now as a precondition obviously the intervals must lock up some collateral on etherium and in this case we over collateralize the vault to mitigate for exchange of fluctuations but I'll talk to that a bit later and the amount of collateral the vault locks up here defines how many Bitcoin back tokens users can securely issue with this vault now do note that any user can become a vault so basically anyone who has ether can go and say ok look I'm walking up ether here's a bit can address you can use me to issue bid comic tokens what Alice will do then is she will send the Bitcoin to the vault and then provide our inclusion proof to the BTC relay that this transaction happened in Bitcoin and the BTC really verifies that the this transaction has happened confirms to the smart contract that this is the case and the contract will then issue their corresponding amount of tokens to Alice now notice one thing the vault is can be on offline throughout this whole issuing process as soon as there's collateral locked up in the contract there is nothing else to do for the vault and that means no one can really prevent Alice from issuing these tokens at the moment right so this is a cool feature we have now the only challenge of course is Alice will only want to issue if there is collateral in the in the contract but we do have some race conditions which we need to fix first the most important one is we'll assume Alice and Carol tried to send bitcoins to the vault for the same amount of collateral simultaneously in the end only one of them will have the security of being basically secured by collateral and the other one will have just given away the Bitcoin for free furthermore the vault there's yeah it's not the issue but the vault sorry for that can try to withdraw the collateral from the contract before Alice can finalize the process and this can be done well he can attack Alice with a denial of service attack this can be due to latency and so on now and for this we introduced two simple but quite effective mitigations the first one is that we don't allow the vault to withdraw the collateral instantly but it must first announced the withdrawal in the contract wait for a period where users can finalize their issue requests and then withdraw so users will know that once the vault has announced its withdrawing collateral that it's risky to actually send Bitcoin there and the second one is to prevent two users from racing for this for the same amount of collateral we use collateralized issue commitments and specifically if Alice must first pre commit yourself in the contract to issuing these bit comeback tokens no obviously so the rest of the protocol stay the same however to prevent a malicious user from going to the contract and filling it with orders but never never never issuing we require that Alice provides minimal collateral so if you actually try to attack the contract and block of vaults from being used by people you will have to pay for that now swaps and transfers are really simple and you can exploit the smart contraction allottee with theorem here which gives you quite a big benefits over bitcoin now let's assume when this process Bob got some bit come back tokens from Alice and now Bob wants to go back to Bitcoin so what does he do he locks the bit come back with a contract and the contract will emit an event signal him to the vault that now is the time to send the bit come back to Bob notice that this is the first time when the vault actually has to do something so the vault will observe this event and send back the Bitcoin to Bob and then it will provide an inclusion proof to the Betty cereal a showing that it behaved correctly they so basically will enforce a proof or punishment approach if the vault does not give a proof it will be slashed and in the end then the collateral is released to the vault now obviously as mentioned if the vault misbehaves if it does not react it is slashed and Bob is reimbursed since we have there could be multiple vaults in the system Bob thinking try we can retry the process with another vault now basically what happens move the guarantee we give you is that you either get back your Bitcoin or you will just have executed a quite beneficial exchange of bit Commerce's ether well and then you can buy the Bitcoin again because obviously we will punish the vault from his behavior as well now one thing you probably probably think about is well but what about exchange rates and this is kind of a challenge we have to face so we have to do is we must try to mitigate possible possible exchange rate fluctuations and for this we as mentioned we over collateralize the vault and we introduced a three-stage culturalization scheme where we say for example so I have some example exchange rate example thresholds on the right side so let's assume we say that the ideal over culture is that over collateralization rate is 2.0 that means you have to provide twice the value of ether for the log bitcoin now as long as the threshold is exceeded the vault can withdraw the collateral users condition your assets now let's assume someone has issued assets for the vault but then the price was of ether starts dropping compared to Bitcoin now obviously the smart cruncher will not no longer allow other users to issue new tokens with the vault because the rates is below the ideal collateralization rate and the vault is kind of asked to provide more collateral because if it does not at some point the rate might go so low that the contract will trigger automatic liquidation to prevent users from making a loss and the liquidation can be triggered by the user himself by any user in the system or depends how the Oracle is implemented that provides the exchange rate now the goal here is to ensure that we maintain the incentives for the vault to behave honestly as long as possible and if actually something goes wrong we make sure that the users get their etherium back at least now we have a few properties that we've shown in the paper but I'll just wanna I just I'll just highlight three of them specifically consistency so we only issue the tokens if you provide a proof for the Bitcoin transaction we ensure that you either get back your Bitcoin or the corresponding amount of ether and finally we have liveness specifically you don't need any third party to actually participate and exclaim because anyone can become an intermediary furthermore as soon as in it as a vault locks up collateral there is nothing it can do except try to withdraw it again but in the meantime users can do whatever they want and the vault cannot set to selective users and prevent them from issuing with compact tokens which is a great advantage of a centralized providers now we're implemented exclaiming celerity and yeah we deploy than Rob Stan one thing that we had to do is we use the old serpent implementation of BTC relay which is that serpent is quite outdated so we're working on a new implementation of BT civilian solidity and you can check up the code on github we're currently two people who are implementing this and yeah we're researchers so if you want to help out please do so if you look at for months and costs yeah please do note that they're probably lower right now because we use the slightly higher exchange rate back then but as we can see today the whole process of issuing at an arbitrary amount of it come back tokens performing an atomic swap and in the theory of smart contract and then redeeming them costs to less than $1 which is actually quite nice now we do note something is not in the slides and that's the cost of maintaining BTC really and back at the date we were testing this it costs approximately 27 us per day to keep the relay up-to-date with Bitcoin blocks now obviously the first version of the pity Sevilla was not optimized and the serpent language was deprecated so we can op the new version is cheaper plus the more users participating next thing the less the cost for a single user for the verification costs and we're also working on improving the AC relay with better techniques like finito pals and true flight clients to cut the cost even lower and yeah and I will also compare implementation to h2 atomic swaps between Bitcoin and ether and what we see is that we're actually way faster and significantly cheaper and the reason is that we do the slow set up between Bitcoin and a theorem exactly once and then we can do the swaps as often as we like whereas in HDL C's you have to do the tiresome process of setting up the channel between Bitcoin and ether between two parties each and every time so obviously this is still a first proof-of-concept and there's a few challenges to solve one as mentioned is the feasibility of chain relays so we're looking into off humidification games like true--but and our reach room for example which was presented at USENIX this year sorry last year we're also looking and outcomes by proofing techniques and thinking of how I can combine game theoretic approaches with potential your knowledge proofs will have a fallback if the game basically breaks now we're also working on multi signatures to prevent theft of bitcoins altogether because right now the vault controls the Bitcoin which is kind of a problem you could argue so we're doing right now we're locking working unlocking the assets in a multi site with the user but then there's a few additional steps you have to do in the theorem side and it becomes really feasible if you use option channels so this is currently working progress and finally we're also looking at how to better incentivize the market of vaults and trying to figure out how to get rid of the problem of centralized exchange with Oracle's trying to distribute trust among different providers or potentially in the long term using the rates of bit compact assets against ether as a relational data stores that's it thanks and if you have any questions please do [Applause] we'll serve a short summary of this on our website and we have an e3 search post as well all right thanks thanks Alexa it's really nice I had a couple questions one of them was uh so yeah I mean just in terms of how do you trust the BTC relay obviously that's like an availability assumption also I'm not it they actually verify the proof of work in the relay if I'm correct yeah yeah so the thing is so yeah you do have to kind of trust that the Pitti civil is up to date now since it's a public contract you still you will see if something goes wrong but we discussed in the paper that obviously could launch a poisoning attack or a selfish mining attack on the relay but you could also really could try to prevent users from submitting new transactions but that's kind of difficult because you'd have to censor the whole network but one major problem and this is kind of a challenge would have to solve to make this scalable among different block chains is that we have to verify the proof of work in the relay itself and for example for I script this does not work because it will cost you over a hundred a third blocks to verify 1s scripts but because it's not supported for default so there's been a lot of work for example by Jason torch and down Boni to to get this into bullet proofs so yeah we're looking forward so we're actually trying to work together with them and to bootstrap this ok cool yeah I so you mentioned a verification of the proof of work in the BGA how does it work for a proof of stack protocol these are solutions so we discussed how this could work for prefers sake in the paper a bit but there's a recent paper at S&P as well this year which is called proof of stake side chains which you can recommend you to look at but in principle for proof of stake there is a slight difference so instead of tracking the difficulty adjustment and verifying the book for work you'd have to know when the epics happen of the staking periods and you'd have to follow the stake right so you'd have to know which violators are selected each round the verification then is be easier because they just checked the signatures but yeah we'll have to see how easy it is to implement that but in principle my gut feeling is that it's probably cheaper to do it yeah for proof of authority blockchains it's quite simple because you know the set of the validators upfront in proof of stake it can change right and that's where you need to really be careful so you don't allow our old validator set to sign transactions yeah all right one more question yeah I also want to point out it was really similar the your idea of the vaults they're basically like sort of maked out collateralized debt positions in the sense of like having the over liquidation yeah the over collateralization of basically a promise of like a locked token on another chain and one of the issues I was like wondering I was trying to understand what do you think the the finality time like parameter basically is suitable enough to like yeah sustain itself against I guess large chain reorg so like you know about 100 bucks down the line so this is of course a big problem but it's so we must make the assumption that both chains were connecting kind of operate securely if you want to be really sure you can obviously at longer conversation periods but the problem is for example what happens if a hard happens right then you must update the relates to track the new chain and if you have a hundred block reorge I mean it will break but you'll have other problems as well it's like it's hard to say basically a security model of the underlying chain is broken but yeah it's an open problem all right thank you very much I think we're going coffee break and then we'll be back in 20 25 minutes thank you [Applause]