Local Setup and First Run

Transcript

Good morning, GMGM. Thank you everybody here for taking choosing [music] to spend your time at our third inaugural no. >> Like I said, I want to get you guys um familiar with how to get started on Aztec cuz a lot of this is kind of like abstract and it's not totally clear exactly what data structures you're going to interact with um how to do do these things. So, I've got a couple slides with some resources and then we'll just open VS Code and uh get going. So, yeah, installation overview of stuff and then some references of resources to get started. So, to install the tooling um this is actually in the docs. So, if you go to

docs.astec.network network. Um, you land on this build section where this is for developers and application developers specifically where you want to write contracts. Um, understand how Aztec works. We have this whole node operator section. This is more for infrastructure operators. Um, but this landing page getting started on sandbox has uh prerequisites and the installation script. So, our tooling does require Docker. Um, it's currently just Docker containers. We're working on removing this dependency so you can actually install the tooling without needing Docker. But currently, you do need Docker installed. And then you can run this oneline install script and

we'll install Aztec up. So Aztec up is our uh just tooling management tool. So if you run Aztec up um after running that script um it will pull some images. I believe I have the latest. So it's not actually going to pull the Docker images. It's just basically when I run Aztec up it's getting the Docker tag latest version which is currently 2.1.6 which is what Ignition is running. If you guys aren't aware, we started our network, was it yesterday morning at like 2 a.m. Um, so we have a network that's running and producing blocks on Ethereum, posting Ethereum transactions,

um, proofs of proofs of blocks. It's awesome. There's no transaction enabled on this network currently. So, if you actually want to write contracts and deploy them to a network, you're going to have to put them on the DevNet or like a local development environment. Um we're looking to get uh the execution environment enabled on uh mainet Q1 next yearish hopefully. Um one of the difficulties with building a blockchain and designing one that's that's never been made before is there's a lot of unknown unknowns and some of the timelines um can can fall a little bit but that's what we're shooting for. Um there was a question previously about versioning. I recently added a whole bunch of versions to the docs. If you

look at this dropdown, I have ignition is the default. It's 2.1.5 or 2.1.6. We had a patch for for a minor thing. We also have testnet. I believe it's still running 2.1.4, but then we also have DevNet, which is essentially just a network that Aztec Labs is running the single node and we're just keeping the network going. This is the network for developers that's public. So if you want to deploy your contracts and have other people connect to that network and also interact with your contracts, um this is a public network that's useful for um yeah writing and testing contracts.

Um and we also have a nightly version of the documentation. Every night we just publish the latest um changes from from our monor repo. Um so yeah, it's kind of confusing which versions to use, but just use DevNet. So the way you would install DevNet is just do Aztec up 3.0 uh 3.0.0/devnet.5. Um you might see like DevNet.2 DevNet.4 DevNet.5 various places. Um these are just minor patches that have been released like DevNet. 2 should work with DevNet.5.

Um, I recommend using DevNet.5 because I think some of the Docker tagging was improved with DevNet.5. So you may just like encounter slightly fewer errors. Um, so you can run once you run that install script, you can run Aztec up 3.0.0-devet.5 and you'll get the uh DevNet version of of the software. You can see it's actually installing a bunch of stuff to my home um in the Aztec directory. It's the Aztec run script. Um there's an Aztec utility, Aztec up utility, Aztec Nargo, which is just a Aztec specific version of Nargo,

like just Naro at a specific commit tag. Um there's Aztec postprocess contract, which does some uh verification key stuff. I actually have a I'll just move to the slide on this. Um here's the details of all of the tools that are included when you run Aztec up. So the basic asset command launches infrastructure systems like mainly I've seen this used for just like running nodes. Um if you go to the run a node section of the docs like a lot of the stuff are just asset commands. Um when we start our sandbox we'll just use the Aztec command. Um and there's some utility commands for interacting with a network. I don't typically use the Aztec command to interact with the network.

I'm typically writing TypeScript stuff. It's just a lot easier um to do. Aztec Nargo, as I mentioned, is a specific build of Nargo. Aztec postprocess contract is a post-processing tool for Aztec contracts um that you'll run pretty much just after compiling contracts. Aztec up helps manage versions. And then Aztec wallet is a tool for interacting with the Aztec network as well. Um so doing basic interactions and it it sets up a wallet that includes the private execution environment that Kiara and um Paula were talking about. Um I mentioned versioning ignition is the latest tag. It's what all the node operators are running. We have test net for node operators to test

newer changes on the networking side. um DevNet for folks like us writing contracts and then nightly versions um if folks are really want to try typically like some of the latest proving system updates or something like that so we can get into actually running the sandbox. Um I want to go through this right here. I have this uh Aztec starter repository linked. Um, what I'm going to do is I'm going to start at the sandbox and kind of go through some of the things in Aztec starter. But this Aztec starter repository is designed not as like a starting point for building an application, but it's a starting point

