---
tags: hard_fork_1
---

# HF1 changes in a nutshell
## High level changes
* First class light client support via sync committees
* Incentive accounting reforms, reducing spec complexity and reducing the cost of processing chains that have very little or zero participation for a long span of epochs
* Fork choice rule fixes to address weaknesses recently discovered in the existing spec
## Beacon State
The following fields will be added to the beacon state.

# For accounting reforms. `pending_attestations` will be removed.
previous_epoch_participation: List[ValidatorFlag, VALIDATOR_REGISTRY_LIMIT]
current_epoch_participation: List[ValidatorFlag, VALIDATOR_REGISTRY_LIMIT]
# For light client support
current_sync_committee: SyncCommittee
next_sync_committee: SyncCommittee

`SyncCommittee` is a new internal beacon state object and it is defined as:

class SyncCommittee(Container):
    pubkeys: Vector[BLSPubkey, SYNC_COMMITTEE_SIZE]
    pubkey_aggregates: Vector[BLSPubkey, SYNC_COMMITTEE_SIZE // SYNC_COMMITTEE_PUBKEY_AGGREGATES_SIZE]

## Beacon Block
The following fields will be added to the beacon block body.

# For light cient support
sync_committee_bits: Bitvector[SYNC_COMMITTEE_SIZE]
sync_committee_signature: BLSSignature

## Block processing
For processing beacon block, below are the main changes.
* `process_operations` is modified for the new processing functions
* `process_attestation` is updated for account reforms
* `process_sync_committee` is added for light client support

#### `process_operations`
As part of `process_operations` we process attestations (`process_attestation`) and deposits (`process_deposit`). In `process_attestation` we calculate the proposer reward based on the timeliness of the attestation with respect to: head, source, target. In `process_deposit` we initialize participation flags for the new validator.

#### `process_sync_committee`
In `process_sync_committee` we want to reward sync committee participants and the proposer whenever the sync committee signs over the previous slot block root. We want light clients to be able to determine the head of the chain, and since the block in the last slot is the head, that's what should be signed. We use `get_sync_committee_indices` to figure out who is in the sync committee. Then we check who participated in the signature and verify that the correct block root has been signed. Lastly, we calculate and issue rewards for participants and the proposer.

## Epoch processing
For processing epoch, below are the main changes
* The original `process_rewards_and_penalties` is modified to use participation flag deltas
* The original `process_justification_and_finalization` is modified to use participation flag. In particular it is using `matching_target_attestations` instead of `matching_target_indices`
* `process_sync_committee_updates` is added to rotate sync committee in state
* `process_participation_flag_updates` is added to rotate epoch participation in state

#### `process_justification_and_finalization`

When updating justified checkpoints in the state in `process_justification_and_finalization`, the condition for the update changes. We now take the total balance of unslashed participating validators which have timely attested to the target and check if it's at least 2/3 of total active balance.

#### `process_rewards_and_penalties`

We increase/decrease each validator's balance based on their participation and whether the inactivity leak penalty should be applied. The exact calculations are performed in `get_flag_deltas` and `get_inactivity_penalty_deltas`.

## RPC

## Validator

## Config