“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.