Geth Roadmap - Felix Lange - Geth

Transcript

Loading Geth developer...

Hello. Uh I am actually going to talk about the GU road map. We do not have [laughter] we do not have our own rollup yet. [laughter] Maybe next year. Getcoin incoming. Um yeah, there you go. Uh my slides are a bit lopsided. I'm sorry. >> [laughter] >> Um yeah, let me just uh quickly introduce myself.

Introduction and Team Overview: Felix introduces himself and the Geth team

Uh so I'm Felix. I'm the current team lead of the GU team at Ethereum Foundation. I became the team lead in the beginning of 2025 after a long tenure by Peter Shilagi. I guess most of you guys know Peter. Uh he's still around and we are have good ties and so it's all good, but he's not with the GU team anymore. And um so for this presentation I thought I'd give a little bit of an overview of what we actually did in 2025 as well as what we're planning for the next year.

And I'm going to start by just quickly running through some of the highlights from the protocol development side. So in G we have the interesting situation that we are very deeply involved with the development of the Ethereum protocol as well as being a production grade Ethereum client. I guess it is the case for like most Ethereum clients that there's some way involved with the protocol development but for us since we're part of Ethereum Foundation and Ethereum Foundation has a very large like research department as well. is kind of like we we always face basically we have a lot of interface with like the people who are like really really deep into you know like exploring the future and so on. So we often get to participate uh in the research in a

direct way. Uh for the Prague fork which is already live uh we worked a lot on history expiry and for us this was a big undertaking because G yeah didn't really want to support it so easily but I'm happy to say that we're now in a pretty good place. Uh we worked also on the like era one files uh which are sort of the backup like we we thought a lot about these cases like yeah I mean deleting the history is easy but how do you actually get it back like what if you really need to access the old history how do you actually make that work and yeah we are still I guess working on that now but for the proc fork we shipped like some kind of solution that we're happy with where if you have pruned the history in your node

but you want to access the old blocks can uh dump error files containing the block range that you're interested in in it into a directory while the client is running and it will automatically pick them up and allow you to access that part of the history. Um we also have a downloader tool for the historical files. So we feel like we yeah we did a pretty comprehensive uh job there. Another thing is like the EIP7685 this is more like a consensus layer execution layer interfacing thing. We worked a lot on that. we were deeply involved in the development of this EIP and kind of shaped it the way it is. And then finally, one of our team members, Matt, is uh the author of EIP7702 uh set EOA account code, I think it is,

uh um with the set code transactions. Anyways, and uh we were very uh deeply involved with figuring out like how to make this supported in the me poolool like this was a big challenge and we felt like we were sort of the client who's like most like thinking the most about how what's the impact of this EIP on the meool is like not a trivial thing at all. And then for the Osaka fork which is going to activate quite soon. Um it was kind of a boring fork like on the execution layer like some changes but not really anything like super massive.

And the main thing for us was just we spent a lot of time looking into our modular exponentiation pre-ompile implementation because that uh is like the slowest by far one of the slowest parts in terms of the like gas per second. And so we ended up making some very deep optimizations in the Golang standard library to uh [snorts] improve the performance of that. And so we're happy to say that no it is no longer like such a bottleneck. So we feel like we're pretty well prepared for for example 60 million gas or 70 80 million gas. We can handle it with this now but it used to be that we wouldn't be able to like this was the worst case. And then for uh the on the feature side, we have two

big things in G in 2025 that I would like to mention. First is the new log index implementation. We shipped this in version 1.15.6 around I think quarter one end of Q1. Um so this is an improvement to the performance of log quering. So ETH get logs and like ETH get filter changes and these types of methods. Um, this used to be a very slow thing. So, for example, if you wanted to query all ERC20 token transfers of an address over the last two or three years or something, this could take a long time.

And with the new thing, you can do just do it like in in seconds. So, we feel like it's a huge improvement. And um as part of this what I find very exciting is um so the index is useful for users right away but we have big plans for this because the index is actually built so that the results of log searches can be proven against the blockchain and we feel this is a big piece of innovation because um yeah I mean it's one of these things where you if you talk to for example an RPC provider and you perform a log search, you cannot easily verify if they actually gave you the correct result.

