foreign
[Music]
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 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 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 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
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 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
you see that line on the top going all
the way over to the proof system as well
in order to compile nargo you need all
integrated so now I'm actually going to
take you through what a Noir circuit
looks like and and I'm going to use one
of the most common examples where ZK
proofs are used to enable private
transfers and rather than you know
simply showing you the entire circuit at
once I'm going to walk through kind of
each part of the circuit and this is to
highlight noir's unique features for and
also for those who may be unfamiliar
with how to write a private transfer
circuit 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 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 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 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 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 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 uh
is actually constraining these two
values with the outputs 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 as this circuit is
the title of this the presentation is
it's Noir uh 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 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 the
development experience easier but also
abstract away some of that cryptographic
safety that you might be familiar with
in other ZK circuit languages or where
you have to directly specify essentially
every constraint and that's the ultimate
goal of Noir to have safety and the a
greater development experience now I'm
actually going to kind of walk through
how you would use our wrapper to prove
and verify this circuit in typescript
and then ultimately in the browser so
that clients can you can prove on the
client side
we have a Noir JS package which has been
created to allow developer to you can
directly compile your circuit and
typescript as you see there but in this
in this uh package you can also read in
from the Acer from file that would be
generated by the nargo package manager
that's a choice of the developer but in
this example we just uh we just show you
how to compile it directly in typescript
so after we have an object representing
our Acer we then just have to specify
our ABI and the ABI is what the prover
is going to be providing to ultimately
construct our proof which has our
private and public inputs and that's
going to be used to generate the witness
and ultimately generate the proof 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 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 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 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 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 true
in the case of our private transfer
we're going to be checking is that
nullifier hash been used before is the
root uh 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
uh simple Shield 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
uh the wrapper itself is pretty new and
we want to improve this development
signifi 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 Mike Connors talk at 2 30 from
Aztec who's going to be discussing that
infrastructure and how we actually are
going to enable Smart contracts in Noir
if you have any questions uh please
shoot and thank you
[Applause]
thank you so much Maxim so we have two
volunteers
there you go this is our balloon two
coming
hey good afternoon uh very impressive
um right now how does the how does your
tooling work for this uh you have to
compile the Noir contract and then
deploy it into into the layer two into
the layer two or the layer two test net
or something not 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 uh 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 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
we have time for more questions
one over there in the left side then we
have two more here
hey hi uh it was amazing uh 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 uh we should
experiment with Noir instead of just
going with sarcom sorry to put you in a
position no no it's okay uh 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 if statements you don't have to
use a multiplexer and things like that
that make it just easier for the
developer and kind of lower that barrier
from someone who's maybe moving from
who's never coded ZK circuits before and
you can also constrain on data types
outside of just our native type because
they everything that we have ultimately
translates to that and we do have
uh I know you can currently do Planck
but I believe right now Noir is the only
language that actually has truly fully
integrated Black Box functionality where
the proving system is specifying the
custom Gates and making those functions
faster
hi
um why base Noir off rust are there
certain properties of rust that make it
you know a better language for this well
we want to one of the main focuses of
noir's safety and Noah and rust that
same thing in Russ right and rust is
also just a nice language
uh thanks a lot for for the talk uh I
was wondering do you have some tools
where am I looking sorry I'm here oh hey
hello uh thanks for the for the talk uh
do you have some tools for uh testing
the logic of the circuits uh 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 uh 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
okay thanks we still have time for more
questions five minutes more there you go
on the right
thank you uh just a quick question on
the first uh like code sample you had uh
I could see the STD the STD package was
under a depth uh namespace and I was
wondering where that is
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 uh
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 uh and that would be the
import that's just how we import our
standard Library
yeah like rust crates uh our our nargo
kind of it it's not like a copy of cargo
but it kind of mocks that functionality
with crates and modules so you can have
you can import modules from within your
crate using use crate and then whatever
else you'd like
it's a very nice talk uh in the next
phase of of Aztec 3 uh can you talk
about the process process of converting
existing circuits to Noir what do you
mean existing circuits you mean
contracts like the uh so in Aztec 3
you're planning on converting existing
circuits to Noir I assume 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 have
someone from Team here as well if you
want to complement anything like to add
on top of the conversation hello yeah I
just want to ask so with Aztec free
we're not actually trying to be ZK evm
compatible right
it's a separate no right
yeah just making sure
cool there's one more over there this
side
oh yeah that was my question again
um that was he said he was he they made
a preamble to the question so that means
that Noir the since Nora is going to
Target to EVMS uh Arctic 3 is not going
to be using Noir for this for for its
inter for the circuits so 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 so yeah so that
means that you also have the your go you
right now have the target for Aztec or
you are going to have or you're going to
build it yet sorry can you say it again
the start the compilation Target right
now it's only ebm but you are planning
to to be able to migrate to to be able
to compile as well to Aztec in the
future yes yeah so currently Noir is
just a language for creating circuits
um and you can create a solidity
verifier that allows you to verify those
proofs uh on the on the ethereum once we
extend extend the syntax to have a
contract terminology uh 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 hi well
I am now in nor right now it's so new
for me and I would like to know whether
the main applications that they are
using now right now
the main applications using Noir right
now yeah uh well there hasn't been many
uh mostly the examples you can find on
my GitHub or inside the Noir repo
testing the language
um 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 uh
private games on on public blockchains
lots of different things all right big
round of applause to Maxim from Aztec
[Music]