An Introduction to Privacy on Ethereum with Arnaud Schenk

Um, cool. My name is Arno. I am Tech Lead at Aztec. Aztec is a privacy protocol on Ethereum. We are really focused on integrating data protection as simply as possible and adding it to DAPs and exchanges and all those things.

Um, before we begin, we have a Discord server where you can ask any questions. We also have a channel on the ETH Waterlue Discord. So you are welcome to either join our own Discord or simply post on EtherLure or on one of the two channels. We will be awarding prizes. We will therefore award $1,000 for the best overall use of Aztec .

Um, and we'll be awarding another $500 for the most surprising use of Aztec. There is a complete disclaimer stating a complete disclaimer stating that we may divide these prizes differently at any time, depending on the number of entries. Um, and we might decide to spend more money than we already have or than we planned . Um, yes. Um, yes, as I said, I'm Arno.

This is Leila and this is Charlie. Um, we're here for you all weekend if you have any questions about Aztec in particular or data protection in general. Please come there. We've only just begun. Um, yes, please, please come and talk to us.

Um, we really enjoy talking about everything related to data protection . The most important question we started with at the beginning of Aztec was probably why data privacy is important was probably why data privacy is important . I think that's not a question most people give too much thought to. I prefer to consider it hypothetical. Does the cashier at your supermarket know how much you earn each month?

Does your boss know how much you save each month ? Could he use that to reduce your salary? Because if you're being paid in cryptocurrencies, they'll definitely do it. I think that's what most people underestimate with the mass adoption of cryptocurrencies: it's not just government surveillance that justifies privacy. It's simply surveillance of any kind.

For example, it's possible that your colleagues could say: "I'm being paid less than my colleague for the same work." For example, it's possible that your cashier might say that you don't earn much in your current position, or whatever. It's really just surveillance of any kind, which I think will be a major obstacle to its widespread adoption . The problem, however, is that data protection is quite difficult for both users and developers . For users, data protection usually means strange UX processes.

Normally , it means keeping secrets. For example, if you have ever used Tornado Cache or any other type of mixer , you need to keep track of this long string of characters, which you must not lose, or you will lose your money. This means you have to wait for zero-knowledge proofs to be created, and sometimes this means waiting half an hour to an hour for these zero-knowledge proofs to be created. For developers, this means that it is quite difficult and prone to errors. If you make a mistake, your users could basically lose all their money.

This involves quite high overhead costs. If someone has heard about trusted setups or simply about the complexity of auditing zero-knowledge code, it's not exactly pleasant. Feel free to come by, or don't. His loss. We believe that data protection should be quite simple .

And we believe that many of these costs, such as trusted setups and complex checks, should be handled by data protection protocols for developers . What we create and produce is a verified protocol. No application-specific trust is established, and I can explain in more detail what that means at the end. And fairly high-level APIs means at the end. And fairly high-level APIs to make the joint process quite simple.

So we are creating a toolbox with plug-and-play zero-knowledge proofs. You can integrate them directly into DAPs . You can create DAPs around these knowledge assets. These knowledge records are designed to be used interoperably in DAPs. Something that people don't really think about or haven't considered is that when you create something with conventional ZK snarks, due to their nature it is very difficult to make two circuits that are slightly different compatible.

So, if you create an ERC20 replication in Zero Knowledge and an ERC721 replication in Zero Knowledge, it's quite difficult to get these two things to work together. We believe work together. We believe that interoperability in this area is fundamental. And gas efficiency. A private transaction to Istanbul costs approximately 200,000 gas.

We hope to be able to make it cheaper over time. We have worked hard to make Aztec as easy as possible for developers to use. I'll now briefly show you what we 've developed and how you can use it this weekend. Over the past few weeks, we have been working on our SDK , which you can add to your DAP with just one line of JavaScript . It basically offers everything you need for client-side use of Zero Knowledge use of Zero Knowledge .

This basically allows you to turn any ERC20 into a zero-knowledge asset . You can send this asset around , you can make it public again, and you can use more complex evidence, for example, to create evidence example, to create evidence that some zero-knowledge nodes are larger or smaller than public or private amounts. You can mint ZK assets like ERC20s and prove that an asset note or zero-knowledge note is a percentage of other notes. The types of flows other notes. The types of flows you can create with it include, for example, the latest Proof of Collateralization, all in Zero Knowledge.

You can create a DAP that is only a payment DAP that is only a payment DAP . For example, you could say: “ . For example, you could say: “ I will pay you to drive me from Toronto to Waterloo, but before I accept your proposal for this journey, you must prove to me that you have enough money to pay me after the journey.” But of course, you don't want the person who will be driving you to have easy access to all your financial data. So you can easily prove that you have $100 without having to show the world how much money you have on the blockchain in total.

We have worked hard to make this as easy as possible. You do not need to use a domain-specific language like Zucratis or similar to use Aztec. It is literally a smart contract call literally a smart contract call . You provide the verification data that our client-side code delivers to you our client-side code delivers to you . This gives you back an instruction object that you can easily use directly in your smart contracts.

