I spent most of my time last week doing research to understand:

1. The dependencies between features so we could build a roadmap.
2. The details about fork-choice, specially LMD GHOST, to start implementing it very soon.

Dependencies

We met with Martin Paulucci and gave an in-depth look to the spec-tests. We used those to understand what building blocks we could code to make each tests pass, and which features were needed by multiple tests. This gave us some order, that we're still improving:

graph LR
  start --> BLS
  start --> SSZ
  start --> Shuffling
  
  SSZ --> Genesis[Genesis/beacon_state]
  Genesis --> Rewards
  Genesis --> ops[Operations]
  Genesis --> sig[Signature Verification]
  Genesis --> epoch[Epoch Verification]
  Genesis --> slot[Slot Processing]
  Genesis --> block[Block Processing]
  ops -.-> block
  Rewards -.->sig
  
  subgraph State Transition Tests
      sig
      epoch
      slot
      block
  end

This allowed us to detect two key features in the critical path, which is SSZ decoding (as it's needed for block representation) and Genesis tests, that involve beacon_state representation. Most of the other features are built on top of those.

Fork-choice

I added a summary of what I learned about consensus PR-14 of the Lambda Ethereum Consensus repo. It includes:

• A basic introduction to consensus in general and in blockchains.
• Attestations and last-message storage.
• Greedy fork choice.
• Slashings.

The goal for the document is for it to work as a ramp-up doc for newcomers and to document the algorithms independently of its evolution in time, which is the approach that the specs and the eth2book take.

It will be expanded this week to contain:

• Finality (Casper FFC).
• Implementation details about storage.