00:05: Anna Rose:

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 Tracy, co-founder of Pluto, a company that is building dev tools that add verifiable data from web data to on-chain applications using ZK. We discuss his move from being an engineer at some well-known Web2 companies, what prompted his move into the decentralized web, and how he eventually found his way into the ZK space. He shares the concept of web proofs and how Pluto can use and extend some of the TLSNotary stack to bring private web data into on-chain applications, as well as the future tool set that Pluto is aiming to develop.

Now, a quick note before we kick off. I don't know if I've mentioned this on the show before, but I wanted to highlight zkMesh, a monthly newsletter that is produced by ZK Hack, another project that I'm involved in. zkMesh comes out at the end of every month and in it we compile the latest research, articles, videos, project announcements, events, and much more from in and around the ZK space. It's a substack newsletter, it's free, and it's a really good way to keep up to date on all things ZK. I've added the link in the show notes. Be sure to subscribe to get this in your inbox every month. Now, Tanya will share a little bit about this week's sponsor.

01:35: Tanya:

Gevulot is the first decentralized proving layer. With Gevulot , users can generate and verify proofs using any proof system for any use case. you can use one of the default provers from projects like Aztec, Starknet, and Polygon, or you can deploy your own. Gevulot is on a mission to dramatically decrease the cost of proving by aggregating proving workloads from across the industry to better utilize underlying hardware, while not compromising on performance. Gevulot is offering priority access to ZK podcast listeners. So if you would like to start using high performance proving infrastructure for free, go register on gevulot.com and write ZK podcast in the note field of the registration form. So thanks again, Gevulot. And now here's our episode.

02:25: Anna Rose:

Today I'm here with Tracy, the co-founder of Pluto. Welcome to the show, Tracy.

02:29: Tracy Livengood:

Hey, Anna. It's great to be here. Thanks for having me. I'm excited to chat.

02:33: Anna Rose:

Yeah, and this has been a long time coming. I'm very excited to do this episode. We're going to be talking about Pluto, we are going to be talking a little bit about your journey to start working on this project. Quick disclosure, I am an investor in the project both personally and through ZKV in this case. And I'm kind of especially excited to do this interview because Pluto has gone through a few iterations. I'm getting a chance to also check in at where it's at today. It's definitely in a space that I feel like myself and maybe members of the audience have been looking more and more towards. Kind of connected to, but not exactly the ZK Email, the TLSNotary world. So I'm looking forward to jumping in. Given that this is a new project, it might make sense for us to first just introduce what is Pluto, and then I'm going to want to find out a little bit more about you. But let's start there. What's Pluto?

03:23: Tracy Livengood:

Yeah, sure. So I think our broad definition of what Pluto is, is we want to use applied cryptography to give powerful new tools to application developers. So we kind of found while we were learning about the space that you could do so many cool new things if you just had these easy tools to use as an application developer, and it was just very hard to onboard ourselves and teach ourselves all these things. And so we want to make that easy for everybody. And the specific thing we're doing, we'll talk about a little bit later on, but we are building a technology which we call a web proof, which is a proof of internet data. So we let you add verifiable data from the internet to your application.

04:02: Anna Rose:

Nice. All right, let's do a step back and learn a little bit about your background. What were you doing before working in this space? And maybe you can share what pilled you, what got you into it?

04:14: Tracy Livengood:

05:30: Anna Rose:

But you didn't dabble. You didn't do it.

05:32: Tracy Livengood:

And the Cloudflare founder and others have all tried to claim that they are neutral infrastructure, but they've struggled because ultimately they have a kill switch and they have the option to do these things. And so external forces can put pressure on them to kind of change their policies and plans. And yeah, in this case, they banned him. It stood out to me, just the power of these platforms and the lack of ability to have neutrality. And I think that got me thinking about crypto more seriously.

08:06: Anna Rose:

Cool. So when you first jumped in, what did you... What were you involved in and who are you working with?

08:12: Tracy Livengood:

09:26: Anna Rose:

Later, they did something like zkDAO, but I'm guessing this is not the same thing. You didn't do the zkDAO stuff.

09:33: Tracy Livengood:

Yeah. So we were in Nouns kind of very early when they were just getting started, and we did a proposal with them for three or four months. It took a little bit of time, but then we kind of debated, should we do more here or not? And we felt like we were kind of at our end of our arc there and we wanted to go a little bit broader and think about different problems. So by the time that zkDAO stuff had come around, we were still paying attention. We saw it, we thought maybe we should submit a proposal, but we'd already been through that and we decided against it. We were kind of moving forward.

10:04 :Anna Rose:

What got you into ZK? At what point did you switch over there?

10:08: Tracy Livengood:

11:31: Anna Rose:

Okay, so this was what got you initially into ZK. I want to say that when I met you, so this is a year ago now, you shared with me some of your Notion notes. And your Notion notes to me are legendary, Tracy. You were the person who actually explained coprocessors to me for the first time in a way that I understood them, even though I had actually heard that description and had met with those teams before. I may have even had them on the show before, but it was... I remember it was talking to you where you mapped it out, and I was like, I get it. I see it. I know what is happening. And from that point on, any coprocessor or coprocessor-like project that has come my way, I had a much better understanding for it. I mean, I've seen a little bit of some of that mapping and the way that you put those things down on paper and the way you're thinking about them, like where does Pluto start in this story? At what point do you start to sort of... I don't know, almost circle the wagon on an idea that you wanted to commit to?

12:34: Tracy Livengood:

13:44: Anna Rose:

13:56: Tracy Livengood:

Yeah, I think it's changed... Both our point of view has changed a lot over the last year, and then I think the ecosystems changed a lot in the last year, too. When we started focusing on this, it was like, all right, let's make something that every app dev in the space can use. So there's a bunch of app developers, none of them are using ZK right now. It's mostly being used by rollups and some... In a settlement capacity. Can we give this tool to an application developer? And what's the benefit of that? Is there benefits to that? And we pretty quickly realized, yes, we could build a tool that did that for an app dev. And so that started to look like this concept that others have called the coprocessor, but the space now knows is a coprocessor, which is sort of off-chain computation. And we started to build a service for off-chain computation, actually using Solidity. And that was kind of where we first started getting serious about, like, I think there's something here. And really, the idea is a simple interface for programming a SNARK for long-running computation, and we think like access to things that aren't currently possible in a Solidity programming environment.

15:59: Anna Rose:

Oh, that's interesting to think of that. Yeah, I feel like I'm only seeing the top-down most of the time, because I'm not an engineer, but that's really cool that you get to also see it from the other side. I think I'm just like, I often have to ask people what's happening under the hood to get a better sense for it. You get to look at it.

16:17: Tracy Livengood:

Yeah, I think a lot of great engineers I know actually don't do the top-down. They only do the bottoms-up. So they just are in the code, and they're like, they work bottoms-up to try and understand what a tool is capable of, and they try to experiment bottoms-up. That actually leads to a lot of really great discoveries. Because you're instead in your more creative mode, and you're sort of exploring for yourself what can be done. Top-down is also useful, because I think it is good to have some perspective on how others are looking at these things, but it can be limiting if you only look that way, because you might just try to fit yourself into a box that already exists.

16:58: Anna Rose:

There was a point where we checked in and you had sort of described Pluto as a little bit of a Solidity extension. I want to understand if the project today still has that aspect. And maybe you can share a little bit about what you meant by that, being a Solidity extension back then.

17:16: Tracy Livengood:

Yeah, so what I meant by that is if you think about Solidity today, it's a multi-entry point program. So you can call a program and start from many points, and each sort of entry point in that program has a certain capacity of logic you can run, like 250 to 500k gas, something like this. There's like a fixed amount of compute you can do. And it's a really bounded box, and we experienced this when we were trying to make dApps. It's like, oh, there's a very limited amount of things that we can do inside of this box. And I think that's a barrier that anybody who tries to build an application runs into pretty quickly. It's like, okay, this is what I can do, this is what I cannot do. And we started to view cryptography and also ZK as tools that can grow this box. And the first idea we really had, because I think we had some background applications, was like, what if I could just run 10 million gas or 50 million gas? Would that be a useful addition to the toolbox here? And I think we got kind of inspired like, oh, that would be cool. That'd be really powerful.

And we thought about some infrastructure use cases, like, oh, if I can do 50 million gas, and it just is programmable like Solidity, I could verify hundreds of signatures, and then make a succinct commitment to hundreds of correct signatures. And that would probably be useful for a validator set, checking if the validator set is correct. But there's also non-infrastructure things like, maybe I just want to compute a Merkle root to generate a snapshot, like who owns this token? And I want to add them all to a Merkle tree, and then get the Merkle root at the end. And we're like, that could be cool too, because then you could snapshot something trustlessly. And a lot of other things started to feel interesting there. We also thought down the privacy rabbit hole a little bit like, oh, you could add privacy and a UTXO tree with notes into Solidity. And if you add like, unbounded gas, you could encode this note tree, and access it and nullify it while saving gas costs. Yeah, and each of these just started to look like tools that I would want if I were building an application, and so our head was like, if I'm building an application, these tools can exist, like, why don't I have these tools available to me right now? And I think that that was what got us excited. It's like, let's bundle this up in a way that everybody in the space has these tools readily available.

19:45: Anna Rose:

Would you say that's still what Pluto is today? Or has it changed from that? Because, yeah, I feel like at least the focus from speaking to you more recently seems to have narrowed at least, because what originally was with this Solidity extension, the way I understood it was almost like, in a coprocessor-like environment, you had these extra things you could do in Solidity, it would kind of go off-chain, something would happen, it would come back on-chain, but it would extend it somehow, but that it was quite general purpose. What happens after that?

