-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: Reduce Slot Time for Lower Peak Bandwidth #8931
Conversation
✅ 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:
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
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks mergeable with the eip renumering as suggested
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
…into reduce-slot-time
Updated numbering |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Reviewers Have Approved; Performing Automatic Merge...
I'm a bit confused by the apparent contradiction of this two statements
and
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. |
Reduce Ethereum's slot time from 12 seconds to 8 seconds
This would be equivalent to increasing blob count from 6 to 8 or gas limit from 30M to 40M; however this approach does not increase peak bandwidth.