The Ethereum Kernel - Martin Hansen

Transcript

Perfect. I like that animation. Hi everyone. I'm Martin Hansen. Very happy to be here. I'm part of the funding coordination team at the Ethereum Foundation. I'm the fourth talk from our team and also the last talk. So, I hope I'm I I can live up to the high standard that my my colleagues set. Today, I'm going to tell you about the Ethereum kernel. And before we get too much into that, I want to talk a little bit about what we as a team focus on at the Ethereum Foundation. We have three high-level goals.

First, we try and focus on how can we increase net new public goods funding supply into the ecosystem? Two, how can we match that funding supply and demand more efficiently? And three, how can we reduce ecosystem funding demand on on the EF? So, keep that in mind as I get started and talk to you about the kernel and why we want to figure this thing out. First off, I just want to give you a high-level description of what the kernel framework is and then we'll get much more into the details. The kernel framework identifies the critical functions ensuring the world computer's uptime, programmability, and accessibility.

We'll dive much more into it, but that gives you a a high-level idea of of what this talk is going to be about. The reason why we set out to map the kernel is that there's a mismatch between these finite runways of of DAOs, of various treasuries, of the EF, and this thousand-year horizon that we have for the Ethereum ecosystem. And in order to solve that, we need to find diversified funding sources. It's also very important that we figure out how to allocate that funding very efficiently. And the view here of the kernel is that we must prioritize the most critical functions first.

Now, we're not the first people to talk about this and to think about this. Almost 4 years ago, this guy, I think most of you know him, Joseph, uh gave a talk at the Ethereum Berlin meetup where he talked about Ethereum as a self-sufficient ecosystem. He talked about what what is the amount of money that this sort of tech ecosystem requires to keep running and how might we fund it via fees, via DAOs, and treasuries. And 4 years ago, it was very different. So, um I would say the landscape looks very different now, but the exercise um has a lot of overlaps and we learned a lot from Joseph's talk and his work back then.

Now, one thing that's very important um for us in uh at the in funding coordination and that I think most of you here probably believe in is the case for neutral funding. And when I say neutral funding, it includes public goods funding. It generally includes the types of funding that doesn't come with strings attached. And in it protects and one of the major benefits of neutral funding in our view is that it can protect you against abrupt shutdowns, which you would otherwise see from um from other funding sources where priorities might shift and suddenly the project is deprioritized or shut down.

Another thing that it enables is that it enables you to think long-term. You're not trying to optimize for the next quarter or something like that. You can You can think long-term and you can do what you think is best for the project and for the ecosystem as a whole. And this is a a key part of funding the kernel and channeling neutral funding to it is that it comes with these benefits and it basically strengthens um our ecosystem. Now, when we talk about the kernel framework and applies it to Ethereum, we look at it through a lens of a certain amount of properties that we expect Ethereum to have. If you look at the kernel of another blockchain

ecosystem, it look it can look very different because you expect different things out of it. With Ethereum, there's certain non-negotiables and properties that you want out of the system. Some of them are listed here. Um credible neutrality is is is an important one um for having a neutral base layer that you can trust. Um you want it to be permissionless access for anyone, whether it's validators, users, developers, and that they have always that they have access at any point in time.

You want the kernel to be censorship resistant. You want it to be open source and free, so that anyone can verify and anyone can read into it. You want it to protect privacy, and you want it to be secure. So, these are some of the properties that we have to keep in mind at we as we map out and design the kernel. And with these properties in mind, there's certain things that we also expect out of the kernel, so sort of more concretely. And these are both from from the past, we've seen a strong track record of 100% uptime. We've seen that Ethereum has been accessible generally by by anyone, even when there have been nation-state attacks.

It has been censorship resistant towards that. Ethereum is verifiable. It's a It's a place where you can securely store your your value and your data. It generally protects privacy and user rights. It's an ecosystem where there's no single entity that's in control. There's no one that can just shut it off. And all of that sort of keeps chucking along, and that's what we've been seeing in the in the past from Ethereum. But, there's also things we expect of the future of Ethereum. So, when we map out the kernel and when we fund the kernel, there's certain things that we expect to improve on Ethereum. One of them is scaling. When you look at Ethereum's track record, scaling has been a consistent improvement over time.

