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 Connor from Celestia. Now, I recorded this just after we wrapped up the ZK Hack Montreal event and I felt I'd take a moment at the beginning of the episode to chat a little bit about this event, especially since this was an event unlike any other. I've never had to switch venues midway through an event before. I tell a little bit of the story at the beginning of this episode. It was truly an amazing event and the hackers that came through, the sponsors, the judges, everyone was wonderful. And Connor was actually one of those judges. So after this, we dive into Connor's background and talk about what brought him to work on Celestia. We also chat about the ZK initiatives happening within the Celestia ecosystem.

Now, before we kick off with this episode, I just want to point you towards the ZK Jobs Board. This is a great spot for teams to post job ads as well as candidates looking to jump in professionally to find their next job. I have heard anecdotally from many teams that they have found amazing candidates through the ZK Jobs Board. In the lead up to the ZK Summit 12 event happening in October, we will also be doing a campaign around the ZK Jobs Board, so keep your eyes open for new job postings over there. I've added the link in the show notes.

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

Today's episode is sponsored by Anoma. Intents are a new way to build dApps based on user-defined outcomes instead of virtual machine transactions. Anoma is making an intent-centric future possible by introducing a distributed intent-centric operating system. This will enable builders to create user-friendly dApps compatible with any blockchain. Use Anoma to add intents to existing dApps or build on Anoma and settle wherever your users are. Anoma aims to vastly improve blockchain user experience, enable novel applications, and promote a more human-centric future for decentralized technology. Get ready to build with intention. Anoma is a universal intent machine, introducing a new era of applications where you define the outcomes you want. Follow Anoma on X to learn more at x.com/anoma. So thanks again, Anoma.

Aleo is a new Layer 1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash and the scalability of a rollup. Driven by a mission for a truly secure Internet, Aleo has interwoven zero-knowledge proofs into every facet of their stack, resulting in a vertically integrated Layer 1 blockchain that's unparalleled in its approach. Aleo is ZK by design. Dive into their programming language, Leo, and see what permissionless development looks like, offering boundless opportunities for developers and innovators to build ZK apps. This is an invitation to be part of a transformational ZK journey. Dive deeper and discover more about Aleo at aleo.org.

And now here's our episode.

So today I'm here with Connor from Celestia. Hi Connor, welcome to the show.

Hey Anna, glad to be here.

So we are recording this in person just days after our team wrapped up ZK Hack Montreal, and you were a judge at ZK Hack Montreal. So maybe we can talk a bit about how it went.

Yeah, yeah, ZK Hack was really fun. Got to see a lot of great projects, learn a lot and -- yeah, great time overall.

What day did you arrive?

I arrived on Friday.

So you were there at the original location?

Oh yes, where the power went out and we ate poutine in the dark in an old theater.

Yeah. So I just wanted to take this minute to do a little recap of this particular event because this was definitely a hackathon unlike any other. Context for the audience, this was ZK Hack Montreal. It ran from August 9th to 11th. It was scheduled to be at an event location called the Rialto, which is like an old theater from the 20s. And on day one, that was where we were. We did our workshops, we kicked off the hackathon. On stage, there was a little flicker of electricity issues, but it just meant that the projector turned off. We just had to wait and the electricity didn't fully go out.

Yeah, it was a big marble building with a really high ceiling. It was a great space though. It had like two or three floors of space. It seemed to fit the structure of the event very well. There was the judging area and the hacking area and then the talking area.

And the eating area.

Yeah, yeah. You can't ask for more than that.

Yeah. I mean, at first for me, I was a bit like, I had vision for this theater, and it was in the neighborhood that I wanted to do it in, but I think it was actually potentially a better space for the actual hacking because it was very airy, lots of space. People could get to know everybody else. We were able to do it. So yeah, but wild. And we are now just a few days after, and so my team and I were still kind of collecting all the feedback, but I wanted to talk a bit about the judging, because for me, it's interesting when I invite judges to the ZK Hack hackathons, because what ends up happening is a lot of these judges may not be as familiar with all of the ZK tooling. If they come from a ZK team, they probably know their tooling, but they don't know other projects' tooling. And as a judge, you sort of need to dive into it in order to really understand what people did. For this time, though, given we had partners like RISC Zero, Polygon, we had some new partners like NovaNet and Pluto. o1js came back. I'm not listing them all here because I don't have them offhand, but just curious what you made of this state of tooling at this time.

State of tooling. So the tooling has gotten better. It's just so much more easy now to make an application that uses zero knowledge. If you can learn Rust, you can make a zero-knowledge proof using zkVMs. And the performance is pretty good to actually demo these things, and you don't have to learn about constraints, and it just has gotten much more easy to iterate ideas and materialize ideas. So I think the hackathon world has benefited from that breakthrough of just the tooling getting easier. We didn't see that many circuits for this one. I don't remember if we saw any Circom things, maybe like one or two. There was a Noir project, but almost every ZK project we saw was made with Rust and using a zkVM.

Yeah. Or using o1js. It was sort of like using a toolset that had been built.

Right. o1js is also very, very good. And there were several things with that, if I remember correctly.

Yeah. I found it funny to see the judges jumping in on that. And like the judging room is always tricky. I mean, this hackathon was no different. It's funny, every time we do this, we improve our judging process, and yet every time we do this, we still run into the last hour being like -- or not even, half hour. So we're racing against time to pick our top three to rank them. And we have a room of 20 judges who don't fully agree on who the top three are. This time, I remember we had like a short list of six and we kept going over who's in the top three, who can we cut?

It felt like almost everyone in the room had a different top three out of those six.

Totally. Yeah. And actually the audience, the folks out there don't know who those top six were, but they are in the honorable mentions. So if you get a chance, to all the listeners here, have a look at what the projects were at ZK Hack Montreal. And yeah, I think you can star them too. So maybe you can also let us know what your favorite was. I'd be curious to see if the audience thinks of it differently. I'm going to add a link there.

