ZKPodcast: Trusted Setup Ceremonies Explored

Transcript

Welcome to Zero Knowledge, a podcast where we talk about the latest in zero knowledge research and the decentralized web. The show is hosted by me, Anna, and me, Fredrik. So, before we start in, I want to remind our listeners to check out the Zero Knowledge YouTube channel to find the ZK Summit videos and the ZK Study Club deep dives. I also want to mention, like I did last week, that you should be sure to subscribe to ZK Mesh newsletter, where we share a rundown of new research every month. So, yeah, check that out as well.

Now, this week, I'm doing sort of a special episode. I wanted to explore the state of trusted setups. There's not one particular project that can necessarily speak to all of the trusted setups happening. So, I broke this episode into four different interviews with four different individuals from four over- overlapping, but different projects. And I think through those interviews, I've had a chance to better understand what a trusted setup is, how they've evolved, what makes them still quite a challenge, and what they aim to accomplish.

Now, I think it's kind of important for this episode to give a little bit of backstory. The most famous SNARK-based trusted setup that you may have heard of would be Zcash's initial Sprout trusted setup. And I think one of the reasons it's the most well-known is there's a RadioLab episode all about it in detail, where they go through kind of step-by-step what it meant to run a trusted setup at that time. They were definitely a trailblazer in that regard. Now, we had a chance to speak with Zooko for the 50th episode, where we actually did get a chance to talk about the second Zcash MPC ceremony for their sapling upgrade.

And I'll be sure to add the link in the show notes to both of those episodes. Now, for this episode, I actually wanted to speak with projects that have been running kind of the new generation of trusted setups and explore how these teams are learning from each other and at times even sharing parts of the trusted setup itself. So, as a primer, the trusted setups are those events or ceremonies that SNARK-based systems need in order to generate the parameters that can kind of like kick off their systems. It's an MPC or a multi-party computation that involves a number of participants, ideally some that don't know each other or have no affiliation. Because, like we know about MPCs, if even one of the participants acts correctly, then the

security of the system is maintained, whereas if they all collude, then that security can be undermined. You'll hear me kind of learn this through the interviews, but it's worth saying kind of what a trusted setup looks like. So, there's a number of participants. One at a time, they download software, run a computation that includes some randomness that potentially they generated, and then they re-upload their results to be folded into the next participant's computation. At the end of this process, there is a hidden parameter that can be used to create the keys that are used to create proofs for private transactions and to verify those proofs. And these keys prove that a transaction is

correct. This is this whole like why SNARKs can be used for validity. So, so far, there haven't been many of these trusted setups ceremonies, but the frequency of them has increased over the last few years. And so, now there's a good pool of people who've put these together, and you can see that there's sort of variation depending on what the purpose of the SNARK is, what the project's all about, um when you look look them. So, I start with Wietse from the EF. I then speak with Tom from Aztec, Brecht from Loopring, and finally Kobi from C Labs and the EF. So, I hope you like this format. I hope you like these interviews. It was really fun to do them.

And um yeah, at the end I kind of will come back to share a short summary of what I learned. So, please enjoy. Let me just introduce myself. Um my name is Wietse. I'm from Singapore, and I'm a software developer with EF's supply chain security team. And so, how this started is that last year I was looking for a new job after uh leaving ConsenSys, and I had a friend who was working at the EF, and she knew this person called Barry Whitehat.

And Barry has really great ideas when it comes to zero-knowledge proofs on Ethereum, and he needed someone to work with him to build those ideas out. So, uh the first project was like a prototype of a mixer. Before that, I had already sort of experimented with very simple ZKPs, and those are not super like important projects. Those are just like toy side projects I did on like during the weekend. And I thought, yeah, that might be a good start. Um and so, I joined Barry's team and worked with him and Kobi Gurkan on this project called Semaphore.

So, you started from Semaphore. In So, in the EF, there's these two trusted setups that happened as far as I can understand. One is this Perpetual Powers of Tau, and one is this Semaphore trusted setup. Are they the same thing? Are they related? Right. So, they are related, but they are different things. So, we should start with the Perpetual Powers of Tau. Cool. All right. So, just to give a big picture, in any ZK-Snark setup, there are two phases. There's phase one and phase two. In phase one, it's something that any ZK-STARK circuit can share. So, the output of that phase can can be shared by Tornado Cash, by Semaphore, by Macy, and other projects. But, phase two is like the circuit-specific trusted setup.

So, Perpetual Powers of Tau is like a single phase one setup that's as large as possible and which goes on into perpetuity that any project can just use at any point in time. And then, they can branch off from Perpetual Powers of Tau and run their own phase two circuit-specific setup. Got it. So, in this way Perpetual Powers of Tau is like doing a service for everybody. So, everybody doesn't have to do their own phase one. They can just use a common phase one and then do phase two. Cool.

Let's Let's start in on that Perpetual Powers of Tau. So, this is an initiative from the EF. I totally get this. It's like the idea is you're going to create something that can then be used by other zero-knowledge proof systems if they decide to do this phase two. So, you're doing the phase one. What does the phase one produce? Like, what are you trying to accomplish with this? Um so, we are trying to produce Like, what's it called? Is it a It's a number. Yeah, there is a number and it's um defined in the paper that I can link to you. Basically, it's like a multi-party computation producing a number.

Got it. And the idea is that you can have multiple participants take turns to add entropy to the production of this number and only one has to discard the toxic waste for the whole thing to be secret. This is this whole idea of like if everybody in the multi-party computation colludes, then you could screw it up. But, if even one provides true entropy then it will be a fully I mean it I think the goal here is to get a fully random number in a way, right? That's how I always think about it, but I might be wrong. Yeah, I would have to refer to that paper to get I guess super precise answer for that.

Okay. But I think it's a good way to think about it. I'm hoping actually through this the interview series that I start to like have a better view of what what exactly that in between is. Okay, so now like about that setup, what what did it mean to do it? Like so I get that there's a goal. You're trying to create some number that could then be used in these step two trusted setups. But what is what is the process like to set one of these things up? Like what do people have to do? All right, so the most important thing to keep in mind is that if you are participant, you need to download something that's 97 GB large, run the computation that could last a whole day, 24 hours or 15 to 24 hours, and then you need to upload a 49 gig

file to a server. So that's the um that's the challenge. That's like what a user would have to do to participate. Exactly. Yes. Got it. So what we've done is that we have a Azure cloud account and we store the files in Azure blob storage, and we also have a VM on Azure VM to produce the challenge file, which is the large 97 gig file that we send to users or or that users download from us. And then we have them upload the file after they computed the response to an SFTP server that we set up.

