Episode 376 - Miden & the Edge Blockchain with Bobbin & Gaylord

Transcript

[Music] 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. [Music] This week I catch up with Bobin and Gaylord from Maiden. We discussed the history of the project since we last covered it back in 2021, their work within the Polygon project and the recent spinout of the Maiden blockchain.

We covered the ZKVM space, privacy and its different flavors and how Maiden looks to differentiate itself from existing privacy projects as well as within the ZK scaling initiatives. One fun fact about the guests and the co-host of this episode, we've all been involved in some capacity in the making of the ZK Whiteboard sessions. Speaking of ZK Whiteboard sessions season 3 have just launched. The ZK Whiteboard sessions are produced by ZK Hack in collaboration with Bane Capital Crypto. Every two weeks we have our hosts Nico and GMO going deep into the key concepts in ZK and you can watch them over on the Zero Knowledge podcast YouTube channel.

I've added a link in the show notes. Please do check them out. These are a great resource to learn about the fundamentals and techniques powering the ZK systems we often discuss on the show. And now here's my interview with Bobin and Gaylord from Miden. Today, GMO and I are here with Bobin and Gaylord from Maiden. Welcome everyone. Welcome Gaylord. Welcome back, Bobin. >> Hi everyone. Great to be here again and thank you for having us. >> Yeah. Hi Anna. It's It feels like I'm in the in the Trone movie in the video game in the Matrix. So, yeah. Very happy.

>> On the other side. >> On the other side. Yeah. >> Very cool. Hi, GMO. >> What's up? >> This feels like a little bit of a mini reunion having all of you on because we've all Well, I've worked with all of you on certain capacity over the last few years, which we will learn about throughout this episode. I'm going to start with Bobin. Bobin, you I think first came on the show in 2021. I think we met around that time. You were part of the ZK hack online mini, our second online event. We had done it all about Winterfell. So like this is I remember working with you on that. And you were also one of the hosts of the first season of the ZK whiteboard sessions which I want to talk about later in this

show. >> Oh really? I shouldn't know that. >> Yeah. >> So we have like a lot of cool touch points. In that episode we did in 2021. We talked a lot about your backstory. You had worked at Facebook, created Winterfell. I'm going to link to that in the show notes if anyone wants to hear kind of that part of your story, but I think we should get brought up to date on all of the work that you've done since then. So, go back to 2021. I think right at that point, Miden had joined Polygon. Yeah. Tell us what has happened since.

>> Yeah, definitely. So, I think we're actually thinking back, we met even before that. Like I think one of the first things I did was the ZK study club uh where I talked about like the Starks the first time where I was still learning about how Starks work and >> yeah oh I didn't realize that. So you were on the early so what what he's talking about here is the ZK study club which is like >> we used to do and we sometimes still do these like monthly paper reads together basically >> and that I mean that goes back to 2019 actually in that case. Oh cool. Oh, sorry. I missed that one. I'll try to dig up the video. We would have recorded it if you hosted one.

>> It was recorded. Yes, it is somewhere online actually. >> Cool. Okay, so we go back even further, but yeah, let's go back to 2021. >> Yes. So, >> tell us about what's happened since then. >> Yeah, so 2021 when I was in the show, I just joined Polygon and I was coming out of Facebook as you said, I had the the Winterfell prover and I was working on the ZKVM. Uh, it wasn't actually called Maiden at the time. There was no Miden. I think Maiden was the name was created inside Polygon. I don't know if you guys know about the the meaning of the name. It actually means zero in Greek.

>> So, it was kind of a play on zero knowledge. >> Wait, sorry, really quickly. What is Winterfell? I actually I know it's been mentioned multiple times. It is a boring like old school question, but >> no, not bad to recap. >> I'm just curious. Yeah, architecturally. >> So, Winterfell was start prover that I've built while I was at Facebook. It was one of the projects like in Facebook I was part of the crypto group the DM or liate person. >> I I do remember from there but I was okay got it that's the connection >> and it was sort of the alternative like I think Starkware and had really pioneered the Stark work and had been doing a lot of those libraries. I think your your library Bob and Winterfell was like the one project outside of Starkware also working on Starks at the

time. >> Oh interesting. And I think it was one of the few if I don't want to say the only one but for sure one of the few open source start provers because I think starkware approver was still closed source at the time. Now they've open sourced it but at the time winfell was I I want to say one of the very very few open source start provers. >> This was 21 20 >> 2021 >> 21 yeah uh >> I think summer of 21 to be more precise >> and it was actually pretty performant. was my like the first dark prover that I ever written was written in JavaScript which was a horrible idea to write a a zk proving system in JavaScript.

Incredible. >> So, so like this was my iteration on this. I was like okay I'm going to write it in rust. So like actually you know it's useful and usable >> and so it turned out actually to be pretty performant. I think comparing back like the performance of Winterfell is still on par. Now there are faster provers now but it's at the time I think it was one of the fast fastest provers around. So this was like coming out of Facebook, but the next thing I really wanted to do was the ZKVDM because start prover is one thing and for me and it goes back to kind of like you know how do people use ZK right because at the time you had to handcode circuits and you need to understand a ton of this and like I wanted to work on ZKVDM and that

was like my way of saying okay this is how we get the ZK into the hands of the masses because nobody really wants to write error constraints or R1cs constraints or whatever. people want to write regular programs. And so at the time in 2021 when we chatted I was right about like released I think Maiden VM V01 which was like the f very very first version of that. And yeah since then I think we had a quite a few touch points like I think we did the ZK whiteboard series as I said we did a ZK hack where I tried to like use Winterfell for kind of like introduce like some puzzles that people solved. You know, funny story about the the the hacks, like you know, you try to put in, for example, one of the puzzles was where I wanted to put in

like a missing constraint type of error and things like that. And then people found this, but they people also found errors that I didn't want to put in. >> Bug in the puzzle. >> Not the puzzle at the end of the Yeah. Yeah. Not the bug at the end of the puzzle, but a a bug actually in the puzzle. >> I mean, you weren't It wasn't the only time that happened. it. >> I think almost every year we've had like one sort of glitch on that front. >> That's awesome. >> But uh within Polygon, I kept working. So like um for about a year I was working on the ZKVM and kind of built a small team around it. Uh I think you guys had Gersa recently on the podcast who was one of the early joiners and was working on Maiden VM at the time. So we

already named it >> and then about a year into this I came up with a blockchain protocol which has now become Maiden as the Maiden blockchain so to say. and I've been working on it ever since. So like I've been working on that for almost 3 years I would say for on the actual blockchain. So like the KVM was earlier and the blockchain happened like in I want to say late 2022 or something like that. >> Okay. >> Um yeah I mean it was like a very interesting environment in Polygon. There was like a very high concentration of talent right there was the Polygon Zero Polygon Hermes one of the first ZKVMs to go in production the PL3 development. So like it was an incredible time. But yeah, more recently though I think you you know seen I'm

sure people have seen the news we spun out of Polygon. I think it was really good to like experiment and research but like bringing things to market requires a different mindset and a different environment. So >> um a couple months ago we spun Miden out of Polygon and now kind of are sailing independently so to say. >> Very cool. And I want to hear more about that transition and what's planned. But first, let's introduce Gaylord to the folks that don't know Gaylord. Gaylord, you and I worked together until earlier this year. >> Yes, we did. Yeah. >> And anyone who's been part of any ZK hack events, the hackathons, the online events, the Discord channel, you're probably familiar with Gaylord. I feel like you joined the team. You joined my team in 2023.

>> Yeah. Two years ago. >> Yeah. and you really took ZK hack from like a once-in- ah conversation on Discord to like a once in a while event to like a real community. So yeah, I wanted to hear I mean I kind of know this but I think you might want to share with the audience a little bit of your backstory working at ZK Hack and then what your focus is on today. Also I do want to just highlight that you are wearing no one can see this because there's no video but it's you have a ZK hack hat and a ZK hack shirt which I very much appreciate. It's not very audio friendly, but yeah, the audience can now picture me with my Zika hack gear around. So, yeah, before actually joining Zik Hack, I was for a long time a software developer in traditional