for learning about how to do things on Aztec. So, um, what it is, it's a relatively simple repository with an Aztec contract in it and then, um, some scripts as well as some tests. So we can see like there's a simple private voting contract in here. Um there's utilities for compiling the contract, generating the TypeScript artifacts. Um there are utility scripts for setting up a wallet. Um setting deploying an account um restoring an account from like environment variables.

um testing unit tests in Noir itself as well as more endto-end tests in Typescript. Um there are some these are more like reference scripts that show how to do certain things. Like if folks ask me questions about how to do certain things on on Discord repeatedly, I'll add something to the scripts folder. Um, if you guys do repeated things on Aztec and um, you use you have common scripts like definitely open PR iss on this repo. There's a bunch of contributors from the community here. Um, but some examples of of scripts like deploying contracts, deploying accounts. Um, there's we have fee abstraction on Aztec. So there's a

bunch of different ways that you can pay fees. We have a fees script that shows all the ways to pay fees. Um, and these are in code. So, like it's not just a description. It's like, hey, if you want to do this in your TypeScript, like check out this uh script and and pull the code you want. Yeah. What's up? you take so deeply how you exchange notes when you exchange not >> for sorry I don't understand the question if if you exchange a note with someone you need to exchange with fees >> exchanging notes

>> yes like paying for a coffee >> okay >> there is fees involved >> transaction fees yes there are transaction fees >> how exos deal with That's >> um well the the fee payment can either be just like >> but fees change the fluctuation of the network fee can change. >> Mhm. >> So is there is a burning process for the >> Yeah. So the way fees are actually paid is a user will send fees like basically they authorize a certain amount of fees to be paid as part of a transaction >> and if there is le if there is more it's burned.

>> If there's >> if it's less fees I I mean >> like they'll get a refund for for unspent fees >> or it's burned. Is it burned or no? >> No. There like there will be fee refunds. Um we may implement you mean something like EIP1559 like burning fees? >> No, it's because I feel you can of guess if it's a refund something. No, >> I don't know.

>> There's You're asking because it fees fees being paid in private. Yeah, that's why. Yeah. >> Yeah. Um I'm not sure I understand the question. >> No, it's fine. Sorry. I'll find a real example. >> Yeah, definitely check out the script. And there's there's examples of how to essentially pay fees yourself. Um fees are quite a complex topic on Aztec. um particularly because the fee token lives on Ethereum, it's non-transferable on layer 2 and we have this fee abstraction concept. So um this is definitely a more

advanced topic that we can talk about a little bit later but I want to focus more on like just the the getting started side of things here. Um so yeah going back to overview of this repo um there's configuration in this as well for like doing things locally on we call it the sandbox um the local development environment or doing things on devet so you can run these scripts against like the actual public network or just doing it locally. Um I'm going to focus on doing this locally here because um I'm not sure how good the internet is. Um so yeah if if we want to just get started um

with the local development environment we'll run Aztec start sandbox. When you run the sandbox there's not actually any proving of blocks happening. The sandbox is not actually checking for valid transaction proofs. It's a local development environment. So it's meant to be fast and allow you to iterate quickly. Um so when you're deploying contracts and when you're sending transactions whenever there's any proof checking happening the sandbox is just saying hey I'm assuming these proofs are valid. Um just to keep it fast and um yeah keep the iteration quick. So if we just look at what's happening when we start the sandbox um we're deploying a

whole bunch of L1 stuff. We're basically, well, we're starting Anvil, um, local Ethereum network. We're deploying a bunch of contracts. All this Aztec protocol contract stuff. Um, we can just see there's like deploying contracts, sent L1 transactions, just sending a whole bunch of L1 transactions, getting our local environment set up to replicate Aztec. Um, doing a whole bunch of this. Then what is it doing? Um connecting syncing with the rollup contract that's on Ethereum.

Um it's starting the the PXE. It's creating some test accounts. So the sandbox actually comes with a uh three accounts that are already deployed. I typically like to deploy my own accounts when I'm starting like writing new scripts just because um it is more similar to how like a user would be interacting with the network. Um they're not going to have we're not going to have accounts that are pre-eployed that we can already connect to when we're interacting with DevNet or something. It's just on the sandbox. So typically when I'm interacting with scripts, I'll I'll deploy accounts myself and just use those. Um, but these are here if you want to use them and they're prefunded

with a bunch of the fee paying asset. So they can just automatically pay for fees. Um, this isn't true on DevNet. On DevNet you'll use uh different aspects of fee abstraction. Um, we have a sponsored fee payment contract that allows you to just use that as the the payment method. So you don't actually have to worry about transaction fees. It makes it quite easy. um not something you'd be able to do on the test net, but if we just keep keep scrolling through, here's the initial account information. Um the pre-eployed account addresses, um we talked about nullifier keys, signing keys, um encryption keys with

