Models

There are many ways to envision the restaking mechanism/layer, and Overload aims to cover the all pragmatic "restaking models" in the future; but to start, we focus mainly on the "many-to-many" model, which we will described below.

There are three major restaking models. The one-to-one, the one-to-many and the many-to-many model. Each model has its own trade-offs, and the developers will have decide which they want to support for their project. For the first rollout of Overload, we only deploy the many-to-many model of restaking.

One-to-one

For the one-to-one graph, it's similar to depositing and transacting with an ERC-20 directly. This case is ignored by Overload, as there's no need for any additonal code in this scenario. The target contract for restaking will not need any additional logic to function.

When you interact with any contract that calls ERC-20 tokens with transfer or transferFrom, that's a one-to-one relationship.

One-to-many

With the one-to-many model, it becomes possible to implement stake-leveraging for an operator (but not the restaker). This enables your ERC-20 tokens to secure multiple AVSs, compared to the one-to-one model that only allows a single AVS to be secured.

One drawdown of the one-to-many model is that it's up to the operator to decide which AVS is to be validated. We only recommend this model when slashing is required, as we'll see that slashing is infeasible in the many-to-many model. In other words, for AVSs that strictly require slashing, we recommend them building on top of a one-to-many model of restaking.

In conclusion, the trade-off made in the one-to-many model is that you reduce flexibility in restaking (the operator decides what to restake to, not the user) in-exchange for slashing of stakes being possible. An example of a protocol that implements the one-to-many model is EigenLayer.

Many-to-many

Finally, with the many-to-many model, restakers have complete control over their restaking and slashing is never possible.

The many-to-many is theoretically the optimal solution for restaking, although in production it is infeasible to implement slashing because of the exponential amount of restaking states to loop over.

Let V be a validator, R_n be the number of restakers for a validator, and D_μ be the average number of restakings that restakers have, for the validator V. Then, to slash a validator, you would need to SLOAD and potentially SSTORE at most R_n * D_μ slots. This quickly gets out of hand as both variables grow, and there would not be enough gas to slash a validator onchain.

To circumvent and make this an non-issue, we introduce jailing of validators. By jailing a validator, you kick them from the validator set; forcing them to miss out on attestation rewards as well as having their assets locked inside the Overload.sol contract for a specified amount of time.

We deem this solution as sufficient as Overload makes all slashable offenses impossible because of onchain consensus and consensus contracts. Because attestations are posted onchain directly, previously slashable offenses such as double-signing become impossible. Hence, the only least critical slashable offense would remain, which is inactivity leak/lack of liveness.

Ethereum solves inactivity of validators through "inactivity leak". When a node goes offline, they slowly bleed Ether from their stake, until it reaches 16 Ether and eventually gets kicked from the validator set. Overload solves it through stricter liveness requirements (that developer can adjust), and jailing of validators.