Withdrawal Credentials Exits Based On A Generalized Message Bus

[ccitizen]

This would require that the LSD protocol holds the pre-signed (never expiring) exit messages from the validators right? That doesn’t seem like a good, or safe, long term approach. Thoughts?

[Wander]

This would require that the LSD protocol holds the pre-signed (never expiring) exit messages from the validators right? That doesn’t seem like a good, or safe, long term approach. Thoughts?

Yes, agreed on all points.

It’s an imperfect solution, but it’s better than nothing, and it’s quick. If we can prioritize a full solution, then let’s definitely do that, but if not, I think this is an easy step forward in the meantime.

[vshvsh]

@ccitizen

Or, perhaps I should say, I truly hope they do not listen to the community and try to decentralize further without first getting a solution to the inability to exit forcibly. But, I fear they likely will.

We can limit the risk a lot by limiting the amount of stake going to a permissionless/unvetted operator if we can solve the white label operator/identity problem. Withdrawer-initiated withdrawals are not a blocker to meaningfully increase the number of operators in Lido, the identity problem is. Allocating the majority of stake to them without a introducing major bond would be problematic without withdrawer-initiated exits.

@ccitizen

If an existing large operator running validators for a LSD pre-signs all of these messages, and they are always valid, at any point the LSD can exit those validators which is fantastic.

The big concern here is centralization risk. Having protocol functioning directly dependent on yet another body that has to handle the secrets is not great. Removing people from the loop is preferable.

[ccitizen]

@vshvsh

We can limit the risk a lot by limiting the amount of stake going to a permissionless/unvetted operator if we can solve the white label operator/identity problem. Withdrawer-initiated withdrawals are not a blocker to meaningfully increase the number of operators in Lido, the identity problem is. Allocating the majority of stake to them without a introducing major bond would be problematic without withdrawer-initiated exits.

Agreed. I’m being involved with conversations on Lido side to help with this as I’ve been working on a model for ordering entering and exiting of validators for a couple hundred hours now. Hopefully can help to bring some ideas to what your team already has progressing.

I think there is a path to diversifying Lido operators even without solving the identity problem, and without requiring collateral to the extent of limiting capital efficiency meaningfully. I’ve been talking to Izzy about it.

@vshvsh

The big concern here is centralization risk. Having protocol functioning directly dependent on yet another body that has to handle the secrets is not great. Removing people from the loop is preferable.

Agreed, this is not an ideal solution long term. Though I do think it’s worth weighing up the time that would be required for an EIP to go live to do this properly, if that does end up being a solution that’s approved and added to the codebase. If it’s 1+ year, an interim solution like above, where Lido would centralize the keys here might be an acceptable option when the alternative is to wait 1+ year (potentially, just a guesstimate), or wait likely longer for the Nethermind solution to identity.

Personally, I find centralization of keys with Lido in the interim to be an acceptable tradeoff, but I know many would disagree. My main reasoning for this is that the current system requires a worse centralization, which is with the reliance on node operators to act faithfully. I think it would be helpful for more of these conversations to be had in public, so that Lido users can weigh-in on tradeoffs here.

Thanks for your response Vasiliy.