Okay, first reaction to this proposal: it feels like we’re not taking advantage of the fact that withdrawal credentials are BLS signatures. There’s a chance to enormously compress withdrawal data here, which could be super useful depending on how the eth1-beaconchain docking ends up working. Wouldn’t it be nice to be able to aggregate the signatures for withdrawals? Maybe it doesn’t matter, but that’s just where my mind goes. I want to try and put more thought into that, maybe others can too. That’s more of a sidenote though.
2nd reaction: how can trustless pools use this method to make a safe deposit? You have to be able to commit to the withdrawal contract before depositing. But if you’re not even on the beacon chain, you can’t use this method afaict. Or did I miss something?
3rd reaction, @djrtwo let me explain why I had room for updating the withdrawal address in DSWC, and the large number of use cases which depend on this capability.
There are several different aspects to this, so I’ll go through them one by one.
Partial withdrawals
As @jgm has already pointed out in his other thread, there are strong reasons why validators will want to withdraw amounts above MAX_EFFECTIVE_BALANCE without withdrawing the rest of the validator balance, and why we should let them do this without having to make a full exit (churn, etc.). This means that (especially if we were to go with my suggested “single bit” modification to his proposal) withdrawal addresses are not going to be single use, and they should have the option of being updateable.
Split keys
One BLS key does not imply one entity. There are a myriad of situations where split keys might specifically not want to leave the withdrawal address un-set, but might also wish to change it in the future. If one of a set of keyholders wants to quit, for example, they can just give/sell their keys to the other keyholders, but the withdrawal contract which would have presumably divided the proceeds will then need to be updated. As new, more advanced contracts get developed specifically to handle as-yet-unprocessed withdrawals, keyholders might want to upgrade provided that they can all agree. If there is a staking service which does the validating they might want to share ownership of the withdrawal key with the client so that they can update the policy under which withdrawals are governed; if there is a DAO the keyholders of the DAO might want the ability to change their minds; etc. It’s also important to note that until the EVM supports BLS operations this is the only way to take advantage of BLS functionality, since you can’t just write BLS support into an EVM contract.
Loss/theft of credentials
Right now we have the lovely property that for most participants in the beacon chain a single mnemonic backup protects both their validator and withdrawal credentials. Given the length of time it might be before withdrawals become possible, someone who owns their own validator outright and is not trying to make a commitment to any other party might want to set their withdrawal address to a cold wallet or something to provide a nice level of “safe” redundancy. Then if they lose all their validator/withdrawal credentials they will be eventually exited for inactivity and recover at least some of their funds. However if they retain control over their mnemonic and lose access instead to the withdrawal address over that time, they can simply restore their withdrawal credentials from their mnemonic and set a new one.
Obviously, even taking the three above considerations into account we still absolutely need the ability to set a non-revocable address for trustless pooling and other use cases which do not have a specific set of keyholders who can be trusted to control withdrawals.