Funding the Ethereum Kernel: What Qualifies, What It Costs, What Goes First

Transcript

Thank you, York. Wow, what an intro. Yeah, that is that is a true fun fact right there. Okay, I feel like uh York already covered most of this slide. Um, I'm Martin Hansen. I'm part of the funding coordination team at the Ethereum Foundation and I'm here to talk about the Ethereum kernel today. How many here recognize these green benches behind me right now? Put your hand up. Okay. Okay, I see some hands. How many people here were at Defcon in Bonosirus last year?

I saw even more hands. Okay, good. So, some people didn't recognize the benches. The reason I put up this um photo right here is that these green ventures were where we had a conversation one year ago about what the critical infrastructure on Ethereum is that everything runs on. What is the core of it? How can we identify it? How can we try to estimate what that cost to fund? like what's sort of like the minimum amount that needs to be secured in neutral funding in order for this to to stay neutral and to stay running and operating.

So that's where it started and that became the start of the project around the Ethereum kernel. Very shortly, Ethereum runs on work that most people never see. Runs in the background and it's great. The Ethereum kernel in and of itself is the work that we all depend on for Ethereum to stay live, to stay correct, and to be usable without permission. That's obviously a high level definition, and we'll get much more into the details, but one thing that I want to point out first is neutral funding and the importance of it. And when I say neutral funding, you can think of public goods funding. You

can generally think of um funding sources that don't have come with strings attached or very very limited strings attached. One of the benefits of neutral funding is that it generally protects against abrupt shutdowns of projects. You can imagine a very critical project uh for Ethereum is running. The organization that hosts it decides to change their priorities. Uh maybe they run out of funding one way or another and suddenly this project is no longer maintained. It's a very negative thing for Ethereum.

Another thing that it enables is long-term work and a long-term focus. Um, when you have neutral funding, you don't have the same sort of pressure to chase the next quarter, the next milestone, and so on. It protects against some of these things. And furthermore, I want to point a direction of this little diagram over here. What I'm trying to tell with that is that at the very core of Ethereum, at the very core critical infrastructure that everything depends on, you have fewer available funding sources that don't come with significant compromises, right? So the further you go out, the more okay you are with making certain compromises. You could imagine an app on Ethereum

that can fairly easily have um a commercial model that funds it and that is sustainable. Maybe it even has an open-source version of the product and perhaps a premium version of the product with more features but that they charge for. That's completely fine. In fact, that's a great model. But at the very core, if you want to make sure that that is neutral, that it provides permissionless access, then there needs to be some neutral funding for the for it. Next thing, something that we would like to see more of in the Ethereum space is basically broaden the ba broadening the base of support. What we've seen till now is that EF and other public goods funders have helped bootstrap and fund most of the critical infrastructure that

Ethereum depends on. And what we'd love to see in the future is that we can broaden that base more, make it more diversified, and see more organizations that depend on Ethereum also help fund the critical infrastructure that helps it run. Okay, now we'll zoom out a little bit. We'll put ourselves into the mindset of the Ethereum kernel here. If you imagine, we're in a deep, deep, deep bare market. It's been several years. Prices are down.

funding is very very scarce and you have to prioritize you have to identify with this limited amount of funding what do you fund first what is most critical in order for Ethereum's properties to stay the way that you want them to and that the way that we're used to an important part of the kernel is also where do you draw the line what is kernel and what is go sort of on top of kernel and that's what I'm trying to outline here the kernel is generally what keeps Ethereum working, keeps it safe, the chain is running and live through every upgrade. It's secure and anyone can use it without permission.

Whether you're a builder deploying apps or whether you're using transacting on Ethereum, all that creates the base that things can be built on top of. And the other box I'm trying to show over here is what sort of goes on top of the kernel. And you can call it adding capability. I think one of the best examples of it is the straw map which is this amazing um road map of um and research that will go into Ethereum over the coming years. Um could be faster finality could be CKVM and real-time proving could be higher throughput and more scaling. All these things are coming um to Ethereum over time.

