EthCC 2: Fabian Vogelsteller

hello oh yeah hello so let's get to the next talk hello world yeah I have to put it very close okay good so um I don't think I have to introduce myself so you can just read down there what I did and I want to start this talk with statements actually two statements the first statement says I think that in 2019 it would be all about web 3 UX this is kind of like a very important thing we have to tackle and the problem with this is that went through UX right now is hard you know it's all about you know looking into the car's engine and while making people drive the car but first expanding them how the engine works and filling gas and changing oil and so on that's one problem the second statement that's that's probably a total gamble but I like my gut feeling says that this will be the case is the 2020 we probably will see mainstream adoption meaning people are using blockchain without knowing that they're using blockchain and it will be used by the non-technical audience which right now it's mostly the technical audience and we have two main problems which come with using the sium network or technically using any blockchain and the main things are gasps the problem of gas is you want to do anything on the blockchain and you have to figure out what the thing either is especially for the newcomers in the space that's a very big problem you can say come in they want to use the token I want to move your token and then they have to figure out oh I need either first but nobody told them before right so the gas problem is a pretty big deal of why the UX is so bad the second thing is everything is on keys so losing your keys basically means losing access to whatever assets you have so it's all based on you have different keys generated and then you need to transport them and to back them up and all of these things this kind of like kills the whole axe when you're interacting with the blockchain year 7 to 5 which is this proposal I made a year two years ago or so a year ago I think which was all about okay how can we interact better on chain how we can basically be more more recognizable how we can better manage a profile on chain the problem is it was rather complicated it's a very complex standard like tries to evolve a lot of different pieces and even though that this is this is a problem you know if you come of complex standard it showed everybody okay what could be the different components and it spurred a rather lively discussion around anything identity on chain and in general any theorem around identity it even led to a alliance forming and some whatever 30 projects saying that they want to use that standard the problem is it was not good enough and therefore we set together in fact I and Taylor set together and like we thought okay what exactly how exactly could this look like what is the core piece or what's the core component of making a profit profile on chain work and the key to that is you make it extremely simple let's kind of probably also what make 20 a successful it was extremely simple now with this simplicity here which looks like nothing like not much right there you have like get data and a set data so you can set data into a smart contract and you can get data in a smart contract and you have an owner and you can execute meaning taught through this smart contract and answer execute function yeah so this kind of solves actually a lot of problems if you think about it it solves actually very many problems and in fact I remember back in the day in 2000 and whatever was 15 or so we met in Amsterdam as the MIS team for the first time everybody's being together we had the first version of the film wallet and the MS browser earlier on built a whisper chat application which used whisper protocol back in the day and we were thinking okay how should we have our accounts in the midst browser yeah and actually Jeffrey the founder of Goethe um said yeah we have to this cannot be keys not at all keys we have to have smart contracts we have to have like smart contracts which you put out there and then the keys interact with that the problem is you have done all of these problems like who's paying for the gas who's deploying them when and all of these things so we decided okay let's make it easy let's just you know use the keys and set as an identifier and the one you use in Unchained in fact looking now back he was completely right he actually already clearly saw it and then over the time you know I'm kind of like here's a seven to five and others kind of led to this and I guess this is kind of what a 7 to 5 now as a result really brings to the table and the benefit of this is if you have a proxy account or a smart contract which you interact with you can't have an owner of the smart contract and this means you can abstract away the keys meaning you can start out having your proxy account and you have just one key and the key owns that account this proxy account the moment you actually want to have a backup you know you want to show your user for example ok now you have an account you purchase something we put it onto your proxy but now you should pack it away we send you one key via email either encrypted or not encrypted even we like for most of these values it doesn't even matter but this way you have a backup and you have not even probably set a password but you have a backup in the moment you lose your phone happen pretty often and we are at the level of email password recovery like which is the standard today right but when you wanna have more security and you now can have a more complex mechanism you could have multiple type of keys and you could assign different roles for these keys if you are a corporation you could even say okay we have here now five keys which certain employees get and they can only call certain functions through their proxy account meaning one chain is always one address acting which could be the the corporation acting but any kind of employee can have different rights while talking through the same address and the most and I think the most important benefit is that we can add also real a transaction functionality or meta transaction or whatever we are calling this which allows anybody to pay for the gas for your transaction meaning you just sign a message with one of your keys you send it to a relayer however that wheel and service is paid if it's a free service or if you like somehow gets a reimbursement over time but he's paying for the transaction that might just be the startup this might just be the application itself you're using and you don't have to bother about any kind of transaction fees especially not for first and early users I know buddy can use an application first have to go to an exchange and register okay I see all of these things just to use an app right that kind of solves it and that may cost it nicely for that user profile you creating here on the other hand you can now attach an hour kind of information to this account and this means you can make this account in some form identifiable or in some form verifiable you could attach all kind of information like for example you could attach different claims all right this is would have been this case probably public claims or you reference any kind of secret claim registries with your public profile and it can also be at other objects but it can also be any kind of reputation systems so if you want this account to be reputable or if you want this account to be validated by a smart contract you can just attach it right here and it's much contract can then go look okay some kind of profiles talking to me let's check if he has whatever I require if he has let him in or not that doesn't mean it's related to anything personal even you don't have to know whoever is behind it but you know you can interact with this account for whatever purpose or reason so it's creating that thing which I call a manageable verifiable account and that's kind of like a very key piece what you currently are missing because currently everything in the theorem will actually every blockchain ecosystem is about keys when these keys are have no information attached and they are pretty hard to manage because they're only like locked basically only manageable by its private key so this creates this kind of proxy account that allows you to interact on chain with everything else without that you have to worry about losing your key or because you can have whatever recovery mechanism be it soul shall be multiple keys with bit multiple devices whatsoever and you could actually deploy this as a proxy okay or as a library meaning you paid 30 mm gasps and in fact if you want to have a very cheap account so stating that to you port actually it's actually not necessarily identity it's in fact your proxy account this is your actor on chain right now your actor on chain is the key now your actor on chain can be a more complex system where the key itself doesn't matter so much and that's that's the main thing if you want to do real world people's identity you probably actually want to go use the ID spec from the w3c and actually just spent the last weekend at the reboot of web of trust 8:00 in Barcelona a lot of these kind of like standards around the idea are discussed so yeah it's all about proxy account and if we agree on a very basic symbol version of how that proxy account can look like and how you interact then we are free to attach any kind of key management to it we are free to attach any kind of piece of information to it and the experimentation can start from there but at least we can equate to the core and that's the key piece it cream to the core and as it is so simple that's not really hard to do and it solves a lot of problems and of us we can finally have the web free experience which can be a lot easier than the web to experience currently is so that's that's all I have to say thank you there's one question here thank you before this talk I was a bit confused before because we used the ERC 725 for key management and it proved very useful and I believed you wanted to replace it with this proxy which makes sense but it's a different usage no you understand that the two will work together in kind of a pair where you've got key management and then the protein so my question is why keep the old name for the new proxy and give a new name for the key management and not the opposite it's confusing for you knowing seven to five is probably less confusing for the people coming new in fact when I created seven two five and seven three five which is to claim the personal claim registry I had to create one extra issue in order to get to like two five and three five and I created three four which is an empty issue which fit perfectly now because I moved to seven to five key management in two three four so yes it's it's a bit confusing because now the proxy server two five three four is the key management the way it was which can talk to that we have probably to do a little bit of improvements there and Devon went three five to claim registry it's just something you can link here you could also link at 780 registry or you could blink a miracle root hash of whatever off chain claims or you could even link just your D ID ID number or whatever you want why are we placing that the thing is seven to five is already something people like talk about it's like a word it's a name you know I mean if it would have created a new number there would just lead to even more confusion and on the other hand it was entrapped and the whole point is we have here standards that are supposed to be evolving and improving and trapped means not final so I have to write kind of like to change it all over again and that's I think what makes totally sentient is important and and that's better to work on one standard evolve that until we all finally think it's it's final rather than constantly creating a new standard you know like I see this so often now that like somebody comes above a sender somebody else like a detail but instead of like changing this on proving this it just creates another Center so you end up with this mess of like standards around the same thing which are only slightly different so the whole point is like let let one evolve until it makes the most sense justice I comment on what you just said it's completely different interface right so it already creates a confusion if you have two completely different interfaces under the same name my question is about claims and about what we put into them in the new version what you present today as we have the set data and get data wouldn't it make sense to add some kind of confirmation into what we set so it will be like well packed and preserved some how to say split between what the identity claims to be and what he puts in because currently yes I with the design while you represent it I can put anything I want but then a third party he will in any case he will always need to check if what what I would make sense so he needs to have he always will need to have as a second contract yes to to verify this game that claims yeah so to the first part I mean seven to five is actually not really used in production anywhere people are worked on it and there were some interfaces being built but I'm not the way that anybody's using in production so seven point five or seven seven two five sorry seven point five seven two five version one in my opinion it was not that much of a risk to replace it the the answer to what you're saying here the whole point is to keep the core extremely simple this is just a reference point that's your proxy so whatever key management can talk to that and the key management have to define of you know what kind of rules you invent to set data what kind of rules you invent to to call the execute function so that's all managed now in the queue manager which can evolve over time and you can replace it so only the owner only that one owner address is able to call set data and is able to call execute that's right but any kind of confirmation your information you attach they this is sitting in a separate smart contract which is a seven eighty contract it might be a seven three five contract it might be a miracle tree and maybe something with like sarah knowledge proof or whatever so that's sitting outside so you're not looking for actually claims with confirmation within here if somebody says okay yeah but I want to put this on the 7:00 to 5:00 contract and it comes up with whatever schema of how you read the bit masks of the the value store they could do that but the idea is not that now this is regulating what to trust it's just the the it's in like in di D world it's the di D it's the point where you go look and find all the other things yeah but if you talk about the usability then let's say I'm a bank and I would like to and you are coming to me and presenting oh this is my identity so instead of using a one identity contract now I need to deal with several other contracts which will verify what you try to present to me so I mean this could be as simple as one call and this call is redirected once to another smart contract so it can be done really simple and the end this this is not this is just defining the core data structure and not the UX and however the you access I mean the a UX can be as easy as me pressing confirm which signs a message proofs that I own and control this smart contract and they go look wherever I need to look automatically and this can be just is going to one next other smart contract but the problem is if we try and this is exactly what seven to five tried to initially do well in my opinion was the biggest fault is that it tried to do too much in one thing and therefore make it really hard to adopt because do we now figure out all the best solution is what of what key management can be or what confirmation process can be probably not we would have to discuss for another five years before we figure out it was a good or bad idea this allows extreme flexibility meaning the way of how we confirm certain things can evolve over time you don't have to change your address you don't lose the reference point a reference cream can always out exists all of these changes and that's kind of the pole I agree for this so let me let's formulate the last question here and in your opinion from the architectural perspective if we design some system to deal with the identities so let's say for the my perspective yes how would you design the the confirmation system that when somebody is coming with the identity he is also needs to have this verification of this claims so there will be always at least two contractors to deal with yeah so the thing is the question is also what is the use case this is the this is your door to the film blockchain or to any kind of EVM based blockchain if you're dealing about like credentials which maybe need to be verified from a bank I mean maybe the D ID approach and the you pol approach is the way you want to look at because that's probably what you want to deal with you don't necessarily need to have anything of this on chain if you want to be verified if you're an IC o---- smart contract maybe there's a claim that you are verified invest or whatever that might help you to automatically interact with this IC o---- but apart from that I think most of these things can happen off chain but anything on chain you probably want to have some kind of gateway proxy which is seven to five version two so these would be the answer to your question D IDs and verifiable claims that's what the tablets we see is specific is fine and then go ahead hey first of all Fabian I love the renaming you know I would and it's awesome and it is a it looks so much happier with this and all I wanted to say is for our date method at du port the Ethernet method I think this would work perfect it will just interoperate completely without any kind of problem so so no nice one thanks okay that's it and no questions anymore no good thank you [Applause]