Testing, am I here? Awesome. I'll give everyone another 15 seconds or so to get situated. And as folks are getting situated, I guess I'll just first say, you know, welcome everybody to what I hope will be one of the many highlights of your Devcon experience. My name is Albert and I'm delighted to be the host, moderator, and perhaps even provocateur of this panel. Joining me, as has been said, is the one and only Gubsheep, Barry, Whitehat, and Vitalik. Three very low-information names, taking this zero-knowledge thing a bit too seriously if you ask me. Though I guess Whitehat is a positive piece of information. Like, you know how people in the West, they have these family names like Taylor or Carpenter or Smith or Shepherd. You know, maybe one day in the digital realm it'll be full of Whitehats. But I digress. Today we're going to discuss programmable cryptography and Ethereum. This is exciting for a bunch of reasons. One that stands out is that the four of us convened at the last Devcon in Bogota for a panel that we titled 'What to Know About Zero Knowledge.' Now I know most audience members didn't see that, simply because there's so many more people at this Devcon than even the huge number that was at Devcon LATAM. But as those who did see that panel may recall, I started that panel by apologizing. Why? Because zero knowledge is not just a misnomer, it's usually an objectively incorrect way to be thinking about what is going on with modern applied cryptography. And most of the time when people do quote-unquote ZK, no part of what they're doing is actually in zero knowledge, which we discussed at length last time. That's why it's cool to see how the terminology has evolved in just the last two few years. We used to call it ZK because we didn't know what else to call it. Now we call it programmable cryptography, or PC, perhaps because we don't know what else to call it. Now, call me old-fashioned, but when I see PC, I still think personal computer. So I always do a double take when I read a note by Gubsheep or Barry that says something something PC. But you know what? Hijacking words such as crypto and zero knowledge to mean things that they didn't mean before, it's basically a tradition at this point. So more power to you if PC actually starts to mean programmable cryptography. That might be your most impressive feat yet. So without further ado, I really have to start here: what are we going to be calling this stuff in two years, in 2026 or 2027? And I don't mean like literally try to predict the exact words, because if you knew, then we would already be calling things that. But as Gubsheep alluded to in his talk, and some of you already saw, the term programmable cryptography actually predates even the last Devcon. In fact, Gubsheep, Barry, and I discussed programmable cryptography at Edcon a couple of months before the last Devcon, but we didn't discuss it in the way that we are talking about it now. It was more vibes and intuition than realization and understanding. So really, for any of you, what jumps to mind for what might be the vibes and intuition of how we are going to be talking about and thinking about this in a couple of years? Anyone?
I think we're going to slowly stop talking about zero-knowledge proofs and SNARKs and STARKs, and we'll just start using the word 'proof.' And like, lots of mathematicians are going to get upset, but like, that's fine, right? Because we made the economists upset by just abusing the hell out of the word 'inflation.' So let's just do it to mathematicians too. Yay, we'll prove Ethereum blocks.
I think that the advent of things like FHE and IO is going to mean that the way that people think about programmable cryptography will be based upon those technologies more than zero-knowledge proofs. So I think that we will have things like FHE and IO become the kind of primary vibes that people interface with.
I think I remember in one of our last conversations that was particularly centered around zero knowledge, we discussed how the idea of what people were calling ZK apps at the time might not be a complete outlook actually on what is possible with this technology. You know, the point of these applications was not the fact that they used zero knowledge, but it was the fact that they actually did something. They brought some new kind of capability that wasn't possible before, whether that's a privacy capability or a verifiability capability or something like that. And I think that, you know, to use a historical example, this is sort of like when we talked about websites as .coms, right? There was some point in time where we talked about the idea of like, oh, this is a .com company, and well, look how that turned out. Eventually we started moving to things like, oh, here's a browser-based game or here's like an e-commerce storefront or something like that. And you know, we similarly, we don't call things HTML apps or HTTP apps. We've started to move away from that. In the ZK world, I hear ZK apps less and less these days. But I think we're going to also face the same kind of problem with programmable cryptography and cryptography apps. There's not really applications of programmable cryptography, it's about what you do with them. So I don't know if it's going to be something about like the nature of programs that are collectively run by multiple people or a capability or a thing that happens as a result, but that's where I would think.
Well, hopefully we'll have more chances to chat about this in a couple of years and beyond, and it'll be really interesting to revisit it because I think one thing we know for sure is that we won't be talking about these things the same way we are now. So, programmable cryptography and Ethereum, or maybe PC and ETH. I know not everyone here saw the talk that Gubsheep just gave, but real quick, in that talk, Gubsheep did a great job teasing the first topic that I really want to dig in with each of you here on today, which is quite simply: how do we think about PC and ETH together? How do we think about programmable cryptography and Ethereum? And I'll start with an even more direct prompt: is Ethereum a form of programmable cryptography? And conversely, or maybe complementarily, is programmable cryptography an extension, or is it like a spiritual descendant even of Ethereum? Where does your mind jump to? Vitalik, I'll start with you.
Yeah, I mean, I think it's like a similar type of thing but different. It's like kind of like how I think about Justin Drake's one-shot signatures, which are this primitive that Justin Drake loves talking about, but they depend on everyone already having quantum computers. But the reason why that analogy comes to mind is basically because I think blockchains are not cryptographic algorithms in the way that we think of cryptographic algorithms, but they achieve objectives that are similar to cryptographic objectives, right? Like they give you guarantees that some data has been published at some point in time. They can create systems that can have a guarantee that someone who wants to participate can participate, which is a really important property of voting systems, but really potentially everything. They give guarantees of verifiability of the execution process. Some cryptography paper buzzword that blockchains basically do is what they call a bulletin board. So blockchains are, I would call them cryptography-adjacent, because they do similar kinds of things and in some ways they feel like and work like a cryptography primitive, but they also have enough differences from things like SNARKs and FHE proofs and FHE and obfuscation that they're worth thinking about as being their own thing.
One thing I also wonder about is, is there some root node perhaps that both programmable cryptography and Ethereum are specific facets of? Is there maybe some more general way to describe systems or the sorts of programs that we might want to run, where you might say, okay, so this property, as an implementation detail, something like Ethereum or a programmable blockchain can provide those guarantees, and this other property, as an implementation detail, you can use something like a ZK-SNARK or some form of program obfuscation to achieve that.
And I think my answer for that is simulated trusted third parties. So this is the idea that you can take a protocol and you first imagine your protocol as running through a trusted third party. So everyone sends everything to Zuck, and everyone trusts Zuck, and Zuck gives everyone the answers. And then you figure out how to replace Zuck with some kind of construction that has much stronger trust properties, meaning much less or no need to trust any specific actor. And often parts of Zuck can be replaced by cryptography, but often there are situations where parts of Zuck can be replaced by blockchains. So it seems to me that they're natural extensions of each other, that Ethereum is an implementation of programmable cryptography ideas, right? That it's just based upon, it's contained within one thing.
One thing that has shaped my thinking is that having programmable cryptography, not necessarily as this entirely distinct thing or an extension, but it seems to be, and this sort of builds on what both Gubsheep and Vitalik were saying, it seems to enable us to in some situations think more holistically about what it is we're trying to do, what properties we want something to have. And I mean, two is greater than one, quite literally, and sometimes that additional flexibility I think has really helped unlock how we think about things, even when it wasn't maybe strictly technically necessary for that. So I think some of these second-order effects, which are always harder to predict than even the already very interesting like literally what can X versus Y do or not do, is going to be a really big part of the story as we continue to explore. One thing that's also become abundantly clear, at least to me, and I imagine others here would agree, is that programmable cryptography, or at least what we're calling that right now, and Ethereum, I'm pretty sure we're going to keep calling it that at least for a while, those together, the whole is greater than the sum of the parts. These are very complementary and we're really going to see, I think, a really beautiful synergy, or you know, choose your buzzword here, in the years to come. But for this kind of next section of this conversation, what I'd like to do here is put on this provocateur hat, because if nothing else, it would be entertaining to me and hopefully to some of the folks who are here with us right now. And as moderator, it is my Devcon-given right to seek amusement. So what I was thinking, what's the best way for me to provoke here? And let's start from the basics: if you want to provoke, you can be reductive and simplistic. So I'm going to be reductive and simplistic, and I'm going to say there's two buckets here. There's the programmable cryptography bucket and there's the Ethereum bucket. So I'm going to start with Vitalik as the, I guess, representative of the Ethereum bucket. Vitalik, what would you like to see the quote-unquote programmable cryptography folks do differently, like maybe consider approaching or prioritizing differently, such as potentially placing greater priority on making things that people in the Ethereum ecosystem can use more immediately?
I think, you know, in Ethereum this year we've definitely seen a big shift from just building demos to trying to build applications that really work for regular users and that work at scale. And we've seen plenty of beautiful examples of this, right? So, you know, we've seen Forecaster and Polymarket and the usual ones, Dusk, you know, decentralized encrypted Google Docs alternative. You know, we've seen all kinds of different things, and blockchains becoming much cheaper and more performant has definitely been a critical part of that, right? And so I think programmable cryptography has been getting to the same transition, right? Where like dev tooling around SNARKs has gotten vastly better and just keeps on improving every year. And I think actually it is time to really have at least some portion of that community approach more problems with, I guess, a product mindset, right? So like one example of this is, you know, we've seen this year ZK Email, right? And basically turning email addresses into Ethereum addresses, where if you have an email address, you can generate an Ethereum address that can only be controlled by that email address. Like, that's powerful. That's like a Web2-Web3 integration. That's like a bridge that allows existing Web2 users to start using Ethereum applications in this very direct way that allows you to then just swap the email address out with anything else later. And I think there's equivalence of that in ZK Passport, there's equivalence of that in the whole other ZK identity space. Like, basically, really get into that gear of actually building things that are like next year, everyone here is going to use, and use voluntarily, and not just because the high priests told them that this is the aligned thing to use.
Gubsheep, I'm curious for your thinking on this, because you're obviously not against the idea of building things that people would find useful. And I also think it's been fascinating to see how Ethereum, not just technologically but, well, for lack of a better way to describe it, the values and philosophy of Ethereum have been very influential and beneficial to you. So when you hear things like what Vitalik was just saying, what else comes to mind? Like, why is it, I'm going to be again reductive deliberately here, why is it not as simple as figure out the thing that a lot of people can use and go and build that? Or is that what you think you are doing?
Yeah, I think ultimately the answer to this sort of thing has to be a yes-and. And I kind of favor an approach that takes at least three things into some kind of balance here. So on the one hand, we absolutely need to be building things that touch real users at the end of the day that are going for adoption maximization. At the same time, I think that I've seen both myself and projects in the ZeroX Park orbit also fall into the trap of basically spending a lot of time building one feature, you know, maybe not even one product yet, but one feature. Or you might see when the technology is in really early stages, entire companies, you know, well-funded companies emerge to build one circuit to do one kind of identity transformation or something like that. And I think it's worth taking a step back at times, and we do need to have that kind of feedback loop out in the world, but at the same time balancing that with the approach of, well, okay, how can we always be thinking about how to level up our capabilities and generalize and not lock ourselves in. We've had a lot of experiences where we'll have basically one neat thing that we want to do, maybe it might be some kind of proof between some sort of identity source and some kind of application that we could imagine using the identity source as authentication, and we might put a couple of engineers who might spend a couple of weeks or even months building the circuit that takes the incoming data schema, converting it, running it through a different proof system, and getting some output. And then we might realize after deploying that actually, you know, this is slightly different or this is maybe even completely off from what people in the target domain actually want to see from the data in the source. So that's where a lot of my thinking in the last couple of months, maybe year or two, has started to go around, like, well, maybe we don't yet have a complete mental model of what's going on, and before putting all of our eggs into the basket of maximizing for a particular kind of adoption, if we can build systems that allow us to flexibly iterate and experiment, then we can sort of take a balanced approach. And then one thing, I mean, I'd love to hear from Barry as well, is there's at least one more kind of branch that we need to be pursuing simultaneously, which is, well, what if it's not just the mental models about existing technology that aren't there yet, but what if the existing technology is completely wrong, and something like obfuscation or functional encryption is actually going to solve a bunch of problems that are obstacles for programmable cryptography even reaching any kind of adoption. So some combination of these three approaches in balance is hopefully the way to go. I'd be curious to hear from Barry.
So I spent some time thinking about why the first blockchain application was currency. I thought that there was another world where we could potentially have had a reputation system become the first major thing to use that technology. But I thought about it and I thought that that was reasonable for a while, but now I don't think that that's reasonable anymore, because I think that currency is inherently freer, right? Because you can just transfer currency to other people and other people can receive it from you. There's no real barrier to entry. But if you had a reputation system or identity system, it's harder to transfer reputation. The other major problem is that currency is able to interact with the rest of the world very easily, right? Because you can transfer from one thing to another. But how do you do reputation and identity systems? How do you use them? Well, it ends up being all about going to places or being allowed, authenticating to do something. And I feel like this is not a good business to be in. This doesn't seem like a good place to spend our energy, because it fundamentally makes systems that are better at excluding people. It's a more efficient way to exclude people. One thing that I've looked back on the last year and thought maybe that was a bad idea was the focus on ZK around ticketing and things like that, because I feel like there's these arguments that I've heard before that if you make it easier to KYC people, people will just get KYC'd more, right? Or maybe KYC is a bad example. If you make it easy to check if someone's over 18 or not, then people will just have to prove they're over 18 if they want to buy eggs or something, right? So this is my general concern about going in the direction of we should just go to production right now. And this line of thinking has made me feel less excited about building things with SNARK proofs and more excited about building things with more interactive technology like FHE and IO and things like that.
So that segues nicely into, I wanted to dial up the provocateur-ing a bit, and I'll start with Gubsheep. I have one for you as well, Vitalik. For Gubsheep, I guess one lens with how you, ZeroX Park, and others have been approaching PC that it could be a bit of, let's call it a skeptical lens, would be that it sort of kicks the can down the road for figuring out the thing, which we certainly all agree is some version of impacting people in a positive way. And I'll even get more specific. One thing that we've discussed is there may even be these kind of correct-by-construction elements to what's emerging in terms of how this whole programmable cryptography thing works. There's some really interesting stuff there. And actually, if you ask me, I kind of believe that we're going to feel like there's directionally correct-by-construction things, kind of like how the theory of computation was, or even just like a Turing machine feels almost correct by construction once you start to really appreciate it, even though it's not obvious at all at first you should have this tape and these symbols and that should be the way to think about pretty much all computation, or at least a very remarkably effective way to think about all computation. And yet at the same time, the Turing machine isn't actually a relevant concept a lot of the time, I would say the vast majority of the time. You know, I've been a professional software engineer, I think it's very interesting, and yet it pretty much never mattered. You could say maybe that's because we got multiple layers of abstraction later or other things. I mean, I think it's somewhere in the middle there. But yeah, that's kind of my, I want to hear your response to that sort of prodding.
Yeah, so one thing that's been really interesting for me to observe over the past maybe five or six years that I've been building various things with some of these frontier technologies is this idea that it's been a process of constant generalization. And what generalization gives us is leverage. So to give a couple of examples, this one actually comes from something, you know, more adjacent to Ethereum than programmable cryptography. When I started working on Dark Forest in 2019, at the time the idea of building an on-chain game using zero knowledge seemed kind of like this really interesting or clever trick. You know, we were using ZK in this one very particular way to achieve one very particular kind of interaction on-chain. And we built this application using some bespoke patterns because there wasn't any model for this idea of an on-chain game or an autonomous world. And I remember thinking back then, you know, one of our big inspirations for Dark Forest actually was this game called EVE Online, which is one of the oldest and largest MMOs with sort of the most interesting player activity, emergence, longevity, all of these things. And I was just thinking, man, you know, it would be so interesting if someday we could get to a world where EVE Online or something of that kind of complexity was actually running on-chain. So I ended up spending about two or three years building Dark Forest and continuing to just add to the specific Dark Forest circuits, optimizing the specific Dark Forest smart contracts, and adding in all these features. And at some point I met my co-founder at ZeroX Park, Ludens, who what he did was he took a look at how we were doing Dark Forest and he basically built a mental model for what was really going on. So he kind of built this mental model that was expressed both in software and abstractly, conceptually, for this idea of autonomous worlds and autonomous worlds infrastructure. And they got to work building Lattice and MUD and Redstone and all of these tools. And suddenly it became possible to build not only the next 10 Dark Forests but also something like a Dark Forest that was actually a hundred times more complex and interesting and actually had a shot at getting to hundreds of thousands, millions of users. And actually today it's really interesting, we've closed the loop on this over five years, and EVE recently announced that they're going to be building their new game on Ethereum-based technology. So when I think about this sort of question, I think not necessarily like, well, how do we make the perfect abstraction of something like lambda calculus, but how can we build a more mental model that actually gives us leverage, where in five years, because we're thinking about this the right way and we're building the right abstractions, we can actually access those millions of people who might want to use this technology.
That leads nicely to the prodding that I want to throw your way, Vitalik. My, I guess, strawman counterpoint to the PC should be doing more for Ethereum people today, it would probably be something along the lines of, this is not as generous to Ethereum as I think it should be, but let's just say that Ethereum has made amazing strides, but it still feels a lot like this magical island where the physics works differently, but it only works that way on that island. And there are bigger and better bridges to get over there, but the island is still kind of pretty far and the bridges are still pretty narrow. It's almost like a Bizarro Burning Man, right, down to the traffic and just how accessible it is, where it's like accessible but it's not that accessible. And Ethereum does already clearly have a very big ecosystem with people doing amazing work on all sorts of fronts. And so arguably what Ethereum needs is efforts that aren't just stacking on top of those prodigious existing efforts, but taking this, say, complementary approach. Bringing, like a phrase that comes to mind is bringing snippets of Ethereum physics back over to the main continent, you know, to accelerate how these different worlds can synergize and synthesize. And I'm curious for what jumps to mind when you hear those kinds of thoughts.
Sorry, I'm trying to think of... Can you like rephrase the question again?
Yeah, I think what I would boil it down to is, reductively you could say if programmable cryptography works backward from what Ethereum needs, it may be more marginal in terms of how it can bring what Ethereum really cares about to the world. And that would be one lens that differs at least slightly. I think again, the real answer is you can do both, but I want to be reductive for the sake of argument.
Yeah, I mean, I think ultimately it makes perfect sense to have people that are developing the algorithms, and algorithms I think are inherently a very general-purpose thing. And there are sometimes optimizations that you can make for some use case, but then as we've seen with proofs, right, everyone is just moving to doing proofs over RISC-V, and once you do that, then any optimization is basically almost equally valid for any use case, right? And I think for fully homomorphic encryption and obfuscation, like a lot of the surrounding primitives, there's a big element to them which is just general-purpose, and it's inherently something where you build infrastructure that either almost any use case or at least very large classes of use cases need, right? And there's one group of people that's very good at and very naturally inclined to do that, and then there's a somewhat different group of people that are more applied, you know, applied programmable cryptography, yeah, in Ethereum people. Sorry, I just...
Realized applied programmability in Ethereum spells ape, it's fine. But you know, so you have like the applied programmable cryptography in Ethereum people, and then like you might realistically end up having like several other applied programmable cryptography communities pop up that care about other kinds of problems. And like to me, that's a natural kind of diffusion. I mean, just like there's lots of Ethereum communities that like really think much about programmable cryptography, but then at the like, even those communities, it's like once the general purpose stuff gets good enough, then they end up using it whether they realize it or not, right? Like anything that's on top of a validity rollup, you know, we're not saying ZK rollup anymore, they're validity rollups, that is a user of programmable cryptography, but they just like don't see it at all. And so I expect we'll see a lot of that.
Well, for the final portion of this talk, which you guys both sort of hinted at, I want to dig into the future, which I'm sure everyone is interested in, in particular through the lens of obfuscation. But before we do that, and I really only want to take like two minutes for this because I do want to make sure we have a chance to explore that topic well, I want to give everyone like 90 seconds to one, get another frog, because I know you guys wanted to do that, and maybe even scan a neighbor's frog if your neighbor happens to have one. So everyone feel free to take a moment to actually pull out your phone, search the swamp. And while we're doing that, Gubsheep, I'd love to hear some quick thoughts on what is this whole frog crypto thing about anyway? We saw a glimpse of it at DevConnect in Istanbul last year, even just like why frogs, but you know, what else is there to it that you might want to say while we have everyone here?
Yeah, so some of you may have noticed the frog hats that have been popping up kind of like mushrooms around the conference, or some of you might have swung by the programmable cryptography booth downstairs. Frog crypto came out of being originally a pun on one of the decentralized sort of DevConnect events we ran last year in Istanbul called Prague Crypto. And we sort of realized, I think at some point someone either like typoed or you know, some part of the P on some signage fell off, and we're like, oh, frog crypto, yeah, that maybe that could be kind of like a mascot or something. So the idea here is that you know, these frogs are almost a delivery mechanism for some of the base sort of data of programmable cryptography. This year, what you can do with them is you can collect them on Zupass. So you can go to Zupass, press the little frog button, and start collecting a frog every 15 minutes. And what that frog is, is it's basically an EDSA signature that's really easy to make ZK proofs about. And various developers have been building games on top of this idea of making ZK proofs about your frogs. One of the new things this year is that you can also scan other people's frogs by you know, holding up your phone and scanning the QR code and sending them a frog request. This allows you to add them as a friend in Frog Social. And what those frog requests are, are those are self-issued attestations to other people who are also participating in this. So what we're essentially doing here is we're building this social graph actually of thousands, or actually I think as of maybe a few hours ago, we might have crossed like 10,000 frog requests that have gone out between different members of the community that we're going to be able to start making all these kinds of social graph proofs on top of. So you can imagine being able to do these reputation proofs. We're already starting to run into a lot of issues with Sybil attacks. So you know, it just goes to show that cryptography preventing these sorts of social attacks is definitely, there's both like a theory of it but also a practice to that. But we're excited for this to be a sort of sandbox for people to experiment with the various kinds of functionalities.