Fireside Chat With Vitalik Buterin And Kartik Talwar I Pragma Taipei 2025

[Music] For our last talk of the day, please welcome Metallic. Yeah. So, uh, so Cardic, it's uh, I mean, it's great to be together on the on the panel again for the nth time. Um so uh I don't know how has Pragma been for you? What are the things that are most striking for you this year?

So this is our second Pragma of the year. Um um and I think the most interesting thing uh that's been happening so far that uh I'm actually really excited to dig into is that uh we just had a talk from Martin from Zirkit who walked through uh seven interesting use cases of 772 and how it can simplify a lot of delegation and just smart contract use cases. So I'm like, "Oh, this actually unlocks a lot of cool things." And um I'm going to rewatch that talk and uh see if we can uh play with some of those things over the weekend. Yeah.

So I mean I'm like a core of course, you know, very close to L1 core research and development, right? And like from my point of view, the excite like there's a lot of exciting things in terms of like Ethereum finally becoming much more usable in terms of fees going down, UX going up, ZK enabling a lot of things. So I'm curious from your side as someone who's like much closer to you know the hackathon world the developers like how has all of this affected the kinds of projects that you've been seeing like now and over the last couple of years. So net net new change here that's super visible to us is that tooling gets better and and and for us like that's the the first derivative of uh what we see that actually decreases the time to from like the first moment to to a working MVP. Um so to me the things that historically and just looking at just the last 18 months alone um the super cool things have been the fact that we now have pretty good standardization around like web3js libraries u VM being the the biggest one foundry being the the second um it's sort of gone down the time from people saying I have an idea or this is cool code let me just clone and and reproduce and immediately you have support um tooling itself has gone really good on being able to support 21st century web frameworks which I think was like the biggest criticism of uh just the at least the front-end libraries.

Um the part that I don't think has gone better is overall useful and up-to-ate tutorials on how do you get started with solidity. Um I think those things have sort of been frozen in time still from a few years ago. Do you uh do in the modern age, do we need tutorials when we have LLMs? That's a very interesting question. Yes, because um there's one thing that we've consistently noticed is that the LLMs are also working on training data from years ago.

So they don't even have information about some common bugs that are now common patterns um or new versions of the same libraries that you get to import. So um for for for the hackathons we allow um use of LLMs. It's just totally fine to have autogen code. Um, and we don't consider that cheating. But the thing that we see consistently not work out is uh smart contract writing that's beyond just uh NFT or ERC20 extensions to uh standard codes, right?

I guess one thing that I'd be curious about is like might it make sense to go meta, right? In the sense of uh like have a hackathon that's about doing things like fine-tuning L. Yeah. Um there's also a couple companies that have approached us that are working on a solidity specific LLM that's trained on GAN and uh it just kind of uses just recent public code to uh to make a better interpreter. So um that is an excellent idea.

Excellent. Just meta vibe coding solidity so you can vibe code solidity. Yep. Yep. VIP code the vibe coders.

Yeah. What what about applications like what what applications have you been seeing that excite you the most? So, there's been a couple things that I would see. I'll answer them in meta and and I can name some specific ones, too. Um, interestingly, I was not prepared for this to be an interview about me, but uh I'm okay with this.

Um, the clear thing that's definitely worked is uh a lot of mini apps. Uh we've seen a pretty big uptick on the world coin ecosystem, varcaster ecosystem um and uh just overall people saying hey we just need to have some inference of who the user is without requiring email as the the first entry point and uh from there we'll just let them do whatever they'd like. And the part that's made it interesting is that not all of these things are finance related or or are payment specific. uh some games themselves kind of fall into this. Especially a lot of games are are kind of uh coming off mini apps and they kind of work and they just sort of interact with the chain to store your final state if you finish it or achieve a high score or you kind of win an achievement.

Um but that's kind of been what's working. Um beyond that, I don't think I've seen net new interesting ideas. I've seen versions of things that are just sort of trying to be more ubiquitous. So, payments uh just kind of the the Venmo of X of uh just make it easy to pay people has been a very consistent theme. Um but I don't think they've sort of taken off as much.

And uh I don't think we've seen a lot of cool things on DeFi in a long time. So one thing that worries me for a long time about like the whole mini app concept is and and a lot of uh like related trends is that there's like a very easy way in which that can go very dark in terms of w gardens right like you know the more you move away from users interacting with applications through wallets with keys that they control through a standardized interface I mean like they have they bring their own keys and instead you have these kind of sube ecosystems that like define their own APIs the more an application built inside of one is like sometimes uh not even just walks to that platform but sometimes even walks to one client right so like uh like even I mean like to what extent like if you think about something like signin with forecaster like that creates a lock in around caster but then like there's also a risk that even creates a lock in around warpcast right so yes but do you do you then differentiate between the fact that maybe that wall garden is fine because if somebody's controlling a good experience for for that game. Um, it's their right to do so. But as long as they're agreeing to posting the the state of that on chain on a public network, is that a is that a problem still or no? Uh, I mean, I think this gets to like a really a question that's really at the heart of like why build on blockchains and like why do decentralization, right?

