# Improving first slot in epoch performance

In Prysm, we have observed the first slot in each epoch has considerable delay with attestation production compared to other slots in the epoch. This document outlines the current design flaws and potential improvements.

The first slot of each epoch has some additional required work. Namely, we must update our validator duties for this current epoch. However, we also do much more than update duties.

First slot tasks (blocking):
1. Fetch epoch duties
1. Determine which subnets to subscribe

Item 1 is a hard requirement, we simply cannot perform any duties if we do not know what they are. However, the second item is actually not required to start performing the assigned duties. Additionally, the second item may be reduced in total work as some of the work being performed is not required.

Looking at [this span](https://jaeger.prylabs.network/trace/01498d06a101cf971a438d1a32efd43f) (note: spans pruned after 7days), we can see that UpdateAssignments took 17s in the first slot. This obviously exceeds any deadline to produce an attestation in the first slot.


Why did it take so long? 15 seconds of this was spent in BLS signatures to determine which attester duties were also aggregators for approximately 1000 keys. This is part of item 2.

## Suggestion 1: Make subnet subscription non-blocking

Imagine we didn't do any subscriptions prior to submitting an attestation. The attestation would be blocked in publishing until a peer can be found within the relevant committee subnet. This can lead to delays in attestations leaving the beacon node, but it is still better than the validator failing to sign the attestation as the duty window has passed.

_An attestation is still valid for 2 epochs, so a delayed attestation is acceptable._

💡💡 The suggestion is not to delete all preemptive subnet subscriptions, rather we allow the validator to start performing its duties while subscription computation and submission to the beacon node occurs in another go routine.

## Suggestion 2: Remove aggregator computation from subnet subscription method (Invalid)

Given that an aggregator is an extension of an attester, the beacon node does not need to perform additional pubsub subscriptions to support this behavior. In the span linked earlier, this behavior represents 15 seconds of blocking behavior.

🤔 Why does this behavior exist today?

Answer: Attesters need to connect to peers subscribed to each relevant subnet topic, but they do not need to actually listen to each topic since they publish only.

Given that answer (thanks, Nishant!), this suggestion has invalid assumptions and is no longer considered.