20:16: Tracy Livengood:

Yeah, we went down that path a good amount, and I think we still have a lot of interesting ideas to eventually bring to bear. But we started feeling kind of like we didn't want to go in a hole and just try and invent a vision for a better future, and then come out two years with here's the new execution environment for crypto, you know? We wanted to kind of inch our way into it a little bit more. Partly, I think it's just about how we learned to build products. It's like, if you're not shipping product at a rapid clip, you're not learning, and you're probably detached from what people actually want. So, we kind of used that initial North Star to help us learn about cryptography. And so, we grabbed this zkEVM off the shelf that PSE had built, and we grabbed this SNARK compressor that Axiom had built, we kind of started tinkering with these things and seeing how they fit together. And we did build a system that roughly does what we described, not with the best performance, and we were running into some performance issues. And then we started building a better version with Plonky2, which is the Polygon stack, which is much more performant than Halo2 for these things. And we were seeing good performance, and we were like, I think we could ship this. But it was just such a grand vision, and so many big ideas baked into that. I think we started to think like... I had a few conversations with people about this sort of grand idea, and we were like, it's too general, it's too grand, what is a very specific thing that people, instead of having to learn our new way of thinking, can benefit from this one specific technology and maybe get the most interesting bit of what we're trying to add, and then we can maybe work our way into the grander view over time.

22:14: Anna Rose:

So now sounds like a really good time to talk about that specific case. And I guess this will also share with our audience kind of what Pluto is today. What are you focused on? What is Pluto?

22:26: Tracy Livengood:

Yeah, so we are about to launch what is called a web proof. And this is a term that we kind of invented, but we think it captures the idea, which is a proof of arbitrary internet data. So we kind of started focusing our thinking toward areas that were under-explored but powerful. And that included bringing data from elsewhere on the internet into blockchains. And we do this already today with Oracles, but they're in a pretty fixed and static structure. They're not very programmable and they're not very flexible. They also can't collect personal data. We can dive into some of the limitations of them, but we kind of started getting excited about.. A bit of a smooth brain kind of idea that you get when you first come into crypto as a developer. You're like, I'm building an application. Okay, I want to get the weather in my Solidity contract. How do I curl the weather API? And it doesn't make sense. And you're like, why can't I get the weather in a blockchain? Like that doesn't make sense.

Obviously, it's a bit of a smooth brain way of thinking because, okay, you start thinking about blockchains. And then eventually like for us, after we had learned all about this, we kind of went back to that, like, why can't I get the weather? And yeah, I think that we were like, well, maybe that is interesting. Maybe that actually opens up some cool things that aren't possible. And I think we took some inspiration from a few teams who were starting to think in this way. We saw ZKP2P, for example, and they had built this really cool application that lets you use your email to verify a Venmo transaction. And it was kind of starting to merge these two worlds of blockchains as they exist today and the internet and its usefulness as well.

24:20: Anna Rose:

For sure.

24:20: Tracy Livengood:

And that really, I think, scratched our itch, especially given our background.

24:24: Anna Rose:

Yeah. Here, we'll put this in the show notes, we actually did an episode with ZKP2P. But also, ZKP2P is built on ZK Email, and that's also coming out of PSE. But what you're describing also sounds a little bit like the TLSNotary project. But I actually have never dug that deep into that, so I might not be fully following that. Can you tell me if there... If it is... First, what is TLSNotary? And then if it is similar, or if you're extending it? Or yeah, if there's some connection there?

24:56: Tracy Livengood:

Yeah. So TLSNotary, I believe it's got a long, long history. I think it's like a 10 year old project or something. I haven't fully dived into the history, but I think this started back in the Bitcoin era. In the last few years, PSE has rebuilt TLSNotary in Rust with more modern cryptography techniques, and really what it is, it's in the name, it's a TLS. And so what TLS is, is secure communication channel between computers over the network. So I connect to...

25:29: Anna Rose:

Which exists already on the internet. Yeah.

25:32: Tracy Livengood:

Yeah, we use it all day, every day, right? You see the little green lock, like you're using TLS or SSL. You're essentially initiating a connection with the server and that traffic is encrypted. So when you send your credit card or your password, nobody else on the internet can see it, you're just in an encrypted relationship with the server. So that's TLS. And then the second part of the name is Notary. And a notary is somebody that sort of authorizes a document, right? And in this case, this software is acting as an authorizer of that connection. So it's sitting external to it and it's sort of putting its stamp of approval on it that like, oh, this connection between these two parties, the server and my laptop, did play out and it actually transmitted this data over the connection. And what that does is it lets you verify the actual contents of that connection.

26:26: Anna Rose:

So then is Pluto also playing in that world? Because you mentioned web proof and this sounds similar to what at least TLSNotary might be used for.

