Notes on Eth 2.0

Notes on Casper

"Casper does not specify details on how blocks are constructed. We merely need that the concepts of blocks and attestations exist, and then LMD GHOST defines an algorithm to find a block given a view."

TLDR:

Message Types

The main type of message proposes a block, which is a piece of data, to the network. Other messages
can be:

• bookkeeping notices such as voting for blocks (“attestation”)
• putting new validators on the blockchain (“activation”)
• proving bad actions of other validators (“slashing”)

Assumptions

• majority trust assumption, less than 1/3 of validators are byzantine - "This constant can be traced
  to Practical Byzantine Fault Tolerance (PBFT) from [8], a classic consensus protocol in byzantine tolerance literature; PBFT ensures that the system runs correctly as long as less than 1/3 of the replicas (synonymous with our validators) are byzantine, as proven in [3]. This constant 1/3 tolerance appears frequently in many works based on PBFT (the main idea is that a pigeonhole principle argument needs the 1/3 to work, such as in our proof in Section 5), with Casper FFG [7] being the most directly relevant to our work, which we review in Section 3.1."

• re:synchrony - "For us, we make no synchrony assumptions when studying safety and plausible liveness. When studying probabilistic liveness (i.e. trying to quantify liveness under “realistic” conditions), we will use the notion (ii) of partial synchrony"

Slashing Conditions

where h(t1) = checkpoint height of t1
aka

• No attestations for two competing blocks on the same checkpoint height
• I don't understand this second cauchy-like attestation slashing condition

"All of these slashable behaviours relate to "equivocation", which is when a validator contradicts something it previously advertised to the network.2

The slashing conditions related to Casper FFG underpin Ethereum 2.0's economic finality guarantee. They effectively impose a well-determined price on reverting finality." - source

Example Fork w/ LMD-Ghost

Questions

• Sometimes attestations are referenced only in the context of a "checkpoint edge", but in the xample above it's used in the same epoch.

Notes on Gasper

• "Equivocation faults are fundementally enough to cause consensus failure"
  

• Ah the answer is to be tolerant up to some number of equivocations.

Attestations

• Each validator gets 1 attestation per epoch. If you go offline for n Epochs you can store n historical votes bc votes are (epoch, vote) pairs.

• If you submit 2 attestations for 1 slot you can get slashed

  • Who does the slashing here?

• Question:

  • What happens if a proposer has no attestations for the previous block.

• Resource on Attestor Aggregation strategies

LMD

• LMD provides block by block consensus and FFG provides finality

Notes on RANDAO

who needs randomness?

• to select proposers
  • fairness
  • protection against DOS attacks
• to select committees
  • bad committee can create link to invalid block
    • requires fraud proof to revert beacon chain
• onchain contracts
  • onchain protocols that need fairness
  • if attacks ar epossible, degrades randomness for everyone

idea 1:

• n people in one room
• each perosn computes a value xi
• compute XOR(x1, x2, ...)

Problem: Last player can change their value after having seen the other choices, until they get a favourable output (XOR grinding)

idea 2:

• n people in one room
• each perosn commits to a value xi by telling everyone HASH(xi)
• compute XOR(x1, x2, ...)

Problem: Anyone can stop the process by not revealing their preimage xi

idea 3:

• BLS signatures are deterministic
• use validator signature of (block, epoch) as commitment
• small problem: what if block is missed?
• skip its use in RANDAO, but this opens an attack where purposefully missing multiple blocks can bias the randomness. Solution is eventually VRDF
  • Vitalik post on how attacker with 36% stake + longest chain fork rule can take over the network

reorgs

• ex post reorgs - adversary observes a block that they subsequently attempt to fork out.

• ex ante reorgs - adversary attempts to fork out a future block that is unknown to the adversary at the start of the attack.

"In PoS Ethereum ex post reorgs become practically impossible. Why?

👏 Power 👏 Of 👏 Parallel 👏 Attestations 👏

Thousands of attesters add weight to blocks in parallel every single slot. The adversary needs to compete with all of them." [source 1]

Other Resources

https://hackmd.io/@0xapriori/SkEUSy1Bo

GASPER appreciation thread by Sreram

• https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md

• Decentralized Thoughts : Ebb & Flow protocols

• https://notes.ethereum.org/@vbuterin/SkeyEI3xv