✅ All reviewers have approved.

Thank you @benaadams for pointing me to this thread :) My initial reaction would be to support reducing slot times to 8 seconds for a few reasons:

1. It increases throughput by 1/2, an effective increase to a 45M gas limit and 9 blob limit. This roughly aligns with the proposed 40M gas limit by pumpthegas.org and the 8 blob limit by Vitalik and others.
2. It opens the Overton window in favour of slot duration changes and would be a great warmup for future slot duration decreases.
3. It makes the slot duration a nice power of two, aligning with the rest of the beacon chain parameters.
4. It will make DEXes like Uniswap v3 roughly sqrt(12/8) ≈ 1.22x more efficient, saving roughly $100M in CEX-DEX arbitrage per year and ultimately leading to better execution for users.
5. It will improve the UX of L1 contracts, reducing confirmation times by 1/3.
6. Smoothing out peak load across more slots makes sense when execution clients largely sit idle between block verification spikes.

One downside of reducing slot times is that it will make timing games slightly more acute because of the slot-to-ping ratio decrease. Assuming a 80ms ping time and a 8s slot time the slot-to-ping ratio would be a healthy 100.

What impact will decreasing the slot time have on

• hardware requirements
• execution state growth and history growth (EIP-4444's hasn't shipped yet and until it does history growth is a valid concern)
• will it affect attestation?
• if solo builders now have less time to propagate everything, couldn't that lead to more skipped slots/re-orgs
• how does network latency play into all this
• Would decreasing the slot time increase the pressure to limit the amount of stakers etc

I am less aware of potential CL concerns, but I think this summary covers most of the potential bases for concerns if the slot time was decreased from 12s to 8s.

Could you also share the validator hardware spec impacts? And also the storage impacts.

Could it lead to worse geographical diversity, especially outside of North America and Europe?

This proposal appears to be a promising approach to scaling Ethereum, essentially increasing its transaction throughput (TPS) and mgas/s without increasing the block size. In this context, it feels like a form of horizontal scaling, distributing the load more evenly over time, whereas simply increasing the block size would be akin to vertical scaling.

However, there are some concerns from my perspective, particularly around validator attestations and chain reorganizations. Based on metrics from our validators (Besu) and nodes, as well as with Geth, around 5% of the blocks we receive are delayed between 3 and 4 seconds, and less than 0.5% arrive after 4 seconds on a daily basis.

I’m not fully aware of all the intricacies on the consensus layer (CL) side, but I assume that if the slot time is reduced from 12 to 8 seconds, the 4-second attestation cut-off time would be shortened accordingly. This could have significant implications for attestations and potentially increase the risk of chain reorganizations. These are areas that may require further analysis to ensure network stability if this proposal is adopted.
We can see below block arrival time on a daily basis with Teku client (running with Besu and Geth)

Besu X Teku

Geth X Teku

Updated numbering

I'm a bit confused by the apparent contradiction of this two statements

Increasing the gas limit from 30 million to 40 million or the blob limit from 6 to 8 directly raises the size of individual blocks or blobs, leading to higher peak bandwidth requirements that can strain network resources and disadvantage nodes with limited bandwidth.

and

Ensure that validators with lower bandwidth capacities can handle the increased frequency of messages.

So in the end bandwidth still remains a factor for both scenarios (i.e. either increase block size or increase block frequency). Or am I missing something ?

As an additional consideration I would also underline how, depending on individual implementations, block size increase vs block frequency increase have (serious measurement needed here) different impact on IO storage latency. Updating the whole state of the chain 30% times more might (!) result heavier (due to internals indexes implementation) than "simple" block size increase. Something to be carefully addressed not to increase the gap amongst implementations and storage models adopted.