Predicate-based eth1 withdrawal

[dankrad]

This is a discussion about an alternative to #2149. I believe that the simple structure given there is not powerful enough for Eth1 withdrawal, and that the final goal should instead be a contract format that provides a number of predicates to allow or disallow actions.

The most fundamental reason for this is that I believe all applications of Eth1 withdrawal addresses are fundamentally very limited if they do not also allow the contract to force the exit of the validator:

• Trustless staking pools cannot work
• Even simpler custodial staking operations will suffer from an additional non-attributable blackmail vector
• We have discussed before (and I am still strongly in favour of) giving the withdrawal BLS key the ability to initiate exit, also useful in case of lost staking keys. If we do not also allow this for Eth1 addresses, they will not have this backup

Here is a possible interface for a predicate-based Eth1 controller contract:

allowExit(validator_pubkey)

allowTransfer(validator_pubkey, amount, destination_address)

The contract can use any internal logic (and, in the future, beacon chain state) to come to a decision on whether to allow any operation. If any of the predicates is true, then another Eth1 address (which is necessary to pay for gas etc.) can make a call to the validator management precompile (or something equivalent) which will call the Eth1 controller contract to check that the operation is allowed.

What is the advantage of adding this functionality now, when we can't specify how Beacon chain state can be read (or aren't willing to as it will constrain the design space too much)?

• Simple "profit sharing" contracts can already now easily add a safeguard to be able to exit in the future, e.g. when a majority of the owners decide to exit
• Staking derivatives can implement a way to exit a certain part of the stake if enough StakingETH comes together, making the promise much more concrete
• More complex staking pools that rely on BFT oracles can already make full use of this even without needing Beacon chain state access
• It allows the contract creator to make a decision now on whether "profit taking" transfers should be allowed or not

[zilm13]

Could you clarify, that allowExit(validator_pubkey) is doing the same as VoluntaryExit in Eth2, both signed by validator key, not withdrawal key?

[dankrad]

Yes. This would implement the suggestion from #1578 at least for Eth1 withdrawal contracts.

[zilm13]

I suggest general Eth1->Eth2 gate if we are going with "Executable Beacon Chain" design proposed by @mkalinin . It will allow one to send any Eth2 message using Eth1 system contract. Without Executable Beacon Chain it's not clear how to implement either the interface you propose or general purpose gate.

[djrtwo]

I don't think we are going to get to a place where we can solidify and commit to such a future-proof predicate interface before we get nearer a merge design and prototypes. Interactions between eth1 and eth2 would require a much more sophisticated machinery than anything currently described in #2149 or even anything we've discussed at all at this point.

In the event that we release ETH1_ADDRESS_WITHDRAWAL_PREFIX soon with a stated, known limited functionality, this will open up more usecases. In a years time, we can consider a more advanced PREDICATE_ETH1_WITHDRAWAL_PREFIX.

What is the advantage of adding this functionality now, when we can't specify how Beacon chain state can be read

I would argue that many usecases are satisfied without beacon chain reads. Profit-sharing, withdrawal-key replacement, tokenization of ownership, multi-sig, etc.

I would suspect any functionality beyond what is in the current PR would block eth1 addr withdrawal credentials for a significant period of time (i.e. at least 9 months)

---

As for transfers, we don't even know if/how these might manifest. Are these validator<->validator transfers, are these early withdrawal of ETH beyond the 32-ETH min. Do they show up as a new operation? Or are they a special trigger by a block proposer.

I don't think we've begun to even scratch the surface on Transfers (and related operations) to be able to consider them in this context anytime soon.