MaxEB Breakout Room #6

[ethDreamer]

Time: April 16, 2024, 12:00-13:00 UTC
Zoom: https://zoom.us/j/99393718546
Recording: https://www.youtube.com/watch?v=J1i3WtLE-6o

Agenda

• Solicit Input on Consolidations from pools
• Solicit input on custom ceilings from pools
• TARGET_EXITS_PER_BLOCK
• Reconsider EL Initiated Consolidations
• EIP-7251: Stricter bound for consolidation queue consensus-specs#3661
• TBD

Previous Breakout Room

[mcdee]

I am unable to attend the call, but will drop in my thoughts on the items on the agenda. Staring with custom ceilings:

Custom ceilings are a relatively blunt tool that doesn't take into account what many people want to do with staking rewards. Many may wish to consolidate, but cannot do this with a simple ceiling as they will have taxes to pay on their rewards. A custom ceiling is an all-or-nothing solution that doesn't fit very well with the situation before the ceiling is reached (no rewards are available on the execution chain without additional transactions) or after the ceiling is reached (no rewards are consolidated).

A more flexible approach would be a range (0,100) for each validator which defines the percentage of rewards earned to be returned. This gives flexibility to suit all requirements (0 == full consolidation, 100 == all rewards returned) when it comes to selection, and can be altered if required.

Changing the percentage rewards returned would be via a consensus operation, similar to the BLS to execution rewards change. To avoid spam whilst keeping down the additional complexity in the specification it seems reasonable to have a small fee, either relative to the current base reward or a fixed value. Either way, ~1 day's worth of rewards seems a reasonable balance between too-expensive-to-carry-out and so-cheap-you-can-spam-it.

Building this would require two new lists in BeaconState: one for the percentage of rewards to be returned and one for the base off of which the rewards since the last sweep is calculated.

This would not impact the current situation where all rewards over MAX_EFFECTIVE_BALANCE would be returned regardless of the setting.

percentage_rewards_returned List[int8, VALIDATOR_REGISTRY_LIMIT]
rewards_base List[Gwei, VALIDATOR_REGISTRY_LIMIT]

The calculation of the withdrawal amount in get_expected_withdrawals() would need to use rewards_base rather than MAX_EFFECTIVE_BALANCE as the base for calculating rewards, and multiply it by percentage_rewards_returned to obtain the value of the withdrawal.

