[Music]
on what is going into the Petra upgrade
we're going to talk about all the eops
that are going to the Petra upgrade
quick disclaimer before I start
everything I'm about to say is all
informational uh for informational per
purposes should not be construed as
Financial or investment
advice before we get into what's going
into pectra the question that I get
asked the most is when pectra is going
on to main T so I'm just going to get
that out of the way um so we can get
into the technical stuff um this is a
very tentative timeline analysis and
everyone's taking pictures already um
when people ask me when is Petra gon to
happen I say it's too early to tell
because it's true te Petra is still in
very early stages of its development
specifications are changing there's the
scope of pectra even has not really
truly been finalized quite yet as we'll
talk about um but through this process
one of the things that you can learn is
how upgrades get developed how upgrades
get tested um and eventually make it
onto mainnet so initially what happens
is developers decide on a couple eips to
include in an upgrade and then they
Implement those eips onto private
developer focused test Nets called Dev
Nets and developers have already
launched a couple of Dev Nets already
for pectra um so these eaps have already
undergone a couple of rounds of
implementation and developers have
noticed edge cases have noticed various
bugs that they want to fix and they uh
iterate they iterate on these eips uh by
launching new Dev Nets devet 4 was
launched um last month October and this
doesn't usually happen but developers
very specially for this entire
conference and for everybody in the
audience launched the first public
pectra test net um this month it's
called me Kong so you can go and
interact with some of the eips that are
going to be in pectra early on um it's
based on devet 4 specifications um but
please note that those specifications
are changing there is a list of changes
specifications changes to the eips that
developers already want to uh include
into pectra devet 5 so there's things
like uh BLS um pre-compile repricing uh
a new EIP that hasn't been implemented
into devet 4 but uh developers are
aiming to implement it in for devet 5 or
a future upgrade so Petra specifications
are changing I foresee multiple more Dev
Nets still to go before specifications
can really be frozen and the other part
that's really important for the Petra
upgrade in its progress to mainnet is
for the scope to be finalized for all of
the eips going into Petra um to be
decided on decided upon with developers
and there is one EIP it's not really an
EIP yet but it's the blob capacity
increase that is what developers have
not yet formally included into pectra
but it seems as though they're likely to
include a blob capacity increase some
kind of a blob capacity increase into
pectra because of the fact that they
have recently included uh this EIP which
we're going to talk about which
introduces a mechanism to be able to
update the blob gas Target and the blob
gas Max um dynamically through the
consensus layer rather rather than
having those par parameters hard-coded
in the execution layer and the consensus
layer um so the addition of that
mechanism into pectra suggests that
developers are doing all the heavy
lifting of trying to um Implement a
change to blob capacity increase or a
change to the blob capacity in pectra um
but developers have not formally um
decided or formally included um that
increase like right now it's a target of
three and a Max of six um they're not
sure if it's going to be an increase of
four or five or six um so ideally
hopefully developers will be able to uh
finalize that early next year um and I
think as the specifications for the
other pectra eips become hardened more
uh finalized it puts pressure on
developers to kind of activate them on
mainnet and in order to do that you have
to ensure that the scope of the upgrade
is fully complete so um you know strong
strong strong I guess like thinking or
or reasoning that the uh fusaka not
fusaka that the pectra scope will be uh
finalized by early next year um and then
once it is finalized you start testing
uh whatever new eips that you've
implemented the full scope of the Petra
upgrade you test that um and battle test
it on a couple more Dev Nets um I
Envision say you know until maybe devet
6 or S um and then once the Petra
specifications are frozen they are ready
to go all the edge cases uh that
developers can find on dev Nets have
been found they will then release the
Petra specifications uh release the
Petra upgrade onto public ethereum test
Nets there are two right now sooa and
heski heski um
Gorly is deprecated I believe um and
historically developers have budgeted
about two weeks between um public test
net upgrades um in kind of rare
occasions developers kind of shrunk that
timeline down to even just one week
between um test Nets but because of the
size of pectra um I imagine that
developers will want to take the full
time to um see how the Petra upgrade
fares on public test net environments um
so I am budgeting roughly about a month
for the sepolia and the heski heski I
don't even know how you would say it
right but heski thank you sir um yeah so
that that's going to happen and I'm
budgeting about a month for that and
then after that's when you can finally
have the main net activation um so given
all of the information that I know right
now and the progress that developers
have made so far on pectra my best
analysis and guess is that pectra maina
will realistically happen next April
2025 um again this is very tentative um
because a lot can change between now and
um April development uh happens on a
week toe basis developers are are on
these ACD calls talking about um this
bug that they didn't expect in this EIP
or this new EIP that they do want to add
into Petra now um so a lot of things can
change this timeline um but looking into
my crystal ball there you have it my
timeline um let's move on to what is the
meat you know the bread and butter of
this talk which is what is going into
Petra upgrade there are 10 eips that are
going into Petra and four of them are
focused on the execution layer oh my
gosh the print is so small there um EIP
2537 it is a uh new pre-compile yay new
pre-compile into the evm um BLS 12381
curve operation this is a new
cryptographic signature scheme um that
uh smart contract developers have been
asking for for a very long time this is
an EAP that was created in 2020 and at
the time dap developers were like we
really want this because it would be um
it would give daps um certain daps that
are relying on zero knowledge
cryptography um stronger stronger
privacy guarantees um potentially
increased security and scalability I
believe BLS signatures that that
signature scheme or that aggregation is
also the signature aggregation that
happens on the consensus layer for
validator um attestations um it this CIP
is a long time coming and so I think one
of the concerns around the CIP is are
there still apps that are waiting for
the BLS precompile and will are they
going to use it uh when that precompile
goes live um so kind of an open question
but if you're in this audience and um
didn't know that the BLS pre-compile is
finally coming it's coming um and maybe
you know you're you have an app that
hasn't already moved on from this vision
and can still utilize this pre-compile
in some pretty cool ways um so it's
going into pectra uh EIP 2935 serve
historical blasters from State um this
one introduces is a change to the
execution layer such that proofs of
historical blocks can be generated from
the state um this does have some
near-term benefits so um it has some
benefits for light cin syncing has um
some benefits for smart contracts that
may want to utilize um data about the
state of a prior block um directly
through the evm you can't actually do
that right now um but those near-term
benefits is not the reason that this EIP
was included into pectra um because
clearly those benefits are a little bit
iffy um not like super important I guess
but the main reason why that was
included into Petra is because it's a
prerequisite for veral and veral is uh
this major overhaul to ethereum's uh the
structure for uh State data on ethereum
that developers had thought that
transition was going to happen right
after Petra so they're like oh you know
faka this is when veral is going to
happen oh well we need this EAP if we're
going to do that veral transition um but
turns out as we're going to talk later
in this uh presentation verl is not
going to go into um fusaka or at least
that's not what developers are expecting
right now um they've punted it out to
another upgrade but it's still there
developers did implement it um and it'll
have some near-term benefits but the
primary reason for it is um as a
prerequisite to to veral um which you
know could happen down the road um and
if it does you know this this stepping
stone has already been checked off the
list EIP 7685 uh general purpose
execution layer requests this is an EIP
that doesn't really introduce new
features to ethereum it's really an EIP
to support other eips in pectra um so in
pectra there's a couple of eips where
the execution layer will be able to pass
way more messages different kinds of
messages to the consensus layer that it
couldn't before um the execution layer
smart contracts on the execution layer
will be able to trigger like validator
withdrawals consolidations deposits um
and rather than implementing these new
um messages these new communication
channels all in a separate kind of
unique faction fashion uh the
implementation of these generalized
these execution layer triggerable
requests um the implementation of all
these requests instead of doing it in
kind of like a siloed fashion why not
create like a generalized structure a
generalized bus to house these requests
um it will be easier to test easier to
implement across clients easier to kind
of standardize especially if developers
want to introduce new types of execution
layer triggerable requests so G
developer um like client he was like I
think this would be a good EIP to add
once developers started implementing
those other e are like oh actually this
is something that would be pretty useful
um so that's why EIP 7685 is in there um
and EIP to support the other eips uh e
772 this one's kind of I guess an
exciting one um a new transaction type
is coming into ethereum and this
transaction type is going to temporarily
allow a user controlled account an eoa
externally owned account um to have
greater flexibility and enable features
like what some that I think many people
in the audience have been waiting for
for a while um to enable EAS to have
features like transaction batching
sponsored transactions conditional
transactions delegated security pretty
cool stuff like you're thinking oh my
gosh is this like the account
abstraction Vision coming alive on
ethereum no it's not it's a baby step um
so it's kind of like a baby step to
seeing how um this will improve the user
experience um it is cool that um you
know some kind of temporary
functionality will um that you'll be
able to create some kind of temporary
new um flexibility into eoas um but
really it's an early step um to see what
the real road map to True native account
abstraction could look like on ethereum
um this had quite a bit of debate um in
terms of how developers should take that
first step um a lot of controversy of
this one getting in and its design but
it's in there and I'm pretty sure um of
all the eips that developers want you to
interact with and kind of test on the
meong test net this is probably high up
on the list um you know trying out this
new transaction type so if you're on
meong um you know thow developers a bone
try it
out there are six others these ones are
consensus layer eips and I'm going to
run through these really quickly because
after me there's going to be some talks
that go deeper into each of these eips
so this is just you know summary
overview um EIP 7742 uncouple blob count
between the consensus layer and the
execution layer this one is the most
recent EIP to be included into Petra um
developers like I said um was
considering should we include an
increase to the blob capacity um and if
we're going to do that currently the
blob capacity is hardcoded into the
execution layer and the consensus layer
and the hard coding of these constants
are all kind of different in all the
clients um and so updating that hard
coding is not as easy as um some may
think um so creating a mechanism to kind
of be able to change the blog capacity
and have it dynamically set by the
consensus layer um will ensure that in
the future developers can easily change
the blob capacity of ethereum if they
want to and and um ensure that that kind
of upgrade it only requires consensus
layer changes doesn't require a change
to both the execution layer and the
consensus layer um so yeah but it's like
heavy work upfront right because the
mechanism doesn't exist right now once
the mechanism exists yes it'll be easy
to use that mechanism and update the
blob capacity but right now that
mechanism doesn't exist so it takes
quite a bit of work um which is why when
developers were like look if we're
really serious about including an
increase the blob capacity in pectra we
should really get started on this
mechanism them sooner rather than later
and so developers were like actually yes
other developers on the call and the ACD
calls I'm talking about they're like you
what that's probably a good idea so
that's why it was included but the last
little lineup here TBD that's the blob
capacity increase developers have not
decided on what specifically that
increase is going to be quite yet um
let's dive deeper into some of these
other ones EIP 6110 Spide to validator
deposits on chain um Vall you know he
was like woohoo you know then the
mainstage talk like the merge happened
um the merge happen and ethereum is more
mature as a proof of stake blockchain
there are certain security assumptions
that can be relaxed now um and one of
those security assumptions is an
additional round of voting um that
happens every time you deposit a 32 eth
on the ethereum 2.0 deposit contract
there's an additional round of voting
that happens on the consensus layer side
to verify those deposits um this EIP
removes that additional round of voting
on the consensus layer side um ensures
all the deposit validation happens on
the execution layer um this has some uh
benefits for validator ux it will shrink
the time um between when you deposit
your 32 eth and when you see the
validator actually be activated on the
beacon chain um EIP 70002 uh execution
layer triggerable withdrawals this is
very good for sticking pools um right
now validators if you want to fully
withdraw a validator the node operator
that controls that operates that
validator needs to um withdraw they need
to uh use their withdrawal key to fully
exit the validator um but through the
CIP smart contracts will be able to
initiate those full withdrawals so it's
kind of a a trust assumption that you
can now remove from staking pools um the
likes of say like Lio rocket pool other
smart contract based staking pools you
can um those smart contracts can now
trigger full withdrawals of validators
if they wish um so a very nice nice
feature for trustless and um improving
the yes this I don't know like
resiliency yes resiliency of uh smart
staking pool smart contract based
staking pools EAP 7251 increasing the
maximum effect of balance I have written
so many reports on the problem of
ethereum's growing validator set size
this really is an issue I guess we know
when developers were thinking about the
beacon chain um they did not expect the
validator set to grow so quickly and for
the peer-to-peer network of ethereum not
to be able to handle um 1.5 million
validators I think we're at like 1.2 or
1.3 somebody can check me on that um but
there's a lot of validators a lot of
active validators a lot of messages
being passed around on the networking
layer and it's too much um really is too
much so it's um straining nodes um and
you know left unchecked it would be a
major problem for the health of ethereum
so uh EIP 7251 is designed to encourage
validators to consolidate their eth um
and have a maximum effective balance
higher than 32 eth and reduce the number
of active validator on ethereum that is
the goal of EIP 7251 let's see how
quickly it is adopted once preure goes
live because that you know depends on
all of the staking pools and
stakeholders of the staking Community
really you know getting it together okay
so uh EAP 7549 um move committee index
outside attestation kind of like a
restructuring refactoring of the way
that attestations are um aggregated uh
to make blocks or to reduce the
networking load of ethereum again see
there's clearly networking pains um and
save node bandwidth um and kind of quick
note about the CIP developers when they
were including an incture I was like oh
this is a this is a great change clearly
has wonderful benefits an easy one to to
go ahead with um in practice though um
turned out to be a lot harder to
implement than expected so sometimes
that's the way the cookie crumbles wow I
cannot believe I only have two more
minutes um okay so in like the Outlook
if you know I Blaze through that really
fast don't worry in summary ra is a
mixed bag of updates it's going to do
three things it's going to fix critical
shortcomings of ethereums as a proof of
stake blockchain think about Max evb
right like that's a critical fix that
needs to happen because the validator
set size can continue to grow unchecked
um improve the user experience right
we're talking about like the new
transaction type make is more flexible
some improvements for uh more trustless
designs for sticking pools Etc some
minor ux improvements there and number
three uh ethereum's data availability
capacity increasing that that hasn't
been formally included into Petra but
again seems likely moving on um okay
here are all the eips that were removed
from pectra this is kind of like a
firsttime thing for um an upgrade to
have so many eips removed from for from
it um the first one is pias honestly
there was going to be a much bigger
increase to data availability capacity
um in Petra initially when Petra was
being scoped out pias is going to um
allow developers to increase the blob
Target of ethereum not from like 3 to
four to like four to five but like by
multiples more without um impacting
greatly the um bandwidth consumption and
the uh computational requirements of
running in ethereum node but it's still
in research and development phase um
it's still being developed and these
other 11 code changes as a bundle are
called eoff it's this major update to
the ethereum evm
and both of these eips all these eips
were really initially included in pectra
but they were being tested on separate
devet so you had the pectra eips that
were moving along progressing um
starting to solidify um starting to
become more aspects of it were starting
to become more or less finalized but
pias and eof um there were developers
thought that it would require a lot more
time to get them really ready for mayet
Activation and developers did not want
to delay the activation of the Petra
eips from getting onto Main net which is
why one of the reasons was they wanted
to get Petra out the Petra eips out
sooner so they said pias and eof um
clearly needs more time to be worked on
we'll pump that to another upgrade and
not hold back these other pector eips
from mainnet another reason is this is a
lot of eips in addition to the other 10
that I talked about um so lots of risk
right um with the interdependencies of
this code um trying to implement it all
at once this is a lot of of work and
time for the testing team and the client
teams to be able to ensure there aren't
any bugs um so lots of reasons for to I
I would say actually main reasons for
why these eips were removed from
Petra and now they are moved to fusaka
so again I have verl up there because
verl was initially slated for fusaka but
then now it's not going to because
developers have given a soft
confirmation that eof and pias are going
to be into in faka but again obviously
there's um changes happen like in the
moment developers should be able to
reassess priorities and uh make
decisions accordingly um so it's like
it's unlikely but there's a non-zero
chance Anything Could Happen um verl so
verl is not in fusaka for now and eof in
pias for now is in P in um fusaka and
there's a couple other eips that I think
developers will reconsider for inclusion
in fusaka once developers have the
bandwidth to really think about it um
and give their full attention to fusaka
after Petra um these are some of the
other ones that were considered for
pectra um but never made it in um but
now there's more time for these other
code changes to be worked on they could
be a lot more ready for implementation
six months from now than right now so
there's like the S transition inclusion
list um change to issuance everybody
remember that debate um could come back
history expiry epbs um and accounts
direction right like with the new
transaction type maybe there'll be some
learnings from that from pectra that
inform next steps so lots of of other
eips that could be um included the
scoping discussion for fusaka will be an
interesting one to watch so in the
audience I hope this just goes to show
please be engaged in ethereum governance
um I don't foresee you know very many
upgrades left in ethereum's future so
every upgrade counts and there's a lot
of priorities on the list um and so it's
worth it in the ethereum ecosystem to
make sure that your voice is heard and
that decisions about where ethereum
protocol is heading is not made by like
a few individuals or a few groups um but
that the whole community and ecosystem
gets involved so thank you I hope you
learned something new about ethereum and
Petra thank you thank you thank you
Christine we have a couple we have a few
minutes for a Q&A as you can see you can
sort of upvote them there so if you have
one that you really want answered please
upvote right now but I will let you take
it away with when eof when eof I
literally just said the devs literally
said that they are going to try and put
it into fusaka do I think that it's
likely probably not do I think that
fusaka is going to happen in 2025
absolutely not I think that the amount
of time is taken to prep par pectra
fusaka will take a similar if not longer
time awesome and then if we want to
answer I think we have time for one more
um is there for us to increase Petra in
case they get too expensive and start um
yes there definitely is an emergency
path for increasing blob Target oh
between now and Petra activation hm no
cuz blob Target is is a hardcoded Target
and Max in the execution layer and
consensus layer for that to change for
blob capacity to change developers need
to do a hard Fork so no I do not think
that there's any way for the blob
capacity to increase between now and
pectra um without a hard Fork yeah
actually we are doing okay on time so
we're going to keep cycling through
these is the proposal to change the blob
limit only or also the blob Target okay
so that's a great question um blob
Target there the most conservative
increase is three to four just changing
the target not changing the max at all
but that's not what uh layer 2
developers have asked for base um
there's this representative of the base
team a coin bases base team and he's
been vying for more aggressive um
increases he's shown data to suggest
that uh the increase wouldn't impact the
the decentral negatively impact the
decentralization of ethereum so there's
actually both uh there's a conservative
proposal to just change the Target and
then there's a more ambitious proposal
to change both the Max and the target to
like it's like eight and four if not
like six and 12 um so there's varying
gradients there's actually a a lot of
different ways in which uh devs could
increase uh the target um we'll see how
conservative they uh choose to go for
but yeah and I think I'm going to go
first so you just urge people to be more
involved in governance we're going to
jump to that question how can the
community get more involved in
governance
yes well so eth research and eth
magicians are two really great
discussion forums for up voting certain
eips showing your support for an EIP um
I would say those are two really good
ones um another one that is good but
probably a little bit harder for
everyone to do um if you have a
representative from from your company
that wants to really uh advocate for an
EIP the ACD calls are probably the most
high signal place to do it all you have
to do is just leave a comment on the ACD
call agenda on GitHub and say like this
is an EIP that I'd like to uh speak
about or present um and the moderator of
the call is usually very agreeable to uh
giving you the time um don't take up too
much time though like maybe like 5
minutes um for you to like say your
peace so um you know use that chip
sparingly but um that is probably one of
the most like uh