Which is what guarantees are we trying to provide to users, right? Um, and I mean let's like we zoom in on I mean like Farcaster as an example, right? So one benefit is like if warpcast uh blows up then you can switch to some other client you know you can switch to firefly you can switch to taco you can switch to whatever right um so but then for that to happen like those flows need to actually exist right um so like is this uh like how much have you seen in terms of like people actually sort of thinking about some of these kind of exceptional case flows not a But um and and um it's not surprising either because at the end of the day the things that do get successful get successful because they are being built by product-minded people who really care about very last mile set of details. Um and that's kind of what helps create that funnel to amplify their growth. And uh if somebody has to kind of pick an alternative, you end up sort of uh by default at a state where the quality is not going to be as high and you already have a bar to to meet.

So it means either people are going to have to accept the alternative or just reject it alto together and move on to the next thing and we kind of see that pattern a lot especially in open source. What what do you think are some ways that like we as an ecosystem can encourage or make it easier for for developers to like build applications the right way? I think you would have to really pick what layer you care about the most. Um ultimately from personal experience or or like a personal opinion I I think you have to uh you will not be able to create any incentive where somebody is going to not want something proprietary for them to succeed if the goal is for them to survive as as a business. Uh it doesn't mean that you cannot have really really well done open source uh projects.

There are actually countless examples of this. Uh but at the end of the day, if somebody has to assemble a team and there's a notion of expenses and and revenue, uh you naturally converse to that. Um the things you can do though is you can um ultimately fall back to a world that we know already works in crypto, which is unfortunately infrastructure is what what's left. And if I can manage infrastructure for you and let anybody control the rest of it, um yeah. Well, I mean, I think um like it's also easy to fall into the trap of thinking about these things as being too binary, right?

Like Oh, yeah. Yeah. Like, okay, maybe like one particular example is if you think about wallets, right? So, one of the failure modes of wallets is like wallet login, right? Like you create an account and then you have no way to switch to another wallet, right?

But you could totally imagine wallets following a standard. I mean, for just like regular EOAs, this already happens, right? Right. And there's like standards you can move you can move 12word seed phrases over. And then you could imagine like actually doing the hard work and like we're doing the same thing for say ZK email recovery.

So if your wallet disappears you can uh like switch to another wallet, recover it with the same email through another interface and like you can actually yeah like make that side of things work, right? I'll give you two counter examples of why that doesn't work in practice. Uh, one is, um, largely if you are a wallet, um, it's in your best interest to not make it easy for somebody to switch over to a different product. Um, and and that's kind of, right? Well, the thing that is in your interest is to make it easier for other people to switch to your product, right?

But it is birectional, right? So, so you you end up having some sort of limiting factor. Uh, that sort of makes this uh, slightly hard. Uh but the second part that I think um it's not even intentional but the the part that should not be ignored is that when something is working um you naturally end up getting feedback from your particular user base saying I would like X and that often ends up dictating the future of a product over what standards would like you to do or what others are trying to do to to raise the the bare minimum of like the the floor. Um, and and that's kind of where you run into a lot of issues where somebody was like, "Yeah, we started off this way, but then turns out the 3 million users we have for our wallet really want to optimize for X or we they want more mini apps or they want to be able to have us control the the single pass key access and uh and that now creates that fork where, right, it just makes it harder for now to to comply with all standards.

So, what do you think are the best ways to push back against some of this? In theory, the answer is how do we make a very high quality open source set of alternative um and ensure that somebody's in charge of maintaining that without having financial incentives be the only reason to to improve it. But in practice, that doesn't always work. I mean, do you think the foundation should run like one wallet the same way that it runs one client with gas? No.

Why not? Uh because if that's not your only priority, you're going to do a bad job at it. Okay. Do you think the foundation should continue running G? Uh running or maintaining?

Maintaining. Yes. Okay. Can we like try to sort out the difference between those two cases then? Yes.

Uh one of them is a product of your product. The other is the primarily thing that there is an expectation for the foundation to uh have a great priority assigned to. Um right but is that expectation sort of unnecessary expectation? I don't think so. Um and that comes from the fact that um if and this is interesting because I do have some questions on this specifically but um to me the goal of the foundation should be to primarily ensure the future and success of the protocol.

Mh. Uh in addition to anything else that's on your wish list. Um but there's one clear expectation. Mhm. Which is make sure the protocol is the best version of what it can be.