finance. That's in another life when I was living in Japan in Tokyo. So, you know, everything was different. And then I decided to come back to Europe. I had heard of web 3, you know, in between that was right after Defi summer if people, you know, remember that. >> 2020. >> Exactly. So yeah, end of 2020 I'm coming back getting curious about blockchain on web 3 and I somehow ended in kind of a a very interesting place about artists uh you know we were talking about NFTs back then and I was the the wet three lead that was the name in this very nice you know warehouse with concert and techno music so very nice time >> you were in the vibe land okay >> yeah you know after tri fight I needed a clean break >> you had hard vibes >> you had like an antidote for a long time

you know >> kind of yeah kind of finally Funny enough though, that's where I've met with Tanya, a member of the DK podcast team. So, you know, >> and Tanya, who people know as as she was the podcast producer in the past and also she's the voice of the ads that we sometimes have on the show and she introduced me to you, Gaylord, and was like, I have this friend, >> he has the background you might need for something like ZK hack. >> Exactly. And actually, that happened right after my discovery of ZK, which mostly happened via ZK hack Lisbon, the event you guys have been mentioning. I was a participant in Zik Hack Lisbon.

>> He won hacker's choice. >> I won hacker's choice with my fruity friends ID. Kind of a weird dating app concept which which was actually done with the now co-founder of Zikke Passport by the way. So you know Zik Hack Lisbon is something that really that was kind of a legendary event where I mean a lot of people actually who passed by the podcast went there the Zika P2P guys even like tong clubs I think globally not was there as well. So, so yeah and then after six months of hackathoning I I joined the the team at ZK hack where yeah as you explained the the mission was really growing the ecosystem also the interest in ZK was you know more newer so people were really into into discovering ZK experiencing with it and it was harder

than it is now as well. So yeah, I mean you know we I mean you know about that obviously Anna but we had a lot of fun organizing the hackathon the study study groups with GMO actually we had one maiden so yeah it's all like the >> the whole group all together and and yeah I've joined the maiden a few months ago basically together with the the spinout announcement that Bobin just mentioned. So yeah, it's been a ride changing rules, you know, from time to time, >> but uh but yeah, it's it's been very fun so far.

>> And we miss you over at ZK Hack, although we also still see you over at ZK. >> I do miss you, but I mean I'm still in a lot of chats, so I see what's happening. >> Agreed. Also helping us a little with ZK Mesh on the side. Yeah, very much appreciate. >> And you are the host of the recent Zikke Hack Berlin, our latest hackathon. >> Yes. Uh it was really really great. I mean, it was a great event, you know, packed with people. The project were awesome. Yeah, actually I encourage people to check it out. It's I mean I always find the Zika hack project awesome to be honest. But yeah, in Berlin I feel like it was probably the the best in terms of quantity and quality. You we almost have quality but this time it was also quantity. So quite

impressive hackathon. >> I mean you being part of Zik Hack hackathon from that starting point of Lisbon, you were at all of them because you were like participant in Lisbon and then behind the scenes for Istanbul, Krakco, Montreal and Berlin. And I also felt like Berlin I mean it's some of the best like we had we had Nicohost of the show hacking we had the powder team hacking a small world it's a small world >> expert we had Ying Tong hacking we had these like amazing >> you know practitioners being part of the hacking community >> but also you know this young kid who just invented this anti-chit you know software and he came second. So you have this yeah the OGs I would say but you also always have some new people flowing in and that's really what I love about

Zika to be honest you always have new faces and you see the enthusiasm it's it's really great to see >> it's been fun to do okay so let's jump into Miden the topic of today's show like you you've just mentioned Bob and sort of the advent of Miden but I think we should define like what Maiden actually is what is it as a ZKVM what makes it different you sort of mentioned a blockchain is it an L2 I'm curious like yeah how do you define maiden today? Maiden term is somewhat ambiguous and maybe we should have picked different names for different things because it refers to for examp which is an independent thing that is kind of a ZKVM that is not a risk 5 VM it's not EVM it's its own instruction set and we have kind of like good

reasons I think for going that route but it is like it is basically a different ZKVM that you can you know write programs using Rust in and it kind of executes this this programs but you know it doesn't adhere to an established instruction set architecture The maid and the blockchain itself is a kind of a blockchain protocol that as I mentioned I kind of like I first authored and it changed a lot since then but the first kind of like idea was about three years ago uh and it is a it is an L2 like we're going to market as an L2 it is going to be actually a centralized L2 and I can talk about kind of the rationale for that but going to the core of it it's kind of like when I was thinking about you know what the ZKVM could be used for and this was

actually I was actually always kind of developing ZKVM is this use at least one use case environment. This use case was to use it in the context of blockchains. >> Even if you like go back the first post I made about ZKVMs I think was like in I want to say 2020 uh on like ETH research forums where I was like hey I think I have an idea for ZKVM but I I think it could be used in a blockchain context. So it was always kind of >> in a back of my mind of how can we use this but >> kind of a bigger thing for me was I saw a few issues with blockchains to be honest like from the you know I got involved in blockchains with blockchains like in 2018 but the two main things that always bothered me was the

scalability aspect where I just didn't think you you could handle like thousands and s of transactions and still be like true to the blockchain uh kind of like original principle so to say and the second one is privacy because for this to work in my mind there like the privacy is an absolute must. You you don't want to live in a dystopian world where you can you you know transaction history and basically entire life is traceable for anyone who has internet access. And so for me kind of the journey to get to this like design of the blockchain was to figure out how we can solve both scalability and privacy at the same time.

>> And ZKVM was one of those things that I thought was required. And at the point when I said okay now I have a ZKVM to play with like what can I do? how can I build a blockchain out of it? And here like one of the things that uh I remember like even writing that blog post like about 3 years ago about how like I want the blockchain to work and what are the main principles for me it was like I didn't want to add this to an existing chain because all the existing chains were kind of designed with kind of like some limitations they didn't know about ZK at the time right so like Bitcoin Ethereum and basically almost every other chain with maybe a few exceptions were built with the kind of presumption that you need to reexecute transactions to have a running

blockchain. And that imposed quite a few limitations on the design. And here I was like, okay, I have ZK. How would I design a blockchain if like I started from the ground up? >> Yeah. Yeah. >> And so a couple of principles that I had at the time for my which I think I realized most of them except for maybe one. The one of the principles was I wanted to have parallel transaction execution where people could execute transaction independ independently of each other. You don't have the sequential execution where one transaction needs to be executed after another because you know again if you can execute a thousand or 10,000 transactions in parallel and that can be done by you know ideally by people who actually want to execute those transactions that's a clear path to scalability. The second one was privacy.

As I said, I want to have privacy to make sure that you know it doesn't have to be only private, but it had to allow people to be private and it should have like the one of the principles I want to make sure is that the privacy was incentivized somehow. So that you wouldn't have to pay more to be private. You would actually have to pay less to be private and you would have to be paying more to be public. >> And that was like another thing. And the third thing I wanted to have smart contracts to make sure like I didn't want to have something that you know just payments because for very cool applications people come up with like different things. So like I did want to have smart contracts and here I think there were two things like one of the things I I wanted to make it EVM

compatible which I wasn't able to do in the end. So that was one of the things that kind of got thrown out >> because I couldn't figure out how to make like smart contracts private and EVM compatible. So we're kind of >> if they're like solidity based and stuff. Okay. >> Yeah. So that that was kind of on smart contracts. Those were the main principles and like the the I think the next one is kind of a smaller one. I also from a scalability standpoint was trying to figure out how do we make it so that you know the state of the blockchain doesn't grow too much right because execution is one of the issues like you don't want to execute transactions kind of sequentially but another issue is like the state is ever growing and how can you minimize it otherwise you know your state goes into

terabytes or dozens of terabytes and that's also kind of against principles of decentralization so to say. So with those kind of principles in mind, I was like, okay, let's design Miden from the ground up. We kind of like iterated a few times on this. We came up with this marketing term, the edge blockchain, where the idea is that you can move both execution and state to the edges. And it's kind of like play on client side proving I guess, but a bit more than that because >> the idea is that both execution or most of the execution happens on user devices and also most of the state is stored on user devices. And so kind of like a nice term for that was edge because this is I mean also popular in other in other industries and we thought it you know could be a good description. We'll see

