# Oracle Based SSV Contracts

***The below is a NON binding, nor fully developed idea for making the SSV contracts cheaper, faster and more decentralized + adding an SSV staking for securing them.
This is aimed for discussion purposes only***

SSV is a DVT network that has the goal of transitioning a substantial amount of ETH (at stake) to be DVT based. That requires a massively scalable DVT network.

One part of scale, specifically in a developer focused protocol like SSV, [is cluster formation](https://alonmuroch-65570.medium.com/rationalizing-dvt-cluster-formation-5c5440a4b39d).
At the heart of cluster formation there are a set of contracts that serve for: zero coordination cluster registration, data availability and settelment.

A next generation SSV contracts set should aim to improve/ facilitate: fee abstraction, clsuter at scale management (thousands of clusters for a single account) and reduce gas cost by 30-50%.

**Current Design**
Current SSV contracts design has in its core the cluster as a unit of accountancy (manages own balances, fees, etc.).
That design was chosen to save on gas cots when registering a new validator.
The implications are that each cluster needs to be 'topped up' with SSV tokens to cover both network and operator fees.

In addition, operators can either set an SSV fee or set zero fee and settle outside the protocol.

The majority of gas cost in registering a new validator comes from updating fee indexes for all operators, similar to [Compound's accrued interest calculation](https://docs.compound.finance/v2/#protocol-math).

**Oracles Based SSV Contracts**
To reduce gas costs and manage fees on account level (instead of cluster level) we can adopt an oracle based approach that reduces computation and storage when registering a new validator.

An oracle will provide periodic snapshots for each account, including: array of ERC20 updated balances, array of burn rates for each ERC20 token.
All balance calculation is done off-chain, it's deterministic since operations affecting balance (registering/ removing validators) are on chain as well.

The above data is enought to drive all necessary accounting functions for on-chain settlement + complete fee abstraction (supporting multi ERC20 balance for each account).

Snapshots will use merkle proofs to not overload the ethereum network with data.

Open Issues:
* Registering validators between snapshots can create ugly edge cases (example: attacker registers 1000 validators with no balance and enjoys "free" service until the next snapshot). **SOLVED BELOW**
* Long periods of instability that cause oracle to not agree on new snapshots
* Long periods of instability on ethereum can cause long periods of non updated snapshots
* Snapshot data availability - requiring uploading the entire snapshot data via calldata is too expensive, espcially for voting. **SOLVED BELOW**

**In-Between Snapshot Validator Registration**
Between snapshots users can register validators, creating periods of doubt as to whether an account actually has enough balance to cover costs.
The above can go to the extreme with an attacker registering many validators in-between snapshots to "benefit" from free validation.

Although between snapshots there is some "on-chain" imbiguity as to current burn rate, for off-chain node listening to register validator events there is none.

Nodes can be configured to ignore validators operating under an account with some lower than threshold balance even before it's burn rate and balance is updated via snapshot.
An attacker trying to manipulate the system in this way will simply waste gas fee registering validators.

**Data Availability**
Usually when submitting a merkle root as a snapshot, the entire merkle tree's data needs to be provided in the transaction as well. Otherwise no one can provide proofs to the tree as the data is not publicly availabe.

In the context of an SSV contract that data is eve growing which can create some serious limitations, luckily that data already exists and can be calculated publicly and permissionlly.
The SSV snapshot is not submitting some previously unknown data on chain, it's merely an affirmation of publicly calculated data (calculated by fired events from the contract).
As long as there are < 1/3 malicous SSV stakers submitting votes on new snapshots, the data for a finalized snapshot is available by everyone.

**Decentralized Oracles**
To reduce the concern of centralized entities controling the SSV oracle, a decentralized oracle approach can be used.

SSV holders can stake their tokens, or delegate them to existing stakers.
A special software, SSV Oracle Client, will be run permissionleslly to participate in oracle snapshot provision.

Each period, stakers will vote on a snapshot root they think is the right one. If a root receives >= 2/3 of votes (out of the existing staked SSV pool) it's finalized and becomes the latest agreed uppon snapshot.
Think of it as continous on-chain governance as an oracle protocol.

Snapshots are deterministic as they are calculated from on-chain data, honest stakers will easily calcute them.

As rewards for this work, stakers will divide between them all the collected network fee in a specific period.

**Decentralized Oracles - 67% Attack**
Fee abstraction creates an incentive by an attacker to purchase enough tokens to take over the SSV staking set and submit a snapshot which gives all assets in the contract to the attacker.
If total assets are worth more than the attack it becomes pluasible vector.

The amount of assets locked in protocol can be calculated as a derivative of # of validators, ETH price, average ethereum rewards rate(ERR), % of rewards as operator fee, % of rewards as network fee and the duration (runway) of fee the average account holds.

The below plot is for the function $Fee_{TVL}/(0.67*Price_{SSV})$

$Fee_{TVL} = Validator Count * ETH Price * ERR * (operator fee \% + network fee \%) * Duration / 365$


$Fee_{TVL}$ is a value derived from the above but inputed as variable, SSV price is a variable as well.
The 3D model above shows how much SSV needs to be staked (axis Z) as a function of $Fee_{TVL}$ (axis x) and SSV price (axis y)

Another way of looking at it is the amount of SSV needed to be staked for each additional validator to make the protocol safe.
Below is a simple example (though fairly edged cased) where:
* ETH Price at $5,000
* ETH APR is 0.05
* Operator + Network fee are 5% of rewards
* SSV price $20

Any additional validator will require 29.85 SSV tokens to be additionally staked to be secure.
At 10K validators - 298,500 SSV
At 100K validators - 2,985,000 SSV
At 368,509 validators - 11M SSV

The scale of the network will depend on the stregnth of SSV/ETH price.

[Link to google sheet](https://docs.google.com/spreadsheets/d/1DvsT5xQ5VjdyVQQS3apNZCh0529GnZujiiBP89an3RU/edit?usp=sharing)

**Decentralized Oracles - <67% Attack (liveness attack)**
An attacker can controll less than 67% of the stake and try to prevent any finalization of new snapshots.
This will cause delays in the ability to withdraw assets from the protocol.

Operators will still be keeping track of new events so practical protocol functioning doesn't change.

**Generating a Snapshot**
Every node keeps track of the following events: register/ remove validator, change operator fee, deposits/ withdrawals.
A node will keep a local balances and burn rate calculations for every account, updated immediatley with every new event.

On every N'th finalized beacon block, a new snapshot root will be generated locally by each node. The root of the snapshot will be postend onchain for voting.
The root with 2/3 of staked SSV votes will be finalized.

Entry for each account:

{
"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2":[10000000000000000000, 100000000000000000], // weth
"0x9D65fF81a3c488d585bBfb0Bfe3c7707c7917f54": [10000000000000000000,110000000000000000] // ssv
}

Simple merkle tree construction and root

The size of proof for a regular merkle tree is O(log2 n). Choosing the right type of tree suitable for contracts is TBD

**Operator Fees**
Each operator will set what ERC20 tokens it accepts as fee, only clsuters paying in those tokens could include the operator in the cluster.
Well known ERC20 tokens can be set alongside custom ERC20 tokens which can cover a wide variety of applications.

**Network Fee**
Network fee will be managed in SSV.

**Liquidations**
Current design requires liquidations to happen if an account falls short of some threshold balance, that's due to the index based system used for settelment.

With an oracle based contract system we can drop liquidations by requiring the following rules:
1. Account balance can't go below 0
2. Nodes stop exeucting for a validator if balance drops below some threshold
3. Oracles can't create negative accountancy between users paying fees and operators receiving them