Right. And that's from anywhere from feedback from people to your own road map kind of coming into play. And uh in that world um just because you don't get to just reset from now and and history matters um get has been the reason why uh things are the way they are in terms of market share for the clients as well as uh just directionally what's been prioritized. So unless there's a goal to not have any involvement in maintaining g then uh I don't think you get to cherrypick and and have it be treated more on a spectrum versus a binary. I mean it depends right so one thing that we did is for consentus clients we decided that we're not bu going to maintain one of them.

That's fair. Yeah. So and then you know ZKVMs at the beginning we maintained one and then we stopped maintaining one. So I guess like but was never but that was as a research experiment not as a commitment to have that be running at all times. So it depends.

Yeah. I mean well it was it was a ZKVM that I think people sincerely meant to like turn into a thing that would actually be used by ZK rollups. Uh yes, but the EF has never officially even hinted that they want to maintain any L2. So, so that particularly still falls into the category of an experiment, right? But not a commitment to ensure the future of the protocol.

Okay. So, one way to relate to a thing is make something and treat it as an experiment, right? And that's actually something we could do with wallets, which is and and that's totally fair game, right? At the end of the day, you have a expectation that it it may not pan out and and you have a a lifeline or like a life expectancy. Yeah.

So there's like like I think if we think about like the level of commitment the EF has to different layers of the stack right there's do nothing at all then there is um like say sort of regulate in the sense of you know like provide incentives to other providers which uh you know could be like CIP type programs it could be funding things like L2B it could be just like talking about what we care about then there is like creating our like writing auxil auxiliary software there is creating our own thing as an exper experiment and there's maintaining our own thing for the long term, right? And so I think an interesting question in general is like as the stack expands and as more categories of things appear like there might be new categories where the optimal thing for the foundation is to actually have those higher tiers of involvement. No, that's absolutely fair. But I I think the the the reason why I objected originally was that um there is still a very discreet differentiation between a product an infrastructure as an experiment and something that's considered critical, right? And um and a wallet is not considered critical from the point of view of EF maintaining a version of it um in in kind of my framework here.

Um, now nor is it considered infrastructure, right? Unless you take on the responsibility of maintaining the full stack and prioritizing it as a product, which means there's somebody listening to feedback, keeping up with the standards, and ensuring that they're also helping ensure the standards are met across the the consortium of others in the game, right? I mean, web3.gs would be another example here, right? Yes.

Which is not a wallet, but it's definitely Yeah. like closer to like like it's dead soft. you needed something to seed off uh the ecosystem and uh and seven years ago it was it was required because you had to be the first person to prove to people that this is something they should care about. But then when things do start to work, people come in and say look these are the shortcomings of this and these is these are things that we don't like. Let's make it better for our particular use case.

And now kind of you have the version of what we have now in VM um where it works with most popular frameworks that people actually use and uh there's a consistent priority for that team to just maintain that library. Right. Yeah. The question is like you know you could be guarding against two different failure modes, right? One is like a thing not existing and two is like a thing going into like fragmentation, walled gardens, sort of the usual failure modes of commercial things, right?

Yes. Um and I do not disagree with that. Um the disagreement I have is when something is a userf facing product right uh and everything else here is a developerf facing product uh that approach does not work okay why do you think it doesn't work uh because somebody has to make that the entire priority for for them so like you're just saying the total volume of work is much higher or the volume attention and uh subdistraction um so in a way if I were to counter against myself here. She's like, you're absolutely welcome to do that as long as the people who are doing this open source wallet are the are only in charge of just that, nothing else and they cannot be influenced by anything else going on and they are listening to the user feedback and maintaining that in perpetuity, right? Which is is a that's exactly what starting a company looks like for a consumer.

We have to listen to the feedback. I mean client developers are listening to a lot of feedback too. Uh but the audience is developers where you have a filter for there's a better expectation of this person knows all these things for sure. But when you have a wallet um it could be you're saying it's right it's it's easier to like work at the level of the stack where there's some intermediaries. Right.

Right. You have a consistent profile of who the user is but the second you go into userf facing products that that spectrum is basically infinite. That makes sense. Okay. Um maybe just like zooming out a bit right.

So as the ecosystem gets more mature, I think we can expect new layers of the stack to emerge, right? And so um you know we've been seeing uh you know like light client servers are would be one um you know we've we've talked about wallets now there's like an entire set of potential inter intermediaries if we're talking about cross layer 2 interoperability. If we start talking about ZK there's a whole set of interoperability um intermediaries. Are there any sort of new layers of the stack that are emerging that you think are interesting that you think are particularly worth like watching and paying attention to for the EF or or let's say for the Ethereum ecosystem I think the I'm trying to come up with a question that I I feel like I can defend properly. I have halfass answers for a lot of these, but uh I'm I'm really being careful with what I say.

