SSV Protocol & Implementation Deep Dive

Secret-Shared-Validator(SSV) is a protocol for distributing the operations of
an Ethereum validator between trustless parties using threshold signatures and
a BFT (consensus) protocol.
For a quick intro please read
this.

This piece includes a deep dive into a full Ethereum, beacon-chain attestation
duty process for an SSV node. This represents a single validator SSV instance
for attestation duties ONLY with code snippets and reference.

All of the info below is relevant to
v0.0.15 of the
SSV node.

Validator Share Management

An SSV node is a piece of software that uses validator shares and network
configurations as input, and if executed properly, outputs an active and
efficient distributed Ethereum validator. Validator shares and network
management can take many shapes and forms, in our case:

1) hard coded shares via config files OR 2) dynamically configure the network
via a set of smart contracts.

Option #2 is the more interesting choice, and will likely be more common.

An SSV node is connected to an Ethereum node (known as eth1, or, ‘execution
layer’) to fetch events originating from the management smart contracts. The
smart contract’s main duty is keeping a registry of operators and a list of
validators (who assign shares to operators).
Every time a new operator or
a new validator is created (by submitting an on-chain tx) the node picks it up
and stores the data locally.

Every SSV operator has a unique ID and a public encryption key used by users
to encrypt the operator shares. If an operator is selected to host a network
validator it will parse the new encrypted share and store it locally.

The
data structs
used for the process are the following:

A new found share will also trigger the addition of a new
validator management struct
— which is responsible (from the moment it’s added), to manage all future duty
executions.
When a new validator struct is initialized, another
important
piece of code executes the creation of new Istanbul BFT handlers. This process
is comparable to ‘mini’ blockchains for each validator and for each duty type.

Each iBFT handler has a unique
identifier
(lambda) which helps separate them, the identifier is deterministic and
constant.

Another important struct to get familiar with is the
share
structure. This struct holds all the information needed (other than network
configuration) for the SSV node to successfully participate and contribute to
the network.

Duty Execution Life-Cycle

When a validator has a new duty scheduled, it will trigger a pipeline of tasks
that will need to be executed correctly in order for a valid signed duty to be
broadcasted to the beacon chain network.

The main
execute duty function
is rather straightforward, encompassing in it all the steps described above.
The function is triggered by a controller which listens, and fetches scheduled
duties the same way a ‘normal’ validator client would.

Blue Steps — Fetch Duty, Duty Data and Validation

The steps marked in blue are grouped together since they are very similar to a
‘normal’ validator client operation. More specifically, scheduling a duty
(within a particular slot), fetching the duty data (for an attestation, the
attestation data) and validating the duty data.

Validating duty data should involve slashing protection as well, however it’s
not yet implemented in the SSV node. The whole slashing protection and signing
methods
should be refactored
completely, which is not yet completed for v0.0.15.

The duty data, in our case the attestation data, is the input for the next
step — the consensus step.
Each node fetches the duty locally and will
try to propose it to the other committee members to sign. There is no
guarantee that the fetched attestation data will be decided on.

Yellow Steps — Consensus

The consensus part of the pipeline is the heart of what makes SSV so robust
and secure. Our implementation uses the
QBFT protocol- a 3 step BFT
protocol which finalizes every instance (comparable to blocks).

QBFT also prioritizes safety over liveness which means that if >f nodes are
down it might take a while to recuperate.

To try and reduce the effects of the above we’ve implemented a quick sync protocol which is a major improvement.

QBFT has 3 steps (with the 4th one a state) in a happy flow:

• Pre-prepare — a deterministic leader sends a proposed input
  data (the fetched attestation data from previous steps) to all committee
  members
• Prepare — Each individual member verifies the input data
  (which includes slashing protection). If the data is valid it will send a
  prepared message indicating he is willing to commit to that data.
• Commit — If 2f+1 prepare messages are received the node
  will send a commit message to all other members.
• Decided* — Not strictly a “step” but rather a state
  achieved if 2f+1 valid commit messages are received.

A QBFT message has the below structure:

• Type — message type (pre-prepare, prepare, etc,)
• Lambda — consensus identifier as calculated
  here
• Sequence Number — unique identifier of a specific instance
  of QBFT which is incremental.

Instance x+1 can’t start if instance x hasn’t decided. An instance is the
execution of a duty.

• Value — the input value to decide on.

Each QBFT message goes through a pipeline of verification, validation and
(upon confirmation) execution steps. This was created with a synchronous
architecture in mind to simplify implementation.

The pre-prepare pipeline above takes as input a pre-prepare message, validates
it’s content, type, identifier (lambda), round number, sequence number,
signature, leader and if all passes, then executes it according to the QBFT
protocol.

If the committee can’t decide within the first round, a change round protocol
is initiated. It includes exponential timeouts, each time it fails, attempts
again until it reaches a consensus.

Orange Steps — Post Consensus

The consensus step returns a decided value which, (should be), a valid
attestation data struct similar to the below one (taken from the
eth2.0 spec)

The next steps are for signing the attestation data with the share key,
resulting in a partial signature which is broadcasted to all the other
members. 2f+1 partial signatures are required to reconstruct
a valid signature (against the validator’s public key).

Waiting for the other signatures is straightforward, limited only by
a timeout.

It’s important to note that this step may fail even if consensus was achieved,
for example 2f nodes could drop offline which will result in insufficient
collected, partial signatures. If this step fails then the validator will miss
an attestation.

Signature reconstruction is using the native Herumi BLS library functions.
Behind the scenes it uses Lagrange interpolation to reconstruct a valid
signature. I’ve written about it
here
and Dash research wrote about it
here.

Summary

The SSV protocol and implementation should be as clear and deterministic as
possible, one of the goals the community should have is a formal spec for SSV
that can serve for additional implementations and as a reference.