if it takes off or not. >> But yeah so like maiden we call this edge blockchain where users can execute their own transactions. They can send proofs to the network and the network verifies those proofs. Users can also store their own state. They don't they only can send commitments to the state to the network. >> That comes with its own trade-offs. You know their challenges and benefits. And then we also have this notion of like public and private. So you can have like network accounts that are public that are maintained by the network where you can have like a AMM running for example or you know something more traditional and you can have this private accounts interacting with public AMMs and so on and so forth.

>> Were all of these ideas already formed end of 2022 or are you describing like things that have come since 2022 and like you've started to explore? >> I think the principles and like the goals were there in 2022. Obviously the design changed quite a bit since then. Like you know if I go read the the initial post that I wrote about it is maybe half of it is still like relevant and the other half is okay this doesn't work this way anymore. we've changed things. But I mean this is like you also don't know that like when you describe things at the high level it feels okay this is simple but then once you start getting into details it's like okay there are trade-offs everywhere and like if you do this then you can't do that and you know you have to figure out how

to deal with those trade-offs and in dealing those trade-offs like the design naturally changes. >> Got it. >> I have like a gajillion questions. I mean, they're these are all like very very cool things and ideas and like tr trust me, you know, you don't have to like threaten me with a good time type of a thing because I I love this stuff. This is like catnip like I'll crush it up and snort it any day. So I guess to start actually one of the things that I've always found very fun and interesting specifically here is you guys actually built your own ISA your own instruction set like >> and it's always been clear to me that like you know right now we we spent a lot of time retrofitting ZK proofs to like ISAs that like we know and love and the reason why is because there's a

bunch of like developer tooling that compiles down to standard ISAs like risk 5 or EVM which is even worse version of that and so on and so forth. So I guess first things first philosophically why do your own ISA? I obviously have a lot of thoughts about this but specifically I want to get your thoughts on it. And number two is how does it differ like why you know not just why build your own ISA but like what do you get from it and like how does it differ from like you know what most people might know or most a strong term but like some people might know like risk five or something like that.

>> Yeah. Yeah. And definitely so I think there are a couple of answers to that. One of the answers is that at the time when I started building Maiden VM, I didn't actually think you could do like something like ZKVM or risk 5 efficiently. So like that was one of the first things I was okay like this is not going to be practical especially if you want to do proofs on the client side you won't be able to do those proofs in any reasonable amount of time. And so it was kind of I need a different VM that can run in a browser and that can generate proofs like on the smartphone or something like that. So like that was >> one of the reasons. I mean I think we will get there to be honest like with risk 5 and others. We probably I mean

we're kind of close to this now. I I think they still like require fairly large machines to generate proofs and all that stuff but 2 3 years down the road maybe a bit more. I don't know like you will be able to run risk 5 on your phone. I think I mean technology moves pretty quickly. So that reason I'm not sure it's as valid anymore because I think you can make it work from the performance standpoint. Although I would say like Miden is very lean especially like as a VM if you run it in a in a browser you can generate proofs fairly quickly and all that stuff. The other thing though was like this different feature sets that I wanted to have that were specifically for blockchain purposes that and some of them you may say maybe there's a way to emulate with more traditional ISAs although at that

point in time like it's it's a question of does it actually you know is it still a traditional ISA if you add a whole bunch of like specific things to it. Like one of the things I knew for example we wanted to do is like and this is like veryam like simple example verifying Merkel proofs because I knew Merkel proofs verification was going to be like a very important thing in the context of blockchain. So we have an instruction that verifies a miracle proof in a single cycle. It like abstracts that away but there is an instruction in the VM that does it in a single cycle. >> This is the the risk five you know blockchain extension I >> exactly. Yep. Yep. If you can if you can do risk 5 blockchain extension those are the type of instructions that you would want to add I think.

>> Right. Right. Right. Then the other thing that was important is like built-in context separation which we use a lot like there's actually the the way Maiden VM is designed is that there's like privileged memory spaces versus unprivileged ones and you know you kind of can get some of that with traditional architectures but this is like built in the VM level where you can't write from like if you're making a contract call the contract call can go back to the previous contract and write into the memory and like there is it enforced not at the compiler level but at the VM level itself. Uh so there is like this context execution context separation that we rely on quite a bit.

>> So you're kind of like also as part of the ISA/ like VM you're also writing like a mini operating system which is like roughly keeping track of you know like access and privilege in different places or whatever which is kind of interesting. Okay. It's just like baked directly into the VM. It's like a hypervisor style thing or something except like >> Yes. Yes. I mean I think we didn't go all the way although if I can figure out how to make it work on a constraint level I would love to go there but there's like actual like the resource model where you can borrow resources and do all kinds of things. It's not quite as sophisticated but it's like it's quite a few steps in that direction where you kind of can emulate those things relatively easily.

>> Very cool. And a third thing is the way we commit to programs that which is very unique and I think is useful in the context of blockchain and I wonder if like somebody will actually use it in different context is that like mm is not a van machine. There is no program counter. There is no kind of like program written in memory. What we have is a merkelized abstract syntax tree and the way you execute a program is you traverse that tree. >> What this means is every node in that tree is a commitment to a program under it. And so what you can do is first of all what this allows you to do is unamiguously commit to a program that you want to execute. So like you would say okay this is the root of my this is a commitment to a program and it is

fully described like the Merkel 300 is describes the program and this is a commitment but you can also think about like calling other functions. How do you call another function in a traditional VM? You call it by reference right in Maiden VM you call it by hash. You specify the hash of that node that you want to execute and it makes a call. So it unamiguously says this is the program I will execute when I make this call. You can't modify that program at all. Like it's cryptographically fixed which is useful when you have like a contract and the contract commits to specific code and this code like you know like you can't modify this code without changing the commitment to the program. So >> so essentially like you can think of so in in Maiden okay sorry we're going to get into like the nerd version of this

but I'm still curious like in Maiden a program is essentially like a pure function that exists like in the wild, right? And like yeah it can reference some data but fundamentally the pure function is uniquely specified by like the literal like abstract syntax tree of the underlying program. So when you execute the thing you're just like okay sir please go and like open up each leaf of these things execute the like step in between and then at every point like you've just essentially like the proof now is like have you opened up all the leaves and executed each thing in in you know in sequence sequential order or something like that and then there's a secondary point which is like okay now you need to like hook that up to some data but the data is like external to the program right and like the program

itself is like just some function takes in some abstract arguments outputs some abstract whatever thing with a proof the arguments themsel elves have this like sick thing which are like great like that's lives somewhere on the blockchain somewhere which I I have a question about how you even point to that data but like whatever but that's fine like all we're doing is just like please give me the hash of the program I'll go execute it on this data and like you're totally good you don't need to do all this like start interesting things with smart contracts which like you have to have different smart contracts if you have a factory of them then you have like weird >> things that like you have to proven that you've correctly done it just like gets very very complicated okay very interesting very Cool. Another thing about this is like it's basically

content addressable programming. If you think like IPFS, it's content addressable data. This is the same thing. You have content addressable programming where a hash like has a program under it and you look up a program by its hash, >> right? And you can also compose programs quite easily too because the like a program inside can call like another program hash somewhere, right? And then you just prove the correct execution of that and then like you just like return back to the caller. There is another nice property to this which I don't think you can easily get with other approaches is where you can selectively deal reveal different parts of the program without revealing the rest of the program. So I can open up a single leaf or a sub tree and show you that this is my part of the program without showing the rest of the program. So it

kind of allows me to keep part of the program private while showing you the the other part of the program there. >> Also it probably makes it cheaper, right? Because in a lot of cases if you have a very big branching program there's a bunch of branches you probably never traverse, right? So you only have to open the things that like actually get executed inside of the sync proof. >> Yep. That was one of the original design rationale for this where I was like you have a big smart contract but every at any given transaction maybe executes like you know five or 10% of the code in there like we don't need to unhash the entire program to be able to execute a few functions out of it.

>> I want to do a bit of a throwback to what you had said earlier and also the earlier work. I'm curious for the Maiden blockchain. Is it still starks under the hood? Does it use Winterfell or was that sort of like left behind? Is that the ISA is kind of what I'm trying to figure out. >> Yeah, so it is Starks under the hood. Although I should say I'm not married to a specific proving system. So like uh maybe we'll get into this later but like >> I would actually sleep better at night if I knew that there's two independent proving systems proving my VM and there's no like maybe it starts in the hair or maybe it's something else maybe it's pinas somewhere in there.