But with this index, if it is integrated into the Ethereum protocol, you can and we feel like this massively reduces the trust in the providers that you have to bring. And I will be talking more about like trustless APIs later. In general, we are like very concerned about the trust aspects of the RPC interface and we always working to reduce that. Um the other big thing that we shipped in 2025 was the new archive node in end of June in the version 1.16.0.

So um as you guys may know GU has two big modes of storing Ethereum state. we have the hashbased storage and the pathbased storage and uh for the archive node when we launched the pathbased storage we initially only supported this for the full node and we had a we had a long project where we basically tried to make it work for the archive node as well I'm happy to say that since June 2025 we can now we now have the path-based archive node implemented uh just for reference this is all like very similar to what other clients are doing there's no like big magic here basically it's like the bizu to bonsai storage or the Aragon like storage.

We basically do the same thing. It's just like there are some slight differences there. But honestly, this appears to be like the architecture that everyone is using nowadays. So yeah, we got that also. But then for so what it means for the archive node is that used to be the archive node was around 20 terabytes and it's now two terabytes uh just about which is a a pretty significant improvement. Another feature on our side is the way it's implemented. You do not actually have to have the state all the way back to the genesis block. By default, we keep the last 90k blocks, but it's a configurable range. And we made this change because we know that people do need the archive node, but not everyone needs like the real like fullon archive

for everything. And I also just want to mention it because people often get confused but but like the archive node and accessing the logs is like two different things. So you don't need an archive node to query logs and people often think like yeah I just I'm just going to need the archive node. I need everything. But that's really not true. Like we've by talking to users we figured out that actually most people don't really need the archive note. They just need like one thing. And so this is uh for us we felt like by default we don't want to have people sync all this stuff when they don't really like never going to need it. And then finally um the way it's implemented is using also these like a bit like the tri logs mentioned by Gary this morning and uh because of the way it's implemented

Archive Node Optimization: Discusses reducing costs and storage needs

the archive part of the state. So the main state has to be stored in the SSD and everyone knows that it requires currently around one terabyte of SD space like including the history but if you just if you offload the history then like the actual state it's not that big but uh the archive state is which is one terabyte of like extra data that turns your like full node into an archive node. This part can also be stored in the spinning disc with our implementation. it will give you like you don't need an SSD for that but the it will be slower obviously if you have an SSD the access will be much faster but for many use cases if you just have an occasional need to peak into the Ethereum state history you don't

actually need to use an SSD for that and that can significantly reduce the costs of running the archive note as well right so let me get on to 2026 I'm not sure how am I doing on time um we will be working on the Amsterdam fork. We think that uh it's would be good if Amsterdam came in summer 2026. It's a pretty ambitious goal but we feel that like on the execution side there are many uh small changes can massively uh improve the user experience and uh I just want to quickly highlight we are very active in the development of block level access list. It is the headliner feature for the Amsterdam fork on the

Glamsterdam Fork 2026: Plans for new features and improvements

execution layer side. And then I'm just giving here some small uh highlights that are particular important to us. One of the big features that we are absolutely rooting for and I personally will really want to work on this is the finally adding automatic logs for ETH transfers into the Ethereum protocol. So this is a feature that has been requested over and over for 10 years. People have always said why can't I just do get logs and see when I received some ETH? And uh I feel like it is finally time to have this. So uh yeah, we will be rooting for that. Uh there we are also behind the uh gas repricing effort and we'll be trying to optimize the client for the higher gas

limit possibility. And then finally I was mentioning it the EIP7545D uh uh h damn. Yeah, the sevens and the fives. Yeah, seven. Seven. Okay, what I'm talking about, he knows what I'm talking about even though it's the wrong number. So, it's the uh trustless log index. Like I said, we really want to have that in protocol, but it is a bit of a controversial thing among the clients. So, we will be facing a bit of an uphill battle. Not every client is happy to have this because it is a significant amount of implementation work. I just want to say that like these are some of the things that are very important for us to work on in Amsterdam. And then finally regarding the uh bigger features

