Proof-of-Stake

Proof-of-stake is a way to prove that validators have put something of value into the network that can be destroyed if they act dishonestly. In Ethereum's proof-of-stake, validators explicitly stake capital in network tokens (32 ETH in Ethereum) into a smart contract. The validator is then responsible for checking that new blocks propagated over the network are valid and occasionally creating and propagating new blocks themselves. If they try to defraud the network (for example, by proposing multiple blocks when they ought to send one or sending conflicting attestations), some or all of their staked network token can be destroyed.

Validators

To participate as a validator, a user must deposit network tokens into the deposit contract and run three separate pieces of software: an execution client, a consensus client, and a validator client. On depositing their network tokens, the user joins an activation queue that limits the rate of new validators joining the network. Once activated, validators receive new blocks from peers on the network. The transactions delivered in the block are re-executed to check that the proposed changes to the network's state are valid, and the block signature is checked. The validator then sends a vote (an attestation) to favor that block across the network.

The time between blocks is divided into slots (12 seconds), and the block forms an epoch (32 slots). One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also, a committee of validators is randomly chosen in every slot, whose votes determine the proposed block's validity. Dividing the validator set up into committees is important for keeping the network load manageable. Committees divide the validator set so that every active validator attests in every epoch but not every slot.

Finality of Transactions

A transaction has "finality" in distributed networks when part of a block can't change without a large amount of network tokens getting burned. This is managed using "checkpoint" blocks. The first block in each epoch is a checkpoint. Validators vote for pairs of checkpoints that they consider to be valid. The checkpoints are upgraded if a pair attracts votes representing at least two-thirds of the total staked tokens. The more recent of the two (target) becomes "justified." The earlier of the two is already justified because it was the "target" in the previous epoch. Now it is upgraded to "finalized".

To revert a finalized block, an attacker would commit to losing at least one-third of the total supply of staked tokens. The exact reason for this is explained in this Ethereum Foundation blog post. Since finality requires a two-thirds majority, an attacker could prevent the network from reaching finality by voting with one-third of the total stake. A mechanism to defend against this is the inactivity leak. This activates whenever the chain fails to finalize for more than four epochs. The inactivity leak bleeds away the staked tokens from validators voting against the majority, allowing the majority to regain a two-thirds majority and finalize the chain.

Crypto-economic Security

Running a validator is a commitment. The validator must maintain sufficient hardware and connectivity to participate in block validation and proposal. The validator is paid in-network tokens (their staked balance increases). On the other hand, participating as a validator also opens new avenues for users to attack the network for personal gain or sabotage. To prevent this, validators miss out on block rewards if they fail to participate when called upon, and their existing stake can be destroyed if they behave dishonestly. Two primary behaviors can be considered dishonest: proposing multiple blocks in a single slot (equivocating) and submitting contradictory attestations.

The amount of network tokens slashed depends on how many validators are slashed simultaneously. This is known as the "correlation penalty", and it can be minor (~1% stake for a single validator slashed on their own) or can result in 100% of the validator's stake getting destroyed (mass slashing event). It is imposed halfway through a forced exit period that begins with an immediate penalty (up to 1 ETH in Ethereum) on Day 1, the correlation penalty on Day 18, and finally, ejection from the network on Day 36. They receive minor attestation penalties daily because they are present on the network but not submitting votes. This all means a coordinated attack would be very costly for the attacker.

Fork Choice: Choice of a New Block

When the network performs optimally and honestly, only one new block is 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 the proof-of-stake of Ethereum is called LMD-GHOST, and it works by identifying the fork with the greatest weight of attestations in its history.

Security Discussions with Ethereum's Proof-of-Stake

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 network tokens. They could then use their attestations to ensure their preferred fork had the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain so that this attacker can make their fork canonical.

However, a strength of proof-of-stake is that the community can mount a counter-attack. For example, the honest validators could 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 tokens. These are economically solid defenses against a 51% attack.

In the context of blockchain security, beyond the well-known 51% attacks, several other sophisticated types of attacks can be attempted by malicious actors. Here’s a clearer breakdown of these attacks and the countermeasures in place to mitigate them:

1. Long-Range Attacks: These involve bad actors attempting to rewrite a blockchain's history from a point far back in time. However, the implementation of a "finality gadget" neutralizes this threat by marking certain blocks as final and immutable, preventing any rewrites past that point.

2. Short-Range Reorganizations (Reorgs): These attacks involve altering the order of recent blocks. Measures like "proposer boosting" and "attestation deadlines" help mitigate this risk. Proposer boosting prioritizes certain block proposals to ensure consistency and continuity. At the same time, attestation deadlines limit the time frame in which blocks can be reorganized, thus preserving the integrity of the blockchain's recent history.

3. Bouncing and Balancing Attacks: These are sophisticated strategies where attackers manipulate block proposals to their advantage, but they have been largely theoretical and demonstrated only under idealized conditions. Proposer boosting again serves as a countermeasure by stabilizing the selection process of block proposers, reducing the feasibility of such attacks.

4. Avalanche Attacks: These occur when multiple conflicting pieces of information flood the network, potentially leading to incorrect or harmful consensus. The fork choice rule, which focuses on considering only the latest message for any decision-making process, effectively neutralizes this type of attack.

Each of these countermeasures is designed to enhance the resilience of blockchain networks against potential disruptions and ensure their operational integrity. These solutions are crucial for maintaining trust and reliability within the blockchain ecosystem.