>> Yes. >> Um but overall it is using starks for now. Uh it is actually using Winterfell still but we are in the process of moving this to plunky 3. uh the main to be perfectly honest like I didn't invest a lot of time and effort into Winterfell over the last 3 years and so it is roughly at a state where it was like 3 years ago and at the time it was one of the best proving systems in terms of speed and others and but now there are better things out there and so we're kind of like hopefully by like Novemberish time frame we'll be on PL3 depending on how the migration goes >> I think one of the challenges there is to make sure that like plunk 3 is actually faster than Winterfell in the aspects that we want it to because >> you know we're still using the

Goldilocks field and so PL3 is very well optimized for 32-bit fields but it's not as well optimized I think for Goldilocks fields and you know we'll in the process of this migration we'll figure out either how to make PL3 as fast or you know come up with some other solution. >> Goldilocks is what 64 bits or something like that. >> It's funny even asking though that question of like is it Starks because we've sort of on the show realized that Starks and Snarks are kind of intertwined. I almost wonder like is it Fry? Yes, it is. >> Are you actually looking at the fry alternatives as well? I don't know if I don't know what's in planky 3, so I don't know if that's already been experimented with like that were or stir or these new things are being also used.

>> They're definitely interesting. I don't think we've experimented with them seriously enough yet. Uh, okay. >> Pl 3 has this twist on fry where it's like a multi-table commitment scheme which is still using fry but you can kind of slide in different tables at the different levels of fry. We may not end up using that. There is another I think there was a presentation that uh at the laziki hammet about lifted fry we may go with that direction uh >> which is allows us to achieve the same goal of multi-tables but using still fairly simple fry >> I think for what it's worth is working on a word plunky 3 implementation >> oh >> for what so that might also be of interest >> that could be very cool as well because one of the things we try to minimize and I didn't mention this but like in a kind

of description of differences of mm versus others is one of the things we try to reduce really is the proof size, right? Like if you run a lot of other proof proving systems you get proofs that are >> couple hundred kilobytes sometimes even go into megabytes depending on which even start based ones because you know on the server it doesn't really matter what the proof size is right you send it to be recursively aggregated and to another uh server that is next to you and so it doesn't really matter for us because we want to do client side proving we want to keep proof sizes small and so for my VM right now a transaction proof is still fairly large it's like you know but it's somewhere around like 80 or 60 kilobytes or maybe like you know depends on what Exactly.

You're proving but it's definitely under 100 kilobytes and with o or stir you can you know if we can bring it down to let's say 60 50 or under 50 kilobytes that would be a clear win. So like that is definitely an interesting thing to explore. >> Yeah I think at 50 or 60 kilobytes I think essentially your like standardly hero territory uh like I think will actually be about as good if not better >> but maybe not. I we need to actually like work out the mechanics of that >> to continue on that language question though and the ISA question. So you're saying like Winterfell getting switched out eventually for Plunky 3, but I'm actually not clear like is Plunky 3 Rust? Like what's the language then?

Like is it its own ISA? Like I thought of risk zero and their first sort of ZKVM pitch coming by the way after yours I think you for me at least the ZKVM concept was like you got you and I guess Cairo was also kind of a VM but like I don't think they used that term back then or Cairo starknet all that but yeah going back to the language like yeah what is the ISA >> so plon 3 is written in rust but like technically there is no ISA for plunky 3 right plunk 3 is a toolkit that you use to build like the other provers. Yeah. I mean the circuits they have the rust way of like I think they call it air builder that the approach that you encode the constraints >> but you can build any ISA on top of it.

So when we talk about ISA I'm talking about ZKVM specifically. So you could have miden you could have SP1 you could you know risk zero could could have used clon 3. I think they have a different proving system under the hood, but the EVM could, you know, the ISA of the VM doesn't matter like the proving system is kind of like it sits at a different level in my mind. So you could use >> we don't need to change the ISA of the VM to go from Winterfell to Plunky 3. >> I see >> things under the hood will change, but as far as the user is concerned, it it will look the same, >> right? You can think of it as like programming language compiles through a compiler to ISA. ISA then gets like executed in big quotes by like virtual machine

>> uh which is itself then proven to have correctly executed by a >> proven system >> sustain proof system >> like plunky 3. >> Exactly. >> Yep. >> Exactly. >> Exactly. And so and any of these things can just kind of be like modularly replaced with something else that like does not change the you think of these as having like interfaces between each of these steps and they're all like consistent. >> So changing the mechanics of how one works doesn't should not change the like exact things. Obviously like in practice it's there they're sometimes a little bit more intertwined but like you know >> I think by the way one thing about languages I want to bring up is that at the very top of this chain that GMO described it sits like which language do you code in >> so >> true >> because you know if you think about like

what the actual user sees and that's why risk 5 is very popular because you can just take rust or you know C and you can compile it and all the tool change remains the same you just run it like you you code in the familiar language and that's like the big appeal On the other hand, you have other systems. You know, you brought up Kaio for example. Kairo has its own language that they've developed and you know it's similar to Rust in many ways but it is a different language. So you kind of use something different and you know similar other projects have different approaches to solving this. With Maiden what we've done is even though we have a different ISA we are targeting Rust as a primary compiler like language in which people write programs and smart contracts. And so what we do is we have a compiler that

takes the Rust program, compiles it down to web assembly and then we transpile web assembly into Maidon assembly. >> Okay. >> Yeah. This is actually a part that's quite important for for my job actually because since I'm talking to the builders, if you don't do that, if you don't have the rest compiler, that means you have to use this language called Men assembly to write your smart contract. And >> it's not as bad as it sounds, but still it's not as easy as writing Rust. So yeah what Bobin is explaining is like rust as an entry point for the smart contract language is so much easy you know as a cell for the builders it doesn't mean my data assembly would not exist but you should see that as the the ule of the EVMS whereas the rest is a solidity kind of so yeah this is we will

still have this kind of optimized language for the VM called maiden assembly but the rest compiler allows you to skip that part if you just want to write some rust and don't need this hyper optimization that you will get with maza Okay. And actually, this was the question because we were talking about all of these ZKVMs. Apparently, according to an episode I recently did with Justin Drake, there are 32 ZKVMs. >> That's true. >> Crazy. But a lot of them using the Risk 5 ISA, which has always been some one of the selling points is always like and then you can just re write rust. But it sounds like for Miden you also can just write rust. It's not like that's a real differentiation, but there is this maiden was or not mid and wasn't maiden

assembly that would be I guess closer to the bare metal like just like a bit more. >> It's funny because you say yeah I mean mazm we say mazm and then you have wm but because wadm is the intermediary I mean it's technically rust to wom to mazm to the vm these are the steps. So it's a yeah it makes sense that you mix. So wait for the VM do you compile W was directly to like I assume Mazm is the VM like ISA or is there a lightweight VM running on top of MidenVM which executes MASM right like cuz W was itself is obviously not like a it it kind of gets compiled to like real source code like under the hood via ahead of time compilation but like not real I mean

it's still like its own thing that's like separate and kind of you can think of as like a mini VM that gets executed in like a container inside of or like you know Safari or whatever. >> So Maiden assembly is basically an ISA for the VM itself. So but there is a small translation step that is happening because like we added some syntactic sugar to maiden assembly to make it a bit easier to code that like gets translated but translation is trivial. So there's an assembler that takes it and translates it into the what we call a must mer syntax trees because >> mazam mass >> wazam mazm.

>> Yes. Yes. Yes. Exactly. >> Rust at the top. Yeah. >> Yeah. So true. >> Like if you if you think like maiden assembly is roughly at the level of ule in terms of like if you can think it's not like x86 assembly where you deal with like way lower level. So min assembly is like at the level of ule kind of you have like a control flow you know like there's an a while loop for example you can write >> that's what I meant it's not that bad I mean it's called assembly is a very poorly chosen name by the way it's very bad publicity but it's not like you're not writing assembly assembly is as Bobin said it's it's not that bad it's a bit easier it's still stack but it's >> it's still unpleasant to code in it's still unpleasant to rust is much better

>> yes >> and actually by the time I think this episode comes out we'll have a blog post Because just last week we released the first version of the compiler that is able to compile smart contracts written in Rust into and execute them on Maiden. Before that we had like pure Ras programs where you would just take a pure Ras program and be able to compile it and run it on Maiden VM. But now we actually have the concept of smart contracts. I mean there's still a lot of work left but that was the first version where you could end to end write a smart contract in Rust and compile it and run it on my test net. >> Yeah. Now we really have to release it because you just announced it. So >> yeah, >> there's no way back.