the kernel itself concerns it mo itself much more with with what is the base and how do we make sure that stays secure and safe and keeps running so that we can add capability over time. So I think that's an important line to draw as well as we talk about the kernel. Okay, in this talk I'm going to have three parts. First we're going to map the kernel together. We're going to talk about what qualifies what does it take to qualify for the kernel and what sort of functions do we have in the Ethereum kernel. Second, we're going to try and estimate at a very minimum what would it cost for these functions to actually work. And thirdly, we're going to talk about how could you fund it? What would you fund first and what does that

priority order look like? In general, when we have to qualify uh whether a function makes it into the kernel or not, we have two tests. First, is this critical? If this function is not working, if it's no longer funded or maintained, would it threaten Ethereum's livveness, its correctness, or its permissionless access? Well, in that case, it's definitely critical. The second test we have is what's the need for crit for neutral funding for this um for this function. I think two risks that we can highlight here is if there was no neutral funding for this function would there be a high risk of this work getting neglected because a

commercial fund a commercial party doesn't have a reason to fund it really they're not incentivized to do so. And then on the other hand, could we be could we be at risk of this function potentially being captured by a party that wants to get leverage over the network and perhaps gatekeep certain things or try to commercialize certain things. Um yeah, so that's the second test. What we're looking for here is functions that fulfill both. They're critical for Ethereum and they have a high need of neutral funding and then they make it in there. Okay, based on that, I have a little test for you here as well. We talked a little bit about the straw map. We talked a little bit about the two tests just now. So, postquantum research, if you think it

goes into the kernel, please put your hand up. Okay. And if you think it's out of the kernel, please put your hand up. Okay. I see. Um, I think most people uh got it right. And um the right answer here would be that it goes into the kernel and I know it was a little bit of a trick question because we talked about the straw map earlier where PQ is a huge part of it. The rational for why something like postquantum research would be part of the kernel is that the threat of um quantum computers to Ethereum is either existential or extremely costly if you have to migrate

and so on. As such, it's important that this work is done sooner, even though uh it could be a long-term problem. So, it's definitely critical. On the second test, um does it need neutral funding? My argument would be yes. One, it enables long-term work as we talked about before, and two, it can protect against abrupt shutdowns. You could imagine that there's an entity that is doing most of the critical postquantum research for Ethereum and suddenly that entity pivots or changes uh focus and postquantum research is no longer on Ethereum is no longer a big focus of theirs and suddenly you stand in a difficult situation. All right, so that was a little test there. Okay, here is

the kernel at a glance, right? The way that we mapped this was we talked to a bunch of experts, 25 plus experts both at the EF and outside the EF 40 50 conversations over time. We tried to ask them what does the kernel look like to you? Then we took all that those uh inputs and we tried to synthesize it and create a version of the kernel that we again went out and tried to check with them does this seem reasonable? Is something missing? And and so on. And one interesting finding was that generally on the protocol layer which is sort of what keeps the gene running keeps it correct some of these functions are fairly well established. It's we have

fairly reasonable ways to estimate what would happen if a function is no longer there and so on. On the access layer however the access layer is basically what lets people use Ethereum without a trusted intermediary. this permissionless access as we've talked about I would say it's slightly more nent a little bit less established than the protocol layer it there's still things that we're building and there's still things that are improving on the access layer so that was definitely the part that was harder to define all right let's go through the functions I'll run through these and of course if anyone has questions afterwards uh either um go through Mircat or um come up to me first off I would say we have the heart of the kernel the clients Um

that's the software that that Ethereum runs on. Basically, they're also of course a huge part in the upgrades that Ethereum goes through EL and CL clients. Next up, we have protocol specs as a critical function as well. There are the specifications that we're testing against and similarly with uh testing. Well, these are doing crossclient testing. They're making sure that um bugs are being fixed and that client pairs are working all the cross. And then we have protocol security which are monitoring and making sure that there's no security holes and so on. Relatedly we have a bug bounty program um that rewards people from finding protocol vulnerabilities. Um we have what I call resilience research which is a category

of research on the primitives that Ethereum depends on. It could be postquantum like we talked about before. It could be cryptography research. It could perhaps even be people that are researching how Ethereum stays censorship resistant. And then lastly, we have critical dependencies. These are what other parts of the kernel, for example, clients depend on. Um, they could be outside Ethereum, they could be inside Ethereum. Um, but if some of these things break or no longer maintained, it's very negative for other functions inside the kernel.

