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