>> You have a couple weeks. Um, so I I kind of want to throw back to what prompted this is something I had actually meant to mention a little earlier in the episode, but there was an episode that we did, GMO, you and I, with MU. >> That's right. >> We were talking about Lihero and the concept of ETH proofs came up. This is before my episode with Justin, so I'll link to both of those in the show notes. But I think GMO, you had some hot takes about EVM and the issues. I know you've already just talked a little bit about some of those challenges, but this prompted Gaylord, you to weigh in. >> Yeah, I I actually posted. Yeah.

>> Yeah. I want to just talk a little though. Right now, we're talking about this Rust line through, but is there an improvement over EVM? Do you do you think you will actually have EVM support? I'm just I want to kind of bring up that question of EVM especially because in my interview with Justin you know ETH proofs this this effort to coordinate a lot of ZKVMs together they still have at their heart EVM and you guys are not doing that and so this is where I'm wondering like how does that all work? >> I see for context I mean I hope he doesn't mind but yeah Justin is kind of caressing anybody building a ZKVM to prove Ethereum blocks. So you know he did that to us and you know it's cool that's one of the use case but you know you can do other things with the ZKVM.

Okay. But yeah just just to give the the short history I think yeah I posted right after listening to the Liero episode which was a few weeks after it came out you know because GMO was ranting about you know how blockchain should be built and it also reminded me of a bunch of rants he did a few months ago which I just checked again for this episode. So actually originally I think you published this blog post which is literally called like how blockchain should work or something like this. Oh yeah. >> So where you had a few ideas about how we should build a blockchain in 2025 and yeah it kind of made me think of Maiden where we you know we built it from the first principle very differently to what the EVM looks like. So yeah I think that was also how this episode I guess came

to be. >> Very cool. >> There are kind of like actually a lot of other overlaps. You had Kirsty and goblin notes recently about talking about local first and in a way the edge blockchain is kind of like I mean it's a different thing but it is local first where you store things locally and you don't want to rely on the you know the cloud in this case network as much as you do now with the most of blockchain design. So like you're pushing the data to the edges and the user should be kind of autonomously managing their own data. There is no reason why state of my account should live on a public blockchain. I should hold that state.

>> I like that. >> And myself. Yeah, >> that's funny. I'm going to link to all of these episodes, but I do want to kind of continue on the this sort of EVM comparison and just like exp like go a little deeper on what did you do that does fit maybe what GMO had suggested in terms of like an optimized blockchain and what have you not done yet like what are the limitations that are harder to do? Talking about EVM specifically, there is like Maiden can execute Rust and with a little bit of work we can get like running raft or something and proving EVM blocks. Whether that's the best use case for Maiden is a question >> it's not optimized for that. I guess >> not I mean you could optimize it by doing pre-ompiles and all of that stuff.

So you could get there and it maybe relatively performant but again I think the core design of Miden was not to do something like that. that was to support this architecture of uh >> you know like the way the blockchain the mining blockchain is designed is by this and I'm going to get into this design of the chain itself like the difference it's actually not an accountbased system and it's not a UTXO based system it's a combination of both it's kind of like a mix like yeah people sometimes say like if Bitcoin and Ethereum were to have a baby it could look like miden >> okay >> wait I have one side before you dive deeper into this architecture you used to work with the Facebook team and you know sui also came out of that and I wondered if there was like any similarities between we've had Costas on

the show to talk about Sweet. They have all sorts of like unique blockchain stuff. Did that influence at all? Miden >> for sure there was some influence. Uh um >> ah >> what I like about and like a lot of the move based things is the kind of the concept of there there are a few things like there's the object model in for example which I've tried to like somewhat emulate in Miden as well. It's not one to one it's there are differences >> but like the concept of nodes and like accounts and like you have objects in we would like to actually move more into that direction there are limitations in the zk side why it's you know I wasn't able to figure out how to support full object model >> but like the idea of that is really cool and I think we'll try to move more into

that direction >> the other thing like that comes with move is this resource management like the re that you have resources at the base level of in the language itself and I think this is super important for safety and other reasons Uh and so again, we kind of emulated this. We can't run the full move because again, it's more complicated and we just >> they're not using ZK at the in the base chain. >> They're not. Yeah. >> But I think this is really cool concept and we again we have some parts of that where one of the things for example in Miden diving deeper is that there is no native asset like there is no like Ethon, Ethereum, or Bitcoin.

>> There's no gas token. >> I mean you could use anything for gas so to say. I mean there's like I'm not going to go too much into the details but you can have many assets and they look as if they are native. So like you can create assets and you don't need to have a special smart contract like on Ethereum like you you know you have a native ETH but everything else is a smart contract. Here you can have native assets and >> they move through the system in a way where an account has a full ownership record of all the asset it owns. It doesn't need to look into other accounts to figure out like do I own this or do I not own this. And this is important for making things local first or make taking them to the edge because if you have

some global smart contract recording ownership of all assets then you can't take your account off chain because somebody else has to keep track of what you own and it also creates like a lot of issues with sequential execution because you know if I need to update like if I'm transferring USDC to to Gaylord and then then Gaylord transfers it to you Anna like we can't do it in parallel because we have to update the same exact account uh on Ethereum while in theory we should be able to send like you know two independent transfers could happen independently and you know if you have assets as a core primitive at the protocol level then it makes things much simpler so >> cool I want to go back to you were actually explaining the architecture I think we've gotten little pieces of it through this thank you for answering

that question yeah I just I figured like you guys work together maybe there was some similarity there but yeah keep going with the sort of how Maiden's architecture looks you were about to dive in there >> yeah so on on Maiden we have both accounts and UTX. So we call them nodes. Actually I would say the inspiration came more from Zcash than from Bitcoin. Uh so we have like concept of nodes and nullifiers but we also have concept of accounts as the first class citizens. And so the accounts look very similar to Ethereum accounts. Ethereum smart contracts I should say. So every account is a smart contract. So it has code, it has storage and unlike Ethereum every account as I mentioned has the full ownership record of what the assets that it own. So if you have a USDC or ETH or USDT or whatever, it's all recorded

inside of your account. >> Mhm. >> And the way accounts communicate with each other is by passing notes, the messages. And this is where the UTXO part comes in. So if I want to send, you know, some USDC to Gaylord, for example, I would create a note that takes the USDC out of my account and there's a now UTXO living on the chain and then Gaylord can consume this UTXO later on to claim the funds and move it into his account uh later on. >> Getting rich. >> Yeah. And like this separation allows me kind of to update my state of my account independently from Gaylord updating state of his account and execute this transaction separately from each other.

So both allows for parallelism and privacy. Privacy because like I don't need to know state of Gaylord's account to send him funds. I just create this UTX note and then he can consume it. And then parallelism because like you know me sending funds updates only my account but if you're sending funds to Gaylord or to Gileiam at the same time you update only your account and so you don't need to update mult like multiple accounts simultaneously and so this is like a very different model and this is also why making it work with EVM was like challenging to say the least. I couldn't figure out how to make this work in EVM because there are con conceptually very different ways to program this. You create nodes the nodes get consumed. It's actually not a new paradigm. It's like it's called what

actor-based systems. It's an actor model where you know there are programming languages like Earl and others that work on actor based systems where the way it works is like you know you have actors that are accountants in our case and they send notes to each other, messages to each other and other actors react based on receiving those messages >> and uh we just applied the actor model to you know they sprinkled some ZK on top of it and applied it to blockchain. So that is kind of like the way to describe >> it's actually I mean I literally had a workshop yesterday on boarding builders and this is exactly how I explained it. So I first explained the actor model which is just you know you know concurrent computational model. So you have the actors, they all have like a mailbox and then when you communicate

between each other, you just send a message to someone else mailbox. But by doing so, you don't interact directly with them and you're just fully responsible for your own state, how much money you have, how much money you sent, and then the the envelope, the mail that's, you know, going to the mailbox. It's out of your hand. So for you, your job is done. Then it's the job of the other actor to actually pick it up, you know, empty the mailbox and then to to get it. So having that you manage to have like isolated states and that's how you achieve yeah parallelism but also privacy >> and it creates a lot of like cool things that are difficult to do in other context and one example of this is like all these nodes are fully programmable like every node has a script that you

