Standardization

Transcript

okay so this is the standardization panel with a bunch of brilliant minds up here Gavin would Nikolai vivillon vitalik and Christian so the point of this panel is to talk about current standards and potential issues that we might see what happen how can we as a community resolve some of these issues and how can we go forward to maybe implement it's like a perhaps a process or something like that so I think to start off with I think will be great too there are so there are certain standards that have already been defined that people are using and want to use such as the token standards registry standards

and so forth in your area which are the ones that you currently feel the most passionate about and and what are your thoughts on that particular standard and going forward we ever wants to start Christian yeah so I think for me it's probably tokens so in the transacted grid energy trading program project were right now we have our own custom way of tokenizing energy credits renewable energy credits and we want to move

towards a standard token solution so that it can may integrate it with with markets such as ether eggs etc and so this is you know for that reason very important we're also i'm also using registries in various tabs but i think they're it's often more straightforward and it's there might be less need for interoperability if you have a very targeted system so I think for me tokens stuffing tokens and registries I think probably are the two biggest categories

and with registry is there are there are different types of them so there are some registries that are specifically kind of targeted to particular types of metadata and then there's other things which are you know basically named registries and they have a lot of different requirements though in some cases kind of partially or entirely the same interface aside from those two the third category would be different different kinds of financial financial contracts exchanges even like purchase offers i want to buy excellence of a 4y units of being yeah so for me would be like proxy contracts contracts were actually would hold your ether and send

it along but maybe do something with it maybe like send our chairs to other proxies or some kind of voting system based on whatever you pass through this would be interesting me and also tokens as well because we need to integrate it in the wallet or we did already and we want to obviously support as many and talk it as possible can can you elaborate more on the proxy contracts I mean the current wallet for example is a proxy contract but ideally you should be for some of the wallet you have a moiety sick on ether ideally you can have a moralistic on everything like even a multi second sending your custom tokens or whatever so you can use these proxies

for yeah whatever you want to do with any other contract on the network okay yeah so I work on maker and obviously were most interested in the under token standard also and I guess my role on this panel is pretty much just going to be I think it's too early and nothing seems like a satisfying solution yet although i don't have anything better so so I think identity in some sense is something worth considering deeply and how we can try and make all of the different pieces of infrastructure fit well together while dealing with actual individuals so things that are going to

fold into this like reputation potentially stuff to do with the outside world my email address my website and so on this is in some sense already addressed with the notion of like this 160-bit address scheme that we have but I think yeah it's worth considering a bit a bit deeper and how this might feed back into things like avatars that go across the various applications within the etherium and sort of web three at-large ecosystem I'd also note that the other thing we tend to think about standard is something that you know that they tend to be kind of opt-in and we need standards in order to have

interoperability right different applications implement the same standard so they can they can they can operate with each other but actually one of the great things about etherium is that this is a fundamentally programmatic infrastructure so we have the notion of objects existing within the system and these kind of already enforce standards because they have an API and if you want to interact with this with this object that sits at the center of subsystem that you that you do want to operate with then you just use the API and the API is a standard it's already there and there's no real prejudice because assuming that it's been implemented in some reasonably fair way and you can check because there's a code there then we can already kind of pre agree to the

standard that go if someone makes a token that doesn't conform to the normal standards then you know maybe ether X you change last exchange wouldn't then be able to use those tokens but considering that the code is open source you can just clone either X and making it exchange for your standard as well so that's it's great in that manner the the topic of my identity I want to come back to that I think it's a it's an important one because as far as I know it hasn't been we haven't specified anything yet this in what like how it should work and are the ideal version of it should work the Christian you yesterday explain more about you port work what's the sort of

the the idea or design goal of that is it sort of the idea that you take you keep your identity in the browser and then you move it between certain depth what about sort of examples where you have a phone client or you have a web browser client or something like Minna mask or something like ha what's the we think is most ideal way to just swap identities through different interfaces yeah so this is of course a big question and the the notion of using you know the same identity on multiple devices that ultimately comes down to key management which is you know might be one of the