All right, we'll move to the access layer. First off, we have the language stack, programming language, compilers, and other tooling that you need to write smart contracts. The next one is trustless access. This ensures that you always have an open envir verifiable path for reading the chain, transacting, and deploying. So, it refers both to builders that are building on Ethereum, but also to users that are transacting on Ethereum, making sure that there's always some open source alternatives that you can use. And lastly, we have the category called risk transparency, which is independent verification of security claims that both apps and wallets make and that are published for everyone. So they go into the code and

they try they explain what is it that you're trusting here, whether it's an L2, an app or a a wallet. Okay. So now you have an idea of what the kernel looks like. Here a couple of example of what I would say is out at least for now. and and why. One example would be CKVM work. I think most people in this room would have high expectation that CKV EVM is going to be a huge part of the Ethereum protocol in the future. But right now, it fails the first test, right? Because if CKVM works stopped right now, it wouldn't threaten the network. The network wouldn't stop per se. So, it might be out right now and maybe will be part of the kernel in the

future. The next one we have is staking providers. Obviously, they are critical. They're really important for securing the network, but they earn validator rewards and fees, and it gives them a a business case, which means that they fail the second test. They don't really have such a high need for neutral funding. All right. Um, next up, next section here is going to be how we priced it and what some of the assumptions were. I think first off it's very important to know that the perspective we had here was that how can we try to create a floor like estimate what the absolute minimum neutral funding floor would be for these functions to keep running. Part of the way that we did that was try to look at

how many people would these different functions require in order to run. And um we try to use uh compensation benchmarks from the protocol guild compensation data which is widely used for for core devs compensation. Um and then we try to price it from scratch, right? So we don't assume any current organizations. We don't assume any existing funding. We're just trying to assume what would a thing what would it take to run this thing. And of course, as we're doing this research, we were mostly thinking in terms of full-time roles and um things are changing very quickly. Maybe um AI tokens would be their own budget line in some way or

another. Um that's something that that we could speculate on, but for now, we're we're looking mostly into FTEES. The estimate that we came to was 14.7 million a year again as a minimum neutral funding floor in order for these functions to act to just run and work at a very minimum. Um the idea would be to review this every six months right because Ethereum changes that means the the kernel changes and this number moves as a result. So might go up it might go down. It's also worth mentioning that this is not some sort of budget, right?

It's an estimate of what's required at a very minimum and it's definitely not what's being spent today, which is higher. All right. Now, we're going to talk about funding and how you could fund the kernel. Here we are introducing a waterfall funding mechanism. The idea here is that um different functions, different components are inside different buckets and as funding comes in a body bucket gets filled, funding gets dispersed and then we go to the next one. The reason why this is reasonable in our minds is that the alternative is that funding comes in and you spread it across all the functions of the kernel. The risk you run there is

that every function gets a portion of funding and if that's the case then basically every function might not work because everyone gets less than the minimum floor. So instead you can have this funding order which also gives more predictability especially to the ones that are that are more important more critical for the network which again also helps with retention. Lastly, um when you have funders that are able to see what their funding provides, well, then you create more transparency. You make it more legible where their their funding goes. And we believe this can unlock more funding as

well. The order itself looks something like this. You have the first category which I call run here. It's what enables basic that the chain runs and does what the spec says and it's at a very minimum like we can keep this going and um it includes something like clients protocol security and so on. So at a very minimum we can um we can run this thing. The next bucket that I have here I call it last. We can keep this going for an extended period of time. We can we can we can sort of weather the storm but it's it's still going to be a little bit tough. And then the third one that I have here is reach. And this is basically what enables u much more permissionless access. Let people know

what they are trusting and and so on. And part of the rationale for having this sort of funding order is that even though everything in the kernel is critical and everything needs neutral funding, there can still be a priority order in it. Right? If we believe that the Ethereum network's livveness or its correctness is challenged, well then priority needs to go there, right? Because network needs to run in order for people to use it. So there still is some sort of priority order and that's what we're trying to map out with this type of funding mechanism here.