Um Okay. To me, the the part that I think is up for renewal is looking at what's happened in the smart contract world of what's been deployed so far and anywhere from best practices to best patterns that people have um and refreshing the standard library because you ultimately want to give people some sort of more guaranteed ways of not having to worry about right 20 core things that everything every project needs uh but not requiring that additional complexity to be coming in from so like you want to expand and modernize the set of like smart contract things that people can do with like just copy pasting existing stuff. Yes. Um, so if if you were to kind of think about a refresh for to solidity for this year, um, what would I think about baking in versus expecting others to reference or or include and specifically how do we actually make it more feature forward? Obviously, uh, Pectra has BLS 381 here, uh, but there's probably a lot more curves that you can add.

Um, I'm not saying go all in on pre-ompiles, but there's you can you can see and do a look ahead of like what people are experimenting with and uh see if that can be supported natively because if you feel like some of these things are about to become bigger patterns, um, why not make them uh defaults, right? What are some of the biggest examples of like workflows that you see that people are having trouble with that like with the right library language feature could be really easy for people? uh surprisingly not a lot of brand new like nuance things. It's it's more about the fact that well what if there was a better way to think about how do I upgrade contracts? Um you can still have an opinion as as uh the the VM but not require everybody to follow it.

Um so so that's like the most common one which is you have to expect people to be able to upgrade their software um until at least it's a certain checkpoint. um and and not having great answers for how do we do that now? Especially when we increase the gas limit, complexity even goes up and you have now more contracts referencing each other. Uh it's a lot easier to create a bigger mess. Uh that's that's one.

Uh second piece would be just how do we actually ensure more native compatibility around account abstraction being a default and not a a secondary pattern that has to be done in code. 772 obviously helps with that. But uh you can update potentially things that that make that uh a lot more seamless between not having to have a case for ERC20 versus native tokens. Um obviously uh one thing that I think you've also brought up in the past is uh how do we read L1 state and L2? Um can that be baked in?

Right. And then um overall just if you are betting on the world of ZK well how do we actually make ZK be on the VM? Um I don't think there's a good answer for that. And and if we've been working on ZK rollups for 5 years uh well why was it not prioritized? Yeah.

Well I think the answer there is that we've been working on scalability rollups that happen to use the exact same technology that's useful for scaling and privacy. Right. But for sure. Yeah. No.

So yeah. So the question is like uh how do we start more properly kind of leveling up and general purposing the privacy part of the stack, right? Yeah. Privacy is a whole category of its own too. Um one thing I mean I don't have a good answer for like how or what specifically but to me I think a a big part of what can be simplified is how do we make oracles more native to the VM.

Um I don't know what that actually means but it does mean that it's a massive dependency across every single chain whether it's Ethereum or not um to rely on external information. Can we do something to make it easy to get outside information into the chain outside? What types of outside information you think would be which is just data passing arbitrarily but but can you make that simpler by allowing native network requests of of kind of different uh protocols? I'm not saying you should, but there's a there's a version of it where you can simplify accepting information uh from outside the chain, right? But still, I'm curious like are we talking like web two requests?

Are we talking about price feeds? Like what? No. Uh still not not specifically anything, but it's more about the fact that uh I don't think you'll ever get a world where the entire onchain interaction will be contained within the chain. Mhm.

So, even if it's stuff like, well, I need to verify my email or my bank or there are other incredible developer tool products out there and that have APIs or even financial products or just not even Facebook, whatever. Um, I would like to be able to access the web 2 API world that is way bigger and way more rich and and incredible. Um, to help transition people more seamlessly on on web 3. Um, can that be simplified so we actually get more people an opportunity to uh use more native crypto apps. How much of that do you think like TLS Notary does already and how much does it not?

Um I think how do I be nice about this? Uh uh I think the meta comment on this is I'm going to answer without directly answering a question. And I'll be upfront about that is you do not want to introduce a brand new way of doing something when everybody already understands how to do something, right? Um so if if we know that every developer in web 2 understands what a REST API is, uh let's not force them to use some brand new thing that is not common or debuggable or requires them to relearn something. Um and and Tosary falls into that category for me.

um in addition to being uh a little bit more inaccessible to every other developer and requiring um not as much direct compatibility with a headless API world that the rest of the APIs are um right are just already require you to to behave with. Yeah. Yeah, I mean I think well the question is like when there's developer friction it's like how much of that is a fundamental property of the thing and how much of that is a high level language thing right sure but I think the the point I'm making is every developer knows how to use a normal API right and there is a very consistent predictable and the same method or a same um set of instructions that every API company gives you on their documentation page on how do you use things, how do you copy paste, how do I clone this repo and make a simple HTTP call. Um, so when you change that, uh, it requires some relearning and it adds some edge cases. Um, so I'm not saying add REST API to solidity.