Yeah. And it's always cool to wonder which ones will continue being built, who will continue to work on their project and maybe turn it into a product or something.

Or for the chewing glass ones. So we have this 'Chewing Glass' prize too. Maybe just for context, we have kind of the application track, ZK applications, and then we also have the implementation or Chewing Glass prize. So this is usually like someone's implemented a library that does something really important. Or they've like -- yeah, they've taken a research paper and put it into code for the first time. And we had two Chewing Glass winners this time. And I always wonder, will we see those in some system? Will it continue -- will they continue to develop that?

Yeah, for sure.

Yeah. I think just to wrap up on the ZK Hack Montreal front, that event was wild, but also big thank you to everyone who came through. Thanks for judging and all that. And also just thanks to the sponsors and the hackers for being patient and coming with us on this kind of insane journey. It was a lot of fun.

Great time. Thanks for having me as judge.

Nice. So I want to now turn a little bit to the purpose of this episode, which was to get to know you, Connor. I think I met you really through the Celestia context, but in talking to you on and off over the last year or so, I feel like I know bits of what you've worked on, but not all of it. I feel like you've interfaced with Mina, you've interfaced with Solana, I think you talk about Bitcoin a lot.

People want me to talk about Bitcoin a lot. I'm not a big Bitcoin person.

Oh, really?

They just always ask me what I have to say about it, so.

Oh, that's so -- Yeah. Because actually in doing research for this, I saw on podcasts, you're always talking about Bitcoin. I'm like, oh he's a Bitcoin guy. Okay, you're not a Bitcoin guy.

Well, I was a really long time ago when that was the only thing, but now I am not.

Okay. And you work at Celestia, but you also work on ZK stuff, and that's maybe where we're interfacing the most.

Yeah.

But, yeah, let's talk a little bit about your story. So maybe share with us, what were the topics of interest that led you to Celestia? Like if you've gone through different research directions or just like interest directions.

Same, same.

And then I left and came back. So I --

Where did you go?

My first full time job in crypto was at Livepeer. I was their intern, and I worked on front-end and Golang stuff for them.

Cool. We should say what Livepeer --

Oh. Livepeer is an Ethereum protocol for -- it's an infrastructure marketplace for live video transcoding. And then I left crypto. And while I was gone, I had a very easy job at the IT help desk at the Juilliard School of Performing Arts. And on the side, I was practicing Rust and writing my own mix nets and stuff like that, and really wanted to get a job involving cryptography and distributed systems, but wasn't really trying to get back into cryptocurrency. But then right when I thought I was out, they pulled me back in.

Okay.

Yeah. I don't know. I just --

It was like it was depressing.

It was pretty depressing. Yeah. I couldn't really justify why I was doing stuff related to cryptocurrency at the time and wasn't too passionate about it. Was more just interested in kind of just general privacy stuff, not really blockchain stuff.

So I had this idea for a project which I started to build, and I had to learn what kind of cryptography do I need to make this thing? And there was some cryptographer who I followed on Twitter who said he was doing an AMA, asked him any question, and I said, if I wanted to build this, how would I build it? And he said, you should look into multiparty computation. So I read a bunch of books and started to mess around with MPC frameworks that existed while I was just sitting at this help desk, not doing anything.

Hanging out with actors.

Yeah, there were a bunch of actors and dancers and musicians roaming the halls. And I walked past the dance studio every day on my way to the dimly lit closet that was the IT office.

Oh, damn.

And I was just learning about Shamir's secret sharing and garbled gates and oblivious transfers and all that cool stuff, trying to figure out how I could make an anonymous DoorDash where you have package couriers who move packages around and no one knows who sends and receives mail. And I started coding it, and so I started working on an implementation in Rust of an MPC protocol, which I believe is called Low Gear or High Gear. So I implemented this Beaver triplets generation thing using paillier cipher, and I implemented networking code because there is this library called MP-SPDZ, which is the main hub for all MPC development. It has implementations in C++ of all these different MPC protocols. And it also has a little Pythonic language that you can use to write circuits. So I learned about arithmetic circuits from the MPC world, and that's why my profile picture on Twitter is an arithmetic circuit. I wasn't really in ZK yet, which also is very big on arithmetic circuits.

Yeah, so it was cool. I learned that there's a cost for each gate, so a multiplication gate is like a certain number of communication rounds. These things are very interactive. If you want to compute something with multiparty computation, you have a lot of back and forth messages between all the different parties involved in computing that computation, unlike in SNARKs, which are non-interactive, and the cost of the gates is paid differently. And you don't really have to think about back and forth and using bandwidth and things like that. So this slowness of MPC comes up a lot, or this communication complexity comes up a lot when you think about all the various blockchain projects that tried to have private state using MPC and how they all need to have tiny validator sets, because otherwise they're just blasting encrypted messages to every other validator in the set and then just becomes infeasible very quickly.

So that was your MPC era?

Yeah, yeah.

Okay, so what was the end of that era? Like, you were kind of trying to build this on your own. Did you meet the MPC community while you were doing that? Because there are teams doing that. There's all the wallets, there was like Zengo back then. I think that was really focused on MPC. I know Nigel Smart, they had an agency, like a consulting group that was doing a lot of MPC work with governments and everything. Yeah, I'm just curious if you interface with any of them.

Well, no, I really didn't. I wasn't really in any sort of community doing this. I was kind of just working at Juilliard and --

Learning on your own?

Trying to learn on my own. And then eventually I was like, oh, I don't really want to work at an IT help desk at a college anymore. So I started trying to get jobs, and I was actually trying to work as an embedded security researcher. So I interviewed for various kind of hardware security jobs, like get a job trying to exploit binaries and come up with things like that. And I thought maybe my newfound Rust and cryptography skills that I got from that project would just help me get a cybersecurity job. And while I was job hunting, a Solana startup pulled me in and I got sucked back into blockchain. And I've been back in blockchain for the last three years full-time.

Damn. What year did you get sucked back in?

2021.

2021. Okay, so you weren't there for the DeFi summer?