And then we publish the hashes of the files as well as the user signatures of the of the attestations to the of what they've done. And we publish this this we call it transcript, and we publish it to GitHub, and we also back up the files to IPFS. Um meaning a hard drive that I run in my house. So, it's not really It's not really fancy, but it's there. Cool. Yeah. And each time so each time somebody downloads this and runs it and then produces this giant file that they have to upload like you can't have people doing it at the same time, can you? So, whatever they upload needs to be used by the next participant.

Yeah, exactly. So, it's uh strictly sequential. That's why we have a central coordinator. This person used to be me, but I've since sort of outsourced this job to someone that I found online to help me out with. Um and we have a Telegram channel that we use to coordinate with other participants. So, you don't have to sort of sign up. You You can just reach out to me. We'll add you to the to the Telegram group, and then you can liaise with other participants and the coordinator to find the right time slot. Got it.

really informal. There is a degree of centralization here, but cuz we publish everything on GitHub, basically the transcript is something that anybody can verify if they if they choose to download all the files and run the computations. And audit. the only thing we can do is censor people, but that's why you have to trust us to not do. But if you want to fork it off and run your own ceremony, uh be my guest. Yeah. Okay, so so this is how like in here I sort of see a few role or a few kind of groups. There's the Telegram group where you just get to know other participants.

You have this role called the coordinator. So, is the coordinator So, I always think sometimes is the coordinator is like some technical role, but it's also a person, right? It's like Mhm. Like what do What does the coordinator do? Uh the coordinator has to reach out to potentially interested people to take part and invite them to join the Telegram group. And then do the scheduling, and they have to also provide them the URLs to download the files from. They also have to set up the SFTP servers to allow them to upload files back to us, and also make sure that we've backed up the files somewhere that in case we lose access to them.

Does the coordinator have to like okay I'm I'm just trying to picture how this would work. So like say you have a pool I'm going to make I know that it's perpetual so it's ongoing. I know that it's like many participants but say there's five participants to start. Yeah. The first participant downloads the thing, runs this computation, uploads the thing, then passes it like this is this is the point where I guess the coordinator comes in. Like who decides or like how is it decided that that participants data that they're uploading is now fed into the next participant? Like is that all automated in the the actual system or It's it's pretty manual because it's so large.

It's manual. Okay. Yeah. What we do is we once we receive the file through SFTP and we basically transform their response into a challenge. So we have to run the computation too that takes like 12 to 18 hours. And then we upload that to SF to Azure blob storage and then give the next person the URL. Oh wow. So it's like really tedious. It takes a lot It doesn't take up too much time because it's just have to run a few commands in the cloud but you have to keep track of it every few days. Okay. Yeah. Like the coordinator like is that automated though or like would the coordinator have to like actually start like download the thing, start this process, upload the thing?

yeah for perpetual powers of tau it is it is not automated. It's manual. Oh wow. But for the semaphore trusted setup it's pretty much automated. Cool. So you found sort of a way to Yeah. Make this a bit better. Do Do you think it's because it's a different part of the ceremony or do you think it's because the whole concept of trusted setups is developing and people have been building more tools? For perpetual powers of tau is meant up because the file sizes are so huge Okay. that we didn't really invest any time into writing scripts to automate this.

Running the computation itself takes like 12 to 18 hours so you don't really get much benefit in automating the thing because like it's going to take so much time anyway. Mhm. So how long has the perpetual powers of tau been running? Uh we've been running it since late last year. The first response was posted 9 months ago. And we have 37 responses so far. So you've had you've done 37 participants? Yes. Okay. So there's been 37 participants in this perpetual powers of tau. Can anyone still participate in it?

Yes, we are still looking for participants and anybody is welcome to get in touch with me and we'll add you to the Telegram group if you'd like to join. Would there have been people who participated then like longer periods where nothing was happening and then somebody participates again or do you feel like most of them happened right at the beginning? That's a That's a good question because uh at the beginning there was like it was a pretty quick pace because we had just started. I think there was a bit of a lull around Def Con Def Con 5 because we were all busy and traveling.

Yeah, sometimes there would be delays because of participants not getting back to us uh they might be traveling or they might be busy. I think things picked up and it got faster once we started using Telegram to schedule slots and time slots and once I found someone to help me out things were even faster. Cool. Which curves did you actually use? What are the the curves? I think it's BN254. That's what everyone uses. Yeah. Cool. So now I think what we should talk about, let's talk about uh Semaphore then because this is the part two of this trusted setup. So like what did you have to do for the second part and how

did you design it? All right, so let me just give a really quick background on what Semaphore is. Semaphore is a ZK-SNARK circuit and Ethereum smart contract which allows you to prove that you're a member of a set of identities in zero knowledge. So you could use Semaphore to create a mixer or you could use it for private voting on DAOs or you could also extend Semaphore to do things like rate limiting. So Semaphore's trusted setup is phase two of the of the trusted setup and we take a point from the phase one Perpetual Powers of Tau and that's where we started. So we got the help of Brian Gu from he's an undergrad at MIT and he

worked with us to fork Aztec's Ignition trusted setup infrastructure to work with the Ethereum base ZK-SNARK software to run phase two of trusted setups with the same command that you can use to run Aztec setup. Cool. So if you recall Aztec used like a Docker image and you had to give them and you had to run it in your command line and it would just download the trusted file and upload a response automatically Mhm.

it had a really good system of uh queuing participants. They didn't have to be online to take part and the whole thing was basically really well done and what Brian Gu did was take that system and modify it so that we could use it. And so Cool. Yeah. So that made things really easy. This trusted setup takes less than five minutes to complete. So it's like it really benefits from automation. And uh he's done amazing work. And we are still also looking for participants. So, if you're interested, I would please get in touch and we can uh get you set up. Cool. Do you think that Does it also have its own Telegram group then? Or is that part of the original uh Perpetual Powers of Tau

group? It has its own Telegram group. It's called the Semaphore Society. But, because there's less person-to-person interaction, you can just get in touch with me and I add you to our if you want to add your whitelist. You can also participate anonymously by going to our setup guide and you can pick a random private key from a list of private keys we've listed that are whitelisted to participate. So, you don't need to sign up. But, if you have registered with us or if you have already run the Aztec initial setup, we've gone ahead and taken that list of addresses and whitelisted whitelisted those addresses.

