Eth1 withdrawal credentials (0x01)

[djrtwo]

Add eth1 withdrawal credentials by specifying a new withdrawal prefix version (0x01) whose content is a 20-byte eth1 address.

Note, this specifies the minimum required commitment and leaves out the end-to-end details on how the beacon chain and eth1 chain/state will handle the withdrawals other than the fact that the ETH will be transferred into the specified address with no payload other than the ETH and this will be triggered/payed for through a normal eth1 TX.

See this ethresearch post for an end-to-end version of how withdrawals might take place. Note, the only important details for this commitment are that 0x01 withdrawals receipts automatically make it to the eth1 chain and then can be consumed through a normal TX that specifies gas/tx-fees and sends the ETH to the destination address.

This opens up eth1 custody options such as smart contract wallets and simple hardware wallet support along with enabling a number of trustless staking pool options

---

Please let me know if the amount specified in validator.md is clear enough.

I considered creating a fork agnostic folder specs/withdrawal_credentials to specify each withdrawal_credential version independent of any fork. Given that these can't really change once deployed, it might make sense to gather them all in one place. Any thoughts?

[dankrad]

Generally speaking I would like to have this in the spec. I think an important function for any Eth1 withdrawal contract is to initiate the validator exit. This is an essential function for any staking pool (where it's not sufficient to use the withdrawal key to initiate exit).

One way to implement it would be to add a function to the withdrawal contract

def isExitable(validatorPubkey) -> bool:

and any Eth1 address can initiate the "Eth2 exit" precompile that will then use this function to check if the contract allows an exit.

[zilm13]

I would add that in case of using ETH1_ADDRESS_WITHDRAWAL_PREFIX, Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

[dapplion]

Should it be part of the spec what minimal functionality must a contract have if it's an eth1 withdrawal address? i.e. be able to send a simple transaction to a TBD address, receive funds, etc.

[ralexstokes]

I would add that in case of using ETH1_ADDRESS_WITHDRAWAL_PREFIX, Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

i'd think specifying a mechanism for the implementation of moving ETH from the beacon chain to the evm userspace is a little premature given the unknowns around the details of the eth1-eth2 merge. (e.g. we could imagine tracking withdrawals outside an actual contract in the EVM)

my understanding of this PR is more to provide a firm(er) commitment to eth withdrawals to today's eth1 so that the use cases that can get away with just this functionality can move ahead w/ development and implementation.

i do think we eventually want a more involved mechanism for eth transfer (e.g. #2151) but i'd suggest waiting for a clearer understanding of the merge before moving ahead w/ concrete specifics of such a scheme

[ralexstokes]

Should it be part of the spec what minimal functionality must a contract have if it's an eth1 withdrawal address? i.e. be able to send a simple transaction to a TBD address, receive funds, etc.

The PR does specify that the eth1 withdrawal address just needs to be able to accept ETH (e.g. by default as an EOA, or a payable function in a Solidity smart contract). If you look at my prior comment, there is certainly a space for a more complex mechanism for withdrawals (discussion starting here: #2151) but I'd say that is a another iteration of withdrawal handling once we better understand the eth1-eth2 merge.

[lsankar4033]

👍

[djrtwo]

@zilm13

Ether will be transferred from fixed SYSTEM_CONTRACT address, with exact address added later, so contracts could easy clarify who is the sender.

I'm inclined to not even put this in there as it is not an entirely actionable detail today.
Also, assume this is a contract that can split funds or a multi-sig or something. Receiving extra ETH from non SYSTEM_CONTRACT seems fine in almost all cases 😂

[AmethystWizard]

Unstaking BLS to ETH1 - the wagyu gui asks for a 24 word recovery phrase, but metamask offers a 12 word phrase, how to proceed in that case? @dankrad @zilm13 @dapplion @ralexstokes @djrtwo

[ralexstokes]

I don't know how the wagyu GUI works and you should probably ask the maintainers

You may find more information here: https://launchpad.ethereum.org/en/withdrawals

[AmethystWizard]

allnodes.com created a Ledger Nano X compatible tool that ended up working.
https://help.allnodes.com/en/articles/7235575-how-to-change-your-ethereum-withdrawal-credentials-from-0x00-to-0x01-deposit-cli

[Romansharar]

Add eth1 withdrawal credentials by specifying a new withdrawal prefix version (0x01) whose content is a 20-byte eth1 address.

Note, this specifies the minimum required commitment and leaves out the end-to-end details on how the beacon chain and eth1 chain/state will handle the withdrawals other than the fact that the ETH will be transferred into the specified address with no payload other than the ETH and this will be triggered/payed for through a normal eth1 TX.

See this ethresearch post for an end-to-end version of how withdrawals might take place. Note, the only important details for this commitment are that 0x01 withdrawals receipts automatically make it to the eth1 chain and then can be consumed through a normal TX that specifies gas/tx-fees and sends the ETH to the destination address.

This opens up eth1 custody options such as smart contract wallets and simple hardware wallet support along with enabling a number of trustless staking pool options

Please let me know if the amount specified in validator.md is clear enough.

I considered creating a fork agnostic folder specs/withdrawal_credentials to specify each withdrawal_credential version independent of any fork. Given that these can't really change once deployed, it might make sense to gather them all in one place. Any thoughts?

i need eth