Withdrawal Credentials Exits Based On A Generalized Message Bus

I would prefer to only introduce a mechanism that is safe from spam of CL through validity conditions on EL.

For example, only one valid exit can/should be made per active validator. Thus you have a very easy way to rate limit if EL has perspective on that which is possible if a beacon_root opcode or some other info is exposed to EL. I’d personally only want to couple this when sufficient proofs can be made in EL to prevent the CL spam, otherwise griefing the ability to exit is too easy.

Similarly, 0x01 rotation (if added) could be rate limited – e.g. one per validator per month – and the EL contract can easily track this (as long as proofs can be made about limited CL state)

  1. I don’t think this should be added with withdrawals given the complexity of withdrawals and the many other high priority items attempted to be added. additionally, I only think this is safe for CL with better spam protection which greatly increases the requirements of this proposal
  2. Yes, I do agree that EL-based withdrawal credentials should be able to trigger some set of events. At a minimum exits. I’m unsure about the key rotation. that can/should easily be programmed into the 0x01 addr itself… Just use a multisig with some rotation rules or something
  3. Maybe ExecutionLayerExit or something
1 Like

And this was understood from the first version of the beacon chain specifications. I would be very wary about anything that changed this in case any services relied upon this feature of the specification.

1 Like

I see a trade-off here between

  • making EL aware and dependant on the details of CL
  • degree of possibility of CL spam

where it is not clear what’s worse.

2 . But we need a way to rotate old 0x01 to the enhanced 0x01 addr in the first place, don’t we?

Could you, please, provide an example of such a service or a problem due to the violation of the assumption?

No idea, I’m not saying that there is anything out there that relies on the specifications. What I am saying is that there could be something out there that relies on the specifications, and changing it could impact them.

If you want a hypothetical: validator key holder runs a validating service on the basis that they charge 50% of the value of the validator over 32 ETH when the withdrawal happens. They can be sure they will be paid because they can withold the exit transaction until a payment agreement is in place (smart contract, escrow, direct payment, whatever).

I would like to propose that this type of proposal might be the only way to keep solo staking competitive with liquid staking options.

Currently a liquid staker can get around 2.5x the returns of a solo staker via usage of leverage such as icETH | Interest Compounding ETH Index | Index Coop with minimal risk

Solo staking needs some kind of liquidity as well to allow borrowing. This seems only possible with allowing protocols to forced exit a validator to get their collateral.

Using staked ETH as collateral to borrow is such a bad idea. It reduces the cost of an attack, and in such case lenders will be wiped out.

1 Like

We’re trying to identify the next steps to elaborate the approach with no CL-aware checks on EL.

It seems, currently the main problem to work on is the question whether it’s OK to not include invalid requests in BeaconBlockBody. Namely, from the perspective of capability of lightweight clients to validate the Becon Chain.

If it’s OK, the next question is if the checks on CL clients can be done before the checks for, e. g., the Voluntary Exit requests.

@djrtwo and others, what do you think should be our next steps to move this proposal forward?

1 Like

It seems, currently the main problem to work on is the question whether it’s OK to not include invalid requests in BeaconBlockBody . Namely, from the perspective of capability of lightweight clients to validate the Becon Chain.

What would be the way to achieve that other than validating requests in the contract? Which would require BEACONBLOCKROOT opcode.

Has there been any further discussion on an approach that would allow for exits using only withdrawal credentials?

Likewise, is anybody aware of any further drafting of an EIP proposal in the background that would allow for something like this?

This conversation seems to have been entirely dropped and with withdrawals upcoming this is concerning. To be clear, this is not a criticism of Ethereum contributors.

@jgm you’re always across all critical discussions and your input on this broad conversation since 2020 on the forum and Github has been extremely valuable. Do you have any awareness of additional discussions beyond this latest one?

@arwer13 please share whether further drafts to solve this issue have been discussed with key Ethereum contributors to find a solution that is realistic to include.

@djrtwo any input here?

(apologies for double post, can only mention two users per post as a new account on the forum)

I suspect that once withdrawals are in place any user that is uncomfortable with their reliance on the validator key (or more accurately validator key holder) will exit and re-enter, thus avoiding the issue.

If, once withdrawals are in place, there is a large percentage of validators that cannot withdraw due to recalcitrance on the part of the validator key holder this, or something like this, may become relevant again.

I think this is overly optimistic. We must remember that most stakers are non-technical. Having read a lot of the Lido forums and Discord, and spoken to institutions deploying millions, I’m quite confident that most of the capital in Lido is contributed by people who do not understand that Lido cannot forcefully exit the validators and get the ETH back.

I tend to believe that in the immediate future, this is likely not an issue. Most of the validators are run by reputable node operators, who likely obey the requests.

But, for a long time many of us in the community have been frustrated with the centralization and risk concentration that has happened as a result of Lido.

Yet, there is no way they can improve this without the ability to exit using only withdrawal credentials, without entirely redesigning the protocol, which is unlikely to happen.

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.

