Anna Rose (00:05): Welcome to zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. Anna Rose (00:27): This week, I chat with Wanseob Lim an applied developer in the privacy and scaling exploration team at the Ethereum Foundation. He's also one of the authors of the Zkopru protocol in our conversation. We explore Zkopru and how it uses optimistic rollups and ZK proofs to create an optimistic private L2. But before we start in, I wanna say hello to all new subscribers and welcome. This is a new year for the ZK Podcast, and it's actually the start of our fifth year as a weekly show. There are a lot of exciting events and initiatives on the horizon, and sometimes it's a little hard track. I try to mention as much as I can at the beginning of each episode, but if you do wanna keep track of what's going on be sure to join some of our channels, maybe follow us on Twitter. Definitely subscribe to the show, wherever you do, get your podcast. Here are some additional highlight channels you might wanna check out. We have a telegram group it's currently on fire. Some of the best ZK researchers in the space are debating all of these really cool kind of nuances of different protocols. It's definitely worth checking out. There's also the ZK community board. This is where we can actually do kind of deeper dives into the research in the space. There's also a ZK jobs board. So if you are looking to jump into the space professionally, that's where a lot of ZK teams are actually posting their jobs. It would be a great place for you to start on your job searching journey. So we're shaking up the format a little bit and starting this month, I'll be inviting my producer, Tanya, to start reading the ads for the show we realized when she was a guest on the ZK Hack wrap up episode last month, that she has a fantastic voice for podcasting and that we should definitely use this for our show. So I wanna say hi, Tanya, and yeah. So tell us a little bit about this week's sponsor. Tanya (02:10): So for this week's sponsor, we wanna thank our friends over at Aztec. Aztec aims to be the privacy layer for Ethereum. They believe that unlocking programmable privacy is the next frontier for blockchains. Aztec is also the first zero knowledge rollup built from the ground up for anonymous payments and DeFi transactions. You can already start sending funds privately on ZK.money, that's zk dot money. So thanks again, Aztec and back to you, Anna. Anna Rose (02:36): Cool. So now here's our episode all about Zkopru. Today I'm here with Wansoeb Lim, an applied ZKP developer, who is part of the privacy and scaling exploration team at the EF. He's one of the authors of the Zkopru protocol Wanseob, welcome to the show. Wanseob Lim (03:22): Thank you so much. Thank you so much for having me on the show. Anna Rose (03:26): Now, this project has been one of those projects that I've been chasing for a little while. Wansoeb, I've been asking you to come on the show for, I think almost a year to talk about the project. I'm very glad that you have come on. You actually spoke, you gave like a short, I think it was a lightning talk back at ZK Summit 6. This is at the end of 2020. So that was sort of my first introduction to this project. Tell us a little bit about what Zkopru is. Wanseob Lim (03:54): Yeah. Okay. So Zkopru is a private transaction protocol that uses ZK SNARK to preserve the privacy and also uses Optimistic rollup for the scaling. Yeah. So you can send some ERC20 and ERC721 in ETHER privately in a cheap way. Anna Rose (04:17): In a cheap way. That's really cool. Yeah. before we jump into the project, cause I think that's gonna be the bulk of the episode. I actually wanted to talk to you a little bit about your work at the EF. So you're part of the applied zero knowledge proof working group, I guess, which is this privacy and then like the subgroup, is this privacy and scaling exploration team. Yeah. What is that team? Like what are you guys doing? What's it like to work there? I'm just very curious about what you're doing there. Wanseob Lim (04:44): Yeah. Actually in the privacy and scaling exploration team, we have a lot of people there so some of them are developing some BLS wallet or some of them are developing some peer to peer finding protocol using some ZKP in a private way. And also some of them are developing this kind of private transaction protocol like Zkopru. And we are one, we are one of them. Anna Rose (05:13): I've always been curious about like the applied zero knowledge working group. Like, is it, is it quite large at this point? Are you talking like 60 people or is it like more? Wanseob Lim (05:24): Actually, I can tell that how, how many people are in the team because we work very separately. So I, I don't know the total number of the team members, but actually they're a lot, maybe, I guess, more than 50. I'm not sure, but yeah, a lot of people are working. Anna Rose (05:42): What about your team? What about the privacy and scaling exploration team? How big is that? Wanseob Lim (05:48): So my team is also, my team is Zkopru team in the privacy and scaling exploration team. Anna Rose (05:54): I see. Okay. So how big is your team then? Let's find that out. Wanseob Lim (05:57): Oh yeah, the Zkopru is, we are eight, including me. Anna Rose (06:02): Okay, cool. One last question about the sort of EF's applied working group. I mean actually is the ZKP applied working group, which is what I've always understood the group to be. Is it the same thing as this privacy and scaling exploration team or? Wanseob Lim (06:17): I think so. Anna Rose (06:17): Okay. You've probably changed the name and I have, sorry about that. Okay, cool. Is there a philosophy, like from what, what I've seen, it's often been like research projects, research papers, early implementations, and then they're kind of like spun out. Like they're kind of like a team will run with it and start to implement it. So what is the philosophy around creating some of these ideas? Like how does an idea come to a team and, and what happens with it? Wanseob Lim (06:44): So actually I think that we usually try to do some discussions between us as much as possible and actually the key philosophy of the teams that we are developing a public good. So we do some projects with a good will and we are not trying to commercialize the projects because these are all projects are funded by EF. Actually, that means these, these are the public goods, so we are focusing on the research and just trying to just spread these research outputs to the whole developers in the ecosystem. Anna Rose (07:32): Very cool. So let's dive into Zkopru. Zkopru is a protocol or a, is it a product? Wanseob Lim (07:41): Actually, this is a protocol and maybe we are thinking, this is, this is a reference implementation. Anna Rose (07:50): I see. So you, and maybe let's go back to the start of this. How did the project start? What is the paper like? Like what was that whole process? Wanseob Lim (07:59): Yeah, so actually this project started from 2019 and at that time I just traveling around the world with some friends and just was shocked a lot because they, my friends were following my Ethereum wallet because we before actually I just send them some DAI because we just share some dinner. So actually some of my friends were tracking my Ethereum wallet and a year later, maybe. Yeah, a few, few months later, I just get some liquidated at the MakerDAO, and they just told, told me that, oh I saw that you got liquidated the MakerDAO like, like that. I just felt. Oh, oh my God. Actually we have really no privacy. Anna Rose (08:56): No. Yeah. So that's wild. Oh man. That's so personal though. That's such a personal story of like your friends being like saw you got liquidated. Wanseob Lim (09:05): Yeah. Right. So that was the reason why I started the privacy solution. So I just started to build it from 2019 around June and had a talk at the Devcon at Osaka. So Devcon 5 and Barry, Barry Whitehat. He just saw my paper on the ETH research and also the Devcon talk. And we just started the talk that actually my first project was also some using some ZKP for the privacy and also using Optimistic rollup for the scaling, but Barry had a better idea for, for about the protocol. So we had a lot of discussions and we, we started to improve the protocol itself. So I just maybe Barry's idea improved the protocol about five times better. Anna Rose (10:06): Cool. Yeah. So I guess, so what you're saying is you already had the mix, you had the idea of doing an optimistic rollup plus zero knowledge proofs kind of as the privacy component, but I guess you remade it. How did you change it? Like what was, what was it before and what is it now? Wanseob Lim (10:23): At first, actually I tried to use Mimblewimble protocol. Mimblewimble is also ZKP, but actually the problem of the Mimblewimble is that we can just keep track of the transaction. I mean actually Mimblewimble is not a full private protocol, so I need to add some kind of common scheme to Mimblewimble. So it's a modified Mimblewimble. Okay. But actually Mimblewimble kind of a modified computation, but Barry idea was that, oh, we don't need to do that multiparty computation for, for, for the transaction. I mean that Mimblewimble will always need the sender and the receiver communicates at the same time. Anna Rose (11:11): To be online at the same time. Yeah. Wanseob Lim (11:13): Right. Yeah. Yeah. And that is a big problem for the user experience. So Barry suggest me that, oh, we need to change it. Just like Zcash Anna Rose (11:25): To make it more like this shielded account kind of model or just using SNARKs I guess. Wanseob Lim (11:30): Yeah right. So actually our Zkopru design is kind of implementing Zcash on Ethereum. Anna Rose (11:37): Oh, wow. Okay. So it is, so you do have that, when you say Zcash, you do actually mean the shielded unshielded? Wanseob Lim (11:43): Yeah. Right. So we have a viewing key and we have spending key. So yeah. It ensures the compliance. Anna Rose (11:52): That's the compliance makes sense, but I mean like, do you have, so as a, as a user, I'm gonna try to picture this, like, would I go main chain over an optimistic rollup bridge kind of thing to a new chain, which is public, but then you go into shielded or do you automatically, when you go over that? Wanseob Lim (12:02): Actually every transaction Shielded. Anna Rose (12:13): Okay. So it's a fully shielded L2, for some reason I had in my own notes, sort of this idea of like ZK rollups and optimistic rollups blended into one but would you say that it's quite distinct, like the actual L2 mechanism is just an optimistic rollup as we understand it? Fraud proofs? Wanseob Lim (12:33): Yeah. So this, actually, this is not a mixed roll up. So it only uses ZK before the privacy. Got it. And the L2 is just run by Optimistic rollup. Anna Rose (12:44): I see. And is it like, which, what kind of fraud proofs is it based on? Cause I know that there's the, the camp or the school of thought that Optimism came up with and the school of thought of, of Arbitrum what's it closest to? Wanseob Lim (12:56): Actually Optimism and Arbitrum are made for general purpose general state L2, but actually our Zkopru is a special purpose Layer 2 special purpose optimistic rollup. So we have a lot of some challenges codes. So for example, the challenge code number one is that the coordinator submits a invalid transaction route. Okay. In the header. So we have a, maybe I just guess that we have 40 types of challenging transactions. So we are just covering all kind of some possible situations. Anna Rose (13:37): We did do episodes with Optimism and Arbitrary, but like how are they doing it differently? Do they also have that kind of thing? Are the codes different? Are they four different edge cases or is it like, yeah, maybe just flesh out a little bit. That difference between the two, because I, I kind of don't remember how they do it. So, so I'm having trouble totally seeing why this is different. Wanseob Lim (13:57): Actually, yeah. Actually, I, I also don't don't know this exactly the difference with Optimism and our protocol. Anna Rose (14:08): I see. Okay. But you just know how you're doing it, so it is. Yeah. Right. So it's the, you come up with like ways that people could produce some fraud and then you have checks for that, I guess. Wanseob Lim (14:19): Yeah. Right. Because it's like a, the implemented fraud proof is just like implementing the protocol itself. I see. I mean that in the protocol, we have a lot of statements, like maybe the protocol statement is like the state root should be changed like this if we have these kinds of transactions. Right. So just the fraud proof implementation is just implementing these protocols itself. Anna Rose (14:54): I See. But do you also have this like seven day waiting period? Or like, is what's, is it the same as that it's like the sort of you, one could challenge that and then what would happen exactly. Or is it's rather like transactions going between main chain and the, and the L2 need to be delayed because there needs to be a period when fraud proofs could be submitted. Wanseob Lim (15:16): Yeah. So we, we wait seven days for the fraud proof. Anna Rose (15:19): Cool. I feel like, like in this, in this conversation, I'm realizing like, man, I gotta revisit the optimistic rollups. Cause I'm, I can tell I'm a little fuzzy on like exactly how they're working, but okay. So, but I, I see some similarities there. I guess what I'm trying to understand is, is there any part where like the, the zero knowledge proofs change in any way, the way the optimistic rollup is implemented? Or would you say it doesn't need to, like the optimistic roll up does its thing whatever's happening underneath the hood? Like if there's zero knowledge proof, or if there isn't, it's kind of acting the same way? Wanseob Lim (15:57): I think in the optimistic rollup, the most important thing is only the cold data size. So if the ZKP needs a big size of proof, then it is very unbeneficial for the protocol because it cause a lot of some call data. Yeah. Actually it depends on how ZKP works. Anna Rose (16:19): Okay. Well, let's move on to that side. Did you have to implement your zero knowledge proofs in a very specific way for them to work within an optimistic rollup? Wanseob Lim (16:29): I don't think so because our transaction itself should be validated by the ZKP. And actually it does not depend on the rollup technology is optimistic rollup or ZK rollup, so, yeah. Anna Rose (16:46): Cool. And then you mentioned that it was like the Zcash model. So you're basically, if you're doing transactions on this roll up, you'd be also attaching to it a SNARK proof, I believe. And that's kind of what proves it's the validity of each transaction. Wanseob Lim (17:03): Yeah, actually we gather all the transactions, including the ZKP together. Okay. And we just pack that as a 1 block and submit it to Layer 1. And we do not run the execution of the validity of each transaction, but we can just submit a challenge that, oh, the seventh transaction of that block is not valid. Anna Rose (17:30): How would you do that though? Like how would someone identify? So let's say that again, you in Zcash, each transaction there's a proof attached to each transaction. What you're describing is, is it also each transaction has a proof? Wanseob Lim (17:47): Yeah. Right. Anna Rose (17:48): It does. Okay. But then you batch them together and these are written to main chain through this optimistic, like the way that most optimistic rollups are. So there's a sequencer, I guess. Wanseob Lim (18:00): Yeah. We have a coordinator and yeah, it's like a sequencer, the same thing. Anna Rose (18:05): Okay. So you have, you have the coordinator that is basically putting, and maybe tell me, I think it's putting together these blocks, like, what, what do you use to kind of compress them into something that would go on the main chain? Like in ZK rollups you often will have like the proof and then a verification in the smart contract. Here what is the sequencer doing exactly. Or the coordinator in your case? Wanseob Lim (18:27): Yeah. So the coordinator receives the transactions from the client and the transactions... Anna Rose (18:31): In a batch, I guess. Wanseob Lim (18:33): Right. Okay. Yeah. So receives the transactions and create a batch. Anna Rose (18:38): Oh, they create the batch. Okay, perfect. Yeah. Wanseob Lim (18:40): They create a batch and submit that to the Layer 1 smart contract. Anna Rose (18:45): So they have a batch. How do they make it a small thing that you could put onto the main chain? Wanseob Lim (18:50): So actually we just submit this batch solid to the layer one, actually, this is our next step to just compress the, all the proofs into one ZK rollup. So, you know, this is kind of recursion right. Anna Rose (19:05): Ah, okay. So what you're saying is, let me see if I can map this. So you have a ZKP attached to every transaction it's then batched together, but then do you, do you then take a SNARK to make that into one proof? Wanseob Lim (19:20): No, we are not processing the proofs into one ZK SNARK, ZKP. Anna Rose (19:25): You're not doing that. So you're not using recursion. Wanseob Lim (19:28): Yeah. Right. We are not using recursion. Okay. Actually recursion is our next, next step. Anna Rose (19:33): Okay. So recursion might come. Okay. We'll we'll leave that for future then. Yeah. We'll revisit that one. Yeah. Okay. But so, but I still don't really understand how, like it, to me, it would seem like a lot of data. This is where I might also my, my fuzzy understanding of optimistic rollups as I'm just realizing I have, I kind of forget how they compress it into something that's small. Like, do you hash it? Do you like, like you must be making it into something smaller. I imagine. Wanseob Lim (20:02): Actually we are, we are not just compressing. So you think that a one transaction has a data about 256 bytes. And also if, because we are using Groth 16, so its proof size is 256. So one transaction has a data around 512 bytes of data and it's cold data gas price is around 8,000 gas. Anna Rose (20:35): Okay. And for one transaction. Wanseob Lim (20:37): For one transaction, and we do not execute the verify function in the smart contract, because the verify it consumes around maybe 200 to 300 thousand gas per one transaction. Anna Rose (20:54): That's the expensive part. Okay Wanseob Lim (20:55): Yeah. So we just skip this. Anna Rose (20:58): Okay. Another question about this that might help me understand, does the rollup, does this actual rollup, have a state, are you basically like doing a checkpoint of the state of the rollup? Is that what you're actually writing to the mainnet? When you talk about batching and you're putting these things together? Cause like, I guess what I started to imagine was like, if you have individual transactions and you're trying to write them to main to the main net, then I'm thinking like, well, that's a lot of, that's still a lot of gas. Yeah. But if you are just showing the latest state at checkpoints, is that kind of what you're doing? Wanseob Lim (21:32): Yeah. You're just storing the latest, checkpoint, the block hash on the smart contract. You don't do anything. Anna Rose (21:40): You're not doing the verification, which would be very gas intensive. And just storing that small hash of the latest state is not that expensive either, I guess? Wanseob Lim (21:49): Yeah. Right. Anna Rose (21:50): Okay. And then you have the seven-day window. So there it's like if someone submitted a fraud proof, proof of fraud, basically, would it be like a bad transaction or would it have been the bad behavior of a coordinator? What are you testing for with this fraud proof? Wanseob Lim (22:07): It's a bad behavior of the coordinator, because if the coordinator accepts an invalid transaction, then it's a bad behavior. I see. Anna Rose (22:21): Yeah. Because that's what they're supposed to be checking for? Wanseob Lim (22:24): Yeah. Right. So actually we have an episode about that. We are now running testnet on the growing? network and our previous coordinator software was accepting invalid transactions. So the tasking coordinator was gas slashed. Anna Rose (22:40): Wow. So did, did you do that on purpose or did you find. Wanseob Lim (22:44): no, not at all. Anna Rose (22:44): You found it afterwards. Wanseob Lim (22:45): Yeah. Right. We just found that just on the testnet. Anna Rose (22:50): So you actually got to see the fraud proof in action. I feel like the fraud proof is always kind of like this like theoretical future thing that you don't get to see. Cause it wouldn't make sense for anyone to do. It would be so dumb. But that's cool. You actually saw Wanseob Lim (23:04): Yeah. Where just encountering a lot of some slashing conditions we've never expected are in our development progress, development stage. Yeah. Anna Rose (23:14): Okay. So I think I'm following this more clearly now. And this is what you mean where there's no, like I think the non-verification on chain actually helps me to understand why this is not gas intensive. I do wonder, you know, we talked about sort of transactions, but are you, is Zkopru only for transactions or does it also deal with any sort of programming? Like, is it purely like I wanna send privately or is it also like I wanna compute privately? Wanseob Lim (23:44): Actually this is only for the transaction like Bitcoin. I see. And we are supporting a, some few features like atomic swap and maybe the only so special feature of the protocol will be the atomic swap. So I have a ERC721 and you have a 10 DAI of ERC20. Okay. Then we want to exchange these with each other. On Zkopru network, then we can exchange in a private way. So anyone does not know. So anyone does not know that I sent ERC721 to you and you sent your 10 DAI to me, anyone anyone does not know this is a private atomic swap. Anna Rose (24:55): How are you doing that though? Cause I know that that's been like sort of that's the Shangri-La that everyone's trying to find. I think that's the wrong metaphor, but I that's the sort of like goal of so many of these like private dexes, are you not, are you not susceptible to the same kind of like, you know, leakage of information? Wanseob Lim (25:15): Actually we just thought that there are two kind of process to achieve this goal. The first one is using MPC, multi-party computation, and the second one is just using a memo field using a memo field. Actually we can just declare that I need a paired transaction, which gives this note to me. So when we try to do a private exchange between us, then I just tell you that, oh, Anna, please create a note. Which amount is 10 and the currency is DAI and the owner is Wanseob. Then I'm gonna create a new note, which includes ERC721. And the owner is Anna and let's make these two transactions and submit this pair to the coordinator. This is how the atomic swap works in Zkopru. Anna Rose (26:16): Is atomic swap. Is this a concept? Is this a Dapp is this a part of the protocol itself? Is... Wanseob Lim (26:22): This like, this is part of a protocol itself. Anna Rose (26:23): Oh wow. Okay. So you have this built into the entire thing. So it's the, yeah, the optimistic rollup the ZKPs on, on like the inside kind of being generated and then making everything private. And then you have this memo field phenomenon. Is that something that any protocol could easily do or is that like very interwoven in what you're doing? I'm also wondering like, is that memo field also hidden? Is it also hidden by a SNARK or is it public? Wanseob Lim (26:52): It's a public. So actually using the multi-party computation is using SNARK and we can just make the atomic swap part as hidden but we just chose the public way. So I mean that actually in the private transaction, we generate outputs of the transaction. We have inputs and outputs of the transaction, right. ZK transaction and atomic swap is just having a, we have a swap field of a transaction and it means that we need a transaction of at least one transaction in the batch, which have an output, which is exactly same with my swap field. Anna Rose (27:44): Oh, okay. So you're kind of like you're doing both sides. Like it would one account kind of do, I'm trying to picture, how do like, can you, can you actually walk, walk us through how this would actually look like for each? So say there's two accounts, there's two users. Yep. And they're trying to, they're doing it with each other, right. There's is that how it's usually happening? Wanseob Lim (28:05): Yeah. Anna and Wanseob. Anna Rose (28:07): Okay. So yeah. Why don't you just say what each of us is doing exactly. Because I, I didn't quite follow how the memo, like what exactly we'd put each into our memo fields. Wanseob Lim (28:17): Yeah. Okay. Let me clarify a little bit. So our Zkopru transaction has a memo field and also swap field. Anna Rose (28:26): Oh, I see you created a new field. Wanseob Lim (28:28): Okay. Actually the memo field is out of protocol, but swap field is a part of the protocol. Okay. Yeah, by the way, usually when I create a ZK transaction, then I spend my note and create two outputs and the two outputs are the hash of the note and the data of the note will be like the amount is 10 and the owner is Anna. And if I use a swap field, then actually this is a kind of pair the transaction. Anna Rose (29:05): But in my, I'm not putting both sides in right? I'm just putting one, like I say, I have 10 DAI. You have. Wanseob Lim (29:12): 10 ETHER. Anna Rose (29:14): Wow. Okay. Weird trade. Wanseob Lim (29:19): Let's trade. Anna Rose (29:21): You're bad trader. Okay. So, okay. So you have 10 ETHER. I have 10 DAI. So what are we like? What am I putting into the memo field if I have 10 DAI? Wanseob Lim (29:31): Yes. So let's say that we are trying to trade 5 DAI to 5 ETHER. Okay. Then I spend my 10 ETHER note and create two notes. I see. And one is five, five ETHER Wanseob Lim (29:49): And one is five ETHER for you. Anna Rose (29:51): Cool. Okay. Wanseob Lim (29:52): And, but I, I actually, I have to get the 5 DAI from you, right? Yeah. Then I just use the swap field and just fill in the data with the hash of the desired note that I want. Anna Rose (30:09): Oh, wow. Okay. Wanseob Lim (30:10): Okay. So you also create, you also spend your 10 DAI and create two notes. And one is 5 DAI for you and with 5 DAI for me and the 5 DAI for me, the note for, for me should be equal, should be, same hash. Yeah, yeah. Of the swap field. Anna Rose (30:31): And what is public then? Is the hash, could one view the hash on chain on the L2? Wanseob Lim (30:37): Yeah. Anyone can view the hash. I mean, anyone can see the hash of the outputs. Okay. So swap field is just a, just the hash of the output. Yeah. That I want from you. Anna Rose (30:51): So you see that like, is that visible? Like if you had an Explorer, could you actually see it? Yeah. Okay. What could I learn from seeing this hash? Wanseob Lim (30:59): What can learn from that is that it is paired or not. Anna Rose (31:03): Okay. You could tell that two hashes had been made and somehow swapped together. Wanseob Lim (31:07): Yeah. Right. So your transaction and my transaction should have each swap field. Each swap field should be one of the output of the opposite transaction. Anna Rose (31:20): If you knew the hashing algorithm you're using, could you not decipher how much it was or something else about it? Wanseob Lim (31:27): Actually we also have a salt value inside the note. So actually that is not possible. If you wanna decipher that, actually you need the SALT value. Anna Rose (31:38): What SALT? Okay. I don't know about the, yeah. Is that something you guys came up with or is it a common? Wanseob Lim (31:44): It's a common, yeah, its a yeah. Common terminology, by the way, let's say that we are using kaptcha 256 and we are using kaptcha and we are hashing a data which is zero. Then we will have always same hash. Right? But if we put a, another data with it, then we can just randomize that. Anna Rose (32:09): I see. So the SALT is a random, an extra random number? Wanseob Lim (32:12): Yeah. Right. Anna Rose (32:14): But then if you're making that on both sides, like how would you get the same SALT? Because you still need the same hash. Wanseob Lim (32:20): So for the exchange, we need to communicate with each other. Yeah. So we should share the same SALT together. Anna Rose (32:27): But you do share salt. Oh, I see. Okay. So even though, okay. That's that's actually, this helps me understand why it's like, especially impossible. The leak is if you knew for some reason someone's account number and chose a few different kinds of amounts kept hashing that without the SALT, could you accidentally run into the same hash? Wanseob Lim (32:50): I don't think so. Anna Rose (32:52): Still would be too hard because you, because the account, the account number that they share with you is maybe not the one that's being hashed. Wanseob Lim (32:59): Yeah. So if it is possible then I, I maybe I already have Vitalik's account. Yeah. Anna Rose (33:05): Got it. Okay. Okay. Here, everyone can hear that. Like, you know, Anna Anna's knowledge of hashing is, is rusty as well. Apparently. Well it's the new year, you know, anyways. Okay. Okay. I guess, I think I understand now, so this like, is this atomic swap idea though? Is that built or is that like still a conceptual thing? Wanseob Lim (33:26): It is already built in the current protocol. Anna Rose (33:29): Okay. And you also mentioned though that like these ERC20s, but like how do you have ERC20s if it's only transactions like it, to me, an ERC20 is a smart contract, that uses a specific kind of formula. To create itself, which is the ERC20 part of it. So it's a new token, but it's usually done as a smart contract. And this actually leads to another question like does Zkopru have like is it EVM compatible? Does it have like an EVM? Like does it have smart contracts on its side? It sounds like not. Wanseob Lim (34:05): No it doesn't. So actually you can deposit your ERC20 or ERC721 or ETHER into the Zkopru smart contract, then it automatically converts ETH to a Zkopru note. Anna Rose (34:20): Got it. So will each of these have its own unique code within the rollup? So like the ERC721 will mean something else in there. So it will have like the Zkopru version of itself, like on, on the Zkopru side of things. Okay. Yeah. And then, and this is what you mean when you're doing these kinds of swaps. You're like, you're gonna have internally a different, like in your rollup, there's a different code name for what these are, I guess like you're gonna have a unique type of token that represents that ERC20, but actually how do you do it with ERC721 since each one of those are unique? Wanseob Lim (34:56): Yeah. Actually ERC721 is, one ERC721 become one note. Okay. Yeah. Every, every note is unique. Anna Rose (35:05): Oh wait are, but are you say, but how, okay. Sorry, let's take a step back. If there's say you have 20 DAI and somebody else has a hundred DAI and they both like want to move onto the rollup they deposit it in the smart contract. But do you create on the Zkopru side very different notes for both of those, even though it's the same ERC20 type? Wanseob Lim (35:27): Yeah. So if then we, we, we can have two, two notes because they have same address. Yeah. ERC20 address, which merge them into one note. Anna Rose (35:41): So they do so, and then would they get, like, I forget what number I used, like 20 and a hundred or whatever, but it's like the person who put in 20, would they get 20 of these notes or would they have one note that says they have 20 of this thing? When you say note, is there 20 notes plus 20 notes or a hundred notes that go out or is there one note that has a new value to it? That's sort of what I'm not clear on. Wanseob Lim (36:06): Yeah. One note that has a value. Anna Rose (36:08): Okay. And so there's one note created on the rollup there's values underneath that, in that yeah. And 20 of that note type will go to one person and a hundred would go to the other person on the rollout. And what if later someone came with another 50 DAI? Like I'm basically trying to understand when you say note, do you mean like type? Is that like a currency type? Like would all DAIs on the like, cuz it's all the same contract right? So it's like the same ERC20 contract on the main net would that reflect a single note type on your side? And then there's only one of those notes, but on, and what you have underneath the note is kind of like the balances? Wanseob Lim (36:54): Actually there is, we have only one type of note, each note has some fields and the first field is amount and the second field is the address. And the third field is like, is NFT or not? Anna Rose (37:10): Okay. Yeah. And then what's but how do you decide between different ERC-20s? Wanseob Lim (37:15): Yeah.So we have address field inside the note. Anna Rose (37:19): And when you say address field, you mean the contract address? Wanseob Lim (37:22): Yeah. Right Anna Rose (37:23): Okay. Okay. Got it. Okay. Yeah. I think when you said address, I thought maybe it was the address of the, the owners. Wanseob Lim (37:30): Yeah. Address of yeah. Also the owner and the address of the ERC20. Anna Rose (37:36): Okay. So that's sort of what I'm trying - so you have amount, so the person who had put in 20 to the smart contract on mainnet now has 20, like it has this note that says you have 20 with the contract for DAI, like, the address of the DAI contract. So it's like tells you what type of currency it is or what it, you, what it reflects and then their own, own address number as well as like, this is the owner of this note. Wanseob Lim (38:03): Yeah. Right. Actually the public key of the owner. Anna Rose (38:08): So you'd have the private and the public on the note or not? Wanseob Lim (38:11): Yeah. Actually to use the ZK transaction on Zkopru, you need to create your own Zkopru account using a private key, then it'll give you a public key. Anna Rose (38:24): Yeah. Where are the SNARKs created? Are they created by the person making the transaction? Wanseob Lim (38:31): Yeah. Anna Rose (38:31): They are. Okay. So each, each time you send something, you're also gonna be generating a SNARK? Wanseob Lim (38:36): Yeah. Right. So if you want, yeah. If you wanna send some transaction, then you need to create a SNARK. Anna Rose (38:42): Okay. What kind and you said it's groth16. Yeah. But is it what, like size, it must not be too big if people are generating their own, like yeah. Tell, tell me a little bit about like how, what the SNARK looks like. What, what is it similar to? Wanseob Lim (38:56): Yeah. Actually our SNARK circuit is not that big. It only contains a logic about the merkle proof and the ownership proof and a little bit of some protocol implementation inside, like range proof. So actually not, not that heavy. Anna Rose (39:14): Not that big. Is it similar in size to like what Tornado Cash used? Because I know theirs was pretty small. Wanseob Lim (39:22): Yeah maybe pretty similar, but the difference with the Tornado Cash is that Tornado Cash is have different pool for different ERC20s. Mm. For ERC20. But we have, have a one, one integrated pool. Anna Rose (39:38): What if somebody had a really weird ERC20 that isn't like, well-known, have you chosen, which ones have been able to be replicated or is it like free for all? Anyone can send any token? Wanseob Lim (39:48): Anyone anyone can register their own token and anyone can use Zkopru and actually very uncommon ERC20 also can be protected. So, but maybe because of the small set of that ERC20's users. So it, Anna Rose (40:07): It sort of reveals the privacy... Wanseob Lim (40:09): Yeah. It all, yeah. There is a, a little bit of privacy leak, but yeah. Protocol still protects every kind of ERCs. Anna Rose (40:19): Okay. But in that case, wouldn't the ERC721s also leak because like they are unique and each one would be like, is there any way that each one would be traceable? Wanseob Lim (40:30): Yeah. But let's say that I deposited crypto kitty, and I just transferred to you and you transfer to your friend and your friend transferred to some other, and that guy withdraw that. Anna Rose (40:49): You'll see these two, but you would see that it on the mainnet you'd see like it south, it's almost like flipped over here without a trade. Wanseob Lim (40:57): Yeah. we, we, we just can see that I deposited and whose name is Carl. Withdrew the crypto kitty, but actually we don't know the trace of the transfers. Anna Rose (41:12): Throughout it. Yeah. How, like, are there any UIs or interfaces already for this? Like, is there any like how I would, I'm trying to kind of picture how. I mean, I know how zkSync looks. I know so far. I mean, I don't know how the, the new versions will look, but like, I, I kind of know how the, the often these L2s will build sort of interfaces so that you can actually like understand that you're set, you're locking something and you hit, like, I'm locking it. You, you know, accept the transaction or signature, whatever on MetaMask, then you have this new interface, this new place where you can like, do things like trade things. Have you built out any of those interfaces or started to think about them? Wanseob Lim (41:53): Actually, we are, we are only have a UI that supports transferring now, but we are currently building the private exchange and also we are building a merchandising. Anna Rose (42:07): Ooh, what's that like? Wanseob Lim (42:09): So I just said that we support private exchange so it means that you can open your own store and you can sell your own NFTs, accepting ERC20s. In the private way that also ensures the compliance. Anna Rose (42:27): Wow. So, you know, I've been trying to find the ZK NFT projects, but it sounds like you, you have sort of a, a potential model there. Wanseob Lim (42:36): Yeah. Right. So it's like a, it's like a Web3 people. Anna Rose (42:39): Wow. Is this part of Zkopru like goal? Like, is this the team that's actually building it too? Wanseob Lim (42:44): Yeah. Right. So there's Takamichi in the team is building the private exchange and Robbie is also building the merchandising tool that uses this private exchange. Anna Rose (42:59): Wow. That's exciting. That's an amazing use case. That was actually one of my questions. Because like, I mean, one of the things I did wanna ask is like, there's a lot of rollups and there are like Aztec's doing privacy on L2, but with private computation and then you have, you know, a lot of like the ZK rollups even if they're not private right now, definitely have like a play for privacy. So how are you seeing yourselves kind of being different? Wanseob Lim (43:23): Yeah. So actually the, I think the final goal of this project is giving the merchandising tool to the ecosystem. I mean the, to the people and to achieve this goal, what we have to do is implement the private exchange. Actually the private exchange is also a little bit difficult because it also uses blind find to find the peers to trade together. And also it uses the socialism millionaire protocol that to find the exact matched order between the seller and the buyer. And so just like this, we need to implement those private exchange. Also we need to implement the merchandising tools. So actually there are a lot of some milestones for the team. That we have to do. Yeah. Anna Rose (44:13): That sounds awesome though. I just realized I wanted to double check something. So earlier in the episode, I asked you if like the state was written to the chain, but now I'm realizing, and it's kind of, I'm remembering like Zcash is like a UTXO model. So is this and the word state? I don't know if it, maybe there's a different term for this. Like I always think of state as like state versus so, so state model. Yeah. Anyway, maybe we should just clarify that. Because now I'm realizing like, just, so I also walk away a bit more understanding what's written to the mainchain, is it a UTXO type state? I don't know what you call it or is it like a EVM type state? Wanseob Lim (44:52): What we store on the main chain and what we store on the Layer 1 is the root of the Merkel tree of the whole output. Anna Rose (45:03): Okay. So which, what does that mean though? Wanseob Lim (45:05): I mean that this is the root hash of the anonymous pool. Anna Rose (45:11): The anonymous pool. But like, is it, this is actually kind of also might be interesting for me to understand if, if Zcash ever wanted to like connect to another org, but like what is the output of a UTXO? Is it a UTXO? Actually that's the question. Wanseob Lim (45:25): It is. And in the UTXO model we have inputs and we have outputs, but in a zk transaction, actually, we have nullifiers instead of the inputs. So, so we can just cut the link between the inputs and the outputs by using the nullifier. Anna Rose (45:44): And the thing that you're ha like Merkelising and then writing to chain is the outputs of a UTXO type model? And not state state was like probably the wrong term. Cool. Cool. Wanseob Lim (45:56): So what we prove using the ZKP is that, oh, this nullifier is actually one of the leaf of the Merkle tree. Anna Rose (46:08): Got it. Thanks for that. Sorry, just took me, it took you like talking about use cases to like, remember that. Oh, maybe... I did wanna ask you, there is one other project that I'm aware of that's doing something similar, which is a rollup and an optimistic combined and that's EY's Nightfall. Is it, is it similar or different to what you're doing? Have you, have you seen what they're working on? Wanseob Lim (46:31): Yeah. I seen what they're working and how, how they're working. And I really like that project. I, I think maybe their approach and our approach have a very, very similar approach, but I think what I found, what I found that, between difference between Nightfall and our protocol is, they're supporting ERC1155 too. And I think that should be our next step too. And very thankfully the orders of the Nightfall is credited us the Zkopru protocol. Anna Rose (47:10): Cool. Yeah, because, so there's a link there, there's a connection between these two orgs. Okay, cool. Wanseob Lim (47:15): Yeah. Right. So maybe I think we are just giving some good influence together. Anna Rose (47:23): Nice. How do you imagine this L2 working with other L2s because we've talked to some of the other L2 about bridging between themselves. Like not only like needing to go to the mainnet, main chain and then off like that, that's, I've sort of been thinking about it a little bit. That way, where it's like the main chain in this regard becomes the bridge where it's like, you go from your L2 to the L1 back to another L2 and that's like the bridge, but you could do a more direct bridge. Does that actually not work in your system because it's so private because of the way it's built? Or do you think you could bridge? Wanseob Lim (47:56): Yeah, to be honest at first in the privacy and scaling exploration team, actually we have a lot of teams that handles the rollups like ZK rollup and Optimistic rollups the actually from 2019, we've discussed how to bridge between the rollups together. But actually currently we're just only focusing on each rollup is solve for now. So well, what I think in the future is that I, I don't think that average transactions in the Ethereum should be private, so maybe some of the transactions should be private. And so I just imagine that Zkopru will be on Ethereum and also will be on arbitrum and also will an optimism, or it will also own another ZK EVM rollup. Anna Rose (48:56): Do you almost picture then like a rollup of a rollup? Is it like it would be working because they're EVM-compatible. So they have, you could basically deploy the Zkopru on like the Zkopru smart contract, their EVM on the L2's EVM. Wanseob Lim (49:12): Yeah. Yeah, sure. Anna Rose (49:13): Wow. Would it all link back to the same place though? Would it all be like into a single L2 or would there be like multiple? Wanseob Lim (49:20): Maybe, yeah. They they'll be all separated because I still believe that Zkopru is built for the privacy itself. So it, it can be used for this kind of merchandising or just transfers between some friends like that. So if I am using optimism, then I think there should be another merchandising tool on optimism. And I think we can use Zkopru for that. Anna Rose (49:49): Would it not be easier to make like a private Dapp on there? Like kind of, how would you compare this type of project to a Tornado Cash? I know that their model is different, but I mean like, could you not build this model as a Dapp using smart contracts? Or do you feel like it needs to live as an L2? Wanseob Lim (50:09): Actually I always think that every Layer 2 are a Dapp. Anna Rose (50:13): Really? I guess they they're smart contracts, right? Wanseob Lim (50:17): Yeah. Right. Because there Layer 2 is a blockchain, which is implemented on smart contract. So actually definitely they are Dapps. Anna Rose (50:27): Wow. Actually, this is the first time that someone said that on the show. I think maybe I'm maybe I'm forgetting somebody else saying it, but I like first time is landing for me. Yeah. That's but that's true. They are yeah. Smart contracts. That's cool. Wanseob Lim (50:42): That's what I'm thinking about, about the future of the zk proof. Anna Rose (50:45): And that's why you think of like, you could then anywhere there's EVM compatibility. Because it's written I'm guessing the smart contracts. Yeah. I mean they're solidity smart contracts. So you have them already, you could just redeploy this and since the entire, like the entire logic of the rollup is in those smart contracts. Right? Yeah. So then you could just redeploy it and it would actually just, the only trouble would potentially be like adoption or like having enough people using it so that the privacy is preserved. But yeah, that's interesting. Wanseob Lim (51:16): Yeah, definitely. And I don't think that we need to use optimistic roll up for the scaling forever. I mean there's this developed, think the protocol. So at the end, maybe there will be a possibility to use the ZK rollup and also like we can use recursion and maybe other protocol, maybe other, other technologies, techniques to improve the protocol. Anna Rose (51:45): Cool. Yeah. I mean, that was a question I had, we kind of pushed that off this idea of like future work and what you have planned. Are you also thinking potentially of ever like changing your circuit or do you think for now that's gonna stay as it is? Wanseob Lim (51:59): Uh, actually for maybe for now we don't, we, we don't have any plan to have any modifications about the circuits because we just did the trusted setup and writing a new circuit is a lot of some security investigations. So, but definitely we are just trying to, yeah, we are trying to. Anna Rose (52:23): Would you, do you think you'd ever use something like plonk instead of groth16? Wanseob Lim (52:27): Yeah. So for, for the recursion, maybe we, we need to use plonk and also actually we also want to support ERC1155 too and for provide them, we need to get some modifications for the circuit and yeah, Anna Rose (52:45): That, sorry, you said ERCs115 or what? Wanseob Lim (52:48): Yeah, 1155. Yeah. Oh yeah. Anna Rose (52:50): Okay, cool. Nice. Well, once off, thank you so much for coming on the zero knowledge podcast finally. I'm so glad you sat down with me to go through all this. Wanseob Lim (53:03): Yeah. I was really happy to, to be on the show and yeah, I actually I was really nervous, but I think you just let me, yeah, I just, can just say whatever I'm thinking. Anna Rose (53:19): Yeah. Totally. Yeah, you're always, you're always welcome to come on the show and, and tell us what you're, what you're up to what you're thinking about. Wanseob Lim (53:25): Thank you so much. Anna Rose (53:26): Well, thanks again. And I wanna say thank you to the podcast producer, Tanya, the podcast editor Henrik and to our listeners. Thanks for listening.