 So I'm Lakshman and I'm going to be talking about some work that we're doing, work with the foundation. It's sort of like a, it's not particularly lamorous work, but it's kind of a necessary work to get the mixers doing what they want them to do. And that's to do with like making sure we have a kind of a decent flash relay in our work. I'll talk a little bit about the problem. Probably won't spend too much time on that because I'm not particularly familiar with it. And then I'll try to talk through what we've built so far and what the next steps are. So this is like a very primitive diagram about non-chain mixers. I'm actually really excited about this primitive in particular because it's one of those things that is pretty obviously different on-chain, which is off-chain. Like off-chain, like in privacy in particular you really don't want people to see what you're doing. And so trusting someone to mix your funds, like trusting Osoc and Wallet or something like that, makes for a completely different user experience as something that is completely trustless. And you're like hiding in the crowd kind of like excited. So just real quick overview of how these things work. You put money into the contract and then let's say a bunch of other people put money into the contract. C-R-A-C-D-C-D and put money in. And then later it's A prime from another address generated proof. It says you are one of those people who put money in without saying which one. And that entitles you to some of that money. And so to someone looking at the network and trying to analyze like who's money is whose, they just see four or ten or a thousand going and a thousand coming out. They can't do this. So yeah, pretty, pretty profit motive. So real quick overview of why relays at all are even necessary. So one of the main things that I've heard that people want to use this kind of thing for is funding addresses that are not associated with any of the addresses you currently have with heaths. So you can like interact with the network with them. So in this case let's say A is one address, A prime is another address, you want to fund A prime. And so you put money in, A prime then has to withdraw the money with this zero knowledge proof. But if they have C-R-A-D, how would they be able to do it? And so that is where relays come in. This also isn't like a new idea. Like many, many projects are talking about transactions, transaction distractions. The idea is for certain things you might want a third party to run transactions for you. So this is what that new kind of like transaction code looks like. So A deposits money in the contract, presents a signed transaction to a relayer, then runs the transaction on the other half. And then over the course of that transaction, money comes out to A prime. And not pictured, but some of that money might come out as a fee to the relayer. It's like a reward for the service that they might need. And so this is kind of the case I'm trying to make, is that the central relayer defeats part of the purpose of a trustless mixer. And a lot of the projects, all of the implementers, some of them here right now, are obviously shipping with the single central mixer, which is I think when you're shipping an MVP, you kind of want to ship the parts that you really want to test initially. So it makes sense maybe not to do a fully featured thing at launch, but a single relayer has two problems. So one, from a user perspective, if you know that the company running the relayer is the same as the company kind of like serving the client code for interacting with the mixer, there's no way for you to know that there isn't some communication going on there, or even more kind of variously that like the relayer, there's some communication going on behind the scenes, like from the web server serving client code in the relayer. And if there's like some pattern in how like the time between deposit and withdraw like in the client code, then the relayer might be able to figure out who you are. So another thing is obviously if you have a single relayer for serving a mixer, there's, you know, issues of censorship, issues with artificially high feeds. So ideally we would have many relayers serving. So that is what we're trying to solve this sort of thing. We're currently in the process of integrating with one mixer. We're looking to integrate it with everyone else. So it's like pretty, obviously pretty alpha stage, but the ideas are that like anyone like you or I could just run like a docker container that is a relayer and you can immediately be a part of this network. Any existing mixer doesn't need to change their contracts anyway to use this and just has to change the client code, like change, literally install an MPM package and change how they find relayers. So this part I'll kind of go over the main parts of what this is. I might try to actually speed through this because it's a little technical and leave more time for questions, but this is kind of like analog to the previous diagram we looked at where you had like someone who's trying to interact with the mixer, you have a mixer contractor for relayer and we're adding these four components, the really key parts are the client, which is like an MPM package that you can put in the wall or a mixer client code. The daemon, which is just like kind of the server of the relayer essentially and then two more contracts that are necessary, but sort of serve as a discovery mechanism for relayers as well as like transaction forwarding. These we have like our first, we've kind of been doing some research into the right way to do reputation in particular and so we have like the first implementation of the stuff, we're also talking with like the gas station at work to see if we can get any great account and they actually is kind of filling that role as well. So first, talk quickly about the client. So the client's main role is client relayers and you get the reputation contract and so the idea is that like let's say this is a client, this is a user, so this is also where like let's say the wallet code or the mixer client code in your browser on your mobile and so through our library it talks, it figures out where your relayers are and it allows you to submit transactions to those routers and this is like structured pretty simply and they get every about, you can see it's just like an mcam package and right now I have an example of getting the best relayer IP of course like the forward address or something, it doesn't really matter. But that's designed to be very, very simple. So next is the gaming. So really what, we're going to share like a reference sort of API that they should expose to properly communicate with the client and we're also releasing like a reference to this that does some like fancy stuff around transaction simulation but this is something that technically like anyone can create that custom version of, you know, if this becomes like a high-volume activity you'd imagine that people would want to create like really high performance things that look at the network and make sure you're not getting thrown and stuff like that. Right now we do some very basic like transactions so basically what happens in the current version of this code for any transaction it simulates running that transaction sees how much running that transaction changes your own e-balance and if it's like a beyond a certain amount basically like so. And I have, yeah it's super simple. If you have Docker installed it's literally just running like a few commands to run that. So this is designed so that like anyone could run it and it would be really cool if like random people run relays. Oh, yeah this is, these are the two critical pieces for this type. There are some other routes but basically like for like given transaction like you need to tell clients what the fee you charge is and you need to tell the client and you need bill submitted. Okay. And so finally this last piece which is the forwarder of our potential contract. So the idea here is that there's, the reason we wanted to start we wanted to kind of like create this set of abstractions that you know we can talk about with something else is because it's nice to have like trust this discovery like some like kind of understood mechanism of regular discovery. And, but you know this is something we can play with. Yeah, just forwarder contract is very simple. It just literally forwards calls to the application contract in the case of mixer. Yeah, and the reputation contracts. Yeah, I can talk at length about this. I don't think I will right now if people want to talk about it. But there's an ETH research post that I published a very white hat on this. So you just Google or really just writing your research. You can kind of see our thinking there. Broadly it's like you know the more ether you've burned in service of life, in service of relaying transactions maybe the higher your reputation is but there's a lot of parameters that need to be there and it's something that will actually be cool. And so finally the next steps are you know a big part like what I'm trying to do is have to talk to a bunch of mixer teams talk to a bunch of wallet teams see how we can integrate this into like the existing flows and also talking to the gas station networks and some other kids and turn that structure into cool. So that's me on Twitter at the top and that is where the repo is for SIRGA. Probably have a lot of time for questions. How do you project the front runners? What do you mean by for like the relay or any front runners from someone else? Yeah, so like in events in your design how you pay back the relay for the service. So if I submit a transaction as a relayer as a relayer and if you're returning the message to them then they're front runner because he sent the device together because he wants to reach front runner. There's sort of a trade-off between yeah something we've thought about a lot. I think the easy answer is you'd expect that to factor into the fee market because it's kind of part of the constituting business of running a relayer. No, but like how do you protect? Because on the first day when we launched the undercatch we even thought about that. So we got front run on the first relay. Sorry, who got it? So then we on the first trial we managed to do that. So we got front run right away so that's why we were like ok, so we noticed the problems so that's why in ZK it's not approved. Oh, I see what you're saying. Well like the, so I didn't really go into detail this but the address of the recipient goes in the preview. The address of the relayer. Yes. So because the address of the relayer is one of the inputs in ours. Ok. You can't front run. I didn't know exactly what you're talking about but you literally can't front run. I understand that. Ok, so you're using the same production. So that means you have to design a smarter track in a way that would decode the ZK approval to prevent front runners. Because in that approval you have to have the address of the relayer. That's right. And so that can exist in the proxy contract. Or like the thing that it can. Yeah, that's right. Yeah, that's right. So if I'm a relayer and I'll be like, I say I'm a relayer in front of action but I don't. What happened there? Yeah, so there's actually another interesting trade-off here. So like in designing client logic you can either broadcast to like every relayer and then relayer is kind of like our at-risk. Or you can broadcast to one relayer and then the client is kind of at-risk. And there's a spectrum of like choices and how you choose to kind of like like your broadcast strategy, essentially your retry strategy that lie along that spectrum. We are opting towards in this implementation. This is an open discussion to protect the client experience. So the client logic by default will try a ton of relayers. And like retry. So like there's more, a little bit of risk that relayers get screwed. So they'll be competing effectively, right? So they can lose again. We'd rather push the competition to the relayers and make the little more expensive to them than make the client experience worse. But like the really, the way to completely solve the problem is just like start it to everyone immediately. But then the risk will be, we actually don't know who's mine. Yes. So that'll factor into. So yeah, again, there's a trade-off here. And fundamentally what happens there is that just factors into like the fees. So it's still, it's kind of, it's not convenient for the user. Yeah. It's paying for not having to waive. Yeah, Jason has the same problem. So I talked to them. They said, well, I propose an idea maybe if they have some sort of memples and the relayers can share the memples. So they like don't execute the same transaction. That's a nice thing I gave them. But then the obvious, well, there's a way to agree for this to just not share your stuff in the pool. Yeah. Then it's like you would have to have some sort of logic here. Or something. And the GSM, they want to have future memos. They just have a good one. So if you say that the approach you're going is that you will kind of broadcast the transaction. This is something I want to do to all of the relayers. So how is this going to work? Because every relayer, they can have a different fee, right? That they want to charge for them. No, basically the only one relayer will succeed. Yeah, I know, but I as a customer, I mean every relayer charges a different fee. And they choose which fee they want to choose. But then if I just broadcast to anybody, am I accepting like any fee? Or only the lowest one? Or is this by a range that I'm willing to pay? Yeah, I think there's like a bunch, like you might say there's some predicate you can define for each success and retry. And depending on kind of like how restrictive or not restrictive that predicate is, like how much you pay and how much your weight changes. It's like a filter program. Yes. How do you lose track of reputation in the system? Yeah, that's really tricky. Completely obvious. Yes. That's my short answer. One mechanism is to just kind of like have like the kind of naive mechanism that we've been thinking about starting with is just how it can participate. Something like that. Probably just burn, not use this on the right. But obviously that only distracts the amount of the membership fee times the number of people. Do you use a reputation as a mechanism to choose whichever you want? Yeah. But how then like the other like knew their wares will compete with their wares? Who's on the top already? Yeah. There is a tendency, yeah. I guess one thing that you could do, so right now, this is certainly a challenge. If you've been around for a long time, there's a higher chance that you could discover the future. Yeah. But one thing that you could do is have like some ability to kind of like react on your, like your entrance fee or something like that. Yeah. Or maybe like you can use a regular reputation mechanism, but not like every request would use that regular reputation points to choose anywhere. So maybe like, you know, I think you can do some randomness. Yeah. Yeah, you can definitely just put that, force that in the client. Yeah, that's basically the pitch from Alderaan. That's how they choose the client over to sign up next wall. Yeah. But we could just make some randomness in the client. Exactly, it's in the client. Yeah, that's the idea. Sanderizing that also. Yeah. I'm not sure what slide number it was, but there was like a reputation contract slide. Could you maybe still explain it? Yeah, yeah, yeah. So, I'm sorry. Yeah, so, again, this is, I kind of went over these a little quickly partially because we have our initial implementation, but this is something that we're exploring, swapping out, or maybe even like, proxying some other system that's doing a reputation like gas station somewhere. But what we've implemented is there's like a portion of each relay that you can choose. Fortunately, each relay or feed that the relay can choose can burn. And then the reputation shifts to a function of the number of times they've relayed and the total amount they've learned. And the most important question, is it about your role? Almost production. Almost production. It's very close. I'm left with no pressure. Yeah, of course. I think by the end of the month. Yeah. I mean, we're kind of like working with that, like you and the other mixed-air implementations like in lockstep. Since, I think, all like, depends on what you guys are already launched, what you're already launched. How are you... What do you think will be the biggest use of this thing? The fixer. Yeah. The big question. Everyone's sending money. You think so? Yeah. Like, when you send ease or die or whatever, wallets should just default and you're sending... I think that's like a little tricky, which is that the anonymity set is defined by, like, how much you're sending. And so the reality is, like, if you're sending, like, say, $10,000, you're probably not going to ever be a lawyer. I don't know what you're saying. And so there's going to be some, my guess is there's going to be some, like, multimodal distribution around, like, which specific, like, anonymity sets are, like, really popular? Well, I mean, the way I think of it is, like, you know, right now the way that, say, tornado catch words is that they have a specific use case, which is you're trying to disconnect the outputs from the inputs. So therefore you have to have, like, this enforced same amount on both sides so you can match them together. But if you look at, say, the Zcash blockchain where they have just a shielded pool that anybody can send any amount into and then send any amount out of, you know, your anonymity set becomes everybody who's ever sent money into the pool. And so they don't enforce, like, you have to send a specific amount in and a specific amount out. So people can send $10,000 even into the shielded pool and then send any fraction of that $10,000 within the shielded pool. And it's only if they decide to leave the pool that they might need to think about what their amount that they're sending out. Yeah, I think the shielded pool approach, actually I think this is what, like, this is broadly what UI Nightfall is doing, like, they're kind of creating, like, you know, who knows what they're actually going to do with it but they're kind of creating some standards around a shielded pool contract. I think that is useful for, like, I almost think of that as, like, a slightly separate segment of market thin mixers. My big open question there, and I don't have, like, a positive or negative kind of sentiment at this, like, a shielded pool gets, like, really, really large. How does that affect the gas cost? Is there a cap on how many shielded pools that scales up worse than market thin mixers? You can have, like, multiple shielded pools, probably with a fixed amount of laboratory participants, so that will not be, like, a very expensive internal gas cost. Like, once you fill in one shielded pool, it's not a new rate. Yeah, yeah, yeah, yeah, so, yeah, that's right. So you'll have segmentation that might be a smaller end, I guess, than a mixer, but gives you the option of, like, hey, so there's a trade-off there. Tony, to kind of, like, answer my opinion on your question, I think it's going to largely be people who want to move small amounts of ETH to interact with contracts or mattresses that are not as easy as their contracts. So I think it's, like, small amounts of ETH. I don't think it's going to be, like, large contracts or something. But, all of it, to be seen. Maybe people are betting in a controversial auger market, or setting up, but voting in a controversial vow or something like that. Right, yeah. Yeah, think about that. Keep back who answer, like, you will do RSVP, but you don't want to show the people, like, you have to do it. In Wasabi, I think it's mostly people that want to kind of, like, watch their clients and, like, associate their holdings from their real-world identity, that all of your answers weren't about that. Is there a reason why you don't think that's going to be the main reason, the main purpose for this? I mean, it could be a matter of, like, breaking the link between KYC exchange and every person on the wall. Yeah. That's a perfectly valid use case. Yeah, how does, does, you know, Wasabi has, like, how does Wasabi segment based on, like, the amount you want to send? They have fixed amounts in which you can send. They don't have fixed amounts, but they will tell you how good you're at it. And how they may use that as, based on how much you want to fix. They do have fixed amounts. It's a little point, one good point. Oh, sure. Yeah. But you can choose to mix, like, whatever content. Great. We'll break it up into .1 chunks. Looks like a matter of time, so we'll have to take the tables. Okay, sure.