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.

This week I chat with Mikerah from HashCloak and Stoffel Labs. We cover how Mikerah got her start in the space, the work she did at ChainSafe working on an ETH 2 client, how she spun out HashCloak, a research consulting firm, and her work on privacy-preserving tech like ZK, TEEs and now MPC. We also had to mention her amazing Twitter game throughout the episode, as many people know her by her moniker, @badcryptobitch. We learn what drives the tweet game, but also the wisdom she has picked up over the years as a technical founder driven by curiosity and memes.

Anyway, before we kick off, I want to point you towards the ZK Jobs Board. There you can find job opportunities to work with top teams in ZK. I also want to encourage teams looking for top talent to post your jobs there as well. We have been hearing from more and more projects that used it that they have found excellent talent through the ZK Jobs Board. So be sure to check it out. We've added the link in the show notes as well.

Now Tanya will share a little bit about this week's sponsors.

Today's episode is sponsored by Aleo. A new era of decentralized, privacy-preserving computing is here. Aleo, a Layer 1 blockchain powered by zero-knowledge cryptography, recently announced their mainnet launch. Now developers can build applications that take advantage of Aleo's unique combination of permissionlessness, programmability, and privacy. Start by learning their domain specific programming language, Leo, write and deploy your first ZK application at leo.lang.org or head on over to aleo.org to learn more about their technology and what you can build. Aleo, this is zero knowledge without compromises. So thanks again, Aleo.

And now here's our episode.

Today, I'm here with Mikerah from HashCloak and Stoffel Labs. Welcome to the show, Mikerah.

Hello. Thank you for having me.

Yeah. So the first time we met in my memory was at Devcon 4 in Prague.

Okay.

Jing from Plasma Group at the time introduced us. We chatted a little bit about the Bulletproof episode, which was very cutting edge at the time. But yeah, this stuck in my memory, but somehow when we met again, you didn't remember.

Oh, I'm sorry.

So I guess this was before I was famous.

Oh, no. It was a little bit before you were famous.

I mean, I was famous for people working on infrastructure layer stuff like ETH2, but I wasn't famous everywhere.

In ZK.

Yeah.

I was looking into it.

Okay.

However, at that point, I didn't have the mathematical maturity to understand the papers I was reading. This was around the time when the Sapling upgrade came about, for Zcash, STARKs had come out. But yeah, I hadn't really taken the coursework to understand a lot of that math. So a lot of it was hard to read and decipher. Yeah.

Yeah, makes sense. But let's go back a little earlier. So we're talking about when we met, but your story in blockchain had already started. Let's go back to what got you first interested enough to jump in.

Right, so to jump in basically, this professor at my university organized a talk by Vitalik and this was during exam season and I should have been studying, but you know, looking back at it was the best decision I did. And so I went to this talk by Vitalik. It was about crypto economics. He's given this talk a few times. There's a few talks recorded on YouTube. And afterwards I walked up to the professor and asked if I can be a research assistant for the summer. And then that's how I actually got started. Before then, I just had heard of crypto. I played around with some of the tooling, I played around with Myst, but nothing actually involving other people, just as a hobby.

What era is this? Or time frame.

Okay. So you're working for your professor for a period of time. How did you then, because I know you worked at ChainSafe, like pretty soon after that, what was that transition like?

Yeah. So during the summer, we worked on this project, and somehow ChainSafe got involved in this project. I think they were meant to be like development partners in some way. Honestly, I don't know the story myself. I just remember going to one of the meetings and then ChainSafe folks were there. And so that's how I got connected to them. And then for the next year, they invited me to work there. And based off the previous summer of doing research. So basically I was doing research at ChainSafe for about a year and a half. And then while there, that's when I started Lodestar, which is now like the typescript Ethereum 2 client, but back then it was in JavaScript and it was poorly written by me in this, like -- yeah, there wasn't much, right?

Less and less interest in studies, maybe.

Yeah, basically. But I kind of --

But it's probably -- it's good you did it, though, right? Like do you feel like it still gave you a bit of a foundation?

Yeah.

Like an important foundation?

Yeah. Like, I chose my majors because I was interested in cryptography. So I don't regret going. I just -- like I can go off and I pursue something that nobody else can pursue or I can continue pursuing the current thing. So it just ended up being a very unfocused semester for me. But the nice thing that came out of the semester is I went to Devcon. That was the first time we met with other Ethereum researchers and developers from everywhere. Anybody who was attached to, in some way the effort of building Ethereum 2 was there. And then a little bit after that, I had to go back, finish my finals, stuff like that.

Did you feel on the fence at the time? Were you kind of torn? Because you were doing a lot of this other work, but I guess you like -- it wasn't like full-time work. You couldn't fully commit to it, but you had this school. Yeah.

I mean, yeah, I was torn because it was like, towards the end anyway, and at that point, my grades didn't matter that much and I had like an end to grad school. So basically I just had to maintain grades for grad school because I was planning on doing research into grad school on blockchain-related stuff anyway. But I was already working on research. I was getting paid to do it. I had met all these people in Prague, so it felt like I was already kind of there without being paid poorly because grad students aren't paid well. And so, yeah, I wasn't particularly torn with regards to staying. It was more like most people would just tell you to finish. I just didn't. Looking back at it, it was fine. It hasn't really stopped me from getting certain opportunities or visa issues.

