Allow withdrawal_credentials to point to an eth1 address

[dapplion]

Motivation

The lack of liquidness of eth2 deposits posses a serious centralization risk on Ethereum 2.0. Centralized actors will offer artificial liquidity on user's eth2 deposits, so it's important to facilitate similar decentralized solutions.

Allowing withdrawal_credentials to point to an eth1 address could potentially do that.

See Vitalik's related tweet https://twitter.com/VitalikButerin/status/1297676370936344576

VitalikButerin: If needed we could just allow a feature where you can set the withdrawal key to be an eth1 address, so there would be a contract that would have the rights to future ETH coming out of the validator when it withdraws in phase 1.5+. Those rights could then be "deposited" today.

Allowing staking withdrawals to go to arbitrary smart contracts is actually something that we could potentially enable very easily today (or if we want to respect the spec freeze, in the first hard fork after phase 0). Certainly worth discussing at least.

Proposal

Allow withdrawal_credentials to be prefixed by a different byte.

No changes are required code-wise since both the deposit contract and clients just copy withdrawal_credentials.

// Prysm
beaconState.AppendValidator(&ethpb.Validator{
	WithdrawalCredentials:      deposit.Data.WithdrawalCredentials,
	...
})

The community should just agree that this feature would be supported in the future with a minimal guarantee that it's technically feasible.

[mcdee]

For this to be useful there needs to be a contract at the specified address. For the contract to be operational there needs to be a defined method that the contract understands to either receive or request withdrawal of withdrawable Ethereum 2 funds.

(It could be possible for Ethereum 2 to automatically dump any withdrawable balance in the Ethereum 1 address without notification, but this is unlikely to meet the requirements for a decentralized staking pool as it will have no information on the provenance of the funds.)

I'd like to see a decision on if the transfer should be "push" (ETH2-initiated) or "pull" (ETH1-initiated), and a definition of the method signature(s) an Ethereum 1 contract would need to support to handle this. There is a channel on the Ethereum 2 R&D discord (#withdrawal-methods) where there is an on-going discussion about these areas.

[dapplion]

@mcdee Thanks for the insight, jumping on the #withdrawal-methods channel

[vshvsh]

We at Lido believe that eth1 withdrawal addresses are crucial for eth2; without them, the network has a chance to centralize significantly in phases 0 and 1 and stay this way later due to the market's inertia; and good thing it's almost a non-issue development-wise. Therefore we propose to adopt it at the earliest point in time it's possible to do so (we believe this time is now).

Let us explain the reasons:

1. Eth2 staking is illiquid in Phases 0 and 1, meaning significant inventory risk for stakers. Stakers will have to lock up funds for a significant amount of time.
2. Eth2 staking rewards are fairly low: yields in defi protocols are bigger (see "Why stake when you can borrow").
3. Eth2 staking is moderately complex and risky (remember Medalla debacles, and Chase Wright's thorough Twitter thread on eth2), and works best with 24/7 support, backup nodes, etc - all features of a professional stakers.
4. There's no native delegation mechanism protocol for people to work with professional stakers seamlessly - there have to be legal agreements, kycs, etc. Staking with staking providers is cumbersome (complex legal agreements, KYC, waiting until after Phase 1 for rewards), or custodial, or both.
5. These things taken together mean that eth2 staking in Phases 0 and 1 compared to defi is lower yield, comparable risk, much worse liquidity, and worse UX.

Apart from enthusiasts, most people won't stake themselves, or even using staking providers. The only staking option that can compete with defi yields is exchange-based liquid staking. Network validation will centralize on exchanges: even in networks where staking has better yields, no competing defi, and no year-long locks, exchanges take tens of percent of the total stake. In ethereum, early phases regular staking is so much worse than liquid exchange staking product-wise that we expect the numbers to be way higher.

On-chain staking derivatives are the only way to reasonably compete with custodial, exchange-based liquid staking and custodial staking. They can bring comparable UX, liquidity, security, and add permissionlessness, and defi compatibility, and, possibly, lack of custody. This is something people can and do build already - pioneered by RocketPool, and we at Lido are taking a shot at this too.

The biggest weakness of possible staking derivatives is withdrawal credentials. In current spec, those are EOAs, controlled by private keys. It can be improved by using threshold signatures to make it distributed (we're making software for this) but the better solution is to have something smart on the receiving end of the withdrawal. That way staking derivatives can become non-custodial, and remove big security hole along with a legal weakness.

It can be done by allowing withdrawal_credentials to point to an eth1 address as proposed here. The good news is that it doesn't require any changes in deposit contract, or eth2 clients (we checked Prysm and Lighthouse - they should work as is). It's purely a community consensus thing to agree on "in the future, in Phase 1.5 or Phase 2 we will allow withdrawals on eth1 address".

[dankrad]

2\. yields in defi protocols are bigger

I doubt that long term risk free returns on ETH in DeFi will exceed staking. Where should these yields come from? That would be counter all market logic. From what I can see right now, they are already lower than what is expected in staking (though I do not have a good market overview).

[vshvsh]

For long-term yields in DeFi we have a pretty good historical example: Bitfinex funding rate. It's been floating around 10-20% APR on USD for a long time, just from organic demand from margin trading. Ergo, 10-20% rates can be sustainable for years. Not saying they will definitely stay in that range but that's a possibility.

Current "sustainable" (not farming-related) lending rates are way lower in defi but I'd argue it's a second order effect of yield farming: supply and demand are in large part driven by protocol rewards these days, not just the ebb and flow of margin trades.

Defi rates are not risk free, but neither is staking.

[dapplion]

I haven't seen opposition to setting an eth1 contract address as withdrawal credentials. However, the withdrawal mechanism should be at least somewhat defined before that, and there are still many unknowns for it. Interested stakeholders (including me) are working into a draft proposal for the withdrawal mechanism which should be discussed in the Ethereum 2 R&D discord (#withdrawal-methods) channel

[dankrad]

I see the main danger here that absent a bridge, and not knowing how a future bridge might actually work. So the only real specification we can write is withdrawing all the money using the contracts normal receive functionality, and any other functionalities that may be very desirable (initiating exit/withdrawal, fox example) couldn't really be specced without knowing more.

There's also a big danger in implementing this social convention without really having any end to end testing opportunity.

[leckylao]

I think it's related to #2149. Feel free to remove if I am wrong

[dapplion]

I think we can close with #2149

[atifnimran]

Please help