I'm saying don't make that set of changes way more than they are now. Right. Right. I guess like like I'm wondering is like what if we can just make a compiler that like takes Python code that contains REST API calls and then we API I think that would increase the order of activity and experimentation by a couple magnitudes. Okay, there there we go.

Hackathon project idea. There you go. Cool. Yeah. Okay.

Well, uh do do you have any questions for me? H I think I do. Um I I'll ask the same question to you. um from anywhere from what you think versus what you've been told whether as a suggestion or a complaint uh what do you think the developer ecosystem is missing from Ethereum h I feel like my the answer for a long time is obviously like a lots of little things right like know like you you you can talk about like making it easier to like you interrupt operate with love too. I mean another thing is uh there's a lot of tooling that exists um around solidity but that same level of tooling doesn't carry over to the ZK world right so like like basically you know like what where is the ether scan solidity verification for circom right there's uh like basically I think one of the things that I worry about for a long time is like there's a lot of assumptions and a lot of like very yeah clean and nice things that we had back when Ethereum was a single chain it just Ethereum.

Nobody car nobody was caring about privacy and so on. And like as more layers of the stack get added, a lot of that stuff kind of doesn't appear and like gets eroded by default, right? And it's like it's never one single thing, right? It's uh like it feels like there's this long tale of a whole bunch of things. But I think for me like asking the question, what is a feature that we took for granted in 2016 that we don't have now?

Like what are the actual regressions? And there's a lot of regressions, right? Like like like to me it's actually a really useful like generator of places where Ethereum should improve. I mean, both from a developer perspective and even from a from an L1 perspective. Do you think um it's a good thing that a bunch of L2s are letting any VM kind of come into play?

Um or do you think it creates like side effects for EVM on L1 with now thinking about HK support? Oh. Oh, yeah. You mean like like arbitum stylus and like other VM types? Um I mean I feel like okay I've gone back and forth on on this a bit, right?

Because uh like on the one hand I think all of this VM innovation is really cool and I support it. There's a lot of amazing things that you can do. But on the other hand, I feel like the thing that we've learned over time is that there is like a lot of network effects and a lot of interoperability benefit to the uh EVM itself, right? And uh like a lot of the uh benefit a lot of the benefits that you can get like the there are ways to get it with like higher level languages and higher level constructs, right? And so I think uh like that's where some of the some of the trade-off is um like application like if I'm an application developer right then uh like if I write a thing in pure EVM then like I have less lock in I have a lot more freedom that like if one L2 goes off the rails I'm able to move the application to other layer 2 potentially even I'm like move it to layer one if like gas conditions become durably more favorable So like that's probably the other side of the of the argument for me.

I mean I but it goes back to original point of dependency around uh somebody choosing to now have their priorities changed. Um purely out of curiosity. We don't have to go deep into this. What happened to EWM? I think okay so I've I felt excited about Ewazam five years ago and I think part of the excitement is like obviously the EVM is like crap in a bunch of well doumented ways the whole 256 bit thing is a mistake um you know there's a bunch we're getting somewhere yeah you know a bunch of call code thing like call code like just dangling as a pointless op code in gas observability like causes I think more harm than good like you can go down the list right and uh and also it's just not compatible with like stuff that people are doing outside of crypto.

And so EWM felt like you know this is the VM of the future. Browsers are adopting it like we should just all use the same VM. But then what happened in practice was uh that I mean I think first of all it got de delayed because of you know the merge and a lot of other things like it's quite plausible that in a world where if we got proof of stake and we got charting for free we would have just switched to ewasm back in 2020 and like made that our big project right but that didn't happen and then I think sometime maybe around 2022 2023 the big shift that happened was uh that you know we saw things like risk zero And also we saw snarks right and when we saw efficient enough when we saw sonarks come online we realized that like if we are going to take the effort to do a wholesale replacement of the VM then we should replace it with something that has snarks in mind right and then in 2020 to 2022 the narrative was basically that well you optimize your computation for snarks right and you make your entire VM mod p for like some 255 bit prime um you know you figure out how to make everything like optimized their own field arithmetic and then of course things ended up changing and things ended up changing again and then right now it feels like risk 5 is like I mean it's a thing that the e that more and more zkm implementations are being written in I mean there's like like open hardware projects are building around risk 5 like it feels like risk 5 is like gaining momentum as a standard right and so like maybe the thing that makes sense now is like if we decide to do a big VM pivot then uh like risk five is actually the right thing to switch over to. That's a it's a provocative statement here that's going to make uh some projects a lot happy uh tomorrow morning. Um actually I won't ask that followup uh because I think we're going to go into a rabbit hole where only I care about the answer and I'll switch topics.

Um why is upgrading Ethereum so slow? Why is upgrading Ethereum so slow? I mean there's just like a lot of people to coordinate. there is uh also just a lot of different priorities that are being juggled. Um I mean and also like things that are being done are fundamentally hard, right?