But you also, you were there for multiple years, right? What year were you in?

This was fourth year.

Fourth year. So you're close to finishing. You could actually just go back and finish any time if you wanted to. How many courses are you missing? Like three.

Like a semester's worth.

Okay.

Yeah, so whatever that is.

But it's true. Yeah. Maybe at this point it really doesn't matter.

Yeah. So, yeah, after Prague, I go back to normal life. And obviously I'm procrastinating, right? But I still have to do my finals. In the middle of procrastinating, I was on Twitter. There's this conversation with Ameen Soleimani of SpankChain and 0xbow and a few other things, trying to sort of prod as to why we can't get to ETH 2 faster.

Yeah.

And basically, the biggest issue was that a lot of the teams doing a lot of the heavy lifting at the time, they were not full time on ETH 2. So in my case, I was a student, I was not focused. I was not even working at ChainSafe full-time. It was part-time. And for a lot of the other teams, they had people who like had a day job. So that was the source of a lot of the frustration. And so Vitalik, out of his own personal money, sort of started donating to teams who needed more funds to set aside a dedicated internal team to work full-time on Ethereum, basically. At first he donated to Prismatic Labs, and then people got excited, and then he donated to Sigma Prime.

These are like the ETH 2 client teams?

Yeah, yeah. They were not full-time at the time. So it's basically to give enough funding to be able to set aside resources. And then when I saw the Sigma Prime team get money, I tweeted, if Vitalik gives us 100k, I'll drop out. And then there's a Twitter thread, I don't know if it's still easily available, but basically Vitalik just needed an address. And so I hate Slack, notoriously --

I hate Slack too.

I got scolded when I was at ChainSafe for not using Slack.

Okay. That was their tool, though, I guess. Like internally they're using Slack, but you don't want to. Okay. I hear you.

Yeah. So I went on and, you know, nag the team. And this was like at night too. So it's not like they were easily accessible. So I had to go nag the team and be like, guys, put an address on the website, Vitalik is gonna give us money. It was like such a rush. And he sent the money, and I was like, great, I'll finish my last exam and then go drop out. So I went to go do my final exam. It was probability, which is a notoriously hard course. And the TA was giving out the exams. And he's like, are you ready? I'm like, no. And he's like, don't worry. But to me, it was like, it didn't matter because after the exam i was going to go, like officially drop out. And so in Canada, it's not like an ejection button. It's sort of like, you basically just don't enroll for the next semester. And so that's what I did. And it was very exhilarating. Obviously, I had to tell my mom, and she wasn't happy about it.

Was it -- were you at all worried?

No, because I had a job.

Yeah, you're right. You're right. You were already on a path.

Yeah. I had a job. I was doing stuff. And also, again, it was easy to go back. When I went to dropout, they explained that you can always come back, and that's still the case, I guess. So, yeah, I had to tell her, but I had a drop, so it was --

It wasn't too bad.

It was fine. So like I --

And you were close to the end, so you'd learned enough stuff.

Yeah, at that point, I was just padding out my schedule with electives.

Yeah. I want to ask you a question in all of this. So at this point, you've joined ChainSafe full-time. Recently, you had a tweet about how you kind of helped invent rollups with John Adler. And I'm just curious, time frame-wise, when did this happen and what does that tweet -- actually, what do you mean?

And so eventually, he left his PhD to go work at ConsenSys, and he was working on scalability at ConsenSys. And I, obviously, being young and wanted to have publications and stuff, was like, hey, can I help you with your research? This was just me. I was still at ChainSafe, but it's not like they had any restrictions on what I can do or anything like that. So this is just me exploring the space. I mean, I had to keep up with what's going on in the space in general anyway. So, yeah, obviously, John didn't just let me have it easy. Right? In these lab settings, you interact more with the grad students than with the professor anyway. So we had grown kind of close at the time. Yeah, he had sent me a few things that he was working on in the direction, and I just had to guess what it was. And kind of how to go about it.

And, yeah, one night I was looking through Plasma, which was the leading scalability solution at the time. Millions of dollars went into Plasma, but also concurrently at the time in Bitcoin, there was these Block Size Wars that had accumulated in the splitting of Bitcoin Cash into its own blockchain. And those wars were going on for a few years. And I was following that at the same time as, well, understanding what are the scalability issues in Bitcoin, understanding scalability in Ethereum. And like, I sent a post a text to him about, like, are you just working on Plasma and merged mining? And he was like, let's hop on a call and discuss it. I was like, okay.

Wait, was merged mining, this is a Bitcoin term.

Yeah.

What does that have to do with rollups? Is there something in a rollup that's sort of merged mining?

So I remember at the time when I was reading Plasma, a lot of the issues were regarding inheriting security from the parent chain, and Bitcoin, like way back, the community had come up with a thing called merged mining, where it allows a miner to mine on both chains, on two chains. So obviously the main chain and then another chain where you can add extra functionality. And to me, it was sort of like, one, I just combined merged mining with Plasma, and I just send that as a text message to John. It seems like that's exactly what he was working on. So I kind of just guessed it and then -- yeah, that's how I was able to contribute to some of the ideas and stuff in the paper. But John did most of the heavy lifting, for sure. Yeah. So that's why I don't make it my personality. Yeah.

And it's why it's not in your bio, but rather it's just one tweet.

So it used to be in my bio, actually.