greatest challenges of of this whole endeavor how to have key management with with a good ux i think yeah I identity is of course very important and and I'm glad I'm glad you brought it up an interesting thing there is so when I think about them today I I describe the the kind of general outline in my talk and the the key management issue is very important so I think we have to have a

system of identity where even if you even if you lose your private key you don't lose your identity so then we come into a the fact that in the current system contracts always interact with keys so you have access control in the form of you know if message tops under equals this address then do this otherwise do something else and that that works in the context of identity because you can have a look up that goes from from key to to identity but it's an interesting thing to think

about if you know if we should think about an access control system that works on the level of identities rather than keys so so in my mind and identities is kind of a cryptographic identifier so maybe a 32 byte hash or something and then the the contract could say ok I'm getting this message going to look up if it's you know maybe it's just the key then do this if I if I if I do a look up and see oh this is actually an identity then I can have access control on the level of that identity and so then you can keep using these contracts even if you rotate your

keys for your identity so that's that's something to think about and that of course you know if we want to go down a path like that it requires it requires standardization in how we construct these these contracts yeah it does paint a potential issue that if a lot of that current apps are going to use the normal account system and not a more safe identity system that you won't be able to upgrade all the previous applications to optionally slot into an ident like a more flexible identity system that's one of the things we we need to figure out any other comments on the medicine in

general I think that you know 20 bite addresses are pretty wonderful identity standards themselves just because like the sort of really important property that they have is how they're good at completely separating the concept of identity to the concept of how you do access control for the identity and even you know we're potentially with things like registry is how you provide metadata or assert a shin about that identity so like I in general you know I do think that you know access control ism is a problem and figuring out how to like switch keys around as a pro Ellen is a problem but all of those things its importance to kind of neat clean we separate all of those problems so that all of those problems can side

and kind of be sort of hidden by always from the point of view of applications hidden behind one single account and then you know people can basically use whatever solutions they want because you know when theory people have the incentive to protect your own see their own security I know and they'll go with what's most comfortable for them I think that that's what proxy contracts can become useful in that regard where you essentially you you navigate your your interaction with the tricity ecosystem through like a personal proxy contract that's your sort of forwarder to the wrist right this could be tied into any type of identity system potentially so that the proxy contract then would

become you know the canonical I mean the address of the proxy contracts becomes the canonical identifier for for you and then you do all your interactions through that but you can have multi sig access through that and do key rotation for access to the proxy contract etc so that might be a good solution if early the EVM can practically be expressive enough especially in terms in terms of cryptography I think you can go very far with boxxy contracts like one really far-out thing is if you look at something like the Estonian digital ID

standard then you know someone with an Estonian digital ID you should is theoretically able to create digital signatures with that and you could even have a proxy contract and verifies those I agree that proxy contracts work very well like the address scheme is super general in it I mean it pretty much solves a problem like you described but another approach you could do is basically you're the two keys are the same identity if both say that about each other so you have one contract or everyone just comes in like I guess wires up there cluster of keys oh and also a contract if you can force it to do a particular call it's the same thing and then your cluster has one canonical address which you use you know when you check the sender you look up the canonical address

and see if that's authorized and then and then you don't have to then then people can make up whatever you know they can even merge identities if you want to really look like I have I have two identities but then I want to combine the reputation or something then I can link them together and now they're one yeah that's right so I think I think one of the we've heard a lot about tokens through the past few days it's definitely one of the more pertinent things to to think about and I think as a community we've come to very close to finding a pretty good decent standard that's not ambiguous and people can can understand I think the next the next big one would most likely be registries that

it's good that a lot of people are going to want to use I'm going to think about I know there's been talk about questioning where should metadata live it should it be in the contracts themselves or should it be in red sheets Gavin I think you you have opinions on that you want to share sure yeah so this is a question concerning whether given a contract that there's some particular thing let's assume it's a some sort of token contract that's recording the balances of various identities should it should the contract itself contain

information regarding itself or should that information be placed elsewhere on the system potentially in some other contract who's res on debt were so to speak is purely to retain information concerning for example token contracts these are the two sort of options it's my opinion that because we live because we have this system so normally i would i would I would place the information in with the contract that is actually sort of that it that it actually refers to this is mainly because in the in the real world we have you know siloed servers

