Wen Escape Velocity, Wen Ossify by Venkatesh Rao & Danny Ryan

That was great. I couldn't agree more. Next up, we have Danny and Venet talking about escape velocity and certification. Welcome. Yes.

Right in the face. Very good. Escape velocity and certification. Um, very good. Let's begin with a brief introduction.

So, D. Yes. I'm Danny Ryan. I work at the Ethereum Foundation on the research team. I also work very closely with the protocol support team .

So I do some research. I write a lot of specifications. I coordinate a lot of major infrastructure upgrades, like the merger and those that will come after. And I am Veneteshra. I'm a blogger at Ribbon Farm and I've been working with the EF for the last few months on some topics that we'll talk about in a few minutes.

To begin with, Danny, at DevCon a few months ago, right after the merger, you showed a bunch of boring graphics, the most boring I 've ever seen in a talk. And you were excited that they were so boring. The entire audience was too, and it was great that it wasn't an event. So now, six months later, what's the assessment? Yes.

The merger was not a major event. I mean, it was a spectacular event, but if you look at those charts, they're very flat because things just worked out. I think if you look at those graphs, things are still working. You know, we're finishing at a steady pace. We have about 99.

9% attestations and blocks all the time. So things have gone well. The staking ecosystem, the node ecosystem, and everything surrounding it continues to evolve, as discussed in the last panel. But in a steady state, things are fine. Everything is ready to move forward.

Very good. It's still not an event, and I think that's what we all want to hear. So, what's next? We just talked about the retreats and 4844 is on the horizon. What are the main things people should observe and what should they pay attention to in the short term?

Yes. Often, when I think about protocol updates, I think about how we need to make things sustainable, secure, and scalable, while still remaining decentralized. The merger helped achieve a couple of those, making the protocol more sustainable. It made it safer. Well, we certainly keep an eye on the retirements, which will close the cycle and complete this mechanism.

In other words, you can not only enter, but you can also leave. Uh, but the most important thing is really scalability. Um, it's been the main topic for years. So it's that third S, 4844, that adds blob-type data transactions, which is just an elegant way of providing greater availability of scalable data to the blockchain and is like an initial step. Um, that's huge.

We are certainly looking for something similar to semi-production test networks, completing features and really polishing the specifications. Um, it's been happening in parallel with the upcoming updates. So I'm really excited to bring some scale to the table. Beyond that, there are many iterative improvements, many continuous tweaks and security enhancements for proof of stake, but many good things. But initial scalability is the most important thing.

OK. And uh, I guess these short-term things we're getting into now are the beginning of, um, the big roadmap that, uh, Vitalik, um, set up long-term with his, you know, purge, surge, um, I can never keep track of how many rhyming words there are, uh, but you just published a very interesting essay of reflections on, more or less, where we're going from these short-term priorities to the long-term roadmaps. Uh, long-term roadmaps. Uh, can you talk a little bit about those topics ? Yes, so there are certainly some technical things there.

So, you know, how do we go from 4844 to full sharding towards a much more scalable landscape? There is some technical work to be done. There are many iterative improvements in security that I think are very important on the horizon of, you know, 3 to 5 years. But a lot of what the essay is about ends up being about my concerns regarding all the things we have to do, but also in this very dynamic environment where there are many different interests, there are many different pressures, and simply how we can continue, uh simply how we can continue, uh , taking the protocol to where it needs to be, to be sufficient for its purpose, uh, without collapsing under the weight of all the different, uh, I don't know, pressures. So, I think you came up with a very interesting characterization of the protocols as being sufficient in several different dimensions and connecting it with your idea about the set of concerns you have about the roadmap.

What are the sufficiency criteria you are looking for in the protocol? In what aspects does it need to be sufficient in the short term? Of course, it has to be safe enough, no doubt. We need sufficient crypto-economic security to back this up. Scalable enough, that's obvious; We need sufficient capacity here or in subsidiary environments, such as Layer 2 networks, to meet global demand.