Cool. So, you can do both. Do you know participants that did both? That did both Not not the Aztec and Semaphore, but rather with the Perpetual Powers of Tau and Semaphore? Like, do you encourage people to do both of those things? Or do you think they should just run one? I think they should do do both. I think there's no harm. I think the the the the more the merrier. Cool. Yeah. Is there like do you for that for the Semaphore version, do you do you have just like a website where people can and do this interaction? Because I know that like on the command line, not uh not through a website.

Got it. Yeah. Is that also perpetual? Or does that have a timeframe? Does that have a time limit? Yeah, it does have a timeframe, but we haven't really figured out exactly when we'll end this. Um I think our current So, our current thinking is that we might wrap it up once we hit 70-something participants, which is around the same number that Zcash had. So, I think if we get that number of Yeah, I think we're happy. Okay. haven't really decided yet. And how many are you at with Semaphore? Uh 40. Cool. Yeah. All right. Well, thank you so much for sharing some insight into like what it is to coordinate and run a trusted setup and some of the nuances that you have to think about when you're creating these or coordinating them. Yeah, thanks

for having me on. I'm Tom Walton-Pocock. I'm one of the co-founders at Aztec, the Ethereum privacy network, and we ran at the end of last year the Aztec ignition ceremony, which was uh run over the BN254 curve. I was wondering about this. So, this trusted setup often trusted setups will have two parts. First part, second part. Is the Aztec both of those things or is it one or the other? No, Aztec didn't need so-called sealing steps. So, the structure of our CRS is actually kind of mathematically very, very simple. It's quite universal and it's actually designed to to support uh universal SNARK structure. So, we had just one uh

type of computation that everyone ran in repetition one after the next. What else would you say is unique about the Aztec trusted setup when you think of the other trusted setups out there? So, I guess there are a couple of things. Uh first of all, I mean, being on BN254 isn't exactly uh unique, but it's where we decided to start. As much as I think it was doing programmable uh privacy, you're you're uh really hurting pretty much everywhere in terms of kind of computational overhead. So, we're starting with BN254. Um it's certainly conceivable that at some future point we may go to BLS12-381 or another curve.

Um the other thing I think that was notable about Aztec is that we had managed to keep our reference string uh relatively short. We were doing this with a view to not just serving our Aztec one protocol, uh which is actually a fairly basic range proof, but also to supporting the Plonk SNARK and Plonk recursion. And there are various reasons why we don't need a level of complexity. We don't need a uh uh uh a long reference string. And the great thing about this, we had actually 100 million points in our reference string. The really great thing was it meant we were able to pack in a lot of people over a relatively short time frame. So, certainly for now it's the most extensive MPC setup that's ever been run. Maybe at some point that will be usurped. For the moment, this has had

the most distributed and large number of participants. How many people were participating? So, from around 600 sign-ups, we were able to accommodate 202 participants who actually ran the software. Of those 176 were valid. So, we had some one or two very spectacular timeouts where people were running presumably a Nokia 203310 or something. I don't know what they were running. And managed to timeout. There were others. We had one case, a manageable case from America where the the individual managed to to run the the software twice and ended up with validation failures. So, that meant that we ended up having 176 participants in all.

Those participants were mostly members of the the public. Most mostly members of the Ethereum community. And we also had major blue-chip tech companies, some blockchain infrastructures, high-profile individuals from from blockchain who all took part. So, that's 176 in all. How long did this trusted setup actually run? So, it took In the end, we planned originally to run it for 30 days. And in the end, just to make sure there was no question that someone hadn't been able to take part when they really wanted to. In other words, if their computer was still online and they were somewhere in the priority queue, we wanted to make sure there was no question that we had cut

people out. We then followed that So, that was that was month one. It went went on, I think it was just over five weeks. And then we reserved about two to three weeks where you know institutions needed to know we're on at this time because the way that we'd structured the public queue there was a kind of there was a dynamic element to it where you had to be kind of on online at the right point and the priority person in the queue to take part. Obviously that wasn't really acceptable for institutions. So we time table them and so we didn't get the same sort of density of of of of computation that we got in the first month when it was the public list.

Can you Can you kind of explain what a user or like a participant would have like done? How they would have engaged with this? Yeah, so we we did this all through Docker. So they kind of downloaded Docker and they ran this thing on their machine. Um The actual generation of the toxic waste was done by most people using randomness generated on the chip. So the level of kind of active engagement if you decided not to not to bury into the code and and and go and generate your randomness yourself. It was actually somewhat semi-passive involvement. But you know for those who really cared about the source of their

randomness, really wanted to make sure that you know that the various chip makers I mean they would all have to bear in mind if colluded in order for the for for the randomness to be even potentially leaked. But we made it an available option to people to inject their own randomness if they wanted. And otherwise the way we tried to kind of improve a sense of engagement was that where IP addresses were available. And of course a lot of these people were privacy conscious running VPNs etc. So So so you weren't always able to establish where where they were from or you know like they were coming from a different place. But we had a NASA generated simulation of the globe. So you could actually see this packet of encrypted information this transcript traveling around the

world. So every time it moved from one person to the next via our coordination server, uh you could see it move from country to country, from city to city, in fact. And I think that was quite a quite a useful way to kind of get get the attention of the community and and to to feel you were you your participation was being actively actually seen, actually watched. And the the globe would then zoom on on your particular in in on your particular location uh to show where you were computing from. How long would a one per like one participant have to have run this? Like, was it a an hour? Was it multiple hours? Like, what are we talking? It we gave a pretty wide uh the estimate we gave people was between two and six hours. I mean, there were there were some people, as I say, who

managed to they were on course, you know, to take days. Um and that was difficult. We did have technically a I think it was seven or eight hour timeout on this thing just because we wanted to pack in as many people. We didn't want one person kind of hogging all the time. But there were a few cases where people were really keen to take part, but they said, "Look, sorry, my computer's slow." So, we did actually lift the lift the cap for them. And then we had uh the institutions tended to run quite fast computers. So, generally, they were at the the lower end of that time. And we had one who clearly wanted uh wanted the the gold medal, who managed to to do the computer in a in a a really fast time. They did it in uh 30 minutes eight eight seconds was

the the time for them. So, don't know what they were running, but uh nothing nothing ordinary. Average compute was we think around 3 and 1/2 hours. Cool. Was each So, each participant would have had to go one after another. How was the transfer of the sort of toxic or I don't know if it's Do you call the toxic waste the thing that you transfer over? Or what do you call that? No, and it's really important that you don't transfer the toxic waste. So, um when you when you kind of I think the best way to sort of describe it is we you have this um so, you obviously have this, you know, this universe of elliptic curve points.

