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
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:
Here is a possible interface for a predicate-based Eth1 controller contract:
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)?