"Aztec 2.0 - A new layer 2 built with privacy at its core" - Joe Andrews
ETHGlobal·Sat, Oct 9, 2021, 12:00 AM
Speaker
Joe Andrews of Aztec discusses the utility of private rollups for scaling Ethereum.
Transcript
tech and he'll be talking about the the new layer 2 aztec is built um as their zika evolved service with the privacy at its core and uh ngo was already here with us on on this uh call so i'll just let joe kick off with a screen share and his presentation welcome jeff thanks guys sorry one second great um i'm gonna run through this uh fairly quickly because i'm on patchy wi-fi hopefully this will uh hold up uh this time and we'll move on to the demo and the code because i'm sure that's what everyone's here to see sounds great uh great um my name is joe i'm one of the co-founders of aztec and we're very excited today to announce the launch of aztec 2 as okay roll up with privacy so in the half now we've got today we're going to run through what aztec 2 is and how we use zk snarks for scaling and privacy uh in the layer 2. we're also going to do a quick demo um of how private transactions uh appear on robston and we'll do a run-through of noir or smart programming language i also think it's it's important to take a step back um when people are developing an ethereum uh things move very quickly it was only eight months ago we launched the 1.0 version of our protocol bringing confidential transactions to mainnet shortly afterwards tornado cash also brought anonymous transactions in february and in the same month our research team upgraded our universal smart planck in february so what is aztec 2 aztec two is a zk roll up base layer two it allows users to have private sends by default averaging around five thousand gas per transaction it has social key recovery built in and allows scalable private access to alongside it we're also shipping a programming language noir giving developers the keys to programming privacy aztec 2 is powered by planck the cursing edge snark built by aztec over the last year planck has the performance of a traditional snark but only needs one trusted setup in certain areas it's also 10 times more efficient allowing us to do recursion this efficiency makes zokay snarks usable on ethereum today signatures can be validated over the ethereum curve as well as curve 25519 which is the curve inside most iphone and android security modules proofs can be constructed in seconds and clients can benefit from full user privacy this efficiency is core to the design of the aztec layer 2. it allows us to roll up snarks inside snarks the inner snark can be anything a private transaction a uniswork trade or even another rollup this design allows our layer 2 to have scaling and privacy as private transactions are at the core of the network users can get opt-in privacy for erc20 token transfers balances are confidential and senders and recipients are anonymous this is the most efficient version of aztec yet it's over 200 times more efficient than aztec one private sends are around 5000 gas per transaction and d5 interactions which will be launched in november around 10 000 gas in fact the network can scale elastically up to 1024 transactions in a single block alongside this we're proud to announce a new account model each user can now have an alias you can be montsuma the second and not an ethereum address we also mirror the common social recovery patterns seen on ethereum maintenance today alongside the network as the core is a snark we're releasing noir a programming language that allows developers to write their own circuits and have those bundled in the aztec roll-up the language will be released in developer preview in november and is open source and written in rust let's move on to a quick demo and we'll first of all demo the block explorer then a quick terminal view and then the code so we have a block explorer live on explorer.aztec.
network this explorer updates in real time and allows users to go and see the blocks that are being processed by the network the transactions on ether scan and any transactions that are inside the block we also have a a demo ui which is a terminal.aztec.network which is a fun command line interface we call the aztec zero knowledge terminal you can use it just by typing help to get a list of commands that are available and then in it in the background here we have to construct some proving keys which allow the client to construct the inner proofs in our roll up once the network's synced we can see my public balance is 655 test die and i have a private balance of 30. if i look at my list of commands now i can do a lot more actions i can mint i can approve deposit withdraw transfer or register an alias let's start with a private transfer then i can transfer to one of my colleagues charlie just by typing transfer charlie the proof's generated in seconds and as soon as it's sent to the roll-up provider we can head over to the block explorer to see it being mined in the background our roll-up provider scales elastically based on the demand of transactions it will pick a roll-up size that's suitable based on the number of transactions in the queue on test nets we prefer to relay blocks more efficiently and quickly just to aid the developer experience on main net this will likely be every hour so you can see here that the block's been processed um it's currently waiting to be mined on roxton and we can go over and see the transaction as soon as this is mined the aztec sdk which powers the terminal view will update and i'll have a live update of my balance decrementing this transfer is completely private no one can see who i'm sending to or the amount that's being sent in fact if we look at the transaction itself the only state changes we can see a gibberish there's also a command to view status of transactions you can see it's still pending here on the theory while we're waiting for that to be mined oh there we go it's been mined um we can also look at um some of the use cases that are useful for d5 such as withdrawals if i want to back to layer 1 say 20 die i can specify any withdrawal address here and that withdrawal will be anonymous i think the transactions are a little bit slower to generate when uh zoom's running um but usually this takes around 10 to 15 seconds we head back to the block explorer we can see that that last block was settled and as soon as the proof sent we'll have a new transaction in the queue and when we look at the the next uh block on on either scan we will we won't be able to see um who the sender of the die was and we'll just see an anonymous withdrawal from the roll-up contract on layer one or waiting for that to be mined as a lot of your developers on the call i'm gonna head over to the documentation so all of this functionality is available today through our javascript sdk the sdk is written in typescript and it allows users to interact with the layer 2. see if this is in mind yet the docs are available at developers.
aztec.network and the docs have this unique feature of being live so you can run all code examples in browser without having to set up any testing environments run through some quick examples around social recovery the way that social recovery works in in the aztec network is we have a multiple uh key model for a user so a user is identified by an alias and then it has multiple sign-in keys when we create an account we create a throwaway keypair that's attached to the user's account but is no that is single use so no one knows the private key before the key pair is thrown away it signs a recovery signature for a trusted party that signature authorizes the trusted party to take over the account and only that trusted party that signature can then be shared amongst uh multiple services or or or or key shop key sharding services and it allows at a later date the account to be recovered to that trusted party without having to share private keys so if we look at the code here we can see we're just going to use random addresses here but this code could be if you're a wallet provider or adapt you could use a trusted address that you use to recover your users accounts or users could select their own address here to allow them to let their friends recover accounts initialize the sdk on the docs so we can interact and run this code uh the docs are also linked to the terminal view so you can see that my balance is synced in the sdk across both websites i'll just open this in a new tab you can see the transaction here waiting to be mined this is an account transaction which is different to the the joint split the more useful thing to properly run here is actually talking about the recovery data and what users get if we run this particular example um if i zoom in we can see there's a request a recovery payload here um which gives us the key that we added as our trusted third party public key um the keyword the key we've added to the account that's the throwaway key and then recovery data the recovery data here is a signature which can be used at a later date with the ad signing key method to add the trusted user into the account and give the user control of their account again should they lose one of their devices we also have um the standard methods for deposit withdrawal transfer for erc20 tokens and the network has a full emergency withdrawal feature should we disappear as a rollup provider all these functions can be run on layer one without the need for us using the emergency withdrawal method later this month we'll be expanding the network to work with d5 users will be able to swap token pairs on uniswap or invest in compound and as i said on on the earlier presentation there'll be a developer preview of noir which allows users to write their own circuits to be bundled in the roll-up i think if the last transaction has been mined we can go and have a look at the anonymous nature of these transactions so here we can see as a user the only transfer that i can see is a transfer from our contract to a user and that user has no link to the original sender of the transaction so this is true cryptographic anonymity um i think that's probably sufficient for the demo i'm happy to go over more things in the questions um but maybe it's good to take a couple of minutes um just to take some questions and run over any details that i may have missed that sounds perfect joe uh thank you so much for that amazing talk and uh i'm super excited to kind of see that uh we just found out about the blog explorer the fact that you guys are ready to uh 2020 for transactions uh that are private by default and also uh about noir uh a lot of a lot of amazing updates bundled in so we have a few questions coming in from the chat here and i'll just kind of start asking them in order and uh um for the people listening in on on the video because of the delay if you have any questions just type them up in the chat and we'll propagate them up to uh to joe but uh example clarifications that i think will be super helpful here i think the first one that we would like to kind of get a better understanding of is how do addresses work in their in aztec too are they just the same as an ethereum one address for a user uh what's different about address spaces as you think about the role of service sure so an identity in in aztec or it can be anything so it could be linked to your ethereum address and it could be derived from your ethereum signing key but it doesn't have to be so we have the concept of multiple keys per account in the current test map the keys that are available to users are on a grumpkin elliptic curve um but later in the year we'll be expanding that with our ultra plunk research to allow ethereum signatures or hardware security module signatures so i think to go back to the question um the account model is is um an account is identified by a unique id that unique id can have an associated alias so a short name such as joe and it can have any number of signing keys [Music] you also don't need to have an initial transaction to generate an account you can kind of have programmatically generated accounts that can receive funds without the user having to call the create account proof um you can just send to a unique user id and then at a later date the user could claim those funds and kind of uh make a fully formed account by adding further keys and an alias to that account and then if at any point uh they want to recover their account they can use the social recovery features to to remove keys have been lost and add in new keys awesome um another clarification that we have from the chat is can you talk a bit about what the onboarding and exiting costs are for a user and kind of how do you think about people onboarding and using the service sure so the deposit flow um for standard erc20 tokens will incur gas on on the user's kind of deposit um deposits uh fairly fast um it just basically is a single block time for our mainnet launch for tokens that support permit we'll probably do an initial um scheme where we pay the gas for deposits to help uh kind of bootstrap network liquidity um but that's still to be finalized great um the next question we have is we would like to learn a bit more about noir in general and what's possible um what are the capabilities or we have planned and features and sort of how does it differ right now from something like sync sure so inside noir this is this is a private by default language so um the programs are private uh so unless a developer wishes to expose variables as kind of public inputs to the circuit everything is private um so i think the the main difference here is um that yeah noise built with privacy at its core in terms of functionality um we have shar hashes um pedersen hashes uh blake two hashes merkel proofs of inclusion and uh non-inclusion um as well as uh some other features which are coming later in the year such as ethereum transactions um but at a high level it's uh it's kind of a very language that's very similar to rust um it's been written to be as as usable as possible um it shouldn't have uh any kind of strange symbols in it um and the idea here is that most ethereum developers can write these mini programs that can be bundled into the roll-up without kind of zero knowledge expertise that's awesome um yeah i feel like i'm personally excited to play with uh smart contract languages that are private by default so uh just to add to that um i think uh one of the other main differences is we have a standard library which is kind of bundled alongside noir so if we look at if my screens are still being shared here this is an example of uh one of our highly optimized uh implementations that comes with noir so this screen is no longer being shared but if you mind doing that we can have that up for everybody else to see uh give me one second uh so this example here um is just importing something from the aztec standard library which will be kind of audited versions of common cryptographic primitives so we're doing a charity 56 hash here so instead of developers having to go and write their own optimized versions of that we're just bundling with uh with the language highly optimized uh efficient versions of common cryptographic primitives so i think that's that's also useful for kind of keeping the complexity down and developers not having to worry about the efficiency of their their smart code because i mean in snark programming efficiency uh is measured in gate count which translates to client proof of time so you don't want users waiting for 10 or 20 seconds for long proofs when it can be a five second circuit amazing the last question that we have here is um a question kind of from for me here just to kind of better understand maybe you can spend a couple minutes on this thing this is clearly a unique approach that you presented here for how a private role ports so if you have time we'd love to understand how does this actually interface with existing default protocols that are already on mainnet and how do you think about how is it possible to bridge them whereas we look at other scaling solutions that require a different vm to exist and have a different version of those contracts over there like how does actually aztec or zkz control ups enable that to be a lot more seamless and kind of how are you getting the the unit swap and the company integration baked into the role of service sure so um with with the november upgrade we're we're taking kind of uh a layer one approach i would say um we're gonna batch transactions in the roll-up um and we'll kind of as a group relay those trades back to uni swap and there's there's some discussion here around kind of minor extractable value um but the initial approach we're taking is instead of having to port an entire d5 protocol to layer 2 which comes with its own audit risks and uh kind of just security risks we're gonna for very liquid markets um i think you can quite easily um allow users to bundle trades together um inside a roll-up and have them all executed at once um and yes there'll be some slippage in that but uh for smaller notionals um the trade-off between gas price and slippage for kind of end users is uh pretty worth it in our case if you're a larger kind of devi trader you can always decide to pay the layer one fees and go back to mainnet but for smaller kind of consumer users and kind of bringing this to mainstream um for notions kind of around 10k the slippage versus gas price that we think we can get uh should be sufficient amazing um i'm personally excited about 5000 gas cost transactions i'm sure others are too here so uh joe want to thank you for doing this presentation and showing us a really cool demo of a private roll-up service that's already available for people to test out
Automatic transcript — names and jargon may be misspelled.