Like if you think about something like the merge, I don't think there is any other software project. Yeah. I guess how about an answer to that question that's postmerge in the last two years. Yeah. And one part of the answer I think is that things like actually are picking up speed, right?

And um I think like the if you think about the level of complexity of some of the stuff that's happening like if you like 4844 7702 like all of these things in the premerge era any one of those things alone would have eaten up like two years of full-time core dev attention right and so if you were to break that two years down how much of that is coordination and how much of that is implementation and research right so I think uh the place where we've gained in speed is that we just have a much wider base of talent that's uh like able to work on these things in parallel and put effort into them. Right? The place where I think we're still slow is uh a big part is coordination requirements. Like one of the ideas that's been thrown around that I'm personally open to is switching to a regime where instead of waiting for n out of clients to be ready before we press go on a hard fork, we wait for n minus one out of n clients and then it's a good metric. Yeah, I mean that like that both speeds things up significantly in a direct way and it also like creates social pressure.

Yeah, exactly. More incentive for clients to ship faster. And so I think things like this are definitely things that we should be experimenting with more. So maybe maybe a dumb question, but why why bundle things as much instead of just saying every month we'll ship something small, right? Well, if it's literally every month, then like node operators have to download a thing every month.

And then like basically once you get to that level of frequency, then the challenge is that like once you make a thing that frequent, people start looking for ways to automate the thing and then you basically end up leading to like auto upgrade buttons and then you end up leading to a small number of people getting centralized control over node software. So I think in that sense it's like good for each individual upgrade to be an independent decision. I do think we can go a little faster, right? I think uh what does that mean to you tangibly? Um I mean I think like I think two forks a year is reasonable.

Um and uh like I'm not sure there is benefit to doing four forks a year instead of two because if you think about the math then like that just like the difference between those two is like on average features coming like three months later and that's like okay fine you can wait. Actually on average one and a half months later right? And like okay fine you can wait. Uh but how do you think about user feedback in this case? So um a very obvious example is uh Uniswap had to wait until the last fork to launch V4.

Uh and I'm sure like there's been projects on the the dock for years to now fully use 381 natively. Um if somebody really has demand or a workaround they've been using to wait on this, how do we think about prioritizing that and satisfying that user demand? I mean honest I mean I guess one part of my answer might be a bit unpopular for developers which is that we should be more willing to tell them to screw off and uh my reason is that if you look at a lot of historical instances of places where we've added features in order to please part like fairly small groups of developers is that EVM specific comment you're about to make like there have been lots of instances where like something was added to great fanfare and then it just ended up not being used right I do remember that. Yeah, like Blake. I mean, even like Motty XP, I think if I could go back and give myself a piece of advice five years ago, like it would be we should never have done Modi XP.

Like there are nonzero projects that use it and derive value from it. But the amount of heartbreak and like the amount of near missens failures that my XP has given us is just insane, right? How do we feel about EOF? Um, yeah, you know, one of those examples, right? I mean I think uh yeah I mean I think my view on that right now is like especially if uh like we think of the long-term road map as being like at some point do we make risk 5 primary then like it's not like is it that worth it to try to make the EVM like 20% better or 10% better and like maybe the right way to think about EF type stuff is what are the specific use cases that matter the most and uh like are there keyhole solutions that are sort of five times is less complicated but that meet those needs, right?

And so one example of that is like increasing code size limits. One example of that is like adding more swap and dup codes. Or you can start from the other end and say well instead of doing all of Eof we're going to like dump code non-introspection or you know we're going to dump the yeah like function calling use like things like basically you know you can approach it from both ends and you can figure out a kind of like a more restricted 8020 and I think that's fair. Yeah, that's a good framework. Um where do native roll-ups fit into all of this?

Yeah. And so I mean so first of all, right, I think uh the whole like there's this whole like rollup terminology confusion. And so I mean I'll give my yeah kind of terminology here, right? So a based rollup is a rollup where the L1 is the sequencer. Um then a uh stage two rollup is a rollup where the uh security is based on trustless code.

And so if the trustless code works correctly, there's nothing that's trustful that can override it. Um and then a uh native rollup is a rollup where the state transition function is directly provided by the layer 1. Um what's the nuance between that and sequencing? Okay, so sequencing is choosing order of transactions. Um I see.

Okay. But not confirmation of the but but not state roots. Yeah. Exactly. So there's like there's like two parts of the pipeline, right?