I just want to say that uh we have started working on an entirely new execution layer API. [laughter] So just in case you guys didn't have enough of the like you know experimental GraphQL and like halfbaked RPC methods, we're going to come at you with yet another [laughter] API. But no, I'm serious. So um one thing that [laughter] One thing we realized is that like it's kind of annoying like JSON JSON RPC has been the default interface to the Ethereum nodes for a long time but Ethereum nodes are actually this inter the RPC API kind of came about as an interface between like the

Ethereum browser 10 years ago and the node running on the local machine and we feel like it's kind of time to rethink what is the interface that the client should provide. We don't think that like the RPC should be deprecated or anything and we do think there is a need to support it still because obviously everyone's using it but it's just something where we should we should rethink it from first principles and design an API that is like fully trustless from the start and just you know exposes the minimum functionality you know that the client really has in the way that you know it can expose it best and uh yeah we have a prototype of it and you know some some documents that we're working on and this is just something that throughout 2026 we will just keep looking into this. Another

thing that we have sort of reconsidered is [laughter] that we may finally add support for the par call traces to get [laughter] I know for some people this might be quite exciting but this has been a long-standing feature request and we feel like it might not actually be that hard in the end and also maybe we can you know like forget about all the politics from like 10 years ago and just add this feature. And then finally we have looked intens extensively into it's basically already done implementation of this is that we have the new archive note but one downside of this you can't actually get the proofs and when we shipped the new archive note we thought oh my god yeah nobody needs proofs of historical

state but it's wrong people need it and uh especially the L2s and the sequencers they need to have access to state proofs for some limited amount of history so we have like Gary from our side has implemented another the archive note for supporting get proof and we will try to roll it out in Q1 uh 2026 so that everyone can finally get off of the like massive hashbased archive note and then um I still don't know how I'm how I'm doing on time but I'm just going to quickly say um we do intend in 2026 to be way more active in advancing the state of P2P networking in

Ethereum we do see that it's a bit of an under uh like an area where not a lot of work has happened. So within the team we have now have many uh mempool experts working on like advanced designs for like the future meool especially regarding the blob scaling. uh we still dream about having some kind of decentralized storage solution for the chain history even though portal network was unfortunately uh uh removed from Ethereum [snorts] funding and um yeah we are also uh working on a project to finally bring

the discovery version 5 topic index into production. So this will be some kind of uh improvement to the peer discovery which is especially important for the smaller networks and or the um L2 networks. And then finally uh yeah we after having a lot of conversations with uh L2 forks of GE and other projects using the GU codebase we feel that certain changes in the core could be very beneficial. Unfortunately, we have a hard time because of the way Go works. It's pretty hard to create like a generalized plug-in interface, but we do want people to like we do want to make the client more modular. So, we have some ideas around that that we're going to be following up. And then for my final um

slide, I just want to say people sometimes wonder how can we reach the GU team? This seems to be a big problem actually that like people don't really know. And um so I just want to mention it officially. So we do have an email address that you guys can use uh in case uh you want to inquire or have some business related uh I mean it is we are there to answer your emails. Please do not use telegram and um we also have a discord server. Uh it's right there. Uh trust me it's a discord link not a scam and uh we do answer questions there and for the

Contacting the Geth Team

for for all the power users and uh you know B2B connections we uh do offer you like can offer you like a private channel there where we will be helping you with your requests. Um yeah that's it. Yeah. [applause] >> Oh, yeah. I do need that still. Yeah. >> Yeah. [applause] Yeah. Keep the mic there. And I put my glasses on this time, so I'll read the words correctly. Road map. Um, so a couple of questions here. One, I think you answered in your question, but I'm going to ask it anyhow since it was one of the top voted ones.

Discussion on Trace Namespace Support

