Clarifying zkVMs and Precompiles: Insights from Justin Thaler

Understanding
Precompiles
in
Ethereum

Justin
Thaler,
a
Research
Partner
at
a16z
and
Associate
Professor
at
Georgetown
University,
has
recently
provided
an
in-depth
discussion
on
precompiles
in
the
context
of
zero-knowledge
virtual
machines
(zkVMs).
His
insights
aim
to
clarify
misconceptions
and
explore
the
intricacies
of
benchmarking
zkVMs,
as
detailed
in
a
recent
article
by

a16z
crypto.

In
the
Ethereum
Virtual
Machine
(EVM),
precompiles
are
operations
natively
supported
to
enhance
efficiency
and
reduce
gas
costs.
These
operations,
such
as
the
SHA-2
hash
function,
avoid
the
substantial
overheads
of
executing
through
EVM
opcodes.
The
distinction
between
precompiles
and
primitive
instructions
(opcodes)
is
mainly
semantic.
Both
are
frequently
executed
operations,
with
precompiles
handling
more
complex
tasks
like
cryptographic
primitives.

Precompiles
in
zkVM
Design

Thaler
explains
that
in
zkVM
design,
precompiles
refer
to
special-purpose
SNARKs
(Succinct
Non-interactive
Arguments
of
Knowledge)
targeted
at
specific
functionalities,
including
cryptographic
hashing
or
elliptic
curve
operations.
Historically,
zkVMs
implemented
primitive
instructions
via
hand-optimized
constraint
systems,
just
like
precompiles,
making
the
difference
between
these
terms
purely
semantic.

However,
Jolt,
a
zkVM,
implements
primitive
instructions
using
lookups
instead
of
traditional
constraints.
Thaler
notes
that
while
using
lookups
can
optimize
certain
processes,
there
are
no
significant
issues
with
employing
traditional
constraints
for
some
instructions.

Benchmarking
zkVMs

Thaler
stresses
the
importance
of
fair
benchmarking
in
evaluating
zkVMs.
He
argues
that
benchmarking
various
RISC-V
zkVMs
without
precompiles
ensures
a
level
playing
field.
Adding
precompiles
to
a
zkVM
alters
its
instruction
set,
thereby
eroding
the
zkVM’s
value
proposition
by
increasing
the
complexity
and
potential
for
bugs.

Thaler
also
addresses
concerns
about
the
functional
differences
between
EVM
precompiles
for
zkEVMs
and
zkVMs.
He
notes
that
zkEVMs
must
support
EVM
precompiles
to
maintain
parity
with
the
EVM,
whereas
zkVMs
like
Jolt
use
precompiles
to
expand
beyond
the
standard
RISC-V
instruction
set.

Broader
Benchmarking
Considerations

Thaler’s
broader
thoughts
on
benchmarking
highlight
the
goal
of
understanding
the
intrinsic
performance
profiles
of
different
proof
systems.
He
acknowledges
the
challenges
posed
by
various
confounding
factors,
such
as
engineering
effort
and
the
inclusion
of
features
like
precompiles.

Thaler
anticipates
that
these
confounding
factors
will
diminish
over
time
as
tooling
for
building
SNARKs
matures,
reducing
the
engineering
effort
required
for
decent
performance.
He
suggests
that
convergence
on
a
standard
constraint
system
could
simplify
benchmarking,
making
it
easier
to
compare
different
SNARKs
based
on
simple
measures
like
constraint-system
size.

Ultimately,
Thaler
emphasizes
the
need
for
transparency
and
detailed
context
in
benchmarking
to
foster
understanding
and
informed
discussions
within
the
community.

Image
source:
Shutterstock

.
.
.

Tags