And you would expect hard forks that bring new features that allow you to do new primitives on top of Ethereum. So, all these things are expectations that sort of come downstream from the properties that we set out in the kernel framework. And an important thing to point out is that the kernel has changed over time. If you look back in time, in the past, I would argue that the the kernel itself was smaller, there was less people involved, we had less clients. There was less breaking features at at at those times and we didn't have the same hard fork cadence as we have now.

Just in 2025, we had two hard forks that brought a ton of new features and improved Ethereum significantly. And that was quite different in the past. So, we have a larger kernel today is my argument. We have accelerated development cycles, but it also requires more coordination, it requires more testing and basically becomes becomes beefier in a sense. We can't say exactly what the kernel kernel like might look like in the future but as the previous presentation explained very well, there are a lot of these end game solutions that hopefully can streamline the the Ethereum kernel and possibly reduce it in the future. It's hard to

say. It's also very important to stress that the kernel's a small part of a much larger ecosystem. The kernel sits at the core of it and there's a lot of other really important things that comes downstream of it. So, you can see that the kernel is the core, you you would have other like extended core infrastructure that's really important as well, but might not make it into to kernel per se. You have various tooling and services, and then of course you have applications as well. And the reason why, again, drawing it back to neutral funding, when you look at this this sort of onion diagram here, the further you go out, the more revenue opportunities, the more funding

sources that there are, and the more acceptable we might view those. If if the kernel if the core is captured in one way or or or another, um that actually impacts everyone in one way or another. Um whereas the further you go out, if an application decides to charge for certain features, that's okay. Um they they have different models that they can experiment with, and that's I think an important um point here as well, that we believe neutral funding should go towards the core first, and then it can go outwards from there.

So, how do we get here? As we were mapping this whole thing out, um we obviously relied a lot on inputs from various different technical domain experts. We talked to a lot of people at the EF in the in the protocol cluster, and tried to get different perspectives from different parts of the organization to get their view on like what's actually the most critical, what's actually most important. Then on top of that, we did a ton of deep deep research trying to understand these various different aspects better. Um and then we also tried to look a little bit about like how has critical Ethereum infrastructure changed over time, and what might we learn from that? How might how might that predict something about the future?

And so, next up, now, we're going to build the kernel together here, one component at a time. And it's important to say that each component of the kernel has certain function. Again, we expect certain things of them. So, together, they should hopefully live up to all the properties, all all expectations high-level that we talked about, but each of them play a role. And there's a reason why some of them are component by themselves and some of them might come separately and we'll get into that. At the heart of the kernel sits the clients, execution layer clients and consensus layer clients.

This is the largest component of the kernel. Um it's one thing that consistently came up as I was doing these talks with different experts was do you need this many clients and how many clients is is sufficient and so on. And it became very clear that client diversity at this point has become synonymous with Ethereum. If you expect um permissionless access at any time, 100% uptime, then client diversity is one way of getting there. So, that becomes a a non-negotiable.

And um we get some really, really nice properties out of that. When you have multiple clients, um you also need coordination because this requires um a ton of of overhead figuring out how to um how to ship these hard forks on at a certain cadence. Um you need to document across um in some cases hundreds of people as was just mentioned in the in the previous presentation as well. It's ton of people all around the world that are coordinating this, so you need some a coordination layer as well. You also need research because you need to figure out how to improve the kernel for the future. And I I'm splitting it up here into two, short-term and long-term research. Short-term research

focuses much more on how do we scale in the short-term? How do we harden? How do we improve the UX on Ethereum? Then you have other people, other researchers that are looking much more in like long-term. How can we figure out these end game solutions? How can we make um Ethereum post post quantum secure? How can we develop this crazy straw map road map and and how do we actually get there? Um so this this is kind of you can look at it a little bit as a funnel where ideas and research come in and um then they get prototyped and then eventually they come down to clients, get developed, and become implemented into client software.

And then of course in order to harden um Ethereum and make sure that we don't have too many bugs and we have 100% uptime, you need a layer of security specs and testing. And this layer I specifically put um by itself because it's often better addressed um overall uh across the protocol. Of course, every single client is going to look at security. Of course, they're going to do a ton of testing, but there's significant benefit it in having testing security specs done at a protocol level all across.

So that's why it's um it's it's it's a component by itself with a very specific function. Now, in order to make Ethereum programmable, we also need a language stack. We need a programming language, we need compilers, and and we need various different tooling for you to actually deploy applications on Ethereum. Because if you can't deploy programs on Ethereum, it we we kind of lose the benefit of Ethereum. Then it's a it might be a network with 100% uptime, but if you can't actually deploy applications on it, it's not as attractive.

