1

Hypothesis

Full nodes that run both valid execution client and consensus-client would end up in a sort of deadlock and stop syncing. The consensus-client would try to feed the execution client with a block that the execution client refuses to accept. The only way to resolve the deadlock would be for the full nodes to update their software.


I guess a way this could happen is if >50% of validators in an epoch run the same version of the same execution client, with some kind of bug that causes the validators to build and sign off on an invalid block.

Is my hypothesis correct? What would actually happen? Would all the validators that reject the invalid block be slashed, due to being a minority?

1 Answer 1

0

The official doc of Ethereum POS states as follow:

Proof-of-stake comes with a number of improvements to the now-deprecated proof-of-work system:

  1. better energy efficiency – there is no need to use lots of energy on proof-of-work computations
  2. lower barriers to entry, reduced hardware requirements – there is no need for elite hardware to stand a chance of creating new blocks
  3. reduced centralization risk – proof-of-stake should lead to more nodes securing the network
  4. because of the low energy requirement less ETH issuance is required to incentivize participation
  5. economic penalties for misbehaviour make 51% style attacks exponentially more costly for an attacker compared to proof-of-work
  6. the community can resort to social recovery of an honest chain if a 51% attack were to overcome the crypto-economic defenses

PROOF-OF-STAKE AND SECURITY

The threat of a 51% attack still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. An 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.

51% attacks are just one flavor of malicious activity. Bad actors could attempt long-range attacks (although the finality gadget neutralizes this attack vector), short range 'reorgs' (although proposer boosting and attestation deadlines mitigate this), bouncing and balancing attacks (also mitigated by proposer boosting, and these attacks have anyway only been demonstrated under idealized network conditions) or avalanche attacks (neutralized by the fork choice algorithms rule of only considering the latest message).

Overall, proof-of-stake, as it is implemented on Ethereum, has been demonstrated to be more economically secure than proof-of-work.

1
  • 2
    I don't feel this answers the question. geth is currently used in >66% of execution clients. A software bug in geth could easily happen, and the economic defences against malicious attacks will be irrelevant in that case. And if an invalid block (that causes a negative balance for example) is finalized - how would you revert this? Would it cause validators running erigon/nethermind/besu/akula/reth to be slashed/be stuck in a deadlock? Feb 21, 2023 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.