Oh, okay.

Yeah. So I've gone through different waves of Twitter fandom or stardom. Right. So --

It's true. I mean --

My current wave is MPC.

You did have -- you had invented SNARKtember. Is that still there?

No, that's no longer there. But it used to be there.

Yeah, I remember that one. I thought that was great. I thought that was a great bio mention. Okay, so this one had been there. So but, yeah, now I'm kind of curious how -- because that must have evolved a lot. Like the Bitcoin merged mining, I mean, that doesn't exactly sound like a sequencer writing to a smart contract platform. But --

Well, rollups now are very different from the paper. It's been like five plus years. So obviously a lot of things have changed since then. Like we formalize -- as a community, we formalize a lot of the things we've come up with, like better designs for rollups. Even in terms of designing like blockchain apps, on-chain apps, like coprocessors kind of came out of seeing rollups as an application. Your application is a blockchain, why not have your application be something that -- like your application on-chain cares more about? So ZK coprocessors is an example of this. Axiom allowing on-chain applications to query old chain states. That's a specific application, and you don't lose security if you delegate this functionality off to Axiom, for example. So the space has come a long way in how we view rollups and how we design rollups and stuff like that. So back then, there was nothing about sequencers. The terminology has changed a lot as well.

Oh, for sure. That's cool, though. You know, we just mentioned your Twitter. Your Twitter account, badcryptobitch, amazing. Why don't you introduce it real quick, because like -- where did it come from? But also, when did you create that? Because did you have that throughout from U of T on, or was it later?

Right, so the Twitter account came about right before I went to Devcon 4.

Okay.

So before then, I was controlling my club's Twitter account. So I started a blockchain club at U of T as a student, and we had a Twitter account, and I was doing a lot of my interactions through that account. And then obviously just -- at some point, I couldn't do things through that account.

There were certain things you were not allowed to say?

Well, no, that was not allowed to say, but it was like, the kinds of trolling that I do now, I was doing it through a club account, and that look wasn't -- it's not good. Like even at 20 years old, I knew there's a line to draw between, like --

What the club says and what you say.

An entity account and like my personal account.

That's good.

So I had to start my own account, but I was the president of the club. So obviously I can either take that. But at some point like -- just because I was 20 doesn't mean I was stupid. You can't be tweeting certain things from your club account.

Yeah.

So I started my own separate account, and this was around the time of, like, Cardi B's like Invasion of Privacy album came out, and it was charting, I had some really good bangers on there. And I was listening to that, and so like badcryptobitch came out of, like, just me listening to this album.

Right. Is that an actual quote from there?

No, it has nothing -- it's just like --

It's just sort of vibe-wise similar.

Yeah, just like Cardi B's music at the time was very -- like, if you're in a bad mood, because it makes you confident.

Yeah.

And so badcryptobitch was the Twitter handle. I can't change it now. The space has changed a lot. So if I were to create it now, I'd have to be more professional or something, but now it's stuck. People like it.

It's stuck. I like it.

People recognize it. That's the story of the birth of the badcryptobitch account.

What about Hashcloak? So far, we've learned a lot about kind of you're at ChainSafe, you're full-time at ChainSafe,. You're working with them on different projects. You're at the same time doing this ETH 2 client.

So the ETH 2 client was at ChainSafe.

It was at ChainSafe. Okay. So it's connected to it. But how does Hashcloak happen? And maybe also where does ZK happen?

Right. So at that point, I had dropped out. So I had more time to think about just what I wanted to do in general. And cryptography and privacy was always an interest of mine, and I wanted to pursue that more. And a lot of the tasks I just assigned myself at ChainSafe were less focused on Lodestar and more focused on P2P and privacy. And that just got in the way and it got me in trouble and I took full responsibility for it. I should have just talked to them and asked, hey, can I work on this other stuff or whatever. But instead I just like, this is interfering and I wanted to focus more on privacy. I felt like I was very neglected. This was around the time Tornado Cash had launched. So this was pretty important.

Did you have people working with you at the start? Because I know you do have a team now, but was it just you?

Yeah, it was just me. I just wanted to explore different aspects of cryptography. And at this point, I had the mathematical maturity to understand a lot of the papers that was coming out. When I tried earlier on, I just did not know what a field was. I had not taken algebra. I took linear algebra, but that's not the same. So, yeah, at this point, I had a lot of mathematical maturity. I could like go back and revisit papers. I had time to do that. I can explore more obscure aspects of P2P networking and just be on my own time. That's basically why I started HashCloak. At HashCloak, we morphed into a regular cryptography consulting firm. We do a lot of long-term engagements related to R&D and cryptography for clients.

Did Hashcloak become an auditing firm? What kind of work have you done since then?

Yeah.

And for like a year and a bit, I was actually -- people are always looking for auditors, but I was saying no to a lot of that because that's not what I wanted to spend my time on. But DeFi summer happened, and Fuel Labs couldn't get an audit, and so they asked me to do it. And then once you do one audit, you're kind of -- people just get to know that you're doing audits, and so you get a lot of just business that way. So I never needed to do much marketing. So the audit stuff is like one thing that we do. A lot of it is mostly just like this R&D stuff that we do on behalf of clients.

And that's the stuff that, I guess, gets you really excited.

Yeah. And then also I have my own internal, like whatever's interesting me at the time.

