New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Anders Holmbjerg Kristiansen - Future of Ethereum

ETHCluj MeetupSun, Nov 9, 2025, 12:00 AM

In this talk Anders Holmbjerg Kristiansen covers some of the key challenges the protocol faces today - scalability, fragmentation and isolated L2s. What are we planning to do in the near term to fix this, and looking ahead, exploring how we can fix many limitations of current rollup design, and in the long term, how enshrining a zkEVM into L1 could unlock massive gains in scalability, composability, and fix the vast majority of bad UX we have today — while staying true to Ethereum’s decentralized ethos.

Transcript

All right. So, I'm Anusk Jensen. I uh work for Nethermind Core. I'm here to talk a bit about uh the future of Ethereum. So um I think uh there's a lot of complaints, reasonable complaints and we have a pretty big problem in general uh from the foundation point of view and us as protocol developers that we suck at marketing and uh we are very bad actually at telling people um letting people know what we're doing, what is coming And actually we are listening to community.

Uh we know there are issues and we are working on them. So uh I think the number one one uh people always complain about is gas prices scaling. It's slow uh too expensive. Um and we have for a long time been really uh sluggish on that part and focused maybe a bit too much on L2s. Um but we are turning that around now and I will get back to that in just a moment.

Um then we have the rollups. So we have the rollup ccentric uh road map and um that that's the primary way if we want to scale Ethereum. However, roll-ups do have some issues. Uh so right now we have basically all these isolated islands of different rollups that find it really hard to actually communicate with each other. uh which creates a lots of um uh liquidity fragmentation uh capital inefficiency because it's difficult to move across these layers.

Um and then there's also a problem inherent problem in in rollups today that um it's basically impossible to create a like decentralized rollup in that um any rollup inherently depends on uh something uh we call a security council for uh upgrades. Um and basically the problem is that a rollup typically tries to be EVM compatible. Um but the EVM continually evolves over time. That means the rollup also has to evolve. But who gets to say when the rollup upgrades and that's why we have security councils so you can upgrade the rollup and uh move forward and so on.

Um and then of course alo also the the price. So uh price action has been pretty bad um this cycle. Uh but I'm sure at the end of this presentation uh Ethereum is going to pump and Salana is going to dump. Okay. So, like I said, um we we suck at marketing and um Justin Drake, he's a great guy.

He's a phenomenal researcher. Uh but his marketing skills could be polished a bit. So, you probably seen this quite a bit. um this messaging that we have uh basically the for uh quite a few years now we've been saying L1 not for users that's for institutions and rich people um this is a terrible message uh we realize that uh and uh quite recently uh we have been pivoting and now we are focusing back on the L1 and actually we want to scale now uh and be uh commit um um be committed to it uh and actually do something about it. Um but first of all I just want to touch briefly on why is it that uh it's so hard to scale.

So you probably familiar with the trilmmer that we have the triangle uh with the axis of scalability security and decentralization and you can generally optimize for two of them at the cost of the other. So Ethereum uh exists at the um security decentralization point and sacrificing scalability and we do that uh because we value decentralization and security higher than scalability. So the problem for us is how do we then scale without sacrificing uh too much of the other twos. Um in Ethereum we are dealing with some different uh bottlenecks. Um so uh there are different reasons uh why it's difficult to uh to scale.

Um so one of the things about Ethereum is that we want to like Peter was uh talking about we basically want we would like Ethereum to run on a toaster. Uh that's not not always possible but um at least idealistically uh that's what we would like. Um but in order to achieve that we cannot allow for example that um the storage requirement for a node grows too big or too fast. Um and that's one of the uh the the bottlenecks that we deal with. There's also uh just compute uh how much uh CPU a node uh has to take and thus bandwidth and so on.

But lowhanging fruit uh for us for quite a while um has been the storage. So right now an in know it takes up about one and a half terabytes um of storage and we have always for a very very long time at least had this idea that we like nodes to remain below the the two terabytes because generally speaking when you buy storage medium it's comes in uh 1 TB, 2 TB, 4 TB. So there's like a jump in in hardware requirements if you go over this uh two terabyte limit. Um and after a long time and probably too long time we have finally committed uh to actually getting rid of a lot of what we call historical data. So this data is basically data that a node doesn't need.

