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
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.
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.
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.
2 Likes
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.
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.