And sufficient expressiveness, you know, in the applications that can be designed here. One of the big questions, as more proposals for improving the EVM emerge, is that everyone wants to modify or expand it. I always wonder: Is this enough? Does the EVM do what's necessary to be the solid base layer of the Ethereum blockchain and allow applications and layer 2s to be built with that expressiveness? That's a great question for me.

Security and scalability are more obvious, but expressiveness is something that definitely needs to be discussed. I suppose that some sufficiency criteria are specific and perhaps difficult or easy to implement. But there are things that are fundamentally more diffuse, even to conceptualize, regardless of how difficult their execution may be. It seems that expressiveness is one of those intrinsically diffuse considerations. Yes, it's a bit blurry.

Obviously, if you do something Turing complete, you say, "Okay, it's expressive enough because it can express anything." But can it express things optimally? Can it express them in a way that is demonstrably secure? Can it express things where we can apply formal verification, audits, and so on? That's less clear to me.

Right now, you ca n't do much pre-validation of the stack in the EVM pre-validation of the stack in the EVM . So you could say that if this is going to be a smart contract platform with billions of dollars at stake, we need more static analysis and stack validation. So, it seems insufficient, but one could also argue that but one could also argue that , in the end, it works. So... I guess we'll have these debates for years, rather than months.

And it may take a decade to determine what "enough" really means by certain criteria. So... without a doubt, and the criteria keep changing, right? If you had asked anyone three or four years ago , their definition of sufficiency might not have included being rich enough to run zero-knowledge tests, ZKVM, and other virtual machines. Whereas now, it seems fundamental and we should evaluate whether it is really enough for that.

I think part of this changing landscape is that, when we were talking behind the scenes, you mentioned that you were somewhat naive and that you were surprised when the merger was completed. Suddenly, you now have a whole new ecosystem of actors making withdrawals and placing bets. That corner of the ecosystem has emerged, and I suppose that's part of why the criteria keep changing, because now more people have been activated to be part of the conversation, in a sense. Yes, I'm still surprised by what gets built on this platform we work on down here, and sometimes those surprises are like, "Oh, cool," and the platform is enough. Sometimes, those surprises are more fundamental; It wasn't a surprise to everyone; some have been thinking about it for years, but it greatly changed our view on security and protocol design.

So, we need to be prepared for surprises. Speaking of surprises, I suppose there are some good ones. But what are the things you think could go wrong in the near future? Yes, good question. Important things to keep in mind.

If you go back to the essay, if you look at my recent reflections, I am deeply concerned about capture. The Ethereum protocol is not finished. I don't know if the Ethereum protocol will ever be finished. But in the meantime, at least until we reach that state, there is growing interest . I am concerned that this messy governance process to update something so incredibly valuable is conducive to capture.

If there's enough money at stake, it's something that can be manipulated for personal gain. That is something that worries me deeply. Hey. I don't know what else could go wrong. I suppose the opposite of what can go wrong is, what can people do to make things go right people do to make things go right ?

And I think you're one of the people in the ecosystem who has earned the right to give sermons. So, if you look at the L2 world and the world of app developers, app developers, what would it be, if you could give a two-minute mini-sermon, what they should be doing? Yes. We spent a lot of time—and this is part of what I was talking about at DevCon—but we spent a lot of time on the base layer making sure that this works, that it's decentralized, and that it's open and accessible. And frankly, if you look at many applications and most L2s, it's a landscape where shortcuts are taken to get to market.

You know, it's a landscape of launching poorly thought-out token models about things in order to gain liquidity and achieve a quick exit. Unfortunately, we can have a foundation as solid as we want, but if we are stacking fragile Legos on top of it, then it will all have been in vain. So I challenge app developers and app developers and , of course, layer 2 developers to get serious, because we are. I understand because we are. I understand .

I understand. It's always a balance between, you know, the operating budget. It's a balance between acquiring users and many other things. But if we are redesigning the architecture for the future, we must take application design as seriously as we take layer one design. I suppose one of the things that will happen if they follow your advice is that blockchains will be able to start reaching their potential in the world at large.