And when you kind of raise an elliptic curve point to the power of some number which you don't want anyone to know, the whole basis of all our cryptography is you can't back out what that number was. So, the toxic waste itself, which is the raw number used to generate this list of points, uh is is never leaked. In fact, it's emphatically important that it's uh destroyed. But, you only require, by the way, one person to destroy it. Once you then hand the the the modified transcript, which is now got your toxic waste in as well as everyone else's who's already taken part, that's no longer toxic waste. That's just a a list of uh of elliptic curve points. And it went via our coordination server, which we were we were running from London. So, yeah, it was it it went via a server, but the the

really important thing here is you could always validate uh that your piece of information had been rolled into this transcript. So, that's obviously really important to be able to kind of check that that we can't manipulate it, we can't do anything to to kind of secretly put a back door into the system. So, you kind of explained so, somebody would download or they'd use Docker to run this Mhm. computation on their computer, and then they would res- they'd have this piece of information that I guess doesn't really have a name. I've heard it referred to a few different ways, but like piece of information then goes on and is transferred to the next participant, right? It's brought into the next participant's computation.

Who did that and how what did that look like? So, do you mean the the bit of information that that you as a participant inject? Yeah, so so so you take you take we call this thing the trans- we call the uh the you could you could in theory at any point during this process you could freeze time, and you could say, "Look, we've done enough. The transcript is now what we call the CRS." So, what I refer to as the transcript is the really the CRS and could function at any point as a CRS. Uh if you didn't want the What does CRS stand for? So, a common reference string. So, this is the kind of the All this is um and it's the whole uh it's kind of the the mathematical framework on which SNARKs are based is it's a mathematical shorthand. Uh these

are little points which essentially allow you to reduce down the the the size of your proofs based on this mathematical shorthand, based on this mathematical ladder. And that's what the whole point of doing this ceremony is. It's all about kind of gaining efficiency. So, you know, you could use, for example, STARKs, but you the reason we do this is is some efficiency gains, but of course it's a trade-off against doing this trusted setup. So, the CRS is the final mathematical ladder that you end up with of this 100 million points. And each person is is taking 100 million points from the previous person. And each of those points contains some power of the the toxic waste that they've generated.

And in fact, more than that, some power of the toxic waste they've generated and what everyone else has generated as well who has preceded them. So, we call that the transcript. You then create this raw toxic data of your own. You roll that into each of those points in a completely sort of consistent manner with how everyone else has done it. So, the way I actually I take my first point and I roll in my toxic waste to the power of one, and I take the next point and I roll in my toxic waste to the power of two, etc. etc. all the way up to 100 million. And then those points essentially have sealed in my toxic waste, and I must then extinguish that toxic waste. Now, when we talk about the total toxic waste that's gone into the system, which is a

secret number at the heart of the transcript, that's actually only reconstructible from the product of your toxic waste, my toxic waste, the next person's toxic waste. And so, only if all of us collude to reconstitute that raw number, can the the toxic waste be exposed and therefore proofs faked. And this is why if even one participant doesn't share their toxic waste, you would not be able to reconstruct the overarching toxic waste. Precisely. In fact, it was it took a while to kind of get the the analogies right for for sort of explaining why this was okay and you know, just you being there is good enough. And we did actually have one bank who who backed out because their

I believe it was their compliance team couldn't get their heads around why this thing should be secured just on the basis of that one bank's involvement. So, it was a bit of a shame, but yeah, I think our I hope our kind of analogies improved as we as we went on with these conversations with the with the with the blue chips. I want to understand a little bit better that transfer moment. So, from one participant to another, you mentioned the coordinator server or the coordination server. Is that in previous or in other trusted setups like a person that you automated or what what was that? Yeah, it was just it was a server. It was a computer running. It was it was I mean centralized, but I I should caveat this with as I say, it's not possible for anyone, us nor anyone

else to to to to manipulate. You know, if we tried to manipulate the transcript as it was being handed around. So, it was always a star-shaped thing. We sent it out, came back to us, we sent it back out again. It was just the easiest way to connect everyone up cuz we had to make sure we were ordering the queue correctly so that we could always slot in the next person fast. But yeah, it's simply a matter of sending sending the points out. We actually did it in packets of 5%. So, if you were running the ceremony, you would see the first 5% of points kind of downloaded, you generated your toxic waste, you started rolling them in, the next 5% next 5%, and then when we sent it back out, we'd send it back out in 5% chunks. I guess that made it a bit faster. Yeah, it just

meant you could get going straight away. Exactly. You could start the computation straight away rather than relying on all 100 million points coming to you and then all 100 million points going back. But was the coordinator a a person? Is that a Is that a Is that like a an individual who's sending the stuff or is that a program? It was it was actually fully automated. The the behind it was one of our senior engineers, Charlie Li, who built the server and also spent a weekend. I just kind of had this idea that we were going to be able to see this transcript go around the world. And I think my my ears looked so floppy at the idea that this might not happen that he then very kindly spent a weekend cribbing a version of NASA's globe to make this thing happen. And it was, I have to say,

spectacular. Dare I say it myself, it was amazing. And yes, so he built that. He built the coordination server. For the first, obviously the first week we were we were really worried. We we thought, you know, the optics would be really awful if this thing froze. So, we did have pretty well 24-hour coverage from amongst the team. Arno Schenk, our CEO, did a huge amount of kind of, you know, late nights, early mornings, often going right the way through the night to make sure everything was was was up and running. And then as we went after about a week or so, we thought, right, you know, we've got we've already got a serviceable CRS. So, we then started it and and we trusted the server was was behaving well.

Cool. What would you say influenced the design? Like what I mean, I think the most famous trusted setup ceremony still remains Zcash. But I'm wondering if like what other trusted setup ceremonies or maybe even other events, like other types of things influenced the design or the thinking around this one? Or do you feel like it was pure cowboy country and you had to define this all on your own? No, I mean, look, I mean, so it's The first thing to say is is kind of I think the the language of of this stuff was was all completely normalized by Zcash. I mean, Zcash blazed a trail here by by doing this.

And obviously they they'd already done a setup twice by the time that we we we ran ours. So, I mean, in terms of design, I mean, I think the visual I think was was somewhat original. Giving people a way to see this thing happening live, I think there was definitely a bit of theater in that that I think was novel. And of course, for us very very important because it's really going to be uh consumers driving demand for privacy on on public networks. So, it was quite important for us to to build up a community in in running this thing and make sure that they felt that if they'd wanted to take part, the the opportunity had been there. And by the way, you'll see them all walking around in I was there t-shirts. It doesn't quite say that. It says ceremony participant t-shirts around when we when