No, I still followed some crypto people on Twitter, so I sort of saw it happening, but I was not participating at all.

Yeah. When you were coming back, was there sort of a resentfulness of coming back?

Yes.

Why?

There was. It had gotten even stupider since I left.

Yep. I was around a bunch of ETH nerds who were blogging about sharding and blogging about SNARKs and blogging about quadratic funding and stuff. And then all of a sudden, I was around all these pixelated animals who were just talking about pumping price and coins and closed source everything. And I was like, what is happening -- what are we doing? What happened to this space while I was gone?

But what was the Solana project?

So I worked at Switchboard, which was a -- it is a general purpose oracle, where you can just create data feeds to use in smart contracts for any data source that you want. And it's really useful. It had great product market fit back then. It played an essential role in the rise of -- the meteoric rise of the Solana ecosystem, and they're still doing great things now as a TEE company.

Oh, they're doing TEE.

Yeah, it's awesome. Switchboard V3, you can now permissionlessly create these data feeds because now you can trust the TEE to behave correctly.

Huh.

And scrape any data off the web.

Interesting. So you were working at this company, but not that long, I guess.

I worked there for over a year.

Oh, you did work there for a while. Okay.

Yeah, it was a great time.

Tell me about the Solana ecosystem.

Back then, it was pretty cool. I liked it. There were a lot of good builders. We had to really help each other a lot because the tooling was bad, but we were all very motivated to make it work and build stuff. So there were hacker houses --

I remember that.

Like every month, and I pretty much traveled around to most of them.

Oh, wow.

To just follow around all the other builders. And there were some of the pioneers of Solana development who were at everyone who would help you. And also, there was a really good Discord where you could ask a question at any hour of the day, and someone would come back with the perfect answer to help you with your bug. And I miss this now, I haven't seen this as much in the ecosystems I've worked in since then.

Where it's just like so many people excited at the same time with those skills, willing to have -- I mean, you know what it sounds like? It sounds like early Ethereum, just the way you described that. And not that -- I wasn't in early Ethereum, just like the way people describe early Ethereum.

That's what I've heard as well.

Oh, my timelines. I'm mixing up the timelines a little bit. I was definitely still working full time at Switchboard when that happened. I certainly remember us going through that.

Okay.

Switchboard had expanded to multiple chains. Switchboard is on several chains now. One cool thing about working there was we got good at writing smart contracts in weird longtail VMs. We rewrote the protocol for NEAR, and my colleagues rewrote it for Aptos Move and Sui Move. And eventually they also ported it to the EVM. I think we tried Cairo, it might be on Starknet. I'm not entirely sure, but we got to try out all these different languages, which was a good experience.

Yeah. At least comparing them. Did you actually get to write any of this?

The only two that I touched personally were Solana and NEAR.

Okay.

Yeah.

I actually want to ask, like where do you position yourself? Like, are you an engineer? Solidly engineer. Are you doing product architecture? Where are you situated?

That's a good question. I'm not so sure what I would call myself at the moment. I like the title engineer. I think researcher is not really a title that I want anymore. I used to want that title, but I think now it's associated with just a lot of yapping and hot air, which I don't want to be associated with. Product is a good one, maybe. Maybe I'll be a product person eventually, but at the moment, I really just like coding and learning ZK stuff and getting deep in the weeds.

Okay, so you went from -- so you knew Solana VM is the language just called Solana.

It's Rust.

It's Rust.

But it'll take even someone who's good at Rust a while to learn how to use that VM because it's pretty weird.

Okay.

Not in a bad way. I actually quite like it now. I think it's, at this point, my favorite VM to build contracts in.

Wow. Still?

Yeah. If I was going to make a DeFi app, I would want to use that tooling.

What about NEAR? What was -- isn't it also Rust?

NEAR is Rust with Wasm. It's not CosmWasm, but it's similar. It's kind of like if the EVM was Rust.

Oh, okay.

You have to reason about a state tree, and it has like mappings, is the way that you do everything. And it's metered, it has gas. One thing that was weird about NEAR is that it has async await programming because NEAR is sharded. And so if you call another contract, that contract might be running on another shard, and so the way that they expose that to the programmer is with the async await paradigm, which is pretty nice and clean, which I liked.

Cool. What happened at Switchboard during the FTX crash? Like, I'm kind of curious, what happened in Solana during the FTX crash? Were people freaking out?

Switchboard's great. It was not negatively affected, and it's thriving now.

Being in the ecosystem.

Well, so a lot of Solana protocols were starting to go multi-chain and try out Aptos and Sui and things like that, which isn't bad. It's okay to expand to other chains. I wouldn't say that people trying out other chains was like a death blow to Solana or anything. And there was also, of course, I'm sure you've heard the story, there was a bunch of true believers who stayed Solana Maxis throughout that whole cycle, and those teams sort of became the champions of Solana now. You have Ellipsis and Jito and Drift, who just they stayed focusing on the one chain they were best at, which was a great decision for them, and came out well.

Okay. So I guess what you're saying, though, is there was teams that sort of fled, that went -- I mean, or they'd maybe been thinking about going multi-chain, and then this was the time they did go multi-chain because they were getting cold feet or something, but some of them stuck through, entirely focused on Solana.

Yeah. I mean, true. Yeah. And I don't think that's really a bad thing at all. I think Solana survived all that bad news, and that speaks well for them.

Okay, what did you do after that?

Well, while I was in the Solana ecosystem, I was really interested in the debates going on between Solana and you could say Ethereum, the rollup scaling versus --

Monolithic.

Monolithic scaling. That whole discussion interested me a lot, because I kind of sympathized with both sides, and I wanted to get to the root of what the disagreement was because I was friends with all the people on the rollup side and also friends with everyone on the Solana side. So I thought, what's the real difference here? What's the real fundamental disagreement, if there is one? And I went really far down the rollup rabbit hole, and I learned everything I could about rollups. I learned about -- went back to all the cryptography stuff and got really back into the ZK stuff. I also just wanted to learn ZK in case it would turn out to be useful for the company I worked at. So we even did some -- we did some research into ZK TLS while I was working there, and if there was any way that using that tech could help us somehow.

