Eigenlayer Integration Bounty Challenge

Governance
22

Quoting milestone 0 from the bounty:

Research applicants must intend to go on to build the full integration

I don’t believe intend to build contracts and a front end should be part of a research bounty. You risk disqualifying capable researchers that aren’t interested/qualified in contract and front end work.
To me it seems splitting this into an actual separate research bounty is in the best interest of everyone, including those that are strong believers in EiL.

3 Likes
23

I’m about to vote against canceling the bounty but for reducing its scope.

I believe the GMC did the right thing with the tools made available to them (i.e., without being able to immediately defer to a full pDAO vote), but I don’t like the way things turned out.

Reasoning

  1. The research is critically important.
    • It will determine what work needs to be done to integrate with Eigenlayer.
    • It will determine the risks posed by restaking protocols and what can be done to mitigate them.
  2. Given that the research is critical, milestones after the research are premature.
    • They may not accurately describe or estimate the work needed to integrate with Eigenlayer.
    • They may not accurately describe or estimate the work needed to protect against a malicious restaking protocol (more on this below).
  3. The GMC has unilateral power to modify bounties, and while I trust that they will follow through with a pDAO vote as promised, and respect the integrity of the members of the GMC, I shouldn’t have to.
    • A malicious GMC could wait for the 2 week challenge period to elapse and scrub the following pDAO vote. I really think there’s a close to 0% chance this would happen, but because it is possible, follow-up work should be a standalone bounty that itself is subject to a challenge period.

Because of the above factors, the cleanest approach to this bounty is to reduce its scope and start fresh when we have more information.

On malicious restaking protocols:

Rocket Pool is, of course, permissionless. Whether we take on the work to integrate with Eigenlayer or not, it is possible (probable, even), that a restaking protocol will integrate with us without asking for our input. Assume, for a minute, that a new restaking protocol called “slashylayer” decides to accept a RP Node Withdrawal Address change as collateral. Assume they offer you 5 points per leb8 and in exchange they slash your entire stake. A node operator can now exchange their 8 eth bond for 5 points. This may even be profitable to the node operator. Once they change their withdrawal address, they have a strong financial incentive to continue operating their validators and steal MEV.

  1. If they exit, they get nothing (except the 5 points they were already assigned).
  2. If they don’t exit, they can continue running the validator and steal MEV from the protocol, which at a certain size will pay their operating costs and add a healthy profit on top, plus the 5 points they were already assigned.

Forced exits are a stopgap, for sure, but unless we can proactively detect that they have been slashed for their entire stake, the node operator can simply wait for a juicy block, steal its MEV, get forced out, and start the whole process over again. I don’t think it is feasible for us to proactively detect this with a malicious protocol. Eigenlayer specifically may not be malicious and may enter an agreement with the RP protocol to make these data available, allowing us to exit the operator in a timely fashion, but again, we need to do more research first.

Solving the risks

It’s not clear to me that a solution exists (research must be done). It’s entirely possible that RP’s permissionless nature undermines its collateral requirements with the advent of restaking, at least when it comes to MEV theft.

It is critical, however, that we do the research, because Eigenlayer is unlikely to be the last restaking protocol with an interest in integrating with RP. The next one(s) may simply integrate permissionlessly.

Hypothetically, even if we solve these risks, I struggle to see why we would want to fund development on behalf of the protocol that posed them in the first place. Again, research must be done first.

Until these questions are answered, it is premature to codify any plans or potential funding beyond the research.

7 Likes
24

What I don’t understand with this reasoning is: If the GMC can arbitrarily change bounties, why do you think it cannot simply add milestone 1 again, even if we reduce the bounty to only have milestone 0?

25

I don’t think it would hold up in contravention of a pDAO vote. At least, based on the RPIP, it seems that’s the intent.

26

Heh - something like that would be asking to be instantly replaced. There’s levels of things. Tweaking the interpretation of “pDAO has signed off” is a very different level to “the pDAO explicitly said X and we’re gonna do the opposite”.

Importantly, I think we’re all agreed that from a practical perspective we do trust that the GMC is getting a pDAO vote regardless of result.