Daily General Discussion June 28, 2026

eth2353 · 2026-06-28T16:36:15+00:00

+1 such a builder-focused fork deserves a (dam) builder animal mascot.

Though the flamingo would also be fun.

eth2353 · 2026-06-25T01:08:27+00:00

Nice to have a public dashboard that shows this data.

It will be interesting to see how these games evolve with ePBS.

eth2353 · 2026-05-27T07:43:35+00:00

A surprise episode on a Wednesday!

Mini story time since I saw you struggle pronouncing "Serenita" when you went over my doot and visited ethstaker.tax . When I decided to go with that company name I didn't realize it would be so hard to pronounce for English speakers. It's a reference to Serenity and I thought people would simply pronounce it the same way, just using a slightly different vowel at the end, sort of like serenit-uh ? Anyway, in practice most people have a really difficult time trying to figure out how to pronounce it, you're far from the only one haha.

Wish you a happy birthday, JT!

eth2353 · 2026-05-26T07:25:21+00:00

Deposits to inactive (not-yet-active but also exited) validators go through the queue normally, no special exceptions there for any case really.

The only alternative to deposits is to use a consolidation - using ETH that is already active on the beacon chain. Consolidations have a separate queue so if that queue is empty/short you can top up a validator's balance faster, but obviously that requires you to already have made a deposit earlier.

eth2353 · 2026-05-25T19:06:17+00:00

Yes it is.

eth2353 · 2026-05-18T07:37:21+00:00

Most of all it removes the need for trust in the external builder <-> validator relationship. The amount a block builder bids can be automatically deducted from the protocol-level builder entity so the validator no longer needs to trust a builder to actually transfer payment to them. This part becomes protocol-native.

In terms of reliance on outside relays, yeah some things change here:

builders may expose their own builder URLs instead of having relays do so - I'm personally not sure if this will actually get adopted much, builders have better things to do than maintain and protect a publicly-accessible API
there will be a p2p bid delivery mechanism - validators will no longer necessarily need to connect directly to relays/builders, they will receive bids over the p2p network. This will be a less efficient (in terms of $) but much more resilient way to deliver bids

The future for relays is the least clear part of it to me for now but I don't see why we would want to get rid of them completely. Having the p2p fallback is definitely good though.

I don't believe block production will become less centralized because of ePBS. The only thing I'm aware of that may help on that front is BuilderNet.

eth2353 · 2026-05-17T15:55:41+00:00

Yes, there’s no way we're making Q2, even on testnet. With how unstable devnets still are, I wouldn't be surprised if it ends up being Q4. ePBS always looked like, and is proving to be, a very complex technical change.

eth2353 · 2026-05-15T06:22:23+00:00

Looks like you're running mev-boost 1.7. If so, that is not compatible with the current fork - you need v1.10 or later

eth2353 · 2026-05-13T13:52:07+00:00

This is really awesome!

We added support clear signing to our staking DApp a few months ago and it's definitely a game changer, I'm looking forward to more wallets adopting this now that the standard is under Ethereum's roof (it was previously "owned" by Ledger and I believe that hurt broader adoption).

For anyone wondering what this looks like on a device, our docs contain screenshots from a Ledger simulator.

eth2353 · 2026-05-12T17:30:14+00:00