It's very important for this language stack as well to contribute um um security as well because most assets are are basically tied much more to the language layer. And it's also very important that the language stack works in tandem with the hard fork. So that's why there is this link between the turquoise boxes and the and the dark blue boxes in a sense. Another aspect here is uh core wallet infrastructure. The average user interacts with Ethereum through a wallet. And it's very important that we have open-source standards, open-source alternatives, ways to verify that what you're doing on chain is what you expect to happen.

Um and therefore we have that as an element here in the kernel as well. Then we need to coordinate on this across the ecosystem. We need to improve the UX and make sure that Ethereum is accessible to anyone. And then lastly, have a bit of a catch-all category here. It's slightly dynamic. Um I'm calling it other critical tooling and dependencies. And that's because there are a ton of these small, small pieces here that are so, so important to Ethereum that basically all add up um to real work that has to be done in order for the chain to keep running. Um and this is something that might include source code verification, making sure that contract data, which is often stored off chain, is actually what you expect it to to be. Um

it also sometimes includes some non-Ethereum dependencies. They're libraries that we might not consider libraries, but our our infrastructure depends heavily on them. So if no one is maintaining them, it's a security risk. Um and um it it yeah, it poses a a threat to Ethereum as a whole. So that's the that's the last category. And this is basically the kernel as I've mapped it out now with these categories here. Then the next question that I asked myself was what would it take for each of these components to be functional? How many people, what sort of funding might it require for this thing to actually work?

Um and I made some assumptions here. Like I assumed that if you only have this and you you have a slightly more minimal approach to it, you would have a slower development cycle than now. Like we we are in a very good place right now. Um but if you only have the kernel, if that's all you can fund with neutral um funding sources, um then you might have slightly slower development cycle. I also assume we have zero cost basis, no org affiliations, no previous revenue, no previous tokens. We just start from zero and we try to map out like what is this thing actually going to cost. Um and then we assume that we're running a lean operation here.

We're not spending too much on lawyers and all kinds of things. So, we we have 85% of the cost going directly to compensation and a 15% overhead, which is quite in line with with various developer-heavy organizations. Um we have an a $1 million annual bug bounty program as well. And um yeah, as mentioned, here I relied a lot on input from various different technical domain experts like how many people might a client team a client team realistically need and how many how many researchers and so on. Like, it's very difficult and that's why the scope that we're talking about earlier about the different properties and what we can expect out of Ethereum is so

important in order to scope this out further. Um and I figured or I came to the number of an annual minimal neutral funding requirement of 18 million. Now, again, this is the minimal for this world computer to keep running, to keep being programmable, to keep being accessible. And um while it might perhaps sound low at this point in time, um it's really important that we find this um every year in order to make sure we have a a neutral core.

Now, it's also important to mention that the world computer keeps changing. We had I I really like the slide from the linear Ethereum website because I think it it neatly um describes how Ethereum changes and um how beautiful that can can be in a way. Um going from the proof of work era to the proof of stake era and then to this the CK era as you might say. So, it's also important to mention that the kernel changes and the analysis and the mapping that we've done here is much more looking at what might it look like today and what components do you need for it to run today.

But that might very well change and you could do this analysis on a regular basis. True decentralization requires diversified sustainable funding mechanisms. That's a very important takeaway that I want you to take away from this that we need to find diversified um funding mechanisms in order to fund the core of Ethereum. Otherwise, um we risk capture. We risk that we don't prioritize long-term of Ethereum and we're just chasing the next the next funding goal. Um so that's a very important takeaway from this presentation and something that our team is working specifically on at funding coordination.

Um I'm not going to be able to address too much of that. We don't have time for that. Um but I would say that in order to get there, get the make sure that the kernel stays funded sustainably with neutral funding, then we need to secure more of it first of all uh both sustainably and predictably and we need to find a way to allocate it um starting with the kernel. Make sure it goes to these um components. That's all I have for you today. Um please share your feedback and your thoughts with me. I I continue to try and harden the kernel. I gave a presentation about the kernel about a month ago. I got some fantastic feedback and actually made some changes to the presentation, removed some components, changed some numbers. Um so this this feedback from from the

community is is what helps improve the framework. Um and yeah, I invite any questions and otherwise just come up to me afterwards. Thank you very much.