Blockers to ossification

1

With ossification talk moving at wombat-speed (almost as fast as Usain Bolt!), maybe it’s time for a topic that considers blockers to ossification.

As in, what Ethereum protocol initiatives need to be solved before RocketPool can ossify?

  • EIP-7002 - exit initiated by withdrawal address. This seems relevant, and may be here with the e-Star hard fork, well before ossification. Does it impact the smart contracts?

  • Raise max effective balance to above 32, with auto-compounding, and potentially EL-initiated partial withdrawals. Does it impact the smart contracts? I expect yes. Proposal

  • SSF, single slot finality. Should not impact RocketPool contracts one way or the other.

  • ePBS, enshrined proposer builder separation, ditto. Curious to hear from those who actually read the contracts, though.

  • Verkle tries - I expect this has no impact, but say if it does.

  • oDAO duties removal - yes. The point of ossification is to remove the last duty oDAO have, overseeing contract upgrades. The two go hand-in-glove.

Anything major that we know is coming, that I’m missing?

3 Likes
2

EIP-7002: the question is how we wish to use it. Allowing exits from the RP withdrawal address seems a no-brainer. Using it for abandonment forced-exits seems straightforward too. Penalties by oDAO and kick by oDAO don’t mix well, so we’d need something more fraud proofy to kick with for MEV theft I think.

Max effective balance could plausibly not impact the smart contracts if RP only allow 32 ETH validators. But it’s an opportunity, since it would be more gas efficient for operators to distribute from just one big validator.

MEV burn has been floated; that’s related to ePBS but might have its own implications. I think this would be a huge impact cuz a lot of our security worst cases are MEV related.

Adjacent conversation:
I think there may be a worthwhile pre-ossification point where we say “ok - this is pretty darn stable, we can make it really annoying to upgrade”.

We have plans to get the pDAO on-chain. If that’s available we could require both pDAO and oDAO approval on upgrades. Could phase it in smoothly with a very low percentage needed and increasing. Could also be phrased as a veto, but I think it amounts to the same thing.

2 Likes