Kiara and Paula. Um the these initial counts show that sort of information. So there's an address associated with each SSC account. Um there's a secret key. There's the master nullifier public key. Um and the master incoming viewing public key. The secret key is used to derive like the nullifier secret key and and the decryption key. Um and then these master nullifier public keys and incoming viewing public keys are used for um verifying that accounts are correctly like they're allowed to essentially nullify notes um or that when you're encrypting notes to those

accounts that they're being encrypted properly. So, as Paula was mentioning in the the last question, um we need to be able to ensure that notes are being encrypted to accounts correctly um when we're interacting with counterparties that we don't necessarily know. Um these keys are important for those operations and we can use those in the ZK proofs to basically ensure that they're done according to the contract rules. So all all accounts on Aztec will have this information. This is why you can't have like Ethereum accounts just working with Aztec accounts by default or Aztec wallets. Like there's a whole bunch of additional information um associated

with Aztec accounts. Um we have the sandbox is registering contract classes in the protocol contracts. Um in Aztec we have a distinction between contract classes and contract instances where essentially we can have like a a token contract class um that will be published once to this contract class registry and then if anybody wants to deploy tokens using that contract class um there's just a pointer in the instance that says hey

I'm this instance of this contract is using this um contract class which massively reduces is the redundancy of code on the network and it makes it much cheaper to deploy instances of contracts because we can say hey this contract logic lives in this class and then the state of the contract the state of the instance will be unique. Um so the sandbox is deploying these contract classes. I think the default accounts that we're using are Schnore account contracts which are essentially just verifying um Schnore signatures to authorize transactions coming from these contracts. Um so it registers Schnore account contract class and then creates

three uh Schnore account instances um and adds a fee payment contract. Fee payment contract helps manage this fee abstraction piece. Um, and yeah, I'll just skip to the bottom and we'll get into running more scripts, but essentially you'll see this when your sandbox has started up. It says Aztec server listening on port 8080. Um, your Aztec server is essentially an Aztec node. So, your sandbox is now just working as an Aztec node that you can send um transactions to to deploy contracts and interact with contracts.

And now this is just running. We can keep it in the background. And um the easiest way to get started is just running some of these commands. So if we just look at package JSON, I have some scripts defined here that make it easy to do certain things. So I can just even run um let's do yarn deploy account. And this is going to deploy a new account to the sandbox for me. So, it happens super fast because it's not actually generating proofs and the sandbox isn't actually verifying proofs, but the sandbox received a transaction.

Um, we can see in the logs here, um, it's generating account keys, secret and salt. Um, these are inputs to the wallet. We can look in the script in a second, but inputs to the wallet to actually generate the account. Um, it's adding the Shnore account to my wallet that I'm creating in the script. Um, and basically just deploying it to the network. Um, if we look at what the script is doing, um, basically what I have this function

called deploy account. It take optionally takes a wallet. If a wallet's not provided, I believe it just creates one. Um, but I create some random values for for the wallet. I can save these later. Um, and these are inputs to the create schnore account method on the wallet. Just passing secret key, salt, and signing key and getting the deploy method from the wallet create account method. And I mentioned um fee abstraction where we need to pay transaction fees on the network for the sandbox and where when you're using DevNet um just use this sponsored fee payment contract the

sponsored FPC which basically what we do is we deploy a fee payment contract to the network and it unconditionally pays transaction fees for anybody that calls it. So, um, yeah, it just basically is loaded up with tons of fee tokens and says, "Hey, whoever's using this as the fee payment method, just give them pay pay their transactions fees for them." Um, this will allow all of your transaction fees to to work on the the sandbox and DevNet. Um, so we set up the sponsored fee payment instance. um we have to register the sponsored fee payment

contract in our wallet because our wallet is what our wallet has the private execution environment and we're actually calling the sponsored fee payment contract as part of our transaction. So we need to tell our private execution environment that the sponsored fee payment contract exists. We need to tell it um what the artifact is like what what does the contract look like? what is the address of the contract and we register that in our PXE. So then when we send a transaction that's calling the sponsored prepayment contract, the private execution environment knows how to execute the the functions associated with this contract. So we set up the sponsored fee

payment method. We call the deploy method send for the account contract specifying the sponsored fee payment method. And there's a a nuance when deploying account contracts where um we specify them as coming from the zero address only for account deployment transactions. any other type of transaction you'll specify the actual address from which the you want the transaction to originate from since this is a account deployment transaction

