# Casper FFG client

Casper FFG client could be used by a 3rd party to track justified and finalized checkpoints. There are a number of ways this client could be designed and implemented. This write up is a summary of currently proposed solutions to that with a portion of new ideas.

## General Overview

The main question Casper FFG client answers is what's the most recent, observable finalized checkpoint? In order to do that, it should collect finality votes made by validators and if those votes have _>=2/3_ of total deposited ETH, then this checkpoint is justified. Two consecutive justified checkpoints is a condition for the former of them to be finalized.

Thus, the client must know the deposit of each active validator in the system and be able to get an identity from each signed vote message. The validator registry must be up to date with the checkpoint that validators are voting for.

In the Beacon chainn votes are identified up to a beacon committee which are shuffled each epoch. Thus, client should be aware of the seed used to shuffle committees for _target_ epoch and has an implementation of the shuffling algorithm.

## Light client

A light client maintains a copy of validator registry by listening for beacon blocks and processing operations from that part of chain that it can observe. Beacon blocks carry deposit, slashing and voluntary exit messages that affects validator's registry. Rewards and penalties is another part of validator changes that is not explicitly published on chain. In order to fetch this data light client have to maintain pending attestations parsed from each block and have an implementation of rewards/penalties calculation logic.

Checkpoint votes are parsed from attestation messages included on chain. In order to get validator indices, the shuffling implementation and data should, also, be maintained. Randao mix data are included into `BeaconBlockBody` as well as beacon chain operations.

Once there is enough evidence of checkpoint justification (there are _2/3 ETH_ voted for the checkpoint) finality state is updated with a new checkpoint. Two consecutive justified checkpoints turns into a new finalized one.

It feels like this is too much for a _light_ client. However, it differs from the full client in a number of ways. First of all, a light client doesn't run the full state transition. This means that it verifies signatures of any messages it processes and it doesn't have to track the information required to verify signatures. Second, it tracks only blocks - which significantly reduces its traffic.

Clients have to run the full state transition to get a proof of block validity or invalidity. On the other hand, light clients rely on full nodes that send [fraud proof](https://arxiv.org/abs/1809.09044) in case the block they've recently processed is invalid. A fraud proof contains evidence of block invalidity that could be verified by a light client.

Due to potential dropped messages and network delays, we assume a synchrony. Suppose there is a commonly agreed synchrony bound _δ_. Which means that any message sent to the network at time _t_ will be received by participants and time _t+δ_. In that case a time that _2δ_ is a time period during which light client should wait for a _fraud proof_ upon reciving a block.

There could be two basic strategies. First, process blocks as they arrive and only rollback/recalculate if a fruad proof is received. Second, track history and process this history after a _2δ_ timeout assuming that collected blocks are valid. With any of these approaches light client will have information about finalized data with _2δ_ timeout.

### Light cliet proposals
- a while ago: https://ethresear.ch/t/casper-ffg-and-light-clients/2957
- a later proposal: issue [#459](https://github.com/ethereum/eth2.0-specs/issues/459), PR [#476](https://github.com/ethereum/eth2.0-specs/pull/476)

## Full client

### Stateless client

This kind of client doesn't have to constantly maintain validator registry. Instead of this it fetches a bit of beacon state after each epoch transition in the chains that it follows.

If from these bits of state it sees that justified checkpoint has been updated, it fetches the entire validator registry and shuffling data from that checkpoint. The client will sequentially download blocks starting from that checkpoint and processes them one by one until it counts _2/3 ETH_ voted. In the case when justification is not reached during an epoch worth of attestations it will have to update its shuffling data to be able to identify further attestations.

In this case attestation processing assumes signature verification as well. As a result, the client needs to maintain an implementation of BLS signature verification.

### Stateful client

Similar to the previous approach, this client fetches bits of state after epoch transition to track justification and proofs recently justified checkpoint in the same way. The main difference is that this client maintains its own copy of validator registry in the same fashion as light client does it.

## Challenges

There is a rare circumstance when a client will have to revert finality in some attack scenarios (https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925/2). This recovery mechanism increases implementation complexity of the Casper FFG client.

The light client doesn't require signature verification while the other two approaches verify attestation messages. In order to reduce complexity of this operation, all messages that contain a vote for a given checkpoint could be aggregated. To achieve this, a finality vote should be signed separately. However, it increases the attestation size by `96` bytes per message and max block size by `96 * MAX_ATTESTATIONS` bytes. It, also, increases verification time which could be mitigated by tricks like double pairing.

Validator registry maintainance is a challenge for stateful and light clients. The main difficulty is the rewards calculation logic. Basically, if a client knows the diff between a pair of versions of validator registries ( or the validator indices that have been changed) it could either use this diff, or just fetch updated validator entries right from the state. There are a couple of places which poses an idea of introducing such a diff ([here](https://ethresear.ch/t/casper-ffg-and-light-clients/2957) and [here](https://notes.ethereum.org/@Yn8wHpL_RWyfvOgPXwCSJw/BJPBa42TQ?type=view#Beacon-chain-sync)).

## Further work
- Calculate the size of the state maintained by each kind of client
- Calculate amount of traffic that is required to update the state
- Compare them to regular beacon chain client