Yeah.

So, yeah, like I said, Mixnets. I worked on that for four years. I just did a bad job of showing it, but we got grant funding, this code --

Cool. Which ecosystems did you do that for?

Like, a networking solution, so.

It could be for anything.

It could be for anything.

But who funded it, though, if you did do --

Yeah. So we got two grants, one from Binance X Fellowship.

Okay.

So Binance was running this grant program way back, and a bunch of people that I know had gotten it. So I asked them, like, oh, how do you apply? And that's how I got it. Ethereum Foundation.

Okay. Yeah, that's why I was kind of curious, which -- yeah, sounds like.

Yeah.

I sort of said this earlier, but I feel like your narrative right now is very MPC focused. So MPC is the center of your – that's like in your heart. And then there's other things like FHE or TEEs that seem to get sort of like some disdain. And there's a lot of comparisons and like -- I don't know if you want to summarize your thesis right now on MPC versus the world, but I'd like to hear it.

I mean, I think a lot of people are too married to their specific thing. It's just easy for Twitter and the algorithm to shit on different things, because that's what it prioritizes. My personal opinion is that we're gonna need all of this stuff in some way or another in different configurations. And I guess I can be nuanced like that, but that doesn't give me the engagement that I need to show.

So instead, you place it in a battle scenario.

Yeah.

Okay. I love this, though. I love that you're sharing. Like the nuanced view is that you totally see them all as collaborative technologies and we should have them all working together. I think that is actually what most people think, but I think it's also funny to see them being pitted against each other. And I've had over the years, people try to tell me that one of these technologies would just actually beat out ZK. That ZK will become obsolete because TEEs, because FHE, because MPC. Yeah. I don't know. So far I haven't seen it happen, so.

It also doesn't make sense. Right? I think we kind of just have this umbrella of privacy-enhancing tech for all of this, and we just think, like, oh, you can apply it in every single instance you'd apply ZKP or something like that. But really it comes down to your application design. And I think a lot of people don't think deeply about how to design their applications and what their needs are. They just try to use whatever trendy thing for whatever reason. Maybe it's very VC-driven, maybe it's not, or narrative-driven or whatever, but it really just comes down to what does your application need and how can you get there? And sometimes you need ZK, sometimes you need MPC, sometimes you need some combination of all of them. Yeah, I think that's how I think about this. Another thing is everybody sees each of these things as a thing that's gonna take over everything, which is weird. And it's coming from people who should know better.

Yeah. Yeah. At the same time -- yeah, I feel like you've also highlighted some of the hypocrisy in some of the marketing. So if I could summarize roughly what you often tweet, it's like, MPC is your fave, FHE overpromises and TEE is being pushed down our throats. You had one quite graphic tweet about that one, so. But I feel like that is a little bit of a summary of the story that you're telling. And I sort of want to explore a little bit of that, because I don't think you're saying MPC wins all, but clearly you're working on an MPC project. So that is kind of what you're focused on. But, yeah, do you want to talk -- can we talk a little bit about TEE world? I mean, FHE and TEE kind of get full compared, right? Because it's like these private spaces where computation can happen. I don't know that MPC and THE get directly compared as much, but, yeah. What are you thinking on that?

I mean, I think it's just a matter of narratives. Like, whoever pays these influencers to shove stuff down our throat and attends all these conferences is what gets the most sort of mindshare. And so it's hilarious looking through crypto that somehow FHE made the jump, but this other stuff is not as prominent. When you get out of magical Internet money crypto and into regular crypto, those same people are more focused on MPC or some other thing. So it's super interesting seeing the economies there because there's actually a lot of people doing MPC stuff. In general, they're not working in magical Internet money crypto. They're working in enterprise-y stuff. But the tech is repurposable to magical Internet money crypto.

And so, yeah, that's pretty interesting because I remember seeing a lot of people doing THE work when I was trying to get into cryptography stuff, and a lot of that stuff is just unusable. Whenever I would see somebody tweet about FHE, I'm like, have you tried using any of the available tooling? It's kind of unusable. And so even from people that I've heard who are connected to teams at major tech companies, when they talk about FHE, even they're not super optimistic about it.

Wow.

So it's super interesting to see that in crypto. Yeah, there's a lot of over-promises about THE, but there are teams in crypto doing things that are not over-promising. They don't get a lot of attention, though. Unfortunately, I feel like I should probably write a Twitter thread about them now that I have a bit of shilling power.

Yeah.

Yeah. Because there's people doing really cool stuff with FHE, and those people are doing stuff that really delineates the differences between when you'd use FHE, when you'd use some other variants, when you'd use MPC and stuff like that. But they don't get that much attention, so I should probably highlight them soon.

Yeah. Also with FHE, I also kind of have the impression that some of the FHE potential. Like it is a potential, but we're far from that potential, and yet sometimes we're being sold FHE as though we've reached that potential. But if you choose, a very narrow use case, maybe something simpler, then THE maybe is at the level where it could be used. Right? Like it's sort of the -- like how generalizable is it? How huge a computation can you do within an FHE environment? Like, isn't that sort of -- if you go narrower and simpler, that actually maybe it is possible. Would you say that's the case?

Yeah. Yeah, I would say that's the case

Yeah.