um there's no point for a node to have this data other than the historical um purposes of being able to uh basically replay the whole chain from Genesis. So um a note runs perfectly fine without the data. Um it doesn't need it at all. But there's there's also this um you can say Um it's kind of a nice uh value or uh feature that you are able to replay the entire blockchain from Genesis all the way to current state. Um and for that you need the historical data.

So it's not that the historical data is not important, it's just that uh we don't need to store it or at least it's not an optimal solution to store the historical data on a node. So uh basically the solution that we've been working on for some some time now it's called the portal network. Uh but then um Thomas my former CEO he kind of threw a a a wrench um in the in the wheel and um actually the portal team got axed. They were all fired. Um, so right now the um we we uh we kind of have to figure out uh a way to make portal still work uh and get rid of this historical data but we are committed to it and we are going to do it.

So uh this graph is basically just displaying um how much uh storage node takes today. So um today it's a what about 1 1.5 but if you take away all the historical state or historical data we're going to save up to around terabytes. So that means a node goes from 1.5 to uh 512 GB approximately.

Uh that's really good um because that actually gives us plenty of room um to then turn up the gas because one of the issues with turning up the gas is that the state size and the storage requirements is going to uh grow faster basically. Um so one of the initiatives is get rid of the historical state. Um and then we have a bunch of uh EIPs coming which uh optimizes the L1 gas which again enable us to turn up the gas even more. And that means that we uh we already turned up from 30 to 36 and by end of year we hope to have uh it hit 100 million uh gas. So that's like a 3x increase performance just on the L1.

Um and then by 27 we hope to have uh increased the L1 gas by a 10x but that will require that we actually implement uh all these initiatives. Um it's a bit technical but basically um all these EIPs are uh there to uh optimize the performance on on the L1 and without increasing uh hardware requirements um we can actually uh yeah increase gas up to uh 10x um and it's reasonably low hanging fruit. um we're pretty confident in it. Uh and most importantly, we are committed to it. It's just that we are we not so good at actually telling people uh that this is what we're doing.

Um but it is coming. Uh we are committed. So I think it's pretty good already. I mean it's end of year 3x that's pretty good, right? 3x scaling.

Come on. No. Um, all right. So that's CL1. So what about these roll-ups then?

Um, so basically the idea is we make them based and we make them native. Okay. So the um right now we have this problem with the rollups being their own central uh isolated islands. They cannot uh communicate with each other. They cannot compose.

uh you cannot make um cross rollup transactions. Um so what's the solution? So our solution or what we propose is basically we make them based. What this means is that instead of uh having centralized sequences which is how most rollups basically work today where you have a central server picking up all the transactions sequencing uh sequencing them uh and then posting uh the block. uh instead we're going to sequence these blocks from the L1 and if a rollup is based it sequences on the L1 and by having this shared sequence um um layer all the base rollups are then able to compose with each other um creating cross rollup transactions uh and eliminating this isolation that we're currently facing uh in the in the rollup ecosystem and then what about native then so I was talking about this problem with the um security councils and all this um added infrastructure that basically roll up needs today um primarily because a rollup wants to be EVM compatible or most rollups do but EVM evolves over time.

So if it evolves over time uh then you need to upgrade. So what's the idea behind native? Well, basically we want to make it possible for a rollup to kind of um um basically we are exposing the EVM to the outside. So a rollup is able to execute its transactions using the actual EVM not just a um um a uh like a virtual one at the so um uh basically all rollups today they have a version of the EVM that they made themselves but the idea here is we are exposing the actual EVM to the rollup itself and therefore eliminating the need to roll your own EVM. Um you just use the layer 1 EVM instead.

So um this has uh quite a few benefits. You get rid of all this uh trusted infrastructure. Uh you no longer need it is uh way cheaper actually because now you don't have to roll your own EVM. Um, also there's potential for a lot of bugs when you roll your own EVM. Uh, one example was optimism had a bug that basically allowed for infinite uh printing of tokens and anyone could do that.

