►
Description
Felfoldi Zsolt - EF
The Ethereum ecosystem already has multiple specialized protocols designed to serve a tightly defined purpose. Multiple development teams bring new ideas to this scene every day which lead to diverging implementations and protocol specs. This competitive evolutionary process ensures long-term progress but it also makes cooperation more challenging. Ethereum and the EVM facilitate a cooperative evolutionary process in blockchain application development by providing a virtualization layer. Through the example of LES (the Geth light client protocol), this talk shows how this approach can take us even further at the p2p protocol level. The growing blockchain size and increased performace demands, the scalability efforts require more and more sophisticated protocols and network topologies. A well-chosen virtualization layer can provide compatibility between platforms, implementations and similarly purposed protocols while also making the development of new features easier.
A
A
Created
a
lot
of
cooperation
even
in
a
highly
competitive
market,
and
this
basic
pattern
is
repeated
in
the
system
too,
and
I'm
not
just
talking
about
the
blockchain,
but
also
the
auxilary
services,
including,
of
course
form.
These
are.
These
should
be
building
blocks
for
the
next
generation
of
applications,
and
this
is
a
great
idea-
and
there
are
lots
of
lots
of
even
better
ideas
to
make
this
platform.
A
A
So
in
this
talk,
I
would
like
to
explore
the
potential
use
cases
for
employing
virtualization
techniques
on
the
individual
node
level,
both
for
in
order
to
improve
existing
protocols
and
client
designs,
and
also
for
moving
toward
a
more
general
Universal
protocol,
which
would
be
based
on
a
remote
code
code,
execution
and
then.
Finally,
I
would
also
like
to
propose
a
virtual
machine
architecture
which
I
will
believe
would
be
suitable
for
for
applying
level
and
also
for
verifying
remote
code
execution.
A
A
A
We
can
make
a
new
special
type
of
request
that
would
allow
clients
to
execute
some
virtual
machine
code
remotely
on
the
server
side,
of
course,
in
a
resource,
limited
environment
and
and
access
all
the
green
boxes,
which
could
provide
everything
that
alias
can
provide
for
its
clients
right
now.
It
could
provide
access
to
the.
A
A
A
So
we
could
implement
a
flexible
and
easy
to
develop
request
for
grading
scheme,
which
would
be
essential
for
shining
light
client,
but
there
are
other
potential
reasons
why
we
would
want
to
modules,
for
example,
for
extendibility,
and
for
that
a
good
example
is
the
client
connection
logic
which
decides
which
clients
to
accept
and
how
much
bandwidth
to
assign
to
them
and
simple
default
logic
for
this.
In
the
current.
A
And
also
there's
a
third
advantage
of,
and
that's
the
possibility
to
run
an
interactive
validation
in
case
of
ESD
chain.
Indexers
would
be
a
good
candidate
for
this,
because
so
these
these
are,
these
are
producing
the
canonical
hash,
try
and
the
bloom
filter,
try
which
I
won't
go
into
details,
but
these
are
health
data
structures
to
increase,
light,
client
performance
and
right
now
the
route
hashes
of
this
tries
are
hard-coded
into
the
light
client,
which
is
not
a
really
nice
solution.
A
And
now
this
we
have
talked
about
remote
execution.
We
can
take
this
idea
one
step
forward
and
we
can
realize
that
once
we
have
the
remote
execution
request.
That's
basically
all
we
need.
We
can
access
everything
else
through
the
backend
interfaces
and
we
can
apply
this
approach
to
all
kinds
of
protocols.
So
in
the
end
we
can
create
a
a
universal
peer-to-peer
protocol
which
accesses
or
the
application
specific
interesting
functionality
through
back-end
interfaces.
A
So
well,
it's
not
a
fundamental
change
because
we
just
move
some
functionality
to
another
level,
but
still
we
could
have
have
the
advantage
advantages
of
increased
flexibility
in
every
protocol.
For
example,
it
would
be
possible
to
run
a
complex
search
on
our
big
data
structure
in
this
form
by
just
being
connected
to.
A
We
can
do
all
kinds
of
things
which
are
needed
in
a
decentralized
computing
environment.
We
can
process
existing
data
structures
with
the
deterministic
stateless
calculations
and
we
can
also
observe
and
even
participate
in
in
consensus
protocols
with
higher
public
chains
as
they
channels
so
implementing
higher
The
Shard
observers
would
be
really
useful
for
shining
light
clients
and
since
the
stationers
are
sometimes
even
harder
to
observe,
because.
A
A
A
A
And
the
references
to
other
channels,
a
channel
reference
is
points
to
a
specific
message
in
a
channel
either
already
existing
or
future
message,
and
the
messages
themselves
can
also
hold
both
binary
data
and
references
to
channels
and
even
to
units
and
units
are
constructed
using
prototypes,
which
contain
which
can
contain
already
pre
compiled,
even
maybe
JIT
compiler
web
assembly
code.
I
think
it's
obvious
to
use
web
assembly
for
this
purpose
and
also
some
IO
port.
The
definitions
and
the
actual
instances,
of
course,
also
have
some
internal
states
and
memory.
A
And
the
the
construction
of
the
units
themselves
would
be
an
even
loop
design
so
that
they
could
wait
for
an
input
channel,
wait
for
a
message
to
arrive
and
when
it
arrives,
do
some
processing
send
some
output
messages
and
an
input
message
again
and
I
should
be
completely
deterministic.
So
it's
only
possible
to
wait
on
single
input
channels,
of
course,
of.
A
A
A
A
A
Thing
really
useful
and
do
something
interesting.
We
can
provide
it
with
some
system
defined
units,
and
these
units
can
do
all
kinds
of
time-dependent
behavior
like
channel
multiplexing
or
time
stamping
or
implementing
analogue,
to
send
a
message
on
a
channel
desired
time.
Systems
could
also
provide
a
random
generator
and
another
thing
that
the
system
units
can
provide
is
the
backend
interfaces,
the
green
boxes
in
the
previous
drawings,
which
can
provide
access
to
chain.
A
Database,
if
we're
talking
about
node
and
also
provide
an
interface
to
talk
to
other
clients
and
besides
constructing
the
network,
the
system
channel
has
another
very
important
function,
which
is
scheduling
so
whenever
I
mean
it
goes
into
a
waiting
State,
it
automatically
sends
a
scheduled
message
to
the
system
Channel,
including
its
own
reference
and
the
reference
to
the
channel
it's
waiting
on
and
when
the
system
service
resists.
This
message,
that's
when
it
actually
schedules
it
for
execution.
Why
is
this
important?
A
A
If
these
these
these
units
can
somehow
process
limit,
filter,
modify
the
system
channel
messages,
then
it's
possible
to
provide
all
kinds
of
different
virtualized
environments
inside
the
virtual
virtualized
environment,
and
this
can
so
this
may.
This
makes
it
possible
to
limit
what
a
child
Network
and
load
what
the
China's
work
does,
or
even
control
the
execution
of
child
units.
So
here's
an
example.
Drawing
of
a
load
balancer
which
what
it
does
is,
we
need
to
receive
the
scheduled
messages
from
its
children.
A
It
multiplexes
them
to
its
own
system
channel
in
a
way
that
guarantees
that
the
both
of
the
units
have
the
necessary
CPU
time,
maybe
even
limit
to
the
CPU
time
the
initiative.
So
it's
also
possible
to
implement
lazy
execution
of
these
networks
by
controlling
system
messages
and
the
execution
log
which
is
necessary
for
verification-
and
this
is
also
implementable
in
this
way,
and
it's
also
for
these
control
units
can
also
limit
what
system
unit
instances
the
China's
work
can
create.
A
For
example,
it
can
disable
creating
non-deterministic
units
if
necessary,
and
it
can
even
add
a
rapper
to
system
units.
So
for
this
a
good
example
again
is
the
alias
remote
code
execution,
because
when
the
when
the
application
code
receives
the
the
state
access
back
in
the
interface,
it
can
be
wrapped
into
a
wrapper
that
collects
all
the
marker
proofs
necessary
for
proving
the
operation
on
the
client-side.
So
the
application
code
doesn't
need
to
care
about
this.
A
Now
it's
also
possible
to
do
even
more
modification
of
behavior
by
by
even
pre-processing
the
actual
code
of
the
child
units
and
the
software
I
have
talked
about
applications
where
we
are
modifying
the
virtualized,
the
capabilities
of
the
virtualized
environment.
But
this
can
also
be
used
for
creating
the
same
virtual
environment
and
there
are
different,
actual
physical
environments
so
to
go
back
to
areas.
A
Examples
again,
it's
possible
for
a
food
and
a
foo
notice
possible
for
an
application
code
to
use
the
the
state
and
child
chain
on
a
traditional
and
yes
client.
It's
possible
to
use
a
simulated
back-end
that
uses
alias
request
to
to
beckon
requests
and
in
in
the
remote
execution
setup
it's
possible
to
use
the
before-mentioned.
A
A
B
A
There
are
other
other
applications,
so
I
told
about
hiring
notes
for
doing
verification,
jobs,
verifying
other
remote,
executors,
verifying
consensus
chain,
execution
and
so
for
for
these,
these
processes
are
usually
not
deterministic
because
they
are
so
they
are
connected
to
to
multiple
other
nodes
and
doing
real,
fast
and
stuff.
So
what
we
can
do
here
is
we
can
do
a
so-called
weak
verification
which
is
based
on
a
random
sampling
and
so
not
not
caring
about
whether
we
have
reasonable
grounds
to
suspect
that
someone
is
cheating
just
randomly
sometimes
requesting
pieces
of
calculation
to
verify.
A
Inside
an
execution
logger,
so
all
these
verifier
nodes
can
watch
each
other
watching
each
other
as
they
watch
each
other.
So
in
the
end,
if
we
have
enough
real
fire
nodes,
we
can
be
fairly
sure
that
at
least
most
of
them
are
doing
the
job
and
detective
one
of
them
is
not.
And
finally
this
is
optional,
but
if
we
want
even
more
security,
then
we
can
add
an
interactive
process
as
a
final
trying
to
cheat
so
interactive
validations
are
expensive
and
very
slow,
so
I.
A
Enough
for
for
ensuring
that
no
one
will
I
will
try
to
change
in
themselves,
but
they
are
very
good
as
a
as
a
threat
for
for
for
for
being
punished.
If
a
higher
note
tries
to
cheat
by
proving
it
the
the
fact
of
cheating
on
chain,
we
can
take
away
a
security
deposit
and
and
discourage
everyone
from
even
trying
to
not
execute
correctly.
So
this
is
what
I
wanted
to
talk
about
and
I
think
we
have
a
few
minutes
for
questions.
B
A
Different
approaches
are
possible,
but
so
I
believe
usually
it's
the
client
who,
whoever
is
ordering
rivers
paying
for
the
execution
and
the
verification
is
the
one
who
can
choose
the
denotes
who.
So,
if
there's
a
there's,
a
big
pool
of
potential
executor
and
verifier
nodes
that
the
client
can
can
can
pick
a
at
least
four
for
a
random
verification
and
well,
if
any
of
them
behaves
differently,
then
it
can
hire
even
more.
So
if
I
think
I
believe.