- Why there is Need for Bounded Withdrawals?
- What Methods or Constants are changed?
In the latest Consensus Layer Call #98, Alex Stokes gave updates on Bounded Withdrawals Sweep Proposal. Alex Stokes explained that developers have recently changed a little on how they were doing withdrawals.
- This solution adds only one field,
latest_withdrawal_validator_index, to the Beacon State that keeps track of the last validator that has performed a withdrawal.
- Proposers pack up to
MAX_WITHDRAWALS_PER_PAYLOADin their execution blocks starting from the next validator after
- There is no epoch processing logic, as there is no queue to include withdrawals.
- Also, it removes unnecessary constants like
According to Potuz, there are some problems associated with this solution. There can be a problem with validators being slashed after a partial withdrawal. This can be an issue for validators that get slashed for more than
MAX_EFFECTIVE_BALANCE. Also, a validator can end up with a slightly low
MAX_EFFECTIVE_BALANCE right after performing a partial withdrawal.
Adrian Sutton was in support of this PR, but he was nervous about the need to scan a lot of validators to find the required number of withdrawals and this will happen on every block import. Paul Hauner also supported this PR because it adds fewer items to the state. Although, he accepted that this PR had some downsides too.
He further added that its scanning every block problem is solvable. Developers could attach to the state a
[uint64; MAX_WITHDRAWALS_PER_PAYLOAD * SLOTS_PER_EPOCH], which contains an ordered list of validator indices that are available for withdrawal. When that list is empty, or the last value equals
last_withdrawal_validator_index, then we know there are no more withdrawals to dequeue.
Why there is Need for Bounded Withdrawals?
After the discussion on the PR by Potuz, the worst case behavior during withdrawals processing was the complete scan of the total validator set on each block. So, it would be nice to bound the length of the scan. Alex Stokes proposed that we need to add a constant
MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP and add it to
get_expected_withdrawals in that PR on the line that scans the validator set, i.e.,
for _ in range(MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP):
Alex Stokes also suggested the value
2**17 for this new constant, which is around 1/4th of the validator set against current mainnet numbers.
What Methods or Constants will be changed?
- A new section,i.e., Withdrawals, will be added in the Constants.
- There will be a slight change in the
get_expected_withdrawalsof the Beacon Chain Transition Function.
## Removed for _ in range(len(state.validators)): ## Added for _ in range(MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP):
- There is also a slight change in the
process_withdrawalsof the Beacon Chain Transition Function.
else: # advance sweep if there were no withdrawals next_validator_index = (state.next_withdrawal_validator_index + MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP) % len(state.validators) state.next_withdrawal_validator_index = ValidatorIndex(next_validator_index)
Danny Ryan initially did not like this idea as it would increase additional code complexity. But later, when he learned about the optimizations that CL client teams may be forced to do in the absence of a sweep bound. So, later he also supported the proposal.
- Consensus Layer Call #98 [2022/11/17]
- The Merge Transition
- Ethereum: The Great Renaming
- Proof of Work
- Proof of Stake
- How to Join Kintsugi testnet?
- Kintsugi Fuzzer Issue
- What is Kiln Testnet?
- How to Join Kiln Testnet?
- An overview of expected changes with the Ethereum Merge upgrade
- MEV in DeFi
- Ethereum Mainnet Shadow Forking: An Overview
- What do Bellatrix, Paris & TTD mean in Ethereum Merge Upgrade?
- Ethereum's roadmap for 2022 and beyond!
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at email@example.com.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!