The end conclusion that I came to was that scaling blockchains while preserving the ability to cheaply verify them is the holy grail. So the thing that is really cool and interesting is to get the TPS as high as possible in a way that they're still easy to verify. So I got really into that problem. The problem of succinctly proving execution of a very high throughput blockchain, and the idea of ZK proving a whole chain and verifying it with one proof, the Mina thing. So I got excited about that. And while I was researching all this stuff, I found out about data availability sampling, because that was written about alongside all of the rollup -- foundational rollup stuff.

It's funny how that actually happened because there was Fuel, right? And that was John Adler, who also was LazyLedger at the time. He was on the show for those two things. I think of them as quite different, actually. But now that you see sort of the Celestia vision with rollups coming off it, it makes more sense that it was almost two sides, right? One was the rollup, and one was what could host a rollup, what could be the base of a rollup.

Yeah. And Fuel is cool. I was very excited about that at the time. I read all about it, and I like parallel things, and I like fraud proof things, and the Fuel UTXO way of doing fraud proofs is way more intuitive than the really complicated way that the EVM optimistic rollups work. Yeah, fraud proofs are pretty interesting. I'm more of a ZK person, but fraud proofs are certainly very cool. And I actually worked on them a little bit when I first started at Celestia. When I was on the Rollkit team, Celestia was betting on fraud proofs very much for a while.

Okay, now, going back to where we were in the story. So you were getting excited about kind of ZK and you did some work with Mina. I thought you worked at Mina.

No, I didn't work there. I was in the fellowship, and I didn't really finish my project for the fellowship.

I see. I feel like I heard that people still recognized you from that. Like it was like something -- Mina people are like, oh, yeah, we knew him. He was good.

I don't know. I was excited about it, and I went to some of their events and I talked about it publicly.

Yeah.

And I still think Mina's awesome. And I'm also actually doing a project with them now at Celestia.

Oh, cool.

Which is something we can talk about, for sure.

Yeah, that's what we want to do. Okay. You only did sort of the fellowship at Mina, but did you work at any other company before Celestia? Like between them?

No. So I was -- I really wanted to do something with ZK, so I applied and interviewed at a lot of different ZK related jobs, and the only non-ZK company I was going to go to is Celestia. And that's the one that I ended up going to.

Interesting.

But I considered working at a variety of the --

ZK.

ZK ecosystem companies.

Yeah, but you ended up at Celestia. So I've known about Celestia since it was LazyLedger, and then I had a lot of friends who started working there, like on the engineering front. I got to know a lot of the founders over the years too. I think for me to understand what DA was took longer than I'm proud of.

No, it's one of the --

I still don't know if I fully -- but I think I have a much better sense for what is happening now. But, yeah, it's always been sort of a tricky one. It's been fun to see the project actually come to fruition, though, because then once it's live, you're like, oh, okay, this is what it's going to look like. This is sort of the place it's going to hold in the space. And that, for me at least, made a lot more sense. But Celestia, or LazyLedger, they're not a ZK project. As you said, there was no ZK in it originally. But since you joining or since really them launching or even before that, I think there's been more work towards incorporating ZK. So maybe we can talk a bit about that.

Yeah, it's not a ZK project. There has never really been a ZK person working there, but it exists for serving rollups and rollups like ZK. So it's pretty important that it be aware -- that the project be aware of ZK and be involved with ZK. And now, yeah, there's like three or four different ZK related initiatives going on that we're trying to build. But it started out as very much like fraud proofs in the L1, fraud proofs in the L2, kind of just an optimistic thing. But now ZK has just gotten really good. ZK has just gotten way better in the last few years, and now all our wildest dreams are within reach.

You were saying you started at Rollkit. Let's just define Rollkit. As I understand, it's like it's the framework to be able to easily build rollups, right? Is it Celestia-driven or funded?

The Rollkit core team are all working at Celestia Labs. So yeah, it's a project at Celestia Labs, but it's very generic over different DA layers. It has a generic DA layer interface for which there is a Celestia implementation, and there's also a Bitcoin implementation and maybe even Avail. I think there on the GitHub, you might see code for that. It's to create a sovereign rollup using Cosmos tooling, basically. It uses the ABCI interface, which is how Tendermint talks to the Cosmos SDK, and it replaces Tendermint. So you take CometBFT -- you take out CometBFT, and you put in Rollkit, and then it goes from being a chain to being a rollup.

Hmm. Is this also a way that existing Cosmos chains could just become rollups if they wanted to?

Yep, very much so. And that is pretty much the point of it -- or part of the point of it.

Huh. So you're working at Rollkit and it's not ZK, but I'm actually kind of curious, how much have you brought ZK into the discussion? Because if you were really interested in it and yet you're working in a space where it's more fraud proof based, yeah, at what point did ZK start to factor in?

Well, I have been going to ZK events this whole time. Like even before I joined Celestia, I would go to the Zcash conferences and stuff like that and go to all the ZK related side events at every conference I went to, just because I like cryptography. I want to learn more. Seems like the most interesting stuff. I don't know that me being a nerd about ZK got Celestia to change its roadmap, but, yeah, I've been trying to get us deeper into that, and it's kind of just, I would say, really, it's just breakthroughs in the tech that has made it a more attractive option for our roadmap.

Yeah, there's the ZK working group. The Celestia ZK working group. We've talked about it at least once on the show before, but, I mean, ZKV, ZK validator, this is another project of mine. We validate on Celestia, we're in that group. I mean, this is kind of part of what ZKV is meant to do as well. Like bring ZK tech into new networks, even if there is none there. So, yeah, that group sort of formed pretty organically. I think there's a weekly meeting or a bi-weekly, bi-monthly meeting. Every two weeks or something.

Yeah, it was every two weeks. I think it still is.

