►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/light-clients-after-the-merge/
The merge unlocks a new era of truly light clients that can stay in sync with the Ethereum network using just 20 bytes / second. All obtained data can be verified in a trust-minimized manner, reducing the risk of a rogue centralized API provider serving incorrect data. This talk describes the latest advancements in CL light client protocols.
Speaker(s): Etan Kissling
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: light-client,trust-minimized,wallet
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
To
answer
that,
first:
let's
look
at
what
you
actually
need
for
a
full
node.
At
the
very
least,
it's
a
Raspberry
Pi,
eight
gigabytes
of
RAM,
2,
terabytes
of
storage,
one
terabyte,
A
month's
internet
and
a
live
client
is
basically
anything
that
doesn't
support
those
specs
like
a
browser
wallet
to
the
left
side,
metamask
or
in
the
center
the
status
mobile
or
on
the
right
Hardware
wallet.
A
A
Here,
someone
approaches
you,
he
wants
to
donate
0.5
East
to
you
so
sounds
good.
0.5
is
a
lot
of
money.
You
give
them
the
QR
code,
they
send
the
money
and
they
send
you
the
transaction
and
seems
good.
But
when
you
check
it
you
see
they
accidentally
sent
five
E's,
so
we
need
to
refund
4.5
of
those,
and
luckily
we
brought
our
Hardware
wallet.
But,
as
you
know,
the
Wi-Fi
is
not
too
great
here.
So,
let's
just
ask
we
can
use
their
laptop
and
they
agree.
A
We
connect
The
Ledger
to
their
laptop,
and
we
see
here
the
9.75
eth,
so
the
plus
five
and
we
signed
the
transaction
for
4.5.
The
letter
protects
our
keys,
so
they
cannot
be
extracted.
We
see
here.
The
amount
is
correct,
the
address
is
correct
and
we
confirm-
and
we
thank
them
for
the
donation,
so
like
clients
very
powerful,
that
there
is
a
problem
when
you
go
back
to
the
hotel,
you
actually
realize
that
a
this
transaction
of
the
five
is
missing.
A
So
what
went
wrong?
We
confirmed
that
everything
is
correct,
but
one
key
piece
is
missing
there.
The
actual
balance
was
4.75
East,
so
they
lied
to
us
with
the
975.
This
is
actually
the
same
problem
with
traditional
banking
when
I
create
a
transaction
to
an
unknown
destination.
They
only
ask
me
is
the
amount,
correct
and
the
address,
but
they
don't
verify
that
the
intent
why
I
am
sending
the
transaction
is
really
why
yeah.
So,
where
is
metamask
putting
this
data
from
the
answer?
A
Is
there
is
a
setting
in
there
and
you
just
put
it
to
a
server
by
default?
That's
infuro,
but
in
this
case
the
scammer
just
put
a
custom
URL
there
that
lies
about
the
balance.
So
how
is
that
possible?
Isn't
that
more
secure?
Actually
it's
just
this
is
the
call
that
metamask
is
doing
is
get
balance.
Your
posit
the
address
the
block
number
and
you
need
a
response.
You
just
get
the
raw
balance,
no
security
whatsoever.
Just
trust
me
bro,
so
in
this
case
the
attacker
simply
added
the
five
E's.
A
If
it's
our
address,
this
is
the
complete
attack
code.
This
thing
I
tried
with
a
real
metamask.
So
now
the
question
is:
how
can
we
make
this
more
secure
to
understand
that
we
need
to
understand?
We
need
to
see
what
are
what
is
actually
stored
in
ethereum
and
all
of
these
things,
any
one
of
you
probably
interacted
with
at
least
one
of
them:
nft
ownership,
game
characters,
tokenized
assets,
exchange
rates
or
even
just
the
plain
East
balance
that
we
have
seen
before.
A
All
of
that
is
just
data
stored
as
part
of
the
ethereum
state
and
because
it's
data,
it's
just
a
bunch
of
bytes,
and
we
can
arrange
it
as
we
want,
for
example.
Here
we
can
order
it
and
then
what
we
can
do
is
we
can
compute
the
hash
function
on
pairs
of
each
of
them.
So
a
hash
function
is
just
a
one-way
function.
It's
a
cryptographic
checksum!
A
A
So
how
is
this
useful?
If
you
have
our
balance
down
here,
the
4.75
we
can
see
the
root
cache
contains
information
about
all
of
it.
So
whenever
someone
changes
that,
for
example,
to
9.75
to
lie
to
us,
Everything
Changes
up
to
the
true
test,
so
if
we
know
the
correct
routes,
we
can
know
that
whether
something
was
tampered
with
or
not.
A
So
how
do
we
actually
send
a
proof
that
the
4.75
is
was
used
as
part
of
this
hash,
and
for
this
we
need
to
work
this
entire
path
to
the
top?
Let's
start
with
this
node
here
to
compute
that
we
also
need
this
one,
and
then
we
go
to
the
next
node
here
and
for
that
one
we
need
the
A
and
B
and
then
from
there
we
go
all
the
way
to
the
top.
What
is
missing
is
EFG
and
H.
A
A
So
how
do
we
obtain
those
proofs?
The
answer
is
is
get
proof.
The
interface
looks
surprisingly
similar
to
the
get
balance,
but
instead
of
just
a
balance
in
the
response,
we
also
receive
the
Merkel
proof,
and
this
marker
proof
can
be
used
to
verify
that
the
balance
that
we
get
is
indeed
part
of
that
root
touch.
So
now
the
question
is:
how
do
we
obtain
the
root
test?
A
This
is
where
the
lifeline
protocol
comes
in.
If
we
look
at
the
Beacon
chain,
it's
a
series
of
blocks
that
point
to
the
parent
block
with
a
address.
That's
part
of
the
block,
it
forms
a
chain
and
since
the
merge
actually
the
root
hash
is
just
part
of
those
blocks.
So
the
question
now
is:
how
do
we
obtain
that
latest
block
with
the
correct,
true
test
and
a
full
node?
Does
this
by
just
following
all
the
signatures
and
verifying
them?
A
The
student
committee
has
a
set
of
just
512
validators
that
the
like
client
can
keep
track
of,
and
they
also
sign
each
block.
They
sign.
Whatever
is
the
latest
block
and
if
you
know
those
keys,
you
verify
the
signature
and
more
than
two-thirds
of
it
agreed
on
the
same
block.
You
can
trust.
That
is
the
same.
That
is
correct.
A
So
how
do
you
get
these
sync
committees?
And
the
answer
here
is
it's
from
the
previous.
In
committee
every
day
the
student
committee
changes
and
the
previous
student
committee
signs
a
message
that
passes
on
this
power
of
signing
the
latest
block
to
the
next
student
committee
and
the
previous
student
committee.
How
do
you
get
that?
A
You
can
continue
and
continue
one
day
at
a
time
to
the
next
string
committee
and
download
those
public
Keys
verify
the
message
that
signs
the
next
single
committee
until
you
are
at
the
present
one
and
then
you
obtain
the
latest
block
check
the
signature,
and
you
know
the
root
hash.
This
data
is
really
small.
It's
just
about
25
kilobytes
each
and
to
obtain
the
final
root
hash.
It's
just
about
300
bytes,
one
thing
for
certain
applications
that
can
be
done
if
you
are
really
offline
for
a
long
time.
A
Those
committee
messages
can
be
combined
into
a
CK
proof,
and
then
you
can
essentially
jump
from
any
point
in
time
to
the
present
in
constant
time
with
a
very
small
proof.
Those
apis
are
available
to
download
the
data.
It's
on
rest,
andly,
P2P.
It's
already
standardized
part
of
the
official
specs
on
the
portal.
Network
there
is
a
PR
and
load
star
and
Nimbus
are
currently
implementing
the
lip
p2pn
rest
apis.
So
if
you
want
to
try
those
feel
free
to
do
so,
then
security,
how
secure
is
it?
A
There
is
some
research
that
shows
that,
with
a
few
minor
modifications
to
the
protocol,
it
can
be
made
so
that
you
can
actually
only
stream
every
four
months.
So
this
really
opens
up
a
lot
of
applications
such
as
iot
devices,
where
you
are
not
connected
to
the
internet.
So
as
long
as
you
student
once
every
four
months
should
be
secure,
then
let's
bring
it
together.
A
A
Now
we
can
obtain
the
latest
root
hash
from
the
beacon,
API
and
then
use
the
get
proof
endpoint
to
actually
get
the
4.75
plus
a
proof
that
it
is
actually
part
of
the
root
hash
that
we
obtained,
and
this
essentially
means
that
if
you
think
that
the
beacon
API
provider
could
be
the
same
as
the
web3
API
provider,
why
not
infuro
could
essentially
just
provide
that
data
and
you
no
longer
have
to
trust
them
for
the
correctness
of
the
data,
but
just
for
the
availability
of
the
data.
That
is
quite
huge.
A
If
you
don't
want
to
modify
metamask,
you
can
also
put
a
proxy
in
between
that.
Does
this
translation
so
metamask
is
unmodified?
It
still
does
this
old
get
balance
call
but
the
verifying
proxy.
It
keeps
track
of
the
latest
root
hash
using
the
light
client
data,
and
it
translates
the
get
balance,
call
to
the
get
proof
and
verifies
that
the
return
data
is
correct.
It
can
alert
you
if
it
was
tampered
with
like
in
our
original
case.
A
This
verifying
proxy
is
available
today
from
Nimbus.
It's
it's
a
part
of
the
Nimbus
E1
repo
in
the
LC
underscore
proxy
subfolder,
and
yesterday,
someone
announced
on
Discord
is
r
d
in
the
light
clients
Channel
a
product
called
keflar.
That
also
does
this,
including
proof,
verification
for
nft
ownership
and
token
balances.
A
A
Of
course
that
needs
a
modification
to
the
letter
software,
but
it
could
be
done
in
a
way
where
we
just
dump
all
of
this
data
to
The
Ledger,
and
it
can
actually
just
verify
that
it's
correct
it
uses
the
live.
Client
data
to
update
to
the
latest
public
keys
then
obtains
the
latest.
True
touch
then
verifies
that
the
balance
that
we
give
it
is
correct
using
the
Merkel
proof,
and
then
it
can
show
this.
It
can
show
the
balance
with
the
timestamp,
and
you
can
verify
that
this
transaction
is
really
something
you
want
to
do.
A
So
what
else
can
we
do
with
this
protocol
for
full
nodes
right
now?
It's
always
a
bit
tricky.
Where
do
you
obtain
that
initial
State
from
usually
you
just
go
to
infuro
and
scrap
States
finalized?
And
then
maybe
you
go
to
Beacon
chain
and
check
that
it's
the
correct
one,
but
with
this
protocol
you
can
just
hard
code.
A
The
merge
transition
block,
for
example,
into
the
client
and
then
use
the
lifeline
protocol
to
jump
to
the
latest
State
download
that
state
and
then
use
that
as
your
bootstrap
checkpoint,
without
having
to
validate
it
against
Beacon
chain
or
another
use
case,
a
decentralized
wallet
that
doesn't
need
to
talk
to
any
server
Geth
has
a
Mode
called
Les.
Currently,
it's
sort
of
a
thing
that
you
have
to
enable,
but
the
key
point
is
that
it
doesn't
require
a
huge
database.
A
A
So
you
just
need,
like
the
little
like
client
on
the
consensus
side,
25
kilobytes
a
day
about
20
bytes
per
second
to
follow
the
blocks
continuously,
and
then
you
can
pass
the
headers
over
to
guess
Les
and
it
can
then
filter
for
the
blocks
that
contain
interesting
transactions
and
just
download
those
few
blocks.
It's
not
every
block
for
sure.
A
So
if
we
go
a
bit
further
to
the
Future
layer,
twos
are
getting
more
important
and
for
them
the
problem
right
now
is
they
get
attacked
all
the
time
like
they
usually
get
operated
by
Oracle
nodes
that
are
trusted.
There
is
a
multi-stick,
maybe
5
out
of
nine
four
out
of
seven,
but
it
turns
out
that
one
party
owns
four
of
those
when
they
get
compromised.
A
Everything
gets
hacked
and
if
you
add
this
Lifeline
protocol
there,
it
can
sort
of
act
as
an
additional
safety
net
so
that
the
Oracle
notes
cannot
just
send
the
bogus
information.
So,
for
example,
when
you
make
a
deposit
into
a
bridge,
you
can
create
a
Merkel
proof
that
you
made
that
deposit
in
the
ethereum
state
and
if
there
is
a
light
client
deployed
to
that
layer
too.
A
A
C
Hello,
thank
you
for
the
great
talk.
I
see
a
lot
of
deformed
Bitcoin
Maxes,
who
say
that
it's
putting
too
much
pressure
on
the
nodes,
while
you're
part
of
the
sync
committee,
so
I
just
wanted
to
ask
what
do
the
resources
of
the
machine
look
like
while
you're
part
of
a
sync
committee,
CPU,
RAM
and
bandwidth.
A
So,
as
part
of
the
same
committee,
you
are
already
doing
extra
work
so
doing
this
extra
lag.
Client
work
is
actually
not
that
much
extra.
Basically,
what
you
need
to
do
is
you
need
to
Hash
the
state
and
you
need
to
grab
a
bit
of
static
data
out
of
it
because
you
already
loaded
the
state
and
getting
those
hashes
is
basically
instantaneous.
So
this
really
just
doesn't
add
that
much
for
nimbos
we
collect
the
lifeline
data
by
default
and
no
one
has
ever
complained
about
any
CPU,
Spike
or
bandwidth
Spike.
Due
to
that.
D
A
We
are
still
working
on
the
protocol,
for
example,
right
now
getting
access
to
the
execution.
Payload
header
is
not
that
easy.
You
need.
You
still
need
to
download
the
full
block
for
that,
but
we
are
targeting
a
couple
improvements
there
for
Capilla
that
further
reduce
the
amount
of
information
that
needs
to
be
exchanged
to
be
fully
synced
to
the
latest
head.
F
Oh
hey,
thanks
for
the
talk,
I
just
have
a
question
about
the
attack
that
you
showed
at
the
beginning
with
metamask
and
the
solution
that
you
came
up
with
at
Nimbus
as
how
to
mitigate
that
attack.
I'm
just
curious,
introduce
my
excuse,
my
ignorance
here
on
this
question,
but
like
why
doesn't
metamask
or
these
like
client
wallet
providers,
just
build
the
solution
and
instantiate
it
themselves
like
what
does
Nimbus?
Why
does
nimbus
need
to
be
brought
in
to
mitigate
this
attack?.
A
Well,
the
reason
there
is
that
actually
those
protocols
just
are
getting
standardized
right
now,
for
example,
the
rest
protocol
was
standardized
on
Monday,
so
that's
when
it
got
merged.
So
there
was
just
not
enough
time
yet
and
we
hope
for
sure
that
metamask
and
Ledger
will
integrate
those
security
enhancements
directly
into
their
products,
or
you
could
also
Imagine
a
scenario
where
Apple
and
Google
put
it
into
the
Android
and
iOS
operating
systems
as
a
background
service.
A
A
All
of
the
security
Implement
implications.
The
student
committee
is
sampled
by
random
from
the
full
validator
set,
so
the
full
Beacon
chain
currently
operates
under
an
honest
majority
assumption.
So
as
long
as
a
majority
is
honest,
the
beacon
chain
works.
So
if
we
sample
randomly
512
validators
from
that
set,
that
is
considered
to
be
honest
maturity,
then
the
same
can
be
assumed
for
the
smaller
set,
and
there
is
also
this
additional
safety.
A
That's
why
it's
more
than
the
weak
subjectivity
period
where,
because
like
it,
has
to
be
exactly
those
512
validators
that
are
only
assigned
for
that
particular
day
that
you
need
to
compromise.
If
you
look
at
it,
how
long
does
it
take
for
validators
to
exit
it
takes
about
four
months
until
enough?
Validators
are
exited
so
that
they
can
then
sign
conflicting
histories
to
compromise
this.
So
as
long
as
you
stay
within
the
four
months,
and
as
long
as
we
improve
the
protocol
with
those
flashing
methods,
then
I
think
it's
quite
a
secure
way.
A
What
you
have
to
keep
in
mind,
though,
is
that
the
student
committee
is
512
validators,
and
each
of
them
has
32
E's.
So
if
you
combine
all
of
these
balances,
it's
about
2
million
dollars,
so
that's
about
the
highest
cost
you
can
get,
even
if
everyone
would
be
fully
slashed
down
to
zero
any
attacker.
Who
can
offer
the
student
committee
a
higher
amount
than
that
can
compromise
this
so
right
now
for
highly
secure
applications
such
as
layer,
2,
Bridges
I,
would
recommend
it
as
an
additional
safety
net.