Yeah. So there's a lot of sort of web2 use cases where THE is usable, and that's why a lot of big tech companies have research teams focused on THE because they have direct applications where they can use it. So, yeah, I agree with that. I think for crypto it's still debatable whether it's useful or not. Simply, we just haven't seen much. We've seen demos, but at least give me a production level demo or something, then I can change my tweets.

Prove it. Yeah. And then badcryptobitch won't mean tweet you anymore.

Yeah.

What about TEEs? We just did an episode like a few weeks ago with Andrew Miller, who also mentioned you. So do you like TEEs, because like --

I don't hate TEEs.

Okay.

I don't have any reason to hate them. It's weird that -- I don't know, I think I've come off as very aggressive on Twitter, so people think I hate things. It's like, no, no. So TEEs are very useful. My concern always just goes back to application design because there are people who hate TEEs, and they will make it their personality. Like in the ZK Podcast group on Twitter, there's a lot of people who genuinely hate TEEs, and I think that's throwing the baby out with the bathwater. Really, it sort of like, it depends what your application needs. And to just give up and say, oh, we can't use TEEs is kind of anti-science or anti-truth. And really we should be trying to make them more palatable because there are use cases where they are useful. And so like Andrew's doing a lot of that heavy lifting and trying to make them more palatable. And I think that's why it kind of got like a resurgence in the space because like the stuff at Secret Network happened, and people kind of just dismissed TEEs. Even before Secret Network, there was always an attack on a TEE every year. And so in general, like cryptographers were just like --

Even recently, right?

Yeah. So, in general, cryptographers were kind of just like, we're not interested. But it turns out there's quite a few interesting use cases for TEEs. And really you should work on trying to make those vulnerabilities or issues more palatable. I mean, we all use Twitter and whatever, and you put all your thoughts on there, or maybe you don't., depends on how you use it.

I don't. Yeah, I'm pretty chill on Twitter.

Right. And there's a risk to doing that, and you still use Twitter in the way that you do. So, I would argue that doing stuff on Twitter is worse than doing it in a TEE. I guess maybe that's a broad -- that's a very broad statement. It's a bad statement to make.

Like TEE is more private than Twitter, is what you're saying.

No. I'm just saying, I guess the point I'm trying to make is that there are things that we use in technology that have sets of trade-offs that might be palatable but are still not great to have. Like people still use Facebook and Google and all of these things even though they actively harm you.

But the difference there is, you know you're acting in public or you should. Facebook, maybe it's a bit more like, I think people think they're working in a more private environment often on Facebook than they actually are. But on Twitter, you know you're public.

But you can protect your Twitter account.

Yeah. I guess if you have a private Twitter, but still, like I don't really get why.

I guess the point is that there's a lot of tech in which like in order to use it, we make some form of trade-offs, right? So as you mentioned earlier in the call, we hate Slack, but we have to deal with clients. So we still use it somewhat, but then we don't use it for our day-to-day. As an example, and you kind of have to see not just TEEs, but all of this stuff as in the same vein. You're going to have to make some trade-off somewhere. You're not going to get the most perfect system out of using ZK or whatever or TEEs or whatever. So people who hate TEEs, I'm just like, yeah, there's use cases where this is useful. You may not like the trade-offs, but then what is the alternative? And so TEEs help with stuff like that. So I've been sort of trying to understand how to use TEEs for MPC. I think Andrew brought up some good examples of that in the previous episode. And so, yeah, that's been my thing is just trying to an open -- I have an open mind when thinking about TEEs, but obviously, I'm just trying to be trendy with my Twitter.

Trying to take the piss because it gets a little bit of likes.

Yeah.

What about ZK, though? We talked a little bit at the beginning about how I met you and the stuff we were doing around ZK, but what has your relationship to ZK been? Because in a way, you seem much more focused on MPC. It's funny in the tweets that you have, it's often a three way battle. It's like there is two -- these three players are put in some constellation and ZK is often not there. So I'm wondering, yeah, like --

I mean, my earlier memes from this year have a lot of ZK in them.

Okay. Okay.

I guess, like, personally. So a lot of our business at HashCloak is ZK-focused because that's where --

I see.

It took like four or five years before people cared about ZK. And so now we're like, for me, just being active in the relevant communities. We've gotten business that way. So a lot of the team is focused on ZK. Personally, I've moved from ZK to MPC because I just think it's more interesting for me. But obviously for MPC, I have been thinking a lot about ZK.

You know, about collaborative SNARKs.

Well, I've just been thinking about computation in general.

Okay.

Right. So we use ZK as this short term for SNARKs when ZK is meant to be like an extra property you add to SNARKs. And really I guess the point of using ZK for blockchains, a lot of it comes down to verifiability and how you get that for just arbitrary programs. So I've been thinking a lot about, yeah like collaborative SNARKs and stuff like that. So for what we're doing, we're building an MPC-VM. You want the MPC computation to be verifiable, you need a ZK proof, or I guess you need a SNARK. At minimum, you need a SNARK, and then if you want to keep certain things private, then you need a zkSNARK. Yeah, so I do think about ZK. It's kind of trendy, I can't -- there's no low hanging fruit meme ideas that it can come up with. I think I posted those earlier in the year already.

Okay.

Maybe I'll have something in the future.

I see.

Also, we're using the term coSNARKs recently, so I need to make fun of that somehow because I made fun of zkTLS recently.

