Fragments is a DKG framework for the SSV network, inspired by the MEV-Boost architecture.
An initiator (who wants to perform a DKG ceremony) will run a Fragments relay, connecting via restful API to other Fragments clients (run by SSV operators).
Fragments relays all messages between the DKG session participants, using simple restfull http.

This design accomplishes the following goals:
* Simplicity - this design has proven to be working and uses well tested components (restful api)
* Diversity first - the DKG boost api enables connecting multiple dkg client implementations, enabling a diverse solution for a complex and ever evolving problem (distribuited key management)
* Verifiability - the initiator being the the relay for all messages will be able to track progress and verify results


## Components
### Fragments Relay
Fragments relay runs on the initiator's machine with a list Fragments clients it wants to perform a DKG ceremony with.
It calls various functions, using the Fragments API (see below)

**Why relay all messages through the initiator?** It's a simple solution for networking and discovery between peers (there is none as the relay passes messages).
Furthermore it puts the control in the hands of the user that will actualy deposit the validator.

### Fragments Client
Runs on the operator's machine, exposing the Fragments API for relays to call to.

### Fragments API
A restful API running as part of the Fragments client.
**Why restufl API?** It's well suited for request-response communication, authentication, secure and scalable.

* [Get] implementations - returns a list of DKG implementations supported by the Fragments client
* [Post] relay - receives a relayed message from Fragments relay, processes and returns an answer message to the relay
* [Get] output - returns the output for a previously executed DKG session

### DKG Implementation
A unique DKG implementation developed to be intergrated to (via grpc/ http/ etc) locally to the Fragments client.
The client will route messages to the implementation and will return responses.

### SideCar API
An API exposed by the SSV node

* [Get] operatorPK - returns an operator public key (synced from the SSV contracts) by ID
* [Post] sign - signs a message with the operator private key

## Authentication
Fragments relay and clients authenticate messages using the operator's rsa keys registered on the SSV contracts

## Messages

type TransportType uint64

const (
	InitMessageType TransportType = iota
	ImplementationMessageType
	InitReshareMessageType
	ExchangeMessageType
	OutputMessageType
)

type Transport struct {
	Type       TransportType
	Identifier [24]byte `ssz-size:"24"`     // | -- 20 bytes address --- | --- 4 bytes nonce --- |
	Data       []byte   `ssz-max:"8388608"` // 2^23
}

type SignedTransport struct {
	Message   *Transport
	Signer    uint64
	Signature []byte `ssz-max:"2048"`
}

type Init struct {
	// Operators involved in the DKG
	Operators []uint64 `ssz-max:"13"`
	// T is the threshold for signing
	T uint64
	// WithdrawalCredentials for deposit data
	WithdrawalCredentials []byte `ssz-max:"256"` // 2^23
	// Fork ethereum fork for signing
	Fork [4]byte `ssz-size:"4"`
	// Nonce for registering the validator in the SSV contracts
	Nonce uint64
}

// Exchange contains the session auth/ encryption key for each node
type Exchange struct {
	PK []byte `ssz-max:"2048"`
}

// Output is the final message sent by each participant
type Output struct {
	EncryptedShare                 []byte `ssz-max:"2048"`
	SharePK                        []byte `ssz-max:"2048"`
	ValidatorPK                    []byte `ssz-size:"48"`
	DepositDataPartialSignature    []byte `ssz-size:"96"`
	DepositValidatorNonceSignature []byte `ssz-size:"96"`
}

// example
const (
	KyberDealBundleMessageType TransportType = iota
	KyberResponseBundleMessageType
	KyberJustificationBundleMessageType
)

// ImplementationMessage contains implementation specific message
type ImplementationMessage struct {
	Type TransportType
	Data []byte `ssz-max:"2048"`
}