# SSV during re-orgs (lesssons learned from Prater)

## Overview
During the last few days 24-28th Aug 2022 the Prater network saw major drop in participation rates due to testing by the lighthouse team.
During that time major chain re-organizations occured which effected how each node in the SSV network "perceived" the duties it had to execute.

2 main issues occured: 1) LH and Prysm nodes returned different duty sltos and 2) The duties returned had different committee data which failed the final post consensus step where partial attestation signatures are reconstructed

Validator [357656](https://prater.beaconcha.in/validator/357656) was operated by 4 SSV nodes, 2 running Prysm and 2 LH.
During slot epoch 117616 the LH nodes returned duty at slot 3763737 and Prysm nodes returned duties at 3763739 with different committee data.

## Issue #1 - Include duty in consensus data
Current SSV versions (running on the Shifu testnet) do not include the duty itself in the data going into the consensus phase, only the attestation data is decided upon.
Then each node takes the decided attestation data, uses it's locally fetched duty and partially signs the attestation.
Nodes wait to receive a quorum of partial signatures with the same root and then reconstruct a valid signature.
Not including the duty in the data going into the consensus phase breaks liveness.

In SSV spec [>V0.2](https://github.com/bloxapp/ssv-spec/blob/main/types/consensus_data.go#L45-L53) the duty itself is included in the consensus data to avoid that issue.

## Issue #2 - dafny DVT spec fix
Current [dafny DVT spec](https://github.com/ethereum/distributed-validator-specs/blob/dafny_spec/src/dvspec/dafny/specification/dvc_spec.dfy#L80-L98) calls for nodes to execute every sequential epoch so to not "skip" any epoch with a duty.
Actual consensus instances are marked by their slot, the above shows that under re-org cases that doesn't hold anymore