Simple correction: has -> have #12896
Conversation
Just spotted a wrong verb used and decided to correct. Much love for Ethereum!
mcmoodoo
requested review from
wackerow,
corwintines,
pettinarip,
minimalsm and
nhsz
as code owners
✅ Deploy Preview for ethereumorg ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@coderabbitai review |
WalkthroughThe update focuses on enhancing the explanation of how new blocks achieve finality in the network. It particularly clarifies the roles of validators and outlines the balance between decentralization, time to finality, and computational demands. This change aims to provide a clearer understanding of the finality process and its associated trade-offs. Changes
Recent Review DetailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Additional Context UsedLanguageTool (31)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
|
@minimalsm please merge. Just a simple change involving two letter changes. Thanks |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Out of diff range and nitpick comments (2)
public/content/roadmap/single-slot-finality/index.md (2)
Line range hint
32-38: Improve conciseness and consider replacing 'greatest' for precision.- With the current mechanism design, in order to reduce the time to finality, it is necessary to reduce the number of validators on the network or increase the hardware requirements for each node. However, there are improvements that can be made to the way attestations are processed that can allow more attestations to be counted without adding to the overhead at each node. The more efficient processing will allow finality to be determined within a single slot, rather than across two epochs. - The aggregator that includes the greatest number of individual contributions passes their aggregate signature to the block proposer, who includes it in the block along with the aggregate signature from the other committees. + To reduce the time to finality under the current design, we must either decrease the number of validators or enhance node hardware. Yet, processing improvements could enable more efficient attestation counting without increasing overhead, achieving finality within a single slot. + The aggregator with the most contributions forwards their aggregate signature to the block proposer, who then includes it with others in the block.
Line range hint
47-49: Correct punctuation and rephrase for clarity.- Further efficiency gains could be made by creating supercommittees of e.g. 125,000 randomly selected validators per slot. Only these validators get to vote on a block and therefore only this subset of validators decide whether a block is finalized. Whether this is a good idea or not comes down to how expensive the community would prefer a successful attack on Ethereum to be. This is because instead of requiring 2/3 of the total staked ether, an attacker could finalize a dishonest block with 2/3 of the staked ether _in that supercommittee_. This is still an active area of research, but it seems plausible that for a validator set sufficiently large to require supercommittees in the first place, the cost of attacking one of those subcommittees will be extremely high (e.g. the ETH denominated cost of attack would be `2/3 * 125,000 * 32 = ~2.6 million ETH`). The cost of attack can be adjusted by increasing the size of the validator set (e.g. tune the validator size so the cost of attack is equal to 1 million ether, 4 million ether, 10 million ether, etc). [Preliminary polls](https://youtu.be/ojBgyFl6-v4?t=755) of the community seem to suggest that 1-2 million ether is an acceptable cost of attack, which implies ~65,536 - 97,152 validators per supercommittee. + Efficiency could be enhanced by forming supercommittees, e.g., 125,000 randomly selected validators per slot. Only these validators would vote on a block, thus only this subset decides a block's finality. The feasibility depends on the community's tolerance for the cost of a potential attack. Instead of needing 2/3 of all staked ether, an attacker would need 2/3 within that supercommittee. Research continues, but it's plausible that with a large enough validator set, the cost to compromise a subcommittee could be prohibitive (e.g., `2/3 * 125,000 * 32 = ~2.6 million ETH`). Adjusting the validator size could modulate the attack cost (e.g., setting it to 1 million ether, 4 million ether, 10 million ether). Community polls indicate that an attack cost of 1-2 million ether is considered acceptable, implying about 65,536 - 97,152 validators per supercommittee.
| The finality guarantee is not an immediate property of a new block; it takes time for a new block to finalize. The reason for this is that validators representing at least 2/3 of the total staked ETH on the network have to vote for the block ("attest") in order for it to be considered finalized. Each validating node on the network has to process attestations from other nodes in order to know that a block has, or has not, achieved that 2/3 threshold. | ||
|
|
||
| The shorter the time allowed to reach finalization, the more computing power is required at each node because the attestation processing has to be done faster. Also, the more validating nodes exist on the network, the more attestations have to be processed for each block, also adding to the processing power required. The more processing power required, the fewer people can participate because more expensive hardware is needed to run each validating node. Increasing the time between blocks lessens the computing power required at each node but also lengthens the time to finality, because attestations are processed more slowly. |
There was a problem hiding this comment.
Consider simplifying the expression and correcting punctuation for clarity.
- The finality guarantee is not an immediate property of a new block; it takes time for a new block to finalize. The reason for this is that validators representing at least 2/3 of the total staked ETH on the network have to vote for the block ("attest") in order for it to be considered finalized. Each validating node on the network has to process attestations from other nodes in order to know that a block has, or has not, achieved that 2/3 threshold.
- The shorter the time allowed to reach finalization, the more computing power is required at each node because the attestation processing has to be done faster. Also, the more validating nodes exist on the network, the more attestations have to be processed for each block, also adding to the processing power required. The more processing power required, the fewer people can participate because more expensive hardware is needed to run each validating node. Increasing the time between blocks lessens the computing power required at each node but also lengthens the time to finality, because attestations are processed more slowly.
+ Finality in Ethereum is not immediate; it requires validators representing at least 2/3 of the total staked ETH to vote for a block. This process takes time as each node must process attestations to determine if the 2/3 threshold has been met.
+ Shortening the finalization time increases the computing demands at each node due to faster attestation processing. More nodes mean more attestations per block, increasing the computational load. Higher computing demands limit participation as they require more expensive hardware. Conversely, increasing the time between blocks reduces these demands but extends the finality time because attestations are processed more slowly.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| The finality guarantee is not an immediate property of a new block; it takes time for a new block to finalize. The reason for this is that validators representing at least 2/3 of the total staked ETH on the network have to vote for the block ("attest") in order for it to be considered finalized. Each validating node on the network has to process attestations from other nodes in order to know that a block has, or has not, achieved that 2/3 threshold. | |
| The shorter the time allowed to reach finalization, the more computing power is required at each node because the attestation processing has to be done faster. Also, the more validating nodes exist on the network, the more attestations have to be processed for each block, also adding to the processing power required. The more processing power required, the fewer people can participate because more expensive hardware is needed to run each validating node. Increasing the time between blocks lessens the computing power required at each node but also lengthens the time to finality, because attestations are processed more slowly. | |
| Finality in Ethereum is not immediate; it requires validators representing at least 2/3 of the total staked ETH to vote for a block. This process takes time as each node must process attestations to determine if the 2/3 threshold has been met. | |
| Shortening the finalization time increases the computing demands at each node due to faster attestation processing. More nodes mean more attestations per block, increasing the computational load. Higher computing demands limit participation as they require more expensive hardware. Conversely, increasing the time between blocks reduces these demands but extends the finality time because attestations are processed more slowly. |
|
@all-contributors please add @mcmoodoo for docs |
|
I've put up a pull request to add @mcmoodoo! 🎉 |
Just spotted a wrong verb used and decided to correct. Much love for Ethereum!
Description
Related Issue
Summary by CodeRabbit