Note that it is possible for the balance of the validator to change significantly with either additional deposits or partial withdrawals initiated from the execution chain. Any changes that occur as part of this would need to increase or decrease rewards_base, respectively, so that only rewards are considered for withdrawal. Slashing would also need to decrease rewards_base (or is_partially_withdrawable_validator() would need to exclude slashed validators, although that's probably a requirement for 7251 anyway).

[dapplion]

I would like to mention

• EIP-7251: Stricter bound for consolidation queue consensus-specs#3661

[crypto-crack]

I plan to attend the call, and put together some thoughts from institutional SPP perspective:

1 How to Initiate Validator Consolidations
Execution layer triggered consolidation mean: Customers need to do, but they also keep control - translating to more work (because SPP need to explain + hold hands) but lower risk to staking service providers.
Consenus layer SPP also needs to explain but can do themselves (smoother), but need to collect customers order+document.
EL vs not shipping consolidation: better include any consolidation as it combines it with setting to auto-compounding in one operation.
Ease of process = ease of adoption = supporting the goal of network to reduce validator count.

2 Setting Compounding Withdrawal Credentials
Option 2: Anyone in possession of the signing keys of the target validator and at least 1 ETH - these are in our case SPP plus customer, so need to coordinate workflow = bad for adoption, therefore important to have consolidations.
Are there any other possible options? (e.g. why 1 ETH required?)
Otherwise not really a choice but supporting the need for a consolidation mechanism!

3 Custom Ceilings
Not having custom ceilings feels like a push towards adoption of the EIP overall, since it would make it more difficult to keep a 32 Eth minimal balance to limit any additional slashing risk for larger validators (even though it seems the slashing penalties in general are to be greatly reduced, they still seem linearly bigger for heavier validators?).
Hence good for the network, negative/trade-off for institutions (save gas+work on manual withdrawals vs higher risks).
Hence opinionated and defaulting to stake accumulation (which is discussed to be too much security % already?), but probably good to leave out the complexity - OR consider more powerful alternatives as proposed by mcdee above, which sounds compelling from the user side.

Does this design break your accounting / operations in a way that cannot be rectified in time for the fork?
Likely assumptions in different places about each validator having 32 Eth, but could be rectified with some effort.

Does this design prevent you from using EIP-7251 with (consolidating) existing validators?
Consolidation of existing validators is work and potential disadvantage regarding higher slashing risk - this is our main concern right now.
Even though it seems the slashing penalties in general are to be greatly reduced, they still seem linearly bigger for heavier validators?

Does this design prevent you from using EIP-7251 with (consolidating) future validators?
Using heavier (at least optionally) validators: same as above for existing validators

What can we do to better enable you to opt into using EIP-7251?
What happened to the change of mechanism regarding both slashing and penalties from https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509? No matter what the MIN_SLASHING_PENALTY_QUOTIENT is (and obv. 4096 ""better"" than 32), e.g. quadratically applying it instead of linearly would help adoption. If I understand correctly even significantly for any larger staker/entity as it would give them an ""advantage"" - so might be a trade-off in terms of decentralization and might make client majority avoidance less of a priority, but for the goals of this EIP it seems beneficial?!
Opting-in can only happen once work on our APIs+UIs etc is done, so would benefit from early clarity of spec and client implementations.

[mcdee]

My thoughts on consolidation:

Rather than look at the mechanism for consolidation, I'm interested in the outcome and to if it is worth consolidating. Looking at this from the perspective of a staking service, the big win for consolidation is reduced network traffic, but it also brings higher penalties if a slashing event occurs. Looking at the higher slashing penalties, with a few assumptions as follows:

• the slashing event is due to an operational incident (e.g. running the same keys in multiple locations) rather than a software error
• the slashing exposure is only for a single slot, as the service will shut itself down when it sees a slashing event from its own validators (the exposure could be for one or two more slots, but it doesn't make a lot of difference to the analysis)
• validators are either 32 ETH (regular) or 2048 ETH (large)

then there is a cost to consolidating validators in that the immediate slashing penalty will be significantly higher due to the validator slashed having a higher balance. So any consolidation from 32 ETH -> 2048 ETH (1 regular validators -> 1 consolidated validator) increases the immediate slashing penalty. Consolidation past 2048 ETH (i.e. multiple consolidated validators) does not further increase the immediate slashing penalty difference, but maintains it. Hence in a slashing event a staking service running regular validators is likely to suffer a lower penalty than one running large validators.

It could be argued that with the massive reduction in the slashing penalty that is being applied in Electra that the difference is not significant, however customer perception is very important here and if a staking service can state that their customers' funds are less at risk from a slashing event due to them not consolidating validators it's entirely possible that they will use this fact against those that do consolidate.

The best outcome for any staking service will be for them to not consolidate, and for their competitors to do so. This allows them to benefit from overall lower network traffic but retain the lower slashing penalty. However, if all staking services follow this path then consolidation will be minimal.

There is an additional question about inclusion of attestations when some validators are large and hence their attestations are worth more than others. This situation is only likely to matter when there is disagreement on the head of the chain, but that is a much more common situation than it used to be and so should be considered carefully. This appears to be the most compelling argument for consolidation from a staker's point of view, however even with the current situation over 30% of blocks in the past day had fewer than 128 attestations, and total attestation space used was around 88%. So it appears that there would still be space for minority attestations from regular validators in most cases.

Overall, I would say that at current there are significant uncertainties around if consolidation is worthwhile for stakers (those who provide funds, as opposed to operators who run the validators). This could seriously hinder the idea of consolidation in the wider community.

[vshvsh]

Two more things to potentially discuss today:

• slashing risk change after consolidations: 1 and 2 (tldr, for large amounts of staker smaller consolidations don't significantly change the risk profile; large (relative to your overall amount of stake) consolidations do change it a lot)
• proposals for a el-cl message bus that would open up more solution space for consolidations and custom ceilings: 1, 2

[hwwhww]

On the specs elves side, we are about to merge ethereum/consensus-specs#3668
@ralexstokes made a backlog/TBD list here: ethereum/consensus-specs#3673

[philknows]

Notes here: https://hackmd.io/@philknows/Hywht12eR