 So if you put disclaimers, if you come to see this talk, we really hope you have familiarity with zero-knowledge proofs, homomorphic encryption commitments, and we're really hoping to provide as unbiased of a discussion as possible here. You feel like we're not doing a good job of that. And please feel free to call us out. So what is a privacy-preserving smart contract? There's a few different components and properties and privacy-preserving smart contracts that we're going to go over and what exactly what defines them. In our case, privacy is defined by two properties, confidentiality and anonymity. And what we define privacy as, in this case, the confidentiality is when we can hide the input and the outputs of that state machines program. So for example, like in a slow-down smart contract, we all know that the inputs are not private. Everybody can see them, as well as they are also not anonymous. The inputs are not confidential. And also, they don't hide the users involved in that computation. So we have two properties that we're defining. That is confidentiality. So that's the bare minimum, which is inputs are hidden. And then anonymity would be a more complete solution, where it implies confidentiality. You're probably familiar with some of the use cases for smart contracts, in case you didn't know. Smart contracts are also a form of private transactions. So a Bitcoin transaction is a smart contract, to some extent. So in the case of private transactions, there are a few implementations of these. Zcash, Venero, and two major ones. Private voting is another use case, where people actually need to have some privacy, some degree of maybe even anonymity, when they vote to cast ballots. As well as auctions, there's a really big market for blind auctions. And keeping to who's paying for what, and how much they're paying private. Moving on. So what are some considerations for privacy preserving smart contracts? In our talk, we're mainly going to focus on transaction privacy. And the reason why is because transaction privacy is a small subset problem of privacy preserving smart contracts. And the cool thing about transactions is that when you make them private, you can actually sometimes generalize these into more broad definitions of smart contracts. So we can actually make them do more computations that aren't just transactions, but maybe involve whole state machines and whole execution. We'll be getting more into that later. So we believe there are four main considerations that go into actually developing a privacy preserving smart contract. So we've separated these out into efficiency, privacy, security, and functionality. Within each of these, there's a lot of complexities. So in efficiency, you can ask yourself, how long does it take to actually generate the transaction? What about verifying the transaction? What is the actual communication complexity? Set up strength size. Set up time, reference strength size. What are the hardware resources required? Some zero-nautristic systems do have a lot of hardware resources required and they tend to gloss over that aspect. And how does it actually scale? With privacy, as we mentioned before, can we provide confidentiality or anonymity? And is the privacy based on cryptographic techniques? So do we have some provable form of privacy? Or are we using other techniques such as tumblers for anonymity or stealth addresses? Security has similar considerations. Is the security based on cryptography? Do we have provable security or is security based on non-cryptographic techniques? We can look at trusted setup. We also have to consider non-standard cryptographic assumptions such as using the algebraic re-model, knowledge of exponent, which are slightly non-standard. And we have to consider what kind of adversary is our scheme actually secured against. A post-quantum one, a semi-malicious one. And then finally, and arguably to us, the most important consideration is functionality. When you're talking about developing PPSC, can you actually adapt your scheme to new settings? Is it possible to really express any arbitrary computation with your scheme? And more importantly, is there support for stateful computations like Ethereum? So that leads us into what we believe are the four definitions for these qualities. For efficiency, in the ideal world, it should be quick to generate and verify transactions. Setup should be fast. There should be a small community. It should be efficient when scaling, and minimal hardware resources are required. With privacy, we should be able to get anonymity, not just confidentiality. It should be based solely on cryptography. Security is similar. It should be based solely on cryptography. We do not want to use a trusted setup, both for security and functionality reasons. And it should be secure against strong adversaries. We've left this deliberately ambiguous because it depends what you can achieve in your scheme. And finally, for functionality, we should be able to check off all three boxes that we just saw. We want it to be easy to adapt to new settings. We should be able to express any kind of program with our scheme. And finally, it should support stateful computations. So how do we actually achieve these four characteristics? We're gonna focus exclusively on the cryptographic techniques because we believe in provable security and privacy. The first one we're gonna look at is of course zero knowledge proofs. And there are three main schemes that everyone's familiar with, Snarks, Starks, and Bulletproofs. So for Snarks, they have trusted setup. However, that allows us to get the smallest proof sizes out of the three and the fastest verification possible. But they also use a slightly non-standard cryptographic assumption, which is knowledge of exponent. Starks are arguably an improvement on Snarks in that they have no trusted setup and they use a much better understood hardness assumption of hash functions. But that comes at the cost of incredibly large proof sizes compared to the other two. And some expensive hardware is needed in the form of extra RAM to actually get the efficiency they talk about. Finding the Bulletproofs, they fall somewhere in between the two. There is no trusted setup, which is fantastic. They have moderate proof sizes, but they have some of the worst verification times. However, they can be improved when batching them together. And they're based on well understood hardness assumptions using discrete blocks. So if we look at the three and see how they compare in terms of the four qualities, we've ignored privacy because arguably all zero knowledge proof systems better could provide confidentiality. In terms of efficiency, Snarks come out ahead with the smallest proof sizes and the fastest verification. However, due to their trusted setup, their functionalities impacted a lot. It's very difficult to port the scheme into new settings. Snarks have very poor efficiency as you see because they need additional hardware resources and they have absolutely giant proof sizes. But they do very well in security and functionality as do Bulletproofs and Bulletproofs fall somewhere in between the two. So that leads us into the next building block that Texas is going to tell us about. So the next one is that is called multi-party computation. Something I'm probably sure a lot of you are already familiar with in the form of secret sharing schemes such as severe secret sharing. So multi-party computation is a type of privacy preserving computation technique which allows us to secure the inputs to some predetermined program. And we have multiple parties who collaborate together and work together to execute this program. And in the output, they should have a private output that only the person who requested that computation should know. Like I said, one of these examples should be a secret sharing which you're all probably familiar with in the case of wallets and how to split up your wallets and shadows. So maybe this is the most predominant issue that everybody should understand when we're talking about multi-party computation is how interactive it is. It is incredibly interactive depending on the number of parties you have. So anything more than usually two or three participants we start seeing some really massive problems. And for many other protocols that requires something like zero knowledge proofs to keep the protocol actually fair. So what that means essentially is we have like complexity layers in our NPC protocols. Like the very first layer we can imagine the network. So all of our participants have to communicate with each other, but we start having similar problems like traffic. You know, when you get in a traffic jam, the first person in the front of the traffic jam steps on the brakes, which causes everybody else to step on the brakes as well. So we start seeing network waitants seem to filter through the entire and propagate through the entire network like that. And it causes massive problems, especially when a lot of communication is required for more complex things like we can imagine for it in privacy preserving smart contract. Another thing is that it has game theoretic security sometimes where we may require an honest majority. And to keep things fair, we require another layer of complexity like that's most like multi-zero knowledge proofs where we start having to integrate proofs to ensure that everybody is acting appropriately. And if we start doing this, now we're talking about a very complex and long protocol. So on our next slide, we'll be talking about some implementations of privacy preserving smart contracts. So two of the most recent approaches that are based on Ethereum are Aztec and Caesar. Both of them allow us to perform confidential transactions on Ethereum. Aztec uses a UTXO model, whereas Zether uses an account-based model. Both of them, in theory, are able to achieve anonymity. However, Aztec uses stealth addresses, which doesn't really satisfy the cryptographic definition of privacy we want. Zether does do bring signatures. However, it's too expensive to implement on Ethereum as is. Zether is a lot more mathematically sophisticated. It comes from the same authors of bulletproofs and utilizes commitment schemes, algomall encryptions, and it actually combines bulletproofs and signature protocols into something called signal bullets. Aztec is significantly simpler, but they use a trusted setup. They're a lot more efficient than Zether, and they just rely exclusively on commitment schemes and signal protocols to achieve this. So what do Zether and Aztec have in common? When we're talking about they both use algomall encryption, what they're actually easily utilizing is a property called additively homomorphic encryption or even commitment schemes. So what does it mean to be additively homomorphic? When we have two, we'll talk about different types of homomorphisms, but in the case of additively homomorphism, we can imagine that we have an encryption of some of a value a and an encryption of a value b. And if we take these two cybertexts and perform an addition operation on the two cybertexts, we actually get the encryption of what would be the output if you had just added the two plaintexts together except they're now encrypted. So how this is built around to build actual confidential transactions is we have an encryption of a balance, say the number three, and then we have an encryption of a transfer amount, say a number like negative two. You're sending two coins to somebody. So when you take your encrypted balance of three and your encrypted transfer of negative two, you add it together and you get one. So that'll be the encryption of the balance after that transaction in general. So it essentially lets you, and additively homomorphism is simply a way to map between these two domains. We have the plaintext domain where we're all familiar with just doing simple addition on things and the encrypted and cybertext domain where we don't normally see what the value is underneath but we know it's some value. And the additive homomorphism is simply an operation, an addition operation that lets us calculate what that value would be in the plaintext space. So you can simply add cybertext together to get their plaintext output. So. That leads us into a fully homomorphic encryption, which that's all I'm talking about. As we just saw, some schemes do utilize homomorphic addition to perform confidential transactions. If you actually extend that and consider homomorphic multiplication, which means that the encryption of A times the encryption of B is the same as first multiplying A and B together and then encrypting it. So what might happen if we were to create a PPS scheme that doesn't only just do homomorphic addition but also does homomorphic multiplication? That would actually give us something that performs fully homomorphic encryption. There hasn't been any PPSC scheme that does fully homomorphic encryption so far but it might be interesting to consider how much more power we would get from including this in such a scheme. We're gonna quickly look at two non-aerium approaches. One is ZXE, which uses the UTXO-like model. They use DK-SNARCs for performing confidential transactions. And they actually have an even stronger notion of privacy than the one you define. In addition to hiding the inputs and outputs of a function, they also discuss hiding the function itself. So what we can call the function privacy. However, to achieve the efficiency that they're talking about, it's also an expensive scheme in the sense that you need hundreds of gigabytes of RAM to get the proving times you're talking about. And there's a second one from OASIS Labs. You don't actually know what their pronoun's the name, so we're just gonna refer to it as the project from OASIS Labs. They use trusted hardware, which does not satisfy our notions of security and privacy with cryptography, so we're just gonna gloss over their work but they're also in this space for everything. So briefly we'll talk about some comparisons between the technology. So it's really difficult to actually compare these technologies because they all accomplish similar things with different techniques and they're just not really that easy to compare together directly, but they do satisfy some properties we can discuss, such as performance, privacy, the interactivity involved and the cryptographic security used. So for fully homomorphic encryption, it is entirely compute bound. So the performance is basically built on is on the, just depends on how well your computer can actually perform these really intense operations, such as FFT. Privacy is also based on the encryption scheme, which if you're familiar with any cryptographic security assumptions, I mean, standards, we can say that usually just assume that it's IND CPA secured. It is non-interactive, meaning that you don't have to interact with a bunch of people who perform this computation. You only need to go to the computing party and encrypt some data, give them a key and they can usually perform the computation on it. And it also satisfies some cryptographic security as well. So we know that when we do a fully homomorphic encryption, we know that it's going to satisfy a mathematically hard problem that's not easy to solve. And like I said, your VC is network bound and it becomes an issue when you have more and more participants in it. It's based on an encryption scheme and not a collusion of that through the privacy. So for Schmuir signature sharing, you're pretty much assuming that your friends won't get together and try to screw you over. It is interactive, so it doesn't satisfy that. And the cryptographic security is somewhat similar that it requires, usually it has some fairness assumptions that requires usually some zero knowledge groups to actually do it. Trust hardware is kind of, you know, almost straight in my opinion. It's just based on hardware security, which you've been paying attention to the space recently. You know, we have spec inspector meltdown, speculative execution attacks. Then like we've been trying for years to make secure processors and they're not working out that well. So it's time, the advancements that it's going to take to make secure processors a real secure thing is much longer than it will be to take these theoretical advancements to improve either FH or NPC. So let's just move on and do actual provable security and not just deal with the stuff that kind of but doesn't work. So that, I have a lot of feelings on trusted hardware. So I can just look at some of the privacy preserving smart contract approaches so far. We've already seen Zeefer and it really optimizes for security in a provable sense. We've frequently seen Aztec, but arguably they're not a PPSC scheme. They're just trying to form confidential transactions. They really optimize for efficiency. Zexi does a fantastic job optimizing privacy and HOP, which we haven't really mentioned but is a lesser known project in Zcash. It doesn't really do a good job with any of them. However, the most important thing to focus on is that none of the approaches so far has actually tried to optimize for functionality. So it might be interesting to consider what happens if we pick a PPSC scheme? What happens if we pick a PPSC scheme that optimizes for security, privacy and functionality and gives a little for efficiency and compromises a little there instead. And for everyone else in the room that might not care so much about that, when you're developing your own PPSCs, you should really look back at the chart and consider which of the four properties you've seen do you really want to optimize for. So that's it. Thank you so much. 30 seconds. Yeah, one question. Yes. Could you explain why you consider bulletproof more secure than Starks and Starks more secure than Snarks? So I don't believe I said that bulletproofs are more secure than Starks. I think it's in there with dots. Let's go back to the slide. Slide. Do you think you missed it? No, I pressed the button at the time. So I didn't. You did? Thank you. Starks are more secure than Starks, in your opinion. I do think Starks are more secure than Starks. I don't really agree with trusted setups. Security can be compromised if the parties glue together. And I think knowledge of exponent is a non-standard assumption that's not well understood. So I personally, as a cryptographer, wouldn't feel comfortable using it. Other people might feel differently. But according to my definition, I think Starks are a little less secure than Starks and Bulletproofs. And why bulletproofs? Bulletproofs are based on discrete log and the discrete log problem. And that's a very well understood cryptography assumption that's been around for a long time. Yeah, but bulletproofs are based on discrete log only if you make them interactive, right? Make them non-interactive. You require a random oracle, the same as Starks, right? Yes. And a random oracle is a security point of view equivalent to knowledge of Starks. If that's true, I agree random oracle is a slightly non-standard cryptographic assumption. And a lot of things use that. If you want to advert or a pre-non-interactive, you almost always need the option here. You're going to get a random oracle out. So it depends, person to person, what you feel most comfortable with. I think this is just an opinion. And I understand that other people maybe not don't feel so comfortable with random oracles and don't want to use that in their own scheme. For many cryptographic use cases, it would be better for us to utilize things. It's great that people want to utilize knowledge and honestly help us find and understand it more as people implement it. But for many use cases where we want to build for the long term in the future, we want to use stuff that we know and understand very, very well now, which is the random oracle model, which is the discrete log problem as well. So I would also agree that knowledge of exponent is not very well understood as either discrete log or random oracle model. It's been around the same time as discrete log and random. I don't think it's been as well studied. I would argue it's not been as well studied and used quite as much to have as good of an understanding. But I'm happy to talk to you about this afterwards if you're still interested. And even setting aside the hardness metric, obviously the trust set up, the trust process loses, starts one of the dots. Yeah, but the trust set up was far called that functionality. That's also part of security, at least to us. That's part of security. Yeah, there. Yeah, but I think we can also argue that using the question here, I'm not good at a number of rounds. It also cannot be used in much, very well thought. So the other person comes on the system anyway, because seriously, it's going to be used very quickly in the minority, but currently, number of rounds, which is easy to see your written letters in this term. So I think we're not going to use any other number of interactions in the interactive part of the project. If you want to interact with it, you need to use Ketchum here. But it's actually an instant effect. So people may just enjoy it. I haven't seen any more of that. Cool. Thanks.