I’m not massively concerned that there will be a “large percentage of validators that cannot withdraw due to recalcitrance on the part of the validator key holder”. I’m thinking about the incentives this creates in the system of LSDs, where the node operators need to be a party that can be trusted in this way. This has incentivized heavily centralization beyond what many of us consider ideal, or even acceptable.

Allowing for exits and withdrawals using only the withdrawal credentials makes a significant improvement to the incentives in the system. This improvement could directly lead to meaningful shifts in entity, jurisdiction, server geography and hosting concentrations, by allowing LSDs to admit smaller, solo or anonymous operators into the validator set.

The reality, right now, is that capital concentration is a limiting factor in diversity. Many operators are willing to run validators, but they do not have the capital, which concentrates with a small group of nodes operators.

Exits using only withdrawal credentials shift the risk calculations massively, allowing LSDs and other parties where the capital is concentrated, to allocate to these new, small or solo operators. Improving diversity and helping to better secure the network.

Is there any significant difference between exits using withdrawal credentials, and a provider such as Lido holding pre-signed exit transactions provided by their node operators? The latter requires a bit more effort but has the rather large benefit of existing today.

Hi all, I’m working on a staking protocol and want to share my POV as well.

First, I agree that most staked ETH will be delegated in the long run, and preparing for this eventuality is important. Ethereum core dev is already behind the LSD market (see this post from @domothy during the recent AMA), and it’s important to catch up where possible to reduce added risk for a large portion of the stake.

Second, I respect Lido and believe they will make the right choice on decentralization, but I think it’s important to prioritize improvements which make it safer to run decentralized staking protocols in general. Ideally, Lido decentralizes carefully and many other competitors grow to help divide up the share of stake, but we don’t necessarily live in an ideal world. Lido is a multi-chain DAO which can survive even in the absence of a healthy Ethereum, so it may be unwise to expect caution, especially since it seems that Lido’s top priority is maintaining and growing market share even when that negatively impacts the health of Ethereum.

Is there any significant difference between exits using withdrawal credentials, and a provider such as Lido holding pre-signed exit transactions provided by their node operators?

@jgm Pre-signed exit transactions aren’t valid forever, meaning validators will have to continually submit these in a secure manner to an off-chain protocol administrator. Even if staking protocols go through the effort to implement this scheme, it prevents on-chain automation and therefore stability. Obviously, for Ethereum’s health, we must encourage the stability of staking protocols.

On a more bureaucratic note, there’s clearly a demand for this feature, so how should staking protocols approach this discussion? Is it more important to make the case for prioritization or to iterate on design? I know there are a lot of important features competing for prioritization, but this should be near the top in my opinion, and it seems to me that this approach is sufficient.

Yes, the former is trustless and allows forceful exits preventing bad actors from holding ETH hostage. It also has the nice ability to allow for mass-exits in a short period, where there might not be sufficient pre-signed messages even among good actors. The ability to forcefully exit is the major difference, which is what changes the incentives here.

The latter has no way to be forced. How do you accurately and reliably check whether a node operator has signed those messages? What do you do if they haven’t? It’s hard to punish the bad actor who does not publish them, because they didn’t publish them, so they can’t be exited.

Messages only last 2 forks and so this needs to be entirely automated. You then need to run an oracle to check on this even, which is another point of centralization, particularly when there is going to be little reward for running this oracle.

Given that deposit messages are always valid, could we make that same exception for exit messages? This would solve the problem entirely with a small change to the spec.

The given reasoning for current behavior is that “mixing the fork version into the message ensures that messages from validators that have not upgraded are invalid. They are out of consensus and have no information that is useful to us, so this provides a convenient way to ignore their messages.”

I disagree with this in the case of exits – it is relevant information to the whole CL if a validator wants to exit, and the fork number is irrelevant to that action, just like with deposits.

This partially solves the problem, but not entirely. It is a reasonable solution that does have value though, and could be implemented quite quickly.

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.

But this does not solve the problem of onboarding new operators trustlessly, which is the stem of this issue. An operator would onboard, but could then refuse to sign the message. Automated thousands of times, that’s the same issue as exists now for LSDs.

There would need to be some way to force the validator to send the exit message. At which point, you’re back to the suggestion in the OP essentially.

I do think that this is a good step in the right direction and could be a reasonable enough fix that LSDs could work around. But being able to force the exit with only the withdrawal credentials is, to me, the right solution

1 Like

Good point. This still helps our project significantly since our system is designed to do operator onboarding via reimbursement (operator creates validator with their own ETH with our contract as the withdrawal address, then is reimbursed), but that still requires an oracle/admin due to EL/CL separation. It’s a lot more stable than the raw permission system that Lido, et al use today, at least.

I’m happy to do the legwork on getting this included in the spec if needed, so I’ll bring this over to the relevant github issue here: https://github.com/ethereum/consensus-specs/issues/1578

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?

2 Likes