LIDO DAO proposal to set “targetValidatorsCount” for Anyblock Analytics operator to 0 to consolidate operations to Blockdaemon account

Node Operators
1

Background

Back in December 2021, Anyblock Analytics was acquired from Blockdaemon, and both entities were in Lido on Ethereum curated Node operators set at the time.
Due to the technical constraints, the operator accounts could not be merged, every now and then causing confusion or complexity with regards to the key limit, since from the protocol perspective, these accounts should be treated as one operator.

With Lido v2 enabling validator exits, it is now possible to clean up the situation (in the sense of getting back to the state where Blockdaemon only runs one Lido NO account), before onboarding new node operators might make it even more complicated.

Explanation of the consequences

By setting “targetValidatorsCount” for Anyblock Analytics to 0 and setting “isTargetLimitActive” set to “True”, the Lido protocol would channel all exits of the protocol to the Anyblock operator, so that the first 2300 validator exits happen there, before other NO’s validators would be exited. Both of these are done via calling “updateTargetValidatorsLimits()” in the Staking Router contract.
At the same time (or rather once gas fees have returned to more reasonable levels), keys to be added and the limit of Blockdaemon operator gets raised (to about 8k keys; currently 5850 keys submitted, but limited to 3800 as per https://operators.lido.fi/.
New activations would then be allocated automatically to the Blockdaemon operator, as it has less active validators – 3800 than the others – who have 6935+ (besides Certus One and Rocklogic, but these NOs are currently not adding new keys). Obviously only if activations exceed exits, but inflows were about ~600k Eth over 20 days (April21-May11), which would be ~9400 validators, so the switch could be expected to be over in a month or so taking exit volume into consideration.
Once caught up, Blockdaemon would grow normally in line with the other node operators again.
Should the “cycling” take too long (i.e. next onboarding round is happening), there is an option for Blockdaemon to “out of order exit” the Anyblock Analytics validators in order to forcefully cycle the stake through the system. This is somewhat non-ideal as there is a sizable entry queue currently, but it could be done slowly and as a last resort, provided there are no objections by the DAO.

Summary

This proposal is to get rid of the “Anyblock exception” for the Lido on Ethereum protocol and streamline operations on Blockdaemon side. The only possible downside is that rebalancing of the protocol (taking exits from the largest NOs) would be delayed by the month or however long it takes.
If approved by the DAO - on-chain vote to be scheduled to make the relevant calls to the Staking Router contract.

10 Likes
2

Thanks for the detailed proposal Freddy!

From my perspective this proposal makes a lot of sense. As you said, a) it removes the operational complexity of Blockdaemon essentially having two entries on the node operator registry, and b) it makes it clearer for reporting, analysis, and stake allocation purposes. Since the process will happen gradually whenever validator exits are needed, it shouldn’t cause unnecessary rewards dilution, and the out of order exit is there as a possibility in case a new onboarding cohort is approaching.

6 Likes
3

Thank you for the proposal! As that’s the request from the team working with Anyblock Analytics validators — the targetValidatorsCount change is to be bundled in the nearest Lido DAO onchain Aragon vote

4 Likes
4

There are two things to consider under this proposal.

  1. Setting targetValidatorsCount to 0 would basically cause Lido on Ethereum protocol to prioritize sending validators exit requests to Anyblocks Analytics validator set. Should note that up to this point Lido on Ethereum had’t had any requests to exit validators under withdrawals processing flow, so the whole process “if the current rates of deposits & withdrawals remain” might take considerable time. Considering this, there’s a decent chance “out of order exit” flow would have to be used; in order to not to impact the protocol’s APR it would have to be done slowly, just as @Freddy_Blockdaemon mentioned in the proposal.
  2. Along with setting targetValidatorsCount to 0, another parameter to set to 0 as well is the stakingLimit (done by calling setNodeOperatorStakingLimit function on the NodeOperatorsRegistry contract); that would doubly-ensure no new stake gets delegated to Anyblock Analytics validators. UPD: the semantics of the field has changed in V2, won’t be touching it in the vote; no new stake would go to Anyblock Analytics if no new keys are sent to the contract either way
1 Like
5

The vote was successfully executed!

1 Like
6

Planning for out-of-band exits of Anyblock validators to migrate to Blockdaemon

With regards to the successful proposal LIDO DAO proposal to set “targetValidatorsCount” for Anyblock Analytics operator to 0 to consolidate operations to Blockdaemon account , the Lido and Blockdaemon team have jointly developed the following plan to migrate the validators from Anyblock to Blockdaemon.

This is to keep the community informed, there is no vote necessary, as the basic idea was already approved in the passed proposal above.

Context considered:

  • There were very few “organic” exits of validators (currently 134 Anyblock validators) in the Lido protocol since Shapella, and there is no indication of this changing significantly any time soon.
  • The DAO wants to onboard new Ethereum node operators by around mid-July.
  • The activation queue is ~45 days long at the moment, and validators in the queue do not earn rewards yet.
  • Exit queue is practically empty and the queue capacity is ~2000 validators per day.
  • Anyblock has 2300 validators to exit https://operators.lido.fi/ (minus already organically exited)

Goals:

  • Not causing a significant exit queue to form or extend the activation queue further for other users of the Ethereum network.
  • Finish the migration process in a reasonable time and potentially use some of the Anyblock exits to “jump-start” the new NOs.
  • Limit the rewards impact for Blockdaemon and other node operators by fairly balancing with other NO number of validators.
  • Limit the rewards impact for Lido coming from Eth that needs to go through the activation queue.

Plan:

  • Test the out-of-band exits with the remaining 8 Anyblock validators on testnet and a small batch on Ethereum Mainnet first.
  • Increase the validator limit of Blockdaemon to 8200-9000 in order to raise the used keys organically via stake inflow to a limit close to the current cohort.
  • Depending on the rate of organic growth on Blockdaemon operation and organic exits on Anyblock operation, start out-of-band exits of 300-500 Anyblock validators per week (in ~2 batches, e.g. Mondays and Wednesdays). Starting exiting with the newest validators in order to avoid potential clashes with organic exits (which would go from oldest to newest).
  • Ideally, if Blockdaemon has arrived at or close to the number of validators of other NOs organically, these exits would happen after the newly onboarded NOs have joined in order to “jump-start” them via the 2300 Anyblock validators. Otherwise, the process gets started before they join to create equal distribution between Blockdaemon and the other node operators.
3 Likes
7

Thank you for the write-up Freddy.

Personally this plan makes sense to me. Given the dilutive effective of possibly mass-exiting all these validators now and waiting for them to re-flow through the queue, it would be preferable to exit most once the new cohort has been onboarded, so it’s probably fine for BD in aggregate to potentially surpass the other node operators for a short amount of time in order to more easily allocate to new onboarders later in the summer.

That said, if there are any objections or other ideas from others, would be glad to discuss them here!