Fast Confirmation Rule

[mkalinin]

Introduction

This PR introduces a modified version of the Fast Confirmation Rule algorithm introduced in #3339.

Modified algorithm starts its confirmed chain from a safe checkpoint and attempts to advance a confirmed block
at the beginning of each slot by finding the most recent confirmed block in the canonical chain. Then the confirmed_root is kept in the Store and is used as the starting point of the algorithm run during the next slot. This iterative approach is one of the main differences comparing to the original version.

A new version also have a few modifications improving the algorithm performance, i.e. reducing distance to the most recent confirmed block in e.g. empty slot case.

There is A Short Explainer covering the logic and rationale of the modified version of the algorithm.

Performance

Changeset

• Store is extended with three fields, one of them is confirmed_root and the other two are required for the algorithm needs. Alternatively, there can be a separate FCRStore class, however, it reduces readability of the spec.
• get_latest_message_epoch is introduced, because Gloas replaces epoch with slot, but the algorithm needs access to LatestMessage.epoch
• New on_slot_after_attestations_applied handler that basically does two things:
  • calls get_latest_confirmed function and updates store.confirmed_root
  • updates other algorithm variables in the store
• A bunch of helper functions to make reads from the Store more convenient
• Algorithm logic encapsulated into get_latest_confirmed function which does several underlying calls
• safe block is switched from store.justified_checkpoint.root to store.confirmed_root

Dependencies

Comparing to the Fork Choice implementation the algorithm has the following dependencies:

• Uses committee shuffling for the previous and the current epoch
• Uses Checkpoint state of the previous and current epoch checkpoints
• Needs access to each vote separately and computes an LMD-GHOST score based on the state of the previous or current epoch checkpoint
• Discounts proposer boost weight when computing an LMD-GHOST score in FCR

Testing

Tests are planned to be a part of a separate PR. The main idea behind tests is to extend the Fork Choice test format with on_slot_after_attestations_applied handler and confirmed_root property check and defined a separate FCR generator.

ToDo

• Merge Refactor get_weight and get_proposer_score #4746