Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Whiteboard session w @aztecnetwork
Recorded: March 25, 2025 Duration: 0:57:59Space Recording
Short Summary
Aztec is a privacy-first layer for Ethereum, introducing innovations like a staking-based sequencer selection protocol and unique public-private state management. Technical advancements include the use of a custom cryptography engine for client-side proof generation. A significant milestone was achieved with a successful end-to-end token transfer transaction on consumer devices, and efforts continue to enhance user experience through proof delegation.
Full Transcription
Hey everyone, welcome to another episode of the whiteboard session.
I'm born from near and with me today is Zach, co-founder of Aztec.
And Zach is well known for his pioneering work in the thickest space in the past several years.
Most notably work on Plunk.
So it's great to have him here.
And yeah, let's talk about how Aztec works.
Yeah, thanks for having me on.
How does ASTIC work?
So, but...
The YPOS is actually in this.
Okay, so ASTIC is a privacy for first layer to you for Ethereum.
So the idea is that you can use it to send into an encrypted blockchain transaction.
So the user, like, you don't see who the user is who's transacting, you don't know the small countries that they're calling,
and you don't know about the data that they're changing.
So, um...
I guess there's a few ways I could start to describe this. I could describe the overall network architecture to go to go with.
Yeah, I'm sorry stuff. Right, so just saying, you've got a
goland dude here who wants to, who wants to, uh, wants to, uh, wants to try and so they want to call,
let's say, you know, um, uh, Bob monster wants to, I cannot write.
Letters.
Oh, whatever.
Areas or a number person or less person.
Okay, it's just, so the idea is you want to send a transaction, right?
So what are some of the abstractus that we have?
So let's say the transaction you want to do is, you know, send.
Send like one east to Alice.
So first of all, this person's going to need to make a ZikaPRIF.
So what's going to happen is there's going to be an entity called, well, there is an
entity called the Pixie.
This is a sense for private execution environment.
So this is basically a component.
So if you think about a normal blockchain, you know, you have your blockchain node implementation.
So you'll have Gets, you'll have REST, which handles the whole like blockchain, state
sinking, transaction construction.
abstraction via RPC node. For Aztec, we split it into two. You have the parts of the node that handle private state and then you have the everything else part of the node.
And the reason we do that is because the private part really needs to run client side, whereas the public part, you could use like an inferior type abstraction, so it's a met to abstract it away.
The idea here is that from here, this person, this like this will basically, from here, it will say like, I want to generate, I want to like call contracts, like, you know, OX, A, F, whatever, E, dot oz, that.
Which will, you know, which is basically like, let's say it's an A, I can't remember what you're calling it, A-L-C or A-Z-T, let's see, ARC-20 contract.
So what this thing is going to do is this, because this thing has got my, this dude state.
stored locally the private state and cryptosate.
And so this will expanse,
it's provides an abstraction layer where,
You can generate proofs, sync with the sync state from the chain, in a way that is very application specific.
It's a bit like a wall, a bit like a firewall.
So that's the like the website or the DAP where this is running and it can't like abuse its prodigers to see what this person's state is in any other domain.
Other members contract.
And so what this is going to do is it's going to spit out a ZK, it's going to basically spit out a ZK proof.
You know, like a ZK. Pris, big, bong, bro.
Sorry, just for me to on the subway,
does this execution actually happen?
Like, is this like local and again?
This is all local in the moment.
Oh, it's all local.
Okay.
Yeah, okay.
This is local.
This is local.
It's called a local host.
So the idea is this will be basically like,
typically, you know, uses web browser.
So this whole thing is running in like in an eye frame.
The proofer, cryptographic proof is running in WASM.
And that last we dealt with. And the output of this is basically a proof which gets, um,
uh, um, uh, uh, which is affecting the, the transaction. Um, so then what this has happened is,
this goes into our p-to-peer. Mimple. Oh? They're bad. You know, like, this is where things get
a little bit more like a standard blockchain. Um, uh, and then you'll have a block builder,
like, uh, basically a, uh, what we call the sequences. Like, network. Network.
So we have a Sequencer selection protocol called Finet, which is functionally what it's a staking-based system where, you know, you stake for the right, you stake tokens for the right to be a sequencer.
The more likely you are to be selected, but it's not guaranteed.
And so the sequence serves, just called an S, they will, they're building a block.
They're going to select this out.
Yeah.
And basically a search-in-book transaction and then you can have a cruder network.
I'm abstracting a lot, by the way.
I'm not even, I'm not talking about the state model, I'm not talking about like how we do encrypted like invents or, you know, like the public-private state abstractions.
And so then the sequence is going to basically appsource proving.
So two things are going to happen.
And that?
It's called this the this.
This is their layer one.
So the sequence is going to, first of all, they're going to make a poster layer one going, yo, this is the block.
And then they're going to generate, then this is going to be a prover.
He generates a proof, which is basically a block proof.
And then this gets verified, and then basically it verifies.
I see.
Yeah.
And basically, L1 controls all the state routes.
And so, you know, in order for this clock to be valid, it's going to present, it's going to provide some, like, you know, input state routes, alpha state routes and a proof of the correctness of the state transition, so they verified no one. And
So that's the high level.
Oh, sorry, question here.
For the Sequencer Network, is there any consensus involved?
Or you're only to block production and delegate consensus to 201?
Yeah, so there's a small amount of consensus here.
So economic consensus is a bit inaccurate, but what we do is,
so we have this issue in our L2, which is not present in most L2,
the ones that are on privacy preserving, which is that this transaction here that
that Bob is spinning out, is non-trivial in terms of its size.
Because it's got a zero-nolge proof.
So right now that ZK proof is 100 kilobytes.
If we worked on it, we can get out of 8 kilobytes.
But that's a lot of data.
So normally what happens when a sequence service posting the block on chain,
they are posting all the information needed to prove the block,
so you don't get censorship attacks.
And we don't want to do that because we don't want to post
every single transaction proof on shame.
Do large.
However, when the proof is made by it, this proof basically swallows up the individuals he gave proofs.
Because once the proof is the only data to broadcast is the block proof and all of the state
diffs that have happened as a result of all these transactions.
So the naive thing to do is basically to have a synchronous model where blocks are only valid if they come with the proof.
But then the problem with that is the is getting a throughput because in a roll-up like this,
I guess for the audience, the amount of time required to prove a block scales with the log of its size,
which means that you big blocks, like big slow blocks means bigger throughput.
So we want big slow blocks.
But if you want big slow blocks, then we want pre-confirmations because we want this dude to
be able to send a transaction, get very fast finality so they know it's going to be in the next
block, and then they can build on top of that transaction.
And so what we need is pre-confirmations.
We need the sequence to be able to say, okay, I'm putting a transaction in my block,
but without posting the proof data on chain, which means we basically need a very
minute, like a miniature data variability network that can maintain
Data, basically can persist data for 10 minutes.
So it's a far ground for some of Celestia.
So we're just in 10 minutes.
That's nothing more than that.
So we use a little economic consensus model to do that, where you have a bunch of validators
that basically put up some tokens under the guarantee that certain proofs will be available.
I see.
Is that part of the sequence of network?
It's a different set of people doing that.
It's a, I can't remember how we did it.
I think it's a different set of people didn't know.
Okay, yeah, yeah.
Okay, okay.
Yeah, I see.
Um, yeah.
There's some interesting economic modeling too, because we don't want the costs to be too large.
Because it's like 10 minute finality, it's not very long.
But, uh, but also, uh, we want to, like, it's trying to do some modeling about,
we were working with blog science, basically like,
If you can do a, like, if you could sense the transactions on a 10 minute time frame, like practically what's the missile out of money, you could extract from that and then making sure that this the slashing costs are higher.
And then what happens when the blog proof haven't, hasn't arrived on that while? Like, do you just like?
Like, it would like, you would still keep sending blocks to the other ones, just like the proofs would arrive later.
Yeah, and the idea is really the, the block production times aren't particularly high.
So the idea is really, um,
The time lag is really, how about this?
Because you can generate the block proof over time as the block has been built.
Typically when a block is fully constructed, it will take much longer for the block proof to arrive.
But we just want to make sure that in that, I think it's like a one minute window now, basically.
You can have partial blocks with another one minute maker so that we can get down to like 10 seconds or
Initially we're talking 10 second finality obviously we want to go but further than that longer term
I see that's it just like thinking from like a more like broad chain perspective
Is there any risk of like reorgs when you don't have the
proves, like, or not, I guess proves, not your realm here.
Like, I think that's, like, sequence of producing blogging, there's, like, whatever
obvious they use, is there any risk of, like, forks and then, you know, reorbs and so on?
I mean, I think there's always small risks of folks and reorgs, but the, so the biggest risk
of a real right is if the block is being claimed as, like, it's being presented.
presented, but the data required to make the proof it doesn't exist.
Because the data, like the DA Council, basically not on their jobs or they're colludeable
but all that.
They're not in their mind or incompetent.
And then they all get slashed.
Now what gets deleted and you've got to remake a new one.
So I think because we're ELTI, because we use Ethereum's consensus, I might be wrong
about this.
I will need to check because I've not been delving into the architecture side lately.
But I think it's unlikely to get a real of more than one block with us with our system.
Okay. Okay.
Because, like, generally we're not, like, we're not really queuing up multiple blocks and improving them.
Generally, like, you can't...
I see, I see, I see.
You can't prove a block, like, you can't post and, you can't, like, settle a new block.
Into the previous song's name.
Okay, okay, okay, okay. I see, I see.
And then on the Prover Network side, how does, like,
Is there like, I assume there are multiple provers, right?
How do they choose, like, which one proves this block?
Or is there, is there like a competition or like market?
Yeah, we want to make a market for it.
So there's lots of startups that are spinning up, doing proven networks.
I mean, I think like, SP1, I believe that.
Well, not, SP1 is ZKVM, but they're doing a proven network.
There's quite a few others.
And so we basically want to just make a market mechanism, right,
where the sequence can negotiate with the premium networks to get the lowest price.
But ideally we want to abstract away as much of it as possible to, you know, actual
proven networks that are, they make it their job to do this.
And so how they work?
Is it like whoever submits the proof first gets the reward or something?
So it's slightly more complicated than that because there's not really one proof.
We use recursion.
It's more like 500 proof.
So let's say, imagine this block sizes at 1,024.
So you got 1,024 transactions, each one's the proof.
The way they're thinking about it is that you have a tree of roll-ups.
So you have a roll-up one, and then here, which will basically take, you know, TX1, TX2,
here I can split something out, you know, then you'll have like three and four.
And basically all of these little things are ZK circuits that are basically just aggregating two
transactors.
So that's all they're doing.
And then, you know, and then you have another circuit which aggregates two transactions.
There are another circuit that aggregates two transactions.
And using this approach, you can get maximum parallelism.
And so basically there's lots of proofs that need to be made and the sequencer coordinates
of basically what they're doing is it's just a pure market mechanism.
Where they're just saying, hey, how much I want to, how much would you give me?
It's, we were thinking originally of trying to support uncle proofs.
Basically the idea being if I'm a slow prover, right, I'm a makeup proof, but it's, I have a lot of the...
But ultimately, I think
Yeah, longer time we'll have to see how the shakes out because I do think the economics of proving are weighted towards a winner-tick-tick-tall scenario.
But what we don't want to end up in is a world where you just have one giant proof of LTTI.
Because then there's a single point of failure.
I think that's something with an open problem to solve.
I see.
I see.
Okay, maybe let's dive into how the public-private state...
Yeah, I do that.
I'm going to have to wipe this off, I'm afraid.
Yeah, how does public-private stake work?
Right. So what's actually happening in this proof?
What's going on here?
By the before, before that, I have a question, like, how does the, like, given this local
computation means that the user needs to have a state logo, right?
They need to, like, download the state locally to be out.
They need to know their private state.
Yes, they didn't know their private state.
Yeah.
Yeah.
And so there's the way, how do you do that?
Yeah.
There's a cradle space here because the, the, what we want to do is not what we do.
can't be done yet, which is, it's called OMA Oblivious Message Achievele.
Ah. So the idea is you could, in theory, use fully homomorphic encryption. So the idea is that
you have a third-party server that has the entire state tree, private state tree, of your network,
but it's all encrypted. And then the user sends a request for specific leafs, but then
what happens is that request is escuaged in an FHGC context, so effectively
The request is encrypted.
The server doesn't know which leaves zero.
They're extracting, but they can still run the competition.
That is a few years away there.
So the way we work, we do it, is through effectively side channels, and no tagging.
The idea is, we have a mechanism by which if I am going to send you some data,
I'm going to generate some, do some transactions, I send you money, give you data.
I can do a handshake with you, where we basically use Diffy Helmut,
sharing, and generator shared secret that I will use to encrypt your data,
the data I'm sending you.
And then if you, and what we, and all out of that,
we basically get sped out a list of little tags, tag IDs.
And when you're syncing into the network, you can basically,
like, listen for these tab IDs, which is a relatively light weight operation.
So instead of what we do or want to do, which is the naive thing, is you trial decrypt,
every piece of encrypted state on the chain.
That's not sustainable.
So using this tagging system, that works,
but if the handshake is occurring over a public channel,
then effectively what gets leaked is
people know that somebody wants to send something to you.
But of course, we can always do that handshake
going to a side channel that people can't see.
There's also other complications.
So for example, if I want to make a proof, if I want to do if it's action proof with my
private state, I need to construct Merkel proofs specifically like to prove that my encrypted
blob is in the state tree.
Right, right.
And naivia requires knowledge of the entire state tree, which you don't have if you're
running a local light line.
There are some ways of working around that, but I think in the short term, I
like the fastest solution is basically just you you there's a third party server yeah you request
the local paths you are linking information in that context so um there's some trust vector there
that um and so like ideally that entity that entity that entity doing that is like a VPN
like a VPN somebody which has this high trust officials but ultimately longer sound we want to
again use oblivious messaging with oblivious messaging shield to handle that um I see I see
So let's, so I go through how state works?
Yeah. Well, before I give a few states, what do I go through?
The core semantics in the photo book is the two intrinsic of heavy-linked.
So I have a contract. My contracts can contain public functions and private functions.
So these are, and basically what's a each function
gets compiled down into a ZK SNOC circuit and a verification key,
and the contract is defined as the son of its verification keys for the defundions.
So you basically create a little tree of verification keys, you hash them.
Oh, that's just a contract address. I see.
And these things can modify private stakes.
Uh, well, yeah, I got on that.
Freight state, uh, and call,
the functions. And these things can modify
uh, other states.
They can also, if you want,
You can...
Oh yeah, these things can also...
They can read historical public state.
Oh, okay.
But...
There's some native operation?
I think so.
I can't wrong that.
And there's a thing that can read...
This can...
If you want to, I mean, you can, in theory, modify private privacy and public function, but it's not Friday at that point.
But you see, like, actually you really leak secrets.
So the idea here is basically when you make your...
Okay, so let's say I'm on Bob, I want to make a proof of like a transaction.
That is?
I am not going to have the up-to-date stakes of the network.
At least I cannot be assumed to have.
But I will have a statement made at some block number.
And I can read the state out of that blog number.
So it's...
You can get some useful properties out of the back, particularly if you have special state, which is, which is Idle, which is immutable, for example.
Or you can have like time-locked state, which you know would change over multiple epochs.
So you can use this to do some basic, like things like escrow or gating.
And so what is public and brother states?
The public state is, like Ethereum, it's an account-based day model.
So public state is basically just key value, key value storage.
So it works just like Ethereum.
You can have mathings, you can have interdivist, but blah, blah, about there.
The private state works like Bitcoin.
Is UTXO-based?
Outspent transaction objects, I say this is what they're called.
Yep.
So with Bitcoin, right, what is the ETX?
The ETXO is a contains of owner and a value.
And the idea was it is you can create these and you can destroy these and that's all you can do.
You can't modify them.
We use this abstraction for the same reason that Zcatch uses it for privacy because the way this works is
Merkle trees and nullifiers.
So I don't know the level of like for the for the typical audience member.
I don't know that typical like background level so I'll just go through what these are right?
Yeah sure.
Yeah.
So also this is a
if you're applying for an engineering job at Aztec then they have some some fun coding questions about
about Merkel trees that we've tried as many developers um okay so you have your mackletree
or you have a look at a pendoni muckle tree
hey um right and you have i'm not and you have enough i said what are these
So the idea is if I want to make a UTXA, if my smart contract was a creative variable,
they will add it into the tree.
I don't.
You know, just...
Yeah, yeah, yeah, yeah.
And this, and it is very important, nothing gets modified or deleted in this tree.
And this is important so that users can use historical state routes to prove the existence of
state variables, because if a, if a UTXO is in an old state route, it'll be in the correct one as one.
And the same with an Nalafires set, you know, like, so the idea is when a, so everyone to create
you know, create a UTXM. I'll do that. This will be encrypted, obviously with a secret key.
And let's say I now want to destroy it, I put it in the nullifier size, which again is also an
pendulum pendulum in a pendulum, which again is also an appendme in Merkel tree. The value of this is that
these, like the nullifier uses effectively a different encryption algorithm to the, to the Merkel tree,
the state tree. And so,
like an absurd, some third-party observer, when they see a nullifier being created, they
can't link that to anything in the appendion number tree because they don't have the decremation
keys.
And so in order to kind of like spend a note in Aztec, what you do is you send a transaction
where you destroy a nodes by creating a nullifier, and then you create units in its place.
So let's say I have a state variable which represents five and I want to change into three,
I'll destroy the five, I'll create the three.
So the way that works is in order to destroy the UTXO, I have to prove that it does not exist in the law of our size.
It's just a non-membership, which historically were actually quite expensive, but not anymore.
There's been lots of advancements on that.
Oh, interesting.
And another difficulty with this is ensuring Mac, like you don't leak any information,
When performing this action, because whilst as a user, if I'm sending a transaction proof,
it's very easy for me to prove that a note exists in this tree.
I can't prove that I notice nothing to the nullify tree,
because I'm using an old state rate,
and I need enough balances.
So I want to get basically, I need the, in the,
back in that old diagram, like the sequencer,
it's the entity that needs to perform the nullify checks.
Yeah, no, no, no, no, no.
So what this proof is spinning out is basically,
like, inside the street public inputs, on public inputs,
you have, what, you have a list of things.
You have basically UTXOs to create.
nullify uh like uh nullifies to add because the idea is you only you only validate and notify
doesn't exist if you want to add it um uh like encrypted events to emit and this um any like any
messages to i want and also public functions to call so that so um
I'll go to this in a second, because this is how the public-private stakes stuff works.
And so the idea is the nullifier is all encrypted.
So it's okay for a third party to perform the nullifier checks because they're all encrypted.
But the number of UTXOs and the number of the numbers and the number of messages and the number of functions, these are all public.
I see. And so you have to actually be a little bit careful to get full 100% guaranteed privacy.
Because let's say I'm doing a basic token transfer with the absolute numbers of these are small,
or I'm doing some really complicated defect transaction where I have loads of bees.
Well, you can distinguish between those.
So the way it works at the moment is that there are certain like sets that you can, that you can, that we, well, like,
okay, so in the actual protocol, the number of things you're doing here is not really bounded.
when it comes to actual patterns that we want people to use, it is each use set.
So there'll be like a set of where you create four BTs and other fires.
There'll be for 8, 16302.
I see.
And the idea is that you can fill these, you can fill the set with nonsense if you haven't
got enough actual values.
I see, okay, I see.
But obviously the more stuff you do in what's very transaction, so there's a tradeoff.
Okay, okay.
And so...
When it comes to calling public functions.
Oh, sorry, before that question, Mike, how does,
what is like the, if you think about like,
if you think about this smart call,
I can see you have variables, it can be like,
you know, marking and so on.
How does it actually translate into like UTF?
What is that kind of magic?
Yeah, so we, so we,
so we have a live put as to asthmdhcdr,
sake dot noa,
to handle, to create a abstraction service,
where you can basically,
you can create a storage structure
that will have a certain type.
So it'll be a struct or a field element or like a U-Satitude.
It can be whatever you want.
Yeah, it's going to, the compiler will convert that into multiple like
UTXOs have required because each of these can, I think, can contain like 72 bytes of data.
Ah, 32 bytes.
Okay, so just like how in a theory you have storage spots, like, 32 bytes.
And in the solidity language, right, if you have a structure, you're storing that's more than that, it'll patent store slots.
Same with our UtXOs.
And the idea is that the main methods that you have to implement, like that, are able to you, is you can use them create, the more you can destroy them.
Uh-huh.
Uh, and that's, that's about...
But if I have something that has relatively large state and I do some operation like iteration or something,
like wouldn't that create a whole bunch of like those UtexO like?
Only if you're reading and writing them. Only if you're modifying them. So, but it's a good question.
So, okay, so here's something which we're quite proud of.
Take Bitcoin, for example, if you want to replicate a Bitcoin wallet, it's actually quite a headache because you have to handle all of these UTXs.
And if a user's like, I want to send 0.3x3-4 Bitcoin, then your wallet needs to understand, okay, well, how many, like, of all their UTXOs, how many do I need to combine?
Yes.
It's the deal on the edge, right?
Yes.
Now, imagine it's extending that abstraction, not just to Bitcoin, but to like,
Smart contracts in general stakes.
Yeah.
It would be an unworkable method with wallet.
Yes, has to handle that.
So how do we deal with it, right?
Well, we deal with it in Noir.
We use, the smart contract developer basically defines, like, get her and sensor functions
directly in the smart contract.
So let me give an example of perhaps works.
Why does it actually crack? I do my laptop and actually get some of the noir examples out because
it's been a while. I don't want to get bad of it. So the idea about the noir is you have
functions, constrained functions and unconstrained functions. Constrained functions are actual, like,
they, you know, they're part of your circuit. And unconstrained functions are helper functions
that you can, like, you can run when generating proofs, but they don't actually contribute
constraints to your zika start. But the unconstraintuitive functions can
make Oracle calls into the Pixie to restate.
So let's say I have a wallet contract.
I'm not wallet, like say token.
And I want to say, uh, get.
So let's say I have an unconstrained function.
Get, um, ballots.
What I can do here is basically for a,
I can't remember I need to, might use a look at my phone to get the exact semantics, but there are basically, there's an oracle calls you can make to say, get me all of the users, ETSS.
And you can basically, you know, you can be like, you know, four, you know, I in, you know, storage dots. I see, I see.
And you can basically iterate up. So you can add up all the notes. And similarly, you know,
a few, let's say I want to do a trans, so, so that, well, now I'm actually, if I'm, if I have a wallet, right, and I just, and I want to get some of balance, it's just like solidity, right?
Where I just call the, the balance function in the, in the smart culture, the API, and everything just in theory just work.
Similarly, if I want to, if I want to send somebody some, some notes, then what can happen is, you know,
Let's say, by default, the same transaction is two in two out.
So basically, I can destroy two notes and create two notes.
So the way this works is, let's say, I want to send you one eth.
I would destroy up to two notes.
So let's say I've destroyed two notes worth 0.5.
Or let's say, just to give an example, I'll destroy a note worth 0.8 and 0.5.
And then I'll create a note worth 1, which I get to you,
and I'll create a note worth 0.3, which I give to me is my change.
And so in this instruction, what you can do is if...
You use one of these unconcreened functions to basically figure out, okay, does this user have enough notes to do a too into about transaction, given the value that they were to send?
And if they don't, you use recursion.
We basically make another function call into this contract to combine two notes into one.
Oh, I see. I see.
And so the idea of it is there is in the Haley path, if the user has the right amount of notes,
it's a very fast transaction, troop generation is really fast.
In the other Hanyp path, you might need to do a few, like, it's still one-uponautomatic transaction
because, you know, contracts can call contracts in our instruction, but making the trip might be a bit more expensive
because now you have to before evaluate model the function calls to combine notes.
But the general design principle, the heuristic that we follow is that the complexity of managing UTXOs
is handled by the smart contract developer.
Ah, okay, okay.
And the smart contract basically exposes an API, API, whatever, that wallets or that's basically
call to get all the information that you don't need to write offer chain code to handle the
annoying nuances of UTXOs.
But doesn't mean, like, as a smart contract developer, I need to basically like
It could get the smart, it could actually get comp rights of managing UTXOs.
It could. That's why ASTEC or NR exists.
So basically, we had this library that tries to create abstraction layers over the ETXOs.
I see it.
Although we did make a design decision very early on, which is that
Once we create an abstraction layers which help to manage UTXOs, we do not hide the nature of the UTXN.
What we don't do is, let's say I want to create a token contract, I want a private balance.
You can't just do something which is like, you know, U-64 privates to balance.
And then you know, you can do it balance, you know, plus SQLs 5 or like minus sequels.
We can't do that.
And the reason for that is there's no way of writing that Zika, because there's an annoying
edge case in these unconsciously functions. If I'm in my smart grid, I'm iterating over user's
storage notes, there is no guarantee that when executing this function, the user is providing
all of the notes, because basically, um,
Obviously, if you're using the pixie, then yes, you do.
But let's say, let me have a malicious user.
That's operating with code maliciously.
There's no way of knowing how many notes the user has, because they're all encrypted.
Yeah.
And so, you're trust and the user to provide them to you.
Oh, okay, okay.
You can't even have a state variable which describes the number of notes the user has.
Because if it's encrypted, if it's encrypted, then
then if I'm sending multiple transactions that are modifying the number of nodes,
I have, then that one encrypted variable is going to constantly change.
So I make its information.
If you encrypt that variable using the UTXO nullifier set abstraction,
then how am I supposed to send you a note?
Because I can't, if I'm sending you in it, I can't increase your encrypted note count.
I don't know how to decryptu.
I could use holomorphic encryption to do that,
but then if that's happening, then people can see
like that I'm modifying a specific variable in the database.
So basically you don't know how many notes a user has.
You have like, and you only know it for the honest user.
And so that problem means that you cannot create abstractions where you can just plus and minus objects
because the, I see.
I see it. Like you don't, you can't really know when you're on the flight.
Basically, I see.
And, um,
So yeah, we have lots of like nice help abstractions to allow people to, like, iterate other notes, create notes, destroy notes, or like, we abstract away the idea of merging notes have needed to recursively.
But ultimately, the core actions of creating destroying UTX objects, that's not hit, that's not attracted away from the developer.
Do you have some like a notion of like,
gas that meters like the complexity of the proof that it potentially going to generate because like they can imagine like in the
Rasmuchin saying that like there's a lot of steps and like it's
Well, the thing about this is let's say you've a malicious contract or whatever which is really really complicated
What's the effect of that? It means that the the user applied side
it's going to spend forever making that proof, which is not nice, but it does not affect the integrity of the network.
You cannot adopt the network. It's all crying. Okay, okay. So what you can do is basically, uh,
like, the, like, we have a measure of, um, complexity for these proofs because they basically
need to compile into circuits and circuits have a number of constraints. So yeah, basically count on
how many constraints. And
You know that ahead of time.
Yeah.
Uh, so, um, so you know if you can, you can, basically, you can write in the no software,
you could just eat out and it, a, but it's reasonable.
So we now have gas there, but we do have a concept of gas with four, the state that you're creating.
So if you're creating ETXOs, notifiers, make everything events, right?
That's all, that has to go, right now it gets forecast for EIP for four blobs onto L1, and so there's a cost there, so that gets near metered.
And anything that happens in public land, I guess, meet it like a traditional...
...withal chain, because the public function stuff is all executed,
sell aside by the... well, both by the sequels are in the Poulouse.
I see, yes.
Should we talk about how the public and private...
Yes.
Consor... One second.
Yes.
One of the...
So, if public functions modify public state, which is basically its share state,
if I have a small contract, if I have a total supply varys, all,
It can't be private, but it can't be public.
And it can't be private because private state is encrypted.
And so if you have a global variable, who increase that?
That is actually being worked on by one of our partners, a competitor,
a compatible Tatsayer, who are using very advanced multi-party computation on the others to
have our shared state, which I'm very excited by.
But it's, uh, there's, uh, there's,
or those parties that participate in this body party?
Who are those parties that actually participate in the same?
Well, that is a question, yes.
So it's a network basically, and you have to doubt, there's honest majority
try some of this and it gets a little bit complicated.
I see you know, um, so like the base protocol itself doesn't have a notion of shared private stakes.
But we're, like, we're hopeful that we can add in those kinds of semantics,
via it and say it's work in the future, but right now it does.
So, um,
With public state, with shared public state, right, you have raised conditions, right?
If I have, if there's two transactions coming here, yeah, yeah, you work.
Therefore, the, you can't make any, you can't make proofs about public function, the public state,
because the, you don't know what the latest state is, and, you know, you don't know what the transaction ordering is.
To actually public functions, first they need to be ordered by a sequencer, and then they need to be executed.
And so this creates a very interesting sort of dynamic where if I have a private function, a calls a public function,
These things are happening in a time asynchronous way.
See if I have like a private function as fool.
Right.
And I call, you know, they call like bar and I call bass.
And let's say this is private and this product.
Well, this function gets executed before this function.
Even though you'd be...
Because I am locally, I am pretty all the other functions first.
So how does this work? How do you actually, if things are not time order correctly,
how do you create some kind of semantics to write contracts that aren't weird?
And the solution is actually pretty simple, it's that public functions come on a return parameters.
When you call a public function, it's like it's a void function.
Like you can give it, it's an argument, but it has no time parameters.
And so in that model, because public functions can't, well, I mean,
better assume it can't modify private state, okay, they can't.
This is you public terms can modify private state. It means that
Any side effects of the public function performs,
I see, I see, cannot touch the product.
Exactly.
So effectively what we're doing is we're creating an abstraction where it doesn't matter
on which order these things are executed in because they can't affect each other.
I see, I see, I see.
Which obviously is there are some limitations there because if you have no return parameters, you can't...
there are some things you can't do but honestly there is a lot of very powerful you
do so you can get out of this because generally what you you can structure
contracts so that you know you have some private validation or product execution and then
after you do that so there's steps there's some public stuff you all to do
sometimes all these public functions can contain assertions that have to be
valid for the transaction to succeed um that use shared stake for example and so things like that
Like, don't, uh, if the public function contains assertion, for example, and you don't, like,
when user execute this locally, they don't necessarily have the latest state.
Yeah.
How does it actually work?
Like, you're assert, like, does it say like I assert on this state route that this?
No, no, so you assert in the public function, you assert on the latest state route, because
you're not, you're, you're, you're not, you're, but the user doesn't necessarily know what they're late.
You're right, but that's the same as any blockchain.
Sure.
Okay.
Because like in Ethereum, right, if I'm calling a function that has an assert, I can only guess
about whether I assert succeed or fails.
I don't know 100%.
Sure, sure.
So what happens is like, what happens is locally you simulate this transaction, easily the
latest state you have, and then you send your transaction, you cross your fingers
and you hope that when it actually gets mined, it's it, you get the same outcome, which
is exactly the same than I like has existing blockchains today.
Well, what's an example of this, let's say a private function that contains cost both
public and private functions?
Yeah, so one example would be defy.
So let's say in exchange.
So let's say I want to do a private, I want to do a swap.
So if I got a basic decks, like a uniswop player, then that's going to be largely public
because I have things like liquidity pools and like total supplies and prices.
logic that you just need to actually public land.
Yeah.
But in this scenario, I would want the identities of the people, transacting.
And be private.
So what I would do is, like, in terms of the transaction flow,
I do?
You would.
It's a fun brazened all this in time.
Actually, I'm actually not the best person to describe this because we measure some really nice
abstractions to make this seem sensible.
And what I'm about to describe is everything you kind of exploded out.
So let's say all this flop.
for...
So I will set one, I will...
I will...
I will un-shield boost...
What I'll un-shield east?
This is what we do to, like, um, uh, like, pseudo-addressed.
So that's it, so, um, uh, and I will do the same for die.
Okay.
So basically, I'm like, I'm Bob, Bob to East or Bob to the second way, and I'm creating basically like a throwaway address here.
Is it actually what happens?
But this is the same outcome.
Okay.
So I'm unshouldily east, like these are some pseudo address, which I control, but it's not linked to my real address.
I then, and this will be private.
And then in public land, I will...
Ah, I see, I see.
Okay.
Heath to die for X.
And then I will shield.
Yeah.
Shieldness.
Bob.
Okay.
Okay.
As saying there.
So this is public and this is a hybrid.
This is actually two functions which is public credits.
Ah, okay, okay, okay.
And so another basic point is let's just say, I am doing something completely that's completely public.
For some reason, an Aztec probably shouldn't.
Yeah, but let's see what.
But we have a counter-sraction in Aztecs.
So the protocol itself doesn't validate public, rather, key pairs signatures.
What happens is you define an entry point contract, and that contract requires the authentication logic.
So what you could do is, let's say, the start of this,
What I did this say is you could like auth like, you know, Bob.
Dot okay.
Let's say you do it via Google sign.
So let's say you have a match to small contract which verifies the Google Authet
and you're using that to validate your address and now be prior to function.
So I'll add the old term.
Accountal authors is always basically fraud.
So that's one example.
Some others would be like if you have, if you're doing some escrow or something just time sensitive,
you may want to call a public function to like assert that the current, like,
you might like to assert that the current block toy is that within some epoch,
and things like that.
Okay, okay.
Yeah, this is very cool.
Maybe can we talk a bit about our client-side-proof generation?
Because I assume it's like a resource, like you need to think about how much resource
consumption cannot be like too expensive to do and like, yeah.
Yeah, so, so yeah, we use our own kind of custom cryptography engine.
So software's called Boresenberg.
We started building it in 2018.
I actually started writing it before I even had a SART protocol.
This is because we were using it for just basically like algebraic.
But ah, so you know in 2019 we came up with the Planck protocol and then we basically
did not take a triple Planck and then also Planck and then we have Funk and then we have
like, okay so basically like the I can go through the premium system because affecting the way it works is right now
the, like, the memory limitation, like, basically, like, you can do all of this stuff with us like make-truths, and the memory about bandwidth is 4 gigabytes.
Uh-huh.
Which is pretty high.
It's basically got buzz on it. And if you do it in four, the target long time is to get under one gigabyte, but right now we also like focus on launching a security overview, so, so, not quite that yet.
Apart from very small, through doctors.
Uh, so...
How does this work? How do I describe that?
So we have our, so we have the base, like the core pretty protocol, which is folk.
So this is basically plonk plus custom gates, uh, plus, uh,
um a sum check iop so unlike the original plot paper we we replaced so i don't know what the
the domain level experience is here like yeah that that's fine uh it is so like you know if you're
proving stuff um if you want to make a zero non-proof of some program whatever there's this
kind of three steps to it first of all you had to take your program statements and go better it to some kind of
algebraic representation that you can easily prove.
So generally this is polynomial algebra.
So you have some, you know, like a bunch of polynomials,
there's simple, simple arithmetic relation over the polynomial that's equal to zero.
And the trick here is that the polynomials are very, very high to be millions, millions
of times.
Then you have something called an interactive oracle proof to
to validate your polynomial relation is correct,
or more precisely converting this polynomial expression of a very high-duty polynomials
to an expression over single values, over point.
And the way that we did that in the original Plunk paper was through quotient testing.
So basically you check that these polynomial expressions are equal to zero,
moduloid or some kind of vanishing polynomial.
That's kind of annoying. It's a bit slow. It's memory-gand-bring, so we use a subject now, which is an older technique, but it didn't work back in 2019 with the kind of algebra technique we need to block, but
There's been lots of advancement since then.
And he did him hype the Hypochrane 20, which make it possible.
So now we use 100.
Yeah, no fin?
We also have like our lithop tables.
So basically, originally this was Slakot, but we, uh, a couple of years ago,
there was a log up, all of how I could create it.
I call log up, which was an initial, like a, a big epitome
shakup, so we use that. And memory instructions.
So basically, this is a little sub-proticle that allows for the emulation of RAMs in your circuit so that you can basically read and write into memory at arbitrary locations and making that very efficient.
So that's the 3D system.
Oh yeah, plus some multilinear polyuretso-criminal scheme, so the gemomites.
Oh, multilinear.
Well, that's one of the annoying things about sun checks.
The good sun checks, they require multilineal polynomials, not univarius, and that.
But anyway, so...
Let's see.
But this isn't alone, is it not enough?
Because the problem with...
So this architecture that we have, like, I wanted to do something like this for many, many years.
But the problem has always been cool semantics.
So if I have a transaction where I'm calling a contract, that calls another contract, that calls another contract, it calls another contract,
how do you compose that all into a single group?
And the answer is recursive composition.
You basically need to have circuits which verify proofs the rubber circuits.
And that's very hard to do efficiently.
It's very hard to do off phone.
It's very hard to do in a web browser where you don't have
access to the native CPU, you have to use web assembly that gets
intelligent and it's horrible. Yeah. So making recursion fast enough was always the hard part.
And so the way that this works is we use is a proto-galaxi folding scheme. So this was something that...
So it's an aviation of Protostar. So Protostar was a folding soliding scheme made by
I think it was a better, and then Ariel and Liam Egan,
I've his rated amount of Predigalcy.
So the Predigalixie formal scheme for version for recursions.
So it's not technically accurate to call this recursion, but it's like the same, it's because you get the same outcome.
So the idea with the following scheme is, let's say I have multiple proofs that I want to verify.
So sort of actually like verifying them,
like creating a verification algorithm of the mobile Zika stock,
with any Zika stock is very expensive.
What we do instead is we basically create random linear combination.
So the idea is you have, you have, you have a, so for the photo guy,
see you have a, you have an accumulator.
So you start with it, your inputs are, an accumulator instance.
So call this, I can't remember these symbols.
And then you have a new circuit.
And the idea here is that you
effectively create a random linear combinations of these.
You basically want to multiply, you want to inject some kind of randomness
into the new circuit instance and adding into the accumulator instance
to clear a new output accumulator.
And the idea is, oh yeah, and the idea is what you're doing there is effectively...
I'll just make this out about to be doing.
Eastons per error. So basically what happens if you basically take a bunch of circuits, like by instance, I mean, so you have a committed, a commitment to a satisfied witness.
If you just smash these together, like you add randomness and smash them together, the result isn't a valid proof anymore, right?
Because the whole point of this of the circuit is you have some expression of some polynomial was which equals zero.
And if you just create randomly combinations of multiple circuit instances,
then the polynomial algebra does not equal zero.
But it does equal some kind of error term.
And so the idea with the folding scheme is that you have this protocol between a proofer and a verifier.
So folding crew and a folding verifier, where the folding verifier,
well, the folding crew basically says, okay, I'm going to smash these two circuits together.
or the satisfying instances that you circled together.
And the result is that instead of the proof relation being zero,
it's now going to be the terrorism.
And the verifier will run a little into a protocol with the approver to validate that the error turns correct.
And this is much cheaper than actually verifying, fully verifying approval.
And so this was a big unlock for us.
because now instead of running a full recursive verify,
we run folding verifier, which is much cheaper.
But there's a problem with this, which is that the,
in order to evaluate the folding verifier,
there are two kind of operations.
You can do field operations and the elliptic curve operations.
And the elliptic curve operations are very painful to do.
Because it's non-native field in a real field.
Basically, you know, all your circuit algebra is over some prime field.
And the elliptic curve algebra you need to perform is over a different prime field.
It's not an extension versus different prime field.
Oh, okay.
And so you have to like to do that, you're to emulate
this non-native fire field.
And the way you do that is by you emulator-based two-number system,
and then you use that to everything.
It's horrible, very expensive.
So, how do you solve that, sir?
Gordon Planck.
So Goblin Planck is a regression accelerator.
You could say, like folding accelerator.
What it does is a very, very nasty,
complicated protocol to convert the expensive operations
in the folding barifier to tube operations.
So what it's doing is it transforms
the expensive elliptic curve operations into elliptic
operations that are over a native curve.
So where the field, the point field matches your second field.
And this uses curve cycles.
So for example, in Aztec, it's been 254 curve.
And so there is a cycle curve for,
so over like, so the curve, so like with,
so let's say it has endpoints and the arithmetic.
is s the p, so for the ECC, uh, like it equals curseild.
And then, and we had a separate club which is called GrumpCats, which has P points.
and the circuit and the field is yeah and so the idea is you can very efficiently
evaluate some bnti 54 operations over in a grumpkin circuit it can very efficiently evaluate
grampen operations at a bha4 circuit and so what we basically do is a very compact
protocol to transform the btify four operations we need to do to basically delegate them
into like you evaluate them in a circuit divided by Duncan and that you you you prove that you
basically correctly arrowed and transform the show's perform the transformation and then
there's one final piece of the puzzle that's a subreder code we call the database
Plunk database. What is the database?
Which is basically an efficient way of transferring information between multiple circuits that are being composed together.
So if each, let's say each circuits that you're recursing over has a thousand public inputs.
Well, in the founding verifier,
Public admitts are not free, right?
Basically, you have to hash any public input.
And that gets expensive if we have a thousand of them.
Yeah, yeah, yeah.
And so what we watch is a constant time protocol.
We're basically no matter how many public inputs you have,
the amount of time to try to transport them between different instances is constant.
And that's what the data bus does.
And so this is a complicated mess, mishmash of protocols.
And yeah, so all of these combined is how we create a cryptographic creating system that can handle the complexity of the asset network.
This is and do the client's side with minimal resources.
That sounds great. Is there any limitation to like, you know, the computation can do?
Well, okay, so there is a limitation where basically every single private function that you do,
it can have a maximum of about a million constraints.
Ah, okay, okay. However, you can always break out your, if you go over that, you can always break it out into multiple private function calls.
And so the only limited factor there is, well, the sheer amount of time taken to the amount of time taken to be.
Yeah, as long as every single,
cool you're making is under a million constraints, then the year limit of
factor is how long you've got away to make the proof.
And then roughly how, let's say for like one million constraints,
so how long it takes to?
More many constraint function.
Well, just one wouldn't be that long.
Like 20, well, maybe 20 seconds.
William, but one is quite a lot.
Like, you don't need anything like close to that for both things.
Sure, yeah.
But for a general asset, so for the, so we did an engineering offsite three weeks ago.
And we got finally, the first time on what test, we got an end to end
token transfer transaction working in a web browser and on a phone.
And it's been impressive.
Thank you.
I think the proving time for that was 15 seconds.
Oh, which is, it's like, it's tolerable but not great, is what I would say.
You know, but that's kind of the performance floor.
There's lots of stuff that you need to improve it that we've not been focusing on.
Like, for example, we don't even use web GPU.
When we're proving, we don't use single instruction, multiple data.
So we're confident we can get that lower.
The target that we have, so our MVP, minimum viable product targets for Mainnet,
is a complicated defy transaction in proved in under a minute of consumer hardware,
which is, you know, it's like,
you know, it's complicated, right?
I mean, by the standards of the industry, of ZK, that's amazing.
But a sandwich for Web 2 user, it's not a good adult.
So something else we're working with this, basically, we want to make available, like, prove a delegation
if users want it.
So basically, you give your proof of third party, which does,
In theory, you could crash privacy.
But if that's a party, it's a TEE, maybe not.
Or if it's a multi-party
proven network like TAS to say,
So, yeah, but like basically the goal is we want the base network, the base predable to function without third part, like without extra infrastructure.
But if you want like a Web2 style, Smapper UX, then me wants to delegate Xen stuff.
We'll see.
The goal is to get rid of that long term.
You know, we're not going to stop.
iterator analysis and improving this until we get to that.
But in the short time, you know, if you want to do super complicated stuff on Aztec,
and you don't want to wait a minute to approve, you might need to do competition navigation.
Okay, yeah, sounds great.
If we went through all this, and thank you, Zach, for looking us through this.
And yeah, it's great. Thank you. Thank you, Dan, yeah.
We enjoyed this.
