Round 8 - GMC Community Discussion of Submitted Applications

Help me understand a bit more about this bounty proposal and you’re subsequent discussions on its merits.

Here is my understanding of EigenLayer: An Ethereum validator could participate in Eigen Layer (EiL) by setting their withdrawal credential to be some yet-to-be-developed Eigner Layer smart contract. Once enrolled in EiL, a NO could participate in several Actively Validated Services (AVS) of their choice. For these additional computing duties, the NO would be paid for running AVS software on their node. To be eligible for this participation, the NO would need to promise their NO validator deposited funds as a surety bond to ensure they were honest and reliable in performing their AVS duties. EiL would have a mechanism to force-exit one or more enrolled validators so they can redeem their surety bond.

In the case of a solo validator, there is an excess NO deposit as the validator deposit (32 ETH) exceeds any non-correlated Ethereum protocol slashing penalty (~1.5 ETH). This excess deposit amount forms the foundation of EiL; This “unused” collateral could be retapped (promised to EiL as a surety bond) and thus the word “restaking.”

My thoughts on what an RP NO integration could look like. If an RP NO were to join EiL (say by locking and setting their Withdrawal address to the above EiL smart contract), the only collateral that would pass through to the EiL would be the NO deposit and not the rETH deposit.

In the case of LEB16 and LEB8 minipools, excess NO ETH can be used in EiL as the surety deposit. For example, if a NO has four LEB8s their deposit would total 32 ETH. Non-correlated Ethereum slashing exposes about 6 (4 * 1.5) of the ETH at risk. So EiL would have an assurity bond of about 26 ETH (32-6), which compares well with a solo validator of 30.5 ETH (32 - 1.5).

In the current state, I see a business case as to why we should provide this option to NOs to access additional earning potential.

But I need help to see the use case in our envisioned world of Megapools where nearly 100% of the NO deposit would be used towards this minimal assurance to protect against adverse Ethereum slashing events.

With the future of RP being focused on Megapools, not minipools, RP wants as much (if not all) of the NO deposit to apply to being exclusively used to protect against non-correlated slashing and MEV theft. Reducing the NO deposit to the minimal viable amount allows RP to grow as capital efficient as possible. In the above example, where a RP NO operator has 32 ETH, instead of running four LEB8s we envision a post-Saturn world where that NO would run a single Megapools with 16 validators. Each validator in that Megapool has 2 ETH of NO deposit to protect rETHers if the NO commits a slashable error.

(Note: Research with the variable node deposit amount is needed to ensure that only a few ETH per validator is sufficiently large enough to protect against MEV theft and likely slashing events.)

For example, suppose we reduce the NO deposit on a sufficiently large Megapool such that each validator only requires 2 ETH. In that case, little ETH is remaining for EiL to access as a collateral deposit. This leaves only 0.5 ETH (2 - 1.5) of a surety deposit for EiL.

My questions:

  1. Is my understanding correct in terms of how EiL works
  2. Is my understanding on how a possible EiL integration with a RP node would be designed?
  3. If so, why is this bounty needed if we are envisioning a Megapool world?