And yes, we had a brief announcement to make. Danny and I, along with others, have been working on this small project we call "summer of protocols". If you go to summerofprotocols.com, you'll see a program we're starting, as well as a pilot study. The intention is to start a broader technical conversation , beyond cryptocurrencies and perhaps even the Silicon Valley tech world, and get the whole of society to start seeing protocols as something fundamental.

Exact. So Danny, you've been focused on the merger and the core technical issues of Ethereum, and you've finally been able to take a breather after a long time and look at the rest of the world, right? What stands out to you about the rest of the world today that crypto, and Ethereum in particular, should be paying attention to? TRUE. Well, I don't know, when I go to an event like this, I look around and think, "This doesn't look like the rest of the world."

Fundamentally, the way these hackathons work, the way companies and protocols are built on top of this protocol, looks very different from big tech companies, traditional businesses, Silicon Valley, and so on. And one of the things we mentioned when talking about protocols and watching this program is the "protocol first" nature of Ethereum. If you look at Silicon Valley, protocols are usually incidental; they are just a means to an end. It's like: okay, I'm creating this way to connect my device to the TV and other things. Okay, we should probably have a protocol for people to adapt to using my product, instead of saying: let's design fundamental protocols so we can interact, coordinate, and solve problems, and then build on that.

And I think if you look at things like Ember, if you look at much of the spirit of Ethereum, a lot of it comes from putting the protocol first. That's why I challenge the rest of the world to treat protocols as first-class citizens and build layers from there. So, are there any particular examples that you think really illustrate the difference between traditional technology, where protocols are almost an afterthought or a means to an end, versus a "protocol first" approach? a "protocol first" approach? What's a good example?

Perhaps I'll ask you the question back. You've been thinking about protocols. What is the example? I have a very... I'm not a technical expert in this world, but for me it's a very simple user experience : last night in the hotel room, I used Chromecast for the first time to take my Netflix account and simply make it appear on the hotel screen.

And I was struck by how impressive it is that a large platform company like Google is able to launch this protocol and get all streaming services and hotels to subscribe to use this way of watching television, right? And I don't know what that would look like in the crypto world. What would Chromecast look like in a world where protocols come first, where protocols rule the earth? the earth? Right?

We would architect the protocol in such a way that devices would communicate with each other in an agnostic and perfect way, you know, with just the click of a button, and Google becomes peripheral. Google becomes one of the many products that are integrated into it. It becomes a much more reasonable landscape for competing ideas, because there is a common protocol on which to build. Whereas, you know, with Chromecast you're now in Google's fenced garden, where they do what they want. And what they want is for people to adopt their proprietary protocol in as many places as possible, so that users get stuck using their suite.

On the other hand, if you start with the protocol first, everything that decides to integrate into that protocol can now live, design, and compete within it. And you, as a user, can be very fluid in what you use and in the decisions you make, instead of being locked in. So, the way you describe it makes it sound like you would be very sympathetic to those who consider protocols as public goods and provide them as such, like streets or national parks. Is this how we should think of them, or...? Yes, I think so.

I mean, I think if you start with protocols, they are naturally open and public goods. If you design a product and then force a protocol into it, it's generally just a means to an end that helps make your fenced garden easier . It reminds me of the difference between a national park and a large, beautiful open-air shopping mall, with lots of gardens and landscaping, but which is fundamentally still a shopping mall, right? We have about a minute left. So, as a closing question, do you think there are fundamental differences in values ​​in the conversation about technology as it currently exists in the mainstream?

That is, Silicon Valley, venture capital and the technological conversation that takes place there, versus the technological conversation that we are trying to catalyze here with this "summer of protocols" that we are starting. But yes, in general we are starting. But yes, in general , what are the axiomatic differences you would point out? Frankly, I'm not really into those, uh , Silicon Valley conversations, so my point of view is very biased. I mean, but the, uh, collaborative approach seems to be the native form of crypto and the native form of protocols, creating like new positive-sum games through the construction of protocols and layers of these; Whereas my intuition about the other game, the other side of the coin, is that it is much more of a " winner takes all" situation at any cost .

TRUE. Well, our time is up. So, thank you very much, Danny time is up. So, thank you very much, Danny , and thank you all for listening. Thanks, guys.