foreign
[Music]
wants to talk about an EIP just like
raise your hand so we can like roughly
keep track of time one okay if you're in
the back it's not going to happen you
need to move forward yeah
okay so sorry I I didn't count because
these guys again again okay one
one and a half two three four five six
seven eight nine okay so we get like
five minutes each it's hard to like cap
that
okay I can like keep the timer yeah you
can roughly keep track of time should we
start
yeah okay yeah um okay I'll start I'll
start on this side
okay
hey guys
um I'm Sarah I'm a smart contract
engineer at uniswap
um and I'm here
I'm Mark and I'm a protocol developer
from optimism
and um so we're gonna
we're in we're done should I drop the
mic
um cool so we're gonna kind of tag team
this EIP today
um yeah first of all I want to thank you
guys for hosting the session I think
it's super important that you know when
we're planning for building open source
software we're really bringing a lot of
diverse perspectives to the table
um you know I think it's you know a lot
of times client devs and core devs were
you know focused on this really
long-term vision for ethereum and
unfortunately for application developers
that means some of the stuff we want to
see does not get through
um and so hopefully I'm here today to
convince you that this is worthwhile and
actually this EIP really will complement
the kind of Future Vision for ethereum
um so let me hand this off to Mark to
give a little a little rundown
okay so we're here today to talk about
EIP 1153 which is transient storage and
this EIP adds two new additional op
codes to the evm and this concept of
transient storage which is basically
like a key Value Store per account and
anytime that you um you know UT store
your t-load which are synonymous to uh s
load and s store but you instead of
putting in a state you put it into this
transient storage map and each one is
namespaced by the account and it
persists throughout the duration of the
single transactions execution
yeah and so so actually we have this
concept of um you know kind of storage
is used sometimes in a transient way
right now in the evm you can see this
sometimes with like re-entrancy locks
right so this is when we clear a slot
back to its original value before the
end of the transaction and then you know
we're allotted some amount of of refunds
um and you know to achieve transientness
in this way is actually quite messy
um from you know the developer point of
view
um you know it's really not
straightforward you know how the
accounting will work for this
um especially because refunds are now
capped
um and so you know enshrining this
directly in the evm is is a more direct
uh kind of use case to get transientness
um you know also developers are kind of
having to go and do the sort of messy
implementation where you'll see a lot of
times like you know one zero one instead
of clearing to zero we're clearing to
some dirtied value because as we
actually end up getting you know more
refunds in that case and so it's really
the sort of patchy way of achieving
transientness in the evm and so kind of
the way that that we look at this EIP is
actually sort of a cleanup it's it's
relieving some of this Tech depth here
um because this is a real use case and
it is wanted
so one really cool side effect of this
is it actually helps a lot with
parallelization because
um you know we want we want to scale
ethereum we want to increase the
throughput of the system and we can do
that by paralyzing the evm and right now
anytime that there is
um a lock taken in a contract it is
writing the storage and that prevents
parallelization of that transaction with
other transactions that are trying to
interact with the same contract so if we
move all these into transient storage
instead then we'll be able to paralyze a
lot more transactions and it's important
to try to get this change in sooner
rather than later so we can start
adopting this pattern now and have more
of the network using this kind of way of
doing locks so we can have more parallel
execution in the future
another problem is that it's really
difficult to know how much gas or how
much gas is going to be used when you're
allocating memory because there's this
like crazy non-linear function
so this makes it much more
straightforward because every you know
t-store uses the same amount of gas so
it's easier for a developer to like know
how much gas they're going to be using
when they're writing their smart
contracts
cool and kind of on the on the last note
here I just want to re-emphasize that
this is not necessarily an addition to
the evm it's it's really we're thinking
about it as a cleanup a cleaner way of
of achieving this use case in the evm I
also want to point out this is a really
siled change it's two op codes it's
easily testable
um and uh also benefit it's already been
implemented across four clients so
nethermind Bay Zoo ethereum JM or
ethereum jmbs and uh also Geth is
implemented we've also written tests for
this they all pass
um and so the kind of the final ask
today is to just really get some more
client Dev eyes on these PRS on the
tests we've written and to actually kind
of seriously open this conversation of
having CFI for 1153 in Shanghai
um thank you
I guess just to make sure we have time
like are there like a couple client devs
with strong opinions about this we
probably can't do everyone but uh okay I
know first I have a minute opinion on
this I think it's awesome that people
from outside the core team are not just
riding the spec writing the
implementation but also writing the
tests I mean big round of applause
[Applause]
[Music]
any other comments
Peter so
um only know just FYI I do like the EIP
however
um I kind of have a feeling that the
russianizations are not necessarily all
equally valid with the parallel
execution I think that's kind of a far
away dream so I I yeah
I mean essentially every time you
execute a transaction you will touch
some state so if you touch the same
contract you will touch the state some
State anyway so that I don't think it
helps there however I I mean personally
I think it might be nice one thing it
would be
yeah let's just keep it at that
I I don't really see the point but I'm
also not a not a not a contract
developer
um it seems to me like a nice to have
but nothing that's critical for for us
right now
so I can read about that one of the one
of the points that I do like about it is
that with the with these mutexes
essentially it touches the state and
even if it does nothing just flip some
bits back and forth it still has to
touch disk and this would allow us to do
these things without touching this so
that's a net benefit for me
have you talked to the solidity team yet
there is an open draft PR with the
assembly op code in the solidity repo
right now
um yeah
I see like it's really parallelization
that has been quite a lot of work in
analyzing how much the transaction can
be paralyzed and even at flashbots we
were running the analysis of the
of the clashes the bundle clashes the
transaction clashes so something uh any
improvements in this would would be
quite nice to see there are some
Builders there like I've seen actually
the the modifications to get that were
introducing parallelization and they
were working and I was really surprised
like how some developers were able to to
do that in their own in their own
implementations just for the simulation
efficiency
uh consider already gains from
paralyzing transactions such as the the
implementations are so complex and so
specific for for searching uh that they
are not coming to the journal View
uh so it'd be great to see that uh I
think the pitch was really great
so I I was not considering this one
because I was always thinking that
anything that was touching the storage
was awful amount of testing and huge
risk of of something escaping and and
some contract breakages so so this is my
biggest worry like we were modifying the
cost of storage in the past we're
modifying the behavior of refunds
um and this one feels a bit like that
like when you say oh it's uh it's a
known cost but do we do we cup the the
storage okay I see yeah refunds are
capped
nowaday they started transition storage
because if it's not capped it again it
should be exponentially growing and it's
it's the same it doesn't exponentially
grow but we looked at it to see kind of
you know the upper bound and it seemed
like it was safe
but it's the same with memory right
yeah so with memory we have the
exponential cost and here we have the
linear one yeah
so I guess just to wrap it up sorry but
like is there something that any like we
have tests for this we have
patience
I guess my question is like from the
client teams very quickly is there
something like you want to see from here
like a big open question you have about
this Daniel you have the solidity
question but like yeah just to wrap it
up anything
you wish you would see from this that
would help you better understand
do you have uh tests or benchmarks for
like
just writing as much uh to the storage
as possible writing in uh in like small
chunks into it doing uh doing separate
calls into different
um different contracts that each write
their own I would really like to see
this
yeah there's an open PR in the ethereum
test repo I think most of those cases
that you just said are covered I haven't
looked in a bit but um
yes re-entrancy I think is covered
um I'm happy to share that out with with
the wider group but there's extensive
tests
something that I did want to do is use
Felix's mem size library and basically
just like look at the gas limit and just
like you know fill in as many things as
possible that would fit in the gas limit
and then like observe the size in the
implementation itself
um I have that like on my like computer
someplace but it's like not really
pushed but that is like something that
we could add add to make it better
wrap this up to the next one oh one last
question okay I just had a comment on
this already depart
um adding it to the assembly well the pr
there wasn't a PR we just edited it but
um it's easy to add the op code and you
can use it in an inline assembly
um and if the AIP goes live that's going
to be added like instantly but adding it
into language is going to take quite a
bit because it's a lot of changes
um I don't expect it to to happen
anytime soon
um so if you guys want the help in
implementing it which may take like 1000
signs of code
um that would be welcome
okay we need to wrap this up I'm sorry
but uh Igor you're up next
thank you
my name is
developer and I'm here to Champion EP
5978 Untitled guest refund and reverse
some motivation for this Eep is that
revert of a transaction or any its sub
calls drops any state modifications
but the user has to pay the full price
for the state modifications while
with State modifications are not
preserved for forever and this has two
problems with this is that users overpay
and then it limits some solidity
patterns where you may may have a call
and revert it and it makes it extremely
expensive to the point where sometimes
instead of reverting the call you may
just like transfer easy tokens from one
address to another just to like restore
the storage instead of uh paying the
higher gas price of reverting the call
and in my opinion it's an anti-pattern
because some side effects can be missed
and it may result in a critical hacks
and lots of funds eventually
and vcp suggests to reprise the
following op codes as a s store create
so so distract through the gas refund
mechanism so they're not going to be
free still gonna pay some price for
touching uh with addresses or storage
variables but it seems unfair to pay a
full price vcp is a in a in an early
version
so I just want to spread more awareness
around this problem and hear what kind
of comments people have thank you
uh question uh I'm maybe I missed
something but um is the suggestion
essentially to reprice some of the
storage of codes
and let's say sloth is
sorry for the clarity so if let's say if
s load operation
store operation inside the reverted
transaction
uh costs 22 000 and then with some
we score reverts then the cost of the
separation should be repriced as just
like a attaching this load for
a different number so you should not pay
twenty two thousand for modifying uh
storage slot which is not modified at
the end of transaction
and the pricing should happen through
the gas refund mechanism
uh does it bring any clarity
foreign
idea so um
it mostly means you would need to
remember all of the changes you've done
and then it's like single point on the
reverts goes you would need to go
through all of the changes and apply a
compute at least the refund you you get
from that so like you have like single
operation that it's actually like
unbounded in the complexity internally
and that might be like doable if you
have this journal Journal implementation
of the state because you do also there
like on journal the the changes but if
someone has different implementation of
that it might be really difficult to
implement
and just one more comment that um
usually with when
reverters you can actually have nested
reverters and you that can end up quite
nasty when you have subcodes that revert
and the outer code doesn't revert then
the outer cool again reverts so
it's not a very very easy EIP to tackle
it might not be too hard but it's I
think the reason about it is not
necessarily easy
yeah I think that if if like that is
assuming that we have to keep the
journal all the time and use it for all
all the other apartment operations and
uh
it kind of this idea fits into that
perfectly I think that might be
considered but if there is something
that you would need to keep different
data structure just for that I think it
should be really difficult to have it
and I know some of the implementations
actually don't use the State Journal
light I mean that's not something we
mandate to to be used
so you would need like in other words it
would be forced to keep something like
that anyway although it's not required
uh in particular right now
you have to keep track of a whole lot of
information for um
for the uh for the refunds anyway for
the for the storage refunds anyway so
it's the same stuff and all
implementations I think whether it's
journal or cash you have all the info
you need
um but I'm just still
traumatized by some of the code I had to
write for the um
for when we were doing the the repricing
of the the 2200
um I can't remember exactly the name of
the of it where it was over fitted
fitted to get and
um our code analysis tool freaked out of
the complexity of the code so I'm kind
of concerned about that about the
maintainability of some of these I mean
I was implementing the algorithm as
specified and sonar said that's too
complex you can't do it
actually
um it was it was the same uh EIP
transient storage
um so without maybe just Reviving you
know everything and reiterating
everything there
um it just just kind of adding on a few
points one
um you know right now some of the higher
level oh sorry uh background uh so I'm
actually a contributor to the Hof
language which is a low-level uh
Assembly Language and then uh formerly
um I worked with the superfluid protocol
and so I think I think both of these
could benefit from transient storage so
on the Huff side you know higher level
languages like solidity and Viper you
know they have these re-entrancy locks
or modifiers to facilitate re-entrancy
locks that you know are very well built
and it's very easy to build this in a
safe and secure way but when it comes to
assembly languages this is actually a
problem because if you set a lock in
storage and you don't explicitly free it
by the end of the transaction those are
now bricked which obviously you should
catch this and unit tests right but it's
just it's one more foot gun on the stack
um sorry to interrupt you I think you
kind of uh capturing the the governance
process right now because we already
talked about the CIP and now rehashing
the discussionist kind of I think not
great
uh so I would
if the if I would rather move on with
the next Erp and uh because we discussed
this one already
I do think though it is valuable to know
that like low-level languages and like
projects like this uh if you can like
write it on the eat magicians post or
somewhere
yeah yeah we could go we're not going to
be done already though
yeah sorry so I was gonna say yes we
probably don't have time to rehash it if
but it is valuable I do think like
putting it in writing on the East
magician's post is probably good to
document
um yeah sorry uh also the microphone
don't be scared it's mainly for Direct
ly okay cool cool sorry you had any IP
as well yes okay
um so I'm working on on 5027
um and also another VIP
5478 so I just discussed five zeros 27
first uh so basically it's uh aims to
remove the right now the contract limit
as 24 kilobytes uh that it was
introduced in uh EIP 170.
um so uh the reason is like I think the
motivation is pretty clear that a lot of
people complain regarding 24 kilobytes
contract size especially right now the
contract is significantly much more
complicated when EIP 170 was introduced
so the major concern of EIP 170 is
basically DDOS attack uh if a large
counter maybe fix 100 kilobytes that was
deployed on the ethereum damn uh if it's
just charging using a flat fee like for
example right now is 2600 then you may
uh specifically significantly under
charged so basically the idea is like
right now the solution basically is that
split the contract to multiple contrast
and then I call kind of like chain of
contracts so they can retrieve their
data but it basically make the whole
larger much more complicated so the
current my idea of solving this EIP
basically the DDOS tag the cup two
weights one is basically introduced uh
basically a contract called hash versus
the to the country size so when we call
our contract then we immediately to know
basically the size because size is very
small like four bytes number then we are
able to pre-charge according to for
example what the actual size of the
country is like maybe we can just charge
uh charge to
2614 per 24 kilobytes so that we are
able to basically have similar
um right now gas behavior of calling
multiple contracts but just putting it
in a single contract so this is one idea
another idea is we can if the counter
size is greater than 24 kilobytes then
we are able to append a size together
with the current 24 kilobytes and then
tells the what's the actual size it is
and when when the first time it costs
its first charge 22 600 about the the
first 24 kilobytes and then the
conscious size and then once we know
country size then we can further charge
the corresponding the rest of contracts
and then put in the memory and then
execute so basically this is the basic
idea uh when it takes a
explore the ebm code and also I have a
single basic implementation together
with some concerns of addressing one and
code storage and also be concerned of
the P2P package size because right now
we have a limitation on the P2P packet
size but with for example 50 million gas
block gas limit divided by 200 gas price
per byte and so the contract limit size
actually is essentially limited to 250
50 kilobytes so right now that's still
fit into the P2P package so the
basically there's a couple of concerns
that regarding this if we are able to
remove this limit yeah happy to
so um there's also EIP 3970 not 3978
um 3860 which is to limit meter and net
code which is like we got two
conflicting eips
um so I'm not opposed to changing the
limit but completely unlimiting it I
think it has issues
um I think it's Martin that has some
really glorious code that shows the
performance problems with the current
jump analysis on on
um the Legacy formats but another thing
to consider is what if we change the
code to required to be done in the eof
and it's the code limit it applies to
and then we could reconsider how much
data you could bring in that is not
subject to this because you're not
supposed to do the jump analysis on the
data the jump analysis is different in
eof2 there's not the same risks but then
as you mentioned you get into the issues
of how does it impact the storage
bringing out you know kilobyte not
kilobyte megabyte codes code out of the
storage
um and
yeah I I think the unlimiting is going
to be a hard sell I think changing the
limit I think is going to be an easier
sell
I guess my question is kind of similar
to this that uh
saying that 24K is too small
I can definitely accept that I think
that's a valid concern my question is
what is reasonable because if uh if you
go towards saying that well it should be
arbitrary large and it will get so
complicated that it definitely won't
ship but for example saying that well
let's raise it from from 24 to item 64.
that's that thing can be analyzed there
we can put the number on it it doesn't
mean that it won't require additional
changes but it's relatively simple to
understand the implications the moment
you introduce these Dynamic changes I
think that's that's not really Gonna Fly
it's going to be too complicated in my
opinion
um yeah
um so because I do some experiment and
and using a code so right now I feel
like pick some instant synchronization
and put out some deploying a lot of uh
like some 200 kilobytes of contract on
top there uh it looks like everything is
working fine on my test net
um so uh has been running for
um more than half years
um
yeah especially like right now in the
gas regarding the jump analysis right
now the glass metering is charged for
2600 per 24 kilobytes which essentially
I think the same is equivalent to I call
this contract and call another one this
Country Corner another one so basically
I charge this the chain of this calling
to in a single but you see using a
single payment so so if we tie this to
eof
um you can have larger contracts if you
do it in an eof container we
simultaneously solve the jump test
analysis problem and uh reasons to
motivate people to use eof so I I think
there's a lot of things we could combine
and trade some horses to make this work
I I
just in my opponent trivia for why 24
kilobytes was chosen as well it was a
convenient representation I think it was
two to the six plus two to the seven and
at the time of the gas limit it wouldn't
have broken any contracts because it was
impossible to reach that
so I it's not possible to do this on uh
on uh mainnet right now and I think it
think it's also not possible to to
increase the code size
uh if you're a client stuff and
you're interested about my reasoning
come talk to me afterwards
um
what is possible is to do it in UF and I
think that's what you what you should
strive for uh do it any eof when we have
the
the jump test stuff cool I'll get us
commented just a tiny tiny bit of dot
comment you mentioned that you had to
test setup and running and it's been
running perfectly the with all these
changes the catch is it's uh the average
case we know that it runs perfectly
because the code is written well the
problem is how attackable it is and in
your private task that nobody is going
to attack it
cool thank you
um dang crab did you have any IPS do you
want to talk about self-destruct
who's the self-destruct guy Proto
okay uh hello everyone I'm proud of I
work with Opie lumps
um
we have this dream of serenity
Serenity includes proof of stake and
sharding
they have achieved proof of Stack I want
to continue with sharding I'm fully bolt
into the ethereum for this combination
not for one and not the other
and
I think right now the process that eaps
has been like kind of imbalanced with
the merge because we have a exclusion
layer consensus layer I think an EIP
that does both of these and actually
does touch on the testing infrastructure
is the thing we need to repair it
right now the merge was
I think still shipped in relative hurry
but with scaling we have actual
incentives outside of just client teams
to
improve this infrastructure to improve
analysis of ethereum to improve
integration testing and so we can get
the best of both worlds where we can
improve ethereum
and we can improve the process that we
have to accept erps and so that we can
be happy to
enter future erps without as much
concern because you have to write
testing in place
and then outside of testing and the
whole process just in case before it
prefer
if you're not familiar already before it
prefer it increases the data for Layer
Two
layer 2
is meant to be an extension of ethereum
you could think of the previous charting
dream of ethereum as this execution
charting thing where it was all the
complexity left on ethereum itself layer
2 enables this to be more competitive
and be split from ethereum where we have
exclusive layer as layer 2 and we have
the layer bomb just focus on the
securing data fatability and this is
what this EIP focuses on and achieves
and then through this means we can adopt
a lot more ethereum users onto Layer Two
and projects like like coinbase or other
like larger ethereum users don't have to
look at these ethereum killers in
quotation marks where they can actually
host these users at low cost
um just because we talked about it a
bunch before
um the client teams have anything else
to add or
numbers numbers
okay you heard it here
um yeah I just I want to make sure we
can get to as many people in the next 20
minutes as possible or thank God we're
gonna add something on
I think I've already said the main
things I wanted to say but yeah once off
destruct I think Mario's has the pitch
oh
do you want to do the pitch mares or do
you want to listen to more of the other
pitches
um we should remove self-destruct
um yes that's the picture we agree okay
okay and we need we need to remove
self-destruct for vertical and history
expiry and uh sorry State expiry and all
of these upcoming changes so it needs to
be done uh the question is do we do we
do it now or do we do it later and I
think it's it's a really small change so
we should do it now
for legacy and dof
so just to I think this uh if somebody
is not really on the page of why we want
to remove self-destruct essentially
every single op code on the evm is the
cost is linear or I mean tries to
approximate the actual execution that
the resources it consumes and
self-destruct is one of those OP codes
where
deleting the contract store essentially
it's a it's a single op code call but it
can result in an arbitrarily large
execution and currently the only reason
why currently it works is because
self-destruct assumes that clients
represent the state in a specific way in
the market Patricia way and if it also
assumes that
this state does not get deleted from
disk it's just a couple of branches of
the market Patricia gets updated but the
moment you want to do something fancier
like what Aragon is doing or what gets
new pruning is doing a sensors
essentially self-destruct will become
Berlin a completely unbounded opcode and
that's it prevents us from
going forward with in the implantations
Imagine self-destruct on usdc
yeah two
sorry
yeah and and to like make this uh add to
this like if you want to be stateless it
would be an unbounded number of State
changes and that completely kills
statelessness
so yeah
comment that the currency of this track
has a quirk that you can destroy Eve
with that
and the question if if we want to
actually like
to make the the scent all work the same
way or we want to kind of fix it and
make it more intuitive I think so I
think it's kind of the the choice
between like more backwards
compatibility between something that is
more obvious how it works
oh
so the way I implemented it now it um
just it doesn't destroy it either so it
and and the idea for everyone the final
implementation right
the first implementation was okay and uh
for everyone in the room we are not
trying to remove self-destruct but we're
changing it uh so that
um so that the self-destruct will just
send all of The Ether
um that is in the contract
and the but the contract itself will
stay
and so so it's like it will keep the
current way the only the only thing that
is kind of iffy about it is there's some
pattern where you self-destruct and
create uh to uh uh contract but there
have been an analysis about it and it
doesn't break too much stuff
and and we and we talk to the people
that that we would break with it and uh
they seem to be okay with it how did
gasto can take it
um okay uh beside you Proto uh sorry I
don't know your name uh you don't think
that's back yeah um Ronan uh I basically
build the own chain games uh and
basically also other application uh many
things actually but
um and by that I mean application or
games that have a zero back-end and
where uh the user player uh provide
their own node through the wallet the
truth
and in that context
um
I am building an indexer that runs in
the browser
um and so you can fetch the logs and it
will all fine and but some application
of game rely on time information
and
most developer assume rightly that the
timestamp is available and so they don't
need to add the timestamp in the event
that they emit unfortunately the logs
don't contain the timestamp information
and so
in my game for example like 20 000
events I can fetch them very quickly
like in five seconds it's all all the
state is synced but if I have to uh add
the timestamp then I need to make 20 000
more requests and account even batch it
because uh eip1193 which is only
interface I have cannot do that so the
idea is a very simple proposal is simply
to add the Block timestamp in the logged
object when you query the logs and
actually someone will say you we could
also add the timestamp to the
transaction received Etc but basically
yeah adding the time some information
so one of my uh questions here is that
long term the
essentially long-term ethereum attempts
to remove access from old chain segments
and ideally I would also completely
remove access from law accessing logs
that are older than
I don't know I would remove I would say
a month three months something fairly
High
so uh essentially
I mean is it already your consensus
because we talked because I feel we are
talking now about another thing like
so what I was getting at is that uh this
is kind of a consensus in ethereum that
the past chain segments needs to be
pruned otherwise the the network
implodes and in from that perspective uh
the amount of logs you will have to
access is more limited so it might not
be that big of an issue not to I mean
you could always retrieve the timestamps
if if you have a bounded number of logs
you can access don't you think that if
we go to that stage uh the the wallet
interface will also evolve uh with a
different mechanism so that the
application can remain decentralized
or are you giving up on complete
decentralization
from the application point of view I'm I
don't understand what because like most
applications we kind of as a developer
we understand that we need to index the
data and that's why we use event
um but okay so I think events are
completely being misused and they are
used as a database instead of events and
uh in my opinion ethereum should use it
as events and should everybody ask you
the tabs but that's my two cents what do
you mean by using as event so by event I
mean that that emits something and
anybody interacting with adapt can react
to it within a specific time frame but
not to look up events that happened 10
years ago because that's that's not an
event that's a kind of a database at
that point yeah I mean I have other
common to make because I think it's a
bigger discussion like a lot bigger than
what we have time for now but because
I've we have all applications rely on
this so the reason why we use the event
of the database is because I mean the
typical example is the NFC if you want
to know the list of the token you own uh
you can add and a lot do that they have
this further called Fetch all you know
by providing the starting index and the
lens at which and and you can do that
but it adds gas codes to the
implementation and many
decide actually to not do that and use
the event and I feel it's it's an I mean
I feel normal to to do that and I feel
we need to have a discussion about how
do we will deal with that for
applications that really want to remain
decentralized have you looked at using
the graphql apis because I think you can
go into a Blog from a log and you can
get the timestamp and you can do it in
one step your graphql is not part of
vip1193 which is the only thing I have
access as an application the graphql is
there's a standard for the graphql and
it is in the execution apis so
um gas and base we both implementing can
expose it but you have I think what is
important here is that I don't have
access to a node
the only interface we have for
application is the ip1193 so I I'm
trying to have actually added a further
AIP to solve this using graphql as a
mechanism by which sorry sorry but um
just because this is not like a core it
does touch on the cardboard we're going
to have a whole session about erc's on
Friday
um it's an infrastructure issue yeah
yeah so I I and I agree with you there's
like a longer discussion about like how
applications use this stuff but I think
yeah that's probably a really good one
to discuss on on Friday
um yeah thank you
yeah uh yeah that will be at 1 pm I'm
not sure where but in some schedule
somewhere yeah it's on there's not a lot
of stuff on the schedule Friday yeah
yeah I'm
Matt do you have one
I have an EIP
e you get a minute
I'll keep it short I'll keep it short
um so my name is Matt I am an author of
eip374 often off call
more to the mic I thought she was going
to take it away from me
you're finished now
um yeah so EIP 3074 adds to new OP codes
off and off call the motivation of the
EIP is to improve the user experience of
ethereum I think if you're using dapps
today you're realizing you're signing
tons and tons of things when you're
interacting with a single dap and the
flow that we have is not the best and
with auth and off call we're providing a
very generic framework for adapt
developers to Define like
multi-transaction flows in a way that
allows users to sign just a single
message and they don't need to use any
kind of smart contract wallets they get
these types of benefits for free without
deploying any smart contract wallet
that's one reason another reason that I
think the EAP 3074 is very valuable is
it lets all users of eoas sign a message
to create some sort of social recovery
mechanism and if they happen to lose
their metamask or their Ledger or
whatever wallet that they're using they
can go and recover it with the people
that they signed through and the third
thing I think is really interesting with
3074 and is a testament for like how
powerful it is is a proposal that Alex
came up with maybe I don't know maybe
last year about replacing the wet erc20
token with a contract that uses the
ip3074 to natively move the ether
balances around whenever you're
interacting with the erc20 token so
that's the the
data
um
there is some huge user experience risks
with it is currently done and the
revision took some of the guard rails
off so
um we don't have enough time to go into
some of those those issues with safety
and those are I think my number one
concern on that right now but if we need
meta transactions let's make a meta
transaction transaction format and some
of the other ones you know account
abstraction yeah I think account
abstract you can solve that and that's
something we know we want to do
yeah okay so the yeah
yeah various ones to China man they're
on the same team we have 10 minutes left
sorry no
um well I will give a shout out there is
an account abstraction panel I think
Matthew on it uh later this week so if
you want to go ahead and do a heated
debate about the various flavors of
account obstruction and fake account
obstruction and 3074 right um we'll have
a whole hour to debate it yeah so yeah
so that's okay cool can you raise your
hand if you still had an EIP uh
but Alex you don't have one
okay just
oh no sorry I mean Alex B
in front ACC now Okay no Okay cool uh
how about it
well do you have it no no uh how about
did you have one
okay Daniel do you have a fully IP I
have three of them but I only want a
quick yay
okay I also have a quick one for a Yin a
okay Dino first and there we finish with
Matt so I just I just want to get a
temperature check on the three other eof
ones on eof function static relative
jumps and stack validation good idea bad
idea too complex that's really all I'm
looking for
okay
okay so the first one is eof functions
where we'd have the call F and we'd
split it up in different functions and
have multiple code segments
good idea bad idea too complex
okay
static relative jumps where it's an
immediate operation you say jump ahead
10.
yes
okay and the stack validation which
needs the functions where you can say
that this function is only going to take
five stack items and if it goes and it's
not going to overflow
so you could remove the Overflow check
my thought on that is it's a bit complex
to get into Shanghai so that's I want to
see if I'm the only one of that opinion
I wasn't saying that the other stuff
should go into Shanghai I think it's it
might be a good idea in the future good
idea just Cancun or later
so cool so no one actually proposed uof
um so I guess the UF is approved for
inclusion oh but I just wanted a
temperature check so let's not discuss
it oh sorry
oh yeah these aren't in yet okay okay
can I like like one comment is like if
you combine functions and relative jumps
you can get rid of of uh jobless
analysis entirely because they kind of
replace that
um unless we get rid of the jump code
too
um the jump wood
jump and jump I would have to get rid of
those get rid of jump test analysis yeah
like to remove all of these we can do
that with these two features but uh like
the way we didn't Champion it like
because I think that's not on us to like
actually say it's great because we need
to input from people that say they want
to use that
but thanks for mentioning and yeah we
have evm panel on Friday as well
I do have another VIP
I didn't wanted to like talk with the UF
because we spent like two hours on like
protocol Workshop
um but this app is really cool it's
called M Copy for memory copying
it's not marriage yet because of the EIP
process but
um I'm going to summarize it so
basically the only way to copy memory
right now there are two ways one way is
to do it at the Loop amp store M low
damn store and that was really
recognized in the identity pre-compile
was introduced
um I think the first like few months
after the launch of ethereum that was
used by the solid compiler but then with
the Shanghai attacks it was repriced and
the call was becoming too expensive so
nobody used the identity compiler
anymore it is just there
I think Viper use it now but it's
already still uses the loop
um so then the mem copy op code fixes
all of this
and I just I'm trying to read the
numbers so
yeah it takes like 800 gas to to copy
255 256 bytes
um
with the Shanghai course with the recent
cost is 160 we demo them towards 100
um and the dip it would be 25 by 25 gas
we did some analysis
um
I think like 25 of all the memory
copying would be
improved by M Copy
um and there's actually one feature
in the solid compiler which is kinda be
I mean it's not blocked by this but it's
not implemented
um slicing of memory arrays and a lot of
cases people are doing like forcefully
using call data stuff because that can
be sliced in the compiler setting mem
copy a cheap mem copy would also improve
solidity as a language
that's it
yes the reason I said I have EIP because
um it's almost certainly not for
Shanghai but I don't think it's been
talked about at all and it's nice to
like
um get people's brains Brewing on it so
um first of all the ones based on this
ERC 457 right which is so much the kind
of abstraction that's like a way of
getting a kind of abstraction without
requiring a hard Fork to avoid all those
like EIP processed mess
um
and um this we found that people quite
like this approach right because
um they can already start using their
smart contract vaults but we found that
users actually still complain quite a
bit about um smart contract worlds
because
um like they already have their money on
elas and switching all their balances
and all their all their nfts and
everything is just too much for them
usually so we were thinking quite a bit
about okay like how can we develop a
kind of abstraction more how can we
perhaps enshrine it a bit and so some
ideas just floating around again there's
no EIP set and there's no like specific
roadmap set but an example is
um
making a new transaction type which
converts an eoa to a Smart contract that
you specify in the data field right and
this basically should be quite a simple
new transaction type there's not really
that much complexity as far as I can
tell but please love to hear some
comments some more advanced ones
and again just ideation is
perhaps making an EIP which converts all
current eoa accounts into a sort of
default proxy smart contract World which
uses the current ecdsa signature scheme
that EO has already used right and
another sort of a more advanced one is
so this ERC 4537 it works with a
so-called entry point smart contract
which is through which you root all your
user operations to interact with your
wallet
and this causes a lot of gas because you
do all the signature verification all
the
um all the stuff on chain using well evm
up codes right so what if instead you
made this part of the protocol right in
um that could be validated outside and
so it would save usually lots of gas
foreign
oh yeah just real quick this isn't on
that but uh it hasn't been suggested for
Shanghai but prior to the merge it had a
bit of support uh time aware base fee
calculation it would essentially just
make 1559 quite proof of stake friendly
1559 is aware of blocks it's not aware
of slots you could have say like an
empty block with proof of work but now
you can have missed block proposal so
here we go
I think with a with the amount of missed
slots we see right now I don't think it
makes sense to to do it now uh it's it's
like I don't know we're seeing like
point point one percent point zero one
percent of missed slots or something
like this
it would be a negligible Improvement to
ux so yeah just for a cleanup but not
necessarily to have
so uh with the wallet uh I think there
was three proposals uh I just wanted to
mention there was one proposal where uh
you said that we could just Auto convert
everything uh no that's not going to
happen essentially uh that that's
already a huge issue for vertical trees
where you just want to do an upgrade
where the state just gets flipped over
and it's a huge linear migration and we
have absolutely no idea how we're going
to do it for vocal trees so let's not do
it twice but what if it's not actually
touching every account and rather it's
there's no code and there's a message
signed from that account and it's
treated as a default account and so it
falls back to some default code
um but that would actually break the new
semantics that we introduced with
right you know which exactly I mean that
no eoa can also have contract code
but there's no code in the account and
so it's already empty
and so it would basically be like me
sending a transaction and rather than
executing it the same way that we do
today it would realize that the
recovered address has no code in it and
so then it would just start executing it
in an evm frame with some default
account code that implements the same
concept of the ecdsa account
okay I couldn't follow so so you
wouldn't set the set the contract code
you would not set the contract code okay
it's a fallback
okay I think we're going to wrap up uh
it's past six
um so first of all thanks everyone for
coming
um there's more places we can discuss
all this this week so we mentioned
there's an evm panel where we can get
into eof 1153 all that good stuff
there's an account abstraction panel uh
and we just had some new fresh account
abstraction content as well and then
finally there's an ERC uh kind of Youth
magician session as well
um throughout the week I don't know when
they are sorry they're all on the agenda
is on Friday at Workshop room 4 at 1 pm
you heard it
um oh product right so Friday there's a
session about tank shorting and
prototank shorting if you're interested
to the helpers of the Erp for Edge refer
just please contact us and we are
hosting co-work sessions
yeah cool yeah thank you so much
everyone for coming
[Applause]