Overview

After the introduction of the PoS (Proof of Stake) consensus algorithm, it gradually gained adoption on multiple mainstream blockchains due to its energy efficiency and performance advantages over PoW (Proof of Work) consensus. PoS requires validators to stake a certain amount of tokens to participate in the validation process. It relies on economic incentives and rational behavior to ensure the security of the validation process. However, PoS demands a high amount of capital, as higher staking values lead to higher security. Additionally, the competition among PoS services fragments liquidity, making it difficult for new validation services to obtain sufficient staking to ensure security.

The concept of heavy retaking involves staking already staked tokens again, allowing different validation services to share security. EigenLayer expands on restaking and proposes it as a security solution for distributed validation networks. It is implemented as a set of smart contracts on the Ethereum blockchain, providing on-chain validation services and enabling middleware to start with lower entry barriers.

Initially, EigenLayer was closely tied to Ethereum, aiming to utilize Ethereum's native PoS staking pool as the source for restaking, conducting validation on Ethereum, enhancing Ethereum's security, and increasing the value capture of $ETH tokens for Ethereum stakers. However, in practice, restaking is not limited to Ethereum's native PoS staking pool but is applicable to all valuable tokens.

Architecture

EigenLayer, as a restaking service, shares a basic architecture with traditional staking services. The protocol involves three roles: Staker, Operator, and Watcher.

• Stakers deposit assets into EigenLayer and choose to become Operators themselves or delegate their stake to an Operator based on their circumstances.

• Operators are responsible for running the required middleware off-chain on a container. They need to register to accept delegation from Stakers and can choose the middleware they want to run based on operational requirements and profit conditions.

• Watchers act as supervisors, monitoring for malicious behavior by Operators. When malicious behavior is detected, Watchers submit fraud proofs to EigenLayer for slashing the corresponding Operator.

EigenLayer is implemented as a set of smart contracts on Ethereum and is combined with containers running AVS (Asset Validation Service) software off-chain, forming the complete EigenLayer AVS architecture.

• The StrategyManager coordinates all token inflow and outflow within EigenLayer, records staking information in the contracts, and manages stakes using shares. When slashing occurs, StrategyManager transfers the shares of the corresponding Operator to a specified address.

• DelegationManager manages the mapping of Stakers to Operators. Stakers can register as Operators and map themselves or delegate to already registered Operators.

• The Strategy contract simplifies ERC20 Vault management, handling specific ERC20 tokens, and managing conversions between tokens and shares. Deposits and withdrawals can only be initiated by StrategyManager.

• The Slasher contract manages logic related to slashing. Operators, when selecting middleware for service, need to call the allowToSlash function to permit specific contracts to initiate slashing in cases of potential malicious behavior. This authorization has a time limit. The slashing process starts with contracts having slashing permissions calling freezeOperator, which freezes the Operator's ability to make deposits and withdrawals. Then, StrategyManager executes the actual slashing (transferring shares).

These contracts effectively address the issue of securing middleware with ERC20 assets. However, for Ethereum's native Beacon Chain staking, the situation is more complex. EigenLayer introduces new contracts specifically for handling Ethereum's native staking, inspired by the architecture of Liquid staking protocols like Rocket Protocol.

• EigenPodManager serves as the entry point for interactions between Beacon Chain stakers and EigenLayer, responsible for creating EigenPods and coordinating virtual deposits and withdrawals of Beacon Chain ETH.

• EigenPods handle the actual Beacon Chain staking, allowing users to perform native staking through EigenPods. Initially, the restaking feature of EigenPods is disabled, allowing users to freely withdraw validator balances. To opt for heavy staking and earn additional rewards, users need to direct their withdrawal credentials from native staking to EigenPods and prove their validity by submitting a Beacon state root. After successful verification, EigenPods use EigenPodManager to call functions in StrategyManager, recording the corresponding share. Subsequent withdrawals must adhere to the restaking delay mechanism.

The BeaconChainOracle periodically submits Beacon Chain state roots, allowing EigenPods to verify the staking status of native stakers.

EigenLayer does not include specific AVS validation and slashing logic but leaves the implementation to middleware designers. This provides more flexibility to project developers while reducing EigenLayer's development costs.

Workflow

We will use EigenDA as an example to explain the basic workflow of AVS.

1. Depositing into Strategy through the StrategyManager or Depositing Beacon Chain ETH through the EigenPodManager EigenLayer currently supports two forms of heavy staking: ERC20 token staking and Beacon Chain ETH staking. Stakers can choose their preferred form.

2. Operator registration, Staker delegate Stakers can register as Operators or delegate to registered Operators. Operators can become EigenDA nodes once they hold the required share of EigenDA.

3. Operators run middleware off-chain Operators run EigenDA software on their computers, preparing to provide services to EigenDA clients.

4. The Sequencer orders transactions and generates blocks, then sends the data blob to the Disperser.

5. The Disperser, using Data Availability Sampling (DAS) mechanisms, divides data into chunks, encodes data using erasure coding, and calculates corresponding KZG commitments. The Disperser submits KZG commitments to EigenDA's on-chain contract for EigenDA nodes to verify data accuracy.

6. The Disperser distributes data chunks and KZG commitments to EigenDA nodes based on the specified allocation rules. Nodes, upon receiving KZG commitments, compare them with on-chain commitments, store data blocks upon confirmation, sign them, and send them back to the Disperser.

