Since we are handling a large number of validators, we are thinking about having multiple validators using the same withdrawal address, for speed and cost reasons of the further handling of funds. However that introduces a potential accounting traceability problem.
Will it be possible to somehow enumerate through all the
execution_payload.withdrawals ... List of [index, validator_index, address, amount]
specified in EIP-4895 performed on the execution layer, to trace the specific transactions per validator ?
Hey @ralexstokes! Are validator gas tips included in the automatic reward push on top of the 32 ETH or are they withdrawn in a different way? Also, can rewards and principal be withdrawn simultaneously? Thanks!
“gas tips” would fall into execution layer rewards and those go to the feeRecipient set in each block
entirely separately, validators get rewards for various duties performed at the consensus layer and those rewards are subject to withdrawals via this EIP-4895 mechanism
you can withdraw “rewards and principal” at the same time if you have exited the validator and it becomes withdrawable
Do partial withdrawals (where the remaining principal after the withdrawal is greater than 16 ETH) require the validator to be exited? If not, is this an immediate withdrawal to the beacon chain?
I was also wondering if the withdrawal operation will require the validator key and the withdrawal key or just the withdrawal key? Thanks!
Question (maybe naive).
With the recipient address on the Withdrawal object being any ETH valid address (including smart contracts), could this affect applications on the EVM assuming that the contract should never have an ETH balance?
Maybe it is just that because of SELFDESTRUCT this should simply not be assumed, but to me looks like something pretty important and new, if working like that.
“partial” withdrawals refer to a validator balance over the MAX_EFFECTIVE_BALANCE which is 32 ETH on mainnet – the intuition is that each validator is about the same “size” by stake and doing so simplifies reasoning/analysis of the protocol
partial withdrawals do not require the validator to be exited, if you exit the validator you start moving to a place where the entire stake becomes withdrawable
withdrawals happen automatically once some conditions are met – a big one is upgrading the “withdrawal credentials” – expect more information soon about how to do this; but in short you’ll need to sign a one-time message to change your “version 0” withdrawal credentials to a “version 1” withdrawal credentials which contains the destination execution layer address
which applications are assuming a contract never has an ETH balance?
I see a scenario where perhaps ETH is sent to a contract (likely by accident) and that ETH is not retrievable (i.e. “burnt”)… but that falls into the category of “user error”
I’d say it is not so much about the direct impact on applications, because currently, due to SELFDESTRUCT, (and coinbase) is just not possible to design assuming the contract will not have ETH, even if (talking Solidity) you don’t have payable functions and revert on receive() and fallback().
But probably quite important to document that from this upgrade, another scenario no which your contract could receive “unexpected” ETH, is as result of a withdrawal.
Is it correctly understod that voluntary-exit and BLSToExecutionChange commands are send directly to the beacon chain using a validator and does not cost anything (gas etc)
What is the expected capacity of these commands
If you for example have 10.000 validators that you want to either set an address or signal an exit
How fast would that be able to execute ?
It is possible to send ether to contracts using selfdestruct and coinbase payments, even if those contracts would usually revert when they receive ether.
right the SignedVoluntaryExit and SignedBLSToExecutionChange messages are “operations” at the consensus layer and we don’t have use a gas model to handle DoS concerns there (we just have relatively small fixed limits per block)
iirc it is 16 exits per block and also 16 credential changes per block – we get a block at most once every 12 seconds
With these, the withdrawals_root and txs_root will eventually match the values in the CL ExecutionPayloadHeader, and the mentioned issues will disappear:
With this proposal to push staking rewards (in particular ethers in excess of effective balance) into ETH1 addresses, there are interesting tax implications.
Regarding taxes, users often prefer to have control over when their rewards are distributed, as opposed to automatically distributed. With this proposal, once a user updates their withdraw address from BLS to an ETH1 address, they lose control over timing their rewards. Do you have any suggestions on how this can be improved?
Hi I currently have a few questions regarding how Beacon Chain updates the user account balance
Now the balance is tracked for each validator, how it’s tracked for each EOA address before / after Shanghai Upgrade?
When the EOA balance will be updated along with the Shanghai Upgrade? Is there any execution process that needs to be triggered by someone?
I guess the second question is dependent on the first one, if the balance it’s already tracked by execution layer (ethereum), then I guess there’s nothing needs to be done. Otherwise I suppose there will be a phase of updating all user’s account balance?
For the exchange of historic withdrawals, ideally there would be a version byte similar to EIP-2718 for consistency, and to enable clean upgradability to SSZ.