Okay. Yeah. Is there any -- I mean, it sounds like because your work is so ZK focused, that in a way, your interests need to be in a slightly different direction, but MPC is also becoming your work. Maybe you can talk a little bit about what is the work you're doing on MPC. Because this started as sort of an interest space, but you have now Stoffel, which I think we should talk about.

That's cool. That's like a treasure trove. It's like that's amazing.

Yeah. So a lot of it's like usable. I mean, it's hard to use, but a lot of those academics are actively updating that code. Or if they're no longer updating the code, if you send them an email, they'll respond.

It was approachable, I guess.

But using MPC somehow.

Using MPC framework written by some academics.

How does that -- wait, where is the AMM? Is it in it? Is it the trade itself is done through a multiparty computation or something.

So basically what I did is these frameworks allow you to write MPC circuits either through an API or through a DSL. And so basically this allows you to just write, x times y equals k, exactly as you would in Solidity. So, yeah, that's basically what I did. One of the frameworks I was using didn't have the vision, so I couldn't implement everything. And then we transferred to a different thing. And then this is a bit of a blur, but somehow a bunch of people got roped into this project and one of Andrew's students took the lead and she actually made it into her PhD thesis and wrote a ton of the code. I just wrote some cute lines and some old framework and then did some -- a little bit of cute stuff. And then somehow, I don't know, this turned into a whole PhD thesis. I don't know how, but it happened.

Wait, I want to go -- can I go back to the MPC as AMM? I want to understand where is the multiparty in the DEX, kind of in the trade. Like is it two parties on each side, and they're doing some sort of multiparty computation to make the trade happen. I just don't know who the multiparty is here.

Okay. So I guess we can go back a little bit. So basically what these frameworks allow you to do, so basically you define what your circuit or your program actually does in one language or API, and then later on you can define who are the parties. And at this time I didn't really understand what that meant, because I was trying to learn MPC. So looking back at it, I don't think I have a good answer for who was doing what.

Okay.

I guess if I were to reimplement it today, I would probably have a better answer. But at the time I was like, I don't know what this is. I can just write this Python code and have it run.

It does something.

It does something.

Nice. Now let's talk about the present in Stoffel Labs. What is that working on? Is this like a research project? Is it a --

This a -- Stoffel Labs is a separate company where -- at HashCloak, while I was doing this research with Andrew and understanding what was going on, we had to look into the code for some of these academic frameworks, particularly MP-SPDZ. And it turns out it's actually quite approachable. Sure, the code isn't the best engineering quality or whatever, but it's still, you can read it and you can kind of get the gist of what's going on. It made me realize that, why can't we just do this for blockchains or have this as an extension for blockchains in the way that people are doing ZK coprocessors now, I think. I think at the time we weren't calling things coprocessors. We were calling rollups or side chains or something else, but basically I realized, why can't we just do this for blockchains? I started writing an implementation at HashCloak and then we open sourced it, but it was still very early days. And unfortunately, when you're doing consulting and internal projects, the consulting has to come over because it pays bills.

It has to comes first.

Yes, it has to come first. It pays the bills.

Yes.

So we're spinning out that work into its own company so it can have resources, basically. And yeah, that's what Stoffel Labs is like working on making a lot of the academic MPC frameworks bit more production ready and making MPC more accessible to everybody. Obviously, we'll be focused on Web3, but there's a lot of low hanging fruit like Web2 applications that we'll also want to explore for this company as well.

Is this going to be an MPC framework? Do you imagine it being a collection of libraries? Do you imagine it being a DSL? Or do you imagine building the actual coprocessor or some sort of environment?

So basically, the way we're doing it, is, I guess the way to explain it would be probably contrasting it to ZK infrastructure. So if you're familiar with RISC Zero, what it allows you to do. You write your program in Rust, compiles down to RISC V bytecode, then the RISC V bytecode runs in RISC Zero's VM. We're doing something similar to that, except our VM is a custom MPC VM. We have our own ISA. We're not using an existing ISA, like RISC V or MIPs or whatever. And it's very similar to that kind of framework. So we are going to go with a DSL, but you can always emit the DSL and build out an LLVM infra and have people write Rust and compile down to the MPC VM. All that is on the table, but ---

It may still be Rust, the language that you're actually using, but you're not going to use the RISC V instruction set.

Yeah.

I see. I guess, yeah, there's like compiling. There's the possibility to compile instead.

Well, the reason for that is because like MPC is just a different kind of computing paradigm. Things are not done locally and so basically made more sense to just use an existing academic framework that took into account those design constraints. And those existing academic frameworks already have a custom ISA for MPC. So it makes sense to just take that and make it a little bit more developer friendly or some improvements to it, because re-using RISC V isn't a bad idea, but it does have its own set of constraints. It's kind of the difference between RISV Zero and Valida, where Valida also has its own custom ISA for its zkVM.

Okay. One thing that those systems promise, though, is verifiable compute. That's like the feature. Does MPC offer something like that too?

It doesn't offer -- an MPC VM doesn't necessarily offer out of the box verifiable compute, but it can. What we offer is like private distributed compute.

Okay. So it's more -- I mean, it's focused more on the private part. And actually I guess with an MPC too, you don't have this prover issue where like the prover can sometimes be the -- especially if you have like a centralized prover, it sort of removes the privacy part or it makes -- like someone, some prover is going to see what's trying to be made private. With MPC, as far as I understand, that isn't the case. So the privacy part, it's in this joint environment that no one can see.

