EigenLayer: The Trust Revolution of Restaking Introducing Middleware
TechFlow Selected TechFlow Selected
EigenLayer: The Trust Revolution of Restaking Introducing Middleware
EigenLayer is expected to complete its mainnet launch early next year and introduce its flagship product, EigenDA.
Navigating Web3 tides with focused insights
Last November, we introduced EigenLayer in this article titled "EigenLayer: Bringing Ethereum-Level Trust to Middleware." Over the past year, EigenLayer has released its whitepaper, completed a $50 million Series A funding round, and launched the first phase of its mainnet. During this time, the Ethereum community has engaged in extensive discussions around EigenLayer and its use cases. This article aims to track and summarize these ongoing conversations.
Background
In the Ethereum ecosystem, certain middleware services (such as oracles) do not fully rely on on-chain logic and thus cannot directly leverage Ethereum's consensus and security. They must bootstrap their own trust networks from scratch. The typical approach is for the project team to initially operate the system, then introduce token incentives to attract participants and gradually achieve decentralization.
This process faces at least two major challenges. First, introducing incentive mechanisms incurs additional costs: the opportunity cost for participants who purchase tokens and stake them, and the operational cost for the project team to maintain the token’s value. Second, even after incurring these costs and building a decentralized network, the resulting security and sustainability remain uncertain. For startups, both issues are particularly daunting.
EigenLayer proposes an alternative: allowing existing Ethereum stakers to re-stake (Restaking), thereby providing economic security to these middleware services (Actively Validated Services, AVS). If re-stakers act honestly, they earn rewards; if they act maliciously, their original Ethereum stake can be slashed.
The benefits are twofold. First, projects no longer need to bootstrap their own trust networks but can outsource trust to Ethereum validators, significantly reducing capital requirements. Second, the economic security provided by Ethereum’s validator set is robust, offering strong security assurances. From the perspective of Ethereum stakers, re-staking offers additional yield, with manageable overall risk as long as they don’t intentionally act maliciously.
EigenLayer founder Sreeram has discussed three use cases and trust models for EigenLayer via Twitter and podcasts:
-
Economic Trust: Reusing Ethereum staking exposure—higher-value token staking leads to stronger economic security, as previously discussed.
-
Decentralized Trust: Some services (e.g., secret sharing) may involve malicious behaviors that cannot be attributed, making slashing mechanisms ineffective. A sufficiently decentralized and independent group is needed to perform tasks securely, mitigating collusion risks.
-
Ethereum Validator Commitment: Block producers pledge credibility using their staking exposure. We’ll explore specific examples below.
System Participants
EigenLayer acts as an open marketplace connecting three key participants.
-
Re-stakers: Those with Ethereum staking exposure can participate by redirecting their withdrawal credentials to EigenLayer or simply depositing liquid staking tokens (LSTs) like stETH. If a re-staker cannot run an AVS node themselves, they may delegate their stake to an operator.
-
Operators: Operators accept delegations from re-stakers and run AVS nodes. They can freely choose which AVSs to serve and must abide by the slashing rules defined by each AVS.
-
AVSs: As demand-side users, AVSs pay re-stakers for access to their economic security.
With these foundational concepts established, let us now examine specific use cases of EigenLayer.
EigenDA
EigenDA is EigenLayer’s flagship product, drawing inspiration from Danksharding, Ethereum’s scaling solution. Its core technique—Data Availability Sampling (DAS)—is also widely used in DA projects such as Celestia and Avail. In this section, we will briefly explain DAS before diving into EigenDA’s implementation and innovations.
-
DAS
As a precursor to Danksharding, EIP-4844 introduced "Blob-carrying Transactions," where each transaction carries approximately 125KB of extra data. In the context of data sharding for scalability, this additional data clearly increases the burden on nodes. Is there a way for nodes to verify that all data is available while only downloading a small portion?
DAS addresses this by having nodes randomly sample small portions of data multiple times. Each successful sample increases a node’s confidence in data availability. Once confidence reaches a certain threshold, the data is deemed available. However, attackers could still hide a small fraction of the data—we need a fault-tolerant mechanism.
DAS employs erasure coding. The core idea is to split data into blocks, encode them, and generate additional redundant blocks. These redundant blocks contain partial information about the original data, enabling recovery of lost or corrupted blocks. Thus, erasure coding provides redundancy and reliability to DAS.
Additionally, we need to verify that the generated redundant blocks are correctly encoded, since incorrect redundancy cannot reconstruct the original data. Danksharding uses KZG (Kate-Zaverucha-Goldberg) commitments. A KZG commitment is a method for verifying polynomials, proving that a polynomial evaluates to a specified value at a given point.
The prover selects a polynomial p(x) and computes commitments C1, C2, ..., Cm for each data block using p(x). The prover publishes both the commitments and the data blocks. To verify encoding, the verifier randomly samples t points x1, x2, ..., xt and requests openings: p(x1), p(x2), ..., p(xt). Using Lagrange interpolation, the verifier reconstructs p(x) from these t points. Then, using the reconstructed p(x) and the data blocks, the verifier recomputes commitments C1', C2', ..., Cm' and checks whether they match the published commitments C1, C2, ..., Cm.
In short, KZG commitments allow verifiers to confirm the correctness of the entire encoding using only a small number of sampled points. This completes the full DAS pipeline.
-
How
EigenLayer adopts the DAS concept and applies it within EigenDA.
1. First, EigenDA nodes re-stake and register in the EigenLayer contract.
2. Next, the Sequencer splits incoming data into chunks, uses erasure coding to generate redundant chunks, and computes KZG commitments for each data chunk. The Sequencer publishes these KZG commitments one by one to the EigenDA contract as witnesses.
3. The Sequencer then distributes each data chunk along with its corresponding KZG commitment to individual EigenDA nodes. Upon receiving the KZG commitment, each node compares it with the one stored in the EigenDA contract. After confirmation, the node stores the data chunk and signs it.
4. The Sequencer collects these signatures, aggregates them into a single signature, and submits it to the EigenDA contract, which verifies the aggregated signature. Once verified, the process is complete.
In this workflow, EigenDA nodes only claim storage via signatures. We therefore need a mechanism to ensure nodes aren't lying. EigenDA uses Proof of Custody for this purpose.
Proof of Custody involves placing a “bomb” within the data—any node that signs it gets slashed. To implement this, a secret value is designed to differentiate DA nodes and prevent cheating, along with a DA-node-specific function that takes the DA data and secret value as inputs and outputs whether a bomb exists. If a node hasn’t stored the full required data, it cannot compute this function. Dankrad has shared further technical details about Proof of Custody in his blog.
If a lazy node is detected, anyone can submit a proof to the EigenDA contract. The contract verifies the proof and slashes the node upon successful validation.
Regarding hardware requirements, computing KZG commitments for 32MB of data within one second requires roughly 32–64 CPU cores—but this burden falls solely on the Sequencer, not on EigenDA nodes. In EigenDA’s testnet, 100 nodes achieved a throughput of 15 MB/s, while requiring only 0.3 MB/s of download bandwidth per node—far below the requirements for running an Ethereum validator.
In summary, EigenDA decouples data availability from consensus. Data propagation is no longer bottlenecked by consensus protocols or low P2P network throughput. Effectively, EigenDA rides on Ethereum’s consensus: the Sequencer publishing KZG commitments and aggregated signatures, smart contract signature verification, and slashing of malicious nodes—all occur on Ethereum, leveraging Ethereum’s consensus guarantees without needing to bootstrap a new trust network.
-
Problems of DAS
Currently, DAS itself has some limitations. We must assume adversarial actors will try every possible means to deceive light nodes into accepting fake data. Sreeram elaborated on this in a tweet thread.
To give a single node high confidence that data is available, the following conditions must be met:
-
Random Sampling: Each node must independently and randomly select samples to query, without the adversary knowing which samples were requested. Otherwise, the adversary could adapt its strategy accordingly to fool nodes.
-
Concurrent Sampling: DAS must be performed simultaneously by multiple nodes so attackers cannot distinguish between queries from different nodes.
-
Private IP Sampling: Each data block query should use an anonymous IP address. Otherwise, adversaries could identify sampling nodes and selectively provide only the parts already queried, withholding the rest.
We can satisfy randomness and concurrency by having multiple light nodes perform random sampling, but currently there is no effective way to achieve private IP sampling. Therefore, attack vectors against DAS still exist, meaning DAS currently offers only weak guarantees. These issues are actively being addressed.
EigenLayer & MEV
Sreeram discussed EigenLayer’s applications in the MEV stack during the MEVconomics Summit. Leveraging cryptographic-economic primitives based on staking and slashing, proposers can enable four key features—essentially the third use case mentioned earlier: validator commitments.
Event-driven Activation
Protocols like Gelato react to specific on-chain events. They continuously monitor the chain and trigger predefined actions when certain events occur—typically executed by third-party listeners/executors.
They are called "third-party" because there is no direct link between the listener/executor and the actual block proposer. Suppose a listener triggers a transaction, but the proposer fails to include it in the block—this omission cannot be attributed, hence no economic guarantee can be enforced.
If re-staking proposers offer this service, they can make credible commitments to execute operations. If the transactions are not included, the proposer gets slashed. This provides stronger guarantees than third-party executors.
In practice (e.g., lending protocols), one reason for setting over-collateralization ratios is to cover price volatility over a certain period—related to the time window before liquidation. Higher collateral ratios mean longer buffer periods. If most transactions adopt event-driven execution with strong proposer-backed guarantees, over-collateralization volatility could be constrained within just a few blocks, lowering collateral requirements and improving capital efficiency.
Partial Block Auction
Under current MEV-Boost design, proposers fully outsource block space to builders and passively accept entire blocks submitted by builders. Compared to the more distributed proposers, builders are few in number and may collude to censor or extort specific transactions—since proposers cannot insert desired transactions under MEV-Boost.
EigenLayer proposes MEV-Boost++ as an upgrade to MEV-Boost, introducing a Proposer-part in the block where proposers can include arbitrary transactions. Proposers can also build an alternative block B-alt and propose it if the relay fails to release the Builder_part. This flexibility ensures censorship resistance while solving relay liveness issues.
This aligns with protocol-layer designs like ePBS’s crList—the goal is to ensure broad participation of proposers in determining block contents for censorship resistance.
Threshold Encryption
In threshold encryption-based MEV solutions, a distributed set of nodes manages encryption/decryption keys. Users encrypt transactions, which are only decrypted and executed after inclusion in a block.
However, threshold encryption relies on a majority-honest assumption. If most nodes are malicious, decrypted transactions might not be included. Re-staking proposers can make credible commitments to include such transactions. Failure to include them results in slashing. Of course, if a malicious majority refuses to release the decryption key, the proposer can propose an empty block.
Long-term Blockspace Auction
Long-term blockspace auctions allow buyers to reserve future block space from validators in advance. Re-staking validators can make credible commitments—failure to include the buyer’s transaction results in slashing. Such guaranteed blockspace has practical use cases: oracles periodically pushing price feeds; Arbitrum publishing L2 data to Ethereum L1 every 1–3 minutes; Optimism doing so every 30 seconds to 1 minute, etc.
PEPC
Now let’s revisit PEPC (Protocol-enforced Proposer Commitment), recently widely discussed in the Ethereum community. PEPC is essentially a generalization or extension of ePBS.
Let’s break down this logical progression step by step.
-
First, take off-protocol PBS (MEV-Boost) as an example. Currently, MEV-Boost relies on Ethereum’s protocol-level slashing mechanism: if a proposer signs two different block headers at the same height, they get slashed. Since proposers must sign the block header submitted by the relay, this binds the builder’s block to the proposer, giving relays confidence that the block will be proposed. Otherwise, proposers would have to forfeit the slot or propose a different block—which triggers slashing. Here, proposer commitment is economically secured via staking and slashing.
-
Similarly, a key principle behind ePBS design is “honest builder publication safety”—ensuring blocks published by honest builders are actually proposed. As an in-protocol PBS, ePBS will be integrated into Ethereum’s consensus layer, with protocol-level enforcement.
-
PEPC extends ePBS further. While ePBS commits to “the builder’s block will be proposed,” expanding this to partial block auctions, parallel block auctions, future block auctions, etc., enables proposers to commit to much more—and the protocol layer ensures these commitments are enforced.
There is a subtle relationship between PEPC and EigenLayer. Notably, the use cases of PEPC resemble those proposed for EigenLayer’s block producers. However, a key difference lies in enforcement: re-staking proposers in EigenLayer can theoretically break their commitments and merely suffer economic penalties; PEPC emphasizes “Protocol-enforced”—commitments are enforced at the protocol level, rendering blocks invalid if commitments aren’t fulfilled.
(PS: At a high level, EigenDA resembles Danksharding, and MEV-Boost++ resembles ePBS—these services act like opt-in versions of protocol-layer designs, launching faster to market while staying aligned with Ethereum’s future roadmap through re-staking.)
Don't Overload Ethereum Consensus?
Several months ago, Vitalik’s article “Don't Overload Ethereum Consensus” was widely interpreted as criticism of Restaking. The author believes this was more of a reminder or warning about preserving social consensus—the focus is on social consensus, not a rejection of re-staking.
In Ethereum’s early days, the DAO hack sparked intense debate over whether to hard fork. Today, the Ethereum ecosystem—including Rollups—supports massive applications. Avoiding deep divisions within the community and maintaining consistent social consensus is crucial.
Hermione creates a successful layer 2 and argues that because her layer 2 is the largest, it is inherently the most secure, because if there is a bug that causes funds to be stolen, the losses will be so large that the community will have no choice but to fork to recover the users' funds. High-risk.
This quote from the original article serves as a perfect example. Today, L2 total TVL exceeds tens of billions of dollars. If something goes wrong, the implications are enormous. Should the community propose a hard fork to roll back state, it would inevitably spark fierce controversy. If you and I had significant funds at stake, what would we choose—recover the money or uphold blockchain immutability? Vitalik’s point is clear: projects built atop Ethereum should manage their risks responsibly and avoid attempting to co-opt Ethereum’s social consensus, tightly coupling their survival to Ethereum’s.
Returning to EigenLayer, the key to risk management lies in AVSs defining objective, on-chain verifiable, attributable slashing rules to prevent disputes. Examples include double-signing blocks on Ethereum; signing invalid blocks on another chain in a light-client-based cross-chain bridge; or the Proof of Custody mechanism discussed earlier in EigenDA. All such cases represent clear slashing conditions.
Conclusion
EigenLayer is expected to complete its mainnet launch early next year, debuting its flagship product EigenDA. Numerous infrastructure projects have already announced partnerships with EigenLayer. We’ve discussed EigenDA, MEV, and PEPC—around these diverse use cases, many fascinating discussions continue. Re-staking is becoming a dominant narrative in the market. We will continue to follow EigenLayer’s progress and share our insights!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
