post-merge updates: pos page #7116
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jmcook1186
requested review from
samajammin,
wackerow,
corwintines,
pettinarip and
minimalsm
as code owners
github-actions
bot
added
content 🖋️
59 tasks
minimalsm
reviewed
Jul 18, 2022
minimalsm
reviewed
Jul 18, 2022
wackerow
requested changes
Jul 25, 2022
There was a problem hiding this comment.
@jmcook1186 Couple tweaks and one question, let me know what you think =)
|
|
||
| ## Fork choice {#fork-choice} | ||
|
|
||
| When the network performs optimally and honestly, there is only ever one new block at the head of the chain, and all validators attest to it. However, it is possible for validators to have different views of the head of the chain due to network latency or because a block proposer has equivocated. Therefore, consensus clients require an algorithm to decide which one to favor. The algorithm used in proof-of-stake Ethereum is called [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), and it works by identifying the fork that has the greatest weight of attestations in its history. | ||
|
|
||
| ## Proof-of-stake and security {#pos-and-security} | ||
|
|
||
| The threat of a [51% attack](https://www.investopedia.com/terms/1/51-attack.asp) still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. A attacker would need 51% of the staked ETH (about $15,000,000,000 USD). They could then use their own attestations to ensure their preferred fork was the one with the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain, so this attacker would be able to make their fork the canonical one. However, a strength of proof-of-stake over proof-of-work is that the community has flexibility in mounting a counter-attack. For example, the honest validators could decide to keep building on the minority chain and ignore the attacker's fork while encouraging apps, exchanges, and pools to do the same. They could also decide to forcibly remove the attacker from the network and destroy their staked ether. These are strong economic defenses against a 51% attack. | ||
| The threat of a [51% attack](https://www.investopedia.com/terms/1/51-attack.asp) still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. A attacker would need 51% of the staked ETH. They could then use their own attestations to ensure their preferred fork was the one with the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain, so this attacker would be able to make their fork the canonical one. However, a strength of proof-of-stake over proof-of-work is that the community has flexibility in mounting a counter-attack. For example, the honest validators could decide to keep building on the minority chain and ignore the attacker's fork while encouraging apps, exchanges, and pools to do the same. They could also decide to forcibly remove the attacker from the network and destroy their staked ETH. These are strong economic defenses against a 51% attack. |
There was a problem hiding this comment.
@jmcook1186 Ignore me if you feel this is out-of-scope, but should we note here that even with 51% support to make this the "canonical chain" the attacked is still unable to finalize without 67% support?
There was a problem hiding this comment.
@wackerow It will finalize - the attacker has 51% of stake so honest nodes' fork choice algorithm will go along with the attacker's preferred chain - it is the heaviest by definition. The only thing an attacker "buys" by increasing their stake from 51 -> 66% is finality reversion.
Co-authored-by: Paul Wackerow <[email protected]>
minimalsm
reviewed
Aug 8, 2022
minimalsm
approved these changes
Aug 8, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Updates
developers/docs/consensus-mechanisms/pos/index.mdfor post-mergeRelated Issue
#7075