- Published:
- Last updated:
Introduction to Proof of Stake
As a reminder, Proof of Stake (PoS) blockchains make use of a protocol-level mechanism called staking whereby users bond (lock in) their tokens into validators operating on a network to boost the network’s security and operational efficiency. In return, users (generally known as delegators or nominators) who bond their stake within a validator are rewarded in the network’s underlying asset for their efforts.
However, this model presents some inefficiencies, notably the fact that delegator-locked assets must undergo an unbonding period of 7- to 28-days or longer. Although necessary to secure Proof of Stake chains, this design obfuscates asset liquidity for the end user because of the unbonding period that the user must endure prior to withdrawing their tokens.
Restaking: The Foundation of EigenLayer
To help eliminate some of the issues we touched on above, EigenLayer pioneered the restaking concept to add unabated liquidity accessibility to PoS networks.
In essence, restaking is a protocol-based mechanism employing a shared security model that allows users to bond their tokens within a specific protocol, to then receive a liquid restaking token (LRT) for supporting the network (on EigenLayer, users initially delegate their ETH to Ethereum).
This means the staker is able to accrue staking rewards for bonding their ETH on EigenLayer while simultaneously earning additional rewards on their LRTs by “restaking” their liquid restaking tokens within an independent protocol operating on EigenLayer.
This system effectively allows users to leverage their asset twice to earn two independent sets of rewards during the period their assets are staked within. In return, the protocol offering restaking to restakers accrues additional tokens for hosting the service via EigenLayer and Ethereum.
Basic Overview of EigenLayer Network Participants
Essentially, the EigenLayer platform is built to provide three main network participants with a marketplace that allows them to achieve what they want and what they cannot achieve on their own.
These include: 1.) stakers, who want to leverage the network as a means to accrue tokenized rewards but don't have the means to run and maintain their own infrastructure; 2.) operators, who want to maximize the use of their validation infrastructure but need stakers as a means to receive payment for their services; and 3.) protocol builders or Actively Validated Services (AVSs), who don’t want to undergo the complexities involved with protocol development at the infrastructure level but have a need for economic security and operational support.
Node Operators and Actively Validated Services
Restakers and native ETH stakers play a vital role on EigenLayer. However, to make this explanation easier to understand as it relates to slashing and the integrity of the network, this analysis will mainly focus on the relationship between two main participants, including:
- Operators: Node operators, such as DAIC Capital and others, are independent entities that run AVS software on top of EigenLayer. Fundamentally, operators are specialized validators that provide validation for different middleware service modules (AVSs) so they are able to carry out their intended tasks and services. Additionally, operators are designed to optimize AVSs and increase capital efficiency by reducing their own operational costs, while simultaneously being rewarded for their efforts.
- Actively Validated Services: Actively Validated Services are middleware service modules that require distributed validation semantics for verification (i.e., they need help to support their platform via a validation operator). AVSs complement EigenLayer by providing various services to the larger EigenLayer network. Examples of AVSs include bridges, sidechains, oracle networks, trusted execution environments (TEEs), consensus protocols, data availability (DA) layers, secure multi-party computation (MPC) frameworks, virtual machines, and others.
On EigenLayer, operators and AVSs form a mutually beneficial relationship. EigenLayer operators must opt-in to decide which AVSs they’d like to support by providing validation and security guarantees. Remember, simply because AVSs are harnessing Ethereum’s economic security as a means to enable their own decentralized trust networks, they still need active nodes to operate.
Operators are allotted a predetermined amount of staking rewards from each AVS they support, in-turn taking on risk should any of the AVSs under their umbrella act maliciously; therefore, threatening the operator’s integrity on the larger EigenLayer network (meaning operators must conduct extremely strict vetting processes on the AVSs they choose to support).
In exchange, the AVS is able to piggyback operator security and validation services, providing them with the correct infrastructure they need to run their independent service platform, which in turn allows the AVS to collect rewards through operators and additional tokens from the independent entities their infrastructure supports. For example, on Ethos Stake, Cosmos chains give Ethos their individual tokens in exchange for security independently from the operator-AVS relationship.
Again, AVSs provide a wide range of service types to different networks, protocols, computation frameworks, virtual machines, middleware systems, and the like. Within the EigenLayer ecosystem, restakers enable the sharing of security via Ethereum, acting as the foundation of the EigenLayer protocol.
AVSs are the projects and services built on EigenLayer run by operators. AVSs can essentially provide any type of service imaginable that helps solve an existing problem in the blockchain landscape. There are a large number of AVS classes being built today and this will continue to expand for the foreseeable future as new business ideations and AVS classes emerge.
Effectively, through this model, EigenLayer could potentially host hundreds of different operators and Actively Validated Service types that provide security and other services to thousands of independent dApps, platforms, protocols, users, and so on.
It's also important to understand that as more AVSs launch, operators will be able to choose to opt-in to secure multiple AVSs concurrently, thereby allowing them to potentially accrue rewards from several AVSs simultaneously.
This does not come without potential sacrifice however. The more AVSs an operator supports, the higher their risk exposure and the more they put their integrity on the line within the larger EigenLayer network should an unfavorable scenario take place in the event any of the AVSs they support are attacked or act dishonestly.
In a worst-case scenario, a dishonest operator could lose their entire stake or even be kicked out of the EigenLayer collective altogether.
To learn more about how EigenLayer creates a multifaceted service collective with the help of the Ethereum trust network, we’d recommend that you dive into our initial article in this series that goes over this concept and much more.
Slashing Abstraction as a Means for Equitability on EigenLayer
Slashing is a penalization mechanism used within Proof of Stake blockchains to ensure that active validators processing and amending blocks as a part of consensus do so in a manner that is equitable. Slashing can even result in a validator (and the entity operating it) being eliminated altogether from the validator set if the infraction is deemed severe enough.
Slashing is typically initiated towards validators using a mechanism called maximal extractable value (MEV) that increases their profitability by deliberately including, omitting, or changing transaction ordering during block creation. This is done to extract additional rewards for themselves on top of the value they would normally obtain via transaction fees.
The Cost of Corruption and Pooled Security
As such, on EigenLayer, the potentiality to carry out an attack is quantified via a theory called the Cost-of-Corruption (CoC). In itself, one of the main foundational premises of EigenLayer is to provision cryptoeconomic security via a host of slashing mechanisms that impose a high CoC.
Case and point, when an attacker attacks an AVS (or dApp) a predetermined cost exists based on a plethora of factors the attacker must take into consideration. Essentially, to corrupt and/or control an AVS and potentially seize its assets, the attacker must possess a certain amount of capital and fulfill additional requirements in a best case attack scenario.
This means that when the cost of corruption is significantly higher than the Profit-from-Corruption (PfC), the system is thought to be extremely secure. To put it more simply, if the potential challenges the attacker must undertake (the cost of corruption) are much larger than the potential reward, it is not really worth conducting the attack in the first place.
As we touched on in great detail in the first article of this series, EigenLayer works using a pooled security mechanism (also known as shared security) that dramatically increases the CoC for potential attackers. In essence, there is a huge difference between the security robustness of AVSs leveraging pooled security and those that do not.
In the event an attacker is trying to breach a non-pooled AVS system that has 13 independent AVS operators (holding 1 billion in assets each) that do not share security with one another, the cost of corruption is 1 billion to attack each individual AVS.
Contrastingly, the pooled security approach means that all 13 separate AVS modules share their security as one interconnected unit. Therefore, this mean that the total cost of corruption is 13 billion (with 1 billion locked inside each AVS) because the attacker must possess at least the equivalent total amount to steal the asset within the intended target (i.e., they must have 13 billion, compared to only 1 billion in the non-pooled security scenario).
Malicious Staker Slashing
Because EigenLayer smart contracts inherently hold the withdrawal credentials of Ethereum PoS stakers, if a staker employing restaking on EigenLayer is proven malicious while using an AVS, they are subjected to the slashing of their ETH and their ability to contribute to another AVS is frozen.
More specifically, since the dishonest staker’s withdrawal address was initially set to a specific EigenLayer contract, when the staker attempts to withdraw their ETH from participation in Ethereum consensus via EigenLayer, the withdrawn ETH is destroyed (slashed).
In and of itself, an AVS is composed of an independent container for off-chain execution that must be downloaded by an operator as well as an on-chain smart contract that determines the slashing and rewards terms for operating the AVS.
These slashing conditions are set by the AVS and approved by the EigenLayer slashing veto committee prior to it being allowed to operate on the EigenLayer network.
Slashing and Risk Management on EigenLayer
On EigenLayer two main types of risk exist that can compromise the integrity of the system. These include:
- Operator collusion: Several operators could work together to attack a group of AVSs concurrently.
- Unintended slashing vulnerabilities: AVSs may be susceptible to inadvertent slashing vulnerabilities (such as smart contract bugs) that can result in honest nodes being slashed.
Operator Collusion
Operator collusion on EigenLayer presents itself as a potential attack vulnerability for a single AVS (in scenario 1) or several AVSs (in scenario 2).
In scenario 1, a single AVS is secured by $8m of restaked ETH containing a total value locked (TVL) of 2 million. With a quorum of 50% needed to steal the $2m, the AVS would be considered secure because a successful attack would mean that a minimum of $4m of the attacker’s stake would be slashed. Therefore, the cost of corruption is too high, so it's not worth conducting the attack in the first place.
In scenario 2, if the same set of stakers introduced in scenario 1 are also restaking in several AVSs, the likelihood of the system being secure is negligible. In this scenario, let's say the same group of restakers are making use of 10 independent AVSs, with each one having $2m locked. This would mean that the total potential profit would be $20m, with the total value at stake only being $8M (again with a 50% quorum required like in scenario 1), thus making the potential profit much higher than the total value at stake ($20m vs. $8m).
This means that in scenario 2 the profit from corruption would far outweigh the cost of corruption; meaning that if operators collude it would be much easier and much more profitable to conduct a successful attack.
One solution to the above issue is to restrict the potential profit for corruption by: 1.) using a bridge to limit the asset value flow during the slashing period (making it impossible for dishonest actors to withdraw their assets from EigenLayer), and 2.) using an oracle to limit the total processed transaction value within a specific time period (again, inhibiting malicious actors from withdrawing their assets).
Another solution is to increase the cost of corruption on EigenLayer (by programmatically changing the minimum threshold via governance) required to corrupt an AVS, therefore making it exponentially more difficult for operators to act maliciously.
In addition, to eliminate the possibility of security vulnerabilities via restaking operator collusion, it is possible to create and open-source cryptoeconomic dashboard that allows AVSs operating on EigenLayer to monitor whether the set of operators providing validation support are entrenched across many AVSs or not.
If an AVS determined that some of the operators supporting their platform were potentially colluding, they could mitigate this risk by creating a specialized smart contract that incentives only operators that are participating in a low number of AVSs. This would create a more adaptable and robust security model that is potentially modifiable.
Unintended Slashing Vulnerabilities
In addition to operator collusion, unintended slashing is a risk that EigenLayer is potentially susceptible to.
Similarly to any robustly-developed protocol, the goal of EigenLayer AVSs is to slowly improve their integrity once they become battle-tested. Once sufficiently hardened, it is assumed that the risk of unintended slashing occurring within an AVS is minimal.
Nonetheless, prior to an AVS and its smart contracts and infrastructure becoming battle-tested, there are numerous slashing risks that need to be eliminated to avoid potential catastrophic risk. One such risk related to unintentional slashing is that an AVS could be susceptible to a programming bug that developers don’t know exists that results in the loss of funds for honest users.
To dramatically reduce the chances of such a scenario occurring, it is necessary to conduct two main preventive measures: 1.) perform an AVS security audit (and potentially perform numerous regular audits continuously); and 2.) incorporate an equitable means to veto potential slashing events.
Although security audits conducted on AVS codebases are generally significantly more complex than the average smart contract, their primary purpose is to protect retail users.
AVS audits are typically focused on stakers and operators which are generally considered to be more sophisticated ecosystem participants. Because of this complexity and the potential risk-reward profile, it is absolutely critical that an audit is conducted on an AVS (and potentially several thereafter on a recurring basis) in order for it to actually receive an opt-in from stakers and operators.
Moreover, the second line of defense prior to an AVS becoming sufficiently secure, is the implementation of a governance layer on EigenLayer made up of reputable members of the EigenLayer and Ethereum community that are able to veto slashing decisions via a community-run multisig. This slashing veto process could be considered akin to a set of training wheels that are removed as the AVS and its underlying security becomes more robust.
For the slashing veto model to work equitably, it's important that a reputation-based veto committee is used, whereby several Ethereum and EigenLayer committee members hold their own independent private keys to a multisig back-end system. This structure eliminates the potential issues that a stake-weighted veto model could be susceptible to.
In a stake-weighted model, centralization issues could potentially exist if a single entity held an extremely large percentage of the network’s tokens, meaning they could potentially sway the network’s governance and slashing penalization structure in their favor (or in a worst-case scenario, attack the system directly).
Through the reputation-based model, the committee is responsible for enabling potential upgrades to EigenLayer contracts, reviewing and vetoing slashing, and admitting newly launched AVSs into the slashing review process should it be deemed necessary.
Of great significance, any AVS that expresses interest in building on top of EigenLayer and employing the veto committee’s reputation-based decision-making processes must be admitted by the veto committee itself. To be accepted as an AVS, the committee generally requires that an AVS undertake protocol security audits and other means to ensure its integrity, including an analysis of the system’s requirements for operators to serve the AVS.
This AVS-veto committee relationship is designed to be balanced to help preserve the equitability of the EigenLayer protocol and its slashing framework. On one side, the AVS must be able to trust that the veto committee will not veto a correct slashing, while on the other side, stakers restaking on EigenLayer must be able to trust that the veto committee will veto any unwarranted slashing by the AVS.
