# Slot timings and ePBS

There seems to be a big push driven by the community (or Paradigm perhaps, it's not clear to me) in having shorter slot times. In this quick note I'll conjecture what I expect to be the actual limits for slot times under ePBS vs the current mechanism or the proposed [delayed execution](https://eips.ethereum.org/EIPS/eip-7886) one.

:::danger
Remembering that the real bottleneck to scaling today is bandwitdh and blob propagation time. Whatever we do, we need to allow for larger times for heavy data propagation. Blob verification is very cheap, the longer the time we have for blob propagation, the more free DA we get to scale.
:::

## Block broadcast, attestation deadline.

Experiments on geographically decentralized devnets with larger block broadcasting show that we have reliable broadcasting in less than 2 seconds for up to 6MB blocks and less than 800ms for 1MB blocks.


These suggest that for the current consensus mechanism we should be fine, even with more blobs, to have an attestation deadline at about 3" into the slot. This is because we can try to push the boundary of MEV-Boost signing to just one roundtrip, broadcast everything from the relayer, assume that blocks and blobs have arrived completely by 2 seconds into the slot and then execute the block CL + EL, and validate DA.

With EIP-7886 we do not need to validate the EL execution (or most of it) so we can probably shed part of the processing that corresponds to executing the block. So reallistically we expect a possible deadline of 2 seconds plus the CL execution plus the static part of the EL execution when using EIP-7886 for this part of the slot, I will put this at 2.2 seconds based on the current status of execution, but it is some number above 2 seconds.

EIP-7732 gives us something more: we do not need to broadcast neither the payload nor the blobs at this stage, so only the beacon block needs to be broadcast, which is much smaller than that execution and the blobs!. In our experiments even at the lower level of 1/2MB, which is 4 times the current full block including the payload, blocks where fully distributed in under 300ms! This means that if we broadcast only the consensus block under EIP-7732, we can safely assume that the block will be completely distributed and executed (since again only the CL execution is needed now) by 1 second into the slot.

:::success
This is only possible because ePBS decouples the broadcasting of the CL block from the EL and blobs, this makes the hot path much more efficient compared to the current specification and to EIP-7886.
:::

## Payload broadcast -- aggregation
Meassurements on current mainnet show that 95% attestations arrive to a node in under 1 second. So the builder under ePBS and the aggregators in general can be forced to reveal the payload and produce aggregates 1 second after the attestation deadline. With the above numbers this would be about 2 seconds for ePBS, 3.2 seconds for EIP-7886 and 4 seconds for the current consensus mechanism.

## Blob broadcat
On the current consensus and EIP-7886, the blobs broadcasting bottleneck is on the hot path blobs are broadcat at 0" into the slot and need to be validated by attestation deadline. This is
### PTC observers
This is something that only applies to ePBS, there needs to be another round that involves the payload being observed by the PTC members and then the attestation being delivered to the chain. This has to be a full broadcast of the payload (which we counted above as 2 seconds in the worst case) plus a full broadcast of these 512 attestations, which reallistically are much less than a second as they are just a few bytes, but we will count them here conservatively as 1 second. This means that ePBS requires at least 3 more seconds after the payload reveal time, putting the minimum slot time that I expect at about 5 seconds for ePBS.

There are other tasks that are being done in parallel by nodes, like getting the aggregates, accounting forkchoice and executing the payload, but ePBS gives more time for this that both the current mechanism and EIP-7886 thus we have already accounted for them in the above.

On the other hand, EIP-7886 and the current consensus mechanism do not need these extra 2 seconds for the broadcast (as they were already accounted for) so we only need to account for the 1 second for aggregations to arrive on nodes. This puts the total slot time for EIP-7886 in about 4.2 seconds for EIP-7886 and 5 seconds for the current consensus mechanism.

### Conjectured minimums at expected latencies.

- Slot time: the total expected slot time, lower is better
- Block execution: the time allowed to execute the payload, higher is better.
- DA broadcast and validation: the time allowed for blobs over the wire + validators to check they were available, higher is better.

| Consensus | Slot time | Block Execution | DA Broadcast and Validation |
| --- | --- | --- | ---
| Current | 5" | 0.2" | 2.2" |
| EIP-7886| 4.2" | 2.2" | 2.5" |
| EIP-7732| 5" | 1" | 4" |

:::info
I am being overly conservative in giving 1" for CL broadcast and 2" for CL+Payload+Blob broadcast. Any difference between these numbers tilts the table more towards ePBS.
:::