Implement skim() in EigenPodProxy.sol

[JasonVranek]

link to notion

[CheyenneAtapour]

WAIT: Need to get / prove the validator index associated with the eigenPod in order to check status of that validator (and determine the case we are in for skim())

Seems like this is currently determined via proofs supplied to eigenPod in the withdrawal functions

Assuming someone has already called one of the withdrawal functions on the eigenPod by supplying such a proof, we can just allow resubmission of the same proof to skim?

There is a mapping I can use that maps pubkey to validator status within eigenpod - also a function

[CheyenneAtapour]

DONE: How do we determine if rewards are coming from an AVS? -I think it's possible for an AVS to send rewards from an address different from the contract / EOA wallet which defines the AVS

Assume funds that come from ServiceManager are from AVS

Later on, maybe PaymentManager

[JasonVranek]

1. for the withdrawBeforeRestaking() case, thevalidatorIndex is not required which is convenient in the short term for testnet sprint. Ideally our proxy.enableRestaking() would save the validator index upon success, but for some reason verifyWithdrawalCredentialsAndBalance() is public, so we can't rely on this.
2. We can save an AVS address on a successful call to enableRestaking(). I don't think it's unreasonable to assume the ServiceManager contract will be sending ETH rewards. Then in the fallback function we can check if the rewards came from whitelisted address.

[JasonVranek]

I asked the EL team: "I'm curious the motivation for not restricting EigenPod.verifyWithdrawalCredentialsAndBalance() to just the podOwner? Someone content with calling EigenPod.withdrawBeforeRestaking() can be forced to opt-in to restaking which will require the slow withdrawal process. Asking since we're in the middle of implementing our Pool's rewards splitting logic."

they got back with:

"This design decision was deemed necessary to ensure that Validators could not remain "overcommitted" for significant time in EigenLayer.

We are actively redesigning multiple mechanisms of EigenPods to clarify & simplify, which should result in an improved user experience. Specifically, I believe we should be restricting access for at least the first call to EigenPod.verifyWithdrawalCredentialsAndBalance() that "flips the switch" which disables future calls to EigenPod.withdrawBeforeRestaking(). I haven't reviewed all changes in detail yet though, so there may be additional changes that help assuage your concern further as well."

How this affects us:

• the validator will always be in the VALIDATOR_STATUS.INACTIVE state until the first call to proxy.verifyAndWithdraw() which should be restricted to the podProxyManager and podProxyOwner. Calling this will update the EigenPod to VALIDATOR_STATUS.ACTIVE and should store the validatorIndex in the EigenPodProxy.
• Until the first call to proxy.verifyAndWithdraw(), we can safely skim() without checking a valid validatorIndex because the withdrawBeforeRestaking() only transfers ETH while hasRestaked == false.
• After we have saved the validatorIndex we can use this in skim() to handle the other cases

[CheyenneAtapour]

TODO: Testing: Make dummy eigenpod, pufferPool contract, put money onto eigenPodProxy, change state variables, and see if funds are distributed according to specs

[CheyenneAtapour]

Waiting for eigenlayer contract changes to hit master to update getting validator status Holding off on implementing VALIDATOR_STATUS.INACTIVE case for now