►
Description
Speaker: Alex Beregszaszi, co-lead at Ethereum Foundation
Topic: Fizzy — A deterministic interpreter
Fizzy https://github.com/wasmx/fizzy
Ethereum https://ethereum.org/en/
Wasm in Web3 workshop https://avive.github.io/wasm_on_the_blockchain_2021/#/
A
A
I
would
also
mention
that
pavel
who
is
whose
talk
is
after
mine
will
cover
a
lot
of
the
really
nitty-gritty
details
regarding
the
the
testing
and
and
all
the
different
findings.
We
have
come
across
with
fizzy,
but
I
will
first
just
give
like
an
overview
of
the
the
topic
of
interpreters
and
then
go
into
fizzy
in
a
bit
more
detail.
A
Let
me
if
this
works.
Okay,
yeah.
So,
as
you
mentioned,
our
team
is
just
called
epsilon
and
we
don't
really
have
a
website
apart
from
this
hackmd,
but
we
publish
all
the
different
findings
and
the
specifications
and
we
do
and
there's
quite
a
few
of
them.
We
also
publish
on
each
research
and
ethereum
magicians,
but
of
course
all
of
these
are
rather
ethereum
centric
and
currently
we're
mostly
working
on
on
evm
related
optimizations.
A
So
just
going
back
to
the
actual
background,
you
know
how
all
of
this
started,
and
then
you
know
why
we
made
any
of
these
decisions.
I
have
to
go
back
to
the
very
beginning,
which
was
in
2016
or
rather
in
2015,
when
we
started
to
work
on
webassembly,
and
I
believe
this
was
the
the
the
first
application
of
webassembly
to
like
a
blockchain
context,
and
our
initial
requirements
were
quiet,
simple.
We
just
wanted
deterministic
execution
and
we
wanted
instant
startup
time
and
we
wanted
fast
execution
time.
A
So
these
were
the
requirements,
and
here
I
I
need
to
because
I
said
you
know
we
want
to
determine
the
execution.
I
want
to
expand
a
tiny
bit.
You
know
what
that
does
that
mean
so
under
this
we
mean
that
between
two
points.
The
first
point
is
that
there
must
be
some
kind
of
a
limit
and,
within
that
limit
execution
has
to
always
stop
at
the
same
place.
A
The
second
point
is
that
under
determinism,
the
results
have
to
be
identical
of
the
execution
and
no
matter
which
host
machine.
You
run
it
on,
and
you
know
whether
it's
like
an
x86,
whether
it's
an
iron,
whether
it's
any
kind
of
other
exotic
machine,
it
has
to
result
in
a
very
same
outcome-
and
here
I
mentioned
like
two
important
points
which
could
cause
concern.
The
first
is
any
kind
of
floating
points
and
because
floating
points
can
be
implemented
differently
across
different
platforms
and,
in
fact,
x86
and
arm
implements
some
parts
differently.
A
The
second
point
is
that
different
host
computers-
and
this
doesn't
only
apply
to
to
different
cpus,
but
rather
different
os's
different
operating
systems,
may
have
like
different
default
stack
sizes.
One
example
is
that
mac
os
versus
linux,
the
mac
os,
has
a
much
smaller
default
stack
size,
and
what
this
can
cause
is
that
if
you
recurse,
you
make
multiple
calls
and
those
could
result
in
a
failure
at
different
points
of
time,
depending
on
how
much
stack
space
you
have.
A
So
that's
all
I
wanted
to
say
with
determinism
and-
and
now
you
know
with
with
knowing
what
the
initial
requirements
were
when
we
started
with,
he
wasn't,
and
these
were
the
our
expectations
we
expected
that
we
may
have
some
issues
with
determinism
with
metering
and
maybe
with
the
interfaces,
how
to
use
wasm
in
the
context
of
contracts,
and
we
expected
there
won't
be
any
issues
with
speed
and
there
would
be
a
lot
of
different
vms
we
could
use.
So
these
were
our
expectations.
A
A
That
was
definitely
a
giant
issue
and,
as
we
learned,
these
different
vms
may
have
different
problems
associated
with
them,
and
especially
I
mentioned
aots
and
jits.
More
importantly,
jits,
of
course,
which
we
have
found
some
issues
with
and
then
for
the
the
points
we
we
hope
that
there
wouldn't
be
any
issues
with.
A
Actually
those
were
the
things
you
know.
We
hope
that
speed
on
the
vms
were
on
the
issues,
but
of
course
those
were
the
main
issues.
So,
instead
of
these,
what
we
found
is
that
the
terminus
determinism
and
metering
isn't
that
bad
those
can
be
solved
and
they
can
be
solved
quite
easily.
So
it's
really
just
the
speed
and
the
vms,
which
became
the
problem
so
based
on
these,
our
initial
choices,
you
know
how
to
accomplish
e-wasm
was
that
we
wanted
to
inject
metering
into
wasn't
code.
A
We
insert
extra
statements
which
counts
the
execution
steps
and
we
use
different
costs
for
different
kind
of
instructions
and,
for
example,
a
more
complex
call
instruction
is
likely
more
expensive
than
just
a
regular
edition
and,
secondly,
we
wanted
to
inject
call
depth,
checking
it
wasn't
code
similar
to
metering,
and
this
is
to
ensure
that
the
different
stack
sizes
wouldn't
cause
any
any
difference.
And
lastly,
we
just
wanted
to
reject
any
code
which
has
floating
points
in
our
use
case.
Floating
points
weren't
crucial.
A
A
and
back
then
we
used
binarian
and
v8,
which
is
the
the
javascript
engine
of
chrome
and
also
used
in
node.js.
So
the
good
results
were
that
everything
works.
The
the
metering
overhead
is
is
not
terrible.
It's
it's
quite
okay.
64-Bit
operations
are
really
fast
compared
to
the
evm,
of
course,
and
256-bit
operations
are
not
as
fast
as
we
hoped
and
definitely
not
as
fast
as
they
are
on
the
evm.
A
The
the
the
problem
case
we
have
found
is
an
attacker
could
craft
a
piece
of
wasm
code
which
increases
the
compilation
time
of
the
wasan
code
into
the
native
code
excessively,
and
this
is
basically
a
case
where
somebody
could
the
os
attack
the
network
at
that
time
there
weren't
any
ahead
of
time,
compilers
or
at
least
stable
versions
of
them.
So
basically
we
just
decided.
Okay,
we
have
to
to
pause
the
work
on
this
v.
A
We
didn't
want
it
to
write
the
vm
right
at
all
and
then
binary
and
was
pretty
slow,
so
we
we
switched
to
to
web
it,
which
was
at
a
time
the
the
next
best
option.
So
we're
talking
about
2018.,
so
in
like
early
2018,
when
we
started
work
on
rebit.
Obviously,
here
I
don't
want
to
give
like
a
you
know,
a
day-to-day
timeline,
because
over
these
years
of
course,
a
lot
of
things
happen.
A
So
this
is
just
like
an
excerpt,
but
in
like
2018
with
webbit,
we
have
mostly
done
different
optimizations
on
the
interpreter
itself.
I
just
mentioned
a
few
here.
One
interesting
one
is
we
combine
multiple
wasm
instructions
into
just
super
instructions,
so
one
combined
instruction,
which
does
the
sum
of
all
those,
and
this
is
of
course
not
like
a
novel
idea.
This
is
exactly
what
jits
also
do
and
ahead
of
time
compilers.
A
A
I
won't
really
explain
all
of
them,
but
yeah,
please
go
ahead
and
browse,
so
the
results
were
that
what
it
is
is
pretty
fast,
so
this
on
the
right
is
like
what
stock
webbit
did.
This
on
the
left
is
what
the
native
rescued
would
do
in
the
middle
is
our
optimized
rabbit,
which
is,
is
pretty
good.
The
red
one
is
the
startup
time
and
the
blue
is
the
actual
execution
time.
A
So
all
of
that
combined,
we
are
like
at
3x
td
native
34x
native,
but
it's
insanely
more
fast
than
you
know
not
doing
any
of
these
optimizations.
So
we're
quite
happy.
But
of
course
there
were
some
some
new
problems,
mainly
that
vebit
and
especially
our
changes.
It's
it's
not
production
ready.
This
was
just
a
prototype,
but
the
second
more
problematic
requirement
we
had
is
that
the
vm
should
be
small
and
understandable
by
the
client
maintainers
and
by
client
maintainers.
A
I
mean
all
of
those
people
who
maintain
ethereum
clients
because
remember
our
main
goal
is
to
introduce
wasm
to
ethereum
and
those
people
at
least
today.
They
understand
the
evm.
It's
it's
pretty
simple.
They
understand
every
single
part
of
the
system,
and
if
you
want
to
introduce
like
webassembly
to
them,
you
are
introducing
a
black
box.
So
the
requirement
is,
if
we
can
make
this
black
box
to
be
understandable
by
them,
then
there's
a
much
better
chance
of
acceptance
and
just
as
a
remark,
I
said
that
we
also
used.
A
So
here's
like
an
overview
what
we
had
of
the
different
interpreters
in
mid
2019,
just
one
sec
yeah,
and
so
basically
these
were
the
interpreters
at
the
time
there
was
binary
and
rabbit
was
me
warmer
and
then
dragon.
At
least
these
were
the
ones
we
looked
at
and
speedwise
wagon
and
binary,
and
they
weren't
really
good.
So
the
choice
was
that
vebit
was
me
and
warmer,
but,
as
I
said,
webbit
wasn't
really
production
oriented.
A
You
know,
as
we
discussed
at
least
we
placed
a
question.
Well,
it
is
more
like
a
toolkit
and
it's
it's
really
just
a
an
implementation
of
the
specification.
It's
not
really
designed
to
be
like
a
production
tool,
at
least
not
like
in
such
a
context.
We
wanted
it
to
be
and,
and
that
that
just
left
us
with
was
me
and
warmer
and
and
their
issues
we
have
found
with
was
me
and
vomer
was
like
the
integration
part,
integrating
rust
with
different
languages.
A
A
So
finally,
we
got
to
fizzy
at
this
point
and
I'm
just
going
to
list
the
different
goals
we
have
and,
and
we
have
four
categories
of
goals.
The
first
category
is
is
the
code
quality
and
we
really
want
to
have
a
small
code
base.
You
know
because
of
the
the
reason
I
mentioned,
and
we
also
don't
want
any
kind
of
external
dependencies.
A
You
know
if
you
can
avoid
them
if
you
want
extremely
clean
and
readable
code
and
it
has
to
be
easily
embeddable
and
the
second
category
is
simplicity,
and
this
is
an
interesting
one,
so
we
only
want
to
support
web
assembly
1.0
and
it's
you
know.
This
is
a
question.
What
what
is
episome
1.0
and
we
started
to-
maybe
you
know
wrongly
at
least
internally
refer
to
the
mvp
as
1.0
and
pavel
in
the
next
talk
we'll,
I
think,
explore
this
topic
in
more
depth.
A
But
basically,
what
we
mean
is
the
the
mvp
without
any
of
the
extensions.
Of
course,
this
doesn't
mean
that
none
of
the
extent
extensions
would
ever
be
supported,
but
the
goal
is
that
those
extensions
would
only
be
supported
once
they're
like
fully
final
deployed
everywhere
up
until
that
point,
they're
really
just
experiments.
At
least
you
know
in
the
eyes
of
visit.
A
A
The
next
set
of
goals
is
conformance.
We
really
want
to
have
a
high
unitas
coverage
and-
and
you
know,
we
want
to
be
really
strict
on
testing.
We
want
to
pass
every
single
possible
test
and-
and,
lastly
is
you
know,
firsthand
support
for
blockchains,
and
so
you
mentioned
a
couple
of
things:
the
floating
point
metering,
the
important
part
with
metering
here
so
far.
I
only
mentioned
injected
metering
because
we
didn't
want
it
to
modify
a
vm,
but
here
we
have
the
opportunity
to
modify
vm
and
doing
runtime
metering.
Doing
all
of
this.
A
So
here's
some
some
numbers-
and
you
know
what
fizzy
looks
like
today,
the
core
logic
itself,
and
by
this
I
mean
the
the
parser,
the
instantiation
part
and
the
execution
part
and
the
these
are
the
actual
lines.
So
it's
I
didn't
go
at
looking
at
the
the
number
of
statements,
but
the
actual
lines
in
the
file.
It's
only
3
500
lines
in
total
and
we
have
100
unit
test
coverage.
Of
course
we
pass
all
the
upstream
tests
and,
according
to
our
measurements,
we
are
the
second
fastest
interpreter
on
the
market.
A
After
wasn't
three
here's
some
speed
comparison.
I
only
listed
these
three
because
these
three
vms
are
integrated
into
our
benchmarking
system.
In
physio
itself,
we
did
had
some
prs
to
also
support
ssvm
and
to
support
walmart,
but
yeah.
We
had
some
issues
with
the
the
apis
of
of
those
vms
and
found
some
some
bugs,
or
at
least
you
know,
maybe
things
we
didn't
fully
understood.
I
think
we
did
open
some
some
issues
upstream,
but
we
couldn't
fully
like
integrate
those
into
benchmarking
system.
A
That's
why
they're
excluded
here,
but
we
do
have
wasn't
free
and
vivid,
and
I
think
what
we
found
in
general
that
fizzy
is
like
two
to
five
x,
lower
than
wasn't
three,
but
is
five
to
ten
x
faster
than
vevit,
and
we
did
do
measurements
outside
of
this
benchmarking
framework
in
infizi.
With
these
these
other
vms,
and
there
we
have,
we
have
seen
that
the
at
least
ssvm
and
and
warmer
at
the
time
they
were
of
similar
speed
of
levitt.
A
So
a
few
more,
I
guess
just
some
of
the
features
we
wanted
to
summarize
about
fizzy
itself
is
we
have
decided
to
use
c
plus
plus
for
the
core
implementation,
and
initially
we
did
use
exceptions
for
everything,
but
we
did.
There
was
more
like
a
temporary
measure.
We
didn't
really
wanted
to
use
exceptions,
you
know
indefinitely,
but
we
did
remove
them
from
everywhere,
except
parsing,
and
this
provided
quite
a
big
boost.
A
A
We
also
looked
into
adding
support
for
the
wasmc
api
and
it
wasn't
c
plus
plus
api,
which
is
used
by
some
of
the
other
vms,
but
so
far
we
haven't
done
that
because
it
is
quite
a
complicated
api
in
terms
of
the
number
interfaces
which
need
to
be
introduced.
The
the
wasmc
api
header
file
itself,
I
believe,
is
you
know
as
long
as
the
entire
source
code
of
like
fizzy
itself,
we
do
have
a
rust
binding
and
we
do
have
what
what's
the
support.
A
It's
not
like
fully
complete,
but
it's
easy
to
complete
each
of
the
the
functions
we
just
didn't
have
time
for
them
and
we
have
a
benchmarking
tool,
which
I
mentioned
fizzy
bench
and
it
it
is
easy
to
extend
with
with
new
test
cases
it
is
and
that
that
is
what
I
used
for
the
charts
before
and
we
have
runtime
metering
then
on
the
testing.
I
just
wanted
to
mention
a
few
things
here,
but
pavel
will
go
really
deep
dive
into
this.
A
So,
of
course,
we
have
unit
tests
which,
which
we
used
with
to
to
find
issues
like
test
cases
which
were
uncovered
by
by
upstream,
but
we
do
have
a
runner
for
the
spec
tests
and,
as
I
mentioned,
we
don't
really
have
support
for
the
text.
Webassembly
format,
and
that
is
not
a
problem
because
we
can
use
webbits,
was
to
json
to
translate
the
test
cases
and
that's
what
we
do.
A
That
was
one
of
the.
The
only
reason
we
would
ever
wanted
to
have.
The
text
format
is
for
specters,
but
since
webbit
has
this
tool
we
there
was
a
really
good
find.
And,
lastly,
we
have
a
special
testing
tool
based
on
this
berkeley
test
float,
which
is
a
quite
large
test,
suite
to
compare
against
ie754
floating
point
conformance
again
pavel
we're
we're
talking
in
more
detail
about
this
okay.
A
A
We
do
have
different
versions
of
it,
but
we
don't
really
have
a
final
and
then
well
well-designed
one
that
would
be
the
you
know,
one
of
the
the
major
last
remaining
items
for
fizzy
and-
and
we
could
also
consider
some
some
further
restrictions
of
complexity
by
adding
limits
due
to
various
various
fields
in
wasm
itself.
Initially,
we
thought
that
this
could
provide
quite
a
big
boost,
but
now
I
think
we're
leaning
towards
that.
A
So
the
new
additions
are
wasn't
tree
and
was
an
edge,
was
images
as
the
new
name
of
ssvm
and,
of
course,
fizzy,
and
I
want
to
highlight
that
you
know
these
labels.
These
are
really
subjective
by
production
oriented.
You
know,
we
just
mean
that
they're
not
designed
to
be-
or
at
least
you
know,
based
on
on
our
understanding
or
opinion.
They
do
not
really
their
goal
isn't
to
be
used
in
in
like
production,
blockchains
or
or
such
use.
A
Cases
they're
more
like
a
hobby
project
or
a
academic
research
project,
or
maybe
they're
like
at
an
earlier
time
where
they,
they
really
focus
on,
like
certain
properties
and
not
others,
and
one
property
for
wasn't
tree
is
the
speed
and
our
experience
was.
Entry
is
really
just
focusing
on
the
speed
currently
and,
of
course,
they're
they're,
the
best
at
that.
It's
really
hard
to
beat
them,
if
not
impossible,
but
we
did
find
a
few
issues
and
bugs
it
wasn't
free
which,
which
is
is
understandable.
A
Given
you
know,
they're,
not
really
at
least
at
the
time
they're,
not
focusing
on
being
like
production,
ready
software
they're,
focusing
on
being
the
fastest,
and
I
think
they're
gonna
they're
gonna
focus.
You
know,
maybe
shift
focus
once
you
know
all
the
optimizations
and
features
are
there.
But
that's
you
know,
that's
how
we
understand
the
space
so
based
on
on.
A
A
Okay-
and
I
think
you're,
probably
at
the
13
minute
mark
now,
so
I
just
want
to
just
similar
summarize.
You
know
what
we
learned.
So
what
we
learned
is
that
creating
a
wasm
interpreter
is
pretty
simple.
It's
it's
easy.
When
we
set
down
for
like
the
initial
like
hackathon,
for
for
getting
fizzy
done,
we
only
spent
less
than
a
week
together
and-
and
we
pretty
much
got
like
a
working
interpreter
out
of
it,
and
that
is
is
not
bad.
So
wasm
isn't
that
complex?
You
can
crack
it.