26:37: Tracy Livengood:

Yeah, definitely. I think we are trying to generalize the inference. We're actually actively using TLSNotary and making some modifications to it. And I think we're trying to generalize it and make it easier to use inside of an application that might actually live on mainnet. The current code base isn't audited, there's performance issues in the current structure. So I think the team building it is actively working on that, but we're also starting to think about how we like to contribute publicly and help level up that infrastructure. But it also comes with challenges productionizing it in many ways. So one way is just to audit and security, but another way is you're actually communicating with this notary in real time while you're connected to like, say, Amazon server, which I was using as an example, and so latency becomes an issue. Like how far are you from the notary? And you actually want to have a notary hosted close to where you're connected to Amazon so that you can minimize the latency for it to sign these transactions. There's a bunch of little details about how that works that make it difficult to use in an application today. And we're trying to sort of fix those issues and make that easier for application developers.

27:56: Anna Rose:

So to understand this, I think we should kind of try to imagine from an end user's perspective, and I realize that you're building tools that maybe a developer would use, but I still want to understand like how someone could use something like Pluto or something like what you're building to actually create these web proofs and what those web proofs would even enable.

28:18: Tracy Livengood:

Yeah. So there's a couple different ways that this can be used. So I think the easiest way to think about it is just similar to an oracle today. So let's imagine I want to just get a price from CoinGecko. Like what is the price of Ethereum today? Now an oracle network does this by having a collection of parties all go get the price at the same time, and they compare, they make sure they agree, and then they spit out with some variance, this is the price of ETH from CoinGecko. How you could do this in a web proof or with TLSNotary, you can actually have just one party retrieve the information and then use a process that verifies that that one party got it correctly from CoinGecko's server. And in doing this it becomes essentially a more powerful oracle that doesn't require multiple parties to retrieve the data. You can just retrieve the data yourself. And that's sort of the standard public oracle data example. But this actually because you are the only party having to retrieve the data it can actually go a bit further than that.

So it can also be used for retrieving personal or private information. So instead of an oracle network which can only get public data this could retrieve things about yourself. So it could retrieve your bank balance or your place of employment, or maybe the fact that you own a Taylor Swift ticket on Ticketmaster. Facts that you would have to share your API keys or your password with the Oracle network in order for them to get. And so this becomes pretty powerful for a wider range of internet data than what Oracle's can do today.

29:54: Anna Rose:

What is this? Is this the TLSNotary, or is this Pluto?

29:57: Tracy Livengood:

This is enabled by TLSNotary, and we depend on TLSNotary. And what TLSNotary does is it lets you verifiably retrieve internet data. So it takes standard internet data, I'm going to get data from CoinGecko, and it makes it signed internet data. So I'm going to get data from CoinGecko, which has a signature on it that says this data is correct. This actually does not use ZKPs. It's just transforming the internet into something that emits signed data instead of unsigned data.

30:30: Anna Rose:

Got it. Okay, and then what Pluto is doing, let's go from there. So it changes it because it allows you to go into private or owned, like things that are not public data.

30:40: Tracy Livengood:

Yes. The things that we add on top of this are we make it easier to use in an application so that it's deployed in a bunch of different places, it has lower latency, it scales a bit better, but we also add a ZKP on top of this. So in the notary example, it's just emitting signed data. So it has the back and forth between the server and the client, so hey, chase.com, give me my bank balance. Yes, here's your bank balance, it's $10,000. Okay, thank you. And it's got this transcript that has been signed by the TLSNotary process. But this is just signed data. You have the plain data, and you have a signature over it. Now there's a little bit of details I'm not going to get into about how TLSNotary conceals some of the facts in there. So it actually has what's called selective disclosure. So you can selectively disclose some of the data. But all of that is non-ZK. It's using a technique called garbled circuits and key sharding in order to do this.

And where we come in is we actually encapsulate that proof into ZK to make a ZK proof, which makes it more succinct, but we are also adding some capabilities on top, like the ability to do some computation. And we also make an SDK that lets you collect user data as well. So if I need to collect my personal data, say my bank balance, in order to do that, I have to be logged into my bank. I can't just say, Pluto, collect my bank balance, because Pluto doesn't have access to your bank balance. So there's actually a user experience here of like, I log into my bank so that I can retrieve that bank balance in a verifiable way.

32:22: Anna Rose:

And when you say log in, you're just like... You're talking about logging in on the web in a portal. Like you have to be on the page.

32:29: Tracy Livengood:

Yeah.

32:30: Anna Rose:

And then on the page, you can create this proof and then privacy of the underlying proof, in a way, or what the proof is proving.

32:39: Tracy Livengood:

Yeah, that's exactly it.

32:40: Anna Rose:

Okay.

32:41: Tracy Livengood:

Yeah. So you actually have to pop up a panel that you input your data into, and it all lives on the device. It never goes to our server.