Um, so if you have a proof, um, that says, for example, "I'm going to transfer some zero-knowledge assets to you, transfer some zero-knowledge assets to you, " the set of commands you get back is: Create these notes get back is: Create these notes , destroy these notes, deliver them to these addresses, um, where you can add your own custom logic, for example, the user whitelist. There are no special secrets to keep in mind ; This is all abstracted by the SDK , um. The evidence gathering process takes about 10 milliseconds, which basically happens instantly. And again basically happens instantly. And again , the low gas costs, um, after instant settlement, mean that this type of private transaction is feasible for users on Ethereum for the first time.

Hello. Um, yes, so it's pretty easy to get started. The SDK I was talking about comes with documentation that walks you through a starter kit, basically showing you everything you need to get started with zero-knowledge transactions on Ethereum. The Cure code will lead you there. Even this small CC URL.

And we also have a full specification for our protocol that you can go through to create your own smart contracts, create your own client-side code, and build zero-knowledge DAPs. The kind of things we 've seen in the past, to give you an idea, are all from Z DAO, where every vote is conducted in Zero Knowledge, which helps protect against both corruption and collusion. Even down to things like providing proof of identity in all zero-knowledge confirmations. The idea is that you can prove to institutions on the blockchain that you have attended a certain university, that you are of a certain age, that you have a certain net worth . These people can only offer you services if you can prove such facts, but they do not have access to the underlying data.

And finally, an alpha demo. I'll simply show you how user interaction with the SDK works, from account creation to sending money . All of this will run on Ringb . So I can't promise any speed. That's simply due to the Ringbi network.

And then I'll gladly answer any questions. Are there any privacy concerns regarding Ethereum while I'm setting it up? Or regarding data protection in general. Go ahead. OK.

Zero Knowledge is generally the idea of ​​being able to prove a statement without revealing the inputs for that statement . For example, you can say: "I'll transfer some money to you." I am creating a transaction, which in our world is a UTXO transaction. Similar to Bitcoin, where there Similar to Bitcoin, where there are input and output nodes, and the transaction should proceed in such a way that the input nodes are identical to the output nodes . Therefore, it is not possible to make double payments or anything like that.

The inputs for the transactions therefore correspond to the outputs. To do this, one must be able to prove that the value of all notes summed on the input and output sides is identical. With Bitcoin, for example, it's very simple because everything consists of whole numbers, right? So, you can simply say that 10 + 4 equals 8 + 6, right? It's the same thing.

When trying to do something with zero knowledge, one wants to be able to say that this encrypted number plus this encrypted number equals this encrypted number plus this one plus that other encrypted number other encrypted number . And that's exactly what zero-knowledge proofs are. Essentially, it's about the idea of creating statements or evidence that one possesses private information and that this private information is subject to either a specific program or equation, without revealing the actual inputs for these things. Does that answer your question? So yes, it is basically possible to maintain privacy, for example, without compromising consensus.

Therefore, every transaction in Bitcoin or every transaction in Ethereum can be designed so that all inputs are completely private that all inputs are completely private , but still have the strong guarantees of the blockchain issue. Yes . I believe I heard you mention the UTXO-based platform . Correct. Yes, exactly.

UTXOs therefore have some advantages when it comes to privacy. And when you make a transfer, you can essentially convert an ERC20 into an Aztec Zero Knowledge Asset. And in this world, the main difference is basically that your balance isn't a balance at all, but a series of UTXOs where everything is fine. Part of the reason is that your account balance doesn't exist , since it's not an account- based model, and since it's a UTXO-based model , you actually have to keep track of several different objects when working with Aztec. And our SDK – the purpose of the SDK is to abstract all of this for both the developer and the user.

Sorry, I may have to apologize for giving demos that messed up the demo script . And the SDK—I'll show you the methods— SDK—I'll show you the methods— basically allows you to make deposits, sends, and all those things without the developer or user having to worry about UTXO . Because, as I said at the beginning, we believe that we need to make data protection as simple as possible. And that also means we have to get rid of things that are technically very advantageous, but fundamentally impair the user- friendliness of data protection . Hopefully, sorry, it's currently loading a JavaScript bundle over the conference Wi-Fi.

I'm not sure if the demo gods are on my side. Lea, do you have one that runs on ganache? What else do you think? Yes . The output key for these UTXO objects is always your private Ethereum key.

So you don't have a separate account for Aztec transactions. What you do have, however, is a so-called display key for each note . With this display key you can see the value of the notes and it is an input for proof building and such things and it is generated via a kind , not a kind, but via the Diff-Defy-Element-K exchange. You can therefore always generate it if you know the recipients and the sender of the note. Yes .

Basically, this is how one thinks about it in this first version of Aztec . Can you imagine that behind it lies this secret, this shared secret, this key to understanding? It simply needs to be a fairly large random number that adds something called Bonaban signatures, namely randomness. So we don't use ZK-Snarks, which was possible before universal ZK-Snarks. Before the introduction of universal ZK snarks, we could basically have a Zer system with only one trust setup where everything is compatible.