Um, and that was caught very shortly before uh before before they went live. Um, so it has multiple benefits. Um and um so uh yeah basically uh what we want to achieve by this is we uh we remove all the trust elements. We uh make uh roll-ups composable uh using the the layer one. Uh we make it much more secure uh and therefore kind of fulfilling the original promise of rollups which was that they were supposed to inherit the security of the L1 and you could say today that's might not entirely be true.

uh but with these initiatives uh we are definitely uh on the right way. All right. And then I also want to talk about a little bit of about a thing that happened uh quite recently. So um we mentioned CK technology before. So just a a briefer um CK uh basically is a way that you can verify um a piece of uh calculation um uh in uh in constant time u and without knowing all the uh inputs.

Um so you can do a calculation uh it doesn't actually matter how big the calculation is then you um compute a proof and this proof can be verified in constant time and this is quite important because it means that if you separate compute from uh validation time u you can basically put as much compute in as as you And what happened quite recently is that um this company called succinct was able to uh do realtime proving of a ethereum block meaning that they could prove a block using CK in less than 12 seconds. That's very important that it's less than 12 seconds because it unlocks something uh very very very significant. Um because then you can prove a Ethereum block in real time. Um meaning that you get something uh you get basically you get the possibility of real-time settlement. Um you get what we call um synchronous composibility.

uh meaning that now you can actually uh real time settle across rollups any transactions. Um so you can make these super transactions that are able to for example provide liquidity um from optimism to uh CK sync or whatever uh because there was some arbitrage um uh inefficiency on unis swap or whatever. um you can uh bridge tokens uh and so on and so forth and you can do this all in a single block because of real-time proving. So if you are in a stage like that that basically means that the chain chain abstraction that we've been talking about for a while um actually becomes a reality. So you know this very annoying thing in metam mask when you click the drop down and then you go from mainet to optimism and see sync and some strange thing maybe you added at some point and you don't really know what's going on or and then suddenly you transferred tokens on um uh optimism instead of on mainet maybe you're not even aware of it and basically if we get to this stage um we get to proper chain abstraction world where we no longer have to have this drop down and all of this stuff can basically rollups uh mainet becomes the same thing.

It's just a technical detail that can be abstracted away in your wallets. Uh you don't have to care about it any longer. Um you can just have searchers who um searches for the most optimal path for most optimal uh use of your transaction, which network to use and so on. Um and I had a bit of a fun with an AI making this uh video here. Um so I know it's a bit uh weird concept CK stuff and real time proving um it's not so uh easy for nontechnical people to understand but basically the idea is you have uh this uh CK prover who runs on some quite sophisticated hardware able to take all this um transactions computer proof posted in a block uh distributed across the network just as you would you would normally uh the proof gets validated um and the validators can can validate the the proof in in constant time.

So it doesn't matter how how much um this prover actually computed. He can prove uh or he could have computed um 10 gig gas or a thousand gig gas whatever it doesn't really matter. Um so that means that in the future um we are going to get end of year 3x L1 uh we're going to get the Pas as well boosting blobs capacity. Um and my prediction is that by 26 27 uh we're going to probably going to make it up to uh 300 million gas. We're going to see the first native rollups.

uh CK rollups will also uh start real improving and by 28 um we might start seeing some um native uh CK uh uh rollups implemented on um on L1 and being able to to have some pretty uh significant TPS Um and also um at that point uh chain abstraction can become a real thing. So all these uh native uh CKVMs using real time proving uh basically they can um use chain abstraction in a way where you no longer care which roll up you're on. Um and then in the far future when the L1 itself becomes a uh CKVM uh basically we just make the uh L1 uh a CK EVM uh using the exact same principles uh and at that point um yeah the sky is the limit. All right thank you very much.

Thank you. Thank you so much for that. We have [Applause] we have quite a few questions. Thank you so much for all the insightful question insightful questions. Can we try to answer them as succinctly as possible so we can try to go through as many as we can?

Um can you please scroll up? Yeah. Uh why is Ethereum Foundation optimizing for one gig gas one that uh eliminates solar stakers and make O2 obsolete?