32:51: Anna Rose:

Interesting.

32:52: Tracy Livengood:

And we collect that data and then ultimately get a proof, and then we build a ZK proof over that. Now, day one, we're actually building the ZK proof on our server, but we actually think we'll start... By the time we get to mainnet, we think we'll be doing it on the device itself.

33:08: Anna Rose:

I want to kind of bring this back, though, to the Solidity extensions, because it feels very far away from that now. And I also don't even know where there's a blockchain in here. This seems more like a web technique with a ZKP. But you sort of said that the Solidity extension idea and those tools, like you had narrowed it. So what are the tools even look like? How are they working?

33:31: Tracy Livengood:

Yeah. So right now, this is just an SDK for adding internet data to a blockchain application. It's a very specific thing for just adding internet data that you maybe otherwise couldn't add to your application, to your application in a few lines of code. And to us, this is narrower, because I think when we were thinking about this Solidity coprocessor, we had started to think of it in a very expansive way, as a new developer experience for crypto. It's like.. And if you start from first principles, and you try to imagine what is a better DevEx for crypto, given we have cryptography and a bunch of tools available to us, what is that DevEx? And where our heads were at is, well, it has long-running computation, meaning I can write a script that runs for a very long time and still get a succinct commitment to it. It has potentially privacy preservation, so maybe I can store state in a privacy-preserving way. It has state proofs, probably, so I can access historic state. And it also probably has what we're calling web proofs, which is access to internet data or sources of data that I normally can't retrieve in a blockchain. And so, in our broadest vision of what that Solidity thing was, it included all these different tools for being a superpower blockchain developer. Like, no longer was I just writing 200 to 500k gas of Solidity code, now I had all these tools at my disposal and I could write these really rich programs that composed across all these tools. That maybe is part of our grander vision for how the DevEx of crypto becomes this more evolved thing. But the narrow point of it is, well, what about just Oracle data for the internet?

35:25: Anna Rose:

And just the web proof side of things so that... Okay, so you're not doing computation on these in this current state. You just focused on the bringing of these personal information from a web browser directly to an application running on a blockchain.

35:43 :Tracy Livengood:

Yep, exactly.

35:44: Anna Rose:

Okay. And this is all on Ethereum, I guess. So it's still... Is it still Solidity? Like you're still formatting it to be used in Solidity?

35:53: Tracy Livengood:

Yeah, you would still verify the web proof in Solidity and you would use it in a dApp that is written in Solidity, and you would verify it on ETH or on an L2, any of the traditional places. But right now it's sort of just an attestation. It's just like a fact, one piece of information. And you can contextualize that on-chain. But right now there's no way to contextualize it in a coprocessor or to do like I'm going to get my bank balance from Chase and I'm going to get my bank balance from... Or my 401k balance from Fidelity and my brokerage account and add them. You can't do that right now.

36:32: Anna Rose:

You can't do that.

36:34: Tracy Livengood:

And so that's where we're starting.

36:37: Anna Rose:

Okay. But that's where you'd like to go, I guess, is that you could add them.

36:41: Tracy Livengood:

I think it's technically possible to do that, and I think we are starting to figure out if that's where we want to go.

36:49: Anna Rose:

Got it. Would you say that just doing this web proof, though, would you still kind of put yourselves in the category of a coprocessor, but just a very narrowly focused one? Or do you think it's something else now?

37:01: Tracy Livengood:

Yeah, I don't know... I haven't actually used the coprocessor term a lot to describe us because I found it confused people a lot when I would use it. So I don't know if people know what a coprocessor is. I don't know if there's an agreed upon definition of a coprocessor. I think one way you could think of it is something that does computation prior to the transaction being settled on-chain. And so, and it does it in a ZKP probably, right? And because it's a ZKP, you can maybe do this on demand, sort of while the application is needing its data, it can compute coprocessor proof as well. But I think the ecosystem is still trying to digest what that means. And there's some thought pieces on, like, well, a coprocessor can only do synchronous data and they can't be ordered, and there's a bunch of brain damage around how to do this and what this means. And I think I don't really want to try and categorize us into this. It's like, we just make these proofs. We make these proofs of internet data, you can use them in your application. That's what we do. And I think we will probably think more generally about that over time. And how does making these proofs of internet data become a more general system for programming and blockchains? We are thinking down that path, but I don't know that we're going to try and categorize it as a coprocessor or any of these things. We're still trying to figure out how we categorize that, how we communicate that, because I think developers will need to understand this thing very clearly and what benefits it gives them. So we want to try and do a good job of describing that when it comes time.

38:50: Anna Rose:

It sounds a little bit like the proposal that Mina or the o1Labs folks make, which is around this zkApp. And I remember them using language... They didn't say web proof, but they would have said something like...

39:04: Tracy Livengood:

Maybe they said zkOracles or something.

39:06: Anna Rose:

Yeah, it definitely had sort of that connotation of taking web information and using ZK. So I just wondered if you'd looked at that or if you're familiar with it, if it is similar or if it's actually something else.

39:20: Tracy Livengood:

Yeah, I actually... I think this idea has been around for a while. I'm not sure exactly who invented it, but like I was saying, I think TLSNotary has been around for years. And Mina, I think, has talked about zkOracles, I think what they've called them, for a long time. I'm not super in-depth on Mina's approach, but I believe they are also considering a notary approach. So this would notarize the connection in the same way that TLSNotary does. I don't think that they have a custom implementation of this. So maybe they do, and I'm just not familiar with it. But yeah, I think for the Mina ecosystem, they also believe that access to arbitrary Web2 information is useful for their applications. And so I think they are either working on building or want someone to build this zkOracle, which would let you retrieve things like your bank balance and use it in application.

I mean, we are focused on Ethereum first and foremost, and we're kind of a general purpose tool for developers kind of decoupled from any specific programming language or any specific blockchain. I think we also add the user experience side of this as well. So there's... Well, we had a couple of things on top. We had the user experience side of actually being able to collect this information, and we had the developer experience side of actually being able to link it into a smart contract application. And we add proofs on top of it to verify and retain the privacy of this whole process. So we kind of bring it from an idea in concept that people understand to like, you're going to actually be able to use it in a smart contract application on mainnet.

40:59: Anna Rose:

Do you think the proofs that are being generated, are they going to require some sort of prover marketplace? This is a term that's obviously been floated around a lot, but who are generating these proofs? Do you imagine you guys doing it for now, or would this be something decentralized? Like, are you going to work with one of the existing prover networks or proposed prover networks? I don't know, actually, if there's any like really live ones yet.

41:22: Tracy Livengood:

43:07: Anna Rose:

So you sort of mentioned a little bit of the ZKP stuff, and it's Plonky2. Is there anything else under the hood that might be interesting to our listeners in how you... In like kind of the systems that you used or how you built it?

43:19: Tracy Livengood:

Yeah, so we didn't want to reinvent the wheel. So when we first started working on this, we worked in Halo2. Well, I guess one thing I'll add is all these systems aren't audited necessarily, right? So there's a lot of frontier things being built, like you've probably heard of Jolt and Plonky3, right? And there's even like Lurk, which people I think underestimate. I think Lurk is really cool. But a lot of these systems are still in active development. They're not ready to go to mainnet, right? And really, the few systems that we have that are really ready for mainnet are like Halo2, maybe Plonky2, maybe gnark and Circom. And those are the set of tools that you can use and have some confidence in that they've been audited. And then I guess more generally, how we've kind of worked on ZKPs up to this point is grabbing other people's tools off the shelf and trying to leverage Halo2, Plonky2 and benefit from some of the existing technology there. But I think as we start to pursue more performance for these client-side proofs, we might find ourselves doing some sort of custom app-specific SNARKs in order to get us the most performance.

44:28: Anna Rose:

I also wonder if you're doing it client-side, like does the proving system sort of, I guess you need performant in a certain way, but maybe all of the things you listed, I think are pretty like SNARK-y and not STARK-y. Like, would you ever go more on the STARK-y side? Actually, well, are they? Maybe these are mixed, like Plonky2 might be a bit of a weird mix one, eh?

44:51: Tracy Livengood:

Nowadays, it's a bit complicated. We used to have maybe a clear line between the two, but Plonky2, Plonky3, these use STARKs for part of their proof and they use SNARKs for other part of the proof and these things are getting mixed and matched a little bit more. Yeah, in terms of pure STARKs, STARKs, like maybe Cairo, we've dabbled with it, but we haven't been serious about using that. Things are evolving really rapidly. I would say like one dictum, like one way you could make this decision in the past was about performance and proof size and privacy, like these are the sort of the criteria you could try to make a decision. And so if you plot these things on a performance scale, some create... Like a performance by size scale, some are very fast, but create very large proofs. And that's typically like STARKs, but that's also say Jolt and Plonky3. They're like large proofs that are made very efficiently. And other tools like Circom and Halo2 can create very small proofs, like Groth16 or single column or a few column Plonk proofs that are very compact. They can be four kilobytes or down to 200 bytes in the absolute most extreme case. And there's a trade-off in terms of performance and the size that you get out of these things. So it ends up being a pretty complicated trade-off space to try and choose the right tool for the job. And then if you add a third axis, which is privacy, some of these tools are privacy preserving. Some of them are not privacy preserving. So you kind of end up with somewhat complicated trade-off space. In addition to that, the trade-off space is changing. So in the past, it maybe made sense to only verify a proof that cost up to 500k gas. But now we're starting to see a world where maybe large proof verification without compression is doable. And we might have contracts that can verify millions of gas of these larger proofs. And so that trade-off point is also moving as well.