we emerge blinking from the lockdown. There there are 200 odd people, well, not quite that, but walking around with these t-shirts. But I think yeah, I think I I think I think really um Zcash had had blazed the trail here and um and the only thing that was really different about ours was it was quite short, so it meant that we could attract people who were not you know, who'd be prepared to run their computer for a few hours, but not come prepared to kind of hand over the keys to their machine for two, three, four days. What was the when did this actually run? Uh November and December. Of 2019, I guess.

maybe it started in October. Yeah. Um yeah, it was it was it was Q4 Q4 '19, exactly. Um how did you wrap it up? Like what was the sort of end of the trusted setup? Did you just have a the the final CRS and you were like, "Cool." and then you just turned it off? Or like what happened? We turned it off. We actually we had a a contribution from the team which is you fundamentally does not in any way improve the um the the security the CRS at all. It was just kind of a rhetorical flourish really cuz we wanted to kind of bake the um uh the the names of all of the team members, we kind of hashed each of each of our names um

including cuz we hadn't actually told the world at that point that Ariel Gabizon was joining us uh as uh chief scientist. We nonetheless we knew he was joining that point, so we hashed his name and and put him in there as well. So, so that's what we did. But I mean, you know, because because you know, one could somewhat you know, back out what that toxic waste was by knowing the names of of the people in the team and sort of guessing the structure. It doesn't really move the dial on the security of the CRS, but that was the kind of the little flash. We we did have kind of visions of you know, hanging out of airplanes and taking photographs of uh taking photographs of mountains and uh and kind of you know, hurling computers from 30,000 ft which would have been spectacular, but uh in the end

uh in the end that's that's what we did. We launched we deployed the protocol eventually on on Brexit day. So, it was this really uh eerie eerie evening. We were all kind of staying quite late at the office and uh and there was sort of uh um a smattering of Union Jacks sort of drifting slightly alarmingly past the window. Uh yeah, it was it was it was a pretty it was a really strange evening to be to be deploying our network, but uh anyway, all these things got in the way and so sadly we didn't quite uh I don't think uh do the spectacular thing we we ought to have done if we'd had a bit more time. That's actually that that does in a way though um like that's that's actually a little part of the whole setup that I want to

explore a bit more which is so once you have this final CRS it you then use this to like unlock or turn on in a way the actual software, right? Like how how does that work? How is that actually delivered and incorporated? Right. So, I mean it's used in actually in two very different ways depending on whether we're talking about Aztec 1 or Aztec 2. And I should say Aztec 2 is not being deployed at this point. So, Aztec 2 is going to be based on Plonk, but um it's used uh in our in our first system uh to construct a Boneh-Boyen signature. So, it's used uh for range proofs and essentially the whole proving

system comes down to can you construct um a a proof that uh you have taken uh whatever number you're sending, seven ZK-Dai, 10-day KDI, whatever that encrypted number is, can you prove it sits inside a range? And the way you actually test it is you're looking for the DNA of that toxic waste. So, you use a pairing operation to test from the outside without being able to ever extract that toxic waste. You're testing is the DNA of that toxic waste sitting inside this pair of elliptic curve points. And if it is, then you can't have cheated because you can't have known that the the governing assumption is the waste was never issued. It was

never leaked. Uh so, that's how it's used in Aztec 1 for range proofs. And um in a not dissimilar way um in our universal SNARK systems, this is our kind of fully scalable, programmable privacy network um which will be launching later this year. Uh it's used in a similar way. You a kind of critical assumption of not being able to fake proofs is can we find the DNA uh of this um of this trusted setup buried inside whatever proof you're issuing. And the thing that it's you're only allowing for a succinct proof on the basis that uh no one got backdoor access to that to that toxic waste. But yet, somehow you're the DNA of that toxic waste is inside your proof. So, you can't have

cheated is the sort of the hand-waving answer. Cool. Well, thank you so much for this interview and for sharing a little insight into how the Aztec trusted setup went down and what you learned, what you found, and what we can maybe learn from that experience. Thanks a lot. Thanks. It was great to speak. I'm Brecht Devos. I work for Loopring. Loopring is a protocol for decentralized exchanges. We recently did a trusted setup for the protocol itself and more specifically for loopring.io and Widex.

Both exchanges are currently live on mainnet. How I guess you're using zero-knowledge proofs in there. How is How are ZKPs or SNARKs being used in the system? We have a setup that's basically Zcash roll up. So, I think it's been on the show quite a few times. So, we use roll up to help with the scalability. Maybe give me a bit of a run down of what your trusted setup process looked like. Yeah, so we use Groth16 with the curve of Ethereum. So luckily we could reuse a lot of stuff from other people because we are not cryptographers.

We kind of need to depend on other projects to do the math heavy stuff. So, luckily the Zcash Foundation started with the Perpetual Powers of Tau in September. And the Ethereum Foundation also funded Kobi Gurkan to work on the phase two which he modified Shon Bow's original code for Zcash to the Ethereum specific curve. And so, we were lucky that both projects were already on their way when we needed to start for our specific project. So, the Perpetual Powers of Tau were at participant like 10 or 11.

So, we branched out from that point out. And then we we did our project specific circuit specific trusted setup building on top of Kobi Gurkan's phase two code. That's interesting. So, the Perpetual Well, I think what what I understand you just said is the Perpetual Powers of Tau was I mean it's perpetual. So, it was run It was in the process of running. It continues to run. And at sort of like at a certain point you branched off from it kind of, right? Like you took what was there and then you ran your part two or second What did you call this? The part second part?

Phase two, yeah. Phase two. You ran your phase two of the trusted setup after that. Yeah, exactly. So, at some point you have to branch off of the phase one trusted setup. And at that point you you can't like go back and start from a a later point of time because then you will have to redo the phase two as the circuit specific trusted setup. Got it. What like what did you actually take from that first from from phase one? Like what is it that you take away from it? It's the generalized powers of tau. So, that's kind of like just the general data that can be reused to run the final trusted setup.

So, it's kind of like the the randomness that's that that everybody generated, but that's hidden in the in actual final data. Okay, so you took this data from that specific part and you run it into your trusted setup, which was like a system that had been designed originally by Shawn, but was redesigned or re-implemented by Kobe. So, once you were running this you would then at the end of your trusted setup, what did you what what did you have? Uh yes, so at the end of our trusted setup we have a bunch of a verified keys and proving keys. So, for we did a quite a lot of circuits of different sizes of different batch sizes because

