The Ethereum Kernel

Transcript

and signal unit. Okay, >> perfect. >> Excellent. >> Okay, I think we're ready to go. Great to see so many people here. Um, I'm Martin Hansen. I work at the funding coordination team at the Ethereum Foundation and today I'm going to tell you about the Ethereum kernel. It's a project I've been working on for a couple of months and it's a work stream at our funding coordination team. Um, before we get started too much, I just want to tell tell you a little bit about our team and what we're working on. um funding coordination at the EF. We have three broad high level goals. We want to increase net new public goods funding into the ecosystem. We want to more effectively match funer supply and um and um demand more efficiently. And

lastly, we want to reduce ecosystem demand uh on EF for funding. So that's part of why this workstream came about. And you will hear a little bit more how uh the kernel workstream references some of these broader goals that we have. Now at a high level, what is the kernel? Let's get that defined first. It's a bit of a mouthful, but it's essentially the critical functions that ensures the world computers uptime, programmability, and accessibility. We'll get be getting much more into the specifics of what that means, but at a high level, you can think about the components that make sure that the the world computer is running and it's usable.

Um, we set out to map out the Ethereum kernel for a couple of reasons. One was that we think there's a huge need for more diversified funding sources um for critical infrastructure that our whole ecosystem depends on. And when you couple that with finite runways of many of these funders, whether it's Dows, whether it's u nonforprofit organizations like the EF and we have this thousand-y year horizon of building civilizational infrastructure for hundreds of years. Um there's a bit of a mismatch and um as we think about these diversified funding sources, we also need to think about where it goes. And so allocation is really really important. And our perspective here is

that as we think about allocation, we need to prioritize the most critical functions first because they sort of make out the base layer. And um related to that, we believe that there are really strong benefits to neutral funding. And when I say neutral funding, uh it can be public goods funding, but it can also be value flows that go directly to dependencies and and so on. One of the benefits is obviously that there are no strings attached the same way that we see with other types of funding sources. So you won't have to make the same kind of tradeoffs. Um another thing is that it can protect you against more abrupt shutdowns. So if you're part of a larger organization and they rep prioritize, they restructure, suddenly projects are shut down and it

can be quite critical if um that's an important component in the world computer. And lastly, it can enable you to think long term. You're not optimizing for the short term. you're not trying to um meet some target for the next quarter. You can think years ahead and try to do what's right today for for a 5year horizon, let's say. So that's why we advocate quite a lot for for neutral funding sources. Um now we're going to talk a little bit more about Ethereum at a at a high level and then we'll get into the kernel more specifically. The reason why the kernel looks different and a certain way for Ethereum is because we have high expectations of Ethereum. There's certain properties we want to see out of

Ethereum. And as such, um, it's going to look very different what the Ethereum kernel is versus some centralized database, let's say. Um, one thing that we expect out of Ethereum is 100% network uptime. That requires quite a bit to achie achieve that. Um, another thing is some of the properties of Ethereum sort of being censorship resistant, being open source, having privacy, being secure. These are properties that we all need to optimize for and we can always improve on those. And then lastly, a lot of people in the Ethereum ecosystem uh have been talking about passing the walkway test, being able to one day step away from from Ethereum and it just running and being reliable and secure for people to use.

And um, these are not easy things to build. And um therefore the kernel is going to look quite different than what we might otherwise see in in other ecosystems. Now how do we get here? How do we set up to map this? What was our methodology so to say? The key thing was that we talked to a lot of technical domain experts particularly from the Ethereum Foundation's protocol cluster across different domains. We tried to get their take on what the kernel is to them and then we tried to synthesize that and sort of give our take on it. And on top of that, we did a ton of deep research on different elements of that. Try to go down multiple different rabbit holes.

And um related to that, we tried to study the evolution of critical Ethereum infrastructure and see how it has changed over time and whether there's some patterns that we can connect and and what that might tell you about the future. And um I think this was was one interesting sort of learning point that um the kernel has definitely changed a lot over time during Ethereum's history. Um we would argue that it was much smaller earlier on. There were fewer clients. Um when you look at the there were fewer hard forks but also hard forks with less sort of breaking changes. Many clients were working for years after they actually um after they stopped maintaining them. Um and that

has changed quite a lot till today. Today we have a lot of clients. Um we have a more accelerated pro protocol development environment. Um we have a lot of big features that have landed on Ethereum and um we need far more coordination. So you see much more sort of governance um coordination work but you also see far more testing work. You have way more researchers than we used to. um and that puts us in a in a in a good place and that we can accelerate the the road map and and we can move faster. Now the big question is of course what is the kernel going to look like in the future and and what timeline do you put on that? There's a lot of research into some of these uh endgame solutions whether it's a lean ethereum