All right. So what we figured out tonight till now is what qualifies. We've mapped out these different functions. We've talked about the different tests, criticality, and a need for neutral funding. We've tried to estimate what it might cost with 14.7 million as a floor. And we've tried to make a priority order in how you could fund it. Some of the open questions that we are working hard on um determining right now is that within a function, there needs to be some criteria for what a project would need to live up to in order to to basically qualify to be considered part of the kernel. So that's something we're working hard on. We also want to have wider input and we have several initiatives in the plans for how

to do so. Um we want the community to chime in and get their give their perspective on on what the kernel looks like to them and what might be wrong, what might be be right with it. And as I mentioned a little bit earlier, we would do regular reviews every six months. Look at how has the kernel changed. Talk to some of these people again, put it out for review and um and make the changes. I want to thank you so much for coming here to the talk at DevCon. It's an honor to be here. I expect there'll be a blog post about the Ethereum kernel on the EF blog in next few months. So, I urge you to check that out and um I have my email up here as well in case you

have any questions. Otherwise, of course, just approach me right now after the talk or ask a question on on Mircat. Thank you very much. >> Wonderful. Wonderful. Thank you very much for this insightful talk. Give it up for Martin. One other round of applause. Thank you. There are a couple of questions. So, um, let's take the second one. Someone asked, why not take 0.42% from each block reward into an R&D dow and fund everything from there?

That's not it hasn't been a big part of my research because um what that question is about is how how does the funds come into the kernel which uh I would say comes secondary. The main priority here has been to map out what the kernel looks like, what it takes to um how much it might cost to fund it um and the the order in which you could fund it. Right? There's other research being done in how you fund it. where does the neutral funding comes from? So I would I would default to others who have uh who have researched that more.

Okay, thank you. Another question has been upvoted. Someone after the voting of hands probably asks, I understand why PQ research fulfills the first criterion, but for the second, don't you think other entities would be willing to provide neutral funding for something so critical to security? I would hope so. I would hope so. The question is whether whether you're willing to depend on that and whether you have um funders that or entities that you think um are willing to fund it, are willing to have the long-term focus and to are willing to stick with it. As I mentioned before, I think one of the risks is that if the entities changes the focus, pivots to

something else, well, what happens to that research and is anyone able to take over for something that's so critical for Ethereum? So, I think it's a matter of risk perhaps. How willing are you to um to let other ent entities uh run that and um and yeah, can you depend on that? Thank you for that question and for the answer. So another one is neutral funding sufficient to prevent uh recipients independently pivoting to what they think is the funers's actual interest. That's a great question. Um, one one thing that I wanted to point out earlier with this slide about broadening

the the base of support is that um the same way that you want to have um well something like client diversity and having um having a broad network of of functions that you depend on, you also want to have diversity in your funders and you don't you don't want to depend and have concentration in your funders. Right? So I would answer the question by saying that ideally we have a broad base of funders and in that scenario um the recipients aren't necessarily thinking so much about what the funders actual interests are. Um they're hopefully just doing their thing and a broad set of funders are are happy with it or can of course give feedback and and um let

their voices be known but they it's not that one fun necessarily um controls it. Thank you for that answer and I'd hope that answer question as well. So if you have any more questions that go in more detail, you can ask those afterwards. Let's move on to the next question. 14.7 million is way more than the F spends on grants nowadays. Protocol guild has less money vesting in shitcoins for the next two years. Are we doomed? >> I wouldn't say we're doomed. Um definitely not. I I mean I think the question um doesn't necessarily say that we are doomed. Um but um again it concerns more with where the funding comes from. As I

mentioned this is not a budget. It's not what's being spent today. I think the number that's being spent today is is much higher. Um and it it means I guess we are in an in an okay place so to say. Um but I I mean the hope is obviously that you can make this critical infrastructure more legible and funders will understand that if these things are not funding that it's critical for Ethereum and if you can help people have insight into that then I think we have a better chance of making sure it's funded. >> Thank you. We don't have the so much time anymore but there's one question that has just been upvoted again and again. So how can academics contribute to the goals of the kernel project?

Um we as I mentioned before we want to do much wider input and engage the community more. So I would um encourage anyone from the academic world to um engage there. Um again follow the EF blog where more will come out or uh or contact me but we would love to to work even closer with the academic world and we generally want