Ethereum Developers Discuss Pectra Devnet 1 and Engine API Updates in Call #138

On
July
25,
2024,
Ethereum
developers
convened
over
Zoom
for
the
bi-weekly
All
Core
Developers
Consensus
(ACDC)
call
#138.
Chaired
by
Ethereum
Foundation
(EF)
Researcher
Alex
Stokes,
the
meeting
focused
on
several
significant
updates,
including
the
launch
of
Pectra
Devnet
1,
proposed
changes
to
the
Beacon
block
body
structure,
and
updates
to
the
Engine
API.

Pectra
Devnet
1

Pectra
Devnet
1
went
live
on
July
23,
but
the
network
has
faced
stability
issues.
EF
Developer
Operations
Engineer
Parithosh
Jayanthi
reported
that
the
Erigon
client
encountered
problems
shortly
after
the
launch,
and
an
EIP
7702
transaction
caused
the
network
to
split
into
three
states.
Developers
are
currently
debugging
the
clients
and
resolving
the
chain
split.

Introducing
an
“ExecutionPayloadEnvelope”

Prysm
developer
“Potuz”
proposed
a
new
structure
for
the
execution
payload
within
the
Beacon
block
body,
termed
the
“binded_execution_payload_envelope.”
This
change
aims
to
simplify
the
data
storage
needed
for
state
transitions
by
consensus
layer
(CL)
clients.
The
proposal
also
necessitates
corresponding
changes
to
the
Engine
API
to
allow
execution
layer
(EL)
clients
to
access
the
required
information
efficiently.

While
Lighthouse
developer
Mark
Mackey
supported
the
change
to
prevent
performance
degradation,
Teku
developer
Mikhail
Kalinin
expressed
reservations
about
the
necessity
of
protocol
changes.
Stokes
encouraged
further
discussion
on
the
proposal
on
GitHub.

Engine
API
Update
for
Devnet
2

Geth
developer
“Lightclient”
suggested
another
Engine
API
change
to
streamline
block
conversion
for
EL
clients.
This
proposal
seeks
to
unify
all
requests
into
a
single
type,
helping
EL
clients
interpret
block
versions
without
referencing
a
fork
schedule.
However,
Nimbus
developer
“Dustin”
argued
that
this
would
merely
shift
complexity
from
the
EL
to
the
CL.

EIP
7688
&
7495
in
Pectra

Nimbus
developer
Etan
Kissling
has
been
advocating
for
the
introduction
of
EIPs
7688
and
7495
to
ensure
forward
compatibility
with
future
SSZ-related
changes.
Despite
support
from
liquid
staking
pools
and
other
client
teams,
Stokes
cautioned
against
overloading
the
Pectra
upgrade
with
too
many
changes.

EF
Developer
Operations
Engineer
Jayanthi
highlighted
the
difficulty
of
testing
multiple
EIPs
together,
suggesting
a
clear
decision
on
their
inclusion
in
the
upgrade.
Lighthouse
developer
Sean
Anderson
recommended
consulting
app
developers
to
assess
the
criticality
of
these
EIPs.

PeerDAS
Updates

Developers
also
discussed
PeerDAS
updates,
with
a
focus
on
fixing
existing
bugs
before
launching
another
devnet.
Stokes
proposed
removing
the
sampling
function
from
PeerDAS’s
initial
mainnet
activation
to
reduce
complexity.
This
proposal
received
support
from
some
developers,
but
others
suggested
keeping
PeerDAS
and
Pectra
workflows
separate
until
both
specifications
stabilize.

Add
BeaconBlocksByRange
V3

Lighthouse
developer
“Dapplion”
proposed
changes
to
the
BeaconBlocksByRange
RPC
to
assist
clients
in
syncing
to
the
canonical
chain
during
extended
chain
splits.
Though
not
urgent,
these
changes
could
potentially
be
included
in
the
Pectra
upgrade.

Developers
are
encouraged
to
review
and
discuss
the
proposal
on
GitHub.

For
the
complete
details
of
the
call,
visit
the
official
summary
on

galaxy.com.

Image
source:
Shutterstock