Yeah. And that's where at least I started to see a lot of action into like -- first of all, that entire community learning how ZK works at all. Like how could you put it in the kind of base chain but then I think -- would you say that those initiatives you're talking about kind of spawned out of there?

I would actually say no. The ZK and the Baselayer working group so far has only talked about SNARK Accounts, which is one initiative that the community wants to add to Celestia.

Okay.

But there's other places where ZK could fit into the Baselayer, and then there's not the Baselayer applications of ZK as well.

Okay, let's start covering them. So, you sort of mentioned the ZK Accounts coming out of this Baselayer working group. Let's start there. So what are ZK Accounts?

ZK Accounts will be a way for Celestia to do more than just be a pet rock. So, right now, Celestia only has transferring tokens and posting blobs. It has no virtual machine for smart contracts, but there is an interest in adding more functionality in a way that won't give us the state bloat that would come with having an EVM or something. So the thought is, what if Celestia had a way for developers to add a custom circuit that TIA can be moved based on the results of, or some computation that could move around TIA without us needing a VM? So the --

How would that work? Can you walk me through what this looks like?

Yeah. So you could make an app as a circuit, and you could then --

Where does it live?

The circuit would live in the Celestia state. So kind of like deploying a smart contract, you would deploy a circuit and funds could move in and out of it based on proofs.

Hmm.

SNARKs are Turing complete, so you can do anything with that. The use case that we tend to think of is settling rollups. So kind of the way that Ethereum has bridges to its L2s, we could have bridges to rollups using these SNARK Accounts where tokens can move in and out and be locked in there and state transition according to cryptography, et cetera.

Could they move from one to another, or would it always be like one rollup, one ZK Account, and you're only interfacing with your own ZK Account as a rollup?

I think anything's possible. I think you could have verifying other of these rollups be part of the rollup state transition. And why not? Like a rollup can read the state of the L1, so it can read -- trustlessly read the state route of other rollups. So I think it's possible for generally and with SNARK Accounts for L2s to be able to bridge to each other without going through the base layer. That seems possible.

Yeah. So I think the first time that I spoke to Mustafa, I think the first time I had him on the show, we talked about sovereign rollups. I think we talked about the settlement layer and how there was no settlement layer in Celestia, whereas in Ethereum, as a base chain to rollups, it also functions as a settlement layer. Here, it's almost like a very unique -- it's like a stripped down version of a settlement layer. I guess you don't have to do the whole writing of the state machine. You're not like updating state on the base chain and then moving it to a new smart contract and then putting it -- you know what I mean? Like moving rollup to rollup, if you can actually do it.

Yeah. So on a regular VM chain like ETH, you have a giant state database and a VM, and it's updating key value pairs in the Merkle tree, and it can grow that state, and contracts can have state and users can have balance, and that's all key value pairs in the tree, which just bloats the state. We're talking about just proofs and blobs. The proof is validated like a transaction, and then the blob is posted in Celestia's blobspace and there's no state tree. The burden of proving or storing the state is punted up to the rollups nodes.

Are there anything more than just settlements that ZK Accounts could be used for?

Yeah, I think you could build any -- just an app. I think you could maybe just build a DeFi protocol that way as well.

Interesting. Could you create a swap in that?

I think so, but the only token that Celestia has is TIA.

Yeah, there is no other base token.

Yeah, it's an IBC-enabled chain, but you can't bridge OSMO or ATOM into Celestia --

Or USDC or anything. Okay.

No, it's only -- only TIA can go in and out through IBC, and the working group has actually talked about changing that. Because if it does have an ecosystem of rollups, then maybe it would want other IBC tokens to go in and out.

Yeah. Do each of the rollups on Celestia actually also have IBC themselves? Like, does it always have to go through the Celestia base in order to hit the IBC network? Or can it just go directly from one of the rollups?

It's a good question. So the IBC is just a spec and there are two or maybe three client implementations. There's the Tendermint client and the Solo Machine client, and I guess the WASM client is the third. And you could just create a new client that these rollups could fit into, and then that client could take the Celestia header and validate rollups based on some rules that involve checking proofs against the Celestia header. So, yeah, I mean, I think the -- for the rollup, for any of these rollups to have finality, they have to proof and blob to Celestia. So there isn't really a way that those things could do IBC without it going to Celestia, because Celestia is the finality for those rollups. You could do something less secure. You could have the rollup maybe has its own validator set where you trust them until it gets to Celestia. For Rollkit, we've done some things like this. So we've done -- at Rollkit, we had really fast block times with the centralized sequencer, faster block times than Celestia, then IBC working that just trust the sequencer. We got that to work and showed TIA moving up and down to the rollups with a lot of trust. And the whole rollup playbook is to ship the thing with trust and then buy yourself time to make it secure.

That's interesting. Yeah, it's funny, I didn't actually know that. I didn't realize that IBC wasn't easy to implement into a rollup on Celestia without somehow going through it. So like right now, the rollups, they also can't interact with other tokens unless they're native, I guess, on those rollups.

Well, anything's possible. So you can write an IBC client that's totally insecure, right? You could write an implementation of IBC between Bitcoin and Osmosis, where the consensus rule is, does it just trust Connor's signature? And then you could bridge Bitcoin to and from Osmosis, just trusting me as the source of truth. And that would be a valid implementation of the IBC spec. We just need Osmosis to accept it, and then there you go. So anything's possible, but doing it in actually fully trustless ways, then you have to think about these things.

What other ZK initiatives are there? I mean, actually one of them I already know about, because you gave a talk at the modular summit about this, which was like ZK light node -- using ZK, I guess on the compression front, a bit like what Plumo used to do. Let's talk a bit about that.

Yeah, that's a side project.

Is that your project?

Yeah. That's just kind of one thing I did in my downtime a few months ago, but I really want to do it because it's a really cool thing. The idea there is kind of just the Celestia vision is having trust minimized light clients that are super embeddable and anyone can run. And I've been really excited about the idea of this happening effortlessly because I'm a big light client Maxi, and I want to see light clients run everywhere, and I want every user of blockchains to get the full trustlessness properties that blockchains provide. And if they take time to sync, no one's going to do it. No one's going to run these things unless it's spoon fed to them. So I became really interested in the way that Plumo and Mina do the succinct proofs where they don't even need to sync. You just get a proof and then you know you have the head of the chain.

