## General Concepts
**consensus mechanism**: complete stack of ideas, protocols and incentives that enable a distributed set of nodes to agree on the state of a blockchain.
:::warning
Common misunderstanding: `proof of stake` or `proof of work` are not consensus protocols. They are actually Sybil resistance mechanisms and block author selectors; they are a way to decide who is the author of the latest block
:::

**Ethereum consensus definition**: at least 66% of the nodes on the network agree on the global state of the network
**Sybil resistance**: measures how a protocol fares against a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). Sybil attacks are when one user or group pretends to be many users.
**chain selection rule**: is used to decide which chain is the "correct" chain

**Ethereum consensus components**:
1. proof-of-stake-based consensus mechanism that derives its crypto-economic security from a set of rewards and penalties applied to capital locked by stakers.
2. a protocol that governs how honest validators are selected to propose or validate blocks, process transactions and vote for their view of the head of the chain.
3. fork-choice mechanism that selects blocks that make up the 'heaviest' chain, measured by the number of validators that voted for the blocks weighted by their staked ether balance.
4. additional security offered by potential out-of-band social coordination as a last line of defense against attacks on the network.

## Proof of stake
**advantages compared to POW**:
1. the community can resort to social recovery of an honest chain if a 51% attack were to overcome the crypto-economic defenses. (_isn't this true for POW as well? is it due to slashing?_)
2. economic penalties for misbehavior make 51% style attacks exponentially more costly for an attacker compared to proof-of-work.

**Validators**:
1. run three separate pieces of software: an execution client, a consensus client, and a validator
2. transactions are broadcasted over execution layer.
3. proposers for current slot is selected pseudo-randomly using RANDAO.

**Finality**:
1. A transaction has "finality" in distributed networks when its part of a block that can't change without a significant amount of ETH getting burned. Finality is a property of certain blocks that means they cannot be reverted unless there has been a critical consensus failure and an attacker has destroyed at least 1/3 of the total staked ether. Finalized blocks can be thought of as information the blockchain is certain about.
2. The first block in each epoch is a checkpoint. Validators vote for pairs of checkpoints that it considers to be valid. If a pair of checkpoints attracts votes representing at least two-thirds of the total staked ETH, the checkpoints are upgraded. 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".

**Settlement finality**:
why we need Finality? _Entrepreneurs, investors and enthusiasts claim that public blockchains are an acceptable settlement mechanism and layer for financial instruments. But public blockchains by design cannot definitively guarantee settlement finality, and as a result, they are currently not a reliable option for the clearing and settling of financial instruments._

a very important philosophical point to make is that **there is no system in the world that offers truly 100% settlement finality in the literal sense of the term**. Bitcoin has rich history of transactions been reverted after a long time.
hard fork double spend attack can be modified as random walk.
**incentive for security in proof of work is limited**, only lost is opportunity cost. Miners can be bribed.
**economic finality of POS**: we can't guarantee that "X will never be reverted", but we can guarantee the slightly weaker claim that "either X will never be reverted or a large group of validators will voluntarily destroy millions of dollars of their own capital". Imagine a version of proof of work where if you participate in a 51% attack your mining hardware burns down.
Validators are pre-registered so there is no possibility that someone is working in the dark with huge computation power.
for high-value assets the economic security margin of public blockchains is too low, is entirely correct and depending on the use case is a completely valid reason for financial institutions to explore private and consortium chains.
public blockchain vs permissioned blockchain concerns: censorship resistant, efficiency and latency.

Attacks against POS:
1. 51% attack
2. [long-range attacks](https://blog.positive.com/rewriting-history-a-brief-introduction-to-long-range-attacks-54e473acdba9) (although the finality gadget neutralizes this attack vector) In short, a Long Range attack is a scenario where an adversary creates a branch on the blockchain starting from the Genesis block and overtakes the main chain. This branch may contain different transactions and blocks and is also referred to as Alternative History or History Revision attack.
3. short range 'reorgs' (although proposer boosting and attestation deadlines mitigate this)
4. bouncing and balancing attacks (also mitigated by proposer boosting, and these attacks have anyway only been demonstrated under idealized network conditions)
5. avalanche attacks (neutralized by the fork choice algorithms rule of only considering the latest message)

Overall, POS is more **economically secure** than POW.

## Gasper
Gasper is a combination of **Casper the Friendly Finality Gadget (Casper-FFG)** and the **LMD-GHOST fork choice algorithm**.

Casper is for **finality**. It's a mechanism that upgrades certain blocks to "finalized" so that new entrants into the network can be confident that they are syncing the canonical chain.

Gasper sits on top of a proof-of-stake blockchain where nodes provide ether as a security deposit that can be destroyed if they are lazy or dishonest in proposing or validating blocks. Gasper is the mechanism defining how validators get rewarded and punished, decide which blocks to accept and reject, and which fork of the blockchain to build on.

Checkpoints -- more than 2/3 stake vote --> justified block -- more than 2/3 stake vote --> finalized block

only epoch-boundary blocks can be justified and finalized. These blocks are known as "checkpoints".

**inactive leak**: activates when the chain has failed to finalize for more than four epochs. The validators that are not actively attesting to the majority chain have their stake gradually drained away until the majority regains two-thirds of the total stake, ensuring that liveness failures are only temporary.

**LMD-GHOST**: stands for "latest message-driven greedy heaviest observed sub-tree". This is a jargon-heavy way to define an algorithm that **selects the fork with the greatest accumulated weight of attestations as the canonical one** (greedy heaviest subtree) and that **if multiple messages are received from a validator, only the latest one is considered** (latest-message driven). Before adding the heaviest block to its canonical chain, every validator assesses each block using this rule.

### history of Casper
1. the idea of [slasher](https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm) + security deposits ***You place a deposit to play, and if you play nice you make a small return on your deposit, but if you play mean you lose your deposit. It feels economically ideal, and it’s so programmable.***
2. **bribing attack**: first useful game theory model of economic security
3. to solve long range attack problem, clients need to know which nodes have the security deposits. Ignoring consensus messages from nodes who don’t currently have security deposits solves/circumvents the long-range attack problem.
4. provide finality
5. sampling + attestation + slashing condition
6. interesting debate on whether economic analysis was central to the blockchain based consensus research.
7. influenced by Tendermint. Tendermint has the property that every block was finalized before it was added (“commited”) to the blockchain. It guaranteed that at least 1/3 of the security deposits would be slashed in the event of any forks whatsoever, no matter how short the fork
8. move from efficient/competitive economic models to oligopolistic models. It changed the unit of analysis from individual validators to cartels of validators. It represented a shift from “ordinary” (independent choice) game theory to social choice/cooperative game theory.
9. Casper design philosophy: **Blockchain architecture is mechanism design for oligopolistic markets**.
10. Most of the projects in our space rely on an assumption that there are not more than some number of faulty nodes (or some percentage of faulty stake). **Fault count assumptions are not appropriate for public blockchains, because public blockchains exist in an oligopolistic setting, where a very small number of miners or coin holders (or reputation holders, in more exotic architectures) control a vast majority of the weight in the consensus**.
11. It's called “the friendly ghost” because of incentives designed to guarantee censorship resistance against the oligopolists: incentives that force the cartel to be friendly to non-cartel validators.
12. **The cartel cannot censor the absence of censored validators. The cartel had to be punished whenever validators appeared to be missing.**
13. A protocol is decentralized only if it can fully recover from the permanent removal of all but one of its nodes.
14. Casper favors liveness over safety.
15. Casper was born as simply “the friendly ghost”, an adaptation of GHOST to proof-of-stake, complete with incentives that would make a cartel “friendly” to non-cartel validators.

[Slasher](https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm): algorithm that combines POW and POS to defend against probabilistic dual-mining attack that is possible with PPCoin. select proposer in a deterministic way.

### Casper introduction
1. Casper is a security-deposit based economic consensus protocol.
2. a validator’s signature is only economically meaningful so long as that validator currently has a deposit. This means that clients can only rely on signatures from validators that they know are currently bonded.
3. When clients receive and authenticate the state of the consensus, **their authentication chain ends in the list of currently-bonded validators**. In proof-of-work consensus, on the other hand, the authentication chain ends in the genesis block.
4. This “out-of-band authentication only necessarily once” property is what Vitalik calls weak subjectivity. In this context information is said to be “objective” if it can be verified in a protocol-defined manner, while it is “subjective” if it must be authenticated via extra-protocol means.
5. **To resist attacks conducted by majority coalitions**, Casper regards the consensus process as a cooperative game and ensures that each node is most profitable if they are in a coalition made up of 100% of the consensus nodes
6. Security-deposit-based proof-of-stake is very light-client friendly relative to proof-of-work. Specifically, light clients do not need to download block headers to have full security in authenticating the consensus

### on weak subjectivity
POS can be made successful at a moderate cost, with regard to the nothing at stake problem.
short range fork can be solved by security deposits but long range fork can't be solved.
categorization of consensus algorithm:
Weak subjectivity is exactly the correct solution. It solves the long-range problems with proof of stake by relying on human-driven social information, but leaves to a consensus algorithm the role of increasing the speed of consensus from many weeks to twelve seconds and of allowing the use of highly complex rulesets and a large state. The role of human-driven consensus is relegated to maintaining consensus on block hashes over long periods of time, something which people are perfectly good at.

## Sources
https://ethereum.org/en/developers/docs/consensus-mechanisms/
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/
https://medium.com/@Vlad_Zamfir/the-history-of-casper-part-1-59233819c9a9
https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-2-8e09b9d3b780
https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-3-70fefb1182fc
https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-4-3855638b5f0e
https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-5-8652959cef58
https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm
https://blog.positive.com/rewriting-history-a-brief-introduction-to-long-range-attacks-54e473acdba9
https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm
https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost
https://blog.ethereum.org/2016/05/09/on-settlement-finality
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity