foreign
[Music]
okay yeah I'm Mike and I'm going to talk
to you about public private
composability and what that really means
is I'm going to talk about Aztecs
private smart contract architecture so
where we spec it all out and we're going
to be spending the next year maybe more
building a general private smart
contract platform for ethereum so what
were our aims when designing this
private smart contract platform
well firstly private States and what
private states are are values known to
only one person so a private state has
an owner and no one else in the world
knows the value of that state
okay and then private function execution
and this is really cool this is the
ability to execute a function without
revealing to anyone in the world which
function you've just executed so similar
to like the sexy protocol
and we want people to have a similar
experience to ethereum so we want people
to be able to deploy contracts
permissionlessly so just any time you
want to deploy a contract to the system
you can just deploy it
and again similarly to ethereum
experience we want composability so we
want someone to be able to call a
function and that function might make a
call to another function of another
contract and that function might make
another call to another function of a
different contract and so on
so that's really important
and we want a different kind of
composability as well we want
composability between
private and public functions which I'll
talk about more as we get into it
um and all together we just want
intuitive transaction semantics so we
want we don't want a developer to have
to think about the underlying
cryptography or any of that we just want
them to have as close to a Smart
contract experience that they have with
ethereum
okay so I'll take a step back what
fundamentally is a smart contract well
at its core it's just a collection of
State variables and a collection of
functions which may edit those State
variables
and here we can see a naughty example of
an erc20 contract balances is a state
variable and there's a function called
transfer which has rules which allow
people to edit the balances State and
there are two to the 160 such balances
States in this example
but what would an Aztec smart contract
look like
well people will still be able to write
functions
and states in for layer one so for
ethereum
they'll also similarly to all the other
Roll-Ups in existence the ZK Roll-Ups
and the optimistic Roll-Ups they'll be
able to deploy functions and have
persistent State on a layer two just to
save on costs
but the key differentiator with Aztec
contracts is there will also be private
functions and private States and
crucially you can see here these will be
on a user's device rather than executed
by ethereum node or roll-up sequencer
okay so what do I mean by private State
let's look into it a bit more get
everyone up to speed on some background
so a public State it's just a value in a
Merkel tree it's the same in ethereum
it'll be the same on our Layer Two
what's a private State well it's just a
commitment to a value in a tree and it
has an owner so here we can see an
example of a commitment it's got an
owner public key it's got some value
that you want to hide and store
persistently in our layer 2 storage
and it's got a salt which is something
random to give the commitment hiding
properties and maybe some other stuff
depending on the application that
someone deploys
public States will follow an account
model just like States and ethereum
smart contracts and with the account
model a state lives at one position in a
Merkel tree one leaf and we'll occupy
that leaf forever so if someone ever
wants to edit that state the person
executing the contract will have to go
to that exact Leaf position modify the
value
but that's no good with private States
because if you have to tell the whole
world I'm editing this particular Leaf
of this tree please update your node
accordingly you've revealed which state
is being edited so that doesn't work
which is why we adopt a utxo model and
in a utxo model once you add one of
these commitments one of these hashes of
a private value to the tree it never
changes if you ever want to edit that
state similar to the zcash model you
have to nullify that state which allows
you to change it or prevent it from
being used again without revealing and
you have to add a new commitment to the
right hand side of the tree so you're
always appending new values
so if someone comes along and they want
to edit your state
they will create a new commitment
representing maybe the add end that they
want to add to the state or something
like that and just to continue with the
background and
carry on with this zcash like protocol
description or indeed our current Aztec
connect protocol description uh let's
say someone inputs a commitment into
their circuit and they want to modify
the value contained within that
commitment they pass it into the circuit
the first thing they would do is prove
that this commitment does indeed exist
somewhere in the Merkel tree of notes
and in Aztec connect the miracle tree is
2 to the 32
with this private smart contract
platform it might be quite quite a lot
bigger because apps will probably create
a lot more commitments
okay the next thing you do is you open
the commitment
and you would hash the values to prove
that you indeed know the pre-image of
the commitment
and Alice in this example is the owner
of this state and so for her to prove
that she is indeed allowed to modify the
state
she has to prove knowledge of her secret
key and she can do that by just hashing
it however or following however the
secret key has arrived and then she
produces another fire in the previous
talk was quite helpful because it
explained nullifies so I don't have to
um
and then
they prove it doesn't yet exist in the
nullifier tree and the nullify tree at
the moment is a sparse uh Merkle tree it
allows you to prove non-membership but
we're actually going to update this to a
linked list tree which allows you to
prove much more efficiently that
something doesn't exist in the tree and
suppose Alice wants to perform some
simple operation on a state if you the
circuit she'll add five to it
and you can see we've incremented the
value that Alice is hiding we've changed
the salt to re-randomize the commitment
and she adds it into the tree
so this is quite a general way of just
modifying state within a public protocol
and crucially this step has to happen on
a user's device or at least in the most
basic systems this has to happen on the
user's device you can do some delegating
schemes but we won't talk about that
here
and so this gives our rollup something
different from other Roll-Ups there is a
layer where if someone wants to modify a
private State they have to do it on
their own device before then passing it
to some sequencer who will deal with all
the public State changes
and indeed because it has to happen on a
user's device possibly in the browser we
need extremely efficient proving systems
which you know we've been working on and
we're continuing to improve
so on an L2 functions are slightly
different from a solidity function
they're actually ZK snark circuits so
similar to other ZK Roll-Ups that you
might have read about except our role it
will need to be actual ZK so provide
hiding properties so if someone begins
with a circuit suppose they write a
circuit in some circuit language like
Noir
they write the rules of their function
you know it might include State changes
computations stuff like that
and using something like Noir they can
take that circuit and compute a proven
key in a verification key
and a user will come along and they want
to execute this function or rather prove
that they have executed the function
correctly
and that function will take some secret
inputs and some public inputs
and they'll pass it into Noir a big
black box and it will generate a proof
out will come the proof
and you can send the proof and the
public inputs to some verifier who
already has the verification key and
they can verify that you did indeed
execute the function correctly
for the given set of public inputs
one thing I want to point out in this
slide and that we'll need going forward
is that the verification key can be used
as a unique identifier for the circuit
because it was derived from the circuit
and the hash of the verification key is
like a unique single number that can
completely represent the circuit
and yeah this this can all be handled by
Noir
so if a verification key can represent a
circuit and if a smart contract is a
collection of functions
then we can create
uh well we can represent our set of
functions as just a set of verification
keys
and if we want to prove one of our
objectives that we have executed a
function without revealing which
function we have actually executed we
can just localize all our verification
Keys into a big tree and we can add our
contract or our set of functions to a
giant contract tree which contains all
functions that have ever been deployed
to this layer 2 smart contract platform
and in doing so
if this computation a miracle membership
check is done within a circuit you can
hide which function someone has executed
uh so this actually already came up with
a system which was really good a few
years ago it's a good paper if you
haven't read it uh for hiding which
function has been executed and this hash
here represents a commitment that
someone might add to a tree that we
talked about earlier
and within the commitment
they had a nice idea that you would put
in a birth predicate I.E details of the
function which created this commitment
and a death predicate a function which
the only function which may nullify this
commitment
but if people are familiar with solidity
smart contract development it's not
quite good enough to just have one
function a modify a state you might want
multiple functions to be able to modify
a state which is why on the previous
slide we've kind of collected all
possible functions of the smart contract
and added them to a contract tree and so
instead what we do in our smart contract
spec is we include a contract address
and that represents just the set of all
functions which may edit this particular
state
and again this is how zexe proposed to
hide the function being called so that
no one knows really what's happening in
the system you know all observers see is
that some function got executed
According to some set of rules for some
smart contract you take the private
circuit and generate a proof
and if we stop there the world would see
which function got executed so we passed
the proof into this kernel circuit
and the kernel circuit verifies the
earlier proof and kind of masks from the
world which function got executed which
is really cool and we take this and we
take it a step further which I'll talk
about in a second
I'll talk about it here
one of the things we said one of our
aims is the ability for functions to
make calls to other functions and so on
and so on and so on and so on
so how are we going to do that well
first why would we want to do that
here's a really simple reason if you
consider a decentralized Exchange
just on layer one at the moment if Alice
wants to swap tokens A and B she must
first call The Exchange contract and
then the exchange contract has to call
the erc20 contract for token a
and then she and then the exchange
contract has to call the ESC 20 contract
for token B so the most basic kind of
applications on ethereum require nested
function calls and we want to mimic that
with our private programming uh smart
contract language
what does a function call look like well
in ethereum it's a contract address some
identifier for where people can locate
the function and a set of arguments and
so similarly for Aztec it will be the
contract address the VK index as we saw
in the previous Slide the verification
Keys all get added to some contract tree
and a hash of the public inputs to the
Circuit which represents a function so
let's work through an example and you
don't need to read the code for this or
you need to really look at is the colors
so we've got to imagine someone calls
the red function over there function one
and the red function is making call to
an orange function in a different
contract and in turn that orange
function is calling a blue function in a
different contract it's returning some
values and then it's calling a green
function in this green function is a
public function so what I'm going to try
and demonstrate is how functions can
core functions of the smart contracts
and can also you can have functions from
private world to the public World well
what we first have to do
is each of those individual functions is
an individual circuit
and so you would have to generate six
distinct proofs one for each function
that you want to prove you have executed
correctly
but then the question is how do we prove
that they relate to each other in a way
that the code wants us them to relate so
how do we prove that they were executed
in order and the parameters that were
sent to functions and the return values
all intertwined correctly
well we we use call Stacks
so say we want to execute function one
first
well the public inputs to every single
function on our smart contract platform
will have to adhere to a very rigid
static Avi and one of the fields in that
ABI will be
call Stacks
so because function one makes a call to
the orange and yellow functions this
circuit will expose through its private
inputs
the call arguments and the function
signatures of the orange and the yellow
functions
and similarly the orange function is
making a call to the green function so
oh and the blue function so it will also
expose calls to the blue function of the
green function in its public inputs and
notice the green function is labeled as
public
and so because public functions get
executed by the sequencer and private
functions get executed by the user they
have to be separated in this way and on
we go the green function is making a
call to the purple function so we add
that to the call stack and here's the
really meaty cool bit and that's kind of
extending the the sexy example we saw
before where if you pass a function into
a kernel circuit it hides which function
function has been executed we add some
extra logic to our kernel circuit
to allow these call Stacks to be
interpreted and to check that the
parameters being passed between all
these functions make sense and are
according to the rules of the smart
contract that somebody wrote or smart
contracts floral that some people wrote
so we begin with Function One
we pass it into the private kernel
circuit
and the private kernel circuit will read
the public inputs of function one and
push onto its own call stack the two
items that function one makes a call to
um and then we will carry on with our
recursion uh the private kernel circuit
will spit out of proof and we will pop
the next call from the call stack and
we'll pass it in to another iteration of
the private kernel circuit so each of
these arrows is a proof and within the
private kernel circuit two proofs are
being verified each time
and so we can see the cool stackers
shrunk a bit and then we pop call number
two uh the orange call off it
and pass that into the private kernel
circuit and we do recurse until the call
Stacks are empty and then we know we're
done except the orange function is
making calls to another two so we'll
just keep going until okay finally the
private call stack is empty and therein
ends the work that needs to happen on a
user's device
so because the user only executes
private functions public functions are
executed by the roller provider
this proof here will be sent to the
roller provider what will the parole a
provider see well they'll just see that
somebody executed some function of some
smart contract and changed some kind of
States but the role provider will have
no idea which
um which is really really cool what they
will see
if the private function is making a call
to a public function they will be able
to see the public functions which need
to be called there's no way around that
so seeing the call stack as it is the
role a provider will take this function
and execute it
and pass it into a public kernel circuit
which has instead of hiding logic it
just executes States out in the open
similar to I guess other ZK roll-ups
and this function's making a call and
we're almost done we pass that into the
kernel circuit and hooray the call
Stacks are empty we finished executing
our function trace or our stack trace
and this can then be sent to the roll-up
circuit this entire thing represents a
single user transaction on our smart
contract platform and it can get rolled
up with all the other transactions
uh you don't need to read this all this
is saying is that the in order for the
kernel circuit
yeah in order for the kernel circuit to
be able to operate on any kind of
function we need one giant static
interface which it accommodates as many
possible function permutations as
possible
and that's what these interfaces are
there's one for private circuits and you
can see
there's a lot of arrays to allow for
various sizes and various permutations
of stuff that an app might wish to do or
a function of an app might wish to do
and we've got one for public circuits
similarly the private inputs and public
inputs to the kernel circuit there's
loads of them and there's a lot
happening there is so much computation
happening in these kernel circuits that
we've been working on a better proof
system more efficient proof system for
ZK snarks and it's actually similar to
hyperplunk which espresso systems have
been working on
um it's really cool idea and I guess
there'll be more on that at some point
in the future
so we have this transaction and I
mentioned when we get to this stage it
gets sent to the roll-up what does the
roll-up topology look like well first I
want to point out that that example
transaction was doing some private
computation for the user and some public
computation
but it doesn't need to be that way it
can just be this transaction is just
public computation
um similar to other ZK Roll-Ups or it
can be completely private computation
you can think Z cash transactions are
completely private so you could deploy
an app which does zcash like
transactions on this smart contract
platform and
I won't go into it today but there's
also the ability to deploy contracts and
you can even have similar to ethereum
uh functions deploying contracts for you
from a smart contract Okay so we've got
these transactions and they get sent to
the sequencer or roll-up provider
and this sequencer is going to compress
compress compress compress until they're
we're left with one proof
and the way you do that is by verifying
proofs within circuits so this base
roll-up circuit verifies two proofs and
this one verifies two proofs and then we
go to the next level
and we verify two more proofs
and then we end up with one proof
and because the proof system we use here
ends up being quite expensive to verify
and ethereum we'll squish it down to a
cheaper proof like plonkore gross16 and
then send it to the smart contract
right
and then within the smart contract this
proof will be verified and the state
trees of all the various trees we're
managing will be will be updated or
rather the roots of the trees will be
updated okay and I think this is the
final slide so
what I want to point out here is that
there's always this Arrow of time with
these transactions so you begin with a
private function executions or proving
you've executed private functions always
on the user's device
and once you've done that step then you
can go
send your transaction or your call
Stacks to the roll-up provider who will
execute their stuff and we'll ignore the
contract deployment step
and then it gets sent to the roll-up
contract and from there similar to Aztec
connect if you've looked into it you can
then make calls to any smart contract in
ethereum and interact with any defy
contract that already exists but suppose
your private function wants to make a
call to a public function or to a layer
one function and receive return values
while it can't receive return values
immediately because of this Arrow of
time and the order things need to happen
excuse me
so you will have to wait until the next
Roll-Up and so what we have and I don't
have time to go into it here is if a
private function is making a call to
another layer of this stack it will have
to record callback functions similar to
if you're working with JavaScript and
those record of those callback functions
will be added to a tree
and then in the next roll up
the user will have to prove that they
are executing the correct set of success
or failure callback function
in order to carry on with the execution
of their function so there's a lot of
complexity there
um
we've written a lot of documentation
which I think we're going to publish
which kind of explains all of this
complexity
um but yeah that's everything I wanted
to talk about today uh oh and I guess I
do have time to just briefly say well
the kernel circuit does it does tons
um and my throat's hurting so much that
um I'm not going to through go through
this but uh feel free to take a picture
and uh ask me questions afterwards
uh yeah thanks very much
we still have time for one question
maybe if someone wants to do a question
we have our volunteers with the mics
there you go here to the left
and maybe one there Depending on time
um one thing that you didn't touch it on
the presentation was about the
participants so you mentioned in the
beginning that you might have previous
state with participants
um so for example Goku Autumn with the
Sarah and best with desire which I'm
sure you are aware there are platforms
that allow you to have public and
private State contracts
they have different ways to tackle it so
peso does like groups you define your
group and that group will share a
private State and Goku Adam which is a
follicle of get with modification for
private State allow you to like select
for each transaction which participants
will see those changes and that means
that you can have the versions on the
state so like you might have a
transaction that you change one smart
contract and you change and you apply
that state change for two participants
but in the next transaction you change
the same value and only one but this
move will see it not the other how do
you solve that in your platform
uh I didn't fully follow the long
question
um maybe we can chat afterwards sorry
about that
yeah you can chat outside that's the
great place to do networking and to get
to know more and we have one more
question there please send to that mic
hello
um just one quick question uh is is this
private call for contracts already
available in NASDAQ or it's going to be
in the next release
uh so we'll be releasing the specs but
we we haven't built this
um we're kind of we've begun building it
um and but it's we're probably maybe a
year away from testnet um so yeah it's a
it's a big beast big round of applause
once again for Mike Connor Thank you