Right. So the nodes are operating over secret shares. So the nodes individually don't see the private inputs, which would be secret shared. However, there's collusion issues. With MPC and like in papers, they kind of just brush it off. Right? So you have these different threat models for MPC, like this honest majority active security, passive adversary stuff like this. And depending on your threat model, you get different properties of what your committee can do. And that's actually an issue in practical deployments of MPC. In practice, a lot of deployments sort of just assume most nodes are honest, or if they're not honest, you're beholden to some contract, some sort of practical deployment drop is made there. So that's actually a major issue. And I think Andrew might have brought it up in the episode where you can use TEEs to help with preventing collusion of MPC nodes.

Interesting.

So that's like a way to solve that. But yeah, outside of collusion the MPC node shouldn't see your secret shares and outside of like bugs in your code as well. Right?

Yeah. I should also maybe add the kind of thing I was saying about ZK and the prover scene stuff. There are actually solutions out there where they are truly ZK, where they'll do ZK on the client-side and then maybe have a prover prove those proofs. But it's still kind of private. But yeah, with MPC it's interesting because as a design space, I definitely have not explored it much. I feel like in the last year I think we've talked about MPC. We've had proper MPC episodes two or three times. So it's like not much. Yeah. I definitely would like to see more of what's possible. Like the kind of paradigms that are just different, things that are created that wouldn't be created with any other tech. Do you see though -- sort of like you kind of gave an example here of TEEs helping MPC to help with this collusion issue. But do you see some overlap with other technologies? Would you sometimes think like, oh, I wish I wasn't using this, I wish I was using something else. Like I know you maybe not because the MPC is like the passion, but yeah.

Well, I guess not that it's a passion, it's more like, I think going back to something I said earlier in the episode, people try to use ZK, FHE, whatever for everything, as opposed to just looking at the problem at hand and seeing what you actually need for your problem. So I think this is probably one of the issues with MPC in the past, is that people want to do everything with MPC as opposed to looking out where it's actually useful or making efforts to find where those areas are. I guess back to the question of is there intersection of MPC with other things? I think we brought it up with ZK, this like private input situation, just like a few companies working on the distributing, proving and that uses MPC. So that's like an area of intersection. For FHE, I think some of my memes kind of bring this up a lot. So for practical FHE deployment, you have to split the decryption keys. Otherwise, even an honest but curious server can potentially decrypt your ciphertext. And so you would use MPC for splitting decryption keys. So that would be intersection to those things.

Actually, it brings me back to what you said, like what is good for what. In you describing MPC in this system that you set up, you sort of mention the privacy component. But is the problem that you're trying to solve creating an environment for private compute better? I'm trying to figure out if it's like, yeah, what's the add on? What's the additional benefit of using MPC? Because there are obviously lots of projects that are using ZK for private compute. Is there an efficiency gain when you do it with MPC? What is it about that system that sort of makes it a better fit to use MPC?

Right? So I would say in order to do more interesting private computes, you need a way for everybody to access your private information. So the issue with ZK is that basically if you take at face value the law of the definitions for zkSNARKs, it kind of just says you're a prover and you want to prove something to somebody else and assume that you have the data and you don't want to share that data. But what if you want somebody else to do some interesting thing over your data. In that case, with ZK you're still kind of limited. Right? So you mentioned earlier on where there's designs where people still do a proof client-side, but then they have to send the proof to some other thing. And that kind of limits what you can do because now you're constrained more by engineering/application design as opposed to the issues with ZK. Like at that point you're kind of just trying to square a peg in a round hole or whatever.

Square peg in a round hole, something like that.

Or is it the opposite? At that point it's sort of like, would you not explore something else? I think for a long time people just use TEEs for that. And TEEs has its set of issues that a lot of people seem to hate. And so there wasn't a lot of good options. And so MPC and THE kind of occupied a space of, it lets you do stuff over encrypted data.

Interesting.

Or private data.

Yeah. And I think from what I heard about MPC too is like you can do something over private data and then that data can also have more things done to it because it sort of all stays in this fully private environment. Right? Like it never -- it doesn't have to -- there's no like you yourself, in the ZK sense, if you're the prover, you see the information. So some person is going to see the information at some point and you can maybe do some sort of computation in a ZK environment that's private, but it's not that it can then remain in this private zone and like more can happen to it as far as I can tell.

Yeah. So there's different models like security models for MPC, and a popular one is delegated security where you don't want to do the computation yourself. But there's some servers in which you can send them your information and they somehow don't see it and then they give you the result. And in that case you're kind of giving up some form of sovereignty over your data but secret sharing it, whereas in the case of THE where you encrypt it yourself and then you send it over. So that's a very common paradigm for MPC. And yes, it allows you to like once that's done, and depending on the policies you've set for your program, that data can be stored on a set of MPC servers, set of nodes.

But unviewable to everyone. Right? Like no one can access that.

Well, as long as they don't collude. Right? As long as a few of them don't collude nobody sees your data. And that allows you to do more interesting things. The trade-off you make there is that now you have a more complicated security model and threat model there dealing with this collusion issue, but it allows you to do more interesting things. So that's the bigger trade-off there.

Yeah. I like this though. This is really helpful. Like this is giving me a picture of why one would want something like this.

