EthCC 2: Tobias Schubotz

and I'm still Toby I work at kenosis and the Ginoza save and yeah I'm gonna be talking about our where we are right now with the product and also what our plans are for 2019 specifically about our work and research on recovery and death and direction now reynosa safe is any theorem wallet and the first question it always comes up why yet another wallet right there's plenty of wallets out there everyone knows madam asked and there's plenty of mobile wallets out there some of them have their browsers some of the some of them don't some of them are for eutteum only some others support multiple blockchain so why are we building another one well pick Moses save is smart contract wallet for mobile what does that mean well the vast majority of the wallets out there are using externally on the counts that means there's a single private key that is used to make transactions and this comes yeah there's some problems with it for example the user has to make sure to backup that private key to backup there a recovery phrase and so they have to even understand that concept of backups and private keys second there's no option for defining more sophisticated access control schemes so you either have access to everything or to nothing so if an attacker gets ahold of your key they can present basically impersonate you and if you lose your key you also have lost control to everything and now let's face it users are not ready for it right so the internet is full of stories like this where people thought they backed it up or didn't even back it up and now they cannot access it anymore and it's a problem and that is why we believe that the future our smart contract wallets because in a smart contract we can put in more sophisticated logic to prevent some of these problems and why is it even possible well on a theorem as much contracts are so-called first-class citizens that means that generally all features that available for regular accounts are also available for smart and yes so what does make you no safe no different there's three features that are enabled by the fact that my just part no safe is a smart contract wallet and I'm gonna be talking about these first of all two-factor authentication that's something that is available right now in our mobile apps you can download them on the iOS and Android App Store and yes in order to explain what it is let's first have a look at well it's very simplified flow of how transactions are done with externally out with regular accounts on a theorem there's a single key that is used to sign a transaction and then this transaction is submitted to the own block chain where it's executed it means again if an attacker gets this monkey they can do everything with it now with two-factor authentication with the smart contract wallet and in that case the two factor authentication happens on chain there's some solutions that do that off chain but now occasion everything is on chain there's two keys that are required to sign a transaction before you perform lock chain that means if an attacker gets ahold or if one key is compromised you still couldn't do anything with it that also means if at the original owner loses one of their keys they can also not do anything anymore but we get that problem later in our case in case of ignores is safe one of the keys is stored in our mobile wallet and the second key is stored in a Chrome extension which acts as a two-factor authentication device and we also build in a way that this key never leaves the device just to prevent some of the attack vectors that are out there and so there's generally two scenarios the first one is you start with your mobile app you want to transfer funds from A to B this sends kind of an of decay authentication requests to the Chrome extension where you confirm or reject then the mobile app knows and will submit the transaction in the blockchain the second cases and it's generally the case when you interact with the DEP adapt like an exchange would like to make transaction this pops up the Chrome extensions similar to meta masks and then this sense now indication request to the mobile app which submits the transaction lets the extension know and the DEP can can proceed now we are very well aware that this setup is very static and also it's restrictive because a user has to use Google Chrome which then everyone wants so that's why we are planning on loosening that up a little bit or extending it so that we also support different two-factor devices such as hardware wallets or saina apps like the parity signer or there's a gap vault out there and you could also use maybe a second Nosa safe mobile app as a two-factor device so we're planning on changing that second and this is an example of four tap interaction is token payment so currently you need ether for every transaction right so even if you bought some dye you want to transfer this dye you need either even if these dye have actual value or significant actual value this feature we have available in our Android app as a prototype so give it a try and we'll hope we can add it soon also to iOS now in order to explain that again let us look at this regular if the in transaction does a user who signs it and generally then stead user or technically the it's same account is submitting at least this transaction to the end blockchain and thus paying the transaction fee the gas in in ether now they still think called meta transactions and while there's plenty of definitions out there you can make them as complex as you'd like but in my opinion the most simple case is that it's a decoupling between the transaction that would like to be executed that it's signed and and and in the submission of the transaction to the blockchain so it does not have to be that same user it doesn't have to be the same account now in that case obviously that right account would run out of at some point because it's paid basically just paying the ether without getting any think back for it that's why we implemented or I guess not only we but that's why generally my the transactions with a refund are implemented so besides just signing that actual transaction that should be executed you also sign that you're willing to transfer a specific amount of Ethan in that case to the user or to the account submitting the transaction to Adi to the blockchain and yes you can you can build it a little bit more general and it doesn't have to be a specific account you can also say to anyone who is submitting it and then that that anyone would would get the refund and this this person that is submitting it's generally called yeah relay or transaction relayer and that person is or that service is basically defining how much gas they are willing basically you also have to define guest limits and gas prices and since it's essentially just another transaction that that that is being signed you can also say you don't accept either but you accept just a you see twenty token and this is basically now the transactions with refund and you see 20 tokens and yeah which which is available right though so just to summarize again why do we use these major transactions first the smart contract wallet they work anyway different so that's why we have to use them the second point is you don't need either on a second account to submit a transaction to the blockchain and the last one is the most important one there's a free choice on who pays for the gas because it could be that user it could be in our case gnosis or it could also be a third party paying for the gas and thus potentially getting a refund because that next question is usually is this why why don't we just pay all transaction fees for the user because it would bring a lot of advantages for onboarding and for adoption because then users just don't have to care about that anymore and the reason why we don't do it it is yeah we would run out of it at some point but technically like did the person or the entity that is having the most value in a transaction should pay for it right so if it's the user I think even though the long-term the user should pay it or if it's actually adapt that once the business of the user then the dad should should do that and that's essentially how we believe it should work long term so that for example like we had we in touch with some projects who are definitely interested in that and it could could work in a way that they would have some credit on our relay service and then we would notice if the user would interact with this step and then instead of us paying in order user paying for the transaction we would just deduct the amount from that credit and essentially a different section is paid for all right next point seedless recovery I think that's something we don't have available right now it's still development we have a lot of ideas and but it's not yet ready so it's actually in my opinion the most exciting point about smart contract wallets because it's trying to solve some of yeah basically that problem right now recovery phrases everyone uses them not really everyone likes them but it's the idea out there and ignore the savers no exception so right now if you right now download the app we'd still have to write down this such a recovery phrase now these problems if you write them down you could lose them even if you write them down on some things like crypto steal you can still lose them that's why generally there is this approach of social recovery and the safe is no exception there so how this would work is you if you said that if a user who's setting up a safe you would define three let's call them friends who could verify your identity in case you have lost access to your safe we don't want to store these at the addresses of these users on chain for privacy reasons but still these three people could verify in case of recovery and this was the setup flow now in case of recovery two of these three would have to verify your identity before you get back access to your safe and well the obvious problem what if these three turn malicious that's why we put in a time lock or a challenge period during which the original owner could stop that recovery and only after that time period has has passed without the original owner kind of like making a transaction then access to a safe is recovered about that time lock or challenge period there's it's not an easy to divide it good time because first of all the user has to notice because if you're on vacation and you're before for like a month and that pier is only two weeks anywhere with your without internet then you would not notice you would not be able to stop the recovery so yeah second yeah how long how long should the last I guess well it's the same same problem but because if you are recovering you want to have it very short right ideally I mean you don't want to wait until you get back access to your funds so maybe a day or so is good but if someone else is trying to like steal your funds obviously you want to have it as long as possible two weeks three weeks a month or a year depending on how much funds you store and so it may be sort and it's that's that's basically I guess that trade-off that you can find this is an option to accelerate so we have two of negation factors right and if you just have lost access to one of them then potentially you can use the second one to shorten the time period and to get back access faster so I guess there is no single ideal answer to the question how long should that period be it should be like a user should be able to set it and we should just come up with a good good default default settings for this then it doesn't have to be I want to highlight with that slight it doesn't have to be just friends or other people you have to trust because essentially it's a little bit of a well chicken and egg problem that your save is only as secure as the saves off of your friends and so if you have lost access and your friends have left access there's still a way for you to recover so that's obviously it could also be other wallets it could be a hardware wallet or you could just hold all the other education factors and so you remain responsible for for keeping them safe now what if there is what what if the recovery phrase is lost and social recovery fails because thats it so could happen right and in that case there's this thing around Oh dead like Deadman switch or paralyzed is proof so how that will work is you as a user who wants to gain back access to your account to your safe you would put up a bounty and more you would take that and this was trigger again another challenge period or a time lock as you enrich it would be checked if the original account original safe it's still not active anymore and if it becomes active then you would lose that bond because obviously you were trying to steal something and if not eventually you gain back access this the same questions how long to set the time period how does the user no no notice also apply here just in general it should be just way longer because this is some kind of a last resort recovery and it's it's something we will definitely not wanted in the first version of this but a long term I think we believe it makes sense because that's the only way it's basically a last resort and also here very important is that we need to prevent front-running so if my phone or my safe just fell into a lake someone sees that and would trigger that there's no way for me to stop them from gaining back access right so we probably have to work with some come commit reveal a scheme or find other ways to prevent that from happening now there's two more features I want to highlight that we're working on they are not specific for smart contract wallets but still so first your signature so there's it's also currently in development we have an internal prototype about that but we would love to talk with some some adept developers out there about it so there steps that require you to sign something off changes I'm some messages and it's used for blogging or vacation or as like an input to like some kind of smart contract function so a foreign regular account if there's one key you just signed something and then the DEP could recover and yeah know about the identity of who signed now a case where there's potentially two keys or more keys right so how do we do that our simple prototype just concatenates the signatures and so you would be able to determine some kind of identity from that now it's a first version it does not itself for some use case it does not solve for all of them because what if one key changes if you replace if you switch to a new phone and this would be a new owner and this would also basically change the signature we don't have a solution for that yet but that's something we were working on and we'd like to definitely start that discussion around that last but not least currently how the gloss is safe enables users to interact with depth is via the Chrome extension so similar to meta mask we implemented the Chrome extension that injects a repertory provider and basically that's that's how it works so now what we've learned is that's a solution that that really specific for the safe and we don't we don't believe that it scales very well obviously we're in competition with meta mask which is currently quite tough and also we're it's it's not really a standard that that someone else could easily adapt and that's why we would like to switch to wallet connect soon for that we also have an internal prototype and we hope we can roll it out soon so essentially what Connect is a protocol to connect it's a communication protocol between mobile wallets and that generally you would scan a QR code which then establishes secure connection between the DEP and the wallet and via that basically transactions are triggered and and transaction data is exchanged a word on security so the safe is a smart contract wallet so yeah a smart contract can have bucks and we've done some audits on it and also we've done not we there has been done formal verification on done on the other smart contracts by a company called run time verification that was funded by the Ian Foundation and ignores ecosystem fund essentially what it is is the smart contracts are formalized as the mathematical specification and then it's verified that the EVM byte code satisfies the specification they do be part of that can be fined can be found at this link and that's essentially the measures we've taken to make sure that there's no bugs in them so since your smart contract wallet did something to that everyone needs to be aware of coming back to that original question why yet another wallet I hope I could highlight some of the differences and why we believe that smart contract wallets are definitely solving some of the problems and something to mention is there is it's actually not on a person true that there's no other wallet out that does that there's Argent right some of you might have seen a talk from yesterday at the motivation of this project is definitely very similar so the motivation of the gross is safe and there's some differences for example kenosis the girls safe is a successor of techno smart ASIC which was it's one of the very popular emoji signature wallets out there used by projects for for the icos back in the days and currently still to maintain funds and since the safe was born out of that it's the use case it's just much more general there's more contracts are written in a little bit more general way and the application areas are bigger for example we don't I mean I guess right now we focus on the individual single user case but in the future would also like to would like to support teams with that then our front-end saw open source so you can check them out and see what we do that we don't do any any bad thing it's another difference and but besides that we're definitely are very interested in keeping both interoperable and maybe we can even get work together on a recovery all right please save try it out let us know what you think be positive or negative and also we'll be doing a bunch of user tests throughout the conference so if you interested find us at the booth and yeah we happy to talk about the safe [Applause] right are there any questions so two questions here the first one is about the formal verification part is that usually when bad things happen in the etherium ecosystem it's not because some project does not fulfill the formal specification but it's because the formal specification does not actually match the informal specification and it would be interesting to hear your your take on what exactly you have proven and how can you convince your users that you know what they informally expect this to do is actually what it does that's the first one so um me personally I'm definitely an expert on formal verification but I can still try to answer your questions so so with that we don't prove that the informal specification but basically what we have implemented matches the informal specification but what we can do is we can look at what has been implemented at the code and we can just look at any input parameters even the ones that we haven't considered while developing that code and see what the outcome of that is if there's any unexpected outcomes so that's to my understanding on what form of verification it does I'm not sure if that answers your question that people can read it and so I think it's I don't think it's possible to make it simple to read a formal specification or a formal like that that you know like the code that we have or that at least they have been producing as part of this process of home verification but isn't that the case with like almost anything that basically you may be you know someone you trust and who's there able to understand what we did and that person says okay well yeah would they they've been doing an okay job at least I don't see any problem and then so you trust these is this person so I I think it's little bit unrealistic that really everyone should understand low level what we've been doing there but they should they should always be away for the interested person who knows everything to double-check and then they could flag and raise issues and then it's a point where even you know like non-technical people would like hear like oh well maybe there's something wrong I should maybe not use it yesterday we had a interesting talk by Fabian about RC 725 which is a standard for a proxy contract where you where you can put all those multi-sig and all those things where people where you can abstract away the key from the account which is basically what was the beginning of your talk there's actually a standard for that ERC 725 and then you can draw a clear line between the proxy contract and the actual application the actual contract that you are kind of governing with that account that abstracted account so is gnosis safe also does it also have that clear separation that this is the proxy contract part where you know it checks the two-factor signature and whatever and here we draw the line and here's the actual safe contract that does yes so we also use proxy contracts and there's the proxy contract that always gets well deployed and this will our proxy through calls to what we call must a master copy but in our case this master copy contains all these info about signatures collection and so on like it contains a database safe contract contains all these things like who is an owner of the contract what's the threshold how many signatures do you need and you can execute transactions arbitrary transactions I know actually you pioneered that approach with the master contract as far as I know you were the first major project that did that last year you presented in this very room but what I'm asking is not the its it specifically the the governing the separation of of the identity governing the contract from the contract which is basically completely agnostic of what the contract does could you could you hand over to Mike sure to Richard who wrote this my contracts I think yes so also concerning to the related 25 contract and before you had like anything could be the owner or the managing identity of the TRC so the safe would probably be more the manager of an entity because a safe actually like to that I said doesn't do anything else than just checking the owner so we don't have any logic build in besides this part that does a multi-state like and the only as a little bit extended logic in the safest that you can add modules that have additional functionality which you could say oh you could add a module which then is a completely different contract it's not part of the identity managing contract that has the functionality of the RC 725 or for our recoveries all this logic will be in different contracts that basically then I just managed again by our safe contract but the safe contract itself is only responsible for checking hey if you want to execute a transaction are do you have enough confirmation from another officer owners to actually actually execute it and nothing else all right thank you thank you very much I'm sorry what's another question we can all right turns out that wasn't a question a happy coffee break [Applause]