that actually have system admins that can actually corrupt data and and and the two sort of systems can become disjoint but within a theorem of course we don't have these problems and we can actually have nice isolation of use cases without having to have the sort of real-world problems that isolation brings such as the fact it's thought on a different computer potentially the different isp potentially it's going to go down at different times and all the rest of it so in this instance I would actually prefer to have a nice fair contract that actually it's resin d'etre is simply to store metadata about other contracts yeah and then allow the coin

contracts and all the rest of the other all the token contracts etc to do their thing which is to say maintain the balances of their of our users you can you explain more what types of metadata you're talking about because that can mean stylish sure so specifically data concerning the contract itself rather than containing that the data that the contract cares about so in this case the death date or things like what's the name of the contract maybe the certificate we consider them like static static members you know stuff that doesn't actually change with the state it's just to do with the actual object itself yeah our opinions on it burner the idea is basically like names and the

token symbol or like how much decimal the blazes 1201 token has and I think it's definitely a valid approach but I could also imagine that a lot of people may want to have told us which are not listed in any kind of registry and as well as I see this is like crowing from simple things from what we can do right now what we can add for example to the wallet right now in an easy way and what ideally we want to some point in the future at some point in the future we probably have I can miss many depths which allow you to look at these registries to modify these registries to have all kind of search functionality and then it's very useful

to have these registries and maybe even exit all through this but in the current state I see it more like a lean approach like putting the things where they are right now easy accessible and easy to understand because it's also from the other developers who use these contracts we want to understand them they have to know that I have to look indigenous and displaces or maybe there's two different coin registries or three or so if they're just like right now have it into place where they're actually expecting it to be it's easier and it's like we I think we would crow in that direction so we're like mature over time and this also brings me to the point of of the current standards so I don't think we

can make up a standard right now which fits everything for the next course I've had five years or so it will probably be many iterations and i think one major point is to make sure that we have some kind of up credibility strategy so what happens if like standards change maybe we can use proxies in front of others or some kind of like via proxies we're like you can change the api of your token in a way without changing the actual contract without it the real update of the contract you can still be sure it's to steal the same contract just now it has a different interface with things like this we can actually rather

flexible even if we have to make changes in the future and one other thing towards the tokens book some of the guys from Colossus have that issue that they want to not only have one contract / token but I have a token contract which holds multiple tokens and that's actually something were thinking of how we like have token per contract or multiple tokens per contract and how we bring this into one standard how we make this readable for example this would require not only having a coin registry which has like token name and add but wrong name address an identifier of the token use inside and so I really would love to we bring the community and come up with what use cases they have and try to find the common standard and

I think that's more right a process yeah so anything regarding standards it's also important to just keep in mind that module modularity fundamentally is about upgradeability so if you knew that you know the way things are is exactly the way things are going to be forever you might as well just write the whole thing in spaghetti code because it's faster so the when you have questions of the form you know should X be lumped into object a or should actually lumped into object be one of the things to think about is you know what what category of those objects do you expect to be upgraded more frequently what category do you expect to be created or destroyed more

frequently so with tokens for example we're going to see you keep on seeing you tokens being issued over time you have a question of you know do the existing tokens that get issued are they going to like are you know who is who is going to be upgrading them is anyone supposed to like have ultimate authority over them how are they going to be upgraded is it just going to be some religious creating new proxy contracts for each new standard might actually be a pretty ain't pretty decent approach another question then you have the question of you know when when are what is the registry going to be upgraded so for example right now we know that tokens have names we know the tokens might have you know decimal places well

guess what ether has you know six sub denominations and you know eventually people are going to decide that they want logos and maybe the fad in 2017 is going to be logos that are in it in the form of mp4 videos so them it's sort of importance to figure out I know exactly whatever standard we take how that's going to handle those kind of situations what one thing that touches both registries and tokens is named registries and I think this is a quite challenging problem because whenever you have a system that registers human