specifying Aztec address.0 zero. Um, and that's basically it. I know this is a lot of information. Really quickly, the idea is this Aztec starter repo is on GitHub. You guys can start the sandbox and run these scripts and actually dig into how this is this is working. Um, and you can mess around with these scripts, modify them, log more stuff um, to get a better sense of what's actually happening behind the scenes. It's a really good test of understanding to be running these scripts and like think about what you expect to happen, run your scripts, and then actually see what happens. Um, or even just logging.

So, um, I'm just trying to give you guys an introduction so you know where you can go to actually, um, start start playing with these things. Um, is anybody actually following along with this or like running these scripts? It's working. Cool. If you have any questions, definitely jump in. Um, >> yep. These I'm not exactly sure. This is normal.

Um, it's not a problem. I'm not exactly sure why these logs are um consistently happening, but yeah, it's normal. Um so, jumping over to the deploy contract script because this will be useful for you guys when you're actually writing contracts. Um later in the day, the DFI Wonderland guys are going to get into actually writing contracts. Um so right now this just comes with an example private voting contract. Um [clears throat] if we we can just

compile what's what's there with yarn compile. It's actually going to run Aztec nargo compile and run Aztec postprocess contract um to generate the artifacts and then I believe yard code genen will generate the typescript artifacts for use in the scripts. Um it's probably going to oh it did update. Um so by default this deploy contract script is just using the private voting contract that comes with um comes in the repo. So I can just run I believe yarn deploy and it's going to deploy this private voting contract. Um I believe it's also going to deploy yeah

it deploys a new account using the same setup that we just went over with the sponsored fee payment contract. deploys a new account and then uses that new account to deploy a private voting contract. So when you're deploying a a new contract, you can just take the contract artifact from the generated TypeScript, call the deploy function on it, passing the wallet um and then the specific address. I believe the second input is like the owner of this contract. Um, and then you specify the specific account address that you want the transaction to come from and the specific fee payment method. We're using the sponsored fee payment method. And

um, log a whole bunch of stuff just so we can read it. And we can see that our we have a new contract deployed. So now we have a private voting contract deployed onto our sandbox that we can then interact with. Um, this is a pretty simple contract. It basically sets up an admin for a voting system, allows people to cast votes for specific numbers, and um, yeah, I'm not going to get too much into the details of the specific ad the contract syntax or how this works. Um, but yeah, now we have a contract that lives on the

network. Um, if you run I believe it's just Aztec deploy, yeah, col devnet, this would actually push it to the public devet and then anyone in the room could use their account contracts to um interact with the private voting contract. So, there's a bunch of examples in here. Um, some of the more interesting ones I think are the fees. fees is a complex topic. Um you can see a lot of the details of how feeds work on from the JavaScript side um in the script. And then also this multiple wallet uh script shows how

you can set up multiple wallets um that should have they should be siloed in terms of like visibility like when you're using one wallet versus another wallet. like wallet two should not be able to see any of the information that's in wallet one and vice versa. And um this is one of the more difficult topics in in developing on Aztec I'd say is when we need to like register contracts think about which contracts exist in which wallets how these um wallets are doing um executing transactions and what's visible in each one. Um, this this script is a good place to start to

kind of see how to how to set up multiple wallets and then think about how this information is siloed between different different wallets. Yeah. >> The artifact. Um, typically it would be served as part of like a front-end application. Um, so yeah, you could get the artifact a number of ways, but yeah, it can just be served with the web page. >> Yeah.

Um, yeah. >> Devet there were creating the account on the devet created two nullifiers. Why why would there be two >> two nullifiers for creating an account on DevNet? >> And is there any way to understand like what or is this just something we shouldn't worry about at all? What the nullifiers which UTXOs and nullifiers correspond to?

>> So what we would want to do is because we're deploying a Schnore account to the to the DevNet, um we'd want to look at the Schnore account contract code which is actually in our monor repo. Um but there is state associated with that Schneore account contract. Um I believe the public key of the signing the signing key is in the account contract state. So then whenever you essentially sign a transaction the signature is the public key is derived from the signature and then it's checked against the public key that's stored in the shore account state. Um when that state is initialized I believe that emits a nullifier

um and then >> there's pro I mean there's another nullifier that's emitted as part of that um >> so process looking at the contracts that the noir contracts you will be able to see the UTXOs that are emitted >> not exactly you'll be able to see like you'd have to know that basically when certain state is initialized um a nullifier is emitted So that's not going to be immediately obvious from just reading the contract. Um but that is one of the side effects of like initializing state. So reading more in the documentation will help like understand which which actions are emitting nullifiers, but um yeah, off the top of my head, I'm not sure where the second

one's coming from, but >> Okay, thanks. >> Yeah, cool. Yeah, I say I'm over time, but uh I'll be out in the hall. So, if you guys want to talk more about any of this, um yeah, come find me. Cool. Test test. Let's give it up for a round of applause. [applause]