Suggestion for alternative Foundation delegation strategy in the wake of the 4th December network incident

Validators 🥩
#1

As most probably know by now, we are big fans of decentralization and are impressed with the efforts of the Solana team to foster this. However, the events of 4th December, with an as yet unidentified bug halting the mainnet and a restart that took some time to co-ordinate a sufficient number of validators, raises questions about the pace of decentralization and whether it might be worth adjusting the Foundation’s delegation strategy in the short-term to strengthen the network. We would like this thread to serve as a basis for discussion and would welcome any constructive thoughts on this subject.

The lengthy network outage was not lost on the wider crypto-community, it was widely publicized, appeared to trigger a token-price decline on the markets and, not unexpectedly, was pounced on by trolls. With mainnet still in its beta stage we could encounter similar incidents and it is clearly in the community’s best interests to be as well prepared as possible to minimize downtime.

The large number of less experienced validators, without sufficient monitoring/alerting to bring such an issue to their attention seems to have prolonged the restart. This is not a criticism of them, indeed, in the long term we want anyone to be able to validate on Solana. Part of achieving this goal is tooling that not only makes node provisioning easy, but also provides comprehensive monitoring/alerting and logging tools; components that professional validators like ourselves use today. The development of all this tooling in an easy to use format will take time and is not available yet.

To strengthen the network in the interim we suggest that the Foundation restricts its initial delegation to a smaller number of validators (potentially in the 50 to 100 region), for the next 3-6 months. This number should then be expanded as we improve confidence in the network.

Potential selection criteria could include:

  1. KYC
  2. Length of time on testnet/mainnet
  3. Running parallel TdS node
  4. Running a backup mainnet node
  5. Responsive to software upgrades
  6. Responsive to any delinquency issues with their nodes (with an agreed target response time)
  7. Provision of logs whenever requested
  8. Email address for alerting to a critical incident requiring a sub 1 hour response
  9. Deploy software built from source
  10. Located at a datacentre with fewer than say 5/10 other Solana nodes

At today’s prices the current plan to delegate around ~270,000 SOL to each mainnet beta validator would only provide annual rewards that are barely sufficient to cover a validator buying and co-locating hardware for a year despite this being the most preferable form of deployment for network strength. This also assumes that the validator will provide admin and personnel costs for free, which is not tenable in the long-term. The proposed reduction in the initial number targeted for delegation would increase rewards 4 fold which could begin to fairly compensate validators for providing quality infrastructure and the resources to support it 24/7 plus devoting energy to tooling development, testing and adoption.

These estimates are obviously based on the current price with a small circulating supply; there is a significant risk that price is adversely affected when the majority of the supply is unlocked in January and if this were to happen we believe it only strengthens the case for reducing the target number of validators in receipt of a Foundation delegation, in order to maintain a strong network.

Whilst this may seem a significant change in temporarily going from ~400 to 100 validators supported by the Foundation, it is worth bearing in mind that absolutely anyone can still run a node via token holdings they either own or from delegations they can attract.

If we go down this route Solana would still be significantly more decentralized than many networks and the number of validators will only increase over time. In parallel we can work to improve the Nakamoto coefficient by implementing some form of @eric’s excellent yield-throttling proposal to create the incentive for nodes holding many millions of staked tokens to redistribute, preferably by stake re-delegation. A network with only 100 demonstrably independent nodes but a better Nakamoto coefficient is likely much more robust and censorship resistant than one with 400+ nodes in which the top 7 are capable of halting the network.

We would love to hear other people’s thoughts on this. I think it boils down to 2 key decisions:

  1. Are people in favour of a change that would concentrate the Foundation’s delegations on an initial small high-quality validator set and then grow it over time?

  2. If so, what are good values for the selection parameters for this smaller set?

3 Likes
#2

I will support the vehicle, there is common sense, and it is obvious here.
I would also add an initial custom stack to the list of requirements, for deploying a validator of 5000-10000 coins. This will also reduce freeloaders and reduce the list of random validators.

3 Likes
#3

Thank you for your support on this.

I think that the requirement to “have skin in the game” with entry criteria that includes a minimum number of self-owned tokens is sound. A number of other networks have this in their model.

#4

Just copy what W3F did in their 1000 validators programme:

  1. minimum self stake of sizeable amount (skin in the game)
  2. history of successfully running a node in sister network (tds in solana’s case)
  3. 12/24h upgrades

Breaking the rules throws you out of the game or reduces the size of delegated stake.

Been advocating skin in the game this for more than a month already (link to discord):

thanks @MBGBuzzer for promoting my idea :wink:

also notice the idea about proportional foundational delegation - the more you stake youself (or stake from your delegators) - the more portion of foundational stake you receive. skin in the game is a must for a PoS network!

3 Likes
#5

@AGx1

Thank you for this contribution.

Looking at the originally suggested criteria of:

  1. KYC
  2. Length of time on testnet/mainnet
  3. Running parallel TdS node
  4. Running a backup mainnet node
  5. Responsive to software upgrades
  6. Responsive to any delinquency issues with their nodes (with an agreed target response time)
  7. Provision of logs whenever requested
  8. Email address for alerting to a critical incident requiring a sub 1 hour response
  9. Deploy software built from source
  10. Located at a datacentre with fewer than say 5/10 other Solana nodes

You are particularly endorsing 2 and 3 and adding no 11 A minimum sizeable self-stake

Your point about self stake influencing the amount of foundational stake is well made with the proviso that it is not just whales who by virtue of their purchasing power come to dominate this, which has happened on other networks. Therefore I suggest that somehow all of these factors are taken into account in determining the foundations initial delegation.

Thank you for this. I think it makes sense. I am still interested in other inputs so let’s hear what others have to say.

#6

Surely that N11 should not be straight forward so it just amplify purchasing power. But to some extent it should. Something like “Should receive no more than xx% of total delegation, no more than xxx SOL etc”.

I can argue on almost all of the 1-10 statements but like the overall idea of raising the bar for participants so the ones who stay receive more and be more motivated to do better. Your point of free personnel costs are exactly what’s worrying me most.

1 Like
#7

Hi, Thank you for the additional qualification. I agree that some sort of cap would make sense to ensure that wealthy validators do not dominate. That plus the other criteria should make a difference.

You are right to come back to the fundamental issue of reward for running a truly secure, robust and capable validator, with strict monitoring and control and sufficient redundancy. It cannot be the bare minimum and it cannot be something which does not reflect the costs of resourcing the development and 24/7 operation of nodes.

#8

I just want to add that email communication is too slow, better use whatsapp or signal for critical incidents.