 All right, so my name is Wei Dai. I'm a research partner at Bankabre Crypto. We're a VC fund crypto native. Anyways, OK, so what I'm going to talk about today is not about zero-knowledge proofs. And let me open by a question. Raise your hand if you think zero-knowledge solved all the privacy problems in the blockchain space. I see one hand. I see two, three. All right, well, if you didn't raise your hands, maybe you know better than I do. But I don't think zero-knowledge solved all the privacy problems, so let me explain why. So let's think about blockchains. So what are blockchains and applications? Everything is a computation of a blockchain. So Ethereum is a public state machine that's replicated via some consensus mechanism. And so what is a state machine? A state machine is something that keeps the states and has some transition function. And transition states do transition function. And what can be thought of as state machines? Blockchains is smart contracts. So everything on Ethereum, all the smart contracts are state machines. OK, what if we want to do state machine transitions with privacy? Well, let's try to use zero-knowledge. How are we going to execute a state machine zero-knowledge? Well, we're going to execute the off-chain and only prove the execution that is correct on chain. So I'm not going to show you the details here, but, more or less, it's going to look like this picture, where every single state is a different color, and your zero-knowledge update is going to essentially link one color to another color. So here, on chain, we'll have three different states. And suppose that a user want to interact with a state machine, and they each independently generate a different proof, linking state two to some state three. Now, if one proof is processed on chain, let's say the left one, the blue one here, what happens is that the second transaction of the second user is now invalid. Because the proof is going from the same state two, but now it needs to link to state three. So that's the problem with executing general state machines in zero-knowledge off-chain. You run into risk conditions. OK, so this problem has actually been observed over the years in many different ways. But basically, the story is that either you do a transparent on-chain computation that we do on Ethereum. So you have no privacy, but you have the benefit of a shared state that everybody can have access to. Or on the other hand, you have a zero-knowledge off-chain execution. And you can have the flipped benefits and downsides, which is that you have private inputs, but to state that's not shared between anyone. So we're basically somewhat like us with these two properties, so we can really get both. And my talk is about how to get both properties. And I call that confidential shared state. So how do we get confidential shared states on a off-chain? And the answer is fully homomorphic encryption, or FHE for short. OK, so what is homomorphic encryption? This is a brief intro to cryptography. So this thing here is kind of a commutative diagram, OK? So suppose there's a message and fix a circuit C here. We can compute the circuit and a message to get C of m. So that's this arrow over here, OK? FHE scheme allows you to kind of do this thing but with three different steps, OK? So first, let's take our message. Instead of computing the function, we're going to encrypt it, OK? So everything that's down here is encrypted. You cannot see what's inside, right? So this is what kind of goes through in your TLS channels and stuff like that, right? You first encrypt it, and then you kind of run this evaluation function, which takes in the circuit, right? And this step for text to get another step for text, OK? What have we done here? Well, we haven't really done anything useful, right? But let's actually try to decrypt this thing again, right? A FHE scheme allows you to essentially, so if you decrypt this, and this thing's actually works, it means that you actually get back the result of computation, OK? So what have we done here? Instead of doing computation in a clear, we can first encrypt, do the computation, and then decrypt, OK? So this thing is really sick, right? Because it allows you to do computation encrypted data. It's like the holy grail of computing and privacy, right? So this thing has been discussed ever since the 80s. But recently, only within the past about 15 years do we know constructions of this thing, OK? So there's still a single point of failure here, which is the decryption key, right? So that anyone holds a decryption key can get the data. So the idea is we're going to move everything on chain to be encrypted stuff, right? But we don't want a single person to be able to decrypt. So what do we do? We add threshold cryptography. We're going to secret share the decryption key to every single validator, OK? So now we're going to have to guarantee that you can only reconstruct what's inside if k out of the n validators say so, OK? All right, so what can we do with that with such a threshold FHG scheme? It turns out we can basically do confidential state machine replication on chain and release any information that we want to the public. So let me kind of wrap up by telling you about the work of Peska. So Peska is short for privacy-enhancing smart contract architecture, which is kind of a blueprint to unify the three types of computation, right? So we have transparent on-chain computation, zero-knowledge off-chain computation, and this on-chain replicated computation. Peska is a framework that tries to unite the three things, putting the three together. So very briefly on what kind of what the challenge is here. So the challenge is that if you want to make this in practical, you have to really, really think about efficiency. So it turns out FHG is really, really slow and is way slower than ZK even. So you want to push computation to zero-knowledge as much as possible while doing the bare minimum amount of shared computation in FHG, OK? And I'm going to kind of connect these two components using the actual decryption. So is it going to look like this? We're on the left-hand side, we'll have some type of ZK-shorted pool, which is really standard. We're going to also use zero-knowledge to kind of encode inputs into this FHG computation module on-chain. And then we're going to decrypt stuff and then put it back into the sort of pool. So this is actually inspired by the Pernumber state model. I encourage you to kind of look it up. It's actually one of the cooler projects that's being implemented right now that's a private tax. OK, anyways. And in the work, we also extend this to two simple applications, one of which is essentially a dark pool, a privacy-preserving constant-function market maker. And the other one is a first-priced privacy-preserving auction. OK, so let me end by a short conclusion, which is, what are the three points I'm going to talk about today? Privacy is really important in blockchain space. And zero-knowledge is not a full solution. And to get confidential shared states, we need something that's fancier. And in this talk, I presented one option using FHG. And I encourage you to try to go to work on PESCA. And the link to the paper is in this QR code. Anyone that didn't raise their hand? Everybody understood that. Or there you can tag with Wei after the talk. Thank you so much, Wei, once again.