we we used the circuits for scalability, but yeah, we we can't always depend on like having that many traits available. So, we did like different circuit sizes, which have different costs for the proof generation. Uh so, we can just pick the the correct size for how many actual transactions we have to settle. So, at the end we have like the verifying keys and the proving keys. The proving keys can be used to generate the proofs and the The keys are set on the smart contracts, so we can verify the proofs Uh on chain.

Would you need to like at what point would you need to do a new trusted setup? Like will you ever need to do another one? Yeah, so anytime you modify the circuits themselves, so like even one single change, you will have to redo the the complete phase two of the trust setup. So the powers of tau we can still reuse, but the phase two we have we'd have to redo everything. Maybe uh something other that could be also be interesting is like how we get from phase one to phase two. So maybe I can talk a bit like about that. Sure.

Uh so um from the phase one we get like a bunch of uh REDEX files uh containing the powers of tau tau data. Uh but then the actual phase two code was written by Kobi and Belman for the Circom circuits. So Circom, yeah. Yeah, but our circuits are actually written in libsnark using ethsnarks. So we had like quite a bit of work to actually make it compatible with the Belman with the Belman code. So the work was to actually export our circuits from libsnark to the Circom format, so we could load it in Belman.

Uh but even then there was an incompatibility between Belman and libsnark, which made it incompatible with each other. So I also made a special branch for libsnark that made the Belman proving keys completely compatible with the libsnark proving keys. So we could We actually pass through quite a lit quite a bit of ecosystem because we start from libsnark, we go through the Circom file format, we load it into Belman to do all the computations, and then we go again from Bellman through a converter to get it back into a lip start compatible format. Oh, interesting. Wow.

That's quite a bit of work around happening there. Yes, the other option was to write it specifically for lip start. So basically to do what we did in Bellman to do it in lip start as well, but Yeah, because we're not cryptographers, we thought like it's better to have one good solution than have one good solution and one bad solution. So it's kind of like safer to just reuse what what was already available. Why are there two parts? Why can that not be a joint part? Like why can it not be combined?

Okay, so the the good thing you could do it in a single part, but by doing it in two phases, you actually save a lot of work for like in general because phase one can be can be completely reused by all projects. And so the phase two you have to do is like less heavy because you can just reuse that data. So it's like you save on computations you otherwise have to do phase two as well. And yet it's still 12 it was still 12 hours for that phase two for you. Yeah, but we had a lot of we had a lot of circuits too.

Of course we used the zero knowledge for scalability, which means we have like very big blocks and we also had quite a bit a few different circuits and at different sizes too. It's kind of like a special scenario, but even in that case we didn't go with like the maximum size. So the powers of tau were done until up to the powers of two to the 28. So we could do circuits up to around 250 million constraints. But we chose not to do that in our phase two because we already has had like this very big file people had to download and I already were doing this at like 12 already took 12 hours. So, we actually

we actually compromise a bit here by not doing the biggest block sizes possible like not the biggest circuit sizes possible, which kind of decreases our scalability a bit. So, like the maximum scalability we we could achieve by having the biggest circuits by just doing the circuits up to two to the power of 26, which is around 64 million constraints, which imposes a maximum of around 1,000 trades per block, which is a little bit less efficient than if you had gone with like the biggest circuit size of two to the power of 28, but then it would be much more

difficult even more difficult to do the trusted setup. Now that you've like done one, what's your kind of feeling about trusted setups generally? Do you think they're cool? Do you think they're here to stay? Do you think Yeah, what do you think about it? I hope they are not here to stay because it's not fun to run the setup setup. So, it's like especially for us because it was a lot of manual work. So, like new participants we had like one participant per day and they had to upload and download and I had to verify all the data and it was like very much a headache especially because now if you want to update the circuits, we we'd have to redo everything again.

So, even if everything is actually available now, it's still not fun to do it because we still take up people's time to to join and yeah, it's just it just makes things more troublesome. A bit of a challenge. Nice. Well, thank you so much for coming on the show and sharing this experience with all of us. It was great to be here. Cool. I'm Kobi. I'm from Selabs and Ethereum Foundation. I work on applied cryptography in both. Mainly in the F I'm working in with the applied ZKP team where we do all kinds of snark stuff.

And in Selabs more general applied cryptography but also snarks. Maybe you can tell us which trusted setups did you work on? And I know from the previous interviews that I've done on this topic that your name seems to pop up quite a bit. So I'm curious to hear yeah, how like which ones have you worked on? It's good to hear because I did participate in in many of them. I think in most of the ones that were publicly executed.

So as a participant I participated in the Zcash Sapling setup in both phases. In the powers of Tau phase and in the phase two for the specific Sapling circuits. Later on I've participated in the Aztec setup and then worked to create a version of the trusted setup tools that are based on the Zcash and the Matter Labs tools that they created to do a trusted setup for both large circuits a powers of Tau for large circuits.

And then the goal was to have a phase two for the Semaphore circuits. Additionally I hope that I helped a bit with the trusted setups for Loopring and Tornado Cash ones so that we have the tools ready for for those as well. Did you like were you already at the EF when they were running the perpetual powers of Tau? Were you part of that as well? Yes. So while WeiJay did most of the coordination, we adapted the tools from the Matter Labs original code that that implemented powers of tau for large circuits.

And we adapted it so that it would fit our use case. And actually we fixed fixed some severe bug that was there. And afterwards we came up with how we're going to do the setup, how the coordination is going to work, and what circuit size we're going to make. And yeah, then we launched the perpetual powers of tau. And we So in a previous interview in this episode, we actually have already gone into it. So I don't think we have to cover too much about the perpetual powers of tau setup build. But what like in the EF itself, there's Semaphore that's like used that perpetual powers of tau at one particular point. I know that outside there's Loopring and Tornado Cash, but

are there other projects inside that use something from that perpetual powers of tau? Mhm. That's a good question. So as to circuits that are deployed, applications that are already deployed, I don't think there are any right now. But one that is planned is going to be MACI. Mhm. Or this minimal anti-collision infrastructure, which is also going to be a few big circuits that are going to be using the same perpetual powers of tau.

Cool. And what's the Like will you then for that actually run an entirely new trusted setup? Like you'll run phase two, I guess. Right, exactly. Since phase one is circuit agnostic, it can actually be used for any circuit up to a certain size. And by the way, it could also be used for Plonk and Marlin if anyone wants to use that for their setup. To use it for Macy, we would have to run phase two, which makes the SRS circuit specific. When you say sort of like it it can accommodate any circuit size, my question here, does phase one have to be for the same curve as phase two? Like like or or could you potentially do

