welcome to the 8th to Q&A session
and what we're gonna do is I'm gonna add
some very very basic questions just to
get you all up to speed and then I'm
gonna open the microphone to the crowd
just a few things I'd so like the whole
thing about validator rewards and so on
I don't know if you want to like dig
into it otherwise you know I think it's
consensus that we can skip those
questions make sense yeah cool all right
so maybe let's start with Joe can you
give us an update I over they interrupt
locking and what you achieve and what
that exactly means so we had this
lock-in is what we called it it's kind
of a workshop for a week out in Muskoka
Canada and I guess we got somebody from
Muskoka here pretty so basically the
idea was that we like basically trap all
the developers in this place and make
them join our two cult and then we'll
work on our clients together and reduce
the round-trip time for communication
for everybody on getting their clients
to interrupt Interop is essentially
being able to talk over live p2p to the
individual clients and gossip baptists
stations and block proposals with
validators kind of like shared among the
individual clients everything that you
need without sinking and so we were
expecting I think eight clients game
seven got two Interop and that was
really exciting I think we thought that
there were probably only be three or
four that would achieve interrupt in
that time which means that all the
individual clients are really doing a
great job so
um I think that that gives us more
higher probability that will make some
early q1 don't quote that but but there
that's kind of like the idea right now
so where people are saying when they
want to see a beacon chained up and so I
think there's a higher probability of
that now so just to give an update does
everyone know what if two is formed by
how many clients we have and all of that
I'm asking the crowd because otherwise
we should give a primer okay like
apparently everyone knows all right so
um so I I don't know like so we have a
couple of the clients here we have meme
Nimbus we have lighthouse we I I just
like I can't these two specification
team we have a lodestar as well and we
have anyone else oh oh sorry yeah JD
okay
quills is here their prototyping phase
one and two all right which of the
clients is the one that's most advanced
lodestar does a really good job at fuzzy
tests and other clients we blow them up
like yeah lighthouse thought they
weren't gonna you know panic we made
them panic they fixed it we made them
panic again those are best lying a full
time
oh no that's what we got best in the
browser
all right the adieu the existing clients
here wanna give a really quick update
maybe we start with okay we don't start
with you yes
yeah nimbus first of all yeah thanks to
consensus and and the organizers of the
entropic was really really really good
to get together their work out a lot of
practical little details that have to be
worked out when you're trying to make
two pieces of software work you'd think
that it's easy like their suspect
everybody just writes the code and then
you know boots it up and it works and
that's obviously not the way it works we
have a pretty complex product coming out
and they're having very many basic
building blocks that have to fall into
place like that's the networking that's
the cryptography that's this pack itself
and I think really valuable was finding
out and using each other's clients as
stress tests as a first sort of fast
testing platform so that we could feel
out where the other clients have put
their effort the most and then that's
how we could improve our own client to
sort of match that level so I think
Interop was great for this we found lots
of bugs lots of issues lots of places
where
the thinking was not consistent between
the kinds and that was sorted out during
that intro I mean there was a lead-up to
the interrupt where were clients were
sort of pairing off and trying to solve
some of the initial things to make it
smooth right so that's that's probably
why we saw so many successes right on
the spot as well like yeah thank you
Artemis so after Interop we ripped out
our rust implementation of lit p2p were
the Java client so we went for the JVM
lit b2b that was built by harmony and we
put that in and now we're kind of
working on some sync issues and some
implementation issues to kind of get
ready we're turning our team over to
start working on a sharding client we're
leaving our beacon chain client with the
production team who's going to kind of
like get the more hardened for
production and yeah that's kind of where
we are we're going to work on a new
sharding client that's going to be built
in Kotlin just super set of Java and
also compiled to machine code notes sir
yeah Interop we started we kind of broke
into several different sub teams we're
working on getting lodestar kind of
productionize we have a lot of
optimization to do to really get to like
this production level that Danny was
talking about and we also were kind of
looking ahead at a light client work so
we start we've started to prototype some
of that work out and we're hopefully
going to start contributing back to the
spec a little bit
thank you that house we're going well I
mean focus at the moment is to target
feature completeness so phase zero
feature completeness we're getting quite
close we're just sort of polishing off
the integration to f12 the deposit
contract we're also working on some
slashing protection for validators so
this is kind of the idea of feature
complete being that we can run the
protocol we can we have everything we
need to run and we can run off the
deposit contract but not necessarily can
we run to say a year and use reasonable
disk usage so that's something we're
working on now is trying to figure out
how to optimize that database storage so
that so that we can run for a long time
yeah so I think the next thing for us is
we really need to start testing more
public test nets we need to get one of
our own public test nuts up and we also
need to start doing test nets with other
clients using the f1 chain as the source
of deposits so we can test this like
dynamic validator set because this is
the thing that we didn't test at Interop
yeah that's that's awesome we're we're
also really trying to help foster the
cool team to to make sure that they can
keep researching the the next phases
whilst still delivering phase zero yeah
so Trudy was a Interop we had a lot of
fun working with everyone since then
we've been just sort of merging in all
the things we found there nothing major
but just a lot of like tiny little
things as I'm sure other people found
the big thing arrest will be performance
so Trinity is a client written in Python
so well it's great in terms of being
readable and very approachable and
accessible we definitely have to deal
with sort of this performance penalty we
accept by choice so that'll be a lot of
our work moving forward for the next
couple months is making really fast
interpreter code well thank you I am
losing my voice so excuse me
so the quilt team has been focused on
doing research around phase two building
on execution environments and doing some
early prototypes on basically the
stateless paradigm so we are already
building execution environments that are
operating with in a stateless way and we
built a simulation within lighthouses
kind of based code base where we now
have shard chains or multiple char genes
interacting with the beacon chain and
we're able to actually run the state
execution on that as well and run these
execution environments on it as well and
so we have been I guess kind of what
we're doing next is expanding that to
include more simulations of what the
state market might look like
advancing on what may be ease for some
of those contract frameworks as well
yeah you guys want to give an update
yeah we're going on all sorts of things
adding add some additional tests to
phase zero justin Drake did some
excellent work making phase one look
really nice and easy to reason about an
elegant a lot of research and thought
and conversations around phase two and
more recently some conversations around
potential alternate structures with
phase one that might allow more rapid
cross-linking and better communication
between shards at the same time working
on some standards helping drive the
standards process on BLS Karl's been
looking into key store formats pushing
on the deposit contract stuff which is
formally verified and ready but we're
waiting on the be lost standardization
to launch that oh and opening up the
conversations around the coming public
test nets with
with the clients and always kind of
providing support and answering
questions on a client side so just
keeping everything moving forward yep
and I've been coming up with this
alternate structure is for faster
cross-linking that Danny mentioned that
we should have some information about me
maybe very soon also data availability
here there's a data field there's been a
lot of kind of progress on different
kinds of data availability proving
mechanisms there was also that
interesting coded Merkle tree paper from
Agra a couple of days ago that lets you
do I raise your coated roots with much
smaller fraud proofs which is also
really which was also really nice also
we're thinking about half fee mark it's
simple a simplification and coming and
coming up with ways to and deal with
edge cases and really real your markets
and all of those issues I guess I've
been thinking about optional upgrades
one of them is the idea of a secret
leader election so right now
beacon proposes and Shah proposes
they're known in advance that they're
going to create a block and then these
these leader based systems suffer from
denial of service attack surface and so
what if we can have a system where you
don't know ahead of time who will be
creating the next block that would be
much more resilient another kind of
optional security upgrade that I've been
working on for some time and it's still
ongoing and we making lots of progress
is the the vdf project to have an
unbiased ball randomness and I guess
I've also been thinking you know maybe a
decade into the future on on e3 and how
to make a quantum secure
at least ten years I'd say damn bonus is
30 Dan also said don't quote me on that
all right I'm gonna open up now to
questions from the audience I wanna go
first
you mean teaching a lot of work on
themarket one thing that I would love to
see is a bit of a high level abstraction
so that you can specify how fast you
want a transaction to happen like I
wanted to happen in a minute or five
minutes or an hour or I don't care and
then and then it builds you like however
much it should the market rate would be
for that right you could pay more and
then it would refund you the difference
because right now it's guesswork like
trying it trying to you know guess the
right amount of gas although the gas
this is the sort of problem that EAP a
one five five nine is meant to basically
eliminate like users would in the normal
case either transactions just included
immediately anyone else questions Oh
okay we have cable so can you come over
please - she actually have questions so
the number of straws i do - times we
start with 1024 so i'm wondering what
why - stitch number especially together
with a large number of agitators there
will be significant costs on camera
cause especially as starting of the
easter - is that concern that maybe we
may not be able to reach so many nodes
or validators at the beginning and so
this is one of the one one of the things
that this kind of faster cross-linking
proposal might actually end up changing
potentially but I think in general the
justification here is that we're trying
to kind of but there's two different
kind of constraints that we have one of
the constraints is the load on the
beacon chain so we want like the higher
the shard count the more scalability but
on the other hand higher the showery
take out the more cross links on the
beacon chain and the more expensive the
beacon chain will be the process in the
other constraints that we have is just
like the higher the total throughput of
the system the higher the harder it is
to be like to be a block Explorer the
higher the risk that some historical
data will eventually just end up being
forgotten completely and so forth
so the scalability that we that were
expecting like the data throughput that
we're expecting the number though like
we've committed numbers between 1 to 10
megabytes per second and that seems kind
of to be close to the upper limit of
people of like what people are fine with
so far and for the vote on the beacon
chain like we've done numbers and it
seems like beacon chain blocks can in
the worst case be verified in like about
us about a second now is it so yeah so
once again it's they kind of like that
much but not more sort of thing yeah I
think there was like four million
validated were starting to encroach over
a second so yeah I personally want to be
concerned want to be conservative or
speaking to a number so I kind wants to
I personally really wants to avoid the
mistake that we made of like in eighth
one where because the chain was heavy
like Sophie people wants to run a note
like I would prefer a beacon chain note
to be just a thing that you would run by
default rather than like running only
what you need it and that does
necessitate kind of fairly like strange
it performance requirements yeah I agree
things are the faster harder does to I
mean on the concern that that won't be
enough validators to start with we're
essentially handling that by only doing
the Genesis once we have sufficient
validators so will the current numbers
are 65,000 validators to Megan if
another idea that we're considering is
that even even if we go four thousand
shots in the very long term we could you
know we could slowly enable them
ratcheted up so start maybe with sixty
four shots and then over time have it
increased because at the very beginning
there's gonna be very little activity
and it might be worth using less shots
yeah speaking of block times or a
process block processing times it's it's
important to remember there are cases
where we have to process blocks which
are not necessarily good ones that might
be spammed might be maliciously
constructed that takes time away so we
need to have a little bit of a buffer
and that also affects the way that
messages propagate in the network so
we're using an epidemic network which
basically means that all the data is
replicated all over the network and the
longer it takes to process or the longer
full block processing takes the less
validation we can do ahead of time
meaning that the more risk there is that
the data that the network will be
flooded by bad data or that it will be
slow either of those two right so so
there's also that argument that if we
can do more good validation upfront and
still maintain low latencies we also
gain in other parts of the system as a
whole
yes I'm wondering what the plan is in
general terms for handling of VRC 20
assets in particular transfer functions
as a developer it's somewhat difficult
from user experience standpoint and
there's been many proposals er c-23 for
instance as an interesting proposal but
as we transition to e 2.0 I'm curious
what the general plan is for handling
those assets because there's just
hundreds of whom just migrating them to
two-threes and it sort of feasible
curious your thoughts so kind of
unrelated to the whole transfer from
thing which I agree needs to be reformed
somehow another issue another reason why
things need to be reformed anyway is
that assets are probably the major
category of application that we expect
like in any particular token will need
to be accessible in all shards like most
applications agree like realistically
unless you're in the top 10 you could
just live inside of one shard and you
could expect people to just move their
points to your shard do stuff inside of
your application then go somewhere else
but tokens need to be able to move to be
moved around everywhere and so like the
idea of a token as being a balance of
one particular model with a contract is
not something that can really survive
and so you'd expect like token Holdings
to themselves be more like individual
contracts and when like when that
happens you're pretty much like it's an
opportunity to kind of reform other
things about how the standard works as
well another question I had just to go
back to Justin you you just a minute ago
mentioned that it could start with 64
shards previously I hadn't heard this so
can you expand on that a little bit more
as to how that could happen because
previously the response was that it
you'd be under utilizing it but is that
really the only consideration that you'd
be under utilizing the beacon chain the
throughput that that's made available
why couldn't we start with the lower
number and then scale up what you have
like validators sitting out and not
really activated I mean the validators
do all sorts of things one of them is
cross-linking and so technically
speaking to reduce number of shards is
pretty trivial like
when they do the crosslink some of these
cross-links will just be hard-coded to
zero and that will this zero hash will
mean that there's no data flowing
through the respective shots but you
know these validators would still be
providing value for example they'd be
contributing towards the finality of the
beacon chain and all sorts of other
things I mean one one good reason to
start with lower shots is in lower
counties that you know maybe more
network stability we wouldn't have so
many short subnets that that's a nice
thing was also it allows for services
like like block explorers to give them a
bit of breathing space to ramp up to to
bigger numbers as to how we increase to
higher number of shots we can have some
sort of automatic schedule or we could
kind of push this to this also social
consensus layer with with hot folks so
this is a possibility that it could
start much lower yes and I think it's
the natural thing to do I think right
yeah yeah because I've heard for many
people and I'm sympathetic to the idea
that block space should be economically
valued or it has economic implications
and it should be valued highly and if
you have a and a bunt overabundance of
it then you end up devaluing the
transactions that are contained in it I
mean that's a good point if we have few
fewer shots in music that we can really
test the new you know gas market with
VIP one one five nine which by the way
is awesome it just seems to solve so
many problems
hi I'm Kent I'm the head of R&D at a
shape shift and I'd love to hear more
from you Vitalik about the use of phase
one and the data availability context
this excites me a lot because it seems
to me that a lot of the really vexing
challenges with e 2.0 are are in phase
two with the Chardonnay ease and
Crossgate trot cross during
communication this could effectively
really give us a very nice bridge where
we have layer two solutions with Starks
and snarks so kind of a two-fold
question to what what extent is the data
availability aspect being Specht out and
built with those particular use cases in
mind and also if you could shed some
light on the big research challenges and
questions as that aspect is built out
sure so their existing a scalability
solution already like plasmid group is
doing a demo of it like a theory I think
at Def Con they called them optimistic
roll-up an optimistic roll-up basically
works by publishing transaction data in
a very compressed form on chain but not
doing like the execution on chain and
optimistic because you avoid executing
you only have a little bit of data and
especially because data is relative is
very cheap relative to computation even
on the East one system you can achieve
scale a scalability of like 10 to 100 X
like the theoretical max throughput is
somewhere around 3000 CPS if like
everyone were to just use optimistic
roll-up for moving coins around and if 2
could potentially take make optimistic
roll-up even more powerful because
instead of using the ease one chains
data store off the store that's a store
this data to make sure that it's
available you would be storing that data
on these two chain and you would
basically kind of feed into these one
side merkel proofs that prove that hey
this data actually has been accepted by
youth too and so if you imagine like
even if say we reduce the chard kale and
some they're like even the scalability
at the beginning is toward the lower end
and say there is one megabyte per second
of data
then if we talk about say 20 buy
transactions then that's 50,000
transactions a second that could fit
inside of a rollup and that's and it's
like a system that could like the logic
for for kind of doing it is something
that is being developed already I think
the main challenge that would need to be
solved as AG you it needs to have at
least a minimal sort of fee market on
the youth suicide
so that optimistic roll-up real layers
would at least have the ability to kind
of pop publish their data and I think
that is one of the things we're actively
thinking about and the other challenges
if you do want to use phase one as a
date availability layer of on eighth one
you need to go down the finality gadget
road and expose it to data to state
routes to eath one so you can make
proofs against it so depending on as we
talked about in the last session
depending on kind of parallel roadmaps
and how long expected things gonna take
it may or may not be worth it right next
question
Oh Marty hey Martin
yeah so I came a little late so I hope
this question hasn't been asked if so
I'll just excuse myself but the question
is around the process by which a
particular execution environment is
chosen for a shard if there's like some
auction going on or renting that space
and also what might happen if you need
to change something about the execution
environment like forking it or something
like that look in all of the proposals
were considering so far I think blocks
would have the ability to contain space
for multiple execution and by kind of
environment spaces in them and so
basically like you would expect like
it's ultimately the block proposes that
chooses what to include and different
people it would would be able to bid but
like you would expect
I mean if at least popular execution
environments to have a presence and be
executed even in every slot in the show
the shards in in which they're located
to be clear the execution environment is
defined on the beacon chain and thus
available on all of the shark chains and
so when you make a block you're kind of
signaling this block is for this
execution environment and thus the data
in this block or chunk of data maybe
multiple is for that execution
environment and so you can kind of think
of say this this block was for execution
fire in a this block was for execution
of IRB and the next one was for a like
the actual blockchain of a is like this
this subset of the the actual shard
chain and on the forking I think so the
nice thing about it is you could
actually define migration paths such
that you could deploy a new Yi and have
some sort of migration from previously
to new Yi and I do expect these things
to kind of emerge in a standards
standards way kind of like in the ERC
standards but I could also see that
certain ease especially like the eath 1e
could still maybe be subject to
hard-working to upgrade and manipulate
depending on the kind of social dynamic
remnant yes yes so I'm saying that would
be a like to actually change in EE would
require kind of changing changing the
actual code of the protocol and an
irregular state change there are options
to migrate an upgrade ease without doing
that but there it might still be like a
social tool to coordinate and manipulate
these things will the E's be
permissioned or like is you're not gonna
so if you want to add a new EE do you
need to fork anything or can you just
add new use transaction for your deposit
requirements so we do the beacon chain
doesn't get filled up too much but like
anyone like it would be able to do it
you're not optioning them like some of
the guys and as are you expecting
applications
expecting applications some of the
bigger ones to have their own EE
yeah possible some a lot of a lot of
like the reasons you might have an e
like it doesn't actually make sense and
it might just make sense to operate
within an e but I do funny that you
asked that I have thought it could be
like certainly an a way to advertise
like if the casino has their own e come
join us gaming e I mean there's probably
some yeah some data that we would want
to store that no one else wants to so
yeah or maybe not data but more like how
you optimize the structure of accessing
certain things in a fraction of a second
block time would be really good yeah I
think it might be like another tier of
developer that makes an EE it might be
someone that's working really deeply in
protocol research or like zero knowledge
proof research or something they really
know what they're doing and they can't
do it anywhere else and then they'll go
to that but then you know like kind of
typical developer that's at the
application layer would probably want to
stay away from it any other question
from the audience I mean while we're
waiting for a question I mean maybe it's
put a bit of cold water on the
like I mean it's the ease of a beautiful
piece of layer of abstraction and very
useful in the context of migrating in f1
into if - but there is also the
possibility that you know E's you know
add extra friction between them in
addition to the friction between shots
and you know there's also the
possibility that we'll have
unsustainable ease so ease for example
without statement similar to what we
have right now and if one and if they
become popular then you know it's all
sorts of complicated questions so it is
possible that at least in the short and
medium term we will roll out with some
sort of default and shrine de some sort
of you know native if tui which just
acts and behaves like somewhat like if
one does today and you won't have that
much room to play with in the medium
term and then in the long term we open
up the ease to everyone rate but how do
you manage that process of opening up to
everyone right well that will happen
under consensus layer and one day we say
hey anyone can can publish an e so you
know going back to the permissioning
question maybe they you know no one will
be able to publish is for some time I'm
not saying it will happen there it's a
possibility
all right questions how much thought is
there been to a transparent sharding
where that developers don't have to UM
figure out which are they want to be on
because if you give them that choice
maybe they all just all choose to be on
the same shard
I mean that's one of the really good
benefits of opening up two E's is that
all this innovation on transparent
shouting can be done at the application
layer and assess consensus like
designers we don't have to bother about
that and so if if you nail polka dot or
whatever comes up with some cool
innovation that can be integrated with
very little friction and there's already
ideas out there for
you know using the shards as you know
fungible data availability resource that
can be used and kind of decoupling the
the the logical centralization of the
application from the underlying resource
which is shorted who decides where the
application goes like does the
application get to decide what shard it
goes on or is it do they have no control
over that I mean at the lower level the
every de lives in the beacon chain and
it's made accessible to every shard but
then you know then it becomes a question
of for the dab developers how do they
want to you know I've you know restrict
themselves to a specific shard or have
some sort of virtual or virtual virtual
execution environment which is separate
from the the consensus level concept
also within e development there's
there's a few things you can do and you
know when when this opens up as well I
think there are a couple questions so
one one question is do you have to
deploy to the beacon chain and do you
also have to deploy to multiple shards
or do you automatically have it
available across all the shards so
that's one piece but also within your
execution environment you could
technically build some basic level of
scheduling yourself as well
saying I will only operates or in you
know certain transactions on short five
four
you know this series of epics or shard
five six and seven for this series of
epics so there's a lot of flexibility
and how how you can write these and how
you may be able to enforce the load
balancing yourself just within the
semantics behind an execution
environment
are we going to retain the financial
Lego that we've got a plug and play
between composability
that are we losing that or compromising
that with the sharding from a tooling
perspective well right now you can you
know you can plug compound and die
together or something if you don't know
if your Lego blocks are now on different
shards and they can't interrupt without
cross shard links which might be slower
and have some penalty I mean I get the
concern but I think all of the kind of T
Phi integrations like for just as one
example I've seen in practice I don't
think any of them really break from me
synchrony one of the reasons why is that
half of these integrations just happen
to do with like one system containing a
token from another system but tokens are
a thing that's like they've probably
easier than anything else to move across
shards you just like yank the contract
over and like one one myrtle branches
and it's like somewhere else wherever
you want it to be him I think the thing
and then if you look at like even unit
swap for example just moves tokens
around you move the token to the unit
swap shard swap it move a token
somewhere else so most of the the
integrations do kind of work like work
that way the ones that don't are
basically the ones that involve kind of
synchronous we calling other Apple other
applications but like even in that case
a lot of a lot of the calls are AC like
dude tends to be a a synchronous or at
least would be perfectly fine if you
didn't move in did them in an
asynchronous way so now we start given
the applications that we know about I
think that's a you kind of like a
smaller risk that a lot of people think
I mean I could see like execution
environment fragmentation being in up
even a bigger issue than shorter than
short fragmentation if not handled
correctly and that's it's definitely
something that we're thinking very
actively about how to smooth over and I
mean concretely it might turn out that
crush team communication is actually
faster on if - then you know an f1
transaction if one on average is 15
seconds and you know two ways that we
could have fast crushed our
communication is one we have this new
proposal where we have cross links in
every slot on the beacon chain you know
we might have crossed cross link regular
collaborate and communication in just
just a few slots and then the other way
kind of which is generic is to use
optimistic cross links where basically
you have some sort of off chain
mechanism to gauge the probability that
some cross link will eventually make it
into the beacon chain and get finalized
but you don't have 100% probability that
will happen and then you you can design
your application around that and benefit
from the low latency can you do any some
kind of automated garbage collection and
start moving smart contracts that want
to be on the same chain together so that
they're faster so I think the space the
cross interaction around multiple shards
I think there should generally be a set
of tooling within the hll sort ESL's
that are used within solidity viper
anything else so from a developer
perspective if you accept asynchronous
as you know a basic concept construct of
communication across shards you can have
tooling that does that through message
passing
you could have tooling that does that
through you know two-phase commit you
know system if you need some type of
atomic transaction you could have you
know tooling that so I think from a dot
developers perspective you're going to
have more tooling in these languages
that you would
go ahead and and utilize for the problem
that you need so yeah the archive notes
look like forth to and our blog
explorers ready for this if you're a
blog explorer you would pretty much have
to download every blog on every shard
which is one to ten megabytes per second
x 86,400 and we're talking 80 to 100
gigabytes a day so it's like you have
you have like more hardware requirements
and then of course so that like that's
one issue - hi Ricardo requirements
going up in another issue is that you'll
have to deal like I kind of understood
with you to basically more things or
being kind of lawyer to a fight than
before so if you have execution
environments and then within execution
environments we're also planning to push
forward on transaction abstraction and
so now you don't like you don't have yo
ways and contracts as different costs of
things anymore and then you have crossed
our transactions the different ways of
implementing them and so your
responsibility to and have understands
popular layer 2 protocols will
realistically end up increasing and
that's another thing that you might need
to what that you'll probably needs to
watch out for so I guess you know in
general for being a general-purpose
black explorers like realistically is
one of the things that will get harder
all right we have time for one last
question
make it quick so as a DAP developer that
has an IRC 20 asset is there anything
specifically we should do or maybe not
do right now no I mean in the in the
future when I think I'm inclined to just
say like don't don't think about the
problem now and like in the future as
the X execution environments and if
start becoming more nailed down then
you'll be able to have think more about
like how to design design the kind of
token and like application specific
details around across shard context but
no migrations like there is a
possibility you'll have to do a one-time
token upgrade but that could also be
done with a wrapper
knowing that tokens are the most used
function in the current chain is it not
worth considering hard coding them and
by making them much more efficient than
they are right now or taking a snapshot
potentially what hard coding make them
more efficient well because right now
they execute code just to do basic
functionality of the token the cord is
like fairly is small right like
execution of EVM code is not like a
dominant factor of like watching over
and overhead time like the one okay so
the thing that I would look into like if
we wants to like really optimize tokens
have only things that I would look into
I mean one is to just like review like
the whole year see 20 transfer from
architecture and like think hard about
do we wants to build into a much higher
level of language standards a more
explicit like pay for token with
function calling em strategy another
thing to look into is that actually one
kind of functionality that I think well
light will likely put in is the ability
to store pieces of contract code on the
beacon chain and then have the ability
to just reference them by address and
this would like this would prevent
things like account abstraction like
tokens not being abstracted and or token
it's already being abstracted
all these other things from blowing up
witness sizes because you know instead
of having a piece of code in your
witness you'll just be able to point to
an index so a lot of those games have
kind of been factored into the existing
design already another thing to look
into either would it be I know
redesigning user accounts so that you
would have the benefit of kind of being
able to like you would be able to get
the efficiency benefits of being able to
hold many units of a token within one
particular package that could get passed
around between shards but like there's
trade-offs there right because from a
privacy point of view if you want to
improve your privacy it actually makes
sense to kind of separate out all of you
all of your token holdings from from
each other and even have multiple
accounts per tokens so it's like in
general I feel like there's a way like
the optimizations are needed but there's
generally ways to make the optimization
without enshrining too many things it's
important to note the the notion of
owning ether actually becomes a layer
two concept in ease so the only thing
that owns ease is the actually easy has
a balance and then there's some sort of
presumably some sort of account model
and state model within that ee that's
defined that allows you to actually have
a right to a portion of that either and
so we've actually instead of enshrining
tokens we're not like d shrining either
within within the alright we have to
stop here sorry everyone do you want to
talk less herded coded things at the end
of the day is better you know so I'm not
having like a yeah you know like a ERC
hard-coded just gonna be better because
less hard Forex less nonsense to deal
with from a p.m. perspective
you