Wow.

And it just became practical to not change Tendermint and just have it work. So step one was to do that. And --

You just mentioned SP1. You mean like SP1, Succinct SP1?

Yeah.

How are you using that with this? Like, what do you mean?

Well, there's a little -- so actually, the first time Tendermint was snarked was just with Plonky2.

Okay.

Succinct built BlobstreamX.

Oh, yes, this is -- okay, this is that work.

Yeah. So the first iteration of BlobstreamX that shipped was using Plonky2. And that team made a Plonky2 circuit to prove Tendermint headers. Just one, though?

Is this almost just like you take Tendermint, you just kind of put a SNARK around it.

Yeah.

Instead of trying to work within Tendermint and ZK, you're just like, well, we're just gonna make it ZK friendly by just snarking it. And then whatever comes out is ZK friendly.

Yeah. You just make a circuit that verifies the headers according to the consensus rules. And the proof time was impressive. It was good enough to be practical and ship, which before was pretty unthinkable. Before it was just so unfriendly. And the innovation that there is really just STARKs and small fields and Plonky2 and good hardware.

What are they doing then? Are they taking a STARK and then SNARK? Is there two steps with that?

With the first iteration of BlobstreamX, it's Plonky2 which is --

Which does that anyways, right?

Yeah, it's a STARK with a permutation argument.

Yeah.

You've had the Plonky2 team come on to talk about Plonky2. It's kind of just Plonk with FRI.

Yeah.

Plonky3 doesn't have the permutation argument. Plonky3 is just straight up STARKs.

Okay.

And that's what SP1 is. And by the way, I don't want to snub RISC Zero. I also wrote all the same code with RISC Zero.

Okay, you did.

For the recursive light client stuff or. Yeah, I've tried it out. I mean, it's very easy to go between them. All you have to do is change the env STD, read/write stuff. And they have different precompiles, they have different accelerators. Like SP1 has a system call that lets you do SHA-256 on an optimized circuit outside the RISC-V VM. And that's the other thing is what makes this so feasible is because most of the proving workload is the unfriendly things like SHA-256. So if the VM has an optimized thing that does that, then the rest of the code is nothing. The rest of the code is just a few if statements and a few checks and very easy basic things.

I want to go back to what you were saying, though, about what you were actually doing to create this light client, because you're using a RISC Zero or an SP1, like a zkVM to do something, but you're actually talking about Celestia. But they're not on Celestia. They're not connected to Celestia necessarily. So how are you -- I guess they're just creating proofs because you can't verify that on Celestia.

Oh, well, this is making proofs about Celestia so that someone can verify Celestia.

Outside of Celestia.

Yeah.

So maybe just to go back, the goal here is to create a light client of Celestia living somewhere else. It's not to allow for small ZK light clients on Celestia.

No. Yeah, that's the SNARK Account work. Is that -- and then now I'm talking about a different, totally different project, which is --

Got it. Yeah, yeah, no, I understand. I just to clarify it, though, so this is like, if you wanted to verify -- if you wanted to check Celestia, the entire state or whatever, like somewhere else on Ethereum or something like that, you could use potentially this.

Oh, well, yeah, I'm not the person who… ZK approved Tendermint. That was Succinct. Succinct Labs.

That's what they did.

Yeah. First they did it with Plonky2, and then they rewrote it with SP1, which is actually just taking Rust and just running it. But I think they optimized it as well. They did some optimization work to get it faster. And what I did was I made it recursive.

Okay.

Using just all very easily -- this took me like a week. It was just writing some very easy Rust after they made the tools for me to do it.

All right. All right.

I just made Rust --

Like a hackathon project.

Yeah.

Okay.

And what it is is it's just the Tendermint SP1 code and then verifying a proof of itself. And if you can do that, then you prove one header, and you include the proof of the previous header, and then you have one proof for the whole chain.

And then it will always be the same size.

Yep.

And it will be very small.

Yep.

And how do you actually -- this is always my question when it comes to light clients, how do you look inside that? You'd still need access to the full node somewhere, right?

Oh, yeah.

So how -- like what does it actually give you to have this little light client on that side?

So, I mean, the way that most people use blockchains right now is they just trust a full node, and the full node just tells them their balance and the state of the apps they use and everything. And you still need that. This light client stuff does not eliminate your need to get the state from somewhere, but it does make it untrusted. So it makes it so you don't have to trust whoever you get that data from.

Because you can check it or it's like somehow checking that the node data you're getting is correct.

Yeah. With Merkle proof.

Okay.

Yeah. So you say, like, oh, what's the interest rate on my Aave position? Or what is my balance? You get a Merkle proof along with the result of that, and then you check that with the light client. And if the light client is trust minimized, which the one we have isn't yet, because it doesn't verify the state transition, but it does check consensus.

Okay.

Then you know that the RPC is at least not -- whatever the RPC is telling you is correct according to the consensus rules, ideally the consensus and execution rules.

So this is your week-long project?

Yep. It took about a week.

And what do you want to do with it? Like, do you want people to start using it or building on it? And it sounds like there's that part that's missing still, so I guess someone has to build that part.

Yeah. There's a few things that need to get done. I'll tell you the end result. The utopia of the light client utopia that I hope this will lead us to is just every single wallet and app have the same exact UX as now. UX is still really good. UX is the same as when we just trust RPCs, but you have a little padlock or a check mark next to everything that tells you that the RPC is not lying to you and cannot lie to you. So just as fast and cheap as the scalable blockchains and rollups we know and love today, with the security as if you were running your own node, but for the people who don't know how to run nodes or don't want to bother doing that.

