(TrustModel2) Decentralized Trust: There are many services in which violations cannot be attributed / slashed, and such systems cannot be built on a system of economic trust. These need decentralization, which creates difficulty for collusion of a large set of nodes.
Where does decentralized trust in Eigenlayer arise from? Of course, from (a subset of) the large decentralized trust network in Ethereum - there are thousands of distinct home stakers and rocket pool nodes in Ethereum .
Do we need exactly the same set of nodes on Ethereum? No. Once trust is unbundled, it is possible to extract out decentralized trust separately from Ethereum, sometimes with even more power than natively available on Ethereum.
For example it is possible to only recruit home stakers / rocket pool nodes (
@Rocket_Pool) to form a decentralized quorum on Eigenlayer. Each service can specify some further entry conditions based on subjective oracles to recruit only maximally decentralized nodes.
This type of subjective oracle, can *massively improve Ethereum decentralization* itself, as once decentralized nodes are identified and valued by providing additional fees, this increases the net APR of decentralized nodes relative to centralized validators.
(Usecase-4) Secure Multiparty Computation: A simple example is Shamir secret sharing, where a secret is split into N shards to be shared to N nodes. More than T nodes need to collude to reveal the secret. This is non-attributable fault and can instead rely on decentralized trust.
(Usecase-5) EigenDA: It is possible to combine trust models 1 and 2 to create new services. EigenDA built on Eigenlayer uses a dual quorum model, where one quorum can be run by ETH staking economic quorum and another quorum can be run by
@Rocket_Pool ETH stakers.
One needs both quorums to sign off for DA. Now as long as at least x% are honest in at least *one of the* quorum, all non-storers lose their ETH due to proof-of-custody! This model combines economic trust (losing ETH) with decentralization trust (difficulty of collusion).
Furthermore, it is difficult to induce coordination by bribing: as when someone is bribed to sign off a data as available without receiving their chunk, there is a risk that the briber later produces the data and the bribed node gets slashed due to custody proof.
It is possible for EigenDA to be run this manner as it is a fully horizontally scaled layer, in its initial design, requiring only 0.3MB/s per node (much lower than Ethereum staking requirement).
(TrustModel3) ETH Validator trust: While the first and second trust models absorb economics and decentralization from the Ethereum trust network, the fact that it is the ETH validators who restake (by setting withdrawal credentials) enables a whole suite of powerful new features
(Usecase-Family-6) MEV Management. Ethereum block proposers can make credible commitments to order blocks according to different rules, creating a powerful MEV toolkit: (i) selling portions of blocks in MEV market, (ii) agreeing to include threshold encrypted transactions, (iii) agreeing to do event-driven actions, for example, third-party keepers agreeing to activate some event-driven transactions (collateral refueling for example), lead to non-attributable errors (did the keeper not trigger a transaction or was it not included).
MEV-Boost++ is a great example:
https://hackmd.io/@layr/SkBRqvdC5 Ethereum researchers (
@barnabemonnot) are actively considering incorporating this type of thing into Ethereum natively
(Usecase-7) Single-slot-finality. It is possible that when enough block proposers opt-in to a new Eigenlayer task where they agree to not fork a block, we can get single slot finality purely via opt-in. Of course, the interactions with Gasper need careful consideration.
The general form of Eigenlayer articulated here will take time to build and we will lean heavily on the broader Ethereum community to build out once some basic elements are ready.