I've written a bit about EigenLayer in the past, and have gotten to know and chat with some of the team members. The team is absolutely stacked and deeply academic (largely Sreeram Kannan and his graduate students).
EigenLayer has been making the rounds on CT. Nick Prince (Crypto Product + Ventures @ Coinbase) recently tweeted:
Keep building @sreeramkannan
eigenlayer.com/whitepaper.pdf
35
It's a well-written whitepaper that is easily digestible even for less technical/non-crypto people (Bitcoin whitepaper-esque). A few immediate thoughts:
Leverage
From the paper:
For example, (1) a bridge can restrict the value flow within the period of slashing, (2) an oracle can have bounds on the total value transacted within the period, etc. However, this solution depends on the designer of those AVSs. The other solution is where EigenLayer can actively increase the CoC for corrupting AVSs. Here, we have a generalized analysis of restaking security where we consider that any set of stakers can collude. If the set forms a majority quorum on certain AVSs, they can potentially extract a PfC from those AVSs. We have a mechanism to determine whether an operator or a set of operators, who are restaked with EigenLayer, are potentially at risk of creating a security vulnerability via some collusion or not.
The paper goes on to say that the EigenLayer protocol itself has risk detection/mitigation measures, but I'm unsure that the protocol will be able to detect every permutation of potential collusion, especially in the early days.
I've written about this in my Minimum Valuation Framework post:
Instead, a given crypto protocol's valuation is related to its dapps and middlewares (or any party that purchases its secure blockspace) in a more subtle way. One should compare the economic security provided by stakers (not the total market capitalization) and the aggregate volume secured by the stakers over a given time horizon. This is to ensure that the net amount of secure, decentralized blockspace being sold is not greater than the aggregate amount being purchased and transacted on by dapps, middlewares, etc. This is to ensure that the protocol is not overleveraged and resides at a local equilibrium.
This is only a first-order analysis. The relationships will only deepen and become increasingly complex (like MEV).
Trust Committee Usage
In order to avoid such a scenario, we use a reputation-based committee comprised of reputed individuals in the Ethereum and EigenLayer community. This committee will hold the re- sponsibility of enabling upgrades to the EigenLayer contracts, reviewing and vetoing slashing events, and admitting new AVSs into the slashing review process. Note that the veto committee has no power to maliciously trigger slashing by itself, and that any upgrade to the EigenLayer contracts comes with a time lag.
and
This veto committee can be considered to be training wheels for new AVSs onboarding onto Eigen- Layer. The AVSs can use this veto committee to assure EigenLayer restakers that they will not be subject to malicious slashing or inaccurate slashing due to bugs, as there is always a fallback to the committee which can veto the slashing. Meanwhile, AVS developers can battle-test the codebase as- sociated with the AVS. Once mature and getting enough trust from restakers, an AVS can stop using the veto committee as a fallback. The trust assumptions for using the veto committee are that the AVS must trust the veto commitee will not veto a correct slashing, while the stakers restaking in EigenLayer must trust the veto committee will veto any unjustified slashing by the AVS.
I don't necessarily think that this is the wrong approach, given how far EigenLayer is down the stack (the consequences of suboptimal outcomes have rippling effects on the entire Ethereum ecosystem).
Is a 2016 DAO hack moment a possible (or even likely) outcome? I can see a future where the trust committee is put in a difficult situation and splits the community and leading to a possible hard fork.
- Loading comments...