phase one for one curve and then phase two for another? Yeah, it actually has to be for the exact same curves and exact same parameters, and you can't change those after you make phase one. And maybe maybe you've noticed that there were a few phase one that ran out there. There was the phase one for Zcash that used the BLS 12 381 curve, and there was the phase one for Filecoin that they ran for some time. And that was also for BLS 12 381, but it was for larger circuits.

And ideally, the team community could share this Filecoin because it's also for large circuits, but then it's a different curve. So, you have to run these two big setups with two different sets of participants, and you can't get around it. But you say you sort of said though that the perpetual powers of Tau is a large enough circuit. As I understand the phase twos, could they be smaller circuits than the phase one? Yes, definitely. The phase one is the maximum circuit size that you can support. Okay. And afterwards, in phase two, it can be for any circuit size that's smaller than that.

And this is why I guess why these like other projects who will have who may have smaller circuit sizes but using the same curves can be run just as like all the project would have to do is run the phase two. They can use something from the phase one. I guess it's actually maybe you can correct me here, but is it a common reference string that's transferred between the two phases or what's the word for that that thing? Hmm. I'm not sure what's the exact word. Uh yeah.

Terminology has come up a couple times through these interviews trying to come up with like how exactly to say them, but yeah. Hmm. Yeah, I'm not sure what's the exact word, but eventually, I guess, the result of phase two is the common reference string. Like so, I guess it's the sub subset of the common reference string. Is it just a long random number? No. It's a bunch of group elements. I see. Actually, it's called the powers of tau because it's exactly what it is. It is a powers of this tau, which is a secret number that nobody must know because if you know it, you can create fake proofs.

Um so, it's powers of this number hidden in the different groups, G1 and G2. So, it's multiplied by the generator of G1 and the generator of G2. And a bunch of other stuff multiplied by other random numbers, but essentially this. What does it look like? Like does it look like what what exactly comes out? What I understand, phase one like multiple participants go through it. At the end, you have this thing that we can't quite name. Some something that needs to be used to activate or to like set off phase two.

So, what is that What does it actually look like for an engineer? So, it would look like a vector of group elements essentially. It's a structure that contains a few vectors of group elements. That's what it would look would look like. It was It would be curve points. So, it would be either, you know, the XY coordinates or some compressed form of that. Yeah, anyone that can parse this specific curve that the setup is on, can load these and work with them and verify them and so on. Is it the same output from phase two? Like is it the same format? I know it's going to be a different different values, but like is that also what phase two outputs?

It's very similar. Phase two actually also works very similarly. It computes some elements. It just adds an additional additional information. Mostly another random number that um specializes this this structured reference string to the specific circuit. When you look into documentation around trusted setups, there's sometimes talk of like entropy sources and the participants actually adding randomness. And we haven't covered that yet, but maybe you can help me understand a little bit about like we've we've gone a little bit through the journey of the participants that they

download something, they run it on their computer, and then they upload their what we've been calling a common common reference string. But where does the entropy come in and how is that actually inserted? Okay, that's a good question. So, when participants participate in the trusted setup, they need to contribute these secret numbers or let's say random elements that are derived from a secret number. And in order to generate the secret, you really want something that is unbiasable or not affected by any source that can be manipulated and so on.

And so, you want to combine, let's say, some entropy sources. So, maybe you want to use your operating system randomness, and then you want to mash your keyboard a bit, or be like Andrew Miller that flew above Chernobyl, I think, and took some measurements with a Geiger counter. So, you can do all of these crazy things to achieve a really good random number that nobody can manipulate and somehow is Yeah. I mean, a lot of people wouldn't be able I I imagine a lot of people who actually participated didn't go out with Geiger counters and like get their own randomness from nature necessarily. What were they doing or was it automatically happening in the actual

computation? I think it depends on the setup. So, I mean, perpetual powers of tau you can mash your keyboard. You can add some randomness by just adding some strings. I think you can do the same in the Tornado Cash setup. I'm not sure about other ones. I'm not sure if Aztec had that capability as well. But to be honest, uh sometimes it's uh it's okay not to to go all the way and maybe just using your OS randomness and some extra random string that you put might be fine for all practical purposes.

I had heard about like in the Zcash I think Frederick actually told this this anecdote in a previous episode where he talked about like how he had a friend who generated some random number for a friend who actually participated. So, I guess it sounds like I mean, at least in the Zcash one they actually like some you physically add it in. Is that also the same for the perpetual powers of tau at the EF where you like as a participant you actually add it or is it sort of like where like at what point do are you prompted to add it? Do you have to add it into the code itself? So, yeah, you don't have to add it to code. You are prompted to add it. You have a You have like a a request, please input some string, and

then you put your string and you can continue from there. And then it gets hashed a bit, but that's okay. Is Is right in the middle of the process or at the beginning? At the beginning because you need to use it for every every other step later on. Cool. Since you've been Since you've participated in so many of these, like how how do you kind of compare them? I know or like not only participated but also worked on so many of these. How do you actually compare these? Hmm, that's a good question. Maybe I can ask you a few questions to help you. Yeah, that would be good. Okay, what was the easiest one to participate in?

Oh, the easiest one I think by far was the Tornado Cash one. Uh it's just using the browser and you go into their website and click contribute and you're done in a few seconds. That was really cool. Which one had the most like unique like design or like narrative? Hmm, okay. I think the Zcash Sapling one which was Yeah, which was one of the first setups that were open to the public. It had the most creative contributions where people really really went all the way and destroyed computers and uploaded pictures of of wrecked computers so that the

randomness is completely destroyed and and did all of all of these crazy things going to remote places and so on. I I have a broken computer here that I used for the setup. Yeah, of course. So yeah, I think that was the most creative one that had a nice community around it. The later ones that had manual contribution also did the effort of saying, "Yeah, we did this and we did that to to make sure that there are no side channel attacks, but uh I think they were a bit less creative or less motivated to do that. Which of all of the ones you've done was the most complicated to actually participate in?

Okay, I think that the one we did that we are still doing actually in the F with the perpetual powers of tau is the most complex in the sense that it's the largest one. It's two to the 28 powers. And that takes quite a few hours to contribute. So, between half a day and a day depending on your computer. Yeah. Um and that's that's a very hard to get participants that could pull through this.

