►
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/private-value-transfer-in-10-lines/
Demonstration of how drawing from a standard cryptographic library can reduce zero knowledge circuit implementations to simple programs of as few as 3 lines.
The Join split circuit is a popular circuit that originated from Zcash and is being used in Aztec. Using the Aztec Noir standard library, we reconstruct the join split in 10 lines hiding all of the circuit complexities involved.
Speaker(s): Maxim Vezenov
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: zero knowledge,languages,scaling
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
And
I'm
a
software
engineer,
slash
language
designer
here
at
Aztec,
Network
and
I'm,
going
to
be
introducing
you
to
Noir
today,
Noir
is
our
rust-based
domain-specific
language
for
writing.
Zero
knowledge
circuits
I'm,
going
to
walk
you
through
a
basic
circuit
and
then
also
show
you
how
to
go
about
proving
and
verifying
that
circuit
in
typescript.
A
So
first
I
want
to
talk
about
what
actually
makes
Noir
unique
Noir
aims
to
be
more
flexible
in
its
design
than
other
domain-specific
languages
that
currently
exist
out
there,
and
we
do
this
by
rather
than
compiling
to
a
specific
MP,
complete
language,
we're
compiling
down
to
an
intermediate
representation.
We
call
this
intermediate
representation,
the
abstract
circuit
intermediate
representation
or
the
Acer
as
I'm
going
to
refer
to
it.
Throughout
this
talk,
this
IR
can
then
be
compiled
down
to
a
rank,
one
constraint
system
or
plonkish
languages,
whichever
you
so
choose.
A
This
is
analogous
to
the
lovm
IR,
but
rather
than
converting
down
the
IR
to
a
specific
instruction
set
architecture,
we're
compiling
down
to
the
constraint
system
of
a
given,
ZK
proof
construction.
This
actually
enables
us
to
essentially
decouple
the
back-end
proof
system
and
the
language
we
currently
have
one
fully
integrated
back-end
system
and
that's
Aztecs
brettenberg
library,
and
we
also
have
plans
for
Integrations
with
The
Arc
Works
proving
systems
such
as
Marlin
and
growth
16.
A
But
anyone
if
you
can
compile
it
down
to
whatever
you'd
like
this
to
our
knowledge,
is
the
only
DSL
that
currently
has
fully
integrated
proving
system
optimizations.
So,
rather
than
just
having
an
interface
for
language
system
optimizations,
we
actually
have
it
on
the
proving
system
as
well
but
like.
Where
do
we
actually
get
from
this?
A
So
we
now
different
use
cases
require
different
kinds
of
systems,
and
now
we
actually
have
a
language
that
separates
the
middle
end,
a
front
end
middle
end
and
back
end
of
a
language
and
developers
can
then
Converge
on
a
common
architecture
standard.
The
fact
that
Noir
has
the
ability
to
support
proving
system.
Optimizations
enables
us
to
have
the
addition
of
optimized
Black
Box
functions,
a
few
that
we
have
are
listed
right
there.
But
if
a
back-end
system
has
integrated
that
specific
Black
Box
function,
the
front
end
can
then
access
it.
A
The
ultimate
goal
here
is
to
lower
the
barrier
to
Circuit
development
by
incorporating
cryptographic
safety
into
the
language
itself,
while
maintaining
performance,
so
I'm
mainly
going
to
be
talking
about
how
to
prove
and
verify
in
typescript.
This
very
high
level
compilation
overview
also
shows
our
package
manager
nargo.
That
I
specifically
want
to
note
that
allows
for
approving
and
verifying
circuits.
This
is
very
similar
to
Cargo,
so
you
can
build
your
circuits
using
this,
but
because
to
actually
prove
you
have
to
require
requires
a
proof
system.
A
How
that
may
be
done
if
you're,
already
kind
of
familiar
with
it,
you
may
have
to
Do's
from
the
inputs
that
the
circuit
essentially
boils
down
to
a
Merkel
membership
proof
similar
to
how
noir's
rust
based
the
syntax
is
rust-like
as
well.
But
the
main
thing
to
note
here
is
the
usage
of
the
pub
keyword.
All
inputs
to
the
Noir
circuit
are
going
to
be
private
by
default,
and
that
keyword
allows
you
to
then
say:
this
also
has
to
be
supplied
to
the
verifier
as
well.
A
Currently,
anything
outputted
from
the
function
must
also
be
public
and
to
take
note
of
our
native
data
type,
that's
called
the
field.
This
is
in
the
Aztec.
Brettenberg
back
end
a
field
on
the
BN
254
curve,
but
we
also
support
smaller
data
types
such
as
u32
u8.
You
can
even
have
u3,
but
these
are
less
efficient
as
they
require
range
constraints
and
but
that's
all
to
the
needs
of
the
circuit
developer.
A
If
you
want
to
constrain
using
our
data
types
rather
than
directly
in
the
circuit
yourself
now,
we
can
actually
get
into
the
logic
of
the
circuit
and
we're
going
to
start
off
by
using
two
of
our
standard.
Library
functions,
the
schnor
fixed
base,
scalar
multiplication
method,
so
we
can
construct
a
private
public
key
from
the
private
key
that
was
supplied
to
the
circuit
and
then
also
a
Pederson
hash
function
which
is
going
to
take
in
a
list
of
field
elements
and
return.
Turn
a
point
on
the
bn254
Curve.
A
We
first
you
we
use
the
random
input
secret.
That
was
shown
in
the
previous
slide
to
keep
our
note,
commitment,
private
and
not
associated
with
any
one
account.
Once
again.
This
is
using
the
Aztec
brettenberg
back
end,
but
if
a
back
end
supports
these
functions,
then
the
front
end
can
access
it,
and
now
we
actually
have
the
the
meat
of
the
circuit,
where
we're
first
going
to
generate
a
nullifier,
and
this
nullifier
has
to
be
unique
and
this
is
used
to
prevent
double
spends
and
the
circuit.
A
The
contract
that
integrates
the
circuit
is
going
to
have
to
make
sure
make
sure
of
that
where
we
provide
the
no
commitment
that
we
just
calculated
in
the
previous
in
the
previous
Slide,
the
index
of
the
snow
commitment
in
the
Merkle
tree
and
then
the
private
key
to
act
as
that
identity,
differentiator
and
then
finally,
we
have
a
check.
Membership
function,
that's
going
to
take
in
the
hash
path,
the
index
that
note
commitment
and
a
note
root.
A
It's
going
to
calculate
a
note
root
using
the
hash
path
and
commitment
provided
and
if
it
matches
the
the
note
route
there
that
we
provided
from
the
circuit,
which
is
public.
We
then
know,
okay,
that
this,
that
those
no
commitment
that
was
calculated
within
the
circuit
is
actually
the
the
person
proving
it
does
possess,
that
no
commitment
and
finally,
we
return
our
nullifier
and
our
recipient.
This
is
actually
constraining
these
two
values
with
the
outputs.
A
It's
a
little
syntactic
sugar
that
we
have
for
our
return
values
you
could
instead,
for
example,
not
have
the
nullifier
be
returned
as
public
output,
you
could
instill
Supply
it
as
public
input
and
you
would
have
to
then
write
constrain
like
nullify
or
hash
equals
nullify
or
index
0
there.
But
this
is
happening
implicitly
when
we
return
it
from
the
circuit
right
there.
A
As
this
circuit
is
the
title
of
this,
the
presentation
is,
it's
Noir
private
transfer
in
10
lines,
so
we
don't
really
show
a
lot
of
what
the
Noir
syntax
looks
like
so
I
wanted
to
quickly
highlight
what
else
also
exists
in
Noir.
We
do
have
compound
data
types
such
as
arrays,
tuples
and
structs,
as
you
can
see
right
there
and
you
can,
then
we
also
have
sub
modules,
so
you
can
easily
separate
your
functions
as
you
as
you
see
fit.
A
Also,
just
recently
added
Global
consts,
which
you
can
also
import
as
you
would
in
any
other
programming
language
such
as
rust
or
control
flow
we
have
for
loops
and
if
statements
and
we're
looking
to
add
recursion
soon
as
well.
We
also
have
recently
added
to
generics
which
is
highlighted
right
here,
which
is
a
great
benefit
to
the
developer
experience.
Just
to
recap:
we
try
and
be
high
level
as
we
want
to
make
this.
A
So
because
Noir
is
back
in
agnostic,
though
we
have
a
separate
wrapper
around
the
Aztec
ruttenberg
back
end
and
that's
any
other
backend
that's
gets
integrated
is
going
to
have
to
do
the
same
thing
as
well,
because
this
backend
has
been
made
to
match
the
Acer
interface
in
order
to
set
up
the
prover
and
verifier.
We
simply
pass
in
the
Acer
and,
as
you
can
see,
right
there
and
then
that
ABI
that
we
specified
earlier
to
construct
our
proof
and
then
we
just
pass
it
along
to
our
verifier.
A
One
thing
you
might
note,
though,
is
that
you
don't
see
any
public
inputs
being
passed
to
the
verifier,
even
though
we
have
we
had
that
in
our
circuit.
Currently,
the
proof
that
gets
spit
out
by
brettenberg
is
pre-pending,
those
as
32
byte,
hex
string
inputs,
but
we
plan
to
separate
that,
as
developers
might
like
to
have
those
inputs
separated
for
their
own
development
purposes.
But
that's
just
to
take
note
of
why
you
don't
see
any
public
inputs
being
passed
to
the
verifier
there.
A
So
we
can
this,
it's
cool
that
we
can
actually
verify
in
typescript,
but
we
want
to
be
able
to
also
enable
this
in
smart
contracts
as
well,
so
Aztecs
brettenberg
backend
does
allow
you
to
compile
from
a
Noir
program
to
an
ethereum
contract.
Improving
systems
looking
to
integrate
Noir
are
going
to
have
to
provide
their
own
implementation
of
how
to
generate
a
solidity
verifier
or
if
you
choose
to
use
any
other
smart
contract
platform,
you're
going
to
have
to
provide
that
implementation
yourself
if
you're
integrating
a
back
end.
A
This
script
here
shows
you
how
to
generate
a
solidity
verifier
using
that
Aztec
brettenberg
back
end,
and
it's
important
to
take
note,
though,
if
you
change
your
circuit
and
don't
change
your
you,
don't
regenerate
your
solidity
verifier
with
the
script.
Your
circuit
is
ultimately
going
to
fail
as
you're
going
to
have
a
new,
Acer
and
you're
going
to
have
a
you're
going
to
need
to
regenerate
that
verifier
in
order
to
have
accurate
verification.
And
finally,
we
can
actually
have
our
ta-da
moment
and
verify
our
circuit
and
solidity.
A
So
using
your
favorite
deployment
method,
you
can
deploy
your
turbo
verifier
as
you
would
any
other
smart
contract,
and
then
you
can
take
that
proof
that
was
spit
out
from
brettenberg
in
the
exact
same
way
with
the
pre,
with
the
public
inputs.
Prepended
pass
it
to
the
verifier,
and
if
your
public
inputs
are
correct
and
your
specified
your
circuit
correctly,
it
should
it
should
ultimately
return.
A
True
in
the
case
of
our
private
transfer,
we're
going
to
be
checking
is
that
nullifier
hash
been
used
before
is
the
root
the
correct
route
and
upon
having
a
verified
proof.
We
can
actually
then
perform
a
private
with
a
withdrawal
and
that
that
note
that
will
be
entirely
private.
So
that's
that's
it
there
and
you
can
see
a
more
full
example
with
the
simple
Shield.
A
But
ultimately,
here
the
benefit
is
that
we
can
enable
autonomous
execution
in
contracts
based
off
verification
of
Noir
circuits
and
I
want
to
also
discuss
some
of
the
future
work
that
we're
going
to
be
doing
in
Noir.
One
of
the
main
things
that
we
want
to
add
is
verify
proof.
This
will
actually
enable
us
to
have
recursive
snarks
inside
of
Noir
itself,
which
enables
many
more
use.
Cases
than
you
can
currently
have.
The
wrapper
itself
is
pretty
new
and
we
want
to
improve
this
development
signifi.
A
These
development
tooling,
submit
significantly
to
make
it
easier
for
anyone
looking
to
integrate
with
Noir.
We
also
want
to
integrate
it
with
Rebels
such
as
ZK
Rebel,
if
you're
familiar
with
that
online
IDE
Integrations
other
debugging
tools,
a
language,
server,
lots
of
development
tools
to
add,
and
in
the
medium
to
long
term,
we're
going
to
be
adding
Noir
contracts
and
Noir
contracts
are
going
to
be
the
next
stage
of
Aztec's
platform,
where
we'll
actually
have
public
and
private
state,
which
is
has
its
own
challenges,
which
you
can
attend.
A
B
C
A
Right
now,
that's
that's
the
next
iteration
of
Aztec's
platform
when
we
add
the
Noir
contracts.
This
is
a
purely
a
zkevm
DSL
right
now,
where
Aztec
can
generate
that
solidity,
verifier
and
you're
going
to
be
proving
circuits
on
a
evm
platform.
You
can.
You
can
gener
like
I
showed
in
that
example,
you
can
compile
your
circuit
in
typescript,
but
you
can
also
use
our
package
manager,
which
I
briefly
mentioned,
to
generate
that
intermediate
representation
that
intermediate
representation
can
be
used,
the
same
way
that
that
that
it
was
used
there.
A
You
just
have
to
read
it
you're
reading
it
in
from
file
using
our
same
our
wrapper
method.
So
you
don't
have
to
do
anything
extra
for
serialization.
That's
handled
that's
handled
by
our
wrapper
yeah
right
now,
but
you
can
also
you
know
ver.
You
can
verify
without
the
evm
as
well.
You
can
just
verify
using
typescript
and
you
don't
have
to
necessarily
have
a
verification
using
a
solidity
contract
that
depends
on
your
needs,
but
a
lot
of
people
like
to
have
that
autonomous
execution.
D
Hey
hi,
it
was
amazing
I
wanted
to
ask
let's
say
as
a
developer:
I
have
the
choice
between
sarcom
and
Noir.
Now,
both
as
an
end
user
feature
provide
proof
systems
with
Planck
and
growth
16.,
it's
exactly
the
same
value
proposition.
So
why
would
you
say
that
we
should
experiment
with
Noir
instead
of
just
going
with
sarcom?
Sorry
to
put
you
in.
A
A
position,
no,
no,
it's
okay,
they
do
serve
slightly
different
use
cases.
Circum
is
definitely
a
much
more
low
level
you're
going
to
have
to
be
specifying
a
lot
of
the
constraints
individually,
while
in
the
language
we
specify
those
constraints
for
you
a
basic
example
there.
When
I
talked
about.
If
statements,
you
can
constrain
your
your
on.
E
F
A
Right
now,
it's
essentially
you're
gonna
have
to
write
your
tests
in
typescript.
We
hope
to
add
debugging
tools.
That's
one
of
the
main
things
that
need
to
be
added
to
make
the
tooling
more
effective,
yeah
you're
gonna
have
to
essentially
test
it
either
in
typescript.
You
can
test
it
in
Rust
too,
and
use
the
nargo
package
manager.
That's
up
to
you,
but
I
only
highlighted
typescript
here,
because
most
contract
developers
are
probably
going
to
lean
towards
that.
G
A
That's
just
our
I
guess
native
kind
of
dependencies
and
that's
how
we
do
it
like
we,
you
can
also
import
from
from
GitHub,
or
you
can
have
modules,
as
you
would
normally
in
Rust
within
your
where
it
would
be
like
mod
something
and
you
can
also
import
packages
from
within
a
crate
as
well,
where
it
would
be
like
create
this,
and
that
would
be
the
import.
That's
just
how
we
import
our
standard.
Library
yeah
like
rust,
crates
our
our
nargo
kind
of
it.
A
H
A
So
that's
actually
probably
you'd
want
to
go
to
Mike's
talk
to
see
more,
it's
very
interesting
how
the
infrastructure
works.
Essentially,
though,
each
function
in
the
contract
is
going
to
be
a
circuit,
but
how
that
actually
gets
integrated
into
the
system
you're
going
to
have
to
attend.
Mike's
talk
to
get
more
info
on
that.
It's
very
interesting.
We.
B
I
A
C
B
C
A
We're
going
to
be
using
Noir
for
circuits,
but
you
don't
necessarily
have
to
Target
the
evm
there.
We
just
Aztecs
backhand
does
allow
you
to
compile
an
evm
verifier
from
a
Noir
circuit
and
that
functionality
will
still
exist,
but
no
R
contracts
and
Aztecs
platform
are
not
going
to
be
ZK.
Vm
they're,
going
to
they're
going
to
be
Noir.
C
A
C
I
Yeah
so
currently
Noir
is
just
a
language
for
creating
circuits
and
you
can
create
a
solidity
verifier
that
allows
you
to
verify
those
proofs
on
the
on
the
ethereum.
Once
we
extend
extend
the
syntax
to
have
a
contract
terminology,
Aztec
free
will
be
built
and
it
will
have
its
own
VM
and
you
can
compile
those
contracts
to
the
Aztec
free
VM,
not
the
ZK,
evm
hi.
E
A
Well,
there
hasn't
been
many,
mostly
the
examples
you
can
find
on
my
GitHub
or
inside
the
Noir
repo
testing,
the
language,
but
there's
anything
you
can
think
of
where
you
would
need
to
verify
a
proof
and
do
something
based
off
that
ZK
proof.
You
couldn't
theoretically
do
a
Noir,
so
that
can
be
quite
a
lot
of
things.
Synonymous
proof
of
membership.
Private
games
on
on
public
blockchains,
lots
of
different
things,
all.