Validators are recorded on the beacon chain and assigned an index with any valid (i.e. >= 1 ETH) deposit amount. They only require a >= 32 ETH balance for the activation_eligibility_epoch to be set.
How could it work with trustless pools?
After money transferred to other validator, ownership to share is lost. Giving an ability to do this by owner of validator key breaks any trustless mechanism.
Two points for trustless pools:
- the requirement for the withdrawal key to allow transfers would mean that this would be an approved operation. If the pool didn’t trust the validator to do the right thing then it could not allow transfers (or punish a validator that transfers to an incorrect validator)
- with shared secret validators multiple validators would have to agree on the transfer, removing the trust requirement on a single validator
I think at this point we shouldn’t assume how trustless pools will work… that could change significantly.
Not sure if my suggestion was talked about. What if we just trigger a transfer via block proposal to the pre-defined eth1 address?
That would require the merge, the proposal is to keep these transfers purely on the beacon chain.
gotcha. In that case my vote is to not allow excess transfers until the merge.
I think that’s what we signed up for.
Also, enabling excess transfers will inherently create a secondary market for eth2, not sure that’s a good idea until the merge.
This proposal is designed to allow transfer of excess balance without requiring the merge. If we require any movement of funds to go through the Ethereum 1 chain it will make what should be a simple operation a complicated one for no benefit.
I don’t see how this proposal creates a secondary market. The timings of transfers are largely unknown, the amounts undetermined until transfer, no pre-conditions can be enforced, and there is no liquidity for the recipient as they will have no excess balance them self.
- Shared pool cannot have withdrawal key, so it could work only for individual users
- Target validator couldn’t split money, user don’t know where is this validator’s withdrawal target. Even if it’s a eth1 contract, it could split money only manually after all. So as I say, it doesn’t work with trustless pools
Every validator has a withdrawal key. There are efforts to shard this withdrawal key, or make an eth1 contract address serve as the withdrawal key, to improve trustlessness, but there has to be somewhere for these rewards to go at validator exit.
But as @jgm has said, enabling this feature to allow a validator to transfer it’s excess balance would be optional, and could remain disabled for trustless pool use cases.
Yeah, shared pool has eth1 contract address as withdrawal, so no key
In that case, the eth1 contract address probably would have no way to permit this balance transfer anyways. So it should be a non-issue.
1 Like
I would imagine exchanges enabling this type of trading easily, only caveat is how long will it take a user to deposit the funds… even if it takes a week it’s worth the liquidity upside.
Once you’ve transferred eth2 tokens to the exchange validator address you Can trade it.
Exchanges can, and are, tokenizing staked Ether without the presence of this proposal’s functionality. As such, I don’t see how this can be considered an enabler of such functionality.
1 Like
If this is accepted, the validator keys take complete control of the funds over MAX_EFFECTIVE_BALANCE. From what I gather from original design and discussion, that is not desirable: the premise is that withdrawal credentials can move funds, but not validation keys.