Do you feel like there should be something like this for all of the different kinds of nodes? I mean, you did yours in the context of Celestia, but going back to Solana, I don't know if that already exists, where you'd have a tiny light node where it's recursed. I know there are light nodes, but I don't know if they're created that way.

Oh, yeah. There's not really anything that fundamentally stops any blockchain from doing this. And this was like a pivotal moment for me when I used to be in a lot of Twitter arguments with Solana people about -- and Ethereum people just trying to get to the bottom of the disagreement. And Vitalik writes this in the famous Endgame blog post, where he says, ‘a big monolithic chain that adds SNARKs, fraud proofs, and data availability sampling is good.’ That gets you to the same end result, which is very scalable and very cheaply verifiable. The Ethereum rollup-centric roadmap is just an indirect way of getting to that same outcome where you have really big beefy block producers and very light cheap verifiers.

And there was a team in the Solana ecosystem called Tinydancer who started out by participating in these Twitter discussions, and they created this project to make a Solana light client. And now they work with Sovereign Labs and they built a DA sampling implementation for Solana and kind of a light client, and Solana is kind of friendly to fraud proofs, weirdly. Like it was not designed to be fraud provable, but the way they achieve parallelism is sort of isomorphic to the way that Fuel does parallelism. And so you can kind of do a Fuel-style fraud proof using the SVM. And I think Sovereign Labs did figure out a way to actually do this without even changing Solana. Yeah, any chain can have a trust-minimized light client.

Are they usually using fraud proofs?

Solana doesn't have anything like that. It's just full nodes only.

Okay, but if you were to create a light client like what you just described, where they were using fraud proofs.

Yeah, it's possible. Yeah, it's possible to make a fraud proof light client for Solana. And maybe you don't believe in the everyone who runs light node is kind of idealistic utopia that I just mentioned, but it has a practical -- there's a practical reason to do this as well, which is maybe you want bridging, maybe you want very decentralized and secure bridging. So a lot of the same research gets done for that goal rather than just me wanting everyone to have more security and realize the blockchain trustless vision.

I kind of want to ask about wallets and light nodes, or light clients. So in the past, wallets actually had nodes and actually some wallets, like Zcash wallets, you have to run the whole thing. But, and this is kind of going back also to MPC stuff because I know there's a lot of wallets that are also using MPC, but are wallets supposed to have light nodes? Would you say that's the ideal thing, that they would actually be running a light client?

I think yes.

Are there some that do that?

Yeah.

And will ZK make it better?

Wow.

It's also way easier to verify consensus on proof-of-work. That's not a reason not to do proof-of-stake, but it's just so easy when all you have to do is follow a chain of hashes and then accept the one that has the highest work on it versus with proof-of-stake, when you have 66 kilobytes of signature data on every header, it's just way heavier and harder on these devices. And ZK fixes that. So not only can you use ZK to aggregate those signatures, you can also use BLS, but if it wasn't designed with BLS, you can SNARK it and do the same end result. Not only can you do that, but you can also squash an infinitely long chain of headers into one. So ZK is definitely gonna mix this way more within reach.

Interesting. Did you ever use Zcash wallets? Have you used them?

Oh, yeah. I've been a big Zcash guy for the longest time. I have multiple Zcash wallets on my phone right now.

For the mobile wallets, what is happening there? Are those -- they're not light clients, are they?

No, they are.

They are light clients. They are just heavy light clients. They're just slow light clients.

Yeah. On a shielded blockchain, if you go with that architecture, you need to scrape all of the encrypted notes out of every block and then do a trial decryption on every one until you find the ones that are meant for you.

Okay.

You don't really have to do that. You could also propagate the notes off-chain. This is how the Payy payments app works. That app doesn't sync blocks, it just sends the notes to whoever you're paying. But Zcash and Penumbra, they both scrape notes out of the blocks and do trial decryption.

Wow.

I think this Zcash wallet also verifies consensus, because why wouldn't it? It's just so easy to just check proof-of-work. You could -- I think Penumbra doesn't. I think Penumbra is, it just trusts the RPC to give you all the nodes, which is fine. That is within the threat model that most crypto users are okay with.

Yeah, yeah, that's cool. You just explained how Payy works, though. I didn't realize that. Let's continue with Celestia and ZK. So what other things -- you sort of mentioned there's some other initiatives. I don't think I know about this. So, yeah, what else is going on?

So this is not really an initiative that Celestia Labs is doing, but it's something that we need. It's kind of on the wishlist is snarking the state machine.

Where would you do this?

It would be --

In consensus. Is this in the chain itself?

If it's easy enough, it would just be something the proposer could do.

Okay.

If it's like a light enough, fast enough, cheap enough proof, the proposer could just do it.

Is this just to keep the validators bloat low?

No, it's kind of just because our light node right now --

Oh, this is still on light nodes side. Okay.

This is still on light nodes. So our light node is supposed to be trust minimized, and it has DA sampling, which is a big part of being trust minimized. But there's an attack that validators could do against light nodes, which is finalize a block with an invalid state transition. But data is available and the light nodes would be fooled, and we kind of need to do consensus execution and DA if we actually want a trust minimized light client. This could also be done with fraud proofs, but it just seems like ZK is kind of close enough. And also part of the reason we don't have a VM is because the state transition being minimal makes it more provable for fraud proofs or validity proofs. So it's a wish list. It's an important wish list thing, and if it's cheap enough, if maybe like STARKs and modern proof systems can do this in under one of our block times, which is currently 12 seconds, then it might be easy enough to just have the proposer do it. If it is too expensive, then we got to mess around with marketplaces and do something like a Snarketplace or something like that. But hopefully we could avoid that complexity.

Or do you think you could use another marketplace that already exists?

It's possible.

Because there's a lot of those. I don't know if you know about the prover marketplaces on the rise.

I know a little bit about them.

Yeah, part of the ZK supply chain. Anything else? You sort of said there was also some things that aren't actually Celestia specific. It's sort of like, could be on the rollups or --

