Lighthouse Update - Dapplion — Sigma Prime
EthClient Summit Buenos Aires 2025 · November 2025 · 9:39
Sigma Prime's Dapplion delivers an update on the Lighthouse consensus client at the 2025 EthClient Summit in Buenos Aires, covering recent progress on Ethereum's validator software stack. The talk situates Lighthouse's roadmap within ongoing work on Staking & Validators and Clients & Nodes across the multi-client ecosystem.
Speakers
Topics
From EthClient Summit Buenos Aires 2025, hosted by Eth Staker.
Transcript
Hello everyone. I'm Dab Lion from Sigma Prime and I need to wait right for loading. Oh, there you go. There you go. So I'm Aord Pthetherum currently developing Lighthouse and I'm going to give a brief update of what has been the last year to date for Lighthouse because we all know the forks forks are very interesting but the real stuff what's really interesting for us is what's happening behind the forks like the maintenance the juicy bits the performance and also I'm going to touch on the same thing what are we doing maintenance- wise for the future.
So, first of all, we had some releases. If you didn't know, Lighthouse, we named releases after Vik Morty characters. So, if you're curious, you can go to the release notes and see all of them. And this has been our major ones because who the hell updates the nodes outside of the fork, right? So, the first thing that we shipped this year is the update famously called tree states. Michael Sprout has been working on this for years and we finally ship it and with this we give massive improvements in memory and disk. So what you see here is a representation of the state as a tree like the beacon state has a characteristic where it doesn't
change that often. So if we represent as a tree we can reuse memory and keep a lot of states in memory and when we have reorgs we don't have to go to disk and do expensive stuff and that's better for your note in terms of performance catching up to the head better resilience then after releasing this we got to the DB so the second step of three states was this that has the fancy name hierarchal state divs but it has the same principle states don't change often then why the hell would you write them in full in the disk every time? Here we have a full snapshot written maybe once a year and then some layers of diffs
such that you can construct a state with a bounded amount of time and operations but it has a massive massive reduction on on disk I think like an order of magnitude something like this. So for indexers, explorers, fantastic. They love it. Also, if you are an tester and you want to survive long non-fality, you need this cuz otherwise lighthouse nodes would just run out of memory, choke and die. They don't anymore. So then also important for homestakers, if you want your SSD to run longer, IO reduction is great. It also affects performance because now the time to
import the block gets reduced and we find another optimization where we compress the four choice data and IIO went from a lot to nothing. So excellent improvement then well here I had an amazing graphic like absolutely amazing. I'm sorry you cannot see it. Uh so this is a feature that we introduced after a definite incident where most of the consensus clients they use finality as a signal to prune and because you are in non-lo finality like finality is not coming the client will just like keep adding junk like disk memory the thing I just talked about before reduces disk but not not
enough in some cases. So you can now send a signal to your client and tell it, hey, trust me, bro, this will not get reorked and everything past that in the past just gets pruned and the client can survive for longer. Also, the last thing, this was introduced by Jimmy. We now have open telemetry support in Lighthouse. And this is [ __ ] cracked. Like if you don't have this in your client, this is crazy. Like before someone would complain, open an issue like hey block production is slow please fix and now you have to like run your client in dev mode hope to capture it. Not anymore.
Now you have perfect capturing of all traces of all everything that happens in the client. We can just go back and see exactly the traces. So this is fantastic for performance. I would highly recommend to everyone that doesn't have this. Cool. Now for the future, the most important thing we are committed to doing at Lighthouse is hardening. We want Lighthouse to be the last client standing if it if that's what it takes for Ethereum to survive. You remember one of the pitches of the Bitcoin chain was to survive World War II. Well, it's not a meme. We're committing to do that.
And now we are kind of doing that test. If you know the hleski definite was deprecated some weeks ago. Everyone stopped running nodes except sigma prime. We run 5% of the network and we're doing fine and we have plans to finalize in the near future. So and we have been able to do this thanks to that previous work that we have done in the past and now we want to extend that not only to survive even more cases but to apply this work to other clients. We have a framework that we have been developed called diamond which is for now a private project where we systematically test a bunch of complicated cases of non-life analyticity and forking situations that we can run constantly on
CI to make sure that clients never regress with these things and we have already found bugs in teu and grandin and we only have three cases and we plan to have upwards of 60. Another important unlock was to be able to checkpoint sync into non-finalized checkpoints. Uh if you are a consensus dev and you are trying to do this, reach out to me because I want to see how you have done it. We finally cracked it and it's it's going to work in the next release. Then another unlock is sync in the beacon chain mainet has been absolutely stable, remarkably stable. We have stopped finalizing I think once for more than three epochs and we have never had
forky situations. So the clients are like too comfortable on the happy path especially for syncing. When things get complicated clients choke and they are not able to successfully ingest all the forks. So treesync is a new model that Nimbus is also adopting. Shout out to them to be able to efficiently and safely ingest different forks. This is still on the works but hopefully we'll have in one year. We'll see. Then another experiment that now we can do to ref shout out they are doing a great job to be strongly production ready. We want to merge lighthouse and ref into a single binary such that you
can just do as a staker comment binary blah and you have a full note with execution and consensus. Jimmy has been doing this recent experiment and it's showing promise. We'll see if we'll release it soon if this is proven to be stable. And the last one but not least, Lighthouse has a lot of code. We have been supporting networking libraries, crypto libraries, state libraries. We implement all the types and we know that using these as part of the ecosystem has not been the easiest. So we are committed to becoming truly modeler such that anyone that wants to do experiments research they can just use our libraries and extend lighthouse kind of a little
bit like ref model with the SDK that they have and the libraries and truly support research beyond what we have now. This includes the lin chain other experiments with zkms and fast. So if you are using Lighthouse for anything or any types, you can reach out. We want to know your opinion. Cool. And with that is all. Thank you for running Lighthouse and thanks for being here. Excellent.
I'm going to have you just move over to center stage for a second because we do have time for a few questions here and there is one in the chat already here. Uh they're asking uh the example of um I think it's Hleski right that's dying. How long will it take for Hilleski to refinalize with only 5% of the validators online? Right. So if you know a bit of the spec when a lot of people are offline we enter non-finality and then the inactivity penalties start to kick in. Everyone's inactivity score starts to go up and your penalties become exponential.
So your balance starts to go down like an S like this and then it dampens at the end. So now we are about at the middle point. The average balance of the network is 16 something ETH. So and this took maybe like 3 to four weeks. So we estimate that a few weeks probably longer than a month. It will take basically for everyone's balance to reach closer to zero such that the active ones represent 2/3. So, I would say three to five weeks. >> Oh, wow. That fast. Wow. Okay.
Excellent. Thank you. Another round of applause for Leon. >> Thank you.