►
From YouTube: PEEPanEIP # 111:Keeping up with #Deneb Specification with Gajinder Singh #ethereum #rollup #staking
Description
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1Kk6H5neSL1rsY8ReoSlxXEmGTuwnQUrUo9c9QCP40p8/edit?usp=sharing
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv
Non-EIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxpby7LszzOnyuAyQl8WLLvh
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
Gajinder Singh @Gajpower | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
A
Welcome
to
people
111
today,
we
will
make
an
effort
to
keep
up
with
the
done-up
spec
changes
with
a
very
special
guest
I'm,
your
host
pujaranjan
from
ethereum
Caterers
and
I'm
very
excited
to
invite
someone
who
is
a
client
app
for
lodestar
with
hidden
JS
and
a
core
EIP
Editor
to
help
us
with
the
EIP
process,
Improvement
Welcome
to
our
own
gajender
Singh.
Thank
you
for
joining
us.
Thank.
A
Singh
has
been
kind
enough
to
have
joined
us
on
people
need
to
talk
about
a
load,
star,
client,
ethereum,
JS,
client
and
EIP
implementation
in
earlier
upgrades,
and
today
it
is
about
a
denim
upgrade
I'm
aware
we
have
got
a
presentation
to
be
shared,
but
before
that
may
I
request
to
briefly
introduce
yourself
to
our
new
users.
Thank.
B
You
Pooja
for
inviting
me
to
talk
about
the
nap
and
hello.
Everyone,
I'm,
kitchenware
and
I
work
on
Northstar
and
kmjs.
Lots
are,
as
you
would
know,
is
a
consensus
client
in
typescript
and
ethereum
JS
is
an
execution
client,
it's
an
experimental
climb,
but
its
backbone
of
of
the
JavaScript
type
script,
ethereum
ecosystem,
and
today
we
are
talking
about
the
next
upcoming
hard
folk
dinner,
which
is
primarily
focused
towards
Roll-Ups.
B
So
it's
increasingly
clear
that
the
road
to
ethereum
scalability
is
based
on
enabling
Roll-Ups,
which
is
sort
of
part
of
the
search
roadmap
and
4844
blobs,
a
stepping
stone
for
that,
because
the
blobs
that
are
being
used
in
Dev,
which
is
basically
defined
in
eip4844.
They
are
of
the
same
format
as
what
is
planned.
Ensuring
so
what
this
introduces
with
this
artwork
really
introduces
is
that
a
transient
data
without
permanently
blowing
up
the
blockchain,
so
you
have
a
blob
which
is
made
up
of
points,
and
each
point
is
basically
a
role
of
data
vectors.
B
So
roll
up
can
decide
what
that
point
is
it
would
be
a
transaction
of
it
could
be
a
roll-up
transaction.
It
could
be
role
of
State
changes
or
whatever
rollup
really
wants.
Ethereum
is
not
really
concerned
about
it,
but
what
does
a
theorem
provides?
Is
that
some
data
point
one
can
refer
to
that
particular
blob
in
smart
contracts
and
see
whether
a
point
in
that
blog
was
included
or
not
so
with
a
very
succinct
proof.
One
can
figure
out
in
the
smart
contract
whether
a
particular
thing
was
included
in
the
blog,
so
for
the
CL.
B
B
So
basically,
there
is
a
target
of
three,
but
you
have
six,
and
this
target
might
be
targeted
and
limit
might
be
revised
later,
but
what
it
really
gives
is
basically
a
little
less
than
1
MB
of
data
space
per
block
and
for
the
sharing
the
target
is
to
go
up
to
16
mb
per
block,
and
the
good
thing
is
that
all
this
data
is
never
going
to
be
permanent
part
of
the
blockchain.
So
it's
transient.
B
What
it
really
means
is
that
in
basically
around
18
days,
which
is
4096
epox,
this
data
will
get
cleared
from
the
clients.
So
one
has
to
take
this
into
consideration
that
this
is
just
a
transient
storage
and
what
a
theme
blockchain
really
make
sure
is
that
the
blob
data
was
available
for
on
this
particular
period,
so
that
one
is
sure
that
whatever
is
included
in
finalize
that
data
was
available.
What
it
really
means
for
execution
layer
is
that
you
know
so.
The
question
arises:
how
does
the
blob
data
enters
the
network?
B
So
then
there
is
a
block
transaction.
So
what
are
all
approved
essentially
do
is.
It
would
create
a
block
transaction
and
basically
pair
it
with
blobs
commitments
and
proof
and
send
it
to
an
execution
layer
which
would
only
include
the
basic
transaction.
It
would
not
include
blobs
or
commitments
or
proofs
inside
the
execution
payload,
so
execution,
payroll,
transaction,
the
serialized
transaction
and
execution
payload
would
be
a
shorter
version
of
the
real
block
transaction,
but
execution
clients
will
provide
blots
bundle
to
the
beacon
clients
while
they
are
requesting
a
proposal.
B
So
what
to
be
compliance
would
then
do
is
that
they
would
transmit
the
block,
which
has
this
execution
payload
with
the
shorter
serialized
plot
transaction
data
along
with
blobs,
which
are
basically
independently
transmitted.
All
this
is
based
upon
kcg
cryptography
and
what
it
really
means
is
that
blobs
can
be
mapped
to
a
low
degree
polynomial
so
which
basically
simplifies
proof
verifications
for
4844
data
availability
and
I
mean
right
now
in
for
it
for
foreign.
B
These
verifications
are
quite
simple,
but
when
we'll
go
to
the
sharing
stage,
there
will
be
custom
30
proofs
and
they
will
be
sophisticated
data
availability
checks,
because
the
validators
will
be
divided
into
different
shards
and
different
charts
will
be
responsible
for
making
sure
the
availability
of
the
data
that
is
allocated
to
that
particular
shot.
So
what
sort
of
block
polynomial
hashes?
So
each
polynomial
is
sort
of
uniquely
represented
as
a
commitment,
and
one
can
think
that
how
we
would
hash
the
data.
We
are
hashing,
the
polynomial,
but
indirectly
we
are
also
hashing
the
block.
B
So
as
you
know
that,
as
we
have
discussed,
that
blob
data
is
not
really
part
of
the
payload
serialized
transactions,
but
that
one
can
still
verify
using
proofs
and
using
this
particular
blob,
Hair
Shop
code,
that
weather
and
point
evaluation
pre-compiled,
which
has
been
added
to
evm-
that
rather
a
particular
point
was
in
that
particular
block.
So
you
you
can
use
it
to
verify
whether
a
particular
data
point
was
in
the
canonical
chain.
B
So
basically,
needless
to
say,
you
know,
we
have
come
a
long
way
for
the
development
of
these
block
features
and
initially
freeze
them
and
get
for
championing
this
particular
feature
and
around
devnet
for
other
clients
joined
in
and
there
have
been
tons
of
iterations
on
this,
and
so
some
of
them
are
like.
You
know.
We
started
with
blobs
which
were
tightly
coupled
with
the
blocks,
so
we
had
a
container
in
which
both
block
and
blobs
would
be
there.
B
So
it
was
like
half
big
effort
which
no
one
really
wanted,
so
it
was
then
again
transition
to
rlp
format,
and
we
are
again
seeing
some
churn
on
what
is
the
max
number
of
blobs
per
block
that
should
be
allowed,
because
it
is
a
big
thing.
So
a
blob
that
you
get
from
b2p
is
not
really
you
don't
really
transmit
it.
It's
not
singly
transmitted.
So
as
many
peers
as
you
have,
you
might
be
doing
B2B
gossips
of
the
block.
B
So
it
has
really
big
impact
on
the
bandwidth
and
it
might
affect
the
decentralization
because
small
stickers
and
homesteakers
might
not
have
that
level
of
infra
support.
And
so
there
is
some
discussion
going
on.
What
is
the
max
blobs
that
one
might
require
for
this
particular
heart?
Four
and
obviously,
when
we'll
go
to
sharing
we'll
again
have
to
revisit
this
problem
again,
and
hopefully
there
could
be
some
sort
of
solutions
which,
like
super
block,
Builders,
which
can
help
in
all
of
these
things.
B
But
that
is
something
to
be
done
and
figured
out
in
on
the
later
stage.
Another
thing
that
we
basically
iterated
on
this
particular
hard
Fork
was
we
changed,
kzg
cryptography
from
Little
Onion
to
Big
Indian,
which
basically
impacts
how
a
smart
contract
would
bundle
the
data
for
to
the
pre-compiled
inputs,
as
well
as
how
a
blob
and
network
transaction
Network
format.
Transaction
of
this
of
the
blobs
is,
but
it
is
being
packaged.
B
There
were
some
other
nice
things
that
happened,
which
was
basically
they
were
simplified,
computation
format
for
Access,
Data
gas
and
data
fee,
and
then
some
of
the
other
simplifications
were
added
by
introducing
some
validations
that
okay,
you
know
a
block
transaction
will
not
be
able
to
deploy
a
contract,
so
there
has
to
be
a
destination
address,
and
then
one
com
do
a
block
transaction
without
actually
having
any
blob.
So
as
with
and
every
other
hub
for
things
change
and,
however,
with
blog,
you
know,
few
things
change
in
fundamental
ways.
B
So
one
of
the
basic
thing
is
that
you
know
right
now.
Now
everybody
in
the
network
already
is
using
checkpoint.
Sync,
to
start
their
nodes
or
to
you
know,
bring
their
left
behind
nodes
up
to
date
to
the
network,
but
you
can
still
theoretically
start
from
Genesis
I'm,
saying
forward
to
Beacon
chain
and
basically
taking
into
account
long-range
attacks
and
all
that
right,
so
that
that
is
still
possible.
B
While
the
proposals
are
happening
and
obviously
now
you
can't
really
import
a
block
without
basically,
you
know
making
data
availability
checks
on
the
blobs,
so
it
basically,
there
is
potential
for
increased
latency.
That
would
imply
tighter
schedules
for
proposals
and
attestations
and
obviously
the
Builder
and
Mev
proposal
flows
will
also
be
impacted
and
they
will
also
have
to
provide
the
blinded
versions
of
globside
cars
and
and
the
validators
will
have
to
sign
blockside
cars.
And
then
the
blinded
versions
will
be
published
to
the
builders
and
relays
and
the
rest
of
the
things
will
come
together.
B
So
the
progress
so
far
is
that
we
have
so
there
is
an
ongoing
devnet
6
and
which
is
basically
all
for
it.
For
focus-
and
we
might
have
another
devnet
which
could
be
for
it
for
for
Focus,
because
some
of
the
clients
are
just
catching
up
with
all
the
spec
changes
that
have
happened,
and
then
there
is
an
ongoing
testing
for
what
is
the
max
blobs
that
can
be
supported
without
really
hurting
decentralization
and
post
once
before
it
for
Force
package
sort
of
stabilized
one.
B
Once
the
clients
get
stabilized
and
we
have
stable.net,
we
will
move
to
include
extended,
Dana
features
and
coming
through
those
features.
So
some
of
the
features
that
our
candidates
are
eip4788,
which
is
basically
including
a
beacon
block
route
in
evm,
so
one
would
be
able
to
now
do
proofs
for
the
beacon
state
in
evm.
So,
for
example,
if
someone
wants
to
trigger
withdrawals
or
someone
wants
to
trigger
exit,
they
would
be
able
to
do
it.
So
basically,
this
is
this
will
enable
a
host
of
applications
and
cost
of
activity
on.
We
can
be
connectivity.
B
That
is
primarily
happening
right
now
on
Beacon
chain.
You
know
the
trigger
would
move
to
execution
layer
where
how
one
would
just
normally
interact
with
a
contract,
and
it
would
trigger
things
on
the
weekend
layer.
Another
EIP
that
is
being
considered
is
basically
having
perpetually
signed
voluntary
exits
right
now.
What
really
happens
is
that
if
you
sign
a
voluntary
exit
and
and
for
some
reason,
you
retained
it,
you
didn't
transmit
on
network.
B
You
know,
if
you
have
enabled
withdrawals,
it
will
be
withdrawn
out
to
your
execution
address.
So
what
really
happens
is
that,
right
now,
most
stickers
are
on
a
disadvantage
that
you
know
their
their
bills,
who
can
basically
pull
their
rewards
together
much
far
faster
and
then
you
know
start
another
validator
but,
for
example,
someone
running
with
a
single
validator.
They
won't
be,
for
example,
for
five
to
ten
years.
B
They
might
not
be
able
to
plot
another
valid
data
without
rewards
for
that,
so
they
might
not
earn
any
rewards
on
whatever
each
they
have
accumulated
as
as
a
result
of
staking,
so
it
might
balance
the
scales
between
a
small
sticker
and
a
big
wheel.
So
that
is
something
I
think
is
interesting
and
very
useful
for
small
validators
yeah.
So
that
basically
covers
what
all
things
are
right
now
happening
in
Denim,
and
but
this
is
not
an
exhaustively
small
things
would
come
in
and
things
could
change
so.
A
Thank
you,
and,
as
many
of
us
know,
that
the
main
goal
of
this
series
is
about
creating
awareness
about
anticipated
protocol
changes.
So
it
was
really
nice
to
follow
some
of
the
less
popular
but
I
guess
high
value
changes
which
is
expected
with
the
turnup
upgrade.
So
thank
you
so
much.
You
have
brilliantly
explained
changes
with
the
help
of
this
presentation
and
I
hope.
The
information
shared
today
on
spec
and
eips
will
be
helpful
to
many.
A
A
The
next
section
is
about
a
question
and
answer,
and
my
first
question
is
with
respect
to
the
proposals
that
you
have
just
shared.
So
I
wonder
like
some
of
the
proposal
is
not
even
in
the
merge,
as
a
draft
status
like
4788
is
already
on
the
CFI
list
for
Cancun,
but
eip7044
and
7045
are
not
I'll.
Be
willing
to
pick
your
brain
on
how
you
see
the
EAP
process
evolving
for
consensus
layer
and
is
the
process
a
bit
different
than
El
clients
like
I?
A
B
Think
primarily,
it
should
not
be
really
different,
but
what
is
very
different
between
execution,
layer,
clients,
developers
and
consists
of
clients.
Developer
is
basically
you
know
the
discipline
with
regard
to
the
EIP
process,
execution
client
developers
are
more
familiar
with
EIP
process
and,
of
course,
there
are
somewhere
else
like
you
know,
we
have
issue
where
what
links
to
allow
and
all
that.
B
But
all
those
issues
will
only
come
forward
when
consensus,
client
developers
will
use
it
and
bring
to
our
notice
whatever
difficulties
they
are
facing.
So
then
I
would
like
to
only
mention
that
you
know
we
are
happy
to
resolve
whatever
issues
they
are
facing
and
so
that
the
process
becomes
smoother
and
smoother.
That.
A
Is
true,
I
mean,
like
I
I,
agree
that
the
EAP
process
is
relatively
new
for
consensus,
client,
I
suppose
in
the
course
of
time
they
would
get
more
familiarize
and
be
able
to
follow
the
process
as
it
is
for
El
clients.
One
another
question
about
this:
eibs
I
see
there
is
this
proposal,
which
does
not
seem
to
be
a
part
of
EIP
that
is
with
respect
to
engine
API.
A
B
Mean
it's
a
part
of
the
engine,
API
repository
and
it's
not
not
really,
basically,
a
change
in
terms
of
design
or
in
terms
of
a
new
idea
that
is
being
proposed
or
modified
right.
It's
just
an
implementation
detail,
but
I'm
I
I'm
not
sure
whether
it
should
come
even
in
the
eib
or
not
because
EIP
is
where
you
know
we
have.
We
have
this
repository
of
the
ideas
that
are
going
into
implementation
and
then
there
are
some
nitty
gritties
and
details
implementation,
details
which
are
not
really
concerned
of
EIP
process.
In
my
opinion,
yeah.
A
Yeah,
it
makes
sense
here
so
I
understand
that
this
could
be
a
consideration
at
the
time
of
testing,
probably
not
being
a
part
of
EIP,
because
EIP
is
anyway
is
standard.
That
is
a
made
available
for
client
teams
to
follow
and
Implement
in
their
respective
client
yeah.
My
next
question
is,
with
respect
to
engineering
challenges
after
the
capella
upgrade
so
after
chappella,
Shanghai
and
kapella.
This
is
the
first
Network
upgrade
where
we
are
making
changes
with
respect
to
withdrawal
process
or
when
we
have
fully
enabled
the
withdrawal
process.
A
B
Think,
with
capella
more
or
less
you
know,
things
are
running
quite
smoothly
and
things
are
going.
Fine,
I
I.
Don't
really
see
that
you
know
we
are
trying
to
address
anything
that
was
missed
in
Capella.
We
are
so
this
hot
program
really
in
a
big
way,
focuses
on
totally
new
features
and
in
my
opinion
we
did
a
good
job
with
shoppel.
That's.
A
Always
wonderful
to
know
that
we
are
not
trying
to
fix
anything
that
broke
in
the
past
with
the
past
upgrade,
but
we
are
just
trying
to
improve
it,
I'm
so
happy
about
it
all
right.
Moving
on
to
the
devnet,
we
get
to
learn
about
the
devnet.net
6,
which
is
therefore
EIP
4844,
and,
as
you
mentioned
like
when
devnet
4
was
there,
then
most
of
the
clients
joined
the
development
work.
A
B
A
B
So
devnet6
is
basically
for
it
for
focused
only
but
right
now,
not
all
clients
are
stable
in
terms
of
you
know,
making
proposals
in
terms
of
downloading
the
chain
or
serving
the
chain.
So
we
are
seeing
issues
in
which
one
client
also
included
a
transaction
in
the
network
format,
basically
with
the
blobs,
which
is
not
how
it's
supposed
to
be
in
the
execution
payload
itself
right.
A
That's
interesting.
My
next
question
is
with
respect
to
the
blob
and
the
block,
so
I
remember
having
a
conversation
with
the
talents
the
other
day
when
we
were
talking
about
eap4844
in
Peep
and
Eep
and
I
think
at
the
time
it
was
two
blobs
per
block.
Now
it
is
six
block
per
block
and
I
suppose
it
is
mentioned
that
it
is
WIP.
So
does
that
means
that
before
dinner,
we
can
see
a
change
on
it
and
if
so,
what
is
the
factor
that
is
deciding
this?
How
many?
B
What
it
really
means
is
that
if
you
increase,
if
you
go
beyond,
if
a
particular
block
goes
beyond
a
target
of,
for
example,
three
right
now,
then
the
gas,
the
data
gas
for
the
next
block
will
be
pushed
high
so
that,
basically
less
than
less
so
that
you
know
it
is
it
will
decent
device
for
someone
to
include
blobs
for
the
next
block.
So
what
it
really
does
is
that
it
tracks?
What
is
the
access
data
gas
that
has
been
trickling
down
from
the
previous
chain
from
the
parent
chain,
and
then
it
rises?
B
How
much
basically
fee
one
would
pay
to
include
the
blocks
so
economically,
it's
trying
to
make
sure
that
no
more
than
three
webs
per
block
would
be
included
to
the
second
part,
to
your
question.
So
so
the
concern-
or
you
know
the
parameter
that
will
really
decide
how
many
Max
or
what
is
the
target
limit
for
blobs
per
block
is
latency
as
well
as
the
bandwidth,
because
it's
not
really
computation
heavy
competition
for
making
sure
that
the
blobs
are
correct
and
everything
is
in
line
is
quite
cheap.
B
But
what
will
really
affect-
and
you
know
the
disk
requirement-
is
not
really
that
high-
it's
about,
for
example,
100
GB
as
of
now,
so,
if,
if
you
keep
packing
with
the
max
blobs
per
block
for
about
19
days
so,
and
that
is
again
a
transient,
so
it's
not
really
that
you
know
it
will.
So
it's
it's
the
one-time
allocation
that
the
clients
will
do
on
the
disk
space
right.
So
it's
not.
That
is
also
not
really
a
big
decision.
Factor.
B
The
big
decision
factor
is
the
bandwidth
that
will
be
required
because
if
you
are
doing
P2P
gossip
communication
between
the
clients,
so
you
are
not
transmitting
blob
on
time.
Maybe
you
are
transmitting
it
50
times
or
100
times
in
a
particular
slot,
depending
upon
what
is
the
number
of
PS
that
you
have
and
what
is
our
request
response
request,
request
response
traffic
that
your
client
is
experiencing,
so
that
will
basically
that
is
a
determining
Factor
as
well.
As
you
know,
what
is
the?
What
is
the
delay
in
which
you
have
blocked
and
blobs?
B
So
there
are
two
things:
one
is
block
proposal
and
attestation
schedule
and
then
the
second
thing
is
the
decentralization
in
terms
in,
in
terms
of
you
know
what
would
happen
to
small
stickers,
who
might
not
have
the
resources
that
are
needed
to
basically
support
the
bandwidth,
so
I
think
some
testing
is
going
on
over
this
to
sort
of
simulate
this
particular
situation,
but
whatever
the
testing
teams
do
it?
It's
not
really.
It's
not
really
perfect
to
what
one
might
experience
on
Main
net,
so
hopefully,
when
you
know
it
will
be
tested
on
bigger
test.
B
Nets
like
go
early
or
whole
ski,
which
is
the
new
new,
which
is
the
New
Testament
to
be
launched
with
twice
the
number
of
validators
on
mainnet.
So
hopefully,
with
these
big
bigger
estimates,
we
will
be
able
to
come
to
a
point.
You
know
where
we
can
say
that.
Okay,
this
is
what
we
are
expering
and
maybe
we
can
lower
or
up
this
particular
limit.
But
from
my
feeling
in
the
community
you
know
people
will
try
to
push
the
limit
down
back
to
Fair
per
block
right.
B
Right
now,
I
mean
this
change
from
four
to
six.
Has
sort
of
you
know
made
all
kind
people
aware
that
you
know
this
is
something
that
can
change,
and
everyone
has.
Basically,
everyone
must
have
configured
their
code
in
a
particular
manner
that
it
should
not
be
a
big
deal
to
change
this
particular
number
and
again
on
the
devnet6.
We
are
seeing
things
getting
broken
when
this
change
has
come
in
so
most
likely,
clients
would
be
able
to
handle
this
particular
change
in
the
bills
that
you
just
update.
A
Testing
yeah
I
have
seen
like
proposal
getting
out
of
the
grid
a
few
days
before
the
upgrade
so
kudos
to
a
client
development
team
that
they
are
taking
care
of
every
possible
incidence
to
come
up
and
make
the
changes
as
needed.
My
next
question
is
with
respect
to
the
extra
validation
address
for
blobs.
Can
you
maybe
explain
that
a
little
bit
more?
Why
do
we
need
that
and
how
is
that
going
to
be
very
helpful
to
users
or
maybe
new
validator,
so.
B
These
validations
are
I
mean
just
to
make
sure
that
the
testing
surface
is
low,
I
mean
because
this,
as
of
now,
is
big
change
in
itself
right.
So
there
are
many
things
that
are
fundamentally
changed.
No
one
really
wants
to
increase
the
testing
surface.
So
as
such,
it
should
not
really
impact
any
of
the
stickers.
But
it's
more
like
you
know.
B
A
That
is
good
good
to
know.
One
other
question
I
have
is
with
respect
to
the
Improvement
I
understand
there
would
be
a
trade-off
of
all
these
changes
coming
in.
Is
there
any
feature
that
you
would
like
to
highlight,
which
has
been
introduced
to
maybe
make
a
user's
experience
even
better,
or
will
there
be
a
feature
which
is
going
to
be
affected
that
it
was
there
earlier?
But
because
we
are
proposing
these
changes,
it's
going
to
be
not
available
anymore,
yeah.
B
So
one
thing
that
is
there
is
that
you
can't
forward
saying
before
or
if
you
start
before
this
blob
availability
window.
So
that
is
something
that
really
needs
to
sink
into
the
community.
That,
for
example,
if
you
shut
your
note
down
for
90
days,
you
will
need
checkpoint
sync
to
sync
forward,
and
then
you
will
also
need
to
allocate
some
of
that
is
space
for
the
transient
blob
storage.
And
then
there
is
concern
for
the
bandwidth.
But
apart
from
that,
I
think
we
should
be
good
right.
A
B
Message
for
the
validator
community
would
be
that
you
know
we
need
to
sort
of
come
to
a
point
where
we
can
do
PBS,
because
that
would
sort
of
enable
us
enable
the
clients
enable
the
stickers
to
to
basically
keep
this
bandwidth
requirement
in
check
and
basically
not
really
have
to
propose
or
build
the
blocks
themselves
and
to
basically
get
involved
in
this
blog
P2P
communication.
So
if
it
can
be
minimized,
I
think
it
will
be
very
important
for
the
small
stickers
and
homesteakers
and
for
the
decentralization.
B
A
Yes
well
said
here
just
for
people
who
are
listening
to
this
conversation.
We
do
have
an
episode
on
PBS
recorded
earlier,
so
please
check
out
the
link
in
description.
If
you
want
to
learn
more
about
this
concept
and
what
changes
it
may
bring
for
future
of
ethereum
blockchain
gajender
Singh
on
behalf
of
the
ethereum
community,
I
appreciate
you
taking
out
time
to
provide
an
overview
of
done
up
spec
changes.
A
We
look
forward
to
seeing
proposals
moving
along
the
EIP
process
and
being
deployed
on
the
mainnet
with
the
tenkun
upgrade
on
this
note,
thanks
to
all
our
YouTube
viewers
and
ech
podcast
listeners
for
following
this
episode
on
tenkun
check
out
the
links
in
the
description
to
learn
more
about
this
upgrade.
Should
you
have
any
question
on
this
or
any
other
topic?
Let
us
know
what
it
get
her
this
discard
next
week,
we'll
be
back
with
another
interesting
talk
till
then
keep
sharing
your
love
with
ethereum
Caterers.
Thank
you.