meaningful strings there's gonna be questions about economics because these things have value they have different values for different people you have things like name squatting which is a huge problem in a name coin for instance so so this this is something that you know we should be thinking very carefully about and I think you Gavin have thought about auctions in the context of registries etc and so just you know putting it up in registries they serve essentially two purposes which is providing additional

information additional metadata but also if there are scenarios where he wants something like a namespace for certain things to exist like if we if we eventually want a system where like one name which has the namespace in Bitcoin wallets then you want that interoperability to exist in all the Bitcoin wallets so then there needs to be like a community decision to gravitate towards a certain namespace for certain things and that's probably more difficult thing than just the fact of registering metadata in one of opinions of that yeah well I kinda want to go inside track like I think before we can start talking about more like

application level standards we should resolve things like what is the correct way to deal with the NS because in the current standard it's like half you know return value vm check and on the other half don't have that so I'm assuming there's an exception being thrown there and this actually is i think in all the standard or all the proposed standards right now so something like that and then maybe some standard design patterns for up ability like they were saying once we get those done I think will be much simpler like I think the standards will just emerge naturally like a couple of people will make some great wallets with decent standards everyone will want to be compatible with that wallet and that there is your standard like it won't change until someone makes a better thing I really agree with this you think it will evolve naturally like Twitter

took on other things to run if somebody does something which a lot of people like the way it's done they will adopt it and it will release become the standard and with time so but I really would like for now because we are very early in this game to have like more community approach bringing in ideas I mean this can be a lengthy process and it can't be like a like discussing sometimes take time and maybe they'll eat somewhere in this stuck path but it's about like bringing ideas together and because so many things we can't think of even yet where this is going what all will be necessary so everything we come up probably will maybe be very simplistic from head to what we need at

some point yeah I think one of the one of the things i want to point I want to make on that is the way the current standards work is whoever edit the wiki the last time and I think if it was very great I think we can move towards just it doesn't have to be very complicated we don't have to put up mailing lists and like get a committee on things in whatever but I think it would be great if there's a sort of a stamp of approval from various poor people that this this feels like the best approach at the moment but we could we could like make a discussion on read it and get a lot of people involved to see what they think so so having actually I think the good

idea would be actually using gist because in this you can comment on the gist and then it moves to a wiki right now kind of like it's a little a little bit like a Wikipedia edit war kind of thing not not that much but bit yeah this is definitely having places where we can bring together examples and have to have these talks okay I think the last topic before I think we end up ten parts i think will be I think they're probably people have some questions so I think one last thing i want to touch upon is do we feel that there should be a more like formal process for defining standards and maybe

into the future not not at the moment i think at the moment it's sort of nebulous and and and and growing organically but you know bitcoin has the improve all process the books right is there something that currently exists in the hearing community or is there and is this something we need to consider more yeah so there's quite recently I think it's a couple of weeks ago Martin set out the eip so okay great yeah and and there's a wiki for its well information about the okay well that's that's that's great then this is read about the theorem protocol updates but one can think of like for all kind of things but

right now I think it's like you say it's very early stage it's very much or exploration pace so I would it's a lot of things like trying things out and and see what catches on maybe it's about who I mean we can make up a standard if nobody follows is that systemic written right yeah I definitely think the Darien foundations role should be like facilitating discussions and all this and not defining standards and definitely not like creating apps then you have to follow those standards because that's the official one you know like yeah again there's about five minutes left I think we open up some questions over there 15 minutes left okay well Viper some other address yeah basically the

fundamental issue here is that caught the call code operator maintains all the same state except for the sender so it sort of just barely doesn't satisfy the role that we work that intuitively it's supposed to yeah something also something we have with the wallet the wallet currently actually uses subcontracts so it's cheaper to deploy 120,000 gas versus 1.2 million gas so we have one code base and we have two subcontracts they use core code and the problem is inside the actual wallet it is method sender is actually the calling contract and not the one who actually initiated it or the one proof before and this basically makes call code not neutral and really like a bit destroys

this library functionality so I really would love to see change here um so one of the other things that's currently not possible if I understand correctly is accessing further down the stack of message sender is that an option for future evm upgrades being able to actually trace your way all the way back to transaction origin yeah it's it's something that we're looking at the argument against it is essentially isolation there's a notion that you know the current executing frame on the stack shouldn't really be possibly prejudiced by previous stack frames because it breaks the notion of Irvine capsulation shouldn't transaction origin be excluded