know can be executed that defines how this node can be consumed and all of that stuff and one of the things that you can emulate here is like recallable transactions. So like if you send something like you create this node but the the other person does not consume this node in a given period of time you can claim it back. So like if you screwed up an address for example like your l your funds may not be lost because if you send it to the wrong address you know the other person just you can claim the node back in let's say four weeks time or whatever. So like it allows you to do this kind of things that are difficult in a traditional blockchain. I would say >> you would have to program it in the in the script that Bobbins mentioned. But yeah, it's like emptying the mailbox, so

to speak, because maybe the bane box actually doesn't have a house. You just, you know, you you messed up the address quite literally in that case, but it enables some new stuff. Yeah. >> I mean, it's also like the boomers among us. Actually, it's not even that. It's like I'm sure the young the young do it. Yeah. But like this fear of like, oh my god, I'm going to put this address in wrong. Like >> checking, re-checking, double checking, be like, you know, that once you send, >> you should still check, but if you mess up, you have a way to, you know, fix your mistake. >> Cool. I mean, one of the big features of the Miden project has been its focus on privacy. even through sort of the privacy dark ages like the period of 2022 to 2024 I'd say where a lot of

projects that had initially been privacy oriented got a little nervous mostly because of the tornado cash and moved away from that. Miden was always very privacy focused throughout that time and there have been I mean you weren't alone there were some other privacy projects that were released during that time some that are coming up very soon so things that come to mind would be like Aztec always consistently focused on privacy and actually just recently Penumbra I mean Penumbra came out what is it a year or two ago but just recently has actually wound down I want to talk a little bit about the privacy question like first like have you found it challenging to stick to privacy and how

are you thinking about privacy because there are these different flavors of it. >> Yes, definitely. First of all, as I mentioned in the beginning, I absolutely believe that privacy is essential. You can't we can't make in my mind blockchains work without privacy. It's just not going to we're not going to get to the level of adoption that we I think we all hope to get to if there is no privacy or if the privacy remains at the level where it is right now. And so this has been something that, you know, I personally have been trying to work on and solve ever since I got into blockchains. It's just like it took a detour into ZK to figure out how ZK works and teach myself ZK and all of that stuff to actually know how to address that. One of the things I would say though is that we're trying to be

somewhat more pragmatic about privacy. Like I'm okay with sacrificing some, you know, absolute privacy things in the short term if it leads to a better UX. So like one of the things I really don't want to do is like have a really cool privacy product if it means like people need to chew glass to use it. >> Okay. So ease of use. Yeah. >> Yeah. Ease of use in my mind especially in a shorter term like is more important than you know absolute privacy and giving people like you know ability to defend themselves against nation states or whatnot. >> Um I think in the long term this is absolutely important but I do think that it shouldn't be a sacrifice for you to use to be private. You shouldn't say, "Okay, I want to be private." And you know, I've used Turnout Cash and at the

time the experience wasn't I mean, >> it was difficult and it was expensive. >> I mean, it was difficult and it was like I paid like $30 for a transaction that should have cost me I don't know less than, you know, a few cents I think at the time. I don't remember the exact numbers, but I remember paying like >> 100 times more than I should have paid and like, okay, am I going to use it in daily life if I need to pay 100 times more for a transaction? >> The cost is part of the UX actually. So, it's quite important as well. >> Yeah. And so one of the things that with Maiden is that on the one hand as I also mentioned this in the beginning where I think you should be incentivized to use privacy in the context of Maiden design

like you can do things yourself. You can execute transaction yourself. You can store the state yourself but then you can also do it on a you know upload the state to the ledger and have the public state or encrypted state but in that case it would be more expensive because you are asking some the network to store your state and so the incentive here is like okay I can be public or I can be like encrypted on chain but then I would need to pay extra for this and so I think this is the right incentive design on the other hand going to back to this pragmatic approach >> I think one of the things that we're like we're starting starting out as a centralized L2 too. And one of the reasons for this is >> you know what we want to do in the

beginning is have this training wheels where I don't trust the proving system enough yet to say that everybody you know like let's go and like open it up for everyone to use. So like my approach is to have this training wheels where we can double check the proofs for the first you know two years maybe three years and then once we feel comfortable maybe once we have two proving systems proving the same thing we can say okay we're removing training wheels. So initially on Maiden you will be private against other users but you would not be private against the operator. So that's one of the distinctions and I think in the short term that's an okay trade-off to make because it you know prevents a catastrophic failure for example. I think you know if there is a catastrophic failure it will not be good for anybody in the space. Uh so like and

you know I would feel and sleep much better at night if I knew that probability of a soundness bug is non-existent or at least negligible. Another thing by the way to bring up like I'm okay with delegated proving like in a way where you delegate proving and give up privacy to some third party to generate proof if you're in a like low power device and you can't generate a proof quickly enough. I would rather you you know give up privacy to some player and then wait 20 seconds for your proof to generate >> but aren't most of the private like not penumbra but like Aztec which is supposed to come out you know it's imminent sort of is also like they do have a validator set and provers >> I think you have to when when you take you know UX into account for the just

for a performance reason you you kind of have I know they're also looking into costs and stuff but yeah that's kind of a must delegate improving when you want to have like you know acceptable performance at least you know now in 2025 but actually going back to what you were saying about the the prover and the the sunlessness bug possibility the way I like to think about it is like in these big factories where you have workers you always have I think it's mandatory by the law you have this big red button that in case someone gets you know a hand stuck in a machine you can stop it so that nobody gets hurt so the way I'm seeing that is very similar here where in case there is a bug we have a way to start things whereas when you're not when you're going fully

decentralized it's a bit harder to do but it doesn't mean you know we will get there and also one way we want to get there we were actually discussing that recently with Bobby and I found it very interesting is this idea of having multiprover redundancy kind of the same way Ethereum has several clients >> actually Justin I think mentioned that they have five because if there's a bug in one or even two then you can switch to another client so here it's going to be the same with the proving system so if you have like you know plunky 3 but you also have the hero or even lierto and there is a bug in Liherito because the research paper maybe was poly written and then you can go back to >> GMA right there but >> fine that's fine you know >> okay I was originally thinking of saying

the opposite I just switched when I saw you pro fail >> but you see what I'm where where I'm guessing with that it's like basically the idea is to mitigate risk really and that's again that's something for the whole industry it's not only for maiden so yeah I really like this idea of having yeah multiprover and that's I think at this stage Maybe we feel good enough to remove the you know big red emergency button and that's that's our approach. >> What is the centralized part in that case? So it sounds like there will be various provers like I like just comparing to other systems that have deployed like how did they do it decentralized and how are you doing it centralized exactly? Is there a validator set? Is there no validator set? Is there a single proving entity?

Like I'm just kind of curious where that centralization actually happens. So initially there will be a single maiden node which you know will post data to Ethereum. >> Is that like the sequencer? >> It will be well so in our case sequencing and proving are basically intertwined. It's uh you basically generate a proof like almost at the same time. I mean there's slight delay but at almost at the same time as you have a block okay >> so there is not a big difference between them. So the idea is that this centralized node collects transactions from people and builds blocks and then proves these blocks and then this proofs go to Ethereum. in in this initial like training wheels period, this will be the only sequencer where the only node and it it will be the only one generating proofs and posting them to Ethereum as

well. And so, you know, you kind of have protection against this node because there's a proving system, but at the same time, if there's a bug in the proving system, you know, this and the node behaves honestly, so we behave honestly, then there is no issue. So like uh >> and that's different from some of the other systems where they launched with a full validator set and sort of handing off that power to a number of different node operators. And to be perfectly like honest, I would say like one another reason is that it's easier to build this centralized approach than to try to build a whole decentralized right right from the start. Like we'll go to mainet, we'll operate in this mode and then you will take the next two or three years to build a truly decentralized system that has multiple validators and operators

and like we have like all the all kinds of cool ideas that we just don't have the time to implement or otherwise it would take us another year or two to deploy the network. And so yeah in the short term I think we because we can be in the L2 we can get this security from Ethereum you know assuming the proving system is sound and we are honest. So it's kind of like one of two assumption we can also bring in other things into this mix as well. >> And then the other thing that to be clear is that like when the users execute and generate their proofs locally they will do this still there is local proving and client side proving but they will also send us the data that will allow us to verify that the proof is correct by initially re-executing the

