terencechain

Saw a lot of back and forth on faster slot time (EIP-7782) and epbs (EIP-7732), so I wanted to share where I stand. First off, I want to emphasize that all the discussions I’ve seen have been in good faith, everyone wants what’s best for Ethereum. The main question is just the order of operations. This is a good problem to have! From the outside it might look messy, but that’s what public R&D looks like. We're in an open kitchen debating whether to serve steak or lobster first, the customer gets both either way, it’s just a matter of when and how.

Now speaking just for myself (not my team), I believe we should ship EIP-7732 first. Here’s why:

1.) From an engineering perspective, it makes more sense to restructure first, then shorten. Doing it the other way around is not just more engineering work, it’s not 1:1 (not linear either) but it's harder to reason about.
2.) From a testing perspective, it's simpler to test slot restructuring first and then faster slots. As we saw in Pectra, testing is the main bottleneck to shipping!
3.) From a security perspective, rolling out a larger change (like restructuring) first and then a smaller one (shortening) is often safer. Let it run on mainnet and harden before adding more complexity.
4.) From a timeline perspective, in terms of combined time, I believe (EIP-7732 → EIP-7782) is faster than (EIP-7782 → EIP-7732). We could ship 7782 just 3–4 months after 7732 if we work on both in parallel and switch to test mode as soon as 7732 lands. A short CL-only fork could get us there quickly.

That’s just my view as someone building and implementing this stuff day to day. I’m missing context in both research and the community. Ultimately the users of Ethereum should have a say, would you prefer faster slot times in Glamsterdam or a higher execution gas limit and more blob capacity? Why? I’d love to hear your thoughts

Haven’t been able to make it to ACD calls as much as I’d like, but today’s session looked super productive. Ethereum is shipping & scaling!

Ethereum validator queue has been growing steadily since late May, I analyzed all the old ETH1 and new EIP-6110 execution deposits from slot 11649077 -> 11931977

Highlevel numbers:
- There are total 82,529 new EL deposits vs. 541 old eth1 data deposits as expected eth1 deposit was deprecated
- Total 2.3M ETH deposited via EL deposit
- 375 EL deposits greater than 32 ETH amount

now we share some charts:

https://launchpad.ethereum.org/en/validator-actions is criminally underrated. The UX for partial deposit, withdrawal, and compound is super smooth. Huge kudos to the team behind it, but as always, DYOR

Been digging into blocks over the past month and found something interesting:
172 blocks had no txs, 85 had no fee recipients.
That’s ~5–6 per day, about the same rate as reorgs.
Example: https://t.co/lw0pSAePBt
Could last-minute reorgs be catching builders off guard? Anyone know more? cc @Data_Always

One month since the Pectra update. Wrote a quick script to download all the blocks since & study execution request usage. What I found across 236k slots:

- Out of 236k slots, only 30,587 blocks had any execution requests
- In those blocks, there were 69,041 deposit requests, 312 withdrawal requests (why so little!), and 17,570 consolidation requests
- For deposits, we saw 57,293 unique pubkeys and 2,102 unique withdrawal credentials
- For withdrawals, 262 unique validator pubkeys and 100 unique source addresses
- For consolidation, 3,422 unique target addresses and 3,544 self-consolidations, which looks like ~1.3% of validators consolidated

anything stood out to you here?

Hoodi testnet reaching 60M gas limit 🚀

One week after Pectra: reorgs per day have dropped back to pre-petra levels, looking good so far

Sepolia testnet reaching 60M gas limit🚀

Pectra saved eth price, who knew all it took was moving committee index out of attestation

Pectra hits mainnet in ~20 hours
I won’t be tweeting finalization—just hoping everything goes smoothly 🫶