[Music]
quick talk I think it shows expert I'm
actually not going to go that deep um so
I am a actually let me go back okay so I
think we should uh rethink some concepts
of the ethereum account model and also
the account models that we're using on
l2s specifically to scale this is a
forgotten mechanism to scale I'll go
into some things here
really quickly I think deterministic
State addresses and state access is
really important in order to accomplish
this um I think uh there has been
discussions of access lists in the past
that didn't necessarily get enough
traction um but this actually can uh
provide significant scaling indexing uh
improvements and security improvements
to ethereum as a whole um so with access
lists or account lists um you know the
state ahead of time that can touch this
allows for uh being able to uh do things
like uh execute concurrently um since
you know the different parts of a graph
of nodes that you are uh touching this
can be enforced by the runtime it
prevents any
overrides um for example if two swap
transactions are happening through the
same protocol um but the same token this
can actually happen concurrently so I I
sort of think of this as another
mechanism for Mex uh multiplexing
spawning parallel
processors um another way to think about
it is um knowing your IO ahead of time
um and or having a uh essentially a
built-in mechanism for um for sharding
as well I think this also works really
well for multiple concurrent uh uh
proposers um this kind of go hands in
hand it's really great um again I I'll
go into erc20 as an example erc20 um
sort of represents a massive Global
state that everyone can touch and
anytime anyone touches it this sort of
creates a global lock on the system um
and so uh you know I I sort of mentioned
this so um you know I'll go ahead and
skip this part um so this is like I got
this silly graph here but you can see
there's different parts that are being
touched um and in this case you could
split this up into three different
concurrent um uh processing um or
execution which um can actually make
things really interesting uh from the
side this is really helpful as well um I
think security and the data side like
once we're indexing and once we get
things to scale and get really really
fast these are things we think about we
don't think about this a lot currently
um in the ethereum ecosystem I I think
there's maybe some exceptions tjs here
um but as as things scale really big and
we get to the point that we're dealing
with like hundreds of thousands of
transactions per second across all the
l2s um actually having mechanisms that
inherently provide better indexing uh
via the account model can be extremely
helpful um but again approved pattern on
erc20 is I'm just giving specific
concrete examples obviously we all know
it's a disaster um you don't know ahead
of time when you look at the shape of a
transaction um you don't know what uh
what accounts will end up being touched
you don't know where the funds can end
up being spent um you don't have a
deterministic way to know what reads or
writes are going to happen if you know
this ahead of time um then this actually
prevents a lot of safeguards that you
have to do on the contract layer um and
this is what I call an account Centric
model um I think we've seen this in uh
some of the concepts of like uh move
ecosystem um I think svm has has done
this there's been some experimentation
with other models as well um and varying
parts of them are are um are interesting
so um this also helps for things like
memory Pro programmatic ownership
patterns memory ownership patterns
across different um levels of the stack
when we're calling um when we're uh
calling between different contracts so
um yeah so uh also it's really fast
pre-processing level from security
perspective um I think what's going to
happen is we're going to have a lot of
wallets that are going to look at the
fingerprint of a transaction ahead of
time and let you know without processing
on chain um or simulating on chain um
what are sort of security uh aspects
that that could be uh vulnerabilities
and so this actually makes this really
clean this is where you can have like a
easily readable format of what your
transaction is about to do um yeah
that's uh that's sort of the the thing I
I'm all for State access lists again um
I'd love to see this come back and have
this as part of um mechanisms to make
things run concurrently on ethereum and
the l2s and scale that um that's all any
questions
okay okay thank you L um do we have
questions okay I saw your hand
so that was good so yeah I have this
question like there was a paper
published maybe last year about uh like
access list by uh some people at it and
the outcome of the paper is essentially
uh the discount is not high enough many
people who are using access list are
misusing it many clients are
implementing it incorrectly and so on
and so forth so what steps concretely we
should take to solve those problems
increasing discount or what yeah I I
think in general you need to enshrine
more into the actual consensus on rules
on how access lists can be used um
different different aspects like that
and then also from the security side
it's it's really important and then I I
also think um I I think that particular
study um looked at it comparing to what
the current patterns are on chain um I
think if you make the changes to have
have a model like this um some of the
programmatic patterns will change and
therefore will lead to scaling uh
naturally but yeah next
question
okay beautiful so the eth research post
or discussion that was talking about
State access list way back in the day is
cited by Fuel and there's been some
extra thought on that and some
developments are there any differences
between your absolute dream like you
know Pie in the Sky perfect if you a
dictator model of State access and what
fuel is currently running I think what
fuel is doing is elegant um so I think
it it follows a more account Centric
model it's like sort of like an a utxo
model is the way that I see it and with
utxo style models um you have better
determinism around accounts and it's
much easier to see what you're going to
touch ahead of time and what you won't
um so I think with regards to ethereum
um it'll never go to that stream um but
I think there's good balances to where
we can sort of keep some of the beauties
of the current account model but also
have additional speed and
security thanks last
question okay TJ
hello um can you just Define these lists
and then how do you calculate this list
prior to the transaction happen I never
understood that how do you oh okay um so
basically any state that you access you
can
deterministically write you can have a
hash that represents that state that
you're going to access for example um
and so uh anything that you touch any of
those um State locations would be
referenced via a list of hashes
essentially um that's one mechanism to
do it there's a bunch of different but
yeah how do you know that without
running um so you have to how do you
sorry how do you get that without
running the transaction um yeah so the
user would run the transaction ahead of
time right um or may run the transaction
ahead of time uh before they form that
and then um it's then it's enforced um
in the consensus protocol if that makes
sense so that means people who are
listening for transactions that are
coming in wallets that are um trying to
validate the security of a transaction
ction things like that um know that
these are the things that are going to
be touched and there's no like bit flip
that might happen that might suddenly
have it touch like 10 other accounts
that could end up siphoning funds or do
some type of bridge attack mechanism if
that makes
sense okay thank you so much let's talk
later thank you so much guys let's give
a hand of Applause for
Wales and thank you for your amazing
questions like I said it's going to be
interesting this morning our next
speaker is