That's how you go from like why would you use MPC over ZK? It's like maybe your application just needs to do more interesting stuff over private data and you don't want the liability of managing that or you don't want to store it yourself. In that case, you can do this delegated MPC model where you send your data off to a set of nodes and they do the compute and then they send you back the results. Or if you want, you can have it be stored amongst the nodes. And as long as they don't collude, nobody should see your private data or the result of your private data -- the result of the computation on your private data.

Yeah. I feel like this collusion issue is something that I now want to explore a bit more though, because this sounds like this is the crux. This is the big drawback you've highlighted.

Yeah. I mean even in blockchains this is a major issue, right?

Yeah.

We've seen 51% attacks in practice. So it's not like it's never going to happen that some quorum of nodes in a P2P network will never attack it. So this is an issue for MPC systems and in practice, like I mentioned earlier, the way this is solved is choosing an appropriate MPC protocol on a specific security model. And then you just have the nodes be bound by some legal jurisdiction system. You sign contracts with them. If they deviate in a byzantine way, then sue them. If there's just a bug, then hopefully you can recover and then you don't sue them. But yeah, like a practice is still very kind of -- it's not enforced via cryptography or via physics. It's enforced via like legal -- by the legal system.

Yeah.

Which I guess to some extent can be true for certain blockchains as well. Right? I guess that's like another episode for another time, depending on who you talk to or if you have to stake into a system and you're kind of validated, are you bound by some legal jurisdiction or something? I don't know. I'm not the person to ask about that. But yeah, for MPC, you have a similar situation where in practice, when you deploy these nodes, who runs them? How do you make sure they're not malicious? How do you make sure that even if they're not malicious, but they go down, you can recover your data? A lot of these questions are questions that plague just distributed systems in general. Right?

True.

What happens to when you can't access Google or Twitter? And I notice 30 plus years of just practical engineering advice around there that you can apply, potentially. But then there's some stuff that's specific to MPC where I still think there are more engineering problems than there are research problems, frankly. But, yeah, I think they're solvable, and some of the solutions people may not like, but I think they should be palatable. So one of the bigger solutions that's used is TEEs. And as mentioned earlier, a lot of people hate TEEs, but right now, if you want to deploy MPC in practice, it'd be irresponsible to not use a TEE to prevent collusion.

Okay. I mean, one day, could it be FHE?

I guess it would depend on what you're building.

Yeah, exactly. Kind of going back to that use case thing.

Yeah.

I haven't seen -- I mean, is there a lot of MPC, THE crossover? Like Nigel Smart says they're the same thing, that FHE is like a version of MPC.

Sorry. FHE is a version of MPC?

That's what he said. Yeah, on an episode we did a long time ago.

Oh, I think. I think I had a meme that was like, so, in the space, a lot of people use the term tFHE, which stands for, like, threshold FHE, and that's just like MPC with extra steps. So he's not wrong, but I guess the way I typically think about it is the opposite, is that MPC is a version of THE because, in a lot of MPC protocols, the way they're implemented is they have somewhat homomorphic encryption implemented, or partially, homomorphic encryption --

But it's the somewhat. Yeah. Or partially not the fully. Yeah.

Yeah. So to me, I usually think of it as the opposite. Obviously, I don't make memes out of that. If I make memes out of that, it's just people are going to --

It goes against the stories. Yeah. Makes sense.

I mean, maybe I can make a meme out of it and be more nuanced in some way, but as soon as I just put the meme out there --

It sounds like you're not supposed to be nuanced on Twitter from what you said. So maybe I think you're doing great. Keep going.

But, yeah, that's how I think about it.

Nice. So, Mikerah, thank you so much for coming on the show. I know we tried to do this over a month ago. We were actually going to do an in-person kind of roast. Tarun and I, and you were in the same city at the same time, but sadly, it was during a hackathon and we didn't actually have any time to record it. This wasn't quite a roast. It was more of a story. But it was really great to get to hear your story. And also, I really like the stuff on MPC. To me, this is a way of using MPC that I haven't heard before. So, yeah, for me, it's been pretty cool to learn about.

Yeah, thanks for having me on. You know, good thing there's no roast because I would have been roasted. But instead, I guess we got this nuanced conversation --

Different from your Twitter.

I hope it doesn't give my enemies any ammo against me.

I doubt it. I doubt it. I love your Twitter. I think it's really fun. That's why we mentioned it throughout this episode. But I also think it's really nice to hear because I think you're quite reasonable -- when you meet you in-person, you're quite reasonable about all this stuff, and you have really good insight. You've been in the space for a long time. You've also consistently explored a little outside of what the crowd is thinking about. You know what I mean? Like everyone's focused on one thing, and you're sort of checking out something over there and down the line that becomes really interesting to people. So, yeah, I think it's cool.

Yeah. I don't know why, I think my attention span, it's just like, if something's mainstream, I'll learn it because people will shove it down your throat. So I should probably spend my time on something that's less mainstream, something that's more under the radar. And if it turns out it's popular, then I had a good time. If it's not popular, then that's great. I always love learning new things.

Nice.

Go follow me on Twitter. Go follow all the accounts on my Twitter bio. Go see Bo -- Bo's kind of --

Yeah. Well, thanks again. I want to say thank you to the podcast team, Rachel, Henrik, and Tanya. And to our listeners, thanks for listening.