Uh no. So um what I said was we were aiming for 100 million gas. Uh so that's only a free 3x end of year. Uh giga gas that's that's that's way way out in the future. Um we probably need something like CKVM for for that.

Um but uh end of year 100 million gas this is possible because we're going to drop all this uh history. So that frees up all this storage for us. And then um in Fusaka it's not really decided yet. Um but we have these initiatives again that optimizes the L1 and we are ensuring that we are not compromising decentralization or solar stickers at all. So the node software or the node hardware that runs today will work exactly the same.

Um it's all happening because we make these uh optimizations and because we are getting rid of this historical data uh that uh we no longer need basically.

Thanks. If we enshrine a native ZKVM at A1, does it mean the other architecture become obsolete or secondhand eventually? No, because uh it's still very valuable for a rollup to be able to um basically create their own um uh blockchain. So, it's their own little network. They can set the parameters the way they want.

um they can do uh CKVM that with uh way larger scale or with special um like they they can uh do like uh they can decide that on on their network you can you will pay gas with uh their native token or uh whatever. there's going to be a lot of value in like being able to decide and design your own network and your own network or rollup the way you want it. Um, so there will be plenty of of space for L2s and rollups uh even in the event of the L1 becoming CK EVM.

What does Ethereum need for quantum resistance?

So that's a good question. Um, that's also something we're working on. Um, we're not really sure yet, but there's a lot of research going into this. I mean, we are we are aware of it. Uh, we are working on it, but at some point we're going to have to basically hard fork and then update our signature schemes.

Um, exactly how that will look and how that will work is to be determined. Um, but we are working on it.

Maintaining a client team is expensive. What are some of the suitable models for EL and CL?

Um, not sure I get that.

What are some of the sustained models

suitable model for EL?

Okay. Right. Yeah.

I think it might be beneficial to explain what EL's are and CL's. I I personally don't know.

Yeah. So that's short for execution layer and consensus layer. So in in Ethereum we have uh we separated after the merge the execution and consensus layer. So in Ethereum we operate with actually two clients and in order to operate node you need those two clients running um and the question is getting at that it's um coming back to uh this uh basically Ethereum is like a public good and how in the world are you going to um actually fund a public good that um anybody can use And um there's no like uh there's no uh I mean h how are you going to sell a Ethereum client to to someone? It's um um it's a b it's basically just a public good, right?

So we have the E um or EF who has been funding um Ethereum development uh since of course since he started the chain. Um and they funded Go Ethereum the original uh client and they're also funding u basically giving grants out to uh all the client teams today but is it a sustainable model? Uh maybe not. Um I there was actually a huge amount of controversy uh with with GE because EF wanted to actually take uh GU out of the EF um and make them a separate entity. So, uh, EF could be more, uh, credibly neutral and not have like this internal, uh, client team that sort of has like a, you know, uh, first, um, um, first citizen status, uh, in the Ethereum community.

Um, yeah, I'm I'm not not sure I have a a good answer to what a sustainable model is. Um but what Nethermine is doing is um they they are getting revenue streams from uh other sources uh because they have to and basically all the client teams uh have to do that uh in order to fund the development uh and I'm not sure how else to do it.

Thank you. Thank you for that. We have two more questions in three more minutes. So L2 interop is a big problem in the Ethereum space from protocol level. What are some of the things that core developers can do?

Right. Um so like I was mentioning uh we have these uh based rollups which is uh at least an uh a way to uh better compose amongst the L2s uh which can be done right now. Now base rollups have their own problems and issues. Um so it's not like a perfect solution. Uh but uh at least it's there.

Um and in terms of what we as developers can do, well we can uh for example help um rollups by doing things like making it possible to become uh native and exposing the EVM like I was talking about before. So it becomes much easier for um uh roll-ups um to well just deploy a rollup basically uh but also uh that you don't have all this extra infrastructure um and generally I would like to see a lot more focus on making Ethereum a more roller friendly um environment and making it easier because yeah there are quite a few problems Um, but like I said, uh, we are we are working on it and trying to make it better.

Thank you so much. That was fantastic. We don't have any more time, but please put your hands together for him and the Ethereum Foundation. Thank you so much.

Automatic transcript — names and jargon may be misspelled.