same program. So again that's why I'm saying there is no privacy against the operator but there is privacy against other people. >> I see. So you would see like as an operator you will see at this first stage like you'll see actually transactions and amounts and everything. >> Exactly. >> Because it's the the the thing that you're doing a proof on is actually being sent to you. >> I mean that's typically what you call this web two style privacy. >> Yeah. >> When you're not private against your bank but you're private against all other people who use the same bank >> which is pretty useful. I mean I think a lot of us still use centralized exchanges as our privacy node.

>> 99% of the world work like that. So yes, >> but again so like I think in the short term this like makes a lot of sense and doesn't like I mean it's drastically better than what we have right now with fully transparent chains. It's not the ideal that we want to get. But I also think it's okay if it takes a few years to get to the ideal. >> Yeah, it's software development. That's how you do it. You iterate and you add the features depending on what people want. You add them progressively. So that's again kind of I think you used the word pragmatic before. So that's in the same vein. That's a pragmatic approach to software development I suppose.

>> What are some of the other challenges though that you see working with privacy? Like even once you become more of a decentralized private system, do you still see like nuanced privacy or are you aiming for full? And this is where I'm kind of trying to dig in here because really a lot of different privacy projects have taken different approaches. We get to learn from some of them, but some of them it's like maybe they were too early, maybe they didn't focus enough on business, maybe they were wrong place, right? You know, like there's all these circumstances that sort of like lead to certain outcomes, but we do now have some examples of launched privacy projects. And yeah, I'm wondering what other takeaways you've you've gathered from them. I think the ideal state of the world in my mind and

I don't to preface this I don't know how to get there yet but I'm hoping to figure it out is that where you have full privacy but at the same time you have like this threat resistance or hack resistance where you can't have North Koreans slandering money through the system uh and things like that >> or like people printing unlimited money because of a bug. Yeah, I'm not sure like uh so the second part hopefully we can solve with like multiprovers and like things like that and like formal verifications and other tools. >> The first one is where how do you give real privacy or absolute or near absolute privacy to people at the same time adhere to some compliance rules and make sure people don't like do bad things. I think that's a very tricky question.

>> It's so tricky. But I do hope that there is there are ways to achieve like maybe not all of it but most of it in some ways where there are some in protocol mechanisms that allow you to say okay if I'm this is not going to work in practice but like let's say if I'm transferring $10,000 like it should be absolutely private if I'm transferring $20 million or a billion dollars maybe there should should be some other things involved where you know it's not as straightforward or maybe there are some mechanism that prevent people from like you know abusing the system so to say and again I don't have a solution right now but I also hope to take this next you know two three years to see maybe there's research enough that can help us in this direction but you know that is

in my mind uncharted territory in some ways >> totally yeah I mean that's why you want a solution that's kind of adjustable depending on the users first you have also individuals and institution it's it's quite different targets they don't have the same needs maybe institutions they are less you know they don't mind so much about the government surveillance but they have other like compliance needs so when you have like adjustable privacy you can actually well adjust it depends depends on whether it's an individual user or maybe an institution. So I mean to be fair right now we are talking also to institution and this is a bit more of our focus like private banking this is also what you know when we onboard builders we usually work on OTC trading maybe peril automation lending staking for treasury so a bit more institution focused in a

way >> and yeah hopefully with the solution being more mature it opens to a larger audience with maybe you know also like nation state surveillance resistance or stuff like that but actually I mean at the standpoint with the current state of the products institutions are actually a more logical focus for us. >> Cool. >> So, one of the things that is kind of interesting you mentioned early on in the episode and I assume this is actually quite tightly coupled with the privacy aspect is this fact that you know you said what's interesting also about Miden is that people are incentivized to kind of maintain state outside of the chain. Yeah. What's what's cool about like succinct proofs and all this stuff is that you know you can kind of hide the inputs either for efficiency sake or for privacy sake or

in in this case both I assume and so I assume this is all somewhat related to but can you talk a little bit more about like what you meant when you said like oh we incentivize people to keep state offchain >> I think basically on maiden you have this accounts and nodes as I mentioned and they can be both either onchain or offchain and so you have this kind of like 2x2 matrix you can think about okay this is an account can be offchain chain or onchain and a node could be offchain or onchain and whenever you create a transaction you would know okay this transaction is interacting with an account that is onchain or offchain or like using nodes that are on chain or offchain and then based on that you would have to pay a fee to the network right so the fee computation mechanism

depends on okay if I'm putting like a bunch of data on chain my fee would be higher if I am consuming or producing nodes that will live on chain the public nodes we call them my fee would be higher because the network needs to store more data they need to consume more resources and so it will kind of happen naturally through the fee system or at least that's our expectation. I mean to be honest like this is not like running in in in production right now but our expectation is that if we build the fee system properly then you know if I store my own state if like okay my account can be a few kilobytes or maybe even like a large account could be megabytes of data if I own a lot of tokens and like have a lot of complicated logic in my account. So it

could be like let's say a megabyte of data which I don't need to put on chain if I keep it privately. I don't need to pay for this extra megabyte to go on chain. I only put a 32 byte commitment to the account on chain. I mean it's a bit more complicated than that but roughly >> and so I don't need to pay the fee for this megabyte. And the same thing if I like run a complicated transaction and in this case like I do think transactions are you know even simple payment transactions would be you know you want to make sure you have like some check against like create limits and things like that. You have sophisticated wallets that prevent hacking and all that stuff. So they all will be relatively complicated and so I prove this transaction myself. I don't have the network proving that and so the

network I don't need to pay a fee for proof generation so to say and so you know I don't know what the delta will be again it's not running in production yet but the expectation is that there is going to be some delta and it will be a meaningful delta because I can do all of the things myself and the network doesn't need to do them >> but this first centralized launch won't have this built right >> there will be a feast in there as well. Yes. So, do you have the incentive to actually do it? Look, I thought you were still sending all the data to a centralized node. >> You do, but like the centralized operator doesn't I mean, we may decide to keep it, but it doesn't need to keep the data. Once it's verified that the proof checks out, it can discard the

data. I mean, there could be good reasons to keep it for other purposes, which we can get into. But in theory, like you don't like the blockchain itself doesn't need to have the data and the centralized operator once it's verified the transaction was submitted correctly can just discard this data and never even store it. So I do think the the incentive will be there. What I cannot say is like you know is it going to turn out to be a big incentive or a smaller incentive that's difficult to predict but that's also part of like I mean we're going to have a multi-dimensional fee model where like different resources you know we have a verification cost resource you have like how much data you put on chain resource you have couple of other things that play into that and so this fee model you know if designed correctly should

incentivize this usage. Yeah, we we don't have thoughts about multi-dimensional fees, you know. Yeah, that's crazy. >> That could be another episode. >> That is a Yeah, maybe it's a good episode, you know, for for a different time. >> I mean, usually cheaper is better for the users. So, >> I think one one thing is important to say because this model is not without its trade-offs, right? Because if I keep the data locally, I am in charge of the data. If I lose it, I'm locked out of my account. So, like I it's like it's a different model. I can right now in the blockchain, I can always like if I have my seed phrase, I can always go and download my information. and it may take me some time to parse through the blockchain or somebody may help me but I can always get the data

>> with this model like if the data is local and if you lose the data then it's kind of like yeah it's lost you've locked yourself out of your account >> and so the solution there is like there and same goes with nodes for example we have the mechanism for distribute nodes through the blockchain but also like the private nodes you have to have a side channel with another person to send them the private node so that they have it otherwise they only see the commitment to the node they don't know how to consume it >> and so you need to build like auxiliary kind of services so to say that allow you to store the the private data start like distribute nodes privately not using the blockchain and you know there could be multiple solutions there for example like if I have $100 in my

account maybe it's fine if it sits on my phone like if I lose my phone I've lost more than $100 anyway so if I have like a few thousand I it's fine if I back it up to Google cloud it's secure enough if I have millions or billions I probably want to have some kind of decentralized solution itself that keeps the state like and so we've actually partnered with a number of like players in the space to help us build those things. So like private state management would be built by open zeppelin, private node distribution is going to be working by nethermind and so like they're kind of like this auxiliary services that you know will come together to saying okay you use the blockchain but you also need these things for private state management if you care about that you can also build it yourself but here is a

