Hi, @Aleksandra_G! Appreciate your ideas!
I believe it is also important to define points where stake distribution actually might change. Forced redistribution might be too resource-consuming. In the current approach, 2 actions might change stake distribution:
- Stake inflow
- Stake outflow
With the outflow, things seem to be a bit simpler since the off-chain part of the VEBO decides what validators should be withdrawn. In contrast, inflow is fully managed on-chain by the staking router. This means that having a complicated model with 1000+ parameters might not be feasible to implement on-chain. One may say that oracles can also be used to manage inflow stake distribution, but it makes protocol even more dependent on trusted Oracles.
My suggestion here will be to rely on a combination of parameters that are available on-chain and DAO governance. With EIP-4788, we now have access to all of BC’s data in a trustless way. However. params like client diversity or HW setup used are not available on-chain (and will hardly ever be). This is where governance comes into play. Allowing governance to supply params values instead of actual shares on-chain will be great. With all these data, the on-chain algorithm can determine inflow stake distribution, also taking into account available capacities.