It's easy to trade assets with each other, etc. But for that, we needed these signature objects, called Bonaban signatures . And in order to effectively use these bundle signatures without revealing which ones are in a list, you have to add randomness to each one, and this is where the viewing key comes into play. You'll probably need to install a few things . A few things will appear, and you'll need to install them.

Yeah right. The SDK basically consists of a series of pieces of evidence. We have a total of seven pieces of evidence that you can use to create custom workflows. There are some of them that most users are unlikely to interact with . The SDK offers a truly simple API for most use cases , meaning you don't have to deal with UTXOs.

You don't need to deal with nodes or anything like that , and you'll get access to extended evidence when you need it. But basically, the SDK is more about abstracting the ETXO model than anything else. And then you can break out of this model if you want to create custom evidence. Yes . So if I go back, oh, actually I'm not showing the presentation anymore, but for example in the SDK, deposit, send, withdrawal, since the parameters in these proofs are fairly standardized, I think we'll get help shortly.

Um, we were basically able to abstract many of the options that are normally used in constructing a proof . Um, you have to . Um, you have to click "Allow", I think. Sorry I had to change laptops immediately. Um, so basically you have simplified parameters, like for deposits and withdrawals.

Um, if you want to do something like a scope verification , you'll need to break out of the SDK a little bit there. They are going into some advanced evidence and, uh, the SDK will still help you access the notes you need to use in this area evidence, for example. Um, but the parameters are a bit more advanced. Cool. Um, so this is part of the demo-demo scripts.

Um, the ones we uh, that are contained in the documents . Um, so basically it's a two-line run you can have to get access to the SDK in its current form . Um, and uh, as I said, it 's uh, alpha software. So, don't use this in production if you have any idea about it, but if we give the Wi-Fi some patience... So, what Leila is doing right now is adjusting some settings.

So it's just the starter kit. It will provide an ERC20 coin that you can mint. This is just a standard ERC 20. Then a ZK asset is provided, which is the zero-knowledge version of the ERC20. It has confidential authorization, confidential referral, confidential transfer from.

And once that's set up, you'll basically see various proofs available for deposits, withdrawals, and sending. There is currently a balance of 200 in the ERC20 public token. The first thing we will do is convert some of this credit into private assets credit into private assets . So if we say we are depositing 50, we will essentially create five bills that add up to a total of 50. Uh, and you 'll see the truth.

From a user's perspective, a deposit into the zero-knowledge world is just this small pop-up SDK. This does not include safekeeping of your public assets. This merely abstracts these notes. MetaMask is still your custody provider. You still have all your assets there.

You still have your private key there. You never have to export it. And as I should have highlighted in this sequence, but it was fast enough to miss: you are creating a zero-knowledge proof. They send this proof to Ganache, and it is validated by what we call ACE . Then the instructions in this instruction set I was talking about are sent back to the ZK asset , and the Z asset decides what to do.

The address 0x E207 now has a private account balance of 50. If you go to the network where this is happening, you will know that 50 have been deposited. Since this is the first transaction, these 50 can now be sent to any Ethereum address . However, they do not know how much each note is worth. Basically, this person can then return all the grades they receive to the public if they wish.

But here too, the following applies: You will not know the amounts sent during the transactions themselves , unless there is a conversion back into public view. Correct. Yes. The first version of Aztec only deals with amounts. We released something called Plunk about a month ago .

One of the major design constraints we faced at the beginning was that the design had to be fast enough so that the user essentially wouldn't notice it, and secondly, interoperability had to be ensured. So basically everything from Gross 16 was simply thrown out the window . Um, and that was the reason why we didn't use Snarks from the beginning . But with Universal Snarks, the next version of the proofs we are now providing, it will basically be the same protocol , only new proofs, um, we will be adding a non-MIDI option. So, in this world, you basically have complete privacy.

Right now, only the amounts are being hidden. So yes, hopefully the documents will explain to you how you can do it better than I could. Effectively, you are adding the following to your DAP: privacy. So if you want to create a DAP with a private flow , it's literally one line of JavaScript and a few pre-provided contracts on Ganache, easily handled by the starter kit , and you can effectively leverage privacy. Cool.

Um, I said at the beginning that my presentation would be short and to the point. Um, and that's what I meant. Um, it was a short and concise presentation. Um, that's a bit of a tricky thing, because it's slightly different from the things you've dealt with if you've built on Ethereum before , it's... B.

no account-based model. It's based on zero knowledge and all that kind of stuff. The best way to familiarize yourself with it is simply to play around with it. Um, I think we've hopefully made it as easy as possible for you to just play around with, but um, if you have any questions, if you're not sure how to proceed, um, we'll be hanging out here all weekend. Um, we 'll try to wear these same hoodies this weekend , but they might get dirty .

Um, so try to memorize our faces as best you can. Um, otherwise just message us on Discord. Cool. Any last questions before I let the next person have their turn? Then I take that as a compliment for my clarity.

Good morning, everyone.