solution that allows you to maintain the state privately. >> Cool. Just going back to sort of the origin story of Miden as a project and spinning out of Polygon. I I mean you mentioned that you're working with the Polygon 3 stack, but are there other connections to the Polygon team still or the Polygon products or the other Polygon spinouts? Like I'm just kind of curious if they if it's really like offshoots doing their own thing or if you are going to like lock into the A layer. I don't know if they're still working on that, but like the initiatives that had been happening over there. Yeah, I think I mean first of all, Polygon has been working on a number of very cool things like throughout my time there and even you know still right now is working on a lot of cool things as well. I think like in

relation to Miden we are kind of separate but we are like you brought up uglier. We will try to integrate with the uglier. So like we actually have >> a design of how Maiden will plug into uglier like for for this to happen like uglier needs to support nonvm chains which according to road map is going to happen hopefully in Q Q4 this year. So maybe a bit you know plus minus some some buffer but yeah our intention is to integrate with the uglier and kind of like this is how we can you know post things to Ethereum and will simplify quite a few things for us if we can do that.

>> Will you also be an L2 on Ethereum or like an L2 on polygon? >> No that's L2 on Ethereum. So like uglier settles to Ethereum. Uh I mean there's other things happening in there to allow like fast interop between different chains but in the end it all goes to Ethereum. Mhm. >> And I think PL3 is really we collaborate uh on like I've had some calls already and we're going to have more calls next week about like you know what do we need in PL3 for example that is not there yet and and you know things like that and maybe >> do you build it or do they build it? >> I mean we could build it or they I mean they also have their own plans to to what they want to do with PL3. So on this technical levels we work very

closely. I would say also nontechnical ones I mean we still have very good relationship with polygon and so like if uh if there are some things and even on the business side we can tackle together doing it with polygon makes a lot of sense. So I I think we have very good relationship like I mean with polygon folks both on technical and nontechnical fronts and uh I think even with other projects that kind of spun out of polygon there is the billions network there's this um and maybe there's I may be missing one other one but yeah so like I mean even though we not talking maybe like immediately together but like we all keep in touch and we know what everybody is working on and so like if there's an opportunity to work on

something together That's always like, you know, yeah, I've been part of several mafias of like there's a Polygon mafia, there's also a Facebook mafia, there's like this different mafias running around and you you plug into them and like it helps. >> Yeah, I guess there is. That's why that's why I'm here. I guess maybe one of the thing on the polygon side actually and helping you maybe with the transition is like polygon was very heavy on ZK education you know a few years back and I feel like also we have maybe to you know pass the torch and maybe all of these project I know a that you didn't mention but they're also doing a lot on the ZK education front so you know there is also this yeah this this part that I feel like the polygon alumni maybe are taking over >> for sure and what I was going to mention

polygon was actually the funer and supporter of the first whiteboard session. And I wanted to wrap this episode on the whiteboard sessions because all four of us have worked on the ZK whiteboard sessions at some point or another. ZK Whiteboard sessions for anyone who doesn't know. I think I will probably have mentioned it at the very start of this episode. It's an educational series video series. It airs on the Zero Knowledge podcast YouTube channel and it's produced by ZK Hack. It's all all the all the pieces. Bobin, you were the host along with Brendan of season 1 and part of the development team. Polygon was so awesome like funding that because I don't know if it would have happened without Polygon

support back then and that really launched the series. >> I would say that was like an awesome experience and I think this is how I get recognized the most at different conferences. People come up to me and say you oh I know you from the whiteboard series like they don't know me from my talks or other things but like they know me from the whiteboard series. Those videos have had a lot of views. Like the season one, I mean the first one is with Dan Bonet. It's 32,000 views at this point. >> So, you know, that's pretty substantial for hardcore ZK content. >> Yeah. This is not easy for people. And then I think the videos you you I mean we did for that season, if I remember correctly, we did 16

>> uh modules. We did tons of videos and you were the host for half of them. I think you were the guest on one of them along with Brendan. I want to throw to Gaylord because Gaylord, you worked on season two as a producer with me. >> I'm season two. Yeah, I recorded one in New York, the infamous one. I had to postp like a very intense color correction animation, the Justin Thaylor video because there had been this big like white splotch right in the middle of the whiteboard. >> Classic.

>> But in the production, there is also, you know, the the communications here. there there's actually a lot of work people maybe don't realize but there's a lot of of work behind the scene and you know I mean and I you're also doing quite a bit of it so so yes not only in the production but even in the communication the distribution and also with the study groups that we are that that we are running on Zak maybe I will do some for season 3 I don't know let's see but it's >> well this is the funny thing too yeah we kind of have done like a continuation of like revisiting those early whiteboard sessions season one we did a study group last year going back to season 1 in prep for season 2. Season 2 was funded by the Ethereum Foundation. They had a ZK

grants program also awesome. And all these great teams like Aztec, Polygon, all these people, and I'm missing some here but >> ZK so many >> you you know it had funded the ZK grants that then funded the whiteboard session season 2. And now season 3 comes along and GMO, you're going to be one of the co-hosts along with Nico this time around and it's supported by Bane Capital Crypto. I feel like this just having all of you on for this episode is so funny because >> it's funny too. Yeah. Season one and then two and then is a rookie. But >> I am. I am. I'm you know I'm surrounded by veterans here. I'm the like young guy, you know, trying to make us work.

>> We believe in you. We believe in you. Lot of potential. Well, by the time this airs, we should have I mean, we have at least one module out the door, possibly two or like the second on the way. >> We're planning eight. So, season 1 was 16, season 2 was six, plus the bonuses that Dan Bonet did, and season 3 will be eight, plus possibly some bonuses, but we don't know yet. >> Okay, it's >> very cool. >> Very cool. Um, yeah, it's so nice to to to have all of you here to just kind of reminisce for a second on that, too.

It's been a long-standing series. >> Anna, you're just building institutions is the point. You know, these are like like I I have bad news. Like these are like >> still a bit of work for 300 ZK whiteboard sessions, but maybe >> those are tricky. One of the big challenges with the whiteboard sessions, maybe just to wrap up, like the way that they they work is we spend time brainstorming like what are those fundamentals that maybe have emerged recently? What can we cover? >> We then seek out the guests. We find the hosts. We find the locations. We do the recordings. We have identified every way possible to wreck a whiteboard session recording by accidentally doing it.

>> There are many ways. >> Audio failure, glare. >> The glare is the worst. glare is really the big one. But we have also I think found a really nice model. I know a lot of people have actually used this to onboard themselves into important concepts and I have heard through the grapevine although I I need to find the source here that it has been used with university like as an addendum to university courses >> like not the main but like an extra. So >> like supplementary. Yeah. Yeah. Actually, I think in the ZK MOO, one of these things that happened like last year or something, I think the the season one was referenced if I recall correctly. I remember seeing in the links.

>> Nice. Maybe that's where I got it from. But yeah, thanks folks for coming on the show and sharing with us the story of Miden. Thank you obviously to all of you for working on some capacity on the whiteboard sessions. I think everyone's really happy about that. But I know that we're here for Miden. Thank you so much for sharing with us what you're working on. Yeah. going into the details, sharing this update, getting us a little up to speed on on what you're thinking about and where you're at. >> Messi, one thing I want to add before we wrap up is we mentioned a lot of, you know, competitors. I mean, not even competitors, but actors of the Zik industry. And I mean, I really want to make it clear that I mean, we're really all fighting the same fight. uh you know maybe of course our approach differ you

know the I don't know private church state here or maybe some levels of privacy proable compliance gradual gradual decentralization or whatnot but you know at the end of the day I mean they are just implementation details so you know it's I mean especially for me who knew allo all these people we've been working together for the past two years with you Anna so >> I mean the point is not really to be competitors actually I guess I misspoke it's more like to build you know this this world where actually we don't have a dystopia as Bobin started with, but we have blockchain that can be used by, you know, billions of people since it's been the target from the beginning >> and has these qualities that we really want to see. Exactly.

>> Out in the world. Cool. Thanks, Gaylord. All right. Thanks, folks. >> Thank you for having us. >> Thanks, Adam. Thank you, guys. >> So, I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Hector, who just recently joined, and to our listeners. Thanks for listening. [Music]