or it's the straw map it's CKVM or it's making Ethereum um postquantum secure and um this could potentially lead to a reduced kernel in the future because certain parts of the protocol might harden um but obviously that is that is a question and we will have to see how that changes over time. The kernel is the core and um it's also a much smaller part of a much bigger ecosystem. It sits at the core. It forms these critical functions, but there's a lot going around it. Of course, um there's obviously other tooling that in in during this research didn't prove to necessarily be absolutely critical for for the uptime of Ethereum. Um but still

really important and useful for um for users and for developers. And then of course there's the whole application layer where a lot of exciting things happen and um and and things are growing really really nicely. The reason why we said we sort of highlight neutral funding so much in in the beginning here and why that our talks generally center a lot about the importance of neutral funding is that when you look at the at the kernel itself at the center it's really really important that you have neutrality you have um you have uh less tradeoffs being made and less um sort of gateways at the at the very base whereas the further you go out more funding opportunities are

present to you and you won't necessarily have to make the same kind of tradeoffs that you would have at the core. So, um I think that that's why we we we keep highlighting neutral funding for the kernel as as being really important. Um what we're going to do now is we're going to build the Ethereum kernel one component at a time together. And we start with the heart of the kernel, the largest components, um, which is the clients, execution layer and consensus layer clients. In all my talks with various different domain experts, it's become quite clear to me that at this point client diversity has become quite synonymous with Ethereum and not having client diversity

essentially, it's not really the same Ethereum that we know of today. So, we do need to have some some client diversity. And of course the properties of client diversity again is fairly synonymous with Ethereum. It makes a our network far more resilient and it has so far secured unm matched uptime um and no downtime. The next thing we have is with client diversity we do need coordination. We need these clients to work and develop in tandem and be in sync. So very important to have um some individuals working on protocol coordination and um relatedly also governing this whole um upgrade processes and um and documenting how things are changing possibly even

more so in in the age of AI. Then we have research as well. Research and prototyping generally um falls outside of the client teams and that has certain benefits. Um here I think it's important to distinguish about the distinguish the importance distinguish the difference between short-term research and long-term research. When we look at short-term research, we are looking more at scaling. We looking at solving various UX uh bottlenecks. How can we harden the protocol? An example of that is um for example how we're able to increase the gas limit very significantly in the next hard fork in Amsterdam via EPBS. It's a large um

scaling improve improvement and that's one of these short-term research um focuses that is now coming into fruition. When we look at some more long-term research, we're looking at how can Ethereum be become postquantum secure, for example. How can we think more about um solutions that would likely be um long-term sustainable and viable for Ethereum and how can we already start working towards them today? And if you look at the straw map that's been issued, that's that's sort of one way to articulate it. Lean Ethereum is another way to do it. Um, another big effort here is is obviously CKVM, which probably falls somewhere a little bit more in between. Um, so yeah, research and prototyping is definitely

also a significant one. And then we have a little bit of a catch all here in the security specs and testing category. Generally functions that harden the protocol, secures the protocol. What I heard from multiple people is that generally with security, it's much more effective when it's addressed across the protocol. Of course, there's security experts within the clients as well, but you're just going to get more out of it um when you have security that's sort of running across the protocol. Specs are really important as well when you have client diversity because they provide a bit of a single source of truth to so to say and possibly even more so in the in the age of AI space specs become even more important. And lastly, you have testing. And testing

has been an effort that's just been increasing a lot over the years, especially as we doing more hard forks uh and we have even more clients. So, a very important uh function as well. Um sorry, let me just go back here. These are basically the functions that um secure Ethereum as a protocol and as a network. I would say these are the key ones. And we could stop here, but in my view, even if you have a functioning network and protocol, there are certain other functions that give us what we expect out of Ethereum.

We expect it to to be useful and to be programmable and so on. And these are some of the things that that go around the kernel here as well or basically go around the protocol but are still part of the kernel. So let's get into those. The first one we have here is indexes and explorers. These are the functions that make Ethereum legible that allows you to read the chain and interact with it. It's also really important for verification efforts and which is relevant both to the clients to developers to users and without open-source alternatives um or open source options when it comes to indexes and explorers we have quite the vulnerability here.

The next one is what makes Ethereum programmable and that's the languages and compilers that developers use to deploy applications on Ethereum. They're also really really important for security because most funds at stake in on the Ethereum protocol um are basically reliant on the language and the compiler. So very important that you have people maintaining these um and that that they also work in tandem with the with the protocol as hard forks come out and new features are um available on Ethereum.

The next one is wallet infrastructure. Wallets are how most users interact with Ethereum directly. It's how they transact. It's how they send funds and so on. And we need a lot of coordination here to make sure that the the the UX is good. UX bottlenecks and challenges are um are addressed and generally we need a lot of open source tooling as well for people to reliably be able to interact with Ethereum. So there's some some efforts as well here and then lastly this is truly a catchal category. Um this and a fairly dynamic category. There are a bunch of things that don't necessarily fall into the other categories, but are really

