Ethereum Foundation DevCon 6 - ZKPs: Privacy, Identity, Infrastructure & More Track, 18 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Public-Private Composability by Mike Connor | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/public-private-composability/

Learn about the challenges of designing a private execution layer for Ethereum.
Previously, smart contract execution (L1 & L2) has been fully public. Some apps provide basic private functionality for a single private state (e.g. privacy coins).
We'll discuss ways to execute general private and public state changes across multiple smart contracts in one transaction, within a zk-rollup. This unlocks programmable private smart contracts.

Speaker(s): Mike Connor
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: zero knowledge,privacy,smart contracts

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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?

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

B

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.

C

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.

C

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.

C

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?.

A

uh I didn't fully follow the long question. um Maybe we can chat afterwards. Sorry about that.

B

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.

D

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?.

A

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.

B

Round of applause once again for Mike Connor,.

A