# Confirmation Rule implementation notes (Teku)

During prototyping of the Confirmation Rule draft spec (https://github.com/mkalinin/confirmation-rule) on Teku client (https://github.com/Nashatyrev/teku/tree/confirmation) the following challenges are worth mentioning:

- Needed to fallback to naive LMD weighting implementation (with some in-place optimizations), i.e. counting individual votes weights for individual blocks. The existing Protoarray structure was not feasible to reuse due to the following reasons:
- `get_attestation_score()` (similar to ForkChoice `get_weight()`) works with an arbitrary `BeaconState` as a validator balances source, while Prototarray is always calculated on the Justified checkpoint state. ([implementation](https://github.com/Nashatyrev/teku/blob/78f8f8e45ce794949878de6ce533c4ad4a036c15/ethereum/spec/src/main/java/tech/pegasys/teku/spec/logic/common/util/ConfirmationRuleUtil.java#L222-L277))
- `get_attestation_score()` doesn't include proposer boost. This however could potentially be overcome by subtracting proposer boost score from the weight taken from Protoarray
- `get_checkpoint_weight()` also works with an arbitrary `BeaconState` as a validator balances source ([implementation](https://github.com/Nashatyrev/teku/blob/78f8f8e45ce794949878de6ce533c4ad4a036c15/ethereum/spec/src/main/java/tech/pegasys/teku/spec/logic/common/util/ConfirmationRuleUtil.java#L590-L647))
- `get_checkpoint_weight()` should sum up weight for a block only for votes casted in the target epoch, while Protoarray doesn't differentiate assigned slots for votes

- Generally the Confirmation Rule spec requires a number of arbitrary `BeaconStates` to be used throughout the code. This is different from the other spec, where a single `BeaconState` is basically enough for calculations. In practice it requires 2-3 (4 in some rare cases) distinct state to calculate the next confirmed block.
In our current prototype we use just a single justified state for the sake of simplicity.

- The latest fixes ([#25 Add empty slot recovery](https://github.com/mkalinin/confirmation-rule/pull/25)) introduced new weight calculation `compute_chain_prefix_support_between_slots()` which is not compatible with the Protoarray implementation and hence was implemented naively for now

- Also the `compute_chain_prefix_support_between_slots()` function needs to know votes assigned slot, but it doesn't contained in the `LatestMessage` struct, that's why another state is required for vote slot calculation. In the implementation however we did add the `slot` field.
It doesn't look like a good idea to add the `slot` field to the spec as it would be a duplicate information in the `Store`