and in principle yes but there is a slight difference in that a transaction is different to a message so other questions so one of the arguments for for the registry against keeping meta data inside contracts is really how does the contract we will register itself because either we have to register on the contra when the contract is lunch meaning that

if you have a register that exists after the Contra has launched the contract can can't register itself or the contract must have some sort of way to pass on arbitrary messages which might add some complexity that something like a token contract minot might not necessarily have which then gives you have the problem of who has the right to pass arbitrary messages so if at all if a token I mean how would the token register itself and who do who would have would be owner of the token if the token has no owners two major categories of solution of ways of solving this I think one of them basically is to say

that you know currency is just earth tokens have to build in some mechanism it doesn't have to be standardized you know in order to allow some particular administrator to keep on updating registry data if they have to and or you know all alternatively you could just say that the the token just calls the method once an insignia code and it never does it again the other approach is this proxy contract route which basically means that you know you start off by just having the token follow whatever the API was at the time and then if a new standard comes along or you know if he wants to update the registry information then the way you would do that is by creating a new token

which is really just a proxy pointing back to the first token and then all that that new token is is basically the same thing as the original one except it has a different interface and maybe different registry data to it so that's like one potential way of making things more modular it's gonna say like if you if you don't know it had a basic there's two categories there's like immutable contracts which basically know exactly what they're supposed to do ahead of time you write the code and there's no back doors or anything but then like if you have even one use case where you might need to do a proxy call then your contract becomes you know you don't it could do anything and so then it needs a got a governance model basically so the answer to that is like if your if your

contract is doing arbitrary behaviors then yes like it you need a governance thing and that's a separate problem altogether yeah the only thing I that if if the notion that actually we're going to say all tokens could in principle become proxy have proxy sort of facades in front of them and this can be added for all possible all eventual improvements to registries then we've got like this order n-squared issue where you're forcing all tokens to support all registries whereas so you're going to end up with like N squared facades right whereas if we go for the the route of saying right well actually tokens maybe there maybe it's the case

that they elect to a registrar some third-party address and say actually this we're not going to execute arbitrary transactions in the future but this guy can actually update metadata on our behalf which massively reduces the attack surface and it could in principle be like a multi-party a multi sig sort of contract multi-party sort of stay call the thing where multiple people actually have to agree that yes this is this isn't just you know some dodgy troll trying to change your name to something something silly it's it's actually a reasonable and metadata upgrade thank you any more questions so how much do standardization

conversations today or how much should they be influenced by scalability conversations tomorrow so with respect to charting if we take some approaches to standardization that may not make sense in a sharted future just wondering that that's actually good questions all like if you have to register you have to token and we day it will take the like the basic like metadata off to talk now out of the contract to a registry and down in different charts would get more complicated yeah I mean I guess today exactly how the shouting is going to work exactly how sort of scalability and

2.0 is going to work is still very much a question of research we've yet to do any real modeling on on the on the ideas that we have and then of course there's still feasibility and implementation all the rest of it so I think it's still a relatively long way off and we probably should be focusing on real use cases today rather than put you know presuming potential architecture decisions that were going to take it maybe 12 years time I feel like it's kind of a case of premature optimization like you know we have this idea that oh maybe in the future they'll be different short so I I make certain decisions now that that's probably not a a good approach and I

mean I think with any future upgrades I guess what what they should just you know we can probably rely on future upgrade not directly breaking what works now and so you know if we create stuff that works now and and make sure that works I think it's I think that's good so yes there's always the possibility to basically copy a contract and copy it storage I mean it would be maybe a manual process or but

it will work so you can always like basically change it move it over you just have to point interfaces 10 to the new one yeah so in the worst case kind of the contracts contains either or any other assets you don't control right yeah but yeah you using winners into two contracts in a modular fashion is good incidentally those less particular argument is actually a very good reason why you might a very good argument in favor of different depths basically creating their own sub tokens I think that's it for this panel so I thank all the people thank you very much