The EigenLayer Universe: Ideas for Building the Next 15 Unicorns
EigenLayer empowers builders to develop innovative distributed systems without worrying about how to build the underlying trust networks for these systems. We call these distributed systems AVSs - actively validated services. We have categorized AVSs into 5 types:
- Rollup Services: augmenting the Ethereum rollup ecosystem with services that inherit aspects of security from Ethereum’s trust network
- Applied Cryptography: creating robust threshold cryptographic systems and TEE committees via decentralized nodes
- General Decentralized Networks: bootstrapping networks easily from prover markets, and relayer markets to security monitoring counsels
- MEV Management: allowing proposers to make additional credible commitments on block inclusion and ordering
- AI Inference: ensuring program integrity and session privacy in a cost-effective manner
Our previous blog post highlighted the three types of trust that any AVS can inherit from Ethereum via EigenLayer, namely economic trust, decentralization trust, and Ethereum inclusion trust, or some combination of the three. As a recap, with EigenLayer, you can program these three types of trust:
- Economic Trust: trust from validators making commitments and backing their promises with financial stakes
- Decentralized Trust: trust from having a decentralized network operated by independent and geographically isolated operators
- Ethereum inclusion Trust: trust that Ethereum validators will construct and include your blocks as promised, alongside the consensus software they are running
In this blog, we will walk through a high-level mental model of how to think about AVS system design. We will use this mental model to illustrate innovative AVSs one can build by mixing and matching types of programmable trust.
Rollup Services
EigenLayer enables the development of foundational services that scale Ethereum while inheriting security from Ethereum’s trust network. This modular approach enhances security, and we collectively refer to these services as 'Rollup Services.'
This section will explore the following Rollup Services: decentralized sequencing, data availability, fast finality, keepers, watchers, and reorg-resistance.
1. Decentralized Sequencing
Currently, rollup sequencers single-handedly decide the order of transaction execution, potentially leading to manipulation and short-term censorship. While long-term censorship is handled in rollups using a mechanism for writing the transaction directly to Ethereum, these sequencer concerns can be mitigated by implementing a decentralized transaction ordering service.
In this service, users send their transactions to a network of decentralized nodes. There can be a variety of different decentralized sequencing services with different transaction ordering policies. We give some examples here:
- Approximate first-in-first-out ordering services (so-called fair ordering protocols)
- Multilateral ordering services with increased censorship-resistance
- Guaranteed MEV return to the rollup
- Shared / individual sequencing across rollups
- Threshold encrypted transaction ordering
- Automated event-driven activation.
For any of these decentralized sequencing services, one can inherit decentralized trust from EigenLayer, as well as reordering protection via economic trust inherent in EigenLayer.
2. Data Availability (DA)
To ensure the correctness of state execution in optimistic rollups and guarantee the liveness of zero-knowledge rollups and optimistic rollups, a critical requirement is the short-term Data Availability (DA) of underlying transaction blobs processed by the rollup.
The core concept involves rollups storing these blobs with a designated set of nodes committed to storing and serving them for a specified time frame, during which anyone can access the blob.
Consider situations where data-heavy consumer applications like gaming and social networking function within rollups. These apps usually have low value per data bit but need a lot of bandwidth for state execution. As a result, they demand substantial throughput, often tens of megabytes per second or more. Meeting this demand requires highly scalable data availability architectures that do not sacrifice security.
To satisfy this demand, the DA layer needs economic trust to tackle issues like the lazy operator problem via Proof of Custody. It also requires decentralized trust to guarantee continuous operation.
EigenLabs has been actively developing a solution called EigenDA to address these challenges.
3. Fast Finality
Rollups have faced several significant challenges, including the absence of instant and secure finality, Ethereum finality lag affecting cross-rollup bridging, costly cross-rollup interactions, liquidity fragmentation across rollups, and limitations for ZK verification.
One potential solution to address these issues is implementing a fast finality layer within EigenLayer. In this approach, any rollup can assert a state claim on the fast finality layer, stating that the execution of a specific block of transactions leads to a particular state commitment. In ‘fast mode,’ nodes within the fast finality layer validate the rollup’s claim and provide attestations of its validity.
If a supermajority of nodes attests to its validity, rollup clients can achieve economic finality nearly instantaneously. However, in ‘slow mode,’ the attestations from the fast finality layer are subjected to a challenge period, allowing anyone to raise a challenge if they suspect malicious behavior.
It's important to note that the fast finality layer requires high economic trust to ensure safety.
4. Keeper Network
Keeper networks prove invaluable for users looking to initiate specific actions based on predefined conditions. These networks deploy nodes to respond to 'if-this-then-that' demands.
There are two types of keeper networks. The first type is suitable for non-time-sensitive actions, such as raising challenges to optimistic rollups within a 7-day window (further discussed in the Watcher Network section below) or managing bridge relays (as expanded in the Relayer Market section below). In such cases, the primary requirement is economic trust, as it enables the penalization of nodes engaging in misconduct.
The second type demands swift and time-sensitive actions, such as preventing collateral liquidation, minting new NFTs, or executing token trades in response to specific on-chain behaviors. These demands can be met through Ethereum inclusion trust via EigenLayer, where validators commit to prioritize and fulfill such requests. This approach can potentially change the status quo and relieve users from the burden of paying high gas fees.
5. Watcher Network
For any optimistic rollup (ORU) to be deemed secure, a challenge must be initiated in a pessimistic scenario involving incorrect state execution. Therefore, every ORU client requires assurance that a vigilant group is actively monitoring for any erroneous executions and raising necessary challenges.
This assurance can be established via economic trust by appointing EigenLayer operators as watchers. These operators can be penalized through slashing if they either make unfounded malicious challenges or fail to raise a challenge when required.
6. Reorg Resistance
One of the paramount characteristics for any blockchain to be considered secure is its resistance to chain reorganizations (reorgs). When a blockchain can leverage the economic trust provided by Ethereum, it significantly bolsters its defenses against potential chain reorgs.
At a high level, a service can be developed to guarantee that nodes with substantial stake in Ethereum attest to the block header of the most recently finalized block of the chain. To achieve this, these nodes run the chain's light client to verify that the finalized block has not been double-signed and is built on the most recently finalized block.
The new confirmation rule for any client on the chain would be to check whether the block header has been finalized by the chain and enough stake from Eigenlayer has attested to the finalized block header.
Obtaining reorg resistance from Ethereum hinges on establishing economic trust through EigenLayer.
7. Inbound and Outbound Bridge
Cross-chain bridging to and from Ethereum involves a delicate balance between interoperability and security. Centralized bridges offer excellent interoperability but compromise security. Conversely, light client bridges provide high security but incur high gas costs to run the light client smart contract.
One can break this tradeoff between interoperability and security by having a group of opt-in nodes, who have put a significant amount of stake as collateral on Ethereum, attest to messages bridging in and out of Ethereum off-chain. At the same time, they can be slashed on-chain optimistically for wrong attestations. This can be achieved via economic trust.
Applied Cryptography
8. Threshold Cryptography
Threshold cryptography has been proposed to achieve applications such as commit-reveal for protection against targeted frontrunning, privacy, etc.
The core idea behind threshold cryptography is that, given an encrypted message, at least k out of n signers can efficiently decrypt the message. In contrast, anything less than k is unable to do so.
The security of this primitive essentially requires k to be large and the set of these signers to consist of a large decentralized set that inhibits collusion and liveness attacks. This decentralized set of nodes can be inherited from EigenLayer.
9. Threshold-FHE
Threshold Fully Homomorphic Encryption (FHE) enables distributed computation on encrypted data, delivering a robust privacy guarantee. As threshold-FHE implementation necessitates decentralization, EigenLayer offers a reliable source of decentralized trust.
In this method, sensitive data is encrypted using threshold encryption, with the secret key shares distributed among the decentralized network of EigenLayer operators. Subsequently, computations are performed on the encrypted data, preserving privacy and security.
10. Trusted Execution Environment (TEE) Committees
Protocols can establish robust security guarantees by harnessing not only Trusted Execution Environments (TEEs) but also by constructing a decentralized network of TEEs through EigenLayer, referred to as TEE Committees.
The combination of TEE and committees strictly improves the reliability of any committee without TEE: this is because a breach of the system requires both a majority of the committee to be colluding and furthermore that the security model of the TEE has been breached.
We note that it is possible to require multiple distinct TEE models like Intel SGX, ARM TrustZone, and Amazon Nitro in the TEE Committee and require at least one sign-off from each model so that breaking the system requires breaking all these distinct trust models as well as majority collusion.
The decentralization of the TEE committee can be absorbed from decentralized trust on EigenLayer and furthermore, the economic trust can be borrowed from EigenLayer in situations where slashing is possible.
The TEE committee also provides privacy in the normal mode so that the TEE is not attacked. This makes the TEE committee an attractive solution for a variety of problems where both program integrity and privacy are required.
Decentralized Networks
11. Relay Networks
Many bridges currently depend on a centralized group of relayers. When a dApp developer selects a bridge to work with, their choices are limited to the options provided by that bridge. This limitation exists in part because setting up a bridge with a set of relays can be challenging. To enhance system resilience, bridges can utilize a decentralized network of relay operators on EigenLayer.
12. Prover Networks
In the future, we may witness the emergence of prover networks competing to generate zk proofs as quickly and cost-effectively as possible, through parallelization methods. A portion of this network can be initiated through EigenLayer nodes, leveraging the decentralization capabilities of the EigenLayer network to provide broader access to these provers and ensure the overall liveness of the network.
13. Risk and Transaction Simulation Networks
Banks employ sophisticated transaction risk analysis to safeguard against malicious transactions, a level of security currently lacking in blockchain systems. A Risk Module AVS would tackle this issue by engaging a subset of nodes to simulate transactions and perform comprehensive risk analysis. If a transaction raises a red flag, the module alerts the network.
DApps can subscribe to this risk module, and any transaction seeking interaction with these DApps must undergo analysis through the risk module. The transaction is only executed when a threshold of k out of n nodes within the module signs off on its correctness, as determined by the risk analysis.
14. MEV Management
In the current MEV supply chain, validators can only offer a limited commitment – that they won’t double-sign conflicting block headers (equivocation). Services like MEV-Boost rely on this rigid commitment.
EigenLayer expands this landscape by enabling validators to make a more diverse range of commitments to their counterparts, whether they are builders or direct users. This expansion of possibilities within the MEV supply chain opens the door to the development of various MEV mechanisms under the “multiple lanes” paradigm, allowing validators to express their preferences more comprehensively:
- Multi-lane block proposal, incorporating MEV-Boost’s full block auction and partial block auction like MEV Boost +/++, empowers proposers to contribute to block composition, enhancing censorship resistance.
- Event-driven activation enables Ethereum validators to function as attributable keepers, agreeing to activate specific event-driven transactions.
- The purchase of blockspace futures facilitates the conversion of statistical arbitrage into atomic arbitrage.
- Threshold encryption offers protection against targeted frontrunning in sandwich attacks.
It’s important to note that the first three MEV mechanisms rely on Ethereum inclusion trust via EigenLayer, while the fourth one depends on decentralization trust from EigenLayer.
15. AI Inference
With the advent of trained open-source large AI models, users inferencing these models on new queries is already becoming a hot topic. However, the current landscape has just a few centralized entities running AI inference engines.
There are several compelling reasons for running AI inferences onchain:
- Program Integrity: While many services opt for centralized servers like AWS, employing zero-knowledge (ZK) techniques for Machine Learning (ML) can be cost-prohibitive. EigenLayer seeks to broaden the market for computational integrity in ML. If you seek both cost-effectiveness and computation integrity when running AI engines for inference, especially when relying on decentralized servers is considered too risky, EigenLayer offers a solution. By offering the ability to inherit economic trust, EigenLayer facilitates these operations.
- Session Privacy: EigenLayer operators running AI engines should only be able to decrypt the complete set of consumer queries if a significant portion of operators collude. This underscores the importance of decentralization, which EigenLayer inherits from the Ethereum trust network.
- Federated Learning: Enabling multiple actors to participate in training AI engines ensures the privacy of datasets. For federated training to succeed, decentralization of actors is essential, a feature EigenLayer provides.
Wrapping Up
The above ideas around Rollup Services, Applied Cryptography, General Decentralized Networks, MEV Management, and AI Inference represent only a handful of the use cases that are emerging from the EigenLayer ecosystem. The true potential of the EigenLayer trust network is limited only by your imagination.
We are thrilled to introduce EigenLayer as a versatile toolkit for others to craft their own protocols and services via programming trust for decentralization, economics, and Ethereum inclusion.
While we have envisioned and outlined some of these possibilities, most innovative applications are yet to be conceived. If you’re excited about these primitives, join our private research discussion group here: https://bit.ly/programmabletrust