[Research] Ethereum Restaking Design
Introduction 1.0
Before diving into this research, here is some insight regarding the source and nature of the information provided. I am a member of Blockswap Labs and am involved in the ongoing development of Blockswap Cloud, a restaking protocol. The thoughts and ideas I offer in this article are based on my discussions with Blockswap Cloud’s engineering team, analysis of various white papers, conversations with people, and research into restaking mechanisms. However, it’s critical to understand that these are high-level ideas. These thoughts might never actualize or may transpire differently than hypothesized. It is also worth noting that while I strive to provide the most accurate and insightful information, my views should not be seen as an official position or representation of Blockswap Labs.
This is a nascent and evolving field. Even just today I had conversations with builders working on restaking peripheries which provided additional insight which I was not able to include. I believe that restaking is a net positive addition to Ethereum and I’m excited to see all market players rollout their solutions.
Do your own research.
Introduction 2.0
Consensus mechanisms and decentralization form the bedrock of Ethereum. They ensure that transactions are correctly processed and agreed upon by all network participants, maintaining the network’s integrity and resilience against possible threats. Decentralization encourages self-aligned actors to look out for their own best interest. As Ethereum evolves and protocols look to reuse consensus mechanisms with restaking protocols, there is an increasing need for careful consideration in restaking protocol design and implementation.
$200 Billion at Risk
Ethereum staking, secured by ETH’s $200 billion market cap, is the backbone of global decentralized computation. With 18% of ETH supply (19.5 million ETH) staked, over 600,000 validators consistently uphold Ethereum’s consensus. The ecosystem manages an average daily transaction value of $11.556 billion, culminating in a $4.1 trillion annual settlement volume. The industry anticipates an increase to 60% ETH staked, signifying the potential for additional security bandwidth in transaction throughput.
Determining Robustness in Restaking
To determine the robustness of a restaking network, it’s important to look at what makes Ethereum resilient and the #1 smart contract network. This will provide a clue as to how a restaking network should be structured. This is making the assumption that what is good for the base chain would also be good for restaking on top of the base chain.
- Individuals look out for their own best interests creating a marketplace of self-aligned users.
- Diversity with no single centralizing entity.
- Openness and permissionless inclusion of everyone, meaning that anyone can participate without a gatekeeper.
- Interoperability allows anybody to build on top without restrictions
Demand for Restaking
Restaking, although a relatively recent term, satisfies long-standing needs by facilitating a cryptographic and on-chain interface between validators and middleware (networks, oracles, L2s, rollups, etc). In its present form, the agreements between middleware and validators do not pose substantial risks to the consensus layer due to their non-direct implications. It is a simple agreement between the validator and middleware without smart contract enforcement.
In the context of formulating restaking models, there are two distinct approaches: the bazaar and the cathedral.
The bazaar approach, resembling the current Ethereum consensus model, promotes a marketplace ecosystem where any participant can act as a maker or a taker. This means anyone can become a validator or utilize the network as a middleware. This follows the same principles of maintaining Ethereum’s robustness.
The cathedral approach manages validators or middleware as an aggregate, subject to group agreement or collective liability. This could be implemented on a per middleware and validator agreement basis, or in any situation where individuals can be penalized for the actions of others.
Upon analyzing the existing restaking proposals, a pattern emerges. Middleware requires Ethereum’s security and aims to ensure it through the potential to slash ETH during instances of misbehavior. The validator, who bears the risk of being slashed, accrues rewards from the middleware by fulfilling their expected duties. Despite the high stakes for validators, this model can potentially expand security and efficiency within the Ethereum ecosystem.
The Rise of Individualism
Restaking in the terms of pre-Uber and post-Uber. Cabs used to have a monopoly over the market, if you needed a ride from A to B you only had one option. If your ride was good or bad you couldn’t give a rating, expectations were low because there was no competition or individual accountability.
You get what you get.
Uber introduced a marketplace. It was a matchmaking service between riders and drivers where Uber had little control of individual interactions and only maintained the backend (accounting, monitoring, tracking, safety, rankings, etc). Drivers and riders both got ratings to encourage accountability. There was nothing wrong with the cab system, it was just not utilizing technology and relied heavily on a monopoly, it made them susceptible. That said, it would not be fair to say that cabs are completely obsolete. Often times leaving an airport like LAX the simplicity of entering the cab line is worth the unreliability and lack of accountability.
Restake with Cabs or Restake with Uber?
When looking at how re-staking might be designed we can look at this in two different ways.
Collective Unit (Cabs)
If validators are treated as a commodity and therefore 100% composable it could weaken the incentivization structure of a decentralized community such as Ethereum. This would mean that an issue that did arise could cause systemic risk to all validators and middleware connected creating a centralized attack vector. You can see a similar outcry from the Ethereum community around liquid staking protocols. Clearly treating validators and their yield as a single unit is not seen as the best option.
Individual Unit (Uber)
Alternatively, validators could be treated as unique assets. They each have a different history as node operators. Giving them ratings and allowing them to operate independently is crucial to maintaining a decentralized ecosystem. This is not the individualism of each Staked Lease Agreement but atomically to validators. Giving separation would allow for any issues that arose to be completely localized between two parties rather than a pool of otherwise good actors.
Rewards and Penalties
To maintain the integrity of the base network (Ethereum) and the restaking network, it is imperative that rewards and penalties empower the individual to do what’s best for them, and in turn, do what is best for all networks involved. Each validator must have their own skin in the game with the node operator personally having something they can lose. Another crucial aspect is having incentives in line with the opportunity costs.
As we’ve seen time and time again through liquid staking, anytime validators become grouped together there becomes an inherent lack of accountability. Who cares about slashing or being offline when it’s only a small dip in rewards socialized over all other participants? The real loser here is the end user.
For example, the current effectiveness of the two most popular liquid staking networks are ~97% and ~96% (Rated.network) with APR of 3.8% and 3.11% (Defillama.com) respectively. For reference, these yields should be at 5.9% (ultrasound.money). Is the real loss to a node operator in these networks if they are offline? Or is it just a missed profit opportunity? It appears there is a misalignment of incentives when operators are not directly affected.
From the perspective of middleware that is trying to hire a set of validators, not being able to penalize and reward the individual validators that adhere to the agreed upon Staked Lease Agreement may hinder the reliability of the service they receive.
Penalty Structure
There isn’t a lot of clarity on how penalties are handled across all restaking networks, but below is the exploration of four designs.
Consensus Slashing
This would involve a user depositing their withdrawal credentials. Because slashing by restaking networks is only possible on the execution layer, any misbehavior would be held as a debt against the validator. Payouts of slashing penalties to the rightful parties would not be able to be made until after the validator is withdrawn. This puts a strain on the consensus layer of Ethereum because a margin call scenario might arise where validators are forcefully exited to pay the debts of the validator. Thus putting Ethereum consensus at risk even when providing security outside of Ethereum.
Middleware - might not get paid for a long period of time or at all if Ethereum slashes the entire validator.
State Replication
This method is available to validators staked through a protocol such as Stakehouse. Stakehouse is an operating system to program ETH staking. Because of the native state replication of the consensus layer to the execution layer, no additional collateral would be required and any slashing could be satisfied on the execution layer representation of the consensus layer validator.
Middleware - would receive a yield-bearing asset until the debt is paid by any market participant looking to access MEV rewards.
Execution Collateral
Node operators provide slashable ETH collateral on the execution layer. This could be accomplished with as little as 4 ETH but any validator would be compatible including Rocket Pool, Solo Stakers, Eigenlayer, etc. To mitigate any risks associated with using LSTs it may be required to utilize a token that has smart contract guarantees to a specific validator rather than relying on price feeds.
Middleware - slashing penalties would be paid out immediately.
Borrowed Collateral
Letting node operators borrow capital from LST stakers would allow for a much larger amount of users to access the yield of restaking yield. The drawback is that there is no way to give penalties to the node operator. This causes a massive incentives misalignment and could be detrimental to the average user.
Also, it should go without saying that to “extend Ethereum’s security” an Ethereum validator and node should be involved. The method of “Borrowed Collateral” or “Execution Collateral” opens up the possibility of no actual Ethereum security being extended. Instead, anybody with a computer could run software while Ethereum is getting slashed for misbehavior. This is using Ethereum as collateral, but not actually extending the security. It would extend “economic security” instead of “ethereum’s security”. If this model is introduced it might be better to use USDC as collateral.
Middleware - penalizes users and not the misbehaving party.
Who Wields the Gavel?
The entity that enforces or vetoes slashing is the owner of the protocol; The credible neutrality of restaking will depend on who judges good behavior against misbehavior. Any penalties which occur should be unquestionably slashed without any option of veto. As soon as you bring in any single entity to determine if a slashing is permissible questions the entire neutrality of the protocol.
This suggests that a restaking network should be a three-sided marketplace rather than a two-sided marketplace. Middleware, validators, and those that enforce the agreement; All three should be permissionless if the protocol is to be considered decentralized.
In the End
As we advance further into the age of decentralized finance, the community should be focused on preserving decentralization. Restaking offers considerable potential and there is a clear demand, but it also brings substantial challenges that must be navigated. It’s a free market, nobody can enforce good practices when designing and implementing Ethereum restaking. It is up to us as the community to not support protocols that could put the ecosystem at risk. Upholding the individual and directly rewarding and penalizing them for their actions has been a cornerstone of Ethereum and I’d like to see that continued through all restaking efforts.