Yeah, I mean, we just always want ZK rollups to use Celestia DA. So there's sovereign SDK, the sovereign ZK-rollup framework, and then there's all the ZK L2s. My main job is actually integrations with ZK L2s. So what I've been grinding on mostly for the last few weeks is an integration with ZK Stack, which is Matter Labs's rollup framework based on zkSync. And so I learned a little bit about how zkSync works and how it does data availability, but this is pretty much just a software engineering plumbing project more than anything else.

Is zkSync already using Celestia for the DA at all?

No.

Because you're talking about ZK Stacks, which is like another level of zkSync.

Yeah, I think these ETH L2s are going to use Ethereum DA for their main net, because they are ETH scaling projects.

Yeah.

But for the ones that have their own stack products, OP Stack is the most famous one.

They all have stacks, though, right? There's -- there's Arbitrum has Orbit.

Orbit, yeah.

And Polygon --

CDK.

CDK.

Yeah.

Have you followed the AggLayer stuff?

I don't know what is going on with that. It looks cool. Using ZK to fix to interop, that sounds good. I don't know anything else about it, though.

Okay. Okay.

Is it cool?

I think it's cool. I mean, I haven't done an episode on it, but I've heard about it a little bit.

Oh, nice.

Yeah. I mix this up, though. I mix up a bit, like -- and maybe rightfully or wrongfully, but ZK Stacks with AggLayer. But I guess I don't think it's equivalent. Right? I think ZK Stack is more, like you just said, like it's OP Stack. It's the Orbit. It's these like how to build new versions of these rollups. Right? It's like it's their SDKs. It's their Rollkit.

Yep.

Yeah.

Yep. And OP Stack is like the first rollup stack that Celestia had working in production ready. So most of the Celestia block space, until very recently with the Eclipse thing, was filled by OP Stack rollups.

Okay, neat. Anything else on the ZK front.

I could talk about like, this was my Athens talk, was trying to make one circuit to reuse for all these integrations.

Sure.

Being a solutions engineer is a fun job because you have to kind of anticipate partnerships that might happen before we actually get confirmed to be working together. So I had this downtime, and I thought, oh, I might be assigned to work on CDK or ZK Stack or maybe even Scroll or Aztec or something. And so what can I do to get ready for when I may have to start doing this? So I just started thinking about, at a high level, these things have some blob, and they need to put it on Celestia, and they need to prove that it got on Celestia somehow. And they have proof systems that might commit to the blobs using different schemes based on what field element they use or what proof system they use. And so like Scroll could commit to their blob using a BN254 Poseidon hash.

So you need to be able to deal with that somehow.

Yeah, but Celestia is a SHA-256 Merkle tree, so.

Okay. Yeah, yeah.

First, I was tasked with make an equivalent data tree to the SHA-256 tree that uses a ZK friendly hash so that these rollups can prove inclusion using a friendlier thing for their proof system. And I was assigned build an equivalent tree using Poseidon hash and then prove that that tree equals the SHA-256 tree. That's a horrible idea, because then you're snarking not just the hashes relevant to the blob, but the whole tree. And the overhead of one SHA hash is so high. So we quickly pivoted into just prove that the specific blob you want is on Celestia and then prove its equivalent to a commitment that the rollup can give you. So, and they all use different stuff. So one of them is BN254. Some of them are BLS-377. Some of them are STARKs with Goldilocks or something. And so I just took SP1 and RISC Zero. This is the thing that I built with both.

Okay.

And also, I'm probably going to have to do it -- I'm going to have to probably try to do it with Jolt now as well. But it's not that hard.

And there's others, too. There's others coming.

Oh, great. Wonderful.

Nova --

4844.

Yeah. Proto-danksharding.

Okay. Yeah. Yeah.

Okay.

Which is kind of funny, because the zkEVM is a general purpose VM just for a weird clunky language.

Okay. So you had to rewrite this. So you would have preferred to have just created a proof that they verified, but you're instead, you're writing the Solidity.

Yeah, I've been working on this -- yeah, I've been on a three-week long Solidity project right now, and it's actually weirdly fun.

Why? You like Solidity?

No, it's terrible.

But, oh, no, it's not fun. You were being sarcastic.

Well, no, no. I mean, like, Solidity is a bad language, but it's the fun of implementing all this weird low-level encoding stuff in a low-level language in a constrained environment. I don't know, it's just kind of -- so I'm taking --

Challenging.

Bites to shares. Celestia has the notion of shares. A blob is encoded in this way. And I took that for granted because in Rust, you just call a function that does it, and it was just so easy to just run that in RISC Zero and SP1. But Solidity, it was like, oh, we don't have any implementation for this. So I got into the weeds and I had to follow the spec. And so it was kind of the first time in my career I ever had to write code based on a spec, and the spec was well written.

Oh, good.

And so that was kind of fun. That took me a week, and then I came up with all these test vectors to try to break it and find places where it diverges from the reference implementation. And this just feels like the kind of thing that cryptographers do. So that's why it was fun.

What could you use to do that? Like are there any languages that are already built to be used in this context? Like can you use Circom?

For this Solidity thing?

Yeah.

No.

Not at all. Is there anything that already exists? Could you use existing libraries for anything?

Well, so, like I made a circuit which we could just verify alongside the ZK Stack proof, but the thing is, the code is just really, really complicated, and to surgically insert another proof into that would have been more work than the three or four weeks it's going to take me to do this.

Okay, wild. But you are now getting – so you're an applied cryptographer, almost.

Yeah. I mean, I feel like now I'm ready to go and implement Binius in Solidity or something.

Whoa. More than a hackathon project.

Yeah.

All right, well, Connor, thanks for coming on the show. This has been fun to explore a little bit of the topics that have gotten you excited over the years, but led you to work on Celestia, and now what Celestia is actually doing in the ZK context. This is cool.

Yeah. Thanks for having me on. I'm glad we could talk about how to interact and transact on the decentralized web.

That's what we talk about here. Nice. All right, I want to say thank you to the podcast team, Henrik, Rachel, Tanya, and Jonas. And to our listeners, thanks for listening.