# SSV Notes

1. Attester:
a. No preconsensus stage
b. Consensus: broadcasts SSVPartialSignatureMsgType
c. Post Consensus: sends attestation to beacon chain
d. Execute Duty: runs consensus

*Lifecycle*: For each validator expected to happen twice in a epoch (add better explanation)

3. Aggregator:
a. Preconsensus: Wait for Quorum. validate and process signed message. Creates aggregate selection proof. Starts consensus.
b. Consensus: Reaches consensus on a partialSignatureMessage and wraps it in SSVPartialSignatureMsgType. Broadcasts it
c. Post consesnsus: Aggregates sigs and broadcasts to beacon chain
d. Execute Duty: Creates a single signature on slot and broadcast it as SSVPartialSignature Type.

*Lifecycle*: For each validator expected to happen once per epoch (add better explanation)

5. Proposer:
a. Execute Duty: broadcast SSVPartialSignatureMsg that signs the randao
b. PreConsensus:receives the above msg. If there is a valid quorum start consensus
c. Consensus: runs consensus to get the full block to propose
d. Post consensus: reconsturct sigs and submits block to beacon chain

*Lifecyle*:

Expected to happen once per epoch? (add better explanation

7. SyncCommitteeAggregator:
a. Execute Duty: sign SyncAggregatorSelectionData. Send as SSV partial signature
b. PreConsesnus: receives the above msg. If there is a valid quorum get from beacon node the committee subnet ID and contribution. Run Consensus on it.
c. Consesnsus: Wraps signed proof of contribution and sends it.
d. post consensus: reconstructs sigs and submit contribution to beacon chain

9. SyncCommittee:
a. Execute Duty: gets sync committe block root from beacon chain and starts consensus
b. Preconsensus: none
c. Consensus: decides on committe block root
d. postConsensus: Create sync Comittee message and submit to beacon chain

11. ValidatorRegistration:
a. Execute Duty: create a message to be signed for registration. Partially sign it and broadcast to ssv network.
b. PreConsesnsus: Base validation only
c. Consensus:

Sync Messages:
On bootsrap we need to get justified heights from 4 different nodes
While running if we see a higher height from F+1 nodes in our quorum then we go to bootstrap mode.

DKGMsgType exists?

### Consensus Message Strategy

type Message struct {
    MsgType    MessageType
	Height     Height // QBFT instance Height
	Round      Round  // QBFT round for which the msg is for
	Identifier []byte `ssz-max:"56"` // instance Identifier this msg belongs to

	Root                     [32]byte `ssz-size:"32"`
	DataRound                Round
	RoundChangeJustification [][]byte `ssz-max:"13,65536"` // 2^16
	PrepareJustification     [][]byte `ssz-max:"13,65536"` // 2^16    

}

type SignedMessage struct {
	Signature types.Signature    `ssz-size:"96"`
	Signers   []types.OperatorID `ssz-max:"13"`
	Message   Message            // message for which this signature is for

	FullData []byte `ssz-max:"4219064"` // 2^22 + 2^15 (see SSV message max size)
}

// SSVMessage is the main message passed within the SSV network, it can contain different types of messages (QBTF, Sync, etc.)
type SSVMessage struct {
	MsgType MsgType
	MsgID   MessageID
	Data    []byte
}

For every message one knows:
1. its ID
1. the operator that sent it
1. the validator that sent it

Assume committee of 4. Input comes from beacon chain to start a duty. We are at round `r` and height `h` and we are synced.