One is like transaction submission to transaction ordering and the other is transaction ordering to to state root calculation and uh like based handles the first part and uh like native handles the second part. And so you can totally have a native rollup that has uh like some proprietary sequencing. And I would argue for a lot of applications that's a good thing, right? like there are one of the trends that we've seen I think is we've seen rollups kind of like a lot of layer 2 initially be interested in uh decentralizing sequencing but then kind of delaying and like sometimes even giving up on that right and like my own prediction for a while is that I expect layer 2s to bifurcate into one side which is like either like centralized sequencing or maybe sort of centralized but replaceable with governance but things that are kind of closer to that end and just based rollups and my argument for that is that like the middle range like it just adds a lot of complexity for a layer two that like it doesn't realistically give them that much benefit right and like the left side it lets you uh protect your users from MV exploitation which is like actually a big value ad yes um but what about revenue from sequencing when you have to optimize for the base rollup case right yeah so in the so in the base uh rollup case uh the thing that you don't get is me. The thing that you do still get are layer two congestion fees.

Just just the congestion fees. Yes. Right. Yeah, that's fair. Got it.

Um Yeah. Yeah. And like also Yeah. The way that I think about it is like as a layer two, if you go based, you are definitely forgoing a lot of revenue, but you're also forgoing a lot of cost and a lot of risk. Risk being in case there is.

Yeah. just like all of the lines of code, all of the infra, all of the responsibility and everything that has to do with the sequencing side. That sounds kind of nice. Yeah. Um, yeah, like basically the way that I see things, right, is that I think like RO layer twos are an entire spectrum that basically goes from glorified shards to like enterprise apps but with more trustlessness features.

And uh like things on all sides of that spectrum are valid and I and I expect the AI ecosystem to like support like to have different parts of it that optimize for all different parts of there. I mean this becomes even more exponential in terms of the scale because you're going to see so many of these. Um, how do you think about Mhm. I mean, I want to say the word revenue extraction, but it sounds bad, but better better rent collection from L2s if they rely on L1 security and and is base roll the solution here where it just kind of magically slightly gives you more I think. Yeah, I think not necessarily.

I think uh I mean honestly the most pragmatic thing that I've seen is like I there's a an EIP to raise the minimum blob fee and I think we should just do it and I would even argue like layer 2 should support this and my case for this is basically that I think uh right like if we have a higher minimum blob fee then that uncouples the question of revenue from the question of blob count and there are going to be people who try to argue well why are we increasing the blob count when that just makes the blob fees drop to zero and uh like why are we giving like L2s more space for free, right? And like it creates an unhealthy dynamic, right? Like basically when price gets regulated by supply like you're giving parts of your community an incentive to create supply caps, right? And so if we just say well there's a higher minimum base blob fee and then we set it to like the level where you know like based on historical numbers like say yeah L1 would end up getting like 10 to 20% of L2 fees then like that actually makes everyone on the same team right because L2s always want higher blob sizes and then the L1 will also want higher blob sizes because it maxes out the amount the the amount of blob gas on which they can collect the blob base feon. So yeah, so so a process question into this this thing you just talked about.

Um clearly for this to become a reality where you're imposing a minimum fee for for blobs. Um what will be the next steps? Like this is like we we debate this for two months with with somebody online or or it's like do we already have candidates that are opposing this view? like how does this become a reality and and what changes now that there's a bigger effort to uh ship faster and care about scaling L1? Yeah, I mean this this gets into this like interesting set of questions about like all core devs improvements, right?

And uh I mean I think uh there's the qu there's the sort of narrow question of like taking the existing ACD as a starting point and like how do you optimize it? And I mean Tim Beo has a lot of ideas a bunch of people have a lot of ideas on this and I think it's like a really important question. The other question to ask is like could we create other forms of signaling and like basically Yeah. mini app where you vote. Yes.

Well, right. I mean, like actually, right, like literally Yeah. I mean, like bring like like remember carbon vote from back in the day, right? Yeah. Yeah.

You should bring back carbon vote also uh make it super easy to use and so you can initiate a carbon vote and then like really easily link to it from, you know, a tweet or a forecast or an Ethereum magician's post and like just make it and then also like not just use ETH for voting like potentially also use, you know, like anti-LE stuff. I mean like y like proof of ethereum contribution like you should have like five different metrics right and or different weights too I guess. Exactly. Like like users like users should be able to just like toggle when they see the you know like the pie chart and they should see like what the pie chart looks like according to the different weights and that's a really valuable source of info by itself, right? Yeah.

Like basically yeah like I I think there are a lot of core devs who are kind of they're well-meaning and they are in some sense fine with anything but they also don't want to like overstep the community's toes. And I think if we had high quality signals of uh like what are things that different parts of the community value and are all okay with then like that is something that like I I think they would really welcome. Uh I'll ask two questions before we end this. Uh one is going to be a very dumb question as a follow-up to what you just said. M um does it violate some internal principle or rule or decision-m framework if you make certain decisions that are considered reversible um to the to the protocol where you could say technically you can do this without requiring a consensus vote and then you may realize that it was not the right move.

