►
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/post-merge-ethereum-client-architecture/
Take a look at the key components of a post-merge Ethereum "node" and how they fit together, encompassing both the consensus and execution clients. How do the two clients work together? What impact does the different designs of clients have on that? And what opportunities are there for execution and consensus clients to work together better in the future?
Let's break down the knowledge silos between consensus and execution layers to get the most out of merged future of Ethereum.
Speaker(s): Adrian Sutton
Skill level: Advanced
Track: Layer 1 Protocol
Keywords: merge,client,architecture
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
What
an
awesome
stage
to
give
my
first
Devcon
talk
on
it's
fantastic
to
be
here.
Thank
you
for
taking
the
time
to
come
and
listen
so
I've
got
a
fair
bit
to
cover
I've
had
to
kind
of
keep
cutting
slides
all
week,
because
I
realize
how
small
25
minutes
is
so,
let's
get
into
it.
My
name
is
Adrian
Sutton
I'm,
a
lead,
blockchain
protocol
engineer
with
consensus.
A
I
started
out
four
and
a
half
years
ago,
actually
working
on
hyperledger
Basu
before
it
was
first
released
back
when
it
was
Pantheon
and
more
recently,
I've
been
focused
on
techu.
The
consensus
client,
so
I've
had
some
experience
with
both
the
consensus
side
and
the
execution
side,
building
new
clients
and
bringing
them
and
getting
them
ready
for
production
and
then
going
through
and
yeah.
Probably
the
highlight
of
my
life
now
will
be
having
having
seen
the
merge,
complete
and
go
through
so
very
proud
of
that
and
very
excited
for
for
ethereum.
A
This
isn't
the
kind
of
talk
where
I'm
going
to
tell
you
about
the
nitty-gritty
details
of
how
the
engine
API
Works
a
little
bit
of
assumed
knowledge
that
you
know
ethereum
here
but
I
think
that's
pretty
safe
for
this
audience.
I
think
you
should
all
be
able
to
follow
along
pretty
well
to
give
you
some
background.
There's
three
scene:
three
key
things
that
I
want
you
to
know
about:
ethereum
clients
and
that'll
form
a
real
grounding
for
the
things
we're
going
to
talk
about
post,
merge
and
what
they
mean
and
the
impacts
of
that.
A
So
the
first
thing
is:
there
is
a
lot
less
difference
between
consensus,
clients
and
execution
clients
than
most
people
believe.
Yes,
they
do
quite
different
jobs.
Yes,
at
every
opportunity,
when
we
were
designing
the
beacon
chain,
we
said
nah
mate.
We
can
do
that
better.
Let's
pick
a
different
technology,
so
there's
basically
no
shared
code
between
the
two,
but
there
are
a
lot
of
shared
concerns
and
Concepts,
and
there
is
a
lot
that
we
can
learn
by
talking
to
The
Other
Side
by
consensus,
client
developers
talking
to
execution,
client
developers
and
vice
versa.
A
Networking
is
probably
a
really
good
example
of
that
in
that
the
core
concept
of
it
really
has
three
parts.
The
first
is
Discovery.
We
need
to
find
peers.
Second,
is
Gossip,
so
that
new
information
flows
around
the
network
quickly-
and
the
third
is
request
response,
which
is
the
ability
to
say,
hey,
I
missed
some
data.
Can
you
give
it
to
me
or
I'm
syncing
how
do
I
catch
up?
A
Each
of
those
are
quite
different:
Technologies
for
Discovery
consensus
uses
Discovery
V5
executionally
uses
Discovery
V4
for
the
other
two,
it's
lib
P2P
versus
Dev
P,
to
p
and
in
terms
of
the
formatting
on
The
Wire,
it's
ssz
versus
rlp,
as
well,
so
completely
different
Technologies
underneath
it,
but
still
the
same
concern
of
how
do
we
find
peers?
We
can
trust
because
the
world
is
out
to
get
us
in
client
development.
We
don't
trust
anyone
and
there's
this
sea
of
peers.
How
do
we
find
the
good
ones?
A
This
idea
that
the
world
is,
is,
you
know
fixed
here,
it's
not
like
a
single
database.
Suddenly,
we,
we
realize
hey,
there's
a
better
chain
over
here
and
we
reorg.
How
do
we
pull
out,
say,
transactions
or
attestations
and
other
operations
from
the
chain?
We
were
on
and
check
that
they
all
made
it
onto
this
new
chain:
lots
of
code
and
lots
of
logic
flows
around
that
and
lots
of
impact
throughout
the
client
in
the
way
it's
designed
the
way
it
works
and
the
kinds
of
things
we
have
to
think
about
when
dealing
with
algorithms.
A
So,
on
the
consensus
side,
probably
the
big
thing
that
we
keep
coming
back
to
and
drives
a
huge
amount
of
our
decisions
and
has
impacts
everywhere
is
the
fact
that
proof
of
stake
is
not
just
a
block
driven
blockchain,
it's
also
time
driven.
So
even
if
no
blocks
are
produced,
the
world
State
continues
to
change.
Now
that
we're
in
proof
of
stake,
every
12
seconds
is
a
slot
whether
it's
empty
or
not.
A
So
if
you
ever
propose
something
to
a
consensus,
client
Dev
and
it's
going
to
slow
down
that
process
of
getting
a
block
out
and
then
brought
into
the
client
ready
to
be
attested
to
we're
going
to
have
a
hard
time
and
we're
going
to
push
back
on
the
execution
side.
It's
a
bit
different
time
is
still
important,
obviously
in
performance.
A
A
Difference
in
size
now
has
all
kinds
of
implications
for
performance,
and
it
means
that
there
are
all
kinds
of
different
approaches
to
how
you
handle
sync
to
how
you
prune
that
data
and
manage
it
as
it
changes
how
you
index
into
that
data.
That
impact
then
flows
through
the
rest
of
the
execution
client.
A
So
every
time
we're
touching
World
State
everything
that
has
has
operations
to
do,
whether
it's
transaction,
gossip
and
so
on
all
comes
back
to
this
world
State
and
getting
access
to
it
and
that's
what
drives
a
lot
of
big
things
for
execution
clients,
and
we
want
to
give
them
scope
to
keep
inventing
new
ways
of
dealing
with
things.
Okay,
post
merge
world
now
that
we've
set
the
scene,
the
deployment
model
you've,
probably
gotten
the
hang
of
these
days.
We
have
two
separate
clients.
A
You
need
to
run
both
a
consensus,
client
and
an
execution
client,
and
they
both
connect
to
their
own
PDP
networks
for
gossiping
data
and
retrieving
stuff.
The
blocks
come
through
the
consensus
client
pass
through
the
engine
API
to
the
execution
client,
and
it's
it's
that
engine
API
that
allows
the
consensus
client
to
to
control
the
execution
client,
and
this
is
one
of
the
first
things,
people
notice
as
something
we
probably
should
clean
up
post
merge
of.
Why
do
I
have
to
run
two
pieces
of
software
for
a
single
ethereum
node?
A
Well,
there's
a
couple
of
solutions
we
can
look
at
for
that.
The
first
is
embedding
a
light
consensus
client
into
an
X
into
each
execution.
Client
I
really
like
this
idea.
It's
simple
for
users
to
run
a
node.
It
reduces
the
system
requirements
like
client
consensus
is
a
lot
less
impact
and
a
lot
less
bandwidth
and
CPU
than
the
full
consensus
protocol,
but
it
does
come
with
some
trade-offs.
You
will
always
be
one
slot
behind
head,
because
you've
got
to
wait
for
the
sync
committee
to
do
its
job.
A
You
can't
run
a
validator
node
this
way
and
areas.
It's
a
reduction
in
security
guarantees
for
most
nodes,
like
if
you're
the
type
of
person
who
really
just
wants
to
run
one
thing
because
you're
running
a
home
node
and
you
just
want
to
send
some
transactions.
It's
probably
a
really
great
solution,
but
it's
not
for
everyone.
So
often
people
suggest
that
we
should
combine
clients.
We
should
take
a
consensus,
client
and
mash
it
into
the
same
process
with
an
execution,
client
I'm
a
lot
more
skeptical
of
this.
A
A
Are
we
really
going
to
maintain
20
different
combined
clients,
so
you
can
run
them
as
a
single
process
and
who's
going
to
do
that,
and
even
if
we
were
prepared
to
do
it,
there's
all
kinds
of
dependency
conflicts
that
we're
going
to
get
into
because
all
of
a
sudden
two
separate
development
teams,
work
is
being
pushed
into
a
single
process
and
to
resolve
that
means.
Development
teams
working
much
closer
together
and
being
restricted
by
what
they're
doing
so.
A
We
get
a
lot
more
cognitive
load
for
core
devs,
a
lot
more
coupling
and
we
lose
this
nice
separation
that
we've
somewhat
accidentally
got
between
consensus
and
execution
layers,
and
that's
that's
a
real
disadvantage
for
the
ethereum
ecosystem,
because
that
separation
and
the
ability
to
have
people
who
specialize
in
consensus
and
people
who
specialize
in
execution
allows
us
to
build
stuff
a
lot
faster
and
build
stuff
much
more
in
parallel.
The
final
thing
is:
it
encourages
client
scope
creep
that
might
be
a
little
unexpected
here,
so
let's
dig
into
it
a
bit
more.
A
This
is
what
a
real
ethereum
deployment
often
looks
like,
and
it's
not
as
simple
as
the
first
picture,
because
we
learned
ages
ago,
even
before
the
merge
right.
We
let
ages
ago
that
putting
your
wallet
inside
your
execution
client
is
just
dumb.
It's
really
bad
for
security,
and
so
we
stopped
doing
it.
You
know
I
if
you've
managed
to
load
your
private
wallet
key
into
yes
still
and
you're,
using
those
Key
Management
apis.
A
Please
stop
use
a
real
wallet
and
so
you're
already
using
two
processes,
you're
already
using
two
different
things
to
access
ethereum,
then
not
every
consensus
client
supports
running
the
validator
client
in
the
beacon
node.
At
the
same
time,
in
the
same
process,
some
do
some
don't
very
common
requirement
for
people
wanting
to
set
it
up
to
have
a
separate,
validated
client
for
various
reasons,
and
you
might
even
take
it
a
step
further
and
want
to
secure
your
keys
more,
and
so
you
use
an
external
signer
that
possibly
has
an
actual
database
for
slashing
protection.
A
You
probably
should
be
monitoring
your
32
East
investment
at
minimum,
so
you
get
something
like
Prometheus
Everyone
likes,
flashy
graphs.
So
now
you've
got
provider
and
then
you
start
adding
on
things
like
MAV
boost.
So
all
of
a
sudden
we've
got
a
lot
of
stuff
going
on
it's.
You
know
you
can't
imagine
all
of
this
being
put
into
one
process:
it's
not
viable,
it's
not
what
we
want
to
do
and
it
you
know,
and
we
don't
want
to
lock
people
into
saying:
hey,
get
started
with
ethereum.
Here's
a
single
process.
A
Oh,
you
want
to
do
something
well,
yeah,
throw
out
everything
you
learned.
Do
it
a
different
way
doesn't
make
a
lot
of
sense.
So
what
I
think
is
the
real
solution
here
is
eat.
Os
important
note,
please
don't
make
it
an
actual
OS
right.
We've
got
good
operating
systems,
but
this
idea
of
moving
up
a
layer
of
coordination
is
going
to
be
really
important
so
that
we
can
maintain
this
decoupling
of
consensus
and
execution
clients.
They
don't
need
to
know
too
much
about
each
other.
A
They
use
the
standard
apis
to
communicate,
but
we
can
start
with
here's
a
single
process.
You
run
and
it
will
spin
up
your
execution
and
consensus
client
and
have
them
hooked
together,
ready
for
you,
then,
if
you
want
to
add
a
validator
it'll,
add
in
a
validated
client
for
you,
it's
just
another
config
option
without
having
to
start
again
same
for
Mev
same
for
metrics,
and
so
on
the
really
good
news
about
this.
It
already
exists
in.
In
fact,
it
exists
in
multiple
forms.
A
What
are
some
of
the
other
problems
and
opportunities
that
we
now
have
because
of
the
merge
and
and
the
way
that
these
two
clients
work?
The
first
one
is
a
pretty
big
one.
We
got
a
bunch
of
data
duplication,
so
the
consensus
client
blocks
include
the
execution
payload,
which
is
what
your
execution
client
sees
as
a
block
kind
of
by
default,
both
clients
wind
up,
storing
that
data.
A
So
we've
duplicated
the
execution
payload,
which
is
what
contains
all
the
transactions
it's
pretty
big
and
that
increases
our
disk
space
requirements
overall,
so
you
will
probably
see
if
you're
running
a
beacon,
node
post,
merge
its
database
will
grow
in
size
faster
than
it
did
pre-merge
because
of
these
extra
transaction
data.
There
are
a
couple
of
ways
we
can
address
this.
The
first
one
is
that
there's
a
proposal
that's
been
around
since
pre-merge,
but
just
execution
climates
didn't
have
time
to
deal
with
it.
Basically
and
I'm,
not
sure
consensus.
A
Clients
did
either
for
get
payload
bodies.
Now
what
this
is
is
it's
a
fairly
efficient
way
for
a
consensus,
client
to
say:
hey
I
need
the
payload
for
this
range
of
blocks,
and
that
way
the
consensus
client
can
simply
stop
storing
it,
and
instead
it
can
rely
on
the
fact
that
the
execution
client
will
be
storing
those
blocks
anyway.
The
consensus
client
does
need
that
data
and
it
needs
it
fairly
quickly
when
it
gets
it
because
things
like
queries
to
its
rest,
API.
A
If
you
ask
for
a
block,
it's
got
to
give
you
the
full
block.
So
it's
got
to
go
and
get
it
and
the
same
for
networking
when
peers
request
a
block,
it's
the
full
block
that
we
need
to
send
back
and
that
in
particular,
we
want
to
be
fairly
fast
and
we
really
want
it
to
be
efficient.
That's
probably
the
Big
Challenge
we
have
with
this
deduplication
right
now.
A
Is
that
we're
asking
the
execution
client
to
store
data
and
give
us
access
to
it
on
our
terms,
if
you
remember
the
big
thing
for
execution,
clients
was
managing
data,
they
have
a
lot
already.
Their
databases
are
under
a
lot
of
pressure
and
that's
the
performance
bottleneck,
so
Lighthouse
has
a
feature
where
they
will
kind
of
emulate.
This
get
bodies.
This
forget
payload
bodies
through
the
existing
Json,
RPC,
Cool
Tech
well
done,
and
it
turns
out
it
puts
a
lot
of
pressure
on
the
execution
clients.
A
Sometimes
it
works
well
if
you've
got
enough
I
O,
sometimes
it
hasn't
and
they've
added
an
option
to
be
able
to
turn
it
off
and
just
go
back
to
duplicating
the
data
which,
for
some
people
has
worked
out
better.
The
other
issue
that
floats
around
here
is
that
we
get
an
increased
coupling
between
the
two
clients
again,
not
so
much
in
terms
of
The
Logical
side
of
it.
A
In
terms
of
you
know
what
their
responsibilities
are,
but
more
in
that,
if
your
execution
client
is
resyncing,
your
consensus
client
just
lost
a
bunch
of
block
data.
It
thought
it
had
and
there's
a
lot
of
complexity
around
how
to
deal
with
that.
It's
it's
reasonable,
you'll,
probably
just
start
getting
errors
from
the
rest,
API
and
say:
oops.
Don't
have
that
block
all
of
a
sudden
same
for
peers,
it's
quite
possible
to
go
and
have
that
block.
A
Anyway,
all
these
details
can
be
worked
out,
but
it's
kind
of
part
of
cleaning
up
the
mess
we
left
behind
when
we
got
the
merge
done.
The
other
solution,
which
is
a
bit
easier
and
kind
of
cheating,
is
let's
just
not
store
all
the
blocks.
So
we've
talked
about
this
with
eip44s
on
the
execution
client
side
for
quite
a
while,
and
the
consensus
client
learning
from
that
actually
put
in
the
spec
that
we
don't
have
to
keep
all
the
blocks
all
the
way
back
to
Genesis.
A
A
It
certainly
would
be
for
a
lot
of
people
and
we
can
do
D
the
deduplication
as
well
to
make
it
even
smaller.
The
really
nice
thing
about
that
is
that
for
for
consensus,
clients
that
aren't
trying
to
form
an
archive
node
that
would
make
their
disk
usage
almost
static,
it
would
grow,
but
only
really
slowly
as
the
number
of
validators
grow
and
the
the
beacon
state
grows,
which
is
it's
relatively
small.
That
way.
A
We're
kind
of
avoiding
this,
this
ever-growing
creep
of
disk
space
usage
that
we've
kind
of
seen
with
ethereum
because
of
the
growing
World
state.
It's
nice
to
the
consensus,
client
doesn't
necessarily
have
to
have
that
problem.
Drawback
is
obviously,
if
you're
running
an
archive
node.
Then
you
want
to
store
all
the
blocks.
You
want
to
store
all
the
data
and
you're
really
going
to
want
to
lean
on
the
deduplication
to
save
this
device.
A
Instead
of
this
approach
and
the
other
part
which
things
like
the
portal
Network
are
aiming
to
solve,
that
those
older
blocks
are
harder
to
find.
You
can't
just
request
them
from
any
peer
on
the
network
and
they
potentially
become
unavailable.
That's
technically,
okay,
but
it
doesn't
feel
good
for
a
blockchain
to
kind
of
lose
old
data.
So
it's
not
really
something
we
want
to
encourage
and
we
want
to
have
systems
in
place
so
that
we
do
hold
on
to
them.
A
Excuse
me
between
the
consensus
and
execution
clients.
Oh,
that
water
didn't
help
yeah.
So
this
interaction
between
the
two
clients
into
in
terms
of
non-canonical
blocks.
So
blocks
that
we
receive
that
we
don't
believe
are
part
of
the
canonical
chain.
Maybe
we
receive
them
really
late
or
whatever
for
an
execution
client,
particularly
ones
that
only
store
one
version
of
the
world
State
rather
than
the
full
tree
of
all
the
world.
A
I
will
store
it
and
it's
here
if
it
becomes
canonical
sure
I'll
execute
it,
but
I'm
not
doing
it
now
and
they
can
return
accepted.
The
problem
is
on
the
consensus,
client
side.
We
have
to
track
that.
That
block
isn't
fully
valid,
so
the
execution
client
didn't
execute
it
because
you
know
World
State's
big.
That
makes
a
performance
problem.
A
That
kind
of
thing
on
the
consensus
client,
though,
that
delay
in
execution
might
become
a
problem
if
we
have
to
reorg
over
to
that
block,
because
it's
going
to
add
delay
right
at
the
point
where
we're
likely
to
not
want
it.
That
time
sensitivity
thing
so
we're
about
to
create
a
block,
and
we've
realized
hey
we're
on
the
wrong
chain.
We're
going
to
reorg
over
to
this
one.
All
of
a
sudden
we've
got
a
block.
We
don't
know
is
valid
that
we
think
is
now
the
canonical
chain.
A
A
It's
just
the
normal.
Day-To-Day
plugging
away
of
engineering
so
keep
up
with
the
latest
versions
of
your
clients
and
life
will
keep
getting
better
I
think
we
want
to
continue
to
learn
from
the
other
side
right
consensus
and
execution.
Clients
through
the
merge
process
have
really
started
talking
to
each
other,
a
lot
more
than
they
did
back
before.
We
were
really
focused
on
the
merge.
We
want
to
keep
that
going.
We
don't,
though,
need
execution,
client
devs
to
be
an
expert
in
consensus
layer.
A
That
split
is
powerful
and
we
want
to
really
leverage
it
and
look
for
other
places
where
that
kind
of
split
can
be
useful,
and
that's
part
of
embracing
this
kind
of
multi-component
future
of
ethereum
that
you
don't
need
to
know
everything
about
every
component
of
ethereum.
You
can
know
your
little
part,
even
just
within
the
the
layer
one.
That's
all
I've
really
got
time
for
so
you
know
thank
you
for
listening
and
I've
I
do
believe.
We
have
some
time
for
questions
which
would
be
awesome.
B
C
Cool
talk
thanks,
so
you
mentioned
multi-component
and
embracing
that
aspect
and
I
think
for
the
most
part,
you
know
we're
on
our
way
towards
that
I.
Think
one
area
where
that
is
not
quite
the
case
is
between,
like
the
beacon,
node
and
the
validator
across
clients,
right
for
like
prism
or
Lighthouse.
C
A
A
In
practice
it's
been
a
bit
hit
and
miss
we've
actually
seen
really
good
compatibility
with
everyone
else
except
prism,
so
prism
uses
grpc,
they
kind
of
got
in
first
and
did
it
and
we
didn't
listen
to
them
and
did
a
rest
API,
because
we
liked
it
more
and
kind
of
outvoted
them.
So
we
put
them
in
a
hard
place
there.
A
So
their
validated
current
uses
grpc.
They
do
expose
the
standard
rest
apis,
so
most
clients
can
their
validated
clients
can
connect
to
prism,
but
prisms
valid.
A
client
generally
can't
connect
to
anything
else.
Otherwise
they
generally
interrupt
pretty
well
and
particularly
for
teku,
because
infuro
was
exposing
the
beacon,
node
apis,
which
they've,
deprecated
and
removed.
Now,
because
people
kept
running
validator
clients
against
inferior,
which
is
kind
of
terrible,
so
it
is
possible.
It
is
something
that
we
need
to
to
ramp
up.
A
Testing
on
more
every
so
often,
we
find
a
little
corner
case
that
didn't
work
as
well
as
it
should
and
those
kind
of
things,
but
yeah
a
lot
of
the
that
the
base
layer
is
there
for
it,
mostly
it
works
and
I
think,
particularly
with
post,
merge,
it's
going
to
become
more
and
more
common,
because
you
so
often
use
a
validated
client
that
failed
over
between
two
Beacon
nodes.
Now
there
is
another
question.
D
Another
hey
Adrian,
thanks
for
the
talk
I
want
to
ask:
what
are
your
thoughts
on
current
design?
Did
the
consensus
client
is
tightly
coupled
with
the
execution?
Cloud
I
mean
one
consensus
cloud
has
to
talk
to
One
execution
client
that
sound
like.
What's
the
reasoning
behind
it,
another
thing
like
what
do
you
think
about
DVT
distributor,
validator
Tech,
and
how
will
it
influence
the
the
future
of
clients.
A
Yeah,
so,
on
the
first
part
there
it
is
pretty
much-
and
I
probably
should
have
mentioned
this-
that
that
one
consensus
client
generally
has
a
tight
coupling
to
one
execution
client.
The
key
reason
for
that
is
that
the
consensus
client
is,
is
writing
and
updating
and
controlling
the
execution
client.
A
There
are
some
solutions
and
I
think
this
is
part
of
the
multi-component
stuff
that
you
can
actually
run
a
middleware
layer
that
will
take
the
option,
the
the
calls
from
the
consensus,
client
and
spread
them
across
multiple
execution,
clients,
I
love
that
I
love
that
it's
built
as
a
separate
thing
and
not
something
that
is
a
client
Dev.
I
have
to
do
myself,
because
it's
hard
and
there's
a
lot
of
different
policy
scope
there
in
terms
of
do
I
trust.
A
This
is
my
primary
execution
client,
you
know
what,
if
they
disagree,
do
I
want
two
out
of
three
to
agree
all
these
kind
of
details.
We
can
build
that
really
well
with
a
dedicated
product
rather
than
trying
to
build
it.
You
know
five
times
once
in
each
consensus,
client
in
terms
of
distributed
validated
technology,
I'm,
not
a
huge
expert,
but
again
that's
pushing
towards
becoming
a
middleware
layer
and
I
think
that's
again,
really
powerful
and
really
good.
A
So
it's
something
I'm
really
Keen
to
see,
keep
evolving
and
keep
kind
of
finding
new
ways
of
doing
it,
and
and
ideally
that
we
find
ways
of
adjusting
pretty
much
the
the
validator
apis
that
we
use
those
rest
apis
I
talked
about
before
adjusting
them,
so
they're
more
and
more
conducive
to
an
external
piece
of
software
just
being
able
to
handle
it
all
and
handle
it
well,
there
might
be
some
trade-offs
there.
We
might
hit
some
limits,
I,
don't
know,
but
yeah
definitely
a
technology
to
keep
investigating.