46:58: Anna Rose:

Why is that? Is that the hardware is the answer?

47:01: Tracy Livengood:

It's not necessarily hardware. It's more about gas costs in L2s and with blobs coming online, gas costs are going down in L2s.

47:12: Anna Rose:

Just like there's no... It's not a limitation, yeah.

47:14: Tracy Livengood:

There's still some limits, but the ceiling is lifting a little bit. And so we could end up in a world where it's not so crazy to verify a proof that costs 4 million gas to verify. And in that world, you may make a different architectural decision about which types of proofs you use because that cost has gone down.

47:35: Anna Rose:

I see. I see.

47:36: Tracy Livengood:

Yeah. And on that performance axis, there's both compute time, but there's also memory budget. So if I'm on a server which has a ton of memory, running Plonky3 proof that uses a lot of memory is totally acceptable. But if I'm on a mobile device, then I have a memory ceiling. And so I think a lot of the space is sort of navigating this sort of three-dimensional trade-off space and trying to figure out what is the exact tool for the exact problem that is optimal and gets me all the things I need, right?

48:08: Anna Rose:

For sure. And it's like which environment is it working in? Is there going to be a hardware element or is it going to be on one of these L2s? Yeah, how fast? How expensive? That's interesting.

48:20: Tracy Livengood:

We've kind of gone down the rabbit hole on all these things as well. And I think we're keeping up to date and we're trying to kind of navigate it correctly and make the right decisions along the way.

48:30: Anna Rose:

How hard is it for, in your system, to switch these things out? I know that right now it's still kind of being built, so you have flexibility. But yeah, is there a moment where it freezes or can you create something where you can switch these things out later?

48:45: Tracy Livengood:

Yeah, I think if preserving optionality is super important, you could technically architect a system where like, you know, you can generate proofs in many different ways and have a verifier that's... You have different verifiers that are sort of flexible over the proof system. Like these things are technically possible, but it's not obvious to me that you're going to want that system in production. I think probably what happens is you get to a good enough proving system to solve the needs of your stack, and then you kind of commit. And it becomes your proving system for a year or two in production. And only after the space is dramatically changed, the unit economics of proof generation, would you build a new version and iterate forward to it? And I think this is what we've seen rollups do as well, right? Rollups start one proof system, and now if you look at most of the zk-rollup guys, they're like in the process of working on their v2 or their v3, which has a newer, more performant and less expensive proof system.

49:48: Anna Rose:

Yeah. What stage are you at? That's kind of like now I'm kind of curious, like how far are you from potentially choosing one of these things? Or are you on testnet? Are you... Like what can people already play with?

50:02: Tracy Livengood:

Yeah, we aren't public yet, but I would say we internally have a testnet. We're going to launch that over the next few weeks here. So I think we'll have a demo in public before the end of this month, people will be able to go play with it, and shortly thereafter, we'll have a testnet that people can actually start building into their applications. We have a lot more to come after that. This will be our first launch, and we're sort of building a bunch of really cool things that can come after that.

50:30: Anna Rose:

Very nice. So it sounds like this is... I'm just going back to your background and those first forays into the space and finding the tools kind of lacking and you've stayed sort of on that tooling front. It sounds like this is kind of one narrow, but potentially powerful tool or tool set that you've developed. There are also other teams building tools. I'm sort of curious, like kind of just, yeah, throwing back to that larger, like what's out there, how possible is it that we get closer to that actual decentralized transfer thing? I'm assuming there's other tool builders as well. How far along do you think we are? How long do we have to go? Like, do you now see momentum? Do you think that we are getting closer to that future that you sort of envisioned? Or do you think we're still very much at the beginning? And I guess the question actually goes to both general blockchain applications, but also maybe separately, we should look at like ZK. But let's start with the blockchain application side of things.

51:36: Tracy Livengood:

Yeah. To be honest, I think we're a little bit stuck in a rut, like with the current set of capabilities. If I look at when I did this survey of the ecosystem and I tried to think about what comes next, a lot of what people were thinking about was how do we take the 250k gas Uniswap swap and make it lower cost, cheaper, put it in more places, higher throughput. That was all about taking what, like one great application that we all were excited about, right? And just making it cheap...

52:13: Anna Rose:

Making that better.

52:14: Tracy Livengood:

And global and universal, right? Yeah. And now it's like, all right, so we've got all these rollups and all these approaches to decentralizing them, and we are going to get like one cent Uniswap swaps, right? And I think that's cool, and I think it's important, but for me, when I think about what excites me, it's not lowering the costs. If we just lower the costs, that's not innovation. Lowering the costs it's about unit economics, right? And it doesn't bring novel, creative experimentation and new applications into the space. And so I think when I look at a lot of what's happening in blockchain infrastructure, it's really great work on lowering the costs of Uniswap swaps.

52:56: Anna Rose:

Wow.

