Goldfish: fixing PoS Ethereum beacon chain

[xuechao2]

Goldfish is proposed as a fix to the Gasper protocol that is supposed to power PoS Ethereum beacon chain after 'the Merge'.

Protocol description

Goldfish

• The protocol proceeds in synchronized slots, each of $3\Delta$ rounds. There are $n$ validators. In each slot, a set of proposers and a set of voters will be elected using VRF.
• Goldfish uses a new fork choice rule called GHOST-Eph, which is a variant of GHOST rule. Different from GHOST, GHOST-Eph is parameterized with the slot number $t$ and it ignores votes from before slot $t$ when deciding the heaviest chain.
• In each slot, validators with different roles (proposer, voter and other validators) apply the GHOST-Eph at different time.
• At any time, each validator stores the consensus messages received from the network in its buffer. Buffered messages are merged
  to the local view only at specific points in time which are explicitly specified by the protocol.
• In each slot, validators with different roles (proposer, voter and other validators) apply the GHOST-Eph at different time.
  • At the start of slot $t$, each proposer merges buffered votes into its local view, determines its canonical GHOST-Eph chain using the slot $t−1$ votes in its view, and proposes and broadcasts a block extending it, together with its local view.
  • One-thirds into slot $t$, each voter selects the proposal with the minimum VRF output and merges the proposed view into its local view, determines its canonical GHOST-Eph chain using the slot $t−1$ votes, and casts a slot $t$ vote on the tip.
  • Two-thirds into slot $t$, each awake validators merge its buffers into its local view, determines its canonical GHOST-Eph chain using the slot $t$ votes, and truncates the chain up to blocks from slots $\leq t-\kappa$ as the confirmed ledger.

Goldfish with optimistic fast confirmations

By introducing a fast confirmation rule and adding $\Delta$ more rounds to a slot, Goldfish can achieve much faster confirmation optimistically, i.e., under high participation and honest supermajority (> 3n/4 await honest validators).

The change in protocol is minor: Two-fourths into the slot $t$, each await validator merges its buffer and view, then marks a block proposed at the same slot $t$ as fast confirmed if more than 3/4 of the eligible voters of slot $t$ voted for it.

Composition with the finality/accountability gadgets

Goldfish with slow confirmation can be easily composed with finality/accountability gadgets, following the construction in the previous work. The key step is to check that Goldfish can self-heal after a period of asynchrony.

However, how to compose the fast confirmation rule with finality/accountability gadgets, that is how to checkpoint fast confirmed blocks remains open.