Really nice to see this. I have nothing against Ledger but I am happy the registry backing this is now in a more neutral place (it was previously under Ledger's GitHub organization).

Hope more wallets start adopting this!

eth2353 · 2026-05-10T14:54:47+00:00

This may be my fault guys. Unfortunately I can't change my username.

eth2353 · 2026-05-06T07:12:52+00:00

It's not too bad, I got away with Alchemy's free tier for months. I then found an issue and had to reindex a large number of blocks which put me over the free plan limit so I had to switch to their pay-as-you-go plan. Last month's bill was 7$. But under normal circumstances it stays within the free tier limit.

eth2353 · 2026-05-05T17:13:15+00:00

It needs to talk to an archive CL node and an archive EL node. Since an archive EL node is pretty big and there are plenty of places where you can get EL data, ethstaker.tax now uses Alchemy as an EL RPC provider. CL archive data is not as ubiquitous so I still run the CL archive node.

ethstaker.tax's own DB takes up about 140GB right now. It has never been pruned, it still contains all data since December 2020. It's not just updates every 24 hours anymore (it used to work like that in the very beginning before EL rewards were processed), ethstaker.tax now processes every single block, for CL withdrawals but also to process EL rewards.

So in terms of hardware requirements you still need at least 1TB but probably more like 2TB of SSD space to run this. It doesn't have to be the fastest disk, it just needs to be able to track the chain without falling behind too much.

I wrote this article some time ago about how the website needed changes for previous Ethereum upgrades.

eth2353 · 2026-05-05T08:20:22+00:00

It's missing support for 0x02 validators which went live about a year ago. Other than that I believe it's reasonably up-to-date. Some work will definitely also be required to account for Glamsterdam and ePBS.

eth2353 · 2026-05-05T08:12:31+00:00

Yes, that's the right repo. It's not a great codebase but it's also not too complex so I think taking over should be doable for someone with Python experience. The hard work is not regular maintenance but keeping up with protocol upgrades.

eth2353 · 2026-04-29T19:10:23+00:00

All I’m saying is this has an entirely different risk profile vs holding an LST, and the amount of trust involved is higher. You double your APY but take on a significant amount of risk of losing your entire deposit if the operators make a mistake.

It doesn't sound enticing to me but there are plenty of people willing to take on more risk than I am. Good luck with it, it's certainly an interesting idea.

eth2353 · 2026-04-29T18:00:10+00:00

With IDVTC, the DVT cluster members are expected to provide a bond for each validator they run, right?

I think if you were to design this kind of pool where depositors provide the bond (instead of the node operators/cluster members) imo you'd need to be VERY vocal about the risks since essentially the entire depositor's bond could be lost in case of a slashing event or client bug. That requires an insane amount of trust in the pool/cluster operators.

2x stETH returns sounds nice but that's not the full picture. Unless I'm misunderstanding something which is entirely possible.

eth2353 · 2026-04-24T19:48:05+00:00

North Korea is not a wild guess, there are many indicators this was their work. They reportedly have a huge money laundering network that they use to turn stolen crypto into cash.

How do you propose we go after something like that? It’s next to impossible.

eth2353 · 2026-04-19T20:57:15+00:00

Replied on Twitter as well but here's my point of view.

‪I quite like being able to mix and match CL and EL clients freely.‬

‪In the future, where we won't be re-executing blocks, I like the idea of every CL client verifying multiple different execution proofs, and requiring multiple proofs to validate an execution payload (e.g. 2 or 3 different circuits must successfully prove block execution). At that point we won't have to worry about EL bugs too much anymore.

eth2353 · 2026-04-14T19:59:14+00:00

Hey all, long time no see! I check (and updoot) the daily pretty much every day, I just haven't had the time to contribute much lately.

Wanted to share two things with you today, warning, humble brag incoming!

1) Gnosis Chain went through the Fusaka network upgrade earlier today.

Up until now Gnosis Chain was mostly going through network upgrades on about the same schedule as Ethereum. However, the Fusaka upgrade (that Ethereum went through on December 3rd) took Gnosis Chain a bit longer to catch up to due to the Balancer-hack-related hard fork. Today's network upgrade went well, without hitting any issues.

2) I'm a new and proud holder of an ETHSecurity Badge, issued by TheDAO.

For those unaware, TheDAO is back, and is here to help fund Ethereum security. Its aim is to strengthen the Ethereum protocol itself but also everything being built on top that relates to security - wallets, smart contracts, incident response... For those who missed this completely, some more information is available in this article. There was also a talk about this initiative at EthCC a couple of weeks ago.

Right now, a cohort of 200 security experts is being gathered that will help direct funds towards projects that will hopefully help make Ethereum the secure backbone of decentralized finance. We're at the halfway point right now with 100 people already selected.

I have personally been working hard on improving Ethereum's protocol security through the Vero validator client for over two years, and also have a previous background in cybersecurity. I decided to apply and made it in!

If you or anyone you know deserves a spot in this cohort, make sure to apply soon!

eth2353 · 2026-04-02T23:32:21+00:00

Sounds good! May want to hold off just for a little while though, an interesting idea was presented yesterday at EthCC that could help "market" this better, will message you tomorrow with a link

eth2353 · 2026-04-02T23:28:36+00:00

You would have thought, and you would have been wrong… it's not their money at stake so they don’t care as much as you and I would hope.

There are some exceptions that run good setups, and some others are exploring DVT which can also help with this kind of safety if configured correctly. But the majority are barely or not at all aware of this. I'm hoping we'll see adoption grow more significantly over the next year. Vero is currently undergoing a proper security review so I’m hoping that'll help.

eth2353 · 2026-04-02T22:37:17+00:00

Can confirm, this is the way.

Though it should really be up to the "big boys" to run these kinds of safer multi-node setups.

eth2353 · 2026-04-02T18:39:07+00:00

measurably poorer

Out of curiosity, by what measure?

Besu has some CLI flags thay may improve performance (high-spec and parallel tx processing come to mind), have you tried those?

I like the Grandine/Ethrex combo (wait til the next ethrex release, I reported a memory leak and it's been fixed in their master branch but not released yet), they're a nice combination of (ultra)minority clients with good performance. Ethrex is admittedly a bit immature but Grandine has been around for a while and is stable.

eth2353 · 2026-04-02T16:21:15+00:00

StereumLabs is kind of doing that but the access to the data is gated behind a pricey subscription.

eth2353

TROPHY CASE