Galaxy Digital: Ethereum Developers Discuss Key Upgrades During Latest Consensus Call

Ethereum
Developers
Convene
for
ACDC
Call
#134

On
May
30,
2024,
Ethereum
developers
gathered
over
Zoom
for
the
All
Core
Developers
Consensus
(ACDC)
call
#134.
These
bi-weekly
meetings
serve
as
a
collaborative
platform
where
developers
discuss
and
coordinate
changes
to
Ethereum’s
consensus
layer
(CL),
also
known
as
the
Beacon
Chain,
according
to





Galaxy
Digital.
This
session
was
chaired
by
Ethereum
Foundation
(EF)
Researcher
Alex
Stokes,
who
steered
discussions
on
various
upgrades,
including
the
Pectra
Devnet
0
and
potential
changes
to
the
Pectra
upgrade
scope.

Devnet
0
Recap

Developers
revisited
the
launch
of
Pectra
on
Devnet
0,
agreeing
to
maintain
attestation
behavior
impacted
by
EIP
7549
unchanged
during
hard
fork
activation.
This
decision
follows
previous
discussions
where
developers
considered
multiple
options
to
prevent
invalid
attestations
during
the
fork.
Ultimately,
they
decided
against
complicating
the
upgrade,
opting
instead
to
activate
EIP
7549
concurrently
with
other
Pectra
EIPs.

Uncertainty
remains
regarding
EIP
7251
and
whether
staked
ETH
consolidations
should
be
initiated
from
the
execution
layer
(EL).
This
feature
could
benefit
staking
pools
by
allowing
stake
consolidations
via
smart
contracts
rather
than
relying
on
node
operators.
Stokes
suggested
revisiting
this
issue
after
further
implementation
progress.

Additionally,
developers
addressed
open
questions
about
validator
deposit
finalization
under
EIP
6110.
Teku
developer
Mikhail
Kalinin
outlined
a
path
forward
in
a

GitHub
comment
prior
to
the
call.
Discussions
also
included
version
control
for
the
“GetPayloadBodies”
request
in
the
Engine
API,
which
was
raised
by
Lighthouse
developer
“sean.”
Stokes
encouraged
feedback
on
this
issue
via
a

GitHub
pull
request.

EIP
7549
Changes

Nimbus
developer
Etan
Kissling
proposed
a
minor
adjustment
to
EIP
7549
to
enhance
stability
for
generalized
indexes.
The
suggestion
to
relocate
a
new
field
to
the
end
of
a
container
to
avoid
index
reassignment
received
no
opposition.
Stokes
advised
developers
to
review
Kissling’s

pull
request
on
GitHub.

Another
proposed
change
to
EIP
7549
involved
designing
requests
and
other
EL-triggered
actions
as
a
sidecar
to
EL
blocks.
Mikhail
Kalinin
praised
this
design
for
simplifying
the
EL.
Stokes
recommended
revisiting
this
topic
in
the
next
CL
call
after
further
review
of
the

proposal
on
GitHub.

Pectra
Scope
Discussion

Developers
debated
whether
to
include
several
CL-focused
EIPs,
such
as
EIP
7688
and
PeerDAS,
in
the
Pectra
upgrade.
EIP
7688
aims
to
ensure
forward
compatibility
by
adopting
part
of
the
“StableContainer”
SSZ
data
structure.
PeerDAS,
a
significant
enhancement
for
the
network’s
data
availability,
could
increase
the
number
of
blob
transactions
per
block
from
three
to
64
or
more.

EF
Developer
Operations
Engineer
Barnabas
Busa
reported
that
an
early
iteration
of
PeerDAS
had
been
launched
on
a
devnet,
revealing
various
issues.
Stokes
questioned
the
feasibility
of
adding
PeerDAS
to
Pectra
if
it
risks
delaying
the
upgrade.
Discussions
also
considered
splitting
Pectra
into
two





hard
forks
to
accommodate
PeerDAS.

Developers
like
“Nishant”
and
“atd”
expressed
differing
views
on
decoupling
PeerDAS
from
other
Pectra
EIPs.
Atd
emphasized
the
logistical
challenges
of
coordinating
multiple
upgrades
within
a
short
period.
Ultimately,
developers
agreed
to
further
test
Pectra
EIPs
and
PeerDAS
together,
with
PeerDAS
activation
on
a
later
epoch
on
devnets
and
testnets.

As
discussions
on
EIP
7688
inclusion
were
postponed
to
the
next
ACDC
call,
the
call
concluded
with
developers
agreeing
to
move
forward
with
this
testing
strategy.

Image
source:
Shutterstock

.
.
.

Tags