Let's roll back. Oh, I see. Um, so this actually gets to another thing that I've been thinking about, right, which is uh like so you know recently like you know like Kev Andre has been pushing this EIP for like basically defining like the uh for the uh like disk and compute requirements for a node and uh like this is really cool right because uh like generally there's this whole question of like well how do we scale the L1 and how do we preserve decentralization and you know like generally like there's always this kind of very illeible holy war about what kinds of things we do, what kinds of things we don't do. And so, well, the what if we can basically encapsulate the holy war and we can have the holy war around like these variables and then once you have those answers then scaling the L1 just becomes a math problem, right? And so like like that's like to me intuitively it's a much better system, right?

Because like the people who care about the holy war, they can actually like they care about in a very legible way, right? Because we're talking about node requirements and like we know what 4 terabytes means. Like you can go on, you know, like your own computer. You can you can price it. Yeah, you can go to your own computer.

You can type pseudo df minus h and you can see you know like what is the hard disk space that you have, right? I think you need pseudo for that command but okay. Yeah, fine. Um but uh you know you can basically uh like it's much more uh like legible that way than if you just like and then once you have that then like it's a much more technical question you talk about that right and so the reason I say this is like the equivalent to this in breaking backwards compatibility right and so but the reason why I asked that question is yes like I agree with breaking backwards compellion and that's obviously when you're building immutable software and promoting that it's it's a big factor but here To me, this is less backwards compatibility and more of an economic decision because this is price action, not necessarily a change. Okay.

So, I guess maybe I was misunderstanding, right? Because like the the way I was the direction I was going is to say I think we should have an EIP that explicitly like standardizes basically what are the waiting periods for breaking different backwards compatibility. And then the thing we can say is if a feature was added only in the most recent hard fork then the backwards compatibility time duration for like for breaking or changing that is zero right yeah just have like a lock in of like a free state yeah so like any feature that is less than two years old can be yeah like can be arbitrarily changed with zero delay right and that's also like so like is that what you meant or are you referring to like a different kind of well yes in terms of that was also part of it but the the question here was like we talked about blob pricing and and I was like, well, why do we have to wait a few weeks, two months for people to argue about the pros and cons when there's going to be more pros? If you can just move ahead with it and you realize that, hey, maybe it was not the best decision, you roll it back or repric it, right? I see.

The question is like, should we just like that's an economic question that is not breaking code. Right. Right. Like should we just last minute like yolo this into pectra basically knowing that if it breaks like we like it's not going to be that bad and we can change it in Saka. Um, I mean it's an interesting idea.

I mean I think uh if Pexra were one month later I would totally support this. I uh I mean I do think that you know there are core devs that would have a hard break if you like add changes this late in the game. Just commit to master. Yeah. Yeah.

Um that's fair. Uh last question. There's been a lot of changes hit the EF. Uh there's been a lot of uh stuff we've seen on Twitter and other places. Mhm.

Um, the thing I'm curious about is when we kind of saw the surge of a lot of posts about things that EF or Ethereum could be doing more or better, whatever. Um, what was the thing that you feel like you ended up changing your mind on that you previously disagreed heavily about? What is Sorry. What is a thing that I ended up changing my mind on? Sorry.

In what scope like in EF related things or EF and Ethereum related? Yeah, that you like directly attribute to feedback from the last two months. I think um I've been having a lot of like rethinking of um like what is the EF's role, right? and um like being open to like a lot of different ideas and I think my thinking there is that the Ethereum ecosystem is evolving and I think one of the positive things that's happened is that we are seeing the emergence of uh you know like very effective and very sophisticated actors outside of the EF that are doing a lot of research that are writing a lot of code and the type of approach that makes sense when the EF is the only actor doing things and it's desperately trying to shift to situation when that's not the case is not the approach that you want to take when that's not the case and you want to ask the question well what are the indispensable things that the EF should do that the that these other actors are not going to do on their own right and so that like you know we talk a lot about philosophy of subtraction right and I think uh like how the philosophy of subtraction should be interpreted or like even thought about or even is subtraction the right word is a question to which the answer can change quite a bit right And so the like the thing that I'm more in favor on of now I think is an approach that's like not about emphasizing this idea that like oh the foundation is on a like on a deliberate managed decline from running 100% of the ecosystem to running zero but rather this kind of dynamic um like identifying where the market failures are and figuring out what are the places it can improve them. But but does that what does that translate to in being actionable for you as a as a conclusion?

Like I think you you talked about a premise but not a takeaway, right? I mean the uh I think the takeaway is like the EF should be more open-minded both to greatly reducing its involvement in areas where it's historically been involved and and in actively expanding its involvement in areas that it's formally formerly seen as being outside of its reignment. Amazing. Ladies and gentlemen, Vitalic Ferrer and Partic [Music]