Why don't you support the trace namespace or parody that every other client supports? >> Yeah, that's a good one. Um so traditionally we didn't want to support this because this the parody namespace requires us to store traces into the database. So we basically have to create an additional index that isn't tracked by the protocol at all that contains all of the call frames of all transactions and then they have some filtering and some indexing on top of that and uh it's just it just goes way back that basically we were just even back in the day we were saying yeah people should just should just use logs for this because logs are a protocol incentivized feature and then I mean this API gives you access to uh an index that the protocol doesn't really care about but

yeah I guess now it's Excellent. Let me let me uh [laughter] >> Oh yeah. Should I answer that again? >> Peter was at Defcon. Uh he was actually hanging out at our booth like you know basically the whole day and um yeah I mean he's good. I mean I can show his project. He has this like health related device that he's been you know publishing about and I mean I can attest it looks great. Uh he showed it around. He even left a couple of his circuit boards at our booth for people to so yeah I think Peter is okay. [laughter] >> All right. Uh next next one which is not a question uh but please uh there was a request here perhaps you can comment on.

Standardizing the REST API

Can you make certain that you standardize the rest API from the ground up? Make it like beacon API standard. >> Yeah that's that's honestly the beacon API is a huge inspiration for us. That's honestly why we got started with this project because we looked at the beacon API and we were like yeah damn we want to be like that. This is like the rest API is the RPC API is kind of a mess like we are working on the standardization of the RPC API. I'm in these calls sometimes and I do maintain also the RPC API testing and so on and we will have a talk later today by Sebastian about like how bad the RPC is and the testing and everything but I mean we are working on it anyways and it's not exactly easy. So yeah, I mean I welcome you all to also like participate

in the RPC standardization calls. We are there and yeah, we want to these calls are like very have very low participation. So yeah, you can absolutely be there. >> All right, next question here. Uh is anyone publishing a block proof archive? >> Yeah, we thought about that but it's big like things would be massive. So I don't really like I don't think anyone's it would be just a huge data set right. So yeah I don't know I don't know about that.

Publishing a Block Proof Archive

>> And then uh do you work on a single binary uh execution client consensus client? >> Um yeah I mean we want to we we had a project like two three four years ago. We had this project idea where we were like yeah we're just going to build a CL real quick. And uh it didn't it wasn't that easy. So, but we do have an uh we do have an execute we do have a consensus layer like client and I think this is something people many people don't know but I mean you don't really need to run a consensus layer client if you don't want to stake like okay yeah if you want to stake you need the CL but if you just want to follow the chain and like provide RPC you don't actually need CL you can just run the like like client

and it's built into GU uh we have a documentation page about it we also have a standalone tool blink so even if you're not using G but you want to drive your other your other like execution [laughter] layer client with our consensus layer like client you can um it's supported >> okay >> as well >> and then uh last question here do you have an estimated disk size of a new archive with uh ETH git proof >> one second I have it right here Gary was he knew this would be asked. So he posted

um yeah I think uh it's going to be around four terabytes right I don't know where he is but I think it's going to be around that. Yeah. >> Okay. Perfect. Perfect. And I think we're at time here so we're going to leave the other two questions but Felix will unless there's one that you're really interested in you can go. >> I just want to quickly answer the XX. Yeah. So we do have um also something that I didn't really mention but it's because it wasn't 2025 but we do have some kind of like plug-inish interface. It's called the live tracer. So we have a a hook system that will basically call like you can write a go based plugin that is you know integrated into G and that receives notifications about pretty much everything related to chain down to

Estimated Disk Size for New Archive

like EVM up codes but also like high level events and uh it is a stable interface. So yeah, I mean people use this mostly for like indexing and so on. So there's a bunch of companies building on top of this and yeah, I mean if you have any questions you should approach Cena. He's also the organizer of this event and he is the maintainer of this interface and yeah it's it's there but it's not as it's a bit different from XX but it's kind of sameish idea. >> Excellent. Excellent. Well, another round of applause for Felix here. [applause]