And it was also a bit scary because this is code that we've adapted. Although, you know, we've not written this from scratch, but we still adapted it and there is a lot of possibility that there was some mistake and then we would have to run this setup from scratch and then it would be bad. Oh god. Well, I hope I hope that's not the case. Um Yeah. If say phase one had a problem, would that matter for the security of the end of phase two? Really? Yes. Tell me how. Okay, you have to have both phases to be independently secure.

Okay. So, if everyone was were malicious, for example, at phase one and the secret tau was exposed at some some way, then phase two would not be secure because this tau by itself can already be used to create fake proofs. So, that's enough. Mhm. And that's the same for phase two like you have to have each of them independently secure. So, what did you do? Like what was done then for that perpetual powers of tau? Like it sounds like it's the most complicated because it's it has like the purpose was so broad and general. But what did you do to mitigate any of that like security fear or security risk? So, in order to mitigate a lot of our

worries about this, we first uh asked a lot of people to put their eyes on it. Uh people who know what they're doing and and they can spot bugs and so on. And we also went to do an audit to to make sure that we're not missing anything else. And you know, just to improve our processes in general. Which came out pretty okay. Like there weren't any critical issues. We gain a lot of confidence by the fact that the verification algorithm that exists in the process is also pretty simple. So once you do the contributions, the coordinator also verifies the

contribution. And actually everyone should at some point verify the contributions if they want to trust this SRS. But the coordinator also does the verification. And the fact that this verification process passes gives us a lot of confidence that things are fine. Cool. Maybe you can tell us you can tell me a bit about like the present or like upcoming trusted setups and how they might be different. So I think in terms of what we do in the F with perpetual powers of tau and the phase two, I think we're pretty good shape. I think we can potentially be running more of setups with this process and these tools.

And one one improvement that we want to make is that the phase two, this automated phase two I mentioned before, would be supporting multiple circuits. So maybe in one process or one setup, you could do the setup for Macy and another project that wants to use this all of the same time. So if all of them for example have very small circuits, which is very common, then the setup would not take long and you would get the phase two for all of these circuits together, which would be really cool. Cool. Um yeah, and for the work we're doing in Celo, um we're going to launch our light sync protocol

at some point this year. Uh which would be using a setup on another curve. So, we need a new powers of tau. It seems like we're going to use this BW6 curve that the people from EY worked on. Cool. And that's going to be another big setup on a big curve. So, we have some challenges to to solve there before we actually do the setup. Because if you just do it naively, it might take a few days for each contribution, which is very bad.

So, we're working to to improve that. But essentially, that's another setup that I'm excited about. Cool. I just wondered when you said the BW, that's by the way, that's cool info. Um is that that's is that equivalent to the BLS to like 12 381 or whatever? Is it like is it replacing that or are they used are they both used? Uh so, the BW6 curve is using the same structure as the Zexe curves, which means that you have an inner curve BLS 12377.

And then you have a curve that can prove statements about the inner curve. So, you have BW6 as the outer curve, which can then involve operations about BLS 12377. So, it's this two-chain with this one-depth recursion. Oh, wow. This is This is getting sophisticated. Yeah. And it's it's wild to me that even in the trusted setup itself, the sophistication needs to also increase.

Even though like once the trusted setup goes through, it's like that whole process, I mean, unless it's perpetual, the The process is so some discarded. Like you do it and then it's over and then you move on to actually like using the system. Yeah, I mean this this might change in the future actually when people start using protocols like Plonky and Marlin because then you can just it's an updatable snark so you can just keep updating the the structure reference string and that might be interesting because then you only have to coordinate when you use the new reference string.

But it's it's maybe not a one-time event anymore. That's that's so cool. What it would you do you imagine like if that was the case that it would almost be like you could have a perpetual powers of tau running as well as like these updatable snark constructions. So you'd basically be like both perpetually changing slightly or would it still there'd be checkpoints? Like I guess. Yeah, I think practically it would still be somewhat like a checkpoint because you after you do this update to the to the structure reference string you still have to deploy it. So people on the chain have to agree that this is the new reference string and so on.

And so it can't probably be automatically updated but it can be updated every few months for example or by some vote mechanism but you have to put less trust in it. So the trade-offs might make it worth so Mhm. you still do it. Yeah. And I guess to conclude like given you work on these a lot but like are you are you also looking forward to a future where maybe they go away? I am hoping for a future like that.

I think that practically today what we know is that you can't have a completely transparent protocol approving a proof system that rivals the efficiency of those with a setup. So, I don't imagine that we're going to ditch them soon. I still think that Groth16 is going to be used and uh Plonk and Marlin and maybe half pairing Halo and stuff like that.

Um but completely moving to transparent systems, I think there are use cases that will do it, but it's not for every use case. Got it. Especially, for example, not for Ethereum smart contracts. Well, thanks so much for sharing all of this insight. Given the fact that you've seen a lot of these, I think it's really cool that we got a chance to talk to you. Thank you for having me. So, thank you to all of the guests of this episode. Um I want to summarize and compare a little bit some of these trusted setups. So, that early Zcash Sprout trusted setup that I mentioned at the beginning, that had a handful of participants, basically hand-selected by Zooko.

The next Zcash Sapling trusted setup had 87 participants for the first phase and 90 participants for the second. The EF's Perpetual Powers of Tau has 40 participants as we record, but they're they're still adding more participants. Loopring had 15. Semaphore had about 40. Aztec had close to 200. And Tornado Cash, a project unfortunately we didn't get to bring on for this episode, they but who we've mentioned a couple times, Tornado Cash is the biggest trusted setup to date with 1,114 participants. If you want to find out more about Tornado Cash, please check out an episode we recorded with them earlier this year. Um I am really sorry

we didn't get a chance to bring them on for this, but we just didn't get a chance to sync up early enough. But hopefully if we do a part two of trusted set state of trusted setups someday, I'll be sure to invite them back. Yeah, so I hope you like this. I hope you got something out of this. I think what I definitely learned here is that we see an evolution from sort of this handpicked trusted setup where it's very much a magical ceremony in a way to a far more automated larger scale type setup.

I think the more the more people participate in these, maybe the more they understand them. I think we can hear from the Aztec project that they've actually been able to get, you know, more corporate, more enterprise participants. So that's kind of exciting that like, you know, larger companies, people in larger companies are actually understanding what this stuff is and understanding why by participating they in a way contribute to its security. I think the takeaways also, I think everybody finds them a little bit annoying to do. And uh there's still a push to try to minimize them, make them faster, make them easier, uh and all that. So I look forward to the next batch of trusted setups.

If you're interested in participating one of these and actually running some computation, I would recommend you join our Telegram group. We're sure to to link them there. All right. So to our listeners, thanks for listening.