EthCC 2: Vincent Eli

hey everyone do we need to wait 1 or 2 minutes so you know people that should come or should I start if no one disagrees then I think I'll start ok let's go ok so hi everyone I'm very happy to be here to be talking about our research at Mara mask I'm van smiley I've been involved in the FM space since 2016 and I've joined made a mask in last November and thank you for being here I know there is a lot of competition now with almost 5 or 6 stage when I first talked in Paris at a firm conference two years ago as a comparison there was only one stage so it's growing very very quickly and the subject of today's talk is going to be about what we call me seriously meda meda mask in a few words it's the will to allow Madonna's to go beyond its current state which is layer 1 transacting wallets and lay you one application wallet and it's it's the will to go beyond that and namely allowing for layer 2 solutions and today I'll be presenting the first step of this research effort and the first step is what we call application keys and we've made a fair Amin provement proposal for that ok so this research originated from the wheel twin to allow me Thomas to go lay YouTube that was my objective when I joined madam asked in November and the first things we tried was to include or integrate a given layer to solution but there are many so we try to play around for instance integrating plasma then when you look at plasma you have plenty flavors of plasma so should we integrate plasma car plasma Debbi plasma mono plasma that's that's a question we didn't decide to solve or we could also choose to integrate dimensional dimensional networks state channel state channel network so the first approach could have been to pick one of you given solution and integrate them instead of that we decided to focus on taking a more global and agnostic approach which is to evolve meta mask in a way that allows to create a framework such that Madame s can better integrate with any layer to solution and not only layer two solution any crypto permission and sophisticated crypto permissions application so it can be it can be layered to but not only privacy solution or even over stuff I'll explain later and to do that to extend madam as beyond transacting layer one wallet we have roughly identified two steps and I'll be talking about the first step today which is application Keys application keys and the next step which probably will be the subject the topic of a future talk or future if it's going to be about extensibility how we can use those application key to extend metamath beyond what it is today so application keys so the idea so the topic of today is roughly mimicking what has been written in this EEP that we proposed one or two weeks ago actually like 10 days ago it's EEP 1775 and it's a draft and we labeled it as a er see if areum requests for coming because the aim is to develop a standard and to develop a good standard we need input for from all points of view so we have a discussion for that which has been quite active on FM magician but you'll get you don't need to write up this link all you need to remember is 1775 because there you get the links to the discussion and you can see the epified and the idea is should to develop a standard it stand up for new type of accounts which I'll explain in a few minutes but we really like to anchor I encourage a wallet developers and application developers to look at this standard and tell us if they like it if it likes some stuff it which would take another alternative approach and so on and so forth so the simple summary of this talk if you if you need to focus for one slide just one slide you can you can focus now the idea is that sophisticated crypto application they require many more than we have today in current wallets they require significant amount of crypto actions so an action in a sophisticated crypto application such as a layer 2 solution may require you to do several signing in one step sign a transaction sign a message sign a second message and then maybe Kunta sign something that your Kunta part is sending so if we've current wallet it will require like four or five clicks one for each signature and also sophisticated crypto application require you potentially to delegate signing if you are going to use a stage channel and the design of this stationer would be that every time your Kunta BOTS sends a message you need to contain it it means you need to be ready if you're using current metallus you need to be ready waiting for the pop-up to appear and sign it so you need to be waiting in front of your browser for that you you cannot automate it you cannot automate this process in any way so you and violet have a bad UX for sophisticated crypto application and this this leads to security and privacy issues because basically you are using your main accounts the one that all your phones to interact with application so you'll be signing message for different applications from the same wall from the same account and also you'll be potentially signing message from an account that also a lot of phones so if someone tricks you into signing the wrong message it may have bad consequences and also privacy issue because someone can link all your blockchain activity to a few accounts that's why we introduced a new type of accounts so these are not going to replace your main accounts the one you currently have in your wallets these are accounts that should be used along side your main accounts those accounts the the the wheel is to to derive them in a way that is specific to your application so they will be isolated for each application and this can allow wallets to implement a more permissive and flexible behavior and security standards for those accounts so basically the idea is that you would use your main accounts for transacting the one that are currently standardized invalid for now and you would use up keys to interact with application maybe initially founding them from your main accounts abstracts so application keys account isolation across application specific accounts that are specifically managed and derived for your application so it gives more power to the to the app developers and it allows also app developers who request some signing the legation so they could use these these accounts to sign stuff without prompting the user I'm going to give now the specification and basically what we need to data mine for the specification to be complete a few things we need to determine how to identify application so what's a unique identifier we can use for each application we need a way to properly authenticate each application when an application is claiming to be some domain how do we know it's the right one and it's not trying to steal keys from another account from another domain and how to derive those accounts using HD Jasha called deterministic derivation and what's the API to use those accounts so that's what I'm going to present now motivation I I already said a bit about this but in more technical terms well it's a firm wallets currently use a few standards those come initially they come from a Bitcoin so we have bits 32 bit 32 is the specification of those derivation paths using indexes and the ability to add on these addresses I'll talk a bit more about auditing later but basically it allows you to isolate your account such that one cannot guess the public key of your child accounts from your parents accounts so anyone here not familiar at all with irrational deterministic derivation or can I assume some basic knowledge an and move very quickly okay so I hope that's fine then so beep-beep 43 is the next step that a firm account are using in the standard is this idea to have this purpose field and they all use a frame account they all use beep 44 before E 4 is so use the purpose field 44 and then you have the coin type and before E 4 is this is this specification all those fields and what beep 44 says is that you can look at this list slip 44 which tells you that a forum is going type 60 basically all of my LEDs to use this derivation path where n is your account index so first accounting metamath would be this using n equals 0 second one n equal 1 and so on and so forth and this is basically the standard for account derivation and then we have API for web 3 RPC and we have EEP 1102 for privacy but there are several things that you cannot do today in classical wallets you cannot easily and manner in easy manageable way use different accounts for each application or you will have to remember which accounts you are using for which application you cannot use forever keys or you need a way to remember that you created this account for one time but it's going to persist in your metamath list of accounts and it's not going to be manageable you cannot have signing without prompting you cannot sign from your account without broadcasting the transaction and we get some requests for that some say we like to be able to sign transaction from madam asked but not broadcast them right away maybe we wait for one hour or we wait for some condition to realize before we we broadcast the transaction this is not possible with the current way it works because for main accounts you don't want this behavior from any accounts we want to broadcast transaction right away and this is why we we think we need and yes and all this sorry last thing all this while using accounts that should be only restorable from your memory we don't want you to have to to backup additional data only you 12 or 24 words seed or you Hardware wallet and then you get access to a standard that allows you to do all those things that are not possible today so this is the motivation and the specification so application already explained I'm going to have to skip a little bit because I want to get to the end of this talk so this is the standard we proposed so to interact with applications which can be a firm application of over of applications we are proposing to derive accounts using this path so it's going to use beeps 32-bit 32 is the era she called deterministic derivation paths that specify indexes and the fact that you can add on indexes and we are going to use bib 43 so before we freeze just this purpose field the first the second one after the manic and this field we are not going to use 44 like in the bib 44 standard we are going to derive from that because here we are going to use a different structure so it's different than what we're using for now for manual adds it's different than before for so that's why we're going to use a different purpose field and then we propose to use three parts in the in the path that he used to do that is used to derive account specific for each application we use we use a personal path this path allows the user to to potentially use different identities with the same application with the same memory and the application will not be aware that it's the same user so maybe you use that from your memory to create a walk and a personal account or you use that in in any way you like second part is going to be a application uniquely assigned tough this part will be determined in a unique and deterministic way using the application domain I'll explain how this part is specific is known by the application and it's it's deterministic and the last part is what we call the application custom path and this path will be under the application control so the application may use this part to include for instance a version field to include to create several accounts and they can do what they like personals so the first part of the path is the personal tough so this this one is easy is just the eep number that we use as a purpose field this one person above this one is under control of the wallet and the user maybe the user wants to manage personals for the the wallet wants to manage personals for the user in some way maybe just uses incremental indexes personal zero personal one person a two or maybe something more sophisticated this is going to isolate the hd3 for each person I will get a different tree and the next part is going to be the application part of the tree this part of the derivation of the eurasia call the derivation is going to be using the application name and we are going to use the domain so we use either ENS domain or we can use a dns domain a classical URL domain and we use basically from ENS we use the age ashing scheme which is that we hash the domain name we split it first so fubar that food bar that if is going to be split in foo bar if and you hash it recursively starting from the from the end so you hash if then you have the result of that and you hash bar and then in a similar way with foo and the result of the previous operation and you use catch AK 256 for that this gives a unique application identifier so any name so we can use fubar calm as well this will come to your unique 256 bits identifier then with splits we split this identifier in a way that is compatible with the bib story to stand out be 32 standards require the indexes in the path to be 30 bits 31 bits so we need to split in to 66 bits with sorry two bytes is going to be dividing in 60 times 16 bits or 60 times 2 bytes and it's going to be a path like that we can we can use alternative maybe to to split it in some other way but the gist of the idea is to split in a way that is compatible with bid 32 so an example would be food additive so we already see now we derived this unique identifier then we split it in 16 equal imaginary parts then we we proposed here to add on the the indexes to be able to be sure that the app are fully isolated so if you leak in some way your private your public keys from one up you won't be able to derive the private the public keys for another app so this is in X and then we translate it to unsigned int integers so this this was the application derivation path we are the person apart before and the last part is the application custom path this path can be managed by the application itself we don't impose any constraint on it except that it should be bib sorry bib sorry - compatible so let me give you an example of the whole path so let's assume so the Jeep is pull request 1775 so let's assume this this is the final if number so the first purpose field of beef 43 standard is going to be 1775 and we are done that then we use a person above so let's assume in this dummy data that the person above that the user wants to use is 0 Arden 7 712 Arden so this is this person above and if you use either different than that for the same application is going to derive different accounts and the application won't know it's the same person then we have the fubar dot if you ID path which is there until here and then here the app custom path is going to be used by an application in the following way they decide to include an index for the version which is here zero and there are donuts and then they use a set of accounts index and account index so they use that that way but you could think of an application that wants to use this custom path in a very simplistic way they would just derive they would remove those two fields and they will just use 0 1 2 and so on here now that we specified how we derived those accounts we need to explain how we your application can use them so application will still be able of course to use main accounts in the same way as currently they use the provider or they use the web 3 API now we would like to introduce new RPC method a new web 3 API or an app key API and this app key API should allow the user to use those those methods so the first one will be enable you request from you request from the user to get access to these set of accounts the user accepts and potentially we can include a challenge that the user automatically signs when you accept to use those those up keys and if it's we can do it in a way suggest it's a one-time request and then the next time the user can write away login into those those website and the app keys will be automatically activated then we use a very embedded so here it's just you have a method to get you have a method to get the public key for your account to get the address you can you can derive public keys from parents keys and so on and so forth then we have signing methods so here it's a fare and signing method but we could use different kind of signing methods we could into introduce your bitcoins I nematodes or even non cryptocurrency signing methods all those from the same derivation path specific for your application so let me skip a bit this and and I'll finish by giving an example because I think my my time is almost over so what you can do with that is that you can use up keys to create a website for instance that will allow you to have accounts for which user can sign transactions and you don't broadcast them right away and you broadcast them later maybe using a script on on the in the web page or using your server or something that's one thing you can do you can use token or application specific accounts you can you can use that to have non wallet or non cryptocurrency accounts those account for instance if you want to do I don't know a basketball password manager you want to do privacy zero knowledge proof maybe we can include those type of methods using these app keys which will not be a failure method so we need new accounts for that and and you can think about integrating State Channel because there you will be able to do more complex actions without prompting the user at every step and finally you can think of cross cryptocurrency exchange where it would create you log in you get accounts for all your Kryptos and you can do swaps transferring your accounts to to you transferring your phones to your own account for each crypto that's it for now so basically I really want to the if you need to remember something of this talk is please go to this EEP if you are wallet or an application developer please go to this hip please review it please make sure that the standard is compatible with what we would like to develop think if there is some benefit from us and if you need other stuff please contribute and let us know that we should change this stand out in some way or we should include this method and so on and so forth so yeah my my contacts and thing I like to thank you and sorry for being a bit long