EPF C4 - Tomás Arjovsky - Week 6

Most of my week was spent doing research for the roadmap. I worked a lot with Martín Paulucci dividing the specs into workable areas. He focused on seprating tasks so they could be handled by different teams and I worked on a release plan, with milestones representing usable

Here's a first iteration of the plan:

1. Receiving and saving blocks.
   1. Libp2p discovery and block retrieval
   2. SSZ + snappy.
   3. on_block callback just saves the latest block in the fork-choice store and does basic checks. GetHead just returns the last obtained block.
   4. EngineAPI: execution payload validation (engine_newPayloadV2).
   5. Beacon API: returning head block root (GET /beacon/states/{state_id}/root)
   6. Optional: Create a docker compose with a Prysm client to use locally
2. Sync.
   1. Libp2p primitives for sync.
   2. Genesis representation.
   3. on_block basic checks, like the parent being present.
   4. BeaconAPI: return headers for head block.
   5. Observability: Basic Grafana dashboard
3. Deposits
   1. BLS signature checks
   2. Update consensus state view of the deposit contract (process_eth1_data)
   3. Process deposit operation to update validator list (process_deposit)
   4. Reset eth data at epoch transition (process_eth1_data_reset)
   5. Verify block signatures (verify_block_signature)
4. Attestations
   1. libp2p attestation retrieval.
   2. Basic beacon state representation.
   3. Attestations as part of the store (last message sent by each validator).
   4. on_attestation callback.
   5. EngineAPI: validate incoming blocks.
   6. BeaconAPI??
5. Slots and Fork-choice
   1. on_tick/process_slot in state transition. GenServer that calls this periodically.
   2. on_block: add slot related checks and epoch calculations (not finalization).
   3. Get-head now uses the messages.
   4. Block header validation.
   5. EngineAPI: process execution payload.
   6. BeaconAPI: getting head values should point to the heaviest.
6. Finality and Slashing
   1. epoch processing.
   2. on_block: pruning of fork-choice store. Not accepting blocks before finalization.
   3. Add RANDAO mix to the beacon state.
   4. BeaconAPI: get finality checkpoints, randao mixes.
   5. Attester slashing processing
   6. Proposer slashing processing
   7. EngineAPI: fork-choice updates.
7. Rewards, shuffling:
   1. Rewards processed on_epoch for a checkpoint.
   2. Deposits, withdrawals.
   3. RANDAO implemented.
   4. Committee calculation for a given state.
   5. Shuffling.
   6. Grafana.
   7. BeaconAPI: getting randao mix for a given block.
8. Validator features.
   1. Attestation creation
   2. Slashing monitors.
   3. Slashing proof creation.
   4. BeaconAPI: posting blocks, slashings, voluntary exits, withdrawals.

The only thing left is adding issues and estimating tasks for a Gantt, but with a clear priorization we now can correctly assign coding tasks to ourselves. We'll get some feedback from the community very soon as well.

This also unblocks us from having a proposal too, which we're presenting on Tuesday 29th.