7. The Disperser collects signatures from EigenDA nodes, generates a BLS aggregated signature, and submits it to EigenDA's contract. EigenDA's contract verifies that the number of signatures exceeds a set threshold, signifying data availability.

8. When Rollup needs original data to restore state, it retrieves the necessary data chunks directly from EigenDA nodes off-chain for restoration.

9. If dishonest behavior is detected among EigenDA nodes, evidence can be submitted to the on-chain Slasher contract for slashing, deducting shares from the corresponding nodes.

As a protocol relying on the PoS mechanism to secure services, EigenLayer does not design a separate consensus algorithm to achieve consensus among nodes. Rollup, as the demand side for DA services, makes the Disperser the communication hub, transmitting data end-to-end to various nodes off-chain, with verification relying on on-chain witness data. To address the lazy validator problem, EigenDA employs Proof of Custody, an optimistic mechanism that assumes nodes work honestly by default. It also allows the acceptance of proofs of dishonesty, leading to slashing of the corresponding nodes after verification.

Proof of Custody and data availability check serve different purposes. Data availability checks ensure that data availability does not rely on the assumption of an honest majority, making it more robust in the presence of adversarial validators. In contrast, Proof of Custody focus on ensuring rational validators remain honest and prevent lazy behavior. In practice, Proof of Custody and data availability checks can complement each other. Proof of Custody ensure that shard data is well-seeded and available among committees, while data availability checks guarantee data is ultimately available to all nodes.

Summary

EigenLayer creatively expands on the concept of restaking and provides a new narrative in a quiet market. From a technical perspective, EigenLayer builds on the work of existing protocols, cleverly adopting the designs of several well-known protocols to define the validation service process and general interfaces through multiple Solidity contracts. The complex and varied implementation of specific validation and slashing logic is left to the requirements of AVS participants, effectively achieving a significant impact with minimal development effort.

Reference:

https://docs.eigenlayer.xyz/overview/whitepaper https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/EigenLayer-tech-spec.md

https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups/

https://mirror.xyz/0x5Eba828AB4999825D8416D7EAd9563b64FD90276/nRNyWdsSYiv77qiVXBXqG5f8JfyK-3RzRDx9cklPAGU

https://mp.weixin.qq.com/s?__biz=Mzk0NjU2NTEwNQ==&mid=2247491664&idx=1&sn=944683a699ca2177427976121f147c46&source=41#wechat_redirect

Current Problems

• Applications built on top EVM can use ETH as a shared security&consensus

  • layer2

  • DApps

• Some modules can’t easily use

  • Examples of such modules include

    • sidechains based on new consensus protocols

    • data availability layers, new virtual machines

    • keeper networks

    • oracle networks

    • bridges

    • threshold cryptography schemes and trusted execution environments.

  Typically, such modules require actively validated services that have their own distributed validation semantics to do the verification.

  AVS

  Usually, these actively validated services (“AVS”) are either secured by their own native token or are permissioned in nature, which has 4 problems:

  1. Bootstrapping problem for a new AVS

  2. Value leakage. With each AVS developing its own trust pool, users have to pay fees to these pools on top of transaction fees to Ethereum. This diversion in flow of fees results in value leakage from Ethereum.

  3. The burden of capital cost.

  4. Lower trust model for DApps.

  Architecture

1. pooled security via restaking

2. free-market governance

3. Pooled security via restaking. EigenLayer provides a new mechanism for pooled security by enabling modules to be secured by restaked ETH rather than their own tokens. In particular, Ethereum validators can set their beacon chain withdrawal credentials to the EigenLayer smart contracts, and opt into new modules built on EigenLayer.

   1. The validators download and run any additional node software required for these modules. The modules then have the ability to impose additional slashing conditions on the staked ETH of validators who opted into the module. We call this mechanism restaking.

   2. In return, validators gain additional revenue from providing security and validation services to their chosen modules.

4. Open marketplace. EigenLayer provides an open market mechanism that governs how its pooled security is supplied by validators and consumed by AVSs. EigenLayer creates a marketplace in which validators can choose whether to opt in or out of each module built on EigenLayer

What problems are solved by Eigenlayer

1. Bootstrapping problem for a new AVS: A new AVS can bootstrap security from the large validator set of Ethereum

2. Capital Cost: Since ETH stakers reuse their capital across multiple services, their capital cost gets amortized.

3. Better security and trust

4. Value Accrual

Assets that can be staked

1. Native restaking. Validators can restake their staked ETH natively by pointing their withdrawal credentials to the EigenLayer contracts. This is equivalent to L1 → EigenLayer yield stacking.

2. LST restaking. Validators can restake by staking their LSTs, ETH already restaked via protocols like Lido and Rocket Pool, by transferring their LSDs into the EigenLayer smart contracts. This is equivalent to DeFi → EigenLayer yield stacking.

3. ETH LP restaking. Validators stake the LP token of a pair which includes ETH. This is equivalent to DeFi → EL yield stacking.

4. LST LP restaking. Validators stake the LP token of a pair which includes a liquid staking ETH token, such as Curve’s stETH-ETH LP token, thus taking the L1 → DeFi → EL yield stacking route.

Main use case

• EigenDA

  • Higher security provided by Ethereum

• Rollup Sequencer

• RPC nodes

• AppChain

• Oracles

• Bridges

• Settlement Chains with Ultra-Low Latency