TL;DR

Background
Why there is Need for Bounded Withdrawals?
What Methods or Constants are changed?
Criticisms

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.

History

Potuz from Prysm created a PR to implement withdrawals without any withdrawal queue. He wanted to explore more solutions like this solution.

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_PAYLOAD in their execution blocks starting from the next validator after latest_withdrawal_validator_index.
There is no epoch processing logic, as there is no queue to include withdrawals.
Also, it removes unnecessary constants like MAX_WITHDRAWALS_PER_EPOCH and WITHDRAWAL_QUEUE_LIMIT.

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.

Name	Value
`MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP`	`131072` (= 2**17 )

There will be a slight change in the get_expected_withdrawals of 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_withdrawals of 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)

Criticisms

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.