52:56: Tracy Livengood:

But what is the thing that expands that design space, right?

52:59: Anna Rose:

What else is possible? Yeah. Wow.

53:03: Tracy Livengood:

And I think that that's kind of where I've tried to orient my mind is like, okay, everyone else is going to lower these costs. These costs are going to come down over the next few years. I can bet on that. And then like, what does it look like to expand that design space beyond Uniswap swaps, right? What does it look like to add web data, add historic state, add long running computation, add privacy? And what does it look like to build a developer experience that has all those things baked in? So you have a much richer design space for building these applications. And so, yeah, I've tried to keep us focused on open the design space versus lower the costs.

53:43: Anna Rose:

Yeah. I mean, I think what you're saying makes a lot of sense here. And I sort of appreciate you sharing this perspective, because I think... I also would like to see us just really expanding our thinking and how far we can go with what we're doing. I think the way you just put it, the one use case, and then just optimizing for that thing is really well said. I hope we can do better and bigger and more. Yeah.

54:07: Tracy Livengood:

And I don't want to criticize, I'm not trying to criticize. I think people are doing great work, but yeah, like 80% or something of the investment dollars in infrastructure are going into lowering Uniswap swap costs almost. And that is a useful thing, but just cheaper transactions I don't think are going to 100x the space. I think you need to solve Sybil resistance, right? Like anti-Sybil techniques, and you need to solve identity and you need to solve privacy and you need to solve access to Web2 data, right? Like all of those open up the design space, and...

54:44: Anna Rose:

I can tell you've been hanging out with DC Builder because you just mentioned Sybil resistance.

54:49: Tracy Livengood:

I mentioned identity. But I actually, I think it's one of the most important threads, actually. I kind of... I gave a talk at ETHDenver about this topic, which was like how LLMs and sort of AI in general, generative AI, changes the internet and the implications for the internet. And I have become pretty convinced that like KYC mechanisms and CAPTCHA mechanisms, like they're going to struggle, and we're going to end up with a Twitter feed that is full of generated content, and is that what people want? Like, how much will you value a stamp that says this is human when like the whole feed is generated? I think it's going to be very important to you as a user of the internet, because there's something about just knowing it's not just generated text. I mean, maybe we end up in a world where we all have just purely generated feeds and we're just okay with it. But yeah, so I think that digital identity string is really interesting. But I also think merging Web2 data into blockchains is also like... One analogy I use is like, if you look at blockchains as a percent of valuable state on the internet, how much of our valuable state lives in blockchains today? And it's just a drop in the bucket, right?

56:03: Anna Rose:

Not much.

56:05: Tracy Livengood:

And if you look at how much valuable state lives in other databases owned by Google or your bank, right? Almost all of it, we have this tremendous wealth of information. And if we can bridge these two worlds together, I think you get a more creative set of applications.

56:20: Anna Rose:

That's cool.

56:20: Tracy Livengood:

Yeah, maybe I'll add one last thing, which is, we've kind of been thinking about this idea, which is what we call gray markets. And a gray market to us is it's not a black market, it's not a white market, it's in between, right? And if you can kind of bridge these two worlds of data, you can start to make these marketplaces on top of the existing infrastructure. And so I think ZKP2P kind of did this with Venmo. They made this peer-to-peer on-ramp on Venmo's transaction capability. But you could also do that, say, with Ticketmaster, where you use Ticketmaster's API to create a marketplace for ticket repurchasing. But you can do it on video game assets too. So I could have Counter-Strike skins and maybe trade them for World of Warcraft gold and build a marketplace around that. There's a bunch of like these marketplaces you can make for digital assets that aren't blockchain native digital assets. And we think that like starts to get really exciting.

57:21: Anna Rose:

And it crosses these like databases, it crosses companies, and whereas I think a third-party company would have a really hard time doing that, primarily because you'd need to get licensing and agreements and all of this stuff, because this is so internet native, it's dependent on... It just like existing in your browser. You start to be able to do more stuff. I hope they don't try to block everybody. That's the only thing as I say this, I'm like, or those companies will still try to lock this stuff down, but yeah.

57:53: Tracy Livengood:

Yeah. Maybe it creates the conduit toward a new kind of protocol for that type of marketplace. It helps kind of bridge the gap in the short term, and then the long term, it grows a new network that can flourish on its own.

58:07: Anna Rose:

Wow. That's really cool. Nice, Tracy. Thanks so much for coming on the show, sharing with us a little bit about your journey from being a Web2 engineer to the Web3 world to like getting into ZK to exploring... Well, teaching me coprocessors, developing Pluto first with this like Solidity extension or kind of like a generalized tool set, narrowing it down to this web proof story. And yeah, thanks for sharing what that could then enable. It's very exciting.

58:39: Tracy Livengood:

Yeah. Thank you. It's been a journey, I'm excited to continue.

58:43: Anna Rose:

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