critical to to making Ethereum um be um be online but also be usable, be programmable and so on. And this is a bit of a category where you might allocate some resources um to ensure that important libraries and other dependencies are updated, are maintained because otherwise they can really slow down other efforts or make Ethereum less secure. So this is generally the key functions that we see inside the kernel. There's some that fall that possibly fall outside or maybe they fall right on the border. Um but that's sort of that's what um the research project sort of identified.

Now the next thing we wanted to do is try to estimate what the funding requirement of the kernel might look like today. We have some assumptions for that. Of course, if you only have the kernel, um, which are these functions that I just showed you here, um, where we try to to look at each of these functions, how many people might you minimally need to staff these, um, to a state where they are they're functioning, but not necessarily as much as we have today. We in a great state today. We have an abundance of clients and um, and many different teams across the protocol. Um but um it's not necessar necessary necessarily that every single one of them are funded

by neutral funding sources. What our case here is that you might need a a core in the middle that's mostly reliant on neutral funding and then you can ideally have other uh functions as well within the kernel that are more funded by corporate sponsors or commercial entities. That's a that's a sort of like a trade-off we're willing to make here. Um, so if you only had the kernel only funded by neutral funding sources, you would definitely have a slower development cycle than today. So the number that I'm going to show you is definitely less than what it is today. Um, the next thing is that we looked at was we just assume a zero cost basis and no or affiliations. Assume no previous funding, no previous revenue. Just start from from from zero. It could be one

organization, it could be many. We assume 85% of cost to be compensation and 15% overhead fairly lean organization and we have an um a $1 million annual bug bounty program. Um and um yeah lastly as I mentioned we try to get just general output from these technical experts on like how many people does each client actually need and how many people uh does um does does do we need for security and specs and testing and so on. And then we tried based on that to to to derive a number.

And um the number that we got to is um $16 million on an annual basis. And again this is based on what we think the kernel looks like today and what we would ideally need in neutral funding today. um it uh we much more is spent on these functions right now because some clients for example are sponsored by by corporates or or um L2s even and um uh and and and that's okay as long as we have an abundance which which we do today. It's also really important to say that um the world computer has always been evolving. That's like a constant thing and the kernel will too as Ethereum changes. It's um as I mentioned

a little bit earlier, maybe it will reduce over time. Maybe we'll it will increase a bit in the in the short term and that's why this exercise was now done here in the beginning of 2026. It would very likely be different if you did it a few years from now. So you can see it more as a as a checkpoint where you're checking in depending on how the protocol changes and what the critical functions then are. Now it's really really important for us that if we want to have true decentralization then we need to have diversified sustainable funding mechanisms. It's something that funding coordination is actively working on. I don't have time to go too much into detail and what that look like. I think some of the primary goals is that we

need to generally secure more neutral funding but we need to do it in more sustainable and predictable ways that um teams can can work with. And our view is also that we need to allocate it starting with the kernel. So first funding these uh critical functions and then we can we can expand outward. Um and we have several different working streams in the funding coordination team addressing these topics. Um and I want to give a quick shout out to um to an event where we will have a lot of presence later this year and we will generally be out there speaking about our working streams a lot but in particular at Devcon in India in November we I will give an updated um talk about the kernel and some related

uh work streams. several of our team members will be there talking about um how we solve this sort of funding crunch and try to create these more sustainable and predictable uh funding flows to to critical infrastructure in Ethereum. So wanted to to highlight that as as a kind of like coming soon next step here. Um and then lastly I just want to say that I'm very open to any kind of feedback that you might have about this uh this project about the kernel. Um did I miss something? uh is should something go out of the kernel in your view or or should we add something else? Um yeah, so that's basically it. Thank you very much.

Do we have time for questions? Okay, >> I think we have time for exactly one question. >> One question. Okay, >> sorry guys. We can take it afterwards outside. I mean, >> yeah, you can also just come to me. I I put my email and my Farcaster and Twitter handle here. You can also ask for my signal. Okay, we got one question. >> Um, great presentation. My question is, how do you think about the tension between wanting to pass the walk away test and then still needing dependencies to fund?

>> Yeah, I think it's it's a challenge that we'll sort of have to face down the road. um oificate we have been not been very near fossification so far. In fact, we've actually seen a a growing funding need over time and an expansion of of of teams that need u neutral funding. Um, so I think the one thing I do rely on is that I think we're seeing more and more of these ideas of like endgame solutions and these kind of like longer road maps and I think if we generally have consensus around the some of these things being the longer term solution and we work towards that then hopefully um hopefully we generally are are more okay with um with being able to pass the

walk away test while still acknowledging that there'll be certain dependencies that we ideally really should fund to secure the the protocol further for the future. Thanks. Thank you very much.