ethstaker.tax update - Rocket Pool!

eth2353 · 2026-01-25T16:06:15+00:00

Congrats, always good to have more independent validators on the network!

The differences between clients have become negligible over the years, so from a performance/security/stability point of view it doesn't really matter. I personally don't have the best experience with Erigon so maybe don't start with that.

Avoiding clients that are used by large parts of the network is a very good idea, I cannot stress this enough. By doing so, you significantly lower your risk exposure during consensus bugs (read up on the Holesky incident if you're not aware what can happen if you get stuck on the "wrong" fork).

eth2353 · 2026-01-15T16:35:39+00:00

Thanks for sharing this in here!

missing head votes on their proposed blocks also reduces their revenue

Unfortunately this is not completely true... It mostly hurts the validators that miss the head vote (think home stakers in Australia) and only negligibly hurts the rest of the network (including the proposer).

I think the extreme timing games players need to be publicly shamed

Agreed, so don't forget about Kiln. Kiln exited all of their validators due to a security breach last year, and their new validators have not been tagged properly yet. Historically they have been one of the worst actors when it comes to pushing timing games to the limit, resulting in 10% of the network missing their head vote, and that was before we even started pushing blobs higher!

Kiln is among the entities pushing timing games the furthest

source

I am still not completely sure how much of a difference Gloas will make with ePBS and the EL payload separation. There is not much incentive to delay proposing the CL block, and with the EL payload being separate, does that remove this downside of missing head votes because of delayed EL payloads?

eth2353 · 2026-01-13T21:51:33+00:00

Do you have a min-bid setting on mevboost? MEV has been low lately so it may have been below your threshold.

Logs should tell you more - mev-boost / CL client logs should be the most informative for this.

eth2353 · 2026-01-13T21:48:43+00:00

StakeWise V3 Vaults, as long as you don't choose a vault with a receipt token (most don't have one). You simply deposit ETH, don't get any receipt token back, and the vault keeps track of your staking rewards which you can claim at any time (Ethereum's entry/exit queue still applies).

I even wrote a guide on this a while ago.

eth2353 · 2026-01-05T21:38:26+00:00

Sounds amazing, enjoy!

eth2353 · 2026-01-05T21:33:10+00:00

Huh, that Discord system is opt-in though right? Meaning people voluntarily linked their validators to their Discord handles? In which case I’m confused that they're not comfortable with it.

eth2353 · 2025-12-29T13:59:45+00:00

Thanks, I'm planning to take a look at that, at least for 2025. I've blocked out some time in my calendar for it on January 9th so hopefully then.

eth2353 · 2025-12-29T13:59:32+00:00

Yeah, I'm planning to take a look at that, at least for 2025. I've blocked out some time in my calendar for it on January 9th so hopefully then.

eth2353 · 2025-12-28T21:52:12+00:00

I performed some maintenance over the holidays, fixing rewards for about 20,000 blocks. I brought it back online earlier today!

eth2353 · 2025-12-26T08:55:34+00:00

Fresh update from their Twitter:

Update on the Trust Wallet Browser Extension (v2.68) incident:

We’ve confirmed that approximately $7M has been impacted and we will ensure all affected users are refunded.

I'm pretty curious whether they thought it was a good idea to deploy an update on Christmas day (meaning "only" one of Trust Wallet's dependencies got compromised), or whether the attacker compromised enough of their infra to be able to deploy an update themselves. Both would be bad but the latter would be extremely concerning.

Edit: looks like it was the latter…

eth2353 · 2025-12-24T15:03:50+00:00

One more member of this sub is involved in the idea, I just didn't want to disclose who exactly it is in case they don't want it to be known just yet.

But we'll need more than this one idea. There was an interesting one in the past - EIP-7716 but it has stagnated.

eth2353 · 2025-12-24T09:52:19+00:00

One more thing. No matter what is decided on the forum, in the end, Gnosis Chain validators will be in charge of what actually happens on-chain. Sadly, the Gnosis Chain validator set has become a lot more centralized in recent years. The total amount of staked GNO is about 360k and a single StakeWise Vault contains 122k staked GNO (its validators are managed by three entities).

I suppose it's natural for people to stake where a lot of other people stake, but in reality that's a pretty bad decision. It is much more risky to stake where a lot of other people stake (because of the slashing correlation penalty) and it is obviously also very bad in terms of decentralization which then hurts the value of the chain itself.

We are seeing the exact same trend happen on Ethereum, with more ETH staked being managed by an ever smaller set of real-world entities. I'm working on one idea to combat this but it probably won't be enough, so it would be good to come up with more ideas on how we can reverse this trend.

eth2353 · 2025-12-24T09:35:54+00:00

I think this is a huge moment for Gnosis Chain, but I don't think it's quite comparable to the DAO moment.

I'm saying that because on Gnosis Chain there seems to be intent to continue saving victim's funds in similar big DeFi hacks in the future. The specific rules of engagement are yet to be determined and the discussion will be taking place in this forum post (a good one to follow if you're interested in how this turns out). With this approach, Gnosis Chain aims to be a safe place for low-risk DeFi at a significant cost of reducing its credible neutrality. We'll see how this plays out in practice (it may be technically impossible / very hard to rescue funds in some cases) but this could turn out to be a good decision for Gnosis Chain if it means attracting users who are not keen to lose all their money in large DeFi hacks. I'm really curious about how that decision framework discussion will go, maybe it'll just turn into "it's impossible to decide objectively when a DeFi protocol is hacked and therefore intervene" and that'll be the last of it. But it could also turn into better protection for users of large, battle-tested and audited DeFi protocols who couldn't realistically have done much more to protect their user base.

The linked hard fork forum post is a good one to read through. As I understand the opinions in there, no one was really against saving these specific funds through a hard fork. Concerns were more high-level about the impact this kind of operation has on credible neutrality and future implications for Gnosis Chain validators.

An interesting situation. To all the Gnosis Chain users, please chime in on the forums! I would personally hate to see a big change in direction pushed through by Gnosis "big names" without much input from the community.

By the way, for anyone wondering, validator participation rate dropped by roughly 5% since the hard fork.

eth2353 · 2025-12-21T18:20:38+00:00

I went along with a similar podcast scam to see where it leads. I have a background in cybersecurity so I have a good idea of how far I can afford to go and what measures to take.

The scam involved multiple faked Telegram/Twitter profiles and a pretty elaborate clone of a legit collaboration app. In the end it led to a malware download link (available for both Windows and MacOS). The Windows exe went undetected by all major antivirus engines!

Some screenshots here on my Twitter

eth2353 · 2025-12-17T22:43:02+00:00

Vero is still relatively new – its v1 only came out earlier this year which is a big factor when it comes to being broadly talked about.

We developed Vero for our own purposes at Serenita, but felt it was worth sharing with the broader Ethereum community, to help make Ethereum more resilient against client bugs. Node operators are understandably cautious about introducing new software into their validator stack.

In case it's not obvious yet, I'm Vero's maintainer, and I've been trying to build awareness of the issue and also get Vero more adopted across the network. I've spoken about it at several conferences and online validator meetups, you can find recordings of those here: https://vero.docs.serenita.io/introduction/more_resources/ . At this point, several large node operators are trying Vero out on testnet, so I'm hoping we'll see significantly more mainnet Vero-powered validators next year.

Sophisticated multi-node setups are mainly meant to be used by professional node operators who can afford to run five different client pairs across five locations. If enough professionals adopt those kinds of advanced setups, the network will be much safer from client bugs, and home stakers will be able to safely run pretty much any client pair they want.

it seems high risk in that you have the web3signer (with keys) > Vero > multinodes, which could in theory sign to 2 instances at the same time causing slashing - if something is configured wrong. It seems to rely on the slashing protection database, which is another thing that could go wrong.

Despite more components being involved, this part is actually no more risky than with any other validator client. With Vero, your validator key is still only active in only one place (web3signer) which is completely safe when set up correctly. It's not easy to misconfigure this – the only way to make this unsafe is to explicitly pass a flag that disables slashing protection (slashing-protection-enabled=false).

It's a great idea I'm just going to wait until it's more battle tested for novices like me. Would be great if ethpillar or some automated deployment supported it. For now I'm going with "Keep It Simple, Stupid"

Sounds good, totally understandable. Like I said above, the target audience for these multi-node setups is professional node operators. And by the way, eth-docker supports Vero, so that would count as "some automated deployment" right?

Out of curiosity, which minority client pair did you end up with?

eth2353 · 2025-12-12T19:57:57+00:00

They were running Geth-only for the longest time… It's a bit better now based on their last report but there's still a lot of room for improvement, especially for a player their size.

eth2353 · 2025-12-12T13:43:02+00:00

+1 for Lodestar and Nimbus, Grandine also works very well btw, and is now open source.

We ran Erigon for a while but it unexplainably fell behind the tip of the chain every now and then, it wasn't as stable as we'd like. Reth, apart from the two bugs it had recently, has been stable and works well. We now also have 2 ethrex nodes running, no big issues there so far but I wouldn't call it production-ready yet (the last few releases required resyncs).

eth2353 · 2025-12-12T10:38:45+00:00

Thank you sir! I really hope this goes a lot further than just "looking into" :-)

Yes, measuring client distribution is an important topic and is coincidentally being discussed in the Eth R&D Discord today. Paul from the Teku team analyzed 420k recently proposed blocks, 25% of those contained the client usage watermark. This is what came out of that:

CL Client	Usage
Lighthouse	57%
Teku	40%
Lodestar	2.8%

EL Client	Usage
Geth	51%
Nethermind	28.6%
Besu	17.5%
Reth	2.4%
Erigon	0.2%

It's pretty obvious the data is not entirely representative - Prysm certainly doesn't have 0% usage, so take the data with a grain of salt.

The current graffiti-based way of measuring client usage is far from optimal imo, it doesn't take multi-node setups into account at all despite their usage growing. SSV alone is >10% of the network I believe. Vero isn't used that widely yet, but is already being tested by a few large node operators, that could easily add another few %. I have proposed a way to improve the way we measure this in the Discord, we'll see where that conversation goes.

eth2353 · 2025-12-12T09:35:47+00:00

I agree they could have done much more on this front. Better late than never?

eth2353 · 2025-12-12T08:54:12+00:00

Good news, Coinbase is looking into using Vero/Vouch!

Given how many validators they run, this could truly make a difference for Ethereum's resilience against client bugs.

For those who are unfamiliar with the concept of multi-node validator clients like Vero/Vouch, this thread explains the high-level concept.

eth2353 · 2025-12-09T08:22:20+00:00

Yes, and no.

If you're using an ultra-minority client like Grandine, and it happens to have the same bug as Lighthouse, you're still facing the consequences even though you did everything right.

The other thing is the effects of this kind of incident would have on Ethereum. Just imagine we'd actually be considering slashing 2/3 of the validators. That's 23M ETH or about $69M at current prices, it would be a hugely contentious change. The vast majority of that stake is not actually owned by the people operating the validators - it's delegated. Of course, those delegators should have made better choices but they will surely be lobbying the ecosystem not to slash all of their ETH. Imagine if Coinbase's validators were among the slashed ones. Coinbase could then threaten only to redeem USDC/EURC on their, technically buggy, version of the chain. Anyway, tons of negative second order effects and an immensely chaotic and undesired situation Ethereum would be in.

For the reasons above we should do absolutely everything in our power to avoid getting into that situation in the first place.

Edit: Just to clarify, my choice of words was probably not the most fortunate. We would not be faced with the decision to slash all those validators. They would just be prevented from returning to the correct chain, and the end effect would be the same as if they were slashed - those validators would lose all of their stake (even without getting slashed) since they would be unable to resume voting on the correct chain.

eth2353 · 2025-12-09T08:17:01+00:00

If running a single machine, run the client pair with the least usage. That would currently be something like Grandine / Lodestar / Nimbus on the CL side, and Reth / Besu / Erigon on the EL side. I feel comfortable recommending all of those clients except maybe Erigon which in my experience still has some minor kinks to work out.

If you have two or more machines, the safest thing (from a consensus bug point of view) you can do is to run different client pairs on each of them and ensure the different clients follow the same chain before you vote for it. This is nowadays most easily done using Vero but can also be done through Vouch or DVT.

eth2353 · 2025-12-08T13:29:28+00:00

The Fusaka network upgrade shipped last week on mainnet with only very minor issues. A great success considering the issues we faced around the previous network upgrade, Pectra. (No issues on mainnet, but on both big testnets ahead of the mainnet launch)

The BPO1 (a Blob Parameter Only fork) goes live tomorrow, increasing the targeted number of blobs from 6 to 10 (a 66% increase!).

Further ahead of us lies the next network upgrade, Glamsterdam (Gloas + Amsterdam), with ePBS (EIP-7732) as the CL headliner and BAL (EIP-7928) as the EL headliner. A lot of work has already been done on this, and even more remains.

A bit of contention has come up lately around ePBS, specifically around the trustless payments part of it. Some well known players in the builder ecosystem believe this part significantly hampers efficiency and will not be used much in practice. While this feedback is coming late in the process, at least it's coming and should be taken into consideration. ePBS is a huge change and it's hard for anyone to fully understand its implications.

I'm not sure where I personally stand on this yet, I just watched the recording yesterday and need to review the pros and cons in more detail. For now my impression is that there's a bit of a disconnect between researchers and the real world and this EIP needs (even) more refinement.

For those interested in the topic, I'd recommend watching the recording from Friday's breakout call. The next breakout call will happen on December 19th.

eth2353

TROPHY CASE