# SSV Smart Contracts v3 Alpha Release
After 6 months of researching, building, and iterating, we are excited to share the alpha release of our smart contracts v3 which will be utilized in our next testnet, scheduled to roll-out during March.

This release marks a significant milestone in the development of the SSV protocol. The scale and nature of improvements over the previous version are significant and we now feel confident to declare it as our **release candidate**.
:::warning
Please note that this release contains breaking changes to previous integrations, which requires adjustments in order to be compatible with the next testnet.
:::
## Introduction
To decentralize Ethereum, Ethereum’s security must be in the hands of as many people, entities or node-operators as possible.

To support this vision, and for distributed validator technology to be adopted as the new benchmark for validator operation, integration costs must be not only as **low** as possible, but also **predictable** at scale.

With this notion in mind, we have redesigned our smart contracts to support usage at scale in a way that also significantly reduces costs.

## Existing Architecture
Before diving into the new design, it’s worthwhile to outline the existing smart contract architecture as a jumping point for upcoming changes.

In our v2 design, a user (or staking application) would manage all of their validators under a single ***account struct***, that shares the same ***liquidation collateral*** and ***operational runway***, which are aggregated and managed through a single ***account balance***:


With this architecture, account balances were easy to manage, but cases of liquidations are devastating as it would result in all validators under the account to go offline.

Managing a shared balance required a lot of computation to calculate payments between stakers and operators, and resulted in very expensive contract interactions, which grew exponentially as more different operators were chosen to manage validators.

#### Registering 10 validators to the same operators set:
| Action | Gas Cost |
| -------- | -------- |
| 1st validator | 719015 |
| 2st validator | 503368 |
| 3rd validator | 503368 |
| 4th validator | 503368 |
| 5th validator | 503368 |
| 6th validator | 503368 |
| 7th validator | 503368 |
| 8th validator | 503368 |
| 9th validator | 503368 |
| 10th validator| 503368 |
| **Average per validator**| **524932** |

#### Registering 10 validators to unique operator sets:
| Action | Gas Cost |
| -------- | -------- |
| 1st validator | 719015 |
| 2st validator | 690412 |
| 3rd validator | 777360 |
| 4th validator | 828357 |
| 5th validator | 915305 |
| 6th validator | 966303 |
| 7th validator | 1053251 |
| 8th validator | 1104250 |
| 9th validator | 1191199 |
| 10th validator| 1242198 |
| **Average per validator**| **948765** |

Although highly simple to manage, the ***account struct*** based architecture presents a very high cost of integration, which is not sustainable for scale of use by large staking applications, especially ones that would want to utilize a wide variety of different operator sets - a design preferred by many players in the industry and also within the SSV developers ecosystem

## Introducing v3
The main goal of our v3 contracts is to mitigate the shortcomings of the previous design, in a way that reduces integration costs to a minimum, and supports the use case of utilizing a vast amount of operator sets at scale.

The new design consists of two major changes to our smart contracts architecture - **cluster structs** and **state inputs**.

### Cluster Structs
In v3, a modular structure was implemented that transitions from the ***account struct*** to a ***cluster struct*** design, in which user’s validators are managed within Clusters - the group of operators that were selected to manage them.

Clusters are unique to each account and they manage their own ***liquidation collateral*** and ***operational runway*** under a ***cluster balance***, which is isolated from any other cluster.

With this architecture, multiple balances might need to be managed (depending on the variety of clusters utilized), but cases of liquidations are more lenient as they only affect the validators within that cluster.


### State Inputs
Payments between stakers to operators are facilitated by SSV smart contracts, which keeps a balance sheet for all network participants.

The calculation of payment flows between the network participants requires storing many variables for each account to track its balance at any single point of time.

Storing data within smart contracts is very expensive, and constitutes the main basis of high transaction costs.

To reduce the costs associated with storing data, v3 utilizes the usage of state inputs instead of on chain storage.

State inputs come in the form of a **cluster object** which contains the latest cluster snapshot data.

Cluster snapshots are used during interactions with cluster related functions through the SSV smart contracts which require the **cluster object** as input:

* registerValidator()
* removeValidator()
* deposit()
* withdraw()
* getBalance()
* reactive()
* isLiquidated()
* isLiquidatable()
* liquidate()

Cluster snapshots are updated after each cluster interaction, and will emit a new **cluster object** which will be required for making the succeeding interaction.

To obtain cluster snapshots, you could use the newly developed tool called `Cluster Scanner` that enables users to retrieve the latest cluster snapshot for a provided cluster from our smart contract.

Alternatively, you could just save the **cluster object** emitted in the transaction event after each interaction, and use it as the input for the succeeding cluster related contract interaction.

### Savings Summary
Applying these changes to our smart contracts architecture greatly reduces integration costs and enable users to onboard validators and manage them at scale in a predictable way - integration costs are as low as swapping a token on a DEX, and the cost of running a single validator on our network would be the same as running the 1000th validator:

#### Registering 10 validators to the same operators set:
| Action | Gas Cost |
| -------- | -------- |
| 1st validator | 206965 |
| 2st validator | 164839 |
| 3rd validator | 164839 |
| 4th validator | 164839 |
| 5th validator | 164839 |
| 6th validator | 164839 |
| 7th validator | 164839 |
| 8th validator | 164839 |
| 9th validator | 164839 |
| 10th validator| 164839 |
| **Average per validator**| **169051** |

#### Registering 10 validators to unique operator sets:
| Action | Gas Cost |
| -------- | -------- |
| 1st validator | 206965 |
| 2st validator | 206965 |
| 3rd validator | 206965 |
| 4th validator | 206965 |
| 5th validator | 206965 |
| 6th validator | 206965 |
| 7th validator | 206965 |
| 8th validator | 206965 |
| 9th validator | 206965 |
| 10th validator| 206965 |
| **Average per validator**| **206965** |

In comparison to our previous architecture, registering a validator to the same cluster in v3 is **~70%** cheaper than in v2, and registering validators to unique clusters is not only **~80%** cheaper but also in a constant way that disregards the number of unique operators.

| | v2 Costs | v3 Costs | Diff. |
| -------- | -------- | -------- | ------ |
| Registering 10 validators to the same operators set | 524932 | 169051 | **-67%** |
| Registering 10 validators to unique operator sets | 948765 | 206965 | **-78%** |

## What's Next
With the finalization of our new contracts architecture, the **v3 testnet** is scheduled to launch near the end of March.

This release will mark the end of our v2 testnet, which will shutdown gradually during the following week (official announcement with all the details will be shared soon).

During the v3 testnet, our smart contracts will be **audited** to ensure their security along with recommendations for code optimization and improved performance.

All feedback will be gathered to form our **release candidate**, the last milestone before mainnet, which is very exciting.

With this said, we welcome you all to review our new contracts and tooling ahead of their official release and evaluate which adjustments you must make to be compatible with our next testnet.

Comprehensive v3 documentation will be rolled out over the following weeks to [docs.ssv.network](https:/docs.ssv.network/)

In the meantime if you have any questions, we are here for you.

Thank you for building on SSV and being part of our ecosystem.

## Resources
* [Documentation v3](https://docs.ssv.network/)
* Contracts
* [Github](https://github.com/bloxapp/ssv-network/tree/main/contracts)
* [ABI](https://github.com/bloxapp/ssv-network/tree/contract-abi/docs/testnet/abi/v0.3.0)
* [SSVNetwork Functions](https://docs.ssv.network/developers/smart-contracts/ssvnetwork)
* [SSVNetworkViews Functions](https://docs.ssv.network/developers/smart-contracts/ssvnetworkviews)
* Tools
* [`SSV-Keys v3`](https://docs.ssv.network/developers/tools/ssv-key-distributor) - as part of the changes and optimizations of our smart contracts, the keyshares (sharesPublicKeys and sharesEncrypted) generated by the SSV Key Distributor tool, have been replaced with a single shares variable. To be v3 compatible you must split your validator keys using the new version of the SSV-